Claude Codeサンドボックス設定の手順と許可範囲の決め方

Claude Codeのサンドボックス設定を、有効化の手順からsettings.jsonの書き方、パーミッションとの使い分けまで整理した。自チームの作業を棚卸しし、書き込み・読み取り禁止・通信先の許可範囲を導く手順を実例で示す。

Claude Codeのサンドボックス許可範囲を作業から導く

Claude Codeのサンドボックスは、有効化そのものは数分で終わる。判断が要るのは、書き込み・読み取り・通信をどこまで許すかという許可範囲の方だ。厳しすぎるとビルドが止まり、緩すぎると隔離の意味が薄れる。本記事では、有効化の手順とsettings.jsonの書き方を短く押さえたうえで、自チームの作業を棚卸しして許可範囲を1つずつ決める手順を実例で示す。

Claude Codeのサンドボックス設定とは？

Claude Codeのサンドボックス設定とは、Bashコマンドの書き込み先と通信先をOSの隔離機能で制限する設定である。

設定は/sandboxコマンドか、settings.jsonのsandboxキーで行う。狙いは2つある。1つ目は、外部から仕込まれた指示などで意図しないコマンドが走っても、被害を作業ディレクトリと許可した通信先の範囲に閉じ込めることだ。2つ目は、範囲内のコマンドを都度の承認なしで実行させ、開発者の承認疲れを減らすことである。

Claude Codeのサンドボックスとは何を制限する機能か？

サンドボックスが制限するのは、ファイルの書き込み範囲と通信の接続先の2点であり、既定では作業ディレクトリの外への書き込みを禁じる。

Anthropicの技術解説によれば、隔離は2つの境界で構成される。

（出典：Anthropic『Beyond permission prompts』。2025年10月公開、原文）

境界	既定の動き	設定で変えられること
ファイル	作業ディレクトリ内は読み書き可、外への書き込みは禁止	書き込み先の追加、読み取り禁止パスの指定
通信	隔離の外にある中継役を経由して接続し、新しいドメインは確認を求める	許可ドメインの事前登録

注意したいのは読み取りである。書き込みの既定の制限に頼らず、~/.sshや~/.awsのような認証情報はfilesystem.denyReadに明示して守る。また制限が及ぶのはBashコマンドとその子プロセスであり、Claude Code自身のファイル読み書き機能はパーミッションの側で制御する。

対応OSと事前準備は何が必要か？

macOSは追加の準備なしで使え、LinuxとWSL2はbubblewrapとsocatの導入が前提になる。

環境	隔離の仕組み	事前準備
macOS	Seatbelt（OS標準）	不要
Linux	bubblewrap	`bubblewrap`と`socat`を標準の導入手段で入れる
WSL2	bubblewrap	Linuxと同じ。WSL1は対象外

Ubuntu系ならsudo apt-get install bubblewrap socatで揃う。Windowsで直接使う場合は、WSL2の中でClaude Codeを動かす構成になる。

サンドボックスはどの手順で有効化するか？

有効化は/sandboxを1回実行すれば済む。チームで揃えるなら、settings.jsonに"enabled": trueを書く。

前節の事前準備を済ませる（Linux・WSL2の場合）
Claude Codeを起動し、/sandboxを実行する
隔離内のコマンドを自動承認するかどうかを選ぶ
ls ~/のような作業ディレクトリ外の読み取りと、touch ~/test.txtのような外への書き込みを試し、後者が拒否されることを確かめる

4番目の確認は省かない方がよい。書き込みが通ってしまう場合、サンドボックスが有効になっていないか、設定ファイルの優先順位で別の値に上書きされている。

settings.jsonでファイルとネットワークの許可範囲をどう書くか？

許可範囲はsandboxキーの下に、ファイル用と通信用の2つの区画へ分けて書けばよい。

ファイルはfilesystem.allowWrite（書き込み追加先）とfilesystem.denyRead（読み取り禁止）で指定する。通信先はnetwork.allowedDomainsに配列で並べる。

主な設定キーは次のとおりである（出典：Anthropic『Claude Code settings』2026年10月、Claude Code Docs）。キー名は版によって追加・変更されることがあるため、導入時に公式の説明書と照合してほしい。

