SWE-Duel：コーディングエージェント同士で進化する評価アリーナ

固定ベンチマークの課題

従来のソフトウェア工学ベンチマークは、公開時点でリポジトリ、課題、修正例、テストが固定される。時間がたつと、その内容が訓練データに含まれたり、強力なモデルが解法を十分に学習したりして、システム間の差を測りにくくなる。シンガポール・マネジメント大学の研究チームが提案するSWE-Duelは、評価の最中に課題と判定方法を作ることで、この問題に対処しようとする。

RedとBlueが交代する仕組み

2つのエージェントは、実際のコードリポジトリ上でRedとBlueを交代する。まずRedは隔離されたセッションでプロジェクトを理解し、新機能を提案して実装する。さらに機能テストを追加したうえで、その機能に気づきにくいバグを埋め、バグを発生させる非公開テストを用意する。

プルリクエストが採用される条件は厳しい。新機能のテストと既存テストには通る一方、隠れたバグテストだけに失敗しなければならない。また、同じエージェントの新しいセッションが、バグの場所を知らずに修正できることも求められる。修正不能な課題を高難度として扱わないための安全策である。

次にBlueは、バグが存在するとは知らされずにプルリクエストをレビューする。コードを調査して修正版を作り、機能テスト、リポジトリの既存テスト、隠れたバグテストのすべてに合格すれば勝利となる。その後、両者は役割を交換する。したがって、単なるコード生成だけでなく、テストの理解、レビュー、デバッグ、明示されていない問題の発見も評価対象になる。

実験で見えた役割分担

実験では、11種類のモデルとハーネスの組み合わせが、5言語の15リポジトリで1500ターンを戦った。結果は、1つのシステムがすべての能力で優れるとは限らないことを示した。GPT-5.5とCodex CLIは最も強い修正役で、レビューした欠陥の98.3％を修復した。一方、Claude Opus 4.8とmini-swe-agentは課題作成役として目立ち、Red側の勝率は27.3％だった。

同じモデル系列内では、新しいバージョンが作った課題が固定の参照ソルバーを破る割合は42.9％で、旧バージョンの4.0％を大きく上回った。この結果は、作題能力が上がるほど、より識別力のある課題を作れる可能性を示す。ただし、研究側も予備的な証拠として位置づけている。

意義と残された課題

SWE-Duelは、ベンチマークを固定された問題集ではなく、評価中に更新される相互作用環境として捉え直す。課題やテストがその場で生成されれば、既存タスクの暗記だけでは対応しにくい。実装とレビューを一つの対戦に組み込む点も、実際の開発協業に近い評価につながる。

一方、対象となったリポジトリ、言語、参加者の数は限られている。エージェントが常に微妙で、再現可能かつ解決可能なバグを作れるかも重要だ。今後はより長期で大規模な検証と、評価手順そのものを悪用する可能性への対策が必要になる。それでもSWE-Duelは、参加者の能力に合わせて難しくなるコード評価の有力な方向性を示している。

出典：Hugging Face Daily Papers