Cloudflare Browser Run に guardrails — ブラウザセッションの通信先を許可ホストだけに制限、Live View の読み取り専用モードも

要約

Cloudflare は 2026-09-14、Browser Run に guardrails を追加しました。ブラウザセッションからの HTTP / HTTPS リクエストを、許可したホスト名だけに制限する機能です。

設定は Puppeteer / Playwright / REST API のいずれからも行えます。Puppeteer の例は次の形です。

import puppeteer from "@cloudflare/puppeteer";

export async function startGuardedSession(env) {
	return puppeteer.launch(env.MYBROWSER, {
		guardrails: {
			allowedDomains: ["example.com", "*.example.com"],
		},
	});
}

allowedDomains は example.com のような完全一致と、*.example.com のようなワイルドカードの両方を受け付けます。

この機能が効く理由は、ブラウザが「何でも読み込める」実行環境だからです。

ヘッドレスブラウザを AI エージェントに持たせると、エージェントは任意のページへ行き、そのページが指定した任意のリソースを読み込みます。エージェントが意図して外部へ行く場合だけでなく、訪問先のページが外部を呼ぶ場合も通信は発生します。 つまり、通信先はエージェントの判断だけで決まっていません。

公式が挙げている用途3つは、この構造をそのまま反映しています。(1) ブラウザのワークフローを特定サイトとそのサブドメインに閉じ込める。(2) 既知のサードパーティ API・スクリプト・画像・フォントだけを読み込ませる。(3) 渡した HTML からスクリーンショットや PDF を生成する際に、外部コンテンツの取得を止める。

3番目が特に実務的です。 HTML を渡して PDF を作る処理は広く使われていますが、その HTML に外部への参照が含まれていれば、レンダリング時に通信が出ます。 生成処理のつもりが、外部通信を伴う処理になっている、という状態です。

あわせて、Live View に読み取り専用モードが入りました。URL を生成するときに { mode: "readonly" } を指定すると、閲覧者はクリック・入力・遷移・JavaScript 実行ができなくなります。 セッションに掛かっているホスト名の制限はそのまま維持されます。

何が変わったか

• Browser Run のセッションで guardrails.allowedDomains による通信先の制限ができる
• 指定は**完全一致（example.com）とワイルドカード（*.example.com）**の両方に対応
• 設定経路は Puppeteer / Playwright / REST API の3つ
• Live View に読み取り専用モード（{ mode: "readonly" }）が追加。クリック・入力・遷移・JS 実行を禁止し、ホスト名制限は維持される
• 公式 changelog にプラン別の提供条件・上限の記載はない

業務インパクト（一般企業向け）

この更新の意味は、「エージェントに何をさせないか」をコードではなく実行環境で決められるようになった点にあります。

エージェントの通信を絞る方法は、これまで主にアプリ側のロジックでした。プロンプトで指示する、ツールの呼び出しを制限する、URL を検証する。いずれもエージェントの判断や実装の正しさに依存します。 プロンプトインジェクションが成立するのは、この依存があるからです。

guardrails は依存の位置を変えます。 許可ホスト以外は実行環境が拒否するので、エージェントが騙されても、実装にバグがあっても、通信は出ません。 これは「エージェントを賢くして防ぐ」のではなく「賢さに関係なく塞ぐ」やり方です。セキュリティ設計としては後者が正しい方向です。

導入時に決めるべきことは2つです。

1. ワークフローごとに許可リストを分ける。 全ワークフローで同じ許可リストを使うと、最も広い要件に合わせた設定になり、絞る意味が薄れます。「この処理はこのドメインにしか行かない」という単位で分けるほど効きます。 PDF 生成のように外部参照が本来不要な処理は、許可リストを空に近づけられます。
2. ワイルドカードの範囲を慎重に決める。 *.example.com は便利ですが、サブドメインを第三者が取得できる構成（サブドメインテイクオーバー）では穴になります。 自社管理下のサブドメインに限定できるなら完全一致を並べるほうが安全です。

Live View の読み取り専用モードは、運用体制の話として価値があります。

エージェントの実行を人が見る場面は増えています。レビュー、デバッグ、顧客への説明、監査。これらは「見る」だけで足りますが、従来の Live View は操作もできました。 つまり、見せるために共有した URL が、操作権限も渡していた状態です。読み取り専用モードは、この過剰な権限を外せます。共有先が社外や別部門の場合、これは実務上必須の区別です。

副業・個人活用視点

個人でブラウザ自動化を使っている人には、すぐ効く機能です。

Browser Run を使ってスクレイピング、スクリーンショット生成、PDF 生成をしている場合、許可リストを設定するだけで、想定外の通信が止まります。 設定は数行なので、導入コストはほぼゼロです。

特に PDF 生成の用途は、今日から見直す価値があります。 HTML テンプレートから請求書や帳票を作っている処理は、テンプレートに CDN のフォントや外部画像が入っていることが珍しくありません。 許可リストを空に近い状態で走らせれば、外部に何も出さずに生成できているかを確認できます。 顧客データを含む帳票を作っている場合、これは説明できるかどうかの差になります。

受託の観点では、提案に組み込みやすい材料です。

「AI エージェントにブラウザ操作をさせる」という案件では、必ず「暴走しないのか」「情報が漏れないのか」を聞かれます。 ここで **「実行環境側で通信先を許可リストに限定します。エージェントが誤動作しても、リストの外へは出ません」**と答えられるのは強い。プロンプトで気をつけます、という回答とは説得力が違います。

Live View の読み取り専用モードも、顧客向けに効きます。 エージェントが何をしているかをリアルタイムで見せられると、発注側の不安は大きく下がります。ただし操作させたくはない。 この要件が設定1つで満たせるので、「動いているところをお見せします」を安全に提供できます。 デモや検収の場面で使いどころがあります。

注意点を1つ。公式 changelog にプラン別の提供条件や上限の記載がありません。 本番の要件に組み込む前に、自分のプランで使えるかを確認してください。changelog に書かれていないことを「制限がない」と読まないことです。