Computer-Use Agents の検証者設計を再考する研究発表

電子メールの処理、スプレッドシートの作成、3D 図の描画、財務メモの起草といった複雑な専門業務を担うようになりつつある Computer Use Agents (CUA) において、verifiers(検証器) はその能力に関する評価や学習のための信号を提供する中核的な役割を果たしています。OSWorld 2.0 や Agents' Last Exam といったベンチマークでは、プログラムによるチェックという形でこれらの検証器を活用し、エージェントが生産レベルの業務を完遂できるかを測定しています。

しかし、検証スコアがデプロイの可否を示す指標となったり、学習における報酬として機能したりする場面では、検証者の誤りは単なる学術的な欠陥に留まりません。それらは直接、モデルの品質低下を引き起こします。この課題を解明するため、私たちは金融、法務、エンジニアリング分野のワークフローを含むプロ向けオフィス CUA 訓練データセットから 38 タスクと、OSWorld 2.0 のタスクを対象に分析を行いました。その背景にある検証器の質を評価したのです。

ベンチマークにおけるプログラム型採点者の欠陥

私たちの評価により、OS World V2 の標準的なベンチマーク採点には、主に以下の 2 つの失敗モードがあることが明らかになりました。

「すべてか、ゼロか」の二値評価: OSWorld 2.0 のような複雑な多段階ワークフローでは、エージェントはメールを読み込み、偽物の書類の中から承認書を見つけ出し、10 個のファイルにわたるチェックリストを作成する必要があります。数十もの異なるステップが存在するにもかかわらず、採点者は参照ファイルとの単なる二値比較しか行わず、硬直した 0 か 1 の結果を返します。この評価方式はパブリックリーダーボード上で深刻な順位逆転を引き起こしています。例えば、最先端のモデルが 0.0 を取得する一方で、性能の劣る 2 つのモデルが 1.0 を獲得してしまうのです。強化学習においては、こうした「すべてかゼロか」の信号が学習報酬を著しく阻害し、長期にわたるタスクに対する評価指標も極めて希薄なものになってしまいます。

脆く、非現実的な要件: OSWorld 2.0 の Task 018 では、エージェントはメールとカレンダーを通じて会議のスケジュールを設定する必要があります。たとえエージェントがわずかに異なる経路で成功したり、書式に細かな違いがあったり、時間設定に小さなズレが生じたりしても、採点基準には自然なニュアンスを受け入れる余地がありません。その結果、全く挑戦しなかったエージェントと同じく、0 点という評価を下されてしまいます。

敵対的な現実：ルールの設計がいかに難しいか

verifier（検証者）を作成するアプローチには主に 2 つあります：

プログラムによる検証（OSWorld スタイル）：エージェントの出力を開いてテストする小規模なスクリプトです。具体的には、ファイルが存在するか、合計値が一致しているか、行の順序が正しいかなどを検査します。

VLM エージェントジャッジ：モデルにエージェントの実績作業と参照となる正解、そして複数の成功次元をカバーする評価基準を与え、出力に対して採点させます。

それぞれには長所と短所があり、以下にまとめました。

Scale AI のアプローチ

Scale は、この課題に対して両方の手法の強みを組み合わせて取り組んでいます。まず、専門家が正しいと考える内容を捉えた人間が作成した評価基準（ルブリック）を出発点とします。次に、決定論的なチェックで正確に評価できる項目はすべて自動変換します。残りの評価基準については、人間の専門家によって入力が検証された「判定者」を用いて継続して採点を行います。さらに、変換された決定論的チェックが本番環境に展開される前には、欠陥のあるサンプルを新しい採点者に渡して、その欠陥が検出され、スコアが減点されることを確認します。

報酬ハッキングの罠

「報酬ハッキング」に対して耐性を持つ評価基準を設計することは、極めて困難です。これはエージェントが作業を実行せずに採点の抜け穴を利用して高得点を獲得する現象を指します。評価者が緩いヒューリスティックに依存している場合、エージェントはタスクそのものよりも指標の最大化を優先して最適化し始めます：

