郭立 (leeguoo)

# agent にブラウザを選ぶ:Playwright 系と chrome-use は同じものではない

Playwright / Puppeteer / browser-use がすでにあるのに、chrome-use は何が違う問題を解くのか、とよく聞かれます。私の答えは、それらは二つの異なる問いに答えているというものです。プログラムでブラウザを開くにはどうするか、そしてプログラムに、あなたがすでに使っているブラウザを使わせるにはどうするか。この文章では、その分岐から連鎖的に生まれる違い(ログイン / フィンガープリント / デバッグ確認ポップアップ / 並行実行)、実際のデータ取得タスクでの比較、そしてどちらを使うべきかの境界線について説明します。

2026年7月2日 · 記事 · 公開

このページの目次

よく聞かれる。Playwright、Puppeteer、browser-use がすでにあるのに、chrome-use はいったい何が違う問題を解くのか。私の答えは、それらは実は二つの異なる問いに答えている、というものだ。前者が問うのは「プログラムでブラウザを開くにはどうするか」。後者が問うのは「プログラムに、あなたがすでに使っているこのブラウザを使わせるにはどうするか」。この分岐ぶんきが、それぞれ何を得意とし、どこが致命的ちめいてきな弱点になるのかを決めている。

左:新しく開いた空のブラウザで、小さな黒いカードがログインフォームと CAPTCHA の壁の前で止まっている。右:あなたが使っている、ログイン済みの Chrome で、スムーズに続行している

使い捨てブラウザか、あなたのブラウザか

Playwright、Puppeteer、browser-use は新しいプロセスを起動し、きれいな profile のブラウザを開いてから、デバッグプロトコルでそれを制御する。このブラウザは使い捨てだ。あなたの cookie も、ログイン状態じょうたいもなく、閉じれば消える。cookie、フィンガープリント、並行実行へいこうじっこうは、すべて自分で管理しなければならない。

chrome-use は新しいブラウザを起動しない。つなぐ先は、今まさにあなたが開いていて、あらゆるものにログイン済みのその Chrome だ。接続はブラウザ拡張かくちょうと native messaging を通り、--remote-debugging-port ではない。

聞いただけだと「誰のセッションを使うか」の違いにすぎないように思える。だが、そこから派生するものは一層どころではない。

連動して生まれる一連の違い

ログイン。空のブラウザでログイン後のページにアクセスするには、スクリプト内でログインを一度走らせるか、自分で cookie を維持する必要がある。await context.addCookies(savedCookies) のように。この cookie は先に手に入れなければならないし、鮮度も保たなければならない。chrome-use ではこの手順はゼロだ。あなた自身がすでにログインしているので、接続した時点でそのセッション内にいる。

フィンガープリントと検出。空の自動化ブラウザは、全身に目印をまとっている。navigator.webdriver=true、headless の描画びょうが上のほころび、CDP で駆動する時によく見られる Runtime.enable の漏れ(rebrowser はこれを専門に検出している)。chrome-use はあなたの本物のブラウザなので、これらはそもそも存在しない。CreepJS での実測では bot スコアは 0% だった。

あのポップアップ--remote-debugging-port で Chrome に接続するツールは、Chrome 136 以降、接続のたびに「リモートデバッグを許可するか」という確認ダイアログが出る。しかもポートは事前に開いておく必要がある。chrome-use は拡張経由なので、一度入れれば確認はゼロだ。

並行実行。chrome-use では各 --session が独立した色付きタブグループを持つ。複数の agent が同じ本物の Chrome を共有しても、互いに混ざらず、あなた自身のタブも奪わない。

これは四つの並列した売り文句ではない。「あなたのブラウザを使う」という選択から必然的に生まれる一連の結果だ。

実際のタスクに落とし込む

具体例を挙げる。ある管理画面の中で、三ページめくってようやく読み込まれるデータをエクスポートするタスクだ。

Playwright を使う場合、launch で空のブラウザを開き、ログインを走らせる。アカウントとパスワードを入力し、CAPTCHA にぶつかって止まるかもしれない。JS の描画びょうがを待ち、ページをめくり、それから取得する。ログインと CAPTCHA の二つの関門だけで、スクリプトが最初の一歩で止まることはよくある。chrome-use なら、connect で接続し、snapshot -i で構造を見て、extract で JSON として取り出す。あなたはもともとログインしているし、ページも手元にある。最初の二つの関門はそもそも存在しない。

難しいのは「取得する」ことではない。難しいのは「取得できるところまで先にたどり着く」ことだ。これが、私がどちらを使うか判断する境界線でもある。

だから、どちらが優れているかではなく、何をしているかを問う

両者に上下はない。役割分担だ。

CI でエンドツーエンドテストを走らせるなら、きれいな環境、再現性、数十個の並列起動が必要になる。Playwright / Puppeteer はまさにそのために生まれている。この場面で無理に chrome-use を使うとかえって扱いづらいし、日々使っている自分のブラウザ上でテストを走らせたいとも思わないだろう。使い捨てスクリプトで、再ログインを気にせず、検出されることも問題でないなら、新しいブラウザを開く三つの案はいずれも使える。browser-use には LLM のオーケストレーションも付いている。だがタスクの中に「自分のログイン状態」「このサイトにはアンチボット対策がある」「本物の人間らしく見せたい」が出てきた瞬間、天秤は chrome-use に傾く。なお、Claude に自分でブラウザを開かせたいだけなら、Claude 公式の Chrome 拡張で十分だ。ただしそれが駆動するのは Claude だけであり、任意の agent や自分のスクリプトに使わせたい時に、ようやく chrome-use の出番になる。

一言で覚えるならこうだ。テストが求めるのは、捨てられるブラウザであり、きれいで再現可能であることが最重要。agent の仕事でしばしば必要なのは、あなたがすでに使っているブラウザであり、本物のセッションとブロックされにくさが最重要。自分が何をしているのかをはっきりさせれば、どちらを選ぶかで迷わなくなる。

← 前の記事
chrome-useのマルチエージェント隔離
次の記事 →
agentにWebページのデータを取らせるために、3つの不器用な方法を試して、最後に1つだけ残した

コメント

コメントは即時公開されますが、ポリシー違反時は非表示になる場合があります。

最大 1000 文字。