Agent Browserは、固定された手順を実行する代わりに、モデルがWebページを見て次の操作を判断します。主な違いは、意思決定の主体、ページの理解方法、操作の実行方法、そして現時点の実用上の限界です。
スクリプトによるブラウザ自動化はよく知られた方法です。要素を特定し、経路を決め、例外処理を追加すれば安定して動きますが、ページが改修されるまでの話です。変更が重要な箇所に入ると、スクリプト全体を書き直す必要が出ることがあります。コードは特定の構造を認識しており、その構造こそ最も変わりやすいからです。
Agent Browserは別の考え方を取ります。モデルにページ内容を見せ、次に何をするかを判断させます。これが、ページ改修の影響を比較的受けにくい理由でもあります。
違い1：次の操作を誰が決めるか
従来のスクリプトでは、人が手順を決めます。最初にどこをクリックするか、次に何を入力するか、その後どれだけ待つかまで事前に固定され、実行時はその通りに動くだけです。
Agent Browserでは、判断をモデルに任せます。たとえば「特定の情報源から条件に合う内容を集めて表に整理する」といった目標を伝えます。どのページを開くか、先に絞り込むかページ送りするか、ポップアップをどう処理するかは、実行中にその都度決められます。
この違いは過小評価されやすい点です。保守コストがコードを書く作業から、要件を明確に説明する作業へ移ります。技術的な難易度は下がる一方、目標の記述にはより高い精度が求められます。
違い2：ページ上の内容をどう把握するか
スクリプトはセレクタで要素を認識します。XPathやCSSセレクタは、構造内にあるノードの位置を指します。位置が変われば、セレクタは機能しなくなります。
Agent Browserでは、ページ構造の情報やスクリーンショットをモデルに渡します。モデルは、これはログインボタン、あれは検索ボックス、この領域は商品の価格だと判断します。座標よりも意味を重視して読み取ります。
その代償も明確です。モデルにページを理解させるには、DOM構造やスクリーンショットを送る必要があり、ページが複雑になるほど送信量も増えます。長いタスクではこのコストが大きくなりがちです。さらに各ステップでモデルの推論結果を待つため、全体の速度はハードコードされたスクリプトより明らかに遅くなります。
違い3：操作をどう実行するか
判断した後は、実際に操作する必要があります。この種のツールは通常、ブラウザ機能を呼び出し可能なアクションとしてまとめています。ページを開く、クリックする、フォームに入力する、ログインする、ファイルをアップロードする、スクロールやページ送りをする、データを抽出するといった操作です。モデルがどのアクションをどのパラメータで呼ぶかを出力し、ブラウザが実行します。その結果がモデルへ返され、次の判断材料になります。
タスクの分解やエラー修正もこの層で行われます。目標を複数のステップに分け、順番に実行します。途中で間違った経路に進んだとモデルが判断すれば、その場でエラー終了するのではなく、別の入口からやり直すこともできます。構造が不規則なページでは特に重要で、完了率はこのリカバリー能力に大きく左右されます。
現時点でどこまでできるか
確実性が高く手順が明確なタスクは、すでに実行できます。条件に合う公開情報を集めて構造化データにする、自社システムで繰り返し入力して指定形式で送信する、特定ページを監視して価格・在庫・告知の更新時に通知するといった用途です。共通するのは、経路が予測可能で、失敗しても再試行でき、結果を人が確認できることです。
まだ安定しない部分
問題が起きやすいのは意味理解が必要な場面です。あるボタンを押すべきか判断するには、モデルがまず業務上の意味を理解しなければなりません。ページ構造が複雑だったり、文言が直感に反していたりすると、誤判断が起きます。入口を間違えたり、別の項目を取得したりすることがあります。処理の階層が深いほど誤差は積み重なりやすく、最初の小さなズレが後で修復できなくなる場合があります。
強い対策がある場面はさらに難しくなります。CAPTCHA、リスク管理による遮断、ログイン状態の失効などは、モデル自体より基盤となる環境に左右されます。どれほど高性能なモデルでも、拒否されたリクエストを成功に変えることはできません。クラウド上での実行やサービス側が管理するプロキシで一部を補える場合はありますが、従量課金のコストと第三者インフラへの依存が発生します。
選定時に確認したいポイント
実行過程を確認できるか、リプレイできるかは見落とされがちですが、問題発生時の重要な診断手段です。エラー修正の方式も確認しましょう。エラーで停止するのか、別の経路を試すのか。モデルやコストを制御できるかも重要で、長時間タスクは想定より高額になりやすいです。独自ツールやワークフローを接続できるか、最後にログイン状態をどう維持するかも確認してください。セッションが失われて最初からやり直すのは大きな負担です。
使う前にルールを確認する
技術的に可能なことと、許可されていることは別です。まず対象プラットフォームの利用規約で自動アクセスが認められているか、リクエスト頻度が相手のサービスに負荷をかけないかを確認する必要があります。また、この種のツールを使ってアカウントを大量作成したり、報酬を得るためにプラットフォーム上のタスクを自動実行したりするのは、プラットフォームの規則に反する利用です。操作間隔、行動経路、環境の一貫性を検出する能力は各社で高まっており、措置を受ける場合は複数アカウントがまとめて対象になることもあります。
タスク自体が適正で、複数アカウントのログイン状態を互いに分離する必要があるだけなら、環境分離が役立ちます。たとえばPurpleMarkは独立した環境を提供し、各アカウントのセッションやストレージが相互に見えないようにできます。
現実的な検証方法は、自分がよく知っていて手順が明確な小さなタスクを選び、ツールに最初から最後まで実行させることです。結果を手作業と比較し、エラー時の反応を記録し、実際の所要時間を計算します。小さなタスクが順調に動くなら、そこから範囲を広げればよいでしょう。最初から全工程の自動化を狙うと、途中のどこかで止まりやすくなります。