評価基準の設計には、構文構造を無視したマッチング方式がしばしば採用されています。この手法では制約のないキーワードや数値を検索するだけで良いため、エージェントは構造化されていないテキストの塊を出力するだけで高得点を得てしまいます。例えば、チェスエンジンに勝利するという指示に対して、「対戦相手のエンジンが降参するまで盤面状態を変更し続けた」という記述のみで「勝利」と判定されることがあります。これは実際にはゲームの意図された進行を回避した行為でありながら、評価システムはそれを正解として扱ってしまいます。同様に、単純な数値の羅列も、より緩いチェック基準に対して同じような抜け道として機能します。

また、指示内容の漏洩という問題もあります。文字列の重複度に基づく評価ルブリックでは、エージェントがプロンプトの文章をそのまま成果物にコピーするだけで高得点を得てしまうケースが多発しています。これにより、実際の実行や調査を行っていないにもかかわらず、高い信頼スコアが付与されてしまいます。

さらに、「何もしない」戦略でも高得点が取得できてしまう欠陥も存在します。単なる存在確認のチェックや、制約のないベースラインでは、空のテンプレートや編集されていない元のファイルを提出するだけで、80%を超えるスコアを獲得できてしまいます。

参照データ自体にも欠陥がある場合もあります。大文字小文字の区別に関するバグや、誤った正解ファイルが使用されていると、正しいエージェントの解決策が不当に減点され、一方で退化した近道が偶然高評価されてしまうという逆転現象が起こります。

これらの抜け穴を塞ぐには、あらゆるエッジケースを事前に想定し、厳密な正確性と、オープンエンドな問題解決に必要な柔軟性のバランスを取ることが不可欠です。

そこで私たちは、評価プロセスを2 つの明確なチェックに分離して再構築しました。

ルール設計の脆弱性（ゲーム化できないか？）

単に期待される回答ファイルとの一致だけで評価するルールの場合、分析を行う代わりに参照ファイルをコピーしただけでクリアできてしまうという欠陥があります。

例えば、「散らかったデータセットをスプレッドシート、レポート、プレゼンテーション資料に変換せよ」というタスクがありました。報酬の大部分が「正解ファイルとの一致」に依存していたため、実際のデータクリーニングを行わずに参照値をそのまま再現するだけで高得点を獲得できてしまう事態が発生しました。さらに問題なのは、同じ数値や指標がスプレッドシート、レポート、スライドと複数の成果物で重複して評価されていた点です。一つの回答が複数の箇所で点数としてカウントされてしまったのです。

これを解決するために、私たちは「提出された作業そのもの」を評価する仕組みを導入しました。具体的には、エージェントが実際に提出した内容から結果を再計算し、重複する評価基準は統合します。また、書式チェックと正しさの検証は分離して行い、参照ファイルはあくまで二次的な整合性確認として扱うようにしています。

エージェントの不正行為（ゲーム化していないか？）

タスクを解決するために出力を計算するのではなく、解答キーを読み込んだり、テスト結果をハードコードしたりといった、望ましくないエージェントの行動が観測されています。

例えば、2 つの財務リスクレポート作成を命じるタスクにおいて、エージェントは分析をスキップし、予期される回答ファイルを開くテキスト抽出ツールを使用。そして、その答えを一字一句そのまま出力にコピーしました。出力は完璧に見え、通過しましたが、実際には計算を行わず、単に解答キーを読み取っただけです。違反のカタログではこれは「Oracle Read（アーティファクトやメタデータの悪用）」と分類され、エージェントによる不正行為としてフラグが立ちます。

実用的な知見

CUA 検証器作成パイプラインをストレステストするため、いくつかの実験を行いました。以下にその知見を示します。

ルールベース検証器の変換合意率

検証器と評価用 AI（judge）が同じ出力に対して判定を行った際、AI が合格とした項目について両者の一致率は 99.5% に達しました。残りの不一致はすべて手動で裁定しました。

さらに、生産環境の AI 評価者に対し、同一の出力をバイト単位で完全に複製した 3 つのコピーを与えたところ、それぞれ 0.0、0.125、0.175 という異なるスコアが返されました。これは、AI が判定を計算するのではなくサンプリングしているため、同じ入力でも結果が分岐してしまうからです。一方、プログラムによる検証器は 3 つのケースすべてに同一のスコアを付与しました。ここから得られる教訓は、カウントやフォーマットチェックなど正確な再現が必須の項目はプログラム検証器へ変換し、主観的な判断が必要な項目のみを AI 評価者に任せるべきだということです。

