ブラウザ使用向けスケーラブルな長期 RL 環境の構築手法を公開

ブラウザエージェントのベンチマークは飽和状態にあります。一年前ならモデルの差を明確に示せたタスクセットも、今では正答率が 90% を超えることが珍しくありません。良い強化学習環境には、優れたベンチマークタスクに必要な要素がすべて揃っている必要がありますが、その構築は決して容易ではありません。

まず、タスクは実在するものでなければなりません。合成されたサイトクローンは再現性が高く検証コストも安いですが、生きたウェブの複雑さを支える重要な特性を失ってしまいます。さらに、両者に必要なのは公平で安定した報酬です。良質な作業と劣悪な作業を見分けることのできる審査員が不可欠です。

本稿では、実際のユーザートラフィックを活用してリアルなウェブ上で強化学習環境を構築する方法について解説します。私たちはこれらの環境を継続的に生成しており、今回オープンソース化する 200 の環境はその一部に過ぎません。ソースは、ブラウザエージェントのタスクに関する当社の生産用コーパスを匿名化したものから派生しています。つまり、すべてのタスクが「誰かが実際に実行したかったこと」に基づいており、「著者が想像する必要があるかもしれないこと」ではありません。

この問題においてより困難な側面は報酬設計です。以下では、各タスクに対する全試行結果から評価基準（ルブリック）を構築し、ライブウェブ上で検証し、凍結されたトレースを再評価することでその安定性を測定する方法について詳述します。

1. タスクの絞り込み

ソースとなるコーパスは、収集期間中に集められた実際のブラウザエージェントのトラフィックです。タスク提出数は数億件に及びますが、その大部分は重複しているため、類似したタスクを統合して約 1,000 万件の固有タスクに絞り込みました。

第三者が実行できない、あるいは閲覧すべきではないタスクは除外しています。具体的には、ローカルネットワークアドレスやローカルファイルを扱うもの、英語であるという確信が持てないもの、文字数が 25〜20,000 の範囲から外れるもの、また報告する結果を汚染する恐れのある既知の公開ベンチマークコンテンツに一致するものです。

すべてのタスクは、利用権および販売権を保有するソースから取得しており、データ使用が制限された契約下のトラフィックは一切コーパスに含まれません。

2. 適合性

実際のユーザータスクの多くは、テキストだけを見てもその理由が明白なため、実用的な環境を構築できません。いくつかは検索エンジンやモデル自身の知識で即座に回答できてしまうほど簡単です。また、ブラウザの使用自体が必要ないケースもあります。個人情報を含むタスクも存在します。さらに、フォームの送信や購入など、ライブサイト上で破壊的または不可逆的な操作を行うタスクもあり、これらは評価ごとに繰り返し実行することができません。原文のままでは不可能なタスクもあれば、判定者が判断できるほど明確でないタスクもあります。

実行にコストをかける前に、大規模なデータセット全体で専門家の適性判断を再現する、低コストのフィルタが必要です。

2.1 手動ラベリング

ベンチマークへの経験を活かし、適切かつ困難なタスクを選別するために、12 時間のスプリントで 900 のタスクを手動でラベル付けしました。各タスクには「適している」「不適切」「不確実」のいずれかの評価と、その理由が記されました。これらの理由が、本節以降のすべての判断基準となります。

2.2 ラベリングエージェントの整合性

タスクテキストのハッシュ値に基づき、ラベルを決定論的に分割しました。開発用として 80%、検証用に 10% を確保し、最終テスト用として 10% をシール（非公開）にしました。この分割は固定されており、再計算されることはありません。

プロンプトの作成も自動化しました。Claude Fable 5 をベースに構築された自動研究エージェントが、人間が記した理由付けデータと開発用データの分割結果を受け取り、「Gemini 3 Flash に対して単一のプロンプトを生成し、それによって人間のラベルリング結果を再現する」という唯一のタスクを与えられました。このエージェントは複数のバリエーションを提案し、合意スコアに基づいて評価・選別を繰り返しました。その結果、最終的に採用されたのは 21 バージョンのプロンプトの中から選ばれたものです。

