Claude Codeのサンドボックスを徹底解説！仕組みと設定・Windows対応も紹介
Claude Codeで作業を任せたいのに、確認のたびに手が止まる。かといって確認を全部オフにするのは怖い。その悩みに公式が用意した答えが、サンドボックスです。とはいえ、有効にしただけで安全になると誤解したまま使うと、かえって危険が残ります。
この記事では、Claude Codeのサンドボックスの仕組みとOSごとの対応状況を、非エンジニアにも読める言葉で解説します。設定方法と見落とされがちな落とし穴まで網羅した内容です。読み終えるころには、自分の環境で安全に自動化を任せる設定を組めます。結論から言うと、サンドボックスはAIの作業範囲をOSの力で囲う強力な仕組みです。ただし既定では読み取りがほぼ素通りのため、認証情報を守る設定まで含めて初めて安全になります。
Claude Codeのサンドボックスとは
まず全体像を以下の3つで押さえます。
- サンドボックスはAIの作業範囲をOSが強制する仕組み
- 導入の動機は確認の手間を安全に減らすこと
- 許可ルールとは役割が違う
サンドボックスはAIの作業範囲をOSが強制する仕組み
サンドボックスとは、AIが書き込めるフォルダと外部への接続を、OSの機能で物理的に制限する仕組みです。AIに与える作業部屋を用意し、部屋の外のファイルには触れられないようにする、と考えるとイメージしやすくなります。
重要なのは、AIの善意や指示の書き方に頼らない点です。外部から紛れ込んだ悪意ある指示が大事なファイルの削除を試みても、部屋の外の操作はOSのレベルで失敗します。約束ではなく壁で守る、これがサンドボックスの本質です。
導入の動機は確認の手間を安全に減らすこと
Claude Codeは既定で、コマンドの実行やファイルの変更のたびに確認を求めます。安全のための設計ですが、同じ確認を何度も返すうちに、確認そのものが作業の流れを止める要因です。
公式ドキュメントは、サンドボックスをコマンドごとに承認する仕組みではないと説明しています。触れてよいファイルと接続先を先に決めて、OSに守らせる仕組みです。境界を先に引けば、境界の中は確認なしで自動実行させられる形です。承認疲れを、安全性を落とさずに解消できる点こそ、導入の本当の狙いになります。
許可ルールとは役割が違う
サンドボックスとよく混同されるのが、許可ルール(permissions)です。両者は別の層で、役割が違います。許可ルールは、どのツールやコマンドを許すか・確認するか・禁止するかを決める判断の層です。一方サンドボックスは、その判断をすり抜けた操作も含めて、OSが物理的に止める強制の層になります。
公式も、権限ルールで判断の層を、サンドボックスでOSによる強制の層を作る多層防御を推奨しています。速さのためにサンドボックスを、機密の保護のために許可ルールを、と使い分けると整理しやすいでしょう。権限ルール側の詳しい設定は次の記事で解説しています。
Claude Codeの権限設定を徹底解説！自動承認を安全に使う方法も紹介
サンドボックスの仕組みとOS別の対応状況
技術的な土台は以下の3点です。
- OSごとに使う隔離技術が違う
- Windowsネイティブは非対応でWSL2を使う
- 有効化は/sandboxコマンドから行う
OSごとに使う隔離技術が違う
壁の実体は、OSが持つ隔離機能です。公式ドキュメントによると、macOSでは追加インストール不要で、標準搭載のSeatbeltが使われます。LinuxとWSL2ではbubblewrapを使うため、事前のインストールが必要です。
細かな技術名を覚える必要はありませんが、どのOSでもOSレベルの強制である点は共通です。macOSはそのまま使え、Linux系はひと手間かかる、と理解しておきましょう。
Windowsネイティブは非対応でWSL2を使う
Windowsを使う人が最初に確認すべき点です。公式ドキュメントは、サンドボックスがmacOS・Linux・WSL2で動作し、ネイティブWindowsは非対応だと明記しています。Windowsで使う場合は、Linux実行環境のWSL2の中でClaude Codeを動かすことになります。
Claude Code本体はWindowsにネイティブ対応していますが、サンドボックス機能だけはWSL2が必要な点が紛らわしいところです。サンドボックスを使いたいWindowsユーザーは、WSL2の導入が前提と覚えておいてください。導入自体の手順は次の記事にまとめています。
Claude CodeのインストールをWindows・Mac別に徹底解説！日本語対応も紹介
有効化は/sandboxコマンドから行う
有効化はセッション内で完結します。公式ドキュメントによると、Claude Codeを起動して/sandboxコマンドを実行すると、設定用のパネルが開く仕組みです。パネルには、承認方法を選ぶModeタブと、サンドボックスで失敗したコマンドを通常実行に戻すかを決めるOverridesタブがあります。Linuxでは不足パッケージを示すDependenciesタブも表示されます。
必要なパッケージが未導入でも、まず/sandboxを実行すればパネルが不足を教えてくれる親切設計です。難しい前提知識がなくても、画面の案内に沿って有効化できます。
サンドボックスで制御できる3つのこと
サンドボックスが守る範囲は以下の3つです。
- 書き込みは作業フォルダ内に限定される
- ネットワークは許可制になる
- 承認なしで実行できる範囲が広がる
書き込みは作業フォルダ内に限定される
1つ目は、ファイルへの書き込みの制限です。サンドボックスを有効にすると、書き込みは作業フォルダの中に限られ、その外のファイルは変更できなくなります。AIが誤って、あるいは悪意ある指示によって、関係のない場所のファイルを書き換える事故を防げます。
書き込みを許すフォルダは、設定で追加も可能です。既定の作業フォルダに加えて、特定の場所だけを書き込み可能にする、といった調整ができます。
ネットワークは許可制になる
2つ目は外部への通信です。公式ドキュメントによると、既定で事前許可されたドメインはなく、新しい接続先が必要になるたびにClaude Codeが承認を求めます。一度許可した接続先は、そのセッションの間は再確認なしで使えます。
この許可制が効くのは、情報を外へ持ち出す経路を絞れるからです。公式も、ネットワーク分離がなければ、侵害されたエージェントがSSH鍵のような機密ファイルを外部へ送り出しかねないと注意しています。書き込みの制限とネットワークの制限は、両方そろって初めて意味を持ちます。
承認なしで実行できる範囲が広がる
3つ目が、冒頭で触れた承認疲れの解消です。/sandboxのModeで自動許可を選ぶと、サンドボックスの境界の中で完結するコマンドは、確認なしで実行されるようになります。
ただし、見落としてはいけないのが、この自動許可の限界です。ファイルの分離を無効にしたまま自動許可にすると、サンドボックス内のコマンドが次に実行されるファイルを書き換え、自分の権限を広げる余地が残ると公式が注意を促しています。この場合、自動許可が安全なのは、書き込みとネットワークの分離が効いている前提のときだけです。
見落としやすい落とし穴【既定では読み取りが素通り】
多くの解説が触れない重要点は以下の3つです。
- 既定ではAWSの鍵やSSH鍵まで読める
- sandbox.credentialsで認証情報を塞ぐ
- 環境変数の認証情報はスクラブ機能で守る
既定ではAWSの鍵やSSH鍵まで読める
ここに最大の落とし穴があります。サンドボックスが制限するのは書き込みとネットワークが中心で、読み取りは既定でパソコン全体に及ぶ点が盲点です。公式ドキュメントは、この既定では~/.aws/credentialsや~/.ssh/のような認証情報ファイルも読めてしまうと明記しています。
つまり「サンドボックスを有効にしたから安全」という理解は危険です。有効化しただけでは、通帳にあたる認証情報は隠れていません。守るには、次に述べる追加設定が必要になります。
sandbox.credentialsで認証情報を塞ぐ
そこで使うのが、認証情報を守る専用の設定です。公式ドキュメントによると、sandbox.credentialsの設定で守りたいファイルや環境変数を個別に指定できます(Claude Code v2.1.187以降)。たとえば~/.aws/credentialsや~/.sshを読み取り禁止にし、GITHUB_TOKENのような環境変数をサンドボックス内のコマンドから消す、といった指定が可能です。
注意したいのは、組み込みの遮断リストが存在しない点です。公式も、指定したファイルと変数だけが制限されると明記しており、守りたいものは自分で列挙する必要があります。読み取りを塞ぎたいパスは、denyReadに追加する方法でも指定できます。
環境変数の認証情報はスクラブ機能で守る
サンドボックス内のコマンドは、既定で親プロセスの環境変数を引き継ぐ点にも注意が必要です。環境変数にAPIキーを入れている場合、AIが実行したコマンドからキーが見える状態になります。
CLAUDE_CODE_SUBPROCESS_ENV_SCRUBを設定すると、Anthropicとクラウド事業者の認証情報をすべてのサブプロセスから取り除けます。サンドボックスの有無に関わらず効く対策です。より柔軟に守りたい場合は、sandbox.credentialsのマスク機能で、値をダミーに置き換えつつ許可した接続先にだけ本物を送る高度な指定も可能です。
設定のカスタマイズ【settings.json】
より細かく制御する設定は以下の3つです。
- denyReadとallowReadで読み取り範囲を絞る
- allowedDomainsとstrictAllowlistで接続先を固定する
- managed settingsで組織全体に強制する
denyReadとallowReadで読み取り範囲を絞る
読み取りは、denyReadで禁止し、allowReadで一部を再度許可できます。公式ドキュメントの例では、ホームフォルダ全体をdenyReadで塞ぎ、作業フォルダだけをallowReadで開ける書き方が示されています。逆に、ホーム全体を読めるままにしつつ、~/.envだけをdenyReadで塞ぐ書き方も可能です。
読み取りルールが重なった場合は、より狭い範囲の指定が優先されます。広い許可の中に狭い禁止を置けば、その一点だけを確実に塞げる設計です。
allowedDomainsとstrictAllowlistで接続先を固定する
ネットワークは、allowedDomainsで事前に許可する接続先を列挙できます。githubのドメインやnpmのレジストリなど、業務で使う接続先を登録しておけば、毎回の確認は不要です。
さらにstrictAllowlistをオンにすると(Claude Code v2.1.219以降)、許可リストにない接続先は確認を挟まずに拒否される挙動になります。確認して許可するのではなく、リスト外は問答無用で遮断する、より厳格な運用です。広いドメイン許可はデータ持ち出しの経路になり得ると公式も注意しているため、接続先は必要最小限に絞るのが安全です。
managed settingsで組織全体に強制する
会社で使う場合は、管理者が配布するmanaged settingsでサンドボックスの設定を強制できます。公式ドキュメントによると、managed settingsでファイルシステムの設定や認証情報の遮断を指定すると、その項目は利用者側では緩められなくなります。
個人の判断に任せず、認証情報の保護を組織のルールとして技術的に固定できる点が、法人利用での価値です。社内展開の全体像は次の記事で解説しています。
Claude Codeの社内利用ルールを徹底解説！商用利用の規約と設定配布も紹介
Dockerなど他の隔離との使い分け
隔離手段の選び方は以下の3つで整理できます。
- ネイティブのサンドボックスは標準装備の鍵
- Dockerや仮想マシンは本格的な隔離工事
- サンドボックスは万能ではないと理解する
ネイティブのサンドボックスは標準装備の鍵
Claude Codeに組み込まれたサンドボックスは、追加のツールなしで(macOSなら)すぐ使える手軽さが利点です。日常の開発で、承認疲れを減らしつつ基本的な事故を防ぐ用途には、これで十分に足ります。
家にたとえるなら、標準で付いている鍵にあたります。まずはこの鍵をきちんとかけ、認証情報を守る設定を足すのが、多くの人にとっての現実的な出発点です。
Dockerや仮想マシンは本格的な隔離工事
一方、より強固な隔離が必要な場面では、Dockerコンテナや仮想マシンを使います。信頼できないコードを扱う場合や、確認をすべて外して全自動で回したい場合に公式が推奨するのは、隔離された環境の利用です。
こちらは、業者を呼んで行う本格的な隔離工事にあたります。CIやチームの自動処理など、強い隔離が要る用途で選ぶ手段です。なお、Dockerコンテナの中でネイティブのサンドボックスをそのまま動かすには追加の設定が要る場合があり、コンテナ側で隔離を固めたうえで内側は制限を緩める二重構造になります。
サンドボックスは万能ではないと理解する
最後に、限界の正しい理解が欠かせません。公式ドキュメントによれば、サンドボックスはセキュリティ境界ではなく、あくまで防御の一層です。たとえばUnix socketの許可を誤れば、Dockerのソケット経由でホストにアクセスされ、サンドボックスを抜け出される恐れがあると具体的に警告しています。
つまりサンドボックスは、油断してよい万能の壁ではありません。既定の許可制・認証情報を守る設定・信頼できないコードを扱わない運用と組み合わせて、多層で守るのが正しい使い方です。
Claude Codeのサンドボックスに関するよくある質問
迷いやすい点への回答は以下の3つです。
- Windowsで使うにはどうすればよいですか？
- サンドボックスを有効にすれば全部安全ですか？
- CodexやChatGPTのサンドボックスと違いますか？
Windowsで使うにはどうすればよいですか？
WSL2の中でClaude Codeを動かしてください。サンドボックス機能はネイティブWindowsに対応しておらず、macOS・Linux・WSL2で動作します。WSL2はWindowsに公式に用意されたLinux実行環境です。WSL2の中で使えば、Linuxと同じ仕組みでサンドボックスが働きます。
WSL2を使わない場合でも、Claude Code本体は動きますが、サンドボックスによる自動化の恩恵は受けられません。その場合は、許可ルールとこまめな確認で安全を保つ運用に切り替えましょう。
サンドボックスを有効にすれば全部安全ですか？
いいえ、有効化だけでは不十分です。既定では読み取りがパソコン全体に及び、AWSの鍵やSSH鍵まで読めてしまいます。sandbox.credentialsやdenyReadで認証情報を塞ぎ、ネットワークを許可制で絞って、初めて実用的な安全になるのです。
公式自身も、サンドボックスは防御の一層でセキュリティ境界ではないと明記しています。過信せず、複数の守りを重ねる前提で使ってください。
CodexやChatGPTのサンドボックスと違いますか？
土台の技術は似ています。OpenAIのCodexも、macOSではSeatbeltを使い、Linuxでは同系統の仕組みでサンドボックスを実現しています。考え方は共通です。大きな違いは位置づけです。Codexはサンドボックスが標準の前提として常に働きます。一方のClaude Codeは許可ルールが基本で、サンドボックスは必要に応じて有効化する多層防御の一枚です。
両ツールを併用する場合も、この違いを押さえておけば混乱しません。Codex側の仕組みは次の記事で解説しています。
Codexのサンドボックスを徹底解説！自動承認を安全に使う設定も紹介
Claude Codeのサンドボックスは認証情報を守る設定まで含めて安全になります
Claude Codeのサンドボックスは、AIが書き込めるフォルダと接続先をOSの力で囲う、強力な安全の仕組みです。macOSはそのまま使え、LinuxとWSL2はbubblewrapの導入が必要です。/sandboxコマンドで有効化すれば、書き込み・ネットワーク・自動実行の3点を制御できます。
ただし既定では読み取りが素通りで、認証情報ファイルまで読めてしまう点が最大の落とし穴です。sandbox.credentialsやdenyReadで認証情報を塞ぎ、strictAllowlistで接続先を固定します。Dockerとの使い分けと限界の理解まで含めて、多層で守るのが正解です。まずは/sandboxで有効化し、~/.awsと~/.sshを塞ぐ設定から始めましょう。
