8月18日、Towards Data Scienceが「Webwright: Why AI Web Agents Should Write Code, Not Click」と題した記事を公開した。Microsoft Researchと香港大学が開発したウェブエージェントフレームワーク「Webwright」が、クリック型の逐次操作ではなくコード生成によってブラウザ自動化の根本的な課題を解決しようとしているかについて詳しく紹介されている。
クリックを繰り返すエージェントの限界
ウェブエージェントに「このディレクトリから全件のリストをスプレッドシートに書き出せ」と指示したとき、何が起きるか。エージェントはページを読み、クリック先を予測し、DOM（ブラウザが解釈するページ構造）の変化を待ち、また読み直す——このループを延々と繰り返す。
問題は40ステップ目あたりで顕在化する。モーダルが突然出現し、「次ページ」ボタンの位置が変わり、エージェントは要素を誤認する。根本的な問題はひとつの悪いクリックではなく、「ページを見る→1アクション決定→変化を確認→また決定」というループ構造そのものだ。タスクが終わっても再利用できるものは何も残らない。
OpenAIのOperatorやAnthropicのComputer Useはスクリーンショットから人間のように操作し、WebVoyagerはDOMを読んで要素を特定する。browser-useやSkyvern、Stagehand、LaVagueはこうした手法をAPIとしてパッケージ化している。しかしどれも本質的な構造は変わらない。1アクションずつ逐次実行し、完了後に再利用可能な成果物を残さない。
各アプローチの限界を整理すると以下のとおりだ。
| ファミリー | モデルが見るもの | 限界 |
|---|---|---|
| ビジョンエージェント | スクリーンショット | レイアウトずれ、トークンコスト増大 |
| DOM/セット・オブ・マークス | HTML、アクセシビリティツリー | ページ状態が肥大化、要素IDが動的変化 |
| 固定アクションAPI | click/type/scroll/select | ループ・リトライ・ファイル出力を表現できない |
| ブラウザフレームワーク | ラップされたブラウザ操作 | 逐次実行、セッション消滅で再利用不可 |
数字で見ると厳しい。VisualWebArenaでは人間の成功率が約**89%であるのに対し、主要なビジョン言語エージェントは約16%**にとどまる。
Webwrightの発想：「ブラウザは一時的、コードが永続する」
Webwright（Microsoft Research・香港大学）のアプローチは一言で表せる——「ウェブエージェントに必要なのはターミナルだけ」。
クリックの次を予測させるのではなく、エージェントにbashやPlaywrightスクリプトを書かせる。ブラウザを開き、ページを調べ、タスクを実行するコードを生成・実行させるのだ。完了後に残るのは、検査・再実行・修正・再利用が可能なプログラムである。
この発想の先行研究として、ICML 2024の論文「CodeAct」がある。JSONスタイルの定義済みアクションをPythonの実行可能コードに置き換えたところ、成功率が最大20%向上し、ステップ数が約30%削減されたと報告されている。Webwrightはこのアイデアをブラウザ自動化に持ち込み、VisualWebArenaにおいてState-of-the-Artに相当するスコアを達成している。
なぜコードが優れているのか
- 頑健なセレクタ —
page.locator(...)やwait_for_selector(...)によるクエリはピクセル座標や一時的な要素IDより安定している - ループと関数 — 「全行に対してこれを繰り返せ」を1プログラムで表現できる。逐次型なら数百回のアクションになる
- ワークスペースがステート — 進捗はファイルとログに残る。セッションが消えてもコードは消えない
- 最小構成 — 依存ライブラリは
httpx、pydantic、playwright、typerの4つ。それでベンチマークでState-of-the-Artを達成している
2つのデモで見る具体的な差
デモ1：JavaScriptスライダーの精密操作
ChaseのIRAシミュレーターで6つのスライダーを操作し、Traditional vs. Roth IRAを比較するタスク。
- Webwright：DOMの入力値を直接コードで書き換え、必要なイベントをトリガー。$300の拠出額が正確に設定され、グラフが正しくレンダリングされる。
- ビジョンエージェント：スライダーを視覚的に動かすため$294止まり。$300に届かない。
「クリックはタスクを1回完了させる。コードはタスクを完了させ、解法を残す。」
デモ2：繰り返しタスクへの対応
Google Flightsでシアトル→サンフランシスコの往復を検索するタスク。
- Webwright：検索条件をPlaywrightスクリプトとして生成・実行し、完了後にそのスクリプトをワークスペースへ保存する。次回の類似した検索では、入力値を変えて再実行するだけでよい。
- クリック型エージェント：同じ検索を再度行う際にはセッションをゼロから開始し直す必要がある。前回の操作履歴はブラウザセッションとともに消滅しており、再利用できる成果物が何も残らない。
Microsoftが「閲覧履歴がクリックではなくコードになる」と表現するのはこの意味だ。デモ1が精度の差を示すとすれば、デモ2は再利用性という次元でのアーキテクチャ上の差異を示している。
Stagehand・browser-useとの違い
Stagehand、browser-useはいずれもブラウザセッションを中心に状態を管理する。Webwrightはブラウザを一時的なものと位置づけ、コード・ログ・出力ファイルをローカルのワークスペースに蓄積する。フレームワークの規模は約1000行と小さく、依存関係も最小限に抑えられている。
Webwrightは2025年5月にリリースされた比較的新しいフレームワークだ。ページネーション処理、JavaScriptレンダリングされたコンテンツ、無限スクロールフィードといった実用的なスクレイピング問題への適用可能性についても元記事で触れられている。コードベースや実装の詳細に関心がある読者は、元記事内に示されているリポジトリリンクから直接確認することを勧める。
詳細はWebwright: Why AI Web Agents Should Write Code, Not Clickを参照していただきたい。
