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

MCPの仕様には、いま廃止に向かっている機能を1ページで確認できるDeprecated Featuresというレジストリがあります。2026-07-28リビジョンでここに載っているのは6件です。対象はRoots・Sampling・Logging・Dynamic Client Registration(DCR)の4機能。加えて、SamplingのincludeContextの一部の値と、HTTP+SSEトランスポートが載っています。

仕様上、Deprecatedの機能は仕様に残ったまま、新規実装は採用すべきでない(SHOULD NOT)扱いです。既存実装は「削除可能になる最短時期」までに移行するのが望ましい(SHOULD)とされています。ただしこの時期は削除の日付ではありません。読み違えやすい点は後半で扱います。

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

このレジストリは、機能ライフサイクルと非推奨化ポリシー(SEP-2596)のもとで「Deprecated」状態にある機能の一覧です。ページ自身が「派生ビュー」と名乗っており、規範となる記録は機能ごとの非推奨通知とリビジョンごとのchangelogにあります。3状態のライフサイクルと12ヶ月ルールの詳細はMCPの機能ライフサイクルポリシーにまとめています。

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

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

Deprecatedセクションの表は「機能」「非推奨化したSEP」「非推奨になったリビジョン」「移行先」「earliest removal(削除可能になる最短時期)」の5列です。

Roots・Sampling・Loggingは何を置き換えられたのか

3つは同じSEP-2577で、同じ2026-07-28リビジョンにまとめて非推奨になりました。changelogによれば、3つは非推奨期間中も完全に動作しますが、新規実装は対応を足すべきではないとされています。

同じリビジョンには、周辺の変更が重なっています。roots/list・sampling/createMessage・elicitation/createは、Multi Round-Trip Requests(MRTR)に置き換わりました。サーバー起点のリクエストをまとめた置き換えです(詳しくはMRTRの解説)。サーバーがInputRequiredResultを返し、クライアントがinputResponses付きで元のリクエストを再送する形です。Elicitationの扱いはフォームモードとURLモードの使い分けで扱っています。

さらにinitialize/notifications/initializedのハンドシェイクが廃止されました。各リクエストは_metaにプロトコルバージョンとクライアントのcapabilitiesを載せます。ping・logging/setLevel・notifications/roots/list_changedも削除されています。Loggingの旧来のやり取りと現在の形は次のとおりです。

6件の移行先と、実装の書き換え方

Rootsは、クライアントが「このディレクトリ/ファイルが作業に関係する」とサーバーに伝える機能です。アクセス制御ではなく、サーバーが範囲を強制される仕組みでもありません(非推奨の経緯とタイムライン)。移行先は、ツール呼び出しの引数やリソースURI、サーバー自身の設定ファイルで対象パスを渡す形です。

Samplingは、サーバーがクライアント経由でLLMを呼び出す機能でした(Samplingの非推奨化)。Samplingでは、サーバーはAPIキーを持たずにクライアント経由でモデルを呼べました。移行先は「LLMプロバイダーのAPIと直接統合する」で、サーバーがプロバイダーのAPIと直接つながります。

Loggingの移行先は、stdioトランスポートならstderrへの出力、可観測性にはOpenTelemetryです。

DCR(RFC 7591)は、認可サーバーへクライアントを動的登録する仕組みです。移行先のClient ID Metadata Documentsは、クライアントが自分の身元情報をURLで公開し、事前登録なしで認可サーバーが検証できる方式です。DCRはClient ID Metadata Documentsに対応していない認可サーバーとの後方互換のために残されます。

クライアント登録の選び方は、認可の仕様で次の順に定められています。

1. 事前登録済みのクライアント情報を使う
2. 認可サーバーがclient_id_metadata_document_supportedで対応を示していれば、Client ID Metadata Documentsを使う
3. 認可サーバーがregistration_endpointを持つなら、フォールバックとしてDCRを使う
4. どれも使えなければ、ユーザーに入力を求める

DCRは現行の仕様でも3番目の手段として残っています。

includeContextの"thisServer"/"allServers"とHTTP+SSEは、2026-07-28より前に非推奨とされていました。SEP-2596が、この2件をDeprecatedへ再分類しています。前者は2025-11-25リビジョンから、後者は2025-03-26リビジョンからです(HTTP+SSEの経緯)。includeContextを送っている実装は、フィールドを削るか値を"none"に変えれば移行できます。クライアントがsampling.contextcapabilityを宣言していない限り、この2つの値は使ってはいけない(SHOULD NOT)とされています。

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

「削除可能になる最短時期」は削除日ではない

表のearliest removal列を「この日に消える」と読むと誤解します。レジストリは、この時期を機能が削除の対象になり得る時期と説明しています。実際の削除は、Core Maintainerがリビジョン準備の中で判断します。ポリシーには、Deprecatedのまま最短期間よりずっと長く残ってもよいとも書かれています。

計算の基準は機能ごとに異なります。Roots・Sampling・Logging・DCRの4つは、ポリシーが定める最小12ヶ月の期間を、非推奨になったリビジョン(2026-07-28)のリリースから数えた日付が起点です。HTTP+SSEだけは「SEP-2596がFinalに達してから3ヶ月後」と、別の基準が使われています。includeContextの2つの値はSamplingに追随します。changelogは、これらの値がSampling本体より遅れずに削除されると書いています。

6件を同じスケジュールとして扱うと、日付を読み違えます。

4機能の12ヶ月は動かせないわけでもありません。versioningのページは、最短期間を12ヶ月以上、緊急削除の例外では90日以上としています。ポリシー側によれば、短縮できるのは公開済みのセキュリティアドバイザリや実際の悪用があり、その場で緩和する手段が無いときです。短縮にはCore Maintainerの承認が要り、非推奨化のSEPか、短い緊急削除のSEPに記録されます。

逆向きの動きもあります。Deprecatedの機能は、非推奨化のSEPを置き換えるSEPによってActiveに戻せます。あとで再び非推奨になれば、最小期間はその時点から数え直されます。移行先は、非推奨になるのと同じリビジョンでActiveでなければなりません。表の日付は、SEPによって延びたり戻ったりする前提の目安です。

SDKの対応は仕様の削除とは別に進む

レジストリは仕様側の状態を示すもので、使っているSDKがそれを反映しているかは別です。ポリシーによれば、仕様から機能が削除されても、SDKが自分のリリースから外す義務はありません。その時期はSDK自身のリビジョンサポート方針で決まります。

義務の範囲も分かれています。非推奨のリビジョンがCurrentになったあと、Tier 1 SDKは次のリリースで該当APIに言語ごとの非推奨マーク(@deprecatedなど)を付ける必要があります(MUST)。実行時の警告は「出すのが望ましい」(SHOULD)の扱いです。つまり警告が出ないことは、非推奨でないことの証拠になりません。

依存の棚卸しと、設計時の判断

新しいサーバーやクライアントを設計するときは、表の6件を新規に採用しない、が判断の中心です。既存実装をリビジョンに追従させるときは、次の順で当たると抜けが出にくくなります。

自作サーバーを配布する立場ならMCPサーバー自作ガイド、Claude Codeでの扱いはMCPの実践ガイドが入口になります。DCRの移行先が絡む認証周りはリモートMCPのOAuth認証で、リビジョンごとの変化はMCP仕様のバージョン履歴で追えます。