Worker Previews で PR ごとの検証環境を作るとき、何が自動で本番から分かれ、何を自分でバインドし直す必要があるか。Wrangler 4.135.0 以降の作り方と、URL・ログの使い分けを整理する。
4.135.0 Preview を作れる Wrangler の最低バージョン Cloudflare Changelog（2026年9月22日）に『Use Wrangler 4.135.0 or later to deploy a Preview』とある
Cloudflare Workers で、PR ごとに本番から切り離した検証環境を立てられるようになった。Cloudflare の changelog が2026年9月22日付で載せた Worker Previews で、Wrangler 4.135.0 以降の npx wrangler preview か、Workers Builds とのリポジトリ連携で作る。ただし、ストレージの分離が自動で済むのは Durable Objects と Containers だけだ。KV、D1、R2 のようなアカウント単位のリソースは、Preview に別のリソースをバインドしてはじめて分離される。
各 Preview は同じ Worker の下で動き、コード、設定、URL、observability をそれぞれ持つ。changelog は、本番からも他の Preview からも隔離されていると説明している。PR ごとに別名の Worker をデプロイする運用とは形が違う。ダッシュボードでは、Worker 名の横にある environment breadcrumb で Production と各 Preview を切り替える。
手元から作るなら次のコマンドになる。
npx wrangler previewCI に組み込むなら、リポジトリを Workers Builds に接続する。Preview が自動で作られ、その URL が PR に投稿される。GitHub Actions など自前の CI から wrangler preview を呼ぶ構成については、changelog は触れていない。
新しい Preview が最初に持つ変数、バインディング、設定は、Wrangler 設定ファイルの previews ブロックで定義する。secret だけは設定ファイルに書かず、Wrangler コマンドで設定する。特定の Preview だけを上書きすることもでき、そのとき本番や他の Preview の設定は変わらない。
previews ブロックの中身をどう書くかは、changelog の本文に例がない。キー名を推測で書き始めるより、公式ドキュメントで書式を確かめてからにしたい。
| リソース | Preview ごとの扱い |
|---|---|
| Durable Objects、Containers | namespace、ストレージ、app、インスタンスを Preview ごとに Cloudflare が自動で用意する |
| KV、D1、R2 などアカウント単位のリソース | 分離するには、Preview に別のリソースをバインドする |
出典：Cloudflare Changelog「Test every pull request in an isolated environment with Worker Previews」（2026年9月22日）
Durable Objects と Containers では、状態の変更、セッション、メモリ、マイグレーション、並行して走るテストが、その Preview の中に閉じる。PR で Durable Objects のマイグレーションを試しても、本番の namespace には及ばない。
注意が要るのは下の行だ。changelog が書いているのは「分離したければ別リソースをバインドする」ことだけで、別リソースを指定しなかった Preview がどのリソースを指すかは明記していない。previews ブロックに本番と同じ KV namespace や D1 データベースを書いていれば、Preview からの書き込みは本番データに届くと考えるのが自然だ。ただしこれは推測で、設定を省いたときの継承の挙動は確認できていない。D1 のスキーマ変更を PR で試すなら、検証用のデータベースを先に作り、Preview 側のバインドをそちらに向けておくのが安全だ。
Preview には 2 種類の URL が付く。
URL は workers.dev、カスタムドメイン、またはその両方で配信できる。カスタムドメインにすると、認証プロバイダ、cookie、CORS、OAuth のリダイレクトが本番と同じ条件で動く。workers.dev のままでは OAuth のコールバックや cookie の domain 属性が本番と食い違いやすいので、ログイン周りを触る PR ではカスタムドメインを割り当てたほうが検証の意味が出る。Preview 用のドメインは Worker の Domains タブで設定し、URL を Cloudflare Access で保護することもできる。
各 Preview は自分のログ、エラー、メトリクス、トレースを持つ。Preview の URL にトラフィックを送り、何が起きたかを見て、修正を push し、次のデプロイを確かめる。この往復を本番に触れずに回せる。本番側では段階デプロイの注釈が Metrics チャートに出るようになったが（Workers の Metrics チャートの注釈）、Preview の観測データはそれとは別に Preview 単位で見られる。
導入するなら、次の順で確かめていくとよい。
npx wrangler preview で Preview を一つ作る。previews ブロックで、KV、D1、R2 のバインドを検証用リソースに向ける。secret は Wrangler コマンドで入れる。changelog 自身が、現時点での制限があるとしてドキュメントを参照するよう書いている。本番データを持つ Worker で使う前に、その制限も目を通しておきたい。