Claude CodeやMCPサーバーを業務で動かしていると、「2026-07-28の仕様更新で何が壊れるのか」が気になるはずです。結論を先に言うと、廃止されたのは Mcp-Session-Id ヘッダーと initialize ハンドシェイクで、影響範囲は自前実装のサーバーほど大きくなります。この記事では、タイトルにある「確認すべき5つのこと」＝次章で紹介する仕様の変更点5つを軸に、開発者・利用者それぞれが取るべき対応を整理します（後半のチェックリスト表もたまたま5項目ですが、こちらは確認事項を便宜上まとめたもので、タイトルの「5つ」とは別物です）。

出典: Unsplash（Taylor Vick）

2026-07-28、MCPは何が変わったのか

一言でいえば「ステートレス化」です。接続時の initialize / notifications/initialized ハンドシェイクと、Streamable HTTPの Mcp-Session-Id ヘッダーによるプロトコルレベルのセッションが完全に廃止されました（SEP-2575、SEP-2567。SEPはSpecification Enhancement Proposalの略で、MCP仕様に対する変更提案の管理番号です）。出典はModel Context Protocol公式changelogです（2026-08-08時点）。

代わりに、プロトコルバージョン・クライアント情報・ケーパビリティは毎リクエストの _meta フィールド（io.modelcontextprotocol/protocolVersion など）に載せて送ります。公式changelogも「Every request now carries its protocol version and client capabilities in _meta」と説明しています。

これまでのMCP（ステートフル）はどう動いていたか

従来は、クライアントが最初に initialize を送り、サーバーが対応バージョンとケーパビリティを返し、notifications/initialized で合意が完了する流れでした。Streamable HTTPではこの合意結果が Mcp-Session-Id に紐づき、以降のリクエストは同じセッションを参照します。

この設計は自然ですが、サーバー側が接続状態を保持し続けることを前提にします。結果として、複数インスタンスへ分散する際にセッションストア（Redisなど）が必須になり、スケール構成が重くなっていました。

2026-07-28仕様の主要な変更点5つ

1. セッションレス化と _meta への情報移動

Mcp-Session-Id とハンドシェイクが消え、リクエストは1本ずつ自己完結します。必要な文脈は毎回 _meta で運ばれるため、サーバーは「前回の続き」を前提にできません。

2. server/discover の新設

サーバーは新設の server/discover RPCを実装しなければならず（MUST）、クライアントは対応バージョン・ケーパビリティ・アイデンティティを事前に確認できます。呼び出しイメージとしては、クライアントは接続直後に引数なしで server/discover を呼び出すだけでよく、サーバーはその応答一往復で「対応しているプロトコルバージョンの一覧」「サポートするケーパビリティ」「サーバー名やバージョンなどのアイデンティティ情報」をまとめて返します。initialize のような合意形成の往復が不要になり、事前確認だけで済むのがポイントです。STDIO接続では後方互換性のプローブとしても使えます。

3. Multi Round-Trip Requests（MRTR）

roots/list、sampling/createMessage、elicitation/create といったサーバー起点リクエストはMRTRに置き換えられました（SEP-2322）。サーバーは resultType: "input_required" を返し、クライアントは inputResponses を添えて同じリクエストをリトライします。

また、HTTP GETエンドポイントと resources/subscribe / unsubscribe は廃止され、単一の長寿命ストリームで変更を受け取る subscriptions/listen に統合されました。SSEの再開・再送（Last-Event-ID）も削除され、切断時は新しいリクエストIDでの再送信が必要です。

4. Roots・Sampling・Loggingの非推奨化とOAuth強化

この3機能はDeprecated指定になり、最低12ヶ月の移行期間が設けられています（正式な削除日は公式changelogでは明記されていないため、継続確認が必要です）。ログはstderrまたはOpenTelemetryへの移行が推奨されています。

認可面では、認可レスポンスの iss パラメータ検証（RFC 9207。RFCはIETFが策定する技術仕様の文書番号）が義務化され、クライアント認証情報を発行元のAuthorization Serverに紐付けて使い回すことが禁止されました。Dynamic Client Registration（RFC 7591）も非推奨となり、Client ID Metadata Documentsへ移行します。

5. エラーコード再割り当てと CacheableResult の必須化

-32000〜-32019 は実装依存領域として既存利用が経過措置的に容認され、-32020〜-32099 がMCP仕様用に予約されました。これに伴い既存コードの番号が変わっています。

