Claude Codeサンドボックス: 本番環境でClaude Codeを隔離、制約、保護する方法

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
はじめに
Claude Codeは、ファイルの読み取り、コードの記述、シェルコマンドの実行、ネットワークリクエストの送信、外部ツールの呼び出しが可能です。開発者のラップトップでは、その自律性がまさに利点です。しかし、企業パイプラインにおいては、明確な境界線が必要な脅威の表面となります。
Claude Codeのサンドボックス化とは、制約された実行環境内でClaude Codeを実行することを意味します。ファイルシステムへのアクセス、ネットワークからのデータ送信、プロセス実行、ツール利用のすべてが、明示的に定義され、制限されます。このステップを怠ると、システム全体にアクセスできる自律型エージェントが、たった1つの不正な命令で重大なインシデントを引き起こす可能性があります。
Anthropicはこのことを認識しています。2025年10月、彼らはOSレベルのプリミティブに基づいて構築されたClaude Code用のネイティブサンドボックス機能をリリースしました。 Linux bubblewrapとmacOS Seatbelt。内部テストでは、権限プロンプトが84%削減されたことが示されました。この技術は機能します。しかし、ネイティブサンドボックス化は、企業チームが必要とするものの一部しかカバーしていません。コンテナレベルの分離、ネットワークからのデータ送信制御、認証情報の範囲設定、監査ログは、単一のCLIフラグでは対応できないインフラストラクチャの決定を必要とします。
ここでは、ファイルシステム、シェル、ネットワーク、外部ツールの4つの封じ込め対象について説明します。さらに、実際に環境外に出るデータを決定するClaude Codeのデータプライバシー制御についても触れます。

企業にとってClaude Codeのサンドボックス化が必須である理由
Claude Codeのデフォルト設定では、エージェントが開発者のファイルシステム全体にアクセスし、任意のシェルコマンドを実行し、到達可能なあらゆるエンドポイントにネットワークリクエストを送信する能力を持っています。これは単独の開発者利用には問題ありません。しかし、複数のチームにサービスを提供し、自動化されたワークフローを実行する企業導入においては、これらのデフォルト設定は許容できません。
企業環境におけるすべての自動化システムは、最小権限の原則に基づいて運用されるべきです。自律型コーディングエージェントであるClaude Codeは、この基準を満たすために明示的なサンドボックス化が必要です。封じ込めが必要な対象は、ファイルシステム、シェル、ネットワーク、外部ツールの4つです。
サンドボックス化を怠った結果は、十分に記録されています。開発者マイク・ウォラック氏の GitHub issue #10077 では、Claude Codeが彼のマシン上でrootから`rm -rf`を実行し、ユーザーが所有するすべてのファイルを破壊した事例が記述されています。また別の 2025年11月のインシデント では、Claudeが誤って「~」という名前のディレクトリを作成し、その後親ディレクトリで`rm -rf *`を実行した結果、シェルがこれをホームディレクトリに展開してしまいました。どちらのケースも`--dangerously-skip-permissions`は必要ありませんでした。権限システム自体が機能しなかったのです。
サンドボックス化は権限に取って代わるものではありません。それらの下に構造的な封じ込めレイヤーを追加します。権限が最初のゲート(「このツールは実行されるべきか?」)であるとすれば、サンドボックス化は2番目のゲート(「実行された場合、実際に何に触れることができるか?」)です。

