先週、私たちは市場で最も強力なエージェント分離を実現するという大胆な目標のもと、Docker Sandboxを立ち上げました。
この記事では、その主張、microVMがどのようにそれを可能にするのか、そしてこのアプローチで私たちが下したアーキテクチャ上の選択について解説します。
他のすべてのアプローチの問題点
すべてのサンドボックスモデルは何かを諦めるように求めます。私たちは上位4つのアプローチを検討しました。
フルVMは 強力な隔離を提供しますが、汎用VMは一時的でセッション重視のエージェントワークフロー向けに設計されていません。特定のワークロード向けに作られたVMの中には、現代のハードウェアでより効果的に起動できるものもありますが、汎用VMの体験(コールドスタートの遅さやリソースのオーバーヘッド)は、開発者をアイソレーションを完全に避ける方向に押し付けます。
コンテナは 高速で、現代のアプリケーションが構築される方法です。しかし、自律的なエージェントが自律的にDockerコンテナを構築し実行する必要がある場合(これはコーディングエージェントが日常的に行う)、Docker-in-Dockerに当たることになり、そもそも設定した隔離性を損なう昇格権限が必要になります。エージェントは開発作業を行うために本物のDocker環境が必要で、コンテナだけではそれを十分に提供できません。
WASM / V8 分離株 はスピンアップが速いですが、分離モデルは根本的に異なります。OSではなくアイソレートを実行しています。アイソレートベースのサンドボックスの提供者でさえ、V8 の強化が難しく、V8 エンジンのセキュリティバグが成熟したハイパーバイザーよりも頻繁に発生していることを認めています。セキュリティモデル以外にも実用的なギャップがあります。エージェントはシステムパッケージをインストールしたり、任意のシェルコマンドを実行したりできません。実際の開発環境が必要なコーディングエージェントにとって、WASMはそうではありません。
サンドボックスを使わない のは明らかに速いです。それはまたリスクでもあります。1つはrm -rf、もう1つはリークされた.env、一度の不正なネットワーク通話で、爆発範囲はマシン全体に及びます。
なぜMicroVMを使うのか
Dockerサンドボックスは、各エージェントセッションを専用のmicroVM内で実行し、VM境界で隔離されたプライベートDockerデーモンを持ち、ホストへの戻り経路はありません。
その一文には、解きほぐす価値のある3つの建築的決定が含まれています。
専用のmicroVMです。各サンドボックスには独自のカーネルが割り当てられます。これはハードウェア境界隔離で、フルVMで得られるのと同じ種類のものです。侵害されたり逃走したエージェントは、ホストや他のサンドボックス、あるいはその環境の外に到達できません。逃げようとすると壁にぶつかります。
プライベートでVM隔離されたDockerデーモン。これがコーディングエージェントの重要な差別化ポイントです。AIはコンテナの作業量を減らすどころか、より多くのものにするでしょう。コンテナはアプリケーション開発の手段であり、エージェントはその開発を行うためにDocker環境が必要です。Dockerサンドボックスは、各エージェントにVM境界によって完全に隔離されたmicroVM内で動作する独自のDockerデーモンを提供します。エージェントは、ソケットマウントやホストレベルの権限、他の方法が要求するセキュリティリスクなしで、完全な dockerビルド、 docker実行、 docker compose のサポートを受けられます。つまり、エージェントを人間の開発者として扱い、SDLC全体で実際にタスクを完了できる真の開発者環境を提供します。
ホストに戻る道がありません。ファイルアクセス、ネットワークポリシー、シークレットはエージェント自身が強制する もの ではなく、エージェントが実行する前に定義されます。これは重要な違いです。自らセキュリティ境界を決めるLLMはセキュリティモデルではありません。バウンディングボックスはシステムプロンプトではなく、インフラから来なければなりません。
なぜ新しいVMMを作ったのか
microVMを選ぶのは簡単な部分でした。実際に開発者が働いている場所で運営するのが一番難しかったです。
既存の選択肢を真剣に調べましたが、どれも私たちのニーズに合ったものではありませんでした。Firecrackerは最もよく知られたmicroVMランタイムで、特にAWS LambdaのようなLinux/KVM環境向けのクラウドインフラ向けに設計されました。macOSやWindowsにはネイティブサポートが全くありません。サーバー側のワークロードには問題ありませんが、コーディングエージェントはクラウド上で動作しません。これらはmacOS、Windows、Linuxの各開発者向けノートパソコンで動作します。
既存のVMMをプラットフォーム間で動作させ、macOSで翻訳レイヤーを作成し、Windowsで回避策を作ることもできましたが、LinuxファーストのVMMにクロスプラットフォームサポートを組み込むには、設計されていなかった抽象化と戦うことになります。そうすると、壊れやすく多層的な回避策が生まれ、「ただ動く」という約束を破り、開発者がサンドボックスを完全にスキップする摩擦を生み出してしまいます。
そこで、コーディングエージェントが実際に動作する場所向けに設計された新しいVMMを作りました。
3つのプラットフォームすべてでネイティブに動作し、それぞれのOSのネイティブハイパーバイザー(AppleのHypervisor.framework)を使用しています。Windows HypervisorプラットフォームとLinux KVMです。3つのプラットフォームに対応する単一のコードベースで、翻訳層はゼロです。
これは、エージェントが各OSごとにカーネルレベルの隔離を最適化できることを意味します。コールドスタートは抽象化税がないため速いです。MacBookの開発者は、LinuxワークステーションやWindowsマシンの開発者と同じ隔離保証と起動性能を得られます。
VMMを一から作るのは簡単なことではありません。しかし、開発者に遅いスタートや互換性の低下、プラットフォーム固有の注意事項を受け入れさせるという代替案は、まさにホスト上でエージェントを動かす原因となるアスタリスクです。私たちのアプローチでは、ハイパーバイザーレベルでそのアスタリスクを取り除きます。
ファスト・コールド・スタート
仮想化レイヤーを一から再構築し、高速スピンアップと迅速な分解を最適化しました。冷たい状態は早いです。これは一つの理由で重要です。サンドボックスが遅いと開発者はスキップします。「エージェント開始」と「エージェントが実行中」の間のすべての摩擦点は、ホスト上で実行する理由となります。ほぼ瞬時のスタートなので、その外で走るパフォーマンス上の理由はありません。
これが実際に意味すること
このアーキテクチャが提供する具体的なバージョンは以下の通りです:
完全な開発環境。エージェントはリポジトリのクローン、依存関係のインストール、テストスイートの実行、Dockerイメージの構築、マルチコンテナサービスの立ち上げ、プルリクエストの開放など、すべてサンドボックス内で行えます。スタブルもシミュレートもしていません。エージェントは開発者として扱われ、タスクをエンドツーエンドで完了するために必要な情報が与えられます。
スコープ付きアクセスであって、全か無かではありません。境界を定義します。エージェントがどのファイルやディレクトリを見られるか、どのネットワークエンドポイントに到達できるか、どのシークレットを受け取るかを正確に決めます。認証情報は実行時に注入され、MicroVMの範囲外に注入され、環境に組み込まれることはありません。
使い捨ての設計です。エージェントが道を外したら、サンドボックスを削除して数秒でやり直しましょう。ホストにクリーンアップすべき状態やロールバックするものはありません。
主要なエージェントはすべて対応しています。Claude Code、Codex、OpenCode、GitHub Copilot、Gemini CLI、Kiro、Docker Agent、そしてOpenClawやNanoClawのような次世代自律型システムなどが含まれます。同じアイソレーション、同じ速度、すべてのサーバーで同じサンドボックスモデルを使います。
チーム用
個々の開発者は、今日、Docker Sandboxをスタンドアロンでインストール・実行でき、Docker Desktopライセンスは不要です。
組織全体で厳格に適用できる集中型のファイルシステムおよびネットワークポリシーを望み、サンドボックス型実行を拡大したいチームには、エンタープライズ展開についてご相談 ください 。
そうでないトレードオフ
サンドボックスの売りにはいつもアスタリスクが付いてきました。確かに 安全ですが、その代償として速度や互換性、あるいはワークフローの摩擦で代償を得ます。
MicroVMはそのアスタリスクを排除します。コールドスタートでVMグレードの隔離が十分に早く実現できるので、スキップする理由もなく、サンドボックス内での完全なDockerサポートも可能です。トレードオフはありません。
エージェントは自律的に動くべきです。ガードレールなしで走るのはやめるべきです。
サンドボックスを秒単位で活用
Sandboxは単一のコマンドでインストールします。
macOS
Brew インストール docker/tap/sbx
Windows
winget install Docker.sbx
詳しく知りたい方はドキュメントを読 んで ください。
