Dockerコンテナ開発が遅い理由とWSL2での最適化方法

Dockerを使って開発環境を整えたのに、「なぜかWebサーバーの応答が遅い」「ファイルの変更を検知するホットリロードが効きにくい」「ビルドにものすごく時間がかかる」といった経験はありませんか？

ローカルのPC(ホストOS)で直接動かすより、コンテナ経由だとパフォーマンスが落ちる…という現象は、多くの開発者が直面する課題です。

「でも、どちらも同じPCのSSDを使っているのだから、読み込み速度は変わらないはずでは？」そう思いますよね。しかし、実際にはファイルの「置き場所」と「コンテナへの見せ方」によって、パフォーマンスに天と地ほどの差が生まれるのです。

この記事では、その技術的な理由を解き明かします。

##ファイルはどこにある？3つの格納方法

まず、Docker環境でプロジェクトファイルを扱う方法を3つのパターンに整理してみましょう。

格納方法	概要	長所	短所
ホストOS(ローカル)	Dockerを使わず、ローカルPCに直接ファイルを置いて開発する状態。	- 最速 - 使い慣れたエディタで直接編集できる	- 環境差異が生まれやすい - 「Dockerの恩恵」がない
Bind Mount	ホストOSのフォルダを、そのままコンテナ内に「マウント」する。	- ホストOSのエディタで編集した内容が即時コンテナに反映される	- パフォーマンスが著しく低下する場合がある(特にMac/Windows)
コンテナ内ストレージ	Dockerが管理する領域(Volume)やコンテナイメージ内にファイルを格納する。	- コンテナからのアクセスが高速 - データの永続化や管理がしやすい	- ホストOSのエディタで直接編集するのが少し手間になる

多くの開発環境では、手元のエディタでコードを書きたいので②のBind Mountが採用されます。そして、このBind Mountこそが、パフォーマンス低下の主な原因となっているのです。

##なぜパフォーマンスに差が生まれるのか？

「同じSSD上にあるのに、なぜBind Mountは遅いのか？」

その答えは、特にDocker Desktop for Mac/Windowsのアーキテクチャに隠されています。

###Docker Desktopの仕組み

MacやWindows上でLinuxコンテナを動かすために、Docker Desktopは内部的に**軽量なLinux仮想マシン（VM）**を起動しています。私たちが操作するコンテナは、実はこのVMの中で動いています。

つまり、ファイルアクセスの裏側では、このようなやり取りが発生しているのです。

[ホストOS: macOS/Windows] <--> [Linux VM] <--> [Dockerコンテナ]

###Bind Mountが遅い理由：OS間のファイルシステム同期

Bind Mountを使うと、ホストOS(macOSやWindows)上のファイルを、Linux VM内のコンテナに見せることになります。ここにはファイルシステムの壁が存在します。

変換コスト: ホストOSのファイルシステムへのI/Oリクエストを、Linux VMのファイルシステムが理解できる形に変換・同期する必要があります。この処理には大きなオーバーヘッドが伴います。
イベント通知の遅延: ファイルの変更を監視する仕組み(inotifyなど)も、この「壁」を越える際に遅延が発生します。これがホットリロードが遅れたり、効かなかったりする原因です。

数千、数万のファイル(node_modulesやvendorなど)に対してこのオーバーヘッドが積み重なると、ビルドやサーバー起動は致命的に遅くなってしまうのです。

###Volumeやイメージ内ファイルが速い理由

一方、Docker Volumeは、このLinux VM内にDockerが管理する専用のディレクトリとして作成されます。コンテナからVolumeへのアクセスは、同じLinux VM内で完結するため、OSの壁を越える必要がありません。そのため、Bind Mountに比べて圧倒的に高速です。

DockerfileのCOPY命令でイメージ内に格納されたファイルも同様に、コンテナと同じファイルシステム内に存在するため最速でアクセスできます。

ホストOSがLinuxの場合、ホストとコンテナは同じLinuxカーネルを共有しているため、「OSの壁」は存在しません。そのため、Bind Mountによるパフォーマンス低下はMac/Windowsほど顕著ではありません。 ::

##WSL2環境での重要な注意点

Windows上でWSL2を使ってDockerを動かしている場合、根本的な問題は解決されません。

WSL2内でVolumeを使っても、プロジェクトファイルがWindowsファイルシステム(/mnt/c/)にある限り、コンテナがファイルにアクセスする際には必ずWindows-Linux間のファイルシステム変換が発生します。これは以下の理由によります：

マウント元の問題: Volumeに分離しても、docker-compose.ymlやdevcontainer.json自体がWindowsファイルシステムにある場合、設定の読み込み時点でWindows-Linux変換が必要
依存関係の解決: package.json、Dockerfileなどの設定ファイルがWindows側にあると、依存関係の解決時にクロスファイルシステムアクセスが発生
ファイル監視の問題: ホットリロードやファイル変更検知も、Windows-WSL2間のイベント通知の遅延が残る

WSL2での正しい解決策：

✅ プロジェクト全体をWSL2内に配置 (~/projects/)
❌ Windowsファイルシステムに配置 (/mnt/c/Users/...)
❌ Volume分離だけに頼る（根本解決にならない）

実用的なワークフロー：

# WSL2内でプロジェクトをクローン
cd ~/projects
git clone https://github.com/your-repo.git
cd your-repo
 
# VS CodeでWSL2内のフォルダを直接開く
code .

##Claude Code × Dev Container の推奨設定

Windows + WSL2環境での推奨アプローチ：

プロジェクトをWSL2内に配置
VS CodeのWSL拡張機能を使用
Dev Containerを起動

この順序により、Windows-Linux間の変換オーバーヘッドを最小限に抑えることができます。

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu24.04",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:latest": {},
    "ghcr.io/devcontainers-community/npm-features/typescript:1.1.0": {}
  }
}

##まとめ：速度と開発体験のバランス

Docker環境でのパフォーマンス問題は、「ファイルをどこに置くか」という根本的な設計で決まります。

重要なのは、環境に応じた正しい選択をすること：

Windows環境：

最優先 → WSL2内にプロジェクト配置
次善策 → 完全Volume + 同期ツール
避けるべき → WindowsファイルシステムでのVolume分離

Mac/Linux環境：

開発効率重視 → Volume分離 + Bind Mount
最高性能重視 → 完全Volume + 同期ツール

現代の開発では、Claude CodeのようなAIツールとの協調作業も増えています。そんな時こそ、待ち時間のない高速な開発環境が、創造性を最大限に引き出してくれるはずです。

あなたのプロジェクトも、この設定で「爆速Docker開発」を体験してみてください！