WebwrightはBrowser Agentの成果物を「セッション」から「コード」へ移した

Microsoft ResearchのWebwright（2026）は、Browser Agentの設計をかなり明確に反転させている。従来の典型的なweb agentではbrowser sessionがagentの作業場であり、screenshotやpage stateを見てclick/type/scrollなどを一手ずつ予測する。Webwrightではagentにterminalを与え、Playwright等のコードを書かせながらサイトを探索させる。

同研究が強調するのは、persistent artifactがbrowser sessionではなくcodeとlogsになる点である。agentはbrowser sessionを起動・破棄しながら探索scriptを書き、失敗を観察して修正し、最終的にtaskを実行するparameterized CLIへまとめられる。

この違いには三つの意味がある。

第一に、一回のmodel actionで複数のbrowser interactionをprogramとしてまとめられる。逐次agentではdate pickerを開く、月を移動する、日を選ぶ、といった各actionごとにLLM turnが必要になり得るが、codeではloopやfunctionを含む一まとまりの処理として表現できる。

第二に、探索結果を再利用できる。同じフォーム入力や予約操作を次回も一から認識する必要はなく、validated scriptを保存・indexして呼び出せる。Microsoft Researchはこれを明示的にRPA-style scriptとして扱い、Online-Mind2Webの分析ではGPT-5.4で1タスク平均$2.37のagent costから再利用可能scriptを得られると報告している。この金額は2026年4月時点の同研究の価格前提なので恒久的な値ではない。

第三に、同一モデルでもaction spaceの設計で性能が変わる。Microsoftの報告では、Webwright + GPT-5.4はOnline-Mind2Webで86.7%のaccuracy、長時間web workflowを扱うOdysseysで60.1%を記録し、同社が再現したconventional screenshot-based GPT-5.4 baselineを大きく上回った。特にOdysseysではbase GPT-5.4の33.5%に対し60.1%としている。ただしベンチマーク・harness・評価条件が異なるシステム間の数字を一般的な「コードはGUIより何倍強い」という結論へそのまま外挿すべきではない。

Webwright自身もlow-level actionを否定していない。click/type/scrollは人間が使えるあらゆる環境で動くというcoverage上の強みがあり、high-level abstractionが使えない場合のfallbackとして残ると述べている。したがってこの研究の本質は「browserを捨てる」ことではなく、browserをLLMが一手ずつ直接操作することと、browser操作programをLLMが開発することを分離した点にある。

また、script化には保守問題が生まれる。サイト変更でsilent failureが起きないかを検証し、古くなったscriptをupdate/retireする必要がある。scriptの粒度も、細かすぎればlibraryが断片化し、粗すぎれば特定taskへ密結合する。この問題はAgentic Automationが自分自身を固定workflowへ「コンパイル」する設計を設計する際の中心課題になる。

Agentの実行履歴から再利用可能なworkflowを抽出するが「procedureをagentが読むworkflowとして永続化する」方向だとすれば、Webwrightは「procedureを通常のprogramとして永続化する」方向の代表例である。

出典

• Microsoft Research, “Webwright: A Terminal Is All You Need For Web Agents”, 2026-05-04: https://www.microsoft.com/en-us/research/articles/webwright-a-terminal-is-all-you-need-for-web-agents/