メインコンテンツまでスキップ

第26章：Windows特有の注意：ファイル共有が遅い/重いときの逃げ道🐢➡️🐇

この章はひとことで言うと、**「遅い原因は“バグ”というより“構造”なので、勝ち筋のルートへ逃げよう」**です😇✨ （特に Node/TypeScript は node_modules やビルド成果物で 小さいファイルが大量になりがちで、差がドカンと出ます💥）

🎯 この章のゴール（できるようになること）🏁​

  • 「なぜ遅いのか」を1分で説明できる🗣️
  • 自分のプロジェクトに合わせて、**最適な逃げ道（3択）**を選べる🧭
  • “置き場所ルール”を決めて、チームや未来の自分が迷わない📌

1) こんな症状、出てない？🫠💦（チェック）​

  • npm install / pnpm install が異常に遅い🐌
  • Hot Reload が効くまで数秒〜十数秒かかる😵
  • テスト（Jest/Vitestなど）が「待ち時間ゲー」になる⏳
  • ファイル監視（watch）が暴れてCPUが上がる🔥
  • 「コンテナは速いはずなのに、なんか全体が重い」🤔

当てはまるなら、次の「構造の話」が濃厚です👇

2) なぜ遅い？（超ざっくり）🧠🧱​

Windowsで Linux コンテナを動かすとき、実体は **Docker Desktop が用意する Linux 環境（VM/WSL2）**の中で動いてます。 なので、**Windows側のフォルダをコンテナに bind mount（共有）**すると、ファイルアクセスが「境界」を跨いでオーバーヘッドが積み上がりやすいんです📁➡️🧱➡️🐢。(Docker)

そして Docker 側も「WSL2 をちゃんと使うなら、プロジェクトは WSL2 側に置こうね（/mnt/c は遅くなりがち）」とハッキリ言っています。(Docker)

3) 逃げ道はコレ！おすすめ順に3本立て🐇✨​

逃げ道A（最強🔥）：コードを WSL2 側に置く📦➡️🐇​

結論：これがいちばん効きやすいです。 理由：WSL2 側の Linux ファイルシステム上のコードは、コンテナと“近い場所”にあるので速くなりやすい🧠✨。(Docker)

やり方（ざっくり手順）🪜

  1. WSL2 を最新に寄せる（地味に大事）🔄
  2. WSL2 のホーム配下にプロジェクトを作る（例：~/src/myapp）📁
  3. その場所から VS Code を開く（WSL 側で code .）🪟➡️🐧
  4. docker compose も WSL2 のターミナルから叩く🧑‍💻

コマンド例（WSLターミナルで）

## 例：WSL2 のホームに置く
mkdir -p ~/src
cd ~/src
git clone <YOUR_REPO> myapp
cd myapp

## VS Code を WSL 側から開く（重要！）
code .

ここが超重要ポイント⚠️

  • WSL2 に置いたのに、Windows側のVS Codeで直接フォルダ開くと、効果が薄くなることがあります🙃 → “WSL側から開く”がコツです🐧✨（Dockerも VS Code もこのルートを推しています）(Docker)

逃げ道B（現実的で強い💪）：node_modules など重いフォルダだけ named volumeへ🧳​

「コードは共有したい（編集の都合）」けど、node_modules や dist が重い…というときの鉄板です🧠✨ VS Code公式も「Windows/macOSは bind mount が遅いことがあるので、node_modules みたいな重い場所は named volume に逃がそう」と案内しています。(Visual Studio Code) Docker側も同じ方向性で、「named volume は VM 内にあるから速い」系の説明をしています。(Docker)

Composeの例（典型パターン）🐳

  • コード：bind mount（編集しやすい）
  • node_modules：named volume（速い）
services:
  api:
    build: .
    volumes:
      - ./:/app
      - api_node_modules:/app/node_modules
    command: npm run dev

volumes:
  api_node_modules:

ありがちな落とし穴🪤

  • ./:/app をマウントすると、ホスト側の node_modules が /app/node_modules を上書きして事故ることがあります💣 → だから上のように **volumeで“上からかぶせて守る”**のが定番です🛡️✨

逃げ道C（ラク＆速い😎）：Dev Containers で リポジトリ自体を volume にクローンする📦✨​

VS Code には、**「コンテナ用のvolumeにリポジトリをクローンして開く」**という選択肢があります。 「bind mount を避けられる＝速い」ので、Windowsではかなり効くことがあります🚀。(Visual Studio Code)

向いてる人🙋

  • “編集はVS Code上でできればOK”
  • “ホスト側にソースがある必要はない（Gitで管理する）”

注意点⚠️

  • 仕組み的に「ホストのフォルダをそのまま編集」ではなくなるので、最初は違和感あるかも😂 でも「速いは正義」ってなる場面、かなり多いです🫶

4) さらに別ルート：Compose Watchで「同期」する👀⚡​

最近の Docker Compose には、ファイル変更を検知してコンテナへ sync / sync+restartできる “Watch” があります。 docker compose up --watch や docker compose watch で使います。(Docker Documentation)

イメージ

  • bind mount に頼りすぎず、「必要なものだけ同期」できるので、構成によっては快適になります🧠✨

例（node_modulesは除外しがち）

services:
  web:
    build: .
    command: npm start
    develop:
      watch:
        - action: sync
          path: .
          target: /app
          ignore:
            - node_modules/

5) “速くなった？”を確認するミニ実験🧪⏱️​

改善は体感だけじゃなく、同じ作業で時間を測るのがいちばん確実です📏✨

おすすめ計測（どれか1個でOK）👇

  • 依存インストール：npm ci（または pnpm install）📦
  • テスト：npm test 🧪
  • ビルド：npm run build 🏗️

コツ

  • 変更前/変更後で同じコマンドを2回ずつ回して、2回目（キャッシュ後）も見る👀✨ 2回目が劇的に速くなるなら、I/O境界の影響が強めです🧠

6) 成果物：「置き場所ルール」テンプレ📌📝​

最後に、あなたのプロジェクト用にこれだけ決めればOKです🙆‍♂️✨

  • ✅ ソースコードはどこ？（例：WSL2 ~/src）🐧
  • ✅ node_modules はどこ？（例：named volume）🧳
  • ✅ 生成物（dist/.next/キャッシュ）はどこ？（必要なら volume）🏗️
  • ✅ Compose Watch を使う？（使うなら ignore 方針）👀
  • ✅ “遅くなったら見る場所”メモ（まず mount と置き場所）🔎

7) AIの使いどころ🤖✨（安全にね🔒）​

  • docker compose.yml と「遅い症状」を貼って 「どのマウントがボトルネックになりそう？逃げ道A/B/Cどれが合う？」って聞くと、整理が速いです🧠⚡
  • ただし 秘密（鍵/トークン/本番DB情報）は貼らないのは鉄則です🔐 （拡張機能なら GitHub の Copilot や OpenAI 系でも同じルールで🛡️）

まとめ🐇🎉​

  • Windowsで遅いのは「境界越えI/O」が原因になりがち。(Docker)
  • 最強の対策は WSL2側にコードを置く（Dockerも推奨）。(Docker)
  • 現実解は node_modules を named volume に逃がす（VS Code公式の鉄板）。(Visual Studio Code)
  • さらに、Dev Containers の “volumeにクローン” や Compose Watch も武器になる。(Visual Studio Code)

次の章で「Docker Desktopの丸ごとバックアップ」へ行く前に、この章の“置き場所ルール”だけは決めちゃうと、今後の運用がめちゃ楽になりますよ📦✨