Docker Sandboxesを使おう

コーディングエージェントを使って開発しているなら、Docker Sandboxesを使いましょう。エージェントの実行環境として設計されたもので、ホスト環境を汚さずに安全にエージェントを動かせます。ここでは私がDocker Sandboxesを使う際に調べた情報を整理して共有します。

Docker

Docker Sandboxes | コーディングエージェントのためのSandboxes | Docker

https://www.docker.com/ja-jp/products/docker-sandboxes/

Claude Code、Gemini、Codex、Kiroのための安全なサンドボックス。microVM ベースの分離環境でコーディングエージェントを実行します。

Docker Sandboxesとは

Docker社が提供する、コーディングエージェント実行のためのサンドボックス機能です。各エージェントをmicroVM（軽量仮想マシン）内で実行し、ホスト環境から完全に隔離することができます。

Claude Codeや、Codex CLI、Gemini CLIなど、コマンドラインベースのコーディングエージェントに対応しています。

使い方

セットアップ

Docker Desktopを最新版にアップデートします。そうすると使えるようになります。

基本コマンド

サンドボックスは次のコマンドで起動できます。これは、Claude Codeを使う想定です。

docker sandbox run claude <path>

claude の部分にはエージェント名が入ります。<path> を省略するとカレントディレクトリが対象になります。このコマンドを実行すると、コンテナの中でコーディングエージェントが起動し、指定したディレクトリだけがサンドボックスと共有されます。

その他の関連コマンドを紹介します。

次のコマンドで、サンドボックスの一覧を確認できます。

docker sandbox ls

次のコマンドで、サンドボックスを削除できます。 sandbox-name は docker sandbox ls で確認したものを使います。

docker sandbox rm <sandbox-name>

次のコマンドで、サンドボックス内にbashを起動できます。

docker sandbox exec -it <sandbox-name> bash

使ってみた所感

使ってみるとわかりますが、Docker sandboxを使うと、コーディングエージェントからカレントディレクトリ以外が見えなくなります。そのため、物理的にカレントディレクトリ以外に格納されている情報は見れなくなるので安心感があります。

また、私はコーディングエージェントが実行するコマンドは細かくチェックするタイプの人なのですが、色んなコーディングエージェントを使っていると気づくと多くのことを許可しすぎている状況に遭遇したこともあります。そんな時もサンドボックス環境に隔離していると安心です。

とはいえ、ホストOSで実行するのと比較すると、microVMを起動するための時間が必要になるので、ちょっと起動のオーバーヘッドがあります。それがちょっと面倒だな、と思いました。簡単なスクリプトを書かせたり、コード調査くらいなら許可することも少ないので、ホストOSでやってしまうのもありかと思ってます。複雑な開発を行う場合は、サンドボックス環境でやる方が安心・安全です。

仕組み

一応、仕組みも調査しているので共有します。私の理解を記載しておきます。

なぜコンテナではなくmicroVMなのか

Docker SandboxesはmicroVM上で実行され、これが重要です。コーディングエージェントは開発中に「イメージのビルド、コンテナの実行、Docker Composeの使用」といった操作をします。つまり、エージェント自身がDockerを扱います。

ただ、ホストのDockerデーモンへのアクセスを許可するのは抵抗が生まれます。普段Dockerを使っている方ならわかると思いますが、Dockerデーモンを経由すると、ホスト上の全コンテナの操作やイメージの参照ができてしまいますし、任意のイメージをDLして実行することもできます。

かといって、通常のコンテナの中で実行したり、Docker-in-Dockerを構築しようとするのはそれはそれで複雑です。Docker Sandboxesは、ハイパーバイザーを使って分離するので、完全に隔離できます。

DinD / DooD との比較

Docker Sandboxesの位置づけを理解するために、従来のアプローチも一緒に調べました。ここで合わせて紹介しておきます。

Docker-in-Docker (DinD)

Dockerコンテナの中でDockerデーモンを起動する方式です。これを実現するためには、 --privileged オプションが必要で、コンテナにホストのほぼすべてのカーネル機能へのアクセスを許可することになります。

すると結局、内側のDockerデーモンがcgroups等のカーネル機能にアクセスする必要があるため使いますが、コンテナがホストに対してほぼ何でもできる状態になり、セキュリティ的にはかなり緩くなります。

Docker Outside of Docker (DooD)

Dokcerコンテナの中からホストOSのDockerデーモンを操作する方式です。

UNIXドメインソケットの /var/run/docker.sock をマウントして、コンテナからホストのDockerデーモンを操作します。こちらも、コンテナ内のプロセスがホストのファイルシステムをマウントした新しいコンテナを作れてしまうため、事実上ホストでなんでもできる状態になります。セキュリティ的にはprivilegedと同等かそれ以上にリスクがあります。