AIエージェントやチャットアプリが、外部のデータベースや社内ツール、ファイル操作、検索機能とつながる場面が増えている。その接続を共通化しようとしているのが Model Context Protocol、略して MCP だ。元記事は、そのMCPが実際にどんな順番でメッセージをやり取りしているのかを、プロトコルの中身に踏み込んで説明している。表面的な「MCP対応」ではなく、どこでアプリが動き、どこでモデルが判断し、どこでサーバーが応答するのかを追えるのが面白い。
元記事はまず、MCPを「AIアプリを、そのアプリが使う tools や data とつなぐための open standard」と定義している。重要なのは、モデルがサーバーと直接しゃべるわけではない、という点だ。Claude、Cursor、ChatGPT、あるいは agent のようなホスト側のAIアプリが前面に立ち、サーバーは「自分に何ができるか」をアプリに提示する。アプリはその内容をモデルに見せる。モデルは、その中から使いたいものを選ぶ。実際にサーバーへ問い合わせて結果を受け取るのはアプリで、モデル自身がネットワーク先へ直結するわけではない。
元記事はこの構造を、まず「Not REST」「Not just JSON-RPC」という対比で整理している。MCPは、単なるHTTP API群でも、ただJSON-RPCを包んだだけのものでもない。JSON-RPCはあくまでメッセージの封筒で、MCPが決めているのはその中身だ。たとえば methods、capability negotiation、transports、auth といった要素が含まれる。つまり、何をどう名乗り、どう接続し、どう権限を扱うかまでを含めた仕様になっている、という主張だ。
さらに元記事は、「Network Sequence」「Message flow」という画面で、wire 上を流れるメッセージを段階的に見せる。ここでは、各ステップで From と To がどう移るのか、どの method が呼ばれるのかを確認できる。加えて、画面には「Not in the MCP spec」という注記もあり、ハーネス実装の都合で入っている処理は、MCPそのものではないと切り分けている。たとえば「Nothing new on the wire: the client and servers still speak plain tools/list and tools/call.」とあり、見た目の複雑さに反して、実際には標準の tools/list と tools/call をそのまま使っていることを示している。
元記事の下部には、MCP spec の日付として 2025-11-25 が記され、トークン数は illustrative、つまり説明用の例だと断っている。ここで強調されているのは、MCPの理解には「機能の一覧」よりも「通信の順番」を見るほうが近道だ、という姿勢だと思う。Runlayer が作ったこのサイト自体が、そのための学習用の層として設計されている。
MCPの説明でいちばん効いているのは、モデルを通信の主体にしない点だと思う。これは一見地味だが、実装と安全性の両方に効く。モデルが直接サーバーへ行く設計にすると、認証、監査、レート制御、エラー処理をモデル側に寄せることになる。だが現実には、そういう制御はアプリケーション層に置いたほうが扱いやすい。元記事の図式は、その責任分界をかなりはっきり描いている。
この分け方は、AIを「賢い実行主体」ではなく「判断エンジン」として扱う考え方に近い。モデルは何を使うかを選ぶが、実際の接続や結果の回収はホストアプリが担う。そうすると、同じモデルでも Cursor のような開発環境と、ChatGPT のような対話UIとで、同じMCPサーバーを違う形で扱える。プロトコルが欲しかったのは、まさにそこだろう。ベンダーごとの独自実装が増えると、ツール連携の説明が毎回やり直しになる。MCPはその反復を減らす方向にある。
元記事は、MCPをJSON-RPCの単なるラッパーとして扱う見方をはっきり退けている。ここは地味に大きい。プロトコルはメッセージ形式だけでは決まらないからだ。実際の連携で厄介なのは、「相手が何を話せるか」「どの transport を使うか」「認証はどうするか」といった接続条件のほうで、MCPはそこを仕様の中心に置いている。
特に capability negotiation を含めているのが重要だと思う。ツール一覧を返すだけなら、古いクライアントと新しいサーバーが衝突しやすい。けれど、互いに対応範囲を先に確認できれば、どこまで使えるかが明確になる。これは API の世界では当たり前に見えて、AIツール連携では意外と軽視されがちだった部分だ。生成モデルの話題ばかり注目される一方で、実際の事故は「相手の機能を勘違いした」ことから起きる。MCPがそこを正面から扱っているのは、かなり実務的だと感じる。
元記事がわざわざ「Nothing new on the wire」と書いているのは、MCPに対する誤解をほどくためだろう。見た目の演出が増えると、つい新しい概念がたくさん入っているように見える。だが、実際の通信は plain な tools/list と tools/call が中心で、そこに余計な魔法はない。これは逆に好印象だ。プロトコルが複雑に見えるときほど、どこが本当に新しいのかを明示したほうがよい。
この点は、MCPを導入したい開発者にとっても大事だと思う。新しいAI機能を入れるたびに、特別なランタイムや独自メッセージ体系を覚えなくていいなら、導入コストはかなり下がる。既存の tools/list と tools/call で表現できる範囲が広いなら、学習コストも抑えやすい。逆に言えば、MCPの価値は「奇抜な新API」ではなく、「既存の形で統一された意味を持たせること」にある。派手さはないが、長く使われる規格はたいていこのタイプだ。
元記事自体は仕様書そのものではなく、仕様を読む前の道案内に近い。Network Sequence や Message flow を前面に出し、ステップごとに From / To / Method を追えるようにしているのは、そのためだと思う。プロトコルは文章で読むと硬いが、流れが見えると急に理解しやすくなる。特にMCPのように、モデル、ホストアプリ、サーバーの役割が分かれている仕組みでは、図や順序の把握がそのまま理解になる。
このやり方は、AI連携の議論が「何ができるか」だけに寄りすぎている現状への小さな反論にも見える。できることの列挙は目立つが、実装で本当に大事なのは、どのタイミングで何が動き、誰が責任を持つかだ。MCP Explained が通信の順番を丁寧に見せているのは、そこを飛ばすと誤解が残るからだろう。私は、この種の説明資料がもっと増えたほうがいいと思う。AIの周辺技術は、機能紹介だけではすぐに空中戦になる。実際の wire の話まで降りてくると、ようやく議論が地面に着く。
