docker rmi でイメージを削除しようとしたらエラーが出る？
Dockerを使い続けていると、不要なイメージがどんどん溜まってディスク容量を圧迫していきます。「そろそろ整理しよう」と思って docker rmi を実行したのに、こんなエラーが出て削除できない…という経験はありませんか？
$ docker rmi nginx:latest
Error response from daemon: conflict: unable to remove repository reference "nginx:latest" (must be forced) - container abc123 is using its referenced imageこのエラーは「イメージを参照しているコンテナが存在するため、削除できません」という意味です。Dockerではイメージとコンテナが密接に関係しているため、単純に docker rmi だけでは消せないケースがあります。
この記事では、Dockerイメージが削除できない原因を3つに整理し、それぞれの解決方法を紹介します。さらに、不要なリソースを一括で削除できる docker prune コマンドの使い分けについても詳しく解説します。
💡 イメージとコンテナの関係がまだ曖昧な方へ
イメージはコンテナの「設計図」、コンテナはイメージから作られた「実体」です。詳しくは「Dockerイメージとコンテナの違い」をご覧ください。
Dockerイメージが削除できない3つの原因
原因1: コンテナが使用中（起動中 or 停止済み）
最も多い原因がこれです。イメージから作成されたコンテナが存在している場合、たとえコンテナが停止していても、イメージは削除できません。
$ docker rmi nginx:latest
Error response from daemon: conflict: unable to remove repository reference "nginx:latest" (must be forced) - container abc123 is using its referenced image起動中のコンテナだけでなく、docker stop で停止したコンテナもイメージへの参照を保持しています。停止済みコンテナは docker ps -a で確認できます。
$ docker ps -a
CONTAINER ID IMAGE STATUS NAMES
abc123def456 nginx:latest Exited (0) 2 hours ago my-nginx原因2: 他のイメージが依存している（親イメージ）
Dockerイメージはレイヤー構造になっており、あるイメージが別のイメージをベースにして作られることがあります。例えば、自作のDockerfileで FROM nginx:latest と指定してビルドした場合、nginx:latest は親イメージとなり、子イメージが存在する限り削除できません。
$ docker rmi nginx:latest
Error response from daemon: conflict: unable to delete (image has dependent child images)この場合、依存している子イメージを先に削除する必要があります。
原因3: タグが複数付いている
同じイメージに複数のタグが付いている場合があります。例えば、docker tag で別名を付けた場合です。
$ docker images
REPOSITORY TAG IMAGE ID SIZE
nginx latest a6bd71f48f68 187MB
my-nginx v1 a6bd71f48f68 187MBIMAGE IDが同じことに注目してください。この場合、docker rmi nginx:latest を実行しても、もう一方のタグ（my-nginx:v1）が残っているため、イメージの実体は削除されずタグだけが外れます。これはエラーではありませんが、「消したのに容量が減らない」と混乱する原因になります。
解決方法をケース別に解説
方法1: コンテナを先に削除してからイメージを削除する（推奨）
最も安全で確実な方法です。まずイメージを使用しているコンテナを特定・削除し、その後にイメージを削除します。
# 停止済みコンテナも含めて一覧表示
$ docker ps -a
# 対象のコンテナを停止（起動中の場合）
$ docker stop my-nginx
# コンテナを削除
$ docker rm my-nginx
# イメージを削除
$ docker rmi nginx:latest
Untagged: nginx:latest
Deleted: sha256:a6bd71f48f68...💡 コンテナのライフサイクルについて
コンテナの作成・起動・停止・削除の流れについては「コンテナのライフサイクル」で詳しく解説しています。
方法2: -f（force）オプションで強制削除する
コンテナが存在していても、-f オプションを付ければイメージを強制的に削除できます。
$ docker rmi -f nginx:latest⚠️ 強制削除のリスク
-f オプションを使うと、コンテナが参照しているイメージが消えるため、そのコンテナは再起動できなくなります。コンテナが不要であることを確認してから使いましょう。本番環境での使用は避けてください。
方法3: docker system prune で一括クリーンアップ
不要なイメージが大量にある場合は、個別に削除するよりも docker system prune でまとめてクリーンアップするのが効率的です。
$ docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
Are you sure you want to continue? [y/N] y
Total reclaimed space: 1.2GBこのコマンドは、停止済みコンテナ・未使用ネットワーク・タグなしイメージ（dangling images）・ビルドキャッシュをまとめて削除します。ディスク不足を一気に解消したいときに便利です。
pruneコマンドの使い分け一覧
Dockerには用途別の prune コマンドが用意されています。状況に応じて使い分けましょう。
| コマンド | 削除対象 | 使いどころ |
|---|---|---|
docker container prune |
停止済みコンテナ | 停止したまま放置しているコンテナを整理したいとき |
docker image prune |
未使用のdanglingイメージ（タグなし） | ビルドの残骸を消したいとき |
docker image prune -a |
コンテナに使われていない全イメージ | 不要なイメージを徹底的に削除したいとき |
docker volume prune |
未使用のボリューム | データの永続化で使ったボリュームを整理したいとき |
docker network prune |
未使用のネットワーク | docker-compose等で作られたネットワークを整理したいとき |
docker system prune |
停止コンテナ＋未使用ネットワーク＋danglingイメージ＋ビルドキャッシュ | 一括でクリーンアップしたいとき |
docker system prune -a |
上記＋全未使用イメージ（タグ付き含む） | 容量を完全に開放したいとき（要注意） |
💡 -a オプションの違い
docker image prune は通常、タグが付いていない「dangling」イメージだけを削除します。-a を付けると、コンテナで使用されていないイメージをタグの有無に関わらず全て削除します。docker system prune -a も同様に、全ての未使用イメージを削除対象に含めます。
docker system df でディスク使用量を確認する
pruneを実行する前に、まず docker system df でDockerが使用しているディスク容量を確認しましょう。
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 15 3 4.2GB 3.1GB (73%)
Containers 5 1 120MB 100MB (83%)
Local Volumes 8 2 850MB 650MB (76%)
Build Cache 20 0 1.5GB 1.5GB (100%)各項目の意味は次のとおりです。
- TOTAL: リソースの総数
- ACTIVE: 現在使用中のリソース数
- SIZE: 合計ディスク使用量
- RECLAIMABLE: pruneで解放可能な容量（割合）
この例では、イメージだけで約3.1GBの容量を解放できることがわかります。「Dockerの容量が圧迫している」「ディスク不足で困っている」という場合は、まずこのコマンドで状況を把握してからpruneを実行するのがおすすめです。
さらに詳しく確認したい場合は -v オプションを付けます。
$ docker system df -vこれにより、各イメージ・コンテナ・ボリュームの詳細な一覧とサイズが表示されます。どのリソースが容量を圧迫しているのか特定するのに役立ちます。
⚠️ pruneコマンドの注意点
pruneコマンドは便利ですが、使い方を間違えると必要なデータまで消してしまう可能性があります。以下の点に注意してください。
注意1: ボリュームの削除は慎重に
docker volume prune はコンテナにマウントされていないボリュームを全て削除します。データベースのデータなど、重要なデータがボリュームに保存されている場合があります。停止中のコンテナに紐づくボリュームも「未使用」と判定されるため、意図せず消えてしまうことがあります。
# 削除前にボリュームの一覧を確認
$ docker volume ls
# 特定のボリュームの詳細を確認
$ docker volume inspect my-data-volume注意2: docker system prune -a は影響範囲が大きい
docker system prune -a は、現在コンテナで使用されていない全てのイメージを削除します。つまり、今後使う予定のイメージも消えてしまいます。再度 docker pull が必要になり、ネットワーク帯域と時間がかかることを理解しておきましょう。
注意3: 本番環境では使わない
pruneコマンドは開発・検証環境での使用を前提としています。本番環境で実行すると、稼働中のサービスに影響が出る可能性があります。本番環境では個別に不要なリソースを特定して削除してください。
注意4: –filter で削除対象を絞り込む
pruneコマンドには --filter オプションがあり、削除対象を条件で絞り込めます。例えば、24時間以上前に作成されたリソースだけを削除するには次のようにします。
# 24時間以上前に作成されたdanglingイメージだけを削除
$ docker image prune --filter "until=24h"
# 特定のラベルが付いたリソースを除外
$ docker system prune --filter "label!=keep"不要なものだけを確実に削除するために、--filter を活用しましょう。
まとめ
Dockerイメージが削除できないときは、まず原因を特定しましょう。
- ✅
docker ps -aでコンテナの使用状況を確認する - ✅ コンテナを先に削除してから
docker rmiでイメージを削除する - ✅ 不要なリソースがたくさんある場合は
docker system pruneで一括削除する - ✅ 削除前に
docker system dfでディスク使用量を確認する - ✅ ボリュームの削除は慎重に行い、本番環境ではpruneを使わない
Dockerを使い込むほど不要なイメージやコンテナは溜まっていきます。定期的にpruneコマンドで整理する習慣をつけておくと、ディスク容量の圧迫を防ぎ、快適な開発環境を維持できます。
Dockerの主要コマンドを体系的に学びたい方は「Docker主要コマンド一覧」も合わせてご覧ください。
コメント