Public Browser

Public Browser

Claude Code、Cursor、そしてあらゆる MCP クライアントから Chrome を操作できます。30 テストのページを使ったブラインドベンチマークでは、各 5 回の実行すべてで Public Browser 3.0 が 30/30 を達成しました。また、agent-browser 0.38.1 が 4.5M 使用したセッショントークンの中央値は 3.0M で、トークン数とコストが 3 分の 1 減、ツール呼び出しが 4 分の 1 減、速度が 48％向上しました（386 秒に対して 261 秒） (ベンチマーク、劣るケースも含みます）。Claude Code 2.1.281、ドライバー Claude Opus 5、Chrome 153 を使用して 2026-09-23/24 に測定しました。agent-browser は公式スキルファイルを使って CLI 経由で実行し、テストページは独自に作成したものです。CDP に直接接続し、a11y ツリーの参照を使い、run_plan で呼び出しごとに複数のステップを実行します。TypeScript テスト 2,700 件以上、Python テスト 280 件以上を実施済みです。

Claude Code、Cursor、およびあらゆる MCP 互換クライアント向けに構築されています。また、LLM を介さずに、Jev のような意思決定モデルにも対応します。

agent-browser、Playwright MCP、Chrome DevTools MCP、または Browser MCP の代替をお探しですか？ Public Browser は、DevTools Protocol 経由で Chrome と直接通信する MCP サーバーです。Playwright への依存も、拡張機能ブリッジも、ステップごとのシェルコマンドも不要です。インストールは 1 つのコマンドで完了し、設定は不要です。以下のベンチマーク比較をご覧ください。

Public Browser を選ぶ理由

• タスクあたりのトークン数が少なくなります。 ツールを呼び出すたびに、モデルはそれまでの会話を読み直すため、料金はセッション全体で決まります。ベンチマークページでは、Public Browser 3.0 は 300 万トークン（5 回の実行の中央値）を使用したのに対し、agent-browser は 450 万トークンでした。その前日の実環境での実行では、Public Browser がまだ 2.10.6 だったとき、Playwright MCP は 780 万トークン、Chrome DevTools MCP は 1,030 万トークンを必要としました。この差は、より少なく、密度の高いステップによるものです。run_plan は変数と条件を使って複数のアクションを 1 回の呼び出しで実行します。また、3.0 以降は応答の繰り返しが減り、差分には変更点だけが表示され、親行ですでに示されているテキストは繰り返されず、ヒントはセッションごとに 1 回だけ表示されます。
• 黙って失敗するのではなく、明示的に失敗します。 複数の要素に一致する CSS セレクターは何も実行せず、候補とその参照を返します。参照はタブごとに保持され、再利用されることはないため、離れたページの参照を使うと、同じ番号を持つ現在のノードをクリックするのではなく、stale ref が報告されます。何も反応しなかった場合、drag は Drag not confirmed を返します。また、クリックによってタブが開いた場合は、新しいタブの名前が示されます。
• ネストされたクロスオリジン iframe と Shadow DOM に対応しています。 別のクロスオリジン iframe 内にあるクロスオリジン iframe の要素にもクリックが届きます。agent-browser 0.38.1 が読み取るのは 1 階層までです（#1784）。オープンおよびクローズド Shadow Root も読み取れます。
• LLM を使わずに利用できる 2 つの方法があります。 Node ライブラリ（createSession()）と Python クライアント（pip install publicbrowser）は、MCP サーバーと同じツールハンドラーを実行します。

agent-browser が優れている点： Chrome プロファイルをコピーしてログイン状態を引き継げます（Public Browser のプロファイルモードでは macOS 上のサイトへのログイン状態は引き継がれません。詳しくは Chrome プロファイルをご覧ください）。HAR ファイルの記録やリクエストのインターセプト、PDF や動画の保存、iOS Safari の操作にも対応しています。エージェントが MCP クライアント経由ではなくシェルから作業する場合は、有力な選択肢です。

ブラインドベンチマーク、各 5 回の実行の中央値	Public Browser 3.0	agent-browser 0.38.1（CLI）
合格数（採点対象 30 テスト）	5 回中 5 回、30/30	5 回中 5 回、29/30 — navigator.webdriver のチェックである T5.2 に不合格
セッションのトークン数、全実行	3.02M（2.47–3.15M）	4.53M（4.40–5.33M）
1 回あたりのコスト、Opus 5 の定価	$2.40	$3.56
ツール呼び出し回数	79	104
完了までの時間、実時間	261 s	386 s
ツール応答の総量	78.9k chars	84.4k chars
ツール応答の平均サイズ	1,040 chars	754 chars

2026-09-23/24、Claude Code 2.1.281、ドライバー claude-opus-5、Chrome 153.0.8010.53。手法、実行ごとの表、その他の実測値については、ベンチマークをご覧ください。

クイックスタート

Claude Code へのインストール

1 つのコマンドで、すべてのプロジェクトにグローバルインストールできます。

claude mcp add --scope user public-browser -- npx -y public-browser@latest

重要： claude mcp add の実行後は、Claude Code を完全に終了して再起動する必要があります。/mcp reconnect だけでは不十分です。Claude Code はセッション開始時にのみ mcpServers の設定を読み込み、キャッシュするためです。再起動後、最初のツール呼び出しで Chrome が表示された状態で自動起動します（ヘッドレスではなく、ポートの設定も不要です）。これで完了です。

Python スクリプト API による並列アクセスを有効にするには、引数に --script を追加します。 claude mcp add --scope user public-browser -- npx -y public-browser@latest -- --script

Cursor へのインストール

~/.cursor/mcp.json に追加します。

{
  "mcpServers": {
    "public-browser": {
      "command": "npx",
      "args": ["-y", "public-browser@latest"]
    }
  }
}

Python スクリプト API による並列アクセスには、"args": ["-y", "public-browser@latest", "--", "--script"] を使用します。

Cline へのインストール

cline_mcp_settings.json に追加します。

{
  "mcpServers": {
    "public-browser": {
      "command": "npx",
      "args": ["-y", "public-browser@latest"]
    }
  }
}

その他の MCP クライアントへのインストール

stdio MCP サーバーに対応しているクライアントなら、引数なしで npx -y public-browser@latest を使用できます。

試してみましょう — 最初のプロンプト

インストール後、これを AI コーディングアシスタントに貼り付けます。

mcp-test.second-truth.com を開いてページを読み取り、名前「Test User」、メールアドレス「[email protected]」で問い合わせフォームに入力してください。

この操作では、3 つの主要なツールが順番に実行されます。navigate がページを読み込み、view_page が安定した要素参照を含むアクセシビリティツリーを読み取り、fill_form が 1 回の呼び出しで複数のフィールドに入力します。Chrome が開き、ページが読み込まれ、フォームに入力されることを確認できます。コードを 1 行も書く必要はありません。

アンインストール

claude mcp remove --scope user public-browser

Chrome プロファイル

デフォルトでは、Public Browser は新しい一時プロファイルで Chrome を起動します。Cookie、ログイン情報、拡張機能はありません。自分の Chrome プロファイルを使って Chrome を起動することもできます。

利用可能なプロファイルの一覧表示

npx public-browser profiles

プロファイルを指定して起動

方法は 3 つあります。環境に合ったものを選んでください。

# CLI flag
npx public-browser --profile "Work"

# Environment variable
PUBLIC_BROWSER_PROFILE="Work" npx public-browser

# MCP tool (call BEFORE any browser interaction)
configure_session({ profile: "Work" })

Chrome はデフォルトのデータディレクトリでのリモート操作を拒否するため、Public Browser はプロファイルフォルダーへのシンボリックリンクを含む軽量なラッパーディレクトリを作成し、そのディレクトリを指定して Chrome を起動します。ラッパーは Public Browser が Chrome を終了すると削除され、クラッシュ後に残ったラッパーも次回起動時に削除されます。プロファイルフォルダー自体が削除されることはありません。

引き継がれるものと引き継がれないもの。 ブックマーク、履歴、拡張機能、Chrome 自体の Google ログインは引き継がれるため、Google のサイトにはログイン済みです。macOS では、少なくとも他のサイトのログイン状態は引き継がれません。 現行の Chrome（153 でテスト済み）は、シンボリックリンク経由ではプロファイルの Cookie を読み込みません。Chrome のネットワークサービスのサンドボックスがラッパー配下のパスのみを許可するためです。そのため、サイトはログアウト状態で開き、セッション中のログインもプロファイルに保存されません。Linux と Windows では未テストです。agent-browser のように起動時にプロファイルをコピーする機能は、今後実装予定です。

デバッグ用ポートは開きません。 実際のプロファイルは --remote-debugging-pipe を介して操作されます。CDP は Public Browser のみが保持するパイプ経由で動作し、TCP ポートで待ち受けることはありません。マシン上の他のプログラムがブラウザーを乗っ取ることはできません。一方で、--attach と Script API のエスケープハッチ（page.cdp）は、実際のプロファイルでは動作しません。Chrome がパイプを拒否した場合、Public Browser はランダムなデバッグ用ポート（9222 は使用しません）で Chrome を再起動し、その旨を stderr と次のツール応答に 1 回表示します。この Chrome が実行されている間は、ローカルプログラムからプロファイルにアクセスできます。

Chrome がすでに開いている場合

Public Browser はロックファイルを調べて、これを検出します。リモートデバッグを有効にして Chrome が実行中の場合は、CDP 経由で接続します。有効でない場合は、先に Chrome を閉じるよう求める明確なエラーが表示されます。1 つのプロファイルを同時に開ける Public Browser は 1 つだけです。2 つ目のインスタンスは、プロファイルを使用している Chrome の PID を示すエラーで停止します。

Jev に最適です — 判断モデルには選択肢のメニューが必要で、Public Browser がそれを提供します

Jev（TypeSafe AI が2026年9月15日に発表、早期アクセス中）はチャットモデルではありません。プログラムの状態と、上限のある選択肢の集合を入力として受け取り、調整済み確率を伴う型付きの選択肢を1つ、70～500 ms で返します。入力トークン100万個あたり $0.042 で、出力は無料です。自由文は生成できないため、存在しないセレクターをでっち上げることもありません。TypeSafe はこれを「System One モデル」と呼んでいます。すでに2つのブラウザーエージェントがこれを使っています。browser-use/jev-ultrafast（Google Flights の検索を7.1秒、$0.0039で実行し、ブラウザープロトコル呼び出しを91%削減）と、jev-browser（12タスクのスイートで Playwright MCP より1.5倍高速、1.6倍低コスト。タスクあたり約$0.0005で自律的な成功率97%）です。

これらのループはどれも、ブラウザー側に同じ3つの要素を必要とします。Public Browser はまさにそれらを中心に構築されています。

Jev が必要とするもの	Public Browser が提供するもの
スクリーンショットや生の DOM ではなく、上限のあるアクションメニュー	view_page（filter: "interactive"）— エージェントが操作できる a11y ツリー要素。それぞれに安定した e-ref が付いています。9月のベンチマークでは、表示あたり平均1.2～1.3k文字で、Jev のページ予算約32kトークンと選択上限255個に十分収まります。
選択した選択肢を実行して検証できるように、アクション後も維持される参照	e-ref は呼び出し間でキャッシュされ、スクロールや DOM の再レンダリング後も維持されます。click／type／fill_form は DOM の差分（NEW／REMOVED／CHANGED）を返します。これは、Jev 方式のループが2回目のモデル呼び出しの代わりに使う、決定論的な検証シグナルになります。
ループに LLM を含めないプログラムによるドライバー	HTTP 経由の Script API (Python) と、プロセス内で動作する Node Library API — MCP サーバーと同じツールハンドラーを使用し、Jev ワーカーごとに Chrome を1つ起動します。ヘッドレスでも、お使いの Chrome プロファイルを使っても実行できます。

主張ではなく、実測値です。 examples/jev-loop.mjs は、Node Library を使った約150行のループです。テストカードで view_page → カードの参照を使った Jev の choice を1回（加えて「すでに完了？」を判定する boolean）→ click／type／fill_form → 繰り返し、という流れです。Jev はテキストを書けないため、「type」アクションを選んだ場合、そのフィールドに入力するリテラル値は gpt-4.1-nano が生成します。これは browser-use/jev-ultrafast が採用しているのと同じ分担です。公開ベンチマークページ の Level 1 カード6枚で、2026-09-18 に2回実行しました。Jev は Vercel AI Gateway 経由、Chrome はヘッドレスで実行しました。

	1回目	2回目
合格したカード	6/6	6/6
ステップ数 = Jev 呼び出し数（1ステップにつき1つの判断）	23	21
テキストモデルの呼び出し数（フォームフィールド、秘密コード、表の合計）	8	7
6枚すべての実行時間	20.2秒	16.4秒
6枚すべてのコスト（Jev は入力100万トークンあたり$0.042、nano は入力100万トークンあたり$0.10、出力100万トークンあたり$0.40）	$0.0012	$0.0011

カード1枚あたりでは約3秒、約$0.0002です。上記の9月の LLM 駆動型実行（MCP 経由で Opus 5を使用し、30枚のカードを281～296秒、$3.35～3.41で実行）では、カード1枚あたり約9～10秒、$0.11です。これはセットアップが異なります（フロンティアモデルはページ全体を読み、計画を立てます。一方、Jev はメニューから選ぶだけです）。そのため、比較対象をそろえたベンチマークではなく、「低コストの方式ではどれほどかかるか」を示すものとしてご覧ください。Level 1 は簡単な段階です。Level 2～4（観察、シャドウ DOM、キャンバス、競合状態）でも Jev のみのループが機能するかどうかは、まだわかっていません。それを検証するハーネスはリポジトリにあります。生データ：test-hardest/results/jev-loop-run1.json、run2。セットアップ：npm i ai @ai-sdk/openai public-browser、AI_GATEWAY_API_KEY + OPENAI_API_KEY、node examples/jev-loop.mjs。

スクリプト API（Python）— Jev ループに最適

Public Browser を利用する 2 つ目の方法は、LLM を介さずに Python から決定論的なブラウザー自動化を行うことです。スクリプトでは MCP サーバーと同じツール実装（Shared Core）を使用するため、click、navigate、fill_form などの改善はすべてスクリプトにも自動的に反映されます。MCP サーバーは AI 主導のワークフローを処理し、Script API は自分で作成する再現可能なスクリプト向けです。

LLM を使わない場合の速度はどの程度でしょうか。ベンチマークスイートの 24 テスト版をスクリプトで実行したところ、スイート全体が 21 秒 で完了しました（type: mcp-scripted、2026-04-04）。この数値は決定論的なスクリプト実行にかかる時間を示すものであり、Public Browser と他の MCP サーバーとの比較を示すものではありません。ベンチマーク にあるサーバー間の比較は、どちらも LLM 主導で行われています。

インストール

pip install publicbrowser

または、ソースをチェックアウトした状態からローカルパッケージをインストールします。

python -m pip install ./python

Chrome.connect() は、ローカルの public-browser バイナリまたは npx フォールバックを介して Public Browser サーバーをサブプロセスとして自動起動するため、Chrome の手動起動やポート設定は不要です。

従来の単一ファイル版： 手早くプロトタイプを作成する場合は、python/publicbrowser_standalone.py をプロジェクトにコピーできます。これは v1 の直接 CDP を使用しており、サーバー側の改善は反映されません。Shared Core の機能をすべて利用するには、ローカルの publicbrowser パッケージを使用してください。

仕組み

Python Script                        Escape Hatch (Power User)
    |                                    |
    v                                    v
HTTP POST /tool/{name}              WebSocket (CDP)
Port 9223                           Port 9222
    |                                    |
    v                                    |
Public Browser Server                    |
    |                                    |
    v                                    |
registry.executeTool()                   |
    |                                    |
    v                                    |
Tool Handler                             |
(click.ts, navigate.ts, ...)             |
    |                                    |
    v                                    v
Chrome <------------ CDP --------------->

スクリプトは、ポート 9223 で稼働する Public Browser サーバーに HTTP リクエストを送信します。サーバーは MCP サーバーとまったく同じツールハンドラーを実行します。1 つのコードベース、1 つのテストスイート（2,700 件以上のテスト）、2 つのアクセス方法です。

自動起動

Chrome.connect() はサーバーを自動的に検出して起動します。

1. 実行中のサーバー — ポート 9223 で GET /health を呼び出し、Public Browser サーバーが応答してキーを受け付けた場合にのみ接続します。そのポートで動作している別のプログラムは報告されますが、使用されることはありません。
2. PATH 内のバイナリ — PATH 内で public-browser を見つけ、--script を付けて起動します。
3. npx フォールバック — npx -y public-browser@latest -- --script を実行します。
4. 明示的なパス — カスタム設定では Chrome.connect(server_path="/path/to/public-browser") を指定します。

アクセスキー

Script API はキー（Authorization: Bearer <key>）を含むリクエストにのみ応答するため、別のユーザーアカウントで実行されている Web ページやプログラムから、この API を使ってブラウザーを操作することはできません。自分のユーザーアカウントで実行されているプログラムは、ブラウザープロファイルを読み取れるのと同様に、キーのファイルも読み取れます。キーはそれらから保護するものではありません。このキーを目にすることはほとんどありません。

• Chrome.connect() がサーバーを起動する場合、キーを生成し、PUBLIC_BROWSER_SCRIPT_TOKEN 環境変数で渡します。
• --script を指定して起動したサーバー（たとえば MCP 設定から起動する場合）は独自のキーを生成し、ユーザーのみが読み取れる ~/.public-browser/script-api-<port>.token に書き込みます。Chrome.connect() はそこからキーを読み取ります。
• 独自のキーを使うには、両側で PUBLIC_BROWSER_SCRIPT_TOKEN を設定するか、Chrome.connect(token=...) を渡します。

サーバーが実行されていない状態で、Chrome.connect() を呼び出すスクリプトが 2 つ同時に実行されると、それぞれが独自のキーでサーバーを起動します。一方はポートを取得し、もう一方は PermissionError を受け取ります。接続は一度だけ行い、その接続からタスクごとに 1 つのページを開いてください（chrome.new_page() は複数のスレッドから呼び出せます）。または、事前に public-browser --script でサーバーを起動すれば、すべてのスクリプトが同じキーのファイルを読み取ります。

キーのないリクエストは 401 を受け取ります。ブラウザーからのリクエスト（Origin ヘッダーを含むもの）、または Host が 127.0.0.1:<port> / localhost:<port> 以外のリクエストは 403 を受け取ります。これにより、ポートを推測された場合でも、Web ページや DNS リバインディングをブロックします。

アップグレード： サーバーと publicbrowser Python クライアントは対応するバージョンを組み合わせて使う必要があります。publicbrowser 2.0.0 には Public Browser 3.0.0 以降が必要です。また、publicbrowser 1.0.0 は 3.0.0 では動作しません。キーを送信しないため、サーバーが実行中でも ConnectionError: Public Browser server not reachable が報告されます。npx -y public-browser@latest -- --script を使った MCP 設定では、次回の起動時に新しいサーバーが取得されます。同時にクライアントも更新してください（pip install -U publicbrowser）。

例：ログインとデータ抽出

from publicbrowser import Chrome

chrome = Chrome.connect()

with chrome.new_page() as page:
    page.navigate("https://shop.example.com/login")
    page.fill({"#email": "[email protected]", "#password": "***"})
    page.click("button[type=submit]")
    page.wait_for("text=Dashboard")

    for cat in ["electronics", "furniture", "toys"]:
        page.navigate(f"https://shop.example.com/orders/{cat}")
        rows = page.evaluate(
            "[...document.querySelectorAll('tr')].map(r => r.textContent)"
        )
        save_csv(cat, rows)

chrome.close()

メソッド

メソッド	説明
Chrome.connect()	Public Browser サーバーに接続するか、自動的に起動します
chrome.new_page()	コンテキストマネージャー。新しいタブを開き、終了時に自動で閉じます
page.navigate(url)	ページに移動し、読み込みを待ちます
page.click(selector)	CSS セレクター（一致する要素が 1 つだけである必要があります）、表示テキスト（"text=Sign in"）、または ref（"e12"）でクリックします
page.type(selector, text)	入力欄にテキストを入力します
page.fill({"sel": "val"})	複数のフォーム項目に一度に入力します
page.wait_for(condition)	ページ内のテキスト（"text=..."）、ref、CSS セレクター（#、.、[）、"network_idle"、または JS 条件を待ちます
page.evaluate(expression)	JavaScript を実行し、結果を返します
page.download()	保留中のダウンロードを待ち、ダウンロードレポート（JSON または通知）を返します
page.close()	タブを閉じます（コンテキストマネージャーによって自動的に呼び出されます）
page.cdp.send(method, params)	エスケープハッチ。WebSocket 経由で CDP に直接アクセスします（下記参照）

エスケープハッチ：CDP に直接アクセスする

ネットワークインターセプト、コンソールログの購読、パフォーマンストレース、Cookie 管理など、高レベル API では対応していないユースケースでは、低レベルの CDP コマンドを直接実行できます。

with chrome.new_page() as page:
    page.navigate("https://example.com")

    # Enable network tracking
    page.cdp.send("Network.enable")

    # Get all cookies
    cookies = page.cdp.send("Network.getAllCookies")

    # Performance tracing
    page.cdp.send("Tracing.start", {"categories": "-*,devtools.timeline"})

エスケープハッチは、サーバーを介さずに WebSocket（ポート 9222）経由で Chrome と直接通信します。最初の send() 呼び出し時に遅延接続し、その後の呼び出しでは接続を再利用します。各ページには、正しいタブにルーティングされる専用の WebSocket が割り当てられます。Chrome のデバッグポートが必要なため、サーバーが実際のプロファイルを操作する場合（--profile）は利用できません。この場合、サーバーはデバッグポートなしで実行されるため、/session/create は cdp_ws_url: null と cdp_ws_note を返し、page.cdp は RuntimeError を発生させます。

MCP の共存

MCP サーバーと Python スクリプトを同時に実行する必要がある場合は、MCP 設定に --script を追加します。残りは Chrome.connect() が自動的に処理します。各スクリプトはそれぞれ独自のタブで動作し、MCP のタブには一切触れません。

MCP 設定での --script の有効化

Claude Code：

claude mcp add --scope user public-browser -- npx -y public-browser@latest -- --script

Cursor / Cline（mcp.json）：

{
  "mcpServers": {
    "public-browser": {
      "command": "npx",
      "args": ["-y", "public-browser@latest", "--", "--script"]
    }
  }
}

API リファレンスの全容と高度な例については、python/README.md をご覧ください。

Node ライブラリ API（1 つのプロセスで複数のインスタンスを実行）— Jev に最適

MCP サーバーと Python Script API は、どちらもプロセスごとに 1 つの Chrome を操作します。一度に複数のブラウザーが必要な場合、たとえば読み取り専用の調査用ブラウザーと、各エージェント専用の別の操作用ブラウザーが必要な場合、インスタンスごとに npx public-browser を起動すると、起動にそれぞれ 4～6 秒かかります。createSession() を使えば、同じセッションを独自の Node プロセス内で実行できます。

import { createSession } from "public-browser";

const research = await createSession({
  cdpUrl: "http://127.0.0.1:9333",          // or cdpPort: 9333
  userDataDir: "/var/agents/a1/research",   // created if missing
  headless: true,
  stealth: false,                            // stay identifiable — see below
  downloadDir: "/var/agents/a1/quarantine",  // never deleted by us
  downloadHash: true,                        // adds sha256 to every download
  downloadNaming: "suggested",               // real filenames, not GUIDs
  cortexDir: "/var/agents/a1/cortex",        // per-instance pattern store
  inheritEnv: ["HTTPS_PROXY"],               // opt in — see Environment below
});

const action = await createSession({ cdpPort: 9334, userDataDir: "/var/agents/a1/action" });

await research.callTool("navigate", { url: "https://example.com" });
const page = await research.callTool("view_page", {});

await research.close();
await action.close();

callTool(name, params) は MCP ツールと同じツール名とパラメーター（navigate、view_page、click、type、fill_form、run_plan、download など）を受け取り、同一のハンドラー（Shared Core）を経由します。

分離。 各セッションはデフォルトで独自のワーカースレッド内で実行されるため、モジュールレベルのキャッシュ（要素参照、セレクターキャッシュ、ビューポートの状態、ステルスフラグ、cortex マッチャー）はプロセスごとではなく、セッションごとに存在します。そのため、あるセッションが別のセッションに古い要素参照を渡すことはありません。

macOS で isolation: "process" を使用し、Public Browser の外部で起動した Chrome に接続した場合の測定値です（ワーカースレッドを使うと約 40 ms 短縮されます）。

	中央値
createSession() が独自のヘッドレス Chrome を起動	約 0.9 秒
実行中の Chrome に attach して、最初のツール応答を得るまで	約 0.7 秒
...実際のページに移動して読み取るまで	約 1.8 秒

接続時の所要時間の大部分は、Public Browser が自ら開くタブ用に Chrome がレンダラーを起動する時間です。接続したセッションが、他のユーザーに属するタブを引き継ぐことはありません。

スレッドはセキュリティ境界ではありません。同じプロセスのメモリーとファイル記述子を共有します。isolation: "process" はセッションごとに個別の OS プロセスをフォークします。別々のヒープ、ファイル記述子、クラッシュドメインを持つため、信頼モデル上そこを境界とするインテグレーターに適しています。isolation: "inline" は分離を完全に省略するため、スレッドが実行するセッションが 1 つだけの場合に限り適切です。

isolation	境界	起動時間	使用する状況
"worker"（デフォルト）	スレッド — プライベートなモジュールキャッシュ	約 1 秒	信頼できる 1 つのプロセスで複数のセッションを実行する場合
"process"	OS プロセス — プライベートなメモリーとファイル記述子	約 1 秒	セッションをホストと同じプロセスで共有できない場合
"inline"	なし — 呼び出し元のスレッド	最速	スレッドごとのセッションが 1 つだけの場合

待ち受け CDP ポートなし（transport: "pipe"）。 デフォルトでは、Chrome は --remote-debugging-port を指定して起動します。これにより --attach、Script API、クラッシュ後の再接続が可能になりますが、同時にマシン上の他のすべてのプロセスがそのブラウザーを操作できるということでもあります。実際のログイン状態を保持するセッションでは、これは自分で行う権限チェックを回避する手段になり得ます。

const action = await createSession({
  transport: "pipe",                      // no --remote-debugging-port at all
  userDataDir: "/var/agents/a1/action",
  headless: true,
});

CDP は子プロセスの標準入出力パイプを介して通信し、そのパイプを保持するのは Public Browser だけです。lsof に待ち受け状態は表示されず、別のプロセスが侵入する方法もありません。その代わり、ポートによって可能だった機能はすべて使えなくなります。Chrome のクラッシュ後に再接続することも、2 つ目のクライアントを使うことも、attach を使うこともできません。"pipe" と attach を組み合わせると、最初のツール呼び出し時ではなく createSession() 時に失敗します。名前付きの profile は、transport の指定にかかわらず常にパイプを介して実行されます。"pipe" が禁止するのは、Chrome がパイプを拒否したときに Public Browser が代わりに使用するランダムポートへのフォールバックのみです。session.transport には実際の接続方式が表示されます。何も待ち受けていない場合、session.cdpPort は undefined になります。デフォルト値を表示すると、ユーザーが開いている 9222 番ポートの Chrome を示してしまうためです。 環境。 セッションはホスト環境から開始するわけではありません。文書化された最小限の環境から開始し、意図的に範囲を広げます。クラウド認証情報、API キー、トークンを保持するオーケストレーターが、同じプロセスツリーを共有しているというだけで、ブラウザーセッションにそれらを渡すべきではありません。

セッションに常に渡されるのは ESSENTIAL_ENV_VARS です。これには PATH、HOME、一時ディレクトリ、CHROME_PATH、ロケール／タイムゾーン、Linux のディスプレイ変数、Windows の基本的なプロセス変数が含まれます。それ以外はすべてオプトインです。

// PATH/HOME/CHROME_PATH plus the proxy — and nothing else from the host.
await createSession({ inheritEnv: ["HTTPS_PROXY", "NO_PROXY"] });

// Full inheritance, the pre-2.8 behaviour.
await createSession({ inheritEnv: true });

プロキシ変数は意図的に必須項目から除外しています。プロキシ URL には認証情報が含まれる場合があるため、誤って継承させるのではなく、明示的に許可リストへ追加する仕組みになっています。

さらに、セッションはどの inheritEnv モードでも、Public Browser 自身の SILBERCUE_*／PUBLIC_BROWSER_* 設定変数を継承しません。それぞれにここで対応するオプションがあり、通常はホスト自身の Chrome 用に設定されるホストレベルの変数によって設定済みセッションが気付かないうちに別の接続先へ切り替わるのは、機能ではなく不具合です。オーケストレーターの環境に SILBERCUE_CHROME_HOST=10.9.9.9 が設定されていても、cdpPort: 9450 で作成されたセッションは引き続き 127.0.0.1:9450 と通信します。意図的に設定し直す場合は env を使います。

シャットダウン。 close() は Chrome が実際に終了してから解決します。終了には SIGTERM を送信し、5 秒後に SIGKILL を送信します。これにより、終了要求を送っただけのプロセスと競合することなく、次の起動に備えてポートとユーザーデータディレクトリを解放できます。

Chrome 1 つにつきセッション 1 つ。 一部の CDP 設定はセッション単位ではなくブラウザー全体に適用されます。その一例が Browser.setDownloadBehavior です。同じ Chrome に接続された 2 つのセッションはダウンロードディレクトリを共有し、最後に接続したセッションの設定が優先されます。

これはエラーなく失敗し、記録を壊します。設定が負けたセッションは自身の downloadDir 内のパスを報告し続けますが、ファイルはもう一方のディレクトリに書き込まれています。エラーが出ないため、path が何も指さなくなります。downloadDir が重要な場合は、各セッションにそれぞれ別の Chrome（専用ポートまたは transport: "pipe"）と専用のユーザーデータディレクトリを割り当ててください。

オプション	デフォルト	説明
cdpUrl	—	http://host:port、host:port、またはポート番号のみ。cdpPort／cdpHost より優先されます
cdpPort / cdpHost	9222 / 127.0.0.1	このセッションが操作する CDP エンドポイント。接続を待ち受けるものがない場合（transport: "pipe"、または名前付き profile）は session.cdpPort が undefined になります
userDataDir	—	自動起動時の Chrome --user-data-dir。インスタンスごとに 1 つのディレクトリ
profile	—	生のディレクトリの代わりに、名前付きの Chrome プロファイルを使用します。パイプ経由で実行され、CDP ポートはありません。macOS ではサイトのログイン状態は引き継がれません（Chrome プロファイル）
headless	false	Chrome をヘッドレスで起動します
stealth	true	false にすると、すべての navigator.webdriver マスキングが無効になります
attach	false	自動起動しません。実行中の Chrome に接続し、存在しない場合はすぐに失敗します
downloadDir	一時ディレクトリ	ダウンロード先です。指定したディレクトリは削除されません
downloadHash	false	完了したすべてのダウンロードについて sha256 を報告します
downloadNaming	"guid"	"suggested" にすると、ダウンロード完了後にサーバーから指定された名前へファイル名を変更します
cortexDir	~/.public-browser/cortex	インスタンスごとの cortex ストア
transport	"port"	"pipe" にすると、待ち受け CDP ポートなしで Chrome を起動します（接続も再接続もできません）
inheritEnv	false	必須項目のみ。配列の場合は必須項目＋許可リスト、true の場合はホスト環境変数全体
env	—	セッション用の追加環境変数。最後に適用されます
isolation	"worker"	"process" は OS プロセス境界、"inline" は境界なし
eager	false	最初の呼び出し時ではなく、createSession() 中に起動／接続します
startupTimeoutMs	30000	セッションのスレッド／プロセスが準備完了を報告するまでの猶予時間

CLI による複数インスタンスの起動

Node ホストを使わずに同じことを行います。Chrome ごとに 1 つのプロセスを起動し、それぞれ異なるポートを使用します。

public-browser --port 9333 --profile research --download-dir /q/research
public-browser --port 9334 --profile action   --download-dir /q/action

--profile を使うと Chrome はパイプ経由で動作し、--port は使用されません。Chrome がパイプを拒否した場合に限り、警告とともにランダムなポートが割り当てられます。

--profile <name> は、実際に使用している Chrome プロファイルのいずれかを使います。エージェントごとに使い捨ての Chrome を用意する場合は、代わりに任意のディレクトリを指定してください。存在しない場合は作成されます。

public-browser --port 9335 --user-data-dir /var/agents/a3/chrome

--attach は Chrome を起動せず、設定されたポートで既に実行中の Chrome に接続します。SILBERCUE_CHROME_PORT と SILBERCUE_SCRIPT_PORT は、それぞれ --port と --script-port に対応する環境変数であり、安定した公開仕様の一部です。

識別可能な自動化（--no-stealth）

デフォルトでは、Public Browser は navigator.webdriver をマスクして（undefined を返します）、--disable-blink-features=AutomationControlled を指定して Chrome を起動します。これは一般ユーザー向けの自動化には適したデフォルトですが、コンプライアンス上の理由によるクロール、社内のエージェント群、または利用規約で正直なシグナリングが求められるサイトなど、自動化がボットであることを明確に識別できる必要がある連携には適していません。

マスクを完全に無効にします。

public-browser --no-stealth
# or
SILBERCUE_STEALTH=0 npx public-browser

await createSession({ stealth: false });

ステルスを無効にすると、navigator.webdriver は true のままになり、ネイティブのゲッターも維持されます（Object.getOwnPropertyDescriptor(Navigator.prototype, "webdriver").get は引き続き [native code] を返します）。これは、ページ遷移やタブの切り替えを経ても永続し、こちらで後から修正する必要はありません。マスク用スクリプトは一切挿入されず、起動フラグも省略されます。

ダウンロード

ダウンロードファイルはセッションごとの一時ディレクトリに保存され、シャットダウン時に削除されます。--download-dir／PUBLIC_BROWSER_DOWNLOAD_DIR／downloadDir を使って、隔離用ディレクトリや共有ボリュームなど、独自のディレクトリを指定できます。指定したディレクトリが存在しない場合は作成され、Public Browser によって削除されることはありません。

--download-hash（または downloadHash: true）を指定すると、完了したすべてのダウンロードに sha256 も付与されるため、download ツールはパス、サイズ、ダイジェストを返します。

{"filename":"report.pdf","path":"/q/research/A1B2...","size":48213,"sizeKb":48,
 "url":"https://example.com/report.pdf","sha256":"9f86d081884c7d659a2f..."}

ファイル名。 Chrome はダウンロードを内部 GUID を使って保存するため、ディスク上のファイル名は A1B2... となり、実際の名前は filename フィールドにのみ記録されます。JSON を読み取る場合には問題ありませんが、別のものがディレクトリを走査する必要がある場合には不便です。--download-naming suggested（または downloadNaming: "suggested"、PUBLIC_BROWSER_DOWNLOAD_NAMING=suggested）を指定すると、完了した各ファイルの名前がサーバーから渡された名前に変更されます。

{"filename":"report.pdf","path":"/q/research/report.pdf","size":48213,"sizeKb":48,
 "url":"https://example.com/report.pdf","sha256":"9f86d081884c7d659a2f..."}

ファイル名はディスクに書き込まれる前にサニタイズされます。ベース名のみを使用し、制御文字は除去され、隠しファイルにはならず、長さにも上限が設定されます。名前が重複した場合は、既存のファイルを上書きせず、-1、-2、... のサフィックスが付与されます。filename には常に実際のファイル名が記録されるため、join(downloadDir, filename) は path と一致します。名前の変更に失敗した場合は、GUID のパスとサーバーから渡された名前がそのまま保持され、報告されます。名前の問題によってダウンロードファイルが失われることはありません。

タイミング。 action: "status" は、ダウンロードがないと報告する前に、ダウンロードの開始を最大 250 ミリ秒待ちます。Chrome はダウンロードを開始するクリックの数ミリ秒後に downloadWillBegin を発火するためです。この待機時間がないと、クリック直後の最初の呼び出しでは、既に始まっているダウンロードを見逃してしまいます。呼び出しごとに settle で調整できます（即時に確認するには {"action":"status","settle":0}、応答の遅いサーバーには 5000）。ダウンロードが開始されると、status は完了まで待機します。ただし、待機時間は timeout が上限です。

ポーリングループでは action: "list" を使用してください。セッションの履歴全体を即座に返し、開始も完了も待ちません。

ツールの概要

ツール	説明
閲覧と観察
view_page	安定した e-refs を持つアクセシビリティツリーです。ページを理解するための基本的な手段です。filter: "interactive"（デフォルト）ではエージェントが操作できる要素を返し、filter: "all" では見出し、段落、その他の静的テキストも含めます。
capture_image	WebP スクリーンショット。最大 800px、100KB 未満です。視覚的な確認専用です。refs は view_page から取得します。
console_logs	レベル／パターンでフィルタリングできるブラウザーコンソール出力
network_monitor	フィルタリングを指定してネットワークリクエストを開始／停止／照会します
observe	DOM の変更を監視します。collect（時間をかけてバッファリング）または until（条件を待ち、その後自動クリック）を使用します
wait_for	要素の表示、ページのテキスト、URL、ネットワークのアイドル状態、または JS 式を待ちます。assert: true を指定すると、一度だけ確認し、待機する代わりに型付きの code を返して失敗します
tab_status	アクティブなタブのキャッシュ済み URL／タイトル／読み込み状態／エラー（0ms）
virtual_desk	すべてのタブを安定した ID とともに一覧表示します。各セッションで最初に呼び出してください。
dom_snapshot	境界ボックス、計算済みスタイル、描画順序を表示します。空間に関する質問で view_page では答えられない場合に使用します。
操作
click	ref、セレクター、テキスト、または座標を指定して、実際の CDP マウスイベントを発生させます。応答には操作対象の要素が示されます（Clicked [e12] button "Save"）。DOM の差分（NEW／REMOVED／CHANGED）は、次のページ操作時、またはこの呼び出しで wait_for_diff: true を指定した場合に返されます。
type	ref／セレクターで指定した入力欄に入力します
fill_form	テキスト、<select>、チェックボックス、ラジオボタンを含むフォーム全体を 1 回の呼び出しで入力します。フィールドごとのステータスを返します。
press_key	Enter、Escape、Tab、矢印キー、ショートカット（Ctrl+K など）の実際の CDP キーボードイベントを発生させます
scroll	ページをスクロールするか、要素を表示領域に移動するか、特定のコンテナー内をスクロールします
file_upload	<input type="file"> にファイルをアップロードします
handle_dialog	操作を実行する前に、alert／confirm／prompt の処理方法を設定します
drag	要素間でネイティブの CDP ドラッグ＆ドロップを実行します
download	保留中のダウンロードを待つか、ダウンロード済みのセッションファイルを一覧表示します
ナビゲーション
navigate	URL を読み込みます。セッションでの最初の呼び出しは、ユーザーのタブを上書きしないよう virtual_desk に自動的にリダイレクトされます。
switch_tab	virtual_desk の ID を使ってタブを開く、切り替える、または閉じます
スクリプト
run_plan	変数、条件、saveAs、エラー処理方法、中断／再開に対応した複数ステップの一括実行です。
configure_session	セッションのデフォルト（タブ、タイムアウト）を表示／設定し、自動昇格の提案を受け入れます
batch_evaluate	複数の URL に順次アクセスし、それぞれのページで同じ JavaScript 式を実行します。
set_page_data	1 つの CDP メッセージに収まらない大きさのデータを、サーバー側で分割して window.__pb_data[key] に書き込みます。
evaluate	ページのコンテキストで JS を実行します。アンチパターンスキャナーが querySelector／.click() に警告を出します。

セレクターは厳密に照合されます。 CSS セレクターを受け取るツール（click、type、fill_form、press_key、scroll、drag、file_upload、observe）では、ページのメインドキュメント内で要素が 1 つだけ一致する必要があります。複数の要素が一致すると、呼び出しは何も実行せず、候補を最大 5 件、その refs とともに返します。いずれかの ref を使うか、より限定的なセレクターを指定してください。

MCP サーバーではなく CLI ではないのはなぜですか？

いくつかのブラウザー自動化プロジェクトは CLI を提供し、コーディングエージェントにシェルから呼び出すよう案内しています。agent-browser や Playwright CLI などがその例です。CLI はコンテキストにツール定義を追加しません。また、2026-09-23 に実施した現場での実行では、セッショントークン数で両 CLI が Public Browser 2.10.6 を上回りました。3 回の実行の中央値は、agent-browser が 4.22M、Playwright CLI が 4.61M に対し、Public Browser は 4.89M でした。この結果に応えるために 3.0 を開発しました。agent-browser との比較では、3.0 は現在、トークン数が 3 分の 1 少なくなっています（各 5 回の実行で 3.02M 対 4.53M）。Playwright CLI は再実行していません。

MCP のインターフェース分のコストを負担しながらも、この結果を実現しています。25 個のツール定義が、ワイヤー経由で配信されるコンテキストで約 4,837 トークンを占めます（tools/list 応答の文字数 / 4、npm run token-count）。テストでは 4,990 未満に抑えられており、再び増えることはありません。同じ方法で測ると、agent-browser のスキルファイルは約 900 トークンです。Public Browser は最初により多くのコストをかけ、その分を、より少なく高密度なステップによって取り戻します。そのための機能が run_plan です。N 個のステップを 1 回の呼び出しにまとめ、変数、条件、そして中断・再開を使ってサーバー側で実行します。一方、agent-browser の batch はコマンドの単純なリストを受け取り、制御フローはモデルに任せます。3.0 の 5 回の実行では、モデルは 1 回あたり 28～43 回 run_plan を使用しました。

モデルが MCP ツールのインターフェースと CLI の --help 出力のどちらに、より流暢に対応できるかは未解決の問題です。ある実践者による Chrome DevTools MCP と agent-browser CLI の比較では、MCP のインターフェースのほうが優れており、モデルは「まだ十分に使いこなせていないように見える」とされています（Pasi Huuhka、2026 年 1 月 28 日）。これは 1 つの比較であり、調査ではありません。

Browser MCP から移行する場合

Browser MCP（@browsermcp/mcp）は、2025 年 4 月 11 日の 0.1.3 以降、リリースされていません。また、その拡張機能ブリッジは 1 つのタブでしか動作しません。4 つの特徴を理由に選んだ場合、それぞれに対する Public Browser の状況は次のとおりです。高速 — 拡張機能ブリッジもクラウド経由の通信もなく、CDP 経由で Chrome に直接接続します。プライベート — お使いのマシン上で動作し、テレメトリーはありません。ログイン済み — 一部のみ対応しています。Chrome プロファイルの 1 つを使うと、ブックマーク、拡張機能、Chrome 自身の Google サインイン情報を利用できますが、macOS では他のサイトはログアウト状態で開始します（Chrome プロファイルを参照）。ステルス — ボット回避という意味では対応していません。デフォルトでは navigator.webdriver は true ではなく、クリックは実際の CDP マウスイベントですが、本格的なボット検出では自動化されたブラウザーとして検出されます。また、--no-stealth を指定すると、意図的に識別可能になります。1 つのコマンドでインストールできます（クイックスタート）。ツール名は異なります。browser_snapshot → view_page、browser_click → click、browser_type → type。view_page は、click と type が受け取る参照を返します。複数のタブに対応しています。

ベンチマーク

すべて当社独自のページ https://mcp-test.second-truth.com で測定した4つのデータセットです。35件のテストのうち、スコア対象は30件です（T5.3～T5.6はページ独自のランナーでしか開始できず、T4.7は自己申告のトークン数を採点するため、全参加者から除外しています）。Public Browser 3.0とagent-browserの比較（2026-09-24、最新）、全体比較（2026-09-23）、Public Browser 2.10.1とPlaywright MCPの比較（2026-09-03）、および履歴として保存している2026年4月の実行です。1つのデータセット内でのみ行を比較してください。ただし、9月の2つのデータセットはハーネス、ページ、モデルが共通で、実行日も1日違いのため比較できます（Public Browser 3.0と2026-09-23の全体比較を参照）。ページのソースはtest-hardest/page/index.htmlにあります。各実行ではページのハッシュ（suite.html_sha256。すべての9月の実行では、当該ファイルのハッシュである81e4b7aa…bed2）とテストIDが記録されます。実行時の生JSONと手法の詳細はtest-hardest/README.mdをご覧ください。

9月の各実行は、プリントモードで行う、新規のブラインドClaude Codeセッション1回分です。ドライバーモデルはclaude-opus-5で、プロンプトはすべて同一です。MCPの参加者には、各セッションでMCP サーバーを1つだけ割り当て、組み込みツールはWriteのみに制限しています。CLIの参加者は、自身のコマンドに限りBashを使用できます（PreToolUseフックtest-hardest/cli-guard.mjsが、それ以外のすべてをブロックします）。また、ツールの公式スキルファイルを追加のシステムプロンプトとして与えています。すべての数値はセッションのトランスクリプトから事後に集計しており、参加者による自己申告はありません。セッションのトークン数は入力＋出力＋キャッシュ書き込み＋キャッシュ読み取りです。各APIメッセージは1回だけカウントしています（tokens.dedup: "message.id"）。コストはOpus 5の定価に基づきます。

2026-09-24（最新）：Public Browser 3.0とagent-browser 0.38.1の比較

Claude Code 2.1.281、Chrome 153.0.8010.53を使用し、各陣営でスコア対象の実行を5回ずつ行いました。agent-browserはCLI経由で実行しており、MCPモードは測定していません。10回の実行に対するnode test-hardest/blind-run.mjs compareの出力：

MCP	バージョン	モデル	日付	実行	ステータス	合格	所要時間	ラウンド数	トークン数	MCP 呼び出し数	応答合計	Ø 応答	P95	スナップショットツール Ø
agent-browser	0.38.1	claude-opus-5	2026-09-23	agent-browser-run4	ok	29/30	333s	107	4.40M	104	76k	732	1982	2131 (2×)
agent-browser	0.38.1	claude-opus-5	2026-09-23	agent-browser-run6	ok	29/30	624s	123	5.33M	121	85k	702	2036	388 (19×)
agent-browser	0.38.1	claude-opus-5	2026-09-23	agent-browser-run7	ok	29/30	303s	101	4.48M	99	84k	852	4041	2281 (1×)
agent-browser	0.38.1	claude-opus-5	2026-09-23	agent-browser-run8	ok	29/30	349s	104	4.53M	102	85k	837	2733	2139 (2×)
agent-browser	0.38.1	claude-opus-5	2026-09-23	agent-browser-run10	ok	29/30	372s	112	4.97M	110	83k	754	2506	2018 (5×)
Public Browser	2.10.6	claude-opus-5	2026-09-24	public-browser-run18	ok	30/30	223s	68	2.47M	66	69k	1040	5597	4150 (3×)
Public Browser	2.10.6	claude-opus-5	2026-09-24	public-browser-run19	ok	30/30	245s	83	3.15M	81	79k	973	5049	1344 (11×)
Public Browser	2.10.6	claude-opus-5	2026-09-24	public-browser-run20	ok	30/30	223s	83	3.03M	81	117k	1445	5602	1909 (12×)
Public Browser	2.10.6	claude-opus-5	2026-09-24	public-browser-run21	ok	30/30	235s	81	2.99M	79	69k	867	5372	2855 (7×)
Public Browser	2.10.6	claude-opus-5	2026-09-24	public-browser-run22	ok	30/30	223s	76	3.02M	74	129k	1748	5866	2590 (11×)
中央値：セッションのトークン数は4.53Mに対して3.02M（−33％）、コストは$3.56に対して$2.40（−33％）、ツール呼び出しは104回に対して79回（−24％）、実時間は386秒に対して261秒（時間は−32％、つまり48％高速：386 / 261 = 1.48）です。ページ独自のタイマーであるDuration列では、349秒に対して223秒です。Public Browserの行に2.10.6と表示されているのは、バージョンを上げる前のコミット 366c194 のローカルビルドで実行したためです（test-hardest/results-local/、受け入れテストレポート acceptance-stage2-366c194.json）。このコミットのコードが3.0.0としてリリースされています。その後のコミットで変更されたのはドキュメント、ヘルプテキスト、メタデータ、リリース用ツールだけで、ベンチマークの経路には変更はありません。agent-browserの追加の2回の実行（agent-browser-run5、run9）は、セッションで許可リストにないツール（Read）を使用したためハーネスによって中断され、集計には含まれていません。どちらも29/30でした。

Public Browserが劣る点。 単一の応答サイズが大きく、文字数は754に対して平均値が1,040、P95が2,506に対して5,597（中央値）です。セッションの合計に含まれるツール定義とハンドシェイク手順の分だけ、スキルファイルに比べてコンテキストをより多く最初に消費します。合格率の差はT5.2だけで、ブラウザーの機能ではなく、navigator.webdriverのチェックによるものです。また、agent-browserにはPublic Browserにない機能があります（Public Browserを選ぶ理由を参照）。

3.0の前後。 同じ夜に同じ条件で測定したPublic Browser 2.10.6のトークン数は4.31M（5回の中央値、各30/30）で、agent-browserの4.53Mに対して僅差でした（baseline-2026-09-aufschliessen.json）。以下の朝のシリーズではagent-browserが上回っていました。3.0の変更（エラーの明示化、応答の短縮）により、Public Browserは3.02Mになりました。実際のサイト（Hacker News、Wikipedia、デモショップ）での検証では、変更前後ともすべてのタスクに合格しました（Public Browserのみ、タスクごとに2回実行。［real-sites-probe.mjs](test-hardest/real-sites-probe.mjs)）。

