HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

ブラウザエージェントの苦い教訓

The bitter lesson of browser agents (browser-use.com)

9 pointsby gregpr072 コメント

要約

AIエージェントがウェブページを操作する際、当初は定義された状態とアクション空間に制約されていましたが、モデルのコーディング能力向上に伴い、コード実行や直接的なChrome DevTools Protocol (CDP) へのアクセスへと移行しました。この進化により、エージェントはより柔軟にページを理解し操作できるようになりましたが、根本的な課題は、モデルに「何を見るか」を自由に選ばせることだと結論づけています。

全文翻訳

2026年9月15日 ブラウザエージェントの苦い教訓 2024年11月にBrowser Useをローンチしたとき、GPT-4oはコンピューター使用のためにトレーニングされていませんでした。次トークン予測に基づいて構築されていたため、ページ上で何ができるかを確実に理解できませんでした。私たちはそれを明示的に指示する必要がありました。モデルのコーディング能力が向上するにつれて、定義済みの状態とアクションからコードへと移行しました。最初はモデルがアクションを書き、次に観察結果を書き、今では生のCDPを通じて、既存のエージェントハーネス内で両方を行っています。 状態とアクション空間の定義 私たちは状態を定義しました。ページ上のもの、クリック可能なもの。次にアクション空間を定義しました。クリック、タイプ、スクロール。すべてのインタラクションはそのルールに適合する必要がありました。私たちの初期のループでは、モデルが見たり行ったりできることを私たちが選択しました。モデルがアクションを選択し、それを実行し、次の状態を返しました。しかし、ブラウザ自動化はエッジケースのゲームです。すべての例外には別の修正が必要でした。 固定アクションをコードに置き換える モデルのコーディング能力は大幅に向上していました。2025年9月にJavaScript実行、10月に永続的なノートブックを実験しました。モデルはアクションを選択する代わりにプログラムを書くことができました。アクションを書かせましょう。まだ私たちのページ状態です。コードは説明的です。署名を描いたり、コメントをループしたりするために、新しいアクションは必要なくなりました。変数が永続化されたため、モデルは結果を検査して続行できました。Hermesエージェントは、Browser Use CLIを搭載したbrowser_execによって12のブラウザツールを置き換えました。Opus 4.8では平均トークン使用量が60%、Kimi K3では66%減少しました。どちらのバージョンも、モデルごとに18/18回の実行(6つのタスク、3回の実行)を解決しました。 定義済み状態の限界 私たちはアクションを開放しましたが、モデルが見ることができるものは依然として私たちが決定していました。それが次の問題になりました。クッキーボタンが画面のすぐそばにあるのに、送信する状態から欠落していることがあります。アクセシビリティツリーがそれを公開していないか、私たちの処理がそれをドロップしているのかもしれません。いずれにしても、モデルはそのボタンを見ることはありませんでした。ボタンはそこにあります。私たちはそれを表示できなかっただけです。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コマンドは説明的です。ブラウザには依然として状態があります。消えるのは、すべてを単一の定義済み表現に適合させるという私たちの要件です。スクリーンショットは一つの質問に答えるかもしれません。DOMクエリは次の質問に答えるかもしれません。モデルは何を見る必要があるかを決定します。 なぜPlaywrightではなくCDPなのか? CDPはChromeのネイティブ制御プロトコルです。モデルはそれを直接使用できます。Chromeの場合、CDPはPlaywrightのブラウザAPIの下にあるモデルへのアクセスを提供します。Playwrightは、閉じられたシャドウルートを見ることができないロケータのような仮定を追加します。CDPはそれらのルートを直接検査できます。PlaywrightもCDPを公開しています。私たちは直接アクセスをデフォルトにしました。 シンプルなブラウザハーネス Pi、Codex、OpenCodeはすでにエージェントループを処理しています。コーディングエージェントは何百万ものユーザーがさまざまな種類の作業を試しています。そのテストは、それらのハーネスを再利用する理由です。QAに入って5時間経ったエージェントが、ループのバグのために失敗すべきではありません。私たちはかつて、コンパクションが生成されすぎてすぐに再びコンパクションを引き起こしたことがあります。お客様はそれらのバグを発見する必要はありません。私たちはシンプルなブラウザツールを追加します。永続的なコード、テキスト、スクリーンショット、エラーがモデルに戻ってきます。CLIまたはツール呼び出しがエージェントをCDPに接続します。2026年1月のAgent SDKから4月のBrowser Harnessまで、これが方向性となりました。Browser Harness、BrowserCode、Browser Use Piはそれぞれ異なるアプローチを取っています。すべてモデルが何を見るか、何をするかを選択できるようにします。 ここでの本当の苦い教訓は何でしょうか? Suttonの苦い教訓は、より多くの計算で改善される一般的な方法を支持します。私たちにとって:実績のあるエージェントハーネスを再利用する。モデルがうまく使用できる最も単純な基盤インターフェースを公開する。モデルに観察結果とアクションを選択させる。ブラウザ、コンピューター、テキスト、音楽:同じ原則が適用されます。モデルが変わるにつれて、ハーネスを再考してください。