メインコンテンツへスキップ
Dev Tools 25分で読める

MCP 2026-07-28仕様リリース｜ステートレス移行の3つの地雷

#MCP#Model Context Protocol#Claude#Claude Code#Anthropic#ステートレス#セッション廃止#SDK移行#AIエージェント

MCPの2026-07-28仕様が正式リリースされ、プロトコルからセッションが消えた。だがステートレス化への移行は、仕様書を読んだとおりには進んでいない。

2026年7月28日の朝、あるエンジニアが npm view を叩いて「想定と違う光景に出会いました」と書いている（出典: Qiita, kai_kou, 2026年7月28日）。MCPのTypeScript SDKが、9つのパッケージに分裂していたからだ。

@modelcontextprotocol/server、/client、/core、/node、/express、/hono、/fastify、/server-legacy、/codemod。すべて v2.0.0 として、日本時間の同日8時55分ごろに一斉公開された。従来の @modelcontextprotocol/sdk は、その6時間前に 1.30.0 が出ていた。

Model Context Protocol（MCP）は、AIエージェントを外部のツールやデータに接続するための標準プロトコルだ。今回の 2026-07-28 仕様はローンチ以来最大の改訂にあたる。基礎から知りたい場合はMCP実践ガイドを先に読んでほしい。6月に書いたステートレス化RC段階の解説記事では「7月28日に何が来るか」を予測していたが、実際に来たものと、来たあとに起きたことは別の話だ。この記事は後者を扱う。

4行でわかる結論
  • 正式リリースは予定どおり2026年7月28日。セッション、initializeハンドシェイク、Mcp-Session-Id ヘッダが消え、Tier 1 SDK（TypeScript・Python・Go・C#）は初日から対応した。
  • 既存サーバーは今日壊れるわけではない。ただし新旧は通信の形式そのものが噛み合わず双方向に非互換で、TypeScriptはパッケージ分裂とNode.js 20以上への引き上げが同時に来ている。
  • 移行で踏まれている地雷は仕様そのものより周辺にある。codemod（コードを自動書き換えする変換ツール）の静かな失敗、CommonJS環境、そしてハンドル管理をサーバー側で自前実装する責任。
  • 運用中のサーバーがあるなら、今日動く必要はない。来週、Node.jsのバージョンとモジュール形式（ESM / CommonJS）だけ棚卸しすれば足りる。
この記事はこんな人におすすめ
  • MCPサーバーを開発・本番運用しているエンジニア
  • Claude CodeやCursorのMCP連携を社内展開しているPM・テックリード
  • AIエージェント基盤の技術選定を担当している方
  • 「うちのMCPサーバーは今すぐ直すべきか」を判断したい方

MCP 2026-07-28仕様の破壊的変更｜セッション廃止とステートレス化の中身

まず何が確定したかを整理する。SEP（Specification Enhancement Proposal）番号は公式の提案番号だ。

変更SEP壊れるもの
セッションとセッションヘッダの廃止SEP-2567Mcp-Session-Id 依存のルーティング、スティッキーセッション、共有セッションストア
initializeハンドシェイクの廃止SEP-2575initialize / notifications/initialized の往復。以後は毎リクエストの _meta からプロトコルバージョンとクライアント情報を読む
Tasksのブロッキング呼び出し廃止SEP-2663tasks/result と tasks/list。tasks/get によるポーリングへ
Roots / Sampling / Logging の非推奨SEP-2577即座には壊れない。最低12ヶ月は維持
HTTP+SSEトランスポートの非推奨SEP-2596同上。Streamable HTTPへの移行が必要

※スティッキーセッションは、同じ利用者の通信を毎回同じサーバーインスタンスに固定して送る仕組み。共有セッションストアはRedis等でセッション状態を全インスタンスから見えるようにする構成を指す。セッションが消えると、この2つが不要になる。

追加された仕組みも押さえておきたい。サーバー起点のリクエストは Multi Round-Trip Requests（SEP-2322）に置き換わった。ツールが途中でユーザーの確認や不足パラメータを必要とするとき、サーバーは resultType: "input_required" を返し、クライアントが inputResponses を添えて呼び直す。接続を握り続ける必要がなくなった。

