Skip to main content

第04章：“遅さの4大犯人”を覚える 🕵️‍♂️🐳⚡️

この章は「遅い理由を“当てずっぽう”で直さない」ための回です😆✨ Dockerが遅いとき、だいたい犯人はこの4人のどれかです👇

  1. ビルドコンテキストが巨大（送ってる荷物がデカすぎ📦💦）
  2. 依存インストールが毎回走ってる（毎回“引っ越し”してる🚚）
  3. COPY順ミスでキャッシュが壊れてる（一瞬でやり直し地獄🔥）
  4. ファイル共有が遅い（Windows×コンテナの“あるある”🐢）

ここで犯人を1人でも特定できると、次章以降の改善がめちゃ効きます🚀

まず結論：4大犯人・症状からの当たり付け表 👀🧭​

  • ビルド開始直後にやたら待つ / ログに「context転送」っぽいのが長い → 犯人① コンテキスト巨大（送る量が多いほど遅くなる） (Docker Documentation)

  • コード1行変えただけなのに npm ci / pnpm install が毎回走る → 犯人② or ③（依存のキャッシュが効いてない） (Docker Documentation)

  • Dockerfileを見たら早い段階で COPY . . してる → 犯人③ COPY順ミス（小さな変更で全部やり直し🔥） (Docker Documentation)

  • 起動はするけど、保存→反映が遅い / watchが重い / node_modules絡みが激遅 → 犯人④ ファイル共有（置き場所で速度が変わる） (Docker Documentation)

犯人①：ビルドコンテキスト巨大 🎒➡️📦​

何が起きてるの？🤔​

Dockerはビルドするとき、まず「ビルドに必要なファイル一式（=コンテキスト）」をビルダーに渡します。 これがデカいと、転送・スキャン・ハッシュ計算が増えて遅くなります😵‍💫 公式も「コンテキストは小さく」が大事って言ってます。 (Docker Documentation)

ありがち原因 🙈​

  • node_modules/ が入ってる
  • dist/ や build/ が入ってる
  • .git/ が入ってる
  • ログ、画像、動画、zip、バックアップが混ざってる

見つけ方（ログで一発）🔎​

ビルドログを“素朴に”して確認します👇

docker buildx build --progress=plain -t temp-check .

ログの序盤に、context転送っぽい行が長い/重いならかなり怪しいです👀 （BuildKitの最適化指南でも「Keep the context small」が重要ポイントです） (Docker Documentation)

犯人②：依存インストールが毎回走ってる 📦🔁💥​

何が起きてるの？🤔​

npm ci や pnpm install は時間がかかる重労働😇 本当は「依存ファイルが変わらない限り、そこはキャッシュでスキップ」したいのに、何かのせいで毎回やり直しになってます。

よくある“やらかし”😵​

  • package.json やロックファイルが、ソースと一緒にCOPYされてる
  • COPY . . のせいで、ちょっとした変更でも依存レイヤが無効化される

見つけ方（最短チェック）✅​

1回ビルドしたあと、ソースコードだけ1行変更して、もう1回ビルド👇

docker buildx build --progress=plain -t temp-check .

2回目も npm ci / pnpm install が走ったら、犯人②が濃厚です😇

ここは次章以降で「キャッシュが効くDockerfile」に直すと劇的に改善します🔥 (Docker Documentation)

犯人③：COPY順ミスでキャッシュが壊れてる 🧱💣​

何が起きてるの？🤔​

Dockerfileは命令ごとに“段（レイヤ）”が積まれます。 で、上の段が変わると下の段も作り直しになります😱 だから 「変わりにくいもの → 変わりやすいもの」 の順に置くのが超大事！ (Docker Documentation)

典型パターン（危険⚠️）​

## 例：危ない（よくある）
COPY . .
RUN npm ci

これ、ソース1行変えただけで COPY . . が変わる → npm ci もやり直し、になりがちです🔥

見つけ方（Dockerfileを見て1秒）👀​

  • COPY . . が 依存インストールより先 にある → ほぼ犯人③です🕵️‍♂️

