Claude Codeのsandbox設定ガイド: 守る操作と守らない操作の判定と検証

Claude Codeのサンドボックス(sandbox)は何のための仕組みで、Dockerとは何が違うのか?

Claude Codeのサンドボックス(sandbox)は、Bashコマンドとそのサブプロセスを、OSの機能でファイルと通信先の両面から制限する仕組みです。承認プロンプトの多さを減らすことと、自律実行で何かが起きたときの影響範囲を狭めることが目的で、Claude Code自体をコンテナに閉じ込めるDockerとは別の層にあたります。

出典は公式 sandboxing(https://code.claude.com/docs/ja/sandboxing)です。設定名や挙動は更新で変わりうるため、本稿のキー名や例は実際に設定する前に現行の記載と照合してください。本稿で「記載あり」と断定するのは、公式で確認できた点だけです。確認できていない点は「未確認」と書きます。

sandboxが解決する2つの困りごと

1つ目は承認の多さです。コマンドごとに許可を求められると、内容を読まずに承認を押す状態になりがちです。範囲を先にOS側で区切っておけば、その範囲内のコマンドは確認なしで進められます。

2つ目は影響範囲です。指示が曖昧だったり、取り込んだ文書に不審な指示が混じっていたりしても、書き込める場所と届く通信先が限られていれば、被害が及ぶ範囲も限られます。

Docker隔離とは別の層

Dockerなどのコンテナは、Claude Code全体を別の環境に置く方式です。sandboxは普段の環境のまま、Bashが触れるファイルと通信先だけをOSが絞ります。どちらか一方を選ぶ関係ではなく、守る単位が違います。コンテナ側の手順はClaude CodeをDockerで動かす方法、モードごとの違いは権限モードの解説、権限ルール全般はセキュリティ設定の解説が扱うため、本稿ではsandboxの設定と検証に絞ります。

sandboxが守る操作と、守らない操作の境界

境界は「Bashとそのサブプロセスか、それ以外か」です。Bashで動くコマンドと、そこから起動される子プロセスはsandboxの対象です。ReadやEditなどClaudeのファイルツールは、sandboxではなく権限システム側で扱われます。

表の読み方と、自分の作業を当てはめる3ステップ

「公式の記載」列は、記載あり、未確認の2区分です。最右列は読者が自分の作業に当てはめて埋めます。

操作	守る層	公式の記載	自分の作業での判定
Bashで直接実行するコマンド	sandbox	記載あり	(記入)
Bashから起動されるサブプロセス(パッケージマネージャーやビルドツールなど)	sandbox	記載あり	(記入)
ReadやEditなどのファイルツール	権限システム	記載あり	(記入)
WebFetchなどの通信系ツール	権限システム側の可能性	未確認	(記入)
MCPサーバー経由の操作	不明	未確認	(記入)
フックで実行されるコマンド	不明	未確認	(記入)

進め方は3ステップです。

普段の作業で実行する操作を、上の表に1行ずつ書き出す。
各行がBash経由かどうかを見て、守る層を決める。
層が決まらない行は「未確認」のまま残し、確認が取れるまで守られている前提にしない。

「未確認」の行をどう扱うか

未確認の操作を、仕組みから推測して「たぶん守られる」と判断するのは避けます。確認する方法は2つあります。公式ページの該当箇所を読み直すか、後述の検証手順と同じ要領で試すかです。試すときは捨てても困らないファイルとディレクトリを使います。結果は表の最右列に日付つきで残しておくと、更新後に見比べられます。

有効化の手順とOSごとの違い

有効化はClaude Code内の /sandbox コマンドで行います。実装はOSで異なり、macOSはSeatbelt、Linuxとwsl2上ではbubblewrapが使われます。WSL1は対象外です。

有効化の手順

Claude Codeを起動した状態で /sandbox を実行し、表示されるメニューからモードを選びます。選択肢は後述の自動許可の有無と対応しています。基盤にはオープンソースの @anthropic-ai/sandbox-runtime(srt)があり、sandboxの部品を単体で使う場合の入口にもなります。本稿は組み込み機能の設定に絞ります。

OS別の前提

OS	実装	追加の準備
macOS	Seatbelt	OS標準の仕組みを使う。追加導入の要否は未確認
Linux	bubblewrap	bubblewrapが必要。ほかの前提パッケージの有無は未確認
Windows(WSL2)	bubblewrap	Linuxと同様
Windows(WSL1)	非対応	WSL2への切り替えが必要

Windowsでの導入ルートはWindows版の導入ガイドにまとまっています。

ファイルの書き込みと読み取りの範囲

既定では、書き込みは作業ディレクトリ配下が中心で、読み取りは広めに許される設計です。そこに許可パスと拒否パスを足して、自分の作業に合わせて狭めたり広げたりします。

判断軸: 何を守りたいか

出発点は設定キーではなく、守りたい対象です。

機密情報の置き場(認証情報、秘密鍵のあるディレクトリ)を読ませたくないのか
プロジェクト外への書き込みを止めたいのか
特定の設定ファイルを書き換えられたくないのか

読ませたくないものは読み取り制限、書かせたくないものは書き込み制限、というように、守りたい対象から使う設定が決まります。

設定例

次は形の例です。スコープごとのマージの扱いは本稿では未確認のため、使う前に現行の記載と照らしてください。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/work/shared-output"],
      "denyRead": ["~/.ssh"]
    }
  }
}

