Cloudflare Browser Runの新機能：ブラウザ自動化を承認済みホストに限定

2026年9月14日、Cloudflare Browser Runに、クライアント向けのブラウザ自動化の提供方法を変える2つの制御が加わりました。セッションの通信先を承認済みホスト名のリスト内に限定でき、レビュー担当者は操作権限を持たずにLive Viewで実行状況を確認できます。ホスト名は直接50件まで、共有ドメインセットは4つまで指定できます。しかし重要なのはリストの大きさではなく、運用上の境界を明確にできることです。

変わったのは1つではなく、2つの境界

Browser Runのセッションは、リモートで動作するChromeインスタンスです。通常はPuppeteer、Playwright、またはChrome DevTools Protocol（一般にCDP）からコードで操作します。

新しいセッションガードレールは、そのブラウザがHTTPまたはHTTPSでリクエストできる送信先ホスト名を決めます。ポリシーはセッション開始時に確定し、そのセッションが終了するまで有効です。

一方、新たに加わったLive Viewの読み取り専用設定は、別の役割を担います。生成された1つの閲覧リンクを使う1人の利用者が、何をできるかを決める機能です。読み取り専用の閲覧者はセッションを見られますが、画面遷移、文字入力、クリック、JavaScriptの実行はできません。

この違いは重要です。ブラウザを操作するのは引き続き自動化処理で、レビュー担当者は見るだけです。同時に、どのLive View接続が開いていても、ブラウザのHTTPおよびHTTPSリクエストはセッションの許可リスト内に収まります。

ブラウザ自動化をクライアントレビューの工程に変える

たとえば、制作会社がクライアントのWebアプリ内でレポートを生成するとします。ブラウザにはクライアントのメインホスト名のほか、認証用ホスト、API、フォント配信元、場合によっては画像CDNへの接続が必要です。クライアントは、成果物を承認する前に実行の様子も確認したいと考えています。

この2つを、別々の判断として扱えるようになりました。

1. 技術責任者が、セッションに必要な送信先を承認します。
2. クライアントには閲覧専用のLive View URLを渡し、処理の実行を見てもらいます。

レビュー担当者に操作可能なブラウザを渡す必要はなく、ジョブ側に無制限の送信先リストを与える必要もありません。1本の共有ブラウザリンクを、デモ用ツールとアクセス制御の判断に兼用するより、役割が明確な引き渡し方です。

ただし、これだけで完全なセキュリティシステムになるわけではありません。Cloudflareが説明しているのはHTTPおよびHTTPSリクエストに対するホスト名制御なので、汎用ネットワークサンドボックスと呼ぶべきではありません。また、Live View URLには署名済みJWTが含まれるため、URL全体が認証情報です。読み取り専用にすれば操作は防げますが、ページ上に表示される内容は閲覧者に見えます。

本当に手間がかかるのはアセット一覧の維持

一見して分かるホスト名だけで、ページ全体が完結することはほとんどありません。

本番ページはログイン中にリダイレクトし、別のAPIを呼び、あるホストからスクリプトを、別のホストから画像を、さらに別のホストからフォントを読み込むことがあります。Cloudflareは、こうした依存先をすべて含めるよう案内しています。1つでも漏れると、そのリクエストには403が返り、レスポンスヘッダーにはcf-mitigated: guardrailsとcf-brapi-guardrails-reason: not-in-allowlistが付きます。

つまり、許可リストの維持は実際の提供コストになります。クライアントサイトのリニューアル、IDプロバイダーの切り替え、分析ツールの変更、CDNの移行は、どれもポリシー更新と再検証につながり得ます。この作業に一律で当てはまる工数はありません。自社のジョブで実測する必要があります。

Cloudflareでは、リストを2通りの方法で指定できます。

• allowedDomainsは直接指定する方法で、セッション起動時の呼び出しに最大50件のホスト名パターンを設定できます。
• allowedDomainSetsには、最大4つの共有リストを指定できます。Cloudflareのcommon-cdnsセット、またはプレーンテキストのホスト名リストを返すHTTPS URLを利用できます。

複数のクライアントジョブで同じ承認済みサービスを使う場合、共有リストが役立ちます。ただし、反映タイミングには注意が必要です。Cloudflareはホストされたリストを最長1時間キャッシュし、更新後のリストが読み込まれてから開始したセッションにだけ変更が反映されます。実行中のセッションのポリシーが途中で変わることはありません。

common-cdnsには別のトレードオフもあります。Cloudflareが管理しており、内容は時間とともに変わる可能性があります。リスト管理の負担は減りますが、固定の許可リストではありません。契約や監査で送信先の固定が求められるなら、ホスト名を明示するか、自社でホストするリストを使います。

今すぐ活用できる4つのチーム像

制作会社の技術責任者：承認と操作を切り分ける

