2026-08-13·無料·論文·12分で読めます

論文解説: OSReward — AIの「採点者」は信用できるか。コンピュータ操作エージェントの報酬を測り直す

PCやスマホを操作するAIエージェントの成否を判定する「VLM審判」は、実は失敗を成功と誤認する甘さバイアスを共有していた——1019本の人手検証済み軌跡でこれを暴き、30〜60倍安い公開報酬モデルOS-Shepherdで埋める論文を、前提知識ゼロから解説する。

#agents #computer-use #reward-model #vlm #llm-as-judge #paper

対象imageタスクagents

OSReward: Instituting Standardized Evaluation for Cross-Platform Computer-Use Reward Models

一次資料 — この記事の根拠

論文の発表 2026-07-30→この解説の公開 2026-08-13同月

OSReward: Instituting Standardized Evaluation for Cross-Platform Computer-Use Reward ModelsQiushi Sun, Kanzhi Cheng, Yian Wang ほか · 2026-07-30 · v2arXiv:2607.28609論文ページ·PDF

原文の要旨（Abstract）を読む

Computer-using agents (CUAs) are advancing rapidly across the digital world. A CUA trajectory records the agent's actions, states, and reasoning. Verifying whether it fulfilled the task instruction is central to CUA evaluation, data curation, and reinforcement learning. Neither human-written verifiers nor human annotators can provide such verification at scale, so the field increasingly turns to vision-language models (VLMs) as judges of CUA trajectories. But a fundamental question has long gone unexamined: are these VLM judges reliable enough? To study it systematically, we introduce OSReward, a realistic, high-quality benchmark that evaluates VLM judges on CUA trajectories. The trajectories come from diverse agent backbones executing human-verified instructions across platforms, and are then rigorously labeled with ground-truth verdicts through multi-stage human annotation. Building on it, we derive OSReward-Hard, a challenge set concentrating genuinely hard cases, and OSReward-Multi for fine-grained efficiency and alignment scoring. The most comprehensive evaluation of VLM judges to date finds even state-of-the-art models fall short of an ideal judge, sharing a systematic leniency bias that mislabels failed runs as successes. The few reliable enough to trust are too expensive to run at scale, while affordable open models trail far behind. To close this gap, we construct and release OS-Shepherd-100K, an open corpus of reasoning-annotated trajectory judgments for the CUA community. On it, we train OS-Shepherd (9B and 35B), open reward models that supply low-cost, stable, and reliable reward signals, matching commercial judges at 30-60x lower cost than the frontier. Extensive analyses further inform the design of reliable CUA reward at scale. Our code, benchmark, dataset, and model checkpoints are available at https://os-copilot.github.io/OSReward-Home/.

答案を読まずに「できました」を信じる先生

生徒が「テスト、全問できました」と言ったら、答案を見ずに満点をつける先生を想像してください。ほとんどの生徒は正直ですが、たまに「できたつもり」の生徒がいる。答案（現物）を確かめない採点は、その思い込みをそのまま成績にしてしまいます。

本稿で扱う論文 OSReward（香港大学・南京大学ほか、arXiv:2607.28609）が指摘するのは、まさにこの構図がAI開発の現場で起きている、ということです。採点される側はコンピュータ操作エージェント（CUA: Computer-Using Agent）——人間の代わりにブラウザやデスクトップ、スマホを操作してタスクをこなすAIです。そして採点する側もまたAI、画像とテキストを読める視覚言語モデル（VLM）です。論文は、この「AIがAIを採点する」仕組みの信頼性を初めて体系的に測り、採点者たちが揃って「失敗を成功と誤認する」癖を持つことを示しました（§4.3）。

前提ゼロから: 軌跡と報酬信号とは何か

CUAは「経費精算の画面を開いて、先月分を提出して」のような指示を受け、画面を見てクリックや入力を繰り返します。この実行記録——各ステップのスクリーンショット（状態）、エージェントの思考、実行した操作——を並べたものを軌跡（trajectory）と呼びます（§1）。

