agent-browser：AIエージェントがCLIでブラウザを操作

背景と概要

AI エージェントにウェブページを操作させる作業は、長いあいだ手間のかかるものでした。初期の方法は大きく二つありました。一つはページ全体の HTML をそのままモデルに渡す方法で、コンテキストがノイズで埋まってしまいます。もう一つはスクリーンショットと座標によるクリックで、位置がずれやすく、操作の結果を確かめる手段も弱いという問題がありました。vercel-labs が公開した agent-browser は、この二つの問題を避けるために作られたツールです。

agent-browser は Rust で書かれたオープンソースのネイティブコマンドラインツールです。ブラウザを、エージェントがシェルコマンドを一つずつ実行して動かせる対象として包みます。位置づけははっきりしています。テストエンジニア向けの新しいフレームワークではなく、シェルから直接呼び出せる、エージェントのためのブラウザインターフェースです。GitHub では 4 万 8 千を超える star を集めており、多くの開発者が同じ悩みを抱えていたことがうかがえます。

ツールチェーン全体で見ると、実行層に近い位置にあります。上流には大規模言語モデルとエージェントフレームワークがあり、下流には Chrome と複数のクラウドブラウザ事業者があります。シェルコマンドを実行できるエージェントなら、複雑な SDK を組み込まなくても、これを使ってウェブ作業ができます。この導入の軽さが最大の魅力です。

深掘り分析

agent-browser は具体的に何をするのでしょうか。中心は「読む、操作する、もう一度読む」という循環です。snapshot コマンドはページをコンパクトなアクセシビリティツリーのテキストに変換し、各要素に @e1 のような ref 番号を付けます。example.com の場合、出力はリンクとその ref の 1 行だけです。エージェントはその ref を使って click @e1 のように操作し、再度スナップショットを取って結果を確認します。モデルが見るのは肥大した DOM ではなく意味のある構造で、座標を推測する必要もありません。 ここで注意点があります。ref はスナップショットを取った時点のページしか表しません。ページ遷移や DOM の変化があったら、取り直す必要があります。ref のほかに、CSS セレクタ、テキスト、XPath、そして役割と名前でボタンを探すようなセマンティックロケータも使えます。 もう一つ評価できるのは、クリックが成功を装わない点です。対象が非表示、無効、ビューポートの外にある、あるいは同意ダイアログのような要素で隠れている場合、コマンドはエラーを返します。エージェントは先に邪魔な要素を閉じてから再試行すべきだと分かります。 構成は単純です。CLI は各コマンドをバックグラウンドのデーモンに送り、デーモンが Chrome DevTools Protocol 経由でブラウザを制御します。ブラウザはコマンドの合間も開いたままなので、各ステップは短いシェル呼び出しで済みます。セッションごとに独立したデーモンとブラウザを持ち、既定では 1 時間アイドル状態が続くとヘッドレスブラウザを閉じてデーモンも終了します。セッション永続化を設定している場合は、先に状態を保存します。

導入手順も短く済みます。npm install -g agent-browser か Homebrew でインストールし、agent-browser install で Chrome for Testing をダウンロードします。この手順が必要なのは初回だけです。Linux では --with-deps を付けると、ブラウザに必要なシステムライブラリも入ります。試すだけなら npx agent-browser open example.com で直接動かせます。典型的な流れは、open でページを開き、snapshot -i で操作可能な要素を一覧し、click で ref を操作し、get url で結果を確認し、最後に close します。 バックエンドの選択肢は広いです。既定は Chrome for Testing で、--cdp や --auto-connect を使えば起動中の Chrome に接続できます。--engine で Lightpanda や Obscura を選べるほか、iOS シミュレータ内の Mobile Safari を動かしたり、Browserbase、Browserless、Browser Use、Kernel、AgentCore といったクラウドブラウザにつなげたりもできます。 エージェント開発者にとって助かるのは、バージョンに合った skills が CLI に同梱されていることです。agent-browser skills get core を実行すると、中核の循環、ref の使い方、待機の方針、よくあるワークフローを読めます。引数を足せば完全なコマンド一覧も確認できます。ドキュメントサイトにはインストール、クイックスタート、セレクタ、セッション、CDP モードが載っており、upgrade と doctor コマンドで更新や環境の点検もできます。

業界への影響

agent-browser は、ブラウザ自動化のインターフェースをコマンドラインとテキストという最も素朴な形にまで絞り込みました。シェルの呼び出しが得意な多くのエージェントの使い方とよく合います。モデルやエージェントフレームワークが違っても同じブラウザ機能を共有でき、特定の SDK に縛られません。 エンジニアリングチームにとっては、セッションが互いに分離されていること、状態を永続化できること、ローカルとクラウドのブラウザを切り替えられることが重要です。これらがあれば、試作から本格的な運用へ移りやすくなります。 注意すべき点もあります。アクセシビリティツリーはページ自体の意味付けの質に左右されるため、構造が乱れたサイトでは要素の説明が不明瞭になる可能性があります。ref はページの変化で無効になるので、エージェントは頻繁にスナップショットを取り直す習慣が必要で、さもないと古い対象を操作しかねません。

実際のブラウザをエージェントに動かさせることは、権限と安全の境界という問題も生みます。ログイン状態やフォーム送信などは利用者が自分で管理する必要があります。これらは現在の資料では詳しく触れられていないため、導入前に各自で評価するべきです。

今後の展望

今後を左右しそうな論点は三つあります。一つ目は、Lightpanda や Obscura といった Chrome for Testing 以外のエンジンへの対応が、どこまで充実するかです。二つ目は、クラウドブラウザ事業者との統合がどこまで深まるかです。三つ目は、バージョンごとに配布される skills がエージェントツールの一般的なやり方になるかどうかです。

現在の注目度と Vercel の研究組織の後ろ盾を考えると、agent-browser はエージェントがウェブを閲覧する際の定番の選択肢であり続ける可能性が高いでしょう。強みは役割を絞っている点にあります。読む、操作する、確かめるという循環を与え、失敗したクリックを正直に報告します。エージェントに安定してウェブ作業をさせたいチームは、まず自社のサイトで試し、そのサイトがアクセシビリティツリーをどれだけきちんと公開しているかを確認するとよいでしょう。