悩み：後輩のコードレビュー、毎回同じような指摘を繰り返すのに時間を取られている
Web制作会社でエンジニアをしていると、後輩や新しく入ったメンバーが書いたコードのレビューが定期的に回ってくる。納期が近い時期は特に、レビュー待ちのプルリクエストが積み上がり、「早く見てあげたいけど自分の作業も止められない」状態になりがちだ。しかも指摘の半分は「変数名を分かりやすく」「このループはもっと簡潔に書ける」といった、毎回似たような内容だったりする。
2026年に入ってから、プルリクエストを開いた瞬間にAIが自動でコードを読み、指摘コメントを付けてくれる「AIコードレビューツール」が普及してきた。CodeRabbitやQodo Merge、Greptileといったツールが代表格で、GitHubと連携させるだけでレビューの一次対応をAIに任せられるという触れ込みだ。実際にチームの開発リポジトリにCodeRabbitを導入し、1ヶ月ほど後輩のプルリクエストレビューに使ってみた。
結論を先に言うと、命名規則や無駄な処理、明らかなバグの兆候といった「コードそのものの問題」は、人間がレビューするより速く、しかも見落としなく指摘してくれた。レビュー待ち時間が大幅に短縮され、自分がレビューに割く時間もはっきり減った。一方で、「このプロジェクトではこの書き方をしない」「このAPIはこのクライアント案件では使わない」といった、チーム固有の暗黙ルールまではAIは拾ってくれなかった。
TOI
AIの指摘は全部「正しい」んだけど、「このプロジェクトではそれ、あえてやってないんだよな」ってやつが混ざってる
なぜAIコードレビューツールを試したか
CodeRabbitは、プルリクエストが作成・更新されるたびにAIがコード差分全体を読み込み、GitHub上に直接レビューコメントを自動投稿してくれるサービスだ。人間のレビュアーがまだ見ていない段階で「ここは意図した挙動か」「このエラーハンドリングは漏れていないか」といった一次チェックを済ませておいてくれる。
自分たちのチームは3〜4人の小規模体制で、レビュアーが自分一人に偏りがちだった。後輩が書いたコードの「明らかな問題」まで毎回自分の目で拾うのは非効率だと感じていたので、そこをAIに肩代わりさせて、自分は設計判断やクライアント固有の仕様確認といった、人間にしか判断できない部分に集中できないか試すことにした。
実際にやってみた
やった手順
- チームの開発用GitHubリポジトリにCodeRabbitを連携
- 後輩が実際に出したプルリクエスト（フォームバリデーション機能の追加）で自動レビューを実行
- AIが付けたコメント一つひとつを、後輩本人と一緒に「対応する／しない」を判定
- 1ヶ月間、通常のプルリクエストすべてでAIレビューを先に走らせてから人間レビューに回す運用に切り替え
AIが速かったこと
プルリクエストを開いてから数分で、コード全体を読んだ上でのコメントが一通り出そろう点にまず驚いた。
- 未使用の変数や、重複しているバリデーション処理をほぼ確実に検出
- 「このif文、早期returnにした方が読みやすい」といった可読性の指摘を、コードの規模に関わらず全箇所に対して実施
- 入力値のnullチェック漏れなど、動作には影響しないが将来バグになりうる箇所を先回りして指摘
- 後輩が「なぜこの指摘が来たか分からない」と聞くと、コメント内で理由を日本語で説明してくれるため、教育的なやり取りがAI相手で完結する場面も多かった
「コードとして正しいかどうか」の一次チェックにかかる時間は、体感で7〜8割減った。以前は自分が読んで気づいていたレベルの指摘を、プルリクエストを開いた瞬間にAIが先回りしてくれるので、人間のレビューはその続きから始められるようになった。
AIに任せきれなかったこと
一方で、1ヶ月使い続けて「これはAIには判断できない」と感じた指摘のズレがいくつも出てきた。
- 一般的には推奨される書き方でも、このプロジェクトでは別の理由（過去に採用したライブラリとの整合性）であえて使っていない書き方に対して、AIは「こちらの書き方が望ましい」と繰り返し指摘してくる
- 「このクライアント案件だけ、旧システムとのAPI互換性のためにあえて冗長な処理を残している」という経緯をAIは知らないため、毎回同じ箇所に同じ指摘が付く
- コードの正しさとは別の「この機能はそもそもこのタイミングで実装すべきか」といった設計判断・優先順位の話には触れてくれない
- チーム内のコーディング規約書（Notionにまとめてある社内ルール）は連携していないため、規約に沿った命名か、社内特有の関数命名パターンに合っているかは判定対象外だった
AIは「一般的に正しいコード」を基準に指摘するため、そのチーム・案件だけの経緯や取り決めを踏まえた判断は、結局人間が拾うしかなかった。同じ指摘が毎回繰り返されるのを見て、後輩が「これは無視していい指摘です」と自己判断で流してしまうケースも出てきており、AIの指摘に対する温度感を教えるのも自分の仕事になった。
TOI
「なんでこの指摘、毎回無視していいんですか」って聞かれて、経緯を説明するのに結局15分かかった
結局どこまで任せていいか：レビューの種類別に整理する
1ヶ月運用してみて分かったのは、レビューの中身によって「AIに任せていい範囲」がはっきり分かれるということだった。
構文的な正しさ・可読性・一般的なバグの兆候の場合
命名規則、重複コード、nullチェック漏れといった「コードそのものの品質」に関する指摘は、AIにほぼ全面的に任せてよい。見落としが少なく、レビュー待ち時間の削減効果が一番大きい領域。
チーム・案件固有の経緯を踏まえた判断が必要な場合
「あえてこう書いている」理由がある箇所は、AIの指摘を鵜呑みにせず人間が「これは対応不要」と明示的に判定する必要がある。この判定を後輩任せにすると、正しい指摘まで一緒に無視されるリスクがある。
設計判断・優先順位に関わる場合
そもそも実装すべきか、どのタイミングで着手すべきかといった話はAIレビューの対象外と割り切り、人間同士のレビューか口頭のすり合わせに委ねる方が早い。
まとめ
- CodeRabbitのようなAIコードレビューツールは、命名規則や重複コード、nullチェック漏れといった「コードそのものの品質」チェックを高速かつ網羅的にこなしてくれ、レビュー待ち時間を大きく削減できる
- ただしAIは「一般的に正しいコード」を基準に指摘するため、そのチーム・案件だけの経緯を踏まえた「あえてこう書いている」判断まではできず、同じ指摘が繰り返される
- AIの指摘をそのまま鵜呑みにせず、「対応する／しない」を人間が明示的に判定する運用にしないと、後輩が正しい指摘まで自己判断で無視してしまうリスクがある
- 次のアクションとしては、チーム固有の「あえてこう書いている」ルールを一覧化しておき、AIレビューで繰り返し出てくる指摘には都度そのルールを引用して却下する運用にすると、後輩の自己判断のブレを防ぎやすい
コメント