agent-browser レビュー: AI エージェント向け Rust 製ブラウザ操作 CLI の実力と注意点

AI エージェントのブラウザ操作はなぜ難しいか

AI エージェントがウェブを操作するとき、DOM を直接触らせるのは危険です。セレクタが壊れやすく、ページの構造が変わると即座に失敗します。agent-browser はこの問題に対して、スナップショットによる参照指定という方法を取っています。`agent-browser snapshot` でアクセシビリティツリーを取得し、各要素に `@e2` のような参照を割り当てます。エージェントはこの参照を使ってクリックや入力を行うため、CSS セレクタの変化に強くなります。これは従来のセレクタ指定とは一線を画す設計です。

インストールとセットアップの実際

インストール方法は複数あります。npm のグローバルインストールが推奨されており、`npm install -g agent-browser` でバイナリが入ります。その後 `agent-browser install` を実行すると、Chrome for Testing から Chrome がダウンロードされます。既存の Chrome や Brave、Playwright、Puppeteer のインストールは自動検出されるため、無駄にダウンロードすることはありません。Homebrew や Cargo からのインストールも可能で、ソースからビルドする場合は Node.js 24 以上と pnpm 11 以上、Rust が必要です。Linux では `agent-browser install --with-deps` でシステム依存ライブラリを導入できますが、パッケージマネージャがすべてのライブラリを入れられない場合は終了コードが非ゼロになります。ここは環境によって詰まる可能性があるので、最初に確認すべき点です。

スナップショットと参照指定の仕組み

`snapshot` コマンドはアクセシビリティツリーを出力します。各要素には `@e1`, `@e2` のような参照が付与され、`click @e2` や `fill @e3 "test@example.com"` のように使います。この方式の利点は、エージェントが要素を探すために複雑なセレクタを考える必要がないことです。ただし、クリック時に別の要素が対象のクリックポイントを覆っていると、早期に失敗します。たとえば同意バナーやモーダルが被さっている場合です。README は、その覆っている要素を操作してから、新しいスナップショットを取り直すよう指示しています。つまり、ページの状態が変わったら参照は古くなるため、毎回スナップショットを取り直す運用が前提です。これはエージェント側のループ設計に影響します。

read コマンド: ブラウザを起動しないテキスト取得

`read` は URL を指定すると Chrome を起動せずにテキストを取得します。`Accept: text/markdown` ヘッダを送り、レスポンスがマークダウンでなければ `.md` を付けて再試行し、祖先パスを辿って `llms.txt` を探します。最終的に HTML から可読テキストを抽出します。`--outline` で見出しの概要を、`--llms index` で近くの `llms.txt` のリンク一覧を表示できます。URL を省略すると、現在のブラウザセッションのアクティブタブのレンダリング後 DOM を読みます。ここにはブラウザの認証状態やクライアントサイドの更新が反映されます。これは便利ですが、`--llms` や `--require-md` は HTTP リソースに依存するため、URL なしでは使えません。また `--require-md` はサーバーが `Content-Type: text/markdown` を返さないと失敗します。この挙動は、ドキュメントサイトを対象にした読み取りに特化しており、動的なページには向いていません。

従来のセレクタも使えるが、設計思想は別にある

agent-browser は `click "#submit"` のような従来の CSS セレクタもサポートしています。`find role button click --name "Submit"` のように ARIA ロールやテキスト、ラベル、プレースホルダー、`data-testid` による意味的なロケータもあります。これらは従来の自動化ツールと同じ発想ですが、スナップショット参照が主軸です。セレクタはページ構造の変化に弱いため、エージェントのループでは参照を使うのが推奨されていると読めます。実際、README のクイックスタートはすべて参照で完結しています。つまり、このツールは人間が書くテストスクリプトよりも、AI エージェントが自律的に操作することを強く意識しています。

制限と失敗モード: カバーリング要素とスクロールバー

先に述べたカバーリング要素の問題は、よくある失敗です。同意バナーやモーダルがクリックを阻害するとき、エージェントはその要素を先に操作する必要があります。これは自動化の難しさをそのまま反映しています。また、ヘッドレス Chromium のスクリーンショットはネイティブのスクロールバーを非表示にします。一貫した画像出力を得るための仕様ですが、`--hide-scrollbars false` を渡せば表示できます。このオプションは起動時にしか効かないため、セッション途中で変更できません。さらに、`read` の URL 指定はブラウザを起動しないため、JavaScript で動的に生成されるコンテンツは取得できません。そういうページはアクティブタブの `read` を使う必要があります。

セッション再利用とアップグレードの運用

agent-browser はブラウザセッションを再利用できます。`open` で起動したブラウザは、`close` するまで同じセッションが続きます。これにより、ログイン状態を保ったまま複数のコマンドを実行できます。`get cdp-url` で CDP の WebSocket URL を取得できるため、DevTools プロトコルを直接触ることも可能です。アップグレードは `agent-browser upgrade` で、npm か Homebrew か Cargo のインストール方法を自動検出して適切なコマンドを実行します。ライセンスは Apache-2.0 なので、商用利用も含めて自由度が高いです。ただし、依存する Chrome for Testing のダウンロードは初回に必ず発生します。オフライン環境では事前にバイナリを用意する必要があります。

代替ツールとの比較: Playwright と Puppeteer

既存のブラウザ自動化ツールと比較すると、agent-browser の独自性が明確になります。Playwright や Puppeteer はライブラリとしてコードから操作する前提で、Node.js のランタイムが必要です。agent-browser はネイティブの Rust バイナリとして動作し、Node.js はソースビルド時のみ必要です。また、セレクタではなくアクセシビリティツリーの参照を使う点は、エージェント向けに最適化されています。一方、Playwright は複数ブラウザのサポートやネットワーク傍受、トレース機能など、テスト自動化に特化した機能が豊富です。agent-browser は CLI として単純な操作に絞っているため、複雑なシナリオをコードで制御したい場合は Playwright の方が適しています。

編集部の結論

AI エージェントにブラウザ操作を任せたい開発者、特に Rust や Node.js のエコシステムにすでに慣れている人には有力な選択肢です。一方、ブラウザ操作を単発のスクリプトで完結させたい場合や、WebDriver 標準に依存したい場合は、Playwright や Puppeteer の方が適しています。導入前に、Linux では `agent-browser install --with-deps` がシステム依存関係を確実に導入できるか、既存の Chrome が自動検出されるかを確認してください。また、`read` コマンドの `--llms` や `--require-md` の挙動は HTTP リソースに依存するため、オフライン環境では使えない点を把握しておく必要があります。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes