MCP新仕様、"廃止"の中身を検証

この記事の結論: MCP公式ブログは「Mcp-Session-Idヘッダー廃止」と書いているが、ベータSDKを実際に展開して中身を見ると、該当コードはlegacy: 'stateless' | 'reject'という明示オプションの中に生きたまま残っていた。後方互換は保たれるので急いで移行する必要はないが、うちの依存パッケージが旧sdkか新server/client分割かは今のうちにnpm viewで確認しておく価値がある。

リナ社長（高校生社長のやり手ギャル）× タクヤ（入社3年目）— 今回は、MCP公式ブログが出した2026-07-28仕様のリリース候補と、各言語SDKのベータ公開を追いかけた回。うちはAstro＋Cloudflare Pages/Workersでダイビングログ機能をD1/R2で動かしている実運用があるので、その目線でも見た。（登場人物について）

何が変わるのか

MCP公式ブログの発表によると、2026年7月28日に公開予定の正式仕様に向けて、以下のような変更がリリース候補（RC）として提示されている。

変更点	内容
セッション管理	initialize/initializedハンドシェイクとMcp-Session-Idヘッダーに依存するステートフルな方式から、ステートレスなコア設計への転換
クライアント情報	接続時ではなく、リクエストごとの_metaに載せる方式に変更
Tasks拡張	experimentalから正式extensionへ昇格。旧tasks/listは廃止し、tasks/get/tasks/update/tasks/cancelに統一
認可	OAuth2.0/OIDC整合を強化するSEPが6件反映
非推奨項目	Roots/Sampling/Loggingが12ヶ月以上の正式非推奨期間に入る
後方互換	新クライアントは旧サーバー（2025-11-25仕様以前）に接続するとinitializeハンドシェイクにフォールバックし、相互運用を継続すると明言（SDKベータ告知より）

「ステートレスコア化とか言われても、正直『へー』としか思わないんだけど」とリナ社長は言う。「でもTasksが正式extensionになるのは分かる。長時間かかる処理をtasks/getで後から拾えるようになるのは、うちのミニロトのスペクトル解析みたいな時間かかる解析処理にも効きそうじゃん」

タクヤは「そこは私も気になっていて、旧tasks/listが廃止される点は実装への影響が出ますね。ただ、後方互換が明言されているので、今すぐ書き換えが必要になるわけではなさそうです」と応じる。

ベータSDKを実際に入れてみる

発表を読むだけでは実装の粒度が分からないので、実際にパッケージを取得して中身を確認した。まず旧来の統合パッケージの状態を見る。

$ npm view @modelcontextprotocol/sdk dist-tags
{ latest: '1.29.0' }

@modelcontextprotocol/sdkは今も1系のままで、2.0系はまだ来ていない。一方で、新設されたserver・clientパッケージは別枠で進行していた。

$ npm view @modelcontextprotocol/server versions --json
[
  "2.0.0-alpha.1", "2.0.0-alpha.2", "2.0.0-alpha.3", "2.0.0-alpha.4",
  "2.0.0-beta.1", "2.0.0-beta.2", "2.0.0-beta.3"
]
$ npm view @modelcontextprotocol/client versions --json
[
  "2.0.0-alpha.2", "2.0.0-alpha.3", "2.0.0-alpha.4",
  "2.0.0-beta.1", "2.0.0-beta.2", "2.0.0-beta.3"
]

「これだけでも分かることあるじゃん」とリナ社長。「sdk本体はまだ1系のまま止まってて、server/clientが別パッケージでベータ進んでる。つまりウチが今@modelcontextprotocol/sdk使ってても、まだ本体には来てないから慌てなくていいってことでしょ」

Python側も同様に確認した。

$ pip index versions mcp
mcp (1.28.1)
Available versions: 1.28.1, 1.28.0, 1.27.2, ...

$ pip download "mcp[cli]==2.0.0b1" --no-deps -d ./mcp_test
Collecting mcp==2.0.0b1 (from mcp[cli]==2.0.0b1)
  Downloading mcp-2.0.0b1-py3-none-any.whl (320 kB)
Successfully downloaded mcp

ダウンロードしたwheelを展開してソースを直接見ると、公式ブログのSDKベータ告知で触れられていた通り、旧来ドキュメントで馴染み深かったFastMCPが実際にクラス名として存在しなくなっていることを確認できた。

$ grep -rl "class MCPServer" extracted/
extracted/mcp/server/mcpserver/server.py

$ sed -n '159p' extracted/mcp/server/mcpserver/server.py
class MCPServer(Generic[LifespanResultT]):

$ head -1 extracted/mcp/server/mcpserver/__init__.py
"""MCPServer - A more ergonomic interface for MCP servers."""

「FastMCPからMCPServerにリネームって、地味に既存コードのimport文が全部死ぬやつですよね」とタクヤ。「関数名じゃなくてクラス名の変更なので、置換自体は機械的にできますけど、フレームワーク側のチュートリアルが一斉に古くなるのは面倒です」

「廃止」の実態：Mcp-Session-Idは消えていなかった

ここが今回いちばん確かめたかったところだ。公式ブログの見出しでは「initialize/Mcp-Session-Idヘッダー撤廃」というステートレスコア化が前面に出ている。だがnpm packで実際にTypeScript版のベータパッケージを取得し、中身を展開すると話が少し違って見えた。

$ npm pack @modelcontextprotocol/server@beta
modelcontextprotocol-server-2.0.0-beta.3.tgz

$ tar tzf modelcontextprotocol-server-2.0.0-beta.3.tgz | grep -i worker
package/dist/cfWorkerProvider-Djgwc46-.cjs
package/dist/shimsWorkerd.cjs