Public Browser 3.0と2026-09-23時点の比較対象

2026-09-24と2026-09-23のデータセットは、同じ条件で1日違いに実行されました。同一のハーネス、同一のページ（suite.html_sha256 = 81e4b7aa…bed2）、同一のドライバーモデルclaude-opus-5、同一のChrome 153.0.8010.53です。変更があったのはClaude Codeだけで、2026-09-23の2.1.280から2026-09-24の2.1.281に更新されています。2026-09-24の比較にあるagent-browserの行も、2026-09-23に実行したデータに基づいています。この表では、Public Browser 3.0の中央値（30/30 ×5、ツール呼び出し79回、セッションのトークン数3.02M、$2.40、261秒）を、各参加者の中央値と比較しています。負の値はPublic Browser 3.0の方が少なくて済むことを示します。agent-browserについては、比較対象の表にある3回実行の行ではなく、2026-09-24の5回実行の中央値を使用しています。

参加者	バージョン	合格	ツール呼び出し	セッションのトークン数	コスト	実時間
agent-browser	0.38.1	29/30 ×5（T5.2）	104（−24％）	4.53M（−33％）	$3.56（−33％）	386秒（−32％）
Playwright CLI	0.1.21	30/30 ×3	107（−26％）	4.61M（−34％）	$3.52（−32％）	454秒（−43％）
Playwright MCP	0.0.82	30/30 ×3	162（−51％）	7.84M（−61％）	$5.22（−54％）	494秒（−47％）
Chrome DevTools MCP	1.9.0	29/30 ×3（T5.2）	169（−53％）	10.33M（−71％）	$6.78（−65％）	535秒（−51％）
browser-use	0.13.10	24/30、26/30	384（−79％）	63.68M（−95％）	$36.06（−93％）	2,187秒（−88％）

