docker compose downの前に確認すべきこと｜停止で消えるリソースと残る匿名ボリュームの扱い

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ Docker ＞ docker compose downの前に確認すべきこと｜停止で消えるリソースと残る匿名ボリュームの扱い

「`docker compose down` を実行したのに、ディスクの空き容量がほとんど変わらない」——そんな経験はありませんか。あるいは逆に、「開発環境でデータが消えるとは思っていなかったのに消えてしまった」という声も現場ではよく聞きます。

`docker compose down` は単純に「止める」コマンドではなく、コンテナとネットワークを「片付ける」コマンドです。ボリュームは原則として残り、指定するフラグによって削除対象が変わります。この挙動を正しく理解していないと、本番環境でのデータ消失や開発環境でのディスク逼迫につながります。

この記事では、`docker compose down` と `docker compose stop` の根本的な違い（docker compose down 違い）から始め、停止時に削除されるリソース・残るリソースの全体像、匿名ボリュームの正体と確認方法、本番・開発環境それぞれに適した停止設計パターンまでを順番に解説します。

この記事のポイント

・ docker compose down はコンテナとデフォルトネットワークを削除するが、ボリュームは残る
・匿名ボリュームもデフォルトでは削除されず `docker volume ls` で確認できる
・ `--volumes` フラグを付けると名前付き・匿名ボリュームが両方削除されるため本番では要注意
・本番は `down` のみ、開発は `down --volumes --remove-orphans` で使い分けるのが基本設計

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

docker compose down と docker compose stop の違い

まずこの2つのコマンドの位置づけを整理します。どちらも「コンテナを停止する」操作ですが、後処理の範囲がまったく異なります。

1. docker compose stop ── コンテナを「眠らせる」

docker compose stop はコンテナのプロセスを止めるだけです。コンテナ自体は「停止状態（Exited）」として残り続けます。ネットワークもボリュームも、設定ファイルも何も変わりません。

# コンテナを停止するだけ（削除はしない） $ docker compose stop # 停止後もコンテナが残っている（Status: Exited） $ docker compose ps -a NAME IMAGE COMMAND STATUS myapp-web nginx:1.25 "nginx -g ..." Exited (0) 5 seconds ago myapp-db mysql:8.0 "docker-ent..." Exited (0) 5 seconds ago

停止後は `docker compose start` で即座に再開できます。開発中に一時的に止めたいだけなら `stop` が正解です。

2. docker compose down ── コンテナとネットワークを「片付ける」

docker compose down はコンテナを停止してから削除し、compose が自動作成したネットワーク（`プロジェクト名_default` など）も削除します。

# コンテナを停止・削除し、ネットワークも削除する $ docker compose down [+] Running 3/3 ✔ Container myapp-web Removed ✔ Container myapp-db Removed ✔ Network myapp_default Removed

再開するには `docker compose up` でコンテナを作り直す必要があります。

コマンド	コンテナ	ネットワーク	ボリューム	再開方法
`docker compose stop`	停止（Exited）	残る	残る	`docker compose start`
`docker compose down`	削除	削除（自動作成分）	残る（デフォルト）	`docker compose up`

docker compose down で消えるリソース・残るリソースの全体像

`docker compose down` を実行したとき、何が削除されて何が残るのか。これが曖昧なままだとデータ消失やディスク逼迫につながります。

1. 必ず削除されるもの

フラグなしで `docker compose down` を実行すると、以下が削除されます。

・コンテナ：compose.yml で定義された全サービスのコンテナが停止・削除されます
・デフォルトネットワーク：compose が自動作成した `プロジェクト名_default` ネットワークが削除されます

2. デフォルトで残るもの

次のリソースは `docker compose down` だけでは削除されません。

・名前付きボリューム：compose.yml のトップレベル `volumes:` セクションで定義したボリュームは保護されます
・匿名ボリューム：Dockerfile の `VOLUME` 命令や、compose.yml でホストパス指定なしの `volumes:` で作られるボリューム。ハッシュ状の名前を持ちます
・external ネットワーク：`external: true` で定義した外部ネットワークは削除されません
・イメージ：ダウンロード・ビルドされたイメージはそのまま残ります

