修正を確認してもらう段になって、毎回同じやり取りが起きます。「どのURLを見ればいいですか」「さっき送ったのと同じURLです、再読み込みしてください」。確認環境が1つしかないと、2つの修正を並行して見てもらえず、順番待ちが発生します。
制作の進行表に、この待ち時間は乗りません。乗らないまま、確認の往復だけが増えていきます。
ブランチの数だけ確認環境が立つ
Cloudflareが2026年9月22日に、Worker Previewsの提供を開始しました。Gitのブランチごとに、本番に近い構成のWorker環境を独立して用意する仕組みです。
それぞれのプレビューには、ブランチ名に基づいたURLが割り当てられます。このURLはプッシュしても変わらず、常にそのブランチの最新版を指します。リポジトリをWorkers Buildsに接続してプレビューのビルドを有効にしておけば、プッシュのたびにプレビューが更新され、プルリクエストにはコメントとしてURLが投稿されます。確認を頼む側がURLを貼り直す作業がなくなります。
ログ・エラー・メトリクス・トレースもプレビューごとに見られます。独自ドメインを割り当てれば、認証やリダイレクトのように本番のドメイン構成に依存する動きも確認できます。ログイン後の画面を確認してもらう案件では、ここが効きます。
自動で分かれるものと、分かれないもの
便利さの裏で、いちばん注意が要るのはここです。
プレビューごとに自動で分離されるのは、同じWorkerで定義したDurable Objectsの名前空間とコンテナのアプリケーションです。一方、KV・D1・R2・キュー・ワークフローといったアカウント単位の資源は、同じIDや名前を指定している限り本番と共有されます。
プレビューの設定は本番の設定を引き継がず、構成ファイルのpreviewsブロックに書いたものから始まります。何も書かなければ資源はプレビューに結びつかず、Wranglerが足りないバインディングを警告します。ここで本番と同じIDを書き写すと、プレビュー環境で試した削除や更新は本番のデータに対して実行されます。管理画面には本番の設定をプレビュー用に取り込む機能もあり、取り込んだ値をそのまま使った場合も同じです。「確認用の環境だから壊してもいい」という前提で操作を頼んだ結果、本番のレコードが消える、という事故の形が想像できます。
別のWorkerを呼ぶサービスバインディングは、現時点ではプレビューからでも呼び先の本番のデプロイにつながります。
分けたい資源は、プレビュー用に別の資源を用意して明示的に結びつけます。previewsブロックを分岐元のブランチに書いておけば各ブランチに引き継がれ、ブランチごとに上書きできます。本番の設定を触らずにプレビューだけを変えられる形です。
確認を頼む側と受ける側で決めておくこと
確認環境を配れるようになると、進め方そのものが変わります。先に決めておく項目を挙げます。
- そのプレビューが見ているデータは本番か、確認用か。URLを渡すときに明記する
- 確認用データの場合、どこまで自由に操作してよいか。注文の確定や決済の実行を含むか
- プレビューのURLを誰まで共有してよいか。クライアント社内の別部署や、その先の取引先まで渡るか
3つ目は見落としやすい点です。プレビューのURLは既定で誰でも開ける状態で、サインインを求めるにはCloudflare Accessで保護します。ブランチ名から推測できるURLは、意図せず外から到達されることがあります。確認用の環境がどう見つかるかについては証明書ログからのドメイン発見とステージング環境の防御に整理しました。認証をかける、公開期間を区切る、といった前提は確認環境でも必要です。
増やす前に、確認の中身を決める
環境が簡単に立つようになると、「とりあえず見てください」と投げる回数が増えます。これは往復を減らしません。
確認してもらう相手に、何をどの順で見てほしいのかを渡せているか。プレビューのURLと一緒に、今回変わった箇所と確認してほしい操作を添えているか。この組み立て方はPRの確認成果物をどう共有するかで扱っています。環境が増えても、確認の質は添える情報で決まります。
導入前に確認すること
すでにCloudflare Workersで動いているサイトなら、まず現在の構成でどの資源を使っているかを書き出してください。KV・D1・R2を使っていれば、プレビュー用の資源を別に用意するかどうかの判断が最初の作業になります。使っていなければ、自動で分離される範囲だけで済む可能性があります。別のWorkerをサービスバインディングで呼んでいる場合は、その呼び先が本番であることも確認の対象です。
これまで確認用に渡してきたURLも見直してください。以前からWorkers Buildsに接続しているWorkerは、一度だけの切り替えをするまで従来のプレビューの方式のままです。従来の方式は本番の設定と資源を使うため、これまでのURLが本番のデータにつながっていた可能性があります。切り替えは元に戻せません。
この切り分けを飛ばして環境だけ増やすと、便利になった分だけ事故の面が広がります。
2026年9月25日に、Cloudflareのブログと変更履歴（いずれも2026年9月22日付）、Workersのドキュメント（Previewsの概要・設定・資源の分離・独自ドメイン、Workers Buildsのブランチ設定）を確認しました。プレビュー環境の作成、資源の結びつけ、プルリクエストへのURL投稿は実際には試していません。料金とプランごとの上限は本文で扱っていないため、導入前に公式ドキュメントで現在の仕様と料金を確認してください。本記事は分離範囲と運用ルールの整理です。
確認環境の作り方や、修正の確認フローの組み直しは、グリームハブへご相談ください。
