カテゴリ
自動化
ステータス
稼働中技術スタック
モデル
「次の金曜のSFO発JFK行きで最も安い便を探して」のように平易な言葉で伝えるだけで、サイトを遷移し、フォームを埋め、ボタンを押し、結果を取り出す。この実験では、Playwrightによるブラウザ制御、ページ理解のためのGPT-4o Vision、複数ステップの計画のためのLangGraphを組み合わせ、サイト固有のコードなしで実際のWebタスクを完了できるエージェントを作った。
5分野にまたがる50タスクのベンチマークを作った。EC(検索、絞り込み、カートへの追加)、旅行(航空券の検索、宿の予約)、情報検索(Wikipediaの参照、ドキュメント検索)、フォーム入力(問い合わせ、申込)、そして複数サイトにまたがる作業(3サイトの価格比較)である。一貫性を測るため各タスクを3回試した。エージェントはGPT-4o Visionでページの構造を理解し、アクセシビリティツリーの解析で操作可能な要素を特定し、LangGraphで複数ステップの行動を計画する。
PlaywrightがCDP(Chrome DevTools Protocol)へのフルアクセスを伴ってブラウザを制御する。GPT-4o Visionがスクリーンショットからページの構造と操作可能な要素を理解する。LangGraphが複数ステップのタスク計画と実行グラフを管理する。Redisがページの状態をキャッシュし、エラーからの復帰と巻き戻しに使う。
この実験から得られた、もっとも重要な知見です。
多様な50タスクで完了率78%
ベンチマークの78%を最後まで完了できた。成功率が最も高いのはEC(88%)で、最も低いのは複数サイトにまたがる作業(62%)だった。サイトを移動しても文脈を保ち続けるのが難しい。
アクセシビリティツリーは画面のみの方式に勝る
ビジョンによるスクリーンショットの理解と、アクセシビリティツリーの解析による構造的な要素の特定を組み合わせると、ビジョンだけの方式よりタスク完了率が22%上がった。スクリーンショットだけでは得られない、信頼できるセレクタが手に入る。
エラーからの復帰が分かれ目になる
「別の方法で再試行する」仕組み、たとえばボタンのクリックからキーボード操作へ切り替える仕組みを入れることで、最初に失敗した操作の15%を回復でき、全体の完了率は65%から78%へ上がった。
CAPTCHAとボット対策が上限になる
失敗の60%はCAPTCHA、ボット検知、あるいは初回描画の後にページが変わる遅延読み込みが原因だった。これらはブラウザ自動操作エージェントの本質的な限界である。
ユーザーは自然言語で目的を伝える。LangGraphがそれをWeb操作の連なり、つまり遷移、クリック、入力、スクロール、抽出へ分解する。各操作ではPlaywrightがスクリーンショットとアクセシビリティツリーを取得し、GPT-4o Visionが対象の要素と操作の種類を特定して、Playwrightが実行する。ステップごとに結果のページを分析して期待どおりかを検証し、検証に失敗した場合は別の操作方法を試すリカバリーのループへ入る。
50タスクのベンチマークで完了率78%。平均所要時間は単一サイトのタスクで34秒、複数サイトで92秒。エラーからの復帰の仕組みが、失敗しかけたタスクの15%を救った。動的なコンテンツ、ポップアップ、Cookieのバナーにも、サイト固有のコードなしで対応した。
検証を進めるうえで解決が必要だった技術的な課題です。
動的なコンテンツと遅延読み込み
初回描画の後に読み込まれる要素は、最初のスクリーンショットには写らない。ページをスクロールし、ネットワークが落ち着くのを待ち、複数回スクリーンショットを撮ってから要素の不在を判断する「待って撮り直す」方式を実装した。
複雑なUIでの操作の曖昧さ
似たボタンが複数あるページ、たとえば「カートに追加」が並んでいる場合には、ビジョンモデルが迷った。まず候補となる要素をすべて特定し、その後に周囲の文脈である商品名や価格から正しいものを選ぶ2段構成を追加した。