Docker Sandboxes: Coding Agent を安全に実行する

ローカルマシンで自律型 AI コーディングエージェントを実行するのは、諸刃の剣です。Claude Code や Gemini CLI のようなツールは「レベル 4 の自律性」――つまり、人間の手助けなしに複雑なコーディングタスクを計画し、実行し、反復する能力――を約束します。しかし、AI エージェントにパッケージのインストール、ファイルの編集、シェルコマンドの実行権限をホストシステム上で与えるのはリスクが伴います。たった 1 つの誤った rm -rf や、ハルシネーションによる依存関係のインストールが、開発環境を破壊してしまう可能性があるからです。

そこで Docker Sandboxes の登場です。

Docker は、この「自律性 vs 安全性」のジレンマを解決するために特別に設計された新しいプリミティブを導入しました。MicroVM ベースの分離を活用することで、Docker Sandboxes は、ホストマシンを危険にさらすことなく、エージェントが「YOLO モード」で実行できる、安全で使い捨て可能な環境を提供します¹。本記事では、Docker Sandboxes の仕組み、エージェントの未来にとってなぜ不可欠なのか、そして今日からどのように使い始めることができるのかを解説します。

Docker Sandboxes とは何か？

一見すると、Docker Sandboxes は標準的な Docker コンテナと間違えられるかもしれません。しかし、基盤となる技術――そしてそれが提供するセキュリティ保証――は根本的に異なります。

MicroVM 分離: セキュリティの境界線

従来の Docker コンテナは OS レベルの分離 を使用します。これらはホストの Linux カーネルを共有し、プロセスを分離するために namespace と cgroups を使用します。これは効率的ですが、攻撃対象領域（アタックサーフェス）を共有するという課題があります。もしプロセスがコンテナから脱出（エスケープ）した場合、ホストカーネルにアクセスできる可能性があります²。

対照的に、Docker Sandboxes は MicroVM 分離 を使用します。各サンドボックスは、専用のカーネルを持つ軽量な仮想マシン内で実行されます¹。これにより、コンテナの分離よりもはるかに堅牢な、ハードウェアレベルのセキュリティ境界（ハイパーバイザー分離）が提供されます。仮にサンドボックス内で実行されているエージェントがカーネルを侵害したとしても、それはその MicroVM 内に閉じ込められ、ホスト OS に触れることはできません³。

このアーキテクチャは、AWS Firecracker のようなセキュアなサーバーレスプラットフォームで使用されている技術に似ており、VM の強力な分離と、コンテナの高速な起動時間（数秒程度）の両方を提供します。

「レベル 4 自律性」: 検証された自律性の解放

「レベル 4 自律性」という概念は、人間の介入なしに複雑なマルチステップのタスクを完了するエージェントの能力を指します。コーディングエージェントの場合、これはしばしば以下を意味します：

1. コードを読む。
2. 依存関係をインストールする (npm install, pip install)。
3. テストを実行する。
4. コードベースをリファクタリングする。
5. 変更をコミットする。

ローカルで実行する場合、開発者は安全を確保するために、シェルコマンドごとに承認を求めることで、この自律性を制限しがちです。この「Human-in-the-Loop（人間がループに入る）」アプローチは安全性こそ確保しますが、自律型エージェントを持つことによる生産性の向上を殺してしまいます。あなた自身がボトルネックになってしまうのです。

Docker Sandboxes はこのボトルネックを取り除きます。環境が分離されており、使い捨て可能であるため、「YOLO モード」（許可プロンプトなしでの実行）を安全に有効にできます¹。設定ファイルを削除したり、競合するライブラリをインストールしたり、ビルドを壊したりといった、エージェントが環境を台無しにするようなミスを犯しても、サンドボックスを破棄して新しいものを立ち上げるだけで済みます。ミスの「コスト」は無視できるほど小さくなります。

ディープダイブ: セキュリティとアーキテクチャ

Docker Sandboxes は単なる空の VM ではありません。エージェントワークフローをサポートするために特定の機能を備えて設計されています。

1. プライベート Docker デーモン

コーディングエージェントにとって最大の課題の 1 つは、Docker の 内部 で Docker を実行すること（Docker-in-Docker）です。エージェントはしばしば、イメージをビルドしたり、統合テストを実行したりする必要があります。

Docker Sandboxes には、MicroVM 内部に プライベート Docker デーモン が含まれています¹。これにより、エージェントは自由に docker run や docker build コマンドを実行できます。重要なのは、このプライベートデーモンがホストの Docker デーモンとは完全に分離されている点です。エージェントは、ホストのコンテナを一覧表示したり、ローカルイメージにアクセスしたり、本番環境のコンテキストを操作したりすることはできません⁴。

2. セキュアなワークスペース同期

サンドボックスとホストの間の唯一の架け橋は ワークスペースマウント です。検証済みのプロジェクトファイルがサンドボックスに同期され、エージェントが実際のコードで作業できるようになります。エージェントがソースコードに加えた変更はホストに反映されます（そのためコミットが可能）が、システムレベルの変更（/usr/bin へのグローバルパッケージのインストールなど）はサンドボックス内に限定されます³。

3. ネットワーク分離

セキュリティはファイルを保護することだけではありません。データの持ち出し（exfiltration）を防ぐことも重要です。Docker Sandboxes はネットワーク分離ルールをサポートしており、許可/拒否リストを定義できます。エージェントが npmjs.com や github.com にはアクセスできるが、任意の IP アドレスや社内ネットワークには接続できないようにすることが可能です¹。

統合: Claude Code & Gemini CLI

主要な AI コーディングツールは、シームレスな「セーフモード」を提供するために、すでに Docker Sandboxes と統合されています。

Claude Code

Anthropic の自律型コーディングツールである Claude Code は、Docker Sandboxes をネイティブにサポートしています。Docker での使用が確認されれば、簡単にサンドボックスセッションを開始できます：

docker sandbox run anthropic/claude-code

このモードでは、Claude は自由にコマンドを実行できます。ANTHROPIC_API_KEY のような必要な API キーを環境変数として注入することで、システム全体の認証情報をさらすことなく、エージェントに必要な機能を持たせることができます¹。

Gemini CLI

Gemini CLI は、安全な運用のために Docker Sandboxes（または独自の内部サンドボックス機能）の使用を明示的に推奨しています。Docker Sandbox 内で Gemini CLI を実行することで、実験的または信頼できないコード生成に対して「安全第一」のアプローチを検証する多層防御（Defense-in-Depth）を追加できます⁵。

結論

AI エージェントが「チャットボット」から「自律的な同僚」へと移行するにつれて、それらを実行するためのインフラストラクチャも進化しなければなりません。システムを安全に保つために、希望的観測や手動の承認プロンプトに頼ることはできません。

Docker Sandboxes は、欠けていたインフラストラクチャのピースを提供します。それは、「エージェントの失敗」を大惨事ではなく些細な出来事として扱う、安全で高速、そして使い捨て可能なランタイムです。エージェントの実行環境を日常使用の OS から切り離すことで、ついにレベル 4 自律コーディングのスピードと可能性を完全に解き放つことができるのです。

Claude Code や Gemini CLI を使用している場合、あるいは独自のエージェントを構築している場合、Docker Sandboxes はそれらを実行するための責任ある方法と言えるでしょう。

参考文献