MCPがステートレスプロトコルに刷新 — セッション管理不要でどのサーバーにもルーティング可能に、AWS AgentCore Gatewayが新仕様をサポート

7月29日、AWSが「How AgentCore Gateway supports the MCP 2026-07-28 spec」と題した記事を公開した。この記事では、MCPの最新仕様（2026-07-28）においてステートレス化という大きな転換が行われ、AWS AgentCore Gatewayがどのようにこれをサポートするかについて詳しく紹介されている。

MCPがステートレスプロトコルに——何がどう変わったか

Model Context Protocol（MCP）の2026-07-28仕様は、2024年のローンチ以来最大の仕様改訂だ。最大の変更点はプロトコルのステートレス化である。

従来のMCPでは、クライアントとサーバーが通信を始めるたびに initialize/initialized ハンドシェイクが必要だった。サーバーは Mcp-Session-Id を発行し、以降のリクエストはすべてそのセッションIDを携帯する必要があった。

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
Accept: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}

このセッションはクライアントを特定のサーバーインスタンスに縛り付ける。水平スケールするには、ロードバランサーでのスティッキーセッション設定か、フリートの背後に共有セッションストアを置く必要があり、エンタープライズ規模での運用の障壁になっていた。

新仕様ではセッションが廃止され、各リクエストが _meta パラメーター内にプロトコルバージョン・クライアント情報・ケーパビリティをすべて内包する。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_basket
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"create_basket","arguments":{},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

1回のツール呼び出しが完全に自己完結し、どのサーバーインスタンスにもルーティング可能になる。ステートフルな処理が必要な場合は、ツールパラメーターとして明示的なIDを渡す既存のHTTPパターンを使えばよい。上記の create_basket の応答で返ってきた basket_id: bsk_a1b2c3 を次のリクエストの引数に渡す、という形だ。

AgentCore Gatewayへの影響——既存クライアントは何も変わらない

Amazon Bedrock AgentCoreのGateway機能は、AWS Lambda関数・API・MCPサーバーを単一のMCPエンドポイントに集約し、各ターゲットとのプロトコル会話をエージェントの代わりに管理する。

新仕様の採用は完全にオプトインだ。UpdateGateway APIの supportedVersions フィールドに 2026-07-28 を追加するだけで有効になる。リクエストごとに MCP-Protocol-Version ヘッダーで使用バージョンを指定し、ヘッダーがない場合は 2025-03-26 にフォールバックする。既存クライアントはそのまま動作し続ける。

HTTPインフラとの親和性向上——ボディを解析せずにルーティング

2026-07-28のもう一つの大きな変更が、標準HTTPインフラとの統合強化だ。

従来は、ロードバランサーやAPIゲートウェイがリクエストの操作内容を知るためにJSON-RPCのボディをパースする必要があった。新仕様では：

Mcp-Method と Mcp-Name ヘッダー（SEP-2243）により、ボディを読まずにルーティング・スロットリング・メータリングが可能になる。SEP（Specification Enhancement Proposal）はMCPの仕様変更を議論・追跡するための提案プロセスで、番号は個々の提案を識別するIDに相当する
tools/list 等のレスポンスに ttlMs と cacheScope （SEP-2549）が付与され、持続的接続なしにキャッシュできる
W3C Trace Context（traceparent、tracestate、baggage）が _meta 内に予約され（SEP-414）、エージェントからゲートウェイ・下流サービスまでの分散トレースがOpenTelemetry互換のコレクターで一つのスパンツリーとして可視化できる

エラーハンドリングの整理

旧仕様ではトランスポート層の障害も含め、ほぼすべてがHTTP 200でJSON-RPCボディにエラーを内包して返ってきた。新仕様ではトランスポート層とアプリケーション層が明確に分離される。

状況	2025-*系	2026-07-28
不明なメソッド	JSON-RPCエラー（HTTP 200）	HTTP 404
未サポートのプロトコルバージョン	不定	HTTP 400、コード -32022
ヘッダーバインドフィールドの欠如・不一致	不定	HTTP 400、コード -32020

また -32002（リソース未発見）がJSON-RPCの標準コード -32602（Invalid Params）に変更された（SEP-2164）。-32002 でマッチングしているクライアントコードは事前の監査が必要だ。

アップグレード前に確認すべき3点

記事では有効化前に以下の確認を推奨している。

クライアントSDKが対応済みか — Tier 1 SDKsは10週間のRC期間中にサポートを出荷予定で、主要スタックは現時点で対応済みとされている。SDKの対応状況はMCP公式サイトのSDKページ等から確認できるが、各SDKのリリースノートも併せて参照することを推奨する
削除・変更された挙動への依存がないか — セッションID、initialize ハンドシェイク、logging/setLevel（廃止）、エラーコード -32002 への依存を確認する
互換性テストを実施したか — 本番ゲートウェイに追加する前に、2026-07-28対応クライアントでテストする

なお、Roots・Sampling・Logging の3機能が新しいフィーチャーライフサイクルポリシー（SEP-2577）の下で非推奨に指定された。SEP-2577はMCPにおける機能の非推奨・削除プロセスを標準化した提案で、この指定により仕様公開から12カ月以内は機能し続けるが、新規実装での利用は推奨されない。

詳細はHow AgentCore Gateway supports the MCP 2026-07-28 specを参照していただきたい。