軌跡が「本当に指示を達成したか」の判定は、CUA開発のあらゆる場面で必要になります。性能評価はもちろん、学習データの選別（良い軌跡だけ集める）、そして強化学習。強化学習では判定結果がそのまま報酬信号——「その行動を強化するか否か」の教師——になるので、判定を間違えると間違った行動を強化してしまう（§6.2）。判定器のことを報酬モデル（reward model）とも呼びます。

問題は規模です。人間が書いた検証プログラムは決められたタスクにしか使えず、環境が残っていない過去の軌跡には適用できない。人手アノテーションは量が追いつかない。そこで実務ではVLMに軌跡を読ませて成否を判定させる VLM-as-a-Judge（VLM審判） が事実上の標準になりました（§1）。ところがこの審判自体の信頼性は、ほぼ検証されないまま使われてきた。論文の予備調査では、最良のVLM審判でさえ、既存ベンチマーク付属の検証器とデスクトップの判定の約4分の1で食い違うことが分かっています（§1）。

審判を測るためのベンチマークを、ゼロから作る

審判を測るには「正解の判定」が付いた軌跡集が要ります。既存ベンチマークの軌跡を再利用すると、軌跡自体の品質問題や検証器のノイズが混ざり、誤りが審判のせいか素材のせいか切り分けられません（§3）。そこで著者らは収集基盤ごと自作しました。

環境（§3.1）: Web（実サイト）、Windows、Ubuntu、Android の4プラットフォーム。デスクトップには実ユーザー並みのアプリ約20〜30本を入れ、ユーザープロファイル・編集対象の実ファイル・紛らわしい囮コンテンツまで初期化する。「完了を語るだけでなく環境を実際に変えないと成功にならない」状態を作るためです。
指示文（§3.2）: アノテータが環境を実際に触ってから作文し、作者以外による相互チェックで曖昧・実行不能なものを除去。約1500候補から約800本が生き残ります。
正解ラベル（§3.3）: 各軌跡を3人が独立に判定し、割れたものは上級レビュア2人の合議（メタレビュー）へ。ここまでで約800人時。判定基準は意図的に厳しく、エージェントが環境から確かめていない答えは、偶然正しくても失敗と数えます。

こうして1019本の人手検証済み軌跡（成功43%／失敗57%、最長100ステップ）が完成しました（§3.4）。さらに2つの派生セットを切り出します。アノテータ自身の判定が割れた難物を再検証して集めたOSReward-Hard（284本、成功30%／失敗70%）と、成功軌跡440本に「意図への忠実さ（alignment）」「無駄のなさ（efficiency）」の細粒度ラベルを重ねたOSReward-Multiです（§3.4）。

FIG 1横軸を軌跡のステップ数と読み替えてください。ステップが増えるほど「途中のどこかで失敗した可能性」の置き場所は増え、最後の数枚のスクリーンショットだけでは確認しきれなくなります。論文でも失敗軌跡は成功軌跡より明確に長い（§3.4）

発見1: 精度の天井——合格ラインに届くのは最前線だけ

27種のVLMを同一条件で審判にかけます。プロトコルは共通で、軌跡の末尾5枚のスクリーンショット＋全ステップの思考・操作テキストを読ませて成功/失敗を出させる（§4.1）。指標は正解率に加えて、成功軌跡を正しく成功と言えた割合 $\mathrm{sRec}$ （低いと厳しすぎ）、失敗軌跡を正しく失敗と言えた割合 $\mathrm{fRec}$ （低いと甘すぎ）、そしてその平均です。

\mathrm{BalAcc} = \frac{\mathrm{sRec} + \mathrm{fRec}}{2}

(1)

つまり $\mathrm{BalAcc}$ （バランス精度）は、2つの率を足して2で割っただけのものです。 $\mathrm{sRec}$ は「成功を成功と言えた率」、 $\mathrm{fRec}$ は「失敗を失敗と言えた率」。両者を必ず同じ重みで扱うので、成功と失敗の比率が43対57に偏っていても、片側だけ当てて稼ぐことができません（§4.1）。

