Skip to main content

第29章：AIと一緒に最適化：レビューの型（プロンプト付き）🤖🧰⚡️

この章は「AIに丸投げ」じゃなくて、**“AIレビューが毎回ちゃんと当たる型”**を作る回だよ😆✨ やることはシンプル👇

  • ✅ 素材を揃える（Dockerfile / compose / .dockerignore / 依存 / 計測ログ）
  • ✅ AIに“同じ質問テンプレ”でレビューさせる
  • ✅ 出てきた修正を“差分（diff）”で受け取る
  • ✅ 実測して勝ったら採用（時間・サイズ・再ビルドの効き）

1) まず“AIレビューが外さない”ための材料セット📦🧪​

AIって、材料が雑だと雑な答えが返ってくるのね😂 だから、レビューに渡す材料を固定しよう！

**AIに渡すべき最小セット（コピペでOK）**👇

  • Dockerfile
  • compose.yaml（or compose.yml）
  • .dockerignore
  • package.json
  • ロックファイル（package-lock.json / pnpm-lock.yaml / yarn.lock のどれか）
  • ビルドログ（--progress=plain が超おすすめ👀）

ログの取り方例👇（BuildKitのログが見やすい）

docker buildx build --progress=plain -t app:dev .

💡 --progress=plain のログは「どこで時間食ってるか」をAIが判定しやすいよ👀✨

2) レビューの“流れ”をテンプレ化する🧭✨​

これを毎回やるだけで、AIレビューの精度がぐっと上がる👍

(1) ベースライン計測  ⏱️📏
(2) AIレビュー依頼     🤖📝
(3) 修正案をdiffで受領  🧩
(4) 適用して再計測      🔁⏱️
(5) “速くなった証拠”を書く 🗣️📒

3) AIに守らせる「出力フォーマット」🧾🔒​

AIにこれを守らせると、修正がブレないし、あとで自分で説明できるようになるよ😎✨

**AIに要求する出力フォーマット（固定）**👇

  • (A) ボトルネックTop3（根拠つき）
  • (B) 改善案3つ（効果の見込み大→小）
  • (C) 最有力案の“差分パッチ（unified diff）”
  • (D) キャッシュが壊れない理由の説明
  • (E) リスク（壊れる可能性）と回避策

ここから本番：プロンプト集（コピペで使える）📌🤖​

🧠 どれも「貼る→ファイル添付→返答がdiff」の流れで使えるようにしてあるよ！

Prompt 1：超速60秒レビュー（まずは雑に当てる）⚡️🤖​

あなたはDockerビルド最適化のレビュアーです。
以下のファイル（Dockerfile / compose.yaml / .dockerignore / package.json / lockfile / buildログ）を読んで、

1) キャッシュが壊れている可能性が高い箇所 Top3（根拠つき）
2) いま一番効く改善案を1つだけ
3) その改善の “unified diff” を出してください

制約:
- 変更は最小限
- 速さ優先だが、再現性（同じ入力→同じ結果）も壊さない
- まずローカルビルドの体感改善を狙う
出力は日本語でお願いします。

Prompt 2：ガチレビュー（改善案3つ＋diff＋検証手順）🧠🔧​

あなたはDocker/BuildKit最適化の専門家です。
次の観点で徹底レビューしてください：

観点:
- Dockerfileのレイヤ順序（依存→ソースの順になってる？）
- ビルドコンテキスト肥大（.dockerignoreの漏れ）
- 依存インストールのキャッシュ設計
- BuildKitのキャッシュマウント/外部キャッシュの活用余地
- 余計なファイルが最終イメージに入っていないか

やってほしいこと:
A) ボトルネックTop3（根拠と、ログの該当箇所を引用）
B) 改善案を3つ（効果見込み・難易度・リスク）
C) 最有力案について unified diff でパッチ提示（Dockerfile, compose, .dockerignore など必要分）
D) “なぜキャッシュが壊れにくくなるか” を初心者向けに説明
E) 検証コマンド（ビルド時間、キャッシュヒット確認、イメージサイズ確認）

注意:
- 秘密情報や環境変数は含めない前提でレビューして
- 不確実な点は質問ではなく「仮定」と「別案」を提示して

Prompt 3：ビルドログから“遅い工程”を特定する（犯人捜し）🕵️‍♂️🔥​

