AIの進化を、ニュースで終わらせない。

技術・研究 · ·

AIが書いたコードをAIに検品させて大丈夫？ GitHub ReviewBenchで測れること

GitHubのReviewBenchは、AIのコードレビューを見逃しと誤った指摘の両面から測る。219件の公開PRで作った評価の仕組みと、96.6%という一致率の意味、実際の開発で役立てるための読み方を解説する。

AIにコードを書いてもらったあと、別のAIに「問題がないか見て」と頼む。その使い方は手軽だが、長いレビューが返ってきただけでは、よく検品できたか分からない。正しい指摘が少なければ確認の手間が増え、見逃しが多ければ不具合が残る。

GitHubが2026年10月5日に発表したReviewBenchは、この二つを分けて測るための公開ベンチマークだ。同じコード変更を複数のレビュー用AIに読ませ、既知の問題をどれだけ見つけたか、出した指摘にどれだけ意味があるかを調べる。AIに検品を任せる判断に使えるのは、その得意分野と見逃し方が分かるからだ。

GitHubの発表

この記事の要点

  1. ReviewBenchは、187の公開リポジトリにある219件のPRを使い、AIのレビューを見逃しと指摘の正しさから評価する。選定では1億390万件のPRの分布を参考にした。評価対象の219件には、ある程度まとまった変更を多めに含めている。
  2. grounded指標は既知の判定を使い、augmented指標は正解集に対応しない指摘もモデルで判定する。grounded precisionでは未対応の指摘を計算から外す。新発見によってaugmented recallの分母はAIごとに変わるため、AI同士の比較ではgrounded recallが基準になる。
  3. GitHubは、複数の独立したモデル実行を統合するレビューを本番のA/Bテストで評価し、改善を報告した。どの組み合わせでも改善するとは限らないため、追加で見つかった問題、誤った指摘、確認の手間と費用を比べて選ぶ。

コードの検品では「見つける力」と「空振りの少なさ」を測る

プルリクエスト、略してPRは、コードをこう変えたいと提案する単位だ。変更した行や、その変更を説明する文章を見ながら、開発者は取り込んでよいか判断する。レビュー用AIも、この段階で不具合や改善すべき点を指摘する。

レビューの良し悪しには、少なくとも二つの問いがある。「出した指摘は役に立つか」と「見つけるべき問題を見落としていないか」だ。前者を表すのがprecision、適合率で、後者を表すのがrecall、再現率である。

たとえば、ある変更に確認済みの問題が10件あるとする。AIが5件を指摘し、そのうち4件が正しい問題なら、指摘の適合率は4÷5で80%、既知の問題に対する再現率は4÷10で40%になる。これは考え方を説明する仮の数字で、ReviewBenchに載る製品の成績ではない。

もっと多く指摘すれば見逃しが減ることはある。ただ、誤った指摘まで増えると、開発者は一つずつ確かめて退ける必要がある。ReviewBenchでは、コメントの数だけでなく、指摘の正しさと取りこぼしを別々に読める。実際の採点では、後述する正解集との対応によって、計算に入る指摘が変わる。

219件のPRを、1億件超の分布に照らして選ぶ

GitHubは1億390万件、103.9 million件のPRを分析し、言語やリポジトリの大きさ、コード変更の規模がどう分布するかを調べた。ReviewBench本体は、その分析をもとに選んだ187の公開リポジトリ、19言語、219件のPRからなる。1億件を超えるPRすべてを各AIに解かせる試験ではない。

言語とリポジトリの規模はGitHub全体の分布に近づける一方、PRの規模には意図的な調整がある。ごく小さな単一ファイルの変更ばかりにならないよう、中規模以上の、レビューする内容がある変更を多めに選んだ。実務を参考にした試験だが、GitHub全体から無作為に同じ比率で抜き出した試験とは異なる。

