AIエージェントがCloudflareアカウントを作り、ドメインを買い、デプロイする——企業が知るべきリスクと統制の全て
2026年4月30日、Stripe Sessions 2026の場で、AIエージェントが人間の操作なしにCloudflareアカウントの作成・ドメイン購入・Workersのデプロイを実行できる仕組みが、オープンベータとして公開された。Stripe ProjectsとCloudflare Agents SDKの組み合わせによるこの自律プロビジョニング機能は、開発速度の飛躍的な向上をもたらす一方で、統制設計なしに導入すれば不可逆なコストとリスクをも自動化してしまう。
この記事では、機能の仕組み・具体的なリスクシナリオ・Cloudflareが用意している統制機能・企業導入チェックリスト・業務適用パターンを整理する。「エージェントに何を許可するか」という設計判断の材料として活用してほしい。
AIエージェントによる自律プロビジョニングの仕組み
Stripe Projects——3つの技術コンポーネント
Stripe Projectsは、AIエージェントが複数のクラウドサービスをプログラム的にプロビジョニング・課金できるオープンプロトコルとして設計されている（出典：Cloudflare公式ブログ 2026年4月30日、https://blog.cloudflare.com/agents-stripe-projects/）。3つのコンポーネントで構成される。
① Discovery（発見）
エージェントが stripe projects catalog コマンドを呼び出し、利用可能なサービス一覧をREST/JSONカタログとして取得する。現在対応するプロバイダーはStripe Projects全体で複数社にのぼる（公式サイト https://projects.dev/providers/ で最新一覧を確認できる）。
② Authorization（認証・認可）
StripeがIDプロバイダーとして機能する。既存のCloudflareアカウントはOAuth標準フロー経由で連携される。Cloudflareアカウントが存在しない場合、StripeのID証明を元にCloudflareが自動的に新規アカウントを作成し、APIトークンをエージェントに返す。
③ Payment（支払い）
Stripeが支払いトークンをプロバイダー（Cloudflare等）に供給する。エージェントは生のクレジットカード番号・支払い詳細を一切参照しない設計になっている。
エージェントが「できること」の範囲
Cloudflareとの連携で、エージェントが実行できる操作は以下のとおりだ。
stripe projects add cloudflare/registrar:domain：ドメインの検索・購入stripe projects add cloudflare/worker：Cloudflare Workersのデプロイ- Cloudflareアカウントの自動作成（未存在時）
Claude Code・Cursor・OpenAI Codex等の開発ツールへの統合手順は、cloudflare/skillsリポジトリ（https://github.com/cloudflare/skills）に収録されている。
法人カードを渡したとき、何が起きるか——3つのリスクシナリオ
機能の説明だけでは不十分だ。エージェントに決済・インフラ操作権限を与えるということが、実際にどのようなリスクを内包するか——法人カードを渡す前に、3つのシナリオを頭に焼き付けてほしい。
シナリオ1：ドメイン誤購入（払い戻し不可）
Cloudflare Registrar APIの公式ドキュメントは「ドメイン登録は払い戻し不可」と明記している。エージェントがタイポドメインやスペルミスを含むドメインを購入した場合、取り消しは不可能だ。承認フロー（waitForApproval）を実装せずにエージェントにRegistrar APIへのアクセスを与えることは、白紙の小切手を渡すに等しい。笑い話で済むのは、購入したドメインが1件で、費用が数ドルの場合に限られる。
シナリオ2：Denial of Wallet——費用爆発
OWASP Top 10 for Agentic Applications 2026が「Denial of Wallet（DoW）」として警告するリスクだ（出典：https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/）。エージェントが意図しないループに入り、APIコールやリソース作成を繰り返すことで、指数的に費用が膨らむ。Stripe ProjectsがプロバイダーごとにデフォルトのSpending Capとして月額$100 USDを設定しているが、設定変更を誤ったり複数エージェントが並列起動した場合、上限が意味をなさなくなるケースも想定しなければならない。
シナリオ3：悪用シナリオ——攻撃インフラの自動展開
InfoWorldの取材に応じたセキュリティ専門家David Shipley（Beauceron Security）は「新しいインフラを構築し迅速に展開できるようにすることは、彼ら（サイバー犯罪者）にとって大きな利益だ」と指摘している。また同取材でShashi Bellamkonda（Info-Tech Research Group）は「運用面では、各ベンダーのパートナーネットワークにとってトランザクション実行と説明責任の面で複雑性が増す可能性があり、相当の事前検討が必要になる」と警告している（出典：InfoWorld 2026年 https://www.infoworld.com/article/4165857/are-we-ready-to-give-ai-agents-the-keys-to-the-cloud-cloudflare-thinks-so.html）。自律的なアカウント作成とデプロイ機能は、防御側だけでなく攻撃側にも等しく利用可能だという現実を直視する必要がある。
Cloudflareが用意している統制機能
リスクを把握した上で、利用可能な統制機能を整理する。Spending CapはStripe Projects側の機能、Managed OAuthはCloudflare Accessで保護された内部アプリ向けの機能だが、残る3つはCloudflareが直接提供する統制だ。以下は公式ドキュメントで確認できた事実のみを記載している。
統制機能の全体像
| 統制機能 | 対応するリスク | デフォルト状態 |
|---|---|---|
| Human-in-the-loop（waitForApproval） | 不可逆操作の誤実行 | 実装が必要（自動では有効にならない） |
| Spending Cap ※Stripe Projects側で設定 | Denial of Wallet | 月額$100 USD（プロバイダーあたり・変更可） |
| Resource-scoped RBAC | 過剰な権限付与 | 設定が必要 |
| Managed OAuth ※Cloudflare Access内部アプリ向け | Confused Deputy問題 | オプトイン（オープンベータ） |
| Audit Logs v2 | 操作の追跡・監査 | デフォルト有効 |
何も設定しない状態で使い始めた場合、Audit Logs v2以外の統制機能はほぼ機能しない。「デフォルトで安全」ではなく「設計して安全にする」仕組みだという前提で導入計画を立てること。
① Human-in-the-loop（承認フロー）
出典：https://developers.cloudflare.com/agents/concepts/human-in-the-loop/
5つの実装パターンが用意されている：Workflow Approval / needsApproval / onToolCall / MCP elicitation / State + WebSocket。主要なAPIは以下の3つ。
waitForApproval(step, { timeout: "7 days" })：ワークフローを承認待ちで一時停止approveWorkflow(workflowId)：承認して実行を再開rejectWorkflow(workflowId)：却下してワークフローを終了
ドメイン登録・支払い処理・一括削除・権限付与などの不可逆操作には、公式が事前承認フローの実装を推奨している。
② Spending Cap（支出上限）
出典：Cloudflare公式ブログ 2026年4月30日
Stripeがプロバイダーあたりのデフォルト上限として月額$100 USDを設定する仕組みだ（Stripe Projects側の機能）。上限を引き上げる場合はCloudflareアカウントのBudget Alertsを設定して支出が閾値を超えた際の通知を有効にできる。エージェントは生の支払いデータにアクセスできない設計になっている。
③ Resource-scoped RBAC（リソース単位の権限管理）
出典：https://blog.cloudflare.com/improved-developer-security/
アカウント・ゾーンレベルを超えた、リソース単位の細粒度権限設定が可能。APIトークンにはスキャナブルなプレフィックス（cfk_ / cfut_ / cfat_）が付与され、GitHub Secret Scanningプログラムと連携することで公開リポジトリへの漏洩を自動検知・revocationできる。
④ Managed OAuth（Confused Deputy対策）
出典：https://blog.cloudflare.com/managed-oauth-for-access/（2026年4月14日オープンベータ公開）
RFC 9728準拠。Cloudflare Accessで保護された内部アプリケーションにエージェントが認証してアクセスする際に機能する仕組みだ（Stripe ProjectsのCloudflare操作に使われる認証とは別フロー）。「Confused Deputy問題」——エージェントが意図せず過剰な権限で操作してしまう問題——への対策として、トークンはユーザーのIDにスコープされ、全操作が起動元の人間に追跡可能になる。サービスアカウント（静的認証情報）の使用を排除できる点は、エージェント設計全般の指針として有用だ。
⑤ Audit Logs v2（監査ログ）
出典：https://developers.cloudflare.com/fundamentals/account/account-security/audit-logs/
全Cloudflareサービスの約95%をカバーする標準化フォーマット。actor_typeは4種類（user：個人ユーザー / account：アカウントAPIトークン / Cloudflare_admin：Cloudflare管理者 / system：システム自動操作）で操作主体を記録し、dashboard/APIなどの操作経路はactor.contextフィールドで区別する。Ray IDも記録される。APIエンドポイントは https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit。エンタープライズ向けにはLogpushで18ヶ月超の保存が可能だ。
企業導入チェックリスト——OWASPリスクとの対応表
OWASPリスクとCloudflare機能の対応
| OWASPリスク | Cloudflareの対応機能 | 対応状況 |
|---|---|---|
| Excessive Autonomy（過剰な自律性） | Human-in-the-loop / Resource-scoped RBAC | 実装により対応可 |
| Denial of Wallet | Spending Cap / Budget Alerts | デフォルトで部分対応 |
| 最小権限原則違反 | Resource-scoped RBAC | 設定により対応可 |
| 認証情報の静的管理リスク | Managed OAuth（Access内部アプリ向け） | オプトインで対応可 |
| 操作の追跡不可 | Audit Logs v2 | デフォルトで対応 |
3フェーズ別チェックリスト
【導入前】
- Stripe Projectsのオープンベータ規約を確認し、本番利用の可否を判断した
- エージェントに付与するCloudflare APIトークンのスコープを最小限に定義した
- Spending Capの上限額を自社の許容リスクに合わせて設定した
- ドメイン購入・Workersデプロイ等の不可逆操作にwaitForApprovalを実装した
【導入時】
- Resource-scoped RBACでリソース単位の権限を設定した
- Cloudflare Accessで保護した内部アプリにエージェントがアクセスする場合、Managed OAuthを有効化してトレーサビリティを確保した
- テスト環境でDoWシナリオ（意図的なループ）を再現し、Spending Capが機能することを確認した
- Audit Logs v2のエクスポート先（Logpushまたは直接API）を設定した
【運用中】
- Budget Alertsの通知先を設定し、定期的に費用レポートを確認している
- Audit Logsで定期的にエージェントの操作履歴を監査している
- APIトークンのプレフィックス（
cfk_等）が外部リポジトリに漏洩していないかGitHub Secret Scanningで確認している - エージェントの操作スコープが業務要件の変化に合わせて適切に更新されている
業務適用パターン3例
パターン1：SaaS MVPの自動セットアップ
スタートアップがMVPを最速でデプロイしたい場面。エージェントがドメイン取得〜Workers デプロイまでをワンショットで完了し、エンジニアはwaitForApprovalによる最終確認のみを行う。インフラ構築の実作業をエージェントに委譲することで、MVP開発のリードタイムを大幅に圧縮できる。ただしドメイン購入は必ず承認ステップを挟むこと——払い戻し不可の原則はここでも変わらない。
パターン2：マルチテナントSaaSの顧客オンボーディング自動化
新規顧客の登録をトリガーに、エージェントがサブドメインとWorkersインスタンスを自動プロビジョニングするパターン。Resource-scoped RBACでテナントごとのAPIトークンスコープを最小限に分離することで、テナント間の権限混線リスクを抑えられる。顧客数が増えるほど、手動オンボーディングとの工数差が拡大する。
パターン3：受託開発でのクライアントインフラ展開支援
クライアントの要件をもとにエージェントがインフラ構成の提案〜初期リソース作成を担い、エンジニアは承認とレビューに集中する構成。初期構築工数の削減が収益性改善に直接つながるため、受託開発の営業文脈でも提案しやすい。クライアントのCloudflareアカウントに対してResource-scoped RBACで最小権限のAPIトークンを発行することで、権限の逸脱なく安全に運用できる。「エージェント基盤の導入設計から伴走する」という提案の骨格として機能しやすいパターンだ。
導入を検討している企業様へ
AIエージェントによるインフラ自動化は、適切な統制設計があってはじめて「企業の資産」になります。Stripe Projectsは現在オープンベータの段階にあり、本番環境で活用するには、技術的な実装に加えて、セキュリティポリシーの整備・承認フローの設計・監査体制の構築をあわせて進める必要があります。
自社での導入を検討中の方、受託開発でクライアントへのエージェント基盤提案を準備されている方など、設計段階で壁打ち相手が欲しいタイミングがあればお気軽にご相談ください。具体的な構成や自社プロジェクトとの適合性についてもお話しできます。
FAQ
Q1. Stripe ProjectsはCloudflareのどのプランで使えるか？
Stripe Projectsは現在オープンベータであり、プラン別の提供条件は公式ドキュメントに明記されていない。利用開始前にCloudflareの最新プラン情報を公式サイトで確認すること。
Q2. エージェントが誤ってドメインを購入した場合、払い戻しはできるか？
できない。Cloudflare Registrar APIの公式ドキュメントはドメイン登録を払い戻し不可と明記している。このリスクへの対策として、公式はwaitForApprovalによる事前承認フローの実装を推奨している。
Q3. waitForApprovalを実装しないとどうなるか？
エージェントは承認なしにドメイン購入・デプロイ・アカウント作成を実行し続ける。設定ミスや指示の曖昧さが即座にコストや本番環境への影響につながるため、不可逆操作を含む全ての用途で実装を前提とすること。
Q4. 既存のCloudflareアカウントがある場合、エージェントに新規アカウントを作らせる必要があるか？
ない。AuthorizationコンポーネントはOAuth標準フロー経由で既存アカウントを連携する設計になっている。新規アカウント作成は既存アカウントが存在しない場合にのみ実行される。
Q5. Audit Logsでエージェントの操作を人間の操作と区別できるか？
Audit Logs v2では、actor_typeフィールドで操作主体（user：個人ユーザー / account：アカウントAPIトークン / Cloudflare_admin / system）を区別できる。dashboard経由かAPI経由かはactor.contextフィールドが担う。ただし「エージェントによるAPIコール」と「人間によるAPIコール」を明示的に分離するフラグは公式ドキュメントに記載がなく、どちらもAPIトークン経由なら同じactor_type（account）として記録される。Managed OAuthを内部アプリへのアクセスに活用することで、トークンを起動元ユーザーにトレースする補完的な手段が得られる。
エージェント統制の核を担う5つの機能——Human-in-the-loop・Spending Cap（Stripe側）・Resource-scoped RBAC・Managed OAuth・Audit Logs v2——はいずれも「設計して安全にする」ものであり、デフォルトのまま使い始める選択肢はない。エージェントに何を許可し、どこで人間が判断を取り戻すか。その境界線を引く責任は、エンジニアと企業の側にある。
お気軽にご相談ください
AIを使った業務効率化、社内ツール開発、既存プロダクトへのAI機能追加、受託開発全般——上流の企画段階から実装・運用まで、まとめてご相談いただけます。
「これってAIで解決できるの？」「どこから手をつければいい？」という入口のご相談大歓迎です。
具体的な仕様が固まる前の壁打ちフェーズからぜひお気軽にご相談ください。
参考情報
- Cloudflare公式ブログ「Agents + Stripe Projects」（https://blog.cloudflare.com/agents-stripe-projects/）
- Cloudflare「Human-in-the-loop」開発者ドキュメント（https://developers.cloudflare.com/agents/concepts/human-in-the-loop/）
- Cloudflare「Improved Developer Security」（https://blog.cloudflare.com/improved-developer-security/）
- Cloudflare「Managed OAuth for Access」（https://blog.cloudflare.com/managed-oauth-for-access/）
- Cloudflare「Audit Logs」ドキュメント（https://developers.cloudflare.com/fundamentals/account/account-security/audit-logs/）
- OWASP Top 10 for Agentic Applications 2026（https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/）
- Stripe Projects プロバイダー一覧（https://projects.dev/providers/）
- Cloudflare Skills リポジトリ（https://github.com/cloudflare/skills）
- InfoWorld「Are we ready to give AI agents the keys to the cloud? Cloudflare thinks so」（https://www.infoworld.com/article/4165857/are-we-ready-to-give-ai-agents-the-keys-to-the-cloud-cloudflare-thinks-so.html）
