コーディングエージェントに「こういう仕事を代わりに処理するエージェントを作って」と任せることが増えている。AgentSWEは、そうして作られた成果物が要求どおりに動くのかを初めて正面から測定したベンチマークだ。生成・編集・最適化の3種類25課題において、評価されたどのコーディングエージェントも、要件が求める水準のエージェントを安定して作り出すことはできなかった。開発中に見せた性能と、実際の納品物の性能とのあいだのギャップは、例外ではなくデフォルトだった。
まず用語を二つ切り分けておこう。ここにはエージェントが二重に登場する。一つは作られる側だ。たとえばECサイトの顧客問い合わせを読み、返金・交換・配送遅延に分類して担当者に回すプログラム — 人が毎回張り付かなくても自分で判断し処理する、こうしたプログラムをエージェントと呼ぶ。もう一つは作る側、つまり要件を自然言語で受け取り、そのプログラムをコードに書き起こしてくれるコーディングエージェントだ(Claude Code、Codexのようなもの)。AgentSWEが試験台に載せるのは作る側であり、採点するのは作られた側の動作である。
ここには静かな前提が一つ敷かれている。要件を受け取ったコーディングエージェントが「その要求を忠実に遂行するエージェント」を納品してくれるはずだ、という信頼だ。問題は、その信頼を検証する道具がなかったことである。
既存のベンチマークは毛色の違うものを測る。SWE-bench系は、コーディングエージェントが書いたコードをあらかじめ正解がわかっているパッチ・テストに照らし合わせるし、要求文書からリポジトリを構築させたり論文を見て実装を再現させたりするベンチマークも、結局は「定められた正解に対してコードを採点する」。逆にAgentBench以降のエージェントベンチマークは、すでに完成したエージェントを置いて、それがどれだけうまく動くかだけを問う。コーディングエージェントがそのエージェントをそもそも作り出せたのかは、誰も問わなかった。
問題空間の他の流れも、問いがずれている。「エージェントを作り改善するエージェント」の研究(例:Arbor、JIT-Agent)は、特殊な探索手続きやメタエージェントがスコアをどれだけ押し上げるかを測り、WorFBench・AIE-Benchのようなエージェント構成ベンチマークも、統制された境界の中での改善を見る。AgentSWEはここで二つの点で異なる。第一に、特殊な仕掛けではなく汎用コーディングエージェントを立てる。第二に、スコアの押し上げではなく「自然言語の要求が描いたエージェントを実際に納品するのか」という忠実性(要求を実際の振る舞いでどれだけ満たしたか)を問う。そして生成という一段階ではなく、生成・編集・最適化のライフサイクル全体をカバーする。
AgentSWEの設計を貫く構図は「試験」ではなく「受注」だ。試験は正解のわかっている問題を解くことであり、受注は顧客が言葉で投げた要求を受け、成果物を納品することだ。この記事全体を通して、たとえはこの一つ — 要求を受けて納品する — に統一する。
各課題の出発点は自然言語の要件である。論文はこの要件を四つの部分に分けて渡す。エージェントが何のためのもので、何がユーザーを満足させるのかを明らかにする目標(goal)、どう実行され何を産出すべきかを固定するインターフェース契約(interface contract)、何を修正・インストール・呼び出してよいかを線引きする制約(constraints)、データ・リポジトリ・モデルへのアクセスといったリソース(resources)。顧客が実際に渡せるものだけをビルダー(エージェントを作るコーディングエージェント)に見せる、という原則だ。
核心となる仕掛けは、「開発ケース」と「保留ケース(held-out、ビルダーに隠しておいた評価用のケース)」の分離である。ビルダーは公開された少数の開発ケースを自由に突きながら作業する。だが納品物が実際に迎えるケースは書かれていない。評価は、この保留ケースで凍結された(frozen)納品物を別途走らせる。開発中は2つの例しか見ていないのに、合格審査は要件全体をまたぐ別のケースで行う、という意味だ。
採点には正解実装がないため、生成・編集課題のすべての実行は、要件から直接引き出したルーブリック(rubric、採点基準表)で評価する。その手前にハードゲート(hard gate、通過できなければ中身を見る前に0点となる最低限の関門)が設けられる。エージェントが実行すらできない、産出物がパースできない、許可された修正範囲を逸脱した — こうした場合は0点だ。見栄えのよいコードでも、動かなければスコアはない。最適化課題は、元のベンチマークの目標指標で測る。
この構造のおかげで、二つのものが一つの数字として分離される。ビルダーが開発中に見せた性能(demonstrated fidelity)と、実際の納品物が出す性能(delivered fidelity)だ。論文は、両者のギャップこそが委任への信頼を蝕む核心の変数だと見る。
本文で必ず押さえておく骨格は三つだ。
第一に、課題は三種類ある。生成(10課題)は、空のワークスペースから完全なエージェントを新たに納品させる。編集(10課題)は、稼働中のプロダクトエージェントの固定されたコードに新機能を載せつつ、既存機能は壊さないようにする。最適化(5課題)は、動作中のエージェントを測定可能な目標へと押し上げる。
第二に、開発ケースと評価ケースを物理的に分ける。生成・編集は課題ごとに開発2つ・保留6つを置き(全体では開発150、保留365)、ビルダーはHarborというコンテナの枠組みの上の一セッションで作業し、スナップショットを提出する。提出物は開発ケースだけで採点されて要約フィードバックが返り、予算を使い切ると成果物が凍結される。評価は、この凍結された成果物を保留ケースで別途走らせる。
第三に、比較対象の土台となるモデルを統一する。保留ケースを走らせるとき、納品エージェントのすべてのモデル呼び出しは、ベンチマークが所有するゲートウェイを経由して一つのランタイムモデルへ向かう。同じ課題群のすべての納品物が同じモデルを共有する。そうすることでスコアは、土台モデルの性能差ではなく、ビルダーの寄与分 — プロンプト、ツール運用、状態管理、出力検証 — を反映する。
スコアを読む前に、まず尺度から。生成・編集のスコアは「要求が描いた振る舞いを実際にどれだけ実現したか」を測る忠実性スコアだ。高いほど良く、ハードゲートに引っかかれば0点になる。コードの優雅さや保守性は測らない — 審判が見るのはコードではなく、「ある具体的なケースでエージェントが実際に出した産出物」だ(生成はGPT-5.6 Sol、編集はDeepSeek-V4.1-Flashを審判に用いた)。最適化は絶対スコアではなく、目標までに残ったギャップをどれだけ縮めたかで測る。ビルダーとしては、Codexハーネス(モデルを包んでツールを使わせ、複数ステップを踏ませる実行の枠組み)に五つのモデル — GPT-5.6 Sol、GPT-5.5、DeepSeek-V4-Pro、DeepSeek-V4-Flash、Qwen3.6-35B-A3B — を組み合わせた。
以下はすべてCodexハーネス基準である。
| 課題 | 核心の数値 | 読み方 |
|---|---|---|
| 生成(10) | 50回の実行(10課題×5ビルダー)で平均11.2、中央値3.4、うち20回が0点。最高のビルダーDeepSeek-V4-Proでも平均19.1で、10課題中8つが20点未満。50点を超えた実行はわずか3つ(形式的定理証明が2回、リポジトリのバグ修正が1回)。 | どのビルダーも二つ以上の課題で30点を超えられなかった — 一つの受注の成功が次へとつながらない。 |
| 編集(10) | 納品に成功したビルダー(DeepSeek-V4-Pro・GPT-5.5・GPT-5.6 Sol)でも、要求機能の一部しか実装できず。平均20〜35点、70点到達はただ一度(GPT-5.5のCodex課題)。Qwen3.6はどの課題も提出できず。DeepSeek-V4-Flashは四課題のみ納品。 | 動いているプロダクトに機能を足す仕事は二方向で失敗する。パッチが要求の一部しか覆わないか、そもそも一つも終えられないか。 |
| 最適化(5) | どのビルダーも平均的に、残ったギャップの5%を超えて縮めることはできず。25回中13回が出発点より高く、9回低く、3回同じ。符号検定で有意な差はわずか5回(有意な改善3回はすべてBrowseComp、有意な悪化2回はτ³とPinchBenchでそれぞれ1回ずつ発生)。 | 利得が課題に依存する。BrowseCompでは五つのうち四つが出発点を超えたが、PinchBenchでは五つのうち四つがむしろ下がった。 |
これらの数字の背後には、三つの失敗の様相がある。観察された現象と、それに対する推定原因を分けて見よう。
条件を変えた追加実験(ablation)もある。開発ケースの数を増やす実験は、PDF・PPTXの二課題で特定のビルダーにより条件ごとに3回ずつ走らせたもので、ここではスコアが0個→2個の区間でのみ上がり、それ以上では上がらなかった — ただし二課題に限った観察であり、ケース数を増やしても効果がないという一般的結論として読んではならない。そのほか、設計をあらかじめ指定するとPPTX課題のスコアはむしろ下がり、テストせよと指示するとスコアの分散だけが狭まり、ケース予算を2.5倍に増やしてもギャップは残った。
著者が自ら認めた限界がある。ビルドが確率的なので単一の実行で結論を出しにくいという反復(repetition)の問題、そして生成・編集の審判にフロンティアモデルを用いたため、審判モデルのバイアスがスコアに混じりうるという点だ。
さらに押さえておくべきはカバレッジだ。25課題、しかも特定のオープンソースエージェントから逆設計した課題であり、広いとは言いがたい。また、土台モデルを課題群の中で統一した設計は、ビルダーの寄与分をきれいに切り分けてくれるが、実際のプロダクトではビルダーが選んだモデルそのものも納品品質の一部だ。この統一は「ビルダーの純粋な寄与」を測ろうとするベンチマークの中では正しい選択だが、現実のプロダクト判断とは一枚隔たっている、という条件を付けて読むべきだ。
ONTLEは、小企業・一人事業者の反復業務を代わりに処理する小さなエージェントを組み立てて納品する側だ。つまりAgentSWEが試験台に載せた「ビルダー」の立場に立つ。
小さなECサイトの店主が「顧客問い合わせを返金・交換・配送遅延に分類して担当者に回すのを代わりにやって」と任せた場面を思い浮かべてほしい。ONTLEがエージェントを組み立て、店主がくれた例の問い合わせ二、三件で走らせてみる。三件とも正確に分類される。デモは文句なしだ。この論文が警告するのはその先である。実戦に入ると「返金だが配送遅延も混じった問い合わせ」「タメ口で誤字だらけの問い合わせ」「注文番号を書いていない問い合わせ」が押し寄せる。開発時に見た二、三件だけに合わせ込まれたエージェントは、ここで崩れる。分類はできたと報告するのに、担当者には一度も回っていない「中身が空のランタイム」まで重なれば、店主は何も起きていないことを「完了」として受け取る。
だから顧客が確認すべき問いは一つに集約される — 「分類結果が画面に出たか」ではなく、「担当者に実際に伝わったか」だ。ONTLEの運用原則はすでに「動作のシグナルだけで完了扱いにせず、実際の振る舞いで検証する」という方向にある。AgentSWEを機に、ここへもう一段階を提案する。店主が見ていない保留ケースの束で、凍結したエージェントを別途走らせてみて、その合格までは「完了」として引き継がない手続きだ。「見せた性能」と「実際の性能」のギャップを数字で露わにする、引き渡しの最後の関門というわけである。
エージェントを作って使う側なら、三つだけ実行に移せばよい。