Claude Codeサンドボックス設定｜Windows対応解説

Claude Codeを使っていると、bashコマンドのたびに「許可しますか？」と聞かれます。

私も最初は丁寧に1つずつ承認していたのですが、3日目には内容も読まずにEnterを連打している自分に気づいて、これはもうセキュリティでも何でもないなと反省したんです。

そこで使い始めたのがサンドボックス機能です。

OSレベルでファイルとネットワークを隔離してくれるので、安全を保ったまま承認ダイアログを大きく減らせます（Anthropicは社内での利用で84%減ったと公表しています）。

この記事では、Claude Codeのサンドボックスを1ヶ月運用した経験をもとに、仕組み・macOS/Linux/WSL2の設定手順・settings.jsonのカスタマイズ例・kubectlやdockerで詰まった時の回避策まで、2026年9月時点の最新情報で一気に解説します。

Claude Codeサンドボックスとは？仕組みを3分で理解

Claude Codeサンドボックスとは、bashツールが触れるファイルとネットワークの範囲をOSレベルで制限する機能です。

Claude本体ではなくOSが境界を守るので、Claudeが暴走しても境界の外には出られません。

従来は「許可しますか？」ダイアログで都度ブロックする方式でしたが、サンドボックスは事前に安全な領域を定義しておくアプローチ。

発想がそもそも違うんですよね。檻の中で自由に走らせる、というイメージが一番近いです。

OSレベルで隔離される2つのレイヤー（FS・ネットワーク）

サンドボックスはファイルシステムとネットワークの両方を同時に隔離します。片方だけだと意味がないんです。

たとえばファイルだけ守ってもネットワークが空いていれば、SSHキーを読まれて外部サーバーに送信されかねません。逆もまた然り。

実装はOSごとに違います。macOSはAppleのSeatbelt（sandbox-exec）、LinuxとWSL2はbubblewrapを使用。

どちらもChromeがタブを隔離するのと同じ系統の技術なので、信頼性は十分です。

通常の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内で実行
/sandbox

WindowsはWSL2経由でないと動きません。ネイティブWindowsでは、2026年9月時点でもサンドボックスは動かず、コマンドはサンドボックスなしで実行されます。

Linux/WSL2はbubblewrapとsocatを入れる

Linux系は隔離にbubblewrap、ネットワーク中継にsocatを使うので、この2つを事前にインストールします。

Ubuntu/Debianなら以下の1コマンドで終わります。

sudo apt-get install bubblewrap socat

Fedoraなら sudo dnf install bubblewrap socat です。

WSL1はカーネル機能が足りず非対応なので、必要ならWSL2にアップグレードしておきます。

なおWSL2では、cmd.exe・powershell.exe・/mnt/c/ 配下のWindowsバイナリの起動がUnixソケット経由でWindowsホストに渡されます。そのためサンドボックス内から起動できるかどうかは、サンドボックスのUnixソケット設定しだいです（ソケットを遮断するには、任意のseccompフィルタを入れておく必要があります）。

サンドボックス内からWindowsバイナリを起動したい場合は、allowAllUnixSockets で起動を許可できます。ただしすべてのUnixソケットをサンドボックス内に開放することになるため、必要なときだけ使います。

/sandboxコマンドでモードを選ぶ

準備が整ったら /sandbox を実行し、Modeタブで自動許可か通常許可（サンドボックス内のコマンドにも通常の許可確認を残す）のどちらかを選びます。サンドボックスはデフォルトでオフなので、使わないなら有効化しなければそのままです。迷ったら自動許可で問題ありません。

私もまずは自動許可で運用を始めて、不都合があったら絞る、という方針にしています。

依存パッケージが不足していると、/sandbox のパネルに「Dependencies」タブが現れ、足りないものが分かります。インストール後はClaude Codeを再起動してから、もう一度 /sandbox を開いてください。エラーで突然止まる感じではないので、初見でも詰まりにくい設計です。

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"]
    }
  }
}

パスは / 始まりが絶対パス、~/ がホーム相対、それ以外（./ 始まりや接頭辞なし）はプロジェクト設定ならプロジェクトルート相対、ユーザー設定なら ~/.claude 相対。

ここを取り違えるとサンドボックス内で謎の書き込みエラーが出るので、最初に整理しておくと安心です。

