技術的概要：SaaS-Bench

問題定義

コンピュータ利用エージェント（CUA）は、受動的なテキスト生成器から、グラフィカルユーザーインターフェース（GUI）やウェブブラウザと対話可能な能動的な実行主体へと進化しました。しかし、これらのエージェントを評価する既存のベンチマークには、現実世界の能力を体系的に過大評価させる 3 つの決定的な限界が存在します：

1. アプリケーションの複雑性の不足：多くのベンチマークは、本番環境のソフトウェアが持つ完全なフロントエンド・バックエンドのロジック、動的な状態依存関係、およびビジネス制約を欠く、簡略化された静的または合成されたウェブ環境に依存しています。
2. 孤立したワークフロー：タスクは往々にして単一のアプリケーションに限定され、かつ短期間のものであり、専門的な業務に内在するアプリケーション間での調整、ドメイン固有の知識、および構造化された多段階プロセスを捉えきれていません。
3. 短期依存関係：既存のタスクは、エージェントの計画、状態追跡、および時間経過に伴うエラー回復能力をテストするために必要な、長期の相互作用シーケンス（多くの場合 100 ステップを超える）をほとんど必要としません。

その結果、CUA が現実的で高付加価値の Software-as-a-Service（SaaS）環境で効果的に動作するかどうかを判断するための厳格な評価フレームワークが不足しています。

手法

ベンチマーク構築（SaaS-Bench）

著者は、現実的で展開可能な SaaS 環境における CUA を評価するために設計されたベンチマーク「SaaS-Bench」を導入します。構築プロセスは以下の 3 つの中核原則に準拠しています：

1. 現実的かつ展開可能な環境：

   • このベンチマークは、玩具的なウェブサイトではなく、23 の実在するオープンソース SaaS システム（OpenEMR、OnlyOffice、BigCapital など）に基づいて構築されています。
   • これらのシステムは Docker によってコンテナ化されており、完全なフロントエンド・バックエンドのロジック、永続的なデータベース状態、およびユーザー認証を確保しています。
   • 再現性を確保し、状態の汚染を防ぐため、各タスクの前に環境は定義済みの初期状態にリセットされます。
   • データは、LLM によって生成された現実的なデータとインポートされたオープンソースデータセットの組み合わせを用いて意味的に充填され、意味のあるビジネスコンテキストを確保しています。

2. 専門的、アプリケーション間、およびマルチモーダルなワークフロー：

   • タスクは、6 つの専門分野（ソフトウェアエンジニアリング、ビジネスオペレーション、医療管理、チームコラボレーション、農業、メディア制作）にまたがって組織化されています。
   • このベンチマークには、現実世界のワークフローに基づいた106 のタスクが含まれています。
   • **タスクの 93.4%**が少なくとも 2 つのアプリケーションを関与させ、50% は 3 つのアプリケーション間での調整を必要とします。
   • セットには74 のテキストのみのタスクと32 のマルチモーダルタスク（画像、ドキュメント、またはメディアを伴うもの）が含まれており、主に農業およびメディア分野に集中しています。

3. 長期実行：

   • タスクは、平均して100 以上の相互作用ステップを持つように設計されています。
   • 4 段階のパイプライン（タスクシード $\rightarrow$ 合成ループ $\rightarrow$ 静的チェック $\rightarrow$ 実行チェック）により、タスクが専門的、実行可能、かつ検証可能であることを保証します。これには、LLM が候補を生成し、人間専門家が曖昧さ、完全性、および検証可能性についてレビューする反復的な「ビルダー・チャレンジャー・リファイナー」ループが含まれます。

評価プロトコル

• 実行フレームワーク：エージェントは、browser-use フレームワークを使用して、ブラウザベースの UI 操作（ナビゲーション、クリック、入力）を通じてのみ相互作用します。データベース、API、またはファイルシステムへの直接アクセスは禁止されています。
• 検証：各タスクは、重み付けされた検証チェックポイントに分解されます。3 つの検証手法が採用されます：
  • 状態チェック：客観的なシステム状態（DB レコード、API 応答）を検証します。
  • コンテンツチェック：文字列マッチングを介してテキスト出力を検証します。
  • LLM 判定：レポートの品質などのオープンエンドな出力を評価します。
