2026 年 5 月、Hacker News で Agents can now create Cloudflare accounts, buy domains, and deploy が話題になり、「AI エージェントが自律的に Cloudflare アカウントを作成し、ドメインを購入し、Workers をデプロイする」フローが公式 API で提供されました。これは 「人間がクラウドコンソールにログインして作業する」前提が崩れた瞬間で、受託開発の運用設計を根本から変える可能性があります。
弊社では、Claude Code / Codex / Cursor を組み込んだ案件で 「エージェントがクレジットカードに紐付くサービスへ自律的にサインアップする」動きが現実に発生しています。本記事では、自律エージェントが支出を生む時代に、受託契約と運用をどう設計し直すかを整理します。
何が変わったのか
Cloudflare の今回の発表は、以下の 3 つの能力を統合した点に意味があります。
| 能力 | 旧来 | 新体系 |
|---|---|---|
| アカウント作成 | 人間の手動操作 | API 経由で自動 |
| ドメイン購入 | 人間が決済画面で承認 | エージェントが Cloudflare Registrar 経由で自動取得 |
| デプロイ | CI/CD で人間が承認 | エージェントが Workers / Pages / R2 を直接構成 |
特に 「ドメイン購入の自動化」が大きな転換点で、1 年単位のドメイン費用 + Workers Paid プラン + R2 のストレージ費が エージェント単独でアカウントに発生する構造が現実になりました。
これは AI エージェントによる本番 DB 削除のガードレール で扱った “破壊的操作の自律化” と表裏一体で、「壊す権限」と並んで「お金を使う権限」をエージェントが持ち始めたことを意味します。
受託で組む「自律支出ガバナンス」の 4 階層
弊社では 「予算」「身元」「監査」「解約」の 4 階層で自律支出をガバナンスしています。
[Tier 1: 予算（Budget Wall）]
├ エージェント単位の月次支出上限
├ 80% 到達 → Slack + メール通知
└ 100% 到達 → API キー失効 + 新規購入停止
[Tier 2: 身元（Identity）]
├ エージェント専用の決済プロファイル
├ 顧客の社員クレカは絶対に使わない
└ Cloudflare / AWS / GCP すべて Service Account
[Tier 3: 監査（Audit）]
├ 取得ドメイン / 課金プラン / IP レンジを日次集約
├ 異常検知（前日比 +200% など）
└ 月次レポートで顧客 PM と共有
[Tier 4: 解約（Off-boarding）]
├ プロジェクト終了時の自動解約スクリプト
├ ドメイン譲渡 / 削除の手順書
└ 残債の精算ルール特に Tier 4 の “プロジェクト終了時解約” は実装が後回しにされがちですが、「使わなくなったエージェント名義のドメインがそのまま課金され続ける」事故が頻発しているため、契約段階で必ず設計に含めます。
受託契約に書く「自律支出条項」のひな型
エージェントが支出を生む受託では、契約段階で支出範囲・責任を明文化することが事故防止の必須条件です。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 支出上限 | エージェント単位の月次上限を明記 | 上限超過時の協議手順 |
| 決済主体 | 弊社 or 顧客のどちらが直接決済するか | 経費計上のルール |
| 取得資産の所有 | ドメイン / アカウントの最終所有者 | プロジェクト終了時の譲渡条件 |
| 異常時停止 | 異常支出検知時の即時停止権 | 通知 SLA |
| 監査ログ | 課金明細・操作履歴の保存期間 | 期間と粒度 |
| 解約条件 | 終了時の解約・譲渡・削除手順 | 残債精算 |
特に **「取得資産の所有」を明記しないと、プロジェクト終了後に “ドメインの所有者が誰か分からない” 事態が発生します。「弊社名義で取得したものは、終了時に顧客名義へ譲渡 or 削除」**を選択肢として書面で合意します。
これは Claude Code Auto Mode を受託で安全運用する で扱った Approval Gates の発想を、「金銭を伴う操作」へ拡張したものと捉えてください。
エージェント専用の「決済プロファイル」を作る
クラウド支出を健全化するうえで最重要なのは、「エージェント専用の決済プロファイル」を作ることです。弊社では以下の構成を標準にしています。
| 項目 | 推奨設定 |
|---|---|
| クレジットカード | プロジェクト用バーチャルカード（Stripe Issuing 等） |
| カード上限 | 月次予算 + 20% のバッファのみ |
| 利用通知 | 全決済を即時 Slack 通知 |
| 名義 | プロジェクト名 / エージェント ID 入り |
| 凍結トリガー | 上限超過時に自動凍結 |
社員個人や代表者のクレカを使うのは絶対 NG です。エージェントが暴走したときに即時凍結できる構造が、自律支出時代の必須条件です。
価格モデル — 自律支出ガバナンスを含めた受託パッケージ
自律支出ガバナンスを含めた受託パッケージは、以下のレンジで提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| Spend Lite | 30 万円 / 5 万円〜 | 既存案件への後付け | バーチャルカード + 月次レポート |
| Spend Standard | 120 万円 / 18 万円〜 | 新規・継続案件 | Lite + 4 階層ガバナンス + 異常検知 |
| Spend Enterprise | 350 万円〜 / 55 万円〜 | 上場・規制業界 | Standard + RBAC + 監査ログ + 24h 対応 |
特に 「Spend Standard を入れたら、エージェントの暴走支出が月数十万円 → 月 1 万円に減った」事例があり、コスト改善幅が見えやすい領域です。
ハマりやすい 5 つの落とし穴
最後に、自律支出を扱う受託で踏みやすい落とし穴を共有します。
落とし穴 1: 個人クレカで運用を始める
「とりあえず代表のクレカで」と始めると、プロジェクト終了後も個人に課金が残り続ける事故が頻発します。初日からプロジェクト用バーチャルカードを必ず発行します。
落とし穴 2: 上限のないクラウドアカウント
Cloudflare / AWS / GCP のアカウントに 月次予算アラートを設定し忘れると、夜間に数十万円の課金が発生します。全クラウドアカウントに必ず予算アラートを設定します。
落とし穴 3: ドメインの所有者を曖昧にする
「とりあえず弊社名義で取得します」と始めると、プロジェクト終了時に譲渡費用と権利関係で揉めます。契約段階で所有方針を合意します。
落とし穴 4: 解約スクリプトを書かない
エージェントが作ったリソースを 「目視で確認して削除」する運用は、リソース漏れが発生します。API でリソース一覧を取得 → 一括解約スクリプトを必ず用意します。
落とし穴 5: 顧客 PM が課金を見ない
弊社だけが課金を監視する運用は、月末の請求書で初めて顧客が気付く事態を生みます。日次の課金 Slack 通知を顧客 PM も購読するルールを契約に書きます。
まとめ — 「人間の承認」から「機械的なガードレール」へ
AI エージェントがアカウントを作りドメインを買う時代、「人間が逐一承認する」運用は速度面で破綻します。機械的に発動するガードレール（予算・身元・監査・解約）を契約と実装の両面で設計することが、受託の責任範囲を健全に保つ唯一の方法です。
弊社では Spend Lite / Standard / Enterprise の 3 段階で 自律支出ガバナンスを組み込んだ受託パッケージを提供しています。「エージェントの支出が読めず怖い」「プロジェクト終了後の解約導線がない」というご相談は お問い合わせフォーム からお気軽にどうぞ。
