# OSWorld-Human: Benchmarking the Efficiency of Computer-Use Agents > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 2 (May 19 / Tue)、"Research Track Oral: Agentic AI 1 & Multimodal/Generative Models" セッション（13:00 - 13:15 PDT、第1発表） > - **URL:** https://mlsys.org/virtual/2026/oral/3865 （arXiv: https://arxiv.org/abs/2506.16042 ） > - **著者（論文表紙）:** Reyna Abhyankar\* (UC San Diego)、Qi Qi\* (UC San Diego)、Yiying Zhang (UC San Diego / GenseeAI, Inc.)。\* は equal contribution。Correspondence: [email protected], [email protected], [email protected] > - **登壇者:** UCSD の大学院生の一人（"done by a few grad students at UCSD, including myself"）。本人が明示的に名乗っていないため、Abhyankar か Qi のいずれかと推定（確証なし） > - **所属ロゴ（スライド表紙）:** together.ai、WukLab（UCSD の Yiying Zhang のラボ） > - **関連研究:** GitHub `https://github.com/WukLab/osworld-human`、ブログ `https://www.bytebot.ai/blog/the-age-of-the-desktop-agent-is-here` > - **会議情報（論文末尾）:** Proceedings of the 9th MLSys Conference, Bellevue, WA, USA, 2026 > [!abstract] 概要（論文 PDF アブストラクト） > 生成 AI はデスクトップアプリケーションを伴う多様な computer-use タスクを解くために活用されている。SOTA システムは主要ベンチマーク上での**精度の向上のみ**に注力してきた。しかしこれらのシステムは、人間ならわずか数分で終わるタスクに対して end-to-end レイテンシが極端に高く（例: 数十分）、実用上ほとんど使い物にならない。この背景にある原因を理解し将来の computer-use agent 開発を導くため、我々は computer-use AI の旗艦ベンチマークである OSWorld 上で、computer-use agent の**時間的性能（temporal performance）に関する初の研究**を行う。我々は、planning・reflection・judging のための large model 呼び出しが全体レイテンシの大半を占め、エージェントがタスク完了により多くのステップを使うにつれ、各後続ステップがタスク開始時のステップより最大 **3x 長くなりうる**ことを見出した。次に、各タスクについて人間が決めた軌跡を含む OSWorld の手動アノテーション版 **OSWorld-Human** を構築する。OSWorld-Human を用いて 16 個のエージェントの効率を評価した結果、最良のエージェントでさえ必要なステップ数の **2.7〜4.3x** 多くのステップを要することが分かった。 ## 問題設定: Computer-Use Agent（CUA）とは - CUA は典型的な日常デスクトップタスク（文書・スプレッドシート操作、プレゼン作成、メディアプレイヤー操作など）を自律実行するエージェント。スライドの例タスクは "Highlight and underline the first sentence of each paragraph"。 - ライフサイクル（スライド "Computer-Use Agent (CUA) Lifecycle"）: (1) デスクトップのスクリーンショット取得 → (2) LLM がアクションを出力 → (3) PyAutoGUI 様のインターフェースでマウス/キーボードを制御して環境内で実行 → これをエージェントが "DONE" と判断するまで **xN のループ**で繰り返す。 - CUA の知覚は主に 3 様式（論文 §2.2）: screenshots、accessibility（A11y）trees、Set-of-Marks（SoM）。 ## OSWorld ベンチマークとエージェント構成 - **OSWorld（2024、香港大学）:** 9 アプリケーション横断の **369 タスク**から成る（スライドのドメイン: Chromium、LibreOffice Suite、VSCode、GIMP、VLC、Thunderbird、Terminal。ドメイン分布は Office 31.7%、Workflow 27.4%、Daily 21.1%、Professional 13.3%、OS 6.5%）。当時の最良モデル **GPT-4 は約 12%**（スライド表記 **12.2%**）。 - 文字起こしの "University of Hong Kong" / "2024" はスライドの "2024 OSWorld Benchmark" と整合。 - **Agent S2（スライド "More Complex Agents: Agent S2"、最大 50 ステップ）:** 各ステップで (a) 類似タスクを探す retrieval database step、(b) 直前ステップ出力の正否を比較する reflection LLM step、(c) 次手を決める planning LLM、(d) アクションを実座標に落とす小型 grounding model を持つ。スライド右上の OSWorld スコアは **41.4%**。 - **GTA1（スライド "More Complex Agents: GTA-1"、最大 100 ステップ）:** 類似構成だが planning LLM を**並列にスポーン**し、それらの判断を judging で集約。grounding は小型モデルが担当。スライド右上の OSWorld スコアは **48.6%**。 - これらに対し、研究の関心は correctness だけでなく **cost・latency・failure modes を含む効率**。 ## 効率の分析: レイテンシ・トークン・コストの蓄積 - **タスクは数分〜数十分かかる。** 文字起こしによれば、ある terminal manipulation タスクで S2 と GTA1 がそれぞれ 40 分・80 分を要した（論文では同タスクで S2 が 50 ステップ・end-to-end 40 分超、GTA1 が 54 ステップで S2 のほぼ 2 倍、と記載。スライド timeline は S2 が約 2500s、GTA1 が約 4500s）。 - **レイテンシの大半は LLM 呼び出し。** スライド "Breakdown by Stage"（論文 Table 1）の time breakdown: - **S2:** Planning 53.47±3.18%、Reflection 33.56±7.77%、Grounding 3.91±0.83%、Retrieval 3.08±2.14%、Action 1.61±0.35%、Screenshot 1.72±0.73%。LLM（planning+reflection）で **76%**。 - **GTA1:** Planning 74.59±2.55%、Judging 22.53±2.85%、Grounding 1.82±0.84%、Action 0.7±0.36%、Screenshot 0.36±0.35%。LLM（planning+judging）で **約 96%**（論文では両者で 91〜96%）。 - **プロンプトトークンと per-step レイテンシ:** スライド "Breakdown by Stage" の bullet —「p50 は **10–15k uncached prompt tokens**」「これが **per-step 20–30 秒**に相当」「Planning は Reflection/Judging より多くの prompt token を消費」。 - **ステップ数とともにコスト/レイテンシが増大（蓄積）:** スライド "Prompt Tokens Accumulate!"（論文 Figure 3/4）。各ステップの prompt が全履歴を含むため、後半ステップほど prompt token とレイテンシが増える。赤線（文字起こし）はステップ 45–50（S2）/ 95–100（GTA1）のテール。 - **ドル建てコストは quadratic に増大:** スライド "Cost ($) Accumulates Too!"（論文 Figure 6、GTA1 の VS Code タスク）。Planning の accumulated cost はステップ 100 までに **約 \$8**（文字起こし「by step 100, about \$8 over the entire task, just doing planning」。論文の同例: \$8.47、27 分）。Judging の accumulated cost は同図で約 \$1.5。 - 補足（論文 Table 3、TogetherAI 課金）: GTA1 の 1 タスク平均コストは **\$2.43**（planning 87%、judging 13%、grounding 1% 未満）。GTA1 の planner は毎ステップ o3 へ 4 並列呼び出し、無効プランなら最大 3 回リトライ。 ## 失敗モード分析: ループ - スライド "Failure Analysis: Looping"（論文 §3.4）の例: blue folder（"Kernels"）。reflection が "Wrong click location"、planning が "Open the blue folder."（正しい計画）と出すが、grounding が毎回誤座標（CLICK(20, 25)）を出力して**ループに陥る**。 - 論文の対応例: VS Code でフォルダを開く単一アクションが grounding 失敗で 100 ステップを要して失敗。planner は "Click the blue 'Open' button" と正しく指示するが grounding が座標を生成できず、tab bar 周辺をクリックし続けた。このループは \$8.47・27 分を浪費し 18 ステップ後に放棄。 - **定量:** スライド「For tasks that fail in 50+ steps, **66% of steps are wasted on looping**」（文字起こしの "two thirds" と整合。論文の loop 検出基準: 連続ステップ間で planner 生成テキスト類似・action text 類似・座標 50px クラスタ・スクリーンショット perceptual hash 5% 以内のうち 2 つ以上一致。エージェントは 54% のケースでループから回復、37% は方針放棄、9% はステップ上限到達）。 - 論文補足: grounding 失敗を考慮し Table 1 を補正すると planning 75%→67%、judging 23%→21%、grounding 2%→12%。 - **既存ベンチマークはこれを捉えない**（スライド "None of this is captured by existing benchmarks — So we built one."）。 ## OSWorld-Human ベンチ設計とスコア式（WES） - **構築:** UCSD の数名の大学院生（発表者含む）が **全 369 タスク**を手動で実施し全ステップを記録、各エージェントを weighted efficiency metric で再採点。OSWorld と同じ 369 examples を含む。データセットは CS 大学院生 2 名による 2 パスで構築・相互 cross-validate、OSWorld VM 上で手動実行して成功スコアを取得（論文 §4.1）。 - **オープンソース・統合容易性:** スライド "OSWorld-Human"（QR コード、`https://github.com/WukLab/osworld-human`）。既存の OSWorld の出力軌跡（checkpoint 済み）の末尾に scoring script を足すだけで効率重み付きスコアが得られる。実行例（スライド）: `python score.py --result-path /x/y/z --max-steps-scoring 50`。「Agent vendor runs OS-World → result folder: 41.4% → WES: **15.6%**」。 - **スコア式の段階的構成（スライド "Scoring Efficiency" 群、論文 §5.1）:** - ベースの OSWorld 採点は**ほぼ binary**（task 成功=1 / 失敗=0）。 - 第1項 **Weighted reward**: reward に `human steps / agent steps`（= t_human / t_agent）を掛け、成功タスクの速さを重み付け。 - 第2項 **Global penalty**: `(1 − avg steps in failures / max steps)`（= 1 − t̄_fail / S）。失敗タスクで浪費したステップを罰する乗数（0〜1）。失敗に長くかかるほどペナルティが大きい。 - **Weighted Efficiency Score（WES、論文の式）:** $\text{WES} = \frac{1}{n}\sum_{t}^{n} r_t \cdot \frac{t_{human}}{t_{agent}} \cdot \left(1 - \frac{\bar{t}_{fail}}{S}\right)$ （左半分 = weighted reward = WES⁺、右半分 = global penalty multiplier。S は各エージェントの最大許容ステップ。論文では S はエージェントごとに異なる値を使うのが最も公平とする） - **結果（スライド "Stacking up against OSWorld"、論文 Table 5）:** 相対順位は保存されるが絶対性能が大幅低下。**最良エージェント（Agent S2 w/ Gemini 2.5）は 41.4% → single-action WES で 15.6% に低下**（dotted line は 1:1 マッピング）。 ## グループドアクション（より難しい版） - 多くのステップは追加の LLM round-trip を要しない。スライド例 "Grouped Actions": geology report を白黒印刷するタスクでは、print dialog の単一スクリーンショットに必要情報が全て含まれる。planner は「black & white チェックボックスをクリック → print をクリック」を一度に提示できるが、系が serial なため print のために余分な round-trip が必要。→ これらアクションを**グループ化**できる（CLICK(19,90) と CLICK(20,01) を 1 ステップに）。 - スプレッドシート例（スライド、論文 Table 4 由来）: single-action で **11 ステップ**だが、視覚刺激はアクション 1–6 と 7–11 で同一 → 現実には **2 ステップ**で可能。 - 論文 §4.2 / Table 4: single-action 軌跡と grouped-action 軌跡を全タスクに用意。grouped は single 以下のステップ数（例 LibreOffice Calc 13.2→4.5、GIMP 2.8→2.0）。 - **結果:** 相対順位は OSWorld・single-action 版と同じく保存されるが絶対性能はさらに低下。**Agent S2 は single-action WES 約 15% → grouped-action WES 9.6%**（スライド "15.6% -> 9.6%"、論文 Table 5）。 - **総括:** 性能は **41.4% → 約 9.6%** に低下。これは「これらエージェントが必要なステップ数の **2.7〜4.3x** 多くのステップを踏んでいる」と解釈できる。 ## 改善策（plug-and-play） スライド "Conclusion" / 論文 §5.3。OSWorld と plug-and-play で使える方向性: 1. **Action grouping（action batching）:** アクションをまとめて 1 round-trip で複数ステップを実行。 2. **Efficient / Reversible Rollback:** 可逆なアクション集合を保存し、ループに陥る代わりにエラーのない checkpoint 状態へ戻る。 3. **Grounding model post-training:** 小アイコン・スクロールバー等に強い grounding を後段学習。image segmentation 等の伝統的 CV を借用。 4. **History compression:** 軌跡の sink（重要部分）を保ちつつ履歴を圧縮（sliding window 等）。 5. **Improvements in LLM serving:** より賢い prefix cache hit / cache eviction policy、speculative decoding、プロバイダ既存の KV cache 活用。 ## 結論 - OSWorld-Human は効率**と**有効性の双方を測るベンチマーク（スライド "Conclusion"）。 - OSWorld の相対順位を保存しつつ、性能は **41.4% → 9.6%** に低下。最良エージェントでも必要の **2.7–4.3x** のステップを踏む。 - next steps: 「benchmark your latest agents!」（オープンソース、`https://github.com/WukLab/osworld-human`）。 ## Q&A - **Q1（聴衆、OSWorld 使用経験あり）:** マルチモーダルモデルを使うとき、画面のスクリーンショットを 2 秒ごと（ハードコード）に取得している。小型モデルでショットあたり約 2–3 秒、大型モデルで 5–10 秒かかり非常に非効率。数秒ごとに撮るのではなく、モデル推論をトリガーして撮る方法はないか。 - **A:** スクリーンショット取得自体の所要時間を計測したところ、LLM に費やす時間に比べると極めて小さかった。〔フォローアップで質問が「一定間隔での撮影 vs 軌跡直後の撮影」だと明確化〕より少ないスクリーンショットを送る賢い方法はある。例えば 2 枚のスクリーンショットの **perceptual hash を比較**し、十分似ていれば新規スクリーンショットを送らない。履歴も同様に圧縮できる。 - **Q2（聴衆）:** computer-use agent で、ターミナルで操作させるだけでなく、本当に画面の vision/可視性をモデルに与える必要があるのか。vision は computer-usage シナリオでタスク完了を本当に助けるのか。 - **A:** terminal manipulation ドメインの多くのタスクではスクリーンショットは不要で、各アプリへの API ベースアクセスで概ね済む。しかしデスクトップ上の大多数のアプリ（例: PowerPoint）にはそうした API がまだ存在せず、何が起きているかの視覚的表現が必要。vision なしでやるのは非常に難しい。 - **〔聴衆フォロー〕** PowerPoint を改変して座標を提供させることもできる。 - **A:** 確かに可能だが、それはアプリケーション提供側の責務になる。