MCPプロトコル：AIエージェントに必要な共通言語

1. 序論

2024年11月、AnthropicはMCPをオープンソース化した——地味な実験プロジェクトだった。
一年半後、状況は一変した。Google、OpenAI、Microsoft、AWSが相次いで支持を表明し、
GitHubでは3000以上のMCP Serverが稼働し、
MCPはLinux Foundation傘下のAgentic AI Foundationに正式に組み込まれた。

一つのプロトコルが、ゼロから業界のコンセンサスに至るまで、わずか一年半。

2024年にAI Agentを構築したことがあるなら、おそらくこんな場面を経験しているはずだ。モデルがSlack APIを呼び出し、PostgreSQLを照会し、Google Driveにファイルを書き込む——そのたびにfunction call wrapperを手書きし、パラメータ形式は自作し、エラーハンドリングも自分で書く。モデルベンダーを変えたら？　ほとんどのwrapperを書き直すことになる。

これがMCPが解決しようとする核心的な問題だ。AI AgentのHTTP——無数の独自コネクタに取って代わる、汎用プロトコルである。

2. 全体像：MCPの現在地

M×N問題

自社に5つのLLMベンダーと20の内部データソースがあるとしよう。MCPがなければ、5 × 20 = 100個のカスタムコネクタが必要になる。各コネクタは独自プロトコル、独自フォーマット、独自認証方式だ。

MCPのアプローチはこうだ。各データソースがMCP Serverを公開し、すべてのLLMが同一プロトコルで接続する。5 + 20 = 25個のインターフェースで、75%の削減になる。

プロトコルの中核アーキテクチャ

MCPは3層モデルを採用している。

Host（ホストアプリケーション、例：Claude Desktop / VS Code）
  └── Client（プロトコルクライアント、接続ごとに1つ）
        └── Server（ツール／データ提供側）

三者の責務は明確だ。

層	責務
Host	接続の起動、ユーザー認可の管理、複数Clientの調整
Client	Serverとの1対1接続の確立、能力ネゴシエーション、プロトコルメッセージの送受信
Server	Tools / Resources / Promptsの公開、具体的な操作の実行

Serverは3種類の能力を提供できる。

能力	説明	類推
Tools	モデルが実行できる関数（副作用あり）	API endpoint
Resources	モデルが読み取れるコンテキストデータ	ファイルシステム
Prompts	事前定義されたプロンプトテンプレート	ショートカット

ClientもServerに対して逆方向に能力を提供できる。

能力	説明
Sampling	ServerがLLMにコンテンツ生成を要求する（Server自身がAPI Keyを保持する必要がない）
Roots	ServerがClientにファイルシステムの境界を問い合わせる
Elicitation	ServerがClientにユーザーから追加情報を取得するよう要求する

重要な設計：JSON-RPC 2.0

プロトコルの基盤にはJSON-RPC 2.0を使用している。ステートフルな接続で、ClientとServerは初回ハンドシェイク時に互いの能力セットを通知し、以降は必要に応じて呼び出す。

// Tool 呼び出しの例
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "東京",
      "unit": "celsius"
    }
  }
}

3. トランスポート層の進化：SSEからStreamable HTTPへ

第一世代：SSE + HTTP POST

2024年の初期MCP specでは、Server → ClientのプッシュにServer-Sent Events（SSE）を、Client → ServerのリクエストにHTTP POSTを使用していた。

欠点は明らかだ。

SSEは単方向の長接続であり、ロードバランシングができない
企業のWAFがSSEの内容を検査しにくい
デバッグが困難

第二世代：Streamable HTTP（2025年3月）

2025年3月のspec更新（2025-03-26）で、SSEはStreamable HTTPに置き換えられた。単一のHTTPエンドポイント /mcp に統一し、ストリーミングレスポンスと通常レスポンスの両方をサポートする。

GET /mcp → Serverがストリーミングイベントをプッシュ
POST /mcp → Clientがリクエストを送信し、Serverがストリーミングまたは単一レスポンスで応答

ヘッダー: Mcp-Session-Id → セッション復元

主な改善点：

