技術的サマリー：Workspace-Bench 1.0

問題定義

現在の AI エージェントは、孤立したタスクにおける実証能力と、現実の職場シナリオにおけるパフォーマンスの間に大きな乖離が存在する。基盤モデルやエージェントハネスはツール呼び出しや GUI 操作において進展を遂げているものの、ワークスペース学習、すなわち複雑なデジタルワークスペース内の多様なファイル間の明示的および暗黙的な依存関係を特定し、推論し、更新する能力においては苦戦している。

既存のベンチマークは、現実のオフィスワークフローを十分にシミュレートできていない。それらは通常、以下に依存している。

• プロンプト駆動型またはオープンソース駆動型のパラダイム：実際のデジタルファイルの処理を必要としないものを採用している。
• タスク・ファイル駆動型のベンチマーク：事前にパッケージ化され、孤立したファイルを提供するもので、エージェントが散らかり、階層化されたディレクトリ構造内で情報を独立して検索、フィルタリング、発見することを要求しない。
• ワークスペース関連ベンチマーク：ペルソナの多様性が欠如しており、10 種類未満のファイルモーダリティしかカバーせず、ファイル間の相乗効果を暗黙的な副産物として扱い、依存関係の特定（例：意味的関係、バージョンの系譜）を明示的に評価しない。

したがって、現実的で多様なワークスペース内の大規模なファイル依存関係に基づいてエージェントを評価するベンチマークが緊急に必要である。

手法

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

著者らは、現実的なデジタルワークスペースと文脈に根ざしたオフィスタスクをシミュレートするように設計された大規模ベンチマークWorkspace-Benchを構築した。

1. ワークスペースシミュレーション：

   • ペルソナ：オペレーションマネージャー、ロジスティクスマネージャー、AI プロダクトマネージャー、バックエンド開発者、研究者という 5 つの明確な専門職を定義した。
   • 規模：ベンチマークは20,476 ファイル（合計最大 20GB）から構成され、74 種類の異なるファイル形式（.xlsx、.pdf、.md、.java、.yaml、.eml などを含む）にまたがっている。
   • 構造：ワークスペースは、トップダウン型の 2 段階パイプラインを使用して生成された。
     • 構造生成：エージェントが、構造的ノイズ（冗長なフォルダ、曖昧な名前）を制御しながら、役割固有のディレクトリ階層を生成した。
     • コンテンツの充填：公開リソース（arXiv、GitHub など）のセマンティック駆動型エージェントクローリングと、取得データを基盤とした LLM 合成アーティファクト（メール、会議メモ、レポート）を組み合わせたハイブリッド戦略を採用した。
   • 複雑性：ファイルは深くネストされており（平均深度 3.7、最大 8）、系譜追跡をテストするために歴史的バージョンを含んでいる。

2. タスク選定：

   • ソース：388 のタスクは、現実のワークフロー（Lark/ByteDance から提供）から選定され、ドメイン専門家によって手動で注釈付けされた。
   • 依存関係グラフ：各タスクには、必須ファイルパスの最小セットとその関係（意味的、集約的、系譜的）を指定するグランドトゥルースのファイル依存関係グラフがペアになっている。
   • 難易度レベル：必要な能力の複雑さ（例：ワークスペース探索、系譜追跡、多様なファイル理解）に基づき、タスクは Easy（14%）、Medium（53%）、Hard（33%）に分類される。
   • 評価基準：最終出力の正しさだけでなく、中間的な決定、ファイルバージョンの使用、依存関係の遵守も評価するために、合計7,399 の微細な基準（タスクあたり平均 19.1）が設計された。

3. 評価フレームワーク：

   • エージェント・アズ・ア・ジャッジ：補助エージェントが、基準と依存関係グラフに対して実行軌跡を評価する。
   • 並列加速：大規模評価を処理するためのサンドボックスプールを使用した、ワークスペースレベルとタスクレベルの二重並列メカニズム。
   • 指標：基準通過率、タスク完了率（TCR@p）、依存関係グラフ認識率（ノード/エッジ F1）、トークン消費量、インタラクションターン数。
   • Workspace-Bench-Lite：迅速な評価のために分布忠実性を維持した 100 タスクのサブセットで、コストを約 70% 削減する。

実験設定

