- 一つのIssueを直すより広い、プロジェクト単位の開発課題を評価した。
- 20課題の実験で最高の総合得点は77.85。提出の受理率27.38%は別の指標だった。
- C++中心の小規模な課題群とAI補助のレビューに、結論の範囲が限られる。
何を確かめた研究か
コード修正のベンチマークは、既存の不具合を一つ直せるかに焦点を当てることが多い。ProjDevBenchは、機能を設計・実装してプロジェクトを完成させる作業を、AIコーディングエージェントにどこまで任せられるかを問う。単にテストに通るだけでなく、コードの品質を評価に加える。
どう検証したか
約2,800の候補から20件を選び、主にC++のプロジェクト開発課題として整えた。提出コードはオンラインジャッジで実行し、別途、コードレビューで品質を採点する。最終得点は実行結果80%、レビュー20%の重みで集計した。六つのエージェント枠組みを含む16のエージェント・モデル構成を比較した。レビューの妥当性は人手評価とも照合している。
採点を二つに分けたのは、実行できるコードと、読みやすく修正しやすいコードを区別するためだ。レビューの点数は便利だが、テストの通過と同じ種類の客観的な判定ではない。総合点の順位を見る際は、重みの設定も確認したい。
何が分かったか
CodexとGPT-5の構成が総合得点77.85で最も高かった。全提出のうちオンラインジャッジに受理された割合は484件、27.38%だった。この27.38%は「20課題のうち成功した割合」ではない。エージェントは課題ごとに複数回提出するため、提出を分母とする受理率と、課題を分母とする成功率を分けて読む必要がある。実行で正しく見えるコードも、レビューでは保守性や実装の質が異なり得る点がこの評価の狙いだ。
プロジェクトを完成させる課題では、最初の実装案が動くだけでは足りない。既存のコード構造に合わせ、複数のファイルを整合させ、修正後のテストを通す必要がある。この研究はその負担を一つのIssueの修正から広げて見ようとする。ただし課題集合が小さいため、特定の言語や枠組みに慣れたエージェントが有利になる可能性を残す。
限界は何か
課題は20件で、言語と問題の分布はC++に偏る。コードレビューにはAIによる判定が関わり、人間の実務レビューを完全には代替しない。比較した構成、試行予算、採点の重みを変えれば順位も変わり得る。結果を企業の開発案件一般に適用することはできない。
総合点の80対20という重みは研究側の判断である。ある組織ではセキュリティ、レビュー容易性、移行の安全性をもっと重く扱うかもしれない。研究内の順位を採用判断に使う前に、実行テストの内容、レビュー基準、やり直し回数を自社の作業に合わせる必要がある。オンラインジャッジに受理されても、長期運用に適したコードかどうかは別に確認したい。
仕事との接点
自社で開発エージェントを試す場合は、単発のテスト通過と、保守可能な完成物を区別したい。コードレビュー基準を事前に決め、同じ課題と予算で複数構成を比べる。これは論文の測定方法を参考にした編集部の提案であり、77.85点が実案件の完了率を表すわけではない。
提出が複数回ある評価では、最終提出だけを見るか、途中の試行を含めるかでも解釈が変わる。記事の27.38%は提出の単位であり、利用者が一つの依頼を渡したときに完成する確率の推定値ではない。