MCP、次版で
ステートレス接続が正式に
これまではセッション状態の同期・復旧がスケール時の悩みどころでした。2026年7月28日公開のMCP仕様改訂で、この前提そのものが変わります。
「動かせる」から
「支えられる」へ
MCP（Model Context Protocol）は登場以来、クライアントとサーバーの間で状態を持つ接続を前提に設計されてきました。接続のたびに initialize ハンドシェイクを交わし、サーバーが発行した Mcp-Session-Id ヘッダーを以降すべてのリクエストに付け続ける——単一サーバーで動かす分には問題になりませんが、複数インスタンスへスケールしようとした瞬間に重くのしかかります。どのリクエストをどのインスタンスへ戻すか覚え続けるスティッキーLB、インスタンス間で状態を同期する共有ストア、ロードバランサー側での深いパケット検査。本番運用のコストは、接続の「賢さ」に比例して膨らんでいました。
MCP公式ブログが公開した「The 2026-07-28 MCP Specification Release Candidate」は、作者自身がローンチ以来最大の改訂と位置づける内容で、この initialize セッションステップと Mcp-Session-Id ヘッダーそのものを仕様から取り除きます。海外メディアも「Model Context Protocol prepares to break with its stateful past」と評しました。これはHTTP/RESTがCookieセッションから素朴なステートレスAPIへ成熟していった道筋と同じで、MCPが個人の実験用プロトコルから本番インフラへ足を踏み入れるための通過儀礼と言えます。
仕様レベルで
何が消え、何が増えるか
ステートレス化だけでなく、UI・長時間タスク・認可まわりも同時に刷新されます。
撤廃されるのはセッション管理だけではありません。同リリース候補は同時に、MCPクライアント内でサーバー側UIを描画するMCP Apps拡張、長時間実行タスクを扱うTasksエクステンション、そしてOAuth / OpenID Connectに準拠した認可フローも導入します。一方でRoots・Sampling・Loggingの3機能は非推奨となり、それぞれツール引数・リソースURIや各プロバイダーAPIの直接呼び出し・標準エラー出力やOpenTelemetryストリームへの置き換えが案内されています。
エンジニアとPM、
効き方はまったく違う
自前でMCPサーバーを運用しているかどうかで、恩恵の大きさが変わります。
| 自前でMCPサーバーを運用する人 | 既製サーバーを使うだけの人 |
|---|---|
| スティッキーLB設定・共有セッションストアが不要に | インフラ構成の理解自体が不要 |
| Mcp-Session-Id / initialize 依存の棚卸しが必要 | クライアントSDKの追随を待つだけでよい |
| 運用がやや楽になる（本人談通りの実利） | 体感の変化はほぼ無い |
この「静かな恩恵」を先取りしているのがGitHub公式MCPサーバーの発表です。正式仕様の公開に先立つ2026年7月23日、GitHubは自社のMCPサーバーが次期仕様に対応することを明らかにしました。GitHub製サーバーを叩くだけのPM・非エンジニアユーザーの操作感はほぼ変わりませんが、裏側の可用性・レイテンシが底上げされる形で間接的に恩恵が及びます。一方で、自分でMCPサーバーを自作・自己運用しているエンジニアにとっては、セッションストアもスティッキー設定もいらなくなる、直接効くインフラ簡素化です。
07-28の切り替えに向けてやること
自前運用サーバーの棚卸し
自作・自己運用しているMCPサーバーが initialize や Mcp-Session-Id に依存していないか洗い出す。07-28のカットオーバー前に確認しておきたい。
クライアントSDKの追随を確認
利用しているMCPクライアントSDKが新仕様互換のベータ・リリースを出しているかチェックする。
Roots / Sampling / Logging の利用箇所を点検
非推奨対象3機能に依存するツールがあれば、ツール引数化・リソースURI化・標準出力/OpenTelemetry化への移行計画を立てる。
「ローンチ以来最大の改訂」は、
無料でもらえるアップグレードではない。
楽観だけでは語れない
「ローンチ以来最大の改訂」という位置づけは、そのまま互換性リスクの大きさでもあります。旧仕様のステートフルな前提でサーバー・クライアントを組んでいる開発者にとって、これは無料で降ってくるアップグレードではなく、明確な移行作業を要する破壊的変更です。Mcp-Session-Idを自前でパースしているコードや、セッション単位で状態を持たせた実装は、07-28以降そのままでは動かなくなる可能性があります。
加えて、改訂の規模が大きいということは、それだけエコシステム側の追随に時間がかかり、初期にはクライアント・サーバー双方でバグに当たりやすいということでもあります。既製サーバーを使うだけの人には関係が薄い一方、自前運用者は「便利になった」で終わらせず、移行期のバグ報告・SDKのアップデートを一定期間ウォッチしておくのが無難です。