著者らは、4 つのエージェントハネス（OpenClaw、ClaudeCode、DeepAgent、Hermes）と7 つの基盤モデル（Opus-4.7、GLM-5.1、GPT-5.4、Kimi-2.5 などを含む）を組み合わせた28 の設定を評価した。また、「人間＋ツール」のベースラインを使用して、人間の専門家も評価された。

主要な結果

1. パフォーマンスの乖離：現在のエージェントは、信頼性の高いワークスペース学習からは程遠い。

   • 全設定における平均基準通過率は**47.4%**である。
   • 最高性能の設定（OpenClaw + Opus-4.7）は**68.7%**を達成する。
   • 人間専門家は**80.7%**を達成しており、自律型エージェントと人間の能力の間に大きな乖離があることを浮き彫りにしている。

2. 難易度による低下：タスクの複雑さが増すにつれて、パフォーマンスは一貫して低下する。

   • Easy タスク：57.6%
   • Medium タスク：49.2%
   • Hard タスク：40.5%

3. 能力のボトルネック：

   • 多様なファイル理解と系譜追跡が主要なボトルネックであり、エージェントはワークスペース探索と比較してこれらの次元で著しく低いパフォーマンスを示す。
   • 依存関係認識：エージェントはファイル間の依存関係を推論することに苦戦しており（エッジ F1 スコアは全体的に低い）、関連ファイルの特定（ノード F1）はできても、その関係を理解できないことが多い。

4. 効率性と精度：

   • 高いインタラクションターン数やトークン消費量は、より良いパフォーマンスを保証しない。一部の設定（例：DeepAgent + MiniMax-M2.7）は、低い成功率（約 45%）のまま「コスト爆発」（最大 58.1 ターン、0.61M トークン）に陥っている。
   • 最上位の設定（例：OpenClaw + Opus-4.7）は高い推論効率を示し、20 ターン未満で 65% 以上の精度を達成している。

5. エラー分析：失敗の大半は、フォーマットやプロセスのエラーではなく、コンテンツの欠落と推論エラー（不正確な集約、統計、関連付け）に起因している。

6. ハネスの影響：基盤モデルの能力が主要な駆動力であるが、ハネスフレームワークは特に弱いモデルにおいてパフォーマンスに大きな影響を与える。例えば、DeepAgent + GLM-5.1 は難易度レベル全体で独自の安定性を示す一方、Hermes はプロダクトマネージャーペルソナにおけるオープンドメインのセマンティックインタラクションで優れている。

意義と貢献

本論文は以下の貢献を主張している。

1. Workspace-Bench ベンチマーク：原子スキルからの評価を、複雑なワークスペース構造への推論へとシフトさせる新しいベンチマーク。明示的な依存関係注釈を備えた現実的かつ大規模な多様なファイルエコシステムを導入し、既存の文献における「ワークスペースレベル」の評価の欠如に対処する。
2. 評価フレームワーク：二重並列加速とエージェント・アズ・ア・ジャッジのパラダイムを特徴とするワークスペースに根ざしたフレームワーク。最終的な正しさ、中間推論、運用効率を網羅する 7,000 以上の基準の微細な評価を可能にする。
3. 実証的知見：最先端のエージェントが依存関係を意識したタスクで著しく苦戦していることを明らかにする包括的な評価。特定のボトルネック（多様なファイル理解、系譜追跡）と、現在の孤立ファイル処理パラダイムと現実のワークスペースの要件との間の「データ関連性ギャップ」を特定する。
4. 理論的フレームワーク：ワークスペース学習の 5 つの段階（データ非感受性実行からワークスペースネイティブ自己進化まで）の提案。このフレームワークはエージェント能力の進化を特徴づけ、「オーケストレーション・シンギュラリティ」（ハネスが LLM よりも重要になる点）や「能力シンギュラリティ」（自律的なエンドツーエンドのタスク処理）などの重要な遷移点を特定する。

著者らは結論として、基盤モデルは印象的な進歩を遂げているが、現実のデジタルワークスペースの複雑で関係的な構造をナビゲートできる真に信頼性の高い生産性エージェントの作成には、根本的かつ未探索のボトルネックが存在すると述べている。将来の研究は、エージェントハネスがどのようにファイル間の依存関係を発見し、表現し、活用するかを再考することに焦点を当てる必要がある。