不要なDockerイメージを削除！docker image prune徹底解説

はじめに：Dockerイメージ管理の重要性

Dockerはコンテナ技術のデファクトスタンダードとして、開発から本番環境まで幅広く活用されています。Dockerを利用する上で避けて通れないのが、Dockerイメージの管理です。Dockerイメージはコンテナの実行に必要なすべての要素（コード、ランタイム、システムツール、ライブラリ、設定ファイルなど）を含む静的なファイルシステムのスナップショットであり、Dockerコンテナのビルドやデプロイの基盤となります。

開発やCI/CDプロセスの中で、新しいイメージが頻繁にビルドされたり、様々なバージョンのイメージがダウンロードされたりします。これにより、ローカルのDocker環境やサーバー上には、使われなくなった古いイメージや、ビルド途中で生成された中間イメージなどが蓄積されていきます。これらの不要なイメージを放置しておくと、いくつかの問題が発生します。

ディスク容量の圧迫: Dockerイメージはサイズが大きくなることが多く、不要なイメージが溜まるとディスク容量を急速に消費します。これは特にストレージ容量が限られている開発マシンや、多くのイメージを扱うCI/CDサーバー、本番環境のホストマシンなどで深刻な問題となります。ディスク容量不足は、新しいイメージのダウンロードやビルドの失敗、さらにはシステム全体のパフォーマンス低下や不安定化を引き起こす可能性があります。
セキュリティリスク: 古いイメージや、脆弱性を含む可能性のあるイメージを放置することは、セキュリティリスクを高める可能性があります。使わないイメージであっても、もしコンテナが実行された場合などに古いソフトウェアが動作するリスクがあります。
混乱と管理の複雑化: 多数のイメージがリストに表示されると、現在使用しているイメージや必要なイメージを特定しにくくなります。これは管理ミスや誤操作の原因となり得ます。

これらの問題を防ぎ、Docker環境を効率的に運用するためには、不要になったDockerイメージを定期的にクリーンアップすることが不可欠です。Dockerはイメージを削除するためのいくつかのコマンドを提供していますが、中でも効率的かつ安全に不要なイメージを一括削除できるのが、今回詳しく解説するdocker image pruneコマンドです。

この記事では、docker image pruneコマンドの基本的な使い方から、強力なオプション、具体的な実行例、さらには削除されるイメージの種類や削除されないイメージについて、詳細かつ網羅的に解説します。また、docker image pruneを効果的に使うための注意点やベストプラクティス、さらに不要なイメージを溜め込まないための予防策についても触れます。

Dockerイメージの種類と`docker image prune`の対象

docker image pruneコマンドがどのようなイメージを削除するのかを理解するためには、Dockerイメージがどのように管理され、どのような状態になりうるのかを知る必要があります。

Dockerイメージは通常、リポジトリ名とタグによって識別されます（例: ubuntu:latest, my-app:v1.0.0）。しかし、すべてのイメージが常に明確なタグを持っているわけではありません。また、イメージがコンテナによって使用されているかどうかも、そのイメージの状態を判断する上で重要です。

Dockerイメージは、その状態によって主に以下の3つのカテゴリに分類できます。

使用中のイメージ (Active / In-use Images):
- 現在、いずれかの実行中または停止中のコンテナが参照しているイメージです。
- これらのイメージは、コンテナが依存しているため、通常、docker image pruneコマンドによって削除されることはありません。これは、誤って使用中のイメージを削除し、コンテナの起動や実行に支障をきたすのを防ぐための重要な安全機構です。
タグ付けされていないイメージ (Dangling Images):
- どのコンテナからも参照されておらず、かつ、リポジトリ名とタグの組み合わせを持たないイメージです。
- これは、例えば同じリポジトリ名とタグで新しいイメージをビルドまたはプルした場合に発生します。以前そのタグを持っていた古いイメージは、新しいイメージによってタグを「上書き」され、タグを失ってdanglingイメージとなります。ビルドキャッシュとして残った中間イメージなどもdanglingイメージとなる場合があります。
- これらのイメージは、通常、直接的に使用されることがないため、最も優先的に削除を検討すべき対象となります。docker image pruneコマンド（オプションなし）のデフォルトの削除対象はこのdangling imagesです。
未使用のイメージ (Unused Images):
- どのコンテナからも参照されておらず、かつ、リポジトリ名とタグの組み合わせを持っているイメージです。
- これには、古いバージョンのイメージ（例: my-app:v0.9.0）や、過去にプルまたはビルドしたが現在は使用していないイメージ（例: alpine:3.10）、あるいは特定のプロジェクトのためにビルドしたが現在は使っていないイメージなどが含まれます。
- これらのイメージはタグが付いているため、danglingイメージとは異なり、デフォルトのdocker image pruneでは削除されません。削除するには、特定のオプション（後述の-aオプション）を指定する必要があります。

