browser-use CLI vs playwright-cli — Claude Code用ブラウザ自動化ツールを計測比較した

背景

Claude Codeでブラウザ操作を自動化するとき、自分はplaywright-cliを使っています。E2Eテストのスクリーンショット取得やフォーム操作など、AIエージェントの「手」として欠かせないツールです。

一方で、運用上の課題がありました。

SAML認証のたびにセッションが切れる。 社内のGitHub Enterprise（GHE）へアクセスするたびにSAML認証を求められ、認証が通らないと新規セッションを起動し直す。これを繰り返した結果、Chromeのプロセスが47個も残っていたことがありました。

そんなとき、browser-use CLIの存在を知りました。Chromeプロファイルの読み込みやCookieのexport/importをサポートしており、SAML問題を解決できそうだと感じました。そこで実際にインストールして計測比較してみました。

計測環境

• macOS (Darwin 25.3.0)
• Python 3.13.7
• playwright-CLI 0.0.61（mise経由）
• browser-use 0.12.2（pip install）

計測方法

各コマンドの実行時間をtimeコマンドで計測しました。daemon起動済みの状態で5回実行し、中央値を採用しています。

# playwright-CLI
time playwright-cli open https://example.com
time playwright-cli snapshot
time playwright-cli screenshot /tmp/pw.png

# browser-use CLI
time browser-use open https://example.com
time browser-use state
time browser-use screenshot /tmp/bu.png

初回起動の計測は、daemonを停止した状態からopenコマンドを実行し、daemon起動からページ表示完了までの時間を計っています。

playwright-cli session-stop  # daemon停止
time playwright-cli open https://example.com  # daemon起動 + ページ遷移

速度比較

同一マシンでhttps://example.comに対して各操作の実行時間を計測しました。

初回起動（daemon起動を含む）

2回目以降（daemon起動済み）

playwright-CLIが全操作で高速でした。browser-use CLIのドキュメントには「50msレイテンシ」と記載がありますが、これはIPC通信のレイテンシを指しており、CLIコマンド全体の実行時間とは計測対象が異なります。自分の環境でのCLIコマンド実行時間は、最速のscreenshotで200ms、DOM取得で2秒という結果でした。

どちらもdaemonアーキテクチャ（初回起動でバックグラウンドプロセスを立ち上げ、以降はソケット通信）を採用していますが、実効速度には大きな差があります。

SAML認証の永続化

今回の調査の本題です。

playwright-CLIの課題

playwright-CLIはセッション機能（--session）を持っており、daemonが生きている間はCookieを維持できます。しかし、SAML認証が切れたときの再認証がうまくいかないケースでは、結局daemonを殺して再起動することになります。再起動するとCookieは消え、再びSAML認証が必要になる。この繰り返しです。

Playwright本体にはstorageStateというCookie/localStorageの保存・復元機構がありますが、playwright-CLIのCLIインターフェースからは直接使えません。

browser-use CLIの機能

browser-use CLIにはSAML問題を解決しうる2つの機能があります。

1. Cookieのexport/import

browser-use cookies export session.json   # 認証Cookie含めてファイルに保存
browser-use cookies import session.json   # 次回起動時に復元

認証済みのCookieをファイルに保存し、新しいセッションで復元できます。SAML認証後にexportしておけば、daemon再起動後もimportで認証状態を復元できるはずです。

2. Chromeプロファイルの読み込み

browser-use -b real open https://ghe.example.com

-b realモードでは、ローカルにインストールされたChromeのプロファイル（Cookie、認証情報を含む）をコピーして起動します。普段のChromeでSAML認証済みなら、そのセッションを引き継げる可能性があります。

Python SDKからも同様のことができます。

from browser_use import Browser

browser = Browser.from_system_chrome(profile_directory='Default')

実際にテストした結果

Chromeプロファイルモードは自分の環境ではクラッシュしました。

CLIの-b realモードはタイムアウトし、Python SDKのfrom_system_chrome()は以下のエラーで落ちました。

ERROR: Failed to setup CDP connection: EventBus at capacity:
100 pending events (100 max). Queue: 50, Processing: 50.

原因は、既存のChromeプロファイルに58個のタブが存在していたこと。browser-useはプロファイルコピー時に全タブのCDPセッションを初期化しようとし、EventBusの容量を超えました。普段使いのChromeでタブを多く開いている自分の環境では、そのままでは使えませんでした。

Cookieのexport/importは動作しましたが、今回のテストでは認証が必要なサイトでの検証まではできていません。

機能比較まとめ

所感

自分の用途（Claude CodeからのE2Eテストやスクリーンショット取得）では、速度面でplaywright-CLIが2〜26倍速く、乗り換える理由は見つかりませんでした。ただし、これはあくまで自分の環境・ワークフローでの結果です。

browser-use CLIはCookie管理やChromeプロファイル読み込みなど、認証まわりの機能が充実しています。速度よりも認証の手間を減らしたい場合や、Python SDKと組み合わせて柔軟にブラウザ操作を組みたい場合は、browser-useのほうが選択肢になります。

自分のケースでは、Chromeプロファイルモードの安定性が課題でした（タブ58個の環境でクラッシュ）。タブを少なく保った専用プロファイルを用意すれば動く可能性はありますが、そこまでするなら別のアプローチを取りたいところです。

SAML問題の解決策としては、playwright-CLIにstorageStateのexport/importをラップするスクリプトを書く方が現実的だと考えています。認証後のCookieをファイルに保存し、daemon再起動時に復元する。browser-useが持っている機能と同等のことを、速度を犠牲にせず実現できます。

参考

• browser-use CLI ドキュメント
• browser-use PyPI
• playwright-cli