MCPがセッションを廃止しステートレス化。旧HTTP+SSEは1年で移行へ

MCP 2026-07-28 は、Model Context Protocol が2026年7月28日に公開した5回目の仕様で、プロトコルの基礎をステートレスな request/response 構成へ移行させる内容です。

📖 この記事で分かること

• MCP 2026-07-28 仕様の主要変更点
• ステートレス化で配置がどう変わるか
• 認可強化と拡張フレームワークの中身
• 既存サーバーに必要な移行対応

💡 知っておきたい用語

• MCP: AI が外部ツールやデータに繋がるための共通規格。USB の端子形状を統一したようなもの
• ステートレス: サーバー側が会話の途中経過を覚えない方式。どの窓口に並んでも同じ手続きが完結する状態に近い

最終更新日: 2026年7月29日

▶ 公式ページ

• MCP 2026-07-28 仕様(Model Context Protocol)
• リリース告知ブログ(Model Context Protocol Blog)
• Claude の対応方針(Claude by Anthropic)

MCP 2026-07-28 仕様が正式リリース

この記事のポイント

• Model Context Protocol は 2026年7月28日、5回目の仕様「2026-07-28」を公開しました。
• 双方向ステートフルから request/response のステートレス構成へ移行し、Mcp-Session-Id ヘッダ要件を撤廃。
• 破壊的変更を含み、旧 HTTP+SSE トランスポートは1年の移行期間つきで非推奨になります。

Model Context Protocol(MCP【エムシーピー】)は 2026年7月28日、バージョン名「2026-07-28」の仕様を正式公開しました。MCP としては5回目の仕様リリースにあたります。

規模の面では、Tier 1 SDK 合計で月間ほぼ5億ダウンロード(2026年7月時点)に達しており、TypeScript SDK と Python SDK はそれぞれ累計10億を超えています。なお Claude 側の告知では月間4億超(前年比4倍)と表記されており、集計時点の違いで数字に幅があります。

MCP 共同発明者の David Soria Parra 氏は、リモート MCP の登場から1年余りを経た今回が MCP にとって最も重要なリリースだ、という趣旨のコメントを寄せています。

ステートレス化で何が変わるか

最大の変更は、プロトコルの基礎をステートレスにしたことです。接続を張り続ける前提がなくなり、サーバーの置き場所の制約が外れます。

従来必要だった initialize / initialized のハンドシェイク交換は廃止され、Mcp-Session-Id ヘッダの要件も撤廃されました。代わりに各リクエストが自己記述的になり、プロトコルバージョン・クライアント識別・ケイパビリティを _meta に載せて送ります。ケイパビリティの探索用には任意の server/discover RPC が用意されました。

この結果、共有ストレージを持たない単純なラウンドロビン方式のロードバランサ配下に MCP サーバーを置けるようになります。どのリクエストがどのインスタンスに届いても処理できるためです。Cloudflare の Brendan Irvine-Broque 氏は、ステートレスでキャッシュ可能かつルーティング可能でグローバルにスケールする、という趣旨で評価し、同社の Agents SDK は初日から対応するとしています。

ストリームを開いたままにしないと成立しなかったサーバー起点のリクエストは、Multi Round-Trip Requests(MRTR)に置き換わりました。呼び出しの途中でユーザーの確認や不足パラメータの補完が必要になった場合、サーバーは resultType: "input_required" と必要な要求を返し、クライアントは inputResponses に回答を入れて元の呼び出しを再試行します。従来 sampling・elicitation・roots が担っていた場面がこの形に統一されます。

運用面の変更も入りました。Streamable HTTP のリクエストには Mcp-Method と Mcp-Name のヘッダが必須になり、ゲートウェイやレートリミッタ、WAF が JSON ボディを解析せずにルーティングや計測を行えます。また tools/list prompts/list resources/list resources/read のレスポンスには ttlMs(ミリ秒)と cacheScope が付与され、並び順も決定的になりました。クライアント側のキャッシュに加え、上流のプロンプトキャッシュを安定させる狙いです。

認可の強化と拡張フレームワークの整備

認可まわりは、本番運用に耐える方向へ引き締められました。エンタープライズでの採用を見据えた変更が中心です。

RFC 9207 の issuer 検証が必須となり、認可サーバーは iss パラメータを返す必要があります。クライアント資格情報は発行元の認可サーバーに束縛されます。動的クライアント登録(DCR)には localhost リダイレクトに対応するための application_type パラメータが追加された一方、DCR 自体は Client ID Metadata Documents(CIMD)を推奨する形で正式に非推奨となりました。後方互換のため当面は残りますが、将来の削除が予告されています。

もう一つの柱が、正式な拡張フレームワークの新設です。実験的にコアへ置かれていた Tasks は io.modelcontextprotocol/tasks 拡張へ移り、ポーリング型の tasks/get tasks/update が加わりました。変更通知は単一の subscriptions/listen ストリームに集約され、通知種別ごとのオプトイン方式になっています。この枠組みには MCP Apps と Enterprise Managed Authorization(EMA)も含まれます。