エンタープライズ互換：HTTPリクエストは標準的なWAFで検査でき、標準的なロードバランサーで分散できる
デプロイの簡素化：専用のSSE接続プールを維持する必要がない
セッション復元：Mcp-Session-Id headerによる切断後の再接続をサポート

2026ロードマップにおけるトランスポート層の方向性

2026年のロードマップでは、トランスポート層が第一優先に位置づけられている。要点：

ステートレスSession：現在のMCPのSessionはステートフルであり、水平スケーリングを妨げている。方向性は、状態をRedis／データベースに外部化し、任意のServerインスタンスが任意のリクエストを処理できるようにすることだ。
MCP Server Cards：.well-known/mcp.json を通じて静的メタデータを公開する——接続を確立せずにサービス能力を発見できる。
新しいトランスポートプロトコルは作らない：ロードマップは、このサイクルで新しい公式トランスポートプロトコルを追加せず、既存のStreamable HTTPのみを進化させると明言している。

📝 2026-10-12 更新：この方向性はすでに実現している。2026年7月28日に公開された正式仕様（2026-07-28）は、MCPをステートレスプロトコルへと変更した。initialize ハンドシェイクと Mcp-Session-Id headerは廃止され、各リクエストは _meta 内にプロトコルバージョンとクライアント能力を自ら持つ。サービス能力を発見するためのオプションの server/discover が追加された。HTTPリクエストには Mcp-Method / Mcp-Name headerが必要になり、ゲートウェイルーティングが容易になった。呼び出しをまたぐ状態が必要な場合は、Serverが明示的なhandleを生成し、ツールパラメータとして返す方式に変わった。上述の「セッション復元」メカニズムは新仕様では削除されている。詳細は公式ブログを参照。

4. 2026ロードマップ：4つの優先方向

2026年3月に公開されたロードマップは、MCPが開発者ツールプロトコルからプロダクショングレードのインフラプロトコルへと転換する決意を示している。

1. 🚄 トランスポート層の進化（Transport Evolution）

すでに前述で詳しく論じた。核心は、MCPを開発者のノートPC上ではなく、真のプロダクション環境で動かせるようにすることだ。

2. 🤖 エージェント間通信（Agent Communication）

Tasksプリミティブ（SEP-1686）：これはロードマップの中で最も画期的な新概念だ。

Toolsは同期である——呼び出し → 待機 → 返却。 Tasksは非同期である——タスク投入 → タスクID取得 → 進捗ポーリング → 結果取得。

# Tools（同期）
result = tool.call(params)
# 完了まで待機

# Tasks（非同期）
task_id = task.submit("この100ページのレポートを分析して")
while True:
    status = task.get_status(task_id)  # processing / completed / failed
    if status == "completed":
        result = task.get_result(task_id)
        break
    time.sleep(5)

これはマルチAgent協調の場面で極めて重要だ。Agent Aが長時間の分析タスクをAgent Bに投入し、他の作業を行い、完了後に結果を取りに戻る。

現在Tasksは実験的機能としてリリースされており、ロードマップはライフサイクルのギャップを埋めつつある：リトライセマンティクス、結果の有効期限ポリシー、進捗通知メカニズム。

3. 🏛️ ガバナンスの成熟化（Governance Maturation）

MCPは多企業が参加するオープン標準（Linux Foundation / AAIF）へと成長した。ガバナンスがそれに追いつく必要がある。

ロードマップにおける主要な施策：

貢献者ラダー（Contributor Ladder）：コミュニティ参加者 → WG貢献者 → WGコーディネーター → 首席メンテナー。各ステップに明確な推薦と審査の基準がある
Working Groupの自治：信頼されたWGは自領域内でSEPを承認でき、コアメンテナーの審査を待つ必要がない——これはレビューのボトルネックを解消する鍵となる施策だ
SEPプロセス：Specification Enhancement Proposal。PythonのPEP / RustのRFCに相当する

4. 🏢 エンタープライズ対応（Enterprise Readiness）

これは2026ロードマップの中で最も「初期段階」の方向性であり、より多くの企業参加者が必要であることが明言されている。

