TL;DR
Dockerは存在しないディレクトリをマウントできません。まず作成してから、コンテナを再実行してください：
mkdir -p /path/to/your/host/directory
docker run -v /path/to/your/host/directory:/container/path your-image
Docker Composeの場合は、docker compose upを実行する前にフォルダを手動で作成するか、名前付きボリュームに切り替えてDockerに管理させてください。
このエラーの原因
エラーの全文は以下のとおりです：
Error response from daemon: invalid mount config for type "bind": bind source path does not exist
バインドマウントは、ホストのディレクトリをコンテナのファイルシステムに直接リンクする仕組みです。Dockerはそのディレクトリを自動作成しません。事前に存在している必要があります。名前付きボリュームは異なり、Dockerが自動管理します。バインドマウントの場合、ソースパスを用意するのはあなたの責任です。
よくある原因：
- ホストパスのタイポ（例：
/data/myappの代わりに/dat/myappと入力してしまう） - パスが間違ったワーキングディレクトリを基準にしている
- ディレクトリが削除されたか、最初から作成されていなかった
- Windows/WSL2で：WindowsとUnixのパス形式を混在させている
- Docker Composeの
volumesブロックが存在しないホストパスを指している
修正1：不足しているホストディレクトリを作成する
ほとんどの場合、これだけで解決します。-vフラグのパスを確認して作成してください：
# 失敗しているコマンド
docker run -v /data/myapp/config:/app/config myimage
# 不足しているディレクトリを作成
mkdir -p /data/myapp/config
# 再実行 — これで動くはずです
docker run -v /data/myapp/config:/app/config myimage
-pフラグを使うと、mkdirが親ディレクトリをまとめて作成します。/dataを作成してから/data/myappを個別に作成する必要はありません。
修正2：まずタイポを確認する
新しいものを作成する前に確認する価値があります。パスはすでに存在しているが、スペルが違うだけかもしれません：
# 存在するか確認
ls -la /data/myapp/config
# 一行で確認
[ -d /data/myapp/config ] && echo "exists" || echo "missing"
一文字違うだけで別のパスになります。/data/myappと/dat/myappはまったく異なるパスです。各セグメントをしっかり確認してください。
修正3：Docker Compose — 相対パスと名前付きボリューム
多くの人がはまる罠です。このdocker-compose.ymlを見てください：
services:
app:
image: myimage
volumes:
- ./config:/app/config
./configはdocker-compose.ymlが存在するディレクトリを基準に解決されます。configフォルダが存在しない場合、Dockerはすぐにエラーになります。修正は簡単です：
# docker-compose.ymlと同じディレクトリで実行
mkdir -p config
docker compose up -d
事前にそのディレクトリにファイルが必要なければ、名前付きボリュームに切り替えましょう：
services:
app:
image: myimage
volumes:
- app-config:/app/config
volumes:
app-config:
名前付きボリュームは初回実行時にDockerが自動で作成します。ホストから直接ファイルを読み書きする必要がある場合（設定ファイル、ビルド成果物、リアルタイムで確認したいログなど）にはバインドマウントを使用してください。
修正4：WindowsとWSL2のパス形式
WindowsのDocker Desktopはパス形式に厳格です。ターミナルに合わない形式を使うと、毎回このエラーが発生します。
PowerShellまたはCMDから：
# 誤り — Unixスタイルのパスは解決されない
docker run -v /c/Users/you/data:/app/data myimage
# 正しい — Windowsのバックスラッシュ
docker run -v C:\Users\you\data:/app/data myimage
# これも正しい — スラッシュでも動作する
docker run -v C:/Users/you/data:/app/data myimage
WSL2ターミナルからは、Linuxパスを使用してください：
# ネイティブWSL2パス
docker run -v /home/you/data:/app/data myimage
# WSLからWindowsのCドライブにアクセス
docker run -v /mnt/c/Users/you/data:/app/data myimage
ルール：実行しているシェルに合ったパス形式を使用してください。
修正5：空の環境変数
設定されているように見えて実際は未設定の変数は、壊れたパスを黙って生成します：
# $DATA_DIRが未設定の場合、-v :/app/data になり即座にエラーになる
docker run -v $DATA_DIR:/app/data myimage
# まずデバッグ
echo "DATA_DIR=${DATA_DIR}"
# 空に展開されないようにフォールバックを追加
docker run -v ${DATA_DIR:-/tmp/myapp-data}:/app/data myimage
未設定の変数は空文字列に展開されます。Dockerは-v :/app/dataと解釈し、どこも指さないパスになります。
修正を確認する
コンテナが起動しましたか？マウントが正しく設定されているか再確認してみましょう：
# 名前付きコンテナを起動
docker run -d --name test-bind -v /data/myapp/config:/app/config myimage
# 起動を確認
docker ps | grep test-bind
# マウントの詳細を確認
docker inspect test-bind --format '{{ json .Mounts }}' | python3 -m json.tool
出力の中に"Type": "bind"と、期待するソースパスと宛先パスが含まれているか確認してください。正しければ完了です。
Composeスタックの場合：
docker compose up -d
docker compose ps
docker compose exec app ls /app/config
クイックリファレンス
- 名前付きボリューム — Dockerが作成・管理する。ホストパス不要
- バインドマウント — コンテナ起動前にホストパスが存在している必要がある
- tmpfsマウント — メモリ上にのみ存在する。コンテナ停止時に消える
CI/CDで実行する場合は、Dockerコマンドの前にディレクトリのセットアップステップを追加してください：
mkdir -p ./data ./logs ./config
docker compose up -d
3秒の準備で、バインドマウントエラーをゼロにできます。