Claude CodeやCodexのようなAIコーディングエージェントが、コードを書くだけでなくブラウザまで操作する時代になってきた。Search Consoleのデータを取ってきて、axe-coreでアクセシビリティを検証して、SaaSにログインして情報を引っ張ってくる。そういう「ブラウザを目として使う」操作を、AIエージェントにどうやらせるか。

そのバックエンドとなるCLIツールが2つ出揃っている。MicrosoftのPlaywright陣営からは「Playwright CLI」、Vercel Labsからは「agent-browser」。どちらもAIコーディングエージェントから呼ばれることを前提に設計されたCLIだ。

コンセプトは同じ。snapshotでページの構造をツリー形式で取得し、AIが画面の意味構造を読んで次のアクションを判断する。CSSセレクタを調べてコードを書く必要がない。

# どちらもほぼ同じコマンド体系
agent-browser open https://example.com
agent-browser snapshot
agent-browser click @e3

playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli click e3

コマンドが同じなら、何が違うのか。Claude CodeのAgent機能やMCP連携で使うことを想定しつつ、同じタスクを両方でやって比較した。

テスト環境

– macOS (Apple Silicon)

– agent-browser 0.24.0（Rust製、Chrome for Testing使用）

– Playwright CLI 0.1.5（Node.js製、システムのGoogle Chromeを使用）

– axe-core 4.10.3

– いずれもデフォルト設定で比較

– 想定ユースケース: AIコーディングエージェントがCLI経由でブラウザを操作するワークフロー

なお、agent-browserはChrome for Testingをバンドルして使い、Playwright CLIはシステムにインストールされたGoogle Chromeをheadlessモードで使う。ブラウザ自体はどちらも正規Chrome系だ。

Round 1: bot対策サイト（X）

bot対策が厳しいことで知られるX（旧Twitter）で、@AnthropicAI のポストを取得する。

どちらも成功。 参考までに、素のPlaywright（Pythonスクリプトでセレクタ指定する方式）ではarticle要素が0件だった。headless Chromiumのブラウザ指紋がbot判定された可能性があるが、原因は特定できていない。CLI版はどちらもsnapshotでポストデータをツリー構造として読み取れた。

到達可否ではどちらも成功。ただし取得件数ではPlaywright CLIが6件でagent-browserの4件を上回った。

Round 2: 構造化データの抽出

テーブルや定義リストで情報が整理されたDBサイトから、名称・金額・条件・期限をJSON形式で抽出する。

同じデータが取れるが、agent-browserの方が9倍速い。速度差の原因はRound 4で詳しく分析する。

Round 3: アクセシビリティテスト（axe-core）

とあるコーポレートサイトにaxe-coreを流してWCAG準拠チェックを行った。

検出結果は完全一致。

結果は同じだが、実行速度はagent-browserが6倍速い。axe-coreの実行自体はブラウザ内で同じ時間がかかるので、差はCLI側のオーバーヘッドだ。

Round 4: 速度ベンチマーク

同一サイトで6つの操作を計測した。Round 2・3とは独立した計測である。

コールドスタート（ブラウザ起動+初回ナビゲーション）はほぼ同じ。だが、ブラウザ起動後の操作ではagent-browserが全項目で3〜9倍速い。

速度差の原因

どちらもバックグラウンドにデーモンプロセスが常駐し、ブラウザとの接続を維持している点は同じだ。差が出るのはCLIフロントエンドの部分と考えられる。

agent-browserはRustネイティブバイナリがUnix socket経由でデーモンに直接通信する。Playwright CLIはコマンドごとにNode.jsプロセスを起動し、デーモンにsocket接続して結果を受け取り、snapshotをYAMLファイルに書き出す。このNode.js起動+ファイルI/Oのオーバーヘッドが速度差の主因と推測される。

ただし、ブラウザチャネルや出力モードの設定によっても差は変わり得るので、この数値はあくまでデフォルト設定での結果だ。

AIコーディングエージェントがsnapshotを取って→判断して→操作して→またsnapshotを取る、というループを回す場合、この差は蓄積する。10回のやり取りでagent-browserなら2秒、Playwright CLIなら7秒。MCPサーバー経由で毎回フルレスポンスを返すよりCLI直叩きの方がトークン効率がいいのと同じ話で、ループの回数が増えるほど差が効いてくる。