結果、報酬モデルの実用ライン（論文は約90%を作業基準とする）に近づくのは最前線モデルだけでした。Claude-Opus-4-8が89.7%で最高、GPT-5.5とClaude-Opus-4-6が89.5%で続き、小型のオープンVLMまで約20ポイントの開きがあります（§4.2, Table 1）。

発見2: 審判は揃って「甘い」——支配的な誤りは偽成功の見逃し

もっと重要なのは誤りの向きです。各審判を（fRec, sRec）平面に置くと、大きな「甘いクラスタ」——ほぼ何でも成功と認め、失敗を捕まえられない一群——が現れます（§4.3）。誤答を分類すると、「未完了タスクの過剰受理」だけで全誤りの3分の2。しかもこれは特定モデルの癖ではなく、27審判すべてで最大の誤りモード（どの審判でも自身の誤りの48%以上）でした。過剰受理と過剰拒否の比は全体で3対1です（§4.3）。

典型例が偽成功（false success）——エージェントが「完了しました」と宣言しつつ実際には失敗している軌跡です。難問セットOSReward-Hardはこの手の軌跡を凝縮しており、ここで審判は総崩れします。最良のClaude-Opus-4-8でも69.7%まで20ポイント落ち、これは30/70の比率なら「常に失敗と答えるだけの機械」と同じ正解率。平均的な審判は52%、つまりコイン投げに毛が生えた程度です（§4.4）。プラットフォーム別ではWindowsが最難でモバイルが最易、失敗の種類では画面を読まないと分からない知覚・操作ミスの見逃しが、テキストに現れる計画ミスより顕著に難しい（§4.4）。

なぜ甘いのか: 審判は画面ではなく「自己申告」を読んでいた

論文は入力を1要素ずつ削って検証します。スクリーンショットを5枚から3枚に減らしても、クリック位置の赤マーカーを消しても、正解率は0.5ポイントも動きません。枚数を1〜16枚まで振っても傾向なし（§5.1）。ところがステップごとの思考・操作テキストを落とすと平均7.2ポイント低下し、判定の22.7%が反転——視覚側のどの変更よりも3倍大きい影響です（§5.2）。

つまり審判は、画面（証拠）よりエージェントのテキスト（自己申告）に体重をかけて判定している。自信満々の「完了しました」に釣られる構造そのものであり、これが甘さバイアスの機構だと論文は結論します（§5.2）。冒頭の比喩に戻れば、答案ではなく生徒の申告を読んで採点していたわけです。

では走らせ方の工夫で直るか。思考モードを強めても、強い審判ほど伸びは小さい（最弱で+2.8pt、最強で+0.4pt）。複数審判の多数決も効きません——審判同士は同じ難物で同じ間違いをするため（上位審判間の一致度κ≈0.71）、上位3体の多数決は最良単体を約1ポイント上回るだけで、コストは数倍（§5.3）。一方で「どれか1体でも正解していれば拾える」理想上限は99%。正解はプールの中にあるのに、多数決では誰を信じるべきか選べないのです（§5.3）。

FIG 2温度を上げると出力分布が平らになり、確率が拮抗した選択肢が入れ替わりやすくなります。論文でも温度0.7で同じ軌跡を再判定するだけで6〜9%の判定が反転（§5.3）。集計精度は安定でも、報酬として1本ずつ消費される個々のラベルは、この揺らぎをそのまま被ります

コストの壁と、OS-Shepherdという答え

信頼できる審判は高い。全1019本の判定にClaude-Opus-4-8は約 $100、GPT-5.5は$ 45かかり、 $3未満の審判はHardで57%以下に沈みます（§5.4）。強化学習ではこれが致命傷で、論文の試算では控えめな1回のRL実行（200更新×バッチ16×ロールアウト16）だけで51,200回の判定が必要——Opusなら約$ 4,000です（§6.3）。

