本文
結論から言うと、新規のremote MCPサーバーは、protocol-level sessionを前提にせず、HTTPの通常の運用単位として設計するのが基本です。2026-07-28版のMCPは、従来のinitialize/initialized handshakeとMcp-Session-Idをprotocol coreから外し、各requestにversion・client information・capabilityを持たせる設計へ移りました。[1] これにより、requestはsticky sessionなしで任意のserver instanceへ届き、通常のload balancer、gateway、autoscalingの下で扱いやすくなります。
ただし「MCPが無状態になった」ことと、「業務が無状態になった」ことは別です。顧客の申請途中データ、非同期jobの進捗、承認待ち、冪等性キー、監査記録をMCP transportのmemoryに閉じ込めていた場合、そのままsessionを消すと再試行や引き継ぎで破綻します。まず、状態を三つに分けます。第一に、tool呼び出しごとに完結する入力・認可情報はrequestから検証します。第二に、長く残す業務状態はdatabaseやqueueなど、MCP instanceの外に明示的に保存します。第三に、接続の再送や進捗通知にだけ必要な一時状態は、必要性を確認してから専用storeに置きます。protocolの都合で業務データをsessionへ置かないことが、scale-outと障害復旧の前提です。
2026-07-28版ではMcp-MethodとMcp-NameがHTTP headerで運ばれ、gatewayやrate limiterがbodyを解釈せずにoperation単位のルールを置けます。また、tool listやresource readにはcache hintが用意され、tool catalogを無条件に毎回再取得する構成を避けられます。[1] ただし、cache可能なのは「誰に見せても同じか」「いつまで正しいか」をserverが説明できる結果だけです。利用者の権限で内容が変わるtool listを共有cacheへ載せる設計は採りません。
2025-11-25以前のclientが残り、既存serverがsession・server-to-client request・replayへ依存している場合は、旧session routeを直ちに消せません。Cloudflareも、新規はstateless handlerを使い、stateful機能を使う既存serverはstateless routeとlegacy routeを並行提供し、既存sessionがdrainするまで残すよう案内しています。[2] 一方、旧clientがあってもstateful機能へ依存しない構成まで、専用の旧routeが常に必要とは限りません。二系統を設ける場合も恒久的な互換層にはせず、廃止条件を先に決めます。
廃止する条件は、少なくとも四つです。全接続元で対応protocol versionを観測できること、legacy routeの利用が連続した観測期間ゼロであること、stateful-only機能を使う業務フローが代替済みであること、rollback時に戻せるreleaseと監視項目が確認済みであることです。最後の旧sessionを待つだけでは足りません。利用client、SDK、proxy、認証gatewayの組み合わせで、server/discover、tool call、認可失敗、timeout、retryを実際に通します。MCPのroadmapも、HTTP-native化が進んだ一方でagent identityとenterprise securityを継続課題として挙げています。[3]
海外の実装を見ると、Cloudflareは自社管理MCPを2026-07-28仕様に対応させ、/mcpでfresh stateless serverとして処理しています。[4] AWS AgentCore Gatewayも2026-07-28を含む複数versionを扱い、MCP targetにOAuth、IAM SigV4、API keyを設定できます。[5] これは「どの基盤でも同じ性能になる」という証拠ではありません。むしろ、protocol version、認証、tool schema、業務状態の所有者をdeployment前に固定すべきという実装例です。
本番確認では、request数だけでなく、protocol version別の成功率、Mcp-Method別のp95 latency、tool schema validation failure、認可拒否、retry回数、外部stateの整合性、legacy routeの接続数を同じdashboardで確認します。trace contextはhost、gateway、MCP server、下流APIをまたいで渡し、障害時に「どのtoolがどの業務状態を変えたか」を追えるようにします。[1] tokenや個人情報をtrace attributeへ無造作に残さないことも前提です。
MCPサーバーの本番運用・移行設計を相談する。
一次情報と確認範囲
確認日：2026年9月17日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。
- 2026-07-28版はhandshakeとprotocol-level sessionを廃した
- stateful legacy serverはstateless routeと段階共存させる
- MCPのroadmapはagent identityとenterprise securityを継続課題に挙げる
- Cloudflare管理MCPはfresh stateless serverでrequestを処理する
- AWS AgentCoreは複数MCP versionとOAuth/IAM/API keyを扱う
- 2025-11-25版のStreamable HTTPではsession ID、resumption、SSE streamが定義されていた