Browser Run：エージェントにブラウザを与える

2026-04-15 — Kathy Liao — 読了約8分

AIエージェントはウェブとやり取りする必要があります。そのためにはブラウザが必要です。サイトの移動、ページの読み取り、フォーム入力、データ抽出、スクリーンショット取得を行い、期待どおりに動いているか観察し、人間が必要なら介入できる仕組みも必要です。そしてこれらを大規模に実行できなければなりません。

本日、Browser RenderingをBrowser Runに名称変更し、AIエージェント向けのブラウザとして重要な機能をリリースします。

Browser Renderingという名前は製品の全体像を十分に表していませんでした。Browser RunはCloudflareのグローバルネットワーク上でフルブラウザセッションを実行し、コードやAIで操作し、セッションを記録・再生し、コンテンツをクロールし、リアルタイムでデバッグし、エージェントが助けを必要とする際に人間が介入できるようにします。

新機能ハイライト

• Live View：エージェントが見ているものとその操作をリアルタイムで可視化。動作確認や不具合の原因特定が瞬時に可能。
• Human in the Loop（ヒューマン・イン・ザ・ループ）：ログインページや想定外のエッジケースでエージェントが詰まったときに、人間に引き継いで解決後に制御を戻すことが可能。
• Chrome DevTools Protocol (CDP) エンドポイント：ブラウザ制御の根幹を成すCDPを直接公開。既存のCDPスクリプトやツールがCloudflare上で動作します（新）。
• MCPクライアント対応：Claude Desktop、Cursor、OpenCodeなどのAIコーディングエージェントがBrowser Runをリモートブラウザとして使用可能（新）。
• WebMCPサポート：WebMCPにより、ウェブサイトはエージェントが発見・呼び出せるアクションを宣言でき、ナビゲーションの信頼性が向上します（新）。
• Session Recordings：DOMの変更、ユーザー操作、ページ遷移を含むセッションを記録し、デバッグに利用可能（新）。
• 上限強化：同時ブラウザ数が30から120へ（4倍）、Quick Actionsは10リクエスト/秒。

エージェントが必要とするすべて

エージェントがウェブをブラウズするときに必要な要素と、各機能がどのように当てはまるかを整理します。

What an agent needs | Browser Run（旧: Browser Rendering）

1. ブラウザオンデマンド

• ChromeブラウザがCloudflareのグローバルネットワーク上で利用可能

2. ブラウザを制御する手段

• ナビゲート、クリック、フォーム入力、スクリーンショットなどをPuppeteer、Playwright、CDP（新）、MCPクライアント対応（新）、WebMCP（新）で実行

3. 可観測性

• Live View（新）、Session Recordings（新）、ダッシュボード再設計（新）

4. 人間の介入

• Human in the Loop（新）

5. スケール

• Quick Actions: 10 リクエスト/秒、同時ブラウザ: 120

1. ブラウザを開く

まず、エージェントにはブラウザが必要です。Browser Runでは、エージェントがCloudflareのグローバルネットワーク上でヘッドレスChromeインスタンスをオンデマンドで起動できます。インフラ管理やChromeのバージョン管理は不要です。ブラウザセッションはユーザーに近い場所で開かれるためレイテンシが低く、必要に応じてスケールします。

Browser RunをAgents SDKと組み合わせれば、ウェブをブラウズし、全てを記憶し、自律的に行動する長時間稼働のエージェントを構築できます。

2. 操作する

エージェントがブラウザを持ったら、それを制御する手段が必要です。Browser Runは複数のアプローチをサポートします：低レベルのCDPとWebMCP、既存の高レベル自動化であるPuppeteerとPlaywright、そして単純タスク用のQuick Actions。以下で詳述します。

Chrome DevTools Protocol (CDP) エンドポイント

Chrome DevTools Protocol（CDP）はブラウザ自動化を支える低レベルプロトコルです。CDPを直接公開することで、エージェントツールのエコシステムや既存のCDP自動化スクリプトがBrowser Runを利用できるようになります。Chrome DevToolsを開いてページを検査したとき、背後で動いているのがCDPです。Puppeteer、Playwright、および多くのエージェントフレームワークはその上に構築されています。

これまでも実際にはCDPを通じてBrowser Runを利用していましたが、今回CDPを直接エンドポイントとして公開します。これはエージェントにとって重要で、CDPはブラウザに対して可能な限り最大の制御を与えます。エージェントフレームワークはCDPをネイティブに扱えるため、直接Browser Runに接続できます。CDPはPuppeteerやPlaywrightでは提供されない機能、例えばJavaScriptデバッグなどをアンロックします。また高レベルライブラリを介さず生のCDPメッセージを扱えるため、モデルに直接メッセージを渡してトークン効率のよいブラウザ制御ができます。

既にセルフホストのChromeでCDP自動化スクリプトを動かしている場合、1行の設定変更でBrowser Run上で動作します。WebSocket URLをBrowser Runに向けるだけで自前のブラウザインフラ管理を止められます。

// Before: connecting to self-hosted Chrome
const browser = await puppeteer.connect({ browserWSEndpoint: 'ws://localhost:9222/devtools/browser' });

// After: connecting to Browser Run
const browser = await puppeteer.connect({ browserWSEndpoint: 'wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser', headers: { 'Authorization': 'Bearer <API_TOKEN>' } });

CDPエンドポイントにより、Browser Runはより多様な言語や環境からアクセス可能になります。Cloudflare Workerを自分で書く必要はありません（既にWorkersを使っている場合は何も変わりません）。

