MCPの新バージョン「v2」が、2026年7月28日に確定します。
現在はリリース候補（RC）が公開されています。
そして、海外の開発者コミュニティでは移行準備の話題で持ちきりです。
実際にサーバーを運用している開発者たちの声には学ぶところが多くあります。
ここでは主要な変更点と、現場の温度感を整理していきます。
ステートレス化：スケーリングの悩みが消える
v2最大の変更点は、トランスポートのステートレス化です。
v1では、セッションが状態を持っていました。
そのため、複数レプリカでサーバーを動かすにはスティッキーセッションが必要でした。
中には、コンテキストを保持するためだけにRedisを立てていたという声もあります。
しかも、再起動すればセッションは消えます。
つまり、水平スケーリングとの相性は正直よくありませんでした。
v2ではこの制約がなくなります。
リクエストごとに初期化のハンドシェイクを踏む必要もありません。
ホスティング環境でサーバーを運用してきた開発者ほど、この変更を歓迎しています。
「そもそも自分でステートレスに実装すればいいのでは？」という疑問も出ていました。
しかし、v1のステートフル性はサーバー実装の問題ではありません。
トランスポート層に組み込まれていたのです。
だからこそ、仕様側での変更に意味があります。
ただし「ステートレス」を誤解しないでください
ここで重要な指摘がありました。
トランスポートがステートレスになっても、アプリケーションがステートレスになるわけではありません。
認証コンテキスト、冪等性、タスクの状態。
これらは依然として、どこかで永続的に管理する必要があります。
リフレッシュトークンやサブスクリプションの状態も同じです。
そして、深夜の障害対応はたいていこのあたりから発生します。
ステートレス化は運用を楽にします。
でも、状態管理の責任を消してくれるわけではないんですよね。
この区別を曖昧にしたまま移行すると、後で痛い目を見ます。
Samplingは非推奨に。ただし即削除ではない
もうひとつの大きな変更が、Samplingの非推奨化です。
「もう使えなくなる」と誤解している人が多いようです。
しかし、RCの段階では非推奨であって削除ではありません。
今回のリリースでは引き続き動作します。
さらに、その後1年以内に公開される仕様でも動作は保証されます。
完全な削除には、別途SEP（仕様変更提案）が必要です。
つまり、猶予期間は12ヶ月あると考えてください。
では、なぜ非推奨になったのでしょうか。
議論の中で説得力があったのは、「サーバーは自分のモデル呼び出しに責任を持つべき」という意見です。
クライアント側のモデルを借りる設計では、応答品質をコントロールできません。
また、無数のモデルに対してプロンプトを評価するのも現実的ではないでしょう。
サーバー開発者が自前のモデルを使えば、品質管理も評価もシンプルになります。
実態としても、Samplingを実装したクライアントは少数派でした。
せっかくサーバーに組み込んだのに、対応ホストが少なくて実質的に死んでいた。
そんな体験談もあります。
そして、サーバーからモデルへ働きかけたいケースの多くは、Elicitationsでカバーできるようです。
v2ではElicitationsが複雑なインフラ構成の背後でも使えるようになりました。
この点を喜ぶ声もありました。
なお、非推奨になるのはSamplingだけではありません。
RootsとMCPロギングも同様です。
したがって、新規サーバーでこれらを採用するのは避けましょう。
可観測性はOpenTelemetryへ寄せていく流れになっています。
移行前に確認すべきポイント
議論の中で挙がっていた監査項目をまとめます。
移行を控えている方は、次の観点でコードを洗い出してください。
- セッションIDや初期化ライフサイクルに紐づいた状態がないか
- サーバー起点の通知やリソースのサブスクリプションを使っていないか
- クライアントごとの分離が、暗黙的にセッション依存になっていないか
- 旧バージョンのクライアントに対して、バージョンネゴシエーションとフォールバックが機能するか
- エラーコードをリテラルで判定していないか
最後の項目は見落としがちです。
リソースが見つからない場合のエラーコードが、-32002から-32602に変わります。
そのため、エラーコードをハードコードで比較している箇所は確実に壊れます。
現場の温度感はどうか
反応は割れています。
セッションIDに依存した処理を組んでいたチームは、作り直しを迫られています。
フックがあるから修正は可能。
でも面倒だ。
そんな本音も漏れていました。
セッション初期化のタイミングでキャッシュを仕込んでいたケースもあります。
この場合、その処理を最初のリクエストへ移す対応が必要です。
大ごとではありません。
ただし、やらなければ動きません。
一方で、v1の時点で自力でステートレス化していた開発者もいます。
セッションID周りのボイラープレートを削っていたのです。
「すでに安定しているから、あえてv2に上げない」という判断も、運用の現場ではひとつの答えでしょう。
懸念の声もありました。
v2では、LLMが任意のIDでリクエストを繋ぎ合わせる形になります。
そのため、モデルがIDを扱い損ねることによる新種のセッションバグを予想する人もいます。
実際にどうなるかは、運用が始まってみないと分かりません。
なお、SDKは7月28日の正式リリースまでベータ扱いです。
本番投入の実績を尋ねる声はありました。
しかし、この記事の時点で明確な報告は見当たりません。
焦って移行するより、正式版とSDKの安定を待つのが現実的だと思います。
まとめ
MCP v2の柱は2つあります。
トランスポートのステートレス化と、Samplingの非推奨化です。
ステートレス化は、水平スケーリングの障壁を取り除きます。
ただし、認証や冪等性といったアプリケーションレベルの状態管理は、これまで通りあなたの責任です。
Samplingには12ヶ月の猶予があります。
慌てる必要はありません。
しかし、新規開発でSampling、Roots、MCPロギングを採用するのはやめておきましょう。
移行作業の中心は、セッションに紐づいた状態の洗い出しになります。
また、エラーコードの変更のような細かい罠にも注意してください。
正式リリースは目前です。
自分のサーバーがどこでセッションに依存しているか、今のうちに把握しておきましょう。
それが移行コストを最小化する一番の近道です。
