docker pruneという単独コマンドはありません。
実体はimage・builder・system・container・volume・networkの6種類に分かれたコマンド群です。
対象を間違えると、必要なデータまで消えます。
私はJavaバックエンドエンジニアとして日常的にDockerを使っており、容量逼迫のたびにdocker pruneに助けられてきました。
実際にdocker system prune -a --volumesで30GBを回収した実測データ（Docker Desktop 4.29系、オプションは公式ドキュメントで確認済み）も紹介します。
この記事でわかること
- 6種類の
docker pruneコマンドの違いと目的別の使い分けがわかる docker system dfで削除前に安全確認できる--filterオプションで「消したくないもの」を守りながら掃除できる- cronを使ったクリーンアップ自動化を設定できる
PARTS LIST ／目次
docker pruneとは？不要リソース削除
docker pruneとは、Docker環境内に溜まった不要なリソースを一括削除するコマンド群の総称です。
開発を続けると古いコンテナ・使われていないイメージ・ネットワーク設定が蓄積します。
手動で消すのは手間ですが、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%超を閾値に運用するのが理想です。
コンテナ・イメージ・ネットワークといった概念からKubernetesとの関係まで体系的に押さえておきたい方には、こちらの書籍も参考になります。
docker prune全6コマンドの使い分け一覧
6つのprune系コマンドは、削除対象・容量への影響・誤削除時のリスクがそれぞれ異なります。次の一覧表で違いを押さえてから、個別の使い方を確認していきます。
docker prune all・cleanupの別名コマンド
検索でよく見かける次の名前は、正式なコマンド名とは別物です。どれも実際の環境で打つのは、右側のコマンドです。
docker prune all：このコマンドはありません。全部まとめて消したいときはdocker system prune -aです（名前付きボリュームは消えません）docker images prune：正しくはdocker image prune（imageは単数形）。docker images pruneと打つと、イメージ一覧のフィルタとして扱われ、何も削除されませんdocker cleanup・docker purge：どちらも「not a docker command」になります。掃除はprune系で行いますdocker buildx prune：docker builder pruneと同じビルドキャッシュ削除です。buildxが入っている環境ではdocker builder pruneもこのコマンドとして動くため、新しいオプションはどちらでも使えます（詳しくは後述）
docker container pruneの使い方
停止しているコンテナだけを削除したい場合は、以下のコマンドを使います。
docker container prune実行すると「本当に削除しますか？」と確認プロンプトが出ます。y入力で削除が始まります。
実行結果には、削除されたコンテナのID一覧とともに、確保できたディスク容量（Total reclaimed space）が表示されます。
開発中に「コンテナ名が重複しています」というエラーが出た場合など、コンテナだけを一掃したいときに便利です。
docker image pruneの使い方と-a・--filter
不要なイメージを削除するには、以下のコマンドを使います。
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 は非推奨です。代わりに --reserved-space（予約サイズ）・--max-used-space（上限サイズ）・--min-free-space（目標空き容量）に置き換わりました。--max-used-spaceと--min-free-spaceはbuildx 0.18.0（2024年10月30日リリース）で追加され、BuildKit 0.17.0以降のビルダーが必要です。「Docker 25.0以降」という記載を見かけますが、buildxとBuildKitのバージョンに依存します。厳密にはDocker Engineの世代ではなく、buildxのバージョンで判断してください。
2026年8月時点（Docker Engine 29.7系）で新規に書くコマンドは docker buildx prune --reserved-space 5GB を推奨します。
docker buildx pruneとbuilder pruneの違い
docker builder pruneは昔からある基本コマンドです。現在のDockerでは、内部的にbuildx経由でBuildKitのキャッシュを操作しています。buildxプラグインが入っていない環境があります。そうした環境やDOCKER_BUILDKIT=0を設定している環境では、「DEPRECATED: The legacy builder is deprecated…」という警告が表示されます。
一方docker buildx pruneはbuildxネイティブのコマンドで、--reserved-spaceや--max-used-spaceなど新しいオプションを持ちます。buildxが入っている環境では、docker builder pruneもこのコマンドに転送されるため同じオプションが使えます。buildxを介さない旧実装のdocker builder pruneで使えるのは--keep-storageまでです（--dry-runはbuildx pruneにも公式には実装されていません）。
これから新規に書くスクリプトやドキュメントではdocker buildx pruneを優先してください。
既存のスクリプトにdocker builder pruneが残っている場合は、次回の見直しタイミングで置き換えるのがおすすめです。
BuildKitが有効かどうかはdocker buildx versionコマンドで確認できます。
私としては、すでに動いている docker builder prune のスクリプトをこのためだけに急いで書き換える必要はないという結論に至りました。
--keep-storage は非推奨扱いになっただけで動作自体は継続しており、緊急性は低いためです。
docker volume pruneの使い方と注意点
ボリュームの削除は最も慎重に行ってください。
docker volume pruneただし、このコマンドがデフォルトで削除するのは「匿名ボリューム」だけです。名前を指定せず作成され、どのコンテナからもマウントされていないものが対象になります（Docker Engine 23.0以降の挙動）。
docker-compose.ymlのvolumes:で名前を付けた「名前付きボリューム（named volume）」は、-a（--all）オプションを付けない限り削除対象になりません。
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の使い方｜-aと--volumes
すべてをまとめてきれいにしたいときは、docker system pruneの出番です。
docker system prunedocker system pruneを実行すると、停止中のコンテナ、未使用ネットワーク、ぶら下がりイメージがすべて削除されます。
さらに、-aと--volumesオプションを組み合わせることで、Docker環境を「初期状態に近い形」までリセットできます。ただし--volumesで削除されるのも匿名ボリュームのみで、名前付きボリュームは対象外です。名前付きボリュームまで削除したい場合は、別途docker volume prune --allを実行してください。
docker system prune は未使用のビルドキャッシュも削除対象に含まれます（BuildKit有効時）。
ビルドキャッシュは数十GBに達することもあるため、回収容量が想定以上に大きくなっても慌てないでください。
docker system prune -a --volumesディスク容量不足を解消する最終手段です。影響範囲が広いため、実行前にはdocker system dfで削除対象を確認してから実行しましょう。
docker pruneの応用テクニック｜dry-run代替と絞り込み
6つのpruneコマンドの基本を押さえたら、次に知っておきたいのが「実行前にどう確認するか」という運用面です。前述のとおりdocker buildx pruneに--dry-runオプションは存在しませんが、代替の確認手段はあります。ここではbuildx pruneの安全な事前確認方法と、消したくないリソースを守る--filterオプションの使い方を解説します。
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を比較する方法が現実的です。
ほかのpruneコマンド（image・container・system・volume）のdry-run事情は、後述のFAQでまとめて解説しています。代替の確認方法もあわせて確認してください。
--filterオプションで削除対象を絞り込む方法
pruneコマンドには--filterオプションがあり、削除対象を条件で絞り込めます。全削除が怖い場合に活用してください。
時間指定（until）：指定した時間より前に作成されたリソースだけを削除します。
docker image prune --filter "until=24h"24時間以上前に作成されたぶら下がりイメージだけが削除されます。直近の作業分は安全に残せます。
ラベル指定（label）：特定のラベルが付いたリソースを対象にしたり、除外したりできます。
docker image prune --filter "label!=keep"keepラベルが付いたイメージは削除から除外されます。
CI/CD環境で「絶対に消したくないイメージ」にラベルを付けておけば、安全にpruneを実行できます。
図解中心でDockerの全体像をもう一度イメージからつかみ直したい方には、こちらの書籍もおすすめです。
docker pruneの注意点｜3つのリスク
docker pruneは便利ですが、削除したデータは復元できません。以下の3つのリスクを事前に把握しておきましょう。
docker pruneで削除したデータは復元できない
Dockerの削除コマンドは、OSのゴミ箱機能とは異なります。
削除を実行した瞬間、Dockerはデータをファイルシステムから完全に消去します。「間違って消してしまったから元に戻す」という操作はできません。
データベースのデータや、コンテナ内で数時間かけて生成したログファイルが消えると、復旧に膨大な時間がかかります。
削除コマンド実行時はエンターキーを押す前に対象を必ず確認してください。
volumeが削除対象に含まれない理由
docker system prune（オプションなし）を実行しても、ボリュームは削除されません。
ボリュームがデフォルトで削除されないのは、Dockerの安全装置です。理由は以下の3点に集約されます。
・永続データを扱う場所
・一時的な実行環境と区別
・誤削除事故の防止
- 永続データを扱う場所：データベースやアップロードファイルなど、失うと致命的なデータを保存している
- 一時的な実行環境と区別：コンテナやイメージのような使い捨て前提のリソースとは性質が異なる
- 誤削除事故の防止：意図せず重要データを消さないよう、明示的なオプション指定なしには削除対象に含まれない
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を安全に使うには？
docker pruneを安全に使うポイントは2つです。削除前にdocker system dfで対象を確認すること、そして--filterオプションで消したくないものを守ることです。
削除前にdocker system dfで対象を確認する
いきなり削除するのではなく、何が消えるのかを事前に確認してください（各コマンドのdry-run事情はFAQを参照）。以下の一覧表示コマンドで事前確認します。
実際の現場では削除前後でdocker system dfで比較して容量をログ記録するクセをつけると、トラブルが少ないですよ。
step
1停止中のコンテナを確認する
現在停止中のコンテナを確認するには以下のコマンドを実行します。
docker ps -a --filter "status=exited"step
2ぶら下がりイメージを確認する
ぶら下がりイメージの一覧確認は以下で行えます。
docker images -f dangling=truestep
3未使用ボリュームを確認する
未使用ボリュームの確認は以下です。
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オプション（全未使用イメージ削除）を付けると、ビルドキャッシュもすべて消えるため注意が必要です。
次回のビルド時間が大幅に増加する可能性があります。
必要なコンテナが停止したままになっていないか、運用ルールをしっかり定めておきましょう。
本番環境での自動化はリスクが高いため、まずは開発環境で試してから導入してください。
実務で使うdocker 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ヶ月間メンテナンスせずに放置した環境を計測した結果を共有します。
実行したコマンドは docker system prune -a --volumes ひとつだけです。
ボリュームは事前に docker volume ls で中身を全件確認し、DB用の2件は削除前にバックアップを取得したうえで実行しました。なおDB用の2件は名前付きボリュームでした。実際には-a --volumes単体では削除対象にならない構成でしたが（匿名ボリュームのみが対象のため）、念のためバックアップを取得しました。
ボリュームをpruneから保護したい場合は、作成時に docker volume create --label keep=true myvolume のようにラベルを付けておくのが有効です。
なお、この30GBの回収量は、Docker Desktop の Disk image size の縮小分です。「Clean / Purge data」を実行して反映させました。
docker pruneでトラブルが起きたら？3つの事例と対処法
docker pruneのトラブルで多いのは、イメージ消失・ボリュームのデータ消失・CI/CDでの誤実行の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"削除したくないイメージやコンテナにラベルを付けておき、フィルター機能で削除対象から除外する設定をパイプラインに組み込みます。
キャッシュ効率とディスク容量のバランスを保てます。
「no space left on device」が出たときの対処
no space left on deviceは、Dockerが書き込む先のディスクに空きがないときに出るエラーです。docker pull・docker build・docker compose upのどれでも起こります。
まず、どこの容量が足りないのかを切り分けます。pruneで消す前にここを押さえておくと、削っても直らない状況を避けられます。
原因の切り分け：どこの容量が足りないか
- Linux（Docker Engine）：Dockerの保存先を置いているパーティションの空きが不足している。保存先の既定は
/var/lib/dockerで、空き容量だけでなくinode（ファイル数の上限）の枯渇でも同じメッセージになる - Docker Desktop（Mac/Windows）：ホストに空きがあっても、仮想ディスクが上限に達すると出る。上限は設定の「Resources」にある「Disk image size」で、公式ドキュメントでは「エンジンが使えるディスク容量の最大値」と説明されている
- Docker内の使い過ぎ：イメージ・ビルドキャッシュ・停止コンテナ・ボリュームが溜まっている。
docker system dfで内訳が分かる
Linuxでは、次の2コマンドで容量とinodeを両方確認します。
# Dockerの保存先（既定は /var/lib/docker）の空き容量
df -h /var/lib/docker
# inode（ファイル数の上限）の残り
df -i /var/lib/dockerUse%が100%に近ければ容量不足、IUse%が100%に近ければinode不足です。inode不足の場合は、小さいファイルが大量に溜まっている場所（古いコンテナのログやビルドキャッシュなど）を減らす必要があります。
対処の手順：影響の小さい順に消す
内訳を確認してから、影響の小さいものを順に削除します。各コマンドの違いは前半の「docker prune全6コマンドの使い分け一覧」で説明した通りです。
# 1. 内訳を確認（-v で個別の一覧）
docker system df -v
# 2. 影響の小さいものから順に削除
docker image prune
docker builder prune
docker container prune削除のたびにdocker system dfでRECLAIMABLEの変化を見て、空きが戻った時点で止めます。ボリュームの削除はデータが戻らないため、イメージ・キャッシュ・コンテナで足りないときの最後に回してください。
Docker Desktopでpruneしても容量不足が解消しない場合は、仮想ディスク側の問題です。後半の「Docker Desktopで容量が戻らない理由」で、Disk image sizeの扱いと容量を回収する手順を説明しています。
docker pruneによくある質問
docker prune全般について、読者からよく聞かれる質問をまとめました。容量が減らない・環境ごとの挙動の違い・存在しないコマンドとの混同など、実際に寄せられた疑問を中心に扱います。細かい手順や根拠は各見出しの本文もあわせて確認してください。
Q1. 実行しても容量が減らないのはなぜ？
A1. 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を実行すると、一気に反映されました。
Q2. Docker Desktopで容量が戻らない理由
A2. Docker DesktopではLinuxサーバーと異なる挙動があります。全データは仮想ディスクとして格納されています。Macでは ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw、Windows（WSL2バックエンド）では %LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx（古いバージョンでは %LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx）です。
そのため docker system prune を実行しても、ホストOS側のファイルサイズはすぐには縮小しないことがあります。Docker公式のMac向けFAQには、2つの説明があります。1つはpruneの後にホスト側で空きが反映されるまで数分かかること、もう1つは多くのツールが実サイズではなく最大ファイルサイズを表示することです。実サイズは ls -klsh Docker.raw で確認できます。
すぐに回収したいときは、同FAQにある docker run --privileged --pid=host docker/desktop-reclaim-space で領域の回収を促せます。「Troubleshoot」→「Clean / Purge data」は全データを初期化する操作です。イメージやボリュームを残したいときには使わないでください。
Windows の場合は代わりに、管理者PowerShellで wsl --shutdown 後に Optimize-VHD -Path <パス> -Mode Full を実行する方法もあります。
prune 後にここで挙げた回収手順を踏むと、ホストOSの空き容量が増えます。
Q3. pruneしても動作に影響は出ない？
A3. 稼働中のコンテナには影響しません。削除されるのは現在使われていないリソースだけです。
ただし「今は停止しているが翌日起動する予定のコンテナ」は削除されます。コンテナは使い捨て前提の設計です。
設定をコンテナ内に直接書き込んでいると初期化される可能性があるため、データは必ずボリュームまたは永続ストレージに外出ししてください。
Q4. 本番環境で使っても大丈夫？
A4. 本番環境での実行は可能ですが、細心の注意が必要です。
本番でpruneを実行する際の鉄則は以下の3点です。
- アクセスが少ない深夜帯に実行する
system prune -aのような広範囲な削除ではなく、対象を絞ったコマンドを使う- 高負荷時は避ける（削除処理でディスクI/Oが上昇し、応答速度が低下する場合がある）
万が一のオペレーションミスがサービス停止に直結するため、本番環境では慎重に操作してください。
私の経験では、本番環境でdocker system pruneを直接実行するよりも、前述のクリーンアップスクリプトのように対象を段階的に絞り込む方が事故率は圧倒的に低くなります。
そもそも本番でpruneが必要になる時点でディスク監視の閾値設計を見直すべき、というのが実務を通じての結論です。
Q5. docker purge・cleanupはある？
A5. 「docker purge」というCLIコマンドは存在しません。不要リソースを削除する正式なコマンドは本記事で解説してきたpruneです。
Linuxのapt purgeなど他ツールの用語と混同して検索されがちですが、docker purgeと入力しても「not a docker command」エラーになります。
なお、Docker Desktop（Mac/Windows）のトラブルシューティング画面には「Clean / Purge data」という機能があります。
こちらはpruneと違い、コンテナ・イメージ・ボリュームを含む全データを初期化する強力な操作です。ディスク容量の整理が目的なら、まずpruneコマンドから使うのが安全です。
Q6. 各pruneコマンドにdry-runはある？
A6. いいえ、2026年9月時点でdocker image prune・docker volume prune・docker system prune・docker buildx pruneのいずれにも公式の--dry-runオプションはありません。コマンドごとに以下の一覧表示コマンドで代替確認してください。
- image prune：
docker images -f dangling=trueで削除候補を一覧表示 - volume prune：
docker volume ls -f dangling=trueで削除候補のボリューム名を一覧表示し、必要に応じてdocker volume inspect <名前>で中身を確認 - system prune：実行前に
docker system dfで内訳を控え、docker ps -a --filter "status=exited"・docker images -f dangling=true・docker volume ls -f dangling=trueを個別に確認してから判断
ボリュームは復元できない削除リスクが最も高いため、docker system prune単体では対象を確認せずに削除しないよう注意してください（ボリュームを含めるには別途--volumesの明示指定が必要です）。
Q7. docker compose pruneというコマンドはある？
A7. 「docker compose prune」というCLIコマンドは存在しません。Docker Compose（V2）のサブコマンド一覧にpruneはなく、実行すると「unknown command」エラーになります。
Composeプロジェクトの不要リソースを掃除したい場合は、docker compose down（コンテナ・ネットワークを削除、--volumesでボリュームも削除）を使ってください。あるいは、本記事で解説したdocker container prune・docker image prune・docker system pruneなどの通常のprune系コマンドも使えます。
まとめ：docker pruneで容量回復
Dockerのディスク容量不足は、docker prune系コマンドを使えば解決できます。
6つのpruneコマンドは、それぞれ削除対象が異なります。
対象を絞った個別コマンド（container / image / builder / network / volume prune）があります。まとめて削除するなら docker system prune です。目的に応じて使い分けてください。
安全運用のための4つのポイントを整理します。
- まずは確認：
docker system dfと一覧表示コマンドで削除前に何が消えるかを把握する - ボリュームは保護：DBなどの永続データはバックアップを取るまで消さない
- フィルターを活用：
--filter until=24hや--filter label!=keepで削除対象を絞り込む - 自動化は慎重に：開発環境で十分にテストしてから導入する
| REV. | DATE | 内容 |
|---|---|---|
| 10 | 2026-10-20 | FAQ・JSON-LDの正確性を再検証し、長い見出しを短縮。段落の強調表示を追加 |
| 9 | 2026-10-15 | 図解を描き直し（図面のデザインにそろえた） |
| 8 | 2026-10-14 | 雰囲気だけの挿絵を外した |
| 7 | 2026-09-30 | 2026年9月時点の情報で全体を見直し |
| … ほか5回の改訂 | ||
| 1 | 2025-11-20 | 初版 |