# chrome-use: あらゆる AI Agent がログイン済みの本物の Chrome を直接操作、CreepJS の bot 判定は 0%

AI Agent を作る人は、遅かれ早かれ同じ壁にぶつかります。agent にブラウザの中であなたの代わりに作業させることです。航空券の予約、投稿、管理画面データの取得、回帰テストの一巡など、ウェブページが関わるかぎり、ほとんどの場合ブラウザ自動化は避けて通れません。

そして、あなたはおなじみの落とし穴にはまります。

従来のブラウザ自動化はなぜこんなに使いにくいのか

Playwright、Puppeteer、browser-use、そして --launch で起動される新しいブラウザは、どれも同じことをしています。まっさらな、設定のない新規ブラウザを開くということです。つまり:

• 毎回ログインし直す必要がある。 あなたが Chrome でずっとログイン状態を保っている ChatGPT、X、GitHub、社内管理画面は、その空っぽのブラウザには一切存在しません。デフォルトで立ち上がるのは空のプロファイルです。Cookie も session もすべて空です（もちろん手動で profile を渡すことはできますが、その場合はログイン状態を自分で管理し続ける必要があります）。
• CAPTCHA が agent を詰ませる。 空のブラウザ、見慣れないフィンガープリント、データセンター IP。サイト側から見れば一目でスクリプトだと分かり、CAPTCHA や Cloudflare のブロックページが出てきます。agent はその場で詰まり、代わりにクリックしてくれる人はいません。
• フィンガープリントがいかにも偽物に見える。 navigator.webdriver、headless の痕跡、CDP の漏れ……これらはひと目で分かる自動化の綻びです。さらに Akamai、DataDome、PerimeterX といった Bot 検知ベンダーは数十の軸でスコアリングします。デフォルト設定の Playwright/Puppeteer は簡単にボロが出ます。
• 何をしているのか見えない。 それは別プロセスの別ウィンドウで動いています。あなたは途中で手を出せず、問題が起きてもログを見ながら推測するしかありません。

根本的な問題はひとつです。それが開いているのは「別の」ブラウザであって、あなたのブラウザではないということです。

chrome-use は発想を変えた：あなたの本物のブラウザを開く

chrome-use は、どんな agent（Claude Code、Cursor、Codex、あなた自身のスクリプト）でも、あなたのマシン上にある、各種サイトにすでにログイン済みの Chromeへ向けられるようにします。

それはあなたのウィンドウ内でクリックします。だから作業している様子を見守れますし、2FA や CAPTCHA にぶつかった瞬間に、あなたがそのまま引き継げます。しかもそれはまさにあなたの本物のブラウザです（ワンクリックでインストールできるストア拡張 + Native Messaging 経由で、chrome.debugger を使ってタブを駆動し、TCP のリモートデバッグポートは露出しません）。そのためサイトがフィンガープリント層で見るのは、本物の人間のブラウザです。自動化の痕跡として掴めるものはありません（CreepJS のステルススコア 0%。後述の「検知回避」節を参照）。もちろん、IP レピュテーション、アカウントリスク、行動のテンポは別の軸なので、そこは引き続き自分で見極める必要があります。

ひと言で言えば、新しい Chrome を開かない。ログインし直さない。もう「あなたはロボットですか？」の壁にぶつからない。

Claude プラグイン、web-access、生の CDP ポートとの比較

• Playwright / Puppeteer / browser-use？ それらは空のブラウザを起動します。各ログインを全部やり直し、各 CAPTCHA に正面から突っ込み、それでも自動化としてマークされます。chrome-use が使うのは、あなたがすでに持っているその session です。
• Claude 組み込みの Chrome プラグイン？ とても良いものですが、駆動できるのは Claude 自身だけです。chrome-use はどんな agent や CLI でも駆動します。
• 生の --remote-debugging-port（web-access 系）？ Chrome 136+ では接続時に「リモート デバッグを許可しますか？」というブロック用のポップアップが出ます（その Chrome セッション内で継続的に有効）。chrome-use ではこれは絶対に出ません。ワンクリックのストア拡張 + Native Messaging を使うからです。

すべてローカルで完結、ネットワークは通りません

あなたの chrome-use CLI は、Chrome のネイティブ メッセージング（native messaging）と、ごく小さなブラウザ拡張機能を通じてやり取りします。これはローカルのプロセス間チャネルであり、ネットワーク socket も、token も、リモートサーバーもありません。拡張機能は chrome.debugger を使って、指定したタブ（あなたのすでにログイン済みの Chrome 内にあるタブ）を操作し、その結果を CLI に返します。すべてはあなたのマシン上に残ります。

