AIコードレビューは「ここがバグです」と言ってくれる賢いbot……と思っていたのですが、私のチームで使い始めて気付いたのは「LGTMしか返さない」場面が意外と多いことでした。明らかにバグが埋まっているコードを投げても、表面的なlint指摘だけで終わる。「結局、本当にバグを見つけているのか?」という疑念がずっと残っていました。
外部のベンチマークは見ます。CodeRabbit 51.5% F1、Greptile 82% catch、Bugbot 58%。色々な数字が公表されていますが、テストセットと評価基準がバラバラで、自社コードに対する数字としては当てにならない。なら自分で計ろうということで、OWASP Top 10 / CWE Top 25から偏りなく選んだ30件の実バグを、3ツール(CodeRabbit / Claude Code Review / GitHub Copilot Review)に投げてみました。
結論を先に出すと、真のバグ指摘率は3ツール平均で42%。私の体感より低くもなく、高くもなく、現実的な数字でした。
正直に言うと、最初は「LLMがコードを書く時代なら、LLMがレビューも完璧にこなしてくれるはず」と楽観していました。実測値を見てそれが甘い期待だったと気付かされた、というのが今の感想です。AIに過大な期待を持っていた自分を、自分のスプレッドシートにぶん殴られたかたちです。
検証設計
公平な比較のために、以下を固定しました。
- コードベース: TypeScript + Next.jsの自社プロダクト(約4万行)
- バグ埋め方: 各バグを個別のPRに分けて投げる(30PR × 3ツール = 90回のレビュー)
- バグ選定: OWASP Top 10 / CWE Top 25 から10カテゴリ × 3件ずつ
- 判定: 「真のバグ指摘」「LGTM(見逃し)」「誤検知(false positive)」の3区分で人手判定
バグの内訳は以下の10カテゴリです。
| カテゴリ | バグ例 |
|---|---|
| SQL Injection | unsanitizedな文字列をクエリに混入 |
| XSS | dangerouslySetInnerHTMLにユーザー入力 |
| 入力検証漏れ | API receiverのzodバリデーション抜け |
| 認証バイパス | 認可チェックが特定のpathで抜けている |
| 暗号化弱化 | MD5でパスワードハッシュ |
| 競合状態 | 非同期処理のロック忘れ |
| NULL pointer | optional chainingの抜け |
| off-by-one | 配列indexの境界条件 |
| ロギング不備 | 機密情報をログ出力 |
| N+1問題 | Prismaのincludesの抜け |
カテゴリ別に3件ずつ、合計30件。バグサンプリングのバイアスを減らす設計にしました。
なぜこの3ツールに絞ったのか
社内の評価候補リストには10ツールほど挙がっていましたが、無料枠で30PR分の検証ができること、APIまたはGitHub Appで自動化できること、日本語のレビューコメントを許容することの3条件で絞ると、現実的に残るのはCodeRabbit / Claude Code Review / GitHub Copilot Reviewの3つでした。Greptileは個人的に試したかったのですが、無料枠が今回の検証規模に合わず、今回は見送りに。次回の検証では追加したいと思っています。
判定者は私を含めシニアエンジニア2人で、判定に揺れがあった指摘はもう1人を加えて多数決にしました。「LGTM」「真のバグ」「誤検知」の境界は思ったよりブレるので、判定の例集を先に作っておくことをおすすめします。私は最初それをサボって3週間で1回再判定をやり直しています。
結果: 真のバグ指摘率
| ツール | 真のバグ指摘 | LGTM(見逃し) | 誤検知 |
|---|---|---|---|
| CodeRabbit | 14/30 (47%) | 13/30 | 3/30 |
| Claude Code Review | 13/30 (43%) | 12/30 | 5/30 |
| GitHub Copilot Review | 11/30 (37%) | 17/30 | 2/30 |
| 3ツール平均 | 42% | 47% | 11% |
公開ベンチマークと比べて低めの数字に見えますが、これはコードベース全体に紛れさせた点が大きいと思っています。バグ単体のpatchだけ送るスタイルだと80%超の数字が出る一方、実プロジェクトのPRに紛れ込ませると見逃し率が一気に上がります。
カテゴリ別に見る得意・不得意
3ツールの「得意分野」がはっきり分かれました。
| カテゴリ | CodeRabbit | Claude CCR | Copilot |
|---|---|---|---|
| SQL Injection | 3/3 ✅ | 3/3 ✅ | 3/3 ✅ |
| XSS | 3/3 ✅ | 2/3 | 2/3 |
| 入力検証漏れ | 2/3 | 2/3 | 1/3 |
| 認証バイパス | 1/3 | 2/3 | 0/3 |
| 暗号化弱化 | 2/3 | 1/3 | 2/3 |
| 競合状態 | 0/3 | 1/3 | 0/3 |
| NULL pointer | 1/3 | 1/3 | 1/3 |
| off-by-one | 1/3 | 0/3 | 1/3 |
| ロギング不備 | 1/3 | 0/3 | 1/3 |
| N+1問題 | 0/3 | 1/3 | 0/3 |
「シグネチャ的に分かりやすいバグは強い」のが3ツール共通の傾向でした。SQL InjectionやXSSのような「禁止パターン」がはっきりしているものは全件発見できる。一方、ロジックや実行順序を読まないと分からないバグ(競合状態、off-by-one、N+1)はほぼ全滅です。
「シグネチャ的に分かりやすい」グループでも100%ではない点に注目してください。XSSやSQL Injectionは「禁止パターン」が広く知られているにも関わらず、Claude / Copilotは1〜2件取りこぼしました。共通の弱点は、エスケープ済みに見えるpath、文字列連結が複数ファイルに分かれているケースです。AIに「セキュリティのお手本問題」を出すと解けるけれど、現場のごちゃっとしたコードに紛れた瞬間に検知率が落ちる、という構図でした。
CodeRabbitの強み
入力検証・XSS・lintっぽい指摘が安定して強い。設定ファイル(.coderabbit.yaml)で語彙を増やせるので、カスタマイズの自由度も高めでした。
Claude Code Reviewの強み
「認証バイパス」のような文脈推論が必要なバグで頭一つ抜けます。コードベース全体のcontextをAgentic Searchで読みに行くので、「この関数は別の場所でauth middlewareを通っているか」を実際に確認できる。一方、表層的な誤検知も多めで、CodeRabbitより誤検知率が高い結果でした。
GitHub Copilot Reviewの強み
3ツール中で最も誤検知が少ない(2/30)。「自信があるものだけ言う」設計に見えました。逆に見逃し率が一番高く、保守的すぎる印象です。OSSプロジェクトでノイズを嫌うチームには向いていますが、社内プロダクトの守りには物足りません。
LGTMが返ってきても安心するな
今回の実測で一番厳しい数字は「3ツール全部に投げてもLGTMが返るバグが12件あった」ことでした。
30件のバグ × 3ツール = 90回のレビュー機会
└─ 真のバグ指摘: 38回
└─ LGTM (見逃し): 42回
└─ 誤検知: 10回
30件のうち、3ツール全部に見逃されたバグ: 12件 (40%)
3ツールに見逃された12件の内訳を見ると、競合状態とN+1問題で9件を占めました。**「複数ファイルを実行時にまたぐ問題」**は2026年5月時点のAIレビュー3ツールではほぼ捕まらないと考えた方が安全です。コードのテキスト面だけを読んでも、ランタイムでどの順序で何が呼ばれるかは見えない、というのが今の限界点でした。
ちなみにこの12件のうち2件は、私が「これは絶対AIが気付くだろう」と踏んでいたバグでした。N+1の典型例で、Prismaのincludeが抜けている、というド定番のやつです。3ツール全部にスルーされた瞬間は、人間レビュアーの存在意義をやや過剰に見直しました。
AIコードレビューが「LGTM」を返したからといって、バグがないとは限りません。特に実行順序・並行性・複数モジュールを跨ぐデータフローに関わるバグは、AIレビューを通り抜けてマージされます。人間レビュアーの目はこの領域にこそ必要です。
誤検知への向き合い方
誤検知も無視できません。3ツール合計で10件の誤検知が出ました。「ここはバグです」と断言された11%の指摘は、実は問題なしの正常コード。
代表的な誤検知パターン:
- テストコードの
expect(thing).toThrow()を例外無処理と判定 - 型推論で明らかにnon-nullableな変数をnullable扱い
- Reactの
useEffect内のstale closureを実際は問題ないのに警告
最初に誤検知をもらったとき、私は素直に信じてrefactorしてしまい、別のテストを壊した経験があります。AIレビューを「先生」として無批判に受け入れるとこういう事故が起きる、というのが学びでした。今は「AIレビューは1人の若手エンジニアの意見」くらいの重みで扱うようにしています。重みを下げてからの方が、かえって本物の指摘に向き合えるようになりました。
誤検知が多いとレビュアーが「狼少年効果」で本物のバグまで読み飛ばしてしまいます。私のチームでは誤検知率15%を許容上限にしていて、超えるツールは設定を見直すか別ツールに切り替えるルールにしました。
3ツール併用 vs 単一ツール
「複数AIに見せれば見逃しは減るのでは?」というのは自然な発想です。実際、私のチームでも一時期そうしていました。
3ツール併用で、3ツールのどれか1つでも指摘すれば「発見」とみなすと、
発見率: 21/30 (70%)
確かに見逃しは47%→30%まで下がります。ただし、レビュアーが処理するコメント数は単純に3倍。誤検知の絶対数も増えるので、チームの認知負荷が結構増えました。
私の現在のチームは「CodeRabbit + 人間レビュアー」の構成です。Claude Code Reviewは「Claude Code内のレビューsubcommand」として、開発者がローカルで作業中に都度回す使い方になっています。社内導入のロードマップとしては、CodeRabbitを軸にし、ClaudeはローカルIDE時に使うが現在のベストプラクティスだと感じています。
「3ツールに見せて全部見逃したバグは、レビュー仕組みの外で取る」という発想も必要です。私のチームではmutation testingを試験導入していて、コードカバレッジ95%でも実装ミスを検出できる箇所が10数件出てきました。これは将来別記事にまとめる予定ですが、AIレビュー単独で品質を保証する時代ではない、というのが今の見立てです。
あなたのチームでも同じ実験をするには
このベンチマークは外部に公開できる形でテストセットを作りました。同じ手順で自社版のベンチマークをしたい方への手順を残します。
- バグカテゴリの選定: OWASP Top 10 / CWE Top 25 から10カテゴリ × 3件
- PR形式で投げる: 1バグ1PR、コードベース全体に紛れさせる
- 判定者は3人: AI 1人、シニアエンジニア2人で多数決
- 3軸で集計: 真のバグ指摘 / LGTM / 誤検知
- カテゴリ別の得意・不得意を可視化: 表で並べる
工数は1人日 × 3週間くらいです。コストはAIレビュー利用料(月数千〜数万円)のみ。私はこの数字を出してから、社内のAIレビュー選定の議論が一気に短くなりました。「公開ベンチマークではなく、自社コードでの数字」が決め手になります。
まとめ
実バグ30件 × 3ツールの実測で見えたことは次の通りでした。
- 真のバグ指摘率は3ツール平均で42%(公開ベンチより低い)
- 得意分野が分かれる: CodeRabbit=lint系、Claude=文脈推論、Copilot=保守的
- 競合状態・N+1問題は3ツール全滅(複数ファイル/実行順序系)
- LGTMはバグ0の保証にはならない
AIコードレビューは「人間レビュアーの代替」ではなく、「lint+α」として組み込むのが現実解だと、今回の検証ではっきり分かりました。ロジック・並行性・データフロー系のバグはまだ人間が見るしかない。それを前提に、AIに何をやらせ、何を人間に残すかを設計するのが、2026年のレビュー仕組み化の出発点です。
レビューハーネス設計の章別ガイドは、無料Book「Engineering Code Review」全15章にまとめています。AIレビューと人間レビューを併走させる仕組みも、AIの誤検知率を管理する設計パターンも含めて扱っています。
Engineering Code Review (Kenimoto)
あなたのチームのAIコードレビュアー、誤検知率はどれくらいですか。AIレビューが見逃した結果、本番でバグになった事例があればぜひコメントで教えてください。私もこの記事の数字を年に2回更新していくつもりなので、現場の実感を共有できると助かります。