MCP 仕様の大幅改訂：影響範囲の棚卸しと移行スケジュールの立て方

MCP 仕様が大幅改訂、12 か月の移行タイマーはすでに動き始めています

Model Context Protocol（MCP）の公式は 2026 年 7 月 28 日、2026-07-28 仕様版を公開しました。MCP 登場以来もっとも大きな改訂です。プロトコルの中核が「ステートフル・双方向」から「ステートレスなリクエスト／レスポンス」へ変わり、Roots・Sampling・Logging の 3 機能が正式に非推奨となりました。Tier 1 SDK 4 種（TypeScript、Python、Go、C#）も同日に更新され、公式ブログによればこれらの SDK の月間ダウンロード数は合計で 5 億回近くに達しています。影響を受けるのは一部の実験的プロジェクトではなく、すでに本番環境で稼働しているツールチェーン全体です。

意思決定者が問うべきなのは仕様の条文そのものではなく、次の 3 点です。どのシステムが影響を受けるのか、移行にどれだけの工数がかかるのか、いつまでに完了させる必要があるのか。今回は正式な機能ライフサイクル方針も定められ、非推奨機能には最低 12 か月の移行期間が保証されます。朗報ではありますが、同時にタイマーが動き始めたことを意味します。

ステートレス化がインフラコストを削減します

改訂の主軸はプロトコル層のセッション廃止です。initialize ハンドシェイクと Mcp-Session-Id ヘッダーがともに削除され、各リクエストが自らプロトコルバージョンとクライアント機能情報を持つようになりました。従来は MCP 接続がハンドシェイクを処理したサーバーに固定されるため、水平スケールにはスティッキーセッションや共有セッションストアが必要でした。新仕様では、リモート MCP サーバーを通常のラウンドロビン型ロードバランサーの背後にそのまま配置できます。

すでに MCP サーバーを社外や他部門へ公開している企業にとって、これはコストと信頼性の直接的な改善です。スティッキー設定が 1 層減り、共有状態コンポーネントが 1 つ減り、スケール時の接続待避も不要になります。代償として、ストリームの再開はできなくなりました。切断された時点でそのリクエストは無効となり、クライアントは新しいリクエストとして再送する必要があります。長時間処理は公式の Tasks 拡張によるポーリング方式へ移行してください。

セッション廃止だけではない：連携の書き方が変わる 3 つの変更

アーキテクチャ以外にも、既存コードの書き方に直接影響する変更が 3 つあります。1 つ目は MRTR（Multi Round-Trip Requests）です。サーバーはクライアントへ能動的にリクエストを送らなくなり、代わりに input_required の結果で必要な情報を提示し、クライアントが回答を添えて元のリクエストを再送します。すべての結果に resultType フィールドが必須となりました。2 つ目はヘッダーによるルーティングです。Streamable HTTP の POST には Mcp-Method と Mcp-Name ヘッダーが必須となり、ゲートウェイやレート制限は JSON 本文を解析せずにルーティングと認可を行えます。API ゲートウェイをすでに運用している企業にとってはむしろ簡素化です。3 つ目は一覧結果のキャッシュ対応です。tools/list や resources/list などの応答には ttlMs と cacheScope が必須となり、クライアント側でキャッシュしてポーリングを減らし、LLM のプロンプトキャッシュのヒット率も高められます。さらに必須メソッドとして追加された server/discover は、対応プロトコルバージョンと機能を通知し、旧版との互換ネゴシエーションの入口となります。

非推奨となった 3 機能：まず棚卸し、次に計画

Roots・Sampling・Logging は移行期間中は動作しますが、新規実装での採用は避けるべきです。公式が示す移行先は明確です。

• Roots：ディレクトリやファイルの範囲は、ツールパラメータ、リソース URI、サーバー設定で受け渡します。
• Sampling：クライアント経由の推論をやめ、LLM プロバイダーの API を直接呼び出します。
• Logging：stdio では stderr へ出力するか、OpenTelemetry を利用します。

さらに 2 項目が削除予定に入りました。2025 年にソフト非推奨となっていた HTTP+SSE トランスポートは正式に管理対象となり、Streamable HTTP への移行が必要です。OAuth 2.0 動的クライアント登録（RFC 7591）も Client ID Metadata Documents に置き換わります。

認可の強化はセキュリティと監査の追加課題になります

今回の改訂では認可層の実務的な穴も塞がれました。認可サーバーは RFC 9207 に従って iss パラメータを返すべきであり、クライアントは検証したうえで認可コードを引き換える必要があります。動的登録では application_type の指定が必須となり、localhost リダイレクトの悪用を防ぎます。クライアント資格情報は発行した認可サーバーに明示的に紐づくため、変更時は再登録が必要です。すでにセキュリティ審査を通した MCP 連携がある場合、再審査が求められる可能性が高いでしょう。

今日から始められる棚卸しチェックリスト

すべてを一度に書き換える必要はありませんが、棚卸しは 1 か月以内に完了させることをおすすめします。自社構築と外部調達の MCP サーバーがそれぞれ何台あり、誰が保守しているかを把握する。各サーバーが Roots／Sampling／Logging または HTTP+SSE を使っているか確認する。外部ベンダーにアップグレード時期を確認する。ステートフルな設計を、サーバーが発行しツール引数として渡す明示的なハンドルへ置き換える。そして移行を 12 か月以内の運用計画に組み込み、機能が実際に削除されてから動くことのないようにする。

ナードテクニックは、こうしたプロトコル改訂を稼働中のシステムへ落とし込む作業をご支援します。自社構築と外部調達の MCP サーバーの棚卸し、各サーバーが利用する非推奨機能と依存範囲の洗い出しから、ステートフルな設計の書き換え、強化された認可要件への対応、そして移行を 12 か月の運用サイクルへ組み込むところまで一貫して対応します。進め方としては、まずリスクの低いサービスから着手し、拡張とキャッシュの挙動が安定していることを確認したうえで範囲を広げます。見落とされやすい外部ベンダーのアップグレード時期は、最初に確認します。すでに MCP を本番環境で運用しているものの、今回の改訂がどこに影響するか整理できていない場合は、ぜひナードテクニックにご相談ください。仕様改訂を突発的な出来事から、予測可能な運用業務へと変えていきましょう。

参考資料

• Model Context Protocol Blog、《The 2026-07-28 Specification》、2026。出典リンク
• Model Context Protocol、《Key Changes（2026-07-28 Changelog）》、2026。出典リンク
• Model Context Protocol Blog、《Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here》、2026。出典リンク
• Model Context Protocol、《Feature Lifecycle and Deprecation Policy》、2026。出典リンク
• Model Context Protocol、《Deprecated Features Registry》、2026。出典リンク
• The Register、《Model Context Protocol prepares to break with its stateful past》、2026。出典リンク