MCPが「セッションを捨てる」設計に大改訂——2026-07-28版で何が変わったか

MCP(Model Context Protocol)の仕様が2026-07-28付けでメジャー改訂されました。今回の変更の中心は、接続の途中経過を覚えておくための「セッション」という概念そのものを仕様から外したことです。

これまでのMCPは、クライアントがinitializeリクエストを送るとサーバーがMcp-Session-Idというヘッダーを発行し、以降の全リクエストにそのIDを付け続けることで「このやり取りは一連の会話である」と認識する仕組みでした。2026-07-28版ではこのハンドシェイクごと廃止されています。各リクエストは_metaにプロトコルバージョンとクライアントの機能情報を都度含めるようになり、サーバー側から見れば一つ一つのリクエストが独立して完結します。サーバーをまたいで状態を引き継ぐ必要がある場合も、サーバーが発行する明示的なハンドルを通常のツール引数として渡す方式に置き換えられました。

セッションを消すと何が変わるのか

一番わかりやすい効果は、サーバーの水平スケールがしやすくなることです。従来の設計では「このクライアントの続きのリクエストは、さっきと同じサーバーインスタンスに届かなければならない」というセッション固定(スティッキーセッション)の制約がありました。ステートレス化によって、ロードバランサーの背後にある任意のインスタンスにリクエストを振り分けられるようになります。

これに合わせてserver/discoverというRPCも新設されました。サーバーは対応しているプロトコルバージョンや機能、アイデンティティを事前に告知することが必須になっています。バージョンが合わない場合はUnsupportedProtocolVersionErrorが返る形に整理されました。あわせて、pingやlogging/setLevelのような単発の状態管理コマンドも廃止され、ログレベルの指定はリクエストごとの_metaに持たせる方式に変わっています。

私たちは開発の中で、Figma Desktop が提供するMCPサーバーにWSL環境から接続する構成を運用しています。接続そのものはinitializeハンドシェイクを含む従来方式です。実務で困るのは「サーバー側のプロセスを再起動しても復旧しない」というケースで、原因はポート転送の設定が待ち受けポートを握り続け、サーバー側のプロセスが同じポートを取り直せないことでした。復旧するには、転送設定を先に削除してからプロセスを起動し直すという順序を守る必要があります。

ただしこれはネットワーク層でのポートの取り合いであり、MCPのセッション機構とは層が違います。実際、この構成で動いているMCPサーバーのプロトコルは古い版で、今回廃止されたMcp-Session-Idはそもそも使っていません。ステートレス化がこの復旧手順を短くしてくれるわけではない、というのが正直なところです。今回の改訂の動機として公式に説明されているのも、ロードバランサー配下のどのインスタンスにも振れるようにする信頼性とスケーラビリティの向上で、私たちのような1台構成がそのまま恩恵を受ける話ではありません。ただinitializeハンドシェイクが無くなり、接続が切れても次のリクエストを投げるだけで復帰できるようになるのは、規模に関係なく効く変更だと思います。

サーバーからの「割り込み」も往復方式に統一された

ただし、接続の状態を消しただけでは「サーバーがクライアントに一方的に割り込む」という設計上の性質までは消えません。今回の改訂ではここにも手が入りました。対象になったのはroots/listやsampling/createMessageのように、サーバーがクライアントに対して一方的にリクエストを送る仕組みです。

2026-07-28版では、これがMulti Round-Trip Requests(MRTR)という統一パターンに置き換わりました。サーバーは追加入力が必要な時、レスポンスのresultTypeに"input_required"を返します。クライアントは必要な情報を集めたうえで、inputResponsesを付けて元のリクエストをそのままリトライします。処理が完了していればresultTypeは"complete"です。このresultTypeフィールドは、今回から全ての結果に必須になりました。

実験的機能だったtasksも、この整理に合わせてコア仕様から独立した拡張(io.modelcontextprotocol/tasks)に切り出されています。ブロッキングだったtasks/resultは、ポーリング方式のtasks/getに置き換わりました。サーバーが応答をブロックしたまま待つのではなく、クライアント側が都度状態を聞きに行く形にすることで、これもステートレス化と同じ方向を向いています。

実装側で確認すべきこと

公式ブログによれば、MCPはこの1年半で急成長し、Tier 1のSDKだけで月間約5億ダウンロードに達しているとのことです。それだけ広く使われている土台の仕様が変わるため、影響範囲は小さくありません。

移行の実務は、TypeScript・Python・Go・C#のTier 1 SDKがすでに新仕様へ対応済みで、Rust SDKもベータ版で利用できる状態です。各SDKが移行ガイドを提供しており、主な作業は「セッション識別子に依存した実装」を洗い出して直すことになります。Mcp-Session-Idをキーにキャッシュや状態を持たせているサーバー実装や、initialize完了を前提に後続処理を組んでいるクライアント実装は、洗い出しの対象です。

非推奨リストにも実務上の期限があります。Roots・Sampling・Logging の各機能、HTTP+SSEトランスポート、OAuth 2.0のDynamic Client Registrationは、いずれも12ヶ月の移行期間付きで非推奨になりました。恒久的に禁止されたわけではありませんが、新規実装でこれらに依存するのは避けた方がよく、既存実装は移行ガイドに沿って計画的に置き換える対象です。

まとめ

移行作業の優先順位は、影響範囲の大きさより先に、検出のしやすさで決めるのが実務的です。コードベース内でMcp-Session-Idヘッダーの参照箇所と、initializeの完了を前提にした後続処理を検索すれば、依存箇所の洗い出しはすぐに着手できます。

使用しているSDKがTypeScript・Python・Go・C#であれば新仕様への対応はすでに完了しているため、まずSDKを最新化してから上記の検索に進むのが早い順序です。Rustを使っている場合は、SDKがまだベータ版であることを踏まえて対応範囲を先に確認しておく必要があります。

---

出典

• Model Context Protocol 公式チェンジログ「2026-07-28」: https://modelcontextprotocol.io/specification/2026-07-28/changelog
• Model Context Protocol 公式ブログ「2026-07-28」: https://blog.modelcontextprotocol.io/posts/2026-07-28/

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)