ブラウザエージェントの苦い教訓
The bitter lesson of browser agents (browser-use.com)
要約
AIエージェントがウェブページを操作する際、当初は定義された状態とアクション空間に制約されていましたが、モデルのコーディング能力向上に伴い、コード実行や直接的なChrome DevTools Protocol (CDP) へのアクセスへと移行しました。この進化により、エージェントはより柔軟にページを理解し操作できるようになりましたが、根本的な課題は、モデルに「何を見るか」を自由に選ばせることだと結論づけています。
全文翻訳
ブラウザエージェントにおける苦い教訓
[画像: 独自のagent loop、定義済みのstate spaceとaction spaceは取り消し線が引かれている。Browser HarnessはPi、Codex、またはOpenCodeとbrowser_execを組み合わせる。][画像: 独自のagent loop、定義済みのstate spaceとaction spaceは取り消し線が引かれている。Browser HarnessはPi、Codex、またはOpenCodeとbrowser_execを組み合わせる。]
Browser Useを2024年11月にローンチした当時、GPT-4oはコンピューター操作のためにトレーニングされていませんでした。次トークン予測に基づいて構築されていたため、ページ上で何ができるかを確実に理解できませんでした。我々がそれを明示する必要がありました。
モデルのコーディング能力が向上するにつれて、我々は定義済みの状態と行動からコードへと移行しました。最初はモデルが行動を書き、次に観察結果を書いていました。現在では、既存のエージェントハーネス内で、生のCDPを通じて両方を行っています。
状態と行動空間の定義
我々は状態を定義しました。ページ上のもの、クリック可能なものなどです。そして行動空間を定義しました。クリック、タイプ、スクロールです。すべてのインタラクションはそのルールに適合する必要がありました。
[画像: 初期ReActスタイルのループ:ブラウザがページの状態となり、GPT-4oが推論し、固定されたアクションメニューからクリック、タイプ、またはスクロールを選択します。ブラウザは次の観察結果を返します。][画像: 初期ReActスタイルのループ:ブラウザがページの状態となり、GPT-4oが推論し、固定されたアクションメニューからクリック、タイプ、またはスクロールを選択します。ブラウザは次の観察結果を返します。]
初期のループでは、モデルが見てできることを我々が選択していました。
モデルがアクションを選択し、それを実行し、次の状態を返していました。しかし、ブラウザ自動化はエッジケースのゲームです。すべての例外には別の修正が必要でした。
固定アクションのコードによる置き換え
モデルのコーディング能力は向上していました。我々は2025年9月にJavaScript実行を、10月に永続的なノートブックを実験しました。モデルはアクションを選択する代わりにプログラムを書くことができました。
[画像: 同じループですが、アクションメニューはforループを持つモデル作成プログラムに置き換えられています。定義済みのページ状態はそのままです。変数とヘルパーは呼び出し間で永続します。][画像: 同じループですが、アクションメニューはforループを持つモデル作成プログラムに置き換えられています。定義済みのページ状態はそのままです。変数とヘルパーは呼び出し間で永続します。]
行動を書かせました。ページ状態はまだ我々のものです。コードは説明的です。
署名を描いたり、コメントをループしたりするために、新しいアクションは不要になりました。変数が永続するため、モデルは結果を検査して続行できました。
Hermesエージェントは、Browser Use CLIを搭載した
browser_execにより、12のブラウザツールを置き換えました。Opus 4.8では平均トークン使用量が60%減少し、Kimi K3では66%減少しました。両バージョンとも、モデルごとに18/18回の実行(6つのタスク、3回実行)を解決しました。
定義済み状態の限界
我々は行動の自由を与えましたが、モデルが見ることができるものはまだ我々が決定していました。それが次の問題となりました。
クッキーボタンが画面のすぐ近くにあっても、我々が送信する状態に含まれていないことがあります。アクセシビリティツリーがそれを公開していないか、我々の処理がそれを落としているのかもしれません。いずれにせよ、モデルはそのボタンを見ることはありませんでした。
[画像: ウェブサイトにはAcceptボタンが表示されていますが、抽出された状態リストにはArticleとRead moreしかありません。欠落しているボタンは、我々の処理がいかにボトルネックになったかを示しています。][画像: ウェブサイトにはAcceptボタンが表示されていますが、抽出された状態リストにはArticleとRead moreしかありません。欠落しているボタンは、我々の処理がいかにボトルネックになったかを示しています。]
ボタンはそこにありました。我々がそれを提示できなかっただけです。
EHRドロップダウンは次のように見えるかもしれません(簡略化されたDevToolsツリー):
<ehr-app>
#shadow-root (open)
<iframe src="https://ui.example">
#document <!-- other origin -->
<dropdown-menu>
#shadow-root (closed)
<button>Choose...</button>
我々の状態ヒューリスティックは、すべてのウェブサイトを予測することはできませんでした。モデルに行動の自由を与えましたが、それはまだ我々の仮定を通して見ていました。
定義済み状態の削除
観察結果も書かせたらどうなるでしょうか?
LLMにCDP(Chrome DevTools Protocol)への直接アクセスを与えました。必須のクリック可能要素リストはありません。DOMを検査したり、スクリーンショットを撮ったり、フレーム内を見たりするコードを書くことができました。
[画像: 以前は、抽出レイヤーがモデルに固定されたクリック可能要素リストを送信していました。現在、モデルはCDPコマンドを通じて観察対象を選択し、ブラウザは要求されたビューを返します。][画像: 以前は、抽出レイヤーがモデルに固定されたクリック可能要素リストを送信していました。現在、モデルはCDPコマンドを通じて観察対象を選択し、ブラウザは要求されたビューを返します。]
モデルが検査するものを選択します。CDPコマンドは説明的です。
ブラウザにはまだ状態があります。消えるのは、すべてを定義済みの単一表現に適合させるという我々の要件です。スクリーンショットは一つの質問に答えるかもしれません。DOMクエリは次の質問に答えるかもしれません。モデルは、何を見る必要があるかを決定します。
なぜPlaywrightではなくCDPなのか?
CDPはChromeのネイティブ制御プロトコルです。モデルはそれを直接使用できます。
[画像: Playwrightでは、エージェントコードはCDPの上に位置する追加レイヤーを介してChromeに到達します。Browser Harnessは、Playwrightレイヤーを削除しながら接続とランタイムを維持しつつ、CDPをエージェントのコードに直接公開します。][画像: Playwrightでは、エージェントコードはCDPの上に位置する追加レイヤーを介してChromeに到達します。Browser Harnessは、Playwrightレイヤーを削除しながら接続とランタイムを維持しつつ、CDPをエージェントのコードに直接公開します。]
Chromeの場合、CDPはPlaywrightのブラウザAPIの下のモデルにアクセスを提供します。
Playwrightは、クローズドシャドウルートを見ることができないロケーターのような仮定を追加します。CDPはそれらのルートを直接検査できます。PlaywrightもCDPを公開しています。我々は直接アクセスをデフォルトにしました。
シンプルなブラウザハーネス
Pi、Codex、OpenCodeはすでにエージェントループを処理しています。コーディングエージェントには、あらゆる種類の作業を試す何百万人ものユーザーがいます。そのテストは、それらのハーネスを再利用する理由です。
QAに5時間費やしたエージェントが、ループのバグのために失敗すべきではありません。かつて、コンパクションが大量のコンテキストを生成し、それがすぐに再びコンパクションを引き起こすという問題に遭遇しました。顧客がそれらのバグを発見する必要はありません。
永続的なコードと、モデルに返されるテキスト、スクリーンショット、エラーを備えたシンプルなブラウザツールを追加しました。
[画像: Pi、Codex、またはOpenCodeは、ChromeとCDP経由で通信するbrowser_execとコードおよび結果を交換します。][画像: Pi、Codex、またはOpenCodeは、ChromeとCDP経由で通信するbrowser_execとコードおよび結果を交換します。]
CLIまたはツール呼び出しがエージェントをCDPに接続します。
2026年1月のAgent SDKから、4月のBrowser Harnessまで、これが方向性となりました。Browser Harness、BrowserCode、Browser Use Piはそれぞれ異なるアプローチを取っています。すべてモデルが何を見るか、何をするかを選択できるようにしています。
ここでの本当の苦い教訓は何でしょうか?
サットンの苦い教訓は、より多くの計算で改善される一般的な方法を支持します。我々にとって:
- 実証済みのエージェントハーネスを再利用する。
- モデルがうまく使用できる最もシンプルな基盤インターフェースを公開する。
- モデルに観察対象と行動を選択させる。
ブラウザ、コンピューター、テキスト、音楽:同じ原則が適用されます。モデルが変化するにつれて、ハーネスを再考してください。