拡張機能ルートなら、あの許可ポップアップを省けます

ほかのローカルツールは、生の --remote-debugging-port（CDP）を使います。Chrome 136 以降、このような接続では初回に「リモート デバッグを許可しますか？」というブロック型の許可ダイアログが表示されます（その Chrome セッション内では継続的に有効）。しかも、事前にポートを開いておく必要があります。chrome-use の拡張機能はネイティブ メッセージングを使います。一度インストールすれば、その後は毎回確認ゼロで使えます。

この許可ポップアップは大げさな話ではありません。生ポート系ツールは初回の**接続（attach）**時に、ブロック型の許可ダイアログを表示します（その Chrome セッション内では継続的に有効）。一方、拡張機能ルートなら一度インストールした後は確認ゼロです。

agent にページを一目見せるのに、たった 200–400 token

ここまでは「誰のブラウザにつなぐか」の話でした。ですが AI agent にとっては、同じくらい致命的な問題がもう 1 つあります。ページを一目見るたびに、どれだけ token を消費するのかです。

多くのブラウザ agent はスクリーンショット駆動です。Web ページ全体のスクリーンショットを視覚モデルに渡し、ピクセルの中からボタンを探させます。スクリーンショット 1 枚だけで数千 token になることも珍しくなく、1 回クリックする、1 ページ進むたびにまた 1 枚必要になります。少し長めのフローを走らせるだけで、token はどんどん燃えていきます。別の方式では、生の HTML/DOM 全体をコンテキストに詰め込みますが、これも同じく長くてノイズだらけです。

chrome-use は構造化優先です。snapshot -i は agent にアクセシビリティツリー（accessibility tree）のスナップショットを渡し、インタラクティブ要素だけを残します。各要素にはコンパクトな @eN 参照が付きます。ページ全体でも通常は ~200–400 token 程度で済み、生 HTML を解析する必要も、ましてスクリーンショットを詰め込む必要もありません。agent は参照を使って直接操作します。

chrome-use open <url>
chrome-use snapshot -i      # インタラクティブ要素だけを見る。各要素に @eN 参照付き
chrome-use click @e3        # 参照で操作する。座標にもスクリーンショットにも依存しない

chrome-use におけるスクリーンショットは出力であって、入力ではありません。証跡を残したい、人間に見せたいときだけ撮ればよく、agent 自身が位置特定 / 読み取り / クリックを行う全工程では不要です。さらに site adapters（後述）は一歩進んで、きれいな JSON を直接取得します。スナップショットすら省けるため、「構造化データを読む」うえで最も安いルートです。

節約できるのは、実際のコストです。同じフローでも、構造化インターフェースはスクリーンショット駆動より 1 桁安くなることがよくあり、タスクが長くなるほど差ははっきりします。だからこそ chrome-use は、人間が見るブラウザパネルではなく、agent のための CLIとして自らを位置づけています。

パッチを当てなければ、調べられる痕跡もない

あなたの本物の Chrome に接続するとき、chrome-use は JavaScript パッチを一切注入しません。ブラウザのフィンガープリントは完全に本物です。指針は、JS で偽装するのではなく、ネイティブの CDP/Chrome 層で上書きすることです。再定義された getter はそれ自体が検出可能ですが、ネイティブ層での上書きにはそのような痕跡が残りません。

• navigator.webdriver = false は Emulation.setAutomationOverride を使います（ネイティブ上書きなので、再定義された getter のように CreepJS のような「嘘発見器」にその場で捕まりません）。
• Runtime.enable はデフォルトでオフです。 生きている Runtime ドメイン自体が、検出可能な CDP シグナルです（patchright/rebrowser が言う「runtime leak」）。本物の Chrome に接続していても同じです。これは console/error の取得を明示的に有効にしたときだけ有効化します。click、fill、eval は、これを開かなくても通常どおり動作します。

実測結果（本物の Chrome に接続）:

CreepJS の 0% stealth が重要な数字です。接続経路では何もパッチしないため、「嘘発見器」に捕まるような上書きがそもそも存在しません。また、私たちは独自の bot 検出器をあえて作りません。最も検証に耐える基準は、公開検出サイトの中でも厳しいもの（CreepJS、incolumitas）をあなたの本物のブラウザに当てることです。なお、それらが測っているのはフィンガープリント / 痕跡であり、商用の行動 + IP レピュテーションのスタックは、別レイヤーのさらに難しい関門です。私たちの言葉を信じる必要はありません。自分で一度検証してみてください。

クリックを人間の手つきに見せる