制約：Public Browser 3.0は5回実行、他の参加者は3回（browser-useは2回）で、いずれも2026-09-23以降は再測定していません。実行ファイル：Public Browser 3.0はtest-hardest/results-local/（public-browser-run18～22）、それ以外はこのセクションの前後2つのセクションに記載されているとおり、test-hardest/results/にあります。

2026-09-23：全体比較（Public Browser 2.10.6）

Claude Code 2.1.280、Chrome 153.0.8010.53、参加者ごとに3回（browser-useは2回）実行した際の中央値：

参加者	バージョン	経由	合格	セッショントークン	コスト	ツール呼び出し	経過時間
Public Browser	2.10.6	MCP	30/30 ×3	4.89M	$3.75	90	323 s
agent-browser	0.38.1	CLI	29/30 ×3（T5.2）	4.22M	$3.39	93	385 s
Playwright CLI	0.1.21	CLI	30/30 ×3	4.61M	$3.52	107	454 s
Playwright MCP	0.0.82	MCP	30/30 ×3	7.84M	$5.22	162	494 s
Chrome DevTools MCP	1.9.0	MCP	29/30 ×3（T5.2）	10.33M	$6.78	169	535 s
browser-use	0.13.10	MCP	24/30、26/30	63.68M	$36.06	384	2,187 s

