Cloudflareが、AIエージェント向けに Temporary Cloudflare Accounts を提供し始めました。ざっくり言うと、AIが「コードを書いたあと、すぐにデプロイまで進みたい」ときに、人間向けの面倒な登録作業を飛ばせる仕組みです。
これ、地味に見えてかなり大きいです。AIはコードを書くのは得意でも、そのあとに出てくる「ブラウザでログインして」「OAuthを通して」「API tokenをコピペして」「2段階認証を入れて」みたいな壁で止まりがちでした。Cloudflareはその壁を、かなり正面から壊しにきた、という印象です。
wrangler deploy --temporary で、60分だけ使える仮アカウントを作れるこの記事でCloudflareが強調しているのは、「AIエージェントには、人間みたいなログイン体験が合わない」という点です。
人間なら、初回登録で多少手間がかかっても我慢できます。でもバックグラウンドで動くAIは違います。途中で「この画面を開いてください」と言われても困るし、「60秒以内にクリックしてください」といった流れにも弱い。要するに、ちょっとした摩擦で止まるんです。
しかも、エージェントの強みは 試して、失敗して、直して、また試す ところにあります。Cloudflareはここをかなりよく見ています。AIは1回で完璧に当てにいくより、動くものを作って実際に叩いて確かめるほうが向いている。だからこそ、安くて、捨てやすくて、すぐ使えるデプロイ先が必要だ、という理屈です。
この考え方は、かなり納得感があります。人間中心に作られた認証フローは、AIには重すぎる。AIのための仕組みは、もっと「試して終わり」くらい軽くていい、ということなんでしょう。
中心にあるのは、CloudflareのCLIツール Wrangler です。CLIはコマンドラインツール、つまり黒い画面で文字を打って操作する道具ですね。Web画面をポチポチする代わりに、wrangler deploy のようなコマンドでWorkerを配備できます。
今回の仕組みでは、最新のWranglerを使って wrangler deploy --temporary を実行すると、CloudflareがAI向けの仮アカウントを用意します。WranglerにはそのためのAPI tokenも渡され、さらに「この仮アカウントをあとで引き取れますよ」という claim URL も返されます。claim URLは、あとで人間が正式にアカウントを受け取るための入口です。
面白いのは、AIがこの新しい --temporary オプションを最初から知っているわけではない点です。そこでCloudflareは、Wrangler側からAIに「こんなフラグがありますよ」と気づかせるメッセージを返すようにしたそうです。ここ、かなり実務的で好きです。AIに学習済みの知識を期待するだけではなく、ツール側が「ヒントを出す」設計になっている。人間の相棒としてではなく、半ば自動実行する主体としてAIを扱っている感じがします。
Cloudflareの説明では、AIエージェントに「Hello WorldのWorkerを作って、build modeでデプロイして」と指示すると、エージェントがWranglerを実行し、出力された案内から --temporary を拾い、すぐデプロイします。人間が途中で介入する必要はありません。
そのあと、エージェントは公開されたプレビューURLを curl して、実際の出力がコードどおりか確認します。ここが大事で、単に「デプロイできました」で終わらず、自分で叩いて確かめるところまで自動化されているわけです。
さらに、1回デプロイしたら終わりではありません。たとえば「hello world を hello cloudflare に変えて再デプロイして」と頼むと、同じ仮アカウントを使い回しながら、コードを直してもう一度配備し、結果を確認できます。60分のclaim windowのあいだなら、何度でも繰り返せるというわけです。
このあたりは、AIが本当に“作業者”として動く未来をかなり現実的に感じさせます。単にチャットで提案するだけじゃなくて、実際のインフラに触って、結果を見て、修正する。ここまで来ると、もはや「コード補助」より一段進んでいます。
Temporary Account は、その名の通り一時的です。使わなければ 60分で自動削除 されます。これはかなり気持ちがいい設計だと思います。試作や検証のために作ったものが、いつまでも残って管理の負担になるのはありがちですが、その問題を最初から避けている。
一方で、気に入ったら claim link をクリックして、その仮アカウントを正式に自分のものにできます。Cloudflareによれば、Workers だけでなく、database や bindings などの関連リソースも一緒に引き継げます。つまり「仮の遊び場」で終わらず、そのまま本番の土台に育てられる。
この設計、個人的にはかなりうまいと思います。完全に使い捨てだと本番への橋がないし、逆に最初から重い正式アカウントだとAIがつまずく。Temporary Account は、その中間をきれいに埋めています。
この記事は単体の機能紹介に見えますが、実際にはもっと大きい流れの一部です。Cloudflareは以前から、AIエージェントがサービスを使うときの「登録しろ」「認証しろ」「カードを入れろ」という摩擦を減らそうとしています。
たとえばStripeとの提携では、エージェントがユーザーの代わりにCloudflareのセットアップを進められるようにする仕組みを発表していました。アカウント作成、サブスクリプション開始、ドメイン登録、API token取得までを、コピー&ペーストなしで進める方向です。
さらにWorkOSと一緒に auth.md という仕組みも出しています。これは、既存のOAuth標準を使って、エージェントが新しいアカウントを作りやすくする考え方です。OAuthは、外部サービスに安全にログインするための仕組み、と考えるとわかりやすいでしょう。
つまりCloudflareは、AI向けの「使えるまでの面倒」を全体的に削っているわけです。Temporary Account は、その中でも「まずデプロイしたい」という場面に刺さる機能です。
面白いのは、CloudflareがAIを「人間の代わりにちょっと手伝う存在」ではなく、「自分で環境を持って試行錯誤する存在」と見ているところです。
従来のSaaSは、人間が画面を見ながら登録して使う前提で作られていました。でもAIエージェントは、画面よりもコマンド、ログ、APIレスポンスのほうが扱いやすい。だからこそ、ログインを前提にした仕組みをそのまま当てはめると苦しい。
Cloudflareの今回の一手は、そのズレをかなり正直に認めた上で、「じゃあAI向けに最短距離を作ろう」としているのがいいです。ちょっとした実装変更に見えて、思想はかなり大きいと思います。
もちろん、万能ではありません。Cloudflare自身も、Temporary Account には制限があり、今後機能が変わる可能性があると書いています。でも、だからこそまずは使ってみて、Agentic deployment の摩擦をどこまで減らせるかを試してほしい、という姿勢なんでしょう。
AIがコードを書くだけでなく、そのまま配備までやる時代。Cloudflareはそこに、かなり実用的な足場を置きにきた、というのがこの発表の核心だと思います。