フィンガープリントは話の半分にすぎません。こうした Bot 検出ベンダー（Akamai、DataDome、PerimeterX）は、行動にもスコアを付けます。カーソルを要素のど真ん中へ瞬間移動させ、接近経路もなく、押下遅延もゼロのクリックは、それ自体が綻びです。たとえ私たちの CDP イベントが isTrusted であってもです。

humanize を有効にすると、カーソル移動は人間が操作しているように振る舞います。クリックは曲線を描き、減速するベジェパスを通り、要素内部のランダムな揺らぎを持つ位置に着地します（決してど真ん中ではありません）。タイピングには変化するキー入力間隔を使い、スクロールは分割してイージングし、ドラッグも曲線で動きます。さらにこれは適応型です。ナビゲーションごとに既知のアンチボットベンダー（cookie / script / global 変数）を検出し、監視されているページでは自動的に人間らしい軌跡へ引き上げ、「瞬間移動クリック」のような最も初歩的な綻びを消します。これは明らかな機械的痕跡を取り除けますが、行動レベルのリスク制御は滞在時間、リズム、セッション全体のエントロピーも見ます。humanize は万能薬ではありません。通常のサイトでは従来どおりの瞬時クリックを保ちます（追加コストゼロ）。

--humanize off|fast|human または環境変数で制御できます。デフォルトは off で、適応型検出器がページに応じて自動的に引き上げます。

前面を奪わない

自分の本物の Chrome を駆動する以上、手元の作業を絶対に邪魔すべきではありません。agent は完全にバックグラウンドで動作します。新しいタブはフォーカスを奪わずに開かれ（agent 自身の色付きタブグループ内で）、agent がタブを強制的に前面へ持ってくることは決してありません。さらに Emulation.setFocusEmulationEnabled により、各 agent タブは継続してレンダリングされ、document.hasFocus() は true を返し、visibilityState は visible を報告します。そのためスクリーンショットは通常どおり使え、ページのレンダリングがスロットリングされることもなく、「セッション全体でタブが不可視」という異常と見なされうるシグナルも発生しません。あなたはアクティブなタブで作業を続け、agent は横で静かに仕事を進めます。

複数の Agent が 1 つの Chrome を共有し、互いに干渉しない

各 --session は自分専用の色付き Chrome タブ一式を取得するため、複数の agent が同じ本物のブラウザを並行して共有できます。互いに邪魔せず、あなた自身のタブにも触れません。1 つのセッションが所有するのは自分で作成したタブだけであり、あなたのタブを乗っ取ることは決してなく、他の agent のタブも乗っ取りません。コマンドの送信もセッションごとに隔離されます。つまり、1 つの実際の Chrome 上で複数の agent を同時に走らせ、それぞれに別々の作業を進めさせることができます。

Site Adapters でウェブサイトを構造化データ CLI に変える

「GitHub issues を読む」「Reddit を検索する」「自分の Bilibili フィードを取得する」といったタスクの多くは、そもそもクリックやスクリーンショットを必要としません。サイトの裏側にはたいてい JSON API がすでにあります（ただしログイン状態でないと呼べないだけです）。site adapter は小さな JS 片で、あなたがログイン済みのタブ内でその API（あなたの cookie、同一オリジンの fetch、サイト自身のモジュール）を呼び出し、きれいな JSON を返します。サイト側から見ると、そのリクエストはあなた本人が手動操作で発生させたものとほとんど区別できません。

chrome-use は adapter を一切内蔵していません。site update は実行時にコミュニティ製の bb-sites パッケージを取得し（パッケージマネージャが依存関係を取得するように）、それらを chrome-use のステルス転送で実行します。

chrome-use site update                      # adapter パッケージを取得（約 145 コマンド）
chrome-use site list                        # github/issues、reddit/search、bilibili/feed…
chrome-use site github/issues epiral/bb-browser --json
chrome-use site bilibili/feed --json        # 実行可能。ログイン済み session を使うため

さらに、これは自動同期・自動提示されます。adapter のあるドメインで open / snapshot すると、chrome-use は出力内に 💡 site adapters for <domain> という 1 行を直接表示します。これにより agent は DOM をこすり取るのではなく、まず構造化データ adapter を使えます。

「クリック作業」を再実行可能なテストスイートにする（chrome-use test）

「開いて、あちこちクリックして、正しいか確認する」ような繰り返し作業は、再実行可能なテストにできます。フロントエンドにスモーク / 回帰テストの層を 1 枚追加するようなものです。YAML でケースを書き、ステップでは chrome-use 自身のコマンドを再利用し、アサーションは単一のチェックにコンパイルされます。

