ステートフルという「負債」からの脱却
深夜2時、分散システムでセッションの不整合に頭を抱えた経験があるエンジニアなら、今回のModel Context Protocol(MCP)の仕様変更がどれほど「福音」であるか、直感的に理解できるはずだ。これまでMCPは、initializeとinitializedのハンドシェイクを伴うセッションベースの通信を前提としていた。これは、クライアントとサーバー間で『Mcp-Session-Id』を維持し続けることを意味し、インフラ担当者にとっては悪夢のような制約だった。オートスケーリングのたびにセッションのマイグレーションやドレイン(接続の排出)に追われ、ロードバランサーは特定のインスタンスにクライアントをピン留めせざるを得ない。これは、現代のクラウドネイティブなアーキテクチャが最も避けるべき「ステートの局所化」そのものだ。
2026年7月28日に公開された最新のMCP仕様は、このセッション管理を完全に切り捨てた。もはやハンドシェイクは不要であり、すべてのリクエストは独立して処理される。これにより、リクエストはどのインスタンスに到達しても等しく処理可能となり、スケーラビリティのボトルネックが解消された。しかし、ここで我々が直面するのは「では、これは単なるREST APIと何が違うのか?」という根源的な問いだ。ステートフルなプロトコルを設計し、運用で苦労した末に、結局はステートレスなHTTPリクエストに回帰する。この歴史の繰り返しは、まるでスパゲッティコードをリファクタリングした結果、結局はシンプルな関数呼び出しに戻った時の徒労感に似ている。しかし、この「回帰」こそが、AIエージェントを実用的なインフラへと昇華させるための唯一の現実解だったのではないだろうか。
ゲートウェイが支配するエージェントの未来
今回のアップデートの真の核心は、単なるステートレス化ではない。必須となった2つのHTTPヘッダー『Mcp-Method』と『Mcp-Name』の導入にある。これまでのMCPは、JSON-RPCのボディをパースしなければ、それがツール呼び出しなのか、リソースの読み込みなのかを判断できなかった。つまり、WAFやAPIゲートウェイは、リクエストの中身を覗き見ない限り、トラフィックの制御が不可能だったのだ。しかし、ヘッダーにメタデータが露出したことで、インフラ層はリクエストを解読することなく、ツール単位でのレート制限やルーティング、さらにはセキュリティポリシーの適用が可能になった。
これは、AIエージェントのガバナンスが「アプリケーション層」から「インフラ層」へと移管されたことを意味する。CloudflareやAzure API Managementが提供するAIゲートウェイ機能が、プロトコルの外側から制御するのではなく、プロトコルそのものに組み込まれた形だ。以下に、この変更がもたらすインフラ制御の構造変化を整理する。
| 項目 | 旧仕様(ステートフル) | 新仕様(ステートレス) |
|---|---|---|
| ルーティング | セッションIDによる固定 | ヘッダーベースの動的ルーティング |
| トラフィック制御 | ボディ解析が必要(高負荷) | ヘッダーによる軽量なフィルタリング |
| スケーリング | セッション維持が必須 | 水平スケールが容易 |
| 認証 | 動的クライアント登録 | RFC 9207/8707準拠の標準化 |
この変更により、開発者は「エージェントがどのツールを叩いているか」をゲートウェイ側で可視化・制御できるようになった。これは、企業がAIエージェントを本番環境にデプロイする際、最も懸念する「制御不能なツール実行」に対する強力な防波堤となる。一方で、エージェントの利便性を追求するあまり、プロトコルが既存のAPIインフラのコピーへと収束していく過程は、標準化の皮肉な側面を浮き彫りにしている。我々は「AIのための新しいプロトコル」を求めていたはずが、結局は「既存のAPIエコシステムにAIを適合させるための規約」を再発明していたに過ぎないのかもしれない。
「プロトコル」は本当に必要なのかという問い
Anthropicの報告によれば、MCPのSDKダウンロード数は月間4億回を超え、爆発的な普及を見せている。しかし、その実態は「使われている」というより「実装されている」という段階に近い。あるコンサルタントの報告では、MCPサーバーを監査したところ、3ヶ月間で61回のツール呼び出ししか発生しておらず、その大半が開発者自身によるテストだったという。これは、多くの企業が「エージェント対応」という看板を掲げながら、実際には実用的なユースケースを欠いているという、現在のAI業界の歪みを象徴している。
ここで我々エンジニアが自問すべきは、「エージェントに専用のプロトコルは本当に必要なのか?」という点だ。CLIツールをそのまま叩くシェルアクセスで十分ではないかという議論は根強い。しかし、モバイルアプリやWebチャット、埋め込みウィジェットといった多様なクライアント環境を考慮すれば、標準化されたインターフェースは不可欠だ。問題は、その標準化が「AIのため」という名目のもと、既存のAPIの車輪の再発明に終始していないかという点にある。今回のステートレス化は、MCPを「AI専用の特殊な通信手段」から「AIも利用可能な汎用API」へと引き戻した。これは退化ではなく、成熟であると私は考える。
明日から我々が取るべき対策は明確だ。既存のステートフルなMCP実装を抱えているチームは、即座にステートレスなルートへの移行計画を立てるべきだ。そして、APIゲートウェイの選定において、MCPの新しいヘッダーをネイティブに解釈できる製品を優先的に評価すること。AIエージェントの時代において、真の価値は「エージェントが何ができるか」ではなく、「エージェントの行動を既存のインフラでどれだけ安全かつ効率的に制御できるか」にシフトしている。あなたは、自社のAIエージェントを、単なる「実験的なおもちゃ」から「堅牢なビジネスインフラ」へと昇華させる準備ができているだろうか?プロトコルの進化に追従するだけでなく、その裏側にある「制御の論理」を設計できるかどうかが、これからのシニアエンジニアの分水嶺となるはずだ。


コメント