AIコーディングエージェントへ、パッケージの追加、テスト、Dockerコンテナの起動まで任せると、毎回の権限確認が作業を止めます。しかし確認をすべて省略してホスト上で動かすと、誤った削除、設定変更、秘密情報の読み取り、意図しない外部通信まで許してしまう可能性があります。
Docker Sandboxesは、この問題に対して「エージェントを隔離されたローカルmicroVMへ入れる」という選択肢を提供します。本記事では2026年8月11日時点の公式情報を基に、macOS、Windows、Ubuntuへの導入、Claude Code・Codexの起動、Direct/Cloneモードの違い、資格情報とネットワークの安全な設定を解説します。
先に結論:自動実行の範囲を広げたいときの隔離層
Docker Sandboxesは、AIモデルそのものでも、一般的なDockerコンテナを起動するだけのラッパーでもありません。各サンドボックスに独立したmicroVM、ファイルシステム、ネットワーク、Dockerデーモンを用意し、その中でコーディングエージェントを動かします。
| 比較項目 | ホストのターミナル | 通常のDockerコンテナ | Docker Sandboxes |
|---|---|---|---|
| 主な目的 | 日常の開発操作 | アプリ実行環境の分離 | AIエージェントの隔離実行 |
| 隔離境界 | ホストユーザー権限 | コンテナ/ホストカーネル | エージェントごとのmicroVM |
| Docker利用 | ホスト設定に依存 | 通常はホスト側デーモン等を利用 | サンドボックス専用Dockerデーモン |
| 作業ファイル | ホストを直接編集 | マウント設定次第 | DirectまたはCloneモードを選択 |
| エージェント設定 | 自分で導入・管理 | イメージを自作することが多い | 対応エージェント別テンプレート |
特に、Claude Code、OpenAI Codex、OpenCodeのように、ファイル編集とシェル実行を組み合わせるツールを長時間動かす場合に向きます。
Docker Sandboxesで守れるもの、守れないもの
microVMの外側は自動的に共有されない
エージェントがパッケージを追加したり、システム設定を変えたり、別のDockerコンテナを起動したりしても、それらは基本的にサンドボックス内へ収まります。案件ごとに依存関係が混ざるのを防ぎ、作業終了後はサンドボックスごと削除できます。
ただし、作業ツリーは既定で読み書きされる
ここが最も重要です。既定のDirectモードは、指定したプロジェクトをサンドボックスへ読み書き可能でマウントします。エージェントがファイルを変更すると、ホスト側の作業ツリーにもすぐ反映されます。
「microVMだからホストのリポジトリは絶対に変わらない」という理解は誤りです。ホストの作業ツリーまで分離したい場合は、後述するCloneモードを選びます。
外部通信と共有資格情報は別途管理する
サンドボックスには独立したネットワークがありますが、外部通信の許可範囲はポリシー次第です。また、エージェントが利用できるOAuthやAPIキーには、その資格情報が本来持つ権限があります。microVMは認証先での削除、公開、送信、課金まで無害化するものではありません。
対応OSと前提条件
公式の前提条件は次のとおりです。
| OS | 主な条件 |
|---|---|
| macOS | macOS Sonoma 14以降、Apple Silicon |
| Windows | Windows 11、64bit Intel/AMD、Windows Hypervisor Platform |
| Ubuntu | Ubuntu 24.04以降、x86_64またはaarch64、KVMが利用可能 |
仮想マシン内のUbuntuで使う場合は、ネストされた仮想化が必要です。Docker Desktopは必須ではありません。加えて、利用するエージェントに応じてAnthropic、OpenAI、Googleなどの認証方法を準備します。
インストール方法
macOS
brew trust docker/tap
brew install docker/tap/sbx
sbx loginWindows
PowerShellまたはWindows Terminalで実行します。事前にWindows Hypervisor Platformを有効にしてください。
winget install -h Docker.sbx
sbx loginUbuntu
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm
sbx loginインストール後に sbx version でCLIが見えることを確認します。Linuxで起動できない場合は、まずKVMとネストされた仮想化の状態を確認してください。
Claude Code・Codex・Gemini CLIを起動する
対象プロジェクトへ移動し、利用するエージェントを一つ選びます。
cd ~/my-project
# Claude Code
sbx run claude
# OpenAI Codex
sbx run codex
# Gemini CLI
sbx run gemini
# OpenCode
sbx run opencode初回はエージェント固有の認証を求められる場合があります。Codexは、事前にホスト側でOAuthを設定することもできます。
sbx secret set -g openai --oauth
sbx run codexDockerのCodexテンプレートは、サンドボックス内で承認と内蔵サンドボックスを省略するオプションを付けて起動します。強い権限を与える設計だからこそ、マウント範囲、資格情報、ネットワークを実行前に確認してください。
なお、ホスト側の ~/.codex などユーザー単位の設定は自動では取り込まれません。必要なルールはプロジェクト内の設定へ置くか、Docker Sandboxesの共有Skill機能を明示的に設定します。
DirectモードとCloneモードの選び方
Directモード:変更をすぐホストへ反映したい
sbx run claude の既定動作です。現在の作業ツリーを直接共有するため、普段のエディタで差分を見ながらAIへ修正を任せられます。
向いている場面は、小さな修正、対話しながらの実装、人間が常に差分を確認する作業です。実行前にコミットまたはバックアップを作り、不要なディレクトリを追加マウントしないでください。
Cloneモード:ホストの作業ツリーから変更を分離したい
Gitリポジトリでは --clone を付けると、サンドボックス内に別のクローンを作ります。
cd ~/my-project
sbx run --clone claudeこのモードでは、エージェントの変更はサンドボックス内のクローンへ残り、ホストの元リポジトリは読み取り専用で参照されます。必要なコミットをpushまたはfetchしてからサンドボックスを削除してください。削除後に未退避の変更を取り戻すことはできません。
長時間の自動実行、複数案の並行実装、初めて扱うIssueにはCloneモードが安全側です。
日常的に使う管理コマンド
# 一覧を確認
sbx ls
# 停止
sbx stop my-sandbox
# 再接続
sbx run --name my-sandbox
# 完全に削除
sbx rm my-sandbox停止しただけでは、追加パッケージ、Dockerイメージ、設定、コマンド履歴が残ります。クリーンな状態へ戻したい場合は削除して作り直します。
実務向けの安全チェックリスト
- 作業範囲を決める:監視しながら使うならDirect、無人実行ならCloneを第一候補にする
- 秘密情報をリポジトリへ置かない:
.envを丸ごと共有せず、sbx secretと最小権限の資格情報を使う - ネットワーク先を絞る:パッケージ配布元、Gitホスティング、必要なAPIだけを許可する
- 不可逆操作を分離する:本番デプロイ、外部投稿、削除、課金は人間の承認を残す
- 成果物を確認する:テスト結果だけでなく、Git差分、依存関係、生成ファイルをレビューする
- 不要になった環境を削除する:ディスク使用量と残存資格情報を抑える
チーム導入では、個人ごとの設定だけに頼らず、Docker AI Governanceによる組織単位のネットワーク、ファイルシステム、MCPポリシーも検討します。ガバナンス機能は sbx CLIとは別の有料契約です。
どんな人に向くか
- AIエージェントへ依存関係の追加やDocker利用まで任せたい
- 手元のPCで実行しながら、ホストのシステム領域は分離したい
- Claude Code、Codex、Gemini CLI、OpenCodeを同じ隔離方式で比較したい
- 長時間または無人のコーディングタスクをCloneモードで走らせたい
- チーム共通のネットワークとファイルポリシーを設定したい
一方、AIへ読み取りだけを許可する場合や、数分の小さな修正だけなら、通常の権限確認で十分なこともあります。microVMの起動とディスク使用量を増やす価値があるか、タスクの危険度と自動化時間で判断してください。
まとめ
Docker Sandboxesの価値は、エージェントへ強い操作権限を与えること自体ではなく、その権限が届く範囲をmicroVM、ワークスペース、資格情報、ネットワークの層で整理できる点にあります。
最初は小さなテスト用リポジトリでDirectモードを確認し、次にCloneモードでホスト側へ変更が出ないことを試してください。そのうえで、Claude CodeやOpenAI Codexへ実際のIssueを渡し、差分と外部通信をレビューする流れがおすすめです。
Docker Sandboxesのツール情報を見る / 開発・プログラミング向けAIツール / エージェント・自動化ツール
公式情報
※ 本記事の情報は2026年8月11日時点です。対応OS、エージェント、コマンド、料金、ガバナンス機能は変更される場合があります。



