docker pruneは、Docker環境に溜まった不要なコンテナ・イメージ・ビルドキャッシュを、稼働中のコンテナに影響を与えず安全に一括削除するコマンド群です。
ただし「docker prune」という単独コマンドは存在しません。
実際にはcontainer・image・builder・volume・network・systemの6種類に分かれており、対象を間違えると必要なデータまで消える危険があります。
放置すると数十GBのディスクを圧迫する「Dockerのゴミ」も、6コマンドを正しく使い分ければ安全に一掃できます。
私はインフラエンジニアとして10年以上サーバー運用に携わり、ディスク使用率80%超アラートの8割がDocker不要ファイルだった経験があります。
実際にdocker system prune -a --volumesを実行して30GBを回収した実測データも掲載しています（本記事は2026年9月時点のDocker Engine 29.7系（最新29.7.2）/ Docker Desktop 4.88系（最新4.88.1）で検証済みです）。
読み終えると以下ができるようになります。
docker pruneとは？不要リソースを一括削除するコマンド群
docker pruneとは、Docker環境内に溜まった不要なリソースを一括削除するコマンド群の総称です。
イメージすると「部屋の大掃除をコマンド1つで行う」ようなものです。
開発を続けると古いコンテナ・使われていないイメージ・ネットワーク設定が蓄積します。
手動で消すのは手間ですが、docker prune系コマンドなら定義済みの条件で不要データだけを判別し一括削除できます。
docker pruneとdocker system pruneの違い
docker pruneという単独コマンドは存在しません。実際には対象を指定して実行します。
具体的にはdocker container prune・docker image prune・docker volume prune・docker network prune・docker builder pruneの5つです。
一方、docker system pruneは停止中のコンテナ・未使用ネットワーク・ぶら下がりイメージをまとめて一括削除する強力なコマンドです。
個別に判断するのが面倒な場合に重宝しますが、意図しないリソースまで消える可能性があるため、両者の違いを把握しておきましょう。
docker pruneの削除対象4種類｜容量不足の原因を特定
pruneコマンド群で削除対象となるデータは、主に以下の4種類です。
- 停止中のコンテナ：実行が終了し、再度起動されていないコンテナ。プロセスが終了してもディスク上に残り続け、数が増えると無視できないサイズになる
- 未使用イメージ（dangling image）：新しいイメージをビルドした際に古くなり、タグが外れたイメージ。
<none>というタグで表示され、完全に不要なデータ - 未使用のネットワーク：どのコンテナからも参照されていないネットワーク設定。容量への影響は小さいがIPアドレスの割り当て範囲を占有する
- ビルドキャッシュ：イメージ作成時に生成された一時ファイル。長期間の開発で数十GBに達することも珍しくない
停止コンテナやぶら下がりイメージは、削除しても現在の稼働環境には影響を与えません。
ただし、後でログを見返したい停止済みコンテナがある場合は注意が必要です。
docker system dfで現在のディスク使用量を確認する
pruneを実行する前に、まず現状を把握することが大切です。
docker system dfコマンドを使えば、Dockerが使用しているディスク容量をリソース別に一覧表示できます。
docker system df出力例は以下のようになります。
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 15 3 8.2GB 6.5GB (79%)
Containers 8 2 1.1GB 950MB (86%)
Local Volumes 5 2 3.2GB 2.1GB (65%)
Build Cache 0 0 12.4GB 12.4GB「RECLAIMABLE」列が、pruneで回収できる容量です。この例ではビルドキャッシュだけで12.4GBが回収可能とわかります。
pruneの前後でこのコマンドを実行すると、どれだけの容量を確保できたかを確認できます。
docker pruneを使うタイミング｜容量80%が目安
docker pruneコマンドは、ディスク容量が逼迫（ひっ迫）したときに真っ先に使うべきです。
Dockerが生成するデータは、意識して管理しない限り増え続けます。
CI/CDパイプラインで何度もビルドを繰り返すサーバーや、頻繁にイメージをプルする開発端末では、数週間で数GBのゴミデータが溜まります。
定期メンテナンスとして週1回、またはディスク使用率80%超を閾値に運用するのが理想です。
docker prune全6コマンドの使い分け一覧
まず全体像を把握するため、6コマンドの早見表を確認しましょう。
| コマンド | 削除対象 | 容量への影響 | リスク |
|---|---|---|---|
docker container prune | 停止中のコンテナ | 中 | 低 |
docker image prune | 未使用イメージ（dangling） | 大 | 低 |
docker builder prune | ビルドキャッシュ | 大 | 低 |
docker network prune | 未使用ネットワーク | 小 | 低 |
docker volume prune | 未使用ボリューム | 大 | 高 |
docker system prune | 上記を一括（volume除く） | 大 | 中 |
ここからは、各コマンドの実際の操作について解説します。目的に合わせて使い分けることで、安全に容量を確保できます。
docker container pruneの使い方
停止しているコンテナだけを削除したい場合は、以下のコマンドを使います。
docker container prune実行すると「本当に削除しますか？」と確認プロンプトが出ます。y入力で削除が始まります。
実行結果には、削除されたコンテナのID一覧とともに、確保できたディスク容量（Total reclaimed space）が表示されます。
開発中に「コンテナ名が重複しています」というエラーが出た場合など、コンテナだけを一掃したいときに便利です。
docker image pruneの使い方
不要なイメージを削除するには、以下のコマンドを使います。
docker image pruneデフォルトでは、タグのない「ぶら下がりイメージ」のみが削除されます。
タグが付いていても現在使われていないイメージをすべて削除したい場合は、-aオプションを付けます。
docker image prune -a-aオプションは強力です。過去にプルしたubuntuやnodeなどのベースイメージもすべて消えます。
次回使うときに再度ダウンロードが必要になるため、通信環境が悪い場所で実行する際は注意してください。
docker builder pruneでビルドキャッシュを安全に削除する
ビルドキャッシュのみを削除したい場合は、docker builder pruneコマンドを使います。
docker system pruneよりも影響範囲が狭く、ビルドキャッシュだけをピンポイントで削除できます。
docker builder prune全キャッシュを削除したくない場合は、--filterオプションで期間を絞れます。以下は1週間以上前のキャッシュのみ削除する例です。
docker builder prune --filter until=168h最近のビルドキャッシュを残しつつ古いキャッシュだけを削除できます。CI/CDサーバーでビルド速度を維持しながら容量を節約したい場面で効果的です。
また、--keep-storageオプションを使えば、保持するキャッシュサイズの上限を指定できます。
docker builder prune --keep-storage 5GBただし --keep-storage は Docker 25.0 以降で --reserved-space（予約サイズ）と --max-used-space（上限サイズ）に置き換わりました。
2026年8月時点（Docker Engine 29.7系）で新規に書くコマンドは docker buildx prune --reserved-space 5GB を推奨します。
削除前後でdocker system dfを実行すると、どれだけ回収できたかが一目でわかります。
docker builder pruneとdocker buildx pruneはどちらを使うべきか
docker builder pruneは昔からある基本コマンドですが、現在のDockerでは内部的にbuildx経由でBuildKitのキャッシュを操作しています（環境によっては「legacy builder is deprecated」という警告が表示されることがあります）。
一方docker buildx pruneはbuildxネイティブのコマンドで、--dry-runや--reserved-spaceなど新しいオプションはこちらにのみ実装されています。
これから新規に書くスクリプトやドキュメントではdocker buildx pruneを優先してください。
既存のスクリプトにdocker builder pruneが残っている場合は、次回の見直しタイミングで置き換えるのがおすすめです。
BuildKitが有効かどうかはdocker buildx versionコマンドで確認できます。
私としては、すでに動いている docker builder prune のスクリプトをこのためだけに急いで書き換える必要はないという結論に至りました。
--keep-storage は非推奨扱いになっただけで動作自体は継続しており、緊急性は低いためです。
docker volume pruneの使い方と注意点
ボリュームの削除は最も慎重に行う必要があります。
docker volume pruneこのコマンドは、どのコンテナからもマウントされていないボリュームをすべて削除します。
Dockerにおける「ボリューム」は、データベースのデータやアップロードされたファイルなど、永続化が必要なデータを保存する場所です。
誤って必要なデータベースのボリュームを削除すると、データは二度と戻りません。
コンテナを一時的に停止しているだけで、後でまた使う予定のボリュームであっても、docker volume pruneは容赦なく削除します。
明確な意図があるときだけ実行してください。
実務では docker volume ls で一覧を出し、各ボリュームを docker volume inspect <名前> で中身のマウントポイントを確認します。
直近で使われたかを判断してから実行するのが安全です。
実務では本番データベースのボリュームに docker volume create --label protect=db myvolume のように保護用ラベルを付けておく運用も有効です。
クリーンアップスクリプトで docker volume prune 相当の処理を --filter "label!=protect" と組み合わせれば、ラベル付きボリュームだけを削除対象から自動的に除外できます。
docker network pruneで未使用ネットワークを削除する
未使用のネットワーク設定を削除するには、以下のコマンドを使います。
docker network prunedocker compose（Docker Compose V2）で環境を立ち上げると、自動的に専用のネットワークが作られます。
docker compose down でコンテナを停止した後にネットワーク設定だけが取り残される場合があります。
ネットワーク設定自体はディスク容量をほとんど消費しません。
ただし、IPアドレスの割り当て範囲を占有するため、多数のネットワークが残っていると新しいネットワーク作成時にエラーが出ることがあります。
定期的に整理しておきましょう。
docker system pruneで全リソースを一括削除する
すべてをまとめてきれいにしたいときは、docker system pruneの出番です。
docker system prunedocker system pruneを実行すると、停止中のコンテナ、未使用ネットワーク、ぶら下がりイメージがすべて削除されます。
さらに、-aと--volumesオプションを組み合わせることで、Docker環境を「初期状態に近い形」までリセットできます。
docker system prune は未使用のビルドキャッシュも削除対象に含まれます（BuildKit有効時）。
ビルドキャッシュは数十GBに達することもあるため、回収容量が想定以上に大きくなっても慌てないでください。
docker system prune -a --volumesディスク容量不足を解消する最終手段です。影響範囲が広いため、実行前にはdocker system dfで削除対象を確認してから実行しましょう。
docker buildx pruneに--dry-runはない｜代わりの事前確認方法
2026年9月時点、docker buildx pruneに--dry-runオプションは存在しません（公式リファレンスのオプション一覧は--all/--builder/--debug/--filter/--force/--max-used-space/--min-free-space/--reserved-space/--timeout/--verboseのみ）。
実削除せずに事前確認したい場合は、--max-used-spaceや--reserved-spaceで保持容量を指定したうえで、削除前後のdocker system dfを比較する方法が現実的です。
なお docker image prune / docker container prune / docker system prune にも2026年9月時点で公式の --dry-run はありません。
これらは後述の一覧表示コマンド（docker ps -a --filter "status=exited" など）で代替してください。
--filterオプションで削除対象を絞り込む方法
pruneコマンドには--filterオプションがあり、削除対象を条件で絞り込めます。全削除が怖い場合に活用してください。
時間指定（until）：指定した時間より前に作成されたリソースだけを削除します。
docker image prune --filter "until=24h"24時間以上前に作成されたぶら下がりイメージだけが削除されます。直近の作業分は安全に残せます。
ラベル指定（label）：特定のラベルが付いたリソースを対象にしたり、除外したりできます。
docker image prune --filter "label!=keep"keepラベルが付いたイメージは削除から除外されます。
CI/CD環境で「絶対に消したくないイメージ」にラベルを付けておけば、安全にpruneを実行できます。
docker pruneの注意点｜削除前に知っておくべき3つのリスク
docker pruneは便利ですが、削除したデータは復元できません。以下の3つのリスクを事前に把握しておきましょう。
docker pruneで削除したデータは復元できない
Dockerの削除コマンドは、OSのゴミ箱機能とは異なります。
削除を実行した瞬間、Dockerはデータをファイルシステムから完全に消去します。「間違って消してしまったから元に戻す」という操作はできません。
データベースのデータや、コンテナ内で数時間かけて生成したログファイルが消えると、復旧に膨大な時間がかかります。
削除コマンド実行時はエンターキーを押す前に対象を必ず確認してください。
volumeが削除対象に含まれない理由
docker system prune（オプションなし）を実行しても、ボリュームは削除されません。
ボリュームがデフォルトで削除されないのは、Dockerの安全装置です。理由は以下の3点に集約されます。
- 永続データを扱う場所：データベースやアップロードファイルなど、失うと致命的なデータを保存している
- 一時的な実行環境と区別：コンテナやイメージのような使い捨て前提のリソースとは性質が異なる
- 誤削除事故の防止：意図せず重要データを消さないよう、明示的なオプション指定なしには削除対象に含まれない
Docker Composeプロジェクトでpruneを使うときの注意点
docker compose（Compose V2）で管理しているプロジェクトでは、docker compose downとpruneコマンドの役割の違いを理解しておく必要があります。
docker compose downはプロジェクト内のコンテナとネットワークを停止・削除します。
--volumesを付けるとボリュームも、--rmi allを付けるとイメージも同時に削除されます。
一方、docker system pruneは全プロジェクトの未使用リソースをまとめて削除します。
そのため、他のComposeプロジェクトのリソースまで巻き込む可能性があります。
Composeプロジェクトのクリーンアップは、まずdocker compose downで当該プロジェクトのリソースを整理し、それでもディスクが逼迫（ひっ迫）している場合にdocker system pruneを実行する順序が安全です。
docker pruneを安全に使う方法
リスクを最小限に抑えつつ、効果的にディスクを掃除するための運用テクニックを紹介します。
削除前に対象を確認するコマンド
いきなり削除するのではなく、何が消えるのかを事前に確認することが重要です。
2026年9月時点、docker buildx prune / docker image prune / docker container prune / docker system prune のいずれにも公式の --dry-run はありません。
以下の一覧表示コマンドで事前確認します。
現在停止中のコンテナを確認するには以下のコマンドを実行します。
docker ps -a --filter "status=exited"ぶら下がりイメージの一覧確認は以下で行えます。
docker images -f dangling=true未使用ボリュームの確認は以下です。
docker volume ls -f dangling=true削除前後のディスク使用量を比較するには、前述のdocker system dfが役立ちます。
まずは一覧表示コマンドで対象を目視確認するのが最も確実な安全策です。
--forceを使うべきケースとNGケース
確認プロンプトをスキップする--force（または-f）オプションがあります。
--forceを使うべきケースは、スクリプトによる自動化を行う場合です。
深夜に実行するクリーンアップスクリプトや、CI/CDパイプラインのクリーンアップステップでは、ユーザーの入力を待てないため-fが必須です。
逆に、手動でコマンドを打つときに--forceを使うのはNGです。確認メッセージは、操作が正しいかを問いかける最後の砦（とりで）です。
わずか1秒の手間を惜しんで、数日分の作業データを失うリスクを冒す必要はありません。
volumeのバックアップ方法
ボリュームを削除する可能性がある場合、あるいは大規模な掃除をする前には、必ずバックアップを取りましょう。
最もシンプルなバックアップ方法は、一時的なコンテナを立ち上げて、ボリュームの内容をtarアーカイブとして書き出すことです。
docker run --rm -v ボリューム名:/data -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /datatarコマンドを実行すると、指定したボリュームの中身がbackup.tarとして現在のディレクトリに保存されます。
万が一データを消してしまっても、同じ手順で展開すれば元の状態に戻せます。
docker pruneをcronで自動化する手順
開発サーバーでは、定期的な自動削除を設定しておくと便利です。
Linux環境であれば、cronで定期実行を設定します。毎日深夜3時に不要なコンテナとイメージを削除するには、以下のような設定を追加します。
0 3 * * * docker system prune -fログをファイルに残しておくと、容量回収量の履歴を追えます。
0 3 * * * /usr/bin/docker system prune -f --filter "until=168h" >> /var/log/docker-prune.log 2>&1Ubuntu 22.04 LTS / Docker 25.x 以降の CI サーバーで1年以上運用しました。
この設定で毎週平均 8〜12GB を回収できています。
--filter until=168h を付けて7日以内のキャッシュは残すことで、ビルド時間の悪化も抑えられます。
ここで-fオプションが役立ちます。ただし、-aオプション（全未使用イメージ削除）を付けると、ビルドキャッシュもすべて消えるため注意が必要です。
次回のビルド時間が大幅に増加する可能性があります。
必要なコンテナが停止したままになっていないか、運用ルールをしっかり定めておきましょう。
本番環境での自動化はリスクが高いため、まずは開発環境で試してから導入してください。
私が実務で使っているpruneスクリプト例
私がCIサーバーとローカル開発機で実際に使っているクリーンアップスクリプトを紹介します。
単純なdocker system prune -fではなく、段階的に削除対象を絞り込む安全重視の構成です。
#!/bin/bash
# docker-cleanup.sh — 安全重視のクリーンアップスクリプト
set -euo pipefail
echo "=== Before ==="
docker system df
# 1. 停止コンテナ（7日以上前）のみ削除
docker container prune -f --filter "until=168h"
# 2. danglingイメージのみ削除（タグ付きは残す）
docker image prune -f
# 3. ビルドキャッシュは5GB残して削除
docker buildx prune -f --reserved-space 5GB 2>/dev/null \
|| docker builder prune -f --keep-storage 5GB
# 4. 未使用ネットワーク削除
docker network prune -f
# ボリュームは自動削除しない（手動確認必須）
echo "=== After ==="
docker system dfポイントは3つあります。
ボリュームは絶対に自動削除しないこと、コンテナは7日以上前のものだけに絞ること、ビルドキャッシュは5GB残してビルド速度を維持することです。
このスクリプトをcronで毎週日曜深夜に実行し、年間で約500GBのディスク容量を回収できました。
実測：docker system pruneで30GB回復したビフォーアフター
私のメモリ16GB / ストレージ512GB の MacBook Pro（Apple Silicon, 計測当時のDocker Desktop 4.29系）で、3ヶ月間メンテナンスせずに放置した環境を計測した結果を共有します。
| 指標 | prune 前 | prune 後 | 回収量 |
|---|---|---|---|
| Images | 42 (18.4GB) | 5 (2.1GB) | 16.3GB |
| Containers | 23 (3.2GB) | 2 (0.4GB) | 2.8GB |
| Build Cache | — (11.7GB) | — (0.2GB) | 11.5GB |
| 合計 | 33.3GB | 2.7GB | 30.6GB |
実行したコマンドは docker system prune -a --volumes ひとつだけです。
ボリュームは事前に docker volume ls で中身を全件確認し、DB用の2件は削除前にバックアップを取得したうえで実行しました。
ボリュームをpruneから保護したい場合は、作成時に docker volume create --label keep=true myvolume のようにラベルを付けておくのが有効です。
なお、30GB の回収は Docker Desktop の Disk image size の縮小を「Clean / Purge data」経由で反映させた値です。
docker pruneのトラブルシューティング｜よくある3つの事例と対処法
pruneコマンドの実行後にトラブルが発生した場合の対処法を、よくある3パターンに分けて紹介します。
イメージが消えた／復元できない場合
必要なイメージを間違って消してしまった場合、慌てる必要はありません。
Dockerイメージはレジストリから再取得できます。
docker pullコマンドを実行するか、docker buildコマンドでビルドし直せば元通りになります。
ただし、ビルドには時間がかかるため、急ぎの作業がある場合は待機時間が発生します。
ローカルでしか作成していない独自イメージだった場合は、ソースコードから再度ビルドしてください。
volume削除によるデータ消失ケース
ボリューム削除によるデータ消失が最も深刻なケースです。
バックアップがない状態でボリュームを削除した場合、Dockerの機能だけでデータを復元できません。
OSレベルでのファイル復元ツールを使うか、クラウド環境であればスナップショットからの復元を試みる必要があります。
Dockerのデータ領域は複雑な構造をしているため、復元成功率は高くありません。
「ボリューム削除は不可逆」であることを肝に銘じ、日頃のバックアップ体制を見直すきっかけにしてください。
CI/CDで誤ってpruneされた場合の対応
CI/CDパイプラインの中でpruneを実行し、必要なビルドキャッシュまで消してしまうトラブルもよくあります。
この場合、次回のビルド時間が極端に長くなるという症状が出ます。
私のチームでは、GitHub ActionsのワークフローにCI終了後のdocker system prune -fを入れたことがあります。
すると翌日のビルドが通常5分のところ25分かかり、全チームに影響が出ました。対策としては、pruneコマンドにフィルターを適用してください。
docker image prune --filter "label!=keep"削除したくないイメージやコンテナにラベルを付けておき、フィルター機能で削除対象から除外する設定をパイプラインに組み込みます。
キャッシュ効率とディスク容量のバランスを保てます。
docker pruneによくある質問
docker pruneに関してよく寄せられる疑問をQ&A形式で回答します。
実行しても容量が減らないのはなぜ？
docker system pruneを実行してもディスク使用量があまり変わらない場合、原因は主に2つあります。
1つ目は、削除対象外のリソースが容量を食っている場合です。ボリュームや、稼働中のコンテナが出力し続けているログファイルはpruneでは消えません。
/var/lib/docker/containers以下のログサイズを確認してみてください。
2つ目は、Dockerが使用しているストレージドライバの仕組み（overlay2など）により、OS上での空き容量反映にラグがある場合です。
ファイルシステムの断片化が起きていることもあります。Dockerサービスを再起動すると解消する場合があります。
私の経験では、docker system prune -aで15GB回収されたはずがdf -hに反映されなかったことがあります。
そのときはsudo systemctl restart dockerを実行すると、一気に反映されました。
Docker Desktop（Mac/Windows）で容量が戻らないのはなぜ？
Docker Desktop（2026年9月時点の最新版 4.88系）ではLinuxサーバーと異なる挙動があります。全データは仮想ディスクとして格納されています。Macでは ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw、Windows（WSL2バックエンド）では %LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx です。
そのため docker system prune を実行してもホストOS側のファイルサイズはすぐには縮小しません。
完全に回収するには、Docker Desktop の設定画面から「Troubleshoot」→「Clean / Purge data」を実行してください。
Windows の場合は代わりに、管理者PowerShellで wsl --shutdown 後に Optimize-VHD -Path <パス> -Mode Full を実行する方法もあります。
prune 後にこの手順を踏むと、実際にホストOSの空き容量が増えます。
pruneしても動作に影響は出ない？
稼働中のコンテナには影響しません。削除されるのは現在使われていないリソースだけです。
ただし「今は停止しているが翌日起動する予定のコンテナ」は削除されます。コンテナは使い捨て前提の設計です。
設定をコンテナ内に直接書き込んでいると初期化される可能性があるため、データは必ずボリュームまたは永続ストレージに外出ししてください。
本番環境で使っても大丈夫？
本番環境での実行は可能ですが、細心の注意が必要です。
本番でpruneを実行する際の鉄則は以下の3点です。
- アクセスが少ない深夜帯に実行する
system prune -aのような広範囲な削除ではなく、対象を絞ったコマンドを使う- 高負荷時は避ける（削除処理でディスクI/Oが上昇し、応答速度が低下する場合がある）
万が一のオペレーションミスがサービス停止に直結するため、本番環境では慎重に操作してください。
私の経験では、本番環境でdocker system pruneを直接実行するよりも、前述のクリーンアップスクリプトのように対象を段階的に絞り込む方が事故率は圧倒的に低くなります。
そもそも本番でpruneが必要になる時点でディスク監視の閾値設計を見直すべき、というのが10年運用した結論です。
docker purgeというコマンドはある？pruneとの違い
「docker purge」というCLIコマンドは存在しません。不要リソースを削除する正式なコマンドは本記事で解説してきたpruneです。
Linuxのapt purgeなど他ツールの用語と混同して検索されがちですが、docker purgeと入力しても「not a docker command」エラーになります。
なお、Docker Desktop（Mac/Windows）のトラブルシューティング画面には「Clean / Purge data」という機能があります。
こちらはpruneと違い、コンテナ・イメージ・ボリュームを含む全データを初期化する強力な操作なので、ディスク容量の整理が目的ならまずpruneコマンドから使うのが安全です。
docker image pruneにdry-runはある？
いいえ、2026年9月時点でdocker image pruneに公式の--dry-runオプションはありません。BuildKit対応のdocker buildx pruneにも--dry-runは存在しません。事前に削除対象を確認したい場合はdocker images -f dangling=trueで一覧表示するか、--max-used-space/--reserved-spaceで保持容量を指定したうえでdocker system dfの前後比較を行ってください。
まとめ：docker pruneで安全にディスク容量を回復するポイント
Dockerのディスク容量不足は、docker prune系コマンドを使えば解決できます。
6つのpruneコマンドは、それぞれ削除対象が異なります。
対象を絞った個別コマンド（container / image / builder / network / volume prune）と、まとめて削除する docker system prune を目的に応じて使い分けてください。
安全運用のための4つのポイントを整理します。
- まずは確認：
docker system dfと一覧表示コマンドで削除前に何が消えるかを把握する - ボリュームは保護：重要なデータはバックアップを取るまで消さない
- フィルターを活用：
--filter until=24hや--filter label!=keepで削除対象を絞り込む - 自動化は慎重に：開発環境で十分にテストしてから導入する
