MCP(Model Context Protocol)整理 — AI がツールを使う標準
このブログのエージェント関連の記事で MCP は何度も登場しましたが、MCP そのものを整理した記事がありませんでした。今回がその 1 本です。結論を先に書くと、MCP(Model Context Protocol)は LLM アプリケーションと外部のツール・データをつなぐオープンな標準プロトコルです。 2024 年 11 月に Anthropic が公開し、2025 年に OpenAI、Google、Microsoft、AWS が相次いで採用したことで、2026 年現在この領域の事実上の標準になりました。実際にアプリで使う方法は LLM アプリ開発 #11 で、サーバーを自作する方法は AI エージェント開発 #6 で扱っており、この記事はその手前に置く概念の整理です。
どの問題を解くのか — N×M を N+M に #
MCP 以前のツール連携は、すべて専用実装でした。アプリが Slack、GitHub、社内 DB にアクセスするには、それぞれの連携をそのアプリ専用にコーディングし、別のアプリを作れば同じ連携をまた作っていました。アプリ(ホスト)N 個 × ツール M 個の分だけ統合コードが生まれる構造です。
MCP はこの間に標準インターフェースを差し込みます。ツール側は MCP サーバーを一度作れば MCP 対応のすべてのアプリから再利用され、アプリ側は MCP クライアントを一度実装すればすべての MCP サーバーに接続できます。N×M が N+M に減ることが、このプロトコルの存在理由です。
Function Calling との関係もここで整理できます。Function Calling は「モデルが決められたスキーマでツール呼び出しを出力する能力」で、MCP は「そのツールを誰がどう提供し、どう発見するか」の標準です。競合ではなくレイヤーが違います。モデルは相変わらず Function Calling でツールを呼び、MCP はそのツール一覧を標準の方式で供給します。
構造 — ホスト、クライアント、サーバーと 3 つのプリミティブ #
- ホスト: ユーザーが向き合う LLM アプリです。デスクトップアシスタント、IDE、エージェントランタイムがここに当たります。
- クライアント: ホストの中でサーバーとの接続 1 本を担当する部品です。ホストがサーバー 3 つにつながれば、クライアントも 3 つです。
- サーバー: ツールとデータを公開する側です。ファイルシステム、GitHub、DB 照会、社内 API のラッパーのように、「モデルに使わせたいもの」がサーバーになります。
サーバーが公開するものは 3 種類に整理されます。
| プリミティブ | 何か | 使う主体 |
|---|---|---|
| tools | モデルが呼び出す動作 (検索、作成、送信) | モデルが判断して呼び出す |
| resources | 読み取り用データ (ファイル、スキーマ、ドキュメント) | アプリがコンテキストとして供給 |
| prompts | 再利用するプロンプトのテンプレート | ユーザーが選択 |
トランスポートは 2 つです。同じマシンでプロセスとして起動する stdio(ローカルのファイルシステムや開発ツール連携の基本)と、リモートサーバーとしてデプロイする streamable HTTP(組織内共有、SaaS 連携)です。リモートサーバーの認証は OAuth ベースで標準化されています。
2026 年現在 — 事実上の標準になった経緯 #
- 2024-11: Anthropic が公開し、オープンソースにしました。
- 2025: OpenAI(3 月、Agents SDK)、Google(4 月、Gemini SDK)、Microsoft(Copilot Studio・Windows)、AWS(Bedrock)が相次いで対応し、「特定ベンダーのプロトコル」というラベルが外れました。
- 2026-01: Anthropic が MCP を Linux Foundation 傘下の財団に移管しました。ガバナンスが中立化され、企業導入の最後の障害が片付いた形です。
- 規模: 公式レジストリに登録されたサーバーは 2026 年半ば時点で 1 万個規模、コミュニティのインデックスまで合わせるとその数倍です。仕様は日付ベースのバージョン(例: 2025-06-18)で改訂され続けているので、SDK 更新時には対象バージョンの確認が必要です。
セキュリティ — 便利になった分、攻撃面も標準化されました #
MCP 導入時に検討すべきリスクはツール連携一般のリスクと同じですが、接続が簡単になった分、踏む頻度も上がります。
- サードパーティサーバーの信頼: レジストリにあることは安全を意味しません。サーバーはモデルにツールの説明を供給しますが、悪意ある説明でモデルの挙動を操る攻撃(tool poisoning)が実証されています。出所を確認したサーバーだけをつなぎ、社内の標準リストを管理するのが基本です。
- プロンプトインジェクション: ツールが取ってきた結果(Web ページ、Issue 本文、メール)に仕込まれた指示文にモデルが従ってしまう問題です。MCP 固有の脆弱性ではなくツールを使うすべてのエージェントの問題で、機微な動作(書き込み、送信、削除)に人の承認を挟むのが現実的な防衛線です。
- 権限の最小化: サーバーに渡す資格情報は読み取り専用、最小スコープから始めます。「とりあえず管理者トークン」が最もよくある事故の入り口です。
- コンテキストの肥大: サーバーをつなぐほどツール定義がコンテキストを侵食し、コストと精度を削ります。作業に必要なサーバーだけを有効にする運用が必要です。
導入の判断 — 必要な場合と、そうでない場合 #
アプリ 1 つがツール 3〜4 個を使う構造なら、MCP なしで Function Calling を直接実装するほうがむしろシンプルです。MCP が価値を出すのは次の場合です。
- 同じツールを複数のクライアントで使う場合。IDE でも、デスクトップアシスタントでも、自作エージェントでも同じ社内ツールを使いたいなら、サーバー 1 つで済みます。
- 組織の中でツールを共有する場合。チームごとに同じ連携を作り直す代わりに、社内 MCP サーバーの一覧を標準資産として管理します。
- サードパーティのエコシステムを活用する場合。すでに作られたサーバー(GitHub、DB、検索など)をつないで、開発なしでツールを確保します。
- エージェントを製品として作る場合。ユーザーに自分のツールをつながせるなら、標準プロトコル以外の選択肢は事実上ありません。
まとめ #
- MCP は LLM アプリとツール・データをつなぐオープンな標準です。ツール連携の N×M 問題を、サーバー 1 回・クライアント 1 回の N+M に減らします。
- Function Calling とは競合しません。Function Calling はモデルの出力能力で、MCP はツール供給の標準です。
- 構造はホスト・クライアント・サーバー、サーバーが公開するのは tools・resources・prompts です。ローカルは stdio、リモートは streamable HTTP + OAuth です。
- 2025 年の主要ベンダー採用と 2026 年初の財団移管で、事実上の標準になりました。仕様は日付バージョンで改訂され続けています。
- サードパーティサーバーの信頼、プロンプトインジェクション、権限の最小化がセキュリティ検討の軸です。ツール数個の単一アプリなら、導入しないのも正解です。