AIにコードを書かせた後、別のAIに確認させる。便利な使い方ですが、指摘がなかったというだけで、安全だと判断できるのでしょうか。
GitHubは2026年10月5日、AIコードレビューを比較する「ReviewBench」を公開しました。研究プレビューとして、評価用のデータや採点方法を公開しています。［1］
ReviewBenchは、AIによる見逃しや指摘の質を調べる仕組みです。コードの安全性を保証する認証ではありません。利用する際は、総合点に加え、自分の開発でどこまで任せられるかを確かめる必要があります。
ReviewBenchとは？1億件の分析と219件の評価は別
分析したコード変更は1億390万件ですが、実際の評価対象は219件です。この二つの数字は、それぞれ役割が異なります。［1］
| 項目 | 公式発表の内容 | 読むときの注意点 |
|---|---|---|
| 設計に使った分析 | GitHub上の1億390万件のPR | すべてのPRでAIを採点したわけではない |
| 評価対象 | 219件の公開PR | 企業内のコードでも使えるかは別途確かめる |
| 収録範囲 | 187リポジトリ、19言語 | 対応言語が多くても、各言語で十分に評価されているとは限らない |
| 変更規模 | 小さな変更の比重を減らし、実質的な変更を重視 | 小さな修正が多い現場とは、変更内容の構成が異なる |
PRはプルリクエストの略です。コードの変更を提案し、確認してもらうための単位を指します。リポジトリは、コードや変更履歴をまとめて保管する場所です。
例えば、決済処理の変更と、画面に表示する文字の修正では、確認する内容が違います。総合順位だけを見るより、自分の現場に近い変更での成績を確かめるほうが、判断しやすくなります。
「96.6％一致」はAIレビューの正解率ではない
96.6％は、評価用の正解データについて、技術者とReviewBenchの判定が一致した割合です。コードの問題を96.6％発見できたという数字ではありません。［1］
GitHubは、データ作成に参加していない上級エンジニアに、正解とした項目を再判定してもらいました。これは社内監査であり、外部機関が実際の開発での安全性を認証したものではありません。
試験に例えるなら、採点に使う答えが妥当かどうかを確認した数字です。受験者に当たるAIが、その問題をどれだけ解けるかは、別に測る必要があります。
正解データに含まれていない問題まで、すべて見つかっているとも限りません。評価の土台がよくできていることと、見逃しがないことは、分けて考える必要があります。
信用できるかを判断するには「正しい指摘」と「見逃し」を分ける
指摘の多くが正しいAIでも、指摘する数が少なければ、多くの問題を見逃している可能性があります。反対に、幅広く問題を拾うAIでは、人が確認するコメントも増えがちです。
この違いを見る指標が「適合率」と「再現率」です。適合率は、出した指摘のうち正しいものの割合です。再現率は、評価対象の問題のうち、見つけたものの割合です。
ReviewBenchは、既知の正解に一致する指摘と、正解集には含まれていない有効な新発見を分けて評価します。前者を評価するものがgrounded、新発見も評価に含めるものがaugmentedです。［1］
新発見を評価する考え方には意味があります。人が作った正解集と一致しない指摘でも、コードを確かめると、本当の問題だと分かることがあるからです。
独自計算：同じF1「45％」でも使い勝手は違う
総合点が同じでも、見逃しと余計な指摘の内訳が違えば、任せられる仕事は変わります。次の表は、その違いを示す仮の計算です。実在する製品の成績ではありません。
| 仮のレビューAI | 適合率 | 再現率 | F1 | 想定される使い方 |
|---|---|---|---|---|
| A：指摘を絞る | 90％ | 30％ | 45％ | 確認負担を抑える補助役 |
| B：幅広く指摘する | 30％ | 90％ | 45％ | 見逃しを減らすための候補出し |
計算式は「F1＝2×適合率×再現率÷（適合率＋再現率）」です。AもBも、2×0.9×0.3÷1.2＝0.45となります。
Aでは正しい指摘を期待しやすい一方、既知の問題の70％を見逃します。Bは90％を拾いますが、指摘の70％は正しくありません。認証や決済などの変更では、総合点だけを見て、この差を見落とさないようにする必要があります。
競合比較：Cubic、Greptile、CodeRabbit、Copilotで傾向は違う
競合製品を、どれだけ問題を拾えるか、指摘がどれだけ正しいかで比べると、違いが見えてきます。比較材料の一つが、Martianの「Code Review Bench」です。GitHubのReviewBenchとは別の評価です。
Martianのオンライン評価では、実際の公開PRを追跡し、AIの提案と、その後に人が行った修正を照合して採点します。そのため、ここでの適合率は、指摘の技術的な正しさだけを測る数字ではありません。［3］
| 製品 | F1 | 適合率 | 再現率 |
|---|---|---|---|
| Cubic Dev AI | 64.9％ | 71.4％ | 59.4％ |
| Greptile | 61.9％ | 79.0％ | 50.9％ |
| CodeRabbit | 61.8％ | 70.1％ | 55.3％ |
| GitHub Copilot | 60.9％ | 67.2％ | 55.6％ |
出典は、2026年10月7日時点で取得できたMartian公式ページの「Last month」の表示です。評価済みPRは、全体で15,131件と表示されていました。数値は更新によって変わります。［2］
この表示では、Cubicは再現率、Greptileは適合率が高い傾向にあります。ただし、各製品が同じPRをレビューした対照実験ではありません。利用者やコードの違いも含まれるため、数ポイントの差だけで製品の優劣は決められません。
ReviewBenchの点数とも、大小を比較することはできません。評価対象も、正解の定め方も異なるためです。共通する製品名があっても、異なる試験の点数を同じ物差しで比べることは避けるべきです。
独自試算：欠陥が少ない現場ほど、誤指摘が目立つことがある
同じ検出能力でも、調べる対象にどれだけ問題が含まれているかによって、指摘が正しい割合は変わります。これは、健康診断で珍しい病気を調べるときにも生じる問題です。
以下は、その仕組みを説明するための仮定です。1,000個の確認項目を、一つずつ判定するとします。本当の欠陥を拾う割合は80％、正常な項目を誤って問題と判定する割合は5％とします。
| 確認対象の状態 | 実際の欠陥数 | 正しく出る指摘 | 誤って出る指摘 | 指摘の適合率 |
|---|---|---|---|---|
| 欠陥が20％含まれる | 200個 | 160個 | 40個 | 80.0％ |
| 欠陥が1％含まれる | 10個 | 8個 | 49.5個相当 | 約13.9％ |
後者の計算は、8÷（8＋990×0.05）です。49.5個は、同じ条件の評価を繰り返した場合の平均的な件数を表します。実際の一回の判定で、半個の指摘が出るわけではありません。
この例から、品質の高いコードでは、正常な箇所に対する少数の誤指摘が目立ちやすいと分かります。公開ベンチマークと同じ適合率が、自社でも得られるとは考えないほうがよいでしょう。
これは、ReviewBenchや特定製品の性能を推定した計算ではありません。実際のコードレビューでは、一つの変更に複数の問題が含まれます。現場のデータで確かめる必要がある理由を、単純化して説明した例です。
独自計算：コメントが61％増えるなら、1件の確認時間を約38％短縮する必要
AIの指摘の質が向上しても、人が確認する時間まで減るとは限りません。GitHubが報告したCopilotの構成変更では、本番でのコメント数が従来比61％増えました。［1］
ここで、従来のコメントが100件あり、1件の確認に3分かかると仮定します。確認時間は300分、つまり5時間です。同じペースで161件を確認すると483分かかり、183分増えます。
| 仮定した状態 | コメント数 | 1件の確認時間 | 合計時間 |
|---|---|---|---|
| 変更前 | 100件 | 3分 | 300分 |
| 61％増えた後 | 161件 | 3分 | 483分 |
| 合計時間を維持する条件 | 161件 | 約1.86分 | 約300分 |
300÷161＝約1.86分です。1件の確認時間を、3分から約37.9％短くする必要があります。
これは、実測した作業時間ではありません。コメント数の増加が人の確認負担にどう影響するかを計算したものです。実際には、根拠が明確な指摘なら短時間で確認できますし、修正には別に時間がかかります。
もちろん、重要な不具合を防げるなら、確認時間が増えても価値があります。この試算は、コメントが増えることを問題視するものではありません。導入効果を測る際は、AIの利用料に加え、人の確認時間と、防げた問題も記録する必要があるということです。
過去事例：モデル名より、レビューの進め方が効く場合もある
AIレビューの成績は、モデルの性能に加え、周辺のコードをどう調べるかによっても変わります。LangChainは2026年7月31日、同じ「ReviewBench」という名前で別の評価を発表していました。GitHub版と混同しないよう注意が必要です。［4］
LangChain版は、同社のLangSmithで行われたレビューを基にしています。発表時の規模は59タスク、64件の基準問題でした。最も成績のよい基本構成でも、基準問題を見つけた割合は約30％と報告しています。［4］
同社はさらに、20タスクを使った比較で、レビュー方針を変えました。変更箇所に加え、呼び出し元やテスト、関連する実装も確かめるよう指示したところ、LunaのF1は0.32となりました。ただし、この構成では推論の設定も調整しているため、指示文を変えた効果だけを切り分けることはできません。［4］
この事例からは、より高性能なモデルを購入する以外にも、改善の余地があると考えられます。自社で重視するルールを伝え、関連するコードを参照できるか確かめることにも意味があります。
例えば、複数企業のデータを扱うサービスでは、利用者が自社の情報だけにアクセスできることが重要です。変更した行に加え、呼び出し元や既存の権限処理まで確認すれば、そのルールに反する変更を探しやすくなります。
「指摘なし」を信用する前に、確認した範囲を確かめる
コメントがないときは、「確認した結果、問題がなかった」のか、「確認対象に入っていなかった」のかを区別します。この違いは、AIの点数とは別に確認すべき運用上の問題です。
GitHubの公式資料では、Copilotのレビュー対象から一部のファイルが除外されると説明しています。例として挙げられているのが、package.jsonなどの依存関係管理ファイルです。また、設定によっては、追加の変更後に再レビューを依頼する必要があります。［5］
つまり、アプリ本体に指摘がなくても、ライブラリの変更まで確認されたとは限りません。最初のレビュー後にコードを修正した場合も、その評価が最新の状態に対するものとは限らないのです。
| 状況 | 任せる範囲の提案 | 人が確認する内容 |
|---|---|---|
| 小規模で、テストのある変更 | AIを最初の確認役にする | 指摘の根拠とテスト結果 |
| 認証、決済、データ削除の変更 | AIに問題の候補を探させる | 権限、失敗時の動作、利用者への影響 |
| 依存ライブラリの変更 | レビュー対象を確認し、依存関係の検査を併用する | 脆弱性、互換性、除外されたファイル |
| レビュー後に追加修正した変更 | 再レビューの実行状況を確認する | 最終版のコードと評価対象が一致するか |
表は、本記事で提案する運用方法です。一定の成績を超えれば自動承認してよい、という基準が実証されたわけではありません。
開発者と利用者への影響：任せる範囲を具体的に決める
ReviewBenchの価値は、AIに任せられる範囲を比較しやすくすることにあります。AIを全面的に信用できる根拠になるものではありません。
開発者には、同じ評価対象でAIを比べられる利点があります。ただし、公開コードでの成績が、自社のルールや日々の変更にも当てはまるかは、追加の確認が必要です。利用者にとっても、開発者がAIを使ったという事実だけでは、サービスの安全性を判断できません。
導入時には、自社で最近行った変更を使い、重大な見逃し、不要な指摘、確認時間を記録します。問題のある変更に加え、人が確認して問題がないと判断した変更も混ぜると、誤指摘による負担を調べやすくなります。評価用に何度も使った変更とは別に、まだ評価に使っていない変更でも確かめるとよいでしょう。
この記事で押さえておきたいのは三点です。96.6％は、AIが問題を発見した割合ではありません。総合点が同じでも、見逃しの数や指摘を確認する負担は変わります。そして、指摘がなかった変更についても、レビュー対象の範囲と、最終版が確認されているかを確かめる必要があります。
関連ページ
AIの評価を見るときは、点数と実際の用途を結び付けて読むことが大切です。開発・テストや、AIによる判定の限界については、次の記事も参考になります。
出典・計算条件
公式に発表された結果と、本記事の仮定に基づく計算は区別しています。確認日は2026年10月7日です。表に示した仮想AIの性能、欠陥の割合、確認時間は、製品の実測値ではありません。
- GitHub Blog（2026年10月5日）：ReviewBench: An open benchmark for AI code review
- Martian公式評価ページ：Code Review Bench（取得できた「Last month」の表示。動的に更新されるため、表示期間・数値は変わります）
- Martian公式リポジトリ：Code Review Benchの評価方法
- LangChain（2026年7月31日）：Evaluating code review agents with ReviewBench
- GitHub Docs：About GitHub Copilot code review
コメントを送信