この論文は、中国科学院自動化研究所と Huawei Technologies の著者らによって ICLR 2026 の会議論文として 発表されたもので、バグ修正ではなく機能開発を対象とするコーディングエージェント向けのベンチマーク FeatureBench を導入している。著者らの動機は、SWE-Bench のようなベンチマークは バグ修正の issue が大半を占めており — 著者らは SWE-bench のインスタンスのうち機能要求は約 18〜22% に すぎないとしている — 、プルリクエストに基づく収集方法では完全な機能を捉えられないという点にある。機能は しばしばプロジェクトの履歴に散らばった複数の PR にまたがり、タグ付けされていないことも多い。
各タスクはエージェントに、高レベルの説明、明示的なインターフェース定義（インポートパス、関数シグネチャ、 期待される振る舞い）、URL のブラックリスト、そして Docker 環境を与え、直接呼び出せる実装を求める。正しい 解は、関連する fail-to-pass テストと pass-to-pass テストに合格する。タスクには 2 つの難易度がある。 Level 1 は機能が取り除かれた既存のコードベースを拡張するもので、Level 2 はリポジトリなしで同じ機能を ゼロから実装するものである。収集パイプラインは、リポジトリのテストを実行し、Python のトレース機能を 使って関数レベルの依存グラフを構築し、各テストが対象とするオブジェクトを LLM に選び出させ、グラフを たどって pass-to-pass テストが実行する部分を残しつつ対象機能のコードを抽出する。そのうえで、取り除いた 後のコードベースが pass-to-pass テストに合格し、fail-to-pass テストに失敗し、パッチを再適用するとすべてに 合格することを検証する。手作業の工程は、各リポジトリのインストールコマンドを指定することだけである。
論文は、OpenHands、Gemini CLI、 Claude Code、OpenAI Codex と最先端モデルとの組み合わせを 含む 7 つのスキャフォールドとモデルの組み合わせを評価し、最も強力な構成でさえフルセットのごく一部しか 解決できないことを見出している。
要点
- 200 タスクのフルセットでは、Claude Opus 4.5 を用いた Claude Code がタスクの 11.0% を解決し、 GPT-5.1-Codex（medium reasoning）を用いた Codex が 12.5% を解決する。
- SWE-bench と共通のリポジトリに限定したサブセットでは、Claude Opus 4.5 はタスクの 5.2% を解決する。 これに対し、論文が SWE-bench Verified でのこのモデルの解決率として挙げている値は 74.40% である。
- 合格率（fail-to-pass テストのうち合格した割合の平均）は解決率よりもはるかに高く、著者らはこれを、 エージェントが一見もっともらしいものの問題の解決からはまだ遠い解をしばしば生成していることの表れと 読んでいる。
- 評価したすべてのモデルが、タスクあたり平均で 100 万を超える入力トークンを消費しており、著者らは低い 解決率を踏まえてこれを極めて低い効率だと述べている。
- プロンプトからインターフェース仕様を取り除くと Lite セットでの成功率が大きく下がり、一方でエージェント に正解のユニットテストを与えると解決率と合格率の両方が大きく上昇する。
- OpenHands のステップ上限を 50 から 100 に引き上げると 2 つのモデルで顕著な改善が得られるが、それを 超えると改善はわずかである。
- Claude Opus 4.5 の失敗分析では NameError が大半を占め、著者らはこれをファイルをまたいで参照を再構築 することの難しさに帰している。また、他のファイルで定義されたインターフェースを読む代わりに推測したり ハルシネーションを起こしたりする傾向も報告している。
- ゼロから実装する Level 2 の設定は、段階的に拡張する Level 1 の設定よりも難しい。
- シニアエンジニアが Lite セットのプロンプトを手作業で改訂したところ、自動生成された元のプロンプトと 非常に一貫した性能が得られ、著者らはこれをパイプラインの信頼性を裏づけるものと捉えている。
補足
パイプラインは現在 Python リポジトリを対象としている。著者らは、新しいコミットからタスクを継続的に生成 できるため、データリークを緩和するためにベンチマークを最新に保つことができ、その検証可能な環境は エージェントの学習にも役立ちうると論じている。著者らは、タスクの性能はタスクのコミット日よりも、必要と されるコードの量にはるかに強く依存することを観察する一方で、エージェントが機能開発に関与する機会が 増えるにつれてデータリークのリスクが高まる可能性があると注意を促している。