あなたのMCPサーバー、7月28日に「レガシー」になります
MCP史上最大の破壊的変更が来る。
2026年7月28日、Model Context Protocol の新仕様が確定する。すでにリリース候補（RC）はロック済み。そして今回の変更は、これまでのマイナーアップデートとは次元が違う。
-
initializeハンドシェイクが消える -
Mcp-Session-Idヘッダーが消える - Sampling・Roots・Logging が非推奨になる
つまり、今動いているMCPサーバーの「作法」が根本から変わる。この記事では、何が変わるのか、なぜ変わるのか、そして今やるべきことを全部解説する。
結論から言うと
MCPは「ステートレス」になる。 セッション管理が protocol レイヤーから消滅し、普通のHTTPインフラ（ロードバランサー＋複数インスタンス）でそのままスケールするようになる。代わりに、状態が必要なら「ハンドル」を明示的に受け渡す設計に移行する。
公式SDK（Tier 1）は仕様確定から10週間以内に対応予定。非推奨機能は12ヶ月の猶予期間の後に削除される。今すぐ壊れるわけではないが、移行計画は今から立てるべきだ。
😱 何が消えるのか：Before / After
1. initialize ハンドシェイクの廃止（SEP-2575）
Before（現行：2025-11-25仕様）
Client → Server: initialize（protocolVersion, clientInfo...）
Server → Client: initialize result（capabilities...）
Client → Server: initialized 通知
Client → Server: やっと tools/call できる
After（2026-07-28仕様）
Client → Server: tools/call（_meta にバージョンとクライアント情報を同梱）
いきなり本題のリクエストを投げられる。 プロトコルバージョンとクライアント情報は、毎リクエストの _meta に乗る。往復3回のセレモニーが消えるので、コールドスタートも速くなる。
2. セッションIDの廃止（SEP-2567）
Mcp-Session-Id ヘッダーとプロトコルレベルのセッションが完全に削除される。
これが何を意味するか？
Before： セッションを持つサーバーは「同じインスタンス」にリクエストを送り続ける必要があった（sticky routing）。Kubernetes でスケールさせるには session affinity の設定が必須で、インスタンスが死ぬとセッションも道連れ。
After： どのインスタンスがリクエストを受けてもいい。 ラウンドロビンのロードバランサーの後ろに並べるだけでスケールする。
「じゃあ状態が必要な処理はどうするの？」→ 明示的なハンドルを使う。例えばモデルが create_basket を呼んでIDを受け取り、以降のツール呼び出しでそのIDを引数として渡す。状態は protocol ではなくアプリケーションの責務になる。
3. サーバー→クライアント通信の再設計（SEP-2260 / SEP-2322）
永続SSEストリームでサーバーからリクエストを送る方式をやめて、InputRequiredResult でクライアントに「入力が必要だ」と返す方式に変わる。ステートレス化の要だ。
4. ゲートウェイに優しいヘッダー（SEP-2243）
Mcp-Method と Mcp-Name ヘッダーが追加され、API ゲートウェイがボディをパースせずにルーティングできるようになる。エンタープライズのインフラチームが歓喜する変更。
5. レスポンスキャッシュ（SEP-2549）
ttlMs と cacheScope でツール結果のキャッシュを制御できる。同じ list_files を何度も実行してトークンを溶かす時代が終わるかもしれない。
💀 非推奨になる3つの機能（SEP-2577）
ここが一番影響が大きい人もいるはず。以下の3つが正式に deprecated になる。
| 機能 | 代替手段 |
|---|---|
| Roots | ツールパラメータ or リソースURIで渡す |
| Sampling | LLMプロバイダのAPIを直接叩く |
| Logging | stdio なら stderr、構造化したいなら OpenTelemetry |
12ヶ月間は動き続けるが、新規開発で使うのはやめたほうがいい。
特に Sampling（サーバー側からクライアントのLLMに推論を依頼する機能）を使った「再帰的エージェント」パターンを組んでいた人は、アーキテクチャの見直しが必要だ。
🎨 新機能：MCP Apps と Tasks
破壊だけじゃない。Extensions フレームワーク（SEP-2133)が導入され、公式拡張が2つ出る。
MCP Apps（SEP-1865）：MCPサーバーがUIを持つ
サーバーがインタラクティブなHTML UIを配信し、ホストがサンドボックス化された iframe でレンダリングする。
- ツールがUIテンプレートを事前宣言 → ホストが prefetch・キャッシュ・セキュリティレビューできる
- UI上の操作も、直接のツール呼び出しと同じ監査パスを通る
「ChatGPT Apps vs MCP Apps」の構図がいよいよ鮮明になってきた。チャットUIの中にアプリが住む時代だ。
Tasks 拡張：長時間タスクの正式な作法
2025-11-25 で実験的に入った Tasks は、本番投入の知見を踏まえて拡張として再設計された。
Client: tools/call → Server: タスクハンドルを即返す
Client: tasks/get でポーリング
Client: tasks/update / tasks/cancel で制御
ステートレスモデルと整合する形になったので、「30分かかるデータ処理をMCP経由で投げる」みたいなユースケースが正式にサポートされる。実験版APIを使っていた人は新ライフサイクルへの移行が必須。
🔐 認可まわりも6つのSEPで強化
セキュリティ系の変更も多い。重要なものだけ：
-
SEP-2468: クライアントは
issパラメータの検証が必須に（RFC 9207準拠）。認可サーバーのなりすまし対策 - SEP-2352: クレデンシャルが発行元サーバーにバインドされる。リソースが移転したら再登録が必要
-
SEP-837: Dynamic Client Registration で OpenID Connect の
application_typeを宣言
昨年から続いた「MCPサーバー経由の認証情報漏洩」事件の数々を踏まえると、この hardening は必然の流れ。
📅 タイムラインと「今やるべきこと」
2026-05-21 RC ロック済み ← 今ここ（検証期間中）
2026-07-28 仕様確定
+10週間 Tier 1 SDK 対応完了の目安
+12ヶ月 非推奨機能の削除が可能に
MCPサーバー開発者のチェックリスト
-
セッション依存の確認：
Mcp-Session-Idに依存した状態管理をしているか？ → ハンドルベース設計への移行を計画 - Sampling / Roots / Logging の使用箇所を洗い出す → 代替手段へ
- Tasks 実験版APIを使っているなら、新ライフサイクルへの移行準備
-
ツールスキーマの見直し：JSON Schema 2020-12 がフル対応（
oneOf/anyOf/$refが使える！SEP-2106）ので、無理やりフラットにしていたスキーマを自然な形に戻せる - SDKのバージョン追従：仕様確定後10週間は SDK の動きをウォッチ
利用者側（Claude Code等でMCPを使う人）
基本的には SDK とホストアプリの更新待ちでOK。ただし自作のMCPサーバーを社内配布している場合は、上のチェックリストが自分ごとになる。
🤔 なぜここまで大胆に壊すのか
答えはシンプルで、MCPが「実験」から「インフラ」になったからだ。
セッションフルな設計は、ローカルのstdioでClaudeDesktopに繋ぐ分には問題なかった。しかし企業が数千人規模でMCPゲートウェイを運用し始めると、sticky routing は運用の悪夢になる。
注目すべきはこの一文：
Breaking changes: This release only; future versions designed for backward compatibility
つまり「壊すのはこれが最後。ここで土台を直して、以降は後方互換でいく」という宣言だ。新機能はまず Extensions として出して、安定してから仕様に取り込むガバナンス（SEP-2484）も整った。これは成熟したプロトコルの振る舞いそのものだ。
まとめ
-
7月28日、MCPはステートレスになる。
initializeもセッションIDも消える - Sampling / Roots / Logging は非推奨。12ヶ月以内に移行を
- MCP AppsでサーバーがUIを持ち、Tasksで長時間処理が正式サポート
- 認可は RFC 9207 準拠などで大幅強化
- 破壊的変更は今回が最後になる設計方針
「動いてるからヨシ」で放置すると、1年後に突然死するMCPサーバーが量産される予感がする。逆に言えば、今このRC期間に追従しておけば、エコシステムの最前線に立てるということだ。
この記事が参考になったら、いいね👍と保存📌をお願いします！
あなたのMCPサーバーはセッションに依存していますか？移行の悩みや知見があれば、ぜひコメントで教えてください。次回はMCP Appsの実装ハンズオンを書く予定です！
参考リンク
The 2026-07-28 MCP Specification Release Candidate | Model Context Protocol Blog
The 2026 MCP Roadmap | Model Context Protocol Blog
MCP Specification (Draft)
MCP Specification Changelog