Stripe×Cloudflare：AIエージェントが自律でインフラ調達・デプロイする時代へ

「Agent commerce is fundamentally a trust problem—agents can’t enter credit cards or verify emails. What’s needed is a trusted third party to verify both sides.（エージェントコマースは本質的に信頼の問題だ。エージェントはクレジットカードを入力できないし、メール認証もできない。双方を保証する信頼できる第三者が必要だ）」

これはHacker Newsに投稿されたコメントだ（出典: Hacker News、2026年3月）。Stripe Projectsの初期プレビューを試みた開発者の言葉で、スレッドには「Sign in with Googleと同じ感覚。エージェントのコマース版だ」「ついにエージェントが本当に完結するインフラができた」という反応が並んだ。

2026年4月30日、Stripe Sessions 2026でStripeとCloudflareが共同発表したプロトコルが、その「信頼の基盤」を実装した。AIコーディングエージェントはもう、コードを書くだけでなく、ドメインを購入し、データベースを立ち上げ、本番環境にデプロイするところまで完結できる。

Stripe Sessions 2026で何が発表されたのか

Stripe Sessions 2026（4月30日開催）は、通常の年次開発者カンファレンスとは毛色が違った。発表の中心に据えられたのは「エージェントが経済活動の主体になる」というビジョンだ。

Stripeは今回288件の機能を発表したが、最も注目を集めたのがStripe Projects（オープンベータ）と、CloudflareとStripeが共同設計したエージェント自律調達プロトコルだ。

このプロトコルが実現するのは次のことだ。AIコーディングエージェントが、ユーザーに代わって以下をすべて自律実行できる。

• Cloudflareアカウントの新規作成
• ドメイン名の購入
• Vercel・Supabaseなどの有料サービス契約開始
• 本番環境へのデプロイ

人間が手動でやる作業はゼロ。ただし、一度だけ利用規約への同意と支払い方法の登録は必要だ（出典: Cloudflare Blog、2026年4月30日）。

InfoWorldは「Are we ready to give AI agents the keys to the cloud?（AIエージェントにクラウドの鍵を渡す準備はできているのか？）」という見出しで報じた（出典: InfoWorld、2026年4月30日）。懐疑的なニュアンスを含むタイトルだが、Cloudflareの回答は「Yes」だ。

プロトコルの3層構造

このプロトコルは技術的には3つの層で構成されている。

1. Discovery（発見） エージェントはREST/JSON形式のカタログを問い合わせ、利用可能なサービスの一覧と仕様を取得する。人間がドキュメントを読む代わりに、エージェントが「何ができるか」を自動で把握する。

2. Authorization（認可） Stripeがユーザーのアイデンティティを証明し、OAuth経由でプロバイダーに渡す。エージェントはそのユーザーのProject専用にスコープされた認証情報を受け取る。重要なのは、この認証情報はProjectに紐づいており、広範な権限は与えられない点だ。

3. Payment（決済） Stripeが決済トークンを発行し、プロバイダーへの請求はそのトークン経由で行われる。生のカード情報はエージェントに渡らない。デフォルトではプロバイダーごとに月額100ドルの上限がAPIレベルで強制される。エージェントが上限を超えようとすると、「警告」ではなく「拒否」が返る（出典: Stripe Blog、2026年4月30日）。

初期パートナー14社—何が使えるのか

Stripe Projectsの初期パートナーには、モダンなWebアプリ開発で使われるサービスが揃っている。

カテゴリ	サービス
インフラ/CDN	Cloudflare, Render
フロントエンドデプロイ	Vercel
データベース	Supabase, PlanetScale
認証	Clerk, WorkOS
監視/エラー追跡	Sentry, PostHog
通信	Twilio, ElevenLabs
コード/開発	GitLab, Browserbase
イベント処理	Inngest

要は、「ゼロからWebアプリを作って本番に出す」ために必要なサービスがほぼ揃っている。エージェントがプロジェクトの要件を理解すれば、これらを組み合わせてインフラを自動選定・契約・設定できる（出典: Stripe Sessions 2026、2026年4月30日）。

Claude CodeやCursorとの組み合わせで何が変わるか

今後、MCPサーバーとしてStripe Projectsが公開されれば、Claude Codeからこの機能を直接呼び出せる可能性がある。

現在のAIコーディングエージェントの限界は「コードは書けるが、インフラはユーザーが手動で整える必要がある」点だ。エージェントがpackage.jsonを生成しても、Vercelへのデプロイ設定やSupabaseのテーブル作成は人間がUIをポチポチする必要があった。

Stripe Projectsはこのギャップを埋める。エージェントがコードを書いた直後に「では本番に出す」まで完結できる。AIエージェント時代の開発者像を論じた議論と合わせると、このプロトコルは「エージェントが開発の主体になる」ための最後のピースの一つと言える。

光と影—セキュリティリスクと法的グレーゾーン

便利さの裏には見逃せないリスクがある。

プロンプトインジェクションによる支出暴走

最も深刻な懸念は「プロンプトインジェクション攻撃」だ。悪意あるプロンプトがエージェントのコンテキストに混入した場合、エージェントは攻撃者の意図通りに外部サービスを契約・課金する可能性がある。月額100ドルの上限はあるが、複数プロバイダーにまたがれば被害は積み上がる。

また、フィードバックループ（エージェントが自分の出力を入力として再利用）が暴走した場合も同様の問題が起きうる。Stripeはスコープ付き認証情報と支出上限でリスクを抑えているが、「設定した上限で十分か」はユースケース次第だ（出典: MindStudio）。

法的責任の所在が未整備

Fenwickの法律分析によれば、既存の金融法や消費者保護法は「人間の意思決定を前提に設計されている」。AIエージェントが不正・誤った取引を起こした場合、責任を負うのはユーザーか、AI開発者か、Stripeか、プロバイダーか、法的解釈が固まっていない（出典: Fenwick、2026年）。

StripeはAML（マネーロンダリング対策）や本人確認をいかにエージェント経由の取引に適用するかについても仕様を詰めている最中だ。

正面から向き合うべき問い

「AIエージェントに課金権限を渡すのは早すぎる」という批判もある。一方で、「エージェントが最後のステップだけ人間を待つのは非効率」という開発者側の現実も無視できない。どちらを優先するかは、チームのリスク許容度と使うエージェントの信頼性次第だ。

関連記事

• Claude Codeの2026年4月アップデート完全解説
• 2026年AIエージェント時代の開発者像—Spotifyはコードゼロ、Uberは70%がAI生成
• Claude Agent SDK完全ガイド—本番エージェントの設計と実装
• MCP vs A2Aプロトコル—AIエージェント間通信の標準争い