Docker Composeを使っていて、

docker compose down

を実行したはずなのに、

• コンテナが残っている
• docker ps -a に表示され続ける
• 再起動すると影響が出る

といった状況になったことはありませんか。

この記事では、Docker compose downしてもコンテナが残る主な原因と、正しく片付けるための確認ポイントを、Mac環境向けに解説します。

※ 本記事は Mac + Docker Desktop + Docker Compose を前提に説明します。

この記事でわかること

• docker compose down の動作範囲
• コンテナが残る典型的な原因
• 正しい削除手順
• 混乱しやすいポイントの整理

docker compose down の基本動作

docker compose down は、同じComposeプロジェクトに属するリソースのみを停止・削除します。

対象になるのは：

• コンテナ
• ネットワーク（Composeで作成されたもの）

👉 すべてのDockerリソースを消すコマンドではありません。

原因① 別のComposeプロジェクトとして扱われている

Docker Composeは、
プロジェクト名でリソースを管理します。

以下のような場合、
同じように見えても別プロジェクト扱いになります。

• 実行ディレクトリが違う
• -p オプション付きで起動した
• プロジェクト名が自動生成で変わっている

確認方法

docker ps -a

の NAMES 列を確認し、
想定と違う名前になっていないかチェックします。

原因② 別の docker-compose.yml を使って起動している

次のようなケースもよくあります。

• 起動時：別ファイルを指定

docker compose -f docker-compose.dev.yml up

• 停止時：デフォルトファイルで実行

docker compose down

この場合、停止対象が一致せず、コンテナが残ります。

対処法

起動時と同じファイル指定で down します。

docker compose -f docker-compose.dev.yml down

原因③ ボリュームは削除対象外になっている

docker compose down では、
ボリュームはデフォルトで削除されません。

対処法（必要な場合）

docker compose down -v

※ データも削除されるため、注意して実行してください。

原因④ Compose外で作成されたコンテナが混在している

次のようなコンテナは、
docker compose down では削除されません。

• docker run で起動したコンテナ
• 別プロジェクトのコンテナ

対処法

不要なコンテナを個別に削除します。

docker rm コンテナID

原因⑤ コンテナは停止しているが削除されていない

停止はされているが、
削除されていない状態のこともあります。

確認方法

docker ps -a

対処法

docker rm コンテナID

よくある勘違い

• docker compose down = 全部消える
  → ❌ プロジェクト単位のみ
• docker compose up した場所は関係ない
  → ❌ 実行ディレクトリが重要
• ボリュームも自動で消える
  → ❌ 明示指定が必要

それでも整理できない場合

一度、不要リソースをまとめて整理します。

docker system prune

※ 実行前に削除対象を必ず確認してください。

まとめ

Docker compose downしてもコンテナが残る場合は、

• プロジェクト名が違う
• composeファイル指定が違う
• ボリュームが残っている
• Compose外コンテナが混在している

のいずれかが原因です。

起動時と停止時の条件を揃えることが、
最も重要なポイントです。