MCPクライアントでBrowser Runを使う

Browser RunがCDPを公開したので、Claude Desktop、Cursor、Codex、OpenCodeなどのMCPクライアントがBrowser Runをリモートブラウザとして使用できます。chrome-devtools-mcpパッケージはCDPのフル機能にAIコーディングアシスタントがアクセスできるようにするMCPサーバーで、信頼性の高い自動化、詳細なデバッグ、パフォーマンス解析を可能にします。以下はClaude Desktop用の設定例です：

{
  "mcpServers": {
    "browser-rendering": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser?keep_alive=600000",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
      ]
    }
  }
}

他のMCPクライアントについては、Browser RunとMCPクライアントを使うドキュメントを参照してください。

WebMCPサポート

インターネットは人間向けに作られているため、現状ではAIエージェントによるナビゲーションは信頼性が低いことが多いです。私たちは将来、ウェブを使うのが人間よりもエージェントの方が多くなると予測しています。その世界では、サイトはエージェントフレンドリーである必要があります。そこでWebMCPをサポートします。WebMCPはGoogle Chromeチームが開発したブラウザAPIで、Chromium 146+で導入されました。

WebMCPにより、ウェブサイトはページ上でエージェントが発見し呼び出せるアクションを公開できます。これにより、エージェントはUIを推測してループする代わりに、公開されたツールを直接呼び出してナビゲーションをより確実に行えます。

• navigator.modelContext：サイトがツールを登録するためのAPI
• navigator.modelContextTesting：エージェントがそのツールを発見・実行するためのAPI

たとえば旅行予約サイトをエージェントが訪れた際、従来はUIを解析して操作方法を見つける必要がありました。WebMCPを使えばサイトが「search_flightsというツールがあり、origin、destination、dateを受け取る」と宣言でき、エージェントは直接そのツールを呼び出せます。これによりUI変更による壊れやすさが緩和されます。

ツールはページで発見され、事前にロードされるわけではありません。これは、すべてのサイトに対してMCPサーバーを事前に用意することが現実的でない長い尾のウェブにおいて重要です。

開発中のブラウザ機能を安定版より前に試せるよう、Chrome betaを実行する実験プールも用意しています。また、Wranglerのブラウザコマンドを導入し、CLIからブラウザセッションを直接作成・管理・表示できるようになりました。WebMCP対応ブラウザにアクセスするには、実験プールでセッションを作成する次のWranglerコマンドを使用します：

npm i -g wrangler@latest
wrangler browser create --lab --keepAlive 300

既存のBrowser Runの利用方法

CDPとWebMCPは新機能ですが、従来どおりPuppeteer、Playwright、Stagehandを使ってBrowser Runでフルブラウザ自動化を行えます。スクリーンショット取得、PDF生成、Markdown抽出のような簡易タスクにはQuick Actionエンドポイントもあります。

/ crawl エンドポイント — ウェブコンテンツのクロール

最近、単一APIコールでサイト全体をクロールできる /crawl エンドポイントを公開しました。開始URLを与えるとページを自動的に発見してスクレイピングし、HTML、Markdown、構造化JSONのいずれかで返します。クロール深度や範囲の指定、変更のないページをスキップ、特定パスの包含・除外などの追加パラメータも用意しています。

/ crawl は「マナーの良いクローラ」として設計しました。デフォルトでサイトオーナーの設定を尊重し、署名済みのエージェントIDを持つエージェントとして振る舞い（Web Bot Authで暗号的に署名）、カスタマイズ不可のUser-Agentを使用し、robots.txtとAI Crawl Controlに従います。Cloudflareのボット保護やCAPTCHAを回避することはありません。サイトオーナーがコンテンツのアクセス可否を選び、/crawlはそれを尊重します。

Initiate a crawl

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
 -H 'Authorization: Bearer <apiToken>' \
 -H 'Content-Type: application/json' \
 -d '{ "url": "https://blog.cloudflare.com/" }'

3) 観察する

自動化は常に一発でうまく行くとは限りません。自動化が失敗したときに原因が分からないというフィードバックを多く受けたため、エージェントが見ているものをライブでも事後でも正確に把握できる複数の方法を追加しました。

Live View

Live Viewでは、エージェントのブラウザセッションをリアルタイムで監視できます。デバッグ中や長時間の自動化スクリプト実行時に、発生していることをそのまま確認できます。ページ本体だけでなくDOM、コンソール、ネットワークリクエストも含まれます。期待したボタンがない、認証が必要、CAPTCHAが出る、といった問題を即座に検知できます。

Live Viewには2つのアクセス方法があります。コードからは、検査したいブラウザのsession_idを取得してレスポンスに含まれるdevtoolsFrontendURLをChromeで開きます。ダッシュボードからは、Browser Runの新しいLive Sessionsタブで任意のアクティブセッションをクリックします。

Session Recordings

常時監視できるわけではないため、Session RecordingsでDOMの変更、マウス・キーボードイベント、ページ遷移を構造化JSONとしてキャプチャし、セッション終了後に再生できます。ブラウザ起動時に recording:true を渡すとSession Recordingsを有効にできます。セッション終了後はCloudflareダッシュボードのRunsタブから録画にアクセスするか、APIで取得してrrweb-playerで再生できます。次のアップデートでは録画中の任意のポイントでDOM状態やコンソール出力を検査する機能を追加予定です。

ダッシュボード再設計

以前はBrowser Runダッシュボードはブラウザセッションのログのみを表示していました。リクエスト（スクリーンショット、PDF、Markdown、クロール...）