AIコードレビューは、人間レビューの代替ではなく、人間レビュー前の一次フィルタとして使う。一般的な品質指摘をAIに任せ、人間は業務仕様・設計判断・保守性に集中する。
6.0b PoC例：別モデルによる一次レビュー
コードレビュアー向けの原則（本章6.1以降）を PoC で強化する一例。実装者と同じモデルに確認させると見逃しが増えやすいため、訓練の異なるモデルで diff をレビューし、食い違った箇所だけ人が判断する（note）。
- 未コミット変更・ブランチ diff の一次チェック
- 設計トレードオフ・隠れた前提の指摘（敵対的レビュー）
- 結果は PR テンプレの AI 利用欄に記録（第14章・第13章）
PoC KPI: レビュー時間・AI指摘採用率・手戻り（第12章 R-1）。業務仕様の最終判断は人間（第1章 結論2）。
6.0c レビューと機械ゲートの役割分担
AI一次レビュー（本章6.0b・事例R-1）はすり抜けレベル 2〜3。SQLi・XSS・認可漏れは SAST/CodeQL + 人間レビューが必要（本章6.5警告）。
| 層 | 担当 | すり抜け | 証跡 |
|---|---|---|---|
| 機械（CI） | SonarQube QG · Semgrep · 言語Lint · テスト | 4〜5 | GitHub Checks / Sonar ダッシュボード |
| AI一次 | 別モデル diff レビュー（6.0b） | 2〜3 | PRテンプレ AI利用欄 |
| 人間 | 業務仕様・設計・リスク受容（6.2） | 文脈依存のみ残る | レビューコメント・ADR |
月次改善（6.6）で「同じ指摘の再発」が出たら、自然文プロンプトではなく Semgrep ルール化または Checkstyle 設定へ落とす。
6.0d PR/MR — CI品質ゲート + AI一次レビュー
本章6.0b（別モデル一次レビュー）を、既存CI/CDパイプライン上で運用する際の位置づけ。AIレビューは PR コメントに残し、マージブロック条件は SonarQube QG · Semgrep · テストとする（6.0c と併読）。
| 順序 | レイヤ | ブロック可否 |
|---|---|---|
| 1 | Lint · Formatter · 単体テスト | はい |
| 2 | SAST · SonarQube QG | はい |
| 3 | AI PRレビュー（Copilot / PR-Agent / CodeRabbit 等） | いいえ（参考） |
| 4 | 人間レビュー | はい（Branch Protection） |
PRテンプレ · Redmine連携 · 16事例: 第7章 7.0d · dev_docs 第4章
研修 — レビュー担当コース（確認テスト・演習）
所要: テスト 5分 + 演習は bonus_kit 演習1 と併用。4/5 以上で知識確認完了。
確認テスト（5問）
| # | 正解の要点 |
|---|---|
| 1 | AIは実装の下書き。採否は人間 |
| 2 | 実装とレビューは別モデルが望ましい |
| 3 | 仕様不明点をAIに勝手に確定させない |
| 4 | PRテンプレにAI利用・採否理由を残す |
| 5 | 本番変更・顧客影響は Human Gate |
演習:
$ai-quality-pr-review → 指摘を採用/保留/不採用に分類（期待結果は bonus_kit README）。6.1 AIに任せやすいレビュー観点
| 分類 | 内容 |
|---|---|
| 可読性 | 命名、重複、コメントと実装の不一致 |
| 単純ミス | Null、未使用変数、例外握りつぶし |
| テスト不足 | 異常系、境界値、モック不足 |
| 性能 | N+1、不要ループ、過剰なDBアクセス |
| 保守性 | 責務分離、複雑度、共通化候補 |
| 基本セキュリティ | 入力検証、危険なログ、認可チェック漏れ候補 |
Before / After 事例（PoC想定・匿名）
事例R-1：AI一次レビュー＋人間レビュー役割分担
| 項目 | Before | After（6週間） |
|---|---|---|
| 人間レビュー時間/PR | 中央値 45分 | 中央値 28分 |
| AI指摘採用率 | — | 54% |
| 同種指摘の再発（命名・Null等） | 月8件 | 月3件 |
| テックリードの業務仕様確認時間 | PRあたり15分 | PRあたり22分（一般指摘はAIに任せた分、仕様確認に集中） |
使ったスキル：requesting-code-review、receiving-code-review（superpowers）。GitHub Copilot Code Review併用案件あり。
6.2 人間が必ず見るべき観点
| 分類 | 内容 |
|---|---|
| 業務仕様 | チケット・設計書・顧客要件と一致しているか |
| 設計思想 | 既存アーキテクチャ、責務分離、将来拡張性 |
| 運用影響 | 障害時の影響、ログ、監視、切り戻し |
| セキュリティ判断 | 権限、認可、機密情報、例外承認 |
| リリース判断 | マージ可否、本番影響、リスク受容 |
6.3 AIレビュー標準プロンプト
あなたは厳しめのコードレビュアーです。
以下の差分をレビューしてください。
レビュー観点：
1. 仕様との不一致
2. Null・空文字・0件
3. 例外処理
4. トランザクション
5. DB更新の整合性
6. 権限チェック
7. ログ出力
8. パフォーマンス
9. 保守性
10. テスト不足
11. セキュリティ
12. 命名・可読性
出力形式：
| No | 重要度 | 指摘内容 | 該当箇所 | 理由 | 修正案 |6.4 PRレビュー運用
- 開発者がPR作成前にAIセルフレビューを実施する。
- AI指摘のうち採用したもの、採用しなかったものを整理する。
- PRテンプレートにAI利用範囲を記載する。
- レビュアーはAI指摘済みの一般論より、仕様・設計・影響範囲を重点確認する。
- レビュー指摘を月次で分類し、標準プロンプトに反映する。
6.5 レビュー観点表
| 分類 | 観点 |
|---|---|
| 仕様 | チケット・設計書と一致しているか |
| 業務 | 業務ルール、例外、運用ケースを満たすか |
| データ | DB更新、整合性、排他、履歴 |
| API | 入出力、エラー、タイムアウト、リトライ |
| 画面 | 入力制御、表示制御、メッセージ |
| テスト | 正常、異常、境界、回帰 |
| セキュリティ | 認証、認可、SQL、XSS、ログ |
| 保守性 | 責務分離、命名、重複、複雑度 |
| 運用 | ログ、監視、障害時対応 |
AIコードレビューは便利だが、重大なセキュリティ脆弱性を見逃す可能性がある。SQLインジェクション、XSS、認可漏れなどは、SAST、CodeQL、DAST、人間レビューを組み合わせるべきである。
6.6 月次改善
| 集計項目 | 改善アクション |
|---|---|
| AI指摘採用率 | 低い場合はプロンプトを見直す |
| 人間レビュー指摘の残存傾向 | AIチェックリストへ追加する |
| 同じ指摘の再発 | 規約化・テンプレ化する |
| レビュー待ち時間 | AI一次レビューで短縮できているか確認する |
| 重大指摘の件数 | 設計・要件レビュー工程に戻す |
