docker-destructive-guardrails

Docker 破壊的コマンドのガードレール

概要

このスキルでは、Docker CLI の破壊的または取り消し不能な操作、つまりデータを削除したり、リソースを取り除いたり、その他の方法で元に戻せなくしたりするコマンドを扱うための、製品横断的なポリシーを提供します。ユーザーがコマンド名を直接挙げていなくても、タスクによってこれらのコマンドを実行する可能性が合理的に考えられる場合は、常にこのスキルを使用してください。より具体的なスキルで扱われていない一般的な Docker CLI コマンドを網羅し、Compose、sandbox、Desktop の破壊的なコマンドがどこに記載されているかもまとめています。

このスキルを使用する場面

以下の場合に、このスキルを有効にしてください。

• ユーザーが特定のコマンドを指定せずに、Docker リソースの「クリーンアップ」「キャッシュのクリア」「最初からやり直す」「すべて消去」「根こそぎ削除」「リセット」「強制削除」「停止と削除」を求めている
• エージェントが、無関係な問題（ディスク容量、停止しないコンテナ、古いネットワーク、壊れたビルドキャッシュ、古いビルダーやボリューム）の解決策として、docker rm、docker rm -f、docker container prune、docker kill、docker stop、docker system prune、docker rmi、docker image rm、docker image prune -a、docker network rm、docker network prune、docker builder prune、docker buildx rm、docker context rm、または単独の（Compose を使わない）docker volume rm／docker volume prune を検討している
• ユーザーが、Docker のスキル全般にわたる破壊的コマンドの概要を求めている

このスキルを使用しない場面

以下の場合は、このスキルを使用しないでください。

• 対象の破壊的コマンドが Compose 固有のものである（docker compose down -v、docker compose rm -v、Compose プロジェクト内での docker volume rm／docker volume prune）— このガイダンス全般を詳しく扱う docker-compose-patterns を直接使用してください
• クリーンアップや削除を伴わず、Dockerfile または compose.yaml の作成やレビューを行うタスクである
• Docker 以外の操作（git、ファイルシステム、クラウドリソース）である — このスキルは Docker CLI の操作のみを対象とします

基本的なガイダンス

以下のすべてのコマンドに共通する基本ルールは、何が削除、停止、または失われるのかを正確に伝え、実行前にユーザーから明示的な確認を得ることです。 トラブルシューティングや「とりあえずクリーンアップ」の反射的な対応として、破壊的なコマンドをデフォルトで実行してはいけません。ディスク容量、停止しないコンテナ、古いキャッシュには、ほとんどの場合、より対象を絞った非破壊的な解決策があります。正確なフラグと、それぞれの安全で範囲を限定した代替策については、references/docker-cli-destructive-commands.md を参照してください。

コンテナのライフサイクルに関するコマンド — docker rm、docker rm -f、docker container prune、docker kill — はリスクが一律ではないため、単一のルールではなく、以下の2つのティアに分けています。docker stop には関連するものの別個の、取り消し可能な操作に関するルールを、ティアの直後に示します。この一覧にあるその他すべてのコマンドには、上記の一律のルールが例外なく適用されます。失われる内容を伝え、明示的な確認を得て、ユーザーの回答を待ってから実行してください。

ティア 1 — 手軽なコンテナのクリーンアップ

これは、すでに停止しているコンテナに対する docker rm <name> と、同じセッション内でエージェント自身がテストまたはデバッグ目的のみで作成・起動したコンテナに対する docker rm -f <name> に限り適用されます。コンテナがまだ実行中であっても、-f が必要になるのはその場合に限られるため、-f の例外が適用されます。以下の条件をすべて満たす必要があります。コンテナがすでに停止しているか、同じセッション内でテスト／デバッグ目的にエージェント自身が作成・起動したものであること。永続化されていない状態が失われる既知のリスクがないこと。対象が範囲を限定しない一括操作ではなく、特定されている1つのコンテナであること。そして、エージェント自身の判断ではなく、このセッション内でユーザーが明示的に依頼した操作であること。すべての条件を満たす場合、エージェントはコンテナを削除し、実行した内容を伝えて処理を続けます。事前に処理をブロックする確認は不要です。それ以外のすべてのケースには、以下のティア 2 の docker rm -f のルールが適用されます。

Tier 2 — 確認が必要なコンテナーコマンド

docker kill は常に Tier 2 です（停止済みコンテナーの例外がない理由についてはリファレンスを参照してください）。また、docker container prune（ホスト上の停止済みコンテナーをすべて削除し、エージェントがクリーンアップしているコンテナーだけを対象にすることはありません）、上記の Tier 1 の条件をすべて満たさないコンテナーに対する docker rm -f（特に、エージェントがこのセッションで作成・起動していない実行中のコンテナー、または作成・起動したものの明示的なユーザーの依頼なしに操作するコンテナー）、コンテナーの状態にかかわらず、その他の対象を限定しない一括処理（例：docker rm -f $(docker ps -aq)、「すべてのコンテナーを削除／停止する」）、エージェントが作成しておらず、状況も把握していないコンテナーへの操作、そして明示的なユーザーの依頼ではなく、エージェントが独自に判断して行うあらゆる操作も Tier 2 です。これらには、このスキルの定める一律ルールのコマンドと同じ確認基準が適用されます。失われるものを正確に伝え、実行前に明示的な確認を得てください。例外はありません。

