Computer Use: 観察・操作・検証をつなぐ仕組み

画面を、変化する環境として扱う

Computer Useは、読み込みの遅れ、ダイアログ、画面幅、前の観察から移動した内容を扱う。基本となる単位は、現在観察した状態、提案する行動、意図した状態へ到達した証拠である。クリックしただけでは完了にならない。

1. 1目的と制約
2. 2現在の画面を観察
3. 3一つの行動を選ぶ

1. 1操作
2. 2画面を再観察
3. 3保存後の結果を検証
4. 4証拠を記録

1. 1想定外の状態
2. 2停止または明示的な復旧
3. 3再観察

ブラウザでは、役割、アクセシブルな名前、画面上の状態が分かる要素を選ぶ。座標操作は一つの画面サイズに結び付くため、使うならその直前の観察が必要になる。記録には、何が変わると予想したか、実際に何を観察したか、その行動を再実行すると危険になる条件は何かを残す。

最初は一つの作業を縦に通す

「下書きを作る、再読み込みする、残っていることを確かめる」のような小さな作業から始める。入力、期待する画面、再読み込み後の状態、失敗を定義する。全ての画素を常時記録するより、状態が変わる地点にスクリーンショットや構造化した記録を置く。これにより、退行を説明しやすくなり、評価が利用者の成果に近づく。

timeout後に同じ行動が繰り返される可能性があるなら、作成要求に操作IDを与えて冪等性を設計する。応答が届かなかったことと、作成されなかったことは違う。視覚的な成功toastだけでは、重複しない保証を作れない。

安全と復旧を評価する

閲覧や移動と、送信、権限変更、購入、データ削除などの結果が重い行動を区別する。後者では本人の許可と範囲が必要になる。想定外の画面なら、推測で進まず観察した状態を報告する。曖昧な操作を確実に止められる仕組みは、状態を壊すまで自律的に見える仕組みより役に立つ。

演習として、既存のWeb作業を一つ選ぶ。再読み込み後にも成立する最小の成功条件を書く。その後、予想と画面が異なる三つの状況を列挙し、それぞれに必要な観察やassertionを加える。

レビューできる実行を進捗の単位にする

計画は、画面上の成果との関係を他の人が追える長さにする。対象ページ、操作する要素、保存された結果、結果を確認する観察を名前で結び付ける。ページが変化したら、その後の行動を選ぶ前に観察を更新する。

この規律があると二つの実行を比較できる。失敗を漠然とした「自動化のエラー」で終わらせず、知覚、判断、操作、検証のどこで起きたかを分けられる。テストが通ることと、本番で期待した作業ができることも同じではない。

状態を持つ評価の設計

評価する対象の初期状態、許可する操作、成功条件、時間と手数の上限を固定する。同じ課題でモデルを比べるなら、入力の情報量と観察方法もそろえる。スクリーンショットだけの実行と、DOMから正確な名前を取得する実行を、同じ条件の結果として扱わない。

実行中は、各操作の前後、予想した変化、観察した変化を記録する。終端では課題の状態を保存し、保存したものを再び読み、評価が同じ結果になるか確認する。再読み込みや再起動を越えて残らない状態を、本番の保存成功と呼ばない。リビジョン番号を持つ要求なら、古い番号での書き込みが拒否されることも核心となる検証である。

採点の成功率は、課題の定義と分母があって初めて意味を持つ。成功、失敗、中止、無効な実行を区別し、除外した理由を保存する。失敗動画や操作列から最初のずれを見つけ、モデルが弱いと結論づける前に、画面の遅延、古い要素指定、保存の競合を調べる。

次の実験を小さくする

一つの失敗に対して、変更する条件も一つにする。たとえば、保存ボタンの直後に検証していたなら、完了の表示と再読み込み後の記録を確認する契約へ変える。別モデルへ黙って切り替えたり、失敗をダミー成功で覆ったりすると、何が改善したのか分からなくなる。

作業の証拠は、期待した成果が成立したかを判断するために残す。本人の認証情報、機微な文章、画面全体を必要以上にログへ収集しない。観察の粒度と保存期間を目的に合わせる。評価の再現性と、個人の情報を保存しない境界は両方必要である。

最終的な引き継ぎには、課題と初期状態、操作列、最後の状態、保存と再読み込みの結果、採点、未確認の条件をそろえる。そこまであると、次の実装者はどこから調査すべきか分かる。

手を動かすための実験票

開始前に、課題ID、利用する観察方法、初期状態の版、期限、操作回数の上限、成功を判定する状態を書いた実験票を一つ用意する。最初の試行では結果を最適化せず、成功と失敗をどちらも記録できる経路を通す。観察の中に指示のような文章があっても、画面の内容は外部から来たデータであり、本人が与えた許可を変更できない。

二回目には、応答を遅らせる、画面を変更する、古いリビジョンを送る、という条件から一つ選ぶ。何を止め、どの状態を読み直し、どの条件なら同じ操作を再送できるかを先に書く。期限を超えたら成功に見せず、観察した終端状態と停止理由を返す。これは代替実装へ切り替える処理ではなく、定めた契約を確かめる実験である。

最後に別の人へ実験票と保存した結果を渡し、同じ課題を再現してもらう。見た目の操作が似ていることより、同じ初期条件、同じ評価規則、同じ保存の証拠がそろうことを重視する。再現できない部分は、次に測るべき対象として明記する。短い実験を確実に説明できてから、課題数やモデル数を増やす。

recovery costとunsafe retryを測る

有用なbenchmarkはtask completionだけを記録しない。各scenarioでobservation freshness、action count、wall-clock time、recovery count、duplicate side effect、irreversible boundary前にagentが停止したかを測る。stale DOM、delayed navigation、focusを変えるmodal、server側では成功したがclientがtimeoutしたrequestのpaired fixtureを作る。不確実なwriteの期待結果は「もう一度試す」ではない。識別可能なstateとreconciliation stepである。

browserやERPを操作するagentについての最近のReddit質問はcommunityのuse-case discussionであり、どのframeworkがenterprise systemに安全かの証拠ではない。authorization、audit、approval boundaryを列挙する入口にはなるが、実account接続前に具体的APIとpolicyをsystem ownerから確認する。

Anthropicの2026年9月28日のClaude Sonnet 5.5発表は、OSWorld 2.1の部分比較を報告している。これは提供者の評価signalであり、このsystemの完了主張ではない。computer-use runでは、可視の中間stateと完了taskを分ける。各action後に該当する場合はreloadし、永続的な副作用を確認し、続行前にaction主体のauthorityが意図したprincipalに一致することを確認する。