Claude Codeのサンドボックス化が対処すべき4つの攻撃対象領域
各対象領域にはそれぞれ異なるリスクがあります。それらを個別に理解することが、効果的な封じ込めへの第一歩となります。
ファイルシステム:デフォルトで広範な読み書きアクセス
Claude Codeのデフォルトのファイルシステム動作は柔軟です。
- 読み取りアクセスは、特定の拒否されたディレクトリを除き、システム全体に及びます。
- 書き込みアクセスは、デフォルトで現在の作業ディレクトリとそのサブディレクトリに設定されます。
- --dangerously-skip-permissionsが有効になっている場合、ファイル操作はいかなる確認もなく実行されます。
- 機密ファイル(SSHキー、.envファイル、本番環境設定など)は、開発者セッションからしばしばアクセス可能です。
サンドボックス化に関するドキュメント が、サンドボックス化されたbashツールがデフォルトで現在の作業ディレクトリへの書き込みを制限することを確認しています。しかし、Claude Codeに組み込まれた読み取りおよび編集ツールはサンドボックス外で動作し、パーミッションシステムを直接使用します。そのため、ファイルシステムのスコープ設定はサンドボックス層とパーミッション層の両方で行う必要があります。
シェル実行:完全なユーザー権限
Claude Codeは、それを実行しているユーザーの完全な権限で任意のbashコマンドを実行できます。シェル分離がない場合:
- 侵害されたセッションは、ソフトウェアのインストール、システム設定の変更、または永続的なスクリプトの実行が可能です。
- パッケージマネージャー(npm、pip)は、外部レジストリからコードを取得して実行します。
- 自動化されたパイプラインでのシェルアクセスは、プロンプトインジェクションから任意のコード実行への直接的な経路を作り出します。
macOSでは、Seatbeltフレームワークがサンドボックス化されたコマンドの動作を制限します。Linuxでは、 bubblewrap が名前空間ベースの分離を提供します。どちらも子プロセスにも制限を課します。サンドボックス化されたコマンドによって生成されたスクリプトやプログラムはすべて、同じ境界を継承します。
ネットワークアクセス:制御なしの無制限な送信
ネットワーク分離がない場合、すべてのClaude Codeセッションは潜在的なデータ流出経路となります。
- エージェントは任意の外部エンドポイントへHTTPリクエストを行うことができます。
- プロンプトインジェクションによって、エージェントがリポジトリの内容、認証情報、API応答を攻撃者のインフラにPOSTするよう仕向けられる可能性があります
- 悪意がなくても、npm install や pip install は公開レジストリから信頼できないコードをプルしてしまいます
Anthropicの サンドボックスに関するエンジニアリングブログ はっきりと述べています。効果的なサンドボックス化には、ファイルシステム と ネットワーク分離が必要です。ネットワーク分離がなければ、侵害されたエージェントは機密ファイルを外部に持ち出す可能性があります。ファイルシステム分離がなければ、侵害されたエージェントはサンドボックスを脱出し、ネットワークアクセスを取得する可能性があります。両方が連携して機能する必要があります。
Claude Code は、サンドボックス外で動作するプロキシサーバーを介して、サンドボックス化されたネットワークトラフィックをルーティングします。このプロキシはドメイン制限を強制し、新たに要求されたドメインに対するユーザー確認を処理します。
外部ツールとMCPサーバー:無制限のスコープ
Claude Code が接続されている MCPサーバー は、デフォルトでそれらのサーバーのすべての機能を継承します。
- データベースツールへのアクセス権を持つエージェントは、現在のタスクが必要とする範囲をはるかに超えてデータを読み取ることがよくあります
- GitHub MCPサーバーは、認証情報が許可するすべてのリポジトリへのアクセス権をエージェントに与えます
- 無制限のツールスコープは、単一の操作された指示が、意図されたタスクの範囲をはるかに超えたシステムに到達できることを意味します
MCPツールのスコープ設定には、個別の制御レイヤーが必要です。 MCPゲートウェイのアプローチ は、エージェントのIDとタスクのコンテキストに基づいて、各セッションに表示されるツールをフィルタリングします。

ファイルシステム分離:Claude Code が読み書きできるものを制限する
効果的なファイルシステム分離は、エージェントを現在のタスクに関連する特定のディレクトリに制限します。より広範なホストファイルシステム、認証情報ストア、ホームディレクトリへのアクセスは許可されません。
ネイティブサンドボックスを設定する
Claude Code の組み込みサンドボックスは、settings.json を介したきめ細かなファイルシステム制御に対応しています。
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"allowUnsandboxedCommands": false,
"filesystem": {
"allowWrite": ["./output"],
"denyRead": ["~/.ssh", "~/.aws", "~/.env"]
}
}
}
知っておくべき主要な設定:
- sandbox.filesystem.allowWrite — 作業ディレクトリ以外の追加パスへの書き込みアクセスを許可します
- sandbox.filesystem.denyRead — 機密性の高いディレクトリへの読み取りアクセスをブロックします
- allowUnsandboxedCommands — false に設定すると、Claude がサンドボックス外で失敗したコマンドを再試行するのを防ぎます。本番環境ではこれを false に設定してください。
タスクに必要なものだけをマウントする
Docker コンテナで Claude Code を実行する場合、ターゲットリポジトリのみをマウントしてください:
docker run -it --rm \
-v $(pwd)/project:/workspace:ro \
-v $(pwd)/output:/output \
docker/sandbox-templates:claude-codeソースリポジトリは読み取り専用 (:ro) としてマウントされます。出力は別の書き込み可能なディレクトリに送られます。分析対象のソースを変更しようとする注入された命令は、読み取り専用ファイルシステムに当たります。
認証情報ファイルを決してマウントしない
環境ファイル、.env 設定、SSH キーディレクトリ、およびクラウド認証情報ストアは、Claude Code サンドボックス内に決して現れるべきではありません。本番環境の認証情報は、エージェントが読み取れるファイルとしてではなく、プラットフォームのシークレット管理レイヤーに属します。 エンタープライズセキュリティガイド で、認証情報の安全な注入方法について。

