MCPプロトコルがステートレス化へ、ローンチ以来最大の仕様変更
2026年7月28日 15:27
AIエージェントと外部サービスを接続する「Model Context Protocol（MCP）」の最新仕様が7月28日に確定し、プロトコル層のセッション管理が全面的に廃止される。これまで本番環境では、スティッキーセッションや共有セッションストアなどが必要だったが、新仕様ではこうしたインフラ上の負担を解消できる。さらに、状態をモデルから見える明示的なハンドルとして扱うことで、AIエージェントが複数のツールにまたがって状態を推論、組み合わせ、引き継げるようになる。MCPサーバーの運用チームは既存実装のセッション依存度に応じて移行する必要があり、コミュニティSDKの利用者は開発元の対応予定を確認してから移行時期を決める必要がある。
■MCPとは何か、そして何が変わるのか
MCPは、コーディングアシスタント、チャットボット、自律型ワークフローツールなどのAIエージェントを、コードリポジトリ、データベース、APIなどの外部サービスに接続するオープン標準である。Anthropicが2024年11月25日に導入し、2026年半ばまでにOpenAI、Google DeepMind、Microsoft、AWS、数百社のエンタープライズソフトウェアベンダーが採用した。現在は、Anthropic、OpenAI、Block、Google、Microsoftなどがプラチナメンバーとして参加する、Linux Foundationの指定基金であるAgentic AI Foundationが管理している。
MCPのステートフルなセッションモデルは、これまで本番環境のMCPデプロイメントに、スティッキーなロードバランサールーティング、共有Redisセッションストア、ゲートウェイでのリクエストボディ検査を事実上強いてきた。2026年7月28日に確定する2026-07-28仕様では、このセッションモデルがプロトコルから全面的に削除され、MCPは初めてプロトコル層でステートレスになる。
これにより、こうしたインフラ上のオーバーヘッドは解消される。しかし、より重要な変化は目に見えにくい部分にある。状態をトランスポート層から、モデル自身が認識できる明示的なハンドルへ移すことで、新仕様はエージェント型ワークフローに従来とは質的に異なる基盤をもたらす。これまでトランスポートメタデータ内に隠されたセッション状態に依存していたAIエージェントは、basket_idやworkflow_run_idをツールの戻り値として直接受け取り、その意味を推論し、ほかのハンドルと組み合わせ、複数段階のツールチェーンへ引き継げるようになる。これは、サーバーが管理するセッション状態では実現できなかったことだ。
現在確定済みの2025-11-25仕様では、すべてのMCPクライアントが、ツールを呼び出す前にinitializeリクエストでセッションを開始する必要がある。サーバーはMcp-Session-Idヘッダーを返し、そのセッション内の後続リクエストにはすべて同じヘッダーを含めなければならない。このセッションIDによって各クライアントは、IDを発行したサーバーインスタンスに固定される。そのため、クライアントを同じインスタンスへ戻すスティッキーなロードバランサールーティングか、あるインスタンスが別のインスタンスで作成された状態を参照できるRedisなどの共有セッションストアがなければ、水平スケーリングができなかった。
2026-07-28仕様では、ハンドシェイクとセッションIDの両方が廃止される。この変更は、2つの仕様拡張提案（SEP）によって定義されている。SEP-2575はinitialize/initializedのやり取りを削除し、SEP-2567はMcp-Session-Idヘッダーとプロトコルレベルのセッションそのものを削除する。以前は接続時に一度だけ交換されていたプロトコルバージョン、クライアントの識別情報、クライアントの機能情報は、個々のリクエストに含まれる_metaフィールドで送信されるようになる。新しいserver/discoverメソッドを使えば、クライアントは事前に必要となった時点で、サーバーの機能情報をオンデマンドで取得できる。
その結果、どのMCPリクエストも任意のサーバーインスタンスで処理できるようになる。これまでスティッキーセッション、共有セッションストア、ゲートウェイでのディープパケットインスペクションを必要としていたリモートサーバーも、単純なラウンドロビン方式のロードバランサーの背後で運用できる。
■ステートレスなプロトコルとステートフルなエージェント
リードメンテナのDavid Soria Parra氏とDen Delimarsky氏は、プロトコルレベルのセッションを削除しても、アプリケーションが永続的な状態を放棄する必要はないと明言している。複数回のツール呼び出しにわたって状態を保持する必要があるサーバーは、HTTP APIが以前から採用してきた方法を利用できる。すなわち、ツールがbasket_id、browser_id、workflow_run_idなどの明示的なハンドルを発行し、その後の呼び出しでモデルが通常の引数としてハンドルを渡す方式だ。
これは単なるインフラ上の回避策ではない。状態がトランスポートメタデータ内にある場合、エージェントからは見えない。モデルはその状態について推論できず、あるツールのハンドルと別のツールのハンドルを組み合わせることも、マルチエージェントワークフローの工程間で状態を引き継ぐこともできない。状態を明示的なツールの戻り値に移すことで、モデルが扱える第一級の入力になる。Parra氏とDelimarsky氏は、実際にはこのパターンがセッション状態と同等の代替手段というだけでなく、「多くの場合、より強力な」代替手段になることが分かったと記している。
■インフラ層で可能になること
同じ仕様リリースに含まれる3つの比較的小規模な変更により、MCPのトラフィックを大規模に運用しやすくなる。
Streamable HTTPトランスポートでは、すべてのリクエストにMcp-MethodヘッダーとMcp-Nameヘッダーを含めることが必須となる（SEP-2243）。これにより、ロードバランサー、ゲートウェイ、レートリミッターはリクエストボディを検査せず、実行される操作に基づいてルーティングできる。リスト取得とリソース読み取りの結果には、HTTPのCache-Controlを参考にしたttlMsフィールドとcacheScopeフィールドが追加される（SEP-2549）。クライアントは、tools/listの応答をいつまで最新のものとして扱えるか、ユーザー間で共有しても安全かを正確に判断できる。
また、_metaを使ったW3C Trace Contextの伝播方法が文書化され（SEP-414）、traceparent、tracestate、baggageのキー名が定められた。これにより、ホストアプリケーションからクライアントSDK、MCPサーバー、さらにサーバーが呼び出す下流サービスまで、ツール呼び出しの分散トレースを追跡し、OpenTelemetry互換のバックエンド上で単一のスパンツリーとして確認できる。
■ステートレス環境に向けて再設計されたサーバーからクライアントへのリクエスト
現在の仕様では、サーバーが呼び出しの途中でユーザーに何かを尋ねる必要がある場合、長時間維持されるServer-Sent Events（SSE）ストリームを使用する。この仕組みも置き換えられる。新しいMulti Round-Trip Request（複数往復リクエスト）機構（SEP-2322）は、永続的な接続がなくても機能する。サーバーがユーザー入力を必要とする場合、質問とrequestStateデータを含むInputRequiredResultを返す。クライアントはユーザーの回答を受け取り、inputResponsesと、受け取ったrequestStateを添えて元の呼び出しを再実行する。必要な情報がすべてペイロードに含まれるため、どのサーバーインスタンスでも再試行を処理できる。
関連する変更（SEP-2260）では、サーバーからクライアントへのリクエストを発行する際、サーバーがクライアントのリクエストを処理中であることを正式な要件とする。従来の仕様では推奨にとどまっていた。これにより、ユーザーに前触れなく入力を求めることはできなくなり、すべてのユーザー入力要求は、ユーザーまたはそのエージェントが開始した操作にひも付けられる。
■7月28日リリースのその他の変更点
ステートレスな中核部分が最大の変更点だが、2026-07-28仕様は、ほかの複数の領域でもこれまでで最も広範なMCPの改訂となっている。
拡張機能が正式な仕組みになる。Extensionsフレームワーク（SEP-2133）により、新機能が実験段階から公式機能へ移行するための体系的な経路が用意される。拡張機能は逆DNS形式のIDで識別され、クライアントとサーバーのcapabilitiesに含まれるextensionsマップを通じてネゴシエーションされる。また、担当メンテナに管理が委任された独自のext-*リポジトリに配置され、コア仕様とは独立してバージョン管理される。
新仕様では、2つの公式拡張機能が提供される。MCP Apps（SEP-1865）は、サーバーがインタラクティブなHTMLインターフェースを提供し、MCPホストがサンドボックス化されたiframe内に表示できるようにする。Tasks拡張機能（SEP-2663）は、サーバー主導のライフサイクルとハンドルベースの状態管理を採用し、ステートレスモデルを中心に再設計されている。
認可も強化される。6つの仕様拡張提案により、OAuth 2.0およびOpenID Connectを使ったデプロイメントとの整合性が高められる。最も重要な変更は、RFC 9207に従って、クライアントが認可応答のissパラメーターを検証することを義務付けるものだ（SEP-2468）。これは、複数のサーバーを使う環境で、クライアントが誤ったサーバーへ認可資格情報を送ってしまうミックスアップ攻撃を、低コストで緩和するための対策となる。そのほかのSEPでは、動的クライアント登録におけるapplication_typeの宣言、認可サーバーの発行者識別子と資格情報のひも付け、リフレッシュトークンのフロー、.well-knownを使ったディスカバリーなどを扱う。
Roots、Sampling、Loggingの3機能は、新しいライフサイクルポリシー（SEP-2577）の下で正式に非推奨となる。これらは7月28日のリリースと、その後12か月以内に公開されるすべての仕様バージョンで引き続き動作するが、削除するには別の正式な手続きが必要となる。Rootsの推奨代替手段は、明示的なツールパラメーターまたはリソースURIである。SamplingはLLMプロバイダーAPIとの直接統合、Loggingはstdioトランスポートではstderr、構造化された可観測性にはOpenTelemetryを使うことが推奨される。
ツールの入出力スキーマは、JSON Schemaの一部に限定した実装から、完全なJSON Schema 2020-12へ移行する（SEP-2106）。これにより、oneOf、anyOf、allOfなどの合成演算子、条件分岐、$refを使った参照が利用できるようになる。これに伴う具体的な破壊的変更として、存在しないリソースに対するエラーコードが、MCP独自の-32002からJSON-RPC標準の-32602へ変更される。リテラル値-32002を照合しているサーバーまたはクライアントは更新が必要だ。
■GitHubが新仕様に即日対応
GitHubは7月23日、AIエージェントがコードを読み取り、ファイルを検索し、リポジトリを操作できるGitHub MCP Serverについて、7月28日に新仕様へ対応したバージョンを公開すると発表した。GitHubチームは、新しいアーキテクチャへの対応で行った3つの具体的な技術変更を文書化している。
第一に、Redisを使ったセッションストレージを削除した。initialize時のデータベース書き込みがなくなり、個々の呼び出しで発生していたデータベース読み取りも排除された。これにより、ユーザーが機能を失うことなく接続を高速化できる。
第二に、ディープパケットインスペクションが不要になった。新仕様で必須となるHTTPヘッダーから、ログ記録とシークレットスキャンに必要な情報を取得できるため、SDKが処理する前にサーバーがすべてのリクエストボディを解析する必要がなくなる。
第三に、GitHubチームはユーザー入力要求の実装を、新しい複数往復リクエストモデルに対応させた。同時に、Go SDKのラッパーを使って、従来のクライアントとの後方互換性も維持した。
GitHubはまた、すべてのTier 1 SDKが後方互換性を維持し、新仕様のベータサポートをすでに提供していることを確認した。これは、移行期間中に基本機能を維持するだけであれば、既存デプロイメントの多くで手作業による対応が不要であることを意味する。
■移行に実際に必要なこと
本番環境でMCPサーバーを運用しているエンジニアリングチームに必要な作業の範囲は、既存実装がセッション状態にどの程度依存しているかによって決まる。
すでに実質的にステートレスなサーバーや、stdioだけで動作するサーバーに必要な変更は少ない。initializeハンドラーを削除し、新しいMcp-MethodヘッダーとMcp-Nameヘッダーに対応したうえで、SDKを更新すればよい。
一方、セッションIDを使い、複数回のツール呼び出しにわたってクライアントごとの状態を参照するなど、本格的なセッションロジックを持つサーバーは、その状態を明示的なハンドルパターンへ移行する必要がある。ツールがハンドルを返し、クライアントがそれを保持し、モデルが後続の呼び出しで引数として渡す方式に変更する。
より難しいのは、Tier 1に含まれないコミュニティSDKを利用しているケースだ。これらのSDKには2026-07-28仕様への対応時期が保証されていない。利用チームは、SDKの開発者が対応予定を公開するまで、移行日を確定すべきではない。
リードメンテナのSoria Parra氏は、今回削除される仕組みの規模の大きさを認めている。7月23日のライブ配信で、2026-07-28改訂には「おそらく認可機能を追加して以来」の「最も大幅な変更」が含まれていると説明し、「MCPを形作ってきた多くのものがなくなった」と述べた。一方で、SDKを最新の状態に保っているチームであれば、アップグレードにそれほど苦労しないはずだとも指摘した。
この仕様は2026年5月21日からリリース候補版となっていた。約10週間の検証期間が設けられ、SDKのメンテナやクライアントの実装者は、最終仕様の確定前に実際のワークロードを使ってテストできた。
非推奨化から最短での削除まで少なくとも12か月を空ける正式なライフサイクルポリシーが導入され、Extensionsフレームワークによって新機能をオプトインで追加する経路も用意された。MCPのメンテナは、7月28日のリリースについて、今後長期にわたってプロトコルを発展させるための基盤になるとの見方を示している。
■注目ポイントQ&A
●7月28日にMCPがステートレス化されると、何が使えなくなりますか？
主な破壊的変更は、initialize/initializedによるセッションハンドシェイクとMcp-Session-Idヘッダーの削除、tasks/listの削除、長時間維持されるServer-Sent Eventsストリームから複数往復リクエストへの置き換えです。Roots、Sampling、Loggingは正式に非推奨となりますが、少なくとも12か月間は引き続き機能します。
resourceNotFoundのエラーコードは、MCP独自の-32002からJSON-RPC標準の-32602へ変更されます。リテラル値-32002を照合しているサーバーは更新が必要です。2025-11-25仕様に基づくサーバーは、新しい2026-07-28 SDKへ更新したクライアントと動作しない可能性があります。互換性を維持するには、クライアントとサーバーの双方が対応する同じ世代のプロトコルを使用するか、明示的なフォールバック処理を実装する必要があります。
●MCPセッションの削除後は、サーバーを完全にステートレスにする必要がありますか？
いいえ。仕様から削除されるのはプロトコル層のセッションであり、アプリケーション層で状態を保持することは禁止されません。ツール呼び出しをまたいで状態を追跡する必要があるサーバーは、明示的なハンドルパターンを採用します。ツールが応答の一部としてbasket_idやbrowser_idなどのハンドルを返し、モデルが後続の呼び出しで通常の引数としてそのハンドルを渡します。
アプリケーションの状態は、Redis、PostgreSQL、プロセス内など、適切な場所に保存できます。ただし、その状態を識別するハンドルは、トランスポートメタデータ内に隠されるのではなく、モデルから見えるようになります。MCPのメンテナによると、このパターンにより、モデルはハンドルについて推論し、ツール間で組み合わせ、マルチエージェントワークフローの工程間で引き継げるようになります。
●ハンドルパターンによって、AIエージェントができることはどう変わりますか？
現在のステートフルな仕様では、セッションコンテキストはサーバーによって管理され、モデルからは見えません。そのため、エージェントはセッションコンテキストを調べたり、組み合わせたり、その意味を推論したりできません。
新しいハンドルパターンでは、状態識別子が、モデルの受け取る明示的なツールの戻り値になります。例えば、複数段階のワークフローを管理するエージェントは、あるツールが返したworkflow_run_idを保持して別のツールへ渡し、さらに3番目のツールから受け取ったbrowser_idと組み合わせられます。隠れたセッションモデルではできなかった形で、ツールの境界を越えて状態を組み合わせられるようになります。MCPのメンテナは、ハンドルパターンについて、セッション状態の単なる代替ではなく、多くの場合はより強力な選択肢になると説明しています。
●7月28日以降、コミュニティのMCP SDKを利用する前に何を確認すべきですか？
GitHubの説明によると、MCPプロジェクトが管理する公式のTier 1 SDKは、新仕様のベータサポートを提供しており、後方互換性も維持しています。一方、Tier 1に含まれないコミュニティSDKには、2026-07-28仕様への対応時期が保証されていません。移行日を決める前に、利用しているSDKの開発者が対応予定を公開しているか確認してください。
すぐに移行できない場合は、クライアントSDKのバージョンを固定し、クライアントとサーバーの双方で2025-11-25世代のプロトコルを維持することが、最も安全な暫定策です。
元記事: AI Tool Protocol Drops Sessions Tomorrow: MCP’s Largest Spec Change Since Launch