BrowserGym を採用する前に見るべきもの: Gym 環境としての Web エージェント評価基盤

Web エージェント研究で散らばりがちな評価環境を一つのインターフェースに寄せる

Web エージェントの評価は、これまでベンチマークごとに操作手順も観測形式もバラバラになりやすかった。MiniWoB で動くエージェントを WebArena に持っていくには、環境側のコードをかなり書き換える必要がある。BrowserGym が解こうとしているのはこの問題で、複数のベンチマークを Gymnasium の環境として登録し、共通の reset() と step() で扱えるようにする。対象読者は、LLM を使った Web 操作エージェントを研究・評価している開発者である。README の冒頭警告は「Web エージェント研究分野を加速するための、開かれた拡張しやすいフレームワーク」と位置づけたうえで「消費者向け製品ではない」と明言しており、業務システムへの組み込みを想定した作りではないことが先に示されている。

AbstractBrowserTask を継承するという拡張の一点集中

BrowserGym の構造上の要は browsergym.core.task.AbstractBrowserTask で、README は新しいベンチマークを作るにはこのクラスを継承するだけでよいと説明している。つまりタスク定義、開始 URL、検証ロジックをこの抽象クラス側に寄せ、実行側は Gymnasium のレジストリから env_id で引く形になる。利用時は import browsergym.miniwob のようにベンチマーク別パッケージを import すると、そのタスク群が gym.envs.registry に登録される。登録済みのタスクは env_ids = [id for id in gym.envs.registry.keys() if id.startswith("browsergym/miniwob")] のように接頭辞で列挙できる。ブラウザ操作そのものは Playwright が担い、README のセットアップでは playwright install chromium を実行するよう指示されている。観測と行動のループは環境側が持ち、エージェント側は action を組み立てて step に渡すだけでよい。

同梱されるベンチマーク群と、それぞれが持ち込むセットアップの重さ

デフォルトで含まれるのは MiniWoB、WebArena、WebArenaVerified、VisualWebArena、WorkArena、AssistantBench、WebLINX（静的ベンチマーク）、OpenApps、TimeWarp である。パッケージは用途別に分割されていて、browsergym が全部入り、browsergym-core がベンチマークなしの openended タスクのみ、ほかは core に各ベンチマークを足した構成になっている。ここで注意したいのは、pip で入れて playwright install chromium を済ませただけでは終わらない点だ。README は各ベンチマークに固有の追加手順があるとして、miniwob、webarena、webarena_verified、visualwebarena、assistantbench については各 README を、WorkArena と OpenApps と TimeWarp については外部ドキュメントを参照するよう案内している。特に WebArena 系は自前のサービス群を立てる必要があり、環境構築のコストはベンチマークごとに大きく異なる。

openended タスクと wait_for_user_message の使いどころ

ベンチマークを使わず、任意の URL から始める対話的なタスクも用意されている。README の例では gym.make("browsergym/openended", task_kwargs={"start_url": "https://www.google.com/"}, wait_for_user_message=True) のように生成し、reset() のあと terminated か truncated になるまで step を回し、最後に env.close() で解放する。wait_for_user_message=True は、エージェントがチャットへ送ったメッセージごとにユーザー入力を待つ挙動だと説明されている。ここは評価ではなくデモや人手を交えた対話に向いた設定で、自動評価のループにそのまま使うと毎ステップで停止する。逆に wait_for_user_message を外せば完全自動のループになり、GPT-4V エージェントの実行例が README の動画で示されている。

研究基盤として割り切るべき制約

最もはっきりした制約は README 自身が書いている。BrowserGym は消費者向け製品ではなく、注意して使うようにという警告である。これは単なる定型文ではなく、API の安定性や後方互換の保証が研究用途の水準にとどまることを示唆する。実際、リリース履歴には v0.14.3.dev4 のような開発版タグが並び、バージョン番号が 0.x のままである。もう一点、ライセンスは NOASSERTION と記録されており、README のバッジは MIT と Apache-2.0 の両方を指すリンクになっていて、どちらが適用されるのか外部からは判別できない。組織で使う場合は、ここを最初に確認しないと後で困る。加えて、ブラウザを実際に起動して操作する性質上、WebArena 系のように自前サービスを立てるベンチマークではマシンリソースとネットワーク構成の検討が避けられない。

AgentLab との役割分担、あるいは自前ループを書くという選択

同じ ServiceNow が公開している AgentLab は、BrowserGym 上のベンチマークでエージェントを実装・テスト・評価するためのフレームワークだと README が案内している。BrowserGym 本体が環境とタスク定義を担い、実験の進行や評価の集計は AgentLab 側に寄せる、という分担である。対照的に、素の Gymnasium ループを自分で書く道もある。README のサンプルコードはまさにその形で、obs, info = env.reset() から始めて action を自作し、obs, reward, terminated, truncated, info = env.step(action) を回す。単一ベンチマークで特定の仮説を検証したいだけなら、AgentLab を挟まずこの短いループで足りる。逆に複数ベンチマークをまたいだ比較や実験管理が必要なら、ループを自作すると再発明が増える。どちらを選ぶかは、比較するベンチマークの数で決めるのが現実的である。

導入前に潰しておくべき確認事項

最初に確認するのは、使うベンチマークの追加セットアップが自組織の環境で再現できるかである。WebArena や WorkArena は外部サービスの構築を前提とするため、ここが通らなければ BrowserGym の利点である横断比較は成立しない。次にライセンスで、リポジトリの表記は NOASSERTION、README のバッジは MIT と Apache-2.0 を指しており、どちらが実際の条件かは外部から確定できない。法務判断は別途必要だが、少なくとも採用可否を決める前にここを埋めておきたい。三つ目はバージョンの追随コストで、開発版タグが継続的に出ている以上、固定バージョンで運用する前提を置くべきか、常に最新を追う前提で組むかを先に決めておく必要がある。

編集部の結論

採用を検討すべきなのは、Web エージェントの研究やベンチマーク比較を目的とし、Gymnasium の reset/step インターフェースに慣れたチームである。逆に、社内業務の自動化や消費者向けツールとして使いたい場合、README 自身が「消費者向け製品ではない」と警告しており、対象外と考えるのが妥当だ。導入前に確認したいのは、使うベンチマークごとの追加セットアップ手順と、ライセンスが NOASSERTION 表記である点の実際の条件である。

公式情報源

1. Issues
2. README
3. Releases
4. ServiceNow/BrowserGym on GitHub