2つのCLIはトークン数でPublic Browser 2.10.6を上回っていました。3.0が目指したのは、この状況を変えることです。Playwright CLI、Playwright MCP、Chrome DevTools MCP、browser-useは3.0と比較するための再実行を行っていません。browser-useは、両方の実行でT3.3、T3.6、T4.4に失敗し、片方の実行ではT4.2にも失敗しました。実行ファイルはtest-hardest/results/にあります：public-browser-run3–5、agent-browser-run1–3、playwright-cli-run2–4、playwright-mcp-run7–9、chrome-devtools-mcp-run5–7、browser-use-run7–8。

2026-09-03：Public Browser 2.10.1とPlaywright MCP 0.0.80の比較

Claude Code 2.1.259を使用し、Public Browser 2.10.1、Playwright MCP 0.0.80、Chrome DevTools MCP 1.8.0はそれぞれ2回、browser-use 0.12.5は1回実行しました。これら7回の実行に対するnode test-hardest/blind-run.mjs compareの出力：

MCP	バージョン	モデル	日付	実行	ステータス	合格	所要時間	ラウンド	トークン	MCP呼び出し	応答合計	Ø応答	P95	スナップショットツールØ
browser-use	0.12.5	claude-opus-5	2026-09-03	browser-use-run6	ok	24/30	2023s	278	42.46M	276	15800k	57244	321033	102819（18×）
Chrome DevTools MCP	1.8.0	claude-opus-5	2026-09-03	chrome-devtools-mcp-run3	ok	29/30	547s	158	9.67M	156	149k	954	5676	4718（12×）
Chrome DevTools MCP	1.8.0	claude-opus-5	2026-09-03	chrome-devtools-mcp-run4	ok	29/30	558s	174	9.71M	172	120k	696	5271	3593（14×）
Playwright MCP	0.0.80	claude-opus-5	2026-09-03	playwright-mcp-run5	ok	30/30	468s	139	6.20M	137	101k	740	3617	1911（17×）
Playwright MCP	0.0.80	claude-opus-5	2026-09-03	playwright-mcp-run6	ok	30/30	493s	153	7.03M	151	99k	656	1587	2269（14×）
Public Browser	2.10.1	claude-opus-5	2026-09-03	public-browser-run1	ok	30/30	281s	85	4.53M	84	109k	1298	6077	2841（16×）
Public Browser	2.10.1	claude-opus-5	2026-09-03	public-browser-run2	ok	30/30	296s	88	4.49M	86	104k	1214	6479	3398（16×）