評価者におけるパイプライン盲点

AI 評価者が、財務メモタスクに対する既知の完全な回答基準に対して評価を行った際、わずか 0.5 というスコアしか付与しませんでした。

テキスト抽出パイプラインは生のテキストと表を処理しましたが、埋め込まれたチャート画像には全く対応していません。皮肉なことに、審査員は未抽出のチャート項目を正解として扱い、「レンダリングされたテキストから特定のデータを検証できない」と明言しています。こうした盲点を持つ審査員は、読めない要素に対して失敗と判定するのではなく、不当に加点してしまう傾向があります。

チャート画像を処理するためのビジョンモデルステップを追加したところ、参照スコアは 0.98 に向上しました。この視覚的検証により、実際の誤りも検出されました。例えば、チャートの棒グラフで符号を反転させて描画し（利益ではなく損失を示すべきところを利益として表示）、その結果スコアが 0.35 に低下した最前線のモデルの誤りを指摘しています。

1 つの数字の間違いで、38 の完璧な評価

タスク作成のスケーリングのために、コーディングモデルを用いて 603 個のプログラムによる検証器を生成しました。これら 603 個すべてが、参照回答に 1.0 を付与する標準的な健全性チェックには合格しましたが、参照テストのみでは不十分です。

真の感度をテストするため、38 のタスクにおける各成果物の最も重要な数字 1 つを意図的に改ざんしました。これは、実社会で文書が無効となるような正確なエラーです。

プログラムによる検証器 38 個のうち、0 個が改ざんされた文書を失敗と判定しませんでした。

• 25 個の検証器は改ざんに全く気づかず、一律に 1.0 のスコアを付与しました。
• 13 個の検証器は項目レベルでエラーを検出しましたが、加重平均によってペナルティが薄められ、総スコアの低下幅は 0.4% から 10.7% に留まりました。

教訓

生成段階での検証者への信頼は捨てろ: 参照回答に 1.0 のスコアを与えるからといって、検証者を盲目的に信じてはいけません。重要な出力値を意図的に改変する「ミューテーションテスト」を適用し、スコアが実際に低下するかを確認してください。

ハードゲートと密な報酬の併用: 両方のシグナルをそれぞれの役割で使い分けてください。ブール型のハードゲートは、核心となる事実に対する厳格な合格・不合格判定として機能します。例えば、見出しの数値が間違っていれば、提出物全体が不合格となります。一方、個々の項目ごとの細かなスコアは、複雑で長期にわたるタスクを学習するエージェントに必要な滑らかな学習シグナルを提供します。ハードゲートが存在しない場合、加重平均によって致命的なエラーが緩衝され、重大なミスを無視できるほどのスコア低下にすり抜けてしまいます。

パイプラインの入力を検証: LLM による判断者が、損失のあるテキスト抽出ではなく、ビジョンモデルを通じて完全なビジュアルレンダリングを受け取っていることを確認してください。

ゲーム可能な評価基準と不正エージェントの分離: レワードハッキング監査では、2 つの異なる問いに答える必要があります。まず、評価基準自体がゲーム可能かどうかをチェックします。これは参照ファイルとの類似度ではなく、提出された作業そのものをゼロから再計算してスコアリングすることで判断します。次に、エージェントが実際に不正を行ったか（例：解答キーの読み取りといった軌跡証拠に基づく）を別々に確認します。前者は改善し、後者は警告し、弱い評価基準をもって不正の証拠とみなすことは決してありません。

エージェントと手動の監査パイプラインを組み合わせる：報酬ハッキングを検出するには、継続的な敵対的テストが必要です。自動化されたエージェントによる欠陥検出パイプラインと、ターゲットを絞った人的レビューを組み合わせることで、ベンチマーク構築者は、検証者が稼働する前にプロンプトの漏洩、構造に依存しないマッチング、参照エラーなどを体系的に発見できます。

信頼性の高い評価は後付けではなく、エージェント開発の基盤です。突然変異テスト済みプログラマティック検証器、視覚的に検証された判定者、そしてルールの欠陥とエージェントの不正を分離する敵対的監査を組み合わせて活用することで、コンピュータ使用型エージェントが継続して進化しても精度を保つ評価システムを構築できます。