STOP Inc.
受託開発ソリューション事業

MCPがステートレスになる日 ―― 2026-07-28仕様で何が変わり、なぜ重要なのか

#API設計 #github #MCP #受託開発 #運用自動化
本ブログのアイキャッチは当社サービス「OrionNaut」で作成しました。

2026年7月28日、AIエージェントとツールをつなぐ標準仕様「Model Context Protocol（MCP）」の新バージョン「2026-07-28」が公開されます。地味に見えるバージョン更新ですが、中身は通信の土台そのものを作り替える「ステートレス化」が主役で、MCPサーバを本番で運用する側にとっては無視できない節目のアップデートです。公開に先立ってGitHubが7月23日にいち早く対応を表明したことも、この変更の実務的な重さを物語っています。本記事では一次情報をもとに、何が変わり、なぜ重要なのかを整理します。

これまでのMCPが抱えていた「状態」の重さ

従来のMCPはステートフルな通信でした。クライアントが接続すると、まず initialize / initialized というハンドシェイクを行い、サーバが発行したセッションID（Mcp-Session-Id ヘッダ）を以後のすべてのリクエストに付けてやり取りします。会話の文脈をサーバ側で覚えておく設計で、一見合理的ですが、大規模運用では厄介の種になります。

というのも、セッションIDに紐づく状態をサーバが保持している以上、リクエストは「そのセッションを覚えているサーバ」に必ず届かなければなりません。複数台のサーバをロードバランサーの背後に並べる場合、同じクライアントを同じサーバへ振り分ける「スティッキールーティング」や、RedisなどでセッションIDを共有するストアが必要になります。スケールさせようとするほど、この状態管理がコストとして重くのしかかっていました。

2026-07-28の目玉：プロトコルのステートレス化

新仕様では、この前提が根本から変わります。initialize / initialized ハンドシェイクと Mcp-Session-Id ヘッダによるプロトコルレベルのセッションが廃止されました。クライアント情報やプロトコルバージョンは各リクエストの _meta フィールドに載せて都度送り、サーバの機能は新設の server/discover メソッドで取得します。つまり、どのリクエストも単独で完結する「ステートレス」な作りになったわけです。

効果はシンプルです。どのサーバがどのリクエストを受けても構わないため、スティッキールーティングもセッション共有ストアも不要になり、素直なラウンドロビンで負荷分散できます。接続時の初期化往復が消えることで、接続そのものも高速化します。

「ステートレス」でも状態を扱えなくなるわけではない

ここで誤解しやすいのが、「ステートレス＝状態を持てない」ではない、という点です。仕様が示すのは、状態管理をプロトコルの階層からアプリケーションの階層へ移す考え方です。たとえば create_basket を呼ぶと basket_id が返り、以降はその値を引数として渡していく——通常のHTTP APIではおなじみの「ハンドルパターン」です。状態はアプリ側で明示的に受け渡すことで、プロトコルは軽く保つ、という役割分担になります。

GitHubが先陣を切った意味

GitHubは正式公開に先駆けて、次期GitHub MCPサーバをこの仕様に対応させました。公式のチェンジログで挙げられているメリットは、まさにステートレス化の恩恵そのものです。初期化とセッションが不要になったことで接続が高速化し、クライアントは並列でハンドシェイクを完了できるようになりました。従来は初期化時に書き込み、呼び出しのたびに読み込んでいたRedisセッションを削除でき、パフォーマンスが向上したといいます。さらに、必要な値をHTTPヘッダから取得できるため、リクエスト本文を細かく検査する必要も減りました。

GitHubほどのトラフィックを捌く事業者が「スケールが容易になった」と真っ先に評価している点は、この変更が机上の理想論ではなく、現実の運用課題への回答であることを示しています。加えて公式の適合性テスト（Conformance Suite）も導入され、実装が仕様に沿っているかを検証しやすくなりました。

ステートレス化だけではない、成熟に向けた変更

