Cloudflare Temporary Accountsで未ログインのままWorkerを出せる

Cloudflare Workersを、アカウント未作成・未ログインのまま一時デプロイできるようになった。
Temporary Cloudflare Accounts for AI agents で発表された機能で、Wrangler 4.102.0以降なら wrangler deploy --temporary だけで workers.dev URLへWorkerを出せる。

公開されたWorkerは60分だけ残る。
その間にclaim URLを開いてCloudflareへログインまたはサインアップすると、Temporary Preview Accountごと自分のアカウントとして引き取れる。
claimしなければ、アカウントとデプロイは自動削除される。

CloudflareはこれをAIエージェント向けとして出している。
ただ、動きだけ見ると「Cloudflareアカウントを作る前に、Workerを60分だけ本物のURLで試す」機能でもある。
Simon Willison氏も、AI向けという名目に限らず一時Workerとして面白いと書き、Codex Desktopから作ったHTTPリダイレクト確認ツールを実際に一時デプロイしている。

止まっていたのはコードではなくログインだった

Cloudflareの説明では、従来の詰まりはWorkerのビルドやデプロイコマンドではなく、OAuth、ダッシュボード操作、APIトークン作成、MFAだった。
人間が横にいるCopilotなら「このURLを開いてログインして」で済む。
バックグラウンドで走るエージェントだと、その時点で作業が止まる。

新しい流れでは、エージェントが通常どおり wrangler deploy を叩く。
Cloudflareの認証情報が見つからない場合、Wranglerが --temporary で再実行できると出力する。
エージェントはその出力を読んで、同じデプロイを wrangler deploy --temporary でやり直す。
この経路を試すときは wrangler logout で先にログアウトしておく。認証情報が残っていると --temporary 自体がエラーになる。

全体の流れはこうなる。

flowchart TD
    A[wrangler deploy] --> B{認証情報あり?}
    B -->|あり| C[通常デプロイ]
    B -->|なし| D[--temporary を案内]
    D --> E[wrangler deploy --temporary]
    E --> F[proof-of-work check]
    F --> G[一時preview account作成]
    G --> H[workers.dev URLへ公開]
    H --> I[claim URLを出力]
    I --> J{60分以内にclaim?}
    J -->|claimする| K[自分のアカウントへ引き取り]
    J -->|claimしない| L[60分で自動削除]

プロンプトで最初から --temporary を渡さなくても、CLIのエラー出力自体がエージェントに次の手を示す。
Cloudflareが4月の Agents Weekで統合CLIやLocal Explorer を出したときも、AIエージェントが存在しないコマンドを呼ばないようにCLIとドキュメントを揃える話があった。
今回のTemporary Accountsは、その発想を初回デプロイの認証フローに当てたものだ。

60分の間は同じ一時アカウントへ再デプロイできる

Cloudflare Workersのドキュメントでは、Wrangler 4.102.0以降が必要だと明記されている。
CLIが一時preview accountを作成し、Workerを workers.dev URLに公開し、claim URLを出力する。

一度作った一時アカウントはWrangler側にキャッシュされる。
60分以内なら、同じ一時アカウントへ wrangler deploy --temporary を繰り返せる。
エージェントがコードを書き、公開URLへ curl し、失敗したら直して再デプロイする、という短いループが回る。

claim後は通常のCloudflareアカウントとして扱う。
その後も同じWorkerを触るなら wrangler login して、--temporary なしでデプロイする流れになる。
逆に、WranglerがすでにOAuth、CLOUDFLARE_API_TOKEN、global API keyを使える状態では --temporary はエラーになる。
--temporary が通るのは未認証の初回デプロイだけだ。既存アカウントのプレビュー環境を増やす用途には使えない。

対応リソースはWorker本体だけではない

Temporary Preview Accountで使えるリソースは限定されているが、Worker単体よりは広い。
ドキュメント上では、Workers、Workers Static Assets、KV、D1、Durable Objects、Hyperdrive、Queues、SSL/TLS certificatesが挙がっている。

制限も具体的だ。リソースごとの上限はドキュメントに数値で書かれている。

リソース	Temporary Preview Accountの制限
Workers Static Assets	最大1,000ファイル、各ファイル5MiBまで
D1	1データベース、データベースあたり100MB、合計100MB
Hyperdrive	最大2つのデータベース設定、10接続
Queues	最大10個
KV / Durable Objects / SSL/TLS	利用可（個別の数値上限はドキュメントに明記なし）

