技術的概要：OpenComputer

問題定義

コンピュータ使用エージェントの拡張は、現在、2 つの重要な課題によってボトルネックとなっています。すなわち、現実的かつ再現性のあるデスクトップ環境の構築に要する高コスト、および複雑なソフトウェア状態におけるタスク成功の検証の難しさです。従来のタスク作成には、ユーザー目標と環境初期化（例：ファイルの作成、設定の構成）の人手による設計が必要であり、これは退屈で非標準化されています。さらに、評価はしばしば「LLM をジャッジとして用いる」方法やスクリーンショットの視覚的検査に依存しており、これは基盤となるアプリケーションの状態、ファイルのメタデータ、または視覚的に明瞭でない永続的な副作用における微妙なエラーを検出できません。既存のベンチマークは主に人手でキュレーションされたもので、規模が限られており、信頼性が高く機械的に検証可能な報酬シグナルを欠くことが多々あります。

手法：OpenComputer フレームワーク

OpenComputer は、コンピュータ使用エージェント向けに検証可能なソフトウェア世界を合成するために設計された、検証器を基盤としたフレームワークです。これは、検証を下流の評価ステップとしてではなく、環境およびタスク構築を組織化する原理として扱います。このフレームワークは、4 つの密接に結合したコンポーネントで構成されます。

1. アプリケーション固有の状態検証器

OpenComputer は、サポートされる各アプリケーションがサンドボックス内で実行される合成 Python 検証器モジュールとペアリングされる検証スタックを構築します。

• 検査チャネル: 検証器は、ブラウザデバッグプロトコル（CDP）、D-Bus、SQLite ベースのプロファイルデータベース、アクセシビリティ API（AT-SPI）、および直接ファイル解析（Inkscape、VS Code、Blender など）など、利用可能な最も信頼性の高いアプリケーション固有の検査チャネルを利用します。
• エンドポイント構築: システムは、構造化された状態表面（コンテンツ、設定、履歴、メタデータ）を露出させる JSON 出力を伴う CLI サブコマンドを生成します。
• テストプロトコル: 検証器は、ヒューリスティックな一致に依存するのではなく、実際のソフトウェア状態を確実に検査できるようにするため、単体テストおよび統合テストを用いた厳格なデバッグ・修正・再試行ループを経ます。

2. 自己進化型検証層

検証器の残存エラー（例：脆いスキーマの仮定や不完全なカバレッジ）に対処するため、OpenComputer は自己進化ループを実装します。

• 較正: 強力なエージェントがサンドボックス内で、少量の容易から中程度のタスクを実行します。
• 不一致の診断: LLM 評価器とプログラムによる検証器が、最終状態に対して独立して判定を生成します。エージェントの失敗ではなく検証器のエラーに起因する不一致が特定されます。
• 洗練: このフィードバックに基づき、検証器コード、エンドポイント、またはドキュメントが洗練されます。このプロセスは、検証器が参照判定と整合するか、予算が尽きるまで反復されます。

3. タスク生成パイプライン

タスクは、検証器を認識するプロセスを通じて合成されます。

• 提案: システムは、多様性を確保するため既存の検証器に条件付けずに、現実的なユーザー目標を提案します。
• フィルタリング: 提案は、複雑性とデータ生成可能性についてフィルタリングされ、多段階ワークフローが優先されます。
• グラウンディング: タスクは検証スタックにグラウンディングされます。ある状態が検査可能だがエンドポイントが存在しない場合、新しいエンドポイントが生成されます。
• 合成: システムは、必要なファイル、設定、プロファイルを生成することでタスクを具体化し、タスクインスタンス $\tau = (x, e, c)$ を出力します。ここで、$x$ は指示、$e$ は環境初期化、$c$ は機械的に検証可能な成功基準です。

4. 評価ハーネス

ハーネスは、新鮮なデスクトップサンドボックス内でエージェントを実行し、完全なスクリーンショット・アクション軌跡を記録します。成功は、最終的なソフトウェア状態に対してタスクのチェッカーコマンドを実行することで計算されます。報酬は通過したチェックの割合（$R = N_{pass}/N_{total}$）であり、完全な機械的に検証可能な成功条件を維持しつつ、部分的なクレジットを可能にします。

主要な貢献

1. OpenComputer フレームワーク: 人手による構築なしに、現実的なソフトウェア世界、タスク記述、および検証器を自動的に生成するための検証器を基盤としたシステム。
2. 信頼性の検証: 厳密にハードコードされた検証器が、特に微細なアプリケーション状態において、LLM ジャッジによる評価よりも人間の裁定とより密接に一致することを示す実証的証拠。
3. 大規模ベンチマーク: ブラウザ、オフィスツール、クリエイティブソフトウェア、開発環境、コミュニケーションアプリにまたがる 33 のデスクトップアプリケーションと 1,000 の完成済みタスクを含むリリース。

実験結果

著者は、OpenComputer ベンチマーク上で最先端およびオープンソースのエージェントを評価しました。

• 最先端のパフォーマンス: GPT-5.4 が 68.3% の完全タスク成功率と 88.4% の平均報酬で最高のパフォーマンスを達成しました。次いで Claude-Sonnet-4.6（64.4%）および Kimi-K2.6（58.8%）が続きました。高い部分的な進捗にもかかわらず、信頼性の高いエンドツーエンドの完了は依然として困難です。
• オープンソースの格差: オープンソースモデルは、OSWorld などの既存ベンチマークで報告されたスコアと比較して、著しいパフォーマンスの低下を示しました。例えば、GUI-OWL-1.5-8B は OSWorld での 52.3% のスコアから、OpenComputer では 5.7% に低下しました。
• 効率性: GPT-5.4 が最も効率的で、タスクあたり平均 19.0 ステップでした。これは、出力において操作を組み合わせ、長い推論痕跡を回避する能力に部分的に起因します。
• 検証の整合性: 120 タスクの比較において、ハードコードされた検証器は 94.1% の頻度で人間の判定と一致し、LLM ジャッジの 79.2% と比較して優れていました。検証器は、スクリーンショットが見逃すターミナルログ、折りたたまれたパネル、および正確なファイルメタデータにおけるエラーを検出する点で特に優れていました。
• 自己進化の影響: 自己進化型検証層は、較正タスクにおけるチェッカー側のエラーの 89.4% を修正し、人間とチェッカーの合意を 85.2% から 94.1% に向上させました。

意義と主張

本論文は、OpenComputer が、現実的なソフトウェア世界と機械的に検証可能なフィードバックを結合することにより、コンピュータ使用研究の拡張のための基盤インフラを提供すると主張しています。著者は以下のように論じています。

• 検証の重要性: エージェントのためのスケーラブルな合成は、LLM ジャッジやスクリーンショットのような弱い代理評価ではなく、信頼性の高い検査と結合されなければなりません。
• 現在の限界: 最先端のエージェントでさえ、現実的なデスクトップワークフローにおけるエンドツーエンドの完了に苦労しており、堅牢なコンピュータ自動化における格差を露呈させています。
• 将来の有用性: このフレームワークは、監査可能でグラウンディングされた報酬を提供することで、評価だけでなく、SFT や RL などのトレーニングパイプラインもサポートします。それは、複雑なソフトウェア環境におけるエージェントの信頼性と失敗モードを研究するための制御された出発点として機能します。

著者は、Draw.io における空間配置など、視覚的または幾何学的な判断を必要とするタスク（プログラム的なチェックに完全に還元できないもの）に関する限界を認めています。これらのタスクは再現性を維持するために主要なベンチマークから除外されていますが、将来のハイブリッド検証研究のために公開されています。