Claude Code サンドボックス

問題: ディスクとネットワークへのフルアクセスを持つ AI エージェントは、無視できないリスクです。npm install を実行するたびに、見知らぬ人が書いたコードがダウンロードされます。すべてのビルドスクリプトはあなたのフルユーザー権限で動作します。プロンプトインジェクションが成功すれば、攻撃者はあなたと同じ権限を手に入れます。壁がない状態では、悪意のある依存関係が SSH キーを読み取り、環境変数を外部に送信し、シェルの設定ファイルをこっそり書き換える可能性があります。

Claude Code のサンドボックスはその扉を閉じます。ファイルシステムとネットワークの制限をカーネルレベルまで押し下げるため、ルールは信頼やプロンプトの文言に依存しなくなります。

クイックセットアップ: 次のコマンド一つでサンドボックスを今すぐ有効にできます。

> /sandbox

サンドボックスモードを選ぶメニューが表示されます。macOS ではすでに利用可能です。Linux または WSL2 の場合は、まず bubblewrap と socat の 2 つのパッケージをインストールする必要があります（手順は以下を参照）。

許可プロンプトだけでは不十分な理由

Claude Code をある程度使っていると、おなじみのパターンに気づきます。Claude がコマンドを実行したい。承認。Claude がファイルを書き込みたい。承認。Claude がテストを実行したい。承認。30 回クリックするうちに、一つ一つのプロンプトを読まずにただ承認し続けるようになります。

これが承認疲れです。安全機能のふりをしたセキュリティ上の問題です。

プロンプトが多いほど、一つひとつへの注意は薄れます。セキュリティ UX の研究では同じ結果が繰り返し示されています: 繰り返されるダイアログは、人々をクリックしてしまうよう訓練します。二重の損失です。フローは中断され、保護は低下します。

サンドボックスはモデルを反転させます。各ステップで「このアクションを実行してよいか?」と問う代わりに、フェンスを一度設置します。読み取りはここで行える。書き込みはここで行える。ネットワークはここまで届ける。フェンスの内側では何もプロンプトしません。外側では、ダイアログではなく OS がアクションを停止します。

見返りは、中断の減少、防御の強化、そして既知の安全な範囲内で自律的に動けるエージェントです。

Claude Code サンドボックスの仕組み

2 つの分離レイヤーが並行して動作します。両方が重要です。どちらか一方を取り除くと、残ったレイヤーにトラックが通り抜けられるほどの穴が開きます。

ファイルシステムの分離

サンドボックス化された bash ツールは、ファイルアクセスを短いディレクトリリストに限定します。

• 書き込みは作業ディレクトリとその配下に限定されます
• 読み取りは、拒否マークが付けられたパスを除いてシステム全体をカバーします
• ツリー外の編集は、明示的に権限を付与しない限り失敗します
• カスタムパスはサンドボックス設定で追加のディレクトリを開閉できます

実際には Claude はプロジェクトファイルを読み取り、リポジトリ内のコードを編集しますが、~/.bashrc、/usr/local/bin、~/.ssh の内容は手が届かない状態のままです。これらの壁を越えて書き込もうとする悪意のある npm パッケージは OS 自体によってブロックされます。

ネットワークの分離

アウトバウンドトラフィックはサンドボックスの外部に存在するプロキシサーバーを経由してルーティングされます。

• ドメイン許可リストは、プロセスがアクセスできるホストを制限します
• 不明なドメインは許可プロンプトを表示するため、新しいホストはすべてあなたの前に現れます
• 継承された制限はすべての子プロセスに引き継がれるため、ビルドスクリプトが生成したシェルもルールを逃れられません
• カスタムプロキシを使えば、企業がサンドボックストラフィックを独自の検査パイプラインに送れます

ファイルシステムの壁だけでは穴があります。乗っ取られたエージェントが、攻撃者が制御するホストにソースコードを送り出す可能性があります。ネットワークの壁だけでも逆の穴があります。両方のレイヤーを並行して実行しなければなりません。設計はその前提に基づいています。

カーネルレベルでの強制

サンドボックスはアプリレイヤーのチェックに依存しません。巧みなエクスプロイトはそれらを常に迂回できます。実際に機能するのは、カーネルセキュリティプリミティブのセットです。

• macOS: Seatbelt。Apple が App Store アプリの分離に使うフレームワーク
• Linux: bubblewrap (bwrap)。Flatpak の基盤となる小型の非特権サンドボックスツール
• WSL2: bubblewrap。ネイティブ Linux と同様

