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

第29章：AIでCompose設計を速く・安全にする🧠⚙️

この章は「AIに叩き台を作らせて💨、人間が安全レビューして🛡️、docker composeで機械チェックして✅、最短で“動く形”に寄せる」ための実戦テンプレ回です✨ （AIは“速いけど雑”になりがちなので、型で勝ちます😎）

1) AIは“設計者”じゃなくて「設計の下書き係」📝🤝​

AIにやらせると効くのは、だいたいこの3つです👇

  • 叩き台生成：サービス分割、ネットワーク、ボリューム、ポート、envの配置案などを一気に出す🚀
  • リスク指摘：秘密直書き、危ないマウント、ログ漏れ、過剰権限などを洗い出す🔍🧯
  • ドキュメント整形：READMEの起動手順、make/npm scripts/タスクの提案などを整える📚✨

ただし大原則はこれ👇 AIは提案するだけ。採用するのは人間。 🧑‍💻✅

2) まずAIに渡す「要件メモ」テンプレ📌（これが勝ち筋）​

AIに“雑に聞く”と、雑なcompose.yamlが返ってきます😂 なので、最初にこのメモをコピペして渡すのがオススメです👇

あなたはDocker Composeの設計レビュー役です。
次の要件で compose.yaml の叩き台を作ってください。

【要件】
- サービス: api(TypeScript), db(Postgres), redis, worker(queue)
- 目的: docker compose up で一括起動、開発向け
- DBは永続化(名前付きvolume)
- api/workerはソースを反映して開発しやすく（watch か mount の提案）
- 依存関係: api/worker は db/redis が起動してから安定して動く
- 設定: 秘密情報の直書き禁止。安全な渡し方を提案（.env / secrets など）
- オプション: 管理UI系は profiles で任意起動にしたい

【出力ルール】
1) compose.yaml を出す
2) “なぜそうしたか”を箇条書きで説明
3) 事故りやすい点（秘密、永続化、起動順）をセルフレビューして指摘

ポイントは「出力ルール」まで決めることです😋 AIはルールを与えると、かなり良い子になります👍

3) AIが出したcompose.yamlは、まず“機械で検査”✅​

3-1) docker compose configで正規化して破綻を早期発見🧪​

docker compose configは、Composeファイルを解決（変数展開など）して“正規の形”にレンダリングしてくれます。複数ファイルのマージや短縮記法の展開もやってくれるので、AI生成物のチェックに超向いてます✅ (Docker Documentation)

例👇

docker compose config

ここで見るポイント👀✨

  • 変数が未定義で空になってない？（${DB_PASSWORD}が空とか）
  • サービス名の参照ミスない？
  • ボリューム/ネットワークの宣言ミスない？

4) “AIレビュー”のチェックリスト🛡️（ここが本題）​

AIの提案は、だいたいこの辺で事故ります💥 だからチェック観点を固定化します👇

4-1) 秘密情報の扱い：env直書き地雷💣→ secretsで回避🔐​

秘密（パスワード/APIキー）を環境変数で渡すと、ログ出力やプロセス一覧などで意図せず露出するリスクがあります😇 Composeにはsecretsがあり、サービスごとにアクセス権を付けて渡せます🛡️ (Docker Documentation)

secretsはコンテナ内で /run/secrets/<secret_name> にファイルとしてマウントされます📄 (Docker Documentation) （公式イメージだと *_FILE 環境変数で読む流儀が用意されてることも多いです） (Docker Documentation)

最小例👇

services:
  db:
    image: postgres:latest
    secrets:
      - db_password
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

✅ チェック項目

  • compose.yamlやGitにパスワードが直書きされてない？
  • .envに置くにしても、コミット対象外になってる？
  • secretsを使うなら、サービスごとに必要最小限だけ付与してる？ (Docker Documentation)

4-2) 起動順：depends_onは“起動”であって“準備完了”ではない⏳🩺​

depends_onは「順番を整える」には効きますが、DBが“接続できる状態”まで待つとは限りません😵 なので、健康状態チェック（healthcheck）と組み合わせる設計がよく出ます🩺✨ (Docker Documentation)

✅ チェック項目

  • DB/Redisが立ち上がる前提のアプリが、即死ループになってない？
  • healthcheckを使うなら、判定コマンドが現実的？（重すぎない/誤判定しない）

（※healthcheckとdepends_onの細部はComposeの仕様・実装差もあるので、AIが出したら必ず公式リファレンスを当てるのが安全です） (Docker Documentation)

4-3) watch（開発の自動反映）：AIが提案したら“条件”を確認👀✨​

Composeには開発向けに develop.watch（Watchモード）があり、ローカルの変更を自動反映できます🔥 watchは path と action を並べて、変更時の動きを決めます。 (Docker Documentation)

主なactionはこんな感じ👇

