結論：MCP（Model Context Protocol）の仕様は2026年7月28日付で最終版「2026-07-28」が公開され、起動時のinitializeハンドシェイクとセッションIDを廃止する、公開以来最大の破壊的変更が入りました。ただし移行は強制ではなく、Deprecated（非推奨）機能は最短でも2027年7月28日まで動き続けます。Claude Codeに接続している既存のMCPサーバーがいきなり止まることはありませんが、「今すぐ着手すべき点」と「1年かけて計画すればよい点」を区別しないと、対応の優先順位を誤ります。
- 要点1：最大の変更はプロトコルのステートレス化。
Mcp-Session-Idヘッダーとinitializeハンドシェイクが仕様から削除され、リクエストごとに_metaでプロトコルバージョンとクライアント情報を渡す方式に変わった（公式チェンジログSEP-2567・SEP-2575） - 要点2：Roots・Sampling・Logging・HTTP+SSEトランスポート・Dynamic Client Registrationの5つがDeprecated入り。いずれも「最短で2027年7月28日以降」まで動作は保証されており、即座の改修は不要
- 要点3：公式Tier 1 SDK（TypeScript / Python / Go / C#）は発表当日からベータで新仕様に対応済み。Claude製品側の具体的な対応時期はAnthropic公式ブログでも「順次展開」としか書かれておらず、2026年8月時点で明言されていない
対象読者：Claude Code経由でMCPサーバーを自作・運用している開発者、チーム展開の設計をするPM・テックリード
今日やること：自分が運用しているMCPサーバーがRoots・Sampling・Logging・DCR（Dynamic Client Registration）・HTTP+SSEトランスポートのどれかに依存していないか、READMEと実装コードで棚卸しする
2026年7月28日、Model Context Protocolの運営元（Anthropic・OpenAI・Microsoft・Googleなど複数社が参加するステアリング体制）が、プロトコル公開以来もっとも大きい仕様改定を確定させました。変更の核は「セッションという概念そのものをプロトコル層から取り除いた」ことです。これまでMCPサーバーはinitializeハンドシェイクで接続を確立し、Mcp-Session-Idヘッダーでその接続状態を維持するのが前提でした。新仕様ではこの前提が消え、1リクエストごとに完結する設計に置き換わっています。
Claude Codeで.mcp.jsonを書いて外部ツールを繋いだことがある人なら、この変更の実務的な意味が気になるはずです。本記事は公式仕様書・公式チェンジログ・公式ブログを一次情報として、「既存のMCPサーバー実装が今すぐ壊れるのか」「いつまでに何を直せばよいのか」を整理します。2026年8月時点で確認できた事実を基準にしており、確認できなかった点は「未確認」と明記します。
何が変わったか——ステートレス化の中身
公式チェンジログ（modelcontextprotocol.io/specification/2026-07-28/changelog）が挙げる「Major changes」9項目のうち、実装への影響が大きいものは次の3つです。
- セッションの廃止（SEP-2567） — Streamable HTTPトランスポートから
Mcp-Session-Idヘッダーとプロトコルレベルのセッションを削除。サーバー側で呼び出しをまたいだ状態が必要な場合は、明示的なハンドル（トークンのようなもの）をツール引数として渡す設計に変える必要があります - ハンドシェイクの廃止（SEP-2575） —
initialize/notifications/initializedの交換をやめ、すべてのリクエストの_metaフィールドにio.modelcontextprotocol/protocolVersion・io.modelcontextprotocol/clientCapabilitiesを載せる方式に変更。バージョンが噛み合わない場合はUnsupportedProtocolVersionErrorが返ります server/discoverの新設（SEP-2575） — サーバーは対応プロトコルバージョン・機能・identityを返すこの新RPCの実装がMUST（必須）になりました。クライアントは接続前にこれを叩いて、対応バージョンを事前に確認できます
この変更が意味するのは「ロードバランサーの背後にMCPサーバーを何台並べても、どのリクエストがどのインスタンスに着地しても動く」という運用面のメリットです。従来はセッションを維持するために、特定のインスタンスへリクエストを固定する仕組み（スティッキーセッション）や共有ストアが必要でした。新仕様ではこの制約が原則不要になります。
破壊的変更の一覧（旧仕様→新仕様）
| 項目 | 2025-11-25以前 | 2026-07-28 |
|---|---|---|
| 接続確立 | initializeハンドシェイク |
廃止。リクエストごとに_metaでバージョン申告 |
| セッション | Mcp-Session-Idヘッダーで維持 |
廃止。状態が要る場合は明示ハンドルを引数で渡す |
| 変更通知 | HTTP GETの常時接続 + resources/subscribe |
subscriptions/listenへの一本化・型ごとにオプトイン |
| ping・ログレベル制御 | ping / logging/setLevel |
削除。ログレベルはリクエストごとの_meta指定に |
| 長時間タスク | コア機能のtasks/result（ブロッキング） |
拡張io.modelcontextprotocol/tasksに移動。tasks/getでポーリング |
| サーバーからの追加入力要求 | roots/list・sampling/createMessage等の個別リクエスト |
MRTR（Multi Round-Trip Requests）パターンに統一。InputRequiredResultを返し、クライアントは元のリクエストを再送信 |
| SSEの再接続 | Last-Event-IDでメッセージ再送 |
廃止。切断されたリクエストは新しいリクエストIDで再送信 |
| リソース未検出エラー | エラーコード-32002 |
-32602（JSON-RPC標準のInvalid Paramsに統一） |
出典：MCP公式チェンジログ 2026-07-28（2026年8月参照）
Deprecated（非推奨）機能と期限——慌てて全部直す必要はない
「大改定」と聞くと総取っ替えが必要に見えますが、仕様のガバナンス上は最短12ヶ月の非推奨期間が制度化されています（feature lifecycle and deprecation policy・SEP-2596）。Deprecated機能は動き続けたまま、次の一覧の期限まで猶予があります。
| 機能 | Deprecated化 | 移行先 | 削除が有効になる最短時期 |
|---|---|---|---|
| Roots | 2026-07-28 | ツール引数・リソースURI・サーバー設定でディレクトリ/ファイルを渡す | 2027-07-28以降 |
| Sampling | 2026-07-28 | LLMプロバイダーAPIと直接統合 | 2027-07-28以降 |
| Logging | 2026-07-28 | stdioはstderr出力、それ以外はOpenTelemetry |
2027-07-28以降 |
| Dynamic Client Registration | 2026-07-28 | Client ID Metadata Documents（CIMD） | 2027-07-28以降 |
| HTTP+SSEトランスポート | 2025-03-26（今回Deprecatedへ再分類） | Streamable HTTP | SEP-2596がFinalになってから3ヶ月後 |
公式のDeprecated Featuresレジストリによれば、「削除が有効になる」日付はあくまで削除できる最短日であり、実際に削除されるかどうかはコアメンテナーの判断です。2026年8月時点で削除が実行された機能はまだありません。
Claude Code実装者への実際の影響
Anthropic公式ブログ「Bringing MCP 2026-07-28 to Claude」は、ステートレス化・拡張フレームワーク・OAuth/OIDC強化の3点を新仕様の要点として紹介し、「Claude製品全体でのサポートは順次展開される」と書いています。ただし本稿執筆時点（2026年8月）で、Claude Code・Claude Desktop・claude.ai・Agent SDKそれぞれの対応バージョンや具体的なロールアウト時期は、この公式発表内では明記されていません。
Claude Codeの公式リファレンス（code.claude.com/docs/en/mcp）を確認したところ、2026年8月時点で以下が分かりました。
claude mcp listでサーバーごとの接続ヘルス（✔ Connected/! Needs authentication/✘ Failed to connect）を確認できる。仕様移行後に自分のサーバーが正しく動いているかは、まずここで確認するのが実務上の一次チェックになる- Claude Codeは現状、MCPサーバーからのelicitation（追加入力要求）をダイアログ形式で表示する機能を持つ。新仕様のMRTRパターン（
InputRequiredResult方式）への移行時期は、このドキュメント内では明記されていない - HTTP/SSEサーバーが切断した場合、Claude Codeは最大5回・指数バックオフで自動再接続する仕様が既に実装済み。新仕様でSSEの再送機能（
Last-Event-ID）が廃止されたことと、この既存の再接続ロジックがどう整合するかは公式ドキュメントに明記がなく、未確認
つまり「Claude Code側がいつから新仕様のみを話すようになるか」は2026年8月時点で公式に確認できていません。実務上は、自分のサーバーが新旧どちらの仕様でも動くdual-era実装（後述）にしておくのが最も安全な選択です。
改修要否チェックリスト——今すぐ動くべきか、待てるか
すべてのMCPサーバーを同じ優先度で扱う必要はありません。公式の互換性マトリクス（basic/versioning）をもとに、判断フローを整理しました。
| 状態 | 今すぐの対応要否 | 理由 |
|---|---|---|
| Roots・Sampling・Loggingのどれも使っていない | 不要（監視のみ） | 該当機能に触れていなければDeprecation自体が無関係 |
| Roots・Sampling・Loggingのいずれかに依存 | 1年以内に移行計画を立てる | 最短でも2027-07-28まで動くが、代替設計への切り替えには実装工数がかかる |
| Dynamic Client Registrationで認証 | 1年以内にCIMDへ移行を検討 | DCRは後方互換のため残るが、新規実装ではCIMD推奨 |
| HTTP+SSEトランスポートで稼働中 | 優先度高め・計画的に移行 | 2024-11-05時点で既に非推奨だった上、今回Deprecated状態が正式化された |
セッションID・initializeハンドシェイクに強く依存した独自実装 |
設計見直しが必要 | 新仕様のクライアントと会話する場合、セッション前提のロジックがそのままでは通用しない |
公式の「Compatibility Matrix」によれば、旧仕様のクライアント（Legacy）が新仕様のみに対応したサーバー（Modern）へ接続すると失敗します。逆に新仕様クライアント（Modern）が旧仕様サーバー（Legacy）へ接続する場合も失敗で、フォールバック手段を持ちません。両者を橋渡しできるのは、新旧どちらの挙動も実装した「Dual-era」なサーバー・クライアントだけです。自作サーバーを外部に公開している場合、当面はDual-era対応にしておくのが接続断を避ける現実的な選択になります。
SDK別の移行実務
公式ブログ「Beta SDKs for the 2026-07-28 MCP Spec Release Candidate」によれば、Tier 1と位置づけられる4言語のSDKが仕様確定と同時にベータで新仕様へ対応しています。
| 言語 | バージョン | 移行の要点 |
|---|---|---|
| TypeScript | v2（パッケージ名を分割） | @modelcontextprotocol/server・@modelcontextprotocol/clientに分離。ツールスキーマはStandard Schema採用。公式codemod（npx @modelcontextprotocol/codemod@beta v1-to-v2 .）で変換を自動化できる |
| Python | 2.0.0b1 | pip install "mcp[cli]==2.0.0b1"で明示的にピン留めしてインストール。デコレータAPIの形はほぼ維持されるが、FastMCPがMCPServerに改称 |
| Go | v1.7.0-pre.1 | 既存APIの安定性を保ちつつ、StreamableHTTPOptions.Stateless = trueで新仕様へ明示的にオプトインする方式 |
| C# | 2.0.0-preview.1 | 非推奨機能に[Obsolete]属性を付与しつつv1 APIを温存。段階的な移行がしやすい設計 |
共通して言えるのは、「安定版をそのままインストールしても勝手に新仕様に切り替わらない」設計になっている点です。TypeScript v2は新パッケージ名そのものがオプトインであり、Pythonはバージョン固定インストールが必須、Goは明示フラグが必要です。既存サーバーが意図せず新仕様に切り替わって壊れる事故は起きにくい設計ですが、逆に言えば自分で移行の意思決定をしない限り何も変わりません。
移行時に起きやすい詰まりどころ
公式ドキュメントと第三者の技術ブログを横断すると、次のようなつまずきパターンが指摘されています。
❌ 「セッションを前提にしたキャッシュ設計をそのまま残す」
⭕ セッションIDが消える前提で、状態が必要な処理は明示的なハンドル（トークン）をツール引数として渡す設計に作り直す。新仕様のリスト系レスポンス（tools/list等）はttlMs・cacheScopeフィールドを持つCacheableResultに変わっており、クライアント側キャッシュの仕組み自体が変わっている点も合わせて確認する
❌ 「Dynamic Client Registrationをこれからの新規実装に採用する」
⭕ 新規にOAuthクライアント登録を実装するなら、非推奨化されたDCRではなくClient ID Metadata Documents（CIMD）を選ぶ。DCRは後方互換のためだけに残っている
❌ 「HTTP GETでの常時接続やresources/subscribeが今後も同じ形で使えると想定する」
⭕ サーバー→クライアントの変更通知はsubscriptions/listenという単一の長時間ストリームに統一されている。通知の種類ごとにクライアントがオプトインする設計に変わったため、既存の購読ロジックは書き直しが前提になる
❌ 「新旧どちらの仕様で会話しているか確認せずに，そのまま接続を続ける」
⭕ 公式が定義するDual-era実装（新旧どちらの挙動も持つサーバー・クライアント）にしておくか、少なくともserver/discoverで相手の対応バージョンを事前確認する設計にする
今後の見通しと関連記事
仕様のガバナンス上、非推奨機能の実削除には最短でも12ヶ月の猶予があるため、2026年8月時点でこの改定によって既存のMCPサーバーが即座に停止する可能性は低いと考えられます。一方で、TypeScript/Python/Go/C#の主要SDKが発表当日からベータ対応している点は、エコシステム側の移行が想定より早く進む可能性を示しています。Claude Code側の具体的な対応バージョン・時期は今後の公式発表を追う必要があります。
Claude CodeとMCPサーバーの基本的な繋ぎ方や自作サーバーの作り方はClaude Code MCP実践ガイド｜設定から自作までで解説しています。OAuth認証まわりの設計（今回CIMDへの移行対象になったDynamic Client Registrationの前段の話）はMCP認証をClaude Codeで安全にチーム配布で扱っています。またステートレス化によって恩恵を受けやすい「常時稼働のリモートMCPサーバー」をVPS上で運用する実務はClaude CodeをVPSで動かす手順と7つの落とし穴を参照してください。
よくある質問（FAQ）
まとめ：今日から始める3つのアクション
- 今日やること：自分が運用・利用しているMCPサーバーの実装が、Roots・Sampling・Logging・Dynamic Client Registration・HTTP+SSEトランスポートのいずれかに依存していないか棚卸しする
- 今週中：依存が見つかった場合、使っているSDK（TypeScript/Python/Go/C#）のベータ版リリースノートで移行手順を確認し、開発環境で新仕様への切り替えを試す
- 今月中：外部公開しているMCPサーバーがあれば、Dual-era対応（新旧両方の挙動をサポート）にするか、少なくとも接続先クライアントの対応状況をドキュメントに明記する
参考・出典
- Key Changes（MCP公式仕様チェンジログ） — modelcontextprotocol.io（2026年8月参照）
- Versioning and Compatibility（互換性マトリクス） — modelcontextprotocol.io（2026年8月参照）
- Deprecated Features registry — modelcontextprotocol.io（2026年8月参照）
- The 2026-07-28 Specification — MCP公式ブログ（2026年7月28日公開）
- Beta SDKs for the 2026-07-28 MCP Spec Release Candidate — MCP公式ブログ
- Bringing MCP 2026-07-28 to Claude — Anthropic公式ブログ
- Connect Claude Code to tools via MCP — Claude Code公式ドキュメント（2026年8月参照）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
