Kubernetes や ECS で動かす想定でも観点は使えますか?

10 観点のうち、ネットワーク・ホスト名解決・volume・healthcheck は Kubernetes でも概念がそのまま対応します (Service / DNS / PVC / Liveness Probe)。ただし port mapping や depends_on は K8s では概念ごと別物になるので、本プロンプトは Compose 環境での切り分けに使い、K8s 移行後は別フレームに切り替えるのが現実的です。

compose.yml が長すぎて貼りきれません

問題が起きているサービスと、その depends_on で繋がっているサービスだけ抜粋して貼れば十分です。共通の volumes / networks セクションは省略せず、無関係なサービス定義だけを削るのがコツです。完全省略すると network や volume の参照不整合が AI から見えなくなるので注意してください。

depends_on を書いているのに DB 起動前に app が立ち上がります

これは観点 6 (depends_on の限界) の典型例です。depends_on は『プロセスが起動したか』しか見ていないため、DB が接続を受け付ける状態になるまで待ちません。healthcheck を DB 側に追加して、app 側で depends_on の condition: service_healthy を指定するのが標準的な解決策で、AI もこの方向で提案を返すはずです。

AI が network_mode: host で誤魔化す提案を返してきます

プロンプトの『やってはいけないこと』に network_mode: host を明示しているのに返る場合は、AI が制約を読み飛ばしている合図なので「制約セクションを再読してから出力し直してください」と返すと修正されます。host モードはコンテナ間隔離を壊すため本番では避けたほうが安全です。

コーディング 2026-05-18 更新

Docker Compose 設定のバグをサービス間関係まで含めて診断するプロンプト

いつ使うか

compose up したらコンテナが立ち上がるけど API がアプリから繋がらない / DB 接続だけ失敗 / volume が永続化されない / port 衝突——みたいなインフラ寄りのバグ。compose.yml と Dockerfile を一緒に渡して、ネットワーク・volume・healthcheck・depends_on の論点を体系的にチェックさせる時に使う。

プロンプト本文 (コピペして使う)

あなたは Docker / Compose の熟練インフラエンジニアです。以下の compose 設定をデバッグしてください。

## 事象
- 期待挙動: <例: app コンテナから db コンテナへ接続できる>
- 実際の挙動: <例: app が db に接続できず Connection refused>
- 再現コマンド: <例: docker compose up -d && docker compose logs app>
- エラーログ抜粋:
```
<貼る>
```

## compose.yml
```yaml
<全文を貼る>
```

## 関連 Dockerfile
```dockerfile
<該当サービスの Dockerfile>
```

## 診断観点 (該当に○+理由)
1. **ネットワーク** (デフォルト bridge / 明示 network / コンテナ名でのDNS解決)
2. **ホスト名 vs localhost** (app の DB 接続先を localhost にしていないか)
3. **port mapping vs expose** (ホスト公開 vs コンテナ間通信の混同)
4. **環境変数の渡し方** (env_file / environment / .env / build args の競合)
5. **volume の種類** (named volume / bind mount / tmpfs / 権限問題)
6. **depends_on の限界** (service が立っていてもアプリが ready でない)
7. **healthcheck の有無と condition: service_healthy** の使用
8. **build context** (.dockerignore で必要ファイルを除外していないか)
9. **マルチステージビルド** (最終ステージに必要なファイルが届いているか)
10. **プラットフォーム差** (linux/amd64 vs linux/arm64 の image 指定)

## 出力
1. 該当観点と一次原因 (番号付き)
2. **修正後の compose.yml 差分** (該当箇所のみ before/after)
3. **修正後の Dockerfile 差分** (必要なら)
4. **動作確認コマンド** (compose 立ち上げ後の検証手順、3コマンドまで)
5. **再発防止** (healthcheck 追加 / CI で compose config 検証 等)
6. **やってはいけないこと** (例: depends_on だけで ready 待ちした気になる、network_mode: host で誤魔化す)

## 制約
- 推測でファイルを書き換えない (該当の compose / Dockerfile 行を根拠にする)
- ホスト側に影響する変更 (ファイアウォール / ホストの /etc/hosts) は最終手段
- バージョン明示 (Compose v2 前提か Compose v1 か)

効くポイント

10観点フレームを渡すと、ネットワーク・volume・healthcheck の論点抜けが消える
「やってはいけないこと」を要求すると、network_mode:host のような事故回避策が出ない
動作確認コマンドを必ず添えさせると、修正の効果検証が即できる

よくある質問

Kubernetes や ECS で動かす想定でも観点は使えますか?: 10 観点のうち、ネットワーク・ホスト名解決・volume・healthcheck は Kubernetes でも概念がそのまま対応します (Service / DNS / PVC / Liveness Probe)。ただし port mapping や depends_on は K8s では概念ごと別物になるので、本プロンプトは Compose 環境での切り分けに使い、K8s 移行後は別フレームに切り替えるのが現実的です。
compose.yml が長すぎて貼りきれません: 問題が起きているサービスと、その depends_on で繋がっているサービスだけ抜粋して貼れば十分です。共通の volumes / networks セクションは省略せず、無関係なサービス定義だけを削るのがコツです。完全省略すると network や volume の参照不整合が AI から見えなくなるので注意してください。
depends_on を書いているのに DB 起動前に app が立ち上がります: これは観点 6 (depends_on の限界) の典型例です。depends_on は『プロセスが起動したか』しか見ていないため、DB が接続を受け付ける状態になるまで待ちません。healthcheck を DB 側に追加して、app 側で depends_on の condition: service_healthy を指定するのが標準的な解決策で、AI もこの方向で提案を返すはずです。
AI が network_mode: host で誤魔化す提案を返してきます: プロンプトの『やってはいけないこと』に network_mode: host を明示しているのに返る場合は、AI が制約を読み飛ばしている合図なので「制約セクションを再読してから出力し直してください」と返すと修正されます。host モードはコンテナ間隔離を壊すため本番では避けたほうが安全です。