そこで著者らは審判を自作します。まず学習データ。人手ラベルは規模的に不可能なので、「多様な強い審判が独立に同じ判定に達した軌跡だけ採用する」一致度フィルタで自動ラベリングしました（§6.1）。多数決が効かないなら、割れた事例ごと捨てればよい——ベンチマークと違い、学習データは捨てる自由がある、という発想の転換です。こうして5モデル族のエージェントによる軌跡から、判定理由のテキスト付き約10万件のコーパスOS-Shepherd-100Kを構築し公開しました（§6.1）。

学習は2段階です（§6.2）。まずSFT（教師あり微調整）で96.6K件から判定を模倣させ、ベースモデルのほぼ全面的な甘さを矯正する。次に残った急所——偽成功——だけを狙い、SFTモデルが「貪欲デコードでは間違えるが、サンプリングでは正解できる」約3.1K件を採掘してGRPOで強化学習します。結果のOS-Shepherd-9Bは全体86.1%・Hard 60.2%で、素のQwen3.5-9B（76.7%・39.4%）から大幅に改善。特にHardの失敗検出率は14.1%→57.6%です（Table 4）。判定コストは全セットで$1.36——最前線比30〜60分の1で、同価格帯の商用審判を上回ります（§6.3）。興味深いことに35B版でもHardのBalAccが+2.4ptにとどまり、効いているのはサイズではなくレシピでした（§6.3）。

汎化も確認されています。学習に一切使っていないOSWorld・AndroidWorld・WebArenaの3ベンチマークで、OS-Shepherdは前者2つで最良のオープン審判となり、約44倍のサイズのQwen3.5-397Bを3つすべてで上回りました。転移しているのは知識ではなく「失敗を捕まえる」脱バイアスそのものです（§7.2）。

論文の限界

誇張せずに読むべき点も明確です。第一に、OS-Shepherdは最前線の精度には届いていません（Hard 60.2% vs Opusの69.7%）。第二に、成功の質を測る細粒度採点（alignment/efficiency）は審判全体の弱点で、OS-Shepherd-9Bは定数ベースライン近傍にとどまります（§4.5, §6.3）。第三に、学習コーパスのラベルは人手ではなく審判アンサンブル由来なので、審判たちが揃って間違える種類の誤りは原理的に混入しえます（§6.1）。また外部ベンチマークとの比較は「その検証器との一致率」であり、検証器自体の不完全さを含みます（§7.1）。arXiv上のコメントも「Work in progress」であり、モデルサイズの追加などは今後とされています（Appendix A）。

現場ではこう使う

エージェント開発でLLM/VLM審判を報酬や品質ゲートに使うすべての人に、この論文はそのまま設計チェックリストとして機能します。

RLや軌跡フィルタの報酬モデルを選ぶ人: 全体正解率ではなくfRec（失敗検出率）を見る。論文の主要な教訓は「集計精度は良いのに、報酬として致命的な審判」が存在することです。自前データで偽成功——完了を自称して失敗している軌跡——を数十本作り、そこでの検出率を測ってから採用してください。
審判プロンプトを書く人: 入力から削ってよいのはマーカーや余分なスクリーンショット、削ってはいけないのはステップごとの操作テキストです（§5.2の推奨: テキスト履歴は全部残す、マーカーは落とす、枚数はモデルごとに5〜9で調整）。逆に、エージェントの自己申告文を審判が過信する構造は常に疑うこと。
学習データを自動ラベリングする人: 多数決ではなく高一致フィルタ＋割れたら捨てる。判定が割れる軌跡を無理に多数決でラベル付けすると、審判共通のバイアスがデータに焼き付きます（§6.1）。
事故になる落とし穴: 判定を温度サンプリングで1回だけ取ると、個々のラベルは6〜9%の確率で再現しません（§5.3）。評価集計なら誤差で済みますが、報酬として1本ずつ消費するパイプラインでは実害になります。貪欲デコード固定か、複数回の一致確認を。

LLMエージェント入門 — エージェントの基本ループと、なぜ検証が要るのか
指示チューニングとRLHF — 報酬モデルという概念の出発点
論文解説: LongHorizon-Harness — 「自己申告を信じない」設計をハーネス側で実装した論文