OSWorld：デスクトップAIエージェントの成功率は12%、人間は72%のタスクで成功

昨日、WebArenaを読みましたが、そこでは自律型Webエージェントの成功率は約14%で、人間のベースラインである78%に及びませんでした。OSWorld（Xie et al., NeurIPS 2024）は、Ubuntu、Windows、macOSといったフルデスクトップの実際のGUIアプリケーションを対象に、同様の問いを投げかけています。その答えは、控えめに言ってもさらに厳しいものであり、失敗の形態もそれ自体が興味深いほどに異なっています。

論文について

OSWorldは、LibreOffice、Chrome、VS Code、GIMP、Thunderbird、VLC、および複数アプリケーションを跨ぐワークフローなど、実際のデスクトップアプリケーションに根ざした369のタスクでベンチマークを構築しています。各タスクにはプログラムによる評価スクリプトが付属しており、実行後の実際のシステム状態をチェックします。文字列の一致を判定するヒューリスティックや、LLMによる評価（LLM-as-judge）は使用されません。タスクが再現可能な状態から開始されるよう仮想マシンを使用しており、主要な3つのオペレーティングシステムすべてを網羅しています。

著者らは、GPT-4V、Gemini-Pro-Vision、Claude-3 Opus、Mixtral、CogAgentなど、一連の最先端モデルを、4つの入力構成（スクリーンショットのみ、アクセシビリティツリーのみ、スクリーンショットとアクセシビリティツリーの併用、および操作要素に数値ラベルをオーバーレイするSet-of-Marks（SoM））でテストしました。

主なポイント

• 人間は見慣れないタスクにおいて72.36%の確率で成功します。投稿時点での最高モデルの成功率は12.24%でした。その差は約60ポイントに達します。
• 上位モデル（GPT-4V、Gemini-Pro-Vision）のスクリーンショットのみのパフォーマンスは約5.26%〜5.80%です。つまり、構造化されたコンテキストを追加することで成功率はほぼ倍増しますが、それでも87%が失敗に終わっています。
• 複数アプリケーションを跨ぐワークフロータスクは最も難易度が高く、成功率の上限は6.57%でした。これに対し、OS/CLIタスクはテキストベースのインターフェースであるため、グラウンディングが比較的容易です。
• アクセシビリティツリーとSet-of-Marksは助けになりますが、その効果はモデルに依存します。著者らは、無関係な構造でモデルを圧倒し、混乱を招く可能性もあると報告しています。
• 論文公開後の進展は急速です。Agent S（GPT-4o、階層型メモリ）は20.58%に達し、強化学習ベースのARPOは29.9%まで押し上げました。Agent S3（Simular AI、2025年）は100ステップの設定で62.6%を記録し、人間に近づいたと主張しています。しかし、これらの成果の多くは、OSWorldが当初テストしたベースのプロンプトによるLLMではなく、より優れたグラウンディングモデルや強化学習による微調整（ファインチューニング）から得られたものです。
• 550件の失敗事例の分析によると、75%以上がマウスククリックの不正確さによるものでした。エージェントは正しく推論していても、間違ったピクセルをクリックしています。これは推論の失敗ではなく、視覚運動グラウンディング（visuomotor grounding）の失敗です。

妥当な点とそうでない点

このベンチマークの設計は非常に厳密です。134の異なる評価スクリプトを用いた実際の仮想マシン上での実行ベースの評価は、多くのエージェントベンチマークを悩ませている曖昧な判定を排除しています。これは重要な方法論的貢献であり、12.24%という数字が信頼できる理由でもあります。

より難しい問いは、12.24%が実際に何を測定しているかということです。タスクの分布は、ピクセル単位の正確なクリックが非常に重要となるGUI中心のアプリケーションに偏っています。CLIで完全に動作するか、テキストファイルを生成するBeancountエージェントであれば、LibreOfficeでスプレッドシートの書式設定を行うエージェントよりも、このベンチマークで遥かに高いパフォーマンスを発揮するでしょう。見出しの数字は、空間的な運動制御、多段階の計画、ドメイン知識といった全く異なる認知的要求をひとまとめにしており、それを単一の「エージェントはコンピューターを使えない」という主張に帰結させるのは単純化しすぎです。

「Set-of-Marksが一部のモデルを誤解させる可能性がある」という発見は興味深いですが、十分に掘り下げられていません。論文では、どのようなタスクやモデルが助けられ、どのような場合に悪影響があるのかを十分に説明せずに、分散に言及しています。これはエージェントUIを設計する実務家にとって最も重要な問いであるように思われますが、わずか1段落しか割かれていません。

また、369のタスクサンプルが実際のワークフローのロングテールをどの程度カバーしているかについても懐疑的です。タスクは研究者によって厳選されており、必然的に検証可能なタスクに偏っています。「これらの一貫性のない加盟店名をクリーンアップする」といった、真に曖昧な現実世界の会計タスクは、プログラムによる評価が難しく、過小評価されている可能性があります。

なぜこれが金融AIにとって重要なのか

「失敗の75%がグラウンディングエラーである」という発見は、Beancountがテキストレイヤーで動作するにもかかわらず、Beancountエージェントに直接関係します。「エージェントは正しく計画を立てるが、実行を誤る」という深いパターンは、エージェントが正しい仕訳を生成しながらも、間違った口座に書き込んだり、日付を書き間違えたりする元帳（レジャー）の書き戻し失敗と重なります。どちらの場合も、ボトルネックは戦略的な推論ではなく、正確な実行にあります。

複数アプリのワークフローにおけるパフォーマンス（6.57%）は、Bean Labsにとって最も冷静に受け止めるべき数字です。実際の会計ワークフローは、ほとんどの場合、銀行のCSVエクスポート、Beancountファイル、照合スプレッドシート、PDFの領収書など、複数のアプリケーションにまたがります。GUIエージェントが、厳選されたタスクでさえ複数アプリの調整に壊滅的に苦労するのであれば、インポート、レジャーの編集、レポート生成をオーケストレートする必要があるBeancountエージェントも、ピクセルクリックが関与しないCLIコンテキストであっても、構造的に同様の課題に直面することになります。

論文公開後の推移（Agent S3が62.6%）から得られる良いニュースは、これらが根本的な障壁ではないということです。より優れたグラウンディングモデルと強化学習の微調整によって解決可能です。しかし、その進歩には18ヶ月の時間と強化学習のトレーニングのための膨大な計算リソースが必要であり、それはBeancountエージェントがプロンプトを与えられた最先端モデルから期待できるデフォルトの能力ベースラインではありません。

次に読むべきもの

• AndroidWorld (Rawles et al., arXiv:2405.14573) — OSWorldをAndroidデバイスに拡張し、動的にパラメータ化されたタスクを導入。モバイル版Beancountインターフェースに関連。
• WindowsAgentArena (Bonatti et al., arXiv:2409.08264, ICLR 2025) — 150以上のタスクでOSWorldをWindowsに適応。OSに関わらずギャップが存続することを独自に検証。
• Agent S2 (Agashe et al., arXiv:2504.00906) — 汎用モデルと専門モデルを組み合わせた構成的なアーキテクチャで、最先端技術を大きく前進。Beancountの多段階プランナーを設計する前に理解しておく価値あり。