Docker AgentとDocker Sandboxesの違い：役割・安全性・使い分けを解説

AIエージェントにリポジトリを渡すとき、「どのモデルに何をさせるか」と「その処理をどこで安全に動かすか」は別の問題です。Docker AgentとDocker Sandboxesは名前が似ていますが、前者はエージェントを組み立てて実行する基盤、後者はエージェントをホスト環境から隔離する実行環境です。

どちらか一方を選ぶというより、必要に応じて組み合わせます。本記事では、Dockerの公式ドキュメントをもとに役割、導入判断、安全上の注意を整理します。

先に結論：構成するのがAgent、隔離するのがSandboxes

• Docker Agent：モデル、指示、ツール、MCP、サブエージェントの構成と実行を担当
• Docker Sandboxes：AIエージェントがコードを編集・実行する環境をホストから隔離
• 組み合わせ：Docker AgentをSandboxes内で動かし、構成力と隔離を両立

エージェントの役割分担やモデル切り替えを宣言的に管理したいならDocker Agentが中心です。既存のコーディングエージェントを隔離して走らせたいならDocker Sandboxesから考えると整理しやすくなります。

機能比較

重要なのは、Sandboxesがエージェントの思考や役割分担を設計する製品ではない点です。また、Docker Agentの安全モードはツール承認を制御しますが、ホスト全体からの隔離そのものではありません。

Docker Agentが解決する問題

Docker Agent公式ドキュメントでは、モデル、人格、ツール、協働方法をYAMLまたはHCLで宣言し、接着コードを書かずにマルチエージェントを構成できると説明されています。

たとえば、次のような役割分担が考えられます。

1. 調査担当がドキュメントとリポジトリを読む
2. 実装担当が変更案を作る
3. テスト担当がコマンドを実行する
4. レビュー担当が差分と失敗条件を確認する

Docker Agentにはファイル、シェル、メモリ、RAG、Gitなどのツールがあり、Docker MCP Catalogを含むMCPサーバーも接続できます。OpenAI、Anthropic、Google Gemini、AWS Bedrock、Docker Model Runnerなど複数のモデルプロバイダーに対応し、用途ごとにモデルを分けられます。

設定したエージェントはTUIやCLIだけでなく、HTTP API、MCPモード、A2Aからも利用できます。OCIレジストリへ保存して共有できるため、チーム内で実行構成を再利用したい場合にも向いています。

Docker Sandboxesが解決する問題

Docker Sandboxesは、AIコーディングエージェントがファイルを書き換え、依存関係を導入し、コマンドを実行するときの境界を作ります。普段使うホスト環境へ直接エージェントを置く場合と比べ、作業ディレクトリや認証情報を分離しやすくなります。

これは、Claude CodeやOpenAI Codexのようなエージェントを安全に試したいときにも重要です。モデルが高性能でも、誤ったコマンド、信頼できない依存関係、WebやREADMEに埋め込まれた指示によるリスクは残ります。実行環境の境界はモデルの賢さとは別に設計する必要があります。

ただし、サンドボックスを使うだけで安全が完成するわけではありません。ネットワーク、マウント、保存シークレット、公開ポート、成果物をホストへ戻す方法を確認してください。

2つを組み合わせる方法

Dockerの公式手順では、プロジェクトを指定して次のようにDocker Agent用サンドボックスを作成できます。

sbx run docker-agent ~/my-project

Docker Agentは必要なプロバイダーの認証情報を保存シークレットから利用できます。OpenAI、Anthropic、Google、xAI、Mistral、OpenRouterなど、実際に使うプロバイダーだけを設定します。

注意点があります。公式のSandboxes向け手順によると、追加引数なしの起動は内部でdocker-agent run --yoloを使います。--yoloはツール呼び出しを自動承認するautonomousモードの旧エイリアスです。隔離環境内であっても、外部API、ネットワーク、マウント、シークレットへのアクセス範囲は別途制御してください。

4つの安全モードをどう選ぶか

Docker Agent CLIリファレンスには4つの安全モードがあります。

無人実行だからautonomous、とは限りません。予期しない操作を人に確認できない場合、許可されない処理を拒否するrestrictedのほうが適切なことがあります。まずstrictまたはbalancedで必要な操作を観察し、許可ルールと隔離範囲が固まってから自動化を広げるのが安全です。

どちらを選ぶべきか

Docker Agentだけで始めるケース

• 信頼できるローカル環境でプロトタイプを作る
• YAMLで複数エージェントとモデルを管理したい
• MCPやAPIを使った業務エージェントを組みたい
• OCIでエージェント設定を共有したい

Docker Sandboxesだけで始めるケース

• すでに使うコーディングエージェントが決まっている
• ホスト環境から切り離してコード変更を試したい
• プロジェクトごとに依存関係や秘密情報を分離したい

両方を使うケース

• 複数エージェントがコード、テスト、レビューを分担する
• 信頼できないリポジトリや外部コンテンツを扱う
• 再利用できるエージェント構成を、隔離された環境で実行したい
• チームの標準実行方法として権限と再現性を揃えたい

導入チェックリスト

• Agentの完了条件と禁止操作を定義した
• 使用するモデルと予算上限を決めた
• 必要なMCP・ツールだけを有効にした
• safety modeを明示した
• Sandboxesへ渡すワークスペースを限定した
• 必要な保存シークレットだけを登録した
• 外部ネットワークと公開ポートを確認した
• ログと成果物をレビューする担当者を決めた
• 削除、公開、送信、権限変更に承認点を置いた

総評

Docker AgentとDocker Sandboxesは代替関係ではありません。Docker Agentは「何を、どのモデルとツールで、どの役割分担で進めるか」を構成し、Docker Sandboxesは「その実行をどの境界内に閉じ込めるか」を担当します。

まずはDocker Agentのツールページで対応機能を確認し、信頼できる小さなリポジトリをstrictまたはbalancedで動かしてください。ホストへの影響、秘密情報、依存関係を分離したい段階でDocker Sandboxesのツールページを組み合わせると、役割を混同せずに安全性を高められます。

参考資料

• Docker Agent Introduction
• Docker Agent CLI Reference
• Docker AgentをDocker Sandboxesで実行する方法
• Docker Agent GitHubリポジトリ