GitHubは2026年10月5日、AIがプログラムの変更内容を点検する「AIコードレビュー」の評価基盤ReviewBenchを公開しました。研究プレビュー版として専用サイトで提供しており、評価データや判定手法とともに、評価済みのコードレビューエージェントの結果を共通ランキングに掲載します。AIレビューを選ぶ企業にとって、問題の発見能力を共通の基準で比べる材料になります。
219件・19言語で評価、判定の仕組みも公開
ReviewBenchの評価データは、187の公開リポジトリから集めた219件で、19言語を含みます。リポジトリはコードなどを保管する場所です。対象はオープンソースライセンスで公開されたものです。
評価対象の構成は、GitHub上の1億390万件のプルリクエストの分析に基づいています。プルリクエストは、コードの変更を提案して確認を受ける仕組みです。GitHubによると、言語とリポジトリ規模の分布はGitHub全体に近い一方、変更規模は小さな変更に偏らないよう、中規模以上を重視しています。
正解の候補は、人間のレビュー、作者による後続の修正、コードを実行せずに調べる静的解析、複数の大規模言語モデルから集めます。同じ問題への指摘はまとめ、共通の基準で正解かどうかを判定します。モデルによる判定にはClaude Sonnet 5を採用しました。
公開内容には、プルリクエストや指摘、ラベル、重大度・分類を含む評価データに加え、判定用の指示文、モデル設定、実行ツールも含まれます。評価データ、判定モデル、指摘を照合する処理はバージョン管理します。日本での提供は発表には書かれていません。
ランキングは「見逃し」を重視、順位だけで選ばない
評価には、指摘のうち正しいものの割合を示す「適合率」、正解のうち発見できた割合を示す「再現率」、両者をまとめた「F1」を使います。既知の正解に基づく評価と、新しく見つかった指摘も評価する方式の両方を用意しています。
システム間の比較で主指標とするのは、既知の正解に基づく再現率です。そのため、ランキングを見るときは、まず何の指標による順位かを確認する必要があります。見逃しの少なさと、誤った指摘の少なさは、分けて見るのがよいでしょう。
GitHubによると、重大度や分類別にも結果を比較できます。また、Fβという指標のβを調整すると、適合率と再現率の重みが変わり、順位も変わります。自社でどちらを重視するかを決めてから比較することが大切です。
構築に関与していない上級エンジニアによる再判定との一致率は、GitHubによると96.6%でした。これは判定同士の一致率であり、AIレビューが問題を発見する割合とは別の数字です。検証手法や評価の妥当性に関する既知の懸念も公開しています。
GitHubはCopilot code reviewの改良評価にもReviewBenchを使っています。同社によると、事前評価での変化の方向は、後の本番A/Bテストと一貫して一致しました。ただし、自社での選定には、使用言語や変更規模が評価対象と合うかの確認も必要です。
影響する会社・しない会社
- 影響する: AIコードレビューを導入・比較する開発組織です。公開されたデータや指標を、候補の比較材料にできます。
- 影響する: Copilot code reviewを利用する会社です。GitHubが改良評価に使う基盤の中身を確認できます。ただし、今回の発表を特定の機能変更や精度向上の告知として扱わないことが重要です。
- 影響しない: コードレビューを行わず、そのツールの選定にも関わらない会社では、今回の評価基盤を直接使う場面は限られます。契約プランや企業規模による対象条件は、発表には書かれていません。
情シスが今日やること
以下は発表で指定された作業ではなく、社内で比較を始めるための確認手順です。
- 今日、開発責任者や委託先に、使っているAIコードレビューの名称と対象言語を確認します。導入検討中なら、候補と、見逃し・誤指摘のどちらを重視するかを一覧にします。
- ReviewBenchの専用サイトで、公開された評価データと共通ランキングを確認します。候補が掲載されているか、主指標が何かを記録し、総合順位だけを社内に共有しないようにします。
- 次の選定会議までに、対象言語、リポジトリ規模、変更規模を自社と照合します。中規模以上の変更を重視した構成なので、小さな変更が中心の運用とは分けて検討します。
- 試験導入の判断前に、開発担当へ重大度・分類別の結果と、公開された評価の懸念を確認するよう依頼します。日本での利用条件も未確認事項として残し、ランキング上の評価と自社での採用判断を分けて報告します。