Round 5: コンテキストサイズ（トークン効率）

AIエージェントにとって、snapshotのサイズはトークン消費量の目安になる。同じページのsnapshotを比較した（CLIの標準出力全文での比較）。

シンプルなサイトでは22〜35%の差だが、Google Search Consoleのようなリッチなアプリケーションでは文字数ベースで約2倍の差が開いた。Playwright CLIはsnapshotにURL情報、コンソールログ、yaml形式のマーカーなど付加情報が含まれる。1回なら気にならないが、AIコーディングエージェントがsnapshotを繰り返し取りながら操作するワークフローでは、LLMのコンテキストウィンドウの消費量に差が出てくる。

なお、ここで比較しているのは文字数であり、実際のトークン数はトークナイザの仕様によって異なる。

Round 6: 認証が必要なSaaS（Search Console）

最後のテストは一番実用的なケース。AIコーディングエージェントが自律的にSaaSからデータを取得するシナリオだ。Google Search Consoleにログインして、検索パフォーマンスデータを取得する。

ログイン保持の方法が違う

agent-browser: --profileオプションでブラウザのプロファイルディレクトリを丸ごと永続化する。初回だけheadedモードでGoogleにログインすれば、以降はプロファイルを指定するだけでいい。

# 初回: headedで手動ログイン
agent-browser --headed --profile /tmp/gsc-profile open "https://accounts.google.com"

# 以降: profileを指定するだけ
agent-browser --profile /tmp/gsc-profile open "https://search.google.com/search-console"
agent-browser snapshot

Playwright CLI: --profileと--persistentオプションが用意されている。今回の検証では--profile単体でGoogleのセッション保持を試みたが安定しなかった。--persistentフラグとの併用で改善する可能性があるが、未検証だ。代わりにstate-save/state-loadコマンドでCookieとlocalStorageをJSONファイルにエクスポート・インポートすることで認証を保持できた。

# 初回: headedでログイン → 状態を保存
playwright-cli open "https://accounts.google.com" --headed
# (手動ログイン後)
playwright-cli state-save google-state.json
playwright-cli close

# 以降: 3コマンド必要
playwright-cli open
playwright-cli state-load google-state.json
playwright-cli goto "https://search.google.com/search-console"

注意: profileディレクトリやstate-saveファイルは認証情報を含みます。.gitignoreに追加し、リポジトリにコミットしないでください。

パフォーマンス

agent-browserは--profile付きのopenコマンド1つでログイン済みの状態でSearch Consoleに直接到達する。今回の検証ではPlaywright CLIはopen→state-load→gotoの3コマンドが必要だった。ただし--persistentフラグとの組み合わせで手順が簡略化できる可能性はある。

取得データ

どちらもSearch Consoleの検索パフォーマンスから、合計クリック数・表示回数・平均CTR・平均掲載順位、クエリ別の内訳まで同一のデータを取得できた。snapshotにテーブル構造として含まれるので、追加のスクレイピングコードは不要だ。

まとめ

デフォルト設定での比較では、速度とコンテキスト効率でagent-browserが上回った。どちらもデーモン常駐型のアーキテクチャだが、CLIフロントエンドの実装言語（Rust vs Node.js）の差が速度に表れていると考えられる。

一方、Playwright CLIはPlaywright公式であり、コード生成（codegen）、trace viewer連携、--browserオプションによるFirefox・WebKitを含むマルチブラウザ対応など、agent-browserにはないエコシステムの厚みがある。テスト基盤としての拡張性を重視するならPlaywright CLIの方が適している場面もあるだろう。

個人的には、Claude CodeやCodexのようなAIコーディングエージェントに「ブラウザで何か調べてきて」と頼む用途ではagent-browser、Playwrightベースのテスト基盤やCI/CDパイプラインと組み合わせる用途ではPlaywright CLIが向いていると感じた。

AIコーディングエージェントがコードを書くだけでなく、ブラウザを「目」として使い、Webの情報を自律的に取得・操作する。そういう未来がCLI一つで手に入る時代になった。