コーディングエージェントを安全に実行するための Docker Sandboxes

Docker Sandboxes は、Claude Code、Codex、Copilot、Cursor などのコーディングエージェントをローカルのマイクロVM内で実行するツールです。マイクロVMは独自のカーネルと独自の Docker Engine を持ち、ホストと共有するのはプロジェクトディレクトリのみです。ローカルでの実行は無料です。

午後だけで ls や npm test の承認プロンプトを100回も許可した経験があれば、「権限確認をスキップする」フラグを使いたくなる気持ちはよくわかるはずです。同時に、そのフラグを有効にしたとき、エージェントがノートPCに何をしでかすかという不安も感じているでしょう。

本記事では、サンドボックスが何を隔離するのか、インストールから最初のセッションまでのセットアップ手順、エージェントによる変更の取り出し方、他の選択肢との比較、そしてコストについて解説します。なお、このツールはバージョン 1.0 未満であり、現在も急速に変化しています。

ノートPCで完全自律モードを使うリスク

完全自律モードのコーディングエージェントは、確認なしにシェルコマンドを実行し、パッケージをインストールし、ファイルを編集します。しかも、これらすべてをあなたのユーザーアカウントで行います。つまり、ホームディレクトリ、SSH キー、クラウドの認証情報、ローカルサービスのすべてにアクセスできる状態です。rm -rf や git reset --hard を一度誤るだけで、コミットしていない作業が消えてしまう可能性があります。

一般的な防御策は承認プロンプトですが、これではエージェントを使う意味が薄れてしまいます。長いタスクはコマンドのたびに止まり、20回目のプロンプトあたりで、たいていの人は内容を読まずに承認するようになります。エージェントをより信頼するのではなく、害を及ぼしにくい場所へ移すほうが良い解決策です。エージェントを隔離すべき理由全般については、コーディングエージェントを YOLO モードで安全に実行するで解説しています。本記事では、特定のツールひとつに絞って取り上げます。

Docker Sandboxes がコンテナではなくマイクロVMを使う理由

通常の Docker コンテナはホストのカーネルを共有します。Docker ソケットにアクセスできるプロセスであれば、ファイルシステムをマウントした特権コンテナを起動できてしまいます。Docker 自身のデーモンの攻撃対象領域に関するドキュメントでも、デーモンは root として実行されるため、信頼できるユーザーだけに制御を許可すべきだと警告しています。エージェントは Docker を必要とすることが多いため、/var/run/docker.sock をマウントするというありがちな近道をとると、マシン全体をエージェントに明け渡すことになります。

Docker の隔離レイヤーに関するドキュメントによると、各サンドボックスは独自の Linux カーネルと独自の Docker Engine を持つマイクロVMです。エージェントは Docker-in-Docker に必要な特権設定なしに、サンドボックス内で docker build や docker run を実行でき、ホストのデーモンが関与することは一切ありません。

Docker Sandbox のセットアップ手順

sbx CLI をインストールし、Docker にサインインし、エージェントにモデルの認証情報を渡したら、プロジェクトディレクトリで sbx run を実行します。公式チュートリアルにあるとおり、ホストには Docker Desktop も Docker Engine も必要ありません。

お使いの OS に応じたコマンドでインストールします。

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install Docker.sbx

# Ubuntu: add Docker's apt repo, install, then grant KVM access
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm

Linux では KVM が必要で、ユーザーが kvm グループに属している必要があります。Docker が sbx をテストし、サポートしているのは Ubuntu です。その他のディストリビューション向けには sbx-releases リポジトリにリリースファイルがありますが、Docker は動作を保証していません。プラットフォームごとの前提条件はインストールページで確認してください。

次に、Claude Code のセッションを開始します。

sbx login
sbx secret set anthropic        # skip if you use a Claude subscription
cd ~/my-project
sbx run --name my-project claude

• API キーを使う場合: sbx secret set anthropic でキーをホストに保存します。サンドボックスのプロキシがエージェントの API リクエストにキーを付与するため、エージェントが生のキーを扱うことはありません。Codex の場合は sbx secret set openai を使います。すでにシェルでキーを export している場合は、sbx secret import --dry-run で sbx が認識できるキーを一覧表示でき、sbx secret import を実行すると1つずつ確認したうえで保存されます。
• サブスクリプションを使う場合: シークレットは不要です。Claude の場合は、サンドボックス内で Claude Code が起動したあとに /login と入力します。Codex の場合は、sbx がまずホスト上で OpenAI のサインインを実行し、その後にサンドボックスを作成します。

初回実行時、sbx はデフォルトのネットワークポリシーを選択するよう求めます。その後、エージェントは完全自律モードで起動するため、Claude Code が権限を求めることはなく、フラグを指定する必要もありません。別のエージェントを使う場合は、claude を codex、copilot、cursor、gemini のいずれかに置き換えてください。

マシンの中でエージェントが書き込めるのはプロジェクトフォルダだけですが、そのフォルダ内のものは何でも削除できます。開始前に必ずコミットまたはプッシュしておきましょう。

エージェントの成果物を取り出すには

デフォルトモードでは、Docker Sandbox 内のエージェントによる編集は、ホストのワーキングツリーに即座に反映されます。普段どおりにレビューしてください。

git diff

Docker のクイックスタート用サンプルリポジトリを含む古いガイドでは、.sbx/ 配下のホスト側 worktree でエージェントを作業させる --branch フラグが紹介されています。このフラグは sbx v0.31.0 で削除され、クローンモードに置き換えられました。現在このフラグを指定すると、--clone を使うよう促すエラーが返されます。

