SWEeper-Bench、対話型ソフトウェアのバグ発見能力を測る

導入

コードエージェントの役割は、要求に応じてコードを書くことから、ユーザーが実際に使える対話型ソフトウェアを届けることへ広がっています。しかし、Web アプリの品質をコードだけで判断するのは困難です。ある不具合は、画面を開くだけでは現れず、権限を変更する、状態を保存する、別の画面へ移動するといった複数の操作を順番に行った後で初めて表面化します。

従来の多くのベンチマークは、すでに報告されたバグをエージェントが修正する形式でした。そのため、バグの発見という重要な工程は十分に評価されていません。SWEeper-Bench は、この空白を埋めることを目指します。

ベンチマークの特徴

• 200 件の実タスク：200 の広く利用されるオープンソース Web アプリから、実際のバグ修正事例をもとに作られています。
• 曖昧な依頼だけを提示：具体的な不具合の内容ではなく、「Focalboard のボード共有とメンバー機能の問題を探して修正せよ」といった開放的な依頼が与えられます。
• 対話的な探索が必須：エージェントはアプリを起動し、ユーザーらしい操作の連続を自分で設計しなければなりません。検索候補インターフェースのような機能も、特定の手順でのみ異常が見える場合があります。
• ブラウザー上で検証：エージェント型の検証器が、修正後のアプリをブラウザーで操作し、ユーザーが観測できる結果に基づいて判定します。
• まだ大きな差がある：15 の先端エージェントのうち、最も良いシステムでも通過率は 59.0% でした。

最大のボトルネック

軌跡の分析から、最も難しいのはバグの挙動を特定する段階だと分かります。エージェントは対象となるページやコンポーネントまで到達しても、ページが表示される、ボタンが反応する、といった浅い確認で探索を終えがちです。故障を発生させるための追加操作を実行しなかったり、異常な結果を見ても仕様違反だと認識できなかったりします。

これは、対話型バグが単一の関数や静的なコードパターンだけに現れるとは限らないためです。状態、遷移の順序、権限、複数の UI 操作の組み合わせを追跡しながら、仮説を立てて実験する必要があります。

意義と影響

SWEeper-Bench は、コードエージェントの評価を実際の開発現場に近づけます。既知の不具合を直せるエージェントと、未報告の問題を自ら発見して検証できるエージェントは同じではありません。後者には、ブラウザー操作の計画、探索的テストの生成、異常の認識、状態管理、回帰確認が求められます。

ユーザーが最初に隠れた不具合を発見し、その後に開発者が修正する流れを短縮するには、エージェント自身がソフトウェアを「使って」検査できなければなりません。59.0% という結果は、その自律的な品質確認がまだ解決途上であることを示しています。

出典：Hugging Face Daily Papers