画面の向こうにある仕事
取引先のフォームを、いつまで人が埋め続けるのか
取引先のポータルで製品資料を請求する仕事を考える。 これは以下の設計を説明する想定例である。 社名、担当者、対象製品を入力し、途中の確認画面を通って送信する。 自社の顧客管理システムには情報がそろっていても、相手のサイトに連携用のAPIがなければ、人が画面を開いて転記する工程が残る。
ブラウザ操作エージェントは、この工程を任せられる可能性を開く。 OpenAIが1月23日に発表したOperatorは、専用APIを用意せず、スクリーンショットを見て入力、クリック、スクロールする仕組みを示した。 提供は米国のPro利用者向け研究プレビューであり、あらゆるサイトで仕事を終えられるという実証ではない。 それでも、連携先がAPIを提供するまで待つ、という製品計画の制約を変える提案として読める。
ただし、操作できる画面が増えるほど、そこで起きたことを確かめる仕事も増える。 送信ボタンを押した後にエラーが出たのか、受付が遅いだけなのか、既に送信されたのか。 本稿の判断は、ブラウザエージェントを計画する際には、操作先の広さと、一件を確実に終えるための負担を一緒に比較する必要がある、というものだ。
操作方法の比較
API、画面の構造、画像は、それぞれ違う手掛かりを渡す
連携APIがあり、対象データと受付結果を直接扱える仕事では、その経路を使う価値がある。 画面の配置が変わっても同じ項目を送れるからだ。 ただし、APIがあることだけで権限、入力内容、結果の正しさまで保証されるわけではない。 一方、画面操作は既存の利用者向け機能を使えるが、表示内容から操作対象と結果を読み取る必要がある。 これは接続先を増やす利点と引き換えに増える処理である。
WebVoyagerの原版は、その読み取りを画像だけに任せてはいない。 Webページの構造から操作可能な要素を抽出し、スクリーンショット上に番号付きの枠を重ねる。 モデルには画面と補助テキストを渡し、選んだ番号に対してクリックや入力を行う。 視覚で位置を理解することと、構造から操作対象を特定することを組み合わせた実装だ。
この違いは選択を変える。 項目名がはっきりした入力欄なら、Webページの構造やアクセシビリティ情報を使う方法が候補になる。 画像の内容や見た目の配置が判断材料なら、テキストだけでは条件を落とす可能性がある。 どれか一つを万能な入口にせず、対象画面に何の手掛かりがあるかから選ぶ方がよい。
連携API
項目と結果を直接扱える場合に有効。必要な機能と権限がAPIで提供されているかを確かめる。
画面内の構造
入力欄やボタンの意味を使う。画像の意味や構造に載らない表示は別の観測で補う。
画面の画像
見た目も判断に含められる。位置の読み違いと、観測の間に消える表示を検査する。
視覚が必要な課題
「同じ商品を選ぶ」には、名前だけでは足りないことがある
VisualWebArenaの原版は、画像とテキストの理解が必要な910課題を、分類広告、買い物、Redditの三つのWeb環境に用意した。 再現可能な環境で、利用者の指示を読み、見た目に根拠のある対象を選び、操作する能力を測る。 一般のサイトで自由に動けるかを測る試験とは、環境の作り方が違う。
例えば、名前が似た複数の商品から、渡された写真に合う形を選ぶ場面を考える。 これは研究の課題設定が持つ意味を説明する例である。 文字を正しく読み、ボタンも正しく押せても、選ぶ対象の条件が画像にしかなければ仕事を取り違える。 視覚を使う意義は、クリックの手段を増やすことに加え、利用者が指定した条件を失わずに扱うことにある。
ただし、画像を読めるモデルでも、似た配置の取り違いや小さな違いの見落としは残る。 WebVoyagerの失敗分析も、隣接する要素の混同や、二つの観測の微妙な変化を認識できない問題を挙げる。 「画像入力を追加した」という仕様だけで、対象を選ぶ精度まで判断することはできない。
研究結果を読む
対応するサイトの数と、完了できた仕事の割合を分ける
WebVoyagerの原版は、15サイトから集めた課題で55.7%の成功率を報告した。 モデルはGPT-4のvision preview、ブラウザの大きさは1024×768、探索は最大15操作という条件である。 この値はその構成の結果であり、Operatorの成功率でも、自社フォームの見込みでもない。 複数のサイトで動いたことと、その各仕事を安定して終えられることは、別の説明を必要とする。
BrowserGymの原版は、Webエージェントの複数の評価環境を共通の観測・行動形式で扱い、実験管理をそろえる仕組みを示す。 評価の条件を追いやすくする基盤であり、異なる課題の得点をそのまま同じ尺度にするものではない。 製品で使うサイト、見える情報、操作の上限が違えば、改めてその仕事を試す必要がある。
対象がブラウザの外へ広がる場合も同じだ。 OSWorldの原版は、Webやデスクトップアプリ、ファイル操作などの369課題と、初期状態の設定、実行結果を判定する仕組みを提示した。 Ubuntu、Windows、macOSへの対応は、全OSで同じ成功率が得られるという意味ではない。 ブラウザからファイル保存や別アプリへ移るなら、その境界も製品の対象範囲として測る必要がある。
見えなかった結果
送信した後、エージェントは何を見ているのか
画面を操作するエージェントは、操作と観測を繰り返す。 その間に起きたことを全て見ているとは限らない。 Anthropicの2024年10月22日の解説は、連続した動画ではなくスクリーンショットをつなげて読むため、短時間だけ現れる通知や動作を見逃しうると説明する。 速度や誤操作にも課題が残るという記述は、成功したデモの外にある条件を示している。
冒頭の資料請求で、送信後の画面が変わらなかった場合を考える。 エージェントには、受付が遅いのか、入力エラーが出たのか、確認通知を見落としたのか、まだ区別できない。 「変化が見えないので再送する」と決めると、既に受け付けられた請求を重ねる可能性がある。 観測が不足している状態を、送信が失敗した状態へ置き換えてはいけない。
私が製品に求めるのは、この不明確さを利用者が読める形で残すことだ。 受付番号、継続して見える完了画面、利用者が確認できる受信記録など、仕事に応じた根拠があるかを確かめる。 ない場合には、試みた時刻と確認できた範囲を示す。 何も言わずにやり直すより、利用者が再送すべきかを判断する材料を渡せる。
人へ戻す時点
画面を渡すだけでは、仕事は引き継げない
Operatorの発表は、ログイン、支払い情報、CAPTCHAなどで利用者に操作を戻し、注文やメールの送信などの前に確認を求める設計を説明した。 人の判断を組み込む具体的な製品仕様であり、どの画面でも誤操作を防げるという保証ではない。 別の製品を作る際には、その仕事で誰が何を確認できるかを設計し直す必要がある。
資料請求の途中で認証が必要になった場合、利用者はログインした後に、何のためにこの画面を開いたのかを思い出すことになる。 目的、入力済みの項目、送信の有無が分かれば、そのまま続きを任せやすい。 画面だけ戻され、最初から説明し直すなら、転記を減らした代わりに別の負担を増やしている。
このため、人の関与を「最後に確認する一回」と数えるだけでは足りない。 何回呼び戻されたかに加え、そのたびに何を調べ直し、何を入力し直したかを見る。 これは本稿が提案する評価の観点であり、既存製品で負担が減ったという測定結果ではない。 人に戻す機能の存在と、引き継ぎの使いやすさを分けて確かめたい。
続きの処理を支える
通信と進捗の記録は、受付済みの証拠とは別に持つ
1月14日に発表されたAutoGen v0.4は、非同期メッセージ、処理の出来事に応じて動く構成、メッセージ追跡やデバッグを提示した。 進捗の保存と復元、停止した処理の再開も説明されている。 これらは長い処理を組むための部品だが、外部サイトが請求を受け付けたかまで自動的に確定するものではない。
Magentic-Oneの原版では、統括役が二つの台帳を使う。 一方に事実、推測、計画を置き、もう一方に進捗と担当への指示を置く。 進まなくなった場合には計画を見直し、ブラウザ、ファイル、コードなどを扱う担当へ仕事を割り振る。 これは複雑な課題に対する研究実装であり、全てのブラウザ業務に同じ人数や構成が必要だという根拠ではない。
資料請求にこの考え方を使うなら、「送信操作を実行した」という記録と、「受付番号を確認した」という根拠を分ける。 途中から再開する処理も、前者しかない状態で再送してよいと決めない。 担当を増やすより先に、次の担当がどの記録を確定した事実として使えるかを定義する。 記録が残ることと、その記録が外部の結果を正しく表していることは別だからだ。
製品計画に置く単位
利用者が続きを調べ直さずに済む仕事から組み込む
Building effective agentsは、あらかじめ定めた経路で進む処理と、モデルが次の手段を選ぶエージェントを区別する。 ブラウザでも、決まったフォームへの入力まで全て自由な判断にする必要はない。 安定した経路は定め、画面や条件が変わる場所で観測と判断を使う、という組み合わせが考えられる。 閲覧と比較だけで目的を満たすなら、送信まで対象に加える理由もない。
製品計画では、一つの具体的な仕事を通して比べたい。 資料請求なら、入力の準備、認証後の再開、送信結果の確認までを試す。 正常な場合だけでなく、必須項目のエラー、遅延、短い通知、途中離脱を含め、完了できた割合と利用者の修正時間を分けて記録する。 対応できるサイトが増えても、一件ごとに人が画面を見直す時間が増えるなら、その負担を含めて採用を判断する。
ブラウザ操作が持つ価値は、既存のソフトウェアと利用者の目的をつなぐ範囲を広げることにある。 その価値を使える製品にするには、どこまで操作し、何を確かめ、分からない結果をどう渡すかが必要になる。 利用者が状況を調べ直さずに続きを選べる仕事を一つずつ増やす。 それが、画面操作の可能性を日々の仕事へ移すための現実的な道筋だ。