MCP 2026-07-28 仕様公開 — ステートレス化で何が変わり、既存サーバーの何が壊れるか

2026年7月28日、Model Context Protocol（MCP）の新仕様 2026-07-28 が公開された。前版 2025-11-25 からの最大の変更はプロトコルのステートレス化で、initialize ハンドシェイクとセッションIDが廃止され、すべてのリクエストが自己完結する形になった。サーバーレスやエッジ環境への配置が容易になる一方、既存のMCPサーバー実装には確実に手が入る。ここでは変更点を、移行時に何が壊れるかという観点で整理する。

従来は接続時に initialize を送り、notifications/initialized で確立し、以降のリクエストはその文脈を前提にしていた。新仕様ではこのハンドシェイクが丸ごと消え、すべてのリクエストが _meta に自分の文脈を載せて自己完結する。

- io.modelcontextprotocol/protocolVersion — そのリクエストのプロトコルバージョン
- io.modelcontextprotocol/clientCapabilities — クライアントの機能
- io.modelcontextprotocol/clientInfo — クライアントの識別情報（SHOULD）
- サーバー側は各結果の _meta に io.modelcontextprotocol/serverInfo を載せる（SHOULD）

バージョンが噛み合わない場合は UnsupportedProtocolVersionError を返す。実装上の意味は明快で、リクエスト間で状態を持つ前提のサーバーはそのままでは動かない。ハンドシェイク時に受け取った capabilities をインスタンス変数に保持しているコードは、リクエスト単位で読む形へ書き換えることになる。

ハンドシェイクがなくなった代わりに、サーバーは server/discover RPCの実装が必須（MUST）になった。対応プロトコルバージョン・capabilities・identity を広告するためのもので、クライアントは他のリクエストの前に呼んで事前にバージョンを選ぶこともできるし、STDIO では後方互換性の探り（旧仕様サーバーかどうかの判定）にも使える。任意呼び出し（MAY）である点がポイントで、呼ばれない前提でもサーバーは正しく応答できなければならない。

Streamable HTTP トランスポートから Mcp-Session-Id ヘッダーが削除され、tools/list resources/list prompts/list は接続ごとに内容が変わってはいけないことになった。同じサーバーに同じリクエストを投げれば誰でも同じ一覧が返る、という前提である。

では会話をまたぐ状態はどう持つか。仕様の答えは「サーバーが発行したハンドルを、通常のツール引数として渡す」である。ログイン後のカーソル、進行中のジョブID、一時ファイルの参照といったものは、プロトコル層ではなくツールのスキーマの中で明示的に扱う。セッションに暗黙で状態を寄せていた実装ほど設計変更が大きくなる。

HTTP GET エンドポイントと resources/subscribe / resources/unsubscribe が廃止され、subscriptions/listen という単一の長寿命POSTレスポンスストリームに統合された。クライアントは受け取る通知の種類（toolsListChanged / promptsListChanged / resourcesListChanged / resourceSubscriptions）を明示的にオプトインし、サーバーは通知に io.modelcontextprotocol/subscriptionId を付けて返す。

注意したいのは、notifications/progress や notifications/message のようなリクエストスコープの通知はこのストリームには流れないという点である。これらは関係するリクエストのレスポンスストリーム上を流れ続ける。進捗通知の受け口を subscriptions/listen に移そうとすると誤る。またログレベルは logging/setLevel が廃止され、リクエスト毎に _meta の io.modelcontextprotocol/logLevel で指定する。このフィールドを含まないリクエストに対してサーバーは notifications/message を出してはならない（MUST NOT）。

ステートレス化に伴い、サーバーからクライアントへ能動的にリクエストを投げる仕組み（roots/list sampling/createMessage elicitation/create）が成り立たなくなった。置き換えが MRTR パターンである。

- サーバーは処理途中で情報が必要になったら InputRequiredResult（resultType: "input_required"）を返し、inputRequests に必要な要求を並べる
- クライアントは inputResponses を付けて元のリクエストを再送する
- 全結果に resultType が必須になり、complete か input_required を必ず名乗る
- 旧仕様サーバーがフィールドを省いた場合、クライアントは complete として扱わなければならない（MUST）

副作用として、notifications/elicitation/complete と URLモード elicitation の elicitationId（いずれも 2025-11-25 で追加）が削除された。再送で結果を知る設計になったため、完了通知と相関IDが不要になったからである。リトライをまたいで相関させたいサーバーは、自前の識別子を requestState に埋める。

