MCP 2026-07-28仕様の破壊的変更まとめ
ステートレス化で何が壊れるか
MCPがプロトコルレベルでステートレスになりました。セッションもinitializeハンドシェイクも廃止され、自作サーバーは手直しが必要になります。公式チェンジログをもとに、壊れる箇所と移行手順を整理します。
2026年7月28日、MCP（Model Context Protocol）の新しい仕様が確定しました。今回の更新は小さな追加ではなく、プロトコルの土台を作り替える内容です。セッションが消え、接続時のハンドシェイクもなくなりました。MCPサーバーを自作している方は、そのままでは動かなくなる箇所があります。この記事では公式チェンジログをもとに、何が壊れるのか、どう直すのかを実務目線で整理します。
何が起きたのか：MCPがステートレスになりました
今回の目玉はプロトコル層でのステートレス化です。公式仕様の「Base Protocol」には、はっきりと次のように記載されています。
Stateless, self-contained requests
Per-request capability negotiationこれまでのMCPは、接続時にinitializeで挨拶を交わし、サーバー側がセッションを保持しながらやり取りする設計でした。新仕様ではこの前提がなくなり、1回のリクエストが必要な情報をすべて自分で持ちます。
なぜステートレスにしたのか
公式ブログでは、効果が次のように説明されています。
any request can land on any instance behind a plain round-robin load balancer without needing shared storage
つまりどのリクエストがどのサーバーインスタンスに届いても処理できるようになります。共有ストレージなしで単純なロードバランサーの背後に置けるため、リモートMCPサーバーをスケールさせやすくなります。ローカルで1プロセスだけ動かしている分にはピンとこない変更ですが、サーバーを公開して複数人で使う構成では大きな意味を持ちます。
今回のチェンジログは2025-11-25からの差分としてまとめられています。それより前のバージョンで実装している場合は、途中の変更も含めて確認が必要です。
まず確認：あなたの実装は壊れますか
細かい仕様を読む前に、自作サーバーが影響を受けるかどうかを判定できるチェックリストを用意しました。1つでも当てはまれば手直しが必要です。
要修正セッションIDでユーザーごとの状態を保持している
Mcp-Session-IdヘッダーがStreamable HTTPトランスポートから削除されました。状態を持ちたい場合は、サーバーが発行したハンドルを通常のツール引数として渡す方式に変える必要があります。
要修正initializeで初期化処理をしている
initializeとnotifications/initializedのハンドシェイクが廃止されました。プロトコルバージョンとクライアント能力は、毎リクエストの_metaで運ばれます。
要修正pingやlogging/setLevelを使っている
どちらも削除されました。notifications/roots/list_changedも同様です。
要修正resources/subscribeで変更通知を送っている
subscriptions/listenに置き換わりました。HTTP GETエンドポイントも廃止され、単一の長寿命POSTレスポンスストリームに統合されています。
要修正接続断からの再開（Last-Event-ID）に頼っている
SSEストリームの再開と再送が削除されました。ストリームが切れたら処理中のリクエストは失われ、クライアントは新しいリクエストIDで送り直す必要があります。
要修正Roots・Sampling・Loggingを使っている
この3機能が非推奨になりました。当面は動きますが、新規実装では使わないよう公式が案内しています（移行先は後述）。
対応推奨ツール一覧をランダムな順序で返している
クライアント側のキャッシュとLLMのプロンプトキャッシュ命中率を上げるため、tools/listは決定的な順序で返すことが推奨されました。
新規必須server/discoverを実装していない
サーバーは対応プロトコルバージョン・能力・識別情報を返すserver/discoverを実装しなければなりません（MUST）。
ツールを定義してtools/callに応答するだけのシンプルなサーバーであれば、影響は限定的です。それでもserver/discoverの実装と、結果へのresultType付与は必要になります。
主な破壊的変更の一覧
公式チェンジログの「Major changes」に挙げられている変更を整理します。
| 変更内容 | 影響 |
プロトコルレベルのセッションとMcp-Session-Idヘッダーを削除 | tools/listなどの一覧系が接続ごとに変化しなくなる。状態はサーバー発行のハンドルをツール引数で渡す |
initialize／notifications/initializedを削除 | 各リクエストが_metaでプロトコルバージョンとクライアント能力を運ぶ。不一致はUnsupportedProtocolVersionError |
server/discoverを追加 | サーバーは実装必須。クライアントは事前のバージョン選択に使える |
HTTP GETとresources/subscribe系をsubscriptions/listenに置換 | クライアントが通知の種類を明示的にオプトインする方式へ |
ping・logging/setLevel・notifications/roots/list_changedを削除 | ログレベルは_metaのio.modelcontextprotocol/logLevelでリクエスト単位に指定 |
| Tasksをコアから公式拡張へ移動 | ブロッキングのtasks/resultをtasks/getのポーリングに変更。tasks/listは削除 |
| Multi Round-Trip Requests（MRTR）を導入 | サーバー起点のリクエストを廃し、InputRequiredResultを返してクライアントが再送する方式へ |
全結果にresultTypeを必須化 | "complete"または"input_required"。旧仕様サーバーの省略は"complete"として扱う |
| SSEの再開・再送を削除 | ストリーム断で処理中リクエストは消失。新IDで再送が必要 |
細かいが見落としやすい変更
- Streamable HTTPのPOSTに
Mcp-Method・Mcp-Nameヘッダーが必須に。ゲートウェイがヘッダーだけでルーティングできるようになります - 一覧系と
resources/readの結果にttlMsとcacheScopeが必須に。cacheScopeは"public"か"private" - リソース未検出のエラーコードが
-32002から-32602（Invalid Params）へ変更 - エラーコードの割り当て方針が定義され、
-32020〜-32099が仕様用に予約。既存SDKの-32000〜-32019は据え置き
非推奨になった機能と移行先
削除ではなく「非推奨」に位置づけられた機能があります。当面は動き続けますが、新規実装では使わないよう公式が案内しています。
| 非推奨 | 公式が示す移行先 |
| Roots | ディレクトリやファイルはツール引数・リソースURI・サーバー設定で渡す |
| Sampling | LLMプロバイダーのAPIと直接統合する |
| Logging | stdioならstderrへ出力、またはOpenTelemetryを使う |
| HTTP+SSEトランスポート | Streamable HTTPへ移行（2025-03-26から非推奨だったものを正式に位置づけ） |
| OAuth 2.0 動的クライアント登録（RFC7591） | Client ID Metadata Documents。未対応の認可サーバー向けに互換性は維持 |
同時に機能ライフサイクルと非推奨ポリシーが策定されました。Active・Deprecated・Removedの3状態が定義され、非推奨から削除まで最低12か月の猶予が設けられます。非推奨機能は公開レジストリで追跡されるため、今後は「気づいたら消えていた」という事態が起きにくくなります。慌てて全部書き換える必要はありません。
移行の進め方
公式ブログによれば、Tier 1 SDKであるTypeScript・Python・Go・C#はすでに新仕様に対応済みで、Rust SDKはベータ対応とされています。多くの場合、SDKを更新したうえで自作部分を直す流れになります。
おすすめの順序
- いまの実装がどのバージョンを前提にしているか確認する。チェンジログは
2025-11-25からの差分です - 上のチェックリストで影響範囲を洗い出す。セッション・ハンドシェイク・削除されたメソッドの3点が主な確認先です
- SDKを新仕様対応版に更新する。トランスポートやライフサイクル周りは多くがSDK側で吸収されます
server/discoverを実装する。サーバー側の必須項目です- 非推奨機能は12か月の猶予内で順次移行する。急ぐ必要はありませんが、新規追加は避けます
セッションで会話の途中経過を保持していた場合、単なるAPI差し替えでは済みません。公式が示す方針は「サーバーが発行したハンドルを、通常のツール引数としてやり取りする」方式です。どの状態を誰が持つのかを整理し直す作業になるため、他の変更より時間を見ておいてください。
今後は移行しやすくなります
今回の仕様には、将来のバージョンアップでトランスポートやライフサイクルのコードを書き直さずに済むよう、拡張の仕組みが組み込まれました。ClientCapabilitiesとServerCapabilitiesにextensionsフィールドが追加され、コア以外の機能はオプトインの拡張として提供されます。今回のような大きな作り替えは、当面は起きにくい設計になったと考えてよさそうです。
新しく使えるようになったもの
壊れる話ばかりではありません。今回の仕様で追加・整理された機能もあります。
公式拡張として整理されたTasks
長時間かかる処理を非同期で扱う仕組みが、実験的な位置づけから公式拡張（io.modelcontextprotocol/tasks）に移りました。ブロッキングして待つ方式ではなくtasks/getによるポーリングになり、処理の途中でクライアントから入力を渡すtasks/updateも追加されています。
MCP Apps
会話の中にチャート・フォーム・動画プレーヤーといったインタラクティブなUI要素を埋め込む拡張です。テキストのやり取りだけでは扱いにくかった用途に道が開けます。
Skills over MCP
エージェントのワークフロー向けに、構造化された指示をMCP経由で配布・利用する仕組みです。
これらの拡張はコアプロトコルの外側にあり、クライアントとサーバーの双方が明示的に対応していて初めて使えます。対応状況は実装ごとに異なるため、利用前に確認してください。
よくある質問
Q. Claude CodeやCodexの設定ファイルを書き換える必要はありますか？
MCPサーバーを利用しているだけであれば、基本的に不要です。今回の変更はプロトコルの実装側に影響するもので、クライアント側の対応はアプリとSDKの更新で吸収されます。影響を受けるのは自分でMCPサーバーを実装している場合です。
Q. 既存のサーバーはいつまで動きますか？
非推奨になった機能（Roots・Sampling・Loggingなど）は、新設された最低12か月の猶予期間のあいだ動作します。一方、pingやlogging/setLevelのように削除されたメソッドは猶予の対象ではありません。まず削除されたものから対応してください。
Q. ローカルで動かす小さなサーバーにも影響しますか？
影響はありますが、限定的です。ステートレス化の恩恵はリモート運用で大きく、ローカルの単一プロセスでは体感しにくい変更です。ただしserver/discoverの実装とresultTypeの付与は共通で必要になります。
Q. Samplingが非推奨だと、サーバーからLLMを呼べなくなりますか？
MCPの機能としては非推奨になりますが、公式はLLMプロバイダーのAPIと直接統合する方針を示しています。MCP経由で間接的に呼ぶのではなく、サーバー自身がAPIを叩く形に変える、という移行先です。
Q. どのSDKを使えばよいですか？
公式ブログによれば、TypeScript・Python・Go・C#のTier 1 SDKが新仕様に対応済みです。Rust SDKはベータ段階とされています。最新の対応状況は公式リポジトリでご確認ください。
まとめ
- 2026-07-28仕様でMCPはプロトコル層でステートレス化された
- セッション（
Mcp-Session-Id）とinitializeハンドシェイクが廃止。状態はサーバー発行のハンドルをツール引数で渡す方式へ ping・logging/setLevelなどは削除。SSEの再開・再送も廃止- サーバーは
server/discoverの実装が必須 - Roots・Sampling・Loggingは非推奨だが、最低12か月の猶予あり
- 影響を受けるのはMCPサーバーを自作している人。使うだけなら基本的に対応不要
最初の一歩としては、自作サーバーのコードを開いてinitializeとMcp-Session-Idを検索してみてください。どちらもヒットしなければ影響は小さく、SDKの更新とserver/discoverの追加でおおむね対応できます。ヒットした場合は、状態をどこに持たせるかの設計から見直すことになるため、12か月の猶予を活かして計画的に進めるのが現実的です。
