MCP入門：AIに外部ツールを触らせる仕組みの基本
AIエージェントを日常的に使うようになって、「このフォルダのファイルを読んで」「GitHubのIssueを一覧して」みたいな頼み方がすっかり普通になりました。でも、AIアプリケーションと外部ツールのあいだをどう繋ぐかは、少し前まで製品ごとにバラバラでした。その接続部分の共通規格として広がってきたのが、MCP（Model Context Protocol）です。
公式ドキュメントは、MCPを「AIアプリケーションにとってのUSB-Cポート」に例えています。USB-Cが機器同士の接続を標準化したように、MCPはAIアプリケーションと外部システム（ファイル、データベース、カレンダー、各種API）の接続を標準化する、という発想です。2024年11月にAnthropicが提唱して公開し、その後いろいろなAIアプリケーションや開発ツールが対応を表明しました。
この記事では、MCPを「使う側」の視点で地図を描きます。サーバを自作する前の段階として、登場人物とデータの流れ、それと権限まわりの考え方を押さえるのが目的です。なお、普段のAIエージェントの使い分けについては、AIコーディングエージェントの使い分けメモに書いています。
まず困りごとから：接続が「組み合わせごと」だった
MCPが解決しようとしたのは、接続の組み合わせ爆発です。AIアプリケーションが10種類、繋ぎたい外部サービスが10種類あると、個別対応では最大で100通りの実装が必要になります。サービス側が「MCPサーバ」を1つ用意し、アプリケーション側が「MCPクライアント」を1つ実装すれば、あとは規格に合う同士で自由に組み合わせられる。実装の総量が掛け算から足し算になる、というのが一番大きな価値だと思います。
もちろん、規格があっても各サービスがサーバを用意しなければ始まりません。ただ、ファイルシステムやGitHub、カレンダーのような定番どころは公式・非公式のサーバ実装が揃ってきていて、「まずは既存のサーバを繋いで試す」が現実的な入り口になっています。
登場人物は3つだけ
MCPの構成要素は、ホスト／クライアント／サーバの3つです。名前の印象と実際の役割が少しずれるので、最初にここを押さえると後の話が全部楽になります。
| 役割 | 何をするものか | 例 |
|---|---|---|
| ホスト | ユーザーが触るAIアプリケーション本体。モデルとの会話を管理し、どのサーバに繋ぐか、ツールの実行を許可するかといった判断と安全境界を持つ | Claude Desktop、Claude Code、VS Code などのAI対応アプリ |
| クライアント | ホストの中にある接続部品。1つのサーバに対して1つ作られ、そのサーバとの通信を担当する | ホスト内部の実装（ユーザーが意識することはほぼない） |
| サーバ | 機能やデータを外に提供するプログラム。ファイル読み書き、DB検索、外部APIの呼び出しなどを引き受ける | ファイルシステムサーバ、GitHubサーバ、DBサーバ |
ややこしいのは「クライアント」が独立したアプリではない点です。ホストがサーバ3つに繋ぐなら、ホストの内側にクライアントが3つできる。サーバ側から見ても、相手はいつも「1つのクライアント」です。
押さえどころ：会話しているモデル自身がMCPを話すわけではありません。モデルは「このツールを使いたい」という要求を出すだけで、実際にサーバへ依頼を送り、結果を受け取ってモデルに返すのはホスト（とその中のクライアント）の仕事です。だから、実行の許可・不許可を握っているのもホスト側になります。
サーバが渡してくれる3種類のもの
サーバが提供する機能は、Tools／Resources／Prompts の3種類（プリミティブ）に分類されます。似たようなものに見えて、「誰が使う判断をするか」がきれいに分かれているのがポイントです。
| 種類 | 中身 | 使う判断をするのは | 代表的なメソッド |
|---|---|---|---|
| Tools | AIが呼び出す「操作」。ファイルの書き込み、API呼び出し、DBへのクエリなど、副作用を持ちうる | モデル（文脈に応じて自動で選ぶ） | tools/list、tools/call |
| Resources | 読み取り専用の「データ」。ファイルの中身、DBのスキーマ、ドキュメントなど、文脈として渡す情報 | アプリケーション（何を取り込むかはアプリ側が決める） | resources/list、resources/read |
| Prompts | 定型の「指示テンプレート」。引数を渡すと、その作業向けに整えた指示文が返る | ユーザー（明示的に呼び出す） | prompts/list、prompts/get |
たとえばデータベース用のサーバなら、「クエリを実行する」はTool、「テーブル定義を返す」はResource、「このDBの分析手順」はPrompt、という具合に分かれます。Toolsだけが目立ちますが、読むだけの情報はResourcesに寄せる設計の方が、権限管理の面でも安全です。この切り分けは、サーバを選ぶときの見方としても使えます。「そのサーバ、読み取りと書き込みがちゃんと分かれているか」は地味に効いてきます。
通信の中身：JSON-RPCと、2つの運び方
クライアントとサーバのあいだでやり取りされるメッセージは、JSON-RPC 2.0 という形式で統一されています。大まかな流れは次のとおりです。
- クライアントがサーバに、対応しているプロトコルのバージョンや機能を確認する
tools/listなどで、使える機能の一覧を取得する- モデルがツール使用を決めたら、ホスト経由で
tools/callを送り、サーバが実行して結果を返す - 応答が不要な連絡（状態の変化など）は、通知メッセージとして送られる
このJSON-RPCのメッセージを「どう運ぶか」がトランスポートで、規格として定義されているのは次の2つです。
| 運び方 | 仕組み | 向いている場面 |
|---|---|---|
| stdio | サーバを子プロセスとして起動し、標準入出力でメッセージをやり取りする | 自分のマシン上で動くローカルサーバ。ネットワークを介さないので速く、構成も単純 |
| Streamable HTTP | HTTP POSTでメッセージを送り、必要に応じてServer-Sent Eventsでストリーミングを受ける | リモートサーバ。複数クライアントからの利用や、チーム共有に向く |
手元のファイルを触るようなサーバはだいたいstdio、SaaSと繋ぐようなサーバはStreamable HTTP、という住み分けが典型です。認証もこの層の話で、リモート接続ではBearerトークンやAPIキーといったHTTPの標準的な認証が使え、公式には認可の仕組みとしてOAuthの利用が推奨されています。
権限の話：便利さと怖さは同じところから来る
MCPで一番考えておきたいのは、実はこの部分です。Toolsは「モデルが判断して呼び出す操作」で、サーバ次第ではファイルの削除や外部への送信までできてしまいます。便利さは、そのまま権限の大きさです。
自分のルール：MCPサーバを繋ぐ前に、「読むだけか、書くのか、消せるのか」を先に確認する。最初は読み取り専用のものから入れ、書き込み系は対象フォルダや対象サービスを絞ったものだけにする。削除や送信のような取り消しにくい操作は、都度承認が挟まる設定でないなら繋がない。
公式ドキュメント側も、ツール実行前のユーザー同意、実行ごとの承認ダイアログ、安全な操作だけ事前承認する設定、実行履歴の表示といった「人間の監督」を挟む仕組みを、アプリケーション側の備えるべきものとして挙げています。つまりMCPは「何でも自動でやらせる」ための規格ではなく、権限の渡し方を設計できる形に揃えた規格、と読むのが正確だと思います。
あわせて、サーバ自体の出どころも確認が要ります。MCPサーバは要するに「自分の環境で動くプログラム」なので、配布元が信用できるかは、普通のソフトウェアを入れるときと同じ物差しで見ます。設定ファイルにAPIキーを書く場面も多いので、キーの権限範囲も最小にしておくのが無難です。
任せる作業と任せない作業の線引き全体については、AIに任せる作業・任せない作業の線引きで整理しています。
触ってみるなら
入門としては、いきなりサーバを自作するより、既存のサーバを1つ繋いで tools/list で何が並ぶかを眺めるのが早いです。サーバが「自分は何ができます」と宣言する一覧を見ると、ToolsとResourcesの切り分けや、説明文（モデルはこの説明を読んで使うかどうかを判断します）の書きぶりが実感できます。開発向けには、サーバの動作を確認するための公式ツール「MCP Inspector」も用意されています。
MCPの全体像は、結局のところ「AIに手足を持たせるための、権限設計込みの接続規格」です。仕様の細部は更新されていきますが、ホスト／クライアント／サーバの3役と、Tools／Resources／Prompts の切り分けさえ掴んでおけば、新しいサーバや対応アプリが出てきても迷子にならないはずです。