browser-control: コーディングエージェントにブラウザ操作を渡すRust CLIの実力と境界

browser-controlが埋めるのは「エージェントにブラウザの手足がない」という穴

LLMを使ったコーディングエージェントは、ファイル編集やコマンド実行はできても、Webページの状態を読んで操作する手段を持たないことが多い。PlaywrightやPuppeteerを呼ぶコードをエージェントに書かせる方法はあるが、そのたびにSDKのAPIを覚えさせ、スクリプトを生成させ、実行させる必要がある。browser-controlのREADMEは、この層を「小さくデバッグ可能なパイプ」として外に出すと説明している。エージェント自身はエージェントのままで、browser-controlが目と手を提供するという立場だ。対象読者は、シェルを実行できるエージェントを持っていて、ブラウザ操作をその延長として扱いたい開発者である。MCPサーバーを別途立てる必要はなく、フレームワークも要求しないと明記されている。

snapshotが返す@e1参照という設計判断

このツールの中心にあるのはsnapshotコマンドだ。READMEの例では、snapshotが@e1 <input#search>、@e2 <a "Get started">のような番号付きの参照を返し、click @e2のようにそのまま指定できる。CSSセレクタをエージェントに書かせる方式だと、DOMが変われば壊れる。座標クリックはレイアウトに依存する。参照方式はその中間で、スナップショット時点の要素に安定した名前を振る。ただし参照が有効なのは、そのスナップショットが撮られた時点のDOMに対してである。ページが大きく書き換われば、@e3が別の要素を指すか、存在しなくなる可能性がある。READMEは参照の寿命や無効化の検出方法について何も述べていない。エージェントに操作させるなら、snapshotと操作を交互に繰り返す使い方が前提になると考えるべきで、長い手順を一括で生成させる用途には向かない。

launchからdoctorまで、実際に打つコマンド

導入はcargo install browser-control-cliで行う。READMEが注記しているとおり、クレート名はbrowser-control-cliだが、インストールされるコマンドはbrowser-controlである。プリビルドのバイナリもGitHub Releasesから取得できる。初期化はbrowser-control initで、.browser-control/ワークスペースを作る。起動と接続はbrowser-control launch https://example.comで、Chromeを起動して接続する。既にCDPで待ち受けているブラウザがある場合はlaunchを省き、環境変数BROWSER_CONTROL_CDP_URLやBROWSER_CONTROL_CDP_WSで指定する。短い別名としてBU_CDP_WSやBU_CDP_URLも使えるとREADMEは記載している。接続状態の確認はbrowser-control doctorで、エンドポイント、ブラウザ、起動したpid、デーモン、ワークスペースを報告する。操作はclick、fill、type、press、scrollなどが揃い、clickには--waitで要素の出現を待つオプション、--clicksでダブルクリック、--buttonで右中ボタンの指定がある。pressはctrl+aやcmd+shift+tのような修飾キーの組み合わせを受け付ける。

evalとcdpという逃げ道が意味すること

ヘルパーコマンドで表現できない操作のために、生のCDPを叩く経路が用意されている。browser-control cdp Runtime.evaluate '{"expression":"location.href","returnByValue":true}'のようにメソッド名とJSONパラメータを直接渡す。evalはトップレベルのreturnをIIFEで包むため、eval 'const x = 1; return x'がそのまま動くとREADMEは説明している。evalには--frameでiframeのURL部分文字列を指定するオプションもある。この二段構えは実用上大きい。ヘルパーが対応していない操作のたびに別ツールへ乗り換える必要がなく、CDPの知識がそのまま資産になる。一方で、cdpに渡すJSONはシェルのクォートと衝突しやすい。READMEの例でもシングルクォートの中にJSONを入れているが、パラメータが複雑になればシェルスクリプト側の工夫が要る。CLIである以上、この摩擦からは逃れられない。

デーモンとトレースによる自己観測、その代償

browser-controlは隠れたデーモンを動かし、イベント、ネットワーク、コンソールのリングバッファをメモリ上に保持する。events、network、consoleの各コマンドはこれを読む。加えて、コマンドが失敗すると.browser-control/traces/配下に簡潔なトレースが残り、エージェントが自分で原因を調べられる。エージェント向けの設計として筋は通っている。ただし、この観測性はデーモンが生きていることに依存する。doctorがデーモンの状態を報告項目に含めているのは、それが失敗要因になり得ることを示唆する。デーモンが落ちた場合や、ワークスペースの外からコマンドを実行した場合の挙動について、READMEは明示していない。リングバッファである以上、古いイベントは消える。長いセッションの全履歴を後から精査する用途には向かない。

クラウドCDPプロバイダを同じコマンドで扱う

READMEはBrowser Use、Steel、Hyperbrowser、Browserbase、および任意のCDPプロバイダを同じコマンドで駆動できるとしている。仕組みは単純で、接続先のWebSocket URLを環境変数で差し替えるだけだ。ローカルのChromeでもリモートセッションでも、snapshotやclickの呼び方は変わらない。プロバイダ固有のSDKを覚える必要がない点は、乗り換えコストを下げる。ただし、リモートセッションではネットワーク遅延が全てのコマンドに乗る。click --wait 5のような待機オプションの値はローカル前提の感覚で決めると足りない可能性がある。また、クラウド側のブラウザバージョンがCDPの挙動に影響する。READMEはプロバイダごとの差異や検証状況について何も述べていないため、特定プロバイダでの動作は自分で確認する必要がある。

Playwrightと何が違うのか

Playwrightはテストフレームワークであり、ブラウザのライフサイクル管理、待機戦略、アサーション、レポートを一つのパッケージで提供する。browser-controlはその逆で、状態を持たない一連のシェルコマンドに近い。差が最も出るのは待機の扱いだ。Playwrightは要素の自動待機やネットワーク idle の判定を内部に持つが、browser-controlは--waitでポーリングするか、エージェント自身がsnapshotを撮り直して判断する。つまり、待つ責任が呼び出し側にある。決定的な再現性が求められるCIのテストスイートを書くならPlaywrightの方が適している。逆に、エージェントがその場でページを見て次の行動を決める、という探索的な用途では、コマンド一つ一つが独立しているbrowser-controlの方が組み込みやすい。どちらが優れているという話ではなく、待機と状態管理をどちらが持つかの違いである。

導入前に確認すべき制約とライセンス

制約はいくつかある。第一に、ChromeまたはChromiumの最近のビルドがCDP経由で到達可能であることが前提で、launchが起動を試み、doctorが検出結果を報告する。FirefoxやWebKitは対象外と読める。第二に、ビルドの再現性はCargo.tomlの厳密なバージョン指定とCargo.lockに依存するため、CIでは--lockedを付けるようREADMEは指示している。scripts/verify.shがローカル検証用に用意されている。第三に、リリースはv0.1.0とv0.1.1の二つのみで、APIの安定性を保証する記述はREADMEにもリリースノートにもない。プロダクションの自動化に組み込むなら、バージョンを固定して呼び出すべき段階だ。ライセンスはMITで、表示義務は緩いが、無保証である。法務判断はここでは扱わない。確認すべきは、自分の環境でlaunchとdoctorが通るか、そして.browser-control/配下に何が書かれるかである。

編集部の結論

シェルコマンドを実行できるエージェントに、最小の構成でブラウザ操作を与えたい場合に向く。MCPやSDKの常駐サーバーを立てたくない、あるいは既にCDPで待ち受けているブラウザへ接続したいチームは検討する価値がある。逆に、複数ブラウザの並列実行やテストスイートとしての再現性を最優先するなら、Playwrightの方が適している。導入前に確認すべきは、自分のChromeのバージョンでlaunchとdoctorが通るか、そして.browser-control/配下に何が書かれるかである。

公式情報源

1. Issues
2. keon/browser-control on GitHub
3. License: MIT
4. README
5. Releases