docker stop — 可逆的で、Tier モデルの対象外

docker stop は何も削除しません。コンテナーはそのまま残り、docker start で再起動できます。そのため、上記の Tier 1／Tier 2 の削除モデルの対象外です。ただし、実行中のプロセスを中断し（SIGTERM を送信し、タイムアウト後に SIGKILL を送信）、コンテナー内の永続化されていない状態を破棄するため、このスキルの対象には含まれます。このセッションでエージェント自身がテスト／デバッグに使用しているコンテナーの場合は Tier 1 と同様に扱います。停止して何が起きたかを伝えればよく、事前の確認は必要ありません。それ以外のコンテナーの場合は、実行が停止し、保存されていないメモリー上の状態が失われることを伝え、まず確認を得てください。

• docker system prune — 停止済みコンテナー、未使用のネットワーク、未タグ付けのイメージ、ビルドキャッシュを削除します。-a を付けると未使用のタグ付きイメージも削除され、--volumes を付けると未使用の匿名ボリュームも削除されます（名前付きボリュームはそのまま残ります。削除するには別途 docker volume rm が必要です）。
• docker rmi / docker image rm — 特定のイメージを削除します。複数タグが付いたイメージや参照されているイメージに対する -f の正確な（部分的に未検証の）強制動作については、リファレンスを参照してください。
• docker image prune -a — 未タグ付けのイメージだけでなく、実行中・停止済みを問わず、どのコンテナーからも参照されていないイメージをすべて削除します。
• docker network rm — 引数で指定したネットワークを削除します。-f フラグが以下の docker context rm -f とどう異なるかについては、リファレンスを参照してください。
• docker network prune — コンテナーに接続されていないカスタムネットワークをすべて削除します。
• docker builder prune — BuildKit キャッシュを消去します。-a／--all を付けると、内部ヘルパー／フロントエンドイメージや、他のビルド成果物と共有されているキャッシュも削除され、そのキャッシュを利用する場合はクリーンな状態からの再ビルドが必要になります。
• docker buildx rm — ビルダーインスタンスを削除します。これは docker builder prune で消去されるキャッシュとは別のものです。フラグの詳細については、リファレンスを参照してください。
• docker context rm — コンテキストのローカル接続設定を削除します。リモートリソースには影響しませんが、簡単には再構築できない場合があります。上記の docker network rm -f とは異なり、docker context rm -f はコンテキストが現在使用中でも、実際に強制削除します。
• docker volume rm / docker volume prune（Compose プロジェクトが関係しない単独の操作）— ボリュームデータを直接、取り消し不能な形で削除します。docker volume prune -a／--all を付けると、既定の匿名ボリュームのみという対象範囲が、名前付きボリュームにも拡大されます。Compose プロジェクト自身のボリュームには、代わりに docker-compose-patterns を使用してください（関連スキルを参照）。compose.yaml で external: true と宣言されているものの、その Compose プロジェクトが管理していないボリュームには、このスキルのガイダンスが適用されます。Compose は down -v でそのボリュームに触れないためです。

関連スキル

• Compose 固有の破壊的なコマンド（docker compose down -v、docker compose rm -v、Compose のコンテキストでの docker volume rm／docker volume prune）には、docker-compose-patterns を使用してください。これらのガイダンスの詳細はすべて同スキルが担当し、このスキルはその索引のみを提供します。このスキルは、スタンドアロン（Compose 以外）の docker volume rm／docker volume prune 自体のケースを担当します。Core guidance と references/docker-cli-destructive-commands.md を参照してください。
• Dockerfile の内部、ビルドキャッシュ、イメージサイズの最適化（破壊的でない事項）には、docker-build-strategies を使用してください。
• Docker プロジェクトを初めてセットアップする場合は、docker-project-foundations を使用してください。
• sandbox（sbx）の破壊的なコマンド（sbx rm、sbx prune）には、docker-sandboxes-lifecycle を使用してください。これらのガイダンスの詳細はすべて同スキルが担当し、このスキルはその索引のみを提供します。Docker Desktop の破壊的コマンドに関するガードレールは、マージ後に専用のスキルに追加されます（進捗状況は references/cross-skill-destructive-command-index.md を参照してください）。そのスキルが公開されるまでは、内容を前提にしないでください。

リファレンス

• references/docker-cli-destructive-commands.md — Docker CLI の各汎用破壊的コマンドについて、正確なフラグ、削除されるもの、安全で対象を限定した代替手段をコマンドごとに解説します。
• references/cross-skill-destructive-command-index.md — Docker の全スキルにわたる破壊的コマンドの製品横断テーブル。Docker Desktop 用の保留中のプレースホルダーも含まれています。

アセット

このスキルには同梱アセットはありません。

チェック

• checks/verification.md — 破壊的コマンドのリクエストへの対応例として、悪い対話例と良い対話例を含む手動レビュー手順書です。