テクニカル・サマリー：ベンチマークがいかにコンピュータ使用エージェントのスコアを誤評価するか

1. 問題提起

コンピュータ使用エージェント（CUA）は、ウェブインターフェースの操作やデスクトップソフトウェアの運用において、ますます広く導入されている。しかし、その評価は、最終状態、URL、またはDOMフィールドを検査する、脆弱でスクリプト化されたオラクル（判定器）に大きく依存している。これにより、「デプロイメントと測定の乖離」が生じている。これは、タスクが短いエピソードから、長期間のクロスアプリケーション・ワークフローへと進化するにつれて、特に顕著となる。

特定された核心的な問題は、ベンチマークのスコアは能力の直接的な観察結果ではなく、複雑なパイプラインの出力であるという点である。このパイプラインは、以下の4つの異なる失敗モードに対して脆弱であり、評価を歪ませる：

1. タスク構築: 陳腐化したタスク、リークした指示、または壊れた環境（例：期限切れの認証情報、ライブサイトにおけるドリフト）。
2. 軌跡の観測: 決定的な視覚的証拠（スクリーンショット、ツールの応答）を欠いた不完全なログ。
3. スコアリング: 正当な代替解を拒絶したり、無効なショートカットによる表面的な正解に報酬を与えたりする評価器。
4. レポート: 特定の失敗原因を隠蔽し、標的を絞ったエンジニアリング改善を妨げる集計成功率。

これらの個別の問題を単一の「エージェントの失敗」カテゴリに集約してしまうことは、システムの誤ったランキングや、誤った方向へのエンジニアリング努力を招く。

2. メソドロジー

著者らは、CUA評価のための4段階の信頼性フレームワーク（タスク構築、実行環境、スコアリング、レポート）を提案する。このフレームワークを検証するため、彼らはウェブナビゲーション、エンタープライズ・ワークフロー、およびデスクトップ制御（OSWorld、WebArena、VisualWebArena、WorkArena、AssistantBench）にわたる5つのベンチマークから、150件の公開された失敗スコア付き軌跡に対して実証的な監査を実施した。

監査手順

• サンプリング: 記録された累積報酬がゼロ（FAIL）であった軌跡を選択した。
• ラベリング: 2つのビジョン対応LLMジャッジ（GPT-5.5およびClaude Sonnet）が、推論、アクション、スクリーンショットを含むフル軌跡を独立してレビューした。彼らの判断は、データの一部をブラインドでレビューした2つの人間グループによってアンカー付けされた。
• 決定ロジック:
  • ステージ1（判定の妥当性）: 「FAIL」が真のエージェントの失敗であるか、評価器の偽陰性（エージェントは成功したが拒絶された）、壊れたタスク（環境または仕様の問題）、あるいは不明であるかを判定した。
  • ステージ2（診断）: 真の失敗に対しては、MASTから適応した3層の診断タクソノミーを適用し、最も早い決定的な失敗を特定した：
    • ティア1（プランニング／仕様）: 違反、ループ、または幻覚（ハルシネーション）による機能。
    • ティア2（実行／グラウンディング）: 不正確な座標、状態の喪失、またはツール引数のエラー。
    • ティア3（検証／フィードバック）: 早すぎる終了、検証の欠如、またはフィードバックを無視した反復（ノーオップ）。

3. 主な結果

判定の信頼性

監査の結果、記録されたFAIL判定の**15.3%**が誤りであることが判明した。

• 10.7%は評価器の偽陰性であった：エージェントはタスクを完了したが、スクリプトまたはチェッカーが正当な代替案を拒絶した（例：WebArenaの文字列一致による、正しい意味論的な回答の拒絶）。
• 4.7%は壊れたタスクであった：環境の問題（例：検索エンジンの停止、CAPTCHAの壁、またはVM内の空のシステムファイル）により、タスクが達成不可能であった。
• **3.3%**は、提供された証拠が不十分であったため「不明」のままとなった。

失敗の診断

122件の真のエージェント失敗のうち、スカラー値としての成功率は、偏ったエラー分布を隠蔽していた：

• ティア3（検証／フィードバック）: 失敗の39.3%。主要なサブカテゴリはフィードバックを無視した反復（29.5%）であり、画面の状態が変わらないにもかかわらず、エージェントがアクションを繰り返していた。
• ティア1（プランニング／仕様）: 失敗の35.2%。仕様違反およびプランニングのループによって引き起こされた。
• ティア2（実行／グラウンディング）: 失敗のわずか13.9%。
• 観測可能性の影響: 監査データからスクリーンショットを削除すると、偽陰性の検出能力が著しく低下し、ジャッジ間の合意度も低下した。これは、スクリーンショットを含む軌跡が、有効な監査に必要であることを証明している。

4. 設計ガイドラインと貢献

これらの知見に基づき、本論文は信頼できるCUAベンチマークのためのステージ固有の設計ルールを導出している：

• タスク構築: 飽和を防ぐためのプロシージャルな更新を備えた「リビング・タスクプール」へと移行すること。タスクは専門的な妥当性を確保するためにドメインエキスパートによって作成される必要があり、タスク、環境、およびオラクルは共にバージョン管理されなければならない。
• 環境: 再現性を確保するため、実行スタック（OS、アプリのバージョン、スキャフォールド）は固定され、開示される必要がある。汚染を防ぐため、リトリーバル（検索）の境界は明示的に宣言されなければならない。
• スコアリング: チェッカーは、タスク文が宣言している内容を正確にテストし、定義された空間内のすべての正当な解を受け入れなければならない。スコアリングは、結果のみのチェックから、プロセスを評価する較正されたルーブリックベースのジャッジへと移行すべきである。
• レポート: ベンチマークは、スコアとともに、証拠として完全な軌跡（スクリーンショット、ツールのI/O、タイムスタンプ）を公開しなければならない。レポートには、単なる集計成功率だけでなく、失敗ごとの所在（locus）とプロセス段階の診断を含めるべきである。さらに、レイテンシ（デッドライン未達率）とコスト（検証された成功あたりのドル）も、第一級の指標として扱うべきである。

5. 意義と範囲

本論文は、再生証拠がチェッカーと矛盾するか、あるいは無効なタスク条件を明らかにしている場合、CUAの失敗判定は疑うべきであると主張している。現在のスカラー成功率への依存は、エージェントの限界の真の性質、特に検証とプランニングにおける限界を覆い隠していると断じている。

範囲と制限事項:

• 実証的な主張は、ウェブ、デスクトップ、およびエンタープライズ・ワークフローにわたるGUIコンピュータ使用評価に限定される。
• 監査は150件の軌跡を対象としている。サンプルサイズは控えめであるが、広い信頼区間は、評価器のエラーが相当な割合で発生していることを示している。
• 本研究は偽陰性（見逃された成功）に焦点を当てており、失敗スコア付きの軌跡のみをサンプリングしたため、偽陽性（誤ってパスしたエージェント）については推定していない。
• 本論文は新しいエージェントアーキテクチャを提案するものではなく、むしろ、エビデンスに基づくガバナンスをサポートするために、評価インフラストラクチャをどのように構築し、解釈すべきかについての改革を求めている。