Claude 側も同日、この仕様への対応を表明しました。Claude アプリと Claude Platform 全体で順次提供するとしていますが、記載は「coming soon」で具体的な提供日は示されていません。会話内に対話的な UI をタブ切り替えなしで描画するMCP Apps、長時間実行の作業に対応する Tasks が標準化された拡張として挙げられており、OAuth 2.0 / OIDC 準拠により Entra や Okta のようなエンタープライズ ID 基盤と統合できるとしています。あわせて、管理者が一度認可すれば IdP グループ経由でユーザー側の設定が不要になるエンタープライズ管理認証、製品面ごとの性能・採用・エラー・レイテンシを追う可観測性ダッシュボード、パブリックに公開せずプライベートネットワークへ接続するMCP Tunnels(リサーチプレビュー)が開発者向けに提供されます。Claude のコネクタディレクトリには 950 以上の MCP サーバーが掲載されています(2026年7月時点)。

既存の MCP サーバーに必要な対応

今回のリリースには破壊的変更が含まれます。特にセッション識別子を使っている実装は更新が必要です。

Tier 1 SDK は TypeScript・Python・Go・C# が更新済みで、Rust SDK はベータ対応です(2026年7月時点)。移行を進めやすくするため、事前テストで寄せられたフィードバックが取り込まれたとされています。

非推奨化されたものには最低12か月の猶予が設定されました。Roots・Sampling・Logging は非推奨となりますが12か月以上は動作を継続します。レガシーの HTTP+SSE トランスポートも正式に非推奨となり、1年の移行期間が設けられました。いずれも新規の実装では採用すべきでないとされています。

移行の効果を示す事例として、Manufact の CTO である Enrico Toniato 氏が、パッケージサイズを約83%削減しつつ25%高速化したという趣旨のコメントを寄せています。エージェント側の需要も伸びており、honeycomb.io の Austin Parker 氏は月間の対話クエリのうちほぼ20%がすでにエージェントによるものだ、という趣旨で述べています。AWS の Swami Sivasubramanian 氏は、AWS と Anthropic が MCP コミュニティを支援し、開発者が標準的でスケーラブルなインフラ上に MCP サーバーを配置できるようになる、という趣旨のコメントを出しています。

編集部の見方

編集部は、今回の目玉は新機能ではなく MCP サーバーの配置と運用コストの構造が変わったこと だと見ています。

• 根拠1: ステートレス化により、セッション固定も共有ストレージも不要な単純なラウンドロビン構成で運用できます。サーバーレスやエッジに置けるようになる意味は、機能追加より運用の裾野を広げる効果が大きいと考えられます。
• 根拠2: リスト結果に ttlMs と cacheScope が付き、順序も決定的になりました。呼び出しのたびにツール一覧を取り直す構成から抜けられるため、レイテンシとトークン消費の両方に効きます。移行事例としてパッケージサイズ約83%削減・25%高速化という報告も出ています。
• 根拠3: RFC 9207 の issuer 検証必須化と OAuth 2.0 / OIDC 準拠により、社内 ID 基盤に載せる前提の議論が現実的になりました。管理者が一度認可すれば済むエンタープライズ管理認証も、導入判断の障壁を下げます。

この見方が変わる条件は、クライアント側の対応時期です。Claude の対応は「coming soon」とされ提供日が示されていません。主要クライアントの対応が遅れて旧仕様との二重実装期間が長引けば、サーバー側が先に移行しても恩恵の実現は後ろ倒しになります。まずは12か月の猶予を前提に、セッション識別子への依存箇所を洗い出す段階と見ています。

よくある質問

Q: 既存の MCP サーバーはすぐ動かなくなりますか?

A: 直ちに停止するわけではありません。Roots・Sampling・Logging とレガシーの HTTP+SSE トランスポートは非推奨化されましたが、最低12か月の猶予が設定されています。ただし破壊的変更を含むため、セッション識別子を使っている実装は更新が必要です。

Q: ステートレス化で具体的に何ができるようになりますか?

A: 共有ストレージを持たない単純なラウンドロビン方式のロードバランサ配下に MCP サーバーを配置できます。接続を張り続ける前提がなくなるため、サーバーレスやエッジ環境への配置も可能になります。

Q: Claude ではいつから使えますか?

A: Claude アプリと Claude Platform で順次提供されるとされていますが、告知では「coming soon」と記載されており、具体的な提供日は公表されていません(2026年7月時点)。

まとめ

MCP 2026-07-28 仕様は、プロトコルの基礎をステートレスに置き換え、認可の要件を引き締め、拡張の枠組みを正式化した内容です。ハンドシェイクとセッション識別子が外れたことで、MCP サーバーは一般的な Web アプリと同じ配置戦略を取れるようになります。破壊的変更を含む一方で非推奨機能には最低12か月の猶予があり、当面はセッション依存箇所の棚卸しと SDK 更新が実務上の作業になります。

【用語解説】

• MRTR(Multi Round-Trip Requests): 呼び出しの途中で必要になったユーザーへの確認や不足パラメータの補完を、ストリームを維持せずに往復で解決する仕組み
• DCR(動的クライアント登録): クライアントを認可サーバーへ自動登録する方式。今回 CIMD を推奨する形で非推奨となった
• ケイパビリティ: クライアントやサーバーが対応している機能の申告。今回から各リクエストの _meta に載せて送る

引用元:

• [1] The 2026-07-28 Specification(Model Context Protocol Blog)
• [2] MCP 2026-07-28 spec: stateless core, coming to Claude(Claude by Anthropic)
• [3] MCP Specification 2026-07-28(Model Context Protocol)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。