Docker Agent（旧cagent）とは — YAMLで作るマルチエージェント入門

Docker Agent（旧名 cagent）は、YAMLの設定ファイルでAIエージェントを定義し、ターミナルから実行できる Docker 製のオープンソースツールです。Docker CLIプラグインとして docker agent で動き、複数のエージェントに役割を分けて仕事を委譲する「マルチエージェント構成」を、数十行のYAMLで組めるのが特徴です。ライセンスは Apache-2.0 です。

結論から言うと、「複数のLLMとMCPサーバーを組み合わせた自分専用のエージェントチームを、設定ファイル中心で素早く試したい人向けのランタイム」です。コーディングに特化した製品ではなく、汎用のエージェント実行基盤という位置づけです。2026年10月にHacker Newsで約300ポイントを集めて話題になりましたが、「YAMLが苦手」「ノーコードの訴求には疑問」といった声もあります。この記事では、公式ドキュメントとリポジトリで確認できた範囲で、仕組みと最短の使い方を整理します。

- マルチエージェント構成: ルートのエージェントが sub_agents に列挙した専門エージェントへ仕事を委譲する
- 複数プロバイダ対応: OpenAI、Anthropic、Gemini、AWS Bedrock、Mistral、xAI、Docker Model Runner（ローカルモデル）など
- MCPサーバー連携: ローカル、リモート、Dockerベースのどれでも接続できる（docker:duckduckgo のようにカタログ参照も可能）
- 組み込みツール: think（思考）、todo（タスク管理）、memory（記憶）、タスク委譲
- RAG: BM25、埋め込み、ハイブリッド検索、リランキングに対応
- OCIレジストリでの共有: エージェント定義をDocker HubなどにpushしてほかのPCでpullできる
- Go SDK: YAMLではなくGoのコードからも利用できる

ちなみに Docker の組み込みAIアシスタント「Gordon」（docker ai）とは別物です。公式ドキュメントでも混同しないよう注記されています。

Docker Desktop 4.63以降では最初から同梱されており、そのまま docker agent が使えます（4.49〜4.62では cagent という名称）。Docker Engineだけの環境などでは、次のいずれかで入れます。

プラグインとして置かず、docker-agent という単体バイナリとして直接実行することも可能です。LLMを使うには、いずれかのAPIキーを環境変数に設定します（Docker Model Runnerのローカルモデルだけなら不要です）。

まず1体のエージェントを定義します。以下は公式READMEにあるサンプルで、DuckDuckGo検索のMCPサーバーを持つ汎用アシスタントです。agent.yaml として保存してください。

実行は次のとおりです。YAMLを書かずに対話形式で雛形を作る docker agent new や、引数なしの docker agent run（デフォルトエージェント）も用意されています。

各エージェントの必須項目は model、description、instruction の3つで、toolsets、sub_agents、fallback、max_iterations などは任意です。model は プロバイダ/モデル名 の形式で指定します。

公式ドキュメントにある「バグ調査チーム」の例です。ルートの調査役が原因を分析し、修正の実装は fixer に委譲します。エージェントごとに別のモデルを割り当てられるため、調査は安価なモデル、実装は別社のモデル、といった使い分けができます。

- ルートエージェントはユーザーとの窓口で、最初に定義したエージェント（または root という名前）がデフォルトになる
- 別のエージェントから始めたい場合は docker agent run config.yaml -a agent_name
- サブエージェントがさらにサブエージェントを持つ階層構成も可能
- 各エージェントは独自のモデルとコンテキストを持ち、知識は共有されない
- 委譲先の選択には各エージェントの description が使われるため、役割が伝わる書き方が重要

リポジトリの examples/ には dev-team.yaml（プロダクトマネージャー・デザイナー・エンジニア）、blog.yaml（調査・執筆・レビュー）、coder.yaml（計画・実装・調査）など、マルチエージェントの実例が多数あります。自作する前にここから探すのが近道です。

MCPは toolsets に type: mcp を追加して接続します。Dockerのカタログにあるサーバーは ref: docker:名前 で参照でき、独自のローカル／リモートサーバーも指定できます。MCP自体の考え方は Claude CodeのMCP連携ガイド で詳しく解説しています。また、既存のCLIツールをエージェントから扱いやすくする発想については CLI-Anything の記事も参考になります。

APIキーを使わずローカルで動かしたい場合は、Docker Model Runner（DMR）をモデルのプロバイダに指定します。models セクションで provider: dmr を定義し、エージェントの model からその名前を参照します。次はリポジトリの examples/dmr.yaml をもとにした最小構成です（DMRの既定エンドポイントは http://localhost:12434/engines/llama.cpp/v1）。

なお、DMRでホストしたモデルはマルチモーダルが自動検出されないため、画像入力などは設定で明示する必要があるとサンプルのコメントに書かれています。

作ったエージェントはコンテナイメージのようにレジストリで配布できます。Docker Hubや、OCI互換のレジストリが使えます。pushすると、リポジトリが無ければ自動で作成されます。

チームで同じエージェント定義を使い回したい場面で便利です。ただし、配布物にはプロンプトやツール設定が含まれるため、公開リポジトリにAPIキーなどの機密を入れないよう注意してください。

以下はあくまで大まかな位置づけの比較です。各製品は機能追加が早いため、最新の仕様は公式情報で確認してください。

ポイントは、Docker Agentが「ライブラリではなく、設定ファイルを読んで動くランタイム」であることです。コードを書かずに構成を試せる一方、複雑な制御ロジックが必要になればGo SDKやほかのフレームワークのほうが向く場面もあります。

HNのスレッド（約300ポイント、145コメント）では、肯定と批判の両方が出ていました。Docker社員とみられるコメント投稿者は、cagentが「エージェント版のCompose」という発想で生まれたこと、Docker Sandboxesより前から存在することを説明し、Go SDKがYAMLの代替になること、ACP対応を検討していることにも触れています。

- 批判: 説明が曖昧で「ノーコード」の訴求に疑問、YAML設定への好みが分かれる、Dockerブランドの名称が紛らわしい
- 不具合報告: Codexを制御する用途でセッションが不安定との声があり、Docker側は詳細を聞いて改善を検討するとした
- セキュリティ: サンドボックスの仕組みや攻撃経路についての文書が見つけにくいという指摘
- 評価点: Go実装への称賛、開発側がフィードバックに丁寧に応じている点

導入時の注意として、エージェントにシェルやファイルシステムのツールを渡すと、LLMの判断で実際にコマンドが実行されます。本番の環境や機密データのあるディレクトリで試す前に、隔離した環境（VMやコンテナ）で動かすことをおすすめします。また、公式READMEによると匿名の利用データが収集されます（詳細は公式のテレメトリのページを参照してください）。