WSL1 は対象外です。bubblewrap には WSL2 のカーネルが提供するユーザー名前空間とマウント名前空間が必要です。Windows ネイティブビルドは計画中ですが、まだリリースされていません。

サンドボックス化されたコマンドが生成するすべての子プロセスは同じ制限を継承します。サンドボックス内で npm install を実行すると、postinstall フックも同じようにサンドボックス内に閉じ込められます。

前提条件とインストール

macOS

追加のインストールは不要です。サンドボックスは OS にすでに組み込まれている Seatbelt フレームワーク上でそのまま動作します。/sandbox と入力してモードを選択してください。

Linux および WSL2

2 つのパッケージが必要です。bubblewrap がファイルシステムの分離を担い、socat がネットワークプロキシの配管を処理します。

Ubuntu/Debian:

sudo apt-get install bubblewrap socat

Fedora:

sudo dnf install bubblewrap socat

インストール後、Claude Code で /sandbox と入力します。依存関係がまだ不足している場合、メニューにプラットフォームに合ったインストール手順が表示されます。

サンドボックスモード: 自動許可 vs 通常の権限

2 つのモードがあります。ファイルシステムとネットワークの壁はどちらも同一です。異なるのは、サンドボックス化されたコマンドがあなたのクリックを必要とするかどうかです。

自動許可モード

bash コマンドがサンドボックス下で実行を試み、適合すれば事前に何も尋ねません。同じコマンドが許可リストにないホストへのアクセスを必要とする場合は、通常の許可フローが起動します。設定済みの確認・拒否ルールは引き続き適用されます。

ほとんどのビルダーはこのモードを望むでしょう。エージェントはフェンスの内側で最大限の自由を持ち、プロンプトはフェンスを越えるものがある場合にのみ表示されます。

一つ注意点があります。自動許可は権限モードとは独立して動作します。「編集を受け入れる」がオフになっていても、サンドボックス化された bash コマンドは自動許可がオンの場合、プロンプトなしで実行されます。Edit ツールによるファイル編集は通常の権限ルールに従い続けます。サンドボックス内の bash のみが対象です。

通常の権限モード

すべての bash コマンドは、サンドボックス化の有無にかかわらず、通常の権限ダイアログを経由します。壁は維持され、各コマンドも最初に確認を求めます。

コマンドごとのレビューを維持しつつサンドボックス保護が必要な場合に選択します。厳格な環境や、新しいサンドボックス設定を調整する最初の数日間に適しています。

サンドボックスの設定

サンドボックスの動作は settings.json で調整します。動作する設定例は次の通りです。

