AIコードレビューは、Pull Requestの差分から不具合や確認漏れの候補を早く見つける補助に向いています。ただし、AIの指摘には誤検知もあるため、重要度、根拠、再現方法を揃え、人が最終判断する必要があります。
「このコードをレビューして」だけでは、diff外の想像、好みの指摘、根拠のないセキュリティ警告が増えます。PRの目的と変更範囲を渡し、レビュー観点と出力形式を固定すると評価しやすくなります。
この記事では、差分レビュー用プロンプト、観点表、重要度の基準、人による確認手順、誤検知率の評価シートを紹介します。
情報確認日：2026年7月17日（日本時間）
結論：AIには「断定」ではなく「検証可能な指摘」を求める
有効な指摘に必要な6項目
- 対象ファイルと該当行
- 起きる条件
- 期待する挙動と実際の挙動
- 根拠となるdiffまたは仕様
- 重要度
- 最小の確認・修正案
行番号と根拠を示せない指摘は、採用前に追加調査します。スタイル上の好みと、利用者へ影響する不具合を同じ重要度で扱わないことも大切です。
AIへ渡す前にPRをレビュー可能にする
- PRの目的を1〜3文で説明する
- 変更しない範囲を明示する
- 関連issueと受け入れ条件を付ける
- 動作確認手順と結果を記載する
- 大きすぎる差分を目的別に分ける
- 生成物や依存lockの大差分を区別する
GitHubの公式ガイドでも、焦点の合った変更と背景情報はレビューを助ける要素です。AIも同様に、目的が曖昧な巨大diffでは有効な判断が難しくなります。
差分レビュー用プロンプト
役割:
あなたはPull Requestの差分レビュー担当です。
目的:
{{pr_summary}}
受け入れ条件:
{{acceptance_criteria}}
変更対象外:
{{out_of_scope}}
差分:
{{diff}}
ルール:
- diffに根拠がある問題だけを指摘する
- 不明な前提は断定せず「確認事項」とする
- スタイルの好みだけの指摘は省く
- 指摘ごとにファイル、行、条件、影響、根拠、重要度、確認方法を示す
- 問題がなければ「重大な問題は見つかりません」と答える
- 修正コードは最小差分で提案する
重要度:
- blocker: マージ不可。重大な障害、漏洩、破壊的処理
- high: 利用者影響の大きい不具合、権限違反
- medium: 特定条件で起きる不具合、保守上の明確な問題
- low: 改善候補。マージを止めない
出力:
1. 要約
2. 指摘一覧
3. 追加で人が確認する点
4. 推奨テストAIコードレビューの観点表
| 観点 | 確認する質問 | 証拠 |
|---|---|---|
| 正しさ | 受け入れ条件を満たすか | 仕様、テスト、制御フロー |
| 境界値 | 空、null、最大値、重複で壊れないか | 条件分岐、型、テストケース |
| 状態 | 失敗途中や再試行で不整合にならないか | transaction、idempotency、rollback |
| 認証 | 誰が操作しているか確認するか | session、token検証 |
| 認可 | 対象データへの権限を確認するか | ownership、role、scope |
| 入力 | 型・長さ・形式・許可値を検証するか | schema、validator |
| 出力 | HTML、URL、ログへ安全に出すか | escape、redaction |
| エラー | 秘密や内部情報を漏らさないか | error handler、log |
| 性能 | N+1や無制限処理がないか | loop、query、pagination |
| 互換性 | 既存APIやデータを壊さないか | schema、public interface |
| テスト | 変更と失敗条件を覆うか | 追加・更新されたtest |
| 運用 | 監視・移行・ロールバック可能か | metric、migration、feature flag |
重要度を揃える
| 重要度 | 目安 | 例 |
|---|---|---|
| blocker | マージすると重大事故が高確率で起きる | 認証回避、全件削除、秘密の公開 |
| high | 主要機能や多くの利用者へ影響 | 権限のない更新、決済の二重処理 |
| medium | 条件付きで機能不良やデータ不整合 | 空入力で500、再試行で重複 |
| low | 明確な改善だがマージ停止は不要 | 分かりにくいエラー、重複処理 |
重要度には「影響」と「発生可能性」の両方を含めます。「セキュリティ」という単語だけでblockerにせず、到達経路と被害を確認します。
人が指摘を検証する手順
- 指摘したファイルと行がdiffに存在するか確認する
- 前提条件がコードと仕様に一致するか確認する
- 最小入力で問題を再現する
- 既存テストと新しい回帰テストを実行する
- 修正が別の仕様を壊さないか確認する
- 有効、部分的に有効、無効、判断保留へ分類する
AIの提案コードも同じ差分としてレビューします。提案を受け入れた後に、テスト、lint、型チェックを実行してください。
誤検知率の評価シート
| ID | 重要度 | 人の判定 | 根拠 | 採用 |
|---|---|---|---|---|
| R-01 | high | 有効 | 権限確認が欠落、再現済み | 修正 |
| R-02 | medium | 無効 | 上位層でnullを除外済み | 却下 |
| R-03 | low | 部分的 | 問題はあるがdiff外 | 別issue |
誤検知率 =
無効と判定したAI指摘数 ÷ AIの全指摘数 × 100
採用率 =
修正または確認追加に使った指摘数 ÷ AIの全指摘数 × 100
重大指摘精度 =
有効なblocker・high指摘数 ÷ 全blocker・high指摘数 × 100見逃し率を測るには、人間が作った正解付きPRや既知の不具合集が必要です。AIが出した指摘だけでは、指摘しなかった問題を数えられません。
レビュー結果の記録テンプレート
PR:
AIモデル・ツール:
確認日:
差分規模:
AI指摘数:
- blocker:
- high:
- medium:
- low:
人の判定:
- 有効:
- 部分的:
- 無効:
- 保留:
重大な見逃し:
平均確認時間:
修正後テスト:
次回プロンプト改善:AIレビューへ任せない判断
- 要件そのものが正しいか
- プロダクトとして受け入れるべきリスクか
- 法令・契約・社内規程への最終適合
- 移行・公開・ロールバックの責任判断
- 生成コードの著作権・ライセンス確認
- ApproveまたはRequest changesの最終決定
利用するAIコーディング環境を比較したい場合はAIコーディングツール比較も参考になります。
まとめ
AIコードレビューは、PR差分の一次点検を速くするために使います。PRの目的、範囲、受け入れ条件を渡し、ファイル・行・条件・影響・根拠・重要度・確認方法を揃えます。
指摘をそのまま採用せず、人が再現し、有効性を記録してください。誤検知率と重大指摘精度を継続的に測ると、自分のリポジトリに合うプロンプトと運用へ改善できます。