固定されたプロンプト条件下でのモデル比較により、小規模モデルの採用が最適であることが確認されました。Gemini 3 Flash は、より大きな候補モデル群と比較して約 5 分の 1 のコストで最高レベルの合意率を達成しました。一方、大規模モデルは過度に保守的であり、私たちが適切と判断したタスクまで却下してしまう傾向がありました。

実際に導入されたプロンプトは、開発用データではラベルリング結果との一致率が 77% に達し、未見のシールドテストセットでは 81% の精度を記録しました。また、発見された適切なタスク 1,000 件あたり約 20 ドルのコストで運用可能です。候補となる全サンプルに対してこのプロンプトを実行した結果、全体の約 13% のタスクが適切と判定されました。

3. Personal Data Replacement

実際のユーザータスクには機密情報が含まれており、それらを製品に含めることはできません。単純な対応策として「検出して削除する」方法がありますが、これは本質的に誤りであり、成果率を大きく損なうことになります。

実際には、多くのタスクにおいて個人情報は作業の本質とは無関係な付随情報です。そのような情報を理由にタスクごと廃棄するのは、依存していない詳細部分を排除するために全体を捨てるようなものです。

そこで私たちは異なる基準を採用しました。「標準的なダミーのペルソナにすべての個人情報を書き換えても、タスクが実行可能で成功できる場合」には、そのタスクは適切と判断します。この問いには明確な答えが存在し、個人情報の問題をフィルタリングから書き換えへと転換させることができます。

ただし、書き換えによって作業内容が保てない場合や、特定の個人情報組み合わせで個人を特定できる場合は廃棄します。文字列置換だけではこれを回避できないからです。

置換処理は、実際のサイト上で動作し続ける必要があります。タスクが米国以外の場合には、その国のユーザー像に合わせてペルソナを調整します。すべての置換はコード内で厳密な文字列の置き換えとして行われ、対象となる文字列が存在することを確認した上で行われるため、モデルが周囲の文章を書き換えることも、タスクの意味を変更することもありません。

4. 実現可能性と難易度

最初の2つのフィルタを通過したタスクは、構造的には問題ありません。しかし、実際に実行可能かどうか、あるいは難しいものかどうかはまだわかりません。

エージェントの能力とは無関係に、現在では不可能なケースがあります。例えば、前段階で削除されたアカウントや個人資産に依存していた場合です。また、情報が古くなって利用できなくなっているケースも少なくありません。これは「以前は可能だったものが現在は不可能になった」というタスクの最大の原因となっています。そもそも最初から不可能だったタスクも存在します。

さらに別の要因として、タスクが単純すぎて役に立たないというケースがあります。この場合、構造的には問題なく実行も可能ですが、モデル間の性能差を評価する用途としては不適切です。

これらはいずれもタスク記述には含まれておらず、そのためセクション 2 で生き残ることになります。ただし、実際の試行ではごく少数のケースでしか出現しないため、画面を実行する必要があります。ここでは Fireworks 上で提供される MiniMax M3 を使用して実行します。参照モデルは強力である必要はありません。重要なのは、一貫性があり、多数回実行できるほどコストが安く、かつ失敗事例から意味のある洞察を得られる程度の品質があれば十分です。この画面に到達した適切に構造化されたタスクのうち、約 40% が「可能であり、かつ維持する価値がある」として通過します。

5. 評価における課題

実行による選別には評価者が必要ですが、その要件は一見すると不可能に見えます。現在の最先端モデルでも、これらのタスクを完璧に完了できるのは 10% に満たないからです。では、同じ最先端モデルで動作する評価者が、どのような状態が「完璧な完了」なのかをどう判断すればよいのでしょうか？これが、多くの LLM 評価者が陥る罠です。つまり、「審査員はエージェントよりも賢くある必要はない」という点を見落としているのです。

しかし、可能なのです。なぜなら、評価と解決は異なる問題だからです。評価者は必ずしもエージェントより賢い必要はありません。重要なのは「より多くの事例を知っている」ことです。実際、人間の評価者もこのように動作しています。ある試験問題に割り当てられた評価者は、その問題に対するすべての回答を精査します。十分な数の回答を経験した後には、正解だけでなく、よくある誤りのパターンや、「正しそうに見えるが実は間違っている」回答の特徴も把握しています。これらすべては、その場でもっとも数学的な知識を持つ必要から生まれるわけではありません。むしろ、一人の学生が経験できない「ある問題に対するすべての試行の分布全体」を評価者が把握しているからこそ可能になるのです。

