「このDockerfileを軽くして、rootじゃないユーザーで動くようにして」とAIエージェントに頼んだら、もっともらしいけれど何となく一般的な答えが返ってきた。逆に「もう使っていないコンテナやイメージを掃除して」と頼んだら、本当は消えてほしくないものまで巻き込みかねないコマンドが返ってきて、実行前に手を止めた。
そんな経験がある人に向けて、Dockerは2026年9月下旬、公式スキル集「Docker Skills」を公開した。公式ドキュメントによると、Claude CodeやCursorなど手元のAIエージェントへ追加するだけで、この2つの不安に応えられるようになる。
公式ノウハウをそのままエージェントへ
Docker Skillsは、DockerがDocker関連の作業のために書いた「スキル」の集まりだ。ここでいうスキルとは、SKILL.mdという1つのファイルにまとめた指示書のことで、AIエージェントはこれを読み込むと、そこに書かれたやり方に沿って提案するようになる。
GitHubリポジトリによると、Docker Skillsは次の5つの製品カテゴリに分かれた、11個のスキルで構成されている。
- Dockerfile & Build(2個): Dockerfileの初期化とビルドの最適化
- Docker Compose(1個): 複数コンテナ構成の設定パターン
- Docker Sandboxes(4個、うち2個は実験的): 隔離環境の構築・管理
- Docker Agent(3個): エージェントの設定・実行・デプロイ
- Cross-Product(1個): 破壊的操作の確認ポリシー
ライセンスはApache License 2.0で無料公開されている。2026-09-22にv0.1.0、2026-09-23に最新のv0.3.0がタグ付けされ、gihyo.jpの報道によれば2026-09-24前後に公表された。
Dockerfile改善は何が変わるか
具体的に何が変わるのか、docker-build-strategiesというスキルの中身で見てみる。このスキルのSKILL.md本文には、本番向けDockerfileの書き方として次のようなノウハウが並んでいる。
- ビルド時の依存関係と実行時の依存関係を分け、
FROM ... AS buildで作った成果物だけをCOPY --from=buildで実行用イメージへ移す(マルチステージビルド) - 変更頻度が低い命令(依存ファイルのコピーとインストール)を先に置き、
RUN --mount=type=cacheでビルドキャッシュを使い回す - レジストリの認証情報は
ARGやENVに渡さず、RUN --mount=type=secretで隔離する。ARG/ENVはイメージのレイヤーに残ってしまうため - 専用のユーザーを作り、rootではなく非rootで実行する
これ自体は書籍やブログでも見かける定石だが、これまでは頼むたびにエージェントがどこまで守ってくれるか運任せだった。Docker Skillsを追加すると、この一覧がエージェントの参照する指示そのものになる。
壊れる操作の前に確認を求める
Dockerfileの最適化より踏み込んでいるのが、docker-destructive-guardrailsというスキルだ。SKILL.mdの本文には、こう書かれている。
Use this skill before running, or recommending, any Docker command that deletes, wipes, resets, or otherwise irreversibly changes state
対象になるのはコンテナ・イメージ・ネットワーク・ボリュームの削除や初期化を伴うコマンド一式だ。具体的にはdocker rm・docker rmi・docker system prune・docker volume rm・docker network pruneなどが挙がっている。ユーザーが「クリーンアップして」「リセットして」のような曖昧な言い方をした場合も対象に含まれる。
このスキルは、エージェントに実行前の振る舞いとして次の一文を指示している。
state exactly what will be deleted, stopped, or lost, and get explicit confirmation from the user before running it
何が消えるかを具体的に列挙し、ユーザーの明示的な承認を得るまでは実行しないという指示だ。例外は、エージェント自身が同じ作業の中で作ったテスト用コンテナを片付ける場合だけで、それ以外はすべて確認が要る。自分もふだんエージェントにdocker system pruneのようなコマンドを頼むとき、本当に必要なものまで消えないか毎回不安だった。この一文を読んで、Docker社内でも同じ不安が言語化されていたのだと腑に落ちた。
1つのスキルが複数エージェントで動く理由
ここまでの2つのスキルは、Claude Codeだけでなく次の7種のエージェントに、それぞれ決まった置き場所へ追加すれば読み込ませられる。
| エージェント | 追加先 |
|---|---|
| Claude Code | ~/.claude/skills/ |
| GitHub Copilot | .github/skills/ |
| Cursor | ~/.cursor/skills/ |
| OpenAI Codex | ~/.codex/skills/ |
| Gemini CLI | ~/.gemini/skills/ |
| OpenCode | ~/.config/opencode/skills/ |
| Google Antigravity | .agents/skills/ |
7社がそれぞれ違う設計のエージェントを作っているのに、Docker Skillsという1つの配布物がそのまま読める。これは、Dockerが7エージェント分の個別対応を作り込んだからではない。
SKILL.mdという同じ形式のファイルを読む取り決め自体が、2025年12月にAnthropicが公開した「Agent Skills」というオープンな共通仕様としてすでに存在していた。Cursor・GitHub Copilot・Gemini CLIなどは、後からこの仕様への対応を進めていた側になる。Dockerがしたのは、この共通の器にDocker自身のノウハウを書いて流し込むことだけになる。
自分のエージェントに追加する方法
追加そのものは、対応済みのエージェントであれば数コマンドで終わる。公式ドキュメントとGitHubのREADMEによると、方法は主に3つある。
- どのエージェントでも共通で使えるCLIを使う:
npx skills add docker/skills(全スキルを入れるなら--all) - 各エージェントのプラグインマーケットプレイス経由で入れる。Claude Codeなら
/plugin marketplace add docker/skillsに続けて/plugin install docker-skills@docker - Gemini CLIは拡張機能として
gemini extensions install https://github.com/docker/skills
入れたあとは、「Make this Dockerfile smaller and run as a non-root user」のように、これまでどおり自然言語で頼むだけでよい。エージェント側が、読み込んだスキルの指示に沿って提案するかどうかを判断する。
使うときに気をつけること
Docker Skillsのmainブランチは随時更新される開発チャネルで、タグ(v0.3.0など)の方が固定されたスナップショットになる。プロジェクトで使うなら、mainではなくタグを指定して導入するとバージョンが不用意に変わらない。また11個のスキルのうちdocker-sandboxes-envとdocker-sandboxes-kitsの2つは、GitHubのREADMEで実験的(experimental)と明記されている。まだ変更が入りやすい段階にあると見ておくとよい。
まとめ
Dockerは2026年9月、Dockerfileの最適化ノウハウと、破壊的なコマンドの前に確認を求める安全策をまとめた公式スキル集「Docker Skills」を公開した。Claude Code・Cursor・GitHub Copilotなど7種のAIエージェント向けに用意されており、追加はnpx skills add docker/skillsなどのコマンド一つで済む。以降は自然言語で頼むだけで、Docker公式の指針に沿った提案が返る。
この仕組みを支えているのは、Docker独自の作り込みではない。Anthropicが2025年12月に公開した「Agent Skills」という共通の配布形式に、Dockerがノウハウを書いて乗せただけだ。手元のエージェントにDocker関連の作業を任せている人は、追加して試す価値がある。
コメント
気づきや感想をどうぞ記事への補足や、読んで考えたことをお寄せください。個人情報や、他の人を傷つける内容の投稿はお控えください。
投稿にはGoogleログインが必要です。
Googleでログイン投稿にはGoogleアカウントの表示名が公開されます。メールアドレスは取得・公開しません。
コメントを読み込んでいます…