MCPのRootsが非推奨に — Claude Codeは今どう動くか

MCP仕様のバージョン2026-07-28で、Rootsが非推奨(Deprecated)に指定されました。Rootsは今日から使えなくなるわけではありません。仕様上は最低12か月残り、実際に消えるとしても2027-07-28以降のリビジョンからです。Claude Codeはv2.1.203(2026年7月7日)でRootsの実装を強化しています。非推奨化そのものは通信仕様を変えません。ただし同じリビジョンで、roots/listはInputRequiredResult経由になり、notifications/roots/list_changedは削除されています。MCPサーバーを自作している人は、新規実装でRootsに依存しない設計へ切り替える判断が必要になります。

MCPのRootsは何のための機能だったか

Rootsは、MCPクライアントがサーバーに対して「このディレクトリ・ファイルが作業対象です」と伝えるための仕組みです。サーバーがroots/listでクライアントに一覧を求めると、file://形式のURIと表示用のnameが返ります。uriは現行仕様ではfile://でなければならず、nameは任意です。

クライアントはrootsケイパビリティを宣言したうえで、サーバーからのroots/listに応答します。返す値は複数でも構いません。

{
  "roots": [
    { "uri": "file:///home/user/repos/frontend", "name": "Frontend Repository" },
    { "uri": "file:///home/user/repos/backend", "name": "Backend Repository" }
  ]
}

Claude Codeのようなクライアントがワークスペースのディレクトリ構成をサーバーへ渡す、という使い方が典型でした。

2026-07-28のやり取りは「聞き返し」型になった

2026-07-28のRootsは、セッション開始時の宣言でも、サーバーからの独立したroots/listリクエストでもなく、ツール呼び出し1回の中で完結します。ケイパビリティは各リクエストの_meta(io.modelcontextprotocol/clientCapabilities)に載ります。

2026-07-28のchangelogでは、notifications/roots/list_changedは削除されています。エラー時も、サーバーはInputRequiredResultへの返答を待っていないので、クライアントが初回の呼び出しを失敗メッセージ付きで再送する必要はない、と書かれています。

Rootsをアクセス制御と誤解するとどうなるか

Rootsはアクセス制御ではありません。仕様は、Rootsを、サーバーが注力すべき場所を知らせる情報提供であってアクセス制御の仕組みではない、と位置づけ、サーバーがRootsの範囲内に留まることはプロトコルが強制しないと述べています。悪意あるサーバーがルート外のファイルを読むのを、Rootsは防ぎません。

一方でSecurity Considerationsには、クライアント側に「適切な権限のRootsだけを公開する」「パストラバーサル対策としてURIを検証する」「アクセス制御を実装する」といったMUSTが並びます。サーバー側は「Rootsの境界に従う」「渡されたパスをRootsと照合する」がSHOULDです。実装ガイドラインも、クライアントがRoots公開前にユーザーの同意を求めるのはSHOULD止まりです。

境界のように見えて強制力がない。SEP-2577が指摘した「意味論が曖昧」は、この構造を指していると読めます。ツール引数ならスキーマで型と必須項目を明示できますが、Rootsは情報提供の一覧以上の意味を持たせにくく、実装コストだけが双方にかかっていました。

何が変わったか — SEP-2577がRootsを非推奨にした理由

非推奨化はSEP-2577(タイトル: Deprecate Roots, Sampling, and Logging)で決まりました。3機能は、コアコントリビューターの会議で「実装の複雑さに対して採用率が低い」と判断されたものです。提案には、廃止は仕様バージョンを1年以上重ねてから、通信仕様そのものは変えない助言的な非推奨に留める、という前提も書かれていました。

Rootsについての具体的な指摘は次の1点です。

Roots: Vague semantics, overlaps with tool parameters and server configuration(意味論が曖昧で、ツール引数やサーバー設定と役割が重複している)

仕様の登録簿が示す移行先は3つあります。いずれも「サーバーがどこを見るか」をRootsという専用プロトコルではなく、既存の仕組みで表現し直す方向です。

同じSEPでSamplingとLoggingも非推奨になりました。Samplingは「人間の承認・モデル選択・セキュリティを含めた実装の複雑さに対してクライアント側の採用が少ない」、Loggingは「stderrやOpenTelemetryと役割が重複している」という理由です。

廃止までのタイムライン

非推奨と廃止は別の段階です。仕様のライフサイクル規定では、機能はActive、Deprecated、Removedの3状態を移り、非推奨に指定されてから廃止の対象になるまで最低12か月置くことが求められます。起点は、非推奨を含むリビジョンがCurrentとしてリリースされた日です。versioningのページでは現行のプロトコルバージョンが2026-07-28で、リリース日も同じ2026-07-28なので、この日が起点になります。

