MCPの非推奨機能一覧 — Roots/Sampling/Loggingの移行先

MCPの仕様には、いま何が廃止に向かっているかを1ページで確認できるDeprecated Featuresというレジストリがあります。2026-07-28リビジョンの時点でここに載っているのは6件。対象はRoots・Sampling・Logging・Dynamic Client Registration(DCR)の4機能です。加えて、SamplingのincludeContextが取りうる一部の値と、HTTP+SSEトランスポートも含まれます。どれも今すぐ動かなくなるわけではありませんが、移行先が決まっている以上、新規実装がこれから使う理由はありません。

非推奨機能レジストリで確認できること

このレジストリは、機能ライフサイクルと非推奨化ポリシー(SEP-2596)のもとで「Deprecated」状態にある仕様機能を一覧化した派生ビューです。各機能の非推奨通知やリビジョンごとのchangelogが一次情報で、レジストリはそれらと整合するように保守される、という位置づけになっています。このポリシーが定める3状態のライフサイクルと12ヶ月ルールの詳細はMCPの機能ライフサイクルポリシーで扱っています。

ページはDeprecatedとRemovedの2セクションに分かれます。Removedは今のところ空です。このポリシーのもとで実際に削除された機能はまだ1件もありません。Deprecated状態の機能が削除されると、その行がRemovedセクションへ移動し、削除を記録したchangelogへのリンクが付きます。

現在Deprecatedとされている6つの機能

Deprecatedセクションの表は「機能」「非推奨化したSEP」「非推奨になったリビジョン」「移行先」「earliest removal(削除可能になる最短時期)」の5列で構成されています。中身は次のとおりです。

Roots・Sampling・Loggingの3つは同じSEP-2577で、同じ2026-07-28リビジョンでまとめて非推奨になりました。3つとも「クライアントとサーバーの間で往復のやり取りが要る機能」という共通点があり、この設計方針そのものが後退したことを示しています。

Roots・Sampling・Loggingが同時に非推奨になった理由

3つがそろって非推奨になったのは偶然ではありません。Roots(roots/list)もSampling(sampling/createMessage)も、サーバーからクライアントへ一方的にリクエストを送る機能でした。どちらも「サーバー起点の呼び出し」という共通構造を持っています。同じ2026-07-28リビジョンでは、Elicitationも含めたサーバー起点リクエストの扱いが変わりました(フォームモードとURLモードの使い分け)。Multi Round-Trip Requests(MRTR)という別パターンに置き換えられています。サーバーはInputRequiredResultを返して必要な情報を要求し、クライアントは元のリクエストをinputResponses付きで再送する、という形に統一されました。サーバーからクライアントへ一方的にリクエストを送る経路そのものが仕様から縮小されている以上、Roots・Samplingのような「その経路に依存する機能」は居場所を失ったことになります。

Loggingが同じタイミングで非推奨になったのも無関係ではありません。2026-07-28リビジョンではinitialize/notifications/initializedのハンドシェイクが廃止され、プロトコル自体がステートレス化しています。すべてのリクエストが_metaにプロトコルバージョンとクライアントcapabilitiesを載せる、自己完結した設計に変わりました。その結果、セッションをまたいで状態を持つ前提の機能は総じて分が悪くなっています。Roots・Sampling・Loggingの3つを個別の変更として覚える必要はありません。「MCPがステートレスかつクライアント起点の設計へ寄っていく過程で、その流れに逆らう機能から順に非推奨になっている」と捉えるほうが、次に何が対象になるかを予測しやすくなります。

RootsとSampling、Loggingを使っている実装は何に移行すべきか

Rootsは、クライアント側が「このディレクトリ/ファイルを扱ってよい」とサーバーに伝える機能です(詳しい非推奨の経緯とタイムライン)。移行先はシンプルで、ツール呼び出しの引数やリソースURI、あるいはサーバー自身の設定ファイルで対象パスを渡す形にします。プロトコルの往復を1つ減らせるので、実装によってはむしろ単純化になります。

サーバーがクライアント経由でLLMを呼び出すのがSamplingの役割でした。移行先は「LLMプロバイダーのAPIと直接統合する」で、サーバー自身が自分のAPIキーでモデルを呼ぶ構成に切り替えることになります。クライアント側のモデルを間借りする発想自体をやめる移行なので、Roots・Loggingより実装の書き換え量は大きくなりがちです。