docker image pruneコマンドは、これらのカテゴリのうち、特に「タグ付けされていないイメージ (Dangling Images)」および、オプションによっては「未使用のイメージ (Unused Images)」をターゲットとしています。使用中のイメージを誤って削除するリスクを最小限に抑えつつ、ディスク容量を圧迫する不要なイメージを効率的に解放することを目的としています。

`docker image prune`とは

docker image pruneコマンドは、Dockerホスト上に存在する不要なDockerイメージを削除するためのコマンドです。不要なイメージを一括で削除することで、手動で一つずつイメージを削除する手間を省き、ディスク容量の解放を効率的に行えます。

このコマンドの主な特徴は以下の通りです。

一括削除: 手動でdocker image rmコマンドを使って個別に、またはリストアップしたイメージIDを指定して削除するのに比べ、docker image pruneは定義された基準に基づいて複数の不要なイメージを一度に削除します。
デフォルトの削除対象: オプションを指定しない場合、docker image pruneはdangling images（タグ付けされていないイメージで、どのコンテナからも参照されていないもの）のみを削除します。これは最も安全かつ一般的な不要イメージの定義に合致しています。
使用中のイメージの保護: 実行中または停止中のコンテナが参照しているイメージは、デフォルトでは削除されません。これにより、現在稼働している、あるいは後で使う可能性のあるコンテナに必要なイメージが誤って削除されることを防ぎます。
オプションによる柔軟な削除: -a (all) オプションを使用することで、danglingイメージに加えて、タグは付いているもののどのコンテナからも参照されていないunused imagesも削除対象に含めることができます。また、--filterオプションを使えば、削除対象をさらに細かく制御することが可能です。
確認プロンプト: デフォルトでは、実際にイメージを削除する前にユーザーに確認を求めます。これにより、意図しないイメージの削除を防ぐことができます（-fオプションでスキップ可能）。

docker image rm <image_id>やdocker rmi <image_id>コマンドもイメージを削除するために使用されますが、これらは通常、特定のイメージIDやリポジトリ名:タグを指定して個別に削除する場合に使われます。あるいは、docker image ls -qf dangling=true | xargs docker image rmのようにコマンドを組み合わせてdanglingイメージを削除することも可能ですが、docker image pruneはこの処理をよりシンプルかつ安全に実行するための専用コマンドとして提供されています。

`docker image prune`の基本的な使い方

最も基本的なdocker image pruneコマンドの使い方は非常にシンプルです。ターミナルを開き、以下のコマンドを実行します。

bash docker image prune

このコマンドを実行すると、Dockerはまず、削除対象となるdangling imagesをスキャンします。そして、削除しようとしているイメージのリストと、解放されるディスク容量の合計推定値を表示し、ユーザーに続行するかどうかを尋ねる確認プロンプトを表示します。

WARNING! This will remove all dangling images. Are you sure you want to continue? [y/N]

ここで y を入力してEnterキーを押すと、対象のイメージが削除されます。N を入力するか、単にEnterキーを押すと（大文字のNがデフォルト選択であることを示します）、操作はキャンセルされます。

削除が実行されると、削除されたイメージのIDが表示され、最後に解放されたディスク容量の合計が報告されます。

bash Deleted Images: untagged: <image_id> untagged: <image_id> ... Total reclaimed space: <size>

このように、docker image prune（オプションなし）は、最もリスクが低いとされるdangling imagesのみを対象とするため、日常的なクリーンアップとして気軽に実行できます。

`docker image prune`のオプション詳解

docker image pruneコマンドには、削除対象を拡張したり、操作の挙動を変更したりするためのオプションが用意されています。これらのオプションを理解することで、より柔軟かつ強力にイメージのクリーンアップを行うことができます。

`-f` または `--force`

