コードは速く出る。でもレビューは速くならない
生成AIを開発へ入れると、コードを書くところは目に見えて速くなります。その一方で、レビューする人数もCIの実行速度も変わりません。生成量だけ増やすと、PRがレビュー待ちになり、直しては再確認する回数も増えます。
この詰まり方を見ると、AIに任せる順番はコード生成が先とは限りません。自分は、既存のCIや人間レビューの手前で「提出前の確認役」にする方が組み込みやすいと考えています。
AIには合否を決めさせない
任せるのは、変更内容の整理、抜け漏れ候補の列挙、確認事項の言語化です。ビルドやテストの成否、マージ可否までは任せません。
境界は次のようになります。
| 判定 | 担当 |
|---|---|
| ビルドできるか | コンパイラ、ビルドツール |
| テストが通るか | テストランナー |
| 規約に合うか | Linter、Formatter |
| 既知の脆弱性がないか | SAST、SCA、Secret scan |
| 仕様どおりか | 人間のレビュアー |
| マージしてよいか | Branch protectionと承認者 |
AIが「問題ありません」と答えても、テストが成功したことにはなりません。逆に、LintやSASTの失敗理由を人が読める形へ整理する用途なら、判定の責任を動かさずに使えます。
入れる場所はPRの少し手前
実装
|
v
ローカルのテスト・Lint
|
v
AIセルフレビュー
|
v
開発者が指摘を採否
|
v
CI・静的解析
|
v
人間レビュー
AIのコメントをそのままPRへ投稿すると、誤検知の確認をレビュアーへ押し付けることになります。開発者が一度読み、採用、却下、確認待ちに分けてから出す方が扱いやすいです。
リポジトリを丸ごと読ませない
リポジトリ全体を毎回渡す必要はありません。最低限、次の情報を組み合わせます。
- 変更の目的
- 対象ファイル
- git diff
- 関連する受入条件
- 実行したテストと結果
- 今回変更しない範囲
観点も固定します。自由にレビューさせるより、今回見てほしいものを5個ほど指定した方が、コメントの粒度が揃います。
次の差分をレビューしてください。
確認観点:
- 受入条件との不整合
- 境界値と異常系
- 例外処理とログ
- 認可・入力検証
- 不足しているテスト
出力:
1. 重大度
2. 根拠となる差分
3. 再現または確認方法
4. 修正案
断定できない内容は「確認待ち」としてください。
根拠となる差分と確認方法を必須にしたのは、もっともらしい一般論を除外しやすくするためです。該当行を示せない指摘は、いったん保留で構いません。
最初はCIを落とさない
最初からAIの結果でCIを失敗させるのは避けます。導入初期は、AIの出力をアーティファクトやPRコメントとして残すだけにします。
jobs:
verify:
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run security:scan
ai-review:
needs: verify
continue-on-error: true
steps:
- uses: actions/checkout@v4
- run: ./scripts/create-review-input.sh
- run: ./scripts/run-ai-review.sh
- uses: actions/upload-artifact@v4
with:
name: ai-review
path: artifacts/ai-review.md
この例には認証やデータ保護を書いていません。実運用では、外部へ送れる差分の範囲、ログ保存期間、シークレット除去を先に決めます。ここが決まらない間は、公開リポジトリかダミーコードだけで試すのが無難です。
「何件見つけたか」では測らない
AIレビューを改善するには、指摘数ではなく採否を記録します。
| 項目 | 内容 |
|---|---|
| finding_id | 指摘の識別子 |
| severity | 重大度 |
| accepted | 採用したか |
| reason | 採用・却下理由 |
| detected_by_human | 人間レビューでも発見されたか |
| escaped | 後工程へ流出したか |
指摘数だけを見ると、細かいコメントを大量に出す設定ほど高評価になります。残したいのは、採用されたか、どう確認したか、人間レビューより前に見つける意味があったかです。
運用メモ
- AIが出したコードにも通常のテストとレビューを適用する
- SASTの警告はAIの説明だけで閉じず、修正後に再スキャンする
- 不明点を推測で埋めず、確認待ちとして残す
- プロンプトやエージェント設定もGitで変更管理する
- AIレビューが停止しても、通常のCIを止めない構成から始める
どこから始めるか
PR前のセルフレビューを1種類だけ選び、しばらく採否を残してみるのが小さい始め方です。そこでノイズが多いなら観点を狭める。役に立つなら、テスト観点やCI失敗ログの整理へ広げる。コード生成とは別に、この順番で試す価値があります。