評価時のコードは、baseとheadのコミットで固定する。後続の修正コミットは「何が問題だったか」を探す材料になるが、その修正後のコードをレビュー対象に混ぜるわけではない。最初から修正済みの差分を読ませれば、元の不具合を見つけられるか測れなくなるからだ。

公式のデータ構成とPRの選び方

正解集を作る工程と、レビューを採点する工程

採点の前に、比較の基準となる指摘の集まりを作る。公式文書ではgolden setと呼ぶ。この記事では正解集と書くが、正しい指摘だけの一覧ではない。正しいと判定した指摘にはTP、誤りや改善につながらないと判定した指摘にはFPというラベルを付けて保存する。

候補は、人間のレビュー、作者が後から加えた修正、静的解析などの決まった規則で動くツール、複数系列の高性能モデルから集める。同じ問題を別の言葉で述べた指摘は、意味を比べて重複を整理する。何人、何モデルが同じことを言ったかで、同じ問題の数を水増ししないためだ。

候補を集める仕事と、それを正しいと認める仕事は分かれている。現在の評価モデルはClaude Sonnet 5で、公開された基準に沿って、事実として正しいか、改善に関係するか、具体的で対処する意味があるかを判定する。「人間が言ったから正解」「複数のAIが同意したから正解」とは扱わない。

REVIEWBENCH

共通の正解集で、AIの指摘を照合する

基準を整えてから、同じPRに対するレビューを評価する。

A

事前準備

基準を作る

01

候補を集める

人とツールの指摘を持ち寄る。

人間レビュー 後続修正 静的解析 複数系列のAI
02

重複を整理して判定する

同じ問題をまとめ、Sonnet 5でTP／FPと重大さ・種類を判定する。

03

人間が確かめる

判定を監査・修正し、正解集を確定する。

正解集（Golden set）

既知のTPとFPを含む、照合に使う共通基準。

05の照合へ
B

評価ごとに実施

対象AIを評価する

04

固定したPRをレビューする

同じコードの版を対象AIに渡し、指摘を集める。

05

正解集と照合する

同じ問題かを確かめ、未対応の指摘は評価モデルで判定する。

06

指標を読む

適合率と再現率を、重大さ・種類ごとにも確かめる。

Grounded

正解集の既知の判定で比較する。

Augmented

未対応の指摘もモデルで判定し、評価に加える。

公式の評価方法をもとにLATENTが作成。正解集の準備と、対象AIの評価を分けた概念図。

正解集を最初に判定したモデルはSonnet 4.6で、その後Sonnet 5へ更新された。人間の監査では、モデルが誤ってTPとした47件も修正したと方法論に記されている。図の判定工程は、モデルの出力をそのまま最終的な正解として採用する工程ではない。

実際の照合でも、文章が同じかどうかだけを見ない。同じファイルの同じ根本原因を指しているかをモデルが判断する。指摘を言い換えたり、行番号が少し違ったりしても対応し得る一方、この照合モデルが誤る余地もある。

ラベル付け、人間の監査、照合の方法

現在の評価モデルに与える判定基準

同じレビューから4つの指標を計算する

正解集がどれほど充実していても、まだ誰も指摘していない問題は残り得る。ReviewBenchは、既知の判定だけで測るgroundedと、未対応の指摘を追加で判定するaugmentedを分けている。とくに適合率の分母は、両者で異なる。

指標 何を数えるか
Grounded precision 正解集に対応した指摘のうち、TPに対応した割合。未対応の指摘は分子にも分母にも入れない。
Grounded recall 正解集のTPのうち、対象AIが見つけた割合。同じ既知の問題を分母にして比較できる。
Augmented precision 全指摘のうち、既知のTPに対応したものと、未対応だが新たにTPと判定されたものの割合。
Augmented recall 見つけた既知のTPと新たなTPを、正解集のTPと新たなTPの合計で割る。分母は対象AIごとに変わる。

具体例として、正解集にTPが10件あり、FPの判定も保存されている場合を考える。あるAIが8件を指摘し、4件が既知のTP、1件が既知のFPに対応した。残る3件には対応がなく、追加の判定で2件がTP、1件がFPになったとする。重複や複数の問題をまとめた指摘はない、単純化した仮の例だ。