設定ファイルの置き場所と優先順位はsettings.jsonの解説を参照してください。

自分の作業に必要な書き込み先の洗い出し方

先に許可を広く入れず、最小の状態で作業して、拒否された書き込み先を1つずつ記録します。ビルド成果物、キャッシュ、一時ファイルなど、作業のたびに必要になるものだけを残し、理由を一言添えておきます。これは通信先の許可を足すときも同じ進め方です。

通信先は許可ドメインで決まる

通信はOS側でプロキシ経由に絞られ、許可されたドメインにだけ出られます。許可にないドメインへの接続が発生すると、Claude Codeが確認を求める動きになります。

許可ドメインの書き方

ドメイン単位で許可を持たせる形です。例は次のとおりです。

{
  "sandbox": {
    "network": {
      "allowedDomains": ["registry.npmjs.org", "github.com"]
    }
  }
}

カスタムプロキシを併用する場合は、通信の経路が変わるため挙動も変わりえます。変わり方の詳細は本稿では未確認です。

許可が持つ意味と限界

ドメインを許可するとは、そのドメインへの通信を許すという意味です。許可したドメインが外部からデータを受け取れるサービスなら、そこへ情報を送り出す経路にもなりえます。許可は「必要だから」だけでなく、「そこへ何が送れるか」も見て足してください。

自動許可とフォールバックの選び方

迷ったら、まず自動許可なしの通常モードでフォールバックを禁止した状態から始めるのが安全側です。そこから、作業の性質に応じて自動許可やフォールバックを段階的に足します。

判断軸

作業の性質: 定型的なビルドやテストが中心か、未知のコマンドを多く試すか
失敗時の影響: sandbox外で実行されて困るものがあるか
見張れるか: 実行中に画面を見ていられるか、放置して任せるか

選択肢の比較表

組み合わせ	sandbox内のコマンド	sandboxで動かないコマンド
通常モード × フォールバック禁止	通常の承認の流れ	sandbox外では実行されない
通常モード × フォールバック許可	通常の承認の流れ	承認のうえsandbox外で再実行されうる
自動許可 × フォールバック禁止	確認なしで実行	sandbox外では実行されない
自動許可 × フォールバック許可	確認なしで実行	通常の権限の流れに戻る

フォールバックの禁止は、設定で「sandbox外での実行を求める指定」を無視させる形で表現されます。この設定のキー名は本稿では未確認です。

迷ったときの出発点

公式の記載範囲では、自動許可は「sandboxで囲われているから確認を省ける」という考え方です。囲いの設定が甘いまま自動許可を入れると、省かれた確認の分だけ見落としが増えます。先にファイルと通信先を決め、検証してから自動許可を検討する順番がよいでしょう。

動かないコマンドはsandboxのせいか、どの許可を足すか