一方Loggingは、サーバーからクライアントへログを送る仕組みでした。stdioトランスポートを使っているならstderrへの出力に切り替え、可観測性が必要ならOpenTelemetryを使う、という2本立てが移行先です。どちらも既存のログ基盤にそのまま乗せられる分、3つの中では最も移行コストが低い部類に入ります。

DCR(Dynamic Client Registration、RFC 7591)については事情が異なります。これは認証サーバーへクライアントを動的登録する仕組みで、移行先のClient ID Metadata Documentsは事前登録なしでクライアントの身元情報を検証できる方式です。DCRは後方互換のために当面は使い続けられますが、Client ID Metadata Documentsに対応していない認証サーバーとの組み合わせに限られます。

includeContextの"thisServer"/"allServers"とHTTP+SSEトランスポートの2つは毛色が違います。どちらも2026-07-28より前から実質的に非推奨だった機能を、SEP-2596によって正式にDeprecated状態へ再分類したものです。前者は2025-11-25リビジョンの時点でソフトな非推奨、後者は2025-03-26リビジョンの時点でStreamable HTTPへの移行が案内済みでした。

SamplingリクエストでincludeContextを送っている実装は、フィールドそのものを削るか値を"none"に変えるだけで移行が終わります。

// 変更前(Deprecated)
{ "includeContext": "thisServer" }
 
// 変更後
{ "includeContext": "none" }
// または includeContext フィールド自体を省略

Deprecatedは「今すぐ壊れる」ではない — 削除可能時期の読み方

表の「earliest removal」列を「この日に消える」と読むと誤解します。レジストリの説明文自体が、earliest removalは機能が削除の対象になり得る時期であって、実際の削除はCore Maintainerがリビジョン準備の中で判断する、と明記しています。対象になり得る時期を過ぎても、実装がそのまま残ることは普通にあります。

具体的な計算方法にも注意が必要です。Roots・Sampling・Logging・DCRの4つには共通の基準があります。「非推奨になったリビジョン(2026-07-28)がCurrentとしてリリースされてから12ヶ月以上」が最短の削除可能時期です。表の「2027-07-28以降にリリースされる最初のリビジョン」という表記はこの12ヶ月ルールをそのまま反映したものです。一方でHTTP+SSEトランスポートだけは基準が異なり、「SEP-2596がFinalに達してから3ヶ月後」という短い猶予になっています。HTTP+SSEはすでに1年以上前から事実上の非推奨だったため、と考えられる扱いです。6件を機械的に同じスケジュールと見なすと日付を読み違えます。

includeContextの"thisServer"/"allServers"は、2025-11-25リビジョンの時点で先に非推奨化されました。その親にあたるSampling機能自体が非推奨化されたのは2026-07-28リビジョンで、順序が逆に見える点は見落としやすいところです。機能全体が非推奨になる前に、その機能の一部のオプションだけが先に非推奨になることがある、という実例になっています。レジストリの各行を独立した機能として見るのではなく、親子関係も含めて読む必要があります。

レジストリに載っていても自分の実装にすぐ影響するとは限らない

レジストリはあくまで仕様側の状態を示すもので、自分が使っているSDKやクライアントがその状態を反映しているかどうかは別問題です。機能ライフサイクルを定めたポリシー文書では、仕様から機能が削除されてもSDKがそれをリリースから外す義務までは負わない、とはっきり書かれています。Tier 1 SDKには@deprecatedマークやランタイム警告を出す義務がありますが、その対応がいつのリリースに入るかはSDKごとのリビジョンサポート方針次第です。レジストリを見て「もう使えない」と早合点せず、自分が依存しているSDKのリリースノートやchangelogで、2026-07-28リビジョンへの追従状況を別途確認する必要があります。

サーバー開発者はこのページをいつ見返すべきか

このレジストリを見るべきタイミングは、新しいMCPサーバーやクライアントを設計するときと、既存実装をリビジョン追従で更新するときの2つです。前者では表の6件を新規採用しない、が判断のすべてです。後者では、自分の実装がRoots・Sampling・Loggingのいずれかに依存していないかを棚卸しし、依存があれば移行先への切り替えを計画に乗せます。MCPそのものの仕組みとClaude Codeでの使い方は基礎から解説していますし、自作サーバーを配布する立場ならMCPサーバー自作ガイドも参考になります。DCRの移行先が絡む認証周りはリモートMCPのOAuth認証も合わせて確認しておくと、レジストリの1行が自分の実装のどこに当たるかが判断しやすくなります。