Public Browserのツール呼び出しは84回と86回で、Playwright MCPの137回と151回、Chrome DevTools MCPの156回と172回を下回りました。また、ページタイマーで281秒と296秒で完了し、Playwright MCPの468秒／493秒、Chrome DevTools MCPの547秒／558秒より速く完了しました。セッショントークンは4.53Mと4.49Mで、Playwright MCPの6.20Mと7.03Mに対して32％減、コストは$3.41と$3.35で、$4.28と$4.78に対して25％減でした。4回の実行はいずれも30/30でした。Playwright MCPの応答はより小さくなりました（Ø 740文字、656文字に対し、Public Browserは1,298文字、1,214文字）。このREADMEの以前のバージョンでは、これらの実行のトークン数を6.3M／6.5M対8.8M／9.6Mと記載していました。この数値はメッセージの使用量をコンテンツブロックごとに加算していました。APIメッセージごとに再集計したことで合計値は変わりましたが、比率は変わりません（以前は30％減、現在は32％減）。Chrome DevTools MCPが失敗したのはT5.2のみです。browser-use-run6は未完了です（2つのテストが開始されませんでした）。

2026年4月（過去の記録） — 24テストおよび35テストのスイート、ドライバーはOpus 4.6、9月の実行結果に置き換え済み

