AI 標準與代理基礎設施
MCP 2026-07-28、接続フェーズのsessionを撤廃し、ツールサーバーをステートレスHTTPへ移行
MCPの新改訂では、初期化ハンドシェイクと`Mcp-Session-Id`を廃止し、単一のリクエストを任意のサーバーインスタンスで処理できるようにする。これは破壊的なプロトコル変更であり、最終版の確定と主要SDKの対応完了までは、デプロイ担当者は引き続きバージョンネゴシエーションと旧バージョンへのフォールバックを維持する必要がある。
Model Context Protocol（MCP）で7月28日に確定予定の新版は、エージェントとツールサーバー間の接続ライフサイクルを刷新する。旧版のStreamable HTTPでは通常、最初に`initialize`を実行し、その後の呼び出しを`Mcp-Session-Id`で維持していた。新版では両方を廃止し、各リクエストにプロトコルバージョン、クライアント機能、ID情報を含めるよう求めるほか、クライアントがサーバーの対応バージョンと機能を照会するための`server/discover`を追加する。実運用では、リクエストを特定のインスタンスに固定する必要がなくなり、リモートMCPサービスを一般的なround-robinロードバランサーの背後に直接配置できるため、共有session storeやsticky routingの必要性が低下する。
状態が完全になくなるわけではなく、アプリケーション層へ移される。呼び出しをまたいでショッピングカート、ブラウザー、または作業セッションを保持する必要があるツールは、明示的なhandleを返し、モデルが次回の呼び出しでそれを渡さなければならない。サーバーがクライアントに確認や追加情報を求める仕組みもMulti Round-Trip Requestsへ変更される。サーバーはまず`input_required`を返し、クライアントはユーザー入力を取得した後、元のリクエストを再送信する。長時間実行される処理は独立したTasks extensionへ移され、`tasks/get`、`tasks/update`、`tasks/cancel`で管理される。
新版ではさらに、HTTP POSTに`Mcp-Method`と`Mcp-Name`を付与することを求め、ゲートウェイがJSON bodyを解析せずにルーティングやレート制限を行えるようにする。ツールとリソースの一覧には`ttlMs`と`cacheScope`が追加され、OpenTelemetry trace contextも統一される。OAuthについては、issuerの検証や、認可サーバーごとのクレデンシャル分離などの要件が追加される。
移行リスクを過小評価してはならない。`ping`、旧式のlogging操作、複数の通知が削除され、Roots、Sampling、Loggingは非推奨期間に入る。また、切断後にSSE event IDを使ってリクエストを再開する仕組みも廃止される。今回の情報取得時点では、公式changelogはまだdraftパスに置かれている。そのため、エンジニアリングチームは最終schema、利用中のSDKにおける対応状況、ダウングレード時の動作を確認すべきであり、バージョン文字列だけを置き換えてそのまま本番環境へ展開するべきではない。