AIコードレビューツールまとめ — 導入して定着させるまでの設計

主要ツールの比較

費用はチームの人数とPRの本数で逆転する。人数が多くPRが少ないなら席課金のない Greptile、少人数で高頻度なら席課金の CodeRabbit や Graphite が安い。計算の仕方は本サイトの「CodeRabbit vs Greptile」で具体的に示している。

導入直後は1つのPRに20個以上の指摘が付く。チームが真面目だと全部に対応しようとして、マージまでの時間が導入前より延びる。これで「AIレビューは邪魔だ」という評価が定着する。

対処は2段階にする。最初の2週間は「指摘は参考情報、対応は任意」と明示して回す。この期間に、どの種類の指摘が実際に有用だったかを記録する。2週間後、有用でなかった種類を設定で無効化する。

• 無効化を検討するもの：命名の好み、コメントの追加提案、既存コードと一貫した書き方への指摘
• 残すもの：null/undefined の扱い、エラー処理の抜け、型の不整合、競合しうる非同期処理
• 判断が分かれるもの：テストの追加提案（チームのテスト方針に依存）

失敗2：誰も読まないコメント欄になる

逆のパターンで、指摘を放置する運用が定着すると、PRのコメント欄が自動コメントで埋まる。人のレビュアーが書いたコメントが埋もれて見落とされるので、放置は無害ではなく有害である。

対処は、指摘に対する扱いをルールにすることである。「対応する」「意図的にそうしている（理由を1行書く）」「次のPRで直す（Issueを立てる）」の3択にして、未処理のまま残さない。3択のどれかを選ぶのに10秒しかかからないので、実際に回る。

レビューの深さを選ぶ

ツールによってレビューの深さを選べる。Greptile はクレジットの段階（Base 1／Plus 3／Apex 10）で読む深さが変わる。すべてのPRを最も深いレビューに回すと費用がかさみ、かつ指摘が多すぎる問題が再発する。

• 依存関係の更新、文言の修正 → レビュー不要、または最も軽い設定
• 通常の機能追加 → 標準のレビュー
• 認証・決済・データ移行に触るPR → 最も深いレビュー

この振り分けをラベルやパスのルールで自動化できるツールもある。手で選ぶ運用は続かないので、設定に落とせるかを選定の基準に入れるとよい。

人のレビューは何をするのか

AIレビューを入れても人のレビューは残る。残るのは、仕様との整合、設計の妥当性、そして「この変更は本当に必要か」という判断である。AIは与えられた差分の中で正しさを見るが、その差分がそもそも作るべきものかは判断しない。

実際に導入したチームで起きる変化は、レビューの時間が減ることより、レビューの内容が設計の議論に寄ることである。機械的な指摘を前段で落とすと、人が読む時間を設計に使える。これが本来の効果である。

よくある質問

Q. 小さなチームでも効果がありますか。

A. 1人開発でも効果があります。レビュアーがいない状況で、機械的な見落としを拾う役割として機能します。公開リポジトリなら CodeRabbit が無料、非公開でも Greptile の無料枠で月50本まで回ります。

Q. AIの指摘が間違っていることはありますか。

A. あります。文脈を取り違えて、正しいコードに誤りだと指摘することがあります。だからこそ指摘を「対応必須」にせず、人が判断する前提の運用にする必要があります。