Filesystem MCPの権限設計｜開くフォルダを絞る3判定

「このフォルダ、AIに見せてしまっていいんでしょうか」。Filesystem MCPをつなぐ話をすると、たいてい最初にこの質問が出ます。

つないだあとの動きは速いです。読むのも書くのも、こちらが確認する間はありません。ところが、どこまで開いたのかは画面のどこにも出ません。開きすぎていたと気づくのは、何かが変わったあとになります。

この記事は、フォルダを渡す前に決めることと、決めた範囲を実際に守らせる場所を扱います。素材は公式リポジトリと公式ドキュメントの記載だけです。自環境へはまだ接続していないため、動かして分かったことは書いていません。確認日は2026年7月29日です。

案内役は3人です。若葉さんが言葉の意味から、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。

01Filesystem MCPの権限設計は、AIエージェントに何を預ける作業なんですか？

若葉さん

若葉さんの発言

Filesystem MCPって、そもそも何をしてくれるものなんでしょうか。

鈴木さん

鈴木さんの発言

建物の入館証に近いと思っています。どの階まで入ってよいかを先に決めて、証を渡す。渡したあとで階を減らすのは、そこそこ面倒です。

Filesystem MCPは、AIにローカルのファイル読み書きを許可する公式リファレンス実装です（出典: MCP公式リポジトリ）。

預けるものは2つあります。どこまで見せるかと、そこで何を変えさせるかです。この2つはひとつの設定でまとめて決まるように見えますが、実際には別々の層が担当しています。見せる範囲を絞っただけでは、その中での書き換えは止まりません。

結論は3つです。

1. 渡すフォルダは事前に3段階へ仕分けます。機密を含むなら渡さない、書き込みが不要なら読み取り専用にする、残りだけを公開します。
2. 読み取り専用は、サーバーの機能だけでは実現できません。Filesystem MCP自体に読み書きを分ける設定が無いためです。
3. 境界の決め方は2通りあり、片方は仕様上すでに非推奨です。起動時のコマンドライン引数と、MCPのRootsプロトコルがあります。後者は2026年7月28日付で非推奨になりました（出典: MCP公式仕様）。

02AIエージェントに開く13のツールは、権限設計のどこを見て選ぶんですか？

何を許可・拒否できるのかを先に把握します。Filesystem MCPが公開するツールは13種類で、うち9種が読み取り専用、4種が書き込みを伴います（出典: 同README、2026-07-29確認）。

読み取り側で見落とされやすいのは、中身よりも構成が見えてしまうことです。ファイル名の一覧だけでも、案件の構成は伝わります。

03読み取りだけのツールでも、Filesystem MCPでAIエージェントに渡すと何が見えるんですか？

読み取り側の9種は、中身を読むものと、構成を返すものに分かれます。後者は本文を1文字も読まなくても、案件の形を伝えます。フォルダ名の並び、階層の深さ、更新の新しさ。渡す範囲を決めるときは、この「本文以外」を見落とさないようにします。

list_allowed_directoriesだけは性格が違います。エージェント自身に「いま何を触れるか」を言わせられる読み取り専用ツールで、権限設計の妥当性を実行時に点検する用途に使えます。

04渡すフォルダの3判定は、AI社員の権限設計でどう当てはめるんですか？

権限設計の起点は、フォルダの中身を見て3段階に仕分けることです。運営元WEBMARKSでは、機密情報をpublic・internal・restrictedの3段階へ分離して扱っています。判定基準そのものはAIエージェントに機密情報を渡さない｜3段階の分離と検査にまとめました。

範囲は案件単位まで絞ります。ホームディレクトリやドライブ全体のように広く渡すと、別案件の機密まで一括で開くことになります。公式のセキュリティ文書も、ローカルMCPサーバーはファイルシステムへのアクセスを制限した状態で起動すべきだと述べています（出典: MCP公式セキュリティ文書）。

05読み取り専用は、Filesystem MCPの権限設計だけでAIエージェントに強制できますか？

高梨課長

高梨課長の発言

読み取り専用にしたいんです。設定ファイルのどこに書けばいいでしょうか。