Mcp-Method と Mcp-Name というヘッダも増えた。ゲートウェイやレートリミッタがJSONボディを開かずに「どのツールのどの操作か」を判定できる。ディープパケットインスペクションが不要になったということだ（出典: Model Context Protocol Blog, 2026年7月28日）。

認可まわりも締まった。RFC 9207による発行者検証で認可サーバーのすり替え攻撃を防ぎ、デスクトップ・CLIアプリのリダイレクト問題を application_type で解決し、動的クライアント登録（DCR）は Client ID Metadata Documents（CIMD）に置き換わる形で非推奨になった。

ステートレス移行で実際に踏んだ3つの地雷

仕様書を読んでいるだけでは見えない部分がある。リリース後2日で報告されている「実際に踏んだ」話を3つ挙げる。

1. TypeScript SDKが9パッケージに分裂し、Nodeの要求が上がった

冒頭の話だ。v2は @modelcontextprotocol/server と /client を軸に、フレームワークアダプタ（express / hono / fastify）が別パッケージに切り出された。ESM前提の設計になり、Node.jsの要求は「>=20」に引き上げられている。

検証した本人の結論は現実的だ。「既存プロジェクトは今日時点で壊れない」。1.x系は残っており、新パッケージのプロトコルバージョン定数はまだ旧仕様のままだったという（同上出典）。つまり急ぐ必要はない。ただしNode 18のまま運用しているサーバーは、移行の日にランタイムのアップグレードも同時にやることになる。ここは工数見積もりに効く。

2. codemodがCommonJSで「成功したふり」をする

公式が用意した @modelcontextprotocol/codemod を実際に走らせた検証がある。ESM形式のサーバーコードでは「Changes: 3 across 1 file(s)」と出て、server.tool() が server.registerTool() に、引数スキーマが z.object() でラップされた形に正しく書き換わった。

問題はCommonJSだった。同じツールを require() を使ったコードに走らせると、変更行数の表示自体が出ず、コードは一切書き換わらず、package.json からは依存パッケージが削除されただけで新パッケージが追加されなかった。そのまま npm install して起動すると Cannot find module '@modelcontextprotocol/sdk/server/mcp.js' で落ちたと報告されている。

検証者はこれを「壊れたことにすら気づけない成功ログ」と表現している（出典: Qiita, kai_kou, 2026年7月）。自動移行ツールの出力を信じず git diff で実差分を見る。今回に限らず、これは守ったほうがいい。

対策は単純だ。codemodは必ずコミット済みのクリーンな作業ツリーで走らせる。差分が意図と違えば git checkout . で戻す。CommonJSのままなら、codemodに任せず手で書き換えるか、先にESMへ移す判断をする。ロールバック手段がある状態で試すかどうかだけで、この地雷は無害化できる。

3. 新旧が双方向に非互換、あるレジストリ運営者は「更新済みは3割」と報告

MCPサーバーのレジストリを運営する開発者が Hacker News で数字を出している。インデックスしている62,726のオープンソースMCPサーバーのうち、30日以内に更新されたものは約3割。そして「新プロトコルは双方向にワイヤ非互換で、多くのサーバー／クライアントがリファクタを必要とする」（HNユーザー punkpeye、出典: Hacker News）。

ワイヤ非互換とは、通信の形式そのものが噛み合わないという意味だ。実害は具体的で、新仕様のクライアントは旧仕様のサーバーに繋がらず、逆も繋がらない。片側だけ更新しても動かない。

残り7割の長い裾野は、当面バージョン橋渡しのプロキシ経由でしか繋がらない。自作サーバーだけ直しても、社内で使っているサードパーティのMCPサーバーが更新されなければ意味がない。棚卸しの対象は自分のコードだけではない。

