はじめに
プルリクエストにAIレビューを組み込んでから、1年が経ちました。この記事では、Zenn版で書いた振り返りをもとに、Qiita向けに「どんな種類の指摘は拾えて、どんな種類の指摘は拾えないか」を表にまとめ、人とAIの役割分担の実務的な考え方を追加しています。
効くところと効かないところ
観測してきた範囲での傾向を、大まかに分類すると次のようになります。厳密な統計ではなく、日々のレビューで繰り返し見えてきたパターンです。
| 指摘の種類 | AIレビューの傾向 |
|---|---|
| 命名規則、フォーマット、明らかなタイプミス | 拾いやすい。人が見る前に機械的に指摘できる |
| 既存の似た処理との実装の重複 | 差分だけを見るレビューでは見落としやすい。プロンプトにリポジトリ全体の文脈を渡せるかで結果が変わる |
| セキュリティ上よくあるパターン(未検証の入力をそのまま使うなど) | 一般的なパターンは拾いやすいが、そのプロジェクト固有の前提を踏まえた判断は弱い |
| 「このビジネスルールはここで正しいか」といった業務知識が要る判断 | 拾えない。レビュアーがドメインを知らなければ、AIも同じく知らない |
| チーム内の暗黙の合意(過去のふりかえりで決めた運用ルールなど) | 拾えない。文書化されていない限り、AIにもレビュアーにも見えない |
人とAIの役割分担
この表から見えてくるのは、AIレビューを「レビューの代わり」ではなく「レビューの最初の一段」として使うと相性がいいという点です。フォーマットや命名、よくあるパターンの指摘はAIに任せ、人のレビュアーは業務知識が要る判断と、チーム固有の前提が絡む部分に時間を使う、という分け方です。この分担にしてから、人のレビュアーが「ここのロジックは本当にこの前提で合っているか」といった、コードの読み方そのものに関わる指摘に時間を使えるようになったと感じています。
できないこと
- AIレビューの指摘の傾向は、私たちの運用範囲での観測です。プロジェクトの性質やコードベースの規模によって、傾向は変わり得ます。
- ドメイン知識やチーム固有の暗黙ルールは、AIに渡していない限り拾えません。渡す仕組み自体を作らない限り、この弱点は解消しません。
- AIの指摘をそのまま採用するのではなく、人が妥当性を確認してから反映しています。誤った指摘をそのまま直すと、かえって不具合を生むことがあります。
最後に
AIコードレビューは、拾えるものと拾えないものが、はっきり分かれています。その境目を意識して人とAIの作業を分けることが、導入してからの1年で一番の学びでした。気になったところから、手元のレビュー運用に当てはめて試してみてください。