Claude Codeのサンドボックス設計 — プロンプトインジェクションを前提に承認疲れを84% 減らす二層分離

背景 — なぜ「権限プロンプト」だけでは安全側に倒せないのか

AnthropicのEngineeringブログが2025年10月20日に公開した「Claude Code Sandboxing」は、Claude Codeに追加された2つのサンドボックス機能(ローカルの Sandboxed Bash Tool、クラウドの Claude Code on the web)の設計思想をまとめた記事です。著者はDavid DworkenとOliver Weller-Daviesで、Anthropic社内利用ベースで承認プロンプトを84% 安全に削減できたという実数値が公開されました。

この記事の重要性は、agenticな開発環境のセキュリティを「権限プロンプト主体」から「OSレベルの分離主体」へ寄せる方針を、Anthropic自身が明文化した点にあります。Claude Codeは元々、読み取りは広く / 書き込みと実行は都度承認という権限モデル(permission-based model)で動いてきました。ただしagentの自律実行が長くなるほど 承認疲れ(approval fatigue)が起き、「中身を確認せずにOKを押す」ことで実質的なセキュリティが下がる現象が、社内利用でも観測されていたと述べられています。

この問題を「OSレベルでファイルシステムとネットワークの境界を引く」サンドボックスで解く、というのが本記事の中核です。背景にあるのは、プロンプトインジェクション(prompt injection、外部入力経由でモデルの判断を奪取する攻撃)を検知ではなく封じ込みで対処するという設計判断です。

Claude Code全体のセキュリティモデル(権限 / サンドボックス / データ扱いの3層)についてはClaude Codeセキュリティ・権限ガイドで扱っており、本記事はそのうちサンドボックス層をEngineering blogの主張に沿って深堀りする位置付けです。

サンドボックスが引く2本の境界線

公式の主張は明快で、有効なサンドボックスにはファイルシステム分離とネットワーク分離の両方が必要だとしています。どちらか片方だけでは、攻撃者の選択肢が片方に閉じてしまうだけで、データ流出 / 権限昇格の経路は残ります。

ファイルシステム分離は「Claudeが触れるディレクトリ自体を制限する」境界で、プロンプトインジェクションが成立しても書き込みや読み取りの物理的な範囲が広がらないことを保証します。ネットワーク分離は「外部にデータを持ち出す経路 / 外部から悪性コードを引き込む経路」を物理的に絞る境界で、Claudeが侵害されても外向きの被害連鎖を断ち切る役割を持ちます。

公式の表現を引用すると、「侵害されたClaude CodeがSSH鍵を盗んだり、攻撃者のサーバに通報したりできない」状態を作るのが目的だとされています。検知や監視ではなく、そもそも到達できない構造を作るという発想です。

OSプリミティブの選択 — bubblewrapとSeatbelt

実装はOSの標準的なサンドボックス機能を使い分けています。記事内で言及されているのは以下の組み合わせです。

• Linux: bubblewrap(Flatpak が採用しているコンテナ的な隔離ツール)
• macOS: Seatbelt(sandbox-exec の元になっている、macOSの標準サンドボックスフレームワーク)

Dockerのような重量級コンテナを使わない選択は、開発者の体験を壊さないための判断と読めます。bubblewrapもSeatbeltも fork ベースで起動でき、コンテナイメージの管理 / プル / ボリューム設計といったオーバーヘッドが発生しません。Engineering blogはこれを「container management overheadが無い」と表現し、普段の開発フローに溶け込ませることを設計目標として明記しています。

重要なのは、サンドボックス境界は「Claude Code本体だけでなく、Claude Codeが起動する子プロセス全体」に効く点です。原文では「not just Claude Code's direct interactions, but also any scripts, programs, or subprocesses that are spawned by the command」と書かれており、npm install の中で動くフック、make の中で呼ばれるツール、テストランナーが起動するヘッドレスブラウザなど間接的に走るすべてが境界の中に閉じ込められることを意味します。

なおLinux / WSL2はbubblewrapが動きますが、WSL1はbubblewrapが動かないため対象外、ネイティブWindowsは計画段階だと、関連ドキュメントに記載があります。Claude Codeのネイティブバイナリ化とサンドボックス基盤の足場固めはv2.1.113で大きく進んでおり、本ブログの設計はその直後の動きとして読むと文脈が掴みやすいです。

ネットワーク制御をUnixドメインソケット越しのproxyで実装する理由

ネットワーク分離の実装は、シンプルなiptables / pfルールではなく、サンドボックスの外で動くproxy経由という構造になっています。記事内の説明では、サンドボックス内のプロセスから外向きの通信はUnixドメインソケットでproxyに流され、proxyがドメインルールに従って許可 / 拒否し、未知のドメインへのアクセスはユーザーに確認を求める設計です。