鈴木さん

鈴木さんの発言

書く場所がサーバー側には無いんです。ドキュメントが示している方法は、フォルダの側を書けない状態にしてから渡す、というやり方でした。

Filesystem MCP自体には、許可フォルダごとに読み取り専用を指定する機能がありません。ドキュメントが示す唯一の実現方法は、Dockerでのroマウントです（出典: 同README）。

{
  "mcpServers": {
    "filesystem": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "--mount", "type=bind,src=/path/to/allowed/dir,dst=/projects/allowed/dir,ro",
        "mcp/filesystem",
        "/projects"
      ]
    }
  }
}

roフラグを付けたディレクトリは、サーバーからは読み取り専用として扱われます（出典: 同README）。ただし、サーバーがフォルダごとに読み書きを判定しているわけではありません。OSのマウントが書き込みを受け付けないので、結果として読み取り専用になっているだけです。

同じ考え方はDocker以外でも使えます。読み取り専用でマウントしたボリュームや、書き込み権限を外したOSのファイル権限を組み合わせれば、Filesystem MCPが書き込みを試みても拒否されます。MCP公式のセキュリティ文書も、ローカルサーバーは最小限の既定権限で起動し、必要な権限だけを段階的に足す設計を推奨しています（出典: MCP公式セキュリティ文書）。

06呼び出す前に止めたいなら、AIエージェントの権限設計はどこに書くんですか？

呼び出しそのものを起こさせたくない場合は、クライアント側の権限設定を重ねます。Claude Codeなら、MCPツールもmcp__サーバー名__ツール名という形式で権限ルールの対象にできます（出典: Claude Code公式ドキュメント）。

{
  "permissions": {
    "deny": [
      "mcp__filesystem__write_file",
      "mcp__filesystem__edit_file",
      "mcp__filesystem__create_directory",
      "mcp__filesystem__move_file"
    ]
  }
}

このdenyルールは、呼び出しが実行される前にブロックします。OSのマウントが「実行後に失敗させる」のに対し、クライアント側のdenyは「実行させない」層です。

順番で見ると違いがはっきりします。モデルが道具を選び、クライアントが照合し、サーバーへ届き、最後にOSが受け付けるかを決めます。denyは2番目で止まり、roマウントは4番目で断ります。同じ「書き込ませない」でも、そこまでに何が動いたかが変わります。

両方を重ねるかどうかは、権限設計として意識的に選びます。配分の考え方はClaude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分で扱っています。

07Rootsでフォルダの境界が入れ替わると、権限設計の中でAIエージェントは何を触れるんですか？

高梨課長

高梨課長の発言

起動するときの引数を絞っておけば、それで範囲は決まりますよね。

鈴木さん

鈴木さんの発言

そこがひっくり返る場合があります。つないできた相手が範囲を持っていると、起動時に書いたほうは残らないんです。

Filesystem MCPが許可フォルダを決める方法は2通りあります。起動時のコマンドライン引数と、MCPのRootsプロトコルです（出典: 同README）。Rootsとは、クライアントが「このディレクトリを見てよい」とサーバーへ伝える仕組みです。

クライアントがRootsに対応している場合、接続時に渡されたRootsは、起動時の引数による許可フォルダを完全に置き換えます（出典: 同README）。引数を絞って起動しても、クライアント側が広いRootsを返せば、境界はクライアント任せになります。

Claude Codeでの挙動は具体的です。roots/list要求には、セッションの起動ディレクトリと追加の作業ディレクトリを合わせて返します。追加の作業ディレクトリは--add-dir・/add-dir・additionalDirectoriesで加えたものです（出典: 同ドキュメント）。この集合が変わるとnotifications/roots/list_changedを送信します。v2.1.203より前は起動ディレクトリしか返さず、変更通知も送っていませんでした。

08Rootsは権限設計の境界になるんですか、それともAI導入の判断材料どまりですか？

MCP公式仕様は、Rootsを「アクセス制御の仕組みではなく、情報提供のためのガイダンスである」と明記しています。プロトコル自体は、サーバーがRootsの範囲内に留まることを強制しません（出典: MCP公式仕様）。