同じ8件の指摘を採点 仮の計算結果
Grounded precision 4÷5＝80%。未対応の3件は除く。
Grounded recall 4÷10＝40%。既知の10件中4件を発見。
Augmented precision 6÷8＝75%。追加判定のTP2件も数える。
Augmented recall 6÷12＝50%。分母にも新たなTP2件を加える。

この例では、新しい正しい指摘が見つかっても、augmented precisionはgrounded precisionより低い。計算に含める指摘が増え、誤りも1件追加されるからだ。grounded precisionが80%でも、「全コメントの80%が正しい」とは読めない。

F1は適合率と再現率をまとめる指標で、2×適合率×再現率÷両者の和で求める。仮の例ではgrounded F1が約53.3%、augmented F1が60%になる。それぞれ同じ系列の適合率と再現率を組み合わせる。さらにFβでは、βが1より小さいと適合率、1より大きいと再現率を重く評価する。

AI同士の見逃しを比べるときは、grounded recallが基準になる。augmented recallでは、そのAIが新しく見つけたTPを分母にも足すため、AIごとに違う問題集合を相手にすることになる。新発見の能力を読む補助情報としては有用だが、それだけで順位を付けると比較の条件がずれる。

実際の集計では、PRごとの値を平均するmacroと、指摘の件数を全PRで足してから割合を出すmicroも区別する。前者は各PRを同じ重さで扱い、後者は指摘の多いPRの影響を受ける。公式の評価は3回繰り返した結果を平均するので、単一PRの計算例を総合点と取り違えないことも大切だ。

指標の式、集計、反復評価

重大さと種類を分けると、総合点の中身が見える

正しい指摘でも、直さないと大きな障害になるものと、読みやすさを少し改善するものでは重みが違う。ReviewBenchは重大さと問題の種類を分けて記録し、必要な範囲だけを選んで成績を見られるようにする。

確認した判定基準の重大さはhigh、medium、lowの3段階だ。発表ブログでは最上位をcriticalと表記する箇所があるため、ここでは採点用の基準に合わせてhighと書く。カテゴリにはcorrectness、security、reliability、maintainability、testingなどがある。

説明用の仮想例 読み取る観点
利用者Aが利用者Bの非公開データを読めてしまう変更 securityの観点で、アクセス権の確認漏れを調べる。影響が大きければ重大な指摘になる。
通信の失敗時に再試行が止まらない変更 reliabilityの観点で、障害時に処理が戻るかを見る。重大さは発生条件と影響で変わる。
周辺コードと食い違う命名を新しく加える変更 maintainabilityの観点で、具体的な不一致を確かめる。好みだけの提案とは区別する。

表はLATENTが作った例で、収録PRの内容や公式のラベルを再現したものではない。たとえばsecurityという種類だけで、重大さが自動的にhighになるわけではない。影響する利用者、必要な条件、すでにある防御も調べて判断する。

低い重大さの指摘を出さないように作ったAIは、総合の再現率では不利に見えることがある。重大な問題だけの再現率が高ければ、通知を絞りたいチームには合うかもしれない。逆に細かな改善まで求める場面では、別の成績が役に立つ。先に用途を決めると、総合点だけでは見えない違いを読める。

重大さ・種類とTP／FPの判定基準

96.6%は判定の一致率で、バグ発見率ではない

GitHubは、データセットの作成に参加していないシニアエンジニアに、指摘を独立して判定し直してもらったと説明する。人間の判定とベンチマークのTP／FP判定は、96.6%の割合で一致した。「そのAIが現実のバグの96.6%を見つけた」という意味ではない。

これはGitHub側が行ったベンチマークの内部監査であり、独立した第三者機関による製品性能の認証ではない。判定者がデータ作成者から独立していることと、評価事業そのものが第三者によることは別の話だ。

