AIエージェントがテスト合格だけでは不十分な理由

コーディングAIの評価において、長らく「テスト合格率」が主要な指標として使われてきた。パッチを当ててユニットテストが通れば「成功」とカウントされる仕組みだ。しかし、米国の研究チームが公開した論文「SWE-Gate」は、この前提に疑問を投げかけている。

研究チームは75のオープンソースPythonリポジトリから303件の修正タスクを用意し、実際のプルリクエストのレビューコメントから「レビュー制約」を抽出。「関数名はスネークケースにしてください」「このパターンは使わないでください」「可読性のためにロジックを分割して」といった、現場のレビュアーが実際に指摘するような条件を評価基準に加えた。

結果は明確だった。テストを通過した644件の修正のうち、221件——つまり約3割——がレビュー制約を満たせていなかった。「動く」コードと「現場で受け入れられる」コードの間には、数字で確認できる大きなギャップがある。LLMの能力レベルが異なる4種類のバックエンドで試しても、この傾向は一貫していたという。

このギャップが生まれる理由は構造的だ。AIコーディングツールは、コードが「正しく動くかどうか」は学習できていても、「そのプロジェクト固有のルール」を自動的に把握することはできない。変数の命名規則、ファイル分割の粒度、エラーハンドリングの書き方、コメントの書き方……こうした「現場の流儀」は、リポジトリごとに異なり、ドキュメントに明示されていないことも多い。

AIに丸投げしてテストが通れば完成、という使い方だと、レビューで毎回差し戻されるコードを量産し続ける可能性がある。個人で使う分には問題が表面化しにくいが、チームのコードベースに混入させたり、オープンソースへの貢献として提出したりするシナリオでは話が変わってくる。

以前紹介したAIに研究させる前に「採点基準」を作らせるという考え方とも重なるが、AIに任せる前に「どう評価するか」を言語化しておくことが、出力品質を決定的に左右する。SWE-Gateの論文が示したのは、その「採点基準」をコーディング評価の世界でも真剣に設計する必要があるという事実だ。