$ grep -o "Mcp-Session-Id" dist/index.cjs
（マッチあり。文脈を展開すると:）
"Bad Request: Mcp-Session-Id header is required"

Mcp-Session-Idという文字列は、コンパイル済みコードの中に普通に残っていた。さらにエラーメッセージ全文を見ると、扱い方が明示的にオプション化されていることが分かる。

function createMcpHandler(factory, options = {}) {
	const { legacy, onerror, responseMode } = options;
	if (typeof legacy === "function") throw new TypeError(
	  "The 'legacy' option only accepts 'stateless' or 'reject', not a handler function. " +
	  "To serve 2025-era traffic with your own handler, route in user land with the " +
	  "exported isLegacyRequest(request) predicate in front of a strict (legacy: 'reject') handler."
	);
	...
}

実際の関数定義を見ると、createMcpHandler(factory, options)のoptionsからlegacyというキーを取り出し、そこに関数（自前ハンドラ）を渡すと明示的にエラーになる作りだった。受け付けるのは文字列'stateless'か'reject'のみ。2025年方式（レガシー）のトラフィックを自分のコードで処理したい場合は、legacyオプションにではなく、別途exportされたisLegacyRequest(request)という判定関数を使ってlegacy: 'reject'設定のハンドラの手前でユーザー側のルーティングとして振り分ける、という役割分担になっている。つまり2025年方式のセッションベース通信をどう扱うかを、サーバー実装者にlegacy: 'stateless'またはlegacy: 'reject'という形で明示的に選ばせる設計だ。「廃止」というより「デフォルトの経路から外し、legacyオプションという名前の箱に押し込めた」という方が実装の粒度としては正確だ。

これは公式ブログが嘘をついているという話ではない。仕様変更のアナウンスとしては「ステートレスコアへの転換」で正しい。ただし、そのまとめ方は仕様の見出しの粒度であって、SDKの実装コードの粒度まで降りると、旧方式のコードパスは意図的に残されている、というのが今回、一次ソース2本（仕様RCの発表とSDKベータ告知）とビルド済みコードを突き合わせて初めて言えることだった。

「え、それってつまり『廃止』って言葉、盛ってるってこと？」とリナ社長。

「盛っているというより、抽象度が違うんだと思います」とタクヤ。「仕様書のレベルでは『標準のやり取りからは外れた』のは事実なので。ただ、『消えた』と『デフォルトから外れて選択制になった』は、移行計画を立てる側からすると全然違う情報ですよね」

「そこは同意。うちがもし今すぐ『廃止されるから対応急がなきゃ』って動いてたら、無駄に工数使うところだった」とリナ社長も認める。二人の最初の食い違いは、発表文言をどこまで額面通り受け取るかという一次ソースの読み方の温度差だったが、実装コードという同じ材料を見て着地点は揃った。

自分たちの開発環境への示唆

「で、それウチら（jinbei-lab）の何が変わるの？」とリナ社長が聞く。うちのブログはAstro（^6.3.7）+ Cloudflare Pages/Workersで動いていて、ダイビングログ機能ではCloudflare D1/R2を実際に使っている。だが、jinbei-labは自社製のMCPサーバーは持っていない。今回のRC・SDKベータの発表を受けて、今すぐ着手すべき対応はない、というのが率直なところだ。

ただし1点、見落とせない発見があった。npm packで取得したベータパッケージの中に、cfWorkerProvider・shimsWorkerdというファイルが同梱されていたことだ。これはCloudflare Workers環境向けの実行シムで、新SDKがWorkers上での実行を最初からサポートしていることを示している。

もし将来、jinbei-labがダイビングログAPIのようなCloudflare Workers上のAPIをMCP経由で外部公開したくなった場合、この新SDKは追加の互換レイヤーなしにその実行環境をサポートしている、ということになる。これはあくまで「もしやるなら」の条件付きの話であって、実際にそうした計画があるわけではないが、選択肢として認識しておく価値はある。

「Workers対応が標準で入ってるのはデカいかも」とリナ社長。「うちが今持ってるD1/R2のダイビングログAPI、将来AIエージェントから直接叩けるようにしたいってなったとき、追加のアダプタ探さなくて済むってことでしょ」

「そうですね。ただ現時点でその予定はないので、『入れておくと楽そう』というだけの話です。優先度を上げる理由にはまだならないと思います」とタクヤが釘を刺す。ここは実利で前のめりになりがちなリナ社長と、実装コストの観点で慎重なタクヤとの温度差が出たが、結論としては「今動くものはない、ただし将来の選択肢としては覚えておく」で一致した。

まとめ

MCPの2026-07-28仕様RCとSDKベータは、公式発表の見出しだけを追うと「ステートフル方式は廃止」という強い印象を受けるが、実際にベータパッケージをダウンロードして中身を確認すると、旧方式のコードパスはlegacyオプションという形で意図的に残されていた。仕様書の見出しとSDK実装の粒度は必ずしも一致しない、というのが今回の一次ソース2本＋実行確認からの発見だ。後方互換は明言されているので、jinbei-labとして今すぐSDKを入れ替える必要はない。

持ち帰り: MCP関連のSDKを使っているなら、まずnpm view <パッケージ名> versionsやpip index versions <パッケージ名>を叩いて、自分の依存が旧パッケージ（@modelcontextprotocol/sdkのまま）なのか、新パッケージ（server/client分割のベータ）なのかを確認するところから始めるとよい。

読者のみなさんは、自分のプロジェクトが依存しているMCP SDKのパッケージ名とバージョンを、npm viewやpip index versionsで最後に確認したのはいつだろうか。

参考

• MCP公式ブログ: 2026-07-28 Release Candidate
• MCP公式ブログ: SDK Betas 2026-07-28