問題の経緯
年末も近づいてきた昨今、気がつけばPCの残容量が危なくなっていたので不要なデータの整理を行なっていたのですが、どうも様子がおかしい。いくらなんでもこんなに使った心当たりはありません。何より、PC内の心当たりらへん、つまりは今年酷使した覚えのあるディレクトリ周辺を調べてまわりましたが、そんなに容量を占めているファイルもディレクトリも見つかりません。
あれこれ調べた結果、どうもサイズの大きいdocker volumeが大量増殖していたことが原因のようでした。
ボケっとしながら少なくとも半分以上は消した後で異変に気付いたので元々どれくらい残っていたのかはわかりませんが、少なめに100と見積もっても0.5GB×100volumeで50GB。チリも積もればゴミの山。
しかし匿名のdocker volumeなんか使った覚えはありません。どうやって作ったのかむしろこっちが訊きたいくらいです。
というわけでAIに訊きました。
🎯 主な原因
1. docker run の -v でホスト側を省略している
docker run -d -v /var/lib/data busybox
-
/var/lib/dataのホスト側が指定されていない - Dockerは自動的にホスト側ボリュームを作る（匿名ボリューム）
- 同じコマンドを繰り返すほど増殖
対策：ホスト側パス or 名前付きボリュームを指定
docker run -d -v data:/var/lib/data busybox
2. docker-compose.yml のボリューム記述ミス
volumes:
- /app/data # ←ホスト側パスが無い
- 起動のたびに新しい匿名ボリュームが作られる
- CI/CDで
docker compose up/down繰り返すと溜まる
対策
volumes:
- data:/app/data
3. --rm への誤解
docker run --rm -v /data busybox
-
--rmはコンテナのみ削除 - ボリュームは残る
対策
- 使い捨て用途なら定期的に
docker volume prune - または名前付きにして再利用
4. Dockerfile の VOLUME 指定
VOLUME /var/lib/mysql
- このイメージでコンテナ起動すると毎回匿名ボリューム生成
- MySQL/PostgreSQL/RedisなどDB系公式イメージでよく起こる
対策
volumes:
- dbdata:/var/lib/mysql
5. docker compose down の仕様
-
docker compose downはデフォルトでボリューム削除しない - スクリプトやCIで繰り返すと溜まる
対策
docker compose down -v
🧪 状況調査コマンド
# ボリューム一覧
docker volume ls
# どのコンテナが使ってるか
docker volume inspect <ID>
# そのボリュームを使ってるコンテナ
docker ps -a --filter volume=<ID>
🧹 片付けコマンド
# 未使用ボリュームだけ削除
docker volume prune
# コンテナ/ネットワーク/ボリュームまとめて削除
docker compose down -v
📌 まとめ
| 原因 | 説明 | 対策 |
|---|---|---|
-v /path/in/container のホスト側省略 |
自動で匿名ボリューム生成 | ホスト側を指定 or 名前付き |
| composeでホスト指定無し | 毎回新ボリューム生成 |
name:/path の形式に修正 |
--rm誤解 |
ボリュームは残る |
pruneで定期掃除 or 再利用 |
DockerfileのVOLUME
|
起動ごとに生成 |
named volumeで束ねる |
compose downの仕様 |
ボリューム残留 | down -v |
最も多い原因：ホスト側パス未指定
🏁 結論
Dockerの匿名ボリューム大量発生は、
「ホスト側の指定漏れ」や「compose/downの仕様理解不足」 がほとんど。
対策は、
- 名前付きボリュームを使う
- 必要に応じて prune / down -v
- VOLUMEの影響を理解する
これだけでだいぶ防げる。
人間から補足
以上AIからでした。いやーすごいですね。素晴らしいですね。よくまとまってますね。
ただちょっと補足しますと
docker volume prune の使用は慎重に
docker volume prune は現在起動中でないvolumeを問答無用で全削除しますので、使用には十分注意を払ってください。
dockerのimageは削除しても再ビルドすればいいだけですが、volumeの場合は内部に貯めたデータは消すともう戻りません。
なお原因これでした
AIのまとめをもとに心当たりを調査した結果、 2 が的中してました。
原因となったソースコードはだいぶ前に手元のPCから削除済みで存在すら忘れかけていたのですが、幸いGitHubに残っていました。
自分では絶対に書かないコードですのでこれはAIが書いたものを見逃したものと思われます。vibecodingの弊害ですね。しかし、AIがこれを良かれと思って書いたからには、これと同じコードが横行しているリポジトリが結構な数あるはずです。 つまり原因は人間です。AI悪クナイ。。。悪イノ全部ニンゲン。。。ニンゲン。。。ダメナ存在。。。。。。？（そんなことないない＾＾）
なおこのコーディングはClaudeを使った覚えがあったのですが、Claudeは今でもdocker composeのyamlファイルのフォーマットとして廃止（非推奨）になっているバージョン番号（ version: 3.8 のアレ）を必ずつけてくる、 docker compose ではなく docker-compose コマンドを使い続けるなど若干知識がアップデートされていない様子が見受けられますね。1リポジトリごとに1回訂正すれば同じ間違いは繰り返さないのであまり問題視していなかったのですが、最近自分がどんどんコードをまともに読まなくなってきましたので、そろそろ自動チェックなどの対策をデフォルトで適用することを検討したほうが良いかもしれないと思い始めています。
激動の2025年
そんなわけで2025年も終わりを迎えようとしていますが、今年はコーディングの常識と勝ちパターンに大規模地殻変動が発生した激動の年になりましたね。んんー。最高だった。
来年もよろしくお願いいたします＼(^o^)／