エージェント評価ベンチ地図 — SWE-bench・GAIA・OSWorldは何を測るか

エージェント評価の代表3本（SWE-bench・GAIA・OSWorld）が実際に何を測っているかを、採点方式の違いから解きほぐす。汚染とリークの4類型、そして発表されたスコアを自分の用途向けに読み替える手順まで。

SWE-bench: Can Language Models Resolve Real-World GitHub Issues?

定規は能力を測らない。定規の目盛りを測る

体力テストの50m走で6.5秒の人がいたとして、その人が「速い」のは分かります。でも、サッカーで点が取れるかは分かりません。50m走が測っているのは50mを直線で走る速さであって、サッカーの能力ではないからです。

エージェントのベンチマークも同じです。「SWE-benchで70%」と聞くと「7割の開発業務ができる」と読みたくなりますが、そう読める根拠はどこにもありません。測られているのはそのベンチマークが定義した、その採点方式での正解率だけです。

にもかかわらずベンチマークは重要です。定規がなければ、モデルが良くなったかどうかを誰も判定できないからです。大事なのは定規を捨てることではなく、その定規が何をどう測っているのかを知った上で、自分の用途に読み替えることです。この記事はその読み替え方を扱います。

3本の定規

エージェント評価でいま最もよく引用される3本を並べます。3本とも「モデルが文章として正しいことを言えたか」ではなく、「環境に働きかけて、結果が正しくなったか」を採点しているのが共通点です。違うのは、どの環境で、何を成功と定義するかです。

SWE-bench — リポジトリの中で、テストが通るか

SWE-bench（Jimenez ら, 2023）は、GitHub の実在するPythonリポジトリから集めた2,294件の課題からなります。1件は「issueの本文」と「そのissueが解決される直前のリポジトリの状態」の組で、エージェントはコードを編集してパッチを出します。

採点は人間の目視ではありません。そのissueを解決したPRに付いていたテストを2種類に分けて使います。

• FAIL_TO_PASS: 修正前は失敗し、修正後は通るべきテスト（=バグが直ったか）
• PASS_TO_PASS: 修正前も後も通るべきテスト（=他を壊していないか）

両方が緑になったときだけ「解決」と数えます。つまり SWE-bench が測っているのは、「用意されたテストを緑にする差分を書けるか」です。派生として、扱いやすさのために300件に絞った Lite、人手で問題文とテストの妥当性を検証した500件の Verified があります。Verified がわざわざ作られたこと自体が、元の2,294件に「問題文だけでは何を直すべきか決まらない」「テストが厳しすぎる／緩すぎる」課題が混ざっていた証拠でもあります。

GAIA — 調べて、短い答えを1つ出せるか

GAIA（Mialon ら, 2023）は「一般アシスタント」のベンチマークです。466問で、うち165問が答え付きの検証セット、300問が答えを伏せたテストセット（提出してリーダーボードで採点）という構成です。

特徴は2つあります。1つは人間には簡単でAIには難しい問題を狙って作ってあること。Web検索・PDFや表の読み取り・画像の理解・複数ステップの計算を組み合わせないと辿り着けない問いを、難易度3段階で用意しています。もう1つは答えが短い文字列で、完全一致で採点されること。「12」「Paris」のように一意に決まる形にしてあるので、採点にLLMも人間も要りません。

この設計は再現性を買う代わりに、表現力を捨てています。正しく調べ切ったのに書式が違って不正解、ということが起きます。

OSWorld — 画面を操作して、状態を変えられるか

OSWorld（Xie ら, 2024）は本物のOS（Ubuntuを中心にWindows/macOSも）の仮想マシンを丸ごと環境として使います。369件のタスクは、ファイル操作・ブラウザ・オフィスソフト・端末など、複数アプリをまたぐものを含みます。

採点が一番おもしろいのはここです。各タスクには初期状態を作るセットアップスクリプトと、最終状態を検査する実行可能な検証スクリプトが付いています。「このスプレッドシートの列を並べ替えろ」なら、終了後にファイルを開いて中身を検査する。操作の手順は問わず、結果の状態だけを見るわけです。

そのぶんOSWorldは、3本の中で最も「実運用の手触り」に近く、同時に最も環境依存で不安定です。ネットワークの調子、アプリのバージョン、ダイアログの出方で結果が変わります。

採点方式が「測れるもの」の上限を決める

3本ともスコアは同じ形をしています。

$$\text{score} = \frac{1}{N}\sum_{i=1}^{N} \mathbf{1}\!\left[V_i(s_i^{\text{final}}) = 1\right]$$

$N$ は課題数、$s_i^{\text{final}}$ はエージェントが作業を終えたあとの環境の状態、$V_i$ はその課題専用の検証器（テスト実行・文字列一致・検査スクリプト）、$\mathbf{1}[\cdot]$ は中身が真なら1・偽なら0を返す関数です。要するに「検証器が丸をくれた課題の割合」、それ以上でも以下でもありません。

