MCPとは？ローカルLLMへツールをつなぐ前に知る仕組みとリスク

MCP（Model Context Protocol）を使うと、AIアプリから外部のデータやツールへ共通の仕組みで接続できる。

ただし、「MCPへ対応しているなら、何でも安全に自動操作できる」という意味ではない。

ローカルLLMへMCPをつなぐ前に決めたいのは、その作業に本当に外部ツールが必要か、必要ならどの権限だけを渡すかだ。

ホスト・クライアント・サーバーを分けて考える

MCPの構成では、利用者が触るAIアプリがホストとなり、その中のクライアントがMCPサーバーへ接続する形を取る。

大まかには次のように分けられる。

要素	役割
ホスト	会話や権限、クライアントを管理するAIアプリ
クライアント	特定のMCPサーバーとの接続を維持する部分
サーバー	ツールや参照用データなどの機能を公開する側
ツール	外部システムへ処理を要求できる機能
リソース	アプリが参照する情報

「LLMが直接PCを操作する」と一括りにせず、どのサーバーが何を公開し、ホストがどこまで許可するかを見る。

ツールを追加すると操作できる範囲が増える

MCPのツールは、モデルへ知識を追加するだけのものではない。

サーバーによっては、

• ファイルの読み書き
• データベース操作
• ブラウザー操作
• 外部APIの呼び出し

などを要求できる。

そのため、利用できるツール数が多いほど常に良いとは限らない。

必要なのが「このフォルダーのファイル名を読むこと」だけなら、書き込み、削除、シェル実行まで同時に渡す理由はない。

何を読めて、何を変更できるかを確認する

最低限、次の4点を見る。

• 何を読み取れるか
• 何を変更できるか
• 実行前に人が内容を確認できるか
• 実行結果やエラーがログへ残るか

ツールを有効にする前に、この4点を説明できないなら権限を広げない。

サーバー側の説明だけを安全性保証にしない

MCPの仕様には、ツールの説明や注釈を扱う仕組みがある。

ただし、「読み取り専用と表示されている」「破壊的ではないと書かれている」といった情報だけで、未知のサーバーを無条件に信頼しない。

配布元、コード、実際に要求する権限、通信先などを別に確認する。

同じPC内とネットワーク越しでは確認点が違う

同じMCPでも、同一PC内のプロセス同士で接続する場合と、ネットワーク越しのサーバーへ接続する場合では境界が違う。

ネットワーク越しなら、認証や認証情報の保存方法も確認対象になる。

一方、ローカルで動くMCPサーバーでも、同じWindowsユーザーが触れる広いファイルへアクセスできるなら、その権限は残る。

「ローカルだから安全」「認証を付けたから安全」と一つの条件だけで結論づけない。

最初は読み取りだけのツールを一つ試す

MCPが必要だと判断したら、最初は小さく始める。

1. 信頼できる配布元のサーバーを一つ選ぶ
2. 読み取りだけで済むツールを一つ有効にする
3. ホストが実行内容をどう表示するか確認する
4. 実行前に拒否できるか確認する
5. 結果とログを照合する
6. 必要になった権限だけ追加する

便利そうなサーバーを大量に登録してから権限を調べるのではなく、一つずつ境界を確認する。

MCPを導入する理由は「新しい仕組みだから」ではない。モデルの回答だけではできない外部操作が本当に必要かで判断し、必要な操作だけを最小権限で接続する。