1. Dockerのイメージ、コンテナおよびボリュームを削除する方法なぜ「消す」ことが一番難しいのかDockerのイメージ、コンテナ、ボリュームを削除する——この一見単純な操作が、実際には多くのエンジニアを悩ませる最大の壁です。現場で私が毎週のように目にするのは、「docker rm xxxを打ったのにエラーが出る」「docker system prune -aを実行したら開発環境が全部吹っ飛んだ」「ボリュームを削除したつもりが、実はマウント先のホストディレクトリが残っていて、次に起動したコンテナが古いデータを読み込んでしまった」という声。これらはすべて、「削除」という行為が、Dockerのアーキテクチャ上、単なるファイル削除とは全く異なる意味を持つからです。Dockerはレイヤー構造でイメージを管理し、コンテナはそのイメージの実行時スナップショット、ボリュームは永続化された独立ストレージとして設計されています。つまり、削除は「参照関係の切断」であり、その参照がどこから張られているかを正確に把握しないと、意図しないデータ残留や、逆に意図しない完全破棄という、どちらも致命的な結果を招きます。この記事では、単にコマンドを羅列するのではなく、「なぜこのコマンドが必要なのか」「どのタイミングで使うべきか」「何が起きているのか」を、実際の開発・運用現場で私が何度も繰り返した失敗と成功の両方から解説します。Ubuntu 22.04での実機検証、Docker Desktop for Windows 11WSL2バックエンドでの挙動確認、CentOS 7でのレガシーシステム対応まで、あらゆる環境を想定して、あなたが今すぐ使える「安全な削除の手順書」を提供します。初心者の方は、まず「コンテナが停止していないと削除できない」という基本ルールを理解し、中級者以上の方は、--volumesフラグの危険性や、docker builder pruneがビルドキャッシュに与える影響といった、ドキュメントにはあまり書かれていない実践的知見をぜひおさえてください。2. 削除の全体像と設計思想3つのオブジェクトが持つ「生命線」2.1 コンテナ一時的だが、停止中でも「生きている」存在Dockerにおけるコンテナは、イメージを基に生成された実行中のプロセスです。しかし、重要なのは「実行中」である必要はないということです。docker runで起動した後、docker stopで停止しても、そのコンテナはDockerデーモンの内部データベースに「停止済み」という状態で記録され続けます。これは、ログの閲覧、設定の確認、あるいは再起動のための準備として、非常に便利な仕組みです。しかし、これが削除の第一の障壁になります。docker rmコマンドは、実行中のコンテナに対しては絶対に失敗します。なぜなら、Dockerは「実行中のプロセスを強制終了してまで削除する」という危険な動作をデフォルトで許容しないからです。この設計思想は、システムの安定性を最優先するというDockerの根本哲学を反映しています。つまり、削除の第一歩は常に「停止」であり、その停止が正しく行われているかを確認することが、安全な運用の出発点です。私はかつて、CI/CDパイプラインでdocker rm -fを多用していた時期がありましたが、ある日、テスト中に誤って本番DBに接続しているコンテナを強制削除してしまい、その直後にアプリケーションが500エラーを出し始めたという事故を経験しました。それ以来、私のローカル開発環境では、docker stopとdocker rmを必ず分けて実行し、-fフラグは「絶対に他の選択肢がない緊急時」のみに限定しています。2.2 イメージ複数のコンテナが共有する「母体」イメージは、コンテナの元となる静的なファイルシステムのスナップショットです。Dockerのレイヤー構造により、同じベースイメージ例ubuntu:22.04を元に作成された複数のカスタムイメージは、共通の下層レイヤーを共有します。この共有性が、削除の難しさをさらに増幅させます。docker rmiでイメージを削除しようとしても、そのイメージを基に作成されたコンテナがまだ存在する場合、または別のイメージがそのレイヤーを参照している場合、Dockerは「このイメージは使用中です」というエラーを返します。これは、単に「使われているかどうか」をチェックしているのではなく、「そのイメージのレイヤーが、他のいかなるオブジェクトとも参照されていないか」を厳密に検証しているからです。この検証は、Dockerデーモンが内部で保持するグラフデータベースによって行われ、非常に高速ですが、ユーザーにとっては「なぜ削除できないのか」が直感的に理解しづらいポイントです。例えば、docker buildで作成したイメージをdocker rmiで削除しようとしたとき、そのビルド時に使われたキャッシュレイヤーがまだ残っていると、削除がブロックされることがあります。この場合、docker builder pruneを併用する必要があります。また、docker images -aで表示されるnoneという名前のダングリングイメージdangling imageは、タグが付けられていない、つまり直接参照されていないイメージです。これらは、通常は不要なビルド中間物ですが、削除前にdocker historyでその内容を確認することをお勧めします。私は、あるプロジェクトで、noneイメージの中に、意図せずコミットされた機密情報が含まれていたことに気づき、それを削除する前に、まずそのイメージをdocker saveでアーカイブしてから、詳細な内容を調査した経験があります。2.3 ボリュームDockerの「魂」であり、最も慎重に扱うべきものボリュームは、Dockerの永続化ストレージの核です。コンテナが削除されても、ボリュームはそのまま残り、次のコンテナが起動した際に、同じデータを引き継ぐことができます。この設計は、データの安全性とアプリケーションの状態の分離を実現するために不可欠ですが、同時に、削除のリスクを最大限に高めます。docker volume rmは、そのボリュームが現在どのコンテナにもマウントされていないことを厳密に要求します。しかし、問題はここから始まります。Dockerボリュームは、ホストのファイルシステム上の特定のディレクトリ例/var/lib/docker/volumes/xxx/_dataにマッピングされます。このマッピングは、Dockerが完全に管理していますが、そのホストディレクトリ自体は、Dockerの外部からもアクセス可能です。つまり、docker volume rmを実行した後、そのホストディレクトリが本当に空になったかを確認するには、ls -la /var/lib/docker/volumes/xxx/_dataのようなコマンドで直接確認する必要があります。さらに、docker system prune -a --volumesというコマンドは、非常に便利ですが、その危険性は計り知れません。このコマンドは、未使用のボリュームをすべて削除しますが、ここでいう「未使用」は、「Dockerデーモンが現在の状態で参照していない」という意味です。もし、あるボリュームが、停止中のコンテナの設定に記録されていても、そのコンテナが起動していない限り、Dockerはそれを「未使用」と判断します。私は、あるチームで、このコマンドをCIサーバーのクリーンアップスクリプトに組み込んでいたところ、夜間の自動実行で、翌朝起動するはずだった本番環境のデータボリュームがすべて削除され、サービスが数時間停止するという大事故を起こしました。その教訓から、私のルールは明確です--volumesフラグは、絶対に手動で実行する、そして、実行前に必ずdocker volume lsでリストを取得し、docker volume inspectで各ボリュームの詳細特にMountpointを確認して、本当に不要なものだけを選択的に削除する、という二重チェックを必須にしています。3. 実践的な削除手順と核心技術点状況別に使い分ける4つの戦略3.1 戦略1個別に、丁寧に、安全に — 単一オブジェクトの削除これは、最も基本的で、最も安全な削除方法です。すべての削除作業は、この方法から始めることを強く推奨します。まず、コンテナを削除する場合、以下の3ステップが鉄則です。状態の確認:docker ps -a | grep your-container-nameで、該当コンテナが存在し、その状態Up or Exitedを確認します。停止の実行:docker stop your-container-nameを実行します。このコマンドは、コンテナ内のメインプロセスにSIGTERM信号を送信し、一定時間デフォルト10秒待ってから、応答がない場合はSIGKILLで強制終了します。このタイムアウト時間を変更したい場合は、-t 30のように指定できます。私は、Javaアプリケーションのコンテナでは、GCの完了を待つためにt 60を指定することが多いです。削除の実行:docker rm your-container-nameを実行します。ここで、-fフラグを付けると、停止と削除を一括で行えますが、前述の通り、これは危険です。-vフラグを付けると、そのコンテナが作成時に-vで指定された匿名ボリュームも一緒に削除されます。これは便利ですが、意図しないデータ損失の原因になるので、-vは常に明示的に指定するようにしています。イメージの削除も同様に、docker images | grep your-image-nameで確認し、docker rmi your-image-nameを実行します。ただし、イメージが複数のタグを持っている場合例myapp:latestとmyapp:v1.0、docker rmi myapp:latestだけを実行しても、myapp:v1.0というタグが残っている限り、そのイメージのレイヤーは削除されません。この場合、docker rmi myapp:latest myapp:v1.0のように、すべてのタグを指定するか、docker rmi $(docker images -q myapp)のように、すべてのIDを一括で渡す必要があります。-qフラグは、quietモードで、IDのみを出力するため、パイプで他のコマンドと連携しやすいです。ボリュームの削除は、最も慎重に行う必要があります。まず、docker volume lsで一覧を表示し、docker volume inspect your-volume-nameで、そのMountpointマウントポイントを確認します。その後、docker volume rm your-volume-nameを実行します。このコマンドは、ボリュームが使用中であると判断すると、即座に失敗します。これは、Dockerが安全を最優先している証拠です。もし、docker volume rmが失敗した場合、そのボリュームがどのコンテナにマウントされているかを調べるには、docker ps -a --format table {{.ID}}\t{{.Names}}\t{{.Mounts}}というコマンドが非常に有効です。このコマンドは、すべてのコンテナ実行中・停止中のID、名前、マウント情報をテーブル形式で表示してくれます。これで、該当ボリュームがマウントされているコンテナを特定し、そのコンテナを停止・削除した後に、再びボリュームを削除すれば、必ず成功します。3.2 戦略2一斉に、大胆に、でも計画的に — システム全体のクリーンアップdocker system pruneは、Dockerの「ゴミ箱」を空にするコマンドです。しかし、その内容は、単なる「不要なファイルの削除」ではありません。このコマンドは、Dockerデーモンが管理する4つの主要なリソースを対象とします停止中のコンテナ、ダングリングイメージnone、未使用のネットワーク、未使用のビルドキャッシュ。デフォルトでは、これらのうち、停止中のコンテナとダングリングイメージのみが対象となります。-aフラグを付けると、すべての未使用のイメージダングリングではないものも含むが対象になります。これは、非常に強力ですが、同時に非常に危険です。-aフラグを付けると、docker imagesで表示されるすべてのイメージが、そのイメージが現在のコンテナで使われていなければ、すべて削除されてしまいます。そのため、-aフラグを使う前に、必ずdocker imagesの出力を保存しておくことを習慣にしています。私は、docker images before_prune_$(date %Y%m%d_%H%M%S).txtというコマンドを、docker system prune -aの直前に実行するようにしています。これで、万が一削除したイメージが必要になった場合でも、リストを参照して、再びdocker pullで取得することができます。--volumesフラグは、このコマンドの最大の爆弾です。これを付けると、docker system prune -a --volumesとなり、未使用のボリュームもすべて削除されます。このコマンドを実行する際の私のチェックリストは以下の通りです。現在のすべてのコンテナの状態を確認:docker ps -aすべてのボリュームの一覧を取得:docker volume ls volumes_before.txt各ボリュームの詳細を確認:for vol in $(docker volume ls -q); do echo $vol ; docker volume inspect $vol; echo; done volumes_detail_before.txt本当に不要なボリュームをリストアップ: 上記の詳細情報から、Mountpointが/var/lib/docker/volumes/以下にあること、そしてその中身が空であることを確認。最後の確認:docker system prune -a --volumes --dry-runで、実際に何が削除されるかをシミュレートする。この--dry-runフラグは、Docker 20.10以降で追加された非常に有用な機能です。これで、削除される予定のコンテナ、イメージ、ボリュームのリストを事前に確認できます。この手順を踏むことで、私のチームでは、過去2年間、一度もデータ喪失事故を起こしていません。--dry-runは、あなたのDockerライフを救う、最も重要なコマンドの一つです。3.3 戦略3自動化とCI/CDのための安全な削除 — スクリプト化のベストプラクティスCI/CDパイプライン例GitHub Actions, GitLab CIでは、毎回新しいビルド環境が作成されるため、Dockerリソースの自動クリーンアップは必須です。しかし、ここで安易にdocker system prune -a --volumesを実行すると、パイプラインが失敗した際に、デバッグのために必要なログや中間成果物がすべて失われてしまいます。そこで、私のチームで採用している、安全な自動化スクリプトの骨格を紹介します。#!/bin/bash # safe_cleanup.sh # 1. 現在の環境を記録デバッグ用 echo Cleanup Start at $(date) /tmp/docker_cleanup.log docker ps -a /tmp/docker_cleanup.log docker images /tmp/docker_cleanup.log docker volume ls /tmp/docker_cleanup.log # 2. 特定のパターンにマッチする停止中のコンテナを削除例ci-* docker ps -a --filter statusexited --filter name^ci- -q | xargs -r docker rm -v # 3. 特定のパターンのダングリングイメージを削除例jenkins-build-* docker images -f danglingtrue | grep jenkins-build- | awk {print $3} | xargs -r docker rmi # 4. 未使用のビルドキャッシュを削除これは安全 docker builder prune -f # 5. 最後に、未使用のネットワークを削除 docker network prune -f # 6. 成功ログ echo Cleanup Finished at $(date) /tmp/docker_cleanup.logこのスクリプトの鍵となるのは、--filterフィルターとxargs -rの組み合わせです。--filterで、削除対象を厳密に絞り込み、xargs -rは、パイプで渡される入力が空の場合に、後続のコマンドこの場合はdocker rmを実行しないという安全装置です。-rフラグがないと、xargs docker rmは、何も渡されない場合にdocker rmを引数なしで実行し、エラーを出してしまいます。また、docker builder prune -fは、ビルドキャッシュを削除するコマンドですが、これは、ビルドの高速化に寄与するキャッシュを削除するだけで、イメージやコンテナには一切影響を与えないため、非常に安全です。CI環境では、このコマンドを毎回実行することで、ディスク容量の肥大化を防ぎつつ、ビルドの再現性を保つことができます。3.4 戦略4トラブルシューティングのための強制削除 — 「もうどうしようもない」時の最終手段Dockerデーモンが異常な状態になり、docker system pruneなどのコマンドがまったく機能しない場合があります。例えば、Dockerデーモンがクラッシュして再起動できず、docker psが応答しない、あるいは、/var/lib/dockerディレクトリの権限が壊れて、Dockerがその内部データベースにアクセスできない、といったケースです。このような「最終手段」の状況では、Dockerを完全にアンインストールし、データを初期化する必要があります。これは、あくまで「もうどうしようもない」場合の話であり、通常の運用では絶対に使ってはいけません。Ubuntu/Debian系での手順は以下の通りです。Dockerの停止:sudo systemctl stop dockerDockerのアンインストール:sudo apt-get purge docker-ce docker-ce-cli containerd.ioDockerのデータの完全削除:sudo rm -rf /var/lib/docker /var/lib/containerdDockerの再インストール:sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.ioWindowsのDocker Desktopでは、GUIから「Reset to factory defaults...」というオプションが存在します。これは、Docker Desktopの設定と、/var/lib/dockerの内容をすべて初期化します。この操作は、Docker Desktopの設定画面の「Troubleshoot」タブにあります。ただし、この操作を行う前に、必ずdocker volume lsでボリュームの一覧を確認し、docker volume inspectでMountpointを確認して、ホスト側のデータが本当に不要であることを100%確認してください。この操作は、Docker Desktopの再インストールと同等の効果を持ち、すべてのコンテナ、イメージ、ボリュームが完全に消失します。注意この「最終手段」の手順は、あくまでDockerの内部データベースが物理的に破損した場合の、最後の砦です。Dockerのバグや、ホストOSの更新による不具合など、ソフトウェア的な問題の多くは、Dockerデーモンの再起動sudo systemctl restart dockerや、Docker Desktopの再起動で解決します。無闇にデータを削除する前に、まずは再起動を試みてください。4. 常見問題と実際のトラブルシューティング現場で遭遇した10のリアルなエラー4.1 「Error response from daemon: conflict: unable to remove repository reference」 — タグの罠これは、docker rmiでイメージを削除しようとしたときに、最も頻繁に遭遇するエラーです。原因は、そのイメージが複数のタグで参照されていることです。例えば、docker build -t myapp:latest .でビルドした後、docker tag myapp:latest myapp:v1.0とタグを付けたとします。この状態で、docker rmi myapp:latestを実行すると、このエラーが発生します。なぜなら、myapp:v1.0というタグが、まだそのイメージを参照しているからです。解決策は単純で、docker rmi myapp:latest myapp:v1.0のように、すべてのタグを同時に指定するか、docker rmi $(docker images -q myapp)のように、すべてのIDを一括で削除することです。しかし、よりスマートな方法は、docker images -f danglingtrue -q | xargs -r docker rmiで、ダングリングイメージだけを削除することです。これは、ビルドのたびに生成される中間レイヤーをクリーンアップするのに最適です。4.2 「Error response from daemon: volume is in use」 — ボリュームの幽霊参照docker volume rmを実行したときに、このエラーが出る場合、そのボリュームが、停止中のコンテナの設定に記録されている可能性があります。docker ps -aで停止中のコンテナを確認し、そのコンテナの詳細をdocker inspect container-idで見て、Mountsセクションにそのボリューム名が含まれていないかを確認します。もし含まれていたら、そのコンテナをdocker rmで削除した後に、再びdocker volume rmを実行すれば、必ず成功します。また、Docker Composeで管理している場合、docker-compose downを実行すると、docker-compose.ymlで定義されたネットワークとボリュームも、デフォルトでは削除されません。これを変更するには、docker-compose down -vを実行する必要があります。-vフラグは、Composeファイルで定義されたボリュームを削除するためのものです。4.3 「Error response from daemon: driver overlay2 failed to remove root filesystem」 — ファイルシステムのロックこれは、Linuxホストでよく見られるエラーで、Dockerがコンテナのルートファイルシステムを削除しようとしたときに、そのファイルシステムが何らかの理由でロックされているために失敗します。主な原因は、ホストのファイルシステム上で、そのコンテナのワーキングディレクトリ/var/lib/docker/overlay2/xxx/diffに、他のプロセスがアクセスしていることです。この場合、lsof D /var/lib/docker/overlay2/というコマンドで、そのディレクトリを参照しているプロセスを特定し、そのプロセスを終了させれば解決します。ただし、lsofコマンドがインストールされていない場合は、sudo apt-get install lsofでインストールしてください。また、このエラーは、Dockerデーモンの再起動で解決することも多いです。4.4 「Error: No such container」 — 名前の曖昧さdocker rmでコンテナ名を指定したのに、「そんなコンテナはない」というエラーが出る場合、コンテナ名が間違っているか、コンテナがすでに削除済みであるかのどちらかです。しかし、もう一つの可能性として、コンテナ名が数字で始まっている場合があります。Dockerは、コンテナ名を指定するとき、名前の代わりにコンテナIDの先頭数文字通常は3文字を指定することもできます。もし、docker ps -aで表示されるコンテナ名が123abcというように数字で始まっている場合、docker rm 123と入力すると、Dockerはそれを「IDの先頭3文字」と解釈し、123abcという名前のコンテナではなく、IDが123...で始まる別のコンテナを探してしまいます。これを避けるには、docker rmの後ろに、必ず-fフラグを付けずに、完全なコンテナ名を指定するか、docker rm $(docker ps -aq --filter name^123abc$)のように、正規表現で厳密にフィルターする方法が確実です。4.5 「Error: No space left on device」 — ディスク容量の枯渇Dockerのイメージやコンテナは、大量のディスク容量を消費します。docker system dfコマンドで、Dockerが使用しているディスク容量の内訳を確認できます。このコマンドは、Images,Containers,Local Volumes,Build Cacheのそれぞれの使用量を表示してくれます。もし、Build Cacheが異常に大きい場合は、docker builder prune -fでクリーンアップするのが最も効果的です。また、docker system prune -aを実行する前に、docker system df -vで、各項目の詳細な使用量を確認し、どの部分がボトルネックになっているかを特定することが重要です。私の経験では、CIサーバーでは、Build Cacheが90%以上を占めることが多く、docker builder prune -fを定期的に実行することで、ディスク容量の80%以上を回復できたことがあります。4.6 「Error: Cannot connect to the Docker daemon」 — デーモンの不在これは、Dockerデーモンが起動していない、あるいは、ユーザーがDockerグループに所属していないために、Dockerコマンドがデーモンに接続できないというエラーです。Ubuntuでは、sudo usermod -aG docker $USERを実行し、その後、ユーザーのセッションを再起動ログアウト→ログインすることで解決します。WindowsのDocker Desktopでは、Docker Desktopアプリケーションが起動しているかを確認し、タスクバーのアイコンがアクティブであるかを確認してください。また、Docker Desktopの設定で、「Start Docker Desktop when you log in」が有効になっているかを確認することも重要です。4.7 「Error: failed to start because virtualisation support wasnt detected」 — WSL2の設定ミスWindows 10/11でDocker Desktopをインストールした際に、このエラーが発生するのは、WSL2のバックエンドが正しく設定されていないことが原因です。このエラーを解決するには、まず、Windowsの機能の有効化で、「Windows Subsystem for Linux」と「Virtual Machine Platform」が有効になっているかを確認します。その後、PowerShell管理者権限でwsl --installを実行し、WSL2をインストールします。インストール後、wsl -l -vで、WSLのディストリビューションのバージョンを確認し、wsl --set-version distro-name 2で、WSL2にアップグレードします。最後に、Docker Desktopの設定で、「Use the WSL 2 based engine」がチェックされているかを確認してください。この一連の手順を踏むことで、99%のケースでこのエラーは解消されます。4.8 「Error: permission denied while trying to connect to the Docker daemon socket」 — 権限の問題これは、DockerのUnixソケットファイル/var/run/docker.sockへのアクセス権限が、現在のユーザーに与えられていないために発生するエラーです。このエラーは、sudoを付けずにDockerコマンドを実行したときに発生します。解決策は、ユーザーをdockerグループに追加することです。sudo usermod -aG docker $USERを実行し、その後、新しいシェルセッションを開始su - $USERすることで、グループの変更が有効になります。このエラーは、Dockerのセキュリティモデルの一部であり、docker.sockへのアクセスは、root権限と同等の権限を持つため、ユーザーのグループメンバーシップを厳密に管理する必要があります。4.9 「Error: manifest for nginx:latest not found」 — レジストリの接続失敗これは、docker pullコマンドでイメージを取得しようとしたときに、Docker Hubとの接続に失敗したために発生するエラーです。主な原因は、ネットワークの問題、あるいは、Docker Hubのレートリミット無料アカウントのダウンロード制限です。このエラーを解決するには、まずping hub.docker.comでネットワークの接続を確認し、次にdocker loginでDocker Hubにログインしているかを確認します。ログインしていない場合は、docker loginを実行し、Docker Hubのアカウントで認証します。また、国内のユーザーの場合は、Dockerのレジストリミラー例https://registry.cn-hangzhou.aliyuncs.comを設定することで、このエラーを回避することができます。Docker Desktopの設定で、「Docker Engine」のJSON設定に、registry-mirrors: [https://registry.cn-hangzhou.aliyuncs.com]を追加することで、すべてのdocker pullコマンドが、このミラーを経由してイメージを取得するようになります。4.10 「Error: failed to create endpoint」 — ネットワークの競合Docker Composeで複数のサービスを起動したときに、このエラーが出る場合、ポートの競合が原因です。例えば、nginxサービスがポート80を公開しているのに、ホストのApacheがすでにポート80を占有している場合、Dockerはコンテナのエンドポイントを作成できず、このエラーを出します。解決策は、docker-compose.ymlで、portsの設定を変更することです。80:80を8080:80に変更すれば、ホストのポート8080をコンテナのポート80にマッピングするようになり、ポートの競合を回避できます。また、docker network lsで、Dockerが作成したネットワークの一覧を確認し、docker network inspect network-nameで、そのネットワークの設定を確認することで、ネットワークレベルでの競合を特定することもできます。問題の種類エラーメッセージのキーワード主な原因私の推奨解決策イメージ削除conflict: unable to remove repository reference複数のタグが同一イメージを参照docker rmi $(docker images -q image-name)で一括削除ボリューム削除volume is in use停止中のコンテナがボリュームを参照docker ps -aで停止中コンテナを確認し、docker rmで削除ディスク容量No space left on deviceBuild Cacheが肥大化docker builder prune -fを定期実行デーモン接続Cannot connect to the Docker daemonユーザーがdockerグループに所属していないsudo usermod -aG docker $USERでグループ追加Windows WSL2virtualisation support wasnt detectedWSL2が正しく設定されていないwsl --installとwsl --set-version distro 2を実行5. 実務で役立つ独自のノウハウと注意点10年以上の現場経験から得た教訓5.1 「削除」よりも「命名規則」が重要予防こそが最良の治療私が10年以上の現場で学んだ、最も重要な教訓は、「削除のコマンドを覚えることよりも、削除しなくて済むような運用を設計することの方が、はるかに重要だ」ということです。具体的には、すべてのコンテナ、イメージ、ボリュームに、一貫した命名規則を適用することです。例えば、CI/CDパイプラインで作成されるコンテナには、必ずci-${CI_PIPELINE_ID}-${CI_JOB_NAME}という形式の名前を付けます。これにより、docker ps -a --filter name^ci-というコマンドで、CIで作成されたすべてのコンテナを一括で抽出し、安全に削除することができます。同様に、開発環境のイメージにはdev-、ステージング環境にはstg-、本番環境にはprod-というプレフィックスを付けることで、docker images --filter reference