機能: 確認プロンプト (Are you sure...?) をスキップし、強制的に削除を実行します。
使い方:
bash docker image prune -f # または docker image prune --force
解説: このオプションを使用すると、コマンド実行時にすぐに削除処理が開始されます。スクリプトなどによる自動化を行う場合や、確認が不要な場合に便利ですが、誤って必要なイメージを削除してしまうリスクが高まります。使用する際は十分注意が必要です。特に、後述の-aオプションと組み合わせる場合は、削除対象が広がるためより一層の注意が必要となります。

`-a` または `--all`

機能: dangling imagesに加えて、未使用のイメージ（タグは付いているが、どのコンテナからも参照されていないイメージ）も削除対象に含めます。
使い方:
bash docker image prune -a # または docker image prune --all
解説: デフォルトのdocker image pruneはdangling imagesのみを削除しますが、時間が経つとタグ付きの未使用イメージもディスク容量を圧迫します。-aオプションを使用することで、これらの未使用イメージもまとめてクリーンアップできます。
- 未使用の定義: Dockerにおいて「未使用 (unused)」とは、「どのコンテナからも参照されていない」状態を指します。実行中のコンテナだけでなく、停止中のコンテナが参照しているイメージも「使用中」とは見なされませんが、「未使用」でもありません。したがって、-aオプションを使用しても、停止中のコンテナが参照しているイメージはデフォルトでは削除されません。
確認プロンプト: このオプションを指定した場合も、デフォルトでは確認プロンプトが表示されます。削除対象リストにはdangling imagesとunused imagesの両方が含まれます。
-aと-fの組み合わせ:
bash docker image prune -a -f
この組み合わせは、確認なしで全てのdangling imagesとunused imagesを強制的に削除します。非常に強力なクリーンアップ手法ですが、停止中のコンテナが参照 していない タグ付きイメージ（例えば、過去のプロジェクトのイメージ、テスト用のイメージ、古いバージョンのイメージなど）も容赦なく削除されるため、実行前に削除対象となるイメージを十分に確認することを強く推奨します。確認のためには、まずオプションなしで実行してリストを確認し、その後-fを付けて実行する、という手順が安全です。

`--filter`

機能: 削除対象とするイメージを特定の条件で絞り込みます。これはdocker image pruneコマンドの最も強力で柔軟なオプションです。
使い方: --filter <key>=<value> の形式で指定します。複数のフィルタを同時に指定することも可能です。その場合、指定されたすべての条件を満たすイメージが削除対象となります（論理AND）。
bash docker image prune --filter <key>=<value> [--filter <key>=<value> ...]
利用可能なフィルタキー: docker image pruneで利用できる主なフィルタキーは以下の通りです。
- until=<timestamp>:
  - 機能: 指定したタイムスタンプよりも古いイメージのみを削除対象とします。最終更新日時（またはビルド日時）がこのタイムスタンプ以前のイメージが対象となります。
  - タイムスタンプの形式:
    - Unixエポックタイム (例: 1678886400)
    - RFC3339ナノ秒 (例: 2023-03-15T10:00:00Z)
    - Go言語の duration 形式 (例: 24h, 7d) – 現在時刻から指定された期間よりも古いイメージを対象とします。例えば 24h は「過去24時間以内に更新されていないイメージ」ではなく、「24時間より前に更新された（古い）イメージ」を意味します。
  - 使い方:
    “`bash
    # 7日以上前に更新されたイメージを削除対象とする (danglingのみ)
    docker image prune –filter until=7d
    
    7日以上前に更新されたイメージを削除対象とする (dangling + unused)
    
    docker image prune -a –filter until=7d
    
    特定の日付より前に更新されたイメージを削除対象とする
    
    docker image prune -a –filter “until=2023-01-01T00:00:00Z”
    `` * 解説: このフィルタは「最近のイメージは残しておきたいが、古いイメージは削除したい」という場合に非常に役立ちます。例えば、CI/CDで毎日ビルドを行っているが、過去1週間分のイメージがあれば十分、といったシナリオで利用できます。until=`形式は、定期的なクリーンアップ処理の自動化にも適しています。