呼び出しのたびに言語モデルは情報を保持しないため、私たちは手動でその露出を蓄積する必要があります。推論時にモデルが利用可能な最良の学習データは、そのモデル自身のコンテキストです。そのため、各タスクに対してグラダーが書き込み・読み取りを行うファイルを用意します。このファイルには、その特定のタスクについて私たちが確立した情報が格納されます。具体的には、正解是什么か、どの経路で到達できるか、どのような失敗が再発し、トレース上でどのように現れるか、そしてエージェントが真偽不明な主張をどう行っているかなどです。このファイルはグラダーのみが利用でき、エージェントには決して提供されません。

私たちはこれを「ルーブリック」と呼びます。これは人間が作成する評価基準の模倣に由来する名称です。本報告書の残りの部分は、正確で安定したルーブリックをいかに構築するかについて主に論じるものです。なぜなら、正しくも安定でもないルーブリックは、ルーブリックがないことよりも悪いためです。それは自信を持って再現可能な誤ったスコアを生み出すからです。

6. 難易度の推定

タスクの難易度を特定するには、ジレンマが存在します。スコアリング実行には完成したルーブリックが必要であり、ルーブリックの作成にはスコアリング済み実行が必要です。成熟したルーブリックができるまで待ってから候補をスクリーニングするとすれば、自明に簡単すぎるものや壊れているものを含め、すべての候補に対してフルコストの実行費用を支払うことになります。

そのため、トレース収集の最中に提出された難易度推定を受け入れる必要があります。各評価が完了するたびに、グラダー（評価者）は学習した内容をタスクのルブリックファイルに記録し、次の評価ではその内容を読み取ります。このルブリックは、これまでの実行結果から導き出せるタスクの最も適切な記述です。

初期の評価ではルブリックがほぼ空の状態であるため、正確なマッチングは困難です。一方、後続の評価では実在する失敗パターンが蓄積されたルブリックに基づいて行われるため、より信頼性が高まります。この仕組みで十分なのは、スクリーニング判断において「全員が完了できるタスク」と「誰も着手できないタスク」を区別できればよく、かつ各候補に対して低コストで実行可能だからです。

スクリーニング自体は早期打ち切りを備えた逐次テストです。多くの候補者は最大実行回数に達する前に判断がつくため、この方式が採用されています。

パス率ゼロのタスクは、困難なものと不可能なものを区別するために、より強力なモデルである Claude Opus 4.8 にエスカレーションされます。ある試行では、エスカレーションされたタスクのおよそ 3 分の 1 がこの強力なモデルによって完了し、「困難だが可能」としてプールに追加されました。そのうち約半数は実質的な部分的進捗を示し、残りは不可能と確認されたか、保留状態となりました。

7. ルール（ルブリック）の構築

スクリーニング段階で反復的に作成されたルールは、最終的に出荷されるものではありません。ここではその理由と、実際に出荷されるルールの作り方を説明します。ユーザーからのタスク指示を「個人的な依頼」という表現に書き換え、フォーマットの詳細を標準化・匿名化しつつ、すべてのタスク指示内容は保持しています。

7.1 なぜ反復的なルールは収束しないのか

セクション 6 で議論されたルールの改善ループが、十分な回数繰り返されれば完璧なルールに収束すると考えるのは自然です。各判断が情報を追加するため、ルールはタスクの正しい記述に近づき、その後変化しなくなるはずです。しかし実際にはそうならず、その原因は構造的なものです。

このループ内のすべての審査員は、一度に一つの実行履歴しか見ることができません。あるエージェントの主張を別のエージェントの主張と比較することも、その主張を実際のサイトと照合して検証することも不可能です。あるページにリストが 7 つあると自信を持って、しかし誤って述べた場合、審査員にはそれを疑う根拠がありません。その数字は「確立された事実」として評価基準（ルブリック）に書き込まれてしまいます。その後のすべての判断では、それが絶対的な真実として読み取られてしまいます。もしこれが誤りだったとしても、このループ自体が修正を行うことはなく、評価基準を手動で修正されるまで、将来の正しい回答すべてを不当に減点し続けます。