「最も早い時点」である点に注意が必要です。仕様は、非推奨のまま廃止されず、最低の12か月よりずっと長く残る場合もあると書いています。逆に短縮できるのは、公開済みのセキュリティ勧告があるなど、実際に悪用されうるリスクがある場合に限られ、それでも非推奨から90日は空きます。Rootsにそのような扱いは付いていません。

SDKへの影響も別の話です。仕様から削除されても、SDKが機能を落とす義務は生じず、各SDKの対応リビジョン方針に従います。Tier 1のSDKには、非推奨を言語ごとのマーカー(TypeScriptの@deprecated JSDocなど)で示す義務があります。

ほかに非推奨の登録簿にある機能

非推奨登録簿には、Rootsと同じ2027-07-28以降の最初のリビジョンが最も早い廃止になる機能として、Sampling・Logging・Dynamic Client Registrationが載っています。HTTP+SSEトランスポートは別の期限です。

サーバーを自作している場合、Rootsだけでなく、これらに依存していないかも同じ機会に洗えます。

Claude CodeはRootsをどう実装しているか

Claude CodeはMCPクライアントとしてroots/listに応答します。返す内容は、セッションの起動ディレクトリに加えて、--add-dir・/add-dir・additionalDirectories設定で追加した作業ディレクトリすべてです。サーバー登録側の設定はclaude mcp addの構文とスコープにあります。ディレクトリの追加・削除があるとnotifications/roots/list_changedを送信し、サーバー側に変更を知らせます。追加されたディレクトリを監査したい場合はDirectoryAddedフックで個別に検知・取り消しができます。

この挙動は比較的最近まで不完全でした。v2.1.203(2026年7月7日)より前のClaude Codeは、roots/listが起動ディレクトリしか返さず、notifications/roots/list_changedも送っていませんでした。Claude CodeがRootsを作業ディレクトリの集合に追随させたのは、MCP仕様がRootsを非推奨にする直前のことです。

作業ディレクトリを追加するフラグは、v2.1.289のclaude --helpでは次のように表示されます。

--add-dir <directories...>   Additional directories to allow tool access to

MCPサーバー側でファイルアクセスを絞りたい場合、Claude CodeはCLAUDE_PROJECT_DIRという別の手段も提供しています。Claude Codeがサーバープロセスの環境に設定する値で、プロジェクトのルートを指します。

// サーバープロセス内で読む(Node.js の例)
const projectRoot = process.env.CLAUDE_PROJECT_DIR;

CLAUDE_PROJECT_DIRはサーバーの環境に置かれる変数で、Claude Code自身の環境変数ではありません。そのため、プロジェクトスコープの.mcp.jsonや~/.claude.jsonのサーバー定義でcommandやargsから参照するときは、${CLAUDE_PROJECT_DIR:-.}のようにデフォルトを付けます。プラグインが提供するMCP設定では、${CLAUDE_PROJECT_DIR}がそのまま置換されるので、デフォルトは要りません。

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

3機能の同時の非推奨化は、単発の整理ではなく方向性の表れだと読めます。Rootsはクライアントの作業ディレクトリをサーバーへ伝える、Samplingはサーバーの代わりにクライアントがLLM呼び出しを仲介する、Loggingはサーバーのログをクライアント経由で流す。いずれも「クライアントがサーバーの機能の一部を肩代わりする」設計でした。

移行先を並べると共通点が浮かびます。Rootsはツール引数・リソースURI・サーバー設定へ、SamplingはLLMプロバイダーAPIへの直接統合へ、Loggingはstderrとオブザーバビリティ基盤(OpenTelemetry)へ。クライアントを経由する専用チャネルをやめ、サーバー側で完結させる向きにそろっています。

MCPサーバー開発者は何を見直すか

新規にMCPサーバーを作るなら、ファイルパスの受け渡しはツール引数かサーバー起動時の設定で設計する選択肢があります。仕様は、新規実装がRootsを採用しないことをSHOULD NOTとして求めています。既存のRoots実装を今すぐ書き換える緊急性はありませんが、次のようなケースは見直しの対象になります。

• Rootsの一覧をアクセス制御の境界として扱っている実装(仕様が最初から否定していた前提です)
• サーバー設定やツール引数で同じ情報を渡せるのに、わざわざRootsを追加実装している設計
• Roots対応の有無が、クライアントごとに機能の差になっている設計

Claude Code向けにMCPサーバーをゼロから書く手順はMCPサーバー自作ガイド、サーバーごとに許可する範囲の考え方はMCPセキュリティガイドで扱っています。ファイルアクセスをRoots任せにせず、ツール引数のスキーマ設計で範囲を明示する発想は、後者の権限設計とそのまま重なります。

まとめ

Rootsを使っているサーバーは、2027-07-28以降の最初のリビジョンまでに、ツール引数・リソースURI・サーバー設定のどれかへ移す段取りを組めば間に合います。Roots自体は情報提供でしかないので、アクセス制御はRootsに期待せず別の仕組みで持たせます。