Cloudflare Worker Previews 公開。「エージェントが作る変更ごとに隔離環境を出す」を前提にした設計

要約

Cloudflare は 2026-09-22、Worker Previews を公開しました。変更ごとに本番同等の隔離環境を立てて検証するための仕組みです。

注目すべきは機能そのものより、公式が付けた副題です。 「Introducing Worker Previews: isolated preview environments for every change your agent makes」——「エージェントが行うすべての変更に」と明示しています。人間が1日に数本のプルリクエストを出す前提ではなく、エージェントが大量の変更を投げてくる前提で設計された、と読めます。

各 Preview は同一の Worker の下で、独自のコード・設定・URL・可観測性を持ちます。 本番からも、他のすべての Preview からも隔離されます。数百の Preview を同時に走らせられると公式は書いています。

プレビュー環境自体は新しい概念ではありません。この発表の中身は「状態を持つプレビュー環境を、自動で、大量に作れるようにした」という点にあります。

何が変わったか

最も実装上の意味が大きいのは、状態の扱いです。

Durable Objects と Containers について、Cloudflare が Preview ごとに名前空間・ストレージ・アプリ・インスタンスを自動で切り出します。 状態変更、セッション、メモリ、マイグレーション、並行テストが、その Preview の中に閉じます。

これが自動でないとどうなるかを考えると、機能の価値が分かります。 状態を持つアプリケーションのプレビュー環境を手で作る場合、データベースの複製、マイグレーションの適用、テストデータの投入、そして使い終わった後の破棄——ここまでを自前で組む必要があります。プレビュー環境が普及しない最大の理由がこの作業量でした。Durable Objects と Containers については、それが消えます。

ただし全部ではありません。 KV、D1、R2 のようなアカウント単位のリソースを隔離したい場合は、別リソースを明示的にバインドする必要があります。 「Preview を作れば全部隔離される」と読むと事故ります。自動で分かれるのは Durable Objects と Containers だけで、それ以外は設計の仕事として残ります。

設定は Wrangler 設定ファイルの previews ブロックで定義します。 新しい Preview が開始時に持つ変数・バインディング・設定をここに書き、シークレットは Wrangler コマンドで設定します。1つの Preview だけを上書きしても、本番と他の Preview には影響しません。

デプロイは Wrangler 4.135.0 以降で以下のコマンドです。

npx wrangler preview

リポジトリを Workers Builds へ接続すれば、Preview を自動生成してプルリクエストへ URL を投稿します。

URL が2種類付くのは、レビュー運用をよく分かった設計です。

• 安定URL: push のたびに中身が更新される。レビュアーは常に最新を見る
• 不変URL: デプロイ単位で固定される。版を比較したり、特定の版へ戻って確認したりできる

レビュー中に相手が push してきて、見ていたものが変わる——という事故を、2種類のURLで分けています。

配信ドメインも選べます。 workers.dev でも、カスタムドメインでも、両方でも配信できます。カスタムドメインを使う理由は明確で、認証プロバイダ・Cookie・CORS・OAuth リダイレクトが本番と同じ挙動になるからです。 プレビュー環境で認証周りが検証できない、というのはよくある詰まりどころで、そこを潰しにきています。Preview URL は Cloudflare Access で保護できます。

可観測性も Preview 単位に分かれます。 リクエストのライフサイクル全体——fetch 呼び出し、バインディング操作、ハンドラ実行——がウォーターフォールで追えます。本番トラフィックや他の変更の信号と混ざりません。 公式ブログはこれを「エージェントと人間の双方に、自己改善のための証拠を与える」と説明しています。何が失敗したかを掴み、修正を push し、本番へ出す前に次のデプロイで検証する、というループです。

業務インパクト

この機能が効くかどうかは、「検証環境の数が足りているか」で決まります。

チームで staging が1つしかなく、順番待ちが発生している。あるいは、プルリクエストのレビューで「ローカルで動かしてみて」と言っている。こういう状態なら、Worker Previews は効きます。

逆に、Workers を使っていない、あるいは状態を持たない単純な Worker しか動かしていないなら、急いで導入する理由はありません。 静的な処理のプレビューなら既存の仕組みでも足ります。この機能の価値は Durable Objects / Containers の自動分離に集中しています。

AI エージェントに開発をさせているチームにとっては、優先度が上がります。 エージェントは人間より多くの変更を出します。その全部を1つの staging で順番に検証するなら、検証が律速になってエージェントの速度が意味を失います。 公式が「Agent Development Lifecycle（ADLC）」という言葉で説明しているのはこの点で、各変更が「アトミックで、独立にデプロイでき、観測でき、修正できる」状態を作る、という組み立てです。

導入の順番としては、まず Wrangler の更新（4.135.0 以降）と previews ブロックの定義です。 そのうえで、KV / D1 / R2 を使っているなら、Preview 用に別リソースを用意するかどうかを決める必要があります。ここを決めずに走ると、Preview から本番の D1 を叩く構成ができてしまいます。「自動で隔離されるもの」と「自分で隔離するもの」の境界を、導入時に文書化してください。

コスト面は公式 changelog に明示がありません。 数百の Preview を同時に走らせられる、という説明はありますが、それが課金にどう効くかは現行の制限とあわせて Worker Previews のドキュメントで確認する必要があります。「作り放題」と読まないでください。

同日に、Workers Builds が Cursor Origin のリポジトリへ対応したという告知も出ています。単体では小さな変更ですが、Worker Previews と並べると、Cloudflare が「変更ごとに隔離環境を出す」という形へ製品全体を寄せているのが見えます。

副業・個人活用視点

個人開発で最も効くのは、「人に見せる」手前の作業が消えることです。

作ったものを誰かに触ってもらうには、どこかへ置いて URL を渡す必要があります。この作業——サーバーの用意、ドメインの設定、環境変数の設定、データの用意——が、個人プロジェクトが止まる典型的な地点です。npx wrangler preview で URL が出るなら、その壁は実質なくなります。

受託案件では、レビュー体験そのものが商品になります。 「修正しました、確認してください」と言うときに、この変更だけが反映された URL を渡せるのは、口頭で説明するより圧倒的に速い。しかも不変URLがあるので、「前の版と比べてどうですか」という見せ方もできます。クライアントとのやりとりの往復回数が減るのは、時間単価で働く人にとって直接利益です。

Access で保護できる点も、受託では実用的です。 未完成のものを URL で渡すとき、誰でも見られる状態にはしたくない。認証を自前で組む必要がないのは手数の節約になります。

学習・発信の題材としては、「状態の隔離」という論点が扱いやすいです。 プレビュー環境を作ったことがある人なら、コードを分けるのは簡単で、状態を分けるのが難しいという実感を持っています。Cloudflare が自動化したのが Durable Objects と Containers だけで、KV / D1 / R2 は手動という線引きは、「どこまでをプラットフォームが吸収し、どこからが設計者の仕事か」を具体的に示す教材になります。

「エージェントが作る変更ごとに」という副題そのものも、発信の切り口として価値があります。 製品の設計思想が「人間が使う前提」から「エージェントが使う前提」へ移っている、という変化を、公式の言葉で示せる事例はまだ多くありません。

参考

• Introducing Worker Previews: isolated preview environments for every change your agent makes（Cloudflare 公式ブログ）
• Test every pull request in an isolated environment with Worker Previews（Cloudflare changelog）