長時間のComputer Useでは、クリックより状態管理と検証が難しくなる
Computer Useの性能を考えるとき、UI elementを正しくclickできるかだけを見ていると長時間業務の難しさを過小評価する。
OSWorld 2.0（2026）は、従来より大幅に長いend-to-end workflowを評価するために108タスクを構築した。人間による完了時間の中央値は約1.6時間で、Claude Opus 4.7 maximum thinkingでは平均318 tool callsを要した。これはOSWorld 1.0の約30 callsと大きく異なる。
500 step上限のbinary completionでは、論文執筆時の最良構成であるClaude Opus 4.8 maximum thinking + batched tool callsでも20.6%の完全成功、partial score 54.8%にとどまった。GPT-5.5はtoken efficiencyでは優れるが完全成功は約13%でplateauしたと報告されている。
重要なのは失敗原因の分析である。著者らは、現在のagentがbasic GUI controlやcodingだけで躓くというより、長いworkflowの中でconstraintを見失う、途中で到着した情報を取りこぼす、曖昧な状態でユーザーへ質問せず推測する、最終verificationを飛ばす、hidden stateを復元できない、といった問題を指摘している。
これは「Computer Use modelのpointing精度が上がれば業務自動化が完成する」という見方に対する重要な反例である。長い仕事には少なくとも次の問題がある。
- 現在どこまで完了したかというworkflow state
- 外部から途中で変化するenvironment state
- ユーザーのpolicyやconstraintを長時間保持するmemory
- irreversible action前のconfirmation
- action後のpostcondition verification
- retryしてよい操作かを判断するidempotency
- partial failureからのresume/recovery
ReUseItがworkflowへcondition checkとfallback actionを導入したのも、低水準actionの成功だけでは反復自動化が安定しないためである。Webwrightも完成判定の早すぎる自己申告を問題として、fresh folderでfinal scriptを実行し、logとscreenshotを作り、self-reflection judgementを通すcompletion gateを追加している。
つまり長時間自動化では「AIに判断させるか、programにするか」という議論に加えて、どこで状態を永続化し、どのpostconditionを機械的に検証するかが中心課題になる。
この観点ではAgentic Automationが自分自身を固定workflowへ「コンパイル」する設計も、単にagent trajectoryをscriptへ変換すればよいわけではない。固定化するなら、precondition、postcondition、retry policy、audit、human approval pointまでprogram側へ持っていく必要がある。
出典
- Mengqi Yuan et al., “OSWorld2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks”, 2026: https://arxiv.org/abs/2606.29537
- Yimeng Liu et al., “ReUseIt: Synthesizing Reusable AI Agent Workflows for Web Automation”, 2025: https://arxiv.org/abs/2510.14308
- Microsoft Research, “Webwright: A Terminal Is All You Need For Web Agents”, 2026: https://www.microsoft.com/en-us/research/articles/webwright-a-terminal-is-all-you-need-for-web-agents/