ハンドシェイク廃止とステートレスの真意
エンジニアとして日々、分散システムの設計に頭を悩ませていると、『セッション管理』という言葉がいかに我々を呪縛してきたかを痛感させられる。ロードバランサーのスティッキーセッション設定、共有メモリの同期、あるいはサーバーレス環境での状態保持の困難さ。これらは単なる実装上の苦労ではなく、システム全体の拡張性を阻害する『技術的負債の温床』であった。2026年7月28日に公開されたMCP（Model Context Protocol）の大型アップデートは、まさにこの呪縛を断ち切るための大胆な決断を下したと言える。
今回の仕様変更で最も衝撃的だったのは、initializeハンドシェイクとMcp-Session-Idの完全廃止だ。これまでのMCPは、通信開始時にクライアントとサーバーが互いの機能をすり合わせるという、いわば『握手』を前提としていた。しかし、この設計はサーバー側に状態を保持させることを強いる。結果として、水平分散構成を組む際には、どのリクエストがどのインスタンスに飛んでも同じ結果を返せるよう、複雑なセッションストアを構築せざるを得なかった。今回のアップデートでは、プロトコルバージョンやクライアント機能を毎回のリクエストに_metaフィールドとして含めることで、各リクエストを完全に独立した『1発リクエスト・レスポンス』モデルへと昇華させた。これは、MCPサーバーを単なるステートレスな関数として扱えることを意味し、サーバーレスやエッジコンピューティングとの親和性を劇的に向上させる。
また、ハンドシェイクの廃止に伴い、サーバーが提供するツールやリソースを事前に把握するためのserver/discoverメソッドが新設された。これにより、クライアントは接続のたびに重厚な初期化プロセスを経ることなく、必要な機能だけを動的に探索できる。この設計思想は、マイクロサービスアーキテクチャにおけるサービスディスカバリの考え方に近く、非常にモダンで合理的だ。我々エンジニアが明日から取り組むべきは、この『ステートレスな世界』への適応である。セッションIDに頼った設計は過去のものとなり、今後はリクエストのコンテキストをいかに効率的にペイロードに詰め込み、かつセキュリティを担保するかという、より本質的な設計能力が問われることになるだろう。
MRTRによる状態管理の再定義
ステートレス化の最大の懸念は、『ユーザーの入力待ち』のようなステートフルな処理をどう扱うかという点にある。例えば、送金処理の途中でユーザーの確認ダイアログを挟むようなケースだ。これまではSSE（Server-Sent Events）ストリームを張りっぱなしにして、サーバー側で状態を維持するのが定石だった。しかし、今回のアップデートで導入されたMulti Round-Trip Requests（MRTR）は、この課題に対して極めてエレガントな解を提示している。サーバーは処理の途中でresultType: “input_required”を返し、同時にrequestStateという文字列をクライアントに預ける。クライアントはユーザーの入力を得た後、そのrequestStateを添えてリクエストをリトライする。この仕組みにより、サーバーはメモリ上に状態を保持する必要が一切なくなる。
実際にTypeScript SDK v2を用いて、プロセスを強制終了させるという過激な実験を行ったが、結果は驚くべきものだった。最初にリクエストを受けたプロセスが消滅しても、別のプロセスがrequestStateからコンテキストを復元し、処理を完遂できる。これは、サーバーが『リクエストの外側に何も覚えていない』という究極のステートレスを実現している証左だ。ただし、ここで注意すべきはセキュリティだ。requestStateはクライアントを経由するため、悪意ある改ざんのリスクが常に付きまとう。SDKにはHMAC-SHA256等を用いた署名検証の仕組みが用意されているが、これを適切に実装し、有効期限や対象ユーザーを厳密に管理するのは開発者の責任である。この『状態の外部化』は、分散システムにおけるデッドロックやメモリリークの可能性を大幅に減らす一方で、データ整合性の担保という新たな責務を我々に課している。
さらに、今回のアップデートでは認可まわりの締め付けも強化された。RFC 9207準拠のissuer検証や、CIMD（Client ID Metadata Documents）への移行など、地味ながらも堅牢なセキュリティ要件が盛り込まれている。これらは、MCPが単なる実験的なプロトコルから、エンタープライズレベルの自律エージェント基盤へと進化しようとしていることの現れだ。我々エンジニアは、単に新しいSDKの使い方を覚えるだけでなく、このプロトコルが前提とする『信頼できないクライアントからの入力をどう安全に処理するか』というセキュリティモデルを深く理解する必要がある。この転換期において、既存のステートフルな実装を漫然と使い続けることは、将来的な技術的負債を積み上げることに他ならない。
エンジニアが直面する次なる問い
MCPの2026-07-28仕様は、単なる機能追加ではない。それは、AIエージェントがインターネット上で自律的に振る舞うための『通信の標準化』に向けた、極めて重要なマイルストーンである。Roots、Sampling、Loggingといった機能がコアから非推奨となり、拡張機能フレームワークへと移行したことは、コアプロトコルを極限まで軽量化し、エコシステムの柔軟性を最大化しようとする強い意志を感じさせる。12ヶ月の移行期間が設けられているとはいえ、我々は今すぐこの新しいパラダイムへの移行計画を立てるべきだ。
しかし、ここで我々が自問すべきは『この抽象化の先にあるものは何か』という問いである。プロトコルがステートレスになり、サーバーがリクエストごとに独立して動作するようになれば、エージェントの実行環境はより分散化し、複雑性は増す。ツール呼び出しの順序性や、複数のエージェントが関与するトランザクションの整合性を、プロトコルレベルではなくアプリケーション層でどう担保するのか。あるいは、今回導入されたヘッダーベースルーティングのように、インフラ側での制御が容易になる一方で、ビジネスロジックがインフラの制約に引きずられるリスクはないか。技術が進化すればするほど、我々エンジニアは『何がプロトコルの責務で、何がアプリケーションの責務か』という境界線を、より鋭敏に定義し続けなければならない。
明日からあなたが取るべきアクションは明確だ。まずはTypeScript SDK v2を触り、MRTRの挙動をローカルで再現すること。そして、現在運用しているMCPサーバーが、もし明日突然プロセスが再起動しても問題なく動作するかを検証することだ。ステートレスな設計は、最初は不便に感じるかもしれない。しかし、それはシステムを『壊れにくいもの』へと変えるための唯一の道である。このプロトコルの進化を、単なるニュースとして消費するのか、それとも自らのアーキテクチャ設計の指針として取り入れるのか。その選択が、数年後のあなたのエンジニアリングの質を決定づけることになるだろう。我々は、この新しいプロトコルを使いこなし、より堅牢な自律経済圏を構築する準備ができているだろうか？
コメント