コードは速く出る。それでもレビューは速くならない
生成AIを開発へ入れると、実装は速くなります。一方で、レビュアーの人数やCIの実行時間は急には変わりません。生成量だけが増えると、PRがレビュー待ちになり、修正と再確認の回数も増えます。
そこで、AIをコード生成より先に「提出前の確認役」として使います。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
- 関連する受入条件
- 実行したテストと結果
- 今回変更しない範囲
レビュー観点も固定します。
次の差分をレビューしてください。
確認観点:
- 受入条件との不整合
- 境界値と異常系
- 例外処理とログ
- 認可・入力検証
- 不足しているテスト
出力:
1. 重大度
2. 根拠となる差分
3. 再現または確認方法
4. 修正案
断定できない内容は「確認待ち」としてください。
該当する差分と確認方法を必須にすると、一般論だけの指摘を保留にしやすくなります。
導入初期はCIを落とさない
最初からAIの出力でCIを失敗させると、誤検知が開発を止めます。導入初期は、結果をアーティファクトとして残すだけにします。
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
実運用では、外部へ送れる差分、ログ保存期間、シークレット除去を先に決めます。未決の間は、公開リポジトリかダミーコードだけで試します。
指摘数ではなく採否を測る
| 項目 | 内容 |
|---|---|
| finding_id | 指摘の識別子 |
| severity | 重大度 |
| accepted | 採用したか |
| reason | 採用・却下理由 |
| detected_by_human | 人間レビューでも発見されたか |
| escaped | 後工程へ流出したか |
指摘数だけを追うと、細かいコメントを大量に出す設定ほど高評価になります。採用率、確認時間、人間レビューより前に発見した意味を記録します。
2週間の小さな始め方
- PR前セルフレビューを1リポジトリ、1観点で試す
- AIの指摘を採用、却下、確認待ちへ分類する
- 人の確認時間と、後工程で見つかった不具合を記録する
- ノイズが多ければ観点を狭める
- 役立つ場合だけ、テスト観点やCI失敗ログの整理へ広げる
AIレビューが停止しても、通常のCIは動き続ける構成にします。プロンプトやエージェント設定もGitで変更管理します。
採否記録シートの配布URL: