Webwright完全解説｜Microsoft発の最小ブラウザエージェントが86.7%でSOTAを達成した理由

Webwrightは、Microsoft Researchが2026年5月4日に公開したブラウザエージェントOSSだ。コーディング向けLLMにターミナルを与え、Playwrightスクリプトを書きながらWebタスクを完遂させる――発表時点でOnline-Mind2Webで86.7%、長期タスクOdysseysで60.1%という、AutoEvalカテゴリのオープンソースハーネス最高スコアを達成している。

AIエージェント設計の全体像については AIエージェントフレームワーク比較2026：LangChain・CrewAI・AutoGen徹底解説 をご覧ください。

“A terminal is all you need” — Webwrightが捨てたもの

ブラウザエージェントの主流アーキテクチャは長らく「ブラウザセッションが状態」だった。Stagehand、browser-use、agent-browser――名前は違えど共通する設計は、各ステップでモデルにページの現状（DOMスナップショット、アクセシビリティツリー、スクリーンショット）を渡し、1つの次アクション（click・type・DOM selector・短いツール呼び出し）を予測させるループだ。

Webwrightはここを反転させる。Microsoftリサーチのブログタイトルが端的に表す通り、「ターミナルがあれば十分」――エージェントとブラウザを分離し、ブラウザを「エージェントが必要に応じて起動・観察・破棄する環境」として扱う。永続的な成果物はブラウザセッションではなく、ローカルワークスペース内のコードとログだ。

この設計上の決断は、LLMが進化したいま2つの大きな帰結をもたらす。第一に、コードas Action――モデルはピクセル単位のクリックやXPathを毎ステップ予測する代わりに、Playwrightスクリプトを丸ごと書いて実行する。第二に、ループと抽象化――「8/15から8/20の航空券を検索」のようなパラメトリックなタスクが、ハードコードされたシーケンスではなく1つの関数になる。日付を変えれば別タスクで再利用できる。

「モデルがコードを書ける時代に、なぜ毎回ピクセル予測をさせるのか」というのがWebwrightの根本的な問いだ。2024年までのブラウザエージェントが「次のクリックを予測する」設計だったのは、当時のLLMが長いコードを正確に書けなかったからにすぎない。GPT-5系・Claude Opus 4系がプログラムを実装・デバッグできるなら、ブラウザ操作も「観察→1アクション」ではなく「観察→スクリプト→実行→スクリーンショット確認→修正」というコーディングと同じループに収まるはずだ。

86.7% SOTA — ベンチマーク結果の読み方

公式ブログとREADMEに記載された数字を、正確に理解しよう。Webwrightは100ステップ予算で2つの実Webサイトベンチマークを走らせている。

Online-Mind2Web（300タスク、AutoEvalカテゴリ）

GPT-5.4の86.7%はAutoEvalカテゴリのオープンソースハーネスで最高スコアだ。注目すべきはHard splitでClaude Opus 4.7がGPT-5.4を上回る点で、難しいタスクほどモデル選択が結果を分けることを示している。

Odysseys（200タスク、長期タスクベンチマーク）

ここでの差分は劇的だ。+15.6ポイント（従来SOTA比）と+26.6ポイント（同モデル比較・別ハーネス）の改善は、ハーネスとアクション空間の設計だけで叩き出されている。同じGPT-5.4が、座標予測では33.5%、Webwrightでは60.1%――27ポイントの差が「何を予測させるか」の違いから生まれる。

「Code-as-action beats coordinate prediction」――READMEのこの一文に、Webwrightが提示する仮説のすべてが詰まっている。モデル能力を据え置いたまま、アクション空間を「座標とクリック」から「Playwright Python」に変えるだけで、長期タスクの完遂率が倍近くまで跳ね上がる。

さらに興味深いのは、生成された再利用可能スクリプトを5個以上のCLIツールとして渡すと、Qwen-3.5-9Bクラスの小型モデルでもOnline-Mind2Webのタスクを完遂できるという報告だ。これは「毎回ブラウザ操作を予測する」のではなく「いったん書いたツールを再実行する」という設計の帰結であり、巨大モデル依存からの脱却を意味する。

内部アーキテクチャ — ~1.5k LoCの内訳

Webwrightのコードベースは驚くほど小さい。READMEに記載された行数を整理すると、エージェントの中核は数ファイルに収まっている。

外部依存はhttpx / pydantic / playwright / typerの4つだけ。LangChain、LangGraph、CrewAI、AutoGen――いわゆる「エージェントフレームワーク」を一切使わずに、SOTAを達成している。

エージェントループの流れ

シンプルだ。観察→実行→記録→次のステップ――エンジニアがRPAスクリプトを書く動きそのままだ。

このループにはマルチエージェントなし、グラフエンジンなし、プラグインレイヤーなし、隠れたオーケストレーションなしだ。READMEに繰り返し書かれている通り「a terminal, a browser, and a model」だけが存在する。

クイックスタート — 5分で動かす

Webwright単体を試すには、Python 3.10+とPlaywright Chromium、そしてバックエンドのAPIキーが必要だ。

インストール

git clone https://github.com/microsoft/Webwright
cd Webwright
pip install -e .
playwright install chromium

OpenAIバックエンドで起動

export OPENAI_API_KEY=sk-...

python -m webwright.run.cli \
    -c base.yaml -c model_openai.yaml \
    -t "Search for flights from SEA to JFK on 2026-08-15 to 2026-08-20" \
    --start-url https://www.google.com/flights \
    --task-id demo_openai \
    -o outputs/default

CLIフラグは最小限だ。-cで設定ファイルをスタック、-tでタスク指示、--start-urlで初期ページ、-oで出力ディレクトリを指定する。実行が始まるとoutputs/default/demo_openai/配下に以下が書き出される。

• trajectories/ — 各ステップのLLM入出力
• screenshots/ — エージェントが撮ったスクリーンショット
• scripts/ — 実行されたPythonコード
• final_script.py — 最終的にタスクを完遂したスクリプト

ここで生成されるfinal_script.pyは単独で再実行可能だ。これがWebwright設計の核心で、ブラウザセッションではなくスクリプトが永続成果物として残る。

Claudeバックエンドに切り替え

export ANTHROPIC_API_KEY=sk-ant-...

python -m webwright.run.cli \
    -c base.yaml -c model_claude.yaml \
    -t "Find the cheapest hotel in Tokyo for 2026-09-10 to 2026-09-12 on Booking.com" \
    --start-url https://www.booking.com \
    --task-id demo_claude \
    -o outputs/default

model_openai.yamlをmodel_claude.yamlに差し替えるだけだ。モデル層は各~150-200行のアダプタとして実装されているため、新規バックエンド追加も非常に小さなパッチで済む。

Claude Code / Codex プラグインとして使う

Webwrightのもう一つの顔がプラグイン版だ。スタンドアロンCLIとは別に、.claude-plugin/plugin.jsonと.codex-plugin/plugin.json、共通スキルskills/webwright/を同梱しており、Claude Code・OpenAI Codex・OpenClaw・Hermes Agentのいずれからも使える。

Claude Codeへのインストール

# 1. リポジトリをClaude Codeマーケットプレイスとして追加
/plugin marketplace add microsoft/Webwright

# 2. プラグインをインストール
/plugin install webwright@webwright

# ローカルチェックアウト派の場合
/plugin marketplace add /absolute/path/to/Webwright
/plugin install webwright@webwright

インストール後はClaude Codeを新しいセッションで再起動する必要がある。プラグインはセッション開始時にロードされるためだ。

/webwright:run と /webwright:craft の違い

Claude Code版Webwrightの真価は、ホストエージェント（Claude Code自身）が追加APIキー不要でループを駆動する点だ。Webwrightのimage_qa / self_reflectionツールはClaude CodeがPNGをネイティブに読めるためスキップされ、ホストサブスクリプション以外のコストは発生しない。

# 一回限りのスクリプト生成
/webwright:run search Google Flights for flights from SEA to JFK on 2026-08-15 to 2026-08-20

# 再利用可能なCLIツール生成
/webwright:craft search a ticket on Google Flights from LAX to SFO depart June 7 return June 14

/webwright:craftが生成するfinal_script.pyはargparse付き関数として書かれている。デフォルト引数は実行時のタスク値だが、後から差し替えできる。

# craftで生成したスクリプトを別の経路で再利用
python final_script.py --origin JFK --destination LAX --depart-date 2026-07-01

これが「タスクをツール化する」というWebwrightの第二の核となる設計だ。1回の高品質な実行から再利用可能なツールが生まれ、それが小型モデルでも実行可能なCLIになる――Qwen-3.5-9Bが86.7%級のタスクを完遂できる理由だ。

他のブラウザエージェントとの比較

Webwrightの設計上の差別化点を、主要OSSと比較してみる。READMEに掲載された公式比較表を踏まえつつ、内部リンク先で詳説した記事も補足する。

Vercel製agent-browserの設計については、こちらの記事を参照。agent-browserは「別エージェントが呼ぶCLIツール」というポジション取りで、Webwrightの「自律的にスクリプトを書く」設計とは対照的だ。

Webwrightの最大の差別化は「コードas Action」と「ワークスペースas State」だ。他のOSSがブラウザセッションを永続状態として扱う中、Webwrightだけがコードとログを永続化する。これにより長期タスクで誤差が蓄積しにくく、スクリプトの再実行・パラメータ化・人間によるレビューが可能になる。

ハーネスエンジニアリングとの接続 — エージェント設計の最前線

Webwrightの設計を一段抽象化すると、いま起きているハーネスエンジニアリングの潮流の典型例として読める。

Claude Codeなど現代のコーディングエージェントが採用しているのは「ハーネス（インフラ層）がループ・コンテキスト・ツール管理を担い、モデルは『何を言うか』に集中する」という設計だ。Webwrightはこの思想をブラウザエージェントに移植している。

12-Factor Agents原則との対応

