開発を続けていると、いつの間にかPCのストレージ容量が圧迫されていませんか。Dockerを長く使っていると、不要なデータが溜まり続け、気づけば数十GBもの容量を消費しているケースがよくあります。
私はインフラエンジニアとして数多くのサーバー運用や開発環境の整備を行ってきました。その経験の中で、ディスク容量不足のアラートが鳴る原因の多くがDockerの不要ファイルであることを突き止めました。実際にdocker pruneコマンドを適切に使用して、50GB以上の空き容量を確保した経験も一度や二度ではありません。
この記事では、Dockerの容量不足に悩んでいる方に向けて、不要なデータを安全かつ効率的に削除する方法を解説します。この内容を実践すれば、ディスク容量を劇的に節約し、快適な開発環境を取り戻せます。
docker pruneとは？
docker pruneとは、Docker環境内に溜まった不要なリソースを一括で削除するためのコマンドです。これはいわば、部屋の大掃除を一気に行うようなものです。
コンテナを利用した開発を行っていると、知らず知らずのうちに古いコンテナや使われていないイメージ、ネットワーク設定などが蓄積されます。これらは手動で一つひとつ消すことも可能ですが、非常に手間がかかります。docker pruneを使えば、定義された条件に従って不要なデータを自動的に判別し、きれいに掃除してくれます。
docker system pruneとの違い
docker pruneとよく混同されるのがdocker system pruneですが、実態は少し異なります。
docker pruneは、特定のオブジェクト（コンテナ、イメージ、ボリューム、ネットワーク）に対して個別に実行するコマンドの総称として使われることが多い言葉です。一方で、docker system pruneはそれらをまとめて一括削除する強力なコマンドです。
具体的には、docker system pruneを実行すると、停止中のコンテナ、使われていないネットワーク、ぶら下がりイメージ（タグ付けされていないイメージ）がすべて削除されます。個別に判断するのが面倒な場合に重宝しますが、消してはいけないものまで消してしまうリスクもあるため、違いを理解しておく必要があります。
削除されるデータの種類
このコマンドで削除対象となるデータは、主に以下の4種類です。
- 停止中のコンテナ：実行が終了し、再度起動されていないコンテナ
- 未使用のネットワーク：どのコンテナからも参照されていないネットワーク設定
- ぶら下がりイメージ：新しいイメージをビルドした際に古くなり、タグが外れたイメージ（dangling images）
- ビルドキャッシュ：イメージ作成時に生成された一時ファイル
これらは基本的に、削除しても現在の稼働環境には影響を与えません。しかし、後でログを見返したい停止済みコンテナがある場合は注意が必要です。
どんな場面で使うべきコマンドか
このコマンドは、ディスク容量が逼迫（ひっぱく）したときに真っ先に使うべきです。
理由は、Dockerが生成するデータは、意識して管理しない限り無限に増え続けるからです。例えば、CI/CDパイプラインで何度もビルドを繰り返すサーバーや、頻繁にイメージをプルする開発端末では、数週間で数GBのゴミデータが溜まります。
定期的なメンテナンスとして週に一度実行する、あるいはディスク使用量が80%を超えたタイミングで実行するなど、ルールを決めて運用するのが理想的です。
docker pruneで削除できるリソース
削除できるリソースの詳細を知ることは、誤削除を防ぐために重要です。ここでは、具体的に何が消えるのかを掘り下げて解説します。
未使用のコンテナ
docker psコマンドを打ったとき、表示されないコンテナが裏側に数多く存在しています。これらが「停止中のコンテナ」です。
コンテナはプロセスが終了しても、明示的に削除しない限りディスク上に残り続けます。エラーで落ちたコンテナや、一度だけ実行して終わったバッチ処理のコンテナなどがこれに該当します。これらはログや書き込まれたファイルデータを保持しているため、数が積み重なると無視できないサイズになります。これらを一掃することで、ファイルシステムのインノード数（ファイル管理領域）の節約にもつながります。
停止中のイメージ
Dockerイメージには「使用中」と「未使用」の状態があります。
pruneで削除されるのは、主に「どのコンテナからも使われていないイメージ」です。特に開発中は、Dockerfileを修正してビルドし直す作業を繰り返します。すると、同じ名前の新しいイメージが作られ、古いイメージは名前（タグ）を失います。これを「dangling image（ぶら下がりイメージ）」と呼び、<none>というタグで表示されます。これらは完全に不要なデータであり、削除しても何の問題もありません。
未使用のネットワーク
Dockerはコンテナ間の通信のために仮想ネットワークを作成します。
docker-composeなどを使って環境を立ち上げると、自動的に専用のネットワークが作られます。しかし、環境を削除したり構成を変更したりした際、このネットワーク設定だけが取り残される場合があります。ネットワーク設定自体は容量をほとんど食いませんが、IPアドレスの割り当て範囲などを占有してしまうため、きれいにしておくのが好ましいです。
ビルドキャッシュ
意外と見落とされがちなのが、ビルドキャッシュです。
Dockerはイメージのビルド時間を短縮するために、各レイヤーのデータをキャッシュとして保存しています。これは開発効率を上げるために非常に有用ですが、古いキャッシュデータはずっと残り続けます。長期間開発を続けていると、このキャッシュだけで数十GBに達することも珍しくありません。キャッシュを削除すると次回のビルド時間は長くなりますが、ディスク容量は大幅に回復します。
docker pruneの基本的な使い方
ここからは、実際のコマンド操作について解説します。目的に合わせて使い分けることで、安全に容量を確保できます。
docker container prune の使い方
停止しているコンテナだけを削除したい場合は、以下のコマンドを使用します。
docker container pruneこのコマンドを実行すると、「本当に削除しますか？」という確認メッセージが表示されます。yを入力すると削除が始まります。
実行結果には、削除されたコンテナのID一覧とともに、確保できたディスク容量（Total reclaimed space）が表示されます。開発中に「コンテナ名が重複しています」というエラーが出た場合など、とりあえずコンテナだけを一掃したいときに便利です。
docker image prune の使い方
不要なイメージを削除するには、以下のコマンドを使います。
docker image pruneデフォルトでは、タグのない「ぶら下がりイメージ」のみが削除されます。もし、タグが付いていても現在使われていないイメージをすべて削除したい場合は、-aオプションを付けます。
docker image prune -aこれは非常に強力です。例えば、過去にプルしたものの、現在は使っていないubuntuやnodeなどのベースイメージもすべて消えます。次回使うときに再度ダウンロードが必要になるため、通信環境が悪い場所で実行する際は注意してください。
docker volume prune は慎重に扱う理由
ボリュームの削除は最も慎重に行う必要があります。
docker volume pruneこのコマンドは、どのコンテナからもマウントされていないボリュームをすべて削除します。Dockerにおける「ボリューム」は、データベースのデータやアップロードされたファイルなど、永続化が必要なデータを保存する場所です。
もし、誤って必要なデータベースのボリュームを削除してしまうと、データは二度と戻りません。コンテナを一時的に停止しているだけで、後でまた使う予定のボリュームであっても、このコマンドは容赦なく削除してしまいます。そのため、このコマンドだけは日常的なクリーンアップには含めず、明確な意図があるときだけ実行することをおすすめします。
docker system prune の一括削除
すべてをまとめてきれいにしたいときは、このコマンドの出番です。
docker system pruneこれを実行すると、停止中のコンテナ、未使用ネットワーク、ぶら下がりイメージがすべて削除されます。さらに、-aと--volumesオプションを組み合わせることで、Docker環境を「初期状態に近い形」までリセットできます。
docker system prune -a --volumesこれはディスク容量不足を解消する最終奥義ですが、影響範囲が広いため、実行前には深呼吸をして確認することをおすすめします。
docker pruneの注意点
便利なコマンドですが、リスクも伴います。失敗しないために知っておくべきポイントを押さえておきましょう。
二度と戻せない削除の仕組み
Dockerの削除コマンドは、OSのゴミ箱機能とは異なります。
削除を実行した瞬間、データはファイルシステムから完全に消去されます。「間違って消してしまったから元に戻す」という操作は不可能です。特にデータベースのデータや、コンテナ内で数時間かけて生成したログファイルなどが消えると、復旧作業に膨大な時間がかかります。削除コマンドを実行する際は、エンターキーを押す前に必ず指を止めて確認する癖をつけてください。
volumeが削除対象に含まれない理由
docker system prune（オプションなし）を実行しても、ボリュームは削除されません。
これはDockerの設計思想による安全装置です。ボリュームは「永続データ」を扱う場所であり、コンテナやイメージといった「一時的な実行環境」とは明確に区別されています。開発者が意図せず重要なデータを消してしまう事故を防ぐため、デフォルトでは削除対象から外されているのです。この仕様のおかげで、私たちは安心してpruneコマンドを利用できます。
--force を使うべきケースとNGケース
確認プロンプトをスキップする--force（または-f）オプションがあります。
これを使うべきケースは、スクリプトによる自動化を行う場合です。例えば、深夜に実行するクリーンアップスクリプトなどでは、ユーザーの入力を待つわけにはいかないため必須となります。
逆に、手動でコマンドを打つときに--forceを使うのはNGです。確認メッセージは、あなたの操作が正しいかを問いかける最後の砦（とりで）です。その安全装置を自ら解除してはいけません。わずか1秒の手間を惜しんで、数日分の作業データを失うリスクを冒す必要はないはずです。
docker pruneを安全に使う方法
リスクを最小限に抑えつつ、効果的にディスクを掃除するための運用テクニックを紹介します。
削除前に対象を確認するコマンド
いきなり削除するのではなく、何が消えるのかを事前に確認しましょう。多くのprune系コマンドには、--filterオプションなどが用意されていますが、一番確実なのは一覧表示コマンドで見ることです。
例えば、現在停止中のコンテナを確認するには以下のようにします。
docker ps -a --filter "status=exited"また、一部のバージョンや構成では、ドライラン（実際には消さずにシミュレーションする機能）に近い確認ができますが、Dockerには標準で明確な--dry-runフラグがすべてのpruneコマンドに実装されているわけではありません（buildxなど一部機能を除く）。そのため、まずは一覧表示コマンドで対象を目視確認するのが最も確実な安全策です。
volumeのバックアップ方法
ボリュームを削除する可能性がある場合、あるいは大規模な掃除をする前には、必ずバックアップを取りましょう。
最もシンプルなバックアップ方法は、一時的なコンテナを立ち上げて、ボリュームの内容をtarアーカイブとして書き出すことです。
docker run --rm -v ボリューム名:/data -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dataこのコマンドを実行すると、指定したボリュームの中身がbackup.tarとして現在のディレクトリに保存されます。これさえあれば、万が一データを消してしまっても、同じ手順で展開（解凍）することで元の状態に戻せます。
クリーンアップを自動化する手順
開発サーバーなどでは、定期的な自動削除を設定しておくと便利です。
Linux環境であれば、cronを使って定期実行を設定します。例えば、毎日深夜3時に不要なコンテナとイメージを削除するには、以下のような設定を追加します。
0 3 * * * docker system prune -fここで-fオプションが役立ちます。ただし、この設定を入れる場合は、必要なコンテナが停止したままになっていないか、運用ルールをしっかり定めておく必要があります。本番環境での自動化はリスクが高いため、まずは開発環境で試してから導入してください。
トラブルが起きたときの対処法
どれだけ注意していても、トラブルは起こり得ます。もしものときの対処法を知っておくことで、冷静に対応できます。
イメージが消えた／復元できない場合
必要なイメージを間違って消してしまった場合、焦る必要はありません。
Dockerイメージは基本的に、DockerfileやDocker Hubなどのレジストリから再取得可能です。docker pullコマンドを実行するか、docker buildコマンドを実行すれば、元通りになります。ただし、ビルドには時間がかかるため、急ぎの作業がある場合は待機時間が発生することになります。ローカルでしか作成していない独自のイメージだった場合は、ソースコードから再度ビルドしてください。
volume削除によるデータ消失ケース
これが最も深刻なケースです。バックアップがない状態でボリュームを削除してしまった場合、Dockerの機能だけでデータを復元することはできません。
OSレベルでのファイル復元ツールを使用するか、クラウド環境であればスナップショットからの復元を試みる必要があります。しかし、Dockerのデータ領域は複雑な構造をしていることが多く、復元成功率は高くありません。「ボリューム削除は不可逆」であることを肝に銘じ、日頃のバックアップ体制を見直すきっかけにしてください。
CI/CDで誤ってpruneされた場合の対応
CI/CDパイプラインの中でpruneを実行し、必要なビルドキャッシュまで消してしまうトラブルもよくあります。
この場合、次回のビルド時間が極端に長くなるという症状が出ます。対策としては、pruneコマンドにフィルターを適用することです。
docker image prune --filter "label!=keep"このように、削除したくないイメージやコンテナにはラベルを付与しておき、フィルター機能を使って削除対象から除外する設定をパイプラインに組み込みます。これにより、キャッシュ効率とディスク容量のバランスを保てます。
docker pruneによくある質問
最後に、よく寄せられる疑問について回答します。
実行しても容量が減らないのはなぜ？
docker system pruneを実行してもディスク使用量があまり変わらない場合、原因は主に2つあります。
1つ目は、削除対象外のリソースが容量を食っている場合です。特にボリュームや、稼働中のコンテナが出力し続けているログファイルはpruneでは消えません。/var/lib/docker/containers以下のログサイズを確認してみてください。
2つ目は、Dockerが使用しているストレージドライバの仕組み（overlay2など）により、OS上での空き容量反映にラグがある、あるいはファイルシステム自体の断片化が起きている場合です。この場合は、Dockerサービス自体を再起動することで解消することがあります。
pruneしても動作に影響は出ない？
基本的には出ません。削除されるのは「現在使われていないもの」だけだからです。
ただし、「今は停止しているが、明日起動する予定のデータベースコンテナ」などは削除されてしまいます。コンテナは「使い捨て」という思想で設計されていますが、データや設定をコンテナ内部に直接書き込んでいるような（推奨されない）使い方をしている場合は、設定が初期化されてしまうリスクがあります。正しいDockerの作法で運用していれば、恐れることはありません。
本番環境で使っても大丈夫？
本番環境での実行は可能ですが、細心の注意が必要です。
高負荷時にpruneを実行すると、削除処理のためにディスクI/Oが上昇し、サービスの応答速度が低下する可能性があります。また、万が一のオペレーションミスがサービス停止に直結します。本番環境で実行する場合は、アクセスが少ない時間帯を選び、かつsystem prune -aのような広範囲な削除ではなく、対象を絞ったコマンドを実行するのが鉄則です。
まとめ：docker pruneを使うメリットと安全な運用ポイント
Dockerのディスク容量不足は、docker pruneを適切に使うことで確実に解決できます。
理由は、このコマンドが不要なリソースを正確に特定し、手動では不可能なレベルでクリーンアップを行ってくれるからです。
実際に私も、このコマンドの定期実行とバックアップ運用を組み合わせることで、ストレージ警告に怯（おび）えることのない快適なインフラ環境を維持しています。
最後に、安全運用のためのポイントを整理します。
- まずは確認：削除前に何が消えるかを理解する
- ボリュームは保護：重要なデータはバックアップを取るまで消さない
- 自動化は慎重に：開発環境で十分にテストしてから導入する