コアの外に公式拡張を置く枠組みが入り、ClientCapabilities / ServerCapabilities に extensions フィールドが追加された。experimental だった tasks はコアから外れ、公式拡張 io.modelcontextprotocol/tasks として再設計されている。

- ブロッキングの tasks/result を廃止し、tasks/get によるポーリングへ
- クライアントからの入力用に tasks/update を追加
- tasks/list は削除
- サーバーはリクエスト毎のオプトインなしにタスクハンドルを返せる

長時間処理をコアの機能として実装していた場合は、拡張として capabilities を宣言し直す必要がある。MCPサーバーを実際に組み込む手順はClaude Code × MCP 連携ガイドで扱っている。

OAuth 2.0 / OIDC 周りは、企業のIdP（Entra、Okta等）と素直に繋ぐための実務的な締め直しが入った。

今回の版から機能ライフサイクルと非推奨ポリシー（Active / Deprecated / Removed の3状態、最低12か月の非推奨期間、非推奨機能レジストリ）が正式に導入された。以下は仕様には残るが、新規実装での採用は避けるべきものである。

- 一覧結果のキャッシュ必須化: tools/list 等の結果に ttlMs と cacheScope（public / private）が必須。ポーリング削減のための鮮度ヒント
- ツールの並び順: tools/list は決定的な順序で返すべき（SHOULD）。クライアント側キャッシュとプロンプトキャッシュのヒット率のため
- リクエストヘッダー: Streamable HTTP のPOSTに Mcp-Method と Mcp-Name が必須。ツール引数から独自ヘッダーを渡す x-mcp-header も追加
- SSEの再開機能を削除: Last-Event-ID とイベントIDによる再送は廃止。ストリームが切れたら新しいリクエストIDで投げ直す（MUST）
- エラーコードの整理: -32000〜-32019 は実装定義、-32020〜-32099 は仕様予約。リソース未検出は -32002 から -32602（Invalid Params）へ変更
- スキーマの緩和: inputSchema / outputSchema が JSON Schema 2020-12 の任意のキーワードを許容、structuredContent は任意のJSON値へ
- トレース: _meta の traceparent / tracestate / baggage による OpenTelemetry のトレースコンテキスト伝播を規約化
- ping の削除: 死活監視をプロトコル層に頼っていた実装は代替が必要

- initialize で受け取った情報に依存している箇所を洗い出し、リクエスト毎の _meta 読み取りに置き換えたか
- server/discover を実装したか（MUST）
- Mcp-Session-Id に依存した状態管理を、サーバー発行ハンドル＋ツール引数へ移したか
- tools/list 等が接続ごとに違う結果を返していないか
- ttlMs / cacheScope を一覧結果に付けたか
- 全結果に resultType を付けたか
- サーバー起点リクエスト（sampling / elicitation / roots）をMRTRへ置き換えたか
- タスク機能を io.modelcontextprotocol/tasks 拡張として宣言し直したか
- 通知の購読を subscriptions/listen に移し、進捗通知はレスポンスストリームに残したか
- ログレベルを _meta の logLevel から読む形にし、指定のないリクエストで notifications/message を出していないか
- 認可でクレデンシャルを issuer 単位で保存しているか、iss を検証しているか
- SSE再開に依存したクライアント実装がないか（切断時の再送に切り替える）

非推奨ポリシーで最低12か月の猶予が明文化されたため、Roots / Sampling / Logging を使っている実装が即座に動かなくなるわけではない。一方でステートレス化そのものは互換性のない変更で、resultType の付与や server/discover の実装は新仕様に対応する時点で必須になる。優先順位としては、まずコア（ステートレス化・resultType・server/discover）に対応し、非推奨機能の置き換えは猶予期間内に順次進めるのが現実的である。逆に、これから新規にMCPサーバーを書くなら、最初から非推奨機能に触れない設計にしておきたい。

2026-07-28 版は、MCPを「双方向ステートフルなプロトコル」から「リクエスト/レスポンスのHTTP APIらしいもの」へ寄せる大きな転換である。サーバーレス配置やスケールの容易さと引き換えに、initializeハンドシェイク・セッションID・サーバー起点リクエスト・SSE再開といった前提が消えた。既存実装の移行では、状態をどこに置き直すか（サーバー発行ハンドル）と、サーバーからの問い合わせをどうMRTRに畳み込むかの2点が設計上の山場になる。