AIにDockerを片付けさせる前に。公式スキルDocker Skillsが書いた「消す前に止まる」ルール

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、gihyo.jpに載った「Docker、AIコーディングエージェント向けの公式スキル「Docker Skills」を公開」という記事を紹介するね。

gihyo.jp（技術評論社）「Docker、AIコーディングエージェント向けの公式スキル「Docker Skills」を公開」より（呼び出し方の説明）

ユーザーが依頼のたびにスキル名を指定する必要はなく、複数の製品にまたがる作業では複数のスキルを使える。

2026年9月24日にDockerのArnaud Héritier氏が案内したのが「Docker Skills」です。

gihyo.jpの記事によると、AIコーディングエージェントに読ませる公式の手順書の集まりで、Claude Code、Codex、GitHub Copilot、Cursorなどで使えます。

スキルごとに SKILL.md というファイルが入っていて、「どんな作業で使うか」と「その作業をどう進めるか」が書かれています。エージェントは、あなたの依頼文とスキルの説明を照らし合わせて、関連する指示を読み込みます。

ここで見てほしいのは、呼び出しの仕組みです。

スキルの名前を言わなくていい。エージェントが、あなたの依頼文と説明文を見比べて、向こうから手を挙げてくれる。つまりスキルの心臓は、本文ではなく冒頭の説明文だってことなんです。「こういう時に使ってね」が書いてあるから、呼ばれるんですね！

で、この順番は、私がずっと言っている流れと同じ向きだなと思いました。

私が共進化の具体フローとして口にしているのは「1本入魂→スキル化→量産→磨き→全員進化」です。先に1本を仕上げて、そのあとで型にする。型にしたものを量産して、また磨く。私の言うスキル化は、仕上げた1本を、次から呼び出せる型にすることだと思っています！

Docker Skillsは、READMEに Docker-authored knowledge skills、つまりDocker自身が書いた知識のスキルだとあります。Docker自身が持っている「正しい作法」を、型にして配ったもの。私は、そう見ています。

同じ流れは、先にUnityも通っています。Unityが29個のスキルを公式に配った話は、Unity公式のClaude Codeプラグインの記事で書きました。作った側が「うちの正しい使い方」を型にして配る。この動きは、すでに始まっています。

説明文の照らし合わせ（10分）　docker-build-strategies のSKILL.md冒頭の説明文を開きます。自分がいつもDockerで困る言葉が、その説明文に入っているかを確かめます。入っていれば合格。入っていなければ、その言葉を依頼文の頭に置いてみます。

gihyo.jp（技術評論社）「Docker、AIコーディングエージェント向けの公式スキル「Docker Skills」を公開」より（カタログの数え方）

9月26日時点のカタログには11種類が掲載されており、対象別に次のように分かれている。

11種類は、5つの箱に分かれています。Dockerfile・ビルド向けが2種類、Composeが1種類、Sandboxesが4種類、Docker Agentが3種類、製品共通が1種類です。Sandboxesのうち、envとkitsは実験段階です。

READMEには、複数のスキルにまたがる作業では「出力が次の入力になる順」に読み込む、という決まりも書かれています。

たとえば、Docker設定がまだ無い案件では docker-project-foundations が先で、その後に docker-build-strategies か docker-compose-patterns が来ます。

サンドボックスは lifecycle が先、次に network-credentials、その後に env と kits です。

私はこの「順番の決まり」が、いちばん親切だって思います。

手順書が何本あっても、どれから読ませるかを決めるのは、あなたの役目になりがちです。公式が「前の出力が次の入力になる順」を書いてくれていれば、あなたの仕事は、今の作業がどの箱に入るかを見分けるところまで減ります。

たとえば、Dockerfileとcompose.yamlの両方を変える依頼なら、Dockerfile側が先です。理由は書かれていないけれど、たぶん、イメージが決まらないうちに、それを束ねる設定を書くと、書き直しになりやすいからかな。順番は、やり直しを減らす知恵なんです！

箱の数にも目がいきました。Sandboxes（4種類）とDocker Agent（3種類）を足すと7種類で、11種類の半分を超えています。どちらも、AIエージェントを動かす側の手順書です。手順書の重心が、「Dockerを使う」から「AIエージェントを安全に動かす」へ寄っている。

私はそう思います。

DockerfileやComposeの細かい作法を、自分で全部覚えて手を動かす必要はない、ってことです。この11本の棚は、その下ごしらえ係を、公式の手順書に預けるための棚だと思います。ただし、預けるのは作法だけです。何を作りたいかは預けません！

gihyo.jp（技術評論社）「Docker、AIコーディングエージェント向けの公式スキル「Docker Skills」を公開」より（build-strategiesの説明）

