Claude Codeに頼むだけで、サンドボックスの安全設定はどこまでできる？

この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。

Claude Codeのサンドボックスを有効にすれば、Bashコマンドによるファイルの書き込みやネットワーク通信は制限できる——が、ファイルの読み取りは制限されていなかった。どこまで安全にできて、どこから人が確認すべきか、Windows 11のWSL2環境で確かめた。検証条件は、ターミナルから自然文で依頼する形。

この記事で確かめること

Claude Codeにはサンドボックス機能があり、Bashコマンドの実行時にファイルシステムとネットワークのアクセスを制限できる。この機能を実際に有効化して、どこまで制限が効くのか、どこから効かないのかを検証する。

具体的には、settings.json にサンドボックス設定を記述し、カレントディレクトリ外への書き込みブロック、特定パスの読み込み拒否、通信先ドメインの制限——この3点の動きを確認する。検証の結果、書き込みと通信はブロックされたが、Readツール経由のファイル読み取りは制限対象外だった。「サンドボックスが守るのはBashの世界だけ」という境界線を見ていく。

環境はWindows 11、WSL2上でClaude Codeをターミナルから使い、入力は自然文のみ。

前提——Windowsでサンドボックスを使うには

サンドボックス機能は、Linuxでは「bubblewrap」、macOSでは「Seatbelt」というOSレベルの隔離ツールに依存している。どちらもWindowsネイティブでは動かないため、Windowsでサンドボックスを使うにはWSL2環境が必要だ。

WSL2が導入済みであれば、bubblewrapがインストールされているか次のコマンドで確認できる。

which bwrap

パスが返ってくれば準備完了だ。インストールされていなければ、Ubuntu側で sudo apt-get install bubblewrap socat を実行する。

以降の検証は、WSL2 + bubblewrapが揃っている前提で進める。WSL2自体のセットアップはこの記事の範囲外なので、未導入の方は先にそちらを済ませてほしい。

今回の検証環境は次の通り。

OS: Windows 11 Pro
環境: WSL2（Ubuntu）
利用形態: ターミナル
入力方法: 自然文

作業フォルダの作り方が不安な方は、Windowsで作業フォルダを作る手順を先に確認しておくとスムーズです。

Step 1: 最初の依頼——サンドボックスを有効にして

Claude Codeを起動した状態で、自然文でサンドボックスの設定を依頼した。

WindowsのWSL2環境で使っているClaude Codeのサンドボックス機能を有効にして。
カレントディレクトリ配下だけ書き込み可能にして、外部ドメインへの
ネットワークアクセスはgithub.comとnpmjs.comだけ許可する設定にして。

依頼文にOSを書いたのは、環境違いの手順を避けるためだ。これを省くとMac向けのSeatbelt設定が提案されることがある。

サンドボックスを有効にすれば安心——そう思って依頼したが、本当にそうなるか。

Claude Codeからの応答はこうだった。settings.json に次のような設定を追加してきた。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["."],
      "denyRead": []
    },
    "network": {
      "allowedDomains": ["github.com", "npmjs.com"]
    }
  }
}

filesystem.allowWrite に "." を指定することで、カレントディレクトリ配下のみ書き込みを許可する意図だ。network.allowedDomains で通信先を限定している。依頼文で指定した内容がそのまま設定に反映されていた。

Step 2: 最初の結果——制限が効いているか確認

設定が反映されたか、いくつかのコマンドで確認した。

ファイル書き込み制限——カレントディレクトリ外への書き込みを試す。

echo test > /tmp/sandbox-test.txt

結果:

Error: Permission denied (sandbox restriction)

ブロックされた。カレントディレクトリ内への書き込みは通るので、期待通りの動きだ。

ネットワーク制限——許可していないドメインへのアクセスを試す。

curl -s https://example.com

結果:

Error: Network access denied (domain not in allowed list)

こちらもブロックされた。github.com へのアクセスは通ることを別途確認している。

良かった点は、書き込み制限もネットワーク制限も設定直後に効いていたこと。依頼文1回でここまで設定できるのは手軽だ。

足りなかった点——ここがこの検証の一番の引っ掛かりになる。今回の検証では、Sandbox設定だけではClaude CodeのReadツール経由の読み取りまでは防げなかった。Sandboxは主にBashコマンドとその子プロセスをOSレベルで制限する仕組みで、Readツールの制御はPermissions側で別途設定する必要がある。

Step 3: 修正指示——カバーできない領域を整理する

Step 2で見えた「サンドボックスだけでは防げない」領域を補うため、次の修正指示を出した。

いまのサンドボックス設定だと、Bashコマンドは制限できているけど
Readツールでファイルを読むのは制限できていないことに気づいた。
サンドボックスとPermissionの違いを整理して、両方設定する
構成にしてもらえる？

修正の狙いは、Sandbox（OSレベルのBash制限）とPermission（ツールレベルの許可制御）の棲み分けを明確にすることだ。サンドボックスはBashコマンドの世界を隔離する仕組み。一方、PermissionはReadツールやWriteツールなど、Claude Codeが内部で使うツール単位でのアクセス制御になる。

この二層構造を理解しておかないと、「サンドボックスを有効にしたから安全」という過信に繋がる。

Step 4: 修正後の結果——SandboxとPermissionの棲み分けが見えた

修正後、SandboxとPermissionがそれぞれ異なる範囲をカバーしていることが確認できた。

サンドボックスが守るのはBashコマンドの世界だけ。ツールレベルのアクセスは別の層で制御する必要がある。

この関係を表にまとめる。