同じページで、**スイートの35テスト版（2026年4月）**を基準に測定しています — 5段階（基本、中級、上級、最難関、コミュニティで多い問題点）。35テストのうち4つはランナー専用のため、すべてのスコアから除外されており、このセクションの合格率はすべて**採点対象の31テスト**に対する割合です。拡張版の42テスト版はローカルに存在しますが、まだ公開されていません。ここに記載の数値はそのバージョンを基準に測定したものではありません。実行を主導したモデルはClaude Opus 4.6で、競合製品のバージョンは記録されていません。各実行は独立しており、ベンチマークページの値はページの読み込みごとにランダム化されます。すべての実行は、`/tmp`から新しいClaude Codeセッションを開始して行いました（プロジェクトのコンテキストによる偏りはありません）。**すべての指標は、[`test-hardest/measure-tool-calls.sh`](test-hardest/measure-tool-calls.sh)を使ってセッションのJSONLから事後測定**したもので、自己申告やMCP側の計測は使わず、`tool_use`ブロックの数と`tool_result`の文字数を数えただけです。

2026年4月のデータ。24テスト版と35テスト版のスイートを使用しており、上記の2026年9月の再実行結果に置き換えられています。

直接比較（24テスト版スイート、2026年4月 — 過去のスイートバージョン）

