今回やること
AIにコードレビューを頼む時、ただ「レビューして」と書くだけでは、浅い指摘や好みの話が増えがちです。
AIレビューでは、何を見てほしいかを先に指定します。
悪い聞き方
このコードレビューして
これだけだと、AIは観点を推測します。結果として、重要なバグよりも命名や細かい書き方を指摘することがあります。
よい聞き方
以下の差分をレビューしてください。
観点は、バグ、セキュリティ、型、エッジケース、既存仕様との回帰に絞ってください。
好みのリファクタは優先度を下げてください。
重大度順に、ファイル名と該当箇所つきで指摘してください。
観点を決めると、レビューが実務寄りになります。
指定したい観点
| 観点 | 何を見るか |
|---|---|
| バグ | 想定通り動かない条件 |
| セキュリティ | 入力検証、認証、秘密情報 |
| 型 | null、undefined、型の不一致 |
| 回帰 | 既存機能が壊れないか |
| UX | 操作しにくさ、表示崩れ |
| パフォーマンス | 重い処理、不要な読み込み |
全部を一度に見せるより、重要な観点を絞る方が精度が上がります。
差分を渡す
レビューでは、完成したファイル全体より差分が重要です。
git diff
差分を渡すと、AIは「今回変わった場所」に集中できます。
ただし、差分だけでは文脈が不足することもあります。その場合は、関係する既存コードや仕様も一緒に渡します。
出力形式を指定する
指摘を使いやすくするため、出力形式も指定します。
以下の形式で出してください。
- [重大度] ファイル名: 問題
理由:
修正案:
形式を決めておくと、後で対応しやすくなります。
AIの指摘は検証する
AIのレビューは便利ですが、必ず正しいとは限りません。
注意すること:
- 存在しないAPIを前提にする
- 仕様を誤解する
- 古いベストプラクティスを出す
- 重要でない好みを強く言う
- テストせずに断定する
AIの指摘は、コード、公式ドキュメント、テスト結果で確認します。
注意: AIレビューは人間のレビューを完全に置き換えるものではありません。見落としを減らす補助として使います。
テンプレート
この差分をコードレビューしてください。
優先観点:
- バグ
- セキュリティ
- 型/null/undefined
- エッジケース
- 既存仕様の回帰
出力ルール:
- 重大度順
- ファイル名と該当箇所を含める
- 好みのリファクタは最後に分ける
- 問題がなければ「重大な問題なし」と書く
まとめ
AIにコードレビューを頼む時は、観点、差分、出力形式、優先度を指定します。
「レビューして」ではなく、「何を、どの基準で、どの形式で見てほしいか」を伝えると、実務で使いやすい指摘になります。
次に読む記事
← 一覧に戻るPR
PR
