Docker SandboxesとYOLOモード──「危険な権限」ごとエージェントを隔離するという発想

コーディングエージェントに「ファイルの許可プロンプトなしで、好きなだけコマンドを実行させる」モードは、しばしば「YOLOモード」と俗称される。速いが、ホスト環境を壊すリスクと隣り合わせだ。Docker社が展開する「Docker Sandboxes」は、この速さと安全性のトレードオフを、隔離環境そのもので解決しようとする製品だ。公式製品ページの言葉を借りれば「YOLO mode, safely（安全にYOLOモード）」を掲げている。

何を解決する製品か

Docker公式の製品ページによれば、Docker Sandboxesは「Claude Code、Copilot CLI、Codex、OpenCodeなど、監督なしで安全に実行される必要があるAIエージェント向けの、使い捨ての隔離されたサンドボックス」だ。各エージェントは専用のmicroVM内で動き、開発環境と、マウントされたプロジェクトのワークスペースだけを持つ。エージェントはパッケージをインストールしたり、設定を変更したり、自分自身のDockerコンテナを立ち上げたりできるが、ホスト側は一切変更されない、と説明されている。

公式FAQはこの隔離レベルについて次のように書いている。

"A sandbox is a microVM isolated environment that protects your filesystem and network from agents running inside it."

「サンドボックスはmicroVMで隔離された環境で、内部で動くエージェントからファイルシステムとネットワークを保護する」というのが基本設計だ。

対応エージェント

公式FAQによれば、標準でサポートされているのは次の6つ。

• Claude Code
• Gemini CLI
• Copilot CLI
• Codex
• OpenCode
• Kiro

独自のエージェントを追加設定することも可能とされている。

"--dangerously-skip-permissions"がデフォルトになる設計

製品ページで目を引くのが、Claude Codeの許可プロンプトをスキップするフラグ--dangerously-skip-permissions（このフラグ名自体はClaude Code側の機能）への言及だ。ページには次のように書かれている。

"Default: –dangerously-skip-permissions. Use permissive modes with confidence. In fact, that's the default."

つまりDocker Sandboxesは、この「危険を承知でスキップする」モードを前提に設計されており、隔離されたmicroVMの中でならこのモードを使っても安全だ、という主張になっている。FAQも同様の説明を補足している。

"YOLO mode (--dangerously-skip-permissions) gives agents autonomy with no approval prompts. Essential for speed, but risky without guardrails. Sandboxes make it safe by isolating each agent inside a dedicated microVM."

ネットワーク・ファイルシステム・認証情報の制御

製品ページの「Why sandboxes」セクションでは、Filesystem・Network・Credentialsの3つの制御軸が挙げられている。組織全体でこれらの制御を強制したい場合は、別プロダクトの「Docker AI Governance」を使う、という案内もある。

インストールコマンドはOS別に案内されている。

CLIコマンド名はsbx。

VMとの違い

FAQは「サンドボックスとVMの違い」についても答えている。

"Sandboxes run fully isolated in microVMs, giving more isolation without paying the full cost of running a VM. This lets them do things that need more permissions safely, like running additional Docker containers."

通常のVMを都度起動するコストを払わずに、より強い隔離を得られる、という位置づけだ。エージェントがサンドボックス内でさらにDockerコンテナを立ち上げるといった、より高い権限を要する操作も安全に行える。

「Docker Agent」という複数エージェント連携の仕組み

Docker Sandboxesと並んで、Docker公式ブログ（2026年3月11日付、Esteban Maya Cadavid氏・Marco Franzon氏）は「Docker Agent」というオープンソースツールを紹介している。これは単一の汎用モデルに全部をやらせるのではなく、役割ごとに特化したAIエージェントのチームを定義するための仕組みだ。ブログに掲載された設定例では、プロダクトマネージャー役・デザイナー役・QA担当役・エンジニア役・修正担当役といった複数のエージェントが、それぞれ異なるモデル（例：openai/gpt-5）と指示・ツールセットを持ち、sub_agentsとして連携する構成が示されている。ブログはこの仕組みと、隔離環境を提供するDocker Sandboxesを組み合わせることで「1人で全部の役割をこなす代わりに、専門化したAIエージェントのチームに仕事を任せる」開発体験を描いている。

利用者からのコメント