移行の優先順位（筆者の整理）
  1. 新規に作るサーバーは、特別な事情がない限り最初から2026-07-28仕様で書くのが妥当だろう。
  2. 本番運用中のサーバーは、まずNode.jsのバージョンと ESM / CommonJS を確認する。ここが移行コストの大半を決める。
  3. codemodは使ってよい。ただし出力ログではなく git diff を信じる。
  4. 依存しているサードパーティMCPサーバーの対応状況を先に調べる。自分だけ直しても繋がらない。

ステートレス化が歓迎されている理由｜運用者の本音

ここまで移行の痛みを書いたが、Hacker Newsの反応は全体として好意的だ。特に強い賛意はMCPの基盤を運用している側から出ている。

  • 「セッション状態を保持する必要が、うちのissueやバグのどれだけを占めていたか、とても言い表せない」（punkpeye）
  • 「セッションを扱うためのサーバー側の複雑さは、インフラにもチーム教育にも大きな負担だった」（btbuilder）

（いずれも出典: Hacker News、翻訳は筆者）

痛みの正体はわかりやすい。ステートフル時代の典型的な障害はこうだ。ポッドAが initialize を処理してセッションIDを発行する。ところがSDKが張る長命のSSEストリームがロードバランサーでポッドBに飛ぶ。ポッドBはそのセッションを知らないので404を返す。ネットワーク障害にしか見えないこの現象のデバッグに、チームが何日も溶かす（出典: Stacktree, 2026年7月）。

ステートレス化でこれが消える。どのインスタンスがどのリクエストを処理してもよく、素のラウンドロビン（順番に均等に振り分ける方式）で水平スケールでき、サーバーレスやエッジにも置ける。共有ストアもスティッキールーティングもいらない。

規模の話も添えておく。Tier 1 SDK合計で月間5億回近いダウンロード、TypeScriptとPythonは累計10億回を突破した。観測性ツールのHoneycombでは、月間のインタラクティブクエリの約2割がすでにエージェント発だという（出典: Model Context Protocol Blog, 2026年7月28日）。趣味の実験の話ではなくなっている。

Claude製品側の対応状況

Anthropicは同日、Claude側の対応を告知した。表現は「Claude製品全体に順次展開する」で、7月30日時点では展開の途中だ。

コネクタディレクトリには950以上のMCPサーバーが登録済み。新機能として案内されているのは4つある。会話の中にサーバー側UIを描画する埋め込みUI（MCP Apps）、EntraやOktaといったIdPから管理者がコネクタを配布する管理者認証、公開済みコネクタの利用状況が見える可観測性ダッシュボード、そして公開せずにプライベートなMCPサーバーへ繋ぐMCPトンネル（リサーチプレビュー）だ（出典: Claude by Anthropic, 2026年7月28日）。

Tier 1以外のSDKには時間差がある。リードメンテナーはHNで「Java SDKはTier 2で、実装まで最大6ヶ月の猶予がある」と回答している（HNユーザー somnium_sn、同上出典）。Rust SDKはベータ対応。JVM中心のチームは、この6ヶ月を前提に計画を組むことになる。

ベンダー側の動きも早い。GitHubは最終公開の5日前に対応を発表したと報じられており、Redisベースのセッションを廃止し、セキュリティスキャンもディープパケットインスペクションから新ヘッダ方式に切り替えたという。AWS、Cloudflare、Google Cloud、Microsoft、Netlifyなども実装を表明している（出典: Vindler Blog, 2026年7月）。

増えたリスク：安全性の責任がサーバー実装者に移った

自分のMCPサーバーがハンドルを発行しているなら、この節は飛ばさないでほしい。歓迎一色ではない。Akamaiのセキュリティ研究チームが、ステートレス化に伴う実装レベルのリスクを指摘している。

要点はハンドルだ。セッションが消えた以上、複数回の呼び出しをまたぐ状態はサーバーが発行する識別子で繋ぐしかない。この識別子が推測可能だと、他人のワークフローの乗っ取り、別エージェントの情報へのアクセス、テナントをまたいだ不正操作が成立しうる。安価にタスクを大量生成できる点はDoS（サービス妨害攻撃）の入口にもなる。