ドメイン許可リストでネットワークを絞る

ネットワーク側は allowedDomains で接続先を制限できます。広く許可するほど便利ですが、データ流出リスクも上がるトレードオフ。

たとえば github.com を全許可すると、攻撃者がGistにデータを上げる経路を与えてしまいます。

私は registry.npmjs.org、pypi.org、api.github.com あたりだけ明示的に許可しておく方針。

新しいドメインに触れたタイミングでプロンプトが出るので、必要に応じて足していけばOKです。

個人的に1ヶ月運用して学んだのは、最初から理想形のホワイトリストを書こうとしないこと。きれいに絞ろうとすると、必ず想定外のドメインで止まります。

作業中断のストレスから、結局サンドボックスを切る方向に流れがちです。

最初は緩めに始めて、サンドボックス違反のプロンプトが2〜3日溜まったログから頻出ドメインだけ恒久許可していく方が、結果的に摩擦が一番少ない運用に落ち着きました。

ハマりどころと回避策5パターン（kubectl/docker/npm/git/disable）

順調に使えると思いきや、特定のツールでつまづく場面が必ず出てきます。私が実際に遭遇した代表例と、その回避策を紹介します。

先に知っておくと無駄な30分を消費せずに済みます。

1ヶ月運用してみての体感ハマり頻度は、ざっくり kubectl > docker > npm/pip > git push > その他 という順番でした。

とくに最初の1週間は kubectl 関連で詰まる回数が圧倒的に多かったです。

kubectl を業務で使う方は、最初に ~/.kube の allowWrite だけでも先に書いておくと事故が一気に減ります。

Windows（WSL2）環境で、依存パッケージを入れたつもりでも /sandbox のパネルに「Dependencies」タブしか表示されず、モード選択タブが出てこないことがあります。公式ドキュメントでは、この状態は必須パッケージが足りないことを示し、依存チェックは起動時に行われるため、インストール後は Claude Code の再起動が必要と説明されています。

この場合はbubblewrap・socatの再インストールやwsl --shutdownでのWSL2再起動を試すか、それでも解消しない場合はDockerコンテナでの隔離運用に切り替えるのが現実的な回避策です。

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 を入れます。

「絶対にサンドボックス外には出させない」ポリシーを敷ける、ということです。チーム配布のテンプレートには入れておくと安心。

npm install・pip installが途中で止まる時のドメイン許可

npm や pip はインストール時に多数のドメインへ通信するため、デフォルトのネットワーク許可リストだと途中で止まりやすいです。

レジストリ本体だけでなくCDNやパッケージ配信サーバーにも繋ぎに行くので、芋づる式にプロンプトが出ます。

対処は allowedDomains に主要レジストリをまとめて入れておくのが手っ取り早いです。

npm系なら registry.npmjs.org、Python系なら pypi.org と files.pythonhosted.org をセットで指定すると、依存解決でほぼ止まらなくなります。

{
  "sandbox": {
    "network": {
      "allowedDomains": [
        "registry.npmjs.org",
        "pypi.org",
        "files.pythonhosted.org"
      ]
    }
  }
}

git pushがSSH越しに通らない時のexcludedCommands

gitのSSHリモート（git@github.com:user/repo.git など）で fetch・pull・push していると、サンドボックス内では通らないケースがあります。公式ドキュメントによると、macOSではホストを許可していてもSSHリモートへの接続が失敗します。Linux・WSL2では、allowedDomains にそのホストを（ポートを付けずに）許可すれば、22番ポートも含めて通ります。

解決策は2つ。1つは excludedCommands に git push * を入れてサンドボックス外で実行する方法。

もう1つは git のリモートURLを HTTPS 経由（https://github.com/user/repo.git）に切り替える方法です。

後者の方が隔離維持の観点では推奨で、HTTPSなら github.com のドメイン許可だけで完結します。

サンドボックスとDevContainer/Dockerはどう使い分ける？

「DevContainerで隔離すればいいじゃん」と思う方も多いと思いますが、両者は守備範囲が違います。サンドボックスは軽量・即起動、DevContainerは完全隔離・重量級。シーンで使い分けるのが正解です。

ローカル開発ならサンドボックスで十分なケース

普段のコード書き、bashコマンド、軽いビルド作業ならサンドボックスで事足ります。