以下は docker buildx build --progress=plain のログです。
ログから「時間がかかっている命令」を特定して、

1) 遅い命令Top5（秒数っぽい根拠つき）
2) 各命令が遅い理由の推定（ネットワーク/依存DL/キャッシュミス/ビルドコンテキスト等）
3) 最短で効く改善を1つだけ提案
4) その改善を反映した Dockerfile の差分（unified diff）

を出してください。

Prompt 4：Compose側の“無駄な再ビルド/再起動”を減らすレビュー👀🔁​

Composeのウォッチは、公式に docker compose up --watch で起動できるよ（ログと同期イベントを分けたいなら docker compose watch もOK）🐳👀✨ (Docker Documentation)

compose.yaml をレビューして、開発中の“ムダな再ビルド/再起動”を減らす提案をください。

欲しい出力:
1) ファイル変更→何が起きるべきか（同期/再起動/リビルド）を整理
2) watch設定が入れられるなら提案（必要ならcompose.yamlのdiff）
3) よくあるNG（過剰リビルド、ログが混ざる等）と回避策
4) 変更後の運用手順（コマンド）

前提:
- 変更は最小限
- 体感速度を上げたい

Prompt 5：CIのキャッシュ戦略レビュー（buildx / cache-to / cache-from）🏗️📦​

外部キャッシュは --cache-to と --cache-from を使って持ち運べるよ、ってDocker公式でも説明されてる👍 (Docker Documentation) さらにキャッシュの出力先は「同じ場所に二回書くと上書き」になりやすいから、ブランチごとに分けるなどの設計も大事だよ⚠️ (Docker Documentation)

GitHub ActionsでDockerビルドを速くしたいです。
CI設定（workflow yaml）とDockerfileを読んで、

1) いまのキャッシュ戦略の問題点
2) cache-to/cache-from のおすすめ構成（type=registry or type=gha など）
3) 具体的な workflow の差分（unified diff）
4) ブランチ別キャッシュをどう分けるべきか
5) 期待効果（どの工程が省けるか）

を出してください。

🧩補足：type=gha はDocker docs上「Experimental」扱いで、デフォルトのdockerドライバでは使えず、別ドライバのbuilderが必要、という注意があるよ👀 (Docker Documentation) 🧪さらに、BuildKitのcache mountはGitHub Actionsのキャッシュに“そのままでは残らない”ので、回避策が紹介されてるよ（これ、ハマりがち😇）(Docker Documentation) （CIでbuildxを整えるなら、セットアップ用アクションがデフォでdocker-containerドライバを使う、という説明もあるよ）(GitHub)

4) 落とし穴あるある（AI時代の罠）🕳️😵‍💫​

  • 🔥 AIが“気持ちよく”大改造してくる → まずは「変更は最小限」縛りにして、diffで受け取るのが安全👍
  • 🔑 秘密情報を貼っちゃう → .env やトークンは絶対貼らない！必要なら API_KEY=*** に置換🙅‍♂️
  • 🧱 “速いけどキャッシュが壊れる”提案 → AIに「キャッシュが壊れない理由も説明して」って必ず言う（Prompt 2のD）✨
  • 🎯 速くなった気がするだけ → “実測”で殴る！⏱️📏（ビルド時間・再ビルド時の挙動・イメージサイズ）

5) ミニ演習：AIレビュー→差分適用→自分の言葉で説明🧪🗣️✨​

やることはこれだけ！めっちゃ良い訓練になるよ😆💪

  1. docker buildx build --progress=plain -t app:dev . を1回回してログ保存📒
  2. Prompt 2 をAIに投げる🤖
  3. 出てきたdiffを適用（手 or コピペ）🧩
  4. もう一回ビルドして、どこが短くなったかを確認⏱️
  5. 最後にこのテンプレを埋める👇
✅ 変更点（1行）：
✅ 速くなった理由（キャッシュ観点で1〜2行）：
✅ 計測結果（前→後）：
✅ リスクと回避策：

まとめ 🎁✨​

この章のゴールは「AIを使える」じゃなくて、 AIを“毎回ちゃんと当てる手順”で使えるようにすること🤖🧰

次の章（第30章）では、この型をそのまま埋め込んだ 自分専用の“速度テンプレ” を完成させるよ🏁🎁✨