packageをインストールし、設定を書き換え、Docker workloadまで起動するcoding agentは、すべての操作で承認を待つと価値が下がる。Docker Sandboxesは逆方向からこの問題を解く。agentの行動を一つずつ予測するのではなく、セッション全体を専用microVMに入れ、filesystem、network、credentialの境界をmodelの外側で定義する。箱の中では自由を与え、hostへの道は閉じる。

Docker-in-Dockerではない

各sandboxは独自のkernelと専用Docker daemonを持つ。agentがdocker build、docker run、docker composeを実行しても、hostのDocker socketをmountしたりprivileged containerを使ったりする必要はない。セッション内で作ったimageとcontainerはそのmicroVMに閉じ、sandboxを削除すれば一緒に消える。

DockerはFirecrackerを使わず、新しいVMMを開発したと説明する。macOSではHypervisor.framework、WindowsではWindows Hypervisor Platform、LinuxではKVMを直接利用する。coding agentが動く開発者の端末で共通の実行modelを提供するための選択だ。project workspaceだけをmountし、networkアクセスとsecret injectionは実行前に決める。セキュリティ境界をsystem promptに書き、model自身が守ることを期待する方式ではない。

強い分離にもコストと限界がある

対応agentにはClaude Code、Gemini CLI、Copilot CLI、Codex、OpenCode、Kiroが並ぶ。sandbox内では、system packageのインストール、serviceの起動、config変更、追加containerの実行が可能だ。macOSとWindows向けの単独インストール手順があり、Docker Desktopは必須ではない。チーム向けのnetwork、filesystem、MCPの中央ポリシーは、別のDocker AI Governanceにつながる。

488 pointsと299 commentsを集めたHNの議論では、宣伝文句よりも実際の境界が問われた。Dockerの担当者は、これがcontainer分離ではなく、OS固有のhypervisor上で動く専用microVMであり、Firecrackerは使っていないと説明した。ユーザーはoutbound firewallとplaceholderを使うsecret injectionを評価する一方、login要件や既存のVM、Incus、container構成との差を尋ねた。また、読み取り専用権限、PR承認、用途を絞ったcredentialなど、タスクごとの権限設計も必要だという指摘が出た。

microVMはagentを信頼できる存在に変えるのではない。現実的な開発環境を与えながら、被害範囲を狭める。mountしたworkspaceへの変更はhostのprojectに影響し、networkやcredentialのポリシーが広ければ重要なsystemに届く可能性も残る。有力な防御線だが、ポリシー設計の代わりにはならない。製品ページとarchitecture解説で詳細を確認できる。

#microvm

Docker SandboxesがcontainerでなくmicroVMを選んだ理由