監査証跡：Agentがどのツールを呼び出し、どのパラメータを渡し、どのような結果が返ったか——エンタープライズグレードのログ
SSO統合：OAuth 2.1 + OIDCを通じて企業のアイデンティティ体系に接続
ゲートウェイ標準化：MCP ClientとServerの間にポリシー実行ポイントを配置
設定のポータビリティ：環境（開発／テスト／本番）をまたいだMCP設定の移行

ロードマップの立場は興味深い。ほとんどの企業要件はExtensions（拡張）を通じて実現すべきであり、コアプロトコルを変更すべきではない。 コアプロトコルは軽量に保ち、企業向け機能はオプションの拡張レイヤーとして重ねる。

5. 実践：私が使っているMCP

理論はここまでにして、MCPが実際の環境でどう動くかを見てみよう。

私自身が使っているAI Agent（Hermes Agent）にはNative MCP Clientが組み込まれている。設定方法は簡単だ——設定ファイルでMCP Serverを宣言するだけ：

mcp_servers:
  # stdio トランスポート——MCP Serverを子プロセスとして実行
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]

  # HTTP トランスポート——リモートMCP Server
  company_api:
    url: "https://mcp.company.com/v1/mcp"
    headers:
      Authorization: "Bearer sk-xxx"

起動後、AgentはすべてのServerに自動接続し、それらが公開するツールを発見して、ツールリストに登録する。開発者はアダプタコードを一切書く必要がない——MCPツールは組み込みツールと対等に扱われる。

実際に使ってみての所感

新しいツールはプラグアンドプレイ：設定を一行追加し、Agentを再起動すれば、新しい能力が即座に利用可能になる
Transportは透過的：stdioでもHTTPでも上位のAgentにとって違いはない
環境分離：MCP Serverの子プロセスはフィルタリングされた環境変数を継承する（API Keyは手動ホワイトリスト方式）ため、ホスト環境が漏洩しない
ツール数が一定規模を超えると、ツールのSchema記述が大量にTokenを消費する——現在はLazy Loading方式（必要に応じてツール記述をロード）があるが、まだ進化の途上にある
Server側のエラーハンドリングは玉石混交：規範的なエラーを返すServerもあれば、生の例外を返すものもある
子プロセスのライフサイクル管理：Serverクラッシュ後の自動再接続メカニズムは各SDKの実装品質に依存する

Sampling能力の実際的な意義

MCPのSamplingは過小評価されている機能かもしれない。これにより、MCP Serverは自身がAPI Keyを保持することなく、LLMに逆向きにコンテンツ生成を要求できる。

例えば、データ分析MCP Serverはリクエスト処理中に、Hostを通じてLLMに説明文を生成させることができる。ServerはAPI Keyを必要とせず、Claudeを使っているかGPTを使っているかを気にする必要もない——モデルはHostが決める。

これは企業環境で非常に重要だ。ツール提供側はモデルキーを保持する必要がなく、モデル提供側はツールエンドポイントを公開する必要がない。 セキュリティ境界が明確になる。

6. 競争環境

MCP vs A2A（Agent-to-Agent）

Googleは2025年4月にA2A（Agent-to-Agent）プロトコルを発表した。よくMCPと比較されるが、実際には両者は異なる層の問題を解決している。

次元	MCP	A2A
層	Tool層（モデル ↔ ツール）	Agent協調層（Agent ↔ Agent）
核心問題	ツール呼び出しをどう標準化するか	Agent間協調をどう標準化するか
メッセージ形式	JSON-RPC 2.0	JSON-RPC + Task記述
状態モデル	ステートフル接続	ステートレス + タスクリスト
適用場面	データベース照会、API呼び出し、ファイル操作	マルチAgentオーケストレーション、組織間協調

両者は代替関係ではなく、補完関係にある。理想的には：Agent内部ではMCPでツールを呼び出し、Agent間ではA2Aでタスクを調整する。

各ベンダーの実装