キー	役割
`enabled`	サンドボックスの有効・無効
`autoAllowBashIfSandboxed`	隔離内のBashを承認なしで実行するか
`excludedCommands`	隔離の外で動かすコマンド（通常の承認を経る）
`allowUnsandboxedCommands`	隔離を外して再実行する逃げ道を残すか
`filesystem.allowWrite` / `filesystem.denyRead`	書き込み追加先と読み取り禁止パス
`network.allowedDomains`	確認なしで接続してよいドメイン

allowUnsandboxedCommandsをfalseとすれば、失敗したコマンドを隔離の外で再実行する経路が閉じる。外で動かしたいコマンドはexcludedCommandsへ明示して管理するため、例外が設定ファイル上で見える。

サンドボックスとパーミッションはどう使い分けるか？

結論は、2つを重ねて使うことだ。サンドボックスはBashコマンドをOS側で囲い、パーミッションはClaude Codeの機能呼び出しを個別に許可・拒否する。

観点	サンドボックス	パーミッション
対象	Bashコマンドと子プロセス	Read・Edit・WebFetch・Bashなどの機能呼び出し
強制の層	OS（Seatbelt・bubblewrap）	Claude Codeのアプリ層
書き方	`sandbox.filesystem`・`sandbox.network`	`permissions.allow`・`ask`・`deny`
向く用途	ビルド・テストなど大量のコマンドの承認削減	特定ファイルの読み取り禁止、危険なコマンドの拒否

使い分けの基準は単純だ。「範囲内なら何をしてもよい作業」はサンドボックスに任せ、「範囲内でも触らせたくない対象」はパーミッションのdenyに書く。作業ディレクトリ内の.envは後者の典型である。

許可範囲を厳しくすると作業は止まらないか？

止まるのは許可範囲が作業の実態とずれているときである。事前に作業を棚卸しして必要な書き込み先と通信先を洗い出せば、停止は数か所の追加設定で解消できることが多い。

止まりやすいのは3つの場面だ。依存パッケージの一時保存先が作業ディレクトリの外にある場合、テストやブラウザ自動化が手元の待ち受け口を使う場合、ビルドが外部の配布元へ接続する場合である。どれも作業から逆算できるため、次節の棚卸しで先回りできる。

作業の棚卸しから許可範囲を導く手順の実例

※提案であり、実施実績ではない。

株式会社ファーリープ（Farleap）は、既存記事で権限最小化の考え方を整理してきた（エンタープライズでのClaude Code開発）。ここではそれを、サンドボックスの設定値に落とし込む手順として示す。想定するのは、TypeScriptのWebアプリと、決済APIのテスト環境を呼び出すリポジトリである。

手順1 作業を列挙して必要な権限を表にする

Claude Codeに任せたい作業を並べ、それぞれが書き込む先・読む必要のない秘密情報・接続先を1行ずつ埋める。

作業	書き込み先	読ませない対象	接続先	設定への反映
依存インストール（npm install）	`~/.npm`（一時保存先）	なし	`registry.npmjs.org`	allowWriteとallowedDomainsに追加
ビルド	作業ディレクトリ内の`dist/`	なし	なし	既定のままでよい
単体テスト	作業ディレクトリ内の`coverage/`	`.env`	なし	`.env`をdenyに追加
E2Eテスト	`~/.cache/ms-playwright`	なし	localhost	allowWriteと手元の待ち受けの許可
外部API呼び出し	なし	`~/.aws`などの認証情報	決済APIのテスト用ホスト	allowedDomainsに追加
git push	なし	`~/.ssh`	Gitの共有先	人が実行し、Claude Codeには任せない

手順2 読み取り禁止を先に決める

書き込み先より先に、読ませない対象を決める。漏れたときの影響が大きいのは読み取りの方だからだ。~/.ssh・~/.aws・~/.config/ghのような認証情報と、作業ディレクトリ内の.envを挙げる。

手順3 例外コマンドを決める

dockerのように隔離内で動かしにくいコマンドはexcludedCommandsに入れ、通常の承認を経て外で動かす。git pushは上の表のとおり人の作業として残す。

手順4 設定ファイルに書いて1週間試す