この式を見ると、ベンチマークの限界がそのまま読み取れます。$V_i$ が見ていないものは、スコアに一切現れません。途中で何回APIを叩いたか、何ドルかかったか、途中で消してはいけないファイルを消したか、10回やって何回成功するのか——全部 $V_i$ の外側です。

試行回数の扱いも読み替えの要点です。エージェントは実行のたびに結果が変わるので、$n$ 回走らせて $c$ 回成功したとき、$k$ 回引いて1回でも当たる確率を推定するのが pass@$k$ です。

$\binom{a}{b}$ は「$a$ 個から $b$ 個を選ぶ組み合わせの数」です。分数の部分は「$k$ 回引いて全部ハズレを引く確率」なので、それを1から引けば「少なくとも1回当たる確率」になります。

ここが読み替え事故の温床です。pass@1（1回で当てる）と pass@5（5回のうち1回当たればよい）は、同じモデルでも大きく差が出ます。発表スコアが pass@1 なのか、複数試行の最良なのか、多数決なのかを確認せずに横並び比較すると、比較そのものが無意味になります。

何が測れていないか

採点式の外側にあるもののうち、実務で効くものを挙げます。

コスト。 同じ70%でも、1課題あたり$0.3で出したのか$15かけたのかで意味が違います。ベンチマークの多くはコストを報告義務にしていないので、スコア表からは読めません。

足回り（スキャフォールド）の寄与。 SWE-benchのスコアは「モデル単体」ではなく「モデル＋検索ツール＋編集ツール＋再試行ループ」の合計点です。同じモデルでもエージェントの作り次第で数十ポイント動きます。モデルを比較しているつもりで、実は誰かの足回りを比較しているのはよくある取り違えです。

指示の曖昧さ。 現場の依頼は「ログイン周りが最近おかしい」から始まります。SWE-benchのissueは、少なくとも「どのテストが通るべきか」が確定している問題に整えられています。

副作用と安全性。 OSWorldの検証スクリプトは目的の状態を見ますが、「ついでに別のファイルを上書きした」を減点する設計にはなっていません。取り消せない操作を含む本番運用では、ここが最大の関心事になります。

分散。 369件や300件のテストセットで、2ポイントの差は誤差の範囲に沈みがちです。1件は約0.3ポイントなので、数件の当たり外れで順位が入れ替わります。信頼区間や複数シードの結果が付いていないスコア差は、そのまま実力差として読まないほうが安全です。

汚染とリークの4類型

「高いスコアが実力を意味しない」もう一つの理由が汚染（contamination）です。混同されがちですが、少なくとも4つの別ものがあります。

1. 学習データ汚染。 ベンチマークの問題と答えが、モデルの事前学習データに入っている。SWE-benchはGitHubの公開リポジトリから作られているので、修正コミットもissueの議論も、原理的にはクロール対象です。「解いた」のか「思い出した」のかを、スコアだけでは区別できません。判別の目安になるのがカットオフとの前後関係で、モデルの学習データ収集時点より後に作られた課題でのスコアが、前の課題より明確に落ちるなら、汚染を疑う根拠になります。

2. 解のリーク（環境内に答えがある）。 学習データではなく、与えられた環境の中に答えが置いてある類型です。issue本文に投稿者が「このファイルのこの行を直せば直る」と書いていたり、リポジトリの別ブランチやテストコード自体に修正後の期待値が書かれていたり。エージェントは推論せずにgrepするだけで当てられます。SWE-bench Verified の人手検証は、こうした課題を弾く作業でもありました。

3. 弱い検証器。 テストが緩くて、本質的でないパッチでも緑になる型です。テストが assertEqual(f(1), 2) しか見ていなければ、return 2 を返すだけの関数で通ります。実行ベース採点は「人間の主観が入らない」代わりに、テストが定義した範囲でしか正しさを保証しないという弱点を必ず持ちます。

4. リーダーボード過学習。 これが最も静かに進みます。テストセットに何度も提出し、通らなかった課題を見てプロンプトや足回りを直し、また提出する。1回1回は正当なチューニングでも、繰り返すとテストセットの答えが少しずつ開発者の頭を経由してシステムに漏れます。訓練データを一度も見ていなくても、テストセットに過学習することは可能なのです。

この4つ目の感覚は、素朴な過学習の図でつかめます。次の図で多項式の次数を上げると、訓練データにはぴたりと合うのにテスト誤差が跳ね上がります。リーダーボードでは「訓練データ」の位置にテストセットが座っている、と読み替えてください。

汚染の1番目を実際に調べるとき、現場でまずやるのは問題文とコーパスの重なり探しです。素朴には n-gram の一致を数えます。

def contaminated(question, corpus_docs, n=13, thresh=0.5):
    grams = {question[i:i+n] for i in range(len(question) - n + 1)}
    for doc in corpus_docs:                       # 学習コーパス側
        hit = sum(1 for g in grams if g in doc)
        if hit / max(len(grams), 1) > thresh:     # 重なり率が閾値超え
            return True
    return False

