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を参照していただきたい。