表から導いた設定値は次のようになる。ドメインは想定値である。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "excludedCommands": ["docker"],
    "filesystem": {
      "allowWrite": ["~/.npm", "~/.cache/ms-playwright"],
      "denyRead": ["~/.ssh", "~/.aws", "~/.config/gh", "./.env"]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org", "api.payments-test.example.com"],
      "allowLocalBinding": true
    }
  },
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

allowLocalBindingは手元での待ち受けを許す設定で、E2Eテストの開発用の起動のために入れている。試行期間中は、確認プロンプトが出たドメインやパスを記録し、毎回許可したものだけを表に戻して追加する。表と設定を往復させることで、許可範囲の1つずつに理由が残る。

チームで運用するときの設定をどう標準化するか？

共通の許可範囲はリポジトリの.claude/settings.jsonに置いてレビュー対象にし、外せない制約は組織の管理設定で強制する、という3層で標準化する。

置き場所	用途	共有範囲
管理設定（managed-settings.json）	`enabled: true`や`allowUnsandboxedCommands: false`など、組織として外せない制約	組織全体（最優先）
`.claude/settings.json`	手順1の表から導いたプロジェクト共通の許可範囲	リポジトリ（Git管理）
`.claude/settings.local.json`	個人の一時保存先など、その人の環境だけの追加	個人（Git管理外）

運用で効くのは、手順1の表を設定ファイルと同じリポジトリに置くことだ。許可ドメインを足す変更に表の更新も含めれば、確認する人は「どの作業のために開けるのか」を判断できる。導入全体の体制づくりはプロダクト開発サービスでも扱っている。他の開発支援AIと比べて権限設計を考える場合は、AIコーディングアシスタントの比較が参考になる。

有効化後にコマンドが失敗したらどう切り分けるか？

失敗の多くは、書き込み拒否・通信拒否・待ち受け拒否の3種類に分かれ、エラーの文面から設定のどこを見直すかが決まる。

症状	原因の候補	見直す設定
`Operation not permitted`や`EPERM`	作業ディレクトリ外への書き込み	`filesystem.allowWrite`
依存の取得が時間切れになる	許可していないドメインへの接続	`network.allowedDomains`
開発用の起動に失敗する	手元での待ち受け	`network.allowLocalBinding`
設定を変えても挙動が変わらない	上位の設定ファイルで上書きされている	管理設定と`settings.local.json`
Linuxで起動直後に失敗する	bubblewrapまたはsocatが未導入	事前準備

失敗したからといってexcludedCommandsに逃がすのは最後の手段にする。例外が増えるほど、サンドボックスで囲える範囲は狭くなる。

まとめ

Claude Codeのサンドボックス設定は、有効化よりも許可範囲の決め方に時間を使う方がよい。まず作業を棚卸しして読み取り禁止を決め、書き込み先と通信先は作業から逆算して最小限だけ開ける。Anthropicは、社内での利用でサンドボックス化により確認プロンプトが84%減ったと報告している。

（出典：Anthropic『Beyond permission prompts』。2025年10月公開、原文）

承認の手間を減らしつつ、許可範囲の理由をチームで説明できる状態を目指したい。

よくある質問

サンドボックスを有効にすれば.envの中身は読まれないか？

読まれる可能性がある。サンドボックスの書き込み制限は作業ディレクトリの外が対象であり、作業ディレクトリ内の.envは既定で読み取れる。秘密情報のファイルは、パーミッションのdenyとサンドボックスの読み取り禁止の両方に登録しておく。

サンドボックスとDevContainerはどちらを使うべきか？

日常の開発で承認の回数を減らしたいならサンドボックス、環境ごと隔離して長時間の自律実行をさせたいならDevContainerが向く。サンドボックスは手元の環境のまま使える点が利点で、両者は併用もできる。

許可ドメインはどの粒度で登録すればよいか？

作業の棚卸しで実際に通信が確認できたドメインだけを、ホスト名単位で登録する。最初から広く登録するより、試行期間に出た確認プロンプトを記録し、毎回許可したドメインだけを追加していく方が、許可範囲の根拠を説明しやすい。

更新履歴

2026-10-13 初稿公開。