一致率も、何について一致したかで変わる。方法論では重大さの完全一致は62.9%と報告されている。TPかFPかがよく一致しても、どのくらい重大かまで同じ精度で決まるとは限らない。重大さ別の細かな差を読むときには、分類そのものにも判断の幅がある。

さらに、人間とモデルが一致しても、両方が同じ前提を見落としている可能性は残る。逆に不一致なら常にモデルが誤りとも限らない。公式の監査ではコードを再確認し、モデル側と人間側のどちらに誤りがあったかを調べている。

監査の結果とモデル更新の経緯

複数モデルの視点を合わせ、追加の発見と負担を比べる

実務では、一つのエージェントで問題を潰しきれず、複数モデルを併用する使い方がある。一つの回答では気づかなかった問題を探すために、複数の視点でコードを確かめる。ReviewBenchでは、そうした併用で問題を追加で見つけられたか、誤った指摘も増えていないかを評価できる。

GitHub自身も、複数のモデル実行を統合したレビューを評価している。Copilot code reviewのlite-tierで試したmulti-model ensemble reviewは、複数の独立したモデル実行の結果を一つのレビューにまとめる仕組みだ。ReviewBenchでは適合率、再現率、コメント数の増加と、レビュー1回あたりの費用の低下を予測し、本番のA/Bテストでも同じ方向の変化が出たと報告している。

本番で測ったもの 従来の本番構成に対する相対変化
修正につながったと判定した割合（addressed rate） 8.0%増
追加で必要になる人間のレビューから測ったrecall 13.6%増
コメント数 61%増
レビュー1回あたりの費用 8.0%減

表はGitHubが報告した本番A/Bテストの結果で、すべて従来の本番構成に対する相対変化だ。8.0%増は8.0ポイント増を意味しない。この節には比較元の絶対値が示されていないため、変更後の割合そのものは求められない。

addressed rateでは、差分、コメントのやり取り、リアクション、解決状態、レビュー後のコードをLLMに見せ、指摘が開発者のコード変更を促したかを判定する。「直してもらえたか」の代理指標であり、指摘の正しさを直接測った割合ではない。本番のrecallも、追加の人間レビューがどれだけ必要かで評価しており、ReviewBenchの既知のTPを分母にする再現率と算出方法が同じとは限らない。

GitHubが報告したアンサンブルの本番実験

この結果からは、GitHubが試したアンサンブルで実用上の指標を改善できたことが分かる。組み合わせたモデル名や構成、実行回数、詳しいサンプル数と実験期間は、この節では特定できない。任意の異種モデルを増やせば同じ改善が出る、あるいは費用が下がるとまでは言えない。コメントが61%増えたこと自体も、その全部が追加の正しい問題だったことを意味しない。

自分たちの開発で試すなら、先に他者の回答を見せず、それぞれにレビューさせてから指摘を統合する構成が考えられる。以下は編集部の提案であり、GitHubの実装手順を再現したものではない。各モデルには同じコードの版と仕様を渡し、他のモデルの結論を前提にせずに問題を探してもらう。

視点を分担する方法もある。セキュリティではアクセス権や入力の扱い、境界条件では空入力や上限値、仕様回帰では既存の動作や外部との約束が保たれているかを重点的に見る。どの担当も同じコードと仕様を参照し、担当名だけで確認範囲に穴ができないよう、人間が観点を見直す。

集まった指摘は根本原因ごとに統合し、多数決だけで正しさを判定しない。三つのモデルが同じ前提を取り違えていれば、賛成が三つあっても正解にはならない。一つのモデルだけが挙げた問題も、コードや仕様、再現条件、テストで確かめる価値がある。各指摘の根拠を残すと、重複と追加の発見を分けて数えられる。

採用するかは、単体のレビューと併用後の最終レビューを同じPRで比べて判断する。既知の重大な問題を追加で何件見つけたかに加え、誤った指摘の確認と重複整理にかかった人の時間、待ち時間、実行費用を記録する。重大な見逃しを減らせたなら多少の手間を受け入れる判断はあり得るが、軽微な指摘と確認作業だけが増えたなら、モデルや担当範囲を見直す理由になる。

