エラーの内容
Error response from daemon: network myapp_default not found
このエラーは、以前に停止したコンテナに対して docker compose start または docker compose up を実行した際に発生します。コンテナが参加しようとするネットワークをDockerが見つけられない場合に表示されます。
発生原因
Docker Composeはプロジェクトごとに専用のネットワークを作成します。デフォルトの名前は {project}_default です。このネットワークが孤立したり削除されたりする状況は以下の通りです:
docker compose down（ネットワークも削除される）を実行した後、docker compose upではなくdocker compose startで再起動しようとした場合- 誰かが手動でDockerネットワークを削除した場合:
docker network prune - プロジェクトディレクトリの名前を変更した場合 — プロジェクト名が変わると、期待されるネットワーク名と一致しなくなる
- 別のツールやスクリプトが実行間に未使用のネットワークをクリーンアップした場合
コンテナは停止した状態で残っています。どのネットワークに属しているかは記憶していますが、そのネットワーク自体が削除されています。
手順ごとの修正方法
方法1: すべて再作成する（最も手軽）
コンテナの状態を保持する必要がない場合は、一度すべて削除してから再起動します:
docker compose down
docker compose up -d
docker compose down は停止中のコンテナとネットワークをきれいに削除します。docker compose up は新しいネットワークを作成してすべてを起動します。これで90%のケースは解決します。
方法2: 不足しているネットワークだけを再作成する
既存のコンテナを保持したままネットワークだけを修正したい場合は、手動で作成します:
# 期待されるネットワーク名を確認する
docker compose config | grep -A5 'networks'
# 実際に存在しないことを確認する
docker network ls | grep myapp
# ネットワークを作成する
docker network create myapp_default
その後、サービスを起動します:
docker compose start
ネットワーク名は {project_name}_default というパターンに従います。プロジェクト名は通常ディレクトリ名です。以下のコマンドで確認できます:
docker compose config --format json | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('name',''))"
または、エラーメッセージを確認するだけでも構いません — どのネットワークが不足しているか（この例では myapp_default）が正確に表示されています。
方法3: compose.yamlにネットワークを明示的に定義する
このエラーが繰り返し発生して困っていますか？compose.yamlにネットワークを固定して、ライフサイクルを自分で管理しましょう:
services:
web:
image: nginx
networks:
- app-net
db:
image: postgres
networks:
- app-net
networks:
app-net:
name: myapp_default # 固定名。ディレクトリ名を変更しても影響なし
driver: bridge
name を固定することで、プロジェクトディレクトリの名前を変更しても何も壊れません。プロジェクトの場所に関わらず、ネットワーク名は安定したままです。
方法4: 外部ネットワークを使用する
複数のComposeスタックが同じネットワークを共有している場合は、外部ネットワークとして宣言します:
# 一度だけ手動で作成する
docker network create shared_net
# compose.yaml内での設定
networks:
shared_net:
external: true
external: true を指定すると、up や down 時にComposeはそのネットワークに触れません — ライフサイクルは別途管理します。共有データベースやTraefikのようなリバースプロキシに適した方法です。
修正の確認
# ネットワークが存在することを確認する
docker network ls | grep myapp_default
# コンテナがネットワークに接続されていることを確認する
docker network inspect myapp_default
# サービスが起動していることを確認する
docker compose ps
docker network inspect の結果で Containers セクションを確認してください。サービスが起動したら、すべてのコンテナがそこに表示されるはずです。
補足情報
stop ではなく docker compose down を使う
docker compose stop はコンテナを一時停止しますが、コンテナとネットワーク参照はそのまま残ります。docker compose start で問題なく再開できます。問題が起きるのは、停止と起動の間にネットワークが消えてしまう場合です — 主に docker network prune が原因です。手動でネットワークをクリーンアップした後は、start ではなく docker compose up を使ってください。
ディレクトリ名の変更に注意
プロジェクトフォルダを移動したり名前を変更したりすると（例: mv myapp myapp-v2）、ComposeのプロジェクトIDが変わり、期待されるネットワーク名が壊れます。停止中のコンテナは myapp_default を参照し続けますが、Composeは myapp-v2_default を探すようになります。.env ファイルでプロジェクト名を固定しましょう:
# .env
COMPOSE_PROJECT_NAME=myapp
ネットワークのサブネット競合をデバッグする
多くのスタックが動作している環境では、サブネットの競合によりDockerがネットワークの再作成に失敗することがあります。docker compose up がネットワーク作成でハングする場合は、まず既存のネットワークとそのサブネットを確認してください。ToolCraftのSubnet Calculatorを使えば、CIDRの範囲を計算して重複を避けるのが簡単になります。compose.yamlにサブネットをハードコードする方法もあります:
networks:
app-net:
driver: bridge
ipam:
config:
- subnet: 172.28.0.0/16
ネットワークリセット後に孤立したコンテナをクリーンアップする
# 有効なネットワークを持たなくなったコンテナを削除する
docker compose down --remove-orphans
docker compose up -d
--remove-orphans は、composeファイルに存在しないサービスのコンテナを削除します。大規模なネットワークリセットの後にこのコマンドを実行して、クリーンな状態から始めてください。