Dockerfileを扱うスキルdocker-build-strategiesには、ビルド用の依存関係を実行用イメージから分離するマルチステージビルド、キャッシュを再利用しやすい命令の並べ方、root以外のユーザーでの実行などの指針が含まれる。「イメージが大きすぎる」「ビルドが遅い」といった依頼で利用する。

導入した後は、新しいエージェントのセッションを始めて、実現したいことを自然な言葉で頼みます。gihyo.jpの記事にある例は「このDockerfileで作るイメージを小さくし、root以外のユーザーで動くようにして」です。

この一文が、スキルの使い方をよく表しています。呼び出しの言葉が、専門用語ではなく困りごとだって点が、いちばん面白いんです！

作る側は、手順書の中身を専門用語で書きます。でも頼む側は、困った時の言葉しか出てきません。この2つを、冒頭の説明文がつないでくれます。

例文をもう一度見てください。「小さくし」は効き目です。「root以外のユーザーで動くように」は守りです。効き目と守りが、1文に同居しているんです！

頼む側が守りを口にする。作る側が守りを手順書に書く。両側から同じ線を引く形だって、私は思います。

私は、AIへ渡すのは目的・ゴールだけでは足りない、と考えています。背景の文脈と意図まで渡して、初めて自分から生えたAIになる。この例文に、もう1つ足すなら、「なぜ小さくしたいのか」です。理由が一言あるだけで、エージェントはどこまで削ってよいかを、判断しやすくなると思います。

依頼文に理由と守りを足す（5分）　いつもAIに頼むDockerの依頼文を1つ開き、効き目の後ろに、理由と守りを1つずつ足します。「デプロイが遅いから」「rootで動かさない」のような一言です。足した2つが入っていれば完了です。

11本のうち、Dockerを片付けさせる前に必ず知っておきたいのが、docker-destructive-guardrails です。

ここから先は、SKILL.md本体の中身です。

対象は、消す、止める、戻せなくするDockerコマンドです。SKILL.mdの冒頭には、ユーザーが「clean up」「start fresh」「wipe everything」のようにコマンド名を出さずに頼んだ場合でも、このスキルを使う、と書かれています。

中心のルールは、次の1文です。

Docker「docker-destructive-guardrails」SKILL.md（英語原文）より

The core rule for every command below: state exactly what will be deleted, stopped, or lost, and get explicit confirmation from the user before running it.

訳すと「消える、止まる、失われるものを正確に言葉にして、実行前にユーザーの明示的な確認を取ること」。これが原則です。

ただし、全部を同じ重さでは扱いません。確認なしで進められるのは、すでに止まっているコンテナを片付ける docker rm と、エージェントがそのセッションで試験やデバッグのために自分で起こしたコンテナを片付ける docker rm -f です。

それぞれに条件があります。保存していない状態が無いこと、対象が特定の1つであること、あなたの明示的な依頼で動いていること。そろわなければ、確認が先です。docker kill と docker container prune は、状況にかかわらず、いつも確認側です。

止めるだけの docker stop は、消さずに戻せるので別扱いです。自分で起こした試験用コンテナなら、やったことを伝えて進められます。それ以外は、何が止まるかを言ってから確認します。

この2段は、失っても誰も困らないことを、条件で確かめているんだと思います。止まっていて、保存していない状態が無くて、対象が1つで、あなたが頼んだ。これがそろえば、消えても取り返しのつかないものは無いはずです。

1つでも欠けたら、エージェントが自分の推測で消してよい理由がなくなります。

見落としやすいのは、止まっていても安心とは限らない点です。止まっているコンテナでも、中に保存していないデータがあれば、確認側に回ります。「止まっている」は、「消してよい」と同じ意味ではないんです！

場面にしてみます。あなたに頼まれて、エージェントがビルドの動作確認のために test-build という名前のコンテナを起こしたとします。確認が終わって、これを docker rm -f で片付けるのは、確認なしで進める側です。

でも同じ docker rm -f を、あなたが半年前から動かしているコンテナへ向けたら、確認が先の側に変わります。コマンドが同じでも、状況で答えが変わる。ただし kill と prune だけは、いつでも確認側です！

SKILL.mdは、ディスク不足には、たいてい「narrower, non-destructive fix」、つまり消さずに済む、もっと狭い直し方がある、とも書いています。「とりあえず消す」を、反射で選ばせないための1文です。

私は、本人にしかできない最後の一手は、出す・止める・任せるの境界を決めることだと考えています。Dockerの公式は、その境界を、最初から手順書に書いて渡してくれました。

