Cloudflareは「Worker Previews」を発表した。この機能により、各GitブランチはWorkerごとに独立した本番同等の環境を持てるようになる。各環境には安定した専用URLが割り当てられ、ブランチごとに固有のデータ状態を保持できるほか、スコープを限定したオブザーバビリティも提供される。プレビュー環境は npx wrangler previewで作成でき、単一のWorker配下で数百のプレビューを同時実行できる。本番トラフィックや他のプレビュー環境に影響を与えることはない。
その背景にあるのが、エージェント駆動開発だ。コーディングエージェントは、より大規模な変更を高頻度で生成するため、テストもボトルネックにならない形でそのペースに追従する必要がある。CloudflareはWorker Previewsを、同社のAgent Development Lifecycleにおけるフィードバックループと位置付けている。このプロセスでは、各変更がアトミックであり、個別にデプロイ可能で、オブザーバビリティを備え、必要に応じて修正できることが求められる。
主な技術的課題はステート管理にある。Durable Objectsは、特定のオブジェクトIDに対して単一のインスタンスがストレージを所有するシングルトンモデルを採用しているため、プレビュー環境が本番環境と同じネームスペースを共有すると、本番稼働中のインスタンスを書き換えてしまう可能性がある。そのためWranglerは、各プレビューごとに新しいDurable ObjectネームスペースとContainerアプリを作成する。これにより、失敗したマイグレーションやスキーマ変更の影響をそのブランチ内に限定できる。開発者はクラスをエクスポートし、マイグレーションを追加したうえで ctx.exports 経由でアクセスする。本番環境では本番用ネームスペースに解決され、プレビュー環境ではそのプレビュー専用のネームスペースに解決される。
/filters:no_upscale()/news/2026/09/cloudflare-worker-agent/en/resources/2download-1790586657119.jpg)
設定は、 mainブランチを起点とするブランチのように機能する。チームはWrangler設定ファイルの previews ブロックで基本設定を定義し、そこには変数、シークレット、バインディングなどが含まれる。例えば、R2バケットの接続先を本番ストレージではなくステージング用ストレージに設定できる。各プレビュー環境はこの基本設定を引き継いで開始され、そのうえで特定のデータベースやマイグレーション用のテストAPIキーなど、個別の設定だけを変更できる。こうした変更は本番環境や基本設定、ほかのプレビュー環境には影響しない。Workers Buildsに接続されたWorkerでは、コードをプッシュするたびにプレビュー環境が自動作成され、同じブランチへの追加のプッシュは実行中の同一プレビュー環境を更新する。
Workers Observabilityはプレビューごとにスコープが分離されているため、ログ、エラー、メトリクス、リクエストトレースを、本番トラフィックを除外するためのフィルタリングなしで確認できる。Cloudflareはさらに、Browser Run、Playwright MCP、Workers Observability MCPサーバーを組み合わせたエージェントループも紹介している。この仕組みでは、エージェントがヘッドレスブラウザーでプレビュー環境を開き、ログインなどの操作フローを実際にクリック操作でたどる。その後、スクリーンショットや再生可能なセッションを取得し、失敗したリクエストをトレースイベントと照合する。最後に修正を適用し、再デプロイして結果を検証する。プレビュー環境は、 feature-login.previews.example.com のようなカスタムドメインで公開できるため、Cookie、CORS、OAuthリダイレクトを本番環境と同様に動作させられる。また、Cloudflare Accessによるアクセス制御も適用できる。
Cloudflareによると、同社はGitHubやSlackなどのサービスとエージェントをGatekeepers経由で接続するオープンソースプラットフォーム「CloudflareOS」の開発において、Worker Previewsを社内利用したという。レビュー中のすべての変更ごとに完全なプレビュー環境をデプロイすることで、変更内容を独立して検証できるようにしている。また、SupermemoryとRampが初期ユーザーとして紹介されているが、このブログ記事ではベンチマークや定量的な成果は示されていない。
Worker Previewsは、環境ごとに個別のWorkerをデプロイして管理する必要があるWranglerの環境機能とは異なる。また、既存のWorkerプレビューURLとも異なり、こちらは現在「Version URLs」に名称変更されている。Version URLsはアップロード済みのWorkerバージョンを指すもので、ブランチごとに分離されておらず、アクセスできるのも本番リソースに限られる。一方、Worker Previewsはブランチごとに独立した環境を提供する。Worker Previewsはプライベートベータ期間を経て、現在利用可能となっている。
エンジニアは、現時点でのいくつかの制限事項にも注意する必要がある。サービスバインディングをプレビュー環境から利用した場合でも、呼び出し先のWorkerは本番デプロイ版となるため、複数のWorkerで構成されるアプリケーションはまだ完全には分離されていない。また、プレビュー環境からQueuesへメッセージを送信することはできるが、Queuesのメッセージを消費することはできない。Workflow実行の分離についても、別途設定が必要となる。さらに、ステージング環境やQA環境向けの長期間維持されるプレビュー環境については、まだエンドツーエンドではサポートされていない。ただしCloudflareによると、ベータテスト参加チームから要望が寄せられており、ロードマップに含まれているという。加えて、Version URLsを利用する既存の仕組みがある場合は見直しが必要になる。Version URLsは引き続き本番環境のバインディングを参照するためだ。