Docker Engineering が GitHub に公開した docker/docker-agent は、ひとことで言えば「AI エージェントを作って、動かして、配るための土台」です。ふつう AI エージェントというと、個別のアプリやチャット画面の中に閉じたものを想像しがちですが、このリポジトリはそこを Docker の流儀に寄せています。YAML で定義し、CLI から動かし、OCI registry に載せて共有する。今これを取り上げるのは、生成 AI の話が「モデルを使う」段階から「運用できる部品にする」段階へ移っているのが、かなりはっきり見えるからです。
docker agent run で始めるAIエージェント基盤このリポジトリの README は、docker-agent を「AI Agent Builder and Runtime」と説明しています。Docker Engineering が作ったもので、AI エージェントを構築し、実行し、共有するための仕組みだと位置づけています。特徴的なのは、コードを書き込むより先に、YAML でエージェントを定義する点です。README では agents: の下に root を置き、model に openai/gpt-5-mini、description に「A helpful AI assistant」、instruction に振る舞いの指示を書き、toolsets から docker:duckduckgo のような MCP server をつなぐ例が載っています。
動かし方も Docker らしく、CLI からの操作が前面に出ています。docker agent という形で使え、docker agent run で既定のエージェントを起動したり、docker agent new で対話的に新しいエージェントを作ったりできます。自分で用意した agent.yaml をそのまま実行することもできますし、myorg/agent:tag のように OCI registry 上のイメージを引いて実行することもできます。つまり、エージェントを「ローカルで試すだけのもの」にせず、配布・再利用できる単位として扱う考え方です。
README は機能面もかなり広く触れています。複数の専門エージェントが仕事を分担する multi-agent architecture、MCP を通じた豊富な tool ecosystem、OpenAI や Anthropic、Gemini、AWS Bedrock、Mistral、xAI、Docker Model Runner などに広がる provider agnostic な設計、そして think、todo、memory といった reasoning 用ツールが挙げられています。検索や参照を組み合わせる RAG についても、BM25、embeddings、hybrid search、reranking を差し替え可能にすると書かれています。最後に、作ったエージェントを OCI registry に push して、どこでも pull して走らせられる点が強調されています。
導入方法も複数あります。Docker Desktop 4.63+ では CLI plugin が最初から入っており、Homebrew なら brew install docker-agent、あるいは GitHub Releases から binary を落として使う形です。モデル用の API key は少なくとも1つ必要で、OPENAI_API_KEY のほか ANTHROPIC_API_KEY や GOOGLE_API_KEY などが例示されています。ただしクラウド API key だけを前提にしているわけではなく、Docker Model Runner でローカルモデルを使う道も用意されています。README はドキュメントへの導線も細かく、Installation、Set Up a Model、Quick Start、Agents、Models、Tools、Multi-Agent、RAG などのページを案内しています。さらに、このプロジェクト自体を docker agent run ./golang_developer.yaml でビルドしていると書いており、道具を作る側が同じ道具で自分を作っている構図になっています。
この公開でいちばん面白いのは、Docker が AI エージェントを「機能」ではなく「配れる成果物」にしようとしていることだと思います。通常の AI エージェント開発は、プロンプト、ツール接続、モデル選定、状態管理がそれぞれ別の文脈で扱われがちです。すると、動いたとしても他人の環境に渡した瞬間に壊れやすい。docker-agent はそこを YAML と OCI registry でまとめてしまうので、再現性の問題にかなり正面から向き合っています。これは地味ですが、実運用ではかなり効きます。
一方で、ここには Docker らしい強みと同時に、少し重さもあります。エージェントは軽快に試せるほうが魅力なのに、docker agent、API key、MCP server、registry、RAG までをひとまとまりで扱うと、学習コストはそれなりに出ます。README の印象では、これは「個人が遊ぶためのボタン一つの AI」ではなく、チームや組織で再利用する前提の道具です。だからこそ筋は通っていますが、カジュアルな用途から入る人には少し大きく見えるはずです。
別の見方をすると、Docker がこの領域に入ってきたのは自然でもあります。AI エージェントは単なるプロンプトではなく、外部ツールを呼び、複数モデルを使い分け、状態を持ち、しばしば権限管理も必要にします。ここではコンテナや CLI、registry のような Docker が得意な領域がそのまま価値になる。つまり Docker は、新しい AI 専用の魔法を足したというより、既に得意だった配布と実行の仕組みを AI に適用している。これは派手さはないものの、実際にはかなり強い戦略ではないでしょうか。
もう一つ気になったのは、README が provider agnostic を前面に出している点です。OpenAI でも Anthropic でも Gemini でもよい、ローカルでもよい、という姿勢は柔軟ですが、裏返すとベンダーの変化にユーザーを巻き込まないための逃げ道でもあります。AI の世界はモデルの入れ替わりが早いので、ここを抽象化しておくのは賢い。とはいえ、抽象化が進むほど、どのモデルをどう選ぶかという本質的な判断は利用者側に残ります。道具は整っても、品質の責任は消えません。その意味で docker-agent は「答え」を売るというより、「運用しやすい入れ物」を出してきたプロジェクトだと受け止めています。
これが広がるかどうかは、機能の多さよりも、実際にどれだけ素直に使えるかで決まりそうです。AI エージェントは便利そうに見えて、実際には失敗の切り分けが面倒です。だから、YAML で定義できて、CLI で動き、registry で配れ、しかも Docker Desktop に最初から入っている、という設計はかなり実務寄りです。派手ではないですが、AI を本当に「ソフトウェア」に寄せるなら、こういう方向が一番現実的なのだと思います。
参考: GitHub - docker/docker-agent: AI Agent Builder and Runtime by Docker Engineering