CloudflareはプラットフォームがREST APIから一時プレビューアカウントを作成し、利用者のログイン前にWorkerと対応リソースをデプロイできるTemporary Accounts APIを公開した。利用者は動作確認後、claim URLからアカウントとリソースを恒久化できる。

何が変わったか

従来の一時デプロイは主にwrangler deploy --temporaryを実行するエージェントやツール向けだった。今回、バックエンドが/provisioning/previews系REST APIを使い、challenge取得、proof-of-work、一時アカウント作成、デプロイ、claim URL提示まで制御できる。利用者はアカウントを先に作らず、生成アプリを約60分テストし、claim後に対応リソースを保持できる。

変更前後の差

変更前はCLI起点の対話が中心で、独自オンボーディングへの統合に制約があった。変更後は規約表示、同意、challenge、プレビューURL、claim URLを自社UIへ組み込める。ただし、プラットフォームが利用者の恒久Cloudflareアカウントへ書き込む権限を得るわけではない。一時APIトークンは一時環境専用で、claim後の永続アクセスを前提にしない。

誰に影響するか

AIコーディングエージェント、アプリビルダー、学習環境、顧客向けプレビューを提供するSaaSに影響する。価値を見せてからサインアップさせられる一方、一時APIトークン、claim URL、プレビューURL、同意記録という新しい秘密・証跡が増える。サポート担当は失効、claim済み、別利用者の誤claimなどの状態を判別できる必要がある。

対応期限

導入を強制される期限はない。一時アカウントの約60分という有効時間が各実行の制約である。front matterは「期限なし」としたが、デプロイごとに有効期限を絶対時刻として表示し、ブラウザーのタイマーだけに依存せずサーバー時刻で判定する。

必要な対応

Cloudflareの利用規約とプライバシーポリシーを自社画面に表示し、利用者の明示同意を監査可能な形で保存する。proof-of-workは再試行、負荷、タイムアウトを考慮する。一時APIトークンとclaim URLはログ、分析イベント、サポート画面、LLMプロンプトへ出さず、claim URLをbearer credentialとして対象利用者にだけ短時間表示する。

実装・移行手順

  1. challenge APIとproof-of-work処理を実装する。
  2. 規約・プライバシー同意を取得する。
  3. 一時アカウントを作り、返されたIDとトークンでデプロイする。
  4. Worker URLを検証し、プレビューとclaim URLを分離表示する。
  5. claim完了、失効、放棄を状態管理する。
  6. 一時秘密を短期保管から削除する。

失敗しやすい点

claim URLを通常の共有リンクとしてチャットやメールへ投稿すると、第三者がアカウントを引き継ぐ危険がある。APIトークンをデバッグログへ記録する、proof-of-work結果を無期限再利用する、失効時刻を端末時計だけで判断することも避ける。対応外リソースを含むアプリが一時環境で完全に動くと想定せず、対応製品と制限を確認する。

リスク

claim URL漏えい、一時トークン漏えい、未claimリソースへの機密データ投入、利用者同意の欠落が主要リスクである。一時環境だから安全とは限らず、公開Worker URLへ実データを送れば漏えいにつながる。大量作成やフィッシングも考慮し、レート制限、コンテンツ検査、利用者上限、通報、停止手順を用意する。

評価方法

作成成功率、デプロイ時間、claim完了率、失効率、再試行回数を測る。ログに秘密が残らないこと、別セッションからclaim URLへアクセスした場合の影響、期限後にトークンが使えないことを確認する。claim後はWorkerや対応リソースが期待どおり引き継がれ、プラットフォーム側が恒久アクセスを保持しないことを検証する。

ロールバック

問題があればTemporary Accounts経路を停止し、認証済みCloudflareアカウントへのデプロイまたはローカルプレビューへ戻す。既に発行したclaim URLと一時トークンは期限まで有効な可能性があるため、停止後も監視する。生成物のソースを別に保持し、一時アカウントを唯一の保存先にしない。

編集部の見解

このAPIはAIがアプリを作る体験とCloudflareのアカウント作成を分離し、価値を見せてから引き継ぐ設計を可能にする。一方、その滑らかさはclaim URLという強い権限をUI裏側へ持ち込む。実装品質はデプロイ速度より、同意、秘密管理、失効、引き継ぎ状態を正しく扱えるかで決まる。

実務チェックリスト

  • 規約とプライバシー同意を取得する
  • proof-of-workの再試行と負荷を制御する
  • 一時APIトークンをログへ出さない
  • claim URLをbearer credentialとして保護する
  • 60分の失効をサーバー側で判定する
  • 対応リソースと制限を確認する
  • claim、失効、放棄を試験する
  • 従来デプロイへの切替を用意する

一次情報