すべての行は同じテストページでClaude Opus 4.6を使ってLLM主導で実行し、各1回の実行結果を記録しています。Public Browserは2026-04-05に実行し、その他のサーバーは2026-04-02に実行しました。これは古い24テスト版のスイートです — 以下の採点対象31テストの数値と比較しないでください。

MCP サーバー	合格したテスト	所要時間	ツール呼び出し数	PBとの速度比較
Public Browser	24/24	350s	71	--
Playwright MCP	24/24	570s	138	1.6倍遅い
browser-use skill	24/24	725s	117	2.1倍遅い
claude-in-chrome	24/24	772s	193	2.2倍遅い
browser-use	16/24	1813s	124	5.2倍遅い

2026年4月に各1回実行した結果（24テスト版スイート、Opus 4.6）では、Public Browserが必要としたツール呼び出しは71回だったのに対し、Playwright MCPは138回でした — 同じ24テストに合格するためのラウンドトリップがおよそ半分です。上記の2026年9月の実行結果が最新の数値です。生データ：test-hardest/benchmark-*.json（Public Browserの行：benchmark-silbercuechrome_mcp-llm-2026-04-05.json、type: llm-driven）。

合格率 + 所要時間（採点可能なテスト31件、LLM 主導）

各行は記録された1回の実行です。実行 ID を記載しているため、各数値を test-hardest/results/ 内の1つの実行 JSON から追跡できます。複数回の実行を平均していません。

MCP	合格	所要時間	実行
Public Browser	30/31（97%）	598s	実行 5
Playwright MCP	29/31（94%）	563s	実行 2
Playwright CLI	28/31（90%）	376s	実行 1
Chrome DevTools MCP（Google）	27/31（87%）	535s	実行 2
browser-use	21/31（68%）	1870s	実行 5
Browser MCP（browsermcp）	6/31（19%）	294s、中断	実行 1
claude-in-chrome	24件のテストデータのみ、再ベンチマーク未実施	—	—

複数回の実行を記録しているサーバーでは、上の行だけでなく結果の幅も確認できます。Playwright MCP は3回の実行（実行 2～4）で29～30/31の範囲で、最高は実行 3 の30/31（449s）です。Chrome DevTools MCP は27～29/31の範囲で、最高は実行 1 の29/31（518s）です。以下のツール効率分析では、ツールの動作を最初から最後まで計測した実行であるため、どちらも実行 2 の数値を引用しています。合格率については、この分野では実質的に同等です。継続的な違いは応答サイズであり、測定したすべての Playwright 実行（実行 2～4、平均1,216～1,467文字）でこの傾向が見られます。

ツール効率（公平な指標）

各ツール呼び出しの応答文字数を直接測定し、ツール名ごとに分類して、chars/4 でトークン数を推定します。この指標を使う理由は、4月の実行では、セッションレベルのトークン差分の大部分が LLM のオーバーヘッド（システムプロンプト + CLAUDE.md + 会話履歴 = 予算の約80～90%）に左右され、MCP 間の差はわずか5～15%しか示さなかったためです。ブラウザーサーバーの比較には信頼できない指標です。ツールの応答サイズは、MCP サーバーが実際に制御する部分です。(2026年9月の実行は異なります。/tmp から実施したブラインドセッションで、CLAUDE.md はなく、各実行の新規入力トークンは170～304件です。そのため、セッション合計を比較でき、上記に記載しています。)

Public Browser の実行 5 と Playwright MCP の実行 2 — 上記の合格率表と同じ2回の実行です。

指標	Public Browser	Playwright MCP	差
ツール呼び出し（MCP のみ）	151	121	+25%（PB は呼び出し数が多く、各呼び出しは小さい）
平均応答サイズ	807文字	1,448文字	PB は1.8倍コンパクト
平均応答トークン数の推定値	201	362	PB は1.8倍コンパクト
P95 応答	2,328文字	8,068文字	PB は3.5倍コンパクト
応答コンテンツ合計	128k文字	175k文字	PB は27%少ない

ツール別の内訳（差が生じる箇所）

ツール	Public Browser の平均	Playwright MCP の平均	評価
view_page¹ / browser_snapshot	1,124文字（21回）	6,084文字（8回）	PB は呼び出しあたり5.4倍コンパクト
evaluate / browser_evaluate	510文字（33回）	2,155文字（47回）	PB は呼び出しあたり4.2倍コンパクト
type / browser_type	88文字（13回）	147文字（13回）	PB は1.7倍コンパクト
click / browser_click	1,278文字（63回）	463文字（44回）	Playwright は2.8倍軽量 — ただし、以下のトレードオフを参照

¹ 2026年4月の実行では read_page として記録されています。ツール名はその後 view_page に変更されました。

Ambient-Context のトレードオフ

Ambient Context — Claude は DOM の変更を追加の view_page なしで確認できます

Public Browser の click は、すべてのクリック応答に DOM の差分（NEW/REMOVED/CHANGED の行）が含まれるため、Playwright より 2.8 倍大きくなります。Playwright は確認のみを返すため、LLM は通常、何が起きたかを確認するために browser_snapshot または browser_evaluate を続けて呼び出します。ベンチマーク全体では、Playwright MCP は平均 2,155 文字の browser_evaluate 呼び出しを 47 回行うのに対し、Public Browser は平均 510 文字の呼び出しを 33 回行います。Public Browser は差分をインラインで返します。その結果、PB の click+read_page+evaluate の合計は 120k 文字で、Playwright MCP の 170k 文字より少なく、応答全体のコンテンツが 30% 削減されます。

2026 年 4 月、Opus 4.6：view_page は Playwright MCP の browser_snapshot より 5.4 倍コンパクトでした（旧情報 — 2026 年 9 月の Playwright MCP 0.0.80 との比較では当てはまりません）

35 件のテストからなるベンチマークで測定しました（2026-04-09）：Public Browser の view_page は呼び出しあたり平均 1,124 文字で、Playwright MCP の browser_snapshot は 6,084 文字でした。同じページ、同じテストスイート、同じ LLM ドライバーです。a11y ツリーの圧縮と Ambient Context のパイプラインにより、エージェントが実際に必要とする情報だけを送信していました。応答が小さくなり、コンテキストへの負荷が減り、実行コストも抑えられました。これが 2026 年 4 月時点の状況です。Playwright MCP 0.0.80 との比較では、もう当てはまりません。このリリースでスナップショット形式が大幅にコンパクトになり、9 月の実行では view_page が 2,841 文字と 3,398 文字であるのに対し、browser_snapshot は平均 1,911 文字と 2,269 文字です。詳しくは上記の2026 年 9 月（最新）を参照してください。

プロトコル全体、テストごとの内訳、tool_efficiency ブロックを含む生の JSON 実行結果については、test-hardest/README.mdを参照してください。

Cortex — ローカルのツールシーケンスヒント

