ローカルPCエージェントは推論予算を増やしても必ずしも高精度にならず、履歴画像4枚を境に効果が反転

研究チームは、OSWorldのUbuntuタスク361件を用いて、Qwen3-VL-8B、Qwen3-VL-30B-A3B、UI-TARS-1.5-7B、OpenCUA-7Bを評価し、推論時の4種類のリソースを体系的に調整した。具体的には、保持する過去の画面画像数、許可する操作ステップ数、計画とグラウンディングを2段階に分割するかどうか、同時に生成する候補計画数である。すべてのエージェントは画面のスクリーンショットだけを読み取り、accessibility treeは使用しなかった。推論は単一のA100 80GB上でvLLMを介して実行された。

最も顕著な効果をもたらしたのは「少量の履歴」だった。平均成功率は、画面画像をまったく保持しない場合の約18％から、1枚保持した場合には25％超へ上昇した。Qwen3-VL-30B-A3Bの場合、履歴画像4枚で28.56％を記録したが、8枚に増やすと逆に27.16％へ低下した。履歴があれば、エージェントは直前に何をクリックしたかを把握できるため、その場でのループやステップ上限到達を減らせる。しかし、タスク完了の判定は改善しなかった。コンテキストが長くなるほど、エージェントが早すぎる段階で成功を宣言する失敗がむしろ増えた。

最大操作ステップ数を15から50または100へ引き上げた場合も、同じ現象が見られた。エージェントがステップ上限に達する頻度は減ったものの、タスク成功率はおおむね横ばいで、累積prompt token数と操作コストは増え続けた。これは、誤った軌跡に入った場合、単に操作を数ステップ追加しても通常は自己修正できないことを示している。より複雑な「プランナー—グラウンダー」アーキテクチャは、全体として単一エージェントを下回った。その要因には、計画と画面の不整合、必須フィールドの欠落、出力フォーマットを解析できない問題などがある。候補計画を一度に4件生成すると、一部のフォーマットエラーを回避できたが、改善幅は追加の計算量に見合わなかった。

エンジニアリング上の示唆は、ローカルエージェントに最先端の大規模モデル向けtest-time scaling手法をそのまま適用すべきではないということだ。より現実的な方向性としては、選別した短期状態の保持、ループおよび停滞の検出、タスクが本当に完了したかを確認する独立した検証器の導入が挙げられる。ただし、この研究は単一のベンチマーク、Ubuntuタスク、1種類のGPU構成だけを対象としており、新たな学習手法も公開していない。したがって、結果が示しているのは既存のローカルモデルにおけるリソース配分のあり方であり、すべてのGUIエージェントに当てはまる普遍的な法則ではない。