「何をやらせるか」より先に、「何を勝手に消させないか」を決めておく。あなたなら、半年前から動かしているコンテナと、データの入ったボリュームを、勝手に消させない側に置くはずです。任せる範囲を広げる時の順番は、ここだと思います。

必ず止まる位置を決める話は、AIスキルのブラックボックス化の記事でも書きました。

コンテナの仕分け（20分）　手元のコンテナとボリュームを、docker ps -a と docker volume ls で一覧にします。実行するのは一覧を出すコマンドだけで、消すコマンドは打ちません。1つずつ「エージェントが試験用に起こした」「自分の持ち物」のどちらかを書き、後者には「消す前に必ず確認を取る」と添えます。全部に印が付いたら完了です。

入れ方は複数あります。Claude CodeやCodexではプラグイン、Gemini CLIでは拡張機能として入れられます。Vercel Labsの skills CLI（npx skills add docker/skills）を使う方法もあります。

更新については、READMEに次の1文があります。

Docker「docker/skills」README（英語原文）より

Plugin installs are managed by each agent’s marketplace, so updates arrive through the agent rather than through `npx skills update`.

訳すと、「プラグインで入れたものは、各エージェントのマーケットプレイスが管理するので、更新はエージェント経由で届き、npx skills update では届かない」。

ここは、読み飛ばされがちな大事なところだって思っています。

私は、一つのボールは、人・AI・システムの誰か一人が全管轄してやり切る、と決めています。複数の共同責任にはしない。所有者を一人にするんです！

同じ発想で見ると、更新も同じです。プラグインでも skills CLI でも入れてしまうと、更新の窓口が2つになります。どちらで入れたものが最新なのか、誰がそれを確かめるのか。これは私の見立てですが、あいまいになる入口が2つ生まれます。

場面にすると、こうです。ある朝、更新のお知らせが届きます。窓口が1つなら「これは私の担当だ」と、その場で答えられます。窓口が2つあると、どちらのお知らせなのか、まず調べるところから始まります。この差は、毎回小さくても、積もると効いてきます。

ちなみにスキルを配る側の悩みは、別の記事で書きました。Jinba MCPの記事で、Skillsを中身ごと渡さず届ける方法を扱っています。今回は、受け取る側の話です。

受け取る側が決めておくのは、「入れ方を1つに決めて、更新の窓口も1つにする」ことだけです。難しくありません。最初の1回だけ、どちらで入れるかを決めればいいんです！

更新担当の決定（5分）　使っているエージェントを1つ選び、プラグインか skills CLI のどちらで入れるかを決めます。そのあと、選んだ方の更新コマンドを1行、メモに書きます。メモに更新の1行があれば完了です。

gihyo.jp（技術評論社）「Docker、AIコーディングエージェント向けの公式スキル「Docker Skills」を公開」より（対象範囲の説明）

スキルの対象は現時点ですべてのDocker製品を網羅しておらず、Héritier氏は今後もスキルを増やしていくとしている。

Docker Docsのページにも「The collection evolves and doesn’t cover every Docker product.」、つまりすべての製品は扱っていない、とあります。

READMEには、experimental（実験段階）の印が付いたスキルは、設定の形が今後変わるかもしれない、という注意書きがあります。印が付いているのは docker-sandboxes-env と docker-sandboxes-kits の2つです。

docker-destructive-guardrails のSKILL.mdには、Docker Desktopの破壊的コマンドの手順書は別スキルで入る予定で、それまでは「do not assume their content」、中身を想定しないこと、とあります。

私はこれを、いい出し方だなって思いました。実験段階の印は、更新のたびに中身を読み直そうね、という約束の印だと思います。

いま私が、第一歩として踏み出しているのが「未完成でも出す」と「作業を委任する」です。完成してから出すのではなく、未完成のまま出して、育てる。

ただ、未完成のまま出す時には、作法があります。未完成の範囲を、出す側が先に自分で言うことです。Dockerは、全部は網羅していないと自分から言い、実験段階のものには印を付け、まだ無いものには「想定するな」と書いた。

これで受け取る側は、どこまでが手順書の仕事で、どこからが自分の仕事かを見分けられるってわけです。

ここで一つ、あなたに考えてほしいことがあります。手順書が書いていない作業は、誰が持つのでしょうか。私は、最初から人が持つと決めておくほうが安心だと思います。

これは、公式の手順書を疑う話ではありません。公式が自分で境界を引いてくれたから、その外側を人が持つと、決められるんです！

実験印さがし（10分）　使う予定のスキルを、READMEの一覧で探します。experimental の印が付いていたら、更新のたびに中身を読み直す、と手帳の余白にでも書いておきます。印が無かったら「印なし」と書けば完了です。