この範囲なら、ただのHello Worldだけでなく、軽いAPI、静的アセット付きの小さなWebアプリ、D1を触るプロトタイプまでは試せる。
一方で、独自ドメイン、本番CI/CD、長時間残す検証環境、既存Cloudflareリソースとの接続は、Permanent Accountへ移ることになる。

Cloudflare Artifacts や Cloudflare Email Service のように、4月の発表群は「エージェントがCloudflare上で状態やチャネルを持つ」方向だった。
Temporary Accountsが削ったのは、最初のWorkerを出す前に止まっていた認証の段差だ。新しい実行基盤を足したわけではない。

プレビューURLの扱いが変わる

ローカルの開発サーバーを外へ見せるだけなら、トンネルやプレビュー共有でも足りる。
Temporary Accountsで変わるのは、実際のWorkers環境に乗ったURLをエージェントが自分で検証できるところだ。

WorkersはV8 isolate上で動く。
Node.jsの fs や child_process に頼るコードはそのままでは動かないし、Cloudflare固有のバインディングもローカルと本番で差が出る。
以前 VoidZeroのCloudflare基盤デプロイでも、V8 isolateの制約とCloudflare Pagesへの移行条件を書いた。
今回の一時デプロイなら、その制約に本物のCloudflare側で早く突き当たる。

人間がレビューする前に、エージェントが公開URLを叩いてレスポンスを確認する。
それで十分な小物なら、claimせず60分で捨てる。
残す価値が出たらclaimする。

ただし、これを本番代わりに使うと扱いが変わる。
CloudflareのChangelogにも、本番やCI/CDでは通常のCloudflareアカウント、wrangler login、APIトークンを使うと書かれている。
Temporary Accountsは、永続的な権限管理や監査ログを作る場所ではない。

課金事故よりも作成乱用の制御が先に来る

未ログインでWorkerを公開できるとなると、乱用対策が気になる。
Cloudflareのドキュメントでは、一時アカウント作成前にproof-of-work checkを行い、CLIが自動処理すると書いている。
短い遅延が入ることはあるが、追加入力は求められない。

proof-of-work（PoW、作業証明）は、リクエスト元に「ある程度の計算量を必ず消費させる」仕組みだ。
CLIがチャレンジ（問題）を受け取り、条件を満たすハッシュ値を総当たりで探して答えを返す。CAPTCHAのように人間の操作を要求するのではなく、CPU時間という形でコストを払わせる。
1回あたりの遅延は数秒程度なので人間や正規のエージェントはほとんど気にならないが、無認証アカウントをスクリプトで大量生成しようとすると、作成のたびにこの計算が積み上がって割に合わなくなる。
ログイン不要という入口の広さと、自動大量作成の抑止を両立させるための設計だ。

作成速度にも制限がある。
短時間に一時preview accountを作りすぎると、待ってから再試行するか、通常のCloudflareアカウントで認証する流れになる。
ここはエージェント基盤に組み込む側でリトライ間隔を雑に詰めないほうがよさそうだ。

費用面では、60分で消える小さなpreview accountという設計なので、いきなり恒久課金のCloudflareアカウントを作るより危険は小さい。
それでもclaimした後は普通のアカウントになる。エージェントが一時アカウントの中で作ったものが、そのまま自分の恒久アカウントに紐づく。
D1、Queues、Hyperdriveまで触れるプロトタイプを引き取るなら、claim直後に中身を点検する。

エージェントが作ったD1データベース、KV namespace、Queue、Durable Objectを洗い出す。一時環境の制限内で雑に量産されていることがある
wrangler.toml / wrangler.jsonc のバインディング定義と、実在するリソースの対応を確認する。一時アカウント用に作られたIDが残っていないか見る
ハードコードした値やダミーのシークレットが残っていないか確認する
本番運用するなら、最小権限のAPIトークンを自分で発行し直す。一時デプロイ経路では発行されない
検証ループで何度も再デプロイしたWorkerがそのまま残るので、要らないものは削除する

claim URLは一時アカウントの所有権そのものなので、gitにコミットしたり公開チャンネルに貼ったりしない。

claimするかどうかは、人間がclaim URLを開く時点で決める。エージェントが自分で本番アカウントを作り続ける仕組みではない。