はじめに
生成AIにコードを渡して、
このコードをレビューしてください。
とお願いしたことがある人は多いと思います。
もちろん、それでもある程度レビューしてくれます。
しかし実際に業務で使うなら、この依頼だけでは少し弱いです。
理由は簡単で、
何をレビューしてほしいのか定義されていない
からです。
この記事では、AIをコードレビューに使う場合のプロンプト設計を整理します。
「レビューしてください」では観点が決まっていない
例えば次のコードがあったとします。
public User findUser(String id) {
User user = userRepository.findById(id);
if (user == null) {
return null;
}
return user;
}
これをAIに、
レビューしてください。
と依頼すると、
- nullについて
- 命名について
- Optionalについて
- 例外について
など、モデルが重要だと思ったものを自由に指摘します。
しかしレビューで確認したい内容が、
今回変更した箇所によって
既存機能が壊れないか
なら、目的が違います。
最初に「レビューの目的」を指定する
例えば、
このコードについて、
バグ混入の可能性を中心にレビューしてください。
とするだけでも変わります。
さらに、
以下の観点でレビューしてください。
1. バグ
2. null安全性
3. 境界値
4. 例外処理
5. DB整合性
6. セキュリティ
7. パフォーマンス
8. 可読性
9. 既存処理への影響
とします。
AIにとって、レビュー観点はチェックリストです。
重大度を付けてもらう
AIレビューで困るのが、指摘が大量に出ることです。
そこで、指摘に重大度を付けます。
各指摘を以下に分類してください。
Critical:
障害、データ破壊、セキュリティ事故につながる
High:
特定条件で不具合につながる可能性が高い
Medium:
保守性や品質に問題がある
Low:
改善するとよいが、必須ではない
これだけで、人間側が読む順番を決めやすくなります。
「指摘」だけでなく「根拠」を要求する
AIコードレビューでは、
なんとなく怪しい
という指摘が混ざることがあります。
そのため、
指摘ごとに以下を記載してください。
- 対象箇所
- 重大度
- 問題
- 問題になる条件
- 根拠
- 修正案
とします。
「問題になる条件」を入れるのが特に重要です。
「本当に不具合なのか？」を考えさせる
AIレビューは慎重すぎることがあります。
例えば、
nullになる可能性があります
と指摘しても、フレームワーク上nullにならないことがあります。
そこで、
推測だけで指摘しないでください。
指摘する前に、
- 実際にその経路が存在するか
- 呼び出し元で保証されていないか
- フレームワーク仕様で保証されていないか
- 既存の共通処理で対策されていないか
を確認してください。
確認できない場合は
「要確認」としてください。
とします。
これで誤検知を減らせます。
差分レビューでは「変更行だけ見ない」
AIにGit diffを渡す場合も注意が必要です。
例えば、
- user.setStatus("0");
+ user.setStatus(status);
だけを見ても、statusがどこから来たのか分かりません。
そのため、
変更行だけではなく、
- 呼び出し元
- 呼び出し先
- 関連DTO
- Entity
- Validation
- SQL
- テスト
まで追跡して影響を確認してください。
と依頼します。
AIの強みは、人間が面倒に感じる参照先の横断確認です。
業務ロジックのレビューでは仕様を渡す
AIはコードをレビューできます。
しかし、
仕様通りなのか
は仕様を知らなければ判断できません。
例えば、
開始日 <= 終了日であること
という仕様があったとしても、コードだけ見てそのルールを必ず推測できるわけではありません。
そこで、
今回の仕様：
- 開始日は終了日以前
- 同一ユーザーに有効なデータは1件のみ
- 更新時は既存データを物理削除しない
- 履歴を追加する
など、レビューに必要な仕様を渡します。
AIコードレビュー用プロンプト
自分なら、次のような形にします。
あなたはシニアソフトウェアエンジニアとして
コードレビューを行ってください。
# 目的
本番障害につながる問題を
実装段階で発見すること。
# レビュー観点
1. 仕様との不整合
2. バグ
3. null安全性
4. 境界値
5. 例外処理
6. DB整合性
7. トランザクション
8. セキュリティ
9. パフォーマンス
10. 既存機能への影響
11. テスト不足
# 指摘ルール
推測のみで指摘しないでください。
コード上確認できない場合は、
「要確認」としてください。
# 重大度
Critical
High
Medium
Low
# 出力形式
|No|重大度|対象|指摘内容|発生条件|根拠|修正案|
|---|---|---|---|---|---|---|
最後に以下も記載してください。
- Critical / High件数
- 追加すべきテスト
- 影響確認すべき機能
- 総評
さらに精度を上げるなら2段階レビュー
一発でレビューさせるより、
1回目：構造を理解
2回目：レビュー
に分ける方法も有効です。
最初に、
まだレビューしないでください。
まずコードを読み、
以下を整理してください。
- 処理概要
- 入力
- 出力
- DB更新
- 外部呼び出し
- 例外経路
- 関連クラス
と依頼します。
AIが正しく理解しているか確認してから、
先ほど整理した処理を前提に、
レビューしてください。
と進めます。
AIに修正させるのはレビュー後
レビューと修正を同時に依頼すると、
問題を発見
↓
AIが即修正
↓
なぜ問題だったのか分かりにくい
ことがあります。
そのため、
レビュー
↓
人間が確認
↓
修正
を分けています。
特に業務システムではこの方が安全です。
レビュー結果そのものも疑う
AIコードレビューで大切なのは、
AIの指摘を正解として扱わないこと
です。
AIは、
- 存在しない実行経路を想定する
- フレームワーク仕様を誤認する
- 業務仕様を誤解する
- 過剰なリファクタリングを提案する
ことがあります。
つまりAIレビューは、
自動で合否判定する仕組み
ではなく、
人間が見るべきポイントを増やす仕組み
として使うのがよいと思います。
プロンプトもコードと同じように改善する
同じレビューを何度も行うなら、プロンプトも使い捨てにしない方がよいです。
例えばGit管理して、
/prompts
code-review.md
test-review.md
security-review.md
のように管理します。
レビューで誤検知があれば、
この条件では指摘しない
を追加します。
逆に見逃しがあれば、
この観点を必ず確認する
を追加します。
こうすると、プロンプト自体がチームのレビュー知識になっていきます。
まとめ
AIコードレビューで重要なのは、
「レビューしてください」
から一歩進んで、
何を
どの観点で
どの程度の厳しさで
どの形式で
レビューするのか
を定義することです。
特に効果があるのは、
- レビュー目的を指定
- 観点を列挙
- 重大度を指定
- 発生条件を書かせる
- 推測と事実を分ける
- コードだけでなく仕様も渡す
- 修正とレビューを分離する
という方法です。
AIのレビュー能力だけでなく、
「レビュー観点そのものを設計する」
ことが、AIコードレビューを実務で使うポイントだと思います。
参考資料
-
OpenAI「Prompt engineering」
https://developers.openai.com/api/docs/guides/prompt-engineering -
OpenAI「Structured Outputs」
https://developers.openai.com/api/docs/guides/structured-outputs