【初心者向け】docker image pruneとは？使い方をわかりやすく解説
Dockerを学び始め、docker build や docker run を使ってコンテナを動かす楽しさに目覚めたあなた。しかし、しばらく使っていると、ふと気づくことがあります。
「あれ…？なんだかPCの動作が重い…」
「Cドライブの空き容量が、いつの間にか真っ赤になっている！」
その原因、もしかしたらDockerが溜め込んだ「不要なイメージ」かもしれません。
Dockerは非常に便利なツールですが、意識せずに使っていると、ビルドの過程で生まれた中間イメージや、古いバージョンのイメージがどんどん蓄積され、貴重なディスクスペースを圧迫していきます。数十GB、場合によっては数百GBもの容量が、知らず知らずのうちに消費されていることも珍しくありません。
この記事は、そんなDocker初心者が直面しがちな「ディスク容量問題」を解決するための、いわば「Dockerのお掃除マニュアル」です。
この記事を読めば、以下のことがわかります。
- そもそも、なぜDockerイメージは勝手に増えてしまうのか？
- 不要なイメージを安全かつ効率的に削除する魔法のコマンド
docker image pruneとは何か？ - 基本的な使い方から、
-aや--filterなどの強力なオプションを使いこなす方法 - イメージだけでなく、コンテナやボリュームも含めたDockerシステム全体を大掃除する方法
この記事を最後まで読めば、あなたはもうディスク容量に怯えることなく、クリーンで快適なDocker環境を維持できるようになります。それでは、さっそくDockerのお掃除術をマスターしていきましょう！
第1章: なぜDockerイメージの削除が必要なのか？
docker image prune の使い方を学ぶ前に、まずは「なぜイメージの削除が必要になるのか」という根本的な理由を理解しておくことが重要です。原因がわかれば、対策もより深く理解できます。
Dockerイメージの正体とは？
Dockerイメージとは一体何でしょうか？一言でいえば、「アプリケーションとその実行環境をひとまとめにした、動かないテンプレート」です。
料理に例えるなら、「カレーライスのレシピと、必要なスパイスや具材一式が冷凍パックになったもの」を想像してみてください。この冷凍パックがDockerイメージです。このパックを温めてお皿に盛り付ければ、いつでも誰でも同じ味のカレーライス（＝コンテナ）を食べることができます。
このイメージは、いくつかの重要な特徴を持っています。
- レイヤー構造: Dockerイメージは、一枚岩の巨大なファイルではありません。
Dockerfileという設計図に書かれた命令（FROM、RUN、COPYなど）が、それぞれ「層（レイヤー）」として積み重なってできています。玉ねぎの皮のように、薄い層が何枚も重なっているイメージです。この仕組みにより、一度作ったレイヤーはキャッシュされ、次回のビルドが高速になるというメリットがあります。 - 読み取り専用 (Read-only): イメージ自体は変更することができません。先程の冷凍パックの例で言えば、パックの中身を直接書き換えることはできませんよね。コンテナを起動すると、この読み取り専用のイメージの上に、書き込み可能な新しいレイヤーが追加され、そこでアプリケーションが動作します。
この「レイヤー構造」と「読み取り専用」という性質が、イメージが増えていく原因と深く関わっています。
イメージがどんどん増えていく理由
では、なぜ私たちの知らないうちにイメージは増殖していくのでしょうか。主な原因は以下の3つです。
1. docker build の繰り返し
アプリケーションを開発していると、ソースコードを少し修正しては動作確認、というサイクルを何度も繰り返します。そのたびに docker build コマンドを実行することになります。
“`bash
アプリケーションのイメージをビルドする
docker build -t myapp:latest .
“`
ここで重要なのは、docker build を実行するたびに、原則として新しいイメージが作成されるという点です。たとえ Dockerfile の内容が同じでも、ソースコードが1行でも変更されていれば、その変更を含む新しいレイヤーが作られ、結果として新しいIDを持つイメージが誕生します。
myapp:latest というタグは、常に最新のイメージに付け替えられます。すると、一つ前に myapp:latest だった古いイメージは、タグを失ってしまいます。このようなタグがない状態のイメージを「dangling image（ダングリング・イメージ）」と呼びます。「dangling」とは「宙ぶらりんの」「ぶら下がっている」という意味で、まさに誰からも名前（タグ）で呼ばれなくなった、孤立したイメージのことを指します。
これが、不要なイメージが溜まっていく最も一般的な原因です。
2. docker pull によるバージョンの更新
公式のイメージ、例えば nginx や ubuntu などを使うことも多いでしょう。これらのイメージは頻繁にアップデートされます。
ある日、あなたは nginx の最新版を使おうとして、以下のコマンドを実行します。
bash
docker pull nginx:latest
もし、あなたのローカル環境に既に nginx:latest が存在していて、Docker Hub側で新しいバージ عَョンがリリースされていた場合、Dockerは新しいバージョンのイメージをダウンロードしてきます。そして、nginx:latest のタグを新しいイメージに付け替えます。
この時、古いバージョンの nginx イメージはどうなるでしょうか？ docker build の時と同じです。タグを失い、dangling imageとなってローカルに残り続けるのです。
3. タグ付け運用の結果
開発の現場では、バージョン管理のために、latest だけでなく、バージョン番号や機能名でタグを付けることがよくあります。
“`bash
docker build -t myapp:v1.0 .
…開発を進める…
docker build -t myapp:v1.1 .
…さらに機能追加…
docker build -t myapp:feature-x .
“`
このようにビルドしていくと、myapp:v1.0、myapp:v1.1、myapp:feature-x といったイメージがローカルに溜まっていきます。v1.1 が完成すれば v1.0 はもう使わないかもしれませんし、feature-x がマージされれば、そのイメージも不要になるかもしれません。しかし、これらはdangling imageではない（タグが付いている）ため、明示的に削除しない限り、ずっと残り続けます。
ディスク容量を圧迫する深刻な問題
これらの理由で増え続けたイメージは、やがてあなたのディスク容量を深刻なレベルで圧迫し始めます。
Dockerイメージは、便利な反面、サイズが大きいものが多いです。OSのベースイメージだけでも数百MB、開発に必要なライブラリやツールをインストールしていくと、1つのイメージが数GBに達することもザラです。
これが10個、20個と溜まっていくとどうなるでしょう？あっという間に数十GBのディスクスペースが消費されてしまいます。
ディスクの空き容量がなくなると、以下のような問題が発生します。
- 新しいイメージのビルドが失敗する (
no space left on device) - 新しいコンテナを起動できない
- PC全体のパフォーマンスが低下する
- OSのアップデートなど、他の作業もできなくなる
こうなってしまう前に、不要なイメージを定期的に「お掃除」する必要があるのです。そして、そのお掃除に絶大な効果を発揮するのが、次章から解説する docker image prune コマンドなのです。
第2章: docker image prune とは何か？
さて、不要なイメージがディスクを圧迫する原因がわかったところで、いよいよ本日の主役、docker image prune の登場です。このコマンドが一体何者なのか、その役割と安全性を詳しく見ていきましょう。
prune という単語の意味
まず、コマンド名にもなっている prune という英単語の意味を知っておくと、コマンドの役割をイメージしやすくなります。
prune (プルーン)
* 動詞: (樹木の枝などを) 刈り込む、剪定(せんてい)する
* 名詞: (乾燥させた) プラム
ガーデニングで、伸びすぎた枝や枯れた枝をハサミで切り落として、木の形を整え、風通しを良くする作業がありますね。あれが「剪定(prune)」です。
Dockerにおける prune コマンド群は、まさにこの剪定作業のように、Dockerシステム内に溜まった不要なリソース（イメージ、コンテナ、ボリューム、ネットワークなど）を「刈り込んで」整理整頓し、システムを健全な状態に保つためのものです。
docker image prune は、その中でも特に「イメージ」の剪定に特化したコマンドというわけです。
docker image prune の核心的な役割
docker image prune の役割を、一言で、かつ正確に表現するならば、こうなります。
「どのコンテナからも現在参照されていない、宙ぶらりんの(dangling)イメージを、まとめて一括で削除するコマンド」
ここで重要なポイントが2つあります。
- dangling image を削除する: 第1章で説明した、タグが
<none>:<none>になっている「宙ぶらりんイメージ」が、このコマンドの主なターゲットです。docker buildを繰り返すうちに量産されてしまった、名前のない不要なイメージたちを一掃してくれます。 - どのコンテナからも参照されていない: たとえdangling imageであっても、もしそのイメージを使っているコンテナが（たとえ停止中であっても）存在する場合、そのイメージは削除されません。Dockerは、コンテナが依存しているイメージを勝手に削除してしまわないように、安全に配慮してくれます。
実際に docker images コマンドでイメージ一覧を見てみましょう。
bash
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp latest c9b54b0b1464 5 minutes ago 950MB
<none> <none> a1b2c3d4e5f6 15 minutes ago 945MB <-- これがdangling image
<none> <none> f9e8d7c6b5a4 30 minutes ago 945MB <-- これもdangling image
ubuntu 22.04 1234abcd5678 2 weeks ago 77.8MB
この例では、REPOSITORY と TAG が <none> になっている2つのイメージがdangling imageです。docker image prune を実行すると、これら2つが削除対象となります。一方、myapp:latest や ubuntu:22.04 のように、ちゃんとタグが付いているイメージは、デフォルトの docker image prune では削除されません。
docker image prune はなぜ安全なのか？
Docker初心者が最も恐れるのは、「間違えて必要なものを消してしまうこと」ではないでしょうか。その点、docker image prune は、デフォルトの挙動が非常に慎重に設計されているため、初心者が最初に試すクリーンアップコマンドとして最適です。
安全と言える理由は以下の通りです。
- 削除対象が限定的: 上述の通り、削除するのは基本的に「dangling image」のみです。あなたが意図してタグを付けたイメージ (
myapp:v1.0など) や、現在利用中のコンテナが参照しているイメージには手を出しません。 - 事前の確認プロンプト: コマンドを実行すると、いきなり削除が始まるわけではありません。
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N]
（警告！これにより、すべてのdanglingイメージが削除されます。続行しますか？）
という確認メッセージが表示されます。ここでyを入力しない限り、何も起こりません。この一手間が、誤操作を防ぐためのフェイルセーフとして機能します。
これらの特徴により、docker image prune は「とりあえず実行しても大きな問題は起きにくい、安全なコマンド」と言えます。開発中に「ちょっとビルドを繰り返しすぎたかな？」と感じたら、気軽にこのコマンドを実行して、こまめに不要なイメージを掃除する習慣をつけるのがおすすめです。
第3章: docker image prune の基本的な使い方
コマンドの役割と安全性が理解できたところで、いよいよ実際に docker image prune を使ってみましょう。ここでは、コマンド実行前の準備から、実行、そして結果の確認までをステップバイステップで解説します。
Step 1: 準備 – 削除対象のイメージを確認する
何事も、まずは現状把握から。いきなり削除コマンドを叩くのではなく、これから何が削除されるのかを事前に確認する癖をつけましょう。これはDocker運用における非常に良い習慣です。
dangling image、つまり docker image prune の削除対象となるイメージを確認するには、docker images コマンドに --filter (または -f) オプションを付けて実行します。
bash
docker images --filter "dangling=true"
あるいは、短縮して次のように書くこともできます。
bash
docker images -f "dangling=true"
このコマンドは、「dangling状態（dangling=true）のイメージだけを表示して」という意味になります。
実行例:
bash
$ docker images -f "dangling=true"
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> a1b2c3d4e5f6 25 minutes ago 945MB
<none> <none> f9e8d7c6b5a4 40 minutes ago 945MB
もし、このコマンドを実行して何も表示されなければ、あなたの環境にはdangling imageが存在しないということです。その場合は、docker image prune を実行しても何も削除されません。
実行結果を見て、「うん、ここに表示されているイメージは確かに不要だな」と確認できたら、次のステップに進みます。
Step 2: コマンドの実行
いよいよ docker image prune を実行します。ターミナル（またはコマンドプロンプト）で、以下のコマンドを入力してください。
bash
docker image prune
コマンドを実行すると、前述の通り、確認メッセージが表示されます。
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N]
内容を確認し、問題なければ y を入力して Enter キーを押します。削除処理が実行されます。
Step 3: 実行結果の確認
削除が完了すると、どのような処理が行われたかの結果が表示されます。
実行結果の例:
“`
Deleted Images:
deleted: sha256:a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6
deleted: sha256:f9e8d7c6b5a4f9e8d7c6b5a4f9e8d7c6b5a4f9e8d7c6b5a4f9e8d7c6b5a4
Total reclaimed space: 1.89GB
“`
この結果から、以下のことがわかります。
Deleted Images:: 削除されたイメージのリストです。イメージID（ここではsha256:から始まるハッシュ値）が表示されます。Total reclaimed space:: 解放された合計ディスク容量です。この例では、約1.89GBのスペースが空いたことがわかります。この数値を見る瞬間は、なかなか爽快です。
本当にdangling imageが消えたか、念のため再度確認してみましょう。
bash
$ docker images -f "dangling=true"
REPOSITORY TAG IMAGE ID CREATED SIZE
$
今度は何も表示されません。無事にdangling imageが一掃されたことが確認できました。
もちろん、docker images で全イメージ一覧を表示しても、<none>:<none> の行が消えていることがわかります。
bash
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp latest c9b54b0b1464 15 minutes ago 950MB
ubuntu 22.04 1234abcd5678 2 weeks ago 77.8MB
スッキリしましたね！これが docker image prune の最も基本的な使い方です。
Tip: 確認メッセージをスキップする -f (--force) オプション
毎回 y を入力するのが少し手間に感じるかもしれません。特に、シェルスクリプトなどでクリーンアップ処理を自動化したい場合には、対話的な確認は邪魔になります。
そのような場合は、-f または --force オプションを使います。
bash
docker image prune -f
このコマンドは、確認メッセージを表示せずに、即座にdangling imageの削除を実行します。
ただし、手動で実行する際は、このオプションの利用は慎重になるべきです。たとえ安全なコマンドだとしても、「何が起きるか分かった上で、自分の意思で実行する」という意識を持つために、最初のうちは確認プロンプトに y と答える習慣をつけておくことをお勧めします。
第4章: もっと強力に削除！-a (--all) オプションの威力
基本的な docker image prune でdangling imageを掃除できるようになり、気分もディスクもスッキリしたことでしょう。しかし、しばらく開発を続けていると、また新たな問題に気づくかもしれません。
「dangling imageは消したはずなのに、docker images のリストはまだ長いままだし、ディスク容量もあまり改善しない…」
それもそのはず。第1章で触れたように、不要なイメージはdangling imageだけではないからです。過去に開発で使っていた myapp:v1.2 や myapp-fix-bug のような「タグ付きの古いイメージ」は、通常の prune では削除されません。
これらを含めて、もっと大胆に、そして強力にお掃除したい。そんな時に登場するのが -a (または --all) オプションです。
-a (--all) オプションの役割
docker image prune -a は、通常の prune とは削除の基準が異なります。
docker image prune(通常):
dangling (タグ無し) のイメージを削除する。docker image prune -a(--all):
どのコンテナからも使われていないイメージを、タグの有無にかかわらず全て削除する。
これが決定的な違いです。「宙ぶらりんかどうか」ではなく、「誰からも必要とされていないかどうか」を基準に削除するのです。
これにより、以下のようなイメージも削除対象に含まれるようになります。
- 過去のバージョンタグが付いたイメージ (例:
myapp:v1.0,myapp:v1.1) - 開発途中で使ったフィーチャーブランチ名のタグが付いたイメージ (例:
myapp-feature-login) - 現在は使っていないベースイメージ (例: 昔
ubuntu:20.04を使っていたが、今は22.04に移行した、など)
docker build と docker run を繰り返す開発スタイルでは、停止したコンテナが古いイメージを参照し続けていることが多いため、docker image prune -a を実行する前に、不要なコンテナを削除 (docker container prune や docker rm) しておくと、より多くのイメージが削除対象になり、効果が高まります。(このあたりは第6章の docker system prune で詳しく解説します)
-a オプションの使い方と注意点
使い方は、prune コマンドに -a オプションを付けるだけです。
bash
docker image prune -a
実行すると、表示される警告メッセージも通常とは少し異なります。
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N]
（警告！これにより、コンテナに関連付けられていない全てのイメージが削除されます。続行しますか？）
「dangling」という単語が消え、「コンテナに関連付けられていない全てのイメージ」という、より強力な表現になっていることに注目してください。y を押して実行すると、未使用のイメージがごっそりと削除され、解放されるディスク容量も通常の prune より格段に大きくなる可能性があります。
実行前の最重要注意点
-a オプションは非常に強力な反面、意図しないイメージまで削除してしまうリスクも伴います。
例えば、あなたが Dockerfile で FROM ubuntu:22.04 のようにベースイメージを指定しているとします。この ubuntu:22.04 イメージは、イメージをビルドするためには必要ですが、ubuntu:22.04 から直接コンテナを起動していなければ、「未使用のイメージ」と見なされ、docker image prune -a によって削除されてしまいます。
削除されても大丈夫？
はい、基本的には大丈夫です。もし削除されてしまっても、次に docker build を実行した際に、Dockerは ubuntu:22.04 イメージがローカルにないことを検知し、自動的にDocker Hubから pull し直してくれます。
ただし、インターネット接続がない環境ではビルドできなくなりますし、イメージサイズが大きい場合は再ダウンロードに時間がかかり、開発のテンポが少し悪くなるかもしれません。
推奨される運用フロー
docker ps -aでコンテナ一覧を確認し、不要な停止中コンテナを削除する。docker imagesでイメージ一覧を眺め、「このイメージは消えても、またビルド/プルすればいいな」「このイメージは残しておきたいな」と頭の中で整理する。docker image prune -aを実行して、未使用イメージを一掃する。
このひと手間をかけることで、「思ったより消えすぎた！」という事態を防ぎ、安心して強力なクリーンアップの恩恵を受けることができます。
実践的なシナリオ
docker image prune -a は、日常的に頻繁に使うコマンドというよりは、定期的な「大掃除」に最適です。
- 週末や週の終わりに: 一週間の開発で溜まった不要なイメージを整理する。
- プロジェクトの一区切りに: ある機能の開発が完了し、関連するイメージが不要になったタイミングで実行する。
- ディスク容量が気になり始めたら: まずは通常の
pruneを試し、それでも不十分な場合に-a付きで実行する。
このように、コマンドの特性を理解し、適切なタイミングで使い分けることが、賢いDockerユーザーへの第一歩です。
第5章: 特定の条件で削除する --filter オプション
docker image prune と -a オプションをマスターすれば、ほとんどのケースでイメージの整理は事足ります。しかし、もっと高度で、もっときめ細やかな制御をしたい場面も出てくるでしょう。
「24時間以上使っていない、古いイメージだけを掃除したい」
「CI/CDで自動生成されたテスト用のイメージだけを削除したい」
そんなわがままな（しかし非常に実用的な）要求に応えてくれるのが --filter オプションです。このオプションを使うことで、削除対象となるイメージを、まるでデータベースを検索するように、特定の条件で絞り込むことができます。
--filter オプションの概要
--filter オプションは、key=value の形式で条件を指定します。
bash
docker image prune --filter "key=value"
このフィルターは複数指定することも可能で、その場合はAND条件として機能します。「条件A」と「条件B」の両方を満たすものだけが対象になります。
ここでは、特に便利な2つのフィルター until と label を紹介します。
1. until フィルター: 時間で絞り込む
until フィルターは、「指定したタイムスタンプよりも前に作成された」イメージを削除対象にします。これにより、「古いイメージだけを掃除する」という、非常にスマートな運用が可能になります。
タイムスタンプは、Unixタイムスタンプのほか、24h (24時間) や 10m (10分) のような人間が読みやすい形式で指定できます。
使用例1: 24時間以上前のdangling imageを削除
bash
docker image prune --filter "until=24h"
このコマンドは、通常の prune (dangling imageが対象) に、「作成から24時間以上経過している」という条件を追加します。昨日ビルドしたばかりのdangling imageは残しつつ、それより古いものだけを掃除できます。
使用例2: 1週間(168時間)以上前の未使用イメージを全て削除
-a オプションと組み合わせると、さらに強力になります。
bash
docker image prune -a --filter "until=168h"
これは、「作成から1週間以上経過しており、かつ、どのコンテナからも使われていないイメージを、タグの有無にかかわらず全て削除する」というコマンドです。
このコマンドは、定期的な自動クリーンアップスクリプトに組み込むのに最適です。例えば、毎週月曜の早朝にこのコマンドを自動実行するように設定しておけば、開発者が意識することなく、常にDocker環境をクリーンに保つことができます。直近1週間で使ったイメージは残るため、開発効率を損なうこともありません。
2. label フィルター: ラベルで絞り込む
label フィルターは、イメージに付けられた「ラベル」を基に削除対象を絞り込みます。
Dockerイメージには、Dockerfile の LABEL 命令を使って、任意のキーと値のペア（メタデータ）を付与することができます。
Dockerfileの例:
“`dockerfile
FROM ubuntu:22.04
ビルドステージや管理者などの情報をラベルとして付与
LABEL stage=”test”
LABEL maintainer=”[email protected]”
LABEL project.version=”1.0″
“`
このようにラベルを付けておくことで、イメージの管理が格段にしやすくなります。そして、prune コマンドでこのラベルを利用できるのです。
使用例1: stage=test ラベルが付いた未使用イメージを削除
CI/CDパイプラインで、テスト実行のためだけに一時的なイメージをビルドすることがよくあります。これらのイメージには stage=test のようなラベルを付けておき、テスト完了後に一括でクリーンアップします。
bash
docker image prune -a --filter "label=stage=test"
使用例2: 特定のラベルが付いていないイメージだけを削除
逆に、「このイメージは重要だから絶対に消したくない」という場合もあります。そのようなイメージには、目印となるラベルを付けておき、それを除外条件とすることができます。label!=value のように != を使います。
例えば、preserve=true (preserve=保存する) というラベルを付けたイメージは削除しないようにしてみましょう。
bash
docker image prune -a --filter "label!=preserve=true"
このコマンドは、「preserve=true というラベルが付いていない、未使用のイメージ」を全て削除します。これにより、重要なベースイメージや、頻繁に使うデバッグ用イメージなどを、prune の対象から安全に除外できます。
filter の組み合わせで、さらに高度な制御を
複数の --filter を組み合わせることで、より複雑な条件を指定できます。
例: 作成から10日以上経過していて、かつ、保存ラベルが付いていない、未使用のイメージを全て削除
bash
docker image prune -a --filter "until=240h" --filter "label!=preserve=true"
ここまで使いこなせれば、あなたはもう単なるDockerユーザーではなく、Docker環境を自在に管理する「Dockerマイスター」と言えるでしょう。--filter は、あなたのイメージ管理戦略を、一段上のレベルへと引き上げてくれる強力な武器なのです。
第6章: イメージだけじゃない！Dockerシステム全体のお掃除 docker system prune
ここまで、docker image prune を使ったイメージの掃除方法を徹底的に解説してきました。しかし、ディスク容量を消費している犯人は、本当にイメージだけでしょうか？
実は、Docker環境にはイメージ以外にも、知らず知らずのうちに溜まっていく「ゴミ」が存在します。
- 停止したコンテナ (
Exited状態のコンテナ):docker runで一度起動したコンテナは、処理が終わると停止しますが、削除しない限り残り続けます。これらも微量ながらディスクを消費し、docker ps -aの一覧を長くする原因になります。 - 未使用のネットワーク: コンテナを連携させるために作成したカスタムネットワークは、コンテナを削除しても自動では消えずに残ることがあります。
- 未使用のボリューム: データベースのデータなどを永続化するために使われるボリュームは、最も注意が必要な存在です。コンテナを削除しても、データを保護するためにボリュームは意図的に残されます。しかし、本当に不要になったボリュームが溜まっていくと、大きな容量を占めることがあります。
- ビルドキャッシュ:
docker buildを高速化するためのキャッシュも、ディスク容量を消費します。
これらの「イメージ以外の不要物」もまとめて一掃してくれる、究極のお掃除コマンドが docker system prune です。
docker system prune の役割
docker system prune は、その名の通り、Dockerの「システム」全体を対象に剪定（prune）を行います。このコマンド一発で、以下のものがクリーンアップされます。
- 停止している全てのコンテナ
- どのコンテナからも使われていない全てのネットワーク
- 全てのdanglingイメージ
- 全てのビルドキャッシュ
注目すべきは、docker image prune の機能（dangling imageの削除）を内包している点です。イメージだけでなく、停止したコンテナや不要なネットワークも同時に掃除してくれるため、非常に効率的です。
docker system prune の使い方と注意点
使い方は非常にシンプルです。
bash
docker system prune
実行すると、削除対象となるリソースの種類がリストアップされた、物々しい警告メッセージが表示されます。
“`
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all dangling images
– all build cache
Are you sure you want to continue? [y/N]
“`
y を押して実行すると、これらのリソースが一括で削除され、多くの場合、かなりのディスク容量が解放されます。
注意点: このコマンドは「停止しているコンテナを全て削除」します。もし「後でログを確認しよう」とか「ちょっと再起動して試したい」と思っていた停止コンテナがあったとしても、問答無用で削除されてしまいます。実行する前に、必ず docker ps -a で停止中のコンテナ一覧を確認し、残しておきたいものがないかチェックする習慣をつけましょう。
さらに強力なオプション: -a と --volumes
docker system prune にも、さらに強力なオプションが存在します。
docker system prune -a
image prune の場合と同様に、-a (--all) オプションは削除対象を広げます。
docker system prune -a は、通常の system prune の機能に加えて、
- 未使用のイメージ（danglingだけでなく、タグ付きも含む）を全て削除
します。つまり、docker image prune -a の機能も取り込んだ、さらに強力なコマンドです。これも同様に、停止コンテナが削除された結果、未使用と見なされるイメージが増えるため、非常に高い効果が期待できます。
docker system prune --volumes （最重要注意！）
これが、Dockerのお掃除コマンドの中で、最も強力かつ、最も危険なオプションです。
docker system prune --volumes は、system prune の機能に加えて、
- どのコンテナからも使われていないボリュームを全て削除
します。
なぜ危険なのでしょうか？ボリュームは、アプリケーションが生成する永続化データ（データベースファイル、ユーザーがアップロードしたファイルなど）を保存するために使われるからです。つまり、このオプションはデータを削除する可能性があるのです。
もちろん、「どのコンテナからも使われていない」ボリュームだけが対象なので、現在稼働中のコンテナが使っているデータが消えることはありません。しかし、開発環境で一時的にコンテナを削除しただけで、データは後で使うつもりだった、というようなケースで、意図せずデータを失ってしまうリスクがあります。
このコマンドを実行する前には、必ず docker volume ls コマンドでボリューム一覧を確認し、そこに表示されているものが本当に不要なものか、一つ一つ確認してください。 データの消失は、イメージの再ビルドのように簡単には取り返しがつきません。
どの prune コマンドをいつ使えばいいか？
ここまで4つの主要な prune コマンド（とオプション）を紹介しました。最後に、それぞれの使い分けの指針をまとめます。
| コマンド | 目的 | タイミング | 安全性 |
|---|---|---|---|
docker image prune |
日常的な軽い掃除 dangling imageの削除 |
開発中、buildを繰り返した後など、気軽に |
★★★★★ (高) |
docker image prune -a |
定期的な中掃除 未使用のタグ付きイメージも整理 |
プロジェクトの一区切り、週末など | ★★★★☆ (中高) |
docker system prune |
徹底的な大掃除 停止コンテナやキャッシュも一掃 |
ディスクが逼迫した時、クリーンな状態にしたい時 | ★★★☆☆ (中) |
docker system prune --volumes |
環境のリセット（最終手段） 未使用ボリューム（データ）も削除 |
環境を初期化したい時。データ消失リスクを理解した上で | ★☆☆☆☆ (低) |
この表を参考に、自分の目的と状況に合わせて、最適な prune コマンドを選択してください。
第7章: よくある質問 (FAQ)
ここでは、docker image prune に関する初心者が抱きがちな疑問について、Q&A形式でお答えします。
Q1: docker image prune で必要なイメージまで消してしまいました。元に戻せますか？
A: 残念ながら、一度 prune で削除したイメージを直接元に戻す（undeleteする）機能はありません。しかし、パニックになる必要はありません。Dockerイメージの多くは「再生成可能」です。
- Docker Hubなどの公式イメージの場合:
ubuntu:22.04やnginx:latestのようなイメージであれば、docker pull ubuntu:22.04のように、docker pullコマンドで再度ダウンロードすれば元通りになります。 - 自分でビルドしたイメージの場合:
Dockerfileとソースコードが手元にあれば、docker buildコマンドを実行すれば、全く同じイメージを再作成できます。
重要なのは、イメージそのものではなく、イメージを生成するための Dockerfile やソースコードをバージョン管理しておくことです。それさえあれば、イメージはいつでも復元可能です。
Q2: docker rmi $(docker images -f "dangling=true" -q) というコマンドをネットで見かけました。これと docker image prune は何が違うのですか？
A: 素晴らしい質問です。この2つのコマンドが実行する内容は、基本的に同じです。どちらも「dangling imageを全て削除する」という処理を行います。
docker rmi $(docker images -f "dangling=true" -q):
これは、古くから使われている方法です。docker images -f "dangling=true" -qでdangling imageのID一覧を取得し、それをdocker rmiコマンド（イメージを削除するコマンド）に渡して、一つずつ削除しています。シェルのコマンド置換機能を使ったテクニックです。docker image prune:
これは、Dockerが公式に提供している、より新しく、より洗練された専用コマンドです。
では、なぜ docker image prune を使うべきなのでしょうか？
- 意図が明確: コマンド名が
image prune（イメージの剪定）なので、何をするかが一目瞭然です。 - クロスプラットフォーム: WindowsのPowerShellなど、一部の環境では
$(...)のようなコマンド置換がうまく機能しない場合があります。docker image pruneはDocker自体のコマンドなので、どのOSでも同じように動作します。 - シンプル: タイプする文字数が少なく、覚えやすいです。
結論として、現在では docker image prune を使うことが強く推奨されます。
Q3: docker image prune を実行しても、あまり容量が空きません。なぜですか？
A: いくつかの理由が考えられます。
- そもそもdangling imageが少なかった:
docker image pruneはdangling imageしか削除しません。もし、ディスクを圧迫している原因がタグ付きの未使用イメージであれば、docker image prune -aを試す必要があります。 - 原因はイメージではなかった: ディスク容量を圧迫している真犯人が、イメージではなく、停止したコンテナ、ビルドキャッシュ、あるいは未使用のボリュームである可能性があります。この場合は、
docker system pruneを試してみてください。解放される容量に驚くかもしれません。 - イメージが（停止した）コンテナから参照されていた: たとえdangling imageであっても、そのイメージを使っているコンテナが1つでも存在すれば（停止していても）、
pruneの対象外となります。まずはdocker container pruneやdocker system pruneで不要なコンテナを掃除してから、再度docker image prune -aを実行すると、多くのイメージが削除できるようになります。
Q4: docker image prune は安全ですか？本番環境で実行しても大丈夫ですか？
A: デフォルトの docker image prune は、dangling imageのみを削除するため、比較的安全なコマンドと言えます。稼働中のコンテナが使っているイメージに影響を与えることはありません。
しかし、「本番環境」での操作は、常に最大限の注意を払うべきです。
-aオプションは特に注意: 本番環境でdocker image prune -aを実行すると、現在稼働中のコンテナが使っていないイメージは全て削除されます。もし、フェイルオーバーやスケールアウトのために待機させているイメージがあった場合、それも削除される可能性があります。いざという時にイメージの再ダウンロードが必要になり、復旧が遅れるリスクを考慮する必要があります。- 実行タイミング: もし実行するのであれば、システムの負荷が低い時間帯（深夜など）に行うのが賢明です。
- 事前確認: 実行前に、どのようなイメージが削除対象になるかを
--filterなどを使って確認し、チーム内で合意を取ることが重要です。
基本的には、本番環境でのクリーンアップは、CI/CDプロセスに組み込むなど、自動化され、テストされた手順で行うのが理想です。手動で安易に prune コマンドを実行するのは避けた方が良いでしょう。
まとめ
長い旅路でしたが、これであなたはDockerのディスク容量問題に立ち向かうための強力な知識とツールを手に入れました。
最後に、この記事で学んだ重要なポイントを振り返りましょう。
- イメージは増えるもの:
docker buildやdocker pullを繰り返すことで、タグのない「dangling image」や、古いバージョンのタグ付きイメージが自然と溜まっていく。 docker image pruneは基本の「き」: dangling imageを安全かつ簡単に削除できる、初心者にとって最初の味方となるコマンド。docker image prune -aは強力な味方: タグの有無にかかわらず、どのコンテナからも使われていないイメージを一掃し、大幅なディスクスペースを解放してくれる。--filterは上級者の武器:untilやlabelといった条件で削除対象を細かく制御し、スマートなイメージ管理を実現する。docker system pruneは最終兵器: イメージだけでなく、停止コンテナやネットワーク、キャッシュなど、システム全体をまとめて大掃除してくれる。ただし、--volumesオプションの使用はデータ消失のリスクを伴うため、最大限の注意が必要。
Dockerは、現代のアプリケーション開発に欠かせない素晴らしい技術です。しかし、その力を最大限に引き出すためには、ただ使うだけでなく、日々のメンテナンスも重要になります。
今日学んだ prune コマンドをあなたの武器に加え、定期的にDocker環境の「剪定」を行う習慣を身につけてください。そうすれば、ディスク容量の心配から解放され、よりクリーンで、より快適なDockerライフを送ることができるはずです。
Happy Dockering