- label=<label> または label=<key>=<value>:
  - 機能: 指定したラベルを持つイメージ、あるいは指定したキーと値のラベルを持つイメージのみを削除対象とします。
  - 使い方:
    “`bash
    # ラベル “temporary=true” を持つ dangling images を削除対象とする
    docker image prune –filter “label=temporary=true”
    
    ラベル “project” が設定されている全ての未使用イメージを削除対象とする
    
    docker image prune -a –filter “label=project”
    
    ラベル “environment=test” を持つ全ての未使用イメージを削除対象とする
    
    docker image prune -a –filter “label=environment=test”
    “`
    * 解説: イメージにラベルを付けて管理している場合に有効です。例えば、テスト目的で一時的に作成したイメージに特定のラベルを付けておき、後でそのラベルを持つイメージだけをまとめて削除するといった使い方ができます。
- label!=<label> または label!=<key>=<value>:
  - 機能: 指定したラベルを持たないイメージ、あるいは指定したキーと値のラベルを持たないイメージのみを削除対象とします。
  - 使い方:
    “`bash
    # ラベル “important=true” を持たない全ての未使用イメージを削除対象とする
    docker image prune -a –filter “label!=important=true”
    
    ラベル “keep” が設定されていない全ての未使用イメージを削除対象とする
    
    docker image prune -a –filter “label!=keep”
    `` * 解説: このフィルタは、特定の重要なイメージ群（ラベルで識別できるもの）を残しておき、それ以外のイメージを削除したい場合に便利です。例えば、本番環境で使用するイメージにはproduction=true` のラベルを付けておき、それ以外の開発・テスト用のイメージをまとめて削除する、といったシナリオで利用できます。
- reference=<pattern>:
  - 機能: 指定したパターン（イメージ名またはタグ）に一致するイメージのみを削除対象とします。パターンはワイルドカード (*) を使用できます。
  - 使い方:
    “`bash
    # 名前が “my-app” で始まる dangling images を削除対象とする (稀なケース)
    # dangling images は通常名前を持たないので、このフィルタは -a と組み合わせるのが一般的
    docker image prune –filter “reference=my-app*”
    
    タグが “dev-” で始まる全ての未使用イメージを削除対象とする
    
    docker image prune -a –filter “reference=:dev-“
    
    特定のリポジトリ名を持つ全ての未使用イメージを削除対象とする
    
    docker image prune -a –filter “reference=my-registry.com/my-project/*”
    
    特定のイメージ名とタグ (例: my-app:old-*) に一致する全ての未使用イメージを削除対象とする
    
    docker image prune -a –filter “reference=my-app:old-*”
    “`
    * 解説: 特定の名前規則やタグ付け規則に従ったイメージだけをまとめて削除したい場合に役立ちます。例えば、開発ブランチからビルドしたイメージに特定のタグプレフィックスを付けておき、そのプレフィックスを持つ古いイメージだけをクリーンアップする、といった用途が考えられます。
- reference!=<pattern>:
  - 機能: 指定したパターン（イメージ名またはタグ）に一致しないイメージのみを削除対象とします。
  - 使い方:
    “`bash
    # タグが “release” または “latest” でない全ての未使用イメージを削除対象とする
    docker image prune -a –filter “reference!=:release” –filter “reference!=:latest”
    # これは複数の –filter を指定することで実現。「release」タグではなく、「latest」タグでもない、というAND条件になる。
    
    特定のイメージ名 “official/nginx” ではない全ての未使用イメージを削除対象とする
    
    docker image prune -a –filter “reference!=official/nginx”
    `` * 解説: 特定の重要なイメージ（例:nginx:latest,ubuntu:ltsなど）は残しておき、それ以外のイメージをまとめて削除したい場合に便利です。複数のreference!=`フィルタを組み合わせることで、除外リストを作成できます。
フィルタの組み合わせ: 複数の--filterオプションを指定した場合、それらの条件をすべて満たすイメージが削除対象となります（AND条件）。
“`bash
# 7日以上前に更新され、かつラベル “temporary=true” を持つ全ての未使用イメージを削除対象とする
docker image prune -a –filter until=7d –filter “label=temporary=true”

特定のイメージパターン（例: my-app:dev-*）に一致し、かつ30日以上前に更新された全ての未使用イメージを削除対象とする

docker image prune -a –filter “reference=my-app:dev-*” –filter until=30d
“`

