第2章 — Model Context Protocol (MCP) の正体

LLM Primer IV: MCPで設計するAI認知 のウォークスルー第2回です。今回は、本書の残りを支えられる程度に丁寧に、メンタルモデルを組み立てます — 3つの役割、JSON-RPCのワイヤ形式、動的なディスカバリ面、そしてセッション・ライフサイクル。

なぜこの章があるのか

第1章は問題に名前を付けました。この章は、答えのメンタルモデルを組み立てます。MCPは一文で要約でき、一段落で誤解されます。なので時間をかけます — ワイヤ・レベルでのプロトコルの正体、3つの役割が何を意味し何を所有するのか、本番で本当に効いてくる場面でRESTとどう違うのか、接続から終了までセッションの中で何が起きるのか。この章を読み終えるころには、次章を読む前に、サーバープリミティブはどういう形でなければならないか、クライアントプリミティブはどういう形でなければならないか、そしてMCPがなぜ今の構造を選んだのかを、自分で予測できる状態を目指します。

2.1 MCPとは何か、「AIのUSB-C」の本当の意味

Model Context Protocolは、LLMアプリケーションが外部の能力を発見し、記述し、呼び出すためのオープン仕様です。ワイヤ上はJSON-RPC 2.0が、少数のトランスポートのうちのどれかに乗ります。アーキテクチャ上は、ホストがどの準拠サーバーとも特注の統合コードなしに動ける契約です。プロトコルに対して一度作られたツールは、それを話すすべてのホストで動きます。プロトコルに対して一度作られたホストは、それを話すすべてのツールを使えます。

定着した言い回しは「AIのUSB-C」です。形は本当にUSB-Cに似ています — 開かれたデバイス群と開かれたホスト群の間を、ひとつの接続標準が仲介する。比喩の限界も名前を付ける価値があります。USB-Cはコネクタとその上のスタックを標準化する。MCPはプロトコルだけを標準化する。USB-Cは電気的なタイムスケールで動き、ハードウェアがフレーミングを強制する。MCPはネットワーク的なタイムスケールで動き、フレーミングはソフトウェア定義 — だからより柔軟である代わりに、切れる接続と遅いピアを自分で扱わなければなりません。

エンジニアにとって近いのはLSPです。Language Server Protocolは、どのエディタとどの言語サーバーも話せるプロトコルを定義しました。MCPは、どのLLMホストとどの能力プロバイダも話せるプロトコルを定義します。勝ち筋の形は同じ — 多対多が共有プロトコルで加法的にスケールする形に畳まれる、というもの。新しいワイヤ形式を発明するのではなくJSON-RPC 2.0を選んだのは意図的です。小さくて、成熟していて、言語非依存で、地味。面白いアーキテクチャ上の選択はワイヤレベルにはありません。Host・Client・Serverがどう責任を分担するか、そこにあります。

2.2 Host・Client・Server — それぞれが所有するもの

MCPは3つの役割を定義します。まず理解すべきは、ここで言う「Client」と「Server」が、他所での意味とは違うことです。Server は能力を公開します — ツール、リソース、プロンプト。Client は、もっと大きなアプリケーションの中で管理される、ひとつのサーバーへの単一のプロトコル接続です。その大きなアプリケーションが Host。Hostはモデル、ユーザーのセッション、そしてモデルが何をしてよいかのポリシーを所有します。Servers はそれぞれの能力面を所有します。Clients はその間を結ぶ配線で、サーバー1つにつき1つです。

この分割が効くのは、それぞれが違う責任と違う信頼姿勢を持つからです。ユーザー視点で意味のある信頼境界はホスト。それ以外はすべて、ホストが「入れることに決めた」もの。5つのサーバーと話すホストは、内部に5つのClientを走らせ、それぞれが自分のセッション状態、自分のサブスクリプション、自分が交渉済みの能力の見え方を持ちます。あるサーバーがクラッシュすれば、対応するClientがクラッシュする。他のClientは生き続け、Hostは生き続けます。Clients は、悪いサーバーがセッション全体を汚染しないようにする接続ごとの絶縁体です。

分割にはセキュリティ上の論拠もあります。どのサーバーも、最低限、誰か他人が書いたコードです。サーバーがホストに影響しうるすべて — 通知、Elicitation、Sampling要求、公開リソース — をClientが仲介し、サーバーごとのポリシーが宿る場所になります。Host・Client・Serverは論理的な役割で、厳密に物理的なものではありません。ローカル構成では Server はしばしば stdio で動くサブプロセス。リモートのデプロイではHTTPベースのトランスポート上のサービス。プロトコルは気にしません。役割の境界が気にします。