リソース種別	down のみ	down --volumes	down --rmi all
コンテナ	削除	削除	削除
デフォルトネットワーク	削除	削除	削除
名前付きボリューム	残る	削除	残る
匿名ボリューム	残る	削除	残る
external ネットワーク	残る	残る	残る
イメージ	残る	残る	削除

匿名ボリュームの正体と「気づかない蓄積」

名前付きボリュームは compose.yml を確認するとすぐ把握できますが、匿名ボリュームは見落としやすいリソースです。開発サイクルを繰り返すたびに積み上がり、数GBになっていることもあります。

1. 匿名ボリュームが生まれる2つのパターン

パターン①：Dockerfile の VOLUME 命令

# Dockerfile の VOLUME 命令で自動的に匿名ボリュームが作られる FROM mysql:8.0 VOLUME /var/lib/mysql

公式イメージ（mysql、postgres、mongodbなど）の多くは Dockerfile に `VOLUME` 命令が書かれています。compose.yml 側でボリュームを明示指定しなくても、コンテナ起動時に匿名ボリュームが自動作成されます。

パターン②：compose.yml でホストパスなしのボリューム指定

services: db: image: mysql:8.0 volumes: - /var/lib/mysql # ← ホストパスなし＝匿名ボリューム

2. docker volume ls で確認する

匿名ボリュームはハッシュ状の名前を持つため、`docker volume ls` で一目瞭然です。

$ docker volume ls DRIVER VOLUME NAME local a3f7c2d1e9b48f2c91d0e4f3a2b1c9d8 # 匿名ボリューム local b8e2f4d6c1a3e5f7d9b0c2e4f6a8c0d2 # 匿名ボリューム local myapp_db-data # 名前付きボリューム（プロジェクト名_ボリューム名） local myapp_redis-data # 名前付きボリューム # 匿名ボリュームだけ確認する場合 $ docker volume ls -f dangling=true DRIVER VOLUME NAME local a3f7c2d1e9b48f2c91d0e4f3a2b1c9d8 local b8e2f4d6c1a3e5f7d9b0c2e4f6a8c0d2

`dangling=true` フィルタは「どのコンテナからも参照されていないボリューム」を表示します。`docker compose down` 後の匿名ボリュームは参照が切れているため、ここに現れます。

使用量を確認するには `docker system df` が便利です。

$ docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 12 4 3.2GB 1.8GB (56%) Containers 0 0 0B 0B Local Volumes 5 1 2.4GB 1.9GB (79%) # 残るボリュームの使用量 Build Cache 48 0 890MB 890MB

停止設計の2パターン ── 本番 vs 開発

`docker compose down` の挙動を把握したうえで、本番と開発で設計を分けることが重要です。

1. 本番環境 ── データを守る停止

本番環境ではボリューム削除は絶対に避けます。メンテナンスや再デプロイで `docker compose down` を使う場合は、フラグなしが基本です。

# 本番環境の停止（ボリュームは絶対に削除しない） $ docker compose down # 再デプロイ（イメージ更新）の場合 $ docker compose pull $ docker compose up -d

名前付きボリュームで永続化を設計しておくことが前提です。compose.yml の書き方は次のとおりです。

# 名前付きボリュームによる永続化設計（本番推奨） services: db: image: mysql:8.0 volumes: - db-data:/var/lib/mysql # 名前付きボリューム → downでも残る environment: MYSQL_ROOT_PASSWORD: "${DB_PASSWORD}" volumes: db-data: # トップレベルで定義 → downで削除されない

2. 開発環境 ── クリーン停止

開発環境では毎回クリーンな状態で起動したいケースが多いです。その場合は `--volumes` と `--remove-orphans` を組み合わせます。

