MCP 2026-07-28アップデートの全体像

Model Context Protocol（MCP）の仕様が2026年7月28日にアップデートされ、この7月28日版から「ステートレスな接続」が正式仕様になりました。前回のリリースが2025年11月25日でしたので、およそ8か月ぶりの節目となる更新です。今回の変更は単なる機能追加ではなく、クライアントとサーバの通信のあり方そのものを見直すもので、MCPサーバを本番運用する現場に直接影響します。

これまでのMCPは、クライアントとサーバの間でステートフルな通信を前提としていました。接続ごとにセッションを確立し、その状態をサーバ側で保持する設計です。新仕様ではこの前提が外れ、各リクエストが単独で完結する形へと移行します。とはいえ移行が強制されるわけではなく、非推奨（deprecation）のウィンドウは最低でも12か月が確保されているため、現行実装をすぐに壊す性質の変更ではありません。本記事では、確定している一次情報の範囲で何がどう変わったのかを整理し、実務でどう見極めるべきかを考えます。

情報源としては、日本語での解説記事に加え、MCP公式ブログとGitHubのChangelogという一次情報を突き合わせています。ステートレス化という同じ変更でも、プロトコルを定義する立場と、実際にサーバを提供する立場では説明の力点が少しずつ異なります。両者を並べて読むことで、仕様として何が決まったのか、そして運用側で何がうれしいのかを切り分けて理解できます。以降では、変更の中身、実務上のメリット、GitHubの対応、そして移行の考え方という順に見ていきます。

最大の変更点はステートレス通信化

今回のアップデートで中心となるのが通信のステートレス化です。従来はクライアントとサーバの間でステートフルな通信が行われ、接続ごとにMcp-Session-Idヘッダを使ったセッション管理が必要でした。加えて、通信を始める際にはinitializeとinitializedによるハンドシェイクを行い、そこで確立した状態を前提に以降のやりとりが進んでいました。新仕様ではこのMcp-Session-Idヘッダによる管理が廃止され、イニシャライズによるハンドシェイクも不要になります。

代わりに、各リクエストが単独で完結する設計へと変わります。プロトコルのバージョン、クライアントID、クライアントの能力といった情報は、リクエストごとに_metaへ載せて運ばれます。これにより、あるクライアントからのリクエストがどのMCPサーバに到着しても処理できるようになりました。さらにStreamable HTTPのリクエストではMcp-MethodとMcp-Nameという2つのヘッダが必須化され、ゲートウェイやレートリミッタ、WAFがJSONボディをパースすることなく、ヘッダの値だけでルーティングや計測を行えるようになっています。

ここで押さえておきたいのは、ステートレス化はアプリケーションに完全な無状態を強制するものではないという点です。状態を保持したいサーバは、ツールから明示的なハンドル（handle）を発行し、そのハンドルをモデルに以降の呼び出しで引数として渡し返させる方式で対応できます。プロトコル層からセッションの概念を切り離しつつ、必要な状態はアプリケーションの設計として明示的に扱う、という役割分担になったと理解すると分かりやすいでしょう。

ステートレス化が実務にもたらすメリット

ステートレス通信化がもたらす最大の実務メリットは、運用のスケーラビリティです。従来はセッション状態がサーバに紐づいていたため、複数台構成にする場合はスティッキーセッションで同じサーバへ誘導したり、共有のセッションストアを用意したりといった工夫が欠かせませんでした。新仕様ではリクエストがどのサーバインスタンスに届いても処理できるため、複数台のMCPサーバとロードバランサーを組み合わせたスケーラブルな運用が容易になると説明されています。

この性質は、ゲートウェイやレートリミッタといった周辺コンポーネントの設計も素直にします。ルーティングや計測に必要な情報がヘッダから読み取れるため、リクエストの中身を解釈するための重い処理を挟まずに済むからです。結果として、トラフィックを前段で捌く構成が組みやすくなります。ただし、どの程度の性能向上が得られるかは環境に依存する部分が大きく、一次情報でも定量的なベンチマーク値は示されていません。ここでは「スケールしやすくなる」という定性的な利点として捉えておくのが妥当です。

