サンドボックス環境の6つのメリット
日本語
コピー
私たちの「エージェント型 AI の現状レポート」では、60% の組織が AI agent を本番環境で稼働させていると回答している。これらの agent は自分でパッケージをインストールし、スクリプトを実行し、外部サービスを呼び出す。しかもその作業の多くは今や開発者のノート PC 上で、開発者の資格情報を使って行われている。信頼できないコードや実験的なコードをローカルで直接動かすのは昔から危険だが、同じマシンを自律型 agent に渡せば、リスクはさらに大きくなる。
サンドボックスはコードに独立した制御可能な実行空間を与え、基盤となるマシンや外部システムへのアクセスを制限する。この境界がどれだけ厳密に守られるかは、サンドボックスの作り方次第であり、ここから差が効いてくる。
サンドボックスの利点はそれ自体を知る価値があるが、その中で権限を自動承認する無人運転の agent が動くとなれば、利点はさらに増幅される。以下では分離、資格情報の扱いから実行時に強制されるポリシーまで 6 項目を挙げ、Docker Sandboxes がそれぞれをどう実現しているかを見ていく。
要点
- サンドボックスは強固な分離境界を提供し、信頼できないコードや自律型 agent が動いてもホストマシンにはアクセスできない。
- Docker のサンドボックスには多くの利点がある。分離、自分で定義するポリシー、安全な資格情報、使い捨て、本物の Linux 開発環境、そしてすべての agent が同じサンドボックス技術を共有できることだ。
- サンドボックスはネットワークとファイルシステムのポリシーを実行時に強制する。だからこそガバナンスの執行点になる。
- AI agent にとって、これらの利点が重なると、境界の内側で完全な自律性が手に入る。agent は仕事をこなし、しかも十分に安全だ。
1. 分離
このリストのどの項目も分離の上に成り立っており、境界の強さがサンドボックスの信頼性を決める。Docker Sandboxes では、各サンドボックスが専用の microVM 上で動く。独立した Linux カーネルを持つ軽量仮想マシンで、ハードウェア支援の hypervisor 境界によってホストから切り離されている。
この分離は完全な仮想マシンが提供する分離と同じ種類のもので、これがあるからこそ agent に本当の自由を与えられる。Docker サンドボックスは独自のカーネルで動くため、侵害されたり暴走したりした agent は、ホストにも他のサンドボックスにも、自分の環境の外にある何ものにも触れられない。逃げ出そうとしても壁にぶつかるだけだ。だから agent はパッケージを入れ、信頼できない依存関係を取得し、無人でコードを走らせられる。中で問題が起きても、被害はサンドボックス内にとどまり、サンドボックスを捨てれば一緒に消える。この封じ込めがあるから、agent を全速力で走らせられる。
| ⓘ MicroVM とコンテナの分離：（Linux）コンテナはホストのカーネルを共有するため、その分離性はカーネル層の制御機構に依存する。Docker Desktop を使う場合、Linux コンテナを動かす環境を用意するために、実際には仮想マシンの中でコンテナをホストしているので、ホスト OS とは分離されている。ただしコンテナはすべて同じカーネル（その Linux 仮想マシンのカーネル）を共有する。したがってコンテナ同士に強い分離はない。 |
|---|
2. 自分で定義するネットワークとファイルシステムの制御
分離が外壁を築くなら、自分で定義する制御は、壁の内側でワークロードが何に触れられるかを決める。多くのサンドボックスはネットワークとファイルシステムへのアクセスをある程度制限できる。ワークロードがどのドメインや IP レンジにアクセスできるか、ホスト上のどのパスを読み書きできるか（できたとしても）といった具合だ。ツールによってこのポリシーをどれだけ細かく表現できるかは異なり、粗いルールは穴を残し、agent はいずれそこを見つけるので、試す前に確認しておく価値がある。
Docker Sandboxes ではこのポリシーをサンドボックスごとに設定でき、実行時に境界で強制される。だから中のコードが予想外の動きをしても、ルールは生きている。これらの制御は、実験が無断で外部に接続するのを防ぎ、データの持ち出しを断ち切り、信頼できないサービスや悪意あるサービスへのアクセスを遮る。ファイルシステムを制限すれば、SSH キーやクラウドの資格情報といった機密性の高いホスト上のパスに手が届かなくなる。
3. 資格情報の安全な扱い
Agent が役に立つ仕事をするには資格情報が要る。リポジトリにコードを push するには token、サービスを呼ぶには API key が必要だ。リスクは、環境内の資格情報がそこで動くあらゆるものに読まれ、ログに記録され、漏れ出すことにある。多くのサンドボックスは鍵を環境変数やマウントしたファイルとして渡すので、値はワークロードが読める場所に置かれ、ワークロードが動かすものも同じように読める。
Docker Sandboxes は資格情報を環境の外に完全に置く。資格情報はホストの keychain に残り、サンドボックスは境界でそれを外向きのネットワークリクエストに注入する。ワークロードは資格情報を使えるが、値そのものは常にホスト上にとどまる。鍵を読めない agent は、それを外に持ち出すことも、ログに書くことも、プロンプトインジェクションの指示に従って渡すこともできない。資格情報はリクエストの経路上で働き、機密の中身は常に自分の管理下にある。
4. 素早く作り直せる一時的で使い捨ての環境
サンドボックスは作るのも速く、捨てるのも簡単なので、どれも使い捨てとして扱える。タスクが終わったとき、あるいは agent が暴走したときに、環境を削除すれば中身もすべて消える。インストール済みのパッケージ、実行中のプロセス、agent がシステムに加えた変更のすべてだ。ただし作業ディレクトリをホストからマウントしている場合、agent がそこで作成・変更したファイルは環境を削除してもマシン上に残る。
同じ環境を再現できることも、同じくらい重要だ。サンドボックスはコードで定義するため、必要になったときにまったく同じ環境を立ち上げられる。パッケージも設定も含めて、毎回同じ構成になる。いわばインフラストラクチャ・アズ・コードをワークスペースに適用したもので、再現可能で、バージョン管理でき、チーム内で統一できる。agent にとっては、使い捨てであることが並列実行能力にもつながる。複数の agent を同時に走らせ、それぞれが真新しい環境で作業し、終わったら全部破棄すればいい。
5. 本物の Linux 開発環境と、完全な Docker デーモン
隔離といっても、環境を削って不完全にする必要はない。使う価値のあるサンドボックスなら、ワークロードに本物の Linux 環境を提供し、開発者や agent が実際に必要とするツールを揃え、境界の内側でパッケージをインストールし、サービスを動かし、データベースを起動し、コードをコンパイルできるようにすべきだ。環境の完全さは大きく差が出る。貧弱すぎる環境は作業をホスト側に押し戻してしまい、それでは境界を引いた意味がなくなる。
Docker Sandboxes はサンドボックス内に完全な Docker デーモンを隔離して動かす。agent は作業の途中でコンテナをビルドして実行できるが、ホストのデーモンに戻る経路はどこにもない。agentic なワークフローにとって、これは実用的な能力だ。一つのタスクがイメージのビルドをこなし、コンテナ内でテストスイートを走らせ、最後にそれらを全部片付ける、ということが起こりうる。この環境は本物のマシンのように振る舞う。だからこそ、実際の仕事ができる場所になる。
6. すべての agent が同じサンドボックス技術を共有する
開発者はよく agent を使い分ける。あるタスクは Claude Code に向き、別のタスクは Gemini CLI、Copilot CLI、Codex、Kiro、OpenCode に向いている。agent ごとに独自の隔離モデルが付いてくるなら、ツールごとに環境を別々に堅牢化しなければならないし、各社のモデルはバージョンアップで変わりうる。
サンドボックス技術を統一すれば、これが解決する。すべての agent が同じように動作し、同じ種類の隔離環境に入り、同じポリシーエンジンを使う。ネットワーク、ファイルシステム、認証情報のポリシーは一度定義すれば、実際に作業する agent がどれであっても同じように適用される。プラットフォームチームやセキュリティチームにとって、この一貫性こそがガバナンスを大規模に機能させる。理解すべき境界は一つ、監査すべき制御も一つで、開発者が採用するすべての agent がその範囲に入る。
誰がサンドボックス環境から最も恩恵を受けるか
この六つの利点は、役割によって価値が異なる。
- 個人開発者
- 自由に試せる余地が手に入る。危険な依存を試したり、慣れないツールを動かしたり、agent を無人で働かせたりできる。環境は隔離されていて使い捨てだと分かっているからだ。問題が起きたら消してやり直せばよく、自分のマシンが巻き込まれることはない。
プラットフォームチーム
- 一貫性と制御が手に入る。サンドボックスを一度定義すれば、どの agent を使うかに関係なく、すべての開発者に同じ環境と同じポリシーを提供できる。開発者が気にする設定は減り、標準は一か所で維持できる。
セキュリティチーム
- 隔離と監視の手段が手に入る。サンドボックスは agent が触れられる範囲を制限し、すべてのツールを横断して監視できる境界を与える。実行時に環境がポリシーを強制するので、agent の採用を安心して承認できる。これが本番環境で AI agent を安全に動かす ことの核心だ。各環境は使い捨てなので、攻撃対象になる永続的なものは何も残らない。
なぜこれが AI agent にとって決定的なのか
六つの能力を合わせて見ると、サンドボックスがagent を動かす標準的な方法になりうる理由が分かる。agent が役に立つには自律性が要る。パッケージをインストールし、コードを実行し、サービスを呼び出す。そのたびに承認を待っていてはならない。ホストマシン上で自律性を与えるのは危険だが、サンドボックスに入れてしまえば安全だ。
隔離は agent にできることを制限し、自分で定義した制御が触れられる範囲を決める。認証情報は agent の手に渡らないので、agent が侵害されても漏れる秘密はない。実行がおかしくなったら、使い捨ての性質のおかげで環境ごと捨てて数秒でやり直せる。本物の Linux 開発環境があれば agent は実際の作業をこなせるし、すべての agent を同じサンドボックス技術で動かせば、チームがどのツールを選んでも同じ状態が保たれる。これらが重なって、agent を全速力で走らせながら、失敗が起きたときの爆発半径をほぼゼロに抑えられる。
Docker Sandboxes で agent を安全に動かす
これらの利点は互いに依存している。どれか一つに穴があれば、そこが制御を失った agent に最初に見つかる弱点になる。隔離だけあって認証情報を扱わなければ、鍵はやはり漏れる。きれいに撤去できない開発環境は、agent が一度でもおかしな動きをした時点で負担になる。
agent を安全に動かすには六つの能力が同時に揃っていなければならず、Docker Sandboxes はそれを狙って設計されている。隔離は microVM で実現し、制御は自分で設定するネットワークとファイルシステムのポリシー、認証情報はホストのキーチェーンに置いたまま境界で注入するので agent には決して見えない。環境は使い捨てでコードで定義され、ワークスペースは完全な Docker デーモンを備えた本物の Linux システム、そして同じサンドボックス技術がすべての主要なコーディング agent を同じように動かす。
チームで agent を安全に動かしたいなら、Docker AI Governance が同じ境界を組織全体のポリシー層へと広げてくれる。ネットワーク、ファイルシステム、ツールアクセスのルールを一度定義すれば、セッションが使える認証情報をまとめて管理でき、それが各開発者のマシンに適用され、セキュリティチームに提示できる監査記録も付いてくる。
Docker Sandboxes を始める **→ **
よくある質問
サンドボックス環境は何に使うのか？
サンドボックスは、コーディング agent とその agent が実行するコードに、ホストから完全に切り離された使い捨ての実行環境を提供する。主な用途は、Claude Code、Codex、Gemini CLI といった AI コーディング agent を無人で走らせることだ。パッケージのインストール、サービスの起動、サンドボックス内での Docker の実行まで自由にやらせられる。自分のマシンでは動かしたくない危険な変更を試すのにも使える。
サンドボックス環境の主な利点は？
隔離。サンドボックスは中で動くものがホストに触れるのを防ぐので、操作ミス、悪意あるパッケージ、制御を失った agent はすべて内側に閉じ込められる。
サンドボックス環境はセキュリティのためだけのもの？
違う。セキュリティは主な利点だが、それだけでなく再現性が上がり、新しいメンバーの立ち上がりが速くなり、環境が使い捨てでコードとして定義されているため、開発者も agent も自由に試せるようになる。
サンドボックス環境は開発者を遅くする？
そうとは限らない。Docker Sandboxes のような MicroVM ベースのサンドボックスは数秒で起動し、完全な Linux 環境がすぐ手に入る。隔離による安全性は、速度をほとんど犠牲にしない。
サンドボックスは AI agent にどう役立つ？
agent を完全に自律的に動かしながら、触れられる範囲を限定できる。隔離は影響範囲を狭め、自分で定義したポリシーがアクセス権限を決め、認証情報の扱いによって鍵が agent の手に渡らないようにする。