# 開発環境の完全クリーン停止 # コンテナ＋ネットワーク＋ボリューム＋孤児コンテナをすべて削除 $ docker compose down --volumes --remove-orphans [+] Running 5/5 ✔ Container myapp-web Removed ✔ Container myapp-db Removed ✔ Volume myapp_db-data Removed ✔ Volume a3f7c2d1e9b48f2c... Removed ✔ Network myapp_default Removed

短縮形として `-v` も使えます（`--volumes` と同じ）。

# -v は --volumes の短縮形 $ docker compose down -v --remove-orphans

3. --remove-orphans で孤児コンテナを掃除する

compose.yml からサービスを削除したとき、古いコンテナが「孤児コンテナ（orphan container）」として残ることがあります。

たとえば、以前 `worker` サービスを定義していたが compose.yml から削除した場合、`docker compose down` だけでは `worker` コンテナが残ります。

# 孤児コンテナの警告例（compose upやdownで表示される） WARN[0000] Found orphan containers ([myapp-worker]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. # --remove-orphans で孤児コンテナも削除 $ docker compose down --remove-orphans

トラブルシュート｜よくある「消えた/残った」の原因

【事例1】「down したのにデータが消えた」

`docker compose down --volumes` または `docker compose down -v` を意図せず実行した可能性があります。また、compose.yml でボリュームを名前付きで定義せず匿名のまま使っていた場合、ボリュームが `docker volume prune` で削除されることもあります。

対策：本番環境では必ずボリュームを名前付きで定義し、`--volumes` フラグの使用はスクリプト・CI/CDの構成レベルで制限します。

【事例2】「ディスクが減らない、ボリュームが積み上がる」

`docker compose down` のみで繰り返し停止・起動していると、匿名ボリュームが蓄積します。`docker volume ls -f dangling=true` で確認し、不要なものは `docker volume prune` で削除します。

# どのコンテナも使っていない匿名ボリュームをまとめて削除 $ docker volume prune WARNING! This will remove anonymous local volumes not used by at least one container. Are you sure you want to continue? [y/N] y Deleted Volumes: a3f7c2d1e9b48f2c91d0e4f3a2b1c9d8 b8e2f4d6c1a3e5f7d9b0c2e4f6a8c0d2 Total reclaimed space: 1.85GB

【事例3】「down 後に up したら設定が反映されていない」

`down` せずに `stop` → `start` を繰り返している場合、compose.yml の変更がコンテナに反映されません。compose.yml の変更を反映するには `docker compose down` してから `docker compose up` し直す必要があります。

【事例4】「external ネットワークが消えた」

`external: true` を付けていないネットワークは `down` で削除されます。複数の compose プロジェクト間で共有するネットワークは `external: true` で保護します。

# 共有ネットワークを external で保護する設計 networks: shared-net: external: true # down しても削除されない

本記事のまとめ

`docker compose down` と `docker compose stop` の違い、および停止時のリソースライフサイクルをまとめます。

やりたいこと	コマンド
一時停止して後で再開（データ・設定を完全保持）	`docker compose stop`
コンテナとネットワークを片付ける（ボリュームは残す）	`docker compose down`
ボリュームも含めて完全削除（開発環境クリーン用途）	`docker compose down --volumes`
孤児コンテナも一緒に削除する	`docker compose down --remove-orphans`
不要な匿名ボリュームをまとめて削除する	`docker volume prune`
ボリュームの使用量を確認する	`docker system df`

停止設計の基本は「本番は `down` のみ（ボリューム保護）、開発は `down --volumes --remove-orphans`（完全クリーン）」で使い分けることです。匿名ボリュームはデフォルトで残り続けるため、定期的に `docker volume ls` と `docker system df` で使用量を把握する運用習慣をつけておきましょう。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、本記事で紹介した Docker Compose の停止設計・ボリューム管理をはじめとする Docker の実践スキルを体系的に学べる講座を用意しています。
→ Dockerマスター講座の詳細はこちら＞＞

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。