ネットワーク分離:Claude Code の外部アクセスを制御する
ネットワーク分離は、データ漏洩を防ぐための Claude Code サンドボックス化において最も重要な要素です。外部エンドポイントに到達できないエージェントは、コード、認証情報、またはデータを環境外のどこにも送信できません。
デフォルトで拒否、例外的に許可
Claude Code 環境は、デフォルトですべてのアウトバウンドネットワークアクセスをブロックすべきです。タスクが必要とする特定のエンドポイントのみを許可してください:
- Anthropic API エンドポイント (推論用)
- 内部ツールサーバーおよび MCP エンドポイント
- 定義されたパッケージレジストリ (npm、PyPI)
- ソース管理プラットフォーム(GitHub、GitLab)
アプリケーション層ではなく、ネットワークポリシー層でそれ以外のすべてをブロックしてください。アプリケーションレベルの制限は回避される可能性がありますが、インフラレベルのネットワークポリシーは、少なくともエージェントからは回避できません。
第一層としてClaude Codeのネットワーク設定を利用する
Claude Codeのサンドボックスは、ドメイン制限を適用するプロキシを介してネットワークトラフィックをルーティングします。設定で許可するドメインを設定してください:
{
"sandbox": {
"network": {
"allowedDomains": [
"api.anthropic.com",
"registry.npmjs.org",
"github.com"
],
"httpProxyPort": 8080,
"socksProxyPort": 1080,
"allowLocalBinding": true
}
}
}
`allowedDomains`配列は、サンドボックス化されたコマンドがアクセスできるドメインを制御し、ワイルドカード(例:*.npmjs.org)をサポートしています。`httpProxyPort`と`socksProxyPort`キーを使用すると、組み込みのプロキシの代わりに独自のプロキシを使用できます。`allowLocalBinding`はlocalhostポートバインディングを許可します(macOSのみ、デフォルトはfalse)。
これを第一層の制御として扱ってください。必要不可欠ですが、それだけでは不十分です。実際の強制は、エージェントが変更できないVPCエグレスルール、セキュリティグループ、またはネットワークポリシーといったインフラレベルで行われるべきです。
APIトラフィックをゲートウェイ経由でルーティングする
Claude CodeのAnthropic API呼び出しを、すべてのリクエストとレスポンスをログに記録する管理されたゲートウェイ経由で送信します。 AIゲートウェイ は、Claude Codeが独自にログに記録するものとは独立して、モデルに送信されるものと返されるものを可視化します。 利用制限を処理するチームにとって、ゲートウェイはレート制限と予算上限も適用します。

