Claude Codeを使っていて、bashコマンドのたびに「許可しますか？」と聞かれるのに正直うんざりしていませんか。私もそうでした。最初の頃は丁寧に1つずつ承認していたのですが、3日目くらいから内容も読まずにEnterを連打している自分に気づいて、これはもうセキュリティでも何でもないなと反省したんです。
そこで救世主のように登場したのがサンドボックス機能。OSレベルでファイルとネットワークを隔離してくれるので、安全を保ったまま承認ダイアログを激減させられます。
この記事では、Claude Codeのサンドボックスを実際に1ヶ月運用してみた経験をもとに、仕組み・設定・ハマりどころまで一気に解説します。読み終わる頃には、自分のsettings.jsonをすぐに書き換えたくなっているはずです。
Claude Codeサンドボックスとは？仕組みを3分で理解
Claude Codeサンドボックスとは、bashツールが触れるファイルとネットワークの範囲をOSレベルで制限する機能です。Claude本体ではなくOSが境界を守るので、Claudeが暴走しても境界の外には出られません。
従来は「許可しますか？」ダイアログで都度ブロックする方式でしたが、サンドボックスは事前に安全な領域を定義しておくアプローチ。発想がそもそも違うんですよね。檻の中で自由に走らせる、というイメージが一番近いです。
OSレベルで隔離される2つのレイヤー（FS・ネットワーク）
サンドボックスはファイルシステムとネットワークの両方を同時に隔離します。片方だけだと意味がないんです。たとえばファイルだけ守ってもネットワークが空いていれば、SSHキーを読まれて外部サーバーに送信されかねません。逆もまた然り。
実装はOSごとに違います。macOSはAppleのSeatbelt（sandbox-exec）、LinuxとWSL2はbubblewrapを使用。どちらもChromeがタブを隔離するのと同じ系統の技術なので、信頼性は十分です。
| レイヤー | 制限内容 | デフォルト挙動 |
|---|---|---|
| ファイルシステム | 書き込み可能なディレクトリを制限 | カレント配下のみ書き込みOK |
| ネットワーク | 接続可能なドメインを制限 | 承認済みドメインのみ通信OK |
通常のpermissions（権限）との決定的な違い
permissionsとサンドボックスは別物で、補完関係にあります。permissionsは「どのツールを呼ばせるか」の制御で、bash・Read・Edit・WebFetchすべてに効きます。一方サンドボックスは「bashが何に触れるか」のOSレベル制御で、bashとその子プロセスにだけ効きます。
つまりpermissionsで入口を絞り、サンドボックスで動ける範囲を物理的に限定する、という二段構えにするのが正解。片方だけだと穴があきます。
サンドボックスが解決する「承認疲れ」という現実問題
サンドボックスを入れる最大の理由は、承認疲れ（approval fatigue）の解消です。実際に運用してみると、承認ダイアログの回数が体感で8割以上は減りました。コードを書くリズムが完全に変わります。
従来の許可フローの3つの限界
許可ベースの運用は理屈としては正しいのですが、人間相手だと破綻します。私が痛感したのは以下の3点です。
- 承認疲れ：同じ確認を100回繰り返せば、101回目は中身を読みません
- 生産性の低下：1コマンドごとに数秒の中断が積み重なる
- 自律性の制限：エージェント本来の連続実行ができない
とくに3つ目が痛い。長時間のタスクを任せて席を立つと、戻ってきたら承認待ちで止まっている、というのがあるあるでした。
自動許可モード（Auto-allow）がもたらす変化
サンドボックスには自動許可モードと通常モードの2つがあり、自動許可モードを選ぶとサンドボックス内で完結するbashコマンドは承認なしで実行されます。境界の外に出ようとしたときだけ通常の許可フローに戻ります。
面白いのは、rm や rmdir がホームディレクトリやシステムパスを狙ったときは自動許可モードでも止まる点。最低限の安全弁は残してくれているので、暴走時のダメージも抑えられます。
Claude Codeサンドボックスの有効化手順
有効化はOSごとに少しだけ手順が違います。macOSはほぼゼロ設定、Linux/WSL2はパッケージを1つ入れるだけ。所要時間は5分もあれば十分です。
macOSは追加インストール不要で動く
macOSはOS標準のSeatbeltを使うので、追加インストールは要りません。Claude Codeを立ち上げて /sandbox を打つだけ。ここはAppleエコシステムの恩恵ですね。
# Claude Code内で実行
/sandboxWindowsはWSL2経由でないと動きません。ネイティブWindowsサポートは計画中とのことですが、2026年5月時点ではまだ未対応です。
Linux/WSL2はbubblewrapとsocatを入れる
Linux系は隔離にbubblewrap、ネットワーク中継にsocatを使うので、この2つを事前にインストールします。Ubuntu/Debianなら以下の1コマンドで終わります。
sudo apt-get install bubblewrap socatFedoraなら sudo dnf install bubblewrap socat です。WSL1はカーネル機能が足りず非対応なので、必要ならWSL2にアップグレードしておきます。
/sandboxコマンドでモードを選ぶ
準備が整ったら /sandbox を実行し、メニューから自動許可・通常許可・無効の3つから選びます。迷ったら自動許可で問題ありません。私もまずは自動許可で運用を始めて、不都合があったら絞る、という方針にしています。
依存パッケージが不足していると、メニューがインストール手順を案内してくれます。エラーで突然止まる感じではないので、初見でも詰まりにくい設計です。
settings.jsonでサンドボックスをカスタマイズする
細かい挙動は settings.json でカスタマイズします。デフォルトでも実用的ですが、kubectlやterraformを使うなら数行の追記が必須。逆にいうと、その数行で日常の摩擦がほぼ消えます。
自動許可モードの最小設定例
もっとも基本となるのが enabled と自動許可のセット。これだけ書いておけば、カレントディレクトリ配下の書き込みと承認済みドメインへの通信が自動許可になります。
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true
}
}最初はこの4行から始めるのがおすすめ。いきなり凝った設定にすると、どこで何を許可したのか自分でも分からなくなります。
allowWriteでサブプロセスの書き込みを広げる
サブプロセスがプロジェクト外に書き込む必要がある場合は filesystem.allowWrite で個別に許可します。kubectlは ~/.kube、ビルドツールは /tmp/build といった具合です。
{
"sandbox": {
"enabled": true,
"filesystem": {
"allowWrite": ["~/.kube", "/tmp/build"]
}
}
}パスは / 始まりが絶対パス、~/ がホーム相対、それ以外がプロジェクトルート相対。ここを取り違えるとサンドボックス内で謎の書き込みエラーが出るので、最初に整理しておくと安心です。
ドメイン許可リストでネットワークを絞る
ネットワーク側は allowedDomains で接続先を制限できます。広く許可するほど便利ですが、データ流出リスクも上がるトレードオフ。たとえば github.com を全許可すると、攻撃者がGistにデータを上げる経路を与えてしまいます。
私は registry.npmjs.org、pypi.org、api.github.com あたりだけ明示的に許可しておく方針。新しいドメインに触れたタイミングでプロンプトが出るので、必要に応じて足していけばOKです。
ハマりどころと回避策5パターン
順調に使えると思いきや、特定のツールでつまづく場面が必ず出てきます。私が実際に遭遇した代表例と、その回避策を紹介します。先に知っておくと無駄な30分を消費せずに済みます。
kubectl・terraformが書き込みエラーになるとき
kubectlは ~/.kube/cache、terraformは ~/.terraform.d に書き込みます。デフォルトのままだとこれらがブロックされ、認証情報の更新やプラグイン取得が落ちます。
対処は前述の allowWrite に該当ディレクトリを足すだけ。excludedCommands で丸ごとサンドボックスから外す手もありますが、隔離の意味が薄れるので、まずは allowWrite 派です。
docker・watchmanはサンドボックス非対応
dockerとwatchmanはサンドボックスと相性が悪く、内部で動きません。dockerデーモンに繋ぐUnixソケットを許可するとサンドボックスを実質バイパスできてしまうので、Anthropic公式も非推奨としています。
dockerは excludedCommands に docker * を追加してサンドボックス外で動かす、watchmanはjest側で --no-watchman オプションをつける、というのが現実的な落としどころです。
dangerouslyDisableSandboxという脱出ハッチ
どうしてもサンドボックス内で動かない処理に出くわしたら、Claudeが dangerouslyDisableSandbox 付きで再実行を提案してきます。名前のとおり危険なので、その都度ユーザー承認が必要です。
管理デプロイで完全に塞ぎたい場合は allowUnsandboxedCommands: false を入れます。「絶対にサンドボックス外には出させない」ポリシーを敷ける、ということです。チーム配布のテンプレートには入れておくと安心。
サンドボックスとDevContainerはどう使い分ける？
「DevContainerで隔離すればいいじゃん」と思う方も多いと思いますが、両者は守備範囲が違います。サンドボックスは軽量・即起動、DevContainerは完全隔離・重量級。シーンで使い分けるのが正解です。
ローカル開発ならサンドボックスで十分なケース
普段のコード書き、bashコマンド、軽いビルド作業ならサンドボックスで事足ります。起動オーバーヘッドがほぼゼロで、ホスト側のツール（VSCode・gitなど）とそのまま連携できるのが強み。
ホストの環境変数や鍵が見えるのを嫌う場合だけ、次のDevContainerに切り替える、という判断軸でいいと思います。
完全隔離が必要ならDevContainerに寄せる
未知のリポジトリを試す、サードパーティのMCPサーバーを動かす、信頼できないスクリプトを実行する、といった場面ではDevContainerが安心です。コンテナごと使い捨てにできるので、汚染しても破棄すれば終わり。
サンドボックス＋DevContainerの二段構成も可能で、これだとほぼ要塞レベルの隔離になります。ただ普段使いでは重いので、用途に応じて切り替えるのが現実的です。
よくある質問（FAQ）
記事を書くにあたって私自身も改めて調べた、よくある疑問をまとめておきます。1問1答で短くまとめたので、必要なところだけ拾い読みしてください。
Windowsでも使える？
ネイティブWindowsは2026年5月時点で非対応です。WSL2経由なら使えるので、Windows環境ではWSL2を立てておくのが現実解。WSL1はサンドボックスに必要なカーネル機能が足りないため動きません。
既存の権限設定はそのまま活きる？
はい、permissionsの設定は引き続き有効です。サンドボックスはbashに対するOSレベルの追加防壁で、permissionsの代替ではありません。両方を併用する前提で設計されています。
Read/Edit/Computer Useにも適用される？
サンドボックスはbashツールとその子プロセスにだけ効きます。Read・Edit・Writeは従来どおりpermissionsで制御、Computer Useは実デスクトップ上で動くためアプリ単位の許可ダイアログで管理されます。
まとめ：サンドボックスは「制限」ではなく「自由」のための仕組み
サンドボックスを使う前は、安全性を上げるとAIが動きにくくなる、というトレードオフを当然のものとして受け入れていました。でも実際に使ってみると、安全と生産性は両立できるんだなと実感が変わりました。
境界を先に決めてしまえば、その中ではClaudeに自由にやらせられる。承認ダイアログにEnterを連打する自分とはもうサヨナラできます。まずは /sandbox を打って自動許可モードを試すところから、気軽に始めてみてください。
