Filesystem MCPの権限設計｜AIに開くフォルダの決め方

Filesystem MCPをAIエージェントにつなぐと、どのフォルダを読み書きさせるかを最初に決める必要があります。本記事は自環境への接続実績がまだ無いため、公式リポジトリと公式ドキュメントの記載だけを根拠に、権限設計の判断基準を整理します。確認日は2026年7月29日です。

01結論：Filesystem MCPの権限設計は、公開前の3判定で決まる

Filesystem MCPは、AIにローカルのファイル読み書きを許可する公式リファレンス実装です（出典: MCP公式リポジトリ）。ツールは13種類あり、うち9種が読み取り専用、4種が書き込みを伴います（出典: 同リポジトリREADME、2026-07-29確認）。

結論は3つです。

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

02公開される13のツール｜権限の絞り方を決める前に知ること

権限設計を始める前に、何を許可・拒否できるのかを把握します。Filesystem MCPが公開するツールは13種類です（出典: 同README、2026-07-29確認）。内訳は次の表のとおりです。

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

Filesystem MCPは、GitHubのmodelcontextprotocol/serversが公開する公式リファレンス実装の1つです。同リポジトリはAnthropicが管理し、収録サーバーは「MCP機能とSDKの使い方を示す教育用サンプルであり、本番運用を前提にしたソリューションではない」と明記されています（出典: 同リポジトリREADME）。提供元の信頼レベルをどう見分けるかは『MCPの選び方｜権限と提供元で見る判断軸5つ』で扱った軸がそのまま使えます。

読み書きを分けるような運用機能まで手厚く作り込まれている前提には立てません。権限設計は自分たちで足す必要があります。

03公開してよいフォルダを決める3判定｜権限設計の起点

権限設計の起点は、フォルダの中身を見て3段階に仕分けることです。自社では機密情報をpublic・internal・restrictedの3段階へ分離する運用をしています。詳しい判定基準は『機密をAIエージェントに渡さない｜gitignoreとフォルダ構成』にまとめています。Filesystem MCPの権限設計は、この分類の続きとして次のように対応づけられます。

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

04読み取り専用に留めるという権限設計の判断｜Filesystem MCP自体に専用モードは無い

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公式セキュリティ文書）。

この方式には注意点があります。OS側で拒否しても、write_fileやedit_fileはツール一覧としてモデルの視界に残ったままです。書き込みを試みる呼び出し自体は発生し、失敗するのは呼び出しが実行された後になります。

呼び出す前に止めたい場合は、クライアント側の権限設定を重ねます。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は「実行させない」層です。両方を重ねるかどうかは、権限設計として意識的に選びます。詳しい配分の考え方は『Claude Codeの権限設定｜allow・ask・denyの配分と設定例』で扱っています。

05Roots協定と権限設計｜クライアント接続でフォルダ境界が変わる仕組み

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より前は起動ディレクトリしか返さず、変更通知も送っていませんでした。

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

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

063層で固める権限設計｜サーバー・OS・クライアントの役割分担

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

この3層は、機密情報を渡す前に分離する設計と考え方が同じです。『機密をAIエージェントに渡さない｜gitignoreとフォルダ構成』では、分類判定・物理隔離・出力マスキングの3層で機密漏洩を防ぐ設計を扱いました。権限設計は、その分類判定より後、AIが実際に触れる範囲を絞る段階にあたります。

権限設計が崩れる典型は、意図して広げた設定ではなく、絞らなかった既定値がそのまま残るケースです。社内で実際に起きた事故の詳細は『AIエージェントの権限設計｜自動承認を広げすぎた日と戻し方』にまとめています。Filesystem MCPでも、toolsやdenyを明示しなければ、書き込み系4種はデフォルトで使える状態のまま渡ります。

07権限設計でつまずきやすい3つの点

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

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

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

08権限設計チェックリスト｜フォルダを公開する前に

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

09FAQ