# smoke.yaml
suite: chatgpt smoke
cases:
  - name: home loads logged in
    steps:
      - open: https://chatgpt.com/
      - wait: { load: networkidle }
    assert:
      - url: { contains: chatgpt.com }
      - visible: "#prompt-textarea"

chrome-use test smoke.yaml                   # 分離ブラウザを起動してケースを実行
chrome-use test smoke.yaml --session default # …または接続済みの Chrome に対して実行

いずれかのケースが失敗すると、終了コードは非ゼロになります（そのまま CI に組み込めます）。失敗したケースではスクリーンショットも保存されます。アサーションは url / visible / hidden / text / count / eval をサポートし、ステップは open / click / fill / type / press / wait / scroll / eval をサポートします。回帰問題を見つけたら、ケースを 1 つ追加するだけです。使えば使うほど、このテストスイートの価値は高まります。

上級者向け: 1 行でインストールして、どんな agent にも接続

curl -fsSL https://raw.githubusercontent.com/leeguooooo/chrome-use/main/install.sh | sh

最新の GitHub Release から、対応プラットフォームのプリビルド済みバイナリをダウンロードし、chrome-use（加えて短いエイリアス abs）をインストールします。npm は使わず、token も一切不要です。

あなたの Chrome に接続します（拡張機能経由がおすすめです。ワンクリックで、ポップアップなし）: Chrome ウェブストアの chrome-use 拡張機能 をインストールし、その後ローカルブリッジを一度だけ登録します。

chrome-use extension install      # ネイティブメッセージングホストを登録（一度だけ）
chrome-use open https://x.com/home

以後はネイティブメッセージング経由で、あなたの本物のログイン済み Chrome をそのまま操作できます。debug ポートなし、token なし、「リモートデバッグを許可しますか?」という確認も一切出ません。

AI agent（Claude Code、Cursor など）に対応スキルを入れます。

npx skills add leeguooooo/chrome-use

これにより skills/chrome-use が専用スキルごとプロジェクトに配置され、agent は正しい使い方の例と、事前に許可された bash 権限を持つようになります。

日常的な使い方はこのような感じで、どんな agent からでも呼び出せます。

chrome-use open https://example.com
chrome-use click "Post"
chrome-use fill "Title" "Hello World"
chrome-use screenshot ./page.png

agent があなたの Chrome 内で操作し、タブが開く、ページが読み込まれる、クリックが発生する様子をリアルタイムで確認できます。必要なときはいつでもあなたが操作を引き継ぎ（たとえば CAPTCHA を解くなど）、その後 agent に続きを任せられます。

本物の Chrome に触れさせたくない場合は、chrome-use --launch open <url> で新しい隔離されたシークレットブラウザを起動できます（完全な検出回避パッチ適用済み）。CI では自動的にこの経路が使われます。

いくつかの重要な違い

• デフォルトで既存の Chrome に接続。chrome-use open <url> は、別のブラウザを起動するのではなく、あなたが今使っているブラウザを操作します。
• Token 効率の高い構造化インターフェース。agent に渡すのはアクセシビリティツリーのスナップショット + @eN 参照で、1ページあたり約 200〜400 token。スクリーンショットに頼らず、生の HTML も詰め込みません。スクリーンショットは出力であり、入力ではありません。
• 拡張機能による中継伝送。ストア拡張機能 + ネイティブメッセージングをワンクリックで利用でき、debug ポートも「リモートデバッグを許可しますか？」というポップアップもありません。
• CDP ネイティブのステルス性。検出対策は JS パッチではなく Chrome/CDP のオーバーライドで行います。本物の Chrome に接続する場合はパッチなし、--launch の場合のみ完全なパッチを適用します。
• Humanize。人間らしいカーソル軌跡 + 適応型のアンチボット対応。
• 複数 agent の分離。並行する agent はセッションごとのタブグループを通じて1つの本物の Chrome を共有しつつ、互いに干渉しません。
• 静かに実行。バックグラウンドで動作し、あなたの前面タブを奪うことはありません。

chrome-use は *-use ファミリーの一員です。iphone-use があなたの本物の iPhone を操作するように、chrome-use はあなたの本物の Chrome を操作します。プロジェクトは Apache-2.0 でオープンソース公開されています。

agent 自動化に取り組む人なら持っておく価値があります。ついでに GitHub で star して、より多くの Agent 開発者の目に留まるようにしてください：github.com/leeguooooo/chrome-use。

leeguooooo によって開発されています。AI agent、リバースエンジニアリング、Cloudflare Workers の現場メモは blog.misonote.com に、X では @leeguooooo をフォローしてください。