はじめに — モデルを測る物差しでシステムを比べる
コーディングエージェントは、いまや多くのチームでソフトウェアを作る主要な方法になりました。ところが、私たちがそれらを並べる物差しは、いまだに モデル一つ を測っていた時代のものです。以前の コーディング評価で信号とノイズを見分ける記事 ではリーダーボードが汚染とインフラのノイズで揺らぐことを見て、UniClawBench の記事 では、より良いエージェントベンチマークがどう作られるべきかの具体的な一つの答えを見ました。本稿で扱う論文は、その間をつなぐ問いに正面から答えます — なぜズレるのか、何が構造的に間違っているのか。
Tessl のチーム(Maria I. Gorinova 他)が 2026 年 6 月 16 日に arXiv へ投稿したポジション論文 "Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering" の主張は、題名の通りです — 今日のコーディングベンチマークは、エージェント型のソフトウェアエンジニアリングと根本的にズレている、というものです。
ズレの根は単純です。いまのベンチマークは 個々のモデル を評価するために、エージェント以前の時代に設計されました。だから一つの正解(reference solution)に照らして 単一の端から端まで(end-to-end)の点数 を出し、途中の過程についての信号は与えません。問題は、私たちがその物差しを、モデルではなく システム を比べるのに使っている点です。
コーディングエージェントはモデルではなくシステムだ
論文の中心的な捉え直しはここにあります。実戦のコーディングエージェントは、モデル一つではなく システムハーネス(system harness) です — モデル、ハーネス、コンテキスト、環境、フィードバック信号が絡み合った複合体だ、というのです。
score = f(model, harness, context, environment, feedback)
この図で決定的な一文はこれです — これらの構成要素のうち どれか一つ を変えるだけで、点数が 隣り合うモデル世代の差に匹敵する幅 で動きうる、ということ。つまりハーネスやコンテキストをいじるだけで、まるで一世代新しいモデルに替えたかのような点数の変化が出ることがあります。
その構成要素を具体的に描くと分かりやすくなります。コーディングエージェントでは、ハーネスは再試行と計画のループ、コンテキストは検索とプロンプト組み立てがモデルの前に置くもの、環境はコンテナ・ツール・テストランナー、フィードバックはコードを実行して返ってくるものです。それぞれが一つの設計判断であり、そのすべてが同じ一つの点数の中に畳み込まれます。
すると、リーダーボードの一つの数字は苦しい立場に置かれます。モデル A がモデル B を上回ったという表示が、本当に A の方が良いモデルだからなのか、それとも A をくるむハーネスが良かっただけなのか、その数字だけでは区別できません。前の記事で Anthropic が重みを一行も変えずコンテナ設定だけで点数を動かした実測は、まさにこの主張の経験的な裏づけです。
三つのズレ
論文はこのズレを、三つの具体的な症状に整理します。
1) モデルとハーネスをひとまとめにする。 ベンチマークの点数は、モデルと残りのハーネスを 一つの塊に混ぜて しまいます。だから、ある改善がモデルが良くなったおかげなのか、システム設計が良くなったおかげなのかを切り分けられません。ベンダーが「新モデルが数ポイント上がった」と言うとき、その上昇分の多くが実はハーネスの仕事だったりします。
2) 単一の正解が正当な代替解を罰する。 一つの正解ソリューションに照らして採点すると、 同じく正しい別の解法 が不正解にされます。ソフトウェアには正解が複数あります。機能的に完全に正しいアプローチでも、採点が特定の gold patch の diff やテストに縛られていれば 0 点になります。(前の記事で引いた OpenAI の観察 — SWE-bench Verified の未解決タスクのうち 60% 以上が採点基準上そもそも解けなかった、というもの — は同じ問題の極端な例です。)
3) コンポーネント単位の信号がない。 個々のハーネスコンポーネントの水準での信号が 欠けている ため、端から端までのシステム点数は改善を導きにくいのです。数字は一つだけで、それがコンテキスト管理のせいか、ツール呼び出しのせいか、フィードバックループのせいかを教えてくれません。システムを作る人にとっては、これが最も深い問題です — どこが問題かを特定できなければ、何を直せばいいかも分かりません。
この三つは互いに独立ではなく、重なって増幅します。ひとまとめ化はどのコンポーネントが点数を稼いだかを隠し、単一正解の採点は実際には正しかった挙動を隠し、コンポーネント信号の欠如はハーネスを疑ってもそれを確かめられなくします。三つが重なると、端から端までの数字は、順位はつけられても、そこから学べるものがない値になります。
より良い評価とはどんな形か
一つはっきりさせておきます。この論文の要旨は問題を 捉え直す だけで、具体的な代替ベンチマークを処方してはいません。ですから以下は、論文の枠組みが自然に指し示す方向であり、先に見た UniClawBench のような設計がすでに部分的に実装しているものです。三つの方向は、三つのズレをそのまま裏返します。
- コンポーネント単位(component-level)。 各構成要素を計測し、一度に一つだけ変えて(ablation)どの部分が点数を動かしたかを報告します。端から端までの一つの数字ではなく、ハーネスのどの層が寄与したかが見えるべきです。
- 多重正解(multi-reference)。 一つの gold patch と文字列を照合する代わりに、 結果と挙動 で採点します。UniClawBench がライブのコンテナ内でステップ単位のチェックポイントにより「その事が実際に起きたか」を見る方式は、この方向の具体例です。
- システム認識(system-aware)。 ハーネスを固定して文書化したうえで、システムをシステムとして比べます。一つの数字を「モデルの実力」と呼ぶ錯覚をやめる、ということです。
要するに、良いエージェント評価は 何が(どのコンポーネントが)なぜ(どんな挙動で)動いたか を教えてくれるべきです。順位一つでは、そのどちらも分かりません。
現実には、多くの公開リーダーボードはこの三つのどれも与えてくれません。だから負担はあなたに移ります — 自分のハーネスを固定し、自分のタスクの結果で採点し、自分のコンポーネントを一つずつ変えてみることです。表から順位を読むより手間はかかりますが、あなたのシステムについて何かを語ってくれる数字は、そうして得たものだけです。
おわりに
ポジション論文だという性格は、はっきり覚えておく必要があります。新しいベンチマークでも、新しいデータでもありません — 一つの 視点 です。ですから結果のように引用するのではなく、レンズのように使うべきです。ただし、そのレンズはかなり鋭いのです。
核心を一文に縮めるとこうなります — 私たちがリーダーボードの一つの数字で二つのエージェントを比べるとき、実は 二つのシステム全体 を比べながら、あたかも二つのモデルを比べているふりをしている、ということ。だから役に立つ問いは「誰が一位か」ではなく「 どのコンポーネントがその差を生み、それを自分のハーネスで再現できるか 」です。コンポーネント単位・多重正解・システム認識 — この三つがそろうまで、エージェントリーダーボードの小数点は、たいてい信号ではなく設定(configuration)です。
参考資料
현재 단락 (1/24)
コーディングエージェントは、いまや多くのチームでソフトウェアを作る主要な方法になりました。ところが、私たちがそれらを並べる物差しは、いまだに **モデル一つ** を測っていた時代のものです。以前の [...