MCP Rootsは、AIコーディング環境で「このサーバーにはどのworkspaceを作業対象として見せるか」を伝えるための仕組みです。便利ですが、ここをファイルアクセスの最終防壁だと思うと危ない。2026年6月13日JST時点でMCP specification 2025-11-25と公式docsを確認すると、Rootsはclientからserverへfilesystem rootを伝えるcoordination mechanismであり、OS上の読み書きを自動的に閉じる強制境界ではありません。
この記事では、MCP RootsをAIコーディング環境に入れる前に、workspace境界、server allowlist、OSファイル権限、sandbox、信頼済みserver審査をどう分けるかを整理します。MCP serverの実装チュートリアルではなく、チームや個人開発で「どこまで見せてよいか」を判断するための設計メモです。
3行まとめ
clientがserverへ作業対象のfilesystem rootを伝える
serverが受け付けるpathや操作を必要最小限に絞る
processが実際に読める範囲、書ける範囲を最後に狭める
Rootsは意図共有の層です。強制境界はallowlist、OS権限、sandboxと組み合わせて作ります。
- MCP Rootsは、clientがserverへ作業対象のfilesystem rootを伝える仕組みであり、それだけでファイルアクセスを安全に閉じるものではありません。
- workspaceはrepo単位で狭く切り、server側のallowlist、OSファイル権限、sandboxを別レイヤーとして用意します。
- official MCP serversも参照実装として審査し、source、version、起動引数、write機能、secret handlingを確認してから使います。
この記事でわかること
`roots/list` と `notifications/roots/list_changed` が何を伝えるか
workspace root、server allowlist、OS file permission、sandboxの役割分担
home directoryや親workspaceをrootにしない理由
filesystem serverや外部MCP serverを入れる前に見る項目
API権限の話とlocal filesystem境界の話を分けると、MCP serverの審査が進めやすくなります。
- MCP Rootsでできること、できないこと
roots/listとnotifications/roots/list_changedをどう読むか- workspace root、server allowlist、OS file permission、sandboxの役割分担
- home directoryや広いworkspaceをrootにしない理由
- filesystem serverや外部MCP serverを入れる前の審査観点
- GitHub read-only MCPのようなAPI権限設計との読み分け
前提知識
- 1client / host application
filesystem rootを `file://` URIとしてserverへ公開する
- 2MCP server
対応していればroot listを問い合わせ、作業対象の手がかりにする
- 3Tools / Resources / Prompts
serverがclientへ提供する機能や文脈とは別の概念として扱う
- 4強制境界
OS権限、別ユーザー実行、container、sandbox、read-only mountで作る
Rootsはserverに作業範囲を知らせる情報であり、workspace外の読み取りを単独で止める壁ではありません。
MCPでは、serverがTools、Resources、Promptsなどの機能を出し、clientやhost applicationがそれらをユーザー体験へ接続します。MCPの基本概念を先に押さえたい場合は、公開済みの<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何か：Tools・Resources・Promptsと権限設計</a>を先に読むと、この後の「Rootsはclient側の機能」という切り分けが追いやすくなります。
Rootsは、server featureではなくclient featureです。仕様では、clientがfilesystem rootをserverへ公開し、serverは対応していればそのroot listを問い合わせられます。current specのRootは file:// URIを使います。HTTP APIのscope、GitHubのFine-grained PAT、OAuthの権限とは別の話です。
ここで大事なのは、Rootsが「serverに作業範囲を知らせる情報」であって、「server processがworkspace外を絶対に読めないようにする壁」ではないことです。強制境界は、OSファイル権限、別ユーザー実行、container、sandbox、read-only mountなどで作ります。
MCP Rootsでできることと、できないこと
Rootsはwell-behaved serverが意図した範囲を扱うためのcoordinationです。強制力は別レイヤーで確認します。
Rootsでできるのは、clientがserverに「このfilesystem rootを作業範囲として扱ってほしい」と伝えることです。たとえば、IDEやAI coding hostが /Users/team/app をrootとしてserverへ渡すと、serverはそのworkspaceを対象に検索やファイル操作を組み立てやすくなります。
仕様上、clientは初期化時にroots capabilityを宣言できます。serverは roots/list を呼び、clientはrootの配列を返します。root listが変わる場合は、clientが notifications/roots/list_changed を送れます。root objectには uri と、任意の表示名である name が含まれます。
{
"jsonrpc": "2.0",
"id": 1,
"method": "roots/list"
}返答の例は次のような形です。
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"roots": [
{
"uri": "file:///Users/team/workspace/app",
"name": "App Repository"
}
]
}
}Rootsは作業対象の共有である
Rootsは、AI coding serverに「どのrepoやfolderを見ればよいか」を伝えるには向いています。複数repoを開いているIDE、monorepoの一部だけを対象にしたい作業、docs rootとsource rootを分けたい作業では、serverが無駄な場所を見に行かずに済みます。
根拠
一方で、Rootsはserverが善意に従う前提のcoordinationです。client conceptsでは、Rootsはintended boundariesを伝えるがsecurity restrictionsを強制しない、と説明されています。actual securityはOS permissionsやsandboxingで実現する、という読み方が必要です。
Rootsだけでは安全にならない
次の状態を見て「安全になった」と判断しないでください。
確認項目
| 状態 | それだけでは足りない理由 |
|---|---|
| client UIにworkspace rootが表示されている | server processの実ファイル権限は別問題 |
serverが roots/list に対応している | root境界を尊重するかはserver実装次第 |
| MCP configにpathを書いた | そのpath以外をOSが読めないとは限らない |
| filesystem serverの引数にallowed pathを書いた | symlink、相対path、write機能、実装バグの確認が残る |
| read-only運用と呼んでいる | 書き込みtoolがないか、mountやOS権限でも閉じているかを見る必要がある |
Rootsは事故防止と作業整理には効きます。悪意あるserverや壊れたserver、広すぎるprocess権限を止める最後の壁ではありません。
workspace境界はrepo単位で狭く切る
- 1対象repoを決める
今回の作業対象が `/workspace/app` なら、そのrepoだけをrootにする
- 2親workspaceを避ける
複数repo、過去ログ、dump、`.env` のコピーが同じ範囲に入らないようにする
- 3参照用rootを分ける
docsやsampleが必要な場合は、作業用rootとは別のread-only参照として扱う
- 4write対象を限定する
生成物や修正対象を明示し、隣のrepoへ書き込まない形にする
広いrootは、意図しない文脈混入、情報漏えい、レビュー困難化の原因になります。
AIコーディングでは、親ディレクトリをrootにしたくなります。たとえば /Users/mogir/workspace のような場所に複数repoがある場合、そこを丸ごと見せればserverは横断検索しやすい。しかし、便利さの裏で、隣のrepo、過去の調査ログ、生成物、ローカルDB dump、.env のコピーまで同じ作業範囲に入る可能性があります。
原則は、対象repoをrootにします。今回の変更が /workspace/app だけなら、/workspace ではなく /workspace/app をrootにする。参照したいdocsやsampleが別にあるなら、read-only参照用rootとして分けます。
親workspaceを渡すと隣のrepoまで近づく
広いrootが危ないのは、serverがすぐに悪さをするからではありません。AI coding taskの入力が曖昧な時、serverやagentが「関連しそうなファイル」を探して横へ広がりやすいからです。隣接repoの設計資料、古い障害ログ、顧客名入りfixture、別案件の.env.exampleが候補に入ると、意図しない文脈混入や情報漏えいにつながります。
root候補ごとに、最低限次を確認します。
評価基準
| 確認項目 | 見る理由 |
|---|---|
| 隣接repoがあるか | 別案件や別顧客の情報が混ざる |
| secretやcredentialがあるか | read-onlyでも漏えいリスクが残る |
| write対象がどこか | 生成物や設定変更の出力先が広がる |
| logやartifactの機密度 | 実データ、障害情報、内部URLが入りやすい |
| CIで再現できるか | ローカルだけの広いrootに依存しないようにする |
作業用rootと参照用rootを分ける
書き込み対象のsource rootと、read-onlyで参照したいdocs rootを同じ扱いにしない方が運用しやすくなります。たとえば、app repoはread/write、design-docs-sanitized はread-only、production-dumps は不可視、と分けます。
注意点
参照資料が必要なら、原本をそのままrootに入れるのではなく、再現用に削ったfixtureや公開済みdocsへ落としてから渡します。.env、SSH key、cloud credential、ブラウザprofile、customer log、production DB dumpは、workspace内に置かない前提で考えます。
root listとserver allowlistを別レイヤーで考える
clientからserverへ作業範囲を知らせる合図
serverが実際に受け付けるpathや操作を制限する防御
symlink、相対path、root変更後のcacheなどを含めて検証する
source、version、起動引数、write機能、secret handlingを確認する
root listが狭くても、server側のallowed pathや実装が甘ければ期待した境界にはなりません。
root listはclientからserverへの合図です。server allowlistは、serverが実際に受け付けるpathや操作を絞る防御です。似ていますが、置く場所も効き方も違います。
根拠
official servers repositoryのREADMEでは、reference serversはMCP featuresやSDK usageを示す教育用の参照実装であり、production-ready solutionsとして扱わず、自分のthreat modelに応じたsafeguardsを実装するよう注意しています。また、Claude Desktop設定例としてfilesystem serverに許可pathを引数で渡す例が示されています。これは、Rootsとは別にserver側でallowed pathを意識する発想の手がかりになります。
root listはserverに作業範囲を知らせる
serverはroots capabilityを確認し、対応するclientなら roots/list でrootを取得します。複数rootがある場合、serverがどのrootを対象にするか、root list変更後に古いpathを保持し続けないかを見る必要があります。
チェックする観点は次の通りです。
確認項目
- roots capabilityがないclientでも安全に失敗するか
- rootが複数ある時に対象rootを明示できるか
notifications/roots/list_changed後にcacheを更新するか- 古いrootのpathを再利用しないか
- root URIが
file://として扱われ、HTTP resourceやAPI scopeと混ざっていないか
allowlistはserverが受け付けるpathを絞る
allowlistは、server実装の中で「このpathだけ処理する」と決める層です。filesystem操作なら、入力pathを正規化し、allowed root配下かを確認し、必要ならsymlinkやcase-insensitive filesystemの扱いも見ます。
実務で確認したいポイントは少し地味ですが、ここを飛ばすとRootsの意味が薄くなります。
注意点
| 観点 | 確認すること |
|---|---|
| path正規化 | ../ や余分なseparatorで外へ出ないか |
| symlink | allowed root内のsymlinkが外部secretへ向かないか |
| read/write mode | read-only rootにwrite toolが届かないか |
| file move | チェック後に移動されたfileを処理しないか |
| error message | 許可外pathやsecret pathをログへ出しすぎないか |
この記事では攻撃手順を詳しく扱いません。目的は、防御側がレビュー時にどの項目を見るかを決めることです。
trusted server reviewを省略しない
MCP serverを追加する時は、公式、community、社内製のどれであっても依存ソフトウェアとして審査します。公式reference serverであっても、READMEの注意書き、起動引数、write機能、依存package、version pin、更新履歴を確認します。
最低限の審査票は次の形で十分です。
評価基準
| 項目 | 見る内容 |
|---|---|
| source | 公式repo、registry、社内repo、package名 |
| version | lockfile、commit、tag、更新頻度 |
| 起動引数 | allowed path、read-only mode、network設定 |
| tools | read toolとwrite toolの一覧 |
| logging | path、file名、secretをログへ出さないか |
| secret handling | env var、token、credentialをどう扱うか |
| stop plan | 問題時にserverを無効化する手順 |
外部MCP serverの選定やtool poisoningの観点は、公開済みの<a href="https://ai-dev.blog.mo-gmo.com/mcp-registry-server-selection-oauth-tool-poisoning-allowlist/">MCP Registryからサーバーを選ぶ前に</a>でも整理しています。Rootsの記事では、server選定そのものよりも、filesystem境界と審査の接続に絞ります。
OSファイル権限とsandboxで最後の境界を作る
- 1process user
同じユーザーで起動すると、home配下の多くのfileへ到達できる可能性がある
- 2read-only mount
読む必要がある範囲と書ける範囲を分け、誤更新の被害を狭くする
- 3container / sandbox
serverから見えるfilesystem viewを必要な範囲へ狭める
- 4secretの退避
SSH key、cloud credential、token、browser profileをworkspaceに置かない
Rootsとallowlistが破れた時でも、OS権限とsandboxで読めない、書けない状態を作ることが重要です。
Rootsとallowlistは大事ですが、最後に効くのはprocessが実際に読めるか、書けるかです。同じユーザーでMCP server、AI coding agent、shell、IDEを動かしている場合、そのユーザーが読めるファイルには到達できる可能性があります。
そのため、root設計のレビューでは「許可pathをどう書くか」だけでなく、「serverが壊れてもworkspace外を読みにくいか」を見ます。
同じユーザーで起動すると読める範囲は広い
macOSやLinuxの通常ユーザーでserverを動かすと、そのユーザーのhome配下にある多くのfileへ読み取り権限があります。~/.ssh、cloud CLIのconfig、package manager token、browser profile、社内VPN設定などは、AI coding taskの対象ではないのに同じユーザーから読めることがあります。
チーム導入では、次のいずれかを検討します。
確認項目
- MCP serverを別ユーザーで起動する
- 対象repoを一時workspaceへcheckoutする
- secretをworkspace外かsecret managerへ移す
- read-only mountを使う
- containerやsandboxでfilesystem viewを狭める
- write対象をgenerated directoryなどへ限定する
read-onlyとwrite可を分ける
コード読取、テスト実行、成果物生成、設定変更、secret更新は同じ権限にしません。read-onlyで始めると、失敗しても被害が「読まれた範囲」に寄ります。writeを許すと、誤変更、破壊、差分混入、credential上書き、生成物の肥大化が加わります。
条件
たとえば、source rootはread/write、docs rootはread-only、secret rootは不可視にします。writeを許すなら、差分確認、rollback、review gate、禁止path、生成先の上限を決めておきます。
sandboxはRootsの代替ではない
sandboxは、serverやtoolが想定外に動いた時の被害を小さくする層です。Rootsの代わりではありません。Rootsは作業対象を伝える。allowlistはserver入力を絞る。sandboxはprocessから見える世界を狭くする。この3つは重ねて使います。
最低限の逃げ道テストは、次の観点で行います。
テスト項目
| テスト | 見たい結果 |
|---|---|
| 許可外pathのread | 失敗する。pathやsecretをログに出しすぎない |
| 許可外pathのwrite | 失敗する。空fileも作られない |
| symlink経由の参照 | allowed root外へ出ない |
| root list変更後の古いpath利用 | cache更新または安全な失敗になる |
| secret fileへのアクセス | OS権限やsandboxで見えない |
| network不要時の外部通信 | 外部へ出ない、または明示承認になる |
外部通信の境界はfilesystem境界とは別に設計します。CodexやMCPの外部通信を分ける考え方は、<a href="https://ai-dev.blog.mo-gmo.com/codex-network-access-allowlist-web-search-mcp-security/">Codexにインターネットアクセスを許可する前に</a>が近いです。
導入前チェックリスト
対象repoだけをrootにし、home directoryや親workspaceを丸ごと渡していない
`.env`、SSH key、cloud credential、browser profileがworkspace内にない
filesystem serverの許可pathが対象repoに絞られ、許可外read/writeが失敗する
出力先、承認、差分確認、rollbackの手順が決まっている
server source、version、起動引数、更新方針、logsを確認できる
ひとつでも曖昧な項目がある場合は、Roots導入より先にworkspace整理とsecret退避を優先します。
個人開発でもチーム導入でも、最初の問いは同じです。Rootsを入れるかではなく、Rootsで意図を伝え、allowlistで入力を絞り、OS権限とsandboxで破れにくい境界を作れるか。
個人開発で最低限見ること
Goの条件
- 対象repoだけをrootにしている
- home directoryや親workspaceを丸ごとrootにしていない
.env、SSH key、cloud credential、browser profileがworkspace内にない- filesystem serverのallowed pathを対象repoに絞っている
- write toolがある場合、出力先と差分確認手順が決まっている
- 許可外pathのread/writeが失敗することを試している
- root list変更後に古いpathを使い続けないことを確認している
この時点で、.env が見える、隣のrepoが見える、allowed pathがhome directory、server sourceやversionが追えない、write toolの対象が曖昧、という状態ならNo-Goです。
チーム導入で追加すること
チームでは、個人の注意力ではなく運用で守ります。次の項目をチームのAGENTS.md、MCP設定レビュー、導入runbookに入れておくと、後から判断しやすくなります。
No-Goの条件
| 分類 | チームで決めること |
|---|---|
| server選定 | 公式、community、社内製の採用基準 |
| version | pinning、更新頻度、脆弱性確認 |
| config review | root、allowed path、write tool、env varのレビュー |
| data classification | workspaceに置いてよいデータ、置かないデータ |
| CI | CI上でserverを使うか、使わないか |
| logs | path、file名、エラー、tokenの扱い |
| incident | server停止、token revoke、workspace削除、再発防止 |
AGENTS.mdやチームルールに落とす場合は、禁止操作、承認が必要な操作、テスト手順、最終報告で書くべき証跡まで決めます。MCPやSkillsの依存監査は、<a href="https://ai-dev.blog.mo-gmo.com/codex-skills-third-party-review-mcp-permissions-audit/">Codex Skillsをチームで入れる前に</a>の考え方も使えます。
GitHub read-only MCP記事とどう読み分けるか
どちらもread-onlyなら安全という話ではありません。読める情報の種類と漏れた時の影響を別々に評価します。
このテーマは、既存のGitHub read-only MCP server記事と近く見えます。ただし、見る権限が違います。
| 比較軸 | GitHub read-only MCP | MCP Rootsとfilesystem境界 |
|---|---|---|
| 対象 | GitHub REST API | local filesystem |
| 主な権限 | Fine-grained PAT、GitHub App permission | OS file permission、sandbox、server allowlist |
| allowlist | tool名、endpoint、repo、scope | root path、allowed path、read/write mode |
| 失敗時の被害 | API越しにIssueやrepo情報が読まれる | host上のfileやsecretへ近づく |
| まず見るもの | token scope、API status、endpoint | root list、process user、allowed path、sandbox |
GitHub read-only MCPは、API scopeとtool allowlistの話です。具体的なFine-grained PATやGitHub APIのread-only設計を見たい場合は、<a href="https://ai-dev.blog.mo-gmo.com/typescript-github-readonly-mcp-server-fine-grained-pat-tool-allowlist/">TypeScriptでGitHub read-only MCPサーバーを作る</a>を読む方が近いです。
今回の記事は、ローカルfilesystem境界の話です。Roots、workspace、server allowlist、OS permission、sandboxの組み合わせで、host fileへの到達可能性をどう下げるかを扱っています。
結果
対象repoまたは必要最小限のdocs rootだけを渡している
root listとserver allowlistが同じ範囲を向いている
allowed path外のread/writeが実際に失敗することを確認している
対象path、承認、差分確認、rollbackが決まっている
source、version、起動引数、更新方針、停止手順を確認している
この条件を満たせない場合は、Rootsより先にworkspace整理、secret退避、sandbox設計を進めます。
MCP Rootsは入れる価値があります。AI coding serverに作業対象を伝え、複数workspaceを整理し、well-behaved serverが意図しない場所を見に行く事故を減らせます。
導入してよい状態
ただし、導入判断は「Rootsがあるから安全」ではありません。実務での合格ラインは次の状態です。
評価基準
- rootは対象repoまたは必要最小限のdocs rootだけ
- root listとserver allowlistが一致している
- allowed path外のread/writeが失敗する
- secretやcredentialはworkspace外、またはOS/sandboxから不可視
- write toolは対象path、承認、差分確認、rollbackが決まっている
- server source、version、起動引数、更新方針をレビュー済み
- 問題時にserverを止め、設定を戻せる
この条件を満たせない場合、Rootsは入れずに、まずworkspace整理、secret退避、sandbox設計から始めた方がよいです。
失敗点
Rootsは意図共有であり、server processの読み取り範囲を単独では強制しない
隣接repo、社内docs、過去logs、temporary filesが候補に入る
path validation、symlink handling、write mode、error loggingが曖昧なままになる
reference implementationでも、自分のthreat modelに合わせたsafeguardsが必要になる
公式かどうかは審査の出発点です。source、version、起動引数、許可pathを必ず確認します。
境界を過信する失敗
よくある失敗は、Rootsを設定したこと自体をセキュリティ対策として扱うことです。Rootsはserverが尊重してくれる前提の合図であり、強制ではありません。
注意点
次に多いのは、親workspaceを広く渡す失敗です。AI coding環境の都合で複数repoをひとまとめにすると、taskの文脈が混ざり、意図しないfileが候補に入ります。private repoや社内docsだけでなく、過去のlogs、generated artifacts、temporary filesも含まれます。
server allowlistのレビュー漏れも起きます。MCP configにpathを書いていても、server側のpath validation、symlink handling、write mode、error loggingが甘ければ、期待した境界になりません。
最後に、officialや有名repoのserverを無審査で入れる失敗です。official servers repo自体も、reference implementationsは教育用の例であり、自分のsecurity requirementsに応じたsafeguardsが必要だと説明しています。公式かどうかは審査の出発点であって、免除理由ではありません。
実務で使うなら
- 1. 対象repoを1つ選ぶ
最初は小さい範囲でrootとallowlistの動きを確認する
- 2. secretをworkspace外へ移す
credential、dump、customer logをroot内に置かない
- 3. read-onlyで開始する
許可外read、許可外write、symlink、root変更後cacheを試す
- 4. write toolを個別承認にする
問題がなければ、対象pathと差分確認を決めてからwriteを足す
- 5. チーム導入前に再審査する
server source、version、起動引数、logs、incident時の停止手順を確認する
home directory、親workspace、write可、複数server、auto-approveを同時に入れると、境界の検証が難しくなります。
最初の導入順序
最初の導入は、次の順番が扱いやすいです。
条件
- 対象repoを1つ選ぶ
- secret、dump、customer logをworkspace外へ移す
- rootを対象repoだけにする
- filesystem serverや関連serverのallowed pathを同じrepoへ絞る
- read-onlyで開始する
- 許可外read、許可外write、symlink、root変更後cacheを試す
- 問題なければwrite toolを個別承認にする
- チーム利用前にserver source、version、起動引数、logsをレビューする
この順番なら、Rootsの恩恵を得ながら、失敗した時の被害を狭くできます。逆に、いきなりhome directory、親workspace、write可、複数server、auto-approveを同時に入れると、どこで境界が破れたか分からなくなります。
チーム導入では、設定ファイルだけでなく、人間のレビュー手順も必要です。誰がroot追加を承認するのか。write toolを足す時に何を見るのか。server update時に再審査するのか。incident時に何を止めるのか。ここまで決めて初めて、Rootsは安全運用の一部になります。
セキュリティ・コスト注意
狭いrootはセキュリティだけでなく、調査の再現性とコストにも効きます。
read-onlyでも残る露出
read-onlyでも、秘密が漏れないわけではありません。private repoのIssue、障害ログ、顧客名入りfixture、内部URL、設計メモは、読まれるだけで問題になることがあります。Rootsを狭くしても、serverが読めるroot内にそれらがあれば、AI contextやlogsへ入る可能性があります。
注意点
また、sandboxや別ユーザー実行には運用コストがあります。開発体験は少し重くなり、設定も増えます。それでも、チームでMCP serverを増やすなら、最初から境界を分けた方が後で楽です。後からhome directoryをrootにした運用を小さく戻すのは、だいたい痛い作業になります。
コスト面では、Roots自体に料金はありません。ただし、広いrootを渡すとAI agentが読む候補が増え、検索、要約、tool call、token消費、レビュー時間が増えます。狭いrootはセキュリティだけでなく、調査の再現性とコストにも効きます。
MCPやAI coding toolの仕様更新は速いので、更新通知を追いたい場合は<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">ニュースレター</a>でも新しい検証記事を案内しています。自社のworkspace、allowlist、OS権限、sandboxをまとめて棚卸ししたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/contact/">お問い合わせ</a>から相談できます。
FAQ
なりません。実際の読み取り範囲はOS権限、sandbox、container、server実装、起動引数に依存します
原則は避けます。必要な場合もrootとwrite対象を分ける方がレビューしやすくなります
そのまま使う前提にはしません。README、起動引数、許可path、write機能、version pinを確認します
Rootsはclientが作業範囲を伝える機能、Resourcesはserverがclientへデータや文脈を提供する機能です
Rootsはfilesystemの作業範囲を伝える機能です。API型serverでは別の権限設計も合わせて見ます。
Rootsを設定すればserverはworkspace外を読めなくなりますか？
それだけではなりません。Rootsは意図した作業範囲を伝える仕組みです。server processが実際に読める範囲は、OS権限、sandbox、container、server実装、起動引数に依存します。
複数repoを1つのrootにまとめてもよいですか？
原則は避けます。monorepoのように全体を同時に扱う必要があり、secretや隣接repoが混ざらず、CIとreview gateが整っている場合だけ検討します。複数repoを扱うなら、rootを分け、write対象も分ける方がレビューしやすくなります。
official MCP serversならそのまま本番利用してよいですか？
そのまま本番利用してよい、とは考えません。official servers repoはreference implementationsを教育用の例として説明しており、実運用では自分のthreat modelに合わせたsafeguardsが必要です。README、起動引数、許可path、write機能、version pin、issue、更新履歴を確認します。
RootsとResourcesは何が違いますか？
Rootsはclientがserverへfilesystem上の作業範囲を伝えるclient featureです。Resourcesはserverがclientへデータや文脈を提供するserver featureです。どちらも「読める情報」に関わりますが、向きと責任が違います。
GitHubやSlackのMCP serverにもRootsは関係しますか？
直接のfilesystem境界としては関係しない場合があります。GitHubやSlackはAPI権限、token scope、OAuth、tool allowlist、監査ログを見る領域です。local filesystemを扱うserverでは、Roots、allowed path、OS権限、sandboxを見る比重が上がります。
更新履歴
- 2026-06-13
MCP specification 2025-11-25のRoots、client concepts、security best practicesを確認
- server resources
ResourcesとRootsを混同しないよう、server側のデータ提供機能として読み分け
- official servers repo
reference implementationsとしての位置づけを踏まえ、production利用前の審査を明記
- 需要投稿
指定アカウントの直近72時間投稿は本文根拠に使わず、一次情報を中心に構成
MCPやAI coding toolの仕様は更新が速いため、Roots、allowlist、sandboxの前提は定期的に見直します。
- 2026-06-13: MCP specification 2025-11-25のRoots、client concepts、security best practices、server resources、official servers repoを確認し、AI Dev Lab Japan向けに初版を作成しました。X/Twitterの指定アカウントから直近72時間の信頼できる需要投稿本文は確認できなかったため、本文の根拠には使っていません。
次に読むなら
参照した主な情報源
- https://modelcontextprotocol.io/specification/2025-11-25/client/roots
- https://modelcontextprotocol.io/docs/learn/client-concepts
- https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
- https://modelcontextprotocol.io/specification/2025-11-25/server/resources
- https://modelcontextprotocol.io/docs/learn/server-concepts
- https://github.com/modelcontextprotocol/servers