整理すると、実務面での恩恵は次のような点に集約されます。

• スティッキーセッションや共有セッションストアがプロトコル層で不要になり、水平スケールの構成を組みやすくなる
• ゲートウェイやWAFがヘッダの値でルーティングと計測を完結でき、ボディの解析に頼らずに済む
• 接続開始時のハンドシェイクが省けるため、接続がシンプルになり、複数の接続を並行して確立しやすくなる

GitHub MCPサーバの新仕様対応

この仕様変更にいち早く歩調を合わせたのがGitHubです。GitHubは2026年7月23日に、次期GitHub MCPサーバが最新のMCP仕様に沿ったステートレス通信へ対応することを告知し、7月28日の新仕様に合わせる形で対応を進めると説明しました。告知の日付とプロトコルの正式移行日は分かれているため、7月23日に告知され、7月28日の新仕様に合わせて対応する、と分けて理解しておくと混乱がありません。

GitHub側の説明によれば、セッションとinitializeがともに削除されたことで、サーバへの接続がこれまでよりシンプルかつ高速になり、通信ごとのやりとりもスムーズになるとされています。実装面では、セッション管理に使っていたRedisセッションが削除され、initialize時のデータベース書き込みと、呼び出しごとに発生していたデータベース読み込みが不要になりました。また、必要な値をHTTPヘッダから直接読み取れるようになったため、ディープパケットインスペクションも不要になったと述べられています。運用に組み込まれていた状態管理の仕組みそのものを減らせる点が、実装者にとっての具体的な効き目だと言えます。

ここで押さえておきたいのは、告知の内容がプロトコル仕様の変更と整合している点です。MCP公式がプロトコル層からセッションとハンドシェイクを外したのに対し、GitHubは自社サーバの実装からRedisセッションやデータベース依存を取り除いて応えています。仕様の変更が、実サーバの運用負荷の軽減という形で具体化された一例として読むと、今回のアップデートが机上の話にとどまらないことが見えてきます。ただし、どの程度シンプルで速くなるかは各サーバの実装や規模に依存するため、数値としての断定は避け、あくまで方向性として受け止めるのが適切です。

移行で押さえるべき両論と段階導入

移行コストについては、立場によって温度差がある点を冷静に受け止める必要があります。GitHubは、すべてのTier 1 SDK（全プロトコル実装を含む完全サポートのSDK）が後方互換性を維持しており、ベータ対応もすでに出荷済みであるため、サポートを維持するために利用者が特別な対応をする必要はない、と楽観的に説明しています。Tier 1 SDK経由で利用しているのであれば、影響は小さく抑えられると考えてよいでしょう。

一方でMCP公式は、セッション識別子に依存していた開発者には一定の移行コストがあると明記しています。つまり、Mcp-Session-Idヘッダに独自に依存した実装を抱えている場合は、ハンドル方式などへの作り替えが必要になり得ます。どちらか一方だけを見て判断せず、自分たちの実装がTier 1 SDKに乗っているのか、それともセッション識別子へ直接依存しているのかを切り分けることが、移行判断の出発点になります。なお、どのSDKや言語がTier 1に該当するかの網羅的な一覧は一次情報で確認できていないため、個別の断定は避け、利用中のSDKのドキュメントで確認する姿勢が安全です。

Ragateの現場で取り入れるなら、いきなり全面移行するのではなく段階的に進めるのが現実的です。まず自分たちのMCP実装がセッション識別子へどの程度依存しているかを棚卸しし、依存が薄ければTier 1 SDKの更新に追随して後方互換の範囲で様子を見る、依存が濃ければ状態の持ち方をハンドル方式へ寄せていく、という順序です。非推奨ウィンドウが最低12か月確保されていることを踏まえれば、慌てて作り替える必要はありません。スケーラブルな運用という利点を見据えつつ、自分たちの実装状況に応じて着実に検証を重ねていくのが、堅実な向き合い方だと考えます。