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

第03章：BuildKitが速い理由（現代Dockerの標準）🚀🧱⚡️

この章のゴールはシンプル！ **「BuildKitの“速さの正体”が分かって、ログを見て“重い工程”を当てられる」**ようになることです🎯✨ （次章以降でキャッシュ技を入れるとき、ここが分かってると爆速で伸びます🔥）

1) そもそもBuildKitって何？🤔🐳​

BuildKitは、いまのDockerで使われている新しいビルドエンジンです。 Docker DesktopではBuildKitがデフォルトで、Docker Engineでも 23.0以降はデフォルトになっています。(Docker Documentation) さらに、昔の“クラシック（レガシー）ビルダー”は**非推奨（将来的に削除予定）**の流れです。(Docker Documentation)

つまり… ✅ 速くするならBuildKit前提 ✅ いま学ぶのが一番コスパ良い💰✨

2) BuildKitが速い「3つの理由」⚡️⚙️🧠​

理由A：ビルドを“上から順”じゃなく“グラフ”で考える 🗺️​

昔の感覚だと「Dockerfileは上から順に実行」っぽいですよね。 でもBuildKitは、内部的に 依存関係（どれがどれに必要か）を見て、実行計画を最適化します。(Docker Documentation)

イメージ（雰囲気でOK）👇

【昔】直列っぽい
step1 → step2 → step3 → step4 → ...

【BuildKit】依存が無い所は並べる（DAGっぽい）
      ┌→ step2 ─┐
step1 ┤          ├→ step4
      └→ step3 ─┘

理由B：並列化できるところは並列にする 🏎️💨​

BuildKitは並列実行を活用して、待ち時間を削ります。(Docker Documentation) （CPUが複数コアある現代PCだと、ここが効きやすいです🔥）

理由C：キャッシュの扱いが賢い（“高度なキャッシュ”）🧱✨​

BuildKitはキャッシュ最適化・高度な機能が強いです。(Docker Documentation) この章では「へぇ〜」でOK。次の章以降で、

  • キャッシュが壊れにくいDockerfile順序
  • キャッシュマウント
  • 外部キャッシュの持ち運び

みたいな“必殺技”に繋がっていきます🪄⚡️

3) まず確認：あなたのDocker、BuildKit動いてる？✅🔍​

ふつうは動いてます（今はデフォルトなので）(Docker Documentation) でも「環境変数で無効化してた」みたいなケースもあるので、ログの出し方を覚えればOKです👍

4) ログを“見える化”する：--progress=plain が超大事📜👀​

BuildKitはデフォルトだとログが「見やすいUI」寄りで、過去ステップの出力が折りたたまれたりします。 全部ベタ出ししたいときはこれ👇 (matsuand.github.io)

docker build --progress=plain -t myapp .

ポイント

  • plain にすると、各ステップの出力が“流れるログ”で追いやすい📜
  • どの工程が重いか、当てやすくなる🎯

5) 🧪ミニ演習：ビルドログを見比べて“重い工程”を当てる🎯⏱️​

ここからは、「どこが遅い？」を当てる練習です（いきなり最適化しない！えらい！）👏😆

演習0：時間を測る（Windows）⏱️🪟​

PowerShellでOK👇

Measure-Command { docker build --progress=plain -t myapp . }

演習1：同じビルドを2回やる（キャッシュの効き方を見る）🔁🧱​

1回目（初回ビルド）👇

docker build --progress=plain -t myapp .

2回目（何も変えずにもう一回）👇

docker build --progress=plain -t myapp .

見るポイント👀✨

  • 2回目は「速いステップ」が増えるはず（キャッシュが効く）
  • 遅いままのステップがあったら、そこが“犯人候補”🕵️‍♂️

演習2：あえて“重い工程”を炙り出す🔥​

キャッシュ無しで全部やらせる👇

docker build --progress=plain --no-cache -t myapp .

見るポイント👀

  • RUN npm ci / RUN pnpm install とかが重い？📦🐢
  • COPY . . の後に重くなる？（キャッシュ壊してる可能性）💥
  • ネットワークDLが遅い？🌐🐢

演習3：“重い工程トップ3”をメモする📝🥇🥈🥉​

メモ例👇（こんな感じでOK）

  • ① RUN npm ci：35秒（依存DLっぽい）📦
  • ② COPY . .：8秒（コンテキスト大きい？）🎒
  • ③ RUN npm run build：20秒（TSビルド重い）🧑‍💻

このメモが、次章以降の改善の設計図になります🗺️✨

6) よくある落とし穴（ログ編）😵‍💫🪤​

  • 落とし穴1：ログが短すぎて原因が見えない → --progress=plain を使う📜(matsuand.github.io)

  • 落とし穴2：BuildKitを無効化してしまってた → DOCKER_BUILDKIT=0 を設定してるとBuildKitが止まります（意図せず遅くなる）(GitHub) ※恒久的に無効化はおすすめしません（速さの章なので）🙏💦

  • 落とし穴3：“docker build” と “buildx” の関係が分からない → docker buildx build はBuildKitでビルドを開始するコマンドです🧰(Docker Documentation) （将来、キャッシュ持ち運びやマルチプラットフォームで効いてきます🌍）

7) 🤖AI活用：ログを貼って“犯人”と“改善案”を出させる🕵️‍♀️✨​

以下のテンプレを、GitHub Copilot / OpenAI Codex系 / なんでもに投げてOKです🤖💡 （ログは長いので、まずは“重い工程の周辺だけ”貼るのがコツ✂️📎）

プロンプト1：重い工程の特定🎯

以下は docker build --progress=plain のログです。
時間がかかっている工程（上位3つ）を特定して、原因候補を箇条書きで出してください。
次に、Dockerfileの変更で改善できる案を3つください（安全度が高い順に）。

プロンプト2：キャッシュが壊れてる場所を当てる💥

このDockerfileとビルドログから、「キャッシュが効かない理由」を推理してください。
特に COPY の順序、依存インストール、ビルドコンテキストの観点で指摘して、
修正版Dockerfile案をください。

プロンプト3：初心者向けに“理由”も添えて直してもらう📘

あなたは初心者に教える先生です。
このDockerfileを、なぜその順序にするのか説明しながら改善してください。
改善ポイントは「キャッシュ」「依存」「ビルドコンテキスト」の3点でお願いします。

8) この章のまとめ🏁✨​

  • BuildKitはいまのDockerの標準ビルダーで、速さと機能が強い🚀(Docker Documentation)
  • レガシー（クラシック）ビルダーは非推奨の流れ🪦(Docker Documentation)
  • 速くする第一歩は「最適化」じゃなくて “見える化”！ → --progress=plain でログを全部出して、重い工程を当てる📜🎯(matsuand.github.io)

次の章（第4章）では、いよいよ “遅さの4大犯人” を覚えて、あなたのプロジェクトで「犯人特定」していきます🕵️‍♂️🔥 よかったら、いま使ってる Dockerfile（個人情報抜き） と、--progress=plain のログの一部を貼ってください📎✨ こちらで“犯人当て”を一緒にやれます😆🎯