AI-Papers
- 画面のスクリーンショットではなくファイルやDOMなどのプログラム状態を直接扱い、GUI操作は全体の約1%のサブゴールだけに絞る新しいPC操作エージェント
- OSWorld 2.0でClaude Opus 4.8の完全成功率を20.6%から26.9%へ、部分成功を54.8%から61.6%へ改善し、タスク当たりコストを約9分の1に削減
- 作業完了を独立に判定する完了ゲートと数百ステップにわたり計画を保持するコンテキスト管理により、長期タスクの信頼性を高めた
研究の背景
ChatGPT のような大規模言語モデル（Large Language Model、LLM）を使ってパソコンを自動操作する「PC操作エージェント」の研究が活発になっています。表計算ソフトを開いて集計したり、カレンダーに予定を取り込んだりといった一連の作業を、人間の代わりにこなす仕組みです。
こうしたエージェントの多くは、画面のスクリーンショットを撮影し、そこに写るボタンや文字を認識して操作を決めます。つまり「人間と同じように画面を見て操作する」という発想です。しかしこのやり方には限界がありました。
Salesforce Research が発表した本研究は、ここに鋭い指摘を投げかけます。画面とは、ファイルやデータベースといった内部の「プログラム状態」を映し出したものに過ぎず、しかもその過程で情報が失われた劣化コピーである、という見方です。小さく表示された数値や曖昧な座標に頼るより、内部の状態そのものを直接読み書きした方が確実だと考えたわけです。
提案手法
提案された StateAct は、画面のピクセルより先にプログラム状態を扱うことを基本方針とした、コード中心の多エージェント構成をとります。中心となる「メインエージェント」は、スクリーンショットを見るのではなくコードを実行し、ファイルやバックエンドの中身を直接操作します。
下の図は、同じ作業を2つの経路で行う様子を対比したものです。ピクセル経路では曖昧な描画値と壊れやすい座標に頼るのに対し、状態経路では成果物そのものを正確に読み書きできます。StateAct は状態でたどれる操作にはこの状態経路を使い、どうしても視覚的なやり取りが必要なときだけ画面操作に切り替えます。
視覚的な操作が必要な場合は、専用の「GUIサブエージェント」に委譲します。ただしこれが呼ばれるのは全体の一部にとどまり、論文では108タスク中28タスク、メインエージェントの全ステップのわずか1.1%だったと報告されています。大半の作業はコードだけで完結するという設計です。
全体のアーキテクチャは次の図の通りです。メインエージェントがプログラム状態を扱い、必要に応じてGUIやブラウザの専門サブエージェントを新しいコンテキストで呼び出します。さらに「完了ゲート」が保存済みの状態を独立に検証し、「コンテキスト管理」が計画やタスクの要点を数百ステップにわたって保持します。
特徴的なのが完了ゲートです。エージェントが「終わった」と宣言しても、そのまま信じるのではなく、実際に保存されたデータを別の視点から点検します。論文の例では、カレンダーに1414件の予定を取り込むタスクで、ダウンロードフォルダのコピーは完全だったのに実際の保存先には88件しか入っていない、という不整合をゲートが検出しました。こうした構造的な欠陥を見つけると、エージェントに最大3回まで作業をやり直させます。
実験結果
評価にはPC操作の総合ベンチマーク OSWorld 2.0 が使われました。バックボーンに Claude Opus 4.8 を用いた結果、StateAct は従来手法を明確に上回りました。
指標 | 参照ベースライン | StateAct |
|---|---|---|
完全成功率（Binary success） | 20.6% | 26.9% |
部分成功（Partial success） | 54.8% | 61.6% |
タスク当たりコスト | 約72ドル | 約7.8ドル |
完全成功率で26.9%を記録し、公開されている当時の上位ラインである21%を唯一超えました。同時に、同じバックボーンを使う標準的な画面操作型の構成と比べてコストは約9分の1です。精度が上がってコストが下がるという、両立の難しい改善を実現しています。
下のコストと精度のグラフを見ると、StateAct（赤）は左上、つまり「より正確でより安い」領域に位置しています。より高性能な公開手法のどれよりも精度が高く、しかも安価です。
この設計思想が効いていることは、比較実験からも読み取れます。GUIサブエージェントを一切使わずコードだけで動かした場合、部分成功は45.9%にとどまり、画面操作型のベースラインを下回りました。状態操作を軸にしつつ、視覚が必要な場面だけ画面操作を補助的に組み合わせる、という配分が重要だと分かります。
状態を軸に据えたことで、エージェントの失敗の性質も変わりました。失敗の原因を人手で分類したところ、完璧に解けなかった79タスクのうち38件が「推論の誤り」に起因し、画面認識の限界や指示の曖昧さによるものは約2割でした。つまりボトルネックは「見えるかどうか」から「どう考えるか」へ移ったのです。この視点は、会話の途中で意図が変わると性能が落ちるといったLLMの推論面の弱点を扱った研究とも通じる論点です。
まとめと今後の展望
StateAct は、PC操作エージェントを「画面を見る」問題から「内部状態を扱う」問題へと捉え直した研究です。行動、検証、記憶のすべてをプログラム状態に基づかせることで、精度とコスト効率を同時に高められることを示しました。
一方で課題も残ります。失敗の多くが推論の誤りに移ったということは、今後の改善はモデルの思考力そのものに向かう必要があるという意味でもあります。また、完了ゲートが確実に捕まえる欠陥の種類がある一方で、見逃す種類も存在すると論文は正直に報告しています。状態を直接扱う設計はあらゆるアプリケーションで等しく使えるわけではなく、適用範囲の見極めも今後の論点になるでしょう。それでも、スクリーンショット依存が当然とされてきたこの分野に別の道筋を示した意義は大きいといえます。