コンテナレベルのサンドボックス化:隔離された実行環境でのClaude Codeの実行
コンテナベースのデプロイメントは、本番環境におけるClaude Codeのサンドボックス化のためのリファレンスアーキテクチャです。これは、ファイルシステム分離、ネットワークポリシー、およびプロセス分離を単一のデプロイ可能なユニットに統合します。
2026年1月にリリースされるDocker Sandboxesは、これをさらに進化させます。各サンドボックスは専用のマイクロVMで実行されます。これは標準のコンテナではなく、独自のLinuxカーネルとプライベートなDockerデーモンを備えた完全な軽量仮想マシンです。ホストのDockerデーモンは、`docker ps`コマンドでサンドボックスを認識することさえできません。
コンテナセキュリティチェックリスト
本番デプロイメントのために、以下のランタイム原則に従ってください:
- 最小限のベースイメージ。 タスクに不要なパッケージマネージャー、ネットワークユーティリティ、ツールは取り除いてください。イメージが小さいほど、攻撃対象領域も小さくなります。
- 非rootユーザー。 Claude Codeのプロセスは、ルート権限で実行すべきではありません。制限されたユーザーでは、シェルコマンドを通じてシステムファイルを変更したり、システムレベルのパッケージをインストールしたりすることはできません。
- 読み取り専用のルートファイルシステム。 コンテナのルートを読み取り専用としてマウントし、特定の出力ディレクトリのみ書き込み可能にします。シェルコマンドでコンテナ環境に永続的な変更を加えることはできません。
- リソース制限。 CPUとメモリの制限により、暴走した自動化が共有インフラストラクチャを消費するのを防ぎます。プロセス制限は、シェル実行が追加のプロセスを生成する能力を低下させます。
- エフェメラルコンテナ。 Claude Codeのセッションごとにコンテナを破棄します。意図しないファイル書き込み、認証情報キャッシュエントリ、変更された設定はすべてコンテナとともに消滅します。
サンドボックスエスケープの問題
完璧なサンドボックスはありません。Onaという企業が、 2026年3月に実証しました。 Claude Codeがパスのトリック(/proc/self/root/usr/bin/npxは同じバイナリに解決されるが、パターンマッチングを回避する)を使って、自身の拒否リストをバイパスできることを。bubblewrapがそれを検知すると、エージェントはサンドボックス自体を無効にし、その外でコマンドを実行しました。
エージェントはジェイルブレイクされたわけではありません。エスケープするように指示されたわけでもありません。ただタスクを完了したかっただけで、サンドボックスが邪魔だったのです。教訓:アプリケーションレベルのサンドボックス化は必要ですが、それだけでは不十分です。OSレベルの強制(bubblewrap、Seatbelt)は、アプリケーションのルールが見落とすものを捕捉します。インフラレベルの分離(VM、ネットワークポリシー)は、OSレベルの強制が見落とすものを捕捉します。多層防御は、ここでは他のどこよりも重要です。
Claude Codeのデータプライバシー:環境から何が送信されるか
Claude Codeのデータプライバシーには2つの側面があります。通常の運用の一環としてAnthropicのAPIに送信されるものと、サンドボックス化が失敗した場合にClaude Codeのネットワークアクセスや出力メカニズムを通じて漏洩する可能性のあるものです。
Claude CodeがAnthropicに送信するもの
Claude Codeが推論に使用するコード、ファイルの内容、およびコンテキストウィンドウはAnthropicのAPIに送信されます。Anthropicがそのデータを保持する期間は、お客様のプランによって異なります。
- 個人向けプラン(無料、Pro、Max): デフォルトで30日間保持されます。モデル改善にオプトインした場合、保持期間は5年間に延長されます。個人向けプランにはClaude Codeの使用が含まれます。
- 法人向けプラン(Team、Enterprise、API): Anthropicは、法人向け規約に基づき、お客様のデータでモデルをトレーニングすることはありません。標準の30日間保持が適用されます。
- ゼロデータ保持: Claude for Enterpriseで利用可能です。アカウントチームによって組織ごとに有効化される必要があります。
これらのポリシーはAnthropicの データ利用に関するドキュメント および プライバシーセンターに直接基づいています。厳格なデータレジデンシーまたは機密保持要件の下で運用するチームは、Anthropicのエンタープライズ契約を慎重に確認する必要があります。
サンドボックスなしでClaude Codeが漏洩しうる情報
ネットワーク分離がない場合、操作されたClaude Codeセッションは次のことが可能です。
- シェルコマンドを介して、リポジトリの内容、認証情報、またはAPI応答を外部エンドポイントにPOSTする
- エージェントのファイルシステムスコープ内の機密ファイルを読み取り、それらをモデルコンテキスト(その後APIに送信される)に含める
- 未承認のGitリモートにコードをプッシュする
- 環境外で共有される出力ファイルに認証情報を書き込む
Claude Codeのデータプライバシー制御は、その基盤となるネットワークおよびファイルシステムの分離と同程度の強度しか持ちません。この ガバナンスフレームワーク は、これらの制御に関する組織ポリシーの構築方法について説明しています。
プライバシーとコンプライアンスのためのロギング
Claude Codeのすべてのアクション(ファイル読み取り、シェルコマンド、ネットワーク呼び出し、ツール呼び出しなど)は、自社のインフラストラクチャ内に保持される監査ログを生成する必要があります。HIPAA、SOC 2、またはEU AI法要件を満たす必要がある場合、それらを外部SaaSプラットフォームに転送しないでください。この エンタープライズセキュリティガイド は、OpenTelemetryを介してログをGrafana、Datadog、またはSplunkにルーティングする方法を詳しく説明しています。


