SWE-benchのスコアを見て「よし、このエージェントは優秀だ」と判断したことがある人は多いはずだ。ただ、あの手のベンチマークが測っているのは、最初に完全なタスク文を渡して、最後に出てきたコードだけを採点した結果でしかない。実際にCursorやClaude Codeを触るときの体験とは、そこが決定的にずれている。私たちは途中で「そこはこう直して」「この制約も足して」と何度も口を出しながら進める。最終的に動くコードへたどり着けたとして、その道中で10回ダメ出しが要ったのか、1回で済んだのかは、同じ「成功」でもまるで別物だ。

この「何回直させたか」を正面から数える対話型ベンチマークが、6月末にarXivで公開されたSWE-Togetherだ。まだ日本語での解説はほとんど見当たらない。

静的な採点から、対話の採点へ

論文の出発点はシンプルで、核心はこの一文に集約される。

Real coding assistance is interactive, with users clarifying goals, adding constraints, and correcting mistakes over multiple turns.

現実のコーディング支援は一発勝負ではなく対話なのだから、評価も対話でやろう、ということ。SWE-Togetherは実際のユーザーとエージェントのセッション記録11,260件から出発し、リポジトリの状態を復元でき、ゴールが明確で、結果を検証できるものだけに絞って109タスクを作っている。1万件超から109件、通過率にして約1%。裏を返せば「対話セッションを再現可能な形で検証する」のがそれだけ難しいということでもあり、この母数の小ささは後述するようにそのまま弱点にもなる。

作り方そのものが面白い。過去のセッションを別のエージェントで再生するために、Geminiで動くユーザーシミュレータが、エージェントの進捗を見ながら元のユーザーが出した質問や修正指示を差し込んでいく。「トラジェクトリ条件付け」と呼ばれる方式で、台本を機械的に再生するのではなく、相手の出方を見て割り込むタイミングを決める。最終的なコードの正しさは、決定的なテストと、Anthropicのモデルによるルーブリック判定(judge score)で採点する。ユーザー役も採点者もLLMという、評価系をまるごとエージェントで回す構成だ。

User Correction という新しい物差し

このベンチマークの目玉は、成否とは別に用意された User Correction という指標にある。定義は素っ気ない。

UserCorrection = N_correction + 0.2 × N_nudge

明確なダメ出し(correction)を1点、軽い催促(nudge)を0.2点として、対話中にユーザーがどれだけ手を入れる必要があったかを足し合わせる。数字が小さいほど、放っておいても勝手に正解へ寄っていく「手のかからない」エージェントということになる。従来のpass率が到達点だけを見ていたのに対し、こちらは道中の摩擦を測っている。

主要モデルの結果は論文のテーブルにこうまとまっている。

モデル	pass@1	pass²	judge score	User Correction
Claude Opus 4.8	63%	52%	0.801	1.38
GPT-5.5	58%	48%	0.763	1.59
Claude Opus 4.6	58%	46%	0.755	1.59

pass@1 は1回の実行で解けた割合、pass² は2回とも閾値を超えた割合で、後者はブレの少なさ(安定性)を見る厳しめの指標だ。最も手のかからなかったのはOpus 4.8の1.38回、逆に最も直しを要したのはMiniMax-2.7の2.17回だった。

ここで論文がわざわざ示すのが、User Correction と pass@1 のピアソン相関で、その値は −0.92。「強いモデルほど直す回数が少ない」という、直感どおりの強い逆相関が出ている。正直に言えば、これは新しい軸が完全に独立した情報を持つわけではないことも意味する。能力が高ければ手もかからない、はある意味当たり前だ。それでも、集計されたpass率だけを眺めていると見落とす「途中の介入コスト」を単独の数値として取り出したこと自体に価値がある。同じ58%でも、少ない介入でそこに達したエージェントの方が、実務での使い勝手は明らかにいい。

手元で回す

コードはApache 2.0で公開されている。セットアップは uv 前提で短い。

uv sync              # .venv に依存関係を用意
cp .env.example .env # APIキーを設定

サンドボックスはE2B(クラウド)かローカルのDockerを使い、実行と採点はステージを分けて呼ぶ。

# 109タスクを実行
.venv/bin/python launch.py canonical_full109.json --stage run --models opencode_opus48 --execute
# 採点
.venv/bin/python launch.py canonical_full109.json --stage judge --models opencode_opus48 --execute

ただし気軽に一発、とはいかない。動かすにはユーザーシミュレータ用のGemini、判定用のAnthropic、対象エージェント用のプロバイダと、複数のAPIキーとサンドボックス課金が同時に要る。評価を回すだけで相応のトークンを燃やす構成で、これは「LLMでLLMを評価する」対話ベンチ全般につきまとうコストだ。再現性の観点でも、採点者やユーザー役のモデルが変われば数字が動きうる点は頭に入れておきたい。

どう受け止めるか

個人的に一番効くと感じたのは、コーディングエージェントの良し悪しを「最終的に解けたか」の一点で語るのをやめさせる圧力になる点だ。実運用でこたえるのは、むしろ何度言い直させられるかという摩擦の方だったりする。SWE-Togetherはそこに数字を与えた。

一方で、109タスクという母数の小ささと、検証しやすいセッションを選び抜いた結果としてのバイアスは割り引いて見るべきだ。「再現・検証できたタスク」は、そもそも比較的素直なタスクに偏りやすい。リーダーボードの絶対値を鵜呑みにするより、User Correction のような「介入コスト」を評価に組み込む発想のほうを持ち帰るのが、この論文の正しい使い方だと思う。自社でエージェントを選ぶときも、通過率の隣に「どれだけ手がかかったか」の列を一本足すだけで、意思決定の解像度はだいぶ変わるはずだ。