起動オーバーヘッドがほぼゼロで、ホスト側のツール（VSCode・gitなど）とそのまま連携できるのが強み。

ホストの環境変数や鍵が見えるのを嫌う場合だけ、次のDevContainerに切り替える、という判断軸でいいと思います。

完全隔離が必要ならDevContainerに寄せる

未知のリポジトリを試す、サードパーティのMCPサーバーを動かす、信頼できないスクリプトを実行する、といった場面ではDevContainerが安心です。

コンテナごと使い捨てにできるので、汚染しても破棄すれば終わり。

サンドボックス＋DevContainerの二段構成も可能で、これだとほぼ要塞レベルの隔離になります。

ただ普段使いでは重いので、用途に応じて切り替えるのが現実的です。

体感ベースでは「サンドボックス単独 < サンドボックス + DevContainer」の順で重くなり、後者は起動だけで数秒〜十数秒余分にかかります。

編集サイクルが速いプロジェクトでは前者で十分というのが正直なところです。

なおサンドボックスランタイム自体は @anthropic-ai/sandbox-runtime としてnpm公開されており、Claude Code以外の独自エージェントやMCPサーバーの隔離にも流用できます。

npx @anthropic-ai/sandbox-runtime <command> の形で呼べるので、信頼度の低いツールを試したい時にも便利です。

よくある質問（FAQ）

記事を書くにあたって私自身も改めて調べた、よくある疑問をまとめておきます。1問1答で短くまとめたので、必要なところだけ拾い読みしてください。

Windowsでも使える？

ネイティブWindowsは2026年9月時点で非対応です（公式ドキュメントでは、ネイティブWindowsのコマンドはサンドボックスなしで実行されると説明されています）。WSL2経由なら使えるので、Windows環境ではWSL2を立てておくのが現実解。WSL1はサンドボックスに必要なカーネル機能が足りないため動きません。

既存の権限設定はそのまま活きる？

はい、permissionsの設定は引き続き有効です。サンドボックスはbashに対するOSレベルの追加防壁で、permissionsの代替ではありません。両方を併用する前提で設計されています。

Read/Edit/Computer Useにも適用される？

サンドボックスはbashツールとその子プロセスにだけ効きます。Read・Edit・Writeは従来どおりpermissionsで制御、Computer Useは実デスクトップ上で動くためアプリ単位の許可ダイアログで管理されます。

サンドボックス有効化でパフォーマンスは落ちる？

体感では誤差レベルです（オーバーヘッドの数値は公式に示されておらず、環境によって異なります）。ネットワークも許可リスト判定が入るだけなので、実質ほぼ等速で動きます。重いビルドや大量ファイル操作でもCPU待ち・I/O待ちのほうが支配的で、サンドボックス自体がボトルネックになることはまずありません。

複数プロジェクトで個別のサンドボックス設定を持てる？

持てます。プロジェクトルートの .claude/settings.json に書けばそのリポジトリ専用設定として効き、ユーザー設定の ~/.claude/settings.json がベース設定として使われます。filesystem.allowWrite のような配列の設定は、スコープごとに置き換わるのではなく、両方の内容が足し合わされます。「共通の許可はユーザー設定に、特定のリポジトリでだけ必要な許可はプロジェクト側に足す」という使い分けがしやすい構造です。

DevContainer内でさらにサンドボックスを使うのは意味ある？

二重隔離になるので攻撃面はさらに減ります。ただしオーバーヘッドも増えるため、通常の開発ではどちらか片方で十分です。未知リポジトリの試走・サードパーティMCPサーバーの実行・信頼できないスクリプト実行など「コンテナを汚されても困らないが、それでも安全側に倒したい」場面では両方使うのが現実解です。

まとめ：サンドボックスは「制限」ではなく「自由」のための仕組み

サンドボックスを使う前は、安全性を上げるとAIが動きにくくなる、というトレードオフを当然のものとして受け入れていました。

でも実際に使ってみると、安全と生産性は両立できるんだなと実感が変わりました。

境界を先に決めてしまえば、その中ではClaudeに自由にやらせられる。承認ダイアログにEnterを連打する自分とはもうサヨナラできます。

まずは /sandbox を打って自動許可モードを試すところから、気軽に始めてみてください。