Anthropic：MCPの提唱者。Claude Desktop / Claude Codeに全面的に組み込み
OpenAI：2025年3月にMCPサポートを発表。Agents SDK v0.12でMCPリトライとエラー正規化を追加
Google：MCPをサポートしつつ、ADK v2.0のTask API（A2AのPython実装）をリリース
Microsoft：Agent Governance Toolkit（AGT）をリリース——MCP ClientとServerの間にポリシー実行層を挿入し、ツール定義をスキャンし、入出力を検査し、監査ログを記録する
Vercel：@ai-sdk/mcp v2を独立パッケージとしてリリース。OAuth2.0、Structured Output、Resourcesをサポート

マイクロソフトのAgent Governance Toolkit

特に注目に値するのがマイクロソフトのAGTだ。これは企業顧客がMCPに対して抱く根本的な懸念を反映している。ツール呼び出しが便利になるほど、セキュリティリスクは大きくなる。

AGTの機能：

ツール定義スキャン：Agentがツール記述を見る前に、隠し命令、偽装攻撃、敵対的パターンの有無を検査する
呼び出しごとのポリシー実行：宣言的ルール（YAML / OPA / Cedar）で各ツール呼び出し前にポリシーチェックを行い、オーバーヘッドは<1ms
レスポンス検査：ツールが返した内容をAgentに渡す前にコンテンツポリシーを通す
アイデンティティと信頼：各Agentが暗号化ID（Ed25519 + 量子安全ML-DSA-65）を取得し、信頼スコアは0-1000
読み取り専用の改ざん不可能な監査ログ：ハッシュチェーン形式で各ツール呼び出しを記録する

AGTはOWASP MCP Top 10に対して7/10をカバーし、残り3項目はロードマップに含まれている。

7. 展望

コンテキストウィンドウの危機

MCPが普及するほど、ある問題が際立ってくる。ツールSchemaがコンテキストウィンドウを食い潰すのだ。

初期のテストでは、20のMCP Serverに接続したAgentは、Tool Definitionsだけで70000+ Tokenを消費した。すべてのツールのSchema記述が存在すれば、実際の会話に残されるToken空間はほとんどない。

解決策の方向性：

Tool Search：Agentがまず「検索ツール」というツールをロードし、それを使って他のツールを発見する——すべてを一度にロードするのではなく
Lazy Loading：defer_loading = true を設定し、実際に必要になったときだけ具体的なツールのSchemaをロードする
ツールのグループ化と名前空間：ドメイン（データベース／コラボレーション／ファイル）ごとに整理し、Agentは現在のドメインのみをロードする

MCP Apps——UIインタラクション層

MCP Appsは2026年1月にリリースされた公式拡張だ。これにより、MCPツールはプレーンテキストだけでなく、リッチなインタラクティブUIを返せるようになる。

// MCP Appの例：システム監視ダッシュボード
{
  "app": {
    "type": "dashboard",
    "url": "https://mcp-apps.example.com/system-monitor"
  }
}

対応Client：Claude（Web + Desktop）、Goose、VS Code Insiders、ChatGPT。

MCPに接続すべきか？

あなたの状況	推奨
1-2個のシンプルなツール、単一モデル	function callingで十分。MCPの利益は不明瞭
5+個のツール、複数モデルの切り替え	MCPを強く推奨——N×Mの統合コストを削減できる
エンタープライズ級、監査コンプライアンス要件	MCP + AGTのカスケード方式。投資する価値がある
チーム／プラットフォームをまたいだツールの再利用	MCP Serverを一度書けば、どこでも動く

結び

MCPは一年半で「Anthropicの実験プロジェクト」から「Linux Foundation傘下の業界標準」への飛躍を成し遂げた。その成功は技術がいかに精巧であるかにあるのではない——JSON-RPC 2.0 + HTTPは新しい技術ではない——このタイミングで業界が最も痛感していた協調の問題をちょうど解決したことにある。

5つのLLMと20のツールの間で行き来する必要があるとき、シンプルなルールが千金の価値を持つ。プロトコルを一度書けば、どこでも動く。

MCPに接続するか、もう少し待つか？　どちらの選択も現段階ではそれぞれ適した場面があり、チームの優先順位とリスク選好による。