同チームの表現を借りれば、「重要なセキュリティ境界が、開発者がそれをどう実装するかに完全に依存するようになった」（出典: Akamai Security Research）。クロステナントのアクセス制御も、シークレット管理も、権限昇格の防止も、プロトコル層では強制されない。

PMとしての理解では、これは仕様の欠陥というより責任分界点の移動だ。認可の標準準拠は明確に前進した。一方でセッションという「暗黙のスコープ」が消えた分、スコープを自分で定義しなければならなくなった。MCPサーバーのレビュー観点を書き直す必要がある。MCPを踏み台にしたエージェント乗っ取りの事例はすでに出ている。

批判もある。「MCPが最初からアンチパターンの塊だったのは明らかで、彼らはその間違いを少しずつ元に戻している」（HNユーザー progbits、同上出典）。運用面では別の不満も出た。「MCPのリリースはsemverを使っていない。これはかなり異例で、追いかけるのがとても難しい」（HNユーザー closetheloopdev、同上出典）。日付文字列のバージョニングは、依存関係の自動更新とは相性が悪い。この指摘には共感する。

自分ならどう動くか

MCPサーバーを社内向けに運用している立場を想定して書く。結論は「来週やる。今日ではない」だ。

今日でない理由は単純で、既存の1.x系が動いており、Claude側の展開も途中だからだ。展開が終わる前に片側だけ新仕様に振ると、壊れたときの切り分けが難しくなる。慌てて移行して深夜に呼び出される価値はない。

来週やる理由は3つある。第1に、新旧が双方向に非互換なので、対応クライアントが増えるほど接続不能の組み合わせが増える。後になるほど痛い。第2に、TypeScriptのパッケージ分裂とNode 20要求は、時間が経っても勝手に楽にならない。第3に、Tier 1 SDKが初日から揃っている今は、10週間のRC検証期間を通った直後で情報が最も濃い。移行記事もcodemodの落とし穴も、いま出揃っている。

具体的な最小の一歩を書く。まず node -v と package.json の "type" を見る。Node 20以上でESMなら、codemodを走らせて git diff を読む。ここまで30分で終わる。Node 18かCommonJSなら、それは移行ではなくランタイム更新の案件として別に見積もる。混ぜると失敗する。

わからないこともある。Claude製品側の展開がいつ完了するのかは公表されていない。旧仕様のクライアントがいつまで残るのかも、12ヶ月の非推奨期間があるのは Roots・Sampling・Logging と HTTP+SSE についてで、ステートレス化そのものには明示的な期限がない。ここは公式のリリースノートを追い続けるしかない。

まだMCPを導入していない立場なら、判断は逆になる。旧仕様の設計を今から採用する理由はなく、最初から2026-07-28仕様を前提に選定すれば移行という論点そのものが発生しない。この改訂は新規導入のハードルを下げている。むしろ気にすべきは情報の鮮度で、initializeハンドシェイクやセッション前提で書かれた設計書や提案が出てきたら、旧仕様ベースかどうかを確認したほうがいい。

社内に一行で共有するなら「運用中のMCPサーバーは今週中にNodeとモジュール形式だけ棚卸し。移行本体は来月の計画に入れる。新規導入は新仕様前提で進めて問題なし」で足りる。

MCPで実際に何ができるかを押さえたいなら

仕様の変遷を追う前に、MCPで何が繋がり何が自動化できるのかを基礎から。サーバーの選び方と最初の1本の作り方まで、実務目線でまとめている。

MCP実践ガイドを読む

関連記事

本記事の情報は2026年7月30日時点のものです。MCP仕様・SDK・各社の対応状況は変動するため、最新情報は公式仕様および各社の発表をご確認ください。英文資料からの引用はいずれも筆者による翻訳で、要約を含みます。正確な文言は各出典の原文をご確認ください。本記事は一般的な情報提供を目的としたものであり、特定の技術選定やセキュリティ対策を保証するものではありません。本記事は言及した各社との商業的関係を持たない独立した立場から執筆しています。Claude、Anthropicは Anthropic PBC の商標です。その他、本記事に記載の会社名・製品名・サービス名は各社の商標または登録商標です。

Share