{
  "sandbox": {
    "mode": "auto-allow",
    "allowedDomains": ["registry.npmjs.org", "api.github.com", "pypi.org"],
    "network": {
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  }
}

主要な設定

mode: "auto-allow" または "regular" に設定します。このフラグでサンドボックス化されたコマンドが自動実行されるか、クリック待ちになるかが決まります。

allowedDomains: bash が確認なしにアクセスできるホスト一覧。新しいドメインにアクセスするとプロンプトが表示され、承認するとそのドメインがこのリストに追加されます。

allowUnixSockets: ソケットアクセスを制御します。注意が必要です。/var/run/docker.sock を許可することは、Docker API を通じてホストへのパスを開くことと同義で、サンドボックスの壁を回避します。

allowUnsandboxedCommands: デフォルトは true。サンドボックスルールがコマンドを強制終了すると、Claude は確認後にそのコマンドをサンドボックス外で再実行することがあります。再試行パスを無効にするには false に設定します。

excludedCommands: サンドボックスを常にスキップするコマンドのリスト。docker のように協調しないツールに有効です。

enableWeakerNestedSandbox: 非特権 Docker セットアップ向けの Linux 専用オプション。壁を弱めるため、外部コンテナが独自の分離を行っている場合にのみ使用します。

権限とサンドボックスの関係

権限とサンドボックスは、互いを補完する 2 つの独立したセキュリティレイヤーです。

権限は Claude Code がどのツールにアクセスできるかを決定します。ツール呼び出しより前に実行され、Bash、Read、Edit、WebFetch、MCP ツールなどすべてのツールに適用されます。

サンドボックスは OS レベルで強制され、Bash コマンド（またはそのサブプロセス）がファイルシステムとネットワークで何をできるかを制限します。

多層防御として考えてください。第一ゲート: このツールは許可されているか? 第二ゲート: 実行されたとき、どこまで届くことができるか?

セキュリティ上の利点

プロンプトインジェクションへの対策

プロンプトインジェクションは AI エージェントにとって現時点で最大のリスクです。攻撃者がファイル、README、または Web ページの中に指示を隠します。Claude はそれをあなたが書いたかのように読み取り、攻撃者のコマンドを実行し始めます。

サンドボックスがオンであれば、インジェクションが成功しても硬い壁に直面します。

ファイルシステム保護:

• ~/.bashrc や ~/.zshrc などのシェル設定ファイルはアクセス禁止
• /bin/ や /usr/local/bin/ 配下のシステムバイナリは変更不可
• 権限ルールで拒否マークが付いたパスは読み取り不可

ネットワーク保護:

• 攻撃者が制御するサーバーへのデータ送信は不可
• 不明なドメインからの悪意のあるスクリプトのダウンロードは不可
• 承認していないサービスへの API 呼び出しは通らない
• 許可リストにないドメインには到達できない

攻撃対象領域の縮小

インジェクション以外にも、サンドボックスは日常的なリスクによるダメージも軽減します。

• 悪意のある依存関係: postinstall に悪意のあるロジックを隠した npm、pip などのライブラリ
• 壊れたビルドツール: 独自の脆弱性を持つビルド時ユーティリティ
• ソーシャルエンジニアリング: ユーザーが騙されて実行した危険なコマンド
• サプライチェーン攻撃: 改ざんされたアップストリームパッケージがインストール時にコードインジェクションを引き起こす

知っておくべき限界

完璧なサンドボックスはありません。壁にどこに隙間があるかを明確にすることが、現実的な脅威モデルを選ぶための基盤です。

ドメインフロンティング

ネットワークフィルターはドメインを選択しますが、深いパケット検査は行いません。トラフィックがあるホストに向かうように見えて実際には別のホストに届くドメインフロンティングは、一部のケースでドメインフィルターを回避できます。

Unix ソケットのエスカレーション

allowUnixSockets は強力なアクセスを静かに付与する可能性があります。/var/run/docker.sock を許可すると、サンドボックス化されたプロセスは Docker API 全体を手に入れ、実質的にホストへのアクセスを意味します。

ファイルシステム権限のエスカレーション

書き込みが緩すぎるとエスカレーションの経路を提供します。$PATH 上のバイナリを含むフォルダ、システム設定ディレクトリ、またはユーザーシェルの設定ファイルへの書き込みを許可すると、別のセキュリティコンテキストでコードが実行される可能性があります。

実践的なヒントと互換性

Docker は相性が悪い

Docker コマンドはサンドボックス下では動作しません。Docker デーモンへの直接接続が必要だからです。docker を excludedCommands に追加して、常にサンドボックス外で実行されるようにしてください。

Watchman も相性が悪い

Facebook の watchman ファイルウォッチャーはサンドボックス化されたプロセスと協調しません。Jest を実行する場合は --no-watchman フラグを追加してください。

脱出ハッチ

サンドボックス化されたコマンドが壁自体によって失敗することがあります。Claude は失敗を分析し、dangerouslyDisableSandbox で再試行することを提案できます。その再試行はサンドボックス外で実行され、通常の権限フローによる承認が必要です。

企業向けカスタムプロキシ設定

より深いネットワークセキュリティニーズを持つ組織は、検査、ロギング、セキュリティスタックとの統合のために、サンドボックストラフィックを独自のプロキシに通すことができます。

その利点は以下の通りです。

• HTTPS トラフィックの終端と検査
• 単純なドメインブロック以上のルールの適用
• すべてのアウトバウンドリクエストの監査ログへの記録
• サンドボックスを既存の SIEM やセキュリティスタックと統合
• マネージド設定スコープで組織全体のルールを展開

オープンソースサンドボックスランタイム

ランタイムは独自の npm パッケージとしてオープンソースで提供されています。任意のエージェントプロジェクトに組み込めます。Claude Code は不要です。

npx @anthropic-ai/sandbox-runtime <command-to-sandbox>

ソースコードは github.com/anthropic-experimental/sandbox-runtime でホストされています。

最初のサンドボックスを設定する

ゼロから動作する設定に至るまでの実践的な手順です。

1. 依存関係を先に（Linux/WSL2 のみ）: sudo apt-get install bubblewrap socat
2. Claude Code で /sandbox と入力してメニューからモードを選択
3. auto-allow を選択。安全性とスピードのバランスを取りたい場合
4. 通常通り Claude を使用し、プロンプトが求める新しいドメインを承認する
5. 1、2 セッション後に設定を見直し、ドメインリストを確認する
6. 不要なものを削除して古いドメインを取り除く

厳しく始める。必要になったときだけ緩める。ルールを緩めることは、最初からなかったルールの後始末よりはるかに安上がりです。