MCP（Model Context Protocol）は、AIアプリやツール同士をつなぐための共通ルールです。ざっくり言うと、「このAIはどんな道具を使えるのか」「どんなデータを読めるのか」をやり取りするための標準規格に近い存在です。
The New Stackの記事が面白いのは、そのMCPに入る“かなり大きめの変更”を、単なる仕様アップデートではなく、これまで多くのサーバーが前提にしていた仕組みを削り取る改訂として描いているところです。地味に見えて、実はかなり大きい。こういう変更は、便利さの裏にあった複雑さをそぎ落とす一方で、既存実装には「え、そこ消えるの？」という衝撃を与えます。
今回の記事の中心は、MCPの最新の大きな変更で、sessionsをなくし、初期化の握手もなくしたという点です。
ここでいう session は、簡単に言えば「このやり取りは同じ相手との1つの流れですよ」とサーバーが覚えておくための仕組みです。普通の人間の感覚だと自然ですが、分散システムやAPIの世界では、この“覚えておく”ことが意外と面倒です。誰がいつつないだのか、途中で切れたらどうするのか、複数の接続をどう区別するのか。考え出すと、途端に設計が重くなります。
そこを今回の改訂で削った、というのが肝です。初回接続時の initialization handshake も外れたので、サーバーは「まず名乗って、条件を確認して、相手の状態を覚えて……」という儀式を減らせます。これはかなりHTTP的です。HTTPは基本的に状態を持たない通信モデルなので、毎回のリクエストが独立している。MCPもそちらに寄せることで、実装を軽くしたいのだと思います。
正直、この方向転換はかなり筋がいいと感じます。AIエージェント周りのシステムは、放っておくとすぐ“便利な状態管理”が増殖します。で、最終的に誰も全体像を説明できなくなる。そういう意味で、状態を減らすのは勇気ある整理です。
では、完全に状態管理をやめたのかというと、そうではありません。状態は handles に移ると説明されています。
handle は、日本語で無理に訳すと「つかみ」や「参照」に近いものです。ファイルを開いたときのファイルハンドルを思い浮かべるとわかりやすいです。中身そのものを毎回持ち歩くのではなく、「これを指している番号」や「参照先」を持つ。そうすると通信はぐっと軽くなります。
この記事の文脈では、MCPが“セッションを丸ごと抱える”方式から、“必要な状態はhandleで参照する”方式へ寄る、という話です。これは設計の発想としてかなり大きい。サーバーにとっては、相手の文脈を覚え続けるより、「これを見ればよい」という参照を扱うほうが単純です。
ただし、単純になるのは設計図の話であって、実装まで自動的にラクになるとは限りません。むしろ、古い仕組みに乗っていたサーバーは一度組み替えが必要になるはずです。便利な抽象化が消えれば、その上に乗っていた便利さも一緒に外れる。こういう変更は、きれいな代わりに痛い。そこがリアルです。
記事の説明で印象的なのは、remote servers act more like stateless HTTP という表現です。つまり、リモートのMCPサーバーは、より「毎回独立したHTTPのやり取り」に近づくということです。
これは、クラウドやWebの世界ではかなり相性がいい考え方です。状態をサーバー側に抱え込みすぎると、スケールさせにくくなります。インスタンスを増やしたとき、どのサーバーがどの文脈を覚えているのか、同期はどうするのか、切断されたらどう復元するのか、面倒が増えるからです。
stateless に寄せると、ロードバランサーの裏に複数のサーバーが並んでいても扱いやすい。故障時の復旧もやりやすい。これはクラウド時代の基本思想そのものです。MCPがそこに合わせにいくのは自然ですし、個人的にはかなり現実的だと思います。
一方で、AIツール連携の世界はまだ新しいので、理想的なHTTP的シンプルさだけでは割り切れない場面もあるはずです。たとえば、長い対話の途中でツールの状態を保ちたいケースや、複数回の操作をひとまとまりで追跡したいケースです。そこを handles でどこまで吸収できるのかは、実運用でかなり試されるのではないかと思います。
この改訂がなぜ重要かというと、MCPが単なる「AI向けの便利な接続規格」から、より広く実装しやすい通信規格に寄っていく気配があるからです。
初期化の握手や session 管理は、ちゃんと作ろうとすると面倒です。でも、面倒だからこそ、そこを規格が肩代わりしてくれるメリットもありました。今回の変更は、その“肩代わり”を減らす方向です。つまり、規格が提供する安心感を少し削って、その代わりに実装の軽さと柔軟性を取る、という判断に見えます。
この手の変更は、愛されることもあれば文句を言われることもあります。特に、すでにMCPサーバーを作っている人にとっては、かなり面倒です。けれど、仕様が少しでも現場に寄りすぎると、今度は互換性の維持が苦しくなる。標準規格っていつもその綱渡りです。私はこういう「整理のために一度崩す」タイプの改訂、嫌いではありません。むしろ、本気で広めたい規格なら一度は通る道だと思います。
もし今、MCPサーバーを実装しているなら、この変更はかなり見逃せません。というのも、サーバーがこれまで session 前提で設計されていた場合、単にバージョンを上げれば終わり、とはいかなそうだからです。
特に影響が大きいのは、接続ごとの状態をサーバー内部で持っていた実装でしょう。そういうサーバーは、handle ベースの設計に合わせて考え直す必要が出てきます。逆に言えば、これまで「ちょっと込み入っているな」と感じていた部分を、規格が切り崩してくれたとも言えます。開発者にとっては痛みを伴うけれど、長期的にはわかりやすくなる可能性があります。
ここはちょっと皮肉なところで、仕様がシンプルになるほど、移行時の現場は一気に忙しくなります。理想はすっきり、現実はバタバタ。いつもの話です。
MCPは、AIエージェント時代の“道具箱の共通言語”になれるかどうかを試されている最中です。その中で今回の変更は、豪華な新機能というより、むしろ土台の再設計に近い。派手ではないけれど、かなり効く。私はそう受け取りました。
参考: MCP’s biggest update removes the machinery many servers were built around