• 指標：
  • 解決スコア（Resolved Score）：バイナリ（1 または 0）；すべてのチェックポイントが合格した場合のみ 1 となります。
  • チェックポイントスコア：進捗を反映する重み付けされた部分スコアであり、長期タスクにおける中間的な成功の測定を可能にします。

主要な結果

パフォーマンス概観

7 つの最先端モデル（Claude Opus 4.6、GPT-5.4 High、Qwen 3.6 Plus などを含む）を用いて実験が行われました。結果は、現在のエージェントが現実的な SaaS ワークフローで著しく苦労していることを示しています：

• 低いエンドツーエンド完了率：最も強力なモデルであるClaude Opus 4.6でさえ、**解決スコアはわずか 1.9%**であり（エンドツーエンドで完了したタスクは 4% 未満）、達成されました。
• チェックポイントスコア：最良のモデルの全体的なチェックポイントスコアは**43.2%**でした。これは、エージェントが中間ステップを完了できることが多い一方で、ワークフロー全体を完了するために一貫性を維持できないことを示しています。
• ドメインによる変動：パフォーマンスはドメインによって異なり、「チームワーク」のタスクは一般的に「ビジネス」および「医療」のタスクよりも容易でした。後者はより厳格な数値制約とドメイン固有の手順を伴います。

失敗モードの分析

論文は、低い解決スコアを説明する 4 つの根本的な失敗モードを特定しています：

1. 長期完了の脆弱性：成功確率の乗法的性質（$p^N$）により、高いチェックポイントごとの精度（例：95%）であっても、10〜20 のチェックポイントを有するタスクでは、解決スコアはほぼゼロになります。
2. アプリケーション間ワークフローにおけるエラーの連鎖：単一の意味論的エラー（例：顧客を「会社」ではなく「個人」と誤分類すること）は、依存関係チェーンを通じて静かに伝播し、エージェントがタスクが完了したと信じている場合でも、下流のチェックを失敗させます。
3. 信頼性の低い自己検証：エージェントは、修正後に自身の行動を再検証することに失敗することがよくあります。エラーを認識し、修正を試み、修正が成功したことを確認せずに次のサブタスクに進むことで、「静かな」失敗を引き起こします。
4. 高い実行間変動：パフォーマンスは非常に不安定です。同じモデルが、同じタスクにおいてある実行では 0.80 のスコアを達成し、別の実行では 0.10 のスコアしか達成しないことがあります。これは、単一実行の指標（pass@1）に依存する現在の評価が誤解を招くことを示唆しており、pass@k指標は、エージェントが時折成功する経路を見つけることはできても、一貫性が大きな課題であることを明らかにします。

意義と主張

本論文は、SaaS-Benchが、専門的、アプリケーション間、長期の環境における CUA を評価するための最初の厳格で現実的なテストベッドを提供すると主張しています。その意義は以下の点にあります：

• 能力ギャップの露呈：LLM の進歩にもかかわらず、現在のエージェントは現実世界の SaaS 環境における専門的なワークフローを信頼性を持って解決する能力をまだ有しておらず、エンドツーエンドで完了するタスクは 4% 未満であることを実証しています。
• 評価基準の再定義：短期・単一アプリケーションのベンチマークでは不十分であると主張しています。分野は、エージェントが状態を維持し、エラーから回復し、長いシーケンスにわたって複数のシステム間で調整する能力を評価する方向へシフトする必要があります。
• 構造的限界の特定：結果は、主なボトルネックが知識検索だけでなく、計画、状態追跡、およびエラー回復にあることを浮き彫りにしています。論文は、現在のエージェントアーキテクチャが、長期タスクの脆弱性を処理するために必要な閉ループ検証メカニズムを欠いていることを示唆しています。

著者らは結論として、SaaS-Bench は重大な限界を明らかにしていますが、より信頼性が高く、実用的に展開可能なコンピュータ利用エージェントに関する将来の研究にとって必要な基盤となると述べています。