フィルタオプションを使いこなすことで、docker image pruneは非常に強力なツールとなります。ただし、フィルタの指定を誤ると意図しないイメージが削除される可能性もあるため、特に-fオプションと組み合わせる場合は、事前にフィルタなしで実行して削除対象リストを確認するなどの慎重な対応が必要です。

`docker image prune`の実行例と解説

これまでに説明したオプションを組み合わせて、具体的な実行例を見てみましょう。

例 1: デフォルトの削除

bash docker image prune
* 解説: 最も基本的な使い方です。どのコンテナからも参照されておらず、かつタグが付いていないdangling imagesのみを削除します。削除前に確認プロンプトが表示されます。最も安全なクリーンアップ方法です。

例 2: デフォルトの削除（強制）

bash docker image prune -f
* 解説: 例1と同じくdangling imagesのみを削除しますが、確認プロンプトをスキップします。自動化スクリプトなどに組み込む場合に便利ですが、意図せず実行されないよう注意が必要です。

例 3: 未使用のすべてのイメージを削除

bash docker image prune -a
* 解説: dangling imagesに加えて、タグは付いているもののどのコンテナからも参照されていないunused imagesも削除対象に含めます。これにより、より多くのディスク容量を解放できる可能性があります。削除前に確認プロンプトが表示されます。

例 4: 未使用のすべてのイメージを削除（強制）

bash docker image prune -a -f
* 解説: 例3と同じくdangling imagesとunused imagesを削除しますが、確認プロンプトをスキップします。強力なクリーンアップですが、停止中のコンテナが参照していないタグ付きイメージ（将来使う可能性があるものも含む）もすべて削除されるため、使用には細心の注意が必要です。

例 5: 1週間以上前に更新されたイメージを削除

bash docker image prune -a --filter until=7d
* 解説: until=7dフィルタにより、最終更新日時が現在から7日以上前のイメージのみを削除対象とします。-aオプションにより、タグの有無にかかわらず（dangling imagesもunused imagesも）対象となります。最近ビルドまたはプルしたイメージは保持しつつ、古いイメージをクリーンアップするのに適しています。

例 6: 特定の日付より前に更新されたイメージを削除

bash docker image prune -a --filter "until=2023-04-01T00:00:00Z"
* 解説: 特定の固定日付 (2023-04-01T00:00:00Z) よりも前に更新された全ての未使用イメージ（-a）を削除対象とします。特定の時点より前のイメージをアーカイブまたは削除したい場合に有効です。

例 7: 特定のラベルを持つイメージを削除

bash docker image prune -a --filter "label=cleanup=true" --filter until=24h -f
* 解説: ラベル cleanup=true が付いており、かつ24時間以上前に更新された全ての未使用イメージ（-a）を、確認なし（-f）で削除します。これは、一時的なビルドやテストで使用したイメージに cleanup=true ラベルを付けておき、一括で削除するようなシナリオで役立ちます。until=24h を追加することで、ごく最近作成された同じラベル付きイメージを誤って削除するのを防ぐといった配慮も可能です。

例 8: 特定のパターンに一致するイメージを削除

bash docker image prune -a --filter "reference=my-app:dev-*" -f
* 解説: イメージ名が my-app で、タグが dev- で始まる全ての未使用イメージ（-a）を、確認なし（-f）で削除します。開発ブランチからビルドされた古いイメージを定期的にクリーンアップするのに便利です。

例 9: 特定のパターンに一致しないイメージ以外を削除

bash docker image prune -a --filter "reference!=*:latest" --filter "reference!=*:production" -f
* 解説: タグが latest または production でない全ての未使用イメージ（-a）を、確認なし（-f）で削除します。重要なタグが付いたイメージを残しつつ、それ以外のイメージをまとめてクリーンアップしたい場合に非常に有効です。複数のreference!=フィルタを指定すると、それらの条件をすべて満たさないもの（つまり、どの除外パターンにも一致しないもの）が削除対象となります。

これらの例は、docker image pruneが持つ柔軟性を示しています。状況に応じて適切なオプションやフィルタを組み合わせることで、効率的かつ安全に不要なイメージを管理できます。

削除されるイメージと削除されないイメージの詳細

docker image pruneコマンドを安全に使うためには、具体的にどのようなイメージが削除され、どのようなイメージが削除されないのかを正確に理解しておくことが重要です。

デフォルト (`docker image prune`):