クライアントのアプリと必要な依存先だけを許可してブラウザジョブを実行し、アカウント責任者やクライアントのレビュー担当者には読み取り専用のLive Viewリンクを発行します。担当者はアプリをクリックして操作したり、実行内容を変えたりせずに、証跡が作られていく様子を確認できます。レビュー工程がいつの間にかオペレーター権限の引き渡しになる事態を避けられます。

SaaS創業者：自己完結型PDFを本当に自己完結させる

信頼できるインラインHTMLからスクリーンショットやPDFを生成しているなら、空のallowedDomains配列を指定し、ドメインセットなしでセッションを起動します。HTMLは表示されますが、HTTPまたはHTTPS経由で外部API、スクリプト、画像、フォントを取得できません。「このレンダリングは外部のWebコンテンツをリクエストしていない」という、検証しやすい説明が可能になります。

この制御は、スクリーンショットやPDFでよく使われるショートカットエンドポイントを含め、Quick Actionsでは利用できません。使用するには、Puppeteer、Playwright、またはCDP経由のBrowser Sessionが必要です。

プラットフォームチーム：依存先ポリシーを一元管理する

HTTPS上にプレーンテキストのリストを置き、1行につき1つのホスト名パターンを記載して、そのURLをallowedDomainSetsから参照します。複数のセッションランチャーで同じリストを共有できます。管理箇所を1つに集約できますが、無効な行が1つでもあると、ホストされたリスト全体が拒否される点が重要です。

セキュリティレビュー担当者：失敗するテストを求める

設定を見せるだけで終わらせてはいけません。許可されていないホスト名へ実際に1回リクエストし、403ステータスと2つのガードレールヘッダーをレビュー記録に保存します。見た目が正しそうな設定オブジェクトのスクリーンショットではなく、拒否経路が機能した証拠を残せます。

制限付きレビューセッションを構成する

この機能はセッション作成時に設定するため、ここからは具体的な技術手順を見ていきます。以下のコードは、本稿で参照したCloudflareのページに掲載されているものです。

1. 1

   対応クライアントをインストールし、ブラウザをバインドする

   ガードレールを使うには、@cloudflare/puppeteer 1.4.0以降が必要です。Cloudflareが案内するPuppeteerのインストールコマンドは次のとおりです。

   npm i -D @cloudflare/puppeteer

   Workerにはブラウザバインディングも必要です。CloudflareのWranglerサンプルでは、MYBROWSERという名前を使っています。

   {
   	"$schema": "./node_modules/wrangler/config-schema.json",
   	"name": "browser-rendering",
   	"main": "src/index.ts",
   	"workers_dev": true,
   	"compatibility_flags": ["nodejs_compat_v2"],
   	"browser": {
   		"binding": "MYBROWSER"
   	}
   }

   インストール済みパッケージのバージョンを確認してください。以前からあるPuppeteer概要ページでは、現在のバージョンが今も1.1.0と記載されていますが、新しいガードレールのページでは1.4.0以降が要件です。この機能を使う場合は、後者の要件に従います。

2. 2

   送信先ポリシーを指定して起動する

   Cloudflareのガードレール付きPuppeteerサンプルでは、ルートドメイン、そのサブドメイン、共有のcommon-cdnsセットを許可しています。

   import puppeteer from "@cloudflare/puppeteer";
   
   export async function startGuardedSession(env) {
   	const browser = await puppeteer.launch(env.MYBROWSER, {
   		guardrails: {
   			allowedDomains: ["example.com", "*.example.com"],
   			allowedDomainSets: ["common-cdns"],
   		},
   	});
   
   	return browser;
   }

   実際の値に置き換える前に、ページが使うリダイレクト、API、スクリプト、画像、フォントをすべて洗い出してください。*.example.comにはexample.com自体が含まれないため、サンプルでは両方を指定しています。

3. 3

   未承認ホストがブロックされることを証明する

   リスト外のホスト名に1回リクエストします。期待する結果はHTTP 403で、cf-mitigated: guardrailsとcf-brapi-guardrails-reason: not-in-allowlistが返ることです。承認済みページについても、ログインからレンダリング完了までの経路全体をテストします。ネガティブテストは境界が働くことを、ポジティブテストはジョブが引き続き動くことを証明します。

4. 4

   閲覧専用のレビューリンクを生成する

   セッションIDを取得したら、CloudflareのRESTサンプルを使って、閲覧者が操作できないタブビューを作成します。

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/browser-rendering/devtools/browser/$SESSION_ID/live_view" \
   	--request POST \
   	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
   	--json '{
   		"mode": "tab",
   		"guardrails": {
   			"mode": "readonly"
   		}
   	}'

   このURLは信頼できるサーバー側コードで生成し、信頼できる経路で共有してください。接続開始までのデフォルト期限は5分です。expiresInMsには最短60,000ミリ秒、最長3,600,000ミリ秒（1時間）を設定できます。