sandboxの拒否表示が出ているなら、足すべきものは書き込み先、通信先、sandbox対象外にするコマンドのいずれかです。拒否表示で判別できる症状だけを扱い、それ以外の一般的なエラーはエラー対処の解説に任せます。

sandbox由来かどうかの見分け方

コマンド自体の失敗(構文、依存の不足など)と、権限の拒否は別物です。拒否表示に書き込みの禁止や接続の拒否が含まれていれば、sandboxを疑います。判別できなければ、一時的にsandboxの対象外で同じコマンドを実行して差を見る方法があります。

逆引き表

症状	起きていること	足す許可
作業ディレクトリ外への書き込みが拒否される	書き込み先が許可パスにない	必要なパスだけ書き込み許可に追加
未許可ドメインへの接続が拒否される、または確認が出る	通信先が許可ドメインにない	必要なドメインだけ追加
dockerがsandbox内で動かない	sandbox内で動かない場合がある(現行の公式記載との対応は未確認)	sandbox対象外のコマンドとして指定する(書き方は未確認)

gitやssh、watchmanなどの個別コマンドの挙動は、一次資料で確認できた範囲に限るため、表には載せていません。

sandboxが効いているかの確認手順

次の3つを試します。未許可パスへの書き込みが拒否され、未許可ドメインへの通信が拒否され、許可済みの操作が通るなら、基本の制限は働いています。以下の期待結果は、前提を固定した場合のものです。

判定の軸を先に固定してから結果を見る、という考え方は、筆者側の運用でも使っています。2026年9月21日時点で、ブログ記事生成エンジンの最終ゲートは intent、primary、news、gain、unique、diversity、voice の7軸を要求します。gain は検索上位の共通論点を再整理しただけの記事を通さず、本文に具体的な情報増分があるかを判定します。gain が失敗した記事は局所改稿せず隔離します。sandboxの確認も、見る項目を先に決めておけば、結果の良し悪しを後から都合よく読まずに済みます。

前提を固定した確認手順

前提は、フォールバック禁止、通常モード(自動許可なし)、カスタムプロキシなしです。プロジェクトのディレクトリで、Claude Codeに次を実行させます。

# 1. 未許可パスへの書き込み(作業ディレクトリ外)
echo test > ~/sandbox-write-test.txt

# 2. 未許可ドメインへの通信
curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://example.com

# 3. 許可済みの操作(作業ディレクトリ内への書き込み)
echo ok > ./sandbox-ok.txt

項目	期待される結果(上記の前提)
1	書き込みが拒否される
2	接続が拒否される、または許可の確認が出る
3	成功する

終わったらテスト用ファイルを削除します。example.com を既に許可している場合は、別のドメインに差し替えてください。この手順の結果を具体的な画面表示として載せていないのは、表示の文言がバージョンで変わりうるためです。

前提を変えると結果が変わる点

変えた前提	結果への影響
フォールバックを許可	拒否されたコマンドが承認のうえsandbox外で再実行されうる
自動許可モード	確認の出方が変わり、sandbox内の操作は確認なしで進む
カスタムプロキシを併用	通信の経路が変わり、結果が変わりうる

想定と違ったときの戻り先

書き込みが通ってしまうなら、ファイルの節で許可パスを見直します。通信が通ってしまうなら、通信先の節の許可ドメインを確認します。確認の出方が想定と違うなら、自動許可とフォールバックの節に戻ります。Claude Codeを更新したあとは、同じ3項目を再実行すれば挙動の変化を比べられます。

まとめ: 今日どこまで設定すれば足りるのか

最小の出発点は3つです。

自分の作業を判定表に当てはめ、sandboxが守る操作とそうでない操作を分ける。
書き込み先と通信先を、拒否されたものを見ながら必要最小限だけ許可する。
前提を固定した3項目の確認で、効いていることを確かめる。

設定名や挙動は更新で変わる可能性があるため、公式の現行記載に戻って照らし合わせる習慣が、そのまま安全側の運用になります。

判定表を自分の環境で埋め、更新のたびに確認を繰り返す作業は、一度で終わらず続きます。自分の手で使えるようになるために学び続けられる場として、学習コミュニティ「AI駆動ラボ」があります。月額1,980円からの学習コミュニティです。