2.3 MCPとRESTの違い — 動的ディスカバリと意味的記述

もっともな質問は「これはRESTでよくないか」です。違いは化粧ではありません。最も大きいのは、動的ディスカバリ、LLM向けに書かれた意味的記述、そして双方向メッセージモデル。

REST APIはエンドポイントを人間の開発者向けのドキュメントで公開します。クライアントが使うエンドポイント集合はビルド時に固定で、新しいエンドポイントは再デプロイが必要です。MCPは逆向きです。セッション開始時にClientが「何を提供しますか」と問い、Serverは型付きカタログ — スキーマ、説明、メタデータ — を返し、ホストがプログラムで使います。サーバーがあとからツールを追加すれば、listChanged 通知が再起動なしにセッション中のClientを更新します。Serverが自分の能力についての権威ある真実の源泉で、説明は実装からドリフトできません — ドリフトするためのクライアント側のコピーが存在しないからです。

2つ目の違いは意味的記述です。RESTエンドポイントのドキュメントは、読んで判断する開発者のために書かれます。MCPツールの記述は、自分のプロンプトの一部として読み、自律的に判断するLLMのために書かれます。「POST /users/:id/orders」と書いてある説明はLLMには無価値です。LLMは、そのツールがどんな概念的操作を行うのか、いつ優先すべきか、副作用は何か、入力がドメイン的にどういう意味なのかを必要とします。APIをLLMが読める用語に翻訳する作業は、能力に最も近い人が保守できる場所 — サーバー — に一度だけ押し込まれています。

3つ目の違いは双方向性です。RESTはリクエスト・レスポンス、接続は閉じます。MCPは設計上双方向です。サーバーはいつでも通知を送れ、ClientへSampling要求を起こせ、フローの途中でユーザーに問い返せます。どれもRESTで技術的に不可能ではありません。どれもRESTでは不格好です。MCPでは標準の一部です。

2.4 能力交渉とセッションのライフサイクル

セッションは、Clientがトランスポートを開いて、自分のプロトコルバージョンと能力を載せた initialize リクエストを送るところから始まります。Serverは自分の能力で応えます — ツールを公開するか、リソースを公開するか、サブスクリプションを提供するか、高度な機能を持つか。Clientは initialized 通知で確定します。セッションは運用状態に入り、使えるメッセージ型はちょうど両者が合意した部分集合になります。

この交渉のおかげで、機能セットが違うClientとServerが生産的に共存できます。バージョンもここで扱われます — Serverは両者がサポートする最も高いバージョンを選びます。運用上の含意もあります。初期化はタダではありません — ラウンドトリップ・コストがあり、リモートサーバーなら接続セットアップも乗ります。長命なセッションが推奨パターン。能力の変化は再接続ではなく通知で流れます。これを尊重するホスト — セッションを温かく保ち、ネットワークの瞬断のあとバックグラウンドで再接続するホスト — はレイテンシが目に見えて良くなります。リクエストごとに分解して初期化し直すホストは、正しく動きますが効率は悪い。

押さえておきたい非対称性: リクエストには返信があり、通知にはありません。list-changedイベントは通知なので、見逃したClientは list_tools を再呼びして自分の見え方を更新できる用意が必要です。通知は最適化であって保証ではありません。堅牢なMCPコードは通知をヒントとして扱い、記録としては扱いません。

第2章を踏まえて

これでメンタルモデルが揃いました。MCPは、3つの役割を持つJSON-RPCプロトコルで、Serverを自分の能力について権威ある存在にする動的ディスカバリ、LLM聴衆向けに書かれた記述、通知とServer発のリクエストを含む双方向メッセージモデル、そして明示的な能力交渉で開き、両者が合意した部分集合の中で運用するライフサイクルを持つ。これだけ足場があれば、ServerとClientがそれぞれ何を公開するかを具体的に話せます — 次の2章がそれをやります。

次回 — 第3章: サーバープリミティブ — Resources・Prompts・Tools。 サーバーが提供できる3つの名詞、それぞれの意味、そして適切なプリミティブを選ぶ規律 — 隣の領分に押し込まないこと。