Rootsを渡していれば安全、という理解は成り立ちません。境界として機能するかどうかは、個々のサーバーの実装しだいです。移行先として仕様が挙げるのは、ツール呼び出しの引数やリソースURI、サーバー起動時の設定でディレクトリを渡す方法です（出典: MCP公式仕様の非推奨registry）。

09サーバー・OS・クライアントの3層は、AI活用の権限設計でどう分担するんですか？

1つの層だけに頼ると、権限設計は崩れます。サーバー・OS・クライアントで役割を分けます。

上へ行くほど早い段階で止まり、そのぶん名指しした対象しか守りません。下へ行くほど守備範囲は広く、区別は粗くなります。3つは択一ではなく、粒度の違う網を重ねる関係です。

この分担は、機密情報を渡す前に分離する設計と同じ考え方です。前掲の記事では、分類判定・物理隔離・出力マスキングの3層で機密漏洩を防ぐ設計を扱いました。権限設計は、その分類判定より後、AIが実際に触れる範囲を絞る段階にあたります。

10権限設計でつまずくのは、AIエージェントを動かし始めたあとのどこですか？

若葉さん

若葉さんの発言

設定を広げた覚えはないのに、広く開いていた、ということがあるんですか。

鈴木さん

鈴木さんの発言

そちらのほうが多いくらいです。広げたのではなく、絞らなかった既定値がそのまま残っている。記録にも残らないので、後から追いにくいところです。

1. Rootsを渡せば安全な境界になると思い込む。Rootsは情報提供のためのガイダンスで、アクセス制御の仕組みではありません（出典: MCP公式仕様）。加えて2026-07-28付で仕様上は非推奨になっています。境界として使うなら、サーバー実装がRootsをどう扱っているかまで確認します。

2. OSの読み取り専用マウントだけを設定し、クライアント側のdenyを省略する。この状態でもwrite_fileはツール一覧に残り続けます。呼び出し自体は発生し、失敗するのは実行後です。呼び出す前に止めたいなら、mcp__filesystem__write_fileのようなクライアント側のルールを重ねます。

3. 許可フォルダをホームディレクトリなど広い単位で渡す。案件フォルダ1つで済む作業に、ドライブ全体や上位ディレクトリを渡すと、無関係な機密まで一括で開く対象に入ります。

3つに共通するのは、画面上は何も起きないことです。広すぎる設定は、ちょうどよい設定と見た目が同じです。社内で実際に起きた事故の詳細はAIエージェントの権限設計｜絞らなかった空白と4段の戻し方にまとめています。toolsやdenyを明示しなければ、書き込み系4種はデフォルトで使える状態のまま渡ります。

11渡す前の点検は、権限設計として生成AIに開くフォルダのどこを見ればいいんですか？

公開する前に、決めたことと実際の設定が合っているかを確かめます。

• 渡すフォルダの中身を、渡さない・読み取り専用・公開の3段階で仕分けたか
• 機密情報（認証情報・restricted相当）を含むフォルダを、起動時の引数から外したか
• 読み取り専用にしたいフォルダを、OSまたはコンテナのマウント設定で実際に書き込み不可にしたか
• クライアント側でmcp__filesystem__write_file等の書き込み系ツールをdenyしているか確認したか
• 接続先クライアントがRootsプロトコルに対応しているか、対応していれば何を返すかを確認したか
• list_allowed_directoriesを呼ばせて、実際の許可フォルダが意図どおりか点検したか
• 許可フォルダの範囲を案件単位まで絞り、ホームディレクトリ等の広い単位を渡していないか
• Filesystem MCPが公式リファレンス実装であり、本番利用を前提に作り込まれていないことを踏まえたか
• Rootsプロトコルの仕様状況とサーバーの最終更新日を、四半期ごとに再確認する運用にしたか

12よくある質問

13まとめ｜今日やる3つのこと

仕分けの単位は案件でした。読み取り専用はサーバーの外側で作るものでした。そして境界を最終的に決めているのは、起動した側とは限りませんでした。