この選択には実用的な理由があります。

• 動的なドメイン許可: 「初めて見るドメインへのアクセスはプロンプトを出す」というUXを、ファイアウォール層では作りにくい。proxyなら接続イベントを掴んで会話に持ち込める
• 任意の許可ルール: ドメイン単位のallow / denyだけでなく、独自のフィルタ(社内プロキシ経由のみ、特定のHTTPメソッドだけ、など)をユーザー側で書ける拡張点になる
• TLSでも見える境界: 接続先ホスト名はSNI / DNSで見えるため、TLSの中身を覗かなくてもallowリストの判定が可能

プロセス内のDNS解決を奪わずにproxyに通すというのは、「悪意あるプログラムが直接IPを叩いてallowリストを回避する」攻撃に対抗するためにも有効です。原文ではこの拡張性を「customization support for arbitrary outgoing traffic rules」と表現しており、企業ごとのegressポリシーを統合できる余地が用意されているのが分かります。

機能1: ローカル向けのSandboxed Bash Tool

最初に紹介されているのは、ローカル環境で動くSandboxed Bash Toolです。これは「Claude Codeが Bash ツールを呼ぶときに、その実行をbubblewrap / Seatbeltの中に押し込む」軽量ランタイムで、研究プレビュー(beta)としてGitHubでオープンソース公開されています。

特徴をまとめると以下のようになります。

開発者目線で大きいのは、プロジェクトごとに「触ってよい場所と外向き先」を宣言的に書ける点です。settings.json の sandbox ブロックに filesystem.allowWrite と allowedDomains を書いておけば、Claudeが呼ぶBashと、その下で動くnpm / pnpm / make / pytestがすべて同じ境界の中で動くことになります。settings.jsonの各キーの詳細はClaude Code設定の完全ガイドに整理しています。

OSSとして公開する判断にも触れられています。原文では「他チームが構築しているagentのセキュリティ姿勢を改善するため」と説明されており、Claude Code専用の囲い込みではなく、agentエコシステム全体の安全側のデフォルトを引き上げる狙いが読めます。MCPサーバや別系のcoding agentでも、同じランタイムで境界を引ける構造になっていきそうです。

機能2: Claude Code on the web — クラウド側の隔離戦略

もう1つは、claude.com/code でアクセスできるClaude Code on the webです。こちらはユーザーのローカル環境ではなく、Anthropic管理のVMの中で完結する形のサンドボックスで、ローカル版とは異なる脅威モデルに合わせて設計されています。

注目したいのがGitの扱いです。Engineering blogは、Web版でGitをどう安全に動かすかについて、専用proxy越しの構造を採っていると説明しています。

[Sandbox 内の git]
       │  scoped credential
       ▼
[Custom Git Proxy]  ← 認証トークン / ブランチ名 / リポジトリ宛先を検証
       │  GitHub 用の本物のトークン付与
       ▼
[GitHub API]

ここでの工夫は、実際のGitHub認証情報をサンドボックスの中に入れないことです。サンドボックス内のGitは専用のスコープ付き資格情報でproxyに喋り、proxy側がリクエストを検証してから本物のトークンを付け替えてGitHubに転送します。

この構造の良さは3つあります。

1. 資格情報の流出防止: サンドボックス内のプロセスが何をしようと、生のGitHubトークンには到達できない
2. 書き込み先の強制: proxyが「許されたブランチ名 / リポジトリだけにpushを通す」と検証できる(例: main への直pushを弾き、work-* 系ブランチに限定)
3. 監査経路の一本化: すべてのgit操作がproxyを通るため、ログが集約され追跡可能になる

ローカルから直接GitHubを叩くモデルでは、トークン漏洩の影響は「ユーザーのアカウント全体」に広がりがちですが、ここではproxyが検証する分だけ被害範囲を狭められます。一方ローカル版のRemote ControlはWeb UIからローカルプロセスに繋ぐ別系統で、認証情報も実行も手元に残るため、Git proxyの保護対象はWeb版だけ、という棲み分けも明確です。

数値の読み解き — 84% という削減率は何を意味するか

記事内で公開されている定量結果は1行だけで、社内利用において承認プロンプトを84% 安全に削減できたというものです。短い数字ですが、agent開発の現場感覚に照らすと意味は重いです。

承認プロンプトの問題は数だけでなく判断疲労にあります。1セッションで何十回もプロンプトが出ると、ユーザーは内容を見ずにOKを押すようになり、結果的にセキュリティの最前線が崩壊します。サンドボックスは「境界内なら聞かない」「境界を超えるときだけ聞く」というメリハリを付けるための仕組みで、84% という数字は承認の意味を取り戻すための装置として読むのが妥当です。

このアプローチがagentセキュリティに何をもたらすか — 検知から封じ込みへ

Engineering blog全体に通底しているのは、プロンプトインジェクションを検知で防ぐのではなく封じ込みで吸収するという設計判断です。

検知ベースのアプローチ(モデルに「怪しい入力を見抜かせる」「フィルタで弾く」)は、攻撃者が新しい誘導文を作るたびに突破され得る、根本的に追いかけっこの構造になります。一方サンドボックスは「攻撃が成功してもできることが限られている」状態をOSで保証するため、プロンプトインジェクションの成功 / 失敗自体を気にしなくてよくなるという性質があります。

ここから読み取れるのは、Anthropicがagentセキュリティを以下の二段で考えていることです。

• 第1段(モデル / 権限): 既存の権限ルールと信頼検証で、まず怪しい指示を実行に持ち込ませにくくする
• 第2段(OS / 境界): それでも実行に至った場合、ファイルシステムとネットワークの境界で被害を物理的に止める

第1段だけだと「巧妙なインジェクションには勝てない」、第2段だけだと「全部聞きにいくか / 全部許すかの二択になり実用的でない」というそれぞれの弱点を、二段で打ち消し合う設計になっているのが要点です。サンドボックス層をオフにしたままの運用は、第1段だけに頼ることになるため、agentの自律性を上げるほど不利になります。

OSS公開という選択も、この文脈で読むと一貫しています。サンドボックスのランタイムをClaude Code専用に閉じ込めると、エコシステム全体では別のagentが「権限プロンプトに頼った設計」のまま留まり、結局ユーザーの開発環境に「サンドボックス無しagent」が混在することになります。OSSにすれば他社製agentも同じ境界に乗ってくる可能性が生まれ、エコシステム全体のベースラインが上がります。

実装上の注意点 — どこで境界が漏れるか

Engineering blog自体は脅威モデルと設計の主張に絞っていますが、関連ドキュメントの内容と合わせると、サンドボックスを過信しないために押さえておきたいポイントがいくつかあります。

• Bash引数フィルタとの混同: Bash(curl ... *) のような引数パターンでのURL制限は、変数経由や -X 差し込みで容易に回避されます。サンドボックスのドメイン制限と組み合わせ、curl / wget 自体はdenyに置く運用が安全寄りです
• docker / watchman のサンドボックス内挙動: これらはnamespaceの制約でサンドボックス内では動きません。excludedCommands で外に逃がすか、jest --no-watchman のような回避設定が必要です
• /var/run/docker.sock の許可: Unixソケット経由でdocker daemonに届くと、コンテナ起動経由で実質的にホストへ抜けられます。allowUnixSockets を緩めるとサンドボックスの意味が消える点は、関連ドキュメントが明示しています
• dangerouslyDisableSandbox の存在: 意図的なエスケープハッチがあり、企業運用では allowUnsandboxedCommands: false で封じる選択肢があります
• -p フラグでの非対話実行: 信頼検証(初回コードベース / 新規MCPサーバ)が無効化されるので、CIから呼ぶ場合はサンドボックス側で押さえる前提が必要です

これらはEngineering blogの主張と矛盾しないものの、「サンドボックスをonにしただけで完全に守れる」と読まないために知っておく価値があります。設定の具体例はClaude Codeセキュリティ・権限ガイドの3レイヤー推奨表、settings.json の各キーは設定の完全ガイドで扱っています。

まとめ — agentの自律性とセキュリティの「同時に上げる」設計

「Claude Code Sandboxing」は、agent開発のセキュリティモデルを権限プロンプトの追加からOS境界での封じ込めへ寄せるという方針転換を、設計と数値で説明した記事です。要点を4つに絞ると次のようになります。

1. 二層分離が前提: ファイルシステムとネットワークの両方を絞らないと、攻撃の経路が片方に残ってしまう
2. OSプリミティブの選択: bubblewrap / Seatbeltを使い、コンテナ管理オーバーヘッドなしで子プロセス全体を境界に収める
3. 承認プロンプトの84% 削減: 境界内は聞かずに通すことで、本当に確認すべきケースに注意力を集中させる
4. クラウド側はgit proxyで資格情報を分離: Claude Code on the webでは生のトークンをサンドボックスに入れず、proxyが認証 / 検証を集約する

この記事は「セキュリティを上げると自律性が下がる」というトレードオフを、境界を引き直すことで両立させようとしている点が興味深く、自社でagentを組む場合のリファレンスとしても示唆があります。Claude Codeを業務利用しているチームが今すぐ確認できる打ち手としては、/sandbox コマンドの有効化、settings.json の sandbox.enabled: true 化、allowedDomains のプロジェクト固有調整あたりが入り口になりそうです。Claude Code自体の全体像を改めて押さえたい場合はClaude Code完全ガイド2026を併読してみてください。