クローンモードでは、エージェントがワーキングツリーに直接触れることはありません。Git ワークフローのドキュメントにあるとおり、sbx はサンドボックス内にプライベートな Git クローンを作成し、エージェントはそのコピー上で作業します。エージェントのブランチを fetch するか、エージェントがリモートにプッシュするまで、ホスト側には何の変更も生じません。クローンモードはサンドボックスの作成時にしか選択できないため、初回実行時に --clone を指定してください。既存のサンドボックスを後からクローンモードに切り替えることはできません。

実践的な疑問

どのネットワークポリシーを選ぶべきか

Docker Sandboxes には3種類のローカルネットワークポリシーがあります。

• Open はすべての通信を許可します。
• Balanced はデフォルトで通信を拒否しますが、一般的な開発用サービスは許可します。
• Locked Down は明示的に許可したもの以外をすべてブロックします。

ほとんどのフロントエンド開発には Balanced がおすすめです。パッケージレジストリ、コードホスティングサービス、AI プロバイダーの API がカバーされています。ドキュメントサイトなど、リストにないサイトにエージェントがアクセスする必要がある場合は、sbx policy check network <domain> でブロックされているかを確認し、sbx policy allow network <domain> で許可します。ルールの一覧は sbx policy ls で確認でき、sbx policy rm で削除できます。また、組み込みのエージェントキットは、Locked Down の場合でもサンドボックスごとに独自の許可ルールを追加することがあります。

状態は保持されるか

はい、保持されます。エージェントがインストールしたツールや OS に加えた変更は、サンドボックスを削除するまで残ります。sbx rm my-project を実行すると、環境とそのサンドボックスにスコープされたシークレットが消去されます。グローバルなシークレットとプロジェクトフォルダはそのまま残ります。

再接続するには

既存の Docker Sandbox に再接続するには、sbx run --name my-project を実行します。エージェント名は既存のサンドボックスから読み取られるため、再度指定する必要はありません。引数なしで sbx を実行すると、インタラクティブなダッシュボードが開きます。

Docker Sandboxes とコンテナ、Dev Container、リモート VM の比較

他の選択肢はいずれも、カーネルレベルの隔離、安全な Docker アクセス、組み込みのエグレスポリシーという3つの要素のうち、少なくとも1つを欠いています。

実際に必要なのが環境の隔離ではなく、エージェントが呼び出せるツールの制御である場合は、AI エージェント向けの Docker MCP を参照してください。

Docker Sandboxes の制限事項とコスト

ローカルサンドボックスは無料で実行できます。v0.45.0 のリリースノート時点では、クラウドサンドボックスは実験的機能であり、有効な Docker Agentic Platform サブスクリプションが必要です。モデルの推論コストは、ご自身のキーまたはサブスクリプションで支払います。sbx login の実行には Docker アカウントが必要です。まだ新しいプロダクトのため、料金体系やフラグは変更される可能性があります。

• プロジェクトディレクトリは完全に書き込み可能なため、コミットしていない作業は保護されません。
• エージェントがプッシュしたものや、許可されたドメインに送信したものは、サンドボックスの外に出ていきます。
• リソースは --memory と --cpus で設定します。ローカルでは、メモリのデフォルト値はホストの RAM の半分（上限 32 GiB）です。ドキュメントに記載されているデフォルトの 2 CPU・4 GiB はクラウドサンドボックスに適用される値です。
• SSH によるコミット署名は SSH エージェント転送で機能します。これはホストで SSH_AUTH_SOCK が設定されていればデフォルトで有効です。ただし、サンドボックス内の Git に対して、転送されたキーで署名するよう設定する必要があります。
• Andrew Lock 氏は 2026 年 4 月、サンドボックス内で実行すると、シンプルなプロジェクトでさえ大幅に遅くなったと報告しています。

まとめ

Docker Sandboxes は、コーディングエージェントに独自のカーネル、独自の Docker Engine、ポリシーで制御されたネットワークを提供します。エージェントがマシン上で触れられるのはプロジェクトフォルダだけです。まずは作業をコミットし、sbx をインストールして Balanced を選択し、失っても困らないリポジトリで sbx run --name my-project claude を実行してみましょう。レビューが済むまでエージェントの変更をワーキングツリーに反映させたくない場合は、クローンモードに移行してください。

よくある質問

Docker Sandbox 内でエージェントが起動した開発サーバーを開くにはどうすればよいですか？

sbx ports でポートを公開します。sbx ports my-project --publish 3000:8080 を実行すると、ホストのポート 3000 がサンドボックスのポート 8080 にマッピングされます。--publish 8080 のように単独で指定すると、ホスト側には一時的なポートが自動で割り当てられます。この操作を行うまで、ブラウザからサンドボックス内のサービスにはアクセスできません。また、開発サーバーは 127.0.0.1 ではなく 0.0.0.0 にバインドする必要があるため、多くのフレームワークでは --host 0.0.0.0 フラグが必要です。

エージェントに他のディレクトリを、変更はさせずに読み取りだけ許可することはできますか？

はい、可能です。メインのワークスペースの後に追加のパスを指定し、それぞれの末尾に :ro を付けると読み取り専用になります。例：sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro。エージェントは最初のパスで起動します。各ワークスペースは、サンドボックス内でもホストと同じ絶対パスに表示されます。メインのワークスペースがクローンモードを使用している場合でも、追加のワークスペースはホストから直接マウントされます。

クローンモードのサンドボックスからコミットを取り出すにはどうすればよいですか？

sbx がホストのリポジトリに追加する Git リモート（sandbox- にサンドボックス名を付けた名前）から fetch します。その後は、通常のリモートと同様に diff や merge を行えます。クローン用の Git サーバーはサンドボックス内で動作しているため、サンドボックスが停止している間は git fetch が失敗します。また、sbx rm を実行するとこのリモートも削除されるため、残しておきたいものはサンドボックスを削除する前に fetch またはプッシュしておいてください。