削除されるイメージ:
- Dangling images: どのコンテナからも参照されておらず、かつタグが付いていないイメージ。これらは通常、新しいイメージにタグが上書きされた古いバージョンのイメージや、ビルドキャッシュとして残った中間イメージなどです。これらはほとんどの場合不要なため、デフォルトの削除対象となります。
削除されないイメージ:
- 使用中のイメージ: 実行中または停止中のコンテナが参照しているイメージ。
- 未使用のイメージ: タグが付いているが、どのコンテナからも参照されていないイメージ。これには、古いバージョンのタグ付きイメージや、プルしたまま使っていないイメージなどが含まれます。デフォルトではこれらは「使用中ではないが、将来使う可能性があるタグ付きイメージ」と見なされ、保護されます。
- フィルタによって除外されたイメージ: --filterオプションが指定されている場合、その条件に一致しないイメージは削除対象から外されます。

`-a`オプション付き (`docker image prune -a`):

削除されるイメージ:
- Dangling images: デフォルトの場合と同様です。
- Unused images: タグが付いているが、どのコンテナからも参照されていないイメージ。docker image prune -aを使用すると、デフォルトでは保護されていたこれらのイメージも削除対象に含まれます。
削除されないイメージ:
- 使用中のイメージ: 実行中または停止中のコンテナが参照しているイメージ。-aオプションを指定しても、停止中のコンテナが参照しているイメージは削除されません。 これは重要な点です。もし停止中のコンテナが参照しているイメージを削除したい場合は、そのコンテナ自体を削除する必要があります（docker rm <container_id>）。コンテナを削除すれば、そのコンテナが参照していたイメージは「未使用」または「dangling」状態になり、次回docker image prune -aを実行した際に削除対象となります。
- フィルタによって除外されたイメージ: --filterオプションが指定されている場合、その条件に一致しないイメージは削除対象から外されます。

重要なポイント:

コンテナが参照しているイメージは削除されない: 実行中であろうと停止中であろうと、コンテナが参照しているイメージはdocker image pruneのデフォルトおよび-aオプションの両方で保護されます。これは、コンテナの動作に必要なイメージを誤って削除しないための重要な安全機構です。
Dangling vs Unused:
- Dangling Images: タグなし、どのコンテナも参照なし。docker image prune (デフォルト) で削除。
- Unused Images: タグあり、どのコンテナも参照なし。docker image prune -a で削除。
- 使用中のイメージ: いずれかのコンテナが参照している。docker image prune / docker image prune -a のどちらでも削除されない。

これらの違いを理解することで、意図したイメージのみを削除し、必要なイメージを誤って削除するリスクを回避できます。特に-aオプションを使用する際は、削除対象にタグ付きの未使用イメージが含まれることを意識し、必要に応じて--filterオプションで削除対象を絞り込むことが推奨されます。削除前にdocker image ls -f dangling=trueやdocker image ls -f unused=true（またはより正確にdocker image ls -f dangling=false -f unused=trueのように組み合わせる）を実行して、削除対象となるイメージを確認する習慣をつけるとより安全です。

`docker system prune`との違い

Dockerには、不要なリソースを一括でクリーンアップするためのより広範なコマンドとしてdocker system pruneがあります。docker image pruneとの違いを理解しておきましょう。

docker system pruneコマンドは、Docker環境全体の不要なリソースを対象とします。デフォルトでは、以下のものが削除対象となります。

すべての停止中のコンテナ (all stopped containers)
どのコンテナからも使用されていないネットワーク (all unused networks)
dangling images

そして、docker system prune -aまたはdocker system prune --allとすると、上記に加えて

どのコンテナからも使用されていないボリューム (all unused volumes)
**どのコンテナからも使用されていないイメージ (all unused images) ** – つまり、docker image prune -aと同じイメージ削除の対象

も含まれます。

このように、docker system pruneはdocker image pruneよりもはるかに広範囲のリソース（コンテナ、ネットワーク、ボリューム、イメージ）を対象とします。

使い分け:

docker image prune: 不要なイメージのみをクリーンアップしたい場合に特化しています。特に、イメージの削除条件を細かく制御したい場合（例: --filterオプションを使う場合）や、コンテナやネットワークなどの他のリソースは保持したい場合に適しています。
docker system prune: Docker環境全体をまとめてクリーンな状態にしたい場合に便利です。開発マシンのディスク容量をまとめて解放したい場合や、CI/CD環境でビルド終了後にすべての使い捨てリソースを破棄したい場合などに適しています。ただし、停止中のコンテナや未使用のネットワーク、ボリュームなども削除されるため、必要なリソースが誤って削除されないか注意が必要です。特にボリュームは永続データを含む場合があるため、docker system prune -aの実行には細心の注意が必要です（ボリュームの削除はデフォルトでは含まれず、-aが必要です）。

基本的には、イメージのみを対象とするならdocker image pruneを、全体を対象とするならdocker system pruneを使用すると覚えておくと良いでしょう。

不要なイメージを溜め込まないための予防策

docker image pruneコマンドは溜まってしまった不要なイメージをクリーンアップするのに非常に有効ですが、そもそも不要なイメージを必要以上に生成・蓄積しないようにすることも重要です。以下にいくつかの予防策を挙げます。

ビルド時のキャッシュ管理 (--no-cache): Dockerビルドはレイヤーキャッシュを利用して高速化されますが、意図しない古いキャッシュが残ることがあります。完全にクリーンな状態でビルドしたい場合や、キャッシュによる不具合が疑われる場合は、docker build --no-cache ...オプションを使用することで、キャッシュを無効にしてビルドできます。これにより、ビルドキャッシュとしての中間イメージの生成を抑えることができます。ただし、ビルド時間は長くなります。
マルチステージビルドの活用: Dockerイメージのサイズを削減し、ビルドプロセスで生成される中間イメージを減らすために、マルチステージビルドを積極的に活用しましょう。マルチステージビルドでは、複数のFROM命令を使用して、ビルドに必要なツールを含む一時的なイメージと、最終的な成果物のみを含む軽量なランタイムイメージを分離できます。これにより、最終イメージには不要なビルドツールや中間ファイルが含まれなくなり、ディスク使用量を削減できます。また、中間ステージで生成されたイメージレイヤーは、それが最終イメージで参照されなければ、dangling imagesとしてdocker image pruneの対象となりやすくなります。
イメージに適切なタグ付けを行う習慣: イメージには常に意味のあるタグを付ける習慣をつけましょう（例: my-app:v1.0.0, my-service:dev-branch-abc, temp:test-feature-xyz）。これにより、イメージの目的やバージョンが一目でわかるようになります。また、docker image prune -aや--filter referenceオプションを使用する際に、どのイメージが不要で、どのイメージを残すべきかを容易に判断できるようになります。タグ付けされていないdangling imagesはデフォルトで削除されますが、タグ付きの未使用イメージは-aオプションなしでは削除されません。重要なイメージには明確なタグを付けておくことで、誤削除のリスクを減らせます。逆に、一時的なイメージには例えば temp- のようなプレフィックスを付けておき、後で --filter "reference=*:temp-*"でまとめて削除するといった運用も可能です。
古いイメージの定期的なクリーンアップの自動化: docker image pruneコマンドを定期的に実行するジョブを設定することで、不要なイメージが蓄積するのを防ぐことができます。Linux環境であればcron、Systemd timer、Windows環境であればタスクスケジューラなどを使用して、例えば毎週または毎日特定の時間にdocker image prune -a --filter until=30d -fのようなコマンドを実行する設定をすることで、常に一定期間より古い未使用イメージを自動的にクリーンアップできます。自動化を行う際は、-fオプションを付けることが一般的ですが、削除対象を慎重に検討し、適切なフィルタを設定することが極めて重要です。

これらの予防策は、docker image pruneによる事後的なクリーンアップの必要性を減らし、Docker環境をより効率的かつ管理しやすく保つのに役立ちます。

注意点とベストプラクティス

docker image pruneコマンドを使用する際に、知っておくべき注意点や推奨されるベストプラクティスをまとめます。