製品ページには、開発ツール企業からの推薦コメントが掲載されている。個人向けAIエージェントツール「NanoClaw」の作者Gavriel Cohen氏は「NanoClawは『エージェントにセキュリティを信頼させるのではなく、エージェントの周りに壁を作る』という原則で作られた」とコメントし、ターミナルツール「Warp」のエンジニアリングリードBen Navetta氏は、ローカル・クラウドを問わず一貫した環境でエージェントを走らせるためSandboxesを自社製品に統合する意向を述べている。

料金：CLI自体は無料、組織向けガバナンスのみ有料

Docker公式ドキュメント（docs.docker.com/ai/sandboxes/）をcurlで直接取得すると、製品ページ・ブログには無い料金体系の記載が確認できた。原文をそのまま引く。

"The sbx CLI is free to use, including for commercial work. Only organization governance requires a separate paid subscription."

（訳）「sbx CLIは商用利用を含めて無料で使える。組織単位のガバナンス機能のみ、別途有料サブスクリプションが必要」

つまり個人・チームがsbxコマンドでサンドボックスを使うこと自体には料金が発生せず、組織管理者が「ネットワーク・ファイルシステム・MCPポリシーを全社員のマシンに一律適用する」ようなガバナンス機能を使う場合にのみ、別建ての有料サブスクリプションが必要になる、という切り分けだ。

GitHub Actions上でDocker Sandboxesを使う実例

Docker公式ブログ（2026年8月21日付、著者Oleg Selajev氏）は、Docker Sandboxesの実際の利用例として、GitHub Actions上でのCI利用を紹介している。原文によれば「2026年7月、GitHub Agentic WorkflowsがDocker Sandboxesをサポート対象のエージェントランタイムとして追加した」（原文: "In July 2026, GitHub Agentic Workflows added Docker Sandboxes as a supported agent runtime"）。この統合はGitHub Agentic Workflows（gh-aw）のバージョン0.82.9で導入されたと明記されている。

紹介されているサンプルでは、GitHub-hostedのUbuntuランナー上でDocker Sandbox（sbx）を起動し、その中でJavaの統合テスト（Testcontainers経由でPostgreSQLを使用）を実行し、意図的に仕込んだバグを見つけて修正し、ドラフトのプルリクエストを開く、という一連の流れが実演されている。設定例（YAML frontmatter）では、サンドボックス内部ではエージェントにsudo権限とほぼ制限のないシェルアクセスを与える一方、サンドボックスの外側（ワークフロー全体）はネットワーク許可リスト（defaults・github・containers・javaのみ）とGitHubトークンのスコープで絞り込む、という「内側は自由・外側は狭い」構成になっている。

Claude Code自体のサンドボックス機能との違い

Claude Codeにも、Bashコマンドの実行を制限する独自のサンドボックス機能がある（詳しくはClaude Codeのサンドボックス・Bash実行制御を参照）。Docker Sandboxesはこれとは別の、OSレベル・microVMレベルでの隔離を提供するインフラという位置づけであり、両者は競合するというより重なる部分のある別レイヤーの防御策と捉えるのが妥当だ。エージェントが読み込む外部コンテンツ自体が攻撃経路になりうる点については、プロンプトインジェクションとはも参照してほしい。

正式なリリース日は公式ページに明記がなかった

• 本記事はDocker公式の製品ページとブログ記事1本ずつを一次資料としている。実際にDocker Sandboxesを導入した際のパフォーマンス（起動速度、リソース消費）や、実際のセキュリティインシデントの有無についての第三者検証は確認できていない。
• 公式ブログの日付は2026年3月11日だが、製品ページ自体に「Docker Sandboxesがいつ正式にリリースされたか」を明記した日付は見当たらなかった。検索時点の情報では2026年3月31日にリリースされたという記述も見られたが、Docker公式ページ本文からは確認できなかったため、本記事では正確なリリース日の記載を避けた。
• 「microVM」による隔離の技術的な実装詳細（どのハイパーバイザー技術を使っているかなど）は、製品ページ・ブログ・ドキュメントのトップページのいずれにも記載がなく、確認できていない。ドキュメント内には「Architecture」という詳細ページへのリンクがあったが、その本文までは今回の調査範囲では読み込んでいない。
• GitHub Actions連携の紹介記事はDocker社自身のブログであり、実際にCIパイプラインへ組み込んだ第三者ユーザーの独立した体験談ではない。紹介されているサンプルも「意図的に仕込んだバグ」を使ったデモである点は明記しておく。