ただし文字列一致は、言い換えられた問題や翻訳を取り逃します。そこで実務では埋め込みで近傍を引く（意味が近い文書を探す）方法を併用します。下の図でクエリを動かすと、同じデータでも距離の測り方（内積・コサイン・L2）で上位の顔ぶれが変わるのが見えます。汚染検出でも「どの距離で何件見るか」の設定次第で結論が変わる、というのが実感として効きます。

スコアを自分の用途に読み替える手順

発表された数字を見たとき、順に確認します。

1. どのサブセットか。 SWE-bench Full / Lite / Verified はスコアの水準が違います。名前を確認せずに比較しない。
2. 足回りは何か。 モデル名だけでなく、エージェントフレームワーク・ツール・最大ステップ数・再試行回数。
3. pass@いくつか。 1回勝負か、複数試行の最良か、多数決か。
4. 1課題あたりのコストと所要時間。 記載がなければ「不明」であって「安い」ではない。
5. カットオフとの前後。 モデルの学習データ収集時点より前に公開された課題かどうか。
6. 自分の分布との距離。 SWE-benchは12個のPythonリポジトリ、GAIAは英語のWeb、OSWorldはUbuntu中心。自分の環境が別言語・社内システム・別OSなら、その差ぶんは推定でしかありません。

そして最後に一番効く問いがあります。「このベンチマークの検証器は、私が困る失敗を落とすか」。本番で怖いのが「見た目は動くが例外時にデータを壊す」なら、FAIL_TO_PASS を緑にする採点はその失敗を一切見ていません。ならばそのスコアは、自分にとっては参考値以上にはなりません。

現場ではこう使う

MLエンジニア／評価担当が、モデルや外部エージェント製品を選定するとき。 公開スコアは一次スクリーニング（明らかに弱い候補を落とす）にだけ使い、最終判断は自社の課題を30〜100件切り出した内部ベンチで行います。作るときは公開ベンチの構造をそのまま真似るのが早道です。SWE-bench 型なら「修正前に落ちるテスト」と「壊してはいけないテスト」を課題ごとに用意する。OSWorld 型なら初期状態のセットアップと最終状態の検査スクリプトを書く。手順ではなく最終状態を検査するのがコツで、これを守ると、エージェントの作りを変えても評価器を作り直さずに済みます。

触るものの名前。 SWE-bench 側では FAIL_TO_PASS / PASS_TO_PASS、SWE-bench Verified、Docker で1課題1コンテナを立てる評価ハーネス。GAIA 側は3段階の Level と完全一致採点、テストセットの答えが公開されないこと。OSWorld 側は仮想マシンのスナップショット、setup 設定と evaluator 関数（getters と metrics の組）。共通して見るのは pass@$k$、最大ステップ数、1課題あたりのトークン数とコスト。

知らないと事故になる落とし穴。

• 内部ベンチのテストセットを毎日見ながらプロンプトを直す。 上の4類型の4番目そのもので、2〜3週間で内部ベンチのスコアが実感と乖離し始めます。防ぐには開発用と封印用に分け、封印側は月1回しか触らない。数字が動かないぶん退屈ですが、それが正しく機能している証拠です。
• 公開スコアの比較で足回りを揃え忘れる。 モデルAは高機能なフレームワーク、モデルBは素の1回呼び出し、という比較表を作ってしまう事故は非常に多いです。
• 1回だけ走らせて結論を出す。 エージェントの実行は分散が大きく、特にOSWorld型は環境要因で揺れます。最低3回、できれば5回走らせて、平均と最悪値の両方を見ます。平均だけ見ると、たまに破壊的な操作をするエージェントを見逃します。
• サンプルが少ない内部ベンチで小数点以下を語る。 50件なら1件が2ポイントです。「2.1ポイント改善」は1件ぶれただけかもしれません。
• 評価環境に本番の資格情報を置く。 エージェントは想定外の操作をします。評価用VMは使い捨て・ネットワーク制限・読み取り専用マウントを既定にします。

面接や設計レビューで問われる形。 「このベンチのスコアが高いのに、うちの環境で使えない可能性はどこにありますか」——答えの筋道は、①検証器が見ていない失敗（コスト・副作用・分散）、②分布の差（言語・OS・社内システム）、③汚染とリーク（カットオフとの前後、環境内の答え）、④足回りの寄与、の4本立てで整理すると漏れません。

まとめ

• SWE-bench・GAIA・OSWorld は、それぞれ「テストを緑にする」「短い答えを完全一致で当てる」「最終状態を作る」を測っている。共通形は「検証器が丸をくれた割合」だけ
• 検証器の外にあるもの（コスト・副作用・分散・足回りの寄与）はスコアに現れない
• 汚染は4類型ある。学習データ汚染／環境内の解のリーク／弱い検証器／リーダーボード過学習。4番目は訓練データを見ていなくても起きる
• 公開スコアは一次スクリーニングまで。判断は自社課題の内部ベンチで、開発用と封印用を分けて行う

エージェント側の設計そのものはLLMエージェントの基礎、評価器の作り方の各論はエージェント評価、汚染を実験で確かめる手つきはデータリークを実験で確かめるで扱っています。