Docker SandboxesとDockerコンテナの比較
違い
Dockerコンテナ
アプリケーションを配布・実行するために設計されている
|
Docker Sandboxes
AI エージェントをホストマシンから隔離するために設計されている
|
|
|---|---|---|
|
隔離の境界 |
共有カーネル上の名前空間（namespaces）と cgroups |
ハイパーバイザーによる、Sandbox ごとのハードウェアレベルの隔離 |
|
カーネル |
マシン上のすべてのコンテナで1つのカーネルを共有 |
Sandbox ごとに専用のカーネルを持つ |
|
隔離を突破した場合の影響先 |
他のアプリケーションも使用しているホストのカーネル |
ホスト OS によって既にセキュリティが強化されているハイパーバイザー |
|
内部のDocker |
Docker-in-Docker またはホストの Docker ソケットのマウントが必要。どちらも高い権限を必要とする |
microVM 内で専用の Docker デーモンが動作。ソケットのマウントもホストの特権も不要 |
|
AI エージェントによるビルド |
必要な権限を付与すれば |
|
|
誰が制限を設定するのか |
Dockerfileと実行フラグ |
エージェントの起動前に定義されたファイル、ネットワーク、およびシークレット |
|
認証情報 |
コンテナ内の環境変数とマウント |
境界を抜ける際にネットワークリクエストに挿入される |
|
一生 |
サービスが稼働している限り |
エージェントとのセッションは1回のみです。削除して最初からやり直してください |
|
取り付ける |
macOSおよびWindows版Docker Desktop。Linux 上の Docker Engine |
1つのコマンドで、単独で動作します。Docker Desktopのライセンスがありません
|
なぜこの2つは混同されるのか
Dockerは10年以上前からコンテナを意味してきた。前面にDockerのロゴが付いた新製品は、当然ながら、名前が変わったコンテナと解釈できる。サンドボックスはコンテナとベンダーおよびワークフローを共有します。 両者は境界線を共有していない。
境界線がどこにあるのか
|
macOS |
Apple Hypervisor.framework を直接呼び出します |
|
Windows |
Windowsハイパーバイザープラットフォームを直接呼び出します。互換性レイヤーはありません。 |
|
リナックス |
KVM、サーバーワークロードが受けるのと同じ境界 |
Sandboxの中
上の図は境界線の位置を示しています。これは、その中身を示しています。ドラッグして回転させ、開いてレイヤーを選択すると、そのレイヤーの機能が表示されます。
コンテナがエージェントに提供できないもの
エージェントは、あなたが監視していない間に、コードを記述し、実行し、必要なものをインストールします。３つのことが続きます。
カーネルは共有部分です
エスケープはカーネルを対象とします。コンテナ内では、そのカーネルはあなたのものであり、マシン上のすべてのコンテナがそれを共有します。
Docker-in-Docker は境界
を解消します。エージェントはイメージをビルドし、compose ファイルを実行します。コンテナ内では、つまりDocker-in-Docker内では、昇格された権限が隔離していたホストに到達します。
プロンプトは境界ではありません
エージェントにディレクトリを避けるように指示すると、リクエストになります。プロンプトで拒否すると、代わりにAPIにアクセスします。
サンドボックスが変更しないもの
ソフトウェアのパッケージング方法に変更はありません。
あなたのサービスは引き続きコンテナとしてビルドおよびデプロイされますが、それは当然のことです。サンドボックスは、開発者マシン上でエージェントセッションを保持します。
サンドボックスはカーネルを起動するため、コンテナよりも多くのメモリを保持します
サービスごとではなく、エージェントセッションごとに 1 つを実行します。 セッションに合わせてサイズを調整してください。艦隊に合わせて
はありません。中央ポリシーにはエンタープライズ展開
が必要です。自分のマシン上で、サンドボックスごとに境界を設定します。 組織全体に適用されるポリシーは、エンタープライズ展開に伴って導入されます。
よくある質問
Docker Sandboxは単なるコンテナですか？
いいえ。コンテナとは、マシンと共有するカーネル内で、名前空間とcgroupによって分離されたプロセスのことです。サンドボックスとは、 microVM 、つまり、特定のワークロードに必要な機能だけを残して簡素化された仮想マシンであり、独自のカーネルを備えている。 Docker実行時にフラグを指定しない場合、2つ目のカーネルが生成されます。
Docker Sandboxesホストカーネルを共有しますか？
いいえ。各サンドボックスは独自のカーネルを起動します。ホストカーネルはハードウェア境界の向こう側に存在し、他のすべてのサンドボックスも同様です。
エージェントはDocker Sandboxから脱出できますか？
脱出するには、カーネルではなくハイパーバイザーを越える必要があり、カーネルは仮想マシンが提供する境界である。ファイル、ネットワーク、およびシークレットはセッション開始前に設定されるため、エージェントの決定によってそれらが拡張されることはありません。
macOS上では、私のコンテナは既にLinux仮想マシン上で動作しています。それは同じことですか？
いいえ。それは1つのLinux VMで、カーネルも1つしかなく、マシン上のすべてのコンテナで共有されます。そして、その内部のDocker-in-Dockerには、やはり管理者権限が必要です。サンドボックスは、エージェントセッションごとに1つのmicroVMで構成され、AppleのHypervisor.framework上に直接配置されます。
私のエージェントはDocker buildとDocker composeを実行できますか？
はい。各サンドボックスはmicroVM内にプライベートなDockerデーモンを備えているため、ホストソケットのマウントやホスト権限がなくてもビルドと構成が機能します。
サンドボックスはコンテナよりも起動が遅いですか？
サンドボックスはカーネルを起動するため、コンテナよりも起動時に多くの処理を行います。VMMは各プラットフォームのハイパーバイザーを直接呼び出し、変換レイヤーの費用は一切発生しません。
Docker Desktopは必要ですか？
いいえ。サンドボックスはスタンドアロンでインストールされ、 Docker Desktopライセンスは不要です。 彼らはClaude Code、Codex、OpenCode、GitHub Copilot、Gemini CLI、Kiro、Docker Agentといったツールと連携して作業を行っています。
私のチームはコンテナを使うべきでしょうか、それともサンドボックスを使うべきでしょうか？
どちらも、それぞれ異なる仕事のためだ。コンテナは、チームが作成したソフトウェアを構築、配布、実行します。サンドボックスは、書き込みを行うエージェントをあなたのファイルや認証情報から隔離します。