Watchの使い方は基本これです👇

  1. compose.yamlにwatchを書く
  2. docker compose up --watchで起動する (Docker Documentation)

さらに、ログ混線がイヤなら docker compose watch という専用コマンドもあります👀 (Docker Documentation)

✅ チェック項目

  • watchを使うなら、イメージ内に必要なコマンド（stat等）がある？ (Docker Documentation)
  • USERがtargetへ書き込める？（権限でコケがち） (Docker Documentation)
  • node_modulesを同期対象に入れてない？（地獄）😇

4-4) “version:”をAIが書いたら赤信号🚥（すぐ直す）​

Composeファイルのトップレベル version は **obsolete（旧式）**扱いで、Composeは最も新しいスキーマを使います。 (Docker Documentation) AIが昔の知識で version: "3" とか書きがちなので、見つけたらサクッと消すのが安全です🧹✨

5) AIに“自己否定レビュー”させる魔法のプロンプト🪄😈​

叩き台を出させたら、次は「それ危なくない？」をAIに言わせます。 この“二段構え”がめちゃ効きます💪

5-1) セキュリティ地雷チェック用プロンプト🔐​

次の compose.yaml をセキュリティ視点でレビューして。
- 秘密情報の扱い（直書き、env漏れ、ログ漏れ）
- 過剰な権限（privileged、docker.sockマウント等）
- 不要なポート公開
- ホストへの危険なマウント
問題点→修正案→修正後の差分（必要なら）で出して。

5-2) 運用事故チェック（永続化・破壊的操作）💾🧨​

次の compose.yaml を「事故る観点」でレビューして。
- DBの永続化が正しいか（volume）
- down/up を繰り返してもデータが意図せず消えないか
- コンテナ再作成で壊れやすい設定がないか
- env_file の絶対パスなど、他PCで壊れる要素がないか

（env_fileで絶対パスを使うと移植性が落ちる、みたいな注意も公式にあります📌） (Docker Documentation)

6) VS Code × AIで“速くする”回し方🧰⚡​

AIは「文脈（コンテキスト）」が多いほど強いです📈 なので **“素材を渡す→提案→検証→修正”**のループを短く回します♻️

6-1) Copilot Chat系に効くコツ（超ざっくり）💡​

  • 具体的に頼む（「いい感じに」禁止🙅‍♂️）
  • 小さく分割して頼む（まずは叩き台→次にレビュー）
  • 提案は必ず検証する（AIは断言して間違える😇）

こういう“ベストプラクティス”はGitHub側も強調してます📌 VS Codeのプロンプト例でも「具体性」「文脈追加」「反復」が重要だと整理されています🧠✨

7) ミニ演習（30分で“型”が身体に入る）⏱️🎮​

演習A：叩き台を出させる（5分）📝​

  1. 要件メモテンプレ（上のやつ）をAIに投げる
  2. compose.yamlを受け取る
  3. version:があったら削除🧹 (Docker Documentation)

演習B：機械検証（10分）✅​

  1. docker compose config
  2. 解決後の出力を見て、変数や参照が崩れてないか確認 (Docker Documentation)

演習C：watch導入の提案→現実チェック（15分）👀🔥​

  1. AIに「watchで開発反映したい」と追加指示
  2. develop.watchが出てきたら、sync/rebuild/sync+restartの意図が合ってるか確認 (Docker Documentation)
  3. docker compose up --watchで動かす (Docker Documentation)
  4. 権限でコケたら、AIに「USERとCOPY --chownを見直す案」を出させる（Watch前提の落とし穴） (Docker Documentation)

8) よくあるAIの“雑提案”あるある集😂🧯（見つけたら即修正）​

  • version: "3"を書いてくる → 消す（旧式）🚮 (Docker Documentation)
  • パスワードをenvironmentに直書き → secretsへ🔐 (Docker Documentation)
  • 「とりあえず全部 ports 公開」→ 必要最小限に絞る🚪
  • node_modulesをホスト共有/同期しようとする → だいたい地雷👟💥
  • 起動順をdepends_onだけで解決した気になる → healthcheck/リトライ設計も検討🩺🔁 (Docker Documentation)

9) まとめ：この章の“持ち帰り”🎁✨​

  • AIは 叩き台担当にすると最強💪📝

  • 採用前に必ず

    1. AI自己レビュー 😈
    2. docker compose configで機械検証 ✅ (Docker Documentation)
    3. secrets / watch / 起動順の観点で人間レビュー 🛡️

  • watchは便利だけど、権限・ツール不足でコケるので条件確認が大事👀 (Docker Documentation)

  • versionは旧式扱いなので、AIが書いたら消す🧹 (Docker Documentation)

次章（スターターキット化🚀🎁）では、この章の“型”で作った構成を コピペで増殖できる形に仕上げます！✨