正解集にない新しい指摘はaugmented指標でも読み、既知の問題をどれだけ拾えたかはgrounded recallで比べる。複数の視点を持たせた効果は、減らせた見逃しと、増えた確認の負担を合わせて評価する。コメント数が増えたという理由だけでは、併用する価値を判断できない。

実際の開発で、何を任せるか判断する

ReviewBenchを使う第一歩は、自分たちが減らしたい負担を決めることだ。重大な不具合を見逃したくないのか、誤った指摘の確認に時間を使いたくないのか。たとえば決済処理の変更なら、重大な問題と正しさに関する再現率を確認し、そのときの適合率も読む、という比較が考えられる。これは編集部による使い方の提案である。

次に、自分たちの過去のPRで少数のレビューを試す。AIの指摘を人間が確かめるだけでなく、AIが指摘しなかった問題も探す。指摘されたものだけを確認する試し方では、適合率は見えても見逃しを捉えにくい。既存のテストが見つけた不具合と重複するか、レビューの待ち時間や費用に見合うかも判断材料になる。

公式の参加手順には、219件のうち25件の試用用セットと、全219件を3回評価する手順がある。25件は219件の一部なので、未公開の別試験ではない。調整を繰り返すほど、その25件に合う設定と、別のコードでも役立つ設定を分けて考える必要がある。

GitHubによる参加手順の案内

公開ベンチマークで確かめきれないこと

219件の公開PRは、評価の中身を他の人が確かめられるという利点がある。一方、社内だけの仕様、非公開の利用状況、独自の構成を持つコードまで同じように評価できるとは限らない。言語の種類が広くても、一つひとつの言語や分野の事例数は有限である。

収録PRがすべてAIの書いたコードであるとも示されていない。GitHubには前述のアンサンブルの評価と本番実験があるが、書くAIとレビューするAIの組み合わせを変え、共通の見落としを網羅的に比較した試験ではない。自分たちが使う組み合わせでも改善するかは、対象のコードと運用で確かめる。

正解集の取りこぼしも残る。複数の人やモデルが問題を探しても、全員が見逃した種類の問題は見えない。augmented評価は新しい指摘を拾えるが、そこで正しいと認めるかは評価モデルに依存する。モデルが苦手な問題を、自動採点だけで完全に補えるわけではない。

成績を比べるときには、データと、評価・照合に使うモデルの版をそろえる。対象AIの版や設定、集計方法も確認して、同じ条件で比べる。評価モデルや判定基準が変われば、同じ指摘でも点数が変わり得るからだ。公開例を使って何度も調整した場合は、新しいPRでも同じ傾向が出るかを別に確かめたい。公開データが学習に混入したと確認したわけではなく、ここでは公開試験に適応しすぎないための編集部の留意点として挙げている。

「AIが書いたコードをAIに検品させて大丈夫か」への答えは、任せる範囲によって変わる。ReviewBenchで分かるのは、指定した条件の下で、そのAIが何を見つけ、どんな指摘を出すかだ。そこに自分たちのコードでの確認を重ねれば、補助を任せる範囲を具体的に決められる。高い点数だけで、人が見ずにコードを取り込んだり、本番へ出したりする安全性まで証明されるわけではない。

既知の限界と再現に必要な条件

出典と確認した資料

2026年10月7日日本時間に公開資料を確認した。本文の実測値と監査結果はGitHubの報告であり、LATENTが独自に製品を実行・採点した結果ではない。例題の計算と図表は、仕組みを説明するために作成した。

計算方法はリンク先のGitHubリビジョンに固定した。公式サイトの説明とリポジトリの更新時点が異なる場合があるため、細かな式はこの版の方法論と採点基準に沿った。順位表は更新されるうえに条件で変わるため、この記事では製品の順位を付けていない。