レビュワー支援ツールをレビューイが使ってみた
はじめに
札幌支社の活動の一環として、AI駆動開発をテーマにした勉強会に参加してきました。
今回はその参加レポートのつもりで書き始めたのですが、書いているうちに自分の課題や、これから先エンジニアが求められることについて改めて向き合うきっかけになりましたので、この記事が誰かの参考になれば幸いです。
いろいろな話がありましたが、自分に一番刺さったのは、AIコーディングの「その次」に起きている問題の話でした。
- AIに任せるとPRが大きくなりがちで、初回レビューに時間がかかる
- レビューを待っている間に別の作業を始めてしまい、返ってくる頃には自分でもPRの内容を忘れている
- そもそも、自分よりレベルが高い人のコードをレビューするのは難しい。AIが人間より良いコードを書くようになるほど、人間のレビューは難しくなる
聞きながら、正直かなり耳の痛い話だなと感じました。
正に自分がレビュワーに負担を押し付けている側だったからです。
1. AIのコーディングに対する理解の難しさ
AIを使うようになり実装速度は明らかに上がりましたが、一方でよくない状況に陥っていると感じる機会も増えました。
コードを理解しきれていないまま、理解したつもりになってしまっているということです。
書くのが速くなった分、一つひとつの変更に向き合う時間は確実に減りました。動いているし、AIの説明も筋が通っているように見えるので、とりあえず通してしまう。そして、見落としがレビュワーのところで見つかります。
なぜ「理解したつもり」になるのか
AIと一緒にコードを書くとき、頭の中では2つのことが同時に走っています。
- 自分で見当をつける — こう実装すべきだろう、という当たりをつける
- AIの提案を理解する — 返ってきたコードが何をしているのか読み解く
自分でゼロから書いていた頃は1しかありませんでした。コードを書くということは、常に自分の理解とイコールだったからです。
今はAIによる実装プラン立てを参考にすることが増え、2の比重が大きくなりました。そして厄介なのは、2は「わかった気」になれてしまうことです。読んで筋が通っていれば納得はできますが、納得することと理解することは違います。
さらに問題なのは、AIが「〜を考慮して実装しました」と説明してくれることです。
本当にそうなのか？と疑うにもエンジニアとしての経験や知識が必要ですが、足りていないと見落としやバグの原因になります。
AIの言い分と成果物は必ずしも一致しません。
2. 負担の皺寄せはレビュワーにいく
自分が理解しきれていない分は消えるわけではなく、レビュワーのところに移動します。
しかもレビュワー側の条件はもっと厳しく、
- PRが大きい（AIでスピーディーに書いた分、差分が多くなる）
- コードの質は上がっているので、指摘すべき点を見つけるのに集中力が要る
勉強会で出ていた「自分よりレベルが高い人のコードのレビューは難しい」というのは、正にこのことかと思います。質の高いコードは、レビューが楽なコードではありません。
また、レビューが返ってくるまでに時間がかかると、レビューイはその間に別の作業を始めてしまいます。
そうすると、レビューイの方でも「思い出す」コストが余分に発生します。
書く速度は上がったがレビューの速度は変わっていない。
AIの書くコードのレベルが上がるにつれてレビューの難易度も上がっている。
自ずとレビューに時間がかかる＝「思い出す」という新たなコストが膨らむ。
ここがAIによるコーディングのボトルネックになっている部分だと感じています。
3. AIコーディングによる負担を軽減するには
レビュー負担への対処は、ツールを入れることだけではありません。思いつく範囲でも、
- PRを小さく分割する
- レビュー観点をドキュメント化してチームで共有する
- Claude Code の
/reviewや GitHub Copilot の PR レビューを使う - CodeRabbit のようなレビュー特化のAIツールを入れる
などがあると思います。
今回はこのうち、レビューイである自分が今日から一人で始められることとして、AIレビューツールを試してみました。
4. 試したこと
今回は勉強会で登壇してくださっていた方が提供しているCodeRabbitというレビュワー支援ツールを3つの形態で試しました。実際に使用してみると、同じサービスでも使う場所が違うと役割も変わってくると感じました。
「ターミナルから離れずにチェックしたい」→ CLI
ターミナルにてCodeRabbitを使用する使い方です。
インストール後に対象ブランチで cr と打つだけで、CodeRabbitがブランチ内のコードに対してレビューを行います。個人的にはこの起動コストの低さがかなりありがたく、「PRを出す前に一応見ておくか」のハードルが下がるのが良いと思いました。
コードレビュー結果が出てくるまでの時間も以下二つに比べると少し早い気がしました。
「実装時の会話とコードと指摘が離れている」→ VSCode拡張
拡張版はレビュー結果がUIとしてエディタ上のコードに直接表示されます。指摘が該当行に紐づくので、「どのファイルの何行目の話か」を探す手間がありません。
レビュー範囲を3つから選べる
拡張版は、レビューする範囲を 未コミットのみ／コミット済み／全体 から選べます。これが地味に便利で、使いどころが分かれます。
| モード | 使う場面 |
|---|---|
| 未コミットのみ | 書いている途中。手を止めてすぐ回す |
| コミット済み | 区切りがついたところで、そのコミット分をまとめて確認 |
| 全体 | PRを出す直前。レビュワーが見るのと同じ範囲を確認する |
特に「未コミットのみ」は書いた直後にレビューを受けられるので、まだ頭に内容が残っているうちに直せるのがとても良かったです。1章に書いた「理解したつもり」の問題は時間が経つほど固定化するので、その場で潰せるのは大きいほか、単純に修正の手戻りも小さく済みます。
一方で「全体」は、レビュワーの視点を先取りするモードだと捉えています。PRを出す前に、レビュワーが見るのと同じ差分を同じ条件で読んでもらう。ここで出た指摘は、そのままレビュワーが言わずに済んだ指摘になります。
実装時の会話と並べて見られる
また、Claude Code のセッションを開いたまま、並べて見られるのが個人的には嬉しかったです。
一画面に
- CodeRabbit の指摘
- 実際のコード
- 実装時にどう指示して、AIが何と言って書いたか
- AIとどういった壁打ち（相談）をしてこの実装になったか
が一画面に全部揃います。
指摘を受けたとき、普通は「なんでこのコードこうなってるんだっけ」から始まりますが、その答えが隣に残っている状態でレビューを読めるので、理解を組み直すコストが大きく減ります。
「チェック済みの範囲がレビュワーに見えない」→ GitHub App
こちらは14日間の無料期間を超えて使用する場合有料になりますが、一番機能が豊富でよりレビュワー支援に特化したものになっています。
web上からGitHubなどのアカウントでログインし、自身やプロジェクトのリポジトリに導入すると、PRに対してbotが自動でレビューしてくれます。指摘だけでなく、
- 変更内容のまとめ
- シーケンス図
- 修正にかかる想定時間
- このままマージしていいかの判断
まで出してくれます。
実感として一番大きかったのは、概要とシーケンス図で処理の流れを掴んでからコードを見に行けることでした。差分を上から順に読んで全体像を組み立てる、という作業が要らなくなります。
また、Web上ではレビュー待ちのPRをトリアージしてくれる機能（ベータ版）もあります。どれから手をつけるべきかを整理してくれるもので、こちらはレビュワー向けに特化しています。
| 見えるもの | |
|---|---|
| CLI・拡張版 | この行がなぜこうなっているか（実装時の文脈と一緒に読める） |
| App版 | この変更全体で何が起きるか（動きの流れをまとめて見られる） |
CLI・拡張版が与えてくれるのは自分にしか持てない文脈で、App版が与えてくれるのは誰が読んでも同じように読める文脈という違いがありました。
CLI と拡張版は、どちらもローカルで完結します。便利な反面、自分がチェック済みであることがレビュワーに一切伝わりません。
App版はPR上にレビューの過程が残るので、レビュワーは「何が指摘されて、どう対応されたか」を見た上でレビューに入れます。同じ確認を二度しなくていい状態が常に作れます。
5. 困りごとに合った使い方を選択する
| 困りごと | おすすめの使い方 |
|---|---|
| チェックの起動コストが高い | CLI（cr の二文字） |
| 実装時の文脈が失われる | VSCode拡張 |
| PRの差分が大きくて把握できない | GitHub App（要約） |
| チェック済み範囲が伝わらない | GitHub App |
勉強会では「CodeRabbit はレビュワー向け、Claude などはレビューイ向け」という整理が出ていました。実際に触ってみると、CodeRabbit も形態によっては色々な使い方ができるというのが実感です。
レビューイの理解もサポートしてくれることで、結果としてレビュワーの負担を減らすことにもつながります。
6. 効果が弱かったところ
便利なところが多かった一方、効果が弱いと感じたところもありました。
- 設計判断の妥当性
- 業務要件との整合（そもそもこの仕様でいいのか）
前提として、AIレビューを通したから安心、にはなりません。
上記をサポートしてくれるSkillsなども現在では多く存在しますが、レビュー支援ツール単体ではここまでの判断には至りません。
また、使う側にもスキルが要ります。勉強会で出ていた「AIの答えにどれくらい問いかけできるかが重要。自分が知らないことは質問できない」という話は、レビューツールにもそのまま当てはまります。
指摘の採否を自分で判断できないと、言われた通りに直すだけになって、理解はむしろ遠のきます。
それでは1章に書いた問題が形を変えて残るだけです。
おわりに
書く速度が上がった分、レビューが重くなっているというのは自分の周りだけの話ではなく、AIを使う開発現場で今広く起きていることだと思っています。
今回Coderabbitを使って便利だと感じた場所は、そのまま今レビューイとレビュワーが困っている場所と重なっていました。
最終的にコードに責任を持つのは人間です。また、現在のAIは人間によってより効率的になるよう土台を整えていく必要がありますが、調整し改善するにはAIの出力したものを正しく理解しなくてはいけません。AIの性能が上がるほどコードのレベルも上がるので、その判断ができる人の価値はむしろ大きくなると思っています。
AIが目覚ましい進化を遂げているように、使用される技術もものすごいスピードで変化していきます。AIに置いていかれてしまわないためにも、常に自分の理解を助けてくれるツールは積極的に使用していきたいです。