今回のアップデートは、ステートレス化以外にも「仕様としての成熟」を感じさせる変更が多く含まれています。主なものを挙げると次の通りです。

  • 機能ライフサイクルポリシーの導入：非推奨になった機能も、削除までは最低12か月間は動作し続けることが約束され、移行に猶予が生まれました。今回は Roots・Sampling・Logging などが非推奨（注釈のみ）となり、それぞれツールパラメータやLLMプロバイダAPI、stderr/OpenTelemetry といった代替が案内されています。
  • 拡張フレームワークの正式化：新機能はコアに直接入れず、逆DNS形式のIDを持つオプトインの「拡張」として開発できるようになりました。サーバがHTML UIを返せる「MCP Apps」や、コアから独立した「Tasks拡張」がその例です。
  • 認可の強化：RFC 9207準拠の iss パラメータ検証や、OpenID Connect による動的クライアント登録など、認可まわりが複数のSEPで整理されました。
  • スキーマとエラーの標準準拠：ツールの入出力スキーマが JSON Schema 2020-12 に完全準拠し、oneOf / anyOf などが使えるように。エラーコードもMCP独自のものからJSON-RPC標準へ寄せられました。

移行にあたって押さえておきたいこと

これだけの変更なので、当然ながら大規模な破壊的変更を伴います。とはいえ「7月28日にいきなり全部壊れる」わけではありません。Tier 1 SDKには後方互換性が維持され、非推奨機能にも前述の12か月ルールが適用されます。仕様はリリース候補として先に固められ、約10週間の検証期間を経て正式版となる流れで、SDKメンテナーや実装者が対応する時間が設けられています。既存の実装を持っている場合、具体的には次のような観点で棚卸ししておくと移行がスムーズです。

  • セッション管理コードの撤去：initialize / initialized ハンドシェイクや Mcp-Session-Id ヘッダに依存している箇所を洗い出し、クライアント情報は _meta フィールドへ、機能取得は server/discover へと置き換えます。ここが移行の中心です。
  • 状態の持ち方をハンドルパターンへ：これまでサーバ側でセッションに紐づけて保持していた状態は、id を返して以降のリクエストで引数として渡す形に設計し直します。プロトコルではなくアプリケーション層で状態を扱う発想への切り替えです。
  • 非推奨機能の棚卸し：Roots・Sampling・Logging を使っていないかを確認します。使っている場合は、それぞれツールパラメータ／リソースURI、LLMプロバイダAPI、stderr／OpenTelemetry といった代替への移行計画を立てます。12か月は動き続けますが、早めに手を打つに越したことはありません。
  • 利用中のSDK・クライアントの対応状況を確認：Tier 1 SDKは後方互換が保たれますが、自分が使っているSDKやクライアントが新仕様にどう追随するかは個別に確認が必要です。ベータ版SDKが公開されているので、検証期間のうちに試しておくと安心です。
  • 適合性テストでの検証：公式の適合性テスト（Conformance Suite）を使い、自分の実装が新仕様に沿っているかをチェックします。手作業で仕様を追うより確実です。
  • インフラ構成の見直し：スティッキールーティングやRedisなどのセッション共有ストアが不要になります。ステートレス化を前提に、ラウンドロビンでの負荷分散へ構成をシンプル化できないか検討しましょう。

いずれも一度に対応する必要はありませんが、検証期間のうちに全体の移行方針を描いておくと、正式版公開後に慌てずに済みます。

まとめ

2026-07-28のMCP仕様更新は、派手な新機能でユーザーを沸かせるタイプのニュースではありません。しかし、セッション管理という配管を作り替えてスケーラビリティを底上げし、機能ライフサイクルや拡張フレームワークで長期運用の土台を整えた点で、MCPが実験段階から本番運用に耐える標準へと成熟していく節目だと言えます。GitHubの素早い対応は、その方向性が現場に歓迎されていることの証左でしょう。MCPサーバを開発・運用しているなら、検証期間のうちに一度自分の実装を仕様に照らしておくことをおすすめします。

参照リンク

関連記事