AIレビューを開発フローに入れるなら、AIには決めた観点の指摘と根拠を返してもらい、採否や次の行動は担当者とワークフローが決めることが大切です。
PRを見て指摘を返すところまで任せるのか。指摘を直すか、レビューを終えるか、マージしてよいかまで任せるのか。ここを決めないまま導入すると、未完了のレビューを完了扱いして、誰も確認しないまま次へ進むことがあります。
この記事では、この責務分担を開発工程に組み込むときに決めておきたい、レビュー対象、出力、実行記録、判断担当を整理します。再実行するか、停止するか、リスクを受け入れるかは、呼び出し側のワークフローや人が担います。
入力から次の行動まで、担当を決める
AIレビューをPR工程へ入れるなら、レビュー依頼の前後で誰が何をするかを決めます。
| 工程 | 担当 | 受け渡すもの |
|---|---|---|
| 対象を決め、入力をそろえる | 開発者またはワークフロー | 要件・計画・差分・テスト結果など、今回見る範囲 |
| 決めた観点でレビューする | AIレビュアー | 指摘、該当箇所、根拠、判断できなかった範囲 |
| 指摘を確認し、採否を決める | 開発者・レビュー担当者 | 修正、却下と理由、追加確認の依頼 |
| 未完了やリスクを扱う | 呼び出し側のワークフロー・責任者 | 再実行、停止、人への引き継ぎ、例外承認 |
この表は、チームで責任の所在を決めるための提案です。低リスクの変更でワークフローが自律的に次へ進む場合も、その条件と権限を誰が決めたかを残します。
たとえばAIが「問題なし」と返しても、予定したレビューがタイムアウトしていれば、確認が終わったとは扱えません。再実行するか、人へ引き継ぐかは呼び出し側が決めます。AI自身の返答に停止の責任まで持たせないためです。
AIレビューを開発フローのどこで使うか
まず始めるなら、実装後にPR差分をレビューさせる方法が分かりやすいです。実装後の手戻りを減らしたいチームは、計画が固まった時点や実装中にも、承認済み計画との照合を加えます。AIレビューはPRの差分確認だけに限らず、変更の段階に合わせて見る対象を変えられます。
- 実装前：計画や設計が要求を満たしているか、抜けている条件はないか
- 実装中：変更が計画や既存の設計と食い違っていないか
- 実装後：差分やテスト結果から、見落としや回帰の懸念がないか
どの段階でも、AIには「何を見るか」と「何を返すか」を決めて渡します。たとえば「PRをレビューして」だけでなく、「承認済みの計画と差分を照合し、問題があれば該当箇所と根拠を示す。判断材料が足りないときはその状態を返す」と定義します。
今回のレビューで何を確認済みとみなすかも決めます。型検査やテストの結果は既存の検査から受け取り、AIには計画と差分の整合など別の観点を依頼できます。同じ確認を重ねず、結果の受け取り先を決めておくと、指摘を次の行動へつなげやすくなります。
指摘を返す責務と、止める責務を分ける
AIレビューの出力にapproveやno findingsがあっても、それだけでマージや修正完了を決める契約にしないようにします。レビューの結果は判断材料です。チームが決めた条件を適用し、先へ進めるかを決める役割は呼び出し側に残します。
River Reviewは、指摘とレビュー上の評価を返しますが、GO / NO-GO、反復、停止、承認、マージは呼び出し側や人の責務です。自動で進める条件を設ける場合も、そのルールと監督境界はワークフロー側で持ちます。
指摘は開発者が修正要否を考える材料、実行状態はワークフローが再実行や引き継ぎを決める材料です。指摘が0件でも予定したレビューが未完了なら、レビューが問題を確認し終えたとは言えません。River Reviewの実験段階のReview Coverageは、予定したレビュー単位の実行状態を記録します。複数回の結果を比較する際、最新のレビューが一部未実行または実行されていない場合、「修正ループを終えられる」という信号を取り下げます。実行記録そのものがない場合は、この変更の対象外です。再実行や停止の判断は呼び出し側が担います。これは、レビュー実行の記録とループ制御を分ける実装例です。
この記録もレビューの正しさを保証するものではありません。すべての予定単位が実行済みでも、見落としゼロや変更の安全性を証明しません。実行状態、指摘内容、テスト結果、チームの停止条件を合わせて判断します。
導入前に決めておく4つのこと
最初から大きなレビュー基盤を作る必要はありません。まず対象を絞り、次の項目をチームで決めます。
- 何を見せるか：差分だけか、計画・要件・テスト結果も渡すか
- 何を返してもらうか：指摘、根拠、重要度、未確認の範囲をどう記録するか
- 誰が次を決めるか：指摘の採否、再実行、停止、リスク受容を誰が担当するか
- 未完了や不明をどう扱うか：失敗・タイムアウトなら再実行するか、人へ渡すか。記録がない場合に成功扱いしないため何を確認するか
たとえば、チームの運用契約を次のように書けます。役割名や再実行の上限は、チームの権限設計に合わせて具体化します。
AIレビューをチームの工程にする
まず一つのリポジトリかPR種別を選び、今回見る範囲、レビュー出力、採否と停止の担当、未完了時の扱いを書いて試します。実行状態、指摘の採否、再実行や引き継ぎの有無を記録し、誤検知や判断の迷いが繰り返されたらレビュー観点や停止条件を見直します。AIレビューを単発のコメントで終わらせず、次の担当と行動へつなぐところから始めます。
