WorkArena：LLMウェブエージェントは実社会のエンタープライズ知識労働でどのように機能するか
小売や航空業界におけるツール呼び出しエージェントのτ-bench評価を読んだ後、私はエンタープライズソフトウェアの分野、つまりBeancountスタイルのエージェントが実際に動作する必要のある領域について掘り下げてみたいと考えました。WorkArena（Drouinら、ServiceNow Research、2024年）は、ServiceNowエンタープライズプラットフォーム内の33の実際のタスクでLLMウェブエージェントをベンチマークしており、現在のモデルが人工的なトイシナリオではなく、本物の知識労働者のワークフローを自動化できるかどうかをテストする最も直接的な指標となっています。
論文について
「WorkArena: ウェブエージェントは一般的な知識労働タスクをどの程度解決できるか？」では、ServiceNowエンタープライズソフトウェアプラットフォームから抽出された33のタスクと19,912のユニークなインスタンスのベンチマークを紹介しています。タスクは、知識労働者が日常的に行う6つのカテゴリ（リストのフィルタリングとソート、フォーム入力、ナレッジベースの検索、サービスカタログからの注文、ダッシュボードの閲覧、メニューの操作）を網羅しています。ベンチマークと並行して、著者らはエージェントにHTML、アクセシビリティツリー、スクリーンショットなどの豊富なマルチモーダルな観察結果を与え、ウェブ操作のための標準化されたアクションスペースを提供する評価ハーネスであるBrowserGymをリリースしました。
この論文が投げかけている核心的な問いは、現在のLLMが、実際のエンタープライズソフトウェアが要求する構造化されたマルチステップのUI制約のあるワークフローを処理できるかどうかです。これらは自由記述形式の検索タスクや一往復のQAではなく、ライブシステム内に検証可能な痕跡を残す、クリック、フォーム入力、フィルター操作のゴール指向のシーケンスです。この「システムの状態による検証可能性」という特性こそが、WorkArenaを他の多くのエージェントベンチマークと一線を画すものにしており、まさにBeancountのライトバック（書き戻し）エージェントが満たすべき特性なのです。
主な洞察
- GPT-4oはWorkArena全体で42.7%の達成率を記録（Chain-of-Thoughtプロンプティング使用時）。対照的に、GPT-3.5-Turboはわずか6.1%にとどまり、オープンソースのLlama3-70B-Instructは17.9%でした。商用の最先端モデルとオープンソースの最先端モデルの間には25ポイントもの差があります。
- リストフィルタリングタスクは完全な壁：すべてのモデルで0%。 ServiceNowのリストウィジェットは非標準のHTMLを使用しており、テストされたエージェントのどれもが確実に対話することができませんでした。ソートも同様に悪く、GPT-4oはリストソートタスクでわずか10%しか達成できませんでした。
- サービスカタログタスクは驚くほど扱いやすい: GPT-4oは9つのサービスカタログタスクで77.8%に達しました。ここではUIがより一般的であり、必要なアクションがモデルがトレーニングで見てきたであろうフォーム入力パターンと密接に対応しているためです。
- マルチモーダルな観察はほとんど役に立たない。 GPT-4oの観察にスクリーンショットを追加しても、パフォーマンスの向上は「極めてわずか」でした。これは、ボトルネックが視覚情報の欠如ではなく、UI構造の理解にあることを示唆しています。
- Chain-of-Thought（思考の連鎖）が成否を分ける。 これを除去すると、Llama3-70Bのスコアは約10ポイント低下しました。マルチステップのウェブタスクには、単なるアクションの予測ではなく、明示的な中間推論が必要であることが確認されました。
- メモリメカニズムが裏目に出た。
use_think_historyフラグを有効にすると、エージェントは「初期のステップで決定した事項、たとえそれが誤りであっても固執する」ようになりました。これは、計画を装った硬直的なコミットメントの具体的な例です。
評価できる点と不十分な点
このベンチマークの最も価値のある特性は、実際のServiceNowインスタンスに対して実行されることです。成功は、期待される出力との文字列一致ではなく、システムの「状態」が実際に正しく変更されたかどうかで判断されます。そのため、リストフィルタリングタスクでの0%という結果は特に深刻であり、言い逃れができません。また、タスクの種類も実に代表的です。6つのカテゴリは知識労働者が時間を費やす業務の全域をカバーしており、都合の良いタスクだけを抽出したものではありません。
一方で不満が残るのは、失敗モードの扱い方です。論文では、特殊なHTML構造、ネストされたiFrame、シャドウDOMがエージェントを壊す原因であると特定していますが、どの構造的特徴がどの程度の割合で責任を負っているのかを系統的に分析（アブレーション）していません。DOMサイズの肥大化の問題（HTMLツリーが4万から50万トークンに及ぶこと）は言及されていますが、深く分析されていません。要約、チャンク化、あるいはアクセシビリティツリーのみの観察によってパフォーマンスが回復するかどうかは不明です。 また、シングルエージェント構成と、分解されたマルチエージェント構成（例えば、セレクターとエグゼキューターの分割）との比較も行われていないため、リストフィルタリングの結果がインターフェースの問題なのか、計画の問題なのか、あるいはその両方なのかが判然としません。
また、プラットフォームの妥当性についても疑問を呈する価値があります。ServiceNowは特有のUIパターンを持つ特定のエンタープライズソフトウェアスタックです。この結果はServiceNowエージェントについては多くを語っていますが、一般的なエンタープライズウェブエージェントについてはそれほど多くを語っていないかもしれません。リストフィルタリングの失敗を、例えばbeanqueryインターフェースやスプレッドシートツールに一般化するには、独立した証拠が必要です。
金融AIにとってなぜ重要なのか
WorkArenaの結果は、Beancount自動化のロードマップにおいて、私が立ち返り続ける基準点となっています。失敗のパターンは示唆に富んでいます。エージェントは、ウェブフォームのように見えるタスク（サービスカタログ、77.8%）ではうまく機能しますが、構造化された非標準のUIウィジェットとの精密な対話を必要とするタスク（リストフィルタリング、0%）では崩壊します。帳簿入力を行うBeancountエージェントは、混合的な状況に直面するでしょう。自然言語か ら取引への変換部分は、パフォーマンスが良好なフォーム入力タスクに似ていますが、クエリ、フィルタリング、照合作業（特定の項目の検索、日付によるソート、アカウントフィルターの適用）は、すべてが機能しなくなるリストタスクに酷似しています。
また、この論文はCRITICやReflexionのログから得られた教訓を再確認させてくれます。それは「内部的な推論よりも外部的な検証が重要である」ということです。WorkArenaのタスクはシステムの状態に基づいて成否が決まります。この明確なグラウンドトゥルースこそが、ベンチマークを誠実なものにしています。Beancountのライトバックエージェントにおいても、コミットされたすべての帳簿変更が、エージェント自身の推論によってチェックされるだけでなく、受け入れられる前にBeancountのPython APIに対して検証されるような設計にすることを強く支持する結果となっています。ICML 2024時点での最高モデルの天井が42.7%であることは、従来のエンタープライズUIタスクにおいてさえ、「時々役立つ」から「確実に自動化できる」までの距離が依然として大きいことを示唆しています。
次に読むべきもの
- WorkArena++ (arXiv:2407.05291, NeurIPS 2024) — 同じServiceNowチームによる後続研究。計画、算術推論、複数文書の検索を必要とする682の複合タスクが含まれており、タスクの複雑さをスケールさせることで、UI操作の壁以外に新たな失敗モ ードが現れるかどうかを直接的に解明しています。
- WebArena (arXiv:2307.13854, ICLR 2024) — 汎用ウェブエージェントのベンチマーク（eコマース、フォーラム、コードホスティング、CMSにわたる812タスク）。GPT-4の達成率がわずか14.41%（人間は78%）であることを示し、WorkArenaの数値をより広いウェブエージェントの展望の中に位置づけています。
- OSWorld (arXiv:2404.07972, NeurIPS 2024) — エンタープライズ自動化の評価を、実際のアプリケーション（LibreOffice、VS Code、Chrome）を含む完全なデスクトップコンピュータ環境に拡張。WorkArenaの失敗モードがUI固有のものなのか、あるいはより深いエージェントの能力不足を反映しているのかを検証する最も包括的なテストです。