削除前の確認は重要: 特に-aオプションを使用する場合や、初めてdocker image pruneを実行する場合、あるいは複雑な--filterオプションを使用する場合は、必ずデフォルトの確認プロンプト (Are you sure...? [y/N]) を表示させ、削除対象となるイメージのリストを確認しましょう。リストを見て、もし残しておきたいイメージが含まれている場合は、Nを入力して操作をキャンセルし、フィルタ条件を見直すか、そのイメージがなぜ削除対象になったのか（例えば、コンテナが参照していない、フィルタ条件に一致しているなど）を確認する必要があります。確認なしで-fオプションを使うのは、削除対象が明確で、かつ誤削除のリスクを許容できる場合に限定すべきです。
重要なイメージには明確なタグを: 前述の予防策とも関連しますが、後で必要になる可能性のあるイメージや、本番環境で使用するイメージには、latestのような移り変わるタグだけでなく、特定のバージョンやコミットハッシュなど、明確で固定的なタグを付けておくことが重要です。これにより、docker image prune -aのような広範囲な削除を行う際に、意図せず削除されるリスクを減らせます。また、--filter reference!=...のようなフィルタを使って、特定の重要なイメージを除外する際にも役立ちます。
本番環境での実行は慎重に: 本番環境のホストマシンでdocker image pruneを実行する際は、開発環境やテスト環境以上に慎重に行う必要があります。誤って必要なイメージを削除してしまうと、サービス停止などの重大な影響が出る可能性があります。実行前に影響範囲を十分に評価し、できれば影響の少ない時間帯に行う、あるいは事前に削除対象リストを確認してから実行するなどの対策を講じましょう。
ディスク容量監視の重要性: 定期的なクリーンアップを行っていても、想定以上にディスク容量が消費されることがあります。Dockerホストのディスク容量を継続的に監視し、容量が逼迫してきた際に適切にクリーンアップを実行できるよう体制を整えておくことが重要です。
レイヤー共有の考慮: Dockerイメージはレイヤー構造になっており、異なるイメージ間で共通のレイヤーを共有することがあります。docker image pruneコマンドは、イメージそのものを削除するだけでなく、そのイメージが使用していたレイヤーのうち、他のどのイメージからも参照されなくなったレイヤーも同時に削除することで容量を解放します。したがって、一つのイメージを削除しても、他のイメージが参照しているレイヤーは削除されません。解放される容量は、削除されるイメージが単独で使用していたレイヤーの合計サイズとなります。
コンテナの削除: 停止中のコンテナが参照しているイメージはdocker image prune -aでも削除されません。もしそのイメージも不要であれば、先にそのコンテナを削除する必要があります（docker rm <container_id>）。不要なコンテナも定期的にクリーンアップすることで、関連するイメージも削除対象になりやすくなります。停止中の不要なコンテナを削除するには、docker container pruneコマンドが便利です。

これらの注意点とベストプラクティスを守ることで、docker image pruneコマンドをより安全かつ効果的に活用できます。

まとめ

この記事では、Docker環境における不要なイメージのクリーンアップに不可欠なdocker image pruneコマンドについて、詳細に解説しました。

docker image pruneは、Dockerホスト上の不要なイメージを一括削除するためのコマンドです。
デフォルトでは、どのコンテナからも参照されておらず、かつタグが付いていないdangling imagesのみを削除します。
-aオプションを指定すると、dangling imagesに加えて、タグ付きだがどのコンテナからも参照されていないunused imagesも削除対象に含まれます。
使用中のイメージ（実行中または停止中のコンテナが参照しているイメージ）は、デフォルトでも-aオプションを使用した場合でも削除されません。
--filterオプションを使用することで、until, label, referenceといった様々な条件で削除対象を細かく制御できます。特に-aオプションと組み合わせて、特定の条件を満たす未使用イメージのみを削除するのに役立ちます。
-fオプションは確認プロンプトをスキップし強制実行しますが、誤削除のリスクがあるため慎重に使用する必要があります。
docker system pruneはイメージだけでなく、コンテナ、ネットワーク、ボリュームなどもまとめてクリーンアップするより広範なコマンドです。
不要なイメージを溜め込まないためには、マルチステージビルドの活用、適切なタグ付け、そして定期的な自動クリーンアップが有効な予防策となります。
コマンド実行前の確認、重要なイメージへの適切なタグ付け、本番環境での慎重な操作などが、安全にdocker image pruneを利用するための重要なベストプラクティスです。

docker image pruneコマンドとそのオプションを適切に理解し活用することで、Dockerホストのディスク容量を効率的に管理し、クリーンで安定したDocker環境を維持することができます。これは、開発効率の向上、インフラコストの削減、そしてセキュリティリスクの低減に繋がります。ぜひ、ご自身のDocker環境でdocker image pruneを定期的に実行し、快適なDockerライフを送りましょう。