CloudflareがAIエージェント向け「一時アカウント」を発表——wrangler deploy –temporaryでサインアップ不要のデプロイが可能に

Cloudflareは2026年6月19日、AIエージェントがアカウント作成やログインを行わずにアプリをデプロイできる新機能 「Temporary Cloudflare Accounts for Agents」 を発表しました。
コーディングエージェントがコードを書いた後、そのまま wrangler deploy --temporary を叩くだけで、サインアップを挟まずに Worker をデプロイできる、というもの。

公式の発表はCloudflareのブログ（Temporary Cloudflare Accounts for AI agents）で確認できる。

なぜ「一時アカウント」が必要なのか

AIにコードを書かせること自体は、もはや日常の風景になりました。
アプリや、ブログ、その他コンテンツのかなりの割合で人間が作ることは少なくなってきましたよね。

問題はその後である。
エージェントが書いたコードを実際にデプロイしようとした瞬間、人間向けに設計された壁 に正面衝突します。
ブラウザベースのOAuthフロー、ダッシュボードのクリック操作、APIトークンのコピー&ペースト、MFAプロンプト。

コードは書いてもらえるが、この辺りが、やはりプログラムやITを昔やっていた人じゃないと難しい場面かと思います。

Cloudflareはこの摩擦が重要である理由を、おおむね次のように整理している。

人間がループに入らないバックグラウンドのAIセッションが標準になりつつある こと。
ブラウザを開かせる、コピペを要求する、「60秒以内にここをクリック」といった認証ステップが挟まれば、エージェントはそこで詰まり、最悪の場合は別のデプロイ先を選んでしまう。

そしてトライ&エラーこそがエージェントの強み であること。
エージェントは write → deploy → verify のタイトなループを必要とする。
自分の出力を curl で叩いて、意図通りに動いているかを自ら判断するためには、安価で使い捨て可能なデプロイ先が不可欠になります。

また、各エージェントプラットフォームが「余計な手順や認証情報なしで動く」デプロイ手段を独自に構築し始めている こと。

ユーザー側も「触ったこともないサービスにサインアップせずとも、ただ動く」ことを期待し始めている。

現状ではまだユーザー自身がAPIキーをとってきたり、プラットフォームに登録したり、決済したり・・・という作業を行う必要がありますよね。

仕組み——Wranglerへの--temporaryフラグ追加

この機能は、Cloudflareの開発者向けCLI Wrangler に組み込まれています。
Wranglerの使い方はオンラインに広く文書化されており、LLMはその扱いをすでに熟知していますが、サインインとアカウントへの権限付与が済んでいなければ、デプロイ時に認証ステップで止まってしまうわけです。

ここでひとつ興味深い設計上の問題が出てきます。
エージェントやLLMは、新設された --temporary フラグの存在をどうやって知るのか？ 
人間が明示的に教えなくても使えなければ意味がない。

Cloudflareの解法はシンプルです。
Wranglerを更新し、認証情報が見つからないままデプロイが試みられた際に、--temporary フラグの存在を伝えるメッセージをエージェント宛に出力する ようにしました。
エージェントはこの出力を読み取り、自律的に再実行する、という流れであります。

実際のフローは次のようになる。エージェントが --temporary 付きで wrangler deploy を再実行すると、Cloudflareは以下を行う。

• エージェント用の一時アカウントを 新規プロビジョニング（もしくは再利用）
• Wranglerに作業用のAPIトークンを払い出し
• Workerを workers.dev のURLへデプロイ
• 人間が後から引き継ぐための claim URL を提示

引き継ぎ（claim）と60分のタイムリミット

デプロイされた一時アカウントは 60分間有効。

この間、エージェントは同じ一時アカウントを再利用しながら、コードの修正と再デプロイを何度でも繰り返せます。

実際のデモでは、エージェントが「hello world」を生成・デプロイし、プレビューリンクを自分で curl して検証した後、「hello cloudflare」へ書き換えて再デプロイ・再検証する、という一連のサイクルを人間の介在なしで完結させている。

claim URLを開くとサインアップ/サインイン画面に遷移し、ログインまたは新規登録を行うことで、一時アカウント上に作られた Worker や関連リソースを 自分の恒久的なCloudflareアカウントへ引き継げる。

引き継ぎの対象は Worker 本体だけでなく、データベースをはじめとする各種 binding も含まれる。

逆に、60分以内にclaimしなければ、一時アカウントとデプロイ内容は自動的に削除される仕組みです。

対象範囲と制約

この一時アカウントは、あくまで プロトタイピングやエージェントによる自動デプロイを円滑にするためのもの 。

本番環境やCI/CDパイプラインには、従来通り正規のCloudflareアカウントと認証情報を使うことが推奨されています。

記事執筆時点で対象となるのは、Workers、Workers Static Assets、Workers KV、D1、Durable Objects、Hyperdrive、Queues、SSL/TLS certificates など一部のプロダクト・リソースに限られており、利用範囲には制限があるので詳細はdeveloper documentationを参照されたい。

より大きな文脈——「フリクションレスなエージェントデプロイ」への布石

今回の一時アカウントは、Cloudflareが進める「エージェントからのサインアップ障壁を取り除く」取り組みの 一手 に過ぎない。

Cloudflareはすでに Stripeとの提携 を発表しており、エージェントがユーザーに代わってCloudflareをプロビジョニングする——アカウント作成、サブスクリプション開始、ドメイン登録、デプロイ用APIトークンの取得までを、トークンのコピペやクレジットカード情報の入力なしに行える——新プロトコルを共同設計している。また先月には WorkOSと協業し、auth.md をローンチしました。

これは確立された既存のOAuth標準を用いて、エージェントが新規アカウントをプロビジョニングできるようにする仕組みで、誰でも採用可能です。

「エージェントがいかにサービスを使い始められるか」をめぐる動きは、今まさに活発化している領域です。

認証フローは長らく「人間がそこにいる」ことを暗黙の前提としてきました。
一時アカウントという発想は、その前提を一度外し、「まず動かす、所有はあとから」 という順序の入れ替えで摩擦を解消しようとする点が巧みです。

--temporary フラグの存在をWranglerの出力経由でエージェントに「発見させる」設計も、LLMの振る舞いを織り込んだ実装として示唆に富んでいます。

一方で、サインアップなしでリソースをプロビジョニングできる経路は、当然ながら濫用リスクと隣り合わせでもあり、60分という短い寿命と対象プロダクトの限定は、その緩衝材として機能しているように見えます。

本番利用には正規アカウントを、という線引きが今後どこまで維持されるのか、続報を待ちたい。