Public Browser には Cortex と呼ばれる小さな学習レイヤーが含まれています。どの種類のページでどのツールシーケンスが成功したかを記録し、エージェントが後で同じ種類のページにアクセスしたとき、最有力のツールが P ≥ 0.9 に達すると、最も可能性の高い次のツールを示す 1 行を navigate および view_page の応答に追加します。例：Cortex (login): next → fill_form (P=0.92), click (P=0.08)。ML モデルも、トレーニング手順も、ネットワークアクセスもありません。

仕組み

1. ページ分類 — すべてのページは、アクセシビリティツリーに基づいて 16 種類の機能タイプのいずれかに分類されます：login、signup、mfa、search_form、search_results、data_table、form_simple、form_wizard、article、navigation、dashboard、settings、media、checkout、profile、error（または unknown）。分類器はルールベース（ARIA ロール、ランドマーク、キーワードシグナル）で、ドメインや URL は関与しません。

2. パターン記録 — navigate で始まり、その後に成功したツール呼び出しが続くシーケンス（60 秒以内に 2～20 回の呼び出し。例：login ページでの navigate → view_page → fill_form → click）は、エントリーに対する Merkle ハッシュツリー（整合性チェック用の tree-head.json）とともに ~/.public-browser/cortex/patterns.jsonl に保存されます。ページタイプごとに直近のシーケンスのみが保持されるため、ファイルにはページタイプごとに最大 1 行だけ保存されます。保存されるのはページタイプ、ツール名、コンテンツハッシュ、タイムスタンプのみで、URL、ページコンテンツ、PII は保存されません。

3. マルコフ予測 — 保存されたシーケンスから、P(next_tool | last_tool, page_type) をモデル化する一次マルコフテーブルが作成されます。最上位の予測がヒントの行に表示されます。古いエントリーは減衰し（0.95/週）、30 日後に削除されます。

4. スターターテーブル — 手書きの遷移テーブル（community-markov.json）がパッケージに含まれているため、新規インストール直後から、何も記録されていなくてもヒントが表示されます。ファイル名にかかわらず、収集した使用データは含まれていません。読み込み時にテーブルの SHA-256 が検証され、ローカルパターンと統合されます（ローカルデータが優先されます）。

プライバシーを設計段階から考慮

Cortex が保存するのは構造メタデータのみで、保存先もお使いのマシン上だけです。ページの種類（ドメインではありません）、ツール名（引数ではありません）、コンテンツのハッシュ（コンテンツそのものではありません）を保存します。login パターンから、どのログインページにアクセスしたかが明らかになることはありません。アップロードは一切行われません。

ローカル摩擦ログ（開発者のオプトイン）

Public Browser 自体の開発向けには、完全にローカルで動作する別のオプトイン機能もあります。SILBERCUE_CHROME_FRICTION_LOG=1 を設定すると、サーバーは実行ごとにツール呼び出し、ツールエラー、検出されたフォールバックの連鎖を数え、~/.silbercue-chrome/friction-queue.json に記録します。記録するのはカウンター、タイムスタンプ、作業ディレクトリのみで、ページのコンテンツ、URL、ユーザー入力は記録しません。また、情報がマシンの外に送信されることはありません。この変数を設定しない場合、コードパス自体が実行されず、ファイルもカウンターもヒントも作成されません。

アーキテクチャ

Public Browser (Node.js MCP server, public-browser)
+-- @modelcontextprotocol/sdk (stdio transport)
+-- CDP Client
|   +-- WebSocket transport (existing Chrome on :9222)
|   +-- Pipe transport (auto-launched Chrome with --remote-debugging-pipe)
+-- Auto-Launch: Chrome + optimal flags, visible by default
+-- A11y-tree cache + Selector cache
+-- Session Manager (OOPIF support for iframes and Shadow DOM)
+-- Tab State Cache (URL/title/ready across tabs)
+-- Cortex (local tool-sequence hints)
|   +-- Page Classifier (16 page types from a11y-tree)
|   +-- Pattern Recorder + Merkle Log (local persistence)
|   +-- Markov Table (transition predictions)
|   +-- Starter Table (hand-written, shipped, SHA-256 verified)
|   +-- Hint Matcher (delivers predictions to tool responses)
+-- Script API (Python, `pip install publicbrowser`)
|   +-- Shared Core via HTTP (:9223) — same tool handlers as MCP
|   +-- Escape Hatch via WebSocket (:9222) — direct CDP for power users
+-- 25 tools
    Reading - Interaction - Navigation - Scripting - Observation

接続の優先順位：

1. 自動起動（デフォルト、設定不要） — --remote-debugging-pipe を使用して Chrome を子プロセスとして起動します。ウィンドウが表示され、信頼性の高いスクリーンショットとキーボードフォーカスを実現するためのフラグがすべて設定されます。
2. WebSocket（オプション） — すでに --remote-debugging-port=9222 を指定して Chrome を実行している場合、Public Browser はそちらに接続します。独自の --user-data-dir を指定して自分で起動した Chrome を操作する場合に使用します（Chrome はデフォルトのプロファイルディレクトリでのリモートデバッグを拒否します）。

要件

• Node.js >= 20
• Google Chrome、Chromium、または Chromium ベースのブラウザー（macOS/Linux/Windows で自動検出。CHROME_PATH で上書き可能）

環境変数

変数	値	デフォルト	説明
SILBERCUE_CHROME_AUTO_LAUNCH	true / false	true	実行中のインスタンスが見つからない場合に Chrome を自動起動します
SILBERCUE_CHROME_HEADLESS	true / false	false	CI／サーバー環境向けのヘッドレスモードをオプトインで有効にします
SILBERCUE_CHROME_PORT	1–65535	9222	CDP デバッグポートです。デフォルト以外の値を指定すると、ユーザーのブラウザーと競合しないよう、分離された Chrome インスタンス（別の --user-data-dir）を起動します。別名：PUBLIC_BROWSER_CHROME_PORT
SILBERCUE_CHROME_HOST	ホスト	127.0.0.1	CDP ホストです。別名：PUBLIC_BROWSER_CHROME_HOST
SILBERCUE_SCRIPT_PORT	1–65535	9223	スクリプト API ポートです（--script が必要）。別名：PUBLIC_BROWSER_SCRIPT_PORT
PUBLIC_BROWSER_SCRIPT_TOKEN	文字列	—（ランダム）	スクリプト API キーです。未設定の場合、--script を指定して起動したサーバーがキーを生成し、~/.public-browser/script-api-<port>.token に書き込みます（モード 0600）
SILBERCUE_STEALTH	0 / 1	1	0 にすると、navigator.webdriver のマスキングを無効にします。別名：PUBLIC_BROWSER_STEALTH
PUBLIC_BROWSER_DOWNLOAD_DIR	パス	—（一時ディレクトリ）	ダウンロードの保存先ディレクトリです。存在しない場合は作成され、削除されることはありません
PUBLIC_BROWSER_DOWNLOAD_HASH	1 / true	—（オフ）	完了したすべてのダウンロードについて sha256 を報告します
PUBLIC_BROWSER_DOWNLOAD_NAMING	guid / suggested	guid	suggested を指定すると、完了したダウンロードの名前がサーバーから渡されたファイル名に変更されます
PUBLIC_BROWSER_CORTEX_DIR	パス	~/.public-browser/cortex	インスタンスごとの Cortex パターンストアです
SILBERCUE_CHROME_PROFILE	パス	—	Chrome のユーザープロファイルディレクトリです（自動起動時のみ）。別名：PUBLIC_BROWSER_PROFILE（プロファイル名）
CHROME_PATH	パス	—	Chrome バイナリへのパスです（自動検出を上書きします）

無効な値を指定すると、明示的にエラーになります。解析できないポートや命名モードを指定すると、9222 に暗黙にフォールバックするのではなく、名前付きエラーで起動が中止されます。 Node ライブラリ経由で作成されたセッションでは、この表の変数のうち CHROME_PATH 以外はすべて無視されます。詳しくはNode ライブラリ API（1 つのプロセスで複数のインスタンスを実行 — JEV に最適）をご覧ください。

ライセンス

MIT ライセンスです。詳しくは LICENSE をご覧ください。商用・非商用を問わず、自由にご利用いただけます。

コントリビュート

github.com/Silbercue/public-browser で Issue やプルリクエストを歓迎します。

プライバシー

Public Browser はすべてお使いのマシン上で実行されます。ブラウザーの自動化はすべて、CDP を介してローカルで行われます。Cortex の学習レイヤーがローカルに保存するのは構造的なメタデータのみです（ページの種類、ツール名、コンテンツハッシュ。URL、ドメイン、ページ内容、個人を特定できる情報は含まれません）。テレメトリーのアップロードはなく、Cortex のデータがマシンの外部に送信されることはありません。

Chrome を画面に表示して実行すると、ページ内に小さな Public Browser バーが表示され、操作を見ている人に向けて案内します（aria-hidden なので、エージェントには見えません）。5 回目のツール呼び出し以降、10 分ごとに 20 秒間、リンク（GitHub のスターまたは Jev のヒント）が表示されます。一度クリックするか閉じると、以降は表示されません（~/.public-browser/nudge.json に記録されます）。ヘッドレスセッションでは表示されません。

関連項目

iOS 向けにも開発していますか？SilbercueSwift は iOS Simulator 向けの同じアイデアです。

リンク

• GitHub リポジトリ
• npm パッケージ
• ベンチマークテストサイト