公式の“キャッシュ最適化”でも「レイヤの順序を工夫してキャッシュ無効化を避けよう」が大事って書かれてます。 (Docker Documentation)

犯人④：ファイル共有が遅い（Windows×コンテナ）🪟🐢​

何が起きてるの？🤔​

開発中は「ホストのファイルをコンテナに見せる（共有/マウント）」ことが多いです。 でもこれ、置き場所しだいで速度が激変します😵‍💫

Docker DesktopのWSL周りのベストプラクティスでも、バインドマウントするならLinux側ファイルシステムに置くのが推奨されています。 (Docker Documentation)

ありがちな症状 😭​

  • 保存しても反映が遅い
  • tsc -w や vite の検知が遅い
  • node_modules が絡むと急に激重
  • コンテナは速いのに、編集がモタモタする

見つけ方（体感でOK）🫠​

  • 反映が“ワンテンポ遅い”どころか、数秒〜十数秒なら、だいたいこれです🐢

対策は次の章以降でちゃんとやるけど、まずは「これが犯人だ」と気づくのが勝ちです🏆

🧪ミニ演習：自分のプロジェクトで犯人を1人捕まえる ✍️🚔​

目的：“遅い理由”を言語化してメモに残す（これだけで改善が速くなる！）✨

手順（5〜10分）⏱️​

  1. まずビルド（ログを見やすく）
docker buildx build --progress=plain -t perf-check .

  1. ソースを1行だけ変更（例：コメント1行）📝

  2. もう一回ビルド

docker buildx build --progress=plain -t perf-check .
  1. 2回目のログで「どこが再実行されたか」を見る👀
  • context転送が長い → 犯人①
  • 依存インストールが走る → 犯人②/③
  • 編集反映が遅い → 犯人④

「遅さ捜査メモ」テンプレ（コピペOK）📒✨​

【今日の遅いポイント】
- 症状：
- 2回目ビルドで再実行された工程：
- 犯人候補：①/②/③/④
- 根拠（ログ or 体感）：
- 次にやる章（予定）：

🤖AI活用：4大犯人を“自動であぶり出す”プロンプト集 🧠⚡️​

1) Dockerfileレビュー（キャッシュ壊しポイント探し）🔍​

次のDockerfileをレビューして、ビルドが遅くなる原因を「4大犯人（①コンテキスト巨大 ②依存毎回 ③COPY順ミス ④ファイル共有遅い）」の観点で指摘して。
特に「キャッシュが壊れる命令」と「直すとしたら順序をどう変えるか」を具体的に提案して。

2) compose.ymlレビュー（共有が遅くなる構成探し）🧩​

次のcompose.ymlを見て、Windows環境で遅くなりそうなポイント（特にボリューム/バインドマウント/共有対象）を洗い出して。
改善案を「変更が小さい順」に3つ出して。副作用（開発体験の変化）も書いて。

3) ログ貼り付けで原因特定（捜査官AI）🕵️‍♀️​

以下は docker buildx build --progress=plain のログです。
遅い箇所トップ3と、それぞれが4大犯人のどれに当たるかを分類して。
一番効きそうな“最小の修正”を1つだけ提案して（理由付き）。

よくある落とし穴Q&A 😵‍💫💡​

  • Q. “イメージが重い”＝“ビルドが遅い” なの？ A. だいたい関係あります！特に依存や生成物が混ざると、転送もビルドも重くなりがちです📦💦（公式のビルドベストプラクティスでも不要物を避けたり、.dockerignoreやキャッシュ活用が推されてます）(Docker Documentation)

  • Q. “速くする”って結局どこから触るのが正解？ A. まずはこの章みたいに「犯人を決める」→ 次章で コンテキスト削減 が最短で効きやすいです🎯 (Docker Documentation)

次章予告 🎒🪶​

次は ビルドコンテキストを小さくする（.dockerignore中心）で、体感レベルで速くします⚡️ この章で捕まえた犯人①が、いちばん気持ちよく倒せます😆💥