エージェント向けブラウザの選び方：Playwright のアプローチと chrome-use は同じものではない

更新日こうしんび 2026年10月7日：この記事では、新しいブラウザコンテキストを作成することと、既存のセッションに接続することを比較します。Playwright、Puppeteer、browser-use も、永続的な設定や既存のブラウザに接続する方法をサポートしているため、「空のブラウザを開くことしかできない」と要約することはできません。フィンガープリントテストは特定の環境だけを表すものであり、すべてのウェブサイトがアクセスを許可することを保証するものではありません。現在のインストール方法と接続方法については、chrome-use documentation（最新の比較は comparison with other tools） を参照してください。

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

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

Playwright、Puppeteer、browser-use は新しいプロセスを起動し、きれいなプロファイルでブラウザを開き、それをデバッグプロトコル経由で制御します。このブラウザは使い捨てです。あなたの cookies も、ログイン済み状態もなく、閉じると消えます。cookies、フィンガープリント、並行処理はすべて自分で管理しなければなりません。

chrome-use は新しいブラウザを起動しません。今この瞬間にあなたがすでに開いている Chrome、つまりあらゆるものにすでにログインしている Chrome に接続します。接続は --remote-debugging-port ではなく、ブラウザ拡張機能と native messaging を通じて行われます。

これは単に「誰のセッションが使われているか」の違いに聞こえるかもしれません。しかし、その意味いみはそれよりずっと深いものです。

関連する違いの連鎖

ログイン。空のブラウザがログインの背後にあるページへアクセスする必要がある場合、スクリプト内でログインフローを実行するか、自分で cookies のセットを維持しなければなりません：await context.addCookies(savedCookies)。まずその cookies を取得し、それから常に新鮮に保つ必要があります。chrome-use では、この手順はゼロです。あなたはすでにログインしており、接続した時点でそのセッションの中にいます。

フィンガープリンティングと検出。空の自動化ブラウザには、一連の目印があります。navigator.webdriver=true、headless 描画の欠陥、そして CDP 経由で操作されるときによくある Runtime.enable リークなどです（rebrowser はこれを特に検出します）。chrome-use の拡張機能経路は、あなたの実際のプロファイルを使います。具体的な検出マーカーは、文書化されたテストに基づいて判断されるべきです。CreepJS のテストでは、bot score は 0% でした。

あのポップアップ。Chrome 136 はデフォルトプロファイルに対する remote debugging を制限します。ポート設定と認可要件は、バージョンや接続方法によって異なります。chrome-use は拡張機能を使うため、一度インストールした後は、それ以上の確認はありません。

並行処理。chrome-use では、各 --session がそれぞれ独立した色付きのタブグループを持ちます。複数のエージェントが、混ざったり、あなた自身のタブを取り合ったりすることなく、同じ実際の Chrome を共有できます。

これらは四つの別々の売り文句ではありません。「あなたのブラウザを使う」という選択から自然に続く、結果の連鎖です。

実際のタスクに当てはめる

具体例を考えてみましょう。三つの画面をページ送りした後でしかデータが表示されない管理画面から、データをエクスポートする場合です。

Playwright では、launch が空のブラウザを開き、ログインフローを実行します。ユーザー名とパスワードを入力し、場合によっては CAPTCHA に当たって止まり、JS の描画を待ち、ページをめくり、それからスクレイピングします。ログインと CAPTCHA の手順は、スクリプトをたいてい最初の段階で止めてしまいます。chrome-use では、connect し、snapshot -i で構造を調べ、extract を使って JSON に取り出します。あなたはすでにログインしており、ページはすでに目の前にあります。そのため、最初の二つの障壁はそもそも存在しません。

難しい部分は決して「スクレイピング」ではありません。まずスクレイピングが可能な地点まで到達することです。これもまた、私がどのツールを使うかを決めるときの境界きょうかいです。

だから、どちらが優れているかを問わない。何をしているのかを問う

ここに上下関係はありません。あるのは役割分担です。

CI での end-to-end テストでは、きれいな環境、再現性、そして何十もの並列ブラウザが必要です。Playwright と Puppeteer はまさにそのために作られています。その場面に chrome-use を無理に押し込むのは扱いにくく、日常的に使うブラウザでテストを走らせたい人もおそらくいないでしょう。一回限りのスクリプトで、再ログインが許容でき、フラグを立てられる心配がないなら、三つの新規ブラウザ型アプローチのどれでも機能しますし、browser-use には LLM オーケストレーションも付いています。しかしタスクが「自分のログイン済み状態」「このサイトには anti-bot 対策がある」「実在の人間のように見える必要がある」を含むようになった瞬間、バランスは chrome-use に傾きます。単に Claude に自分でブラウザを開いてほしいだけなら、Claude の公式 Chrome 拡張機能で十分です。ただし、それが操作するのは Claude だけです。任意のエージェントや自分のスクリプトを使いたいなら、そこで chrome-use の出番になります。

一文で覚えるならこうです。テストには、清潔さと再現性が最も重要な使い捨てブラウザが向いています。エージェント作業には、本物のセッションとブロックされにくいことが最も重要な、あなたがすでに使っているブラウザが向いていることが多いのです。自分がどちらの仕事をしているのかが明確になれば、選択は難しくなくなります。