曖昧な要件をリリースまで進める手順
要件が曖昧で時間もないとき、いきなりコードを書かせると、後から戻れなくなります。この流れでは、不確実な部分を前半に寄せ、テストと設定確認で閉じます。
進め方
要件をエンティティと状態遷移に落とす
要件をそのまま「要件をデータモデルに落とす」に貼り、コードはまだ書かせません。エンティティ一覧、関連の基数、主要オブジェクトの状態遷移、半年以内に変わりそうな項目（価格、権限、論理削除）を出させ、最後にプロダクト担当へ確認すべき点を三つ挙げさせます。この三つが未確認のままだと、後の分割は推測の上に載ります。
API 契約を軸に並行できるタスクへ分ける
前のステップで得たエンティティと状態遷移、チーム人数を「並行開発できるタスクに分解する」に渡します。まず並行にできない順序制約（データモデル、API 契約、マイグレーション）を洗い出させ、残りを一人が一週間で独立して届けられる単位に切り、入力・出力・受け入れ条件を書かせます。衝突しやすい共有ファイルも挙げさせます。
レビュー前にテストの抜けを埋める
コードが動いたら、実装と既存テストを「テストの抜けを見つける」に貼ります。未カバーの分岐を確認し、本番影響の大きい順に補うべき五件を選び、それぞれ入力と期待値を書きます。重複したテストや、実装の詳細を検証しているテストは削ってかまいません。保守の負担が増えるだけです。
公開前に変更の影響範囲を数える
diff、呼び出し元の一覧、トラフィック量を「変更の影響範囲を見積もる」に渡します。影響人数と復旧の難しさで上位三箇所を並べさせ、今回の変更が前提にしているのに検証していない仮定を挙げさせます。公開順序と、切り戻しを判断する指標のしきい値も出させます。
設定の穴を一つずつ突いてから公開する
最後に設定ファイルと環境ごとの環境変数を「公開前に設定の穴を突く」に渡します。デフォルト値に頼っている項目、ローカルでは動くのに本番で落ちる経路を書き出させ、リスク順のチェックリストにします。リストはステップ4の切り戻し手順と一緒に残し、次のリリースで使い回します。
使うプロンプト
よくある質問
AI が書いたコードをそのまま公開できますか
できません。デプロイ環境、実際のデータ量、現在の設計に至った経緯はモデルから見えず、そこが公開後の障害の原因になりがちです。ステップ4と5で影響範囲と設定を補いますが、差分を読む人、テストを実行する人、切り戻しを判断する人は必要です。
要件が一行しかなくてもタスク分割できますか
できますが、推測の上での分割になります。先に「要件で不明確な点、プロダクト担当に確認すべき点」を挙げさせ、回答を得てから分割してください。そうしないと入力と受け入れ条件が想像で埋まります。
小さな変更でも全部の手順が必要ですか
いいえ。文言修正やログ追加ならステップ3と5だけで足ります。データモデル、権限、外部の呼び出し元に関わる変更は五つすべてを通す価値があります。判断基準は変更行数ではなく、壊れたときにすぐ戻せるかどうかです。