12-Factor Agents完全解説：本番投入できるLLMエージェント設計12原則を一次ソースで読む の枠組みでWebwrightを見ると、複数のFactorに合致する。

状態機械ガードレールとの組合せ可能性

Statewright完全解説｜Rust製状態機械ガードレールがSWE-bench 2→10/10に変えた理由 のような状態機械ガードレールと組み合わせた場合、Webwrightの自由形式コードアクションに対して「planningフェーズではブラウザ起動のみ、implementingフェーズでフォーム入力許可、verifyingフェーズではスクショ撮影のみ」といった制限を加えられる。Webwrightが提供する自由度の高いアクション空間と、Statewrightが提供する状態ごとのツール制限は、本質的に補完関係にある。

Task Showcase モード — 再実行可能ダッシュボード

Webwrightは単発タスクだけでなく、反復実行可能なOdysseyタスクをダッシュボード化する仕組みも持つ。assets/task_showcase/配下の小さなFlaskアプリで、デイリーでの価格チェック、在庫モニタリング、ジョブボード巡回、天気サマリ――そういった反復タスクを一覧で管理できる。

pip install flask
python assets/task_showcase/app.py    # http://127.0.0.1:5005

Webwrightにrenderer-ready形式でタスクを書かせるには、task_showcase.yamlを設定スタックに加える。

python -m webwright.run.cli \
    -c base.yaml -c model_openai.yaml -c task_showcase.yaml \
    -t "Find the top 10 deals on Amazon today under 1000 yen for kitchen items" \
    --task-id amazon_kitchen_deals \
    -o outputs/default

実行後はtask_showcase/tasks/<short_id>/にtask.json（メタデータ）とreport.json（ソース・テーブル・リスト・サマリ等の構造化結果）が出力される。

python assets/task_showcase/app.py \
    --tasks-dir outputs/default/<run>/task_showcase/tasks

これがWebwrightの第三の設計ポイントだ。1回の実行から、再実行可能なタスク・再利用可能なツール・閲覧可能なダッシュボード――この3つが同じワークスペースから生まれる。

設計判断とトレードオフ

Webwrightの設計は強い意見の塊だ。「とにかく軽量」「フレームワーク不使用」「ブラウザは使い捨て」――それぞれにメリットと裏返しがある。

これらは「悪い」ではなく「Webwrightが優先したもの」のリストだ。フレームワークが何でも吸収してくれる時代の安心感を捨て、エンジニアが読める・修正できるコードベースを優先している。

こんなチームに向く / 向かない

特にClaude Code / Codexを既に開発に使っているチームには、プラグイン版Webwrightは追加コストなしで導入できるため、まず試す価値が高い。

関連オープン研究との位置づけ

Webwrightの登場は、ブラウザエージェント研究における「コードas Action」アプローチの正当性を示す材料となる。同じ流れに位置する研究を整理しておく。

• SWE-agent / mini-swe-agent — WebwrightがREADMEでクレジットしている設計インスピレーション源。コード作成タスクで「ターミナル+ファイル編集」のミニマルなアクション空間が高性能を出すことを示した
• Code-as-action (CodeAct, CodeR) — ツール呼び出しではなくPythonコード生成をアクションとして扱う研究系統
• Online-Mind2Web / Odysseys ベンチマーク — Webwrightが性能評価に使用。実Webサイト・長期タスクという従来から最も難しいとされた評価軸

これらの流れの中でWebwrightが新しいのは、実装の小ささとプラグインとしての配布性だ。論文付属のリサーチコードではなく、Claude Code / Codexプラグインとして実装まで完結している点で、研究と運用の境界をまたいでいる。

まとめ — 「軽量・フォーカス・読める」がもう一度勝つ

Webwrightが示すのは、AIエージェントの世界で「フレームワークの分厚さ」がもはや競争優位ではないという事実だ。~1.5k LoC・4依存・~450行のエージェントループという極小スタックが、Online-Mind2Webで86.7%、Odysseysで60.1%――同じモデルで座標予測アプローチを27ポイント上回るSOTAを叩き出している。

その鍵は3つに要約できる。

1. コードas Action――モデルがPlaywrightスクリプトを書ける時代に、1クリック予測は最適解ではない
2. ワークスペースas State――ブラウザではなくコードとログが永続成果物、長期タスクで誤差が蓄積しない
3. プラグイン配布――Claude Code・Codex・OpenClaw・Hermesにそのまま乗り、追加コストなしで強化される

Microsoft Researchが論文を書くだけでなく、Claude Code / Codexプラグインとして配布まで完結させた事実は、エージェント研究と開発者ツールの距離が急速に縮んでいることを示す。あなたが既にClaude Codeを使っているなら、Webwrightは追加APIキーなしで明日から使える。試してみる価値は十分にある。

参照ソース

• microsoft/Webwright — GitHubリポジトリ
• Webwright: A Terminal Is All You Need For Web Agents — Microsoft Research Blog
• Webwright Project Page
• SWE-agent / mini-swe-agent — 設計インスピレーション源
• Playwright公式ドキュメント