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

MCP仕様のバージョン2026-07-28で、Rootsが非推奨(Deprecated)に指定されました。Rootsは今日から使えなくなるわけではありません。仕様上は最低12か月残り、実際に消えるとしても2027-07-28以降のリビジョンからです。Claude Codeはむしろここ数バージョンでRootsの実装を強化したばかりで、今すぐ影響を受けるユーザーはいません。ただしMCPサーバーを自作している人は、新規実装でRootsに依存しない設計へ切り替える判断が必要になります。

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

Rootsは、MCPクライアントがサーバーに対して「このディレクトリ・ファイルが作業対象です」と伝えるための仕組みです。サーバーはroots/listリクエストでクライアントから一覧を取得し、file://形式のURIと表示用のnameを受け取ります。

Rootsはアクセス制御ではありません。公式仕様は「サーバーの操作範囲を絞り込むための情報提供であり、アクセス制御の仕組みではない。プロトコルはサーバーがRootsの範囲内に留まることを強制しない」と明記しています。つまりRootsを実装しても、悪意あるサーバーがルート外のファイルを読むのを防ぐ効果はありません。あくまで「協調的なサーバー」への手がかりです。

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

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

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

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

仕様のSecurity Considerationsは、クライアント側に「適切な権限のRootsだけを公開する」「パストラバーサル対策としてURIを検証する」「アクセス制御を実装する」ことを要求し、サーバー側には「Rootsの境界を尊重する」「渡されたパスをRootsと照合して検証する」ことを求めています。裏を返せば、この検証と尊重を両者が正しく実装して初めて境界として機能する仕組みで、仕様自体は強制していません。実装ガイドラインでも「クライアントはRoots公開前にユーザーへ同意を求めるべき」とSHOULD止まりで、MUSTではありません。

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

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

非推奨化はSEP-2577(タイトル: Deprecate Roots, Sampling, and Logging)で決まりました。提案者のモチベーションはコアコントリビューター会議での判断で、3機能に共通する評価軸は「実装の複雑さに対して採用率が低い」ことです。

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

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

移行先は3つ: ツール引数でディレクトリ・ファイルを渡す、リソースURIで参照する、サーバー設定(起動時の環境変数やコマンドライン引数)で決め打ちする、のいずれかです。いずれも「サーバーがどこを見るか」をRootsという専用プロトコルではなく、既存の仕組みで表現し直すことになります。

同じSEPでSamplingとLoggingも非推奨になりました。Samplingは「人間の承認・モデル選択・セキュリティを含めた実装の複雑さに対してクライアント側の採用が少ない」、Loggingは「stderrやOpenTelemetryと役割が重複している」という理由です。3機能に共通するのは、いずれも「クライアントがサーバーの代わりに何かをする」双方向の仕組みだった点です。

廃止までのタイムライン

猶予期間中はプロトコルの通信仕様そのものは変わりません。非推奨は「エコシステムに廃止への準備を促す通知」であり、既存のRoots実装が今日壊れることはありません。SDKには言語ごとの非推奨マーカー(TypeScriptの@deprecated JSDoc等)を付ける義務がありますが、機能自体の削除とは別の話です。

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

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

この挙動自体、比較的最近まで不完全でした。v2.1.203より前のClaude Codeは、roots/listが起動ディレクトリしか返さず、notifications/roots/list_changedも送っていませんでした。つまりClaude CodeがRootsをきちんと実装したのは、MCP仕様がRootsを非推奨にするのとほぼ同じタイミングです。

MCPサーバー側でファイルアクセスを絞りたい場合、Claude CodeはCLAUDE_PROJECT_DIRという別の手段も提供しています。こちらはプロジェクトのルートを指す安定した値で、セッション中に作業ディレクトリを追加・削除しても変わりません。

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

公式ドキュメントは「作業ディレクトリの集合に自分のファイルアクセスを合わせたいサーバーはroots/listを実装すべき」としつつ、CLAUDE_PROJECT_DIRはそれとは別の安定参照として案内しています。両者の使い分けは、動的に増減する作業ディレクトリ全部を追いたいか(roots/list)、プロジェクトの起点1つだけあれば足りるか(CLAUDE_PROJECT_DIR)で決まります。.mcp.jsonのプロジェクトスコープ設定でこの変数を${CLAUDE_PROJECT_DIR:-.}のようにデフォルト付きで参照する書き方も用意されています。

RootsとSampling、Loggingが同時に退場する理由

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

移行先を見ると共通点が浮かびます。Rootsはツール引数・サーバー設定へ、Samplingは「LLMプロバイダーAPIに直接統合」へ、Loggingは「stderrとOpenTelemetry」へ。3つとも、クライアントを経由する専用プロトコルをやめて、サーバー側で完結させる方向に寄せています。プロトコルの守備範囲をツール呼び出しの往復に絞り込み、汎用的な双方向チャネルを仕様から外していく判断だと読めます。

Claude CodeがRootsの実装を強化した直後にRoots自体が非推奨になったのは、皮肉というより時間差の産物です。既存仕様への追随と、次の仕様改定への追随は別のサイクルで動きます。Tier 1 SDKやクライアントの実装が仕様の変化に追いつくまでには、実装コストの分だけ遅れが生まれます。

MCPサーバー開発者は何をすればよいか

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

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

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

まとめ

Rootsは2026-07-28の仕様改定で非推奨になりましたが、廃止の最短時期は2027-07-28以降で、今日のサーバー・クライアントが即座に動かなくなるわけではありません。Claude Codeは--add-dirで追加した作業ディレクトリをroots/listで返し、変更時に通知も送る実装を既に持っています。新規にMCPサーバーを設計するなら、ディレクトリ・ファイルの受け渡しはツール引数かサーバー設定に寄せるのが仕様の推奨に沿った選択です。SamplingとLoggingも同じSEPで同時に非推奨化されており、MCPが「クライアントを経由する専用チャネル」から「サーバー側で完結する設計」へ寄せていく流れの一部として見ておくと、今後の仕様改定も読みやすくなります。