10月12日、Machine Learning Masteryが「AI Agent Benchmarks Explained: SWE-Bench, GAIA, WebArena, and More」と題した記事を公開した。この記事では、主要なAIエージェントベンチマークが実際に何を測定しているのか、そしてリーダーボードのスコアだけに頼ることの危険性について詳しく解説されている。

AIエージェントの評価基準が乱立する中、「リーダーボードで高スコアを取ったエージェントが、本番環境でも使えるか」は別問題だ。本記事では、SWE-Bench・GAIA・WebArena・OSWorldという4つの主要ベンチマークの設計思想と限界を整理する。

エージェントベンチマークと従来ベンチマークの根本的な違い

MMLUやHumanEvalに代表される従来のベンチマークは、「1問1答」形式だ。モデルに質問を投げ、返ってきた回答を採点する。言語理解や推論能力の測定には有効だが、現実の作業をこなせるかどうかは分からない。

エージェントベンチマークはまったく異なる。エージェントはウェブを閲覧し、コードを書いて実行し、GUIを操作し、複数ステップにわたって目標を追いかけなければならない。失敗は「誤答」だけではない——処理が無限ループに陥ったり、ワークフローが途中で壊れたりすることも失敗だ。

記事はこれを端的に表現している。「従来のベンチマークは筆記試験。エージェントベンチマークは、本物のツールと摩擦と想定外の出来事をこなす実地シミュレーションだ」。

4つの主要ベンチマーク

SWE-Bench / SWE-Bench Verified：ソフトウェアエンジニアリングの試金石

SWE-Bench は、DjangoやScikit-learnなどの実際のPythonリポジトリから取得したGitHub issueをエージェントに与え、バグを修正するコードパッチを生成させるベンチマークだ。そのパッチが既存のユニットテストをパスすれば「成功」とみなされる。

SWE-Bench Verified は、その中から人間のエンジニアが「本当に解ける問題かつテストが正確に機能している」と確認したサブセット。オリジナルの問題には曖昧な仕様や不完全なテストスイートが含まれており、それを補正したものだ。

ただし重要な留意点がある。ユニットテストをパスすることと、良いコードを書くことは別物だ。 メモリリークを生んでいても、セキュリティ脆弱性を抱えていても、テストさえ通れば「成功」になる。SWE-Benchはコードの品質・保守性・安全性を測定しない。

GAIA：複数ツールをまたぐ推論能力

**GAIA**（General AI Assistants）は、複数のツールとモダリティをまたいで複雑な問いに答える能力を評価する。典型的なタスクは「文書を参照し、ウェブ上の情報と照合し、計算を行い、最終的な答えを導く」といった構成だ。

GAIAの特徴は、ネットアクセスができる人間には簡単だが、現在のAIには難しいという設計思想にある。ウェブ検索・ファイル操作・多段階推論を正しい順序で組み合わせられるかを問う。

限界は、GAIAのタスクが「唯一の正解を持つ問題」に寄っている点だ。現実のアシスタント業務では、ユーザーの要求が変化したり、目標そのものが多義的だったりする状況が頻繁に起きる。GAIAの設計はそうした「解が一意に定まらないケース」をスコープ外に置いており、曖昧な指示への対応力は評価対象になっていない。

WebArena / BrowserGym：ブラウザ操作の実力

WebArena は、ECサイト・CMSシステム・フォーラムなどのサンドボックス版ウェブアプリを使い、エージェントがボタンのクリック・フォーム入力・メニュー操作を通じてタスクを完遂できるかを評価する。ライブのウェブサイトではなくサンドボックスを使う点が特徴だ。

BrowserGym はWebArenaとは独立したフレームワークで、ServiceNowが開発した。異なるウェブ環境や評価タスクをモジュールとして差し替えられる構造になっており、WebArenaをはじめ複数のブラウザ操作ベンチマークをその上で実行・比較できる。特定のスコアを持つベンチマークというより、ブラウザエージェント研究のための共通実行基盤として位置づけられている。

大きな問題はデータ汚染（contamination）だ。WebArenaの元タスクはすでに長期間流通しており、新しいモデルのトレーニングデータに含まれている可能性がある。高スコアが「本物の能力」なのか「タスク構造の丸暗記」なのか、ベンダーはほとんど開示していない。

OSWorld：OSごとエージェントに渡す

OSWorld はサンドボックス化されたデスクトップOS上でエージェントを動かし、ファイル操作・GUIアプリ操作・システム設定変更・複数プログラムの連携といった実際のPC作業を評価する。最も野心的なスコープを持つベンチマークだ。

裏返しとして、OSWorldは最も脆弱でもある。 シミュレーションOSのクラッシュ、描画の乱れ、アプリの予期しない挙動があれば、エージェントの推論が正しくても失敗とみなされる。スコアはモデルの能力だけでなく、インフラの安定性にも左右される。

リーダーボードが見せない共通する4つの死角

各ベンチマークの構造的な限界に加え、記事は「どのベンチマークも共通して測っていないもの」を列挙している。これらは個々のベンチマークの欠陥というより、現在のエージェント評価全体が抱える空白地帯だ。本番運用の観点からはむしろこちらが重要になる。

• コストと効率： SWE-Benchで**80%を取るエージェントが、数十回の試行と膨大なAPIコールを消費していることがある。70%**のエージェントより高い請求書が来ることもある。ベンチマークのスコアはコスト構造を一切反映しない。
• レイテンシ： タスクに30秒かかるか20分かかるかは、UXにもインフラコストにも直結する。しかし主要ベンチマークに速度指標は存在しない。応答速度が要件になる用途では、スコアだけを見て採用を決めると後から痛い目を見る。
• 安全性と境界の遵守： 権限境界を守るか、不確かなときに確認を求めるか、破壊的な操作を拒否するか——これらは本番で最も重大な挙動にもかかわらず、一貫して評価するベンチマークは現時点でほぼ存在しない。
• エラー回復： リンク切れ・予期しないUI変化・サブプロセスの失敗に直面したとき、エージェントがどう立て直すかは本番での真の実力を示す。しかしこの次元はベンチマーク設計上ほぼ未評価のままだ。

さらに、自動採点自体のノイズも問題だ。多くのベンチマークは別のLLMを使って正誤を判定する。自信満々な誤答が自動採点を騙し、スコアを実態より高く見せることがある。

ベンチマークの正しい使い方

記事の結論は明快だ。

公開ベンチマークは「絞り込みの道具」として使う。 SWE-Benchでほぼゼロのシステムはソフトウェアエンジニアリング用途に使えない。GAIAで苦戦するシステムは複雑なリサーチ業務に向かない。候補を減らすためには有効だ。

本番性能の予測には使えない。 制御されたテスト環境と実業務の間のギャップは大きい。最終的に信頼できる評価は一つだけだ——自社の実際のワークフローで、自社のデータを使って評価すること。 旅行予約をするエージェントは旅行予約でテストし、契約書を要約するエージェントは自社の契約書でテストする。

詳細はAI Agent Benchmarks Explained: SWE-Bench, GAIA, WebArena, and Moreを参照していただきたい。