私たちはデータを観察してこの現象を確認しました。私たちが重視するタスクにおいて、編集頻度は低下しません。困難なタスクでは、9 回目のラン（試行）においてもなお編集率は 59% に達していました。評価基準は異なる解釈の間で揺れ動き、永遠に自己修正を繰り返す状態でした。

7.2 私たちが代わりに採用する並列型評価基準

タスクの難易度を推定し、挑戦的なタスクを選定した後は、各タスクの解決策空間を探索するために多様な試行が必要です。私たちは 9 つのモデルをそれぞれ 2 回ずつ実行するファーム（群）を運用しています。使用するのは以下の通りです：Claude Opus 5、GPT-5.6 Sol、GPT-5.6 Luna、GPT-5.5、Gemini 3.1 Pro、Gemini 3.7 Flash、Gemini 3 Flash、Grok 4.5、MiniMax M3。

Claude Fable 5 を基盤とした単一のエージェントが、各評価基準（ルブリック）を記述します。多数の試行記録は、反復的な判定プロセスで見つかった課題とともにファイルとして保存されます。このエージェントは、関連する文脈を取得するために試行記録を体系的に検索し、実際のウェブ環境と照合して検証を行います。これにより、真実（グラウンドトゥルース）と有効なパスが特定されます。

スクリーニング判定はこのプロセスの入り口となります。評価基準としての安定性は低いものの、試行記録間で疑われる問題に関する豊富な履歴を提供します。エージェントは主張された欠陥を確認するために該当する試行記録を開き、それが実際に存在するかを判断します。これらの判定結果から得られた情報は信頼に頼って引き継がれることはなく、スコアや結論も再利用されません。

試行記録の段階を通過した候補は、最終的に現実世界との整合性チェックを受けます。エージェントはライブブラウザを開き、今日時点での実際のサイトに対して、自分が根拠とする事実を検証します。記録されるすべての事実は、検証が行われた日付と共に付与されます。「この値はサイトのどこにも存在しない」といった否定形の事実は、普遍的な否定命題は反証不可能であり証明もできないという性質上、特別なマークとして区別して扱われます。

7.3 良いルブリックの特性

良いルブリックとはどのように定義されるべきでしょうか。私たちが導き出した答えは以下の通りです。

すべての主張は容易に検証可能であり、誰がその主張を行ったかを明確にする必要があります。評価基準（ルブリック）はタスクとウェブサイトの両方に関する主張を含みます。これらは現実世界の状態についての主張であり、特定の日に記録されたライブサイトに対して検証済みです。誰でもサイトをオープンして直接確認できます。

採点者は発見事項を提示し、エージェントのトレースに関する主張を行います。各主張には、証拠が現れるステップを必ず引用する必要があります。人間であれば、審査員の主張を確認し、エージェントのトレース内でそれが真実かどうかを直接検証できるはずです。

評価基準も採点者も、決してスコア自体を発行しません。スコアはコードによって発見事項から計算されます。これこそが、アーティファクトをエンドツーエンドで監査可能にする理由です。パイプライン内の言語モデルのすべての出力は、人間が確認または反証できる具体的かつ位置付けられた主張であり、信頼に頼らなければならない判断は一切含まれません。

各項目は原子的です。各項目は一つの範囲内で一つの事柄のみをチェックするため、単一の欠陥が二度と罰せられることはありません。重みの合計は 100 となり、スコアは達成された項目の重みの合計で計算されます。項目間で「最良のものだけが勝つ」といったルールはなく、減点方式も採用されていません。そのため、部分的な加点は項目の細かさ（粒度）によって得られるものであり、単一の項目内での算術処理によるものではありません。