項目	Sandbox（OSレベル）	Permission（ツールレベル）
対象	Bashコマンドの実行	Read/Write/Edit等のツール
書き込み制限	allowWriteで制御可能	allowWrite / denyWrite等で制御
読み込み制限	denyReadでBash経由をブロック	ツール単位で別途設定が必要
ネットワーク制限	allowedDomainsで制御可能	対象外（ツール経由の通信は別）
設定場所	settings.jsonのsandbox	settings.jsonのpermissions

両方設定すべき理由はシンプルだ。SandboxだけではReadツール経由の読み取りを防げない。Permissionだけでは、許可したBashコマンド配下の子プロセスまでOSレベルで細かく隔離することはできない。Bash経由のファイル操作やネットワーク通信を境界内に収めるには、Sandbox側の設定も必要になる。

Step 5: どこまで頼むだけでできた？

サンドボックス設定について、AIに任せられたことと人が確認したことの分担を事実ベースで書き出す。やり取りの回数は2回（初期依頼1回 + 修正指示1回）だった。

比較的任せやすい

サンドボックスの基本設定（enabled、allowWrite、allowedDomains）
書き込み制限の動作確認（Bashコマンドでブロックされるか試す）
ネットワーク制限の動作確認

条件付きで使える

ネットワーク制限のドメイン指定（用途によって許可リストが変わるため、自分の利用環境に合っているかの確認が必要）
denyRead の組み合わせ（Bash経由はブロックされるが、Readツール経由は別途Permissionが必要な点を理解した上で使う）

必ず人が確認すべき

設定にサンドボックスを無効化する項目が含まれていないか（サンドボックス全体を無効にするオプションがある場合、制限がすべて外れる）
Permission層の設定が漏れていないか（Sandboxだけ設定して終わらないか）
failIfUnavailable の設定（サンドボックスが使えない環境での挙動をどうするか）

最終結果——最小限の安全設定

検証を通じて到達した最小構成の安全設定を示す。プロジェクトディレクトリは架空の汎用構成にしているので、パスやドメインは自分の環境に合わせて読み替えてほしい。

この設定例は検証時の環境で動作確認した内容であり、設定キーの一部は公式ドキュメントで明記されていないものも含まれる。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "filesystem": {
      "allowWrite": ["."],
      "denyRead": []
    },
    "network": {
      "allowedDomains": ["github.com", "npmjs.com"]
    }
  },
  "permissions": {
    "allow": [
      "Read(./src/**)",
      "Read(./config/**)"
    ],
    "deny": [
      "Read(../**)",
      "Read(/etc/**)"
    ]
  }
}

failIfUnavailable を true にした理由は、bubblewrapが使えない環境でサンドボックスなしで動いてしまうのを防ぐためだ。この設定が true だと、サンドボックスが利用できない場合はBashコマンド自体が実行されない——という挙動が今回の検証環境では確認できた。

自動承認に近い権限モードは利便性が高いが、予期しないコマンドが実行されるリスクもある。都度確認のモードは手間が増えるが、コマンド単位で把握できる。用途に応じて選ぶと良い。

初心者ならまずは書き込み制限だけでも効果的だ。ネットワーク制限は用途次第なので、必要になったタイミングで追加しても遅くない。外部ツールとの連携が必要になったら、MCPサーバーの導入も検討できます。

この検証の振り返り

依頼文の書き方で効いたのは2点——OSを明記したことと、具体的な制限内容（書き込みブロック、読み込み拒否、ドメイン制限）を書いたことだ。漠然と「サンドボックスを有効にして」と頼むより、何を制限したいかを書く方が意図に近い設定が出てきやすい。

この構成が向いていそうなのは、Claude Codeでの操作を手堅く安全にしたい人や、チーム内でClaude Codeを導入するにあたり最低限の安全設定を決めたい人だ。一方で、Windowsネイティブ環境のみでWSL2を導入する予定がない人や、サンドボックスを有効にすれば完璧だと思ってしまう人には向かない。

環境やバージョンによっては、今後さらに進められる可能性がある。

次に試すなら

サンドボックス設定をさらに進めたい場合の導線を3段階で示す。

第1段階: WSL2のセットアップ（未導入向け）

サンドボックスが使える環境が整い、Bashコマンドの書き込み制限の恩恵を受けられる。まずはここが前提だ。

第2段階: denyRead や allowedDomains のバリエーション（設定を深める向け）

読み込み制限と通信制限を組み合わせて防御範囲を広げられる。Bash経由のアクセスだけでなく、どのパスを読ませたくないかを具体化していくと、より安全な構成に近づく。

第3段階: managed-settings.json やMDM（チーム運用向け）

個人ごとの設定漏れを防ぎ、組織全体で統一した安全設定を維持できる。複数人でClaude Codeを使う環境では、この層まで整えておくと安心感が増す。チームでの運用を検討しているなら、エージェントチーム機能も併せて確認すると良いでしょう。

サンドボックス機能の基本は「頼むだけで設定できる」。ただし、どこまで制限が効くかを知った上で使うことが大切だ。

サンドボックス以外にも権限モードやPlan Modeなど、複数の安全機能が用意されています。Claude Codeの安全設定まとめで全体像を確認できます。

まとめ

サンドボックスは頼むだけで設定でき、Bashコマンドの書き込み制限やネットワーク制限は確かに効いた。ただし、Readツール経由の読み取りは制限対象外で、SandboxとPermissionは別の層として両方設定する必要があった。まずは書き込み制限だけでも有効にすれば、意図しないファイル変更のリスクは大きく減る。どこまでサンドボックスに頼れるかを知った上で、自分の環境に合った設定を選んでいきたい。

今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。