ここではguardrailsという同じ単語が繰り返されるため、混同しやすい点に注意してください。セッション起動時はallowedDomainsを保持し、送信先を制御します。Live View URLのリクエスト時はmode: readonlyを保持し、その閲覧者の操作を制御します。両方の境界が必要なら、両方を設定する必要があります。

導入経路によって料金体系が変わる

Cloudflareの現在のBrowser Run料金には、許可リストの項目ごとの個別料金はありません。費用が変わるのは、連携方法を変更した場合です。

Quick Actionsはブラウザ利用時間だけが課金対象ですが、ガードレールを利用できません。Browser Sessionsではガードレールを使える一方、ブラウザ利用時間と同時実行ブラウザ数の両方が課金対象です。ショートカットを使うPDFやスクリーンショットのワークフローにホスト名制限が必要になり、Puppeteer、Playwright、またはCDPへ移行すると、実装だけでなくコストモデルも変わります。

Workers Paidには、月10時間分のブラウザ利用と同時実行ブラウザ10台分が含まれます。追加のブラウザ時間は1時間あたり$0.09です。同時実行枠の追加は1台あたり$2.00で、各日のピーク値を月平均した台数に基づきます。

計画に使える式は次のとおりです。

extra usage cost = max(0, browser hours - 10) × $0.09 + max(0, average daily peak browsers - 10) × $2.00

Cloudflare自身の例では、ブラウザ利用時間が50時間、平均同時実行数が15台です。超過した40時間で$3.60、追加の5台で$10.00となり、追加使用料の合計は$13.60です。これはガードレールの利用料ではありません。ガードレールに対応するBrowser Session経路で発生する料金です。

Workers Freeには、1日10分のブラウザ利用と同時実行ブラウザ3台分が含まれます。小規模な検証には使えますが、何度もレビューを行うクライアント向けワークフローには余裕がありません。

すでにBrowser Sessionsを使っているなら、課金区分は変わりません。新たに増えるのは主に運用コストです。アセットホストの収集、許可・拒否経路のテスト、リストの更新作業が必要になります。マネージドブラウザの選択肢を比較中なら、AIエージェント向けブラウザの総合ガイドで、こうした利用料の位置付けを確認できます。

それでも破綻しやすいポイント

最も起こりやすいのは、開発環境では動いていたページが、許可リストの有効化後にフォント、画像、ログイン時のリダイレクト、API呼び出しのいずれかを失うケースです。広すぎるワイルドカードを使えば不具合は消えるかもしれませんが、本来設けたかった境界も弱くなります。

Cloudflareで使用できるワイルドカードは、ホスト名パターンごとに1つです。サブドメインには*.example.comを使い、ルートドメインは別に指定するのが適切です。*example.comのように先頭へワイルドカードを置くパターンは、evilexample.comのような似せたドメインにも一致するため、厳密なクライアントポリシーには向きません。

読み取り専用Live Viewにも限界があります。保護されるのは1つの閲覧者接続であり、オペレーターからセッションを保護する機能でも、同じセッションへの別の接続による操作を防ぐ機能でもありません。必要なコマンドがブロックされるため、PuppeteerとPlaywrightは読み取り専用接続を操作できません。レビュー担当者には適していても、自動化用の認証情報には使えないという、意図どおりの設計です。

Quick ActionsとKitesurfは、引き続きガードレール機能の対象外です。どちらかを使っているチームには、ホスト名の境界のために連携経路を変えると決めるまで影響はありません。

月曜日に着手すること

まず、送信先が安定している実際のクライアントジョブを1つ選びます。最も複雑なログインフローから始める必要はありません。

成功する経路で使われるすべてのホスト名を、リダイレクト先やアセットホストも含めて洗い出します。ガードレール付きBrowser Sessionを起動して目的の出力を確認し、次に未承認のホスト名へ意図的にリクエストして403の証跡を保存します。最後に、チームメンバーへ読み取り専用のLive Viewリンクを渡し、閲覧はできても操作はできないことを確かめます。

この試行から、必要なホスト名の数、維持にかかった時間、当初誤ってブロックした正当なリクエスト数、同時実行ブラウザ数の日次ピークの平均という4項目を記録します。この4つの値を見れば、そのワークフローにとって、明快な制御になるのか、コストの高い約束になるのかを判断できます。

クライアント向けにブラウザジョブを提供していて、必要なホストを特定でき、操作権を渡さない閲覧が実際の承認課題を解決するなら、今週中に動く価値があります。依存先が頻繁に変わる場合や、ジョブがまだQuick Actions上にありBrowser Sessionへの移行費用を試算していない場合は、待つべきです。Browser Sessionsを実行せず、ライブのブラウザ作業も共有しないのであれば、このリリースによって月曜日の予定を変える必要はありません。

プラットフォーム変更を運用者の視点で解説する記事をもっと読みたい方は、ニュースレターにご登録ください。