さらに tools/list などのリスト系レスポンスには、ttlMs（キャッシュ有効期限）と cacheScope（public/private）を持つ CacheableResult が必須化され、クライアントや中間プロキシでのキャッシュが仕様として整備されました。

なぜステートレス化するのか｜運用面のメリット

出典: Unsplash（Kevin Ache）

Googleは開発者ブログで、どのサーバーインスタンスでもリクエストを受けられるため通常のラウンドロビン型ロードバランサーの背後に置けると説明しています。特別なスティッキーセッション設定が不要になる点が大きな違いです。

加えて、Cloud RunやCloud Functionsのようなサーバーレス基盤でアイドル時のゼロスケールが可能になり、セッション状態を保持するRedisなどの外部ストアも不要になります。Googleはこの構成変化によって運用がシンプルになる点をメリットとして挙げています。

GitHub MCP Serverはどう対応したか

出典: Unsplash（Scott Rodgerson）

実装側の先行事例として分かりやすいのがGitHubです。GitHub Changelog（2026-07-23）によると、正式仕様の公開前にGitHub MCP Serverが次期仕様への対応を発表しました。

• Redisセッションストアを廃止：初期化時のDB書き込みと呼び出しごとの読み込みがなくなり、パフォーマンスが改善
• ヘッダーベースの処理へ移行：ロギングとシークレットスキャン用の値をHTTPヘッダーから読み取り、ペイロードの深層検査が不要に
• エリシテーションの両対応：Go SDKのラッパーで新旧クライアントの双方に対応

セッションストアを消して、必要な情報をリクエスト自身に持たせる。この考え方は自前サーバーの移行方針としてもそのまま参考になります。

MCPサーバー開発者が今すぐ確認すべきこと【チェックリスト】

なおTypeScript SDKの移行ドキュメントによると、デフォルトは引き続き2025年時代のプロトコル動作を維持し、versionNegotiation オプション（legacy / auto / pin: '2026-07-28'）で明示的にオプトインする設計です。慌てて全面移行する必要はなく、まずバージョン確認から始めるのが現実的です。

利用者側（Claude Codeなどクライアント）が確認すべきこと

サーバーを書かない利用者でも、押さえておくべき点があります。

• 後方互換性の仕組み：後方互換性はフォールバック方式で担保されます。2026-07-28対応クライアントが2025-11-25以前のサーバーに接続すると従来のinitializeハンドシェイクへ自動的に戻り、新サーバーも旧クライアントには従来方式で応答するとされています（The Register の報道による、2026-08-08時点）。
• 両者非対応時のリスク：両者が同じプロトコル時代を共有しない場合や、独自実装がセッション依存のままの場合は接続できない可能性があります。またThe Registerの報道では、実装者にとって作業負担が大きい、仕様が複雑になったという評価も紹介されています（原文の直接引用ではなく間接的な要約情報のため参考程度にとどめてください）。移行はテスト環境で先に確認するのが安全です。
• 利用者が取るべき行動：Claude Codeを含む各クライアントが2026-08-08時点でどのモード（legacy / auto / pin）をデフォルトにしているかは、公式に確認できる情報が限られます。まずは利用中のクライアントの公式リリースノート（changelog）を開き、MCP関連の更新履歴の中に「Mcp-Session-Id」や「2026-07-28仕様」への言及がないか探すのが手掛かりになります。加えて、通信ログやデバッグ出力を見て、Mcp-Session-Id ヘッダーや initialize ハンドシェイクがまだ使われていればlegacyモードのまま、毎リクエストの _meta に protocolVersion が載っていれば新仕様側への移行が進んでいると判断できます。またRoots / Sampling / Loggingに依存したツールを使っている場合は、移行期間のうちに代替手段を決めておきましょう。

まとめ｜今日からできる対応

2026-07-28仕様の核心は、セッションを捨ててリクエスト単位で完結させることです。ロードバランサー配下での水平スケールやサーバーレス運用という明確な利点がある一方、セッション前提の自前実装には書き換えが必要になります。

今日できる最初の一歩は、自チームのMCPサーバーとクライアントが使っているSDKのバージョン確認です。そのうえで Mcp-Session-Id 依存の有無を洗い出し、公式changelogで該当箇所を突き合わせてみてください。