5万5,000件の実際のレビューコメントが示す、短くそのまま適用できるAI修正案ほど開発者に採用されやすい

新たな研究は、人為的に作成した脆弱性課題だけでAI code reviewを評価するのではなく、エージェントが実際にGitHub pull requestへ残したコメントに開発者がどう対応したかを追跡した。研究者らは、Copilot、Cursor、Codex、Devin、Claudeが342件のPythonリポジトリで生成した54,791件のレビューコメントを収集し、コメントがresolvedとマークされたか、内容の種類、コメントの形式、さらにコアコントリビューターと周辺コントリビューターがその後どのような行動を取ったかを比較した。

結果によると、解決済みコメントの72.9%をCopilotが占めていた。ただし、これはサンプルの構成を示すものであり、Copilotの解決率が72.9%である、あるいは必然的に他のツールより優れていると解釈すべきではない。回帰分析では、そのまま適用できるinline code suggestionが付いていることが、コメントの解決を予測する最も強い因子だった。一方、長く構造が複雑なコメントほど採用されにくかった。コア開発者は設計や発展性に関する問題へ対応する傾向が強く、周辺コントリビューターは機能上の欠陥へより多く反応していた。これは、プロジェクトに関する知識や権限上の立場が、AIの提案が実際に反映される過程に影響することを示している。

チームはさらに、未解決の議論470件を対象にオープンカードソーティングを行い、10種類のパターンに分類した。その中では、誤った提案と、開発者が既存設計を意図的に維持したケースが最も多かった。レビューエージェントの構築にとって、この結果が示すのは、最適化の目標を単に「より多くの問題を見つける」ことに置くべきではないという点だ。ノイズを抑え、適用可能な最小限の修正案を提示するとともに、issue、テスト、アーキテクチャ上の意思決定といったプロジェクトコンテキストを取得する必要がある。

研究の限界は、対象がPythonの公開リポジトリに限られていること、またresolvedという状態が、提案が正しいことや実際にマージされたことを意味しない点にある。各エージェントの提供開始時期、利用量、デフォルトインターフェース、リポジトリの選択が交絡因子となっている可能性もある。ツール自体のレビュー品質を比較するには、今後、実際のdiffやテスト結果、ランダム化実験と組み合わせた検証が必要となる。