Docker Sandboxの解明：未公開のMicroVM APIをリバースエンジニアリングする

長年、Dockerコンテナはバックエンドデプロイの業界標準となってきました。しかし、Claude Code、Codex、GeminiといったAIコーディングエージェントの台頭により、任意の信頼できないコードを実行する需要が高まるにつれ、標準的なコンテナの限界が明らかになってきました。コンテナはホストのカーネルを共有するため、侵害されたコンテナはホストマシン全体を危険にさらす可能性があります。

これに対処するため、DockerはAIエージェントの安全性に特化したソリューションである「Docker Sandboxes」を導入しました。Dockerは、ホワイトリストに登録された少数のエージェント向けに限定的なCLIを提供していましたが、実際にはmicroVMを起動するための未公開のAPIを密かに提供していました。このAPIにより、コンテナでは提供できないレベルの隔離を実現し、信頼できないコードを実行するための「ゴールドスタンダード」を効果的に作り出しています。

コンテナ vs. MicroVM：セキュリティのギャップ

Dockerがサンドボックス機能のためにmicroVMへ移行した理由を理解するには、2つの技術の違いを区別する必要があります。コンテナはnamespacesとcgroupsを使用して隔離を提供しますが、ホストカーネルを共有するため、カーネルレベルのエクスプロイトに対して脆弱です。

対照的に、MicroVMは各インスタンスに対して個別のカーネルを提供します。従来の仮想マシン（VM）よりも大幅に軽量でありながら、VMのセキュリティプロファイルを提供します。このアーキテクチャは、ユーザーが送信したスクリプトやマルチテナントのプラグインなど、実行されるコードを信頼できないワークロードにおいて極めて重要です。

比較概要

特徴	Docker Container	Docker Sandbox
セキュリティ	共有カーネル (namespaces)	個別のカーネル (microVM)
信頼できないコード	安全ではない	安全
ネットワークアクセス	直接 HTTP	フィルタリングプロキシ経由
Volumes	直接マウント	双方向ファイル同期
Platform	Linux, macOS, Windows	macOS, Windows のみ (初期段階)

`sandboxd` APIのリバースエンジニアリング

Dockerのサンドボックス機能は、sandboxdデーモンによって管理されており、~/.docker/sandboxes/sandboxd.sockにあるUnixソケットを通じて通信します。このデーモンをリバースエンジニアリングすることで、主に3つのエンドポイントが公開されていることが発見されました。

GET /vm: すべてのアクティブなVMをリストアップする
POST /vm: 新しいVMを作成する
DELETE /vm/{vm_name}: 特定のVMを破棄する

隔離モデル

Docker Sandboxesにおける最も重要なアーキテクチャの転換の一つは、Dockerデーモンの扱われ方です。標準的なセットアップでは、すべてのコンテナは/var/run/docker.sockを共有します。サンドボックスモデルでは、各microVMは~/.docker/sandboxes/vm/<name>/docker.sockに配置された専用のDockerデーモンを受け取ります。

これにより、一つのmicroVM内で実行されているコンテナは、別のVM内のコンテナやホストマシンから完全に隔離されます。これらのVMと対話するためには、開発者はcurl --unix-socketまたはdocker --host unix://...を使用してUnixソケットのパスを上書きする必要があります。

カスタムワークロードの実装

新しいVMは隔離されているため、イメージは手動でVMにロードする必要があります。これは、イメージをビルドし、アーカイブ化して、VMの特定のソケットにロードすることで実現されます。

ネットワークとVolumes

これらのmicroVMにおけるネットワークは、host.docker.internal:3128にあるフィルタリングプロキシを介してルーティングされます。このプロキシは、HTTPSトラフィックに対してman-in-the--middle (MITM) 操作を行い、ネットワークポリシーを強制します。本番環境では、TLS検証を無効にするのではなく、VMのレスポンスで提供されるCA証明書をインストールすることを推奨します。

ワークスペース同期

ワークスペースの同期は絶対パスを介して行われ、ボリュームマウントが標準的なDocker環境と同様に機能するようにします。

Sandbox Agent SDKによるオーケストレーション

生の/vm APIは強力ですが、これらのVMのライフサイクル（作成、イメージのロード、失敗後のクリーンアップ）を管理することは複雑です。これを簡法化するために、Sandbox Agent SDKが開発されました。これは未公開のAPIをラップし、AIエージェントの起動と対話のための統一インターフェースを提供し、ストリーミング出力やhuman-in-the-loopワークフローを処理します。

コミュニティの視点と進化

このAPIの発見は、サンドボックス化に関する現在の状態についてのいくつかの技術的な議論を巻き起こしました。

Platform Support: Linuxサポートは、KVMを介して可能であると一部のコミュニティメンバーが指摘しています（Apple Virtualization.frameworkやHyper-Vを利用するmacOSとWindowsに初期実装が機能焦点は、macOSとWindowsにありました）。Docker Desktopの具体的な実装は異なる場合があります。
Alternative Tools: Podmanのようなツールは、Linux上でlibkrunを介して透過的にmicroVMを起動できる代替手段として挙げられています。
The sbx Binary: 初期の解析の試み以降、Dockerはsbxをリリースしました。これは、フルセットのDocker Desktopのインストールを必要とせずに、microVMサンドボックスエンジンを提供するスタンドアロンの50MBのバイナリです。
The "Agent Problem": 一部の批判者は、VMによる隔離はインフラストラクチャの侵害問題のみを解決すると主張しています。彼らは、エージェントが侵害されたパッケージをインストールしたり、アクセス権限を持つトークンを濫用したりすることで、依然として害を及ぼす可能性があると指摘しており、隔離はより大きなセキュリティ・パズルの構成要素の一つに過ぎないことを示唆しています。

MicroVMのプリミティブを公開することで、Dockerは、ホワイトリストに登録されたAIエージェントだけでなく、あらゆるワークロードに対して、安全でスケーラブルな隔離を実現するための道筋を提供しました。これは、10年前にコンテナがもたらした革命を革命として、サンドボックス化の分野に再びもたらしました。