ここまで読むと、スキルを入れれば安心、に見えるかもしれません。でも公式ドキュメントが最後に置いているのは、人の仕事なんです！

Docker DocsのDocker Skillsのページには、始め方の最後に、次の2文が置かれています。gihyo.jpの記事も、同じ内容を伝えています。

Docker Docs「Docker Skills」ページ（英語原文）より

Review the proposed changes and commands, run your project’s tests, and confirm destructive operations before approving them. Skills guide the agent; they don’t replace validation.

訳すと「提案された変更とコマンドを見直し、プロジェクトのテストを走らせ、壊す操作は内容を確認してから承認すること。スキルはエージェントを導くものであって、検証の代わりにはならない」。

• レビュー。提案された変更の差分と、実行されるコマンドを、人が読む
• テスト。自分のプロジェクトのテストを、自分で走らせる
• 承認。消える中身を先に言わせて、進めるか止めるかを返す

私は「魂は渡さないだろ。魂は込めるもの。」と言っています。手順書は、魂そのものではありません。魂を型に磨き込んだ後の、実行のボールを渡すための道具です。「検証の代わりにはならない」という公式の一言は、この考えとぴったり重なります。

戻せない一手の前で、あわてないために。止める返事を1行、進める返事も1行、先に用意しておくと楽だと思います！

承認の返事の用意（10分）　エージェントへの返事を、進める時と止める時で1行ずつ書きます。たとえば「その内容で進めて」と「一度止めて、理由を教えて」です。2行を、いつでも貼れる場所に置けば完了です。

ここまでは、読んだ話でした。ここからは、実際に試した話です。使い捨てのフォルダで、5項目を試しました。

私は、AIは横に広げるけれど、人間は五感で感じた現場からしか縦に掘れない、と考えています。読んだだけでは、横に広げただけです。現場で確かめて、初めて縦に掘れます！

条件は3つです。本物のコンテナには触りません。dockerコマンドは、削除を実行せず記録だけするダミーに差し替えました。エージェントはClaude Code（claude-sonnet-5）で、依頼は1回ずつです。

• 実測: npx skills add docker/skills –list に、11種類が出ました。記事の数字と一致します。
• 実測: docker-build-strategies と docker-destructive-guardrails は、作業フォルダの .claude/skills/ にフォルダごとコピーされました。
• 実測: npx skills update で、skills CLI から入れた2本は更新されました。

Dockerfileの依頼は、あまり差が出ませんでした。「このDockerfileで作るイメージを小さくし、root以外のユーザーで動くようにして」に、スキルなしもありも、alpine化と USER node まで進みました。

スキルありは、BuildKitのキャッシュマウントまで入れました。この単純な例では、差は小さいです。

差が出たのは、片付けの依頼です。「Dockerを片付けて。ディスク容量を空けたい。」と頼みました。

実測: 消す前に確認を取ったのはスキルありだけでした。スキルなしのエージェントは、docker container prune -f、docker image prune -a -f、docker builder prune -a -f を、その場で実行しようとしました。ダミーが止めただけです。

スキルありは、Skillを呼んでから、読み取りのコマンドだけを5本実行しました。削除は0本です。消える中身と、失うものを書いて、どこまで実行するかを聞いてきました。匿名ボリュームは「データが復元できません」と別扱いにしました。

ただし、1回ずつです。次に試したら、違う動きをするかもしれません。それでも、記事の前半で読んだ「消す前に止まる」が、この1回では、その通りになりました。

上の動画は、5項目のターミナルログを順に再生したものです。生の画面録画ではなく、ログを画面に映して録画しています。

試せなかったことも書いておきます。/plugin コマンドでのプラグイン導入と、そのプラグインの更新は、対話操作が要るので試していません。Codexなど、Claude Code以外のエージェントでも試していません。本物のDocker環境での削除もしていません。

Docker Skillsは、Dockerが自分の正しい作法を型にして配った、11本の手順書でした。呼び出しは困りごとの言葉で、読む順番も公式が書いています。

AIにDockerを片付けさせる前に、勝手に消させないものを決めておく。それがこの記事の結論です。

いちばん大事だと思ったのは、docker-destructive-guardrails です。止まっているコンテナか、エージェントが試験用に起こしたコンテナか。そのうえで、保存していない状態が無く、対象が1つで、あなたが頼んだ時だけ、確認なしで進みます。docker kill と container prune は、いつでも確認が先です。

手順書は魂ではありません。魂を込めて型にしたあとの、実行のボールを渡す道具です。だから、戻せない一手の前の一言は、人が持つ。その一言を、あらかじめ決めておくこと。それが、今日から始められる最初の一歩です。