AIに設計書レビューをさせる時のプロンプト例
結論
AIに設計書レビューをさせるときは、単に「レビューして」と依頼するのではなく、観点、前提、出力形式を指定することが重要です。 AIはレビュー担当者の代わりではなく、抜け漏れ確認を助ける補助者として使います。
初心者がつまずくポイント
AIに設計書を渡して丸投げすると、一般論の指摘や、前提を取り違えた指摘が混ざります。 業務ルール、既存仕様、変更範囲、対象外の観点を伝えないと、現場で判断できる出力になりません。
現場ではどうなるか
設計レビューでは、入力チェック、異常系、既存機能への影響、テスト観点、用語の揺れなどを短時間で確認します。 AIに観点を固定して出力させると、人間のレビュー前に粗い抜け漏れを洗い出せます。
よくある失敗
- 「問題点を教えて」だけで依頼し、抽象的な指摘しか返ってこない。
- 前提条件や対象外の範囲を伝えず、不要な修正提案が増える。
- AIの指摘を根拠確認なしで採用し、既存仕様と矛盾する。
実務での使い方
まずレビューの目的を決め、次に前提、対象範囲、観点、出力形式を指定します。 返ってきた指摘は、重要度、確認先、修正要否に分け、人間のレビューで最終判断します。
具体例
画面項目を追加する設計なら、AIには「入力チェック」「保存先」「既存画面との表示差分」「テスト観点」「運用で確認すべき質問」に分けて確認させます。 返ってきた指摘は、そのまま修正指示にせず、既存仕様書、チケット、担当者確認で根拠をそろえてから採用します。
現場での判断基準
判断基準は、AIの出力が「具体的な確認行動につながるか」です。 指摘内容、影響、確認先、修正案が分かれていればレビュー前の下準備に使えますが、根拠が曖昧な一般論は質問リストとして扱います。
AI活用のヒント
プロンプトには「推測で断定しない」「不足情報は質問として出す」「表形式で優先度を付ける」といった制約を入れると、実務で扱いやすくなります。 機密情報、顧客名、実データは含めず、一般化した内容で確認しましょう。
プロンプト例
あなたは業務システム開発の設計レビュー担当です。
以下の設計内容を、既存仕様との整合性とテストしやすさを重視して確認してください。
前提：
- 対象は画面入力から登録処理までです。
- 外部連携の仕様変更は対象外です。
- 不明点は推測で断定せず、確認質問として出してください。
レビュー観点：
1. 入力チェック漏れ
2. 異常系・エラーメッセージの不足
3. 既存処理や既存データへの影響
4. テスト観点の不足
5. 用語、条件、境界値の曖昧さ
出力形式：
| 優先度 | 指摘内容 | 影響 | 修正案 | 確認すべき質問 |
| --- | --- | --- | --- | --- |関連するUdemy講座
「VS Code + AIでレガシーCOBOLを解析する」では、AIに前提と観点を渡して既存コードや設計情報を整理する方法も扱う予定です。