Skip to main content

第21章：“ファイルが遅い”問題：Windows×コンテナの現実 🪟🐢⚡️

この章はひとことで言うと―― **「Dockerが遅いんじゃなくて、“ファイルの置き場所”が遅い」**ことがめっちゃ多いよ！って話です😇📁

✅ まず結論：これだけ覚えれば勝ち 🏆✨​

速くしたいなら、プロジェクトは “WSLのLinux側” に置く！

  • NG（遅くなりがち）：C:\... のプロジェクトをコンテナにマウント（WSLでは /mnt/c/...）
  • OK（速くなりやすい）：WSL内の ~/src/myapp みたいな場所（Linuxファイルシステム）で作業

Docker公式も、Linuxコンテナにバインドマウントするファイルは Linux ファイルシステム側に置くのがおすすめ、さらに /mnt/c を避けてね、そして inotify（変更検知）もLinux側に置かないと届かないよ と言っています。(Docker Documentation)

🧠 なんで遅くなるの？（超ざっくり図解）🧩​

イメージはこれ👇（“境界線”をまたぐと遅い）

(速い)  Linux側（WSLのext4）         (遅くなりがち) Windows側（NTFS）
   ~/src/myapp  ─────→  コンテナ         C:\src\myapp ─→ /mnt/c/src/myapp ─→ コンテナ
        ↑                     ↑                 ↑                 ↑
   Linuxのまま              Linuxのまま      変換・共有が入る     変換・共有が入る

Windowsの C:\ をコンテナに見せるとき、裏で「共有」「変換」「通知（ファイル変更）」みたいな処理が増えやすく、大量ファイル（node_modules / monorepo / dist / .git）で爆死しがちです😵‍💫📦

🔍 “いま遅いルートを踏んでるか”一発チェック ✅​

WSL（Ubuntuなど）でプロジェクトフォルダに移動して、pwd を見るだけ！

  • pwd が /mnt/c/... なら：遅くなりやすいゾーン😇
  • pwd が /home/<you>/... なら：速くなりやすいゾーン🚀

🛠️ 最速ルート：プロジェクトをWSL側へ引っ越す（手順）🚚✨​

1) WSLを最新寄りにする（安定＆速さの土台）🧱​

Docker Desktop + WSLは、**WSLは新しめ推奨（最低でも 2.1.5）**とされています。(Docker Documentation)

Windows PowerShellで（例）：

wsl --update
wsl --version

2) WSL側に作業ディレクトリを作る📁​

WSLのターミナルで：

mkdir -p ~/src
cd ~/src

3) ここにgit clone（またはコピー）する🐙​

例：

git clone <your-repo> myapp
cd myapp

4) VS Codeは「WSLで開く」が最強 🧑‍💻✨​

WSL側で myapp にいる状態で：

code .

VS Codeが WSL接続モードになって、編集は快適・実行も速い、になりやすいです🎉

5) Docker/Composeは “WSL側ターミナル” から叩く🐳​

docker compose up --build

これで、バインドマウントがLinuxファイルシステム由来になって、体感が変わることが多いです⚡️

🧪 ミニ演習：体感差を“数字”で記録しよう 📊📝​

演習A：npm/pnpmの速度比較（おすすめ！）📦⚡️​

同じプロジェクトを

  1. C:\...（= /mnt/c/...）側
  2. ~/src/...（Linux側） で用意して、WSLからそれぞれ実行：
time npm ci

結果をメモ👇

  • /mnt/c 側：____ 秒
  • ~/src 側：____ 秒
  • 差：____ 秒（体感：😇/😊/🤩）

演習B：ホットリロードの反応速度（inotify体験）👀🔁​

ファイルを保存してから、コンテナのログが反応するまでの体感をメモ。 Linux側に置くと変更検知（inotify）が届きやすいので、ここも差が出やすいです。(Docker Documentation)

😭 よくある落とし穴あるある（先に潰そう）🪤​

  • 「WSL使ってるのに遅い」 → 実はプロジェクトが /mnt/c/...（Windows側）にあるパターンが多いです😇
  • ホットリロードが不安定 → Linux側にファイルがないと inotify が届かないことがあるよ、が公式の注意点です。(Docker Documentation)
  • vmmem がメモリ食いまくる → WSLやDocker Desktopのドキュメントでも、WSLを新しめにするのが大事と言及があります。(Docker Documentation)
  • 「じゃあDocker Desktopの“同期共有”使えば？」 → それ、実は WSL利用時は使えません（使えるのは別条件＆サブスク等あり）。(Docker Documentation)

🤖 AI活用：Copilot / Codex に投げる“診断プロンプト”集 🧰✨​

プロンプト1：遅さの原因特定（置き場所チェック）​

Docker Desktop + WSL2 環境です。
コンテナのファイルI/Oが遅いです。
いまのプロジェクトは /mnt/c 配下にあります。これが原因になり得るか？
Linux側（~/src）へ移す手順と、速度比較の測り方も提案して。

プロンプト2：compose.ymlのマウント設計レビュー​

以下の compose.yml の volumes が、Windows+WSL2 で遅くなる可能性があるかレビューして。
改善案を「手間が少ない順」に3つ出して。
（貼り付け：compose.yml）

プロンプト3：ホットリロードが効かない原因切り分け​

Node/TypeScript のホットリロードが不安定です。
Windows+WSL2+Docker で、inotify/ファイル変更通知が原因になり得るか？
チェック手順と、確実に動く構成案をください。

✅ この章のまとめ（持ち帰り）🎁​

  • 遅さの本体は “ファイルの置き場所” になりがち📁🐢
  • /mnt/c（Windows側）を避けて、WSLのLinux側（~/src）へ置くのが鉄板💪
  • 変更検知（ホットリロード）も Linux側のほうが安定しやすい👀🔁(Docker Documentation)
  • 「同期共有」みたいな別ルートもあるけど、WSLでは使えないなど条件があるので、まずは王道で勝つ🏆(Docker Documentation)

次の第22章が「node_modulesは共有しない（爆速化）」なので、第21章で“置き場所”を直してから第22章に進むと、伸びがめちゃ大きいです😆📈✨