プルリクエストに対するAIのコードレビューは、開発現場への導入が進む一方で、その出力品質を客観的に評価することが難しい領域でした。多くのコメントを出すツールが必ずしも優れているとは限らず、誤指摘の少なさや、障害につながる重大な不具合を確実に検出できるかどうかが実用性を左右します。

こうした課題に対し、GitHubはAIコードレビュー向けのオフライン評価基盤であるReviewBenchの解説記事を公開し、データセットや評価手法、実行環境を研究プレビューとして提供し始めました。実務でAIレビューの導入や比較を検討する開発責任者にとって、その評価設計には多くの示唆が含まれています。

実態に近いPRと多角的な正解集合で測るReviewBench

ReviewBenchの大きな特徴は、評価対象とするコード変更の選定と、判定基準となる正解データ（Golden set）の構築方法にあります。

評価対象には、19言語にわたる187の公開OSSリポジトリから選ばれた219件のプルリクエストが使われています。言語やリポジトリ規模の分布はGitHub全体の傾向に合わせていますが、プルリクエスト自体の規模については、1ファイルのみの微小な変更の比率を抑え、レビューの質が問われる中規模から大規模な変更に重みを置く構成です。

また、正解データの作成にあたっては単一のツールや人間に頼っていません。人間のレビュアーによる指摘、作成者が後から追加したコミットから推測される修正内容、静的解析ツールの判定、そして複数の最先端LLMによる指摘を収集しています。そのうえで、同じ問題を指している候補の重複を意味論的に統合し、「事実に基づいているか」「変更に関連しているか」「些末でないか」という共通の基準に照らして判定を行っています。

GitHubの報告によれば、データセット構築に関わっていないシニアエンジニアが公開前に正解集合に含まれる各指摘を独立して再判定したところ、真陽性・偽陽性の判定一致率は96.6%であったとのことです。これは判定の一致率を示した監査結果であり、AIエージェントの不具合検出率そのものを示す数値ではありませんが、評価の前提条件を揃える工夫として参考になります。

既知の不具合と未知の指摘を分ける評価指標

AIのレビューを評価する際、あらかじめ用意した正解集合に一致したかどうかを見るだけでは、エージェントが新しく発見した正当な指摘を「正解にないから誤り」として減点してしまう問題が生じます。ReviewBenchではこの問題に対し、2つの評価系統を定義しています。

ひとつは、事前に確認された正解集合のみを基準とする「grounded評価」です。指摘のうち既知の問題に一致した割合を示す適合率や、既知の有効な指摘をどれだけ拾えたかを示す再現率を測ります。このうちgrounded recallが、システム間を公平に比較する主要な再現率指標として位置付けられています。

もうひとつは、正解集合に含まれていなかった新規の指摘についてもジャッジが個別に正誤を判定する「augmented評価」です。ツールが自律的に見つけ出した有効な指摘を加点評価できる利点はあるものの、各エージェントが発見した内容に応じてaugmented recallの分母が広がります。そのためReviewBenchでは、個別システムの追加診断指標として用いる位置付けをとっています。

さらに、指摘をCritical、Medium、Lowといった重大度や、正当性、セキュリティ、信頼性などの分類ごとに絞り込んで集計できるよう設計されています。保守現場においては、些末なスタイルの指摘よりも業務停止を招くような不具合の検出が優先されるため、自社が重視する観点に合わせて評価を切り分ける視点が欠かせません。

自社の保守業務でAIレビューを試行するアプローチ

公開ベンチマークのスコアが高くても、それが自社の業務仕様や独自フレームワークにそのまま通用するとは限りません。ReviewBenchの考え方を参考に、自社の保守現場で段階的に試行を進めることが現実的です。

たとえば、社内の受注管理システムを保守している場面を仮定してみます。過去に不具合を含んでいた変更コミットを評価対象として用意し、後から作成された修正プルリクエストや当時の障害報告を正解の根拠として突き合わせます。これにより、AIレビューが根本原因を指摘できたか、関係のない指摘を大量に出していないかを確認する流れです。このように問題が存在する版を対象として判定基準を明確にしておけば、修正済みのコードに対して指摘が出ないことを見逃しと誤認することなく、見逃してはならない重大な問題と軽微な提案を切り分けて、自社にとっての実質的な検出能力を確かめられます。

また、実務でGitHub Copilotのコードレビュー機能を組み込む際には、ツールの動作条件も考慮する必要があります。Copilot code reviewの公式ドキュメントで説明されているように、レビュー済みのプルリクエストに修正をプッシュした際、自動レビューを有効にして新しいプッシュを対象にする設定を行っていない限り、自動的な再レビューは行われません。

さらに、リポジトリ全体やファイルパスごとに指定できるカスタム指示（.github/copilot-instructions.mdなど）は、マージ先ではなく変更が含まれるheadブランチ側から読み込まれます。業務固有のルールを指示ファイルに追記して精度を検証する場合は、どのブランチのどの指示バージョンに対してレビューが行われたかを記録し、条件を揃えて比較することが求められます。

業務の整理とレビュー工程の接続に向けて

AIコードレビューを開発保守に取り入れる際は、ツールの導入そのものを目的にするのではなく、どの変更を誰が確認し、どの段階でAIの指摘を挟むのかという開発手順の整理が欠かせません。

過去の変更履歴をもとにした評価対象の選定や、自社のコーディング基準に合わせた指示ファイルの設計、既存の開発・運用フローを崩さない連携方法など、検討すべき論点は多岐にわたります。

デノフでは、Webサイト・業務システムの設計・開発・運用保守やAI活用支援を行っており、業務の整理からAIを活用する領域の選定、ツールの選定、導入後の定着までを一貫して支援しています。自社システムの保守業務においてAIレビューをどのように評価し、どこから小さく検証を始めるべきかお悩みの際は、デノフへの相談窓口よりお気軽にご相談ください。課題の整理や試行計画の策定からご相談を承ります。