この順序こそが、報酬を不正に操作しにくくする理由です。捏造された作業は、すべての項目にトレーシング上の裏付け証拠が必要となるため、何の報酬も得られません。一方、誠実だが不完全な作業に対しては、その誠実さに応じた正当な報酬の一部が支払われます。また、各項目とは別に、採点者は報酬ハッキング、嘘、捏造が発生したかどうかを報告します。

項目ごとのスコアはまず通常通り計算され、その後、不正行為を示すフラグが立っていればそのスコアはゼロになります。つまり、不誠実さは「重み付けされた 1 つの項目を失う」という形で評価されることはありません。

7.4 不安定性を曖昧さの指標として

ベンチマーク、特に報酬設計においては、同じトレーシングデータに対して採点者が評価するたびに必ず同じスコアが出力される必要があります。言語モデルは非確定的な性質を持つため、多少の変動が生じることは避けられません。しかし重要なのは、その変動が均一に散らばっているわけではないという点です。

ほとんどの項目は、凍結されたトレーシングデータを再評価しても完全に安定しており、不安定性が発生するのはごく一部の項目に限られます。

意見が分かれたペアを読み返すと、同じ採点者でも 2 回の実行で項目の記述を異なる解釈し、境界線を引く位置が異なっていたケースが多いことがわかります。そこで私たちは、この不安定性をモデルからのノイズではなく、ルール自体の曖昧さを示すシグナルとして扱います。判定がひっくり返った項目こそが、どの文句を見直すべきかを示す手がかりとなるのです。

これは、タスクや評価基準のどこに曖昧さがあるかを測定可能な方法で特定する手段です。各項目は、同じ入力に対して「満たされる」と「違反する」の間で反転する頻度が高い順にランク付けされます。閾値を超えた項目については、トレーシングデータとライブウェブアクセス権を保持している元の評価基準作成エージェントに戻り、意見が分かれた発見結果のペアを並べて提示し、「2 人の独立した採点者が同じ判定を下す」ほど明確な意思決定ルールとして再記述するよう依頼します。このループは最大 3 回実行されます。

7.5 選別

すべてのタスクが生き残るわけではありません。欠陥の 3 つのクラスを順に除去しました。

*解決しなかった評価基準の曖昧さ*：3 回の改訂ラウンドを経ても項目が反転し続けるタスクはすべて除外しました。完全なトレーシングアクセスとライブ検証を伴う 3 回の試行をもってしても判断基準を決定可能にできない場合、問題なのは文章表現ではなくタスクそのものです。そのようなタスクから実用的な報酬信号を得ることは永遠に不可能です。

タスク解釈の分岐

異なるエージェントが同じタスクテキストを読み込み、真に異なる目標を追求します。すべての分岐が欠陥であるわけではありません。2 つのエージェントが同じ答えに至るために異なる経路を取ることもあります。しかし、2 つのエージェントが「何を求めているか」について意見が対立する場合、どちらの解釈にも合致する評価基準は存在しません。この場合、問題の原因はタスクテキストそのものにあります。唯一の解決策はタスクを明確化することですが、それにより既存の実行は無効となり、再収集が必要になります。ただし、明確化では「何をもって完了とみなすか」のみを定義し、「どのように行うか」については一切言及してはいけません。これにより、解法が漏洩するのを防ぎます。適切に行われれば、本来なら廃棄されてしまうような困難かつ価値の高いタスクの多くを救済できます。

時間的減衰

正解がまだ発生していない事象や、リリースサイクルよりも速く入れ替わるデータに依存するタスクは削除しました。未来の日付に固定されたタスクは、時間が経つと必ず誤りになります。これは現在の誤りよりも、より遅く、かつ深刻な失敗です。ライブ市場に関連するタスクについては、その変動性を日付付きの事実で管理するコストとして捉え、欠陥とは見なしませんでした。そのため、これらのタスクは優先度を下げて採用しました。

その結果、すべてのタスクに原子レベルで重み付けされた証拠付きのルーブリックが用意され、各事実には日付が付与されてライブサイトと照合済みです。また、凍結されたトレースを繰り返し評価しても、判定が反転する割合は 1% を下回る水準に抑えられています。

8. データの利用可能性

これらのタスクのうち 200 件とそのルーブリックのサンプルは、オープンソースとして github.com/browser-use/benchmark で公開されています。