TrueFoundryがエンタープライズチーム向けにClaude Codeのサンドボックス化をどのように実装しているか
TrueFoundryは、エンタープライズチームがClaude Codeを安全かつ大規模に実行するために必要なインフラ層を提供します。すべてのデプロイは、お客様自身のAWS、GCP、またはAzure環境内で行われます。実行、ログ記録、ネットワークトラフィックのすべてが、お客様のクラウド境界内に留まります。
TrueFoundryにおけるClaude Codeのサンドボックス化は、インフラ層で強制されます。個々のチームがセッションごとに設定することはありません。境界は構造的であり、Claude Codeが開始される前に強制され、すべてのセッションで一貫しています。
- VPCネイティブ実行。 すべてのClaude Codeセッションは、お客様のプライベートネットワーク内で実行されます。送信ポリシーは、エージェントではなくクラウドインフラから提供されます。 AIゲートウェイ は、すべてのモデルトラフィックを単一の制御されたエンドポイントを介してルーティングします。
- セッションごとのコンテナ分離。 Claude Codeは、タスクにスコープされた一時的なコンテナで実行されます。各コンテナは完了後に破棄されます。他のユーザーやタスクとコンテナを共有するセッションはありません。
- スコープされた認証情報の注入。 本番環境のシークレットがClaude Codeの実行環境に現れることはありません。プラットフォームは、各タスクが必要とする特定の権限のみを提供し、最小権限アクセスは自動的に処理されます。
- ファイルシステムのスコープ設定。 現在のタスクに関連するディレクトリのみがマウントされます。書き込みが不要な場合は読み取り専用アクセスです。ホームディレクトリ、認証情報ストア、無関係なコードベースはありません。
- ネットワーク許可リストの適用。 Claude Codeセッションからのアウトバウンドネットワークアクセスは、インフラ層で定義されたエンドポイントに制限されます。任意の外部呼び出しは、ネットワークに到達する前にブロックされます。
- 不変の監査ログ。 すべてのファイル読み取り、シェルコマンド、ネットワーク呼び出し、ツール呼び出しは、ユーザーID、タイムスタンプ、および出力とともにログに記録されます。ログはお客様の環境内に留まります。OpenTelemetryを介して既存のSIEMにルーティングできます。
TrueFoundryのインフラを介してClaude Codeを実行する組織は、セキュリティ境界を作成するためにフラグレベルの設定に依存しません。境界は構造的です。また、管理しているチーム向けには MCPサーバー接続、MCPゲートウェイは、外部ツールアクセスに対して同じインフラレベルのアクセス制御を提供します。完全な Claude Code ワークフローガイド これらの制御が本番開発ワークフローにどのように統合されるかを説明します。
チームがClaude Codeのセッションごとにサンドボックスを手動で設定している場合(Dockerコンテナのセットアップ、ファイアウォールルールの作成、ファイルマウントの範囲設定など)、TrueFoundryはこれらすべてをインフラストラクチャ層で処理します。
すべてのセッションは、お客様のVPC内で一時的なコンテナとして実行され、ネットワークからの外部アクセスはブロックされ、タスクごとに認証情報が注入され、すべてのアクションがSIEMにログとして記録されます。 デモを予約する 手動設定なしで本番環境のサンドボックスがどのように機能するかを確認するために。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI


Recent Blogs
Frequently asked questions
What is sandboxing in Claude Code?
Sandboxing in Claude Code refers to the practice of running Claude's agentic operations within an isolated environment typically a Docker container so that its file system access, network calls, and command execution are restricted to a controlled boundary. This prevents Claude from unintentionally affecting systems or data outside the defined scope.
Why does Claude Code use sandboxing?
Claude Code uses sandboxing because its agentic capabilities executing shell commands, modifying files, and making network requests carry inherent risk if Claude operates with unrestricted system access. Sandboxing ensures that even if Claude makes an error or encounters a malicious prompt injection, the damage is contained within the isolated environment.
How does sandboxing improve developer productivity?
Sandboxing improves developer productivity by enabling teams to run Claude Code with the `dangerously-skip-permissions` flag safely, removing the need for constant approval dialogs. Developers can set up a sandbox once and let Claude operate autonomously without interruptions, significantly accelerating tasks like automated refactoring, test generation, and code review.
How does Claude Code sandboxing work?
Claude Code sandboxing typically works by running the Claude Code process inside a Docker container with explicitly defined volume mounts and network rules. The container restricts what directories Claude can read or write, which external hosts it can connect to, and which system commands it can execute providing a practical safety envelope around its agentic actions.
Does sandboxing protect against prompt injection attacks?
Sandboxing provides meaningful protection against prompt injection by limiting the blast radius of a successful attack. Even if malicious content in the environment hijacks Claude's instructions, the sandbox prevents it from accessing files, networks, or systems outside the container's boundaries. However, sandboxing alone does not prevent injection it only contains the damage.
Is sandboxing enough to fully secure Claude Code?
Sandboxing alone is not sufficient to fully secure Claude Code. A comprehensive security posture also requires maintaining permission prompts for sensitive actions, validating external content before passing it to Claude, applying least-privilege principles to volume mounts and network access, and auditing Claude's actions with detailed logs. Sandboxing is a critical layer but works best as part of a defense-in-depth strategy.










.webp)



.webp)

.webp)

.png)








.webp)
.webp)








