タグアーカイブ 従量課金

Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金

Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金

広告型モデルの限界とAIエージェント向け従量課金

広告型モデルの限界とAIエージェント向け従量課金

2026年7月1日、CloudflareはMonetization Gatewayを発表した。HTTPの402ステータスコードを拡張したオープンプロトコル「x402」を基盤に、ウェブ上のあらゆるリソースに対して従量課金を適用できる仕組みである。保護対象はウェブページ、データセット、API、MCPツールにおよび、代理店や大規模言語モデルが自律的に支払う時代を見据えている。

背景にはウェブビジネスモデルの構造変化がある。30年にわたり、コンテンツは広告や月額課金で収益化されてきた。しかしAIエージェントが人間に代わって情報を消費するようになると、バナー広告をクリックすることも、毎月のサブスクリプションを維持することもない。エージェントは必要なデータを一度取得すれば、数十回、数千回と繰り返しアクセスし始める。Cloudflareの発表資料によると、AIクローラーのリクエスト数は、そこからサイトへ誘導される訪問者1人あたり数百~数万回に達しているという。

従来のAPI従量課金は既存ユーザー向けに限定され、サブセント単位の少額決済には向かなかった。クレジットカードの手数料が取引額を上回るためだ。ここでCloudflareが着目したのが、ステーブルコインによる一瞬の決済である。Monetization Gatewayは、支払い検証と流量制御をエッジで完結させ、オリジンサーバーに過剰な負荷をかけずに課金を実現する。

従来の広告モデル(Before)
人間の訪問者 ページ閲覧 → 広告クリック → 収益発生
※AIエージェントは広告をクリックしないため収益化できない
従量課金モデル(After)
AIエージェント リクエスト → 自動支払い → リソース取得
※1リクエスト単位の少額決済で収益化が成立
人間 = 広告・サブスクリプション  AIエージェント = 従量課金・自動決済

CloudflareはすでにContent Independence DayでAIクローラーの制御機能を提供し、Pay Per Crawlでクローラーに課金する仕組みを導入していた。Monetization Gatewayはその延長線上にあり、クローラー以外の任意の呼び出し元に対して課金できる点が新しい。

エージェントが変える支払いの単位

AIエージェントが自律的に行動するようになれば、サービスの課金単位も座席数や月額から「リクエスト数」「トークン数」「成果物」へと移行する。Cloudflareが例示したのは、1回のウェブ検索あたり数セント、アップロードエンドポイントで0.001ドルの基本料金+1MBあたり0.01ドル、サポートエスカレーション解決時に0.99ドルといった単位である。

これまで実現が難しかったサブセントの決済を、x402プロトコルとステーブルコインが可能にする。ステーブルコイン(Open USDやUSDC)は1秒未満で決済が完了し、手数料が無視できるほど小さい。従来の決済手段では、手数料が支払い額を上回る逆転現象が起きていたが、それが解消される。

Cloudflareが提供する課金インフラ

Cloudflareの強みは、すでに自社の課金システムや顧客向けアナリティクスで従量課金の会計基盤を構築してきたことにある。Monetization Gatewayでは、売り手と買い手の間に入り、支払い証跡をHTTPリクエストに埋め込む形で検証パスを統合する。メータリング、支払い交換、決済はすべてオリジンサーバーの外で完結し、サイト運営者は課金ルールと価格だけを定義すればよい。買い手のオンボーディングや請求システムの構築は不要だ。

x402プロトコルとは

x402プロトコルとは

x402はHTTPのステータスコード「402 Payment Required」を実際に活用するオープンプロトコルである。この規格はCloudflareがx402 Foundationのもとで25以上の業界リーダーと共同開発を進めている。従来の402は予約状態にあり、実際の決済フローには使われていなかった。

x402のやりとりは単純だ。クライアントが支払い必須のリソースをリクエストすると、サーバーは402 Payment Requiredとともに価格、受け入れ可能な通貨、支払い先を含む小さなペイロードを返す。クライアントは支払いを実行し、支払い証明を添えてリクエストを再送する。ファシリテーター(検証者)が証明を確認し、オリジンサーバーが最終的にリソースを返す。すべてが通常のHTTPリクエスト/レスポンスの中で完了し、決済ページへのリダイレクトも個別の決済API呼び出しも発生しない。

STEP 1 AIエージェント がリソースをリクエスト
STEP 2 APIサーバー が 402 Payment Required と価格を返す
STEP 3 エージェントが ブロックチェーン で支払いを実行
STEP 4 支払い証明付きで再リクエスト → リソース取得
AIエージェント = 利用者  APIサーバー = 提供者  ブロックチェーン = 決済基盤

x402の利点は2つある。1つは最小単位がセント未満まで刻めること。プロトコルのオーバーヘッドが極めて低く、取引額が支払いコストを下回る逆転を防げる。もう1つは、買い手が売り手のアカウントを事前に取得する必要がないことだ。支払い自体が資格情報として機能するため、サインアップやAPIキー発行なしに取引が成立する。

サブセント決済と一瞬の決済

ステーブルコインを使う決済は、現在の主要な決済レールでは実現できなかったスピードと低コストを両立する。Cloudflareはサブセカンド(1秒未満)の決済を目標に掲げている。エージェントが数セントのデータを購入するために数ドルの手数料と数日の決済期間を待つ必要はなくなる。この速度と低コストが、AI時代の大量のマイクロペイメントを支える。

Monetization Gatewayの機能

Monetization Gatewayの機能

Monetization GatewayはCloudflareのエッジネットワーク上で動作し、330以上の都市でリクエストを処理する。x402ハンドシェイクが買い手の近くで実行されるため、レイテンシが小さくなり、オリジンサーバーへの負荷も軽減される。

具体的な課金ルールの適用方法として、以下のような機能が計画されている。

  • 特定のRESTメソッドへの課金。/api/premium/* へのGETやPOSTに0.01ドルを設定できる
  • タスクの複雑さに応じた変動価格。画像生成などの処理負荷に応じて最大2ドルまでの課金が可能
  • 認証されていない発信者への402 Payment Requiredの返却。オリジンが401を返した際に、自動で402と価格情報に置き換える

ルールはCloudflareのダッシュボードから設定するほか、Cloudflare APIやTerraformを通じてコードとして管理できる。課金エンドポイントの追加が、単なる別のインフラ設定として扱えるようになる設計だ。

Cloudflareはまた、Web Bot Authとの連携も予定している。エージェントに認証を求め、既存のアカウントに対して従量課金を適用する柔軟性を提供する方針だ。これにより、完全な匿名取引だけでなく、信頼関係に基づく課金も選択できるようになる。

ルール定義
サイト運営者 ダッシュボード / API / Terraform で設定
エッジで検証
Monetization Gateway 支払いを確認しオリジンを保護
決済完了
ステーブルコイン 売り手のウォレットに直接入金
運営者 = ルール設定  Gateway = 検証  決済 = 即時着金

売り手にとっての変化

Monetization Gatewayを利用する売り手は、蓄積したステーブルコインをそのまま別の取引に使うことも、銀行口座で法定通貨に換金することもできる。Cloudflareが発表した構想では、支払い検証はすべてエッジで完結し、オリジンには課金ルールと実際の収益だけが残る。

これはAPIプロバイダーにとって、販売可能市場を拡大する直接的な手段になる。AIエージェントはリソースを要求し、価格を提示され、支払い、結果を得る。サインアップもAPIキーも事前の関係も必要ない。Cloudflareは、いつでも買い手の認証や既存アカウントとの紐付けを追加できる柔軟性を残している。

この記事のポイント

  • CloudflareがHTTP 402を利用した従量課金プロトコルx402を実用化。Monetization Gatewayによりあらゆるウェブリソースへの課金が可能に
  • AIエージェントが大量にコンテンツを消費する時代、広告に依存しない収益モデルとしてマイクロペイメントが鍵を握る
  • ステーブルコインによるサブセカンド決済で、サブセント単位の取引でも手数料が収益を上回らない
  • 課金ルールはコードで管理でき、売り手は買い手のオンボーディングや請求システムを構築する必要がない
  • Web Bot Authとの連携や変動価格設定など、エージェント経済向けの拡張機能が計画されている
Prisma Compute vs Vercel、料金比較でわかるコスト差の全容

Prisma Compute vs Vercel、料金比較でわかるコスト差の全容

TypeScriptアプリのホスティング先を選ぶとき、Prisma ComputeとVercelが候補に挙がる。両者とも従量課金でゼロスケールするため、アイドル時のコストはかからない。だが料金単価と課金項目の設計思想が異なり、同じ負荷でも請求額に2倍以上の開きが出るケースがある。Prisma Computeはパブリックベータ中で現在無料、ここで示す料金は将来の本番適用が予定されている参考値だ。

本記事ではPrisma Blogが2026年7月1日に公開した料金比較をもとに、各メーターの単価差、20Mリクエストの実ワークロード試算、そしてなぜ同じ負荷で請求が変わるのかを掘り下げる。Vercelの価格にまつわる開発者の声も紹介し、自社のアプリに当てはめるときの判断材料を提供する。

料金体系の基本比較

料金体系の基本比較

両サービスともリクエスト数、メモリ消費、CPU時間、外向き帯域を課金対象とするが、単価には明確な差がある。Prisma Computeの価格はベータ版後の予定値であり、変更の可能性がある点に注意が必要だ。

リクエスト単価(100万回あたり)
Prisma Compute $1.00 vs Vercel Pro $0.60
Vercelが約40%安い
メモリ単価(GB時間あたり)
Prisma Compute $0.006 vs Vercel Pro $0.0106
Prismaが約43%安い
CPU単価(vCPU時間あたり)
Prisma Compute $0.064 vs Vercel Pro $0.128
Prismaが半額
外向き帯域単価(GBあたり)
Prisma Compute $0.025 vs Vercel Pro $0.15
Prismaが1/6の価格
エッジリクエストとシート料金(ワークフロー)
Prisma Compute 無料 vs Vercel Pro エッジ $2.00/100万, シート $20/ユーザー/月
Prismaは開発者数やエッジ呼出に課金しない
Prisma Compute(予定価格)  Vercel Pro  Prismaが有利  Vercelが有利

リクエスト単価ではVercelが優位だが、サーバーワークの大半を占めるメモリとCPU、そして帯域ではPrisma Computeが大幅に低い単価を提示している。さらに開発者シートやエッジリクエストといったワークフローコストがPrismaには存在しない点が、後々の請求に大きく響く。

実ワークロードでのコスト試算

実ワークロードでのコスト試算

月間2000万リクエスト、常時2GBメモリ使用、実CPU 300vCPU時間、外向きトラフィック2TB、開発者1名という条件で両者を比較する。Vercel Proには1TBの帯域無料枠が含まれる点を織り込んだ試算だ。

Prisma Compute(予定価格)
リクエスト (2000万) $20.00
メモリ (1460 GB時) $8.76
CPU (300時間) $19.20
外向き帯域 (2TB) $50.00
シート (1名) $0.00
合計 ~$98
Vercel Pro(1シート)
リクエスト (2000万) $12.00
メモリ (1460 GB時) $15.48
CPU (300時間) $38.40
外向き帯域 (2TB中1TB無料扱い) $150.00
シート (1名) $20.00
合計 ~$236
Prisma Compute ~$98  Vercel Pro ~$236  差額は約2.4倍。メモリ、CPU、帯域の単価差が総額を押し上げている。

この試算ではエッジリクエストを除外し、開発者1名で固定している。実際にはチーム人数が増えるほどVercelのシート料金が積み上がり、格差はさらに拡大する。一方で外向き帯域がごく小さく、リクエスト単価の差が支配的になるシナリオでは両者の総額は接近する。

料金差を生む構造的要因

料金差を生む構造的要因

なぜ同じ負荷でこれほどの差がつくのか。理由は課金モデルの設計思想とアーキテクチャの2軸に集約される。

ワークとワークフローの分離

ホスティング料金は「アプリが稼働中に行う実作業(ワーク)」と「デプロイやプレビューなど開発プロセス(ワークフロー)」に分けられる。Prisma Computeはリクエスト、メモリ、CPU、帯域というワークのみに課金し、開発者シートやエッジリクエストといったワークフロー項目は一切請求しない。Vercelはワークに加え、シート料金とエッジリクエストをワークフローとして課金する。

ワーク(アプリ稼働)
リクエスト / メモリ / CPU / 帯域
Prisma Compute 課金
Vercel 課金
ワークフロー(開発プロセス)
開発者シート / エッジリクエスト / デプロイ / プレビュー
Prisma Compute 無料
Vercel 課金
Prisma Compute  Vercel  差が生まれるのはワークフロー部分。特にシート料金は人数比例で拡大する。

Prisma Blogの著者Martin Janse van Rensburg氏は、AIエージェントがコードの変更→テスト→プレビューを繰り返す開発スタイルでは、Vercelのワークフロー課金が急速に膨らむリスクを指摘している。一方PrismaではデプロイのたびにイミュータブルなバージョンとプレビューURLが作られるが、それらに追加料金は発生しない。

データベース隣接配置によるエグレス抑制

Prisma Computeのアーキテクチャ上の特徴として、Prisma Postgresと同じインフラ上で動作する点が挙げられる。通常、アプリケーションサーバーとデータベースが別ベンダーや別リージョンにある場合、両者間の通信が外向き帯域として課金対象になる。Prisma Computeはデータベースとの通信が同一基盤内で完結するため、こうした隠れエグレスコストが発生しない。

一般的な構成(Before)
アプリ (Vercel等)ネットワーク越しDB (Supabase等)
アプリ-DB間通信が外向き帯域として課金
Prisma Compute(After)
アプリ (Prisma Compute) Prisma Postgres
同一基盤内で通信が完結。エグレスコストなし

データベースとの通信量が多いアプリほど、この差は請求額に明確に現れる。大量のクエリを発行するAPIサーバーなどでは、Vercel+外部DB構成のエグレス費用が無視できなくなる。

開発者の声と注意点

開発者の声と注意点

VercelのFluid Computeは適合するワークロードでは大幅な削減効果を発揮する。リンク短縮サービスdub.coの創業者Steven Tey氏は、Xで「Vercelの利用タブが壊れたのかと思った」と述べ、Fluid有効化後に請求が50%減少したと報告している。

しかし、一部の開発者からは予想外の料金跳ね上がりに関する声も上がっている。Redditのr/nextjsスレッドでは、あるCTOがフロントエンドのみのNext.jsアプリの月額請求が「100ドル未満から800ドル超」に急増し、Cloudflare Workersへ移行後は「同じトラフィックで20ドル未満」になったと述べた。同スレッドでは「Vercelのフロントエンドは素晴らしく安いが、バックエンドは高すぎる」という見方や、Deployment Protection Exceptionsで150ドル請求された事例も共有されている。

好例
dub.coのSteven Tey氏
Fluid Computeを有効化 → 請求が50%減少
注意例
匿名CTO(Reddit)
フロントエンドのみのNext.jsアプリ → 月$100未満→$800超に急増
Cloudflare Workers移行後 → 同トラフィックで$20未満
開発者の不満は料金そのものより、請求の中身がワークフローの進行後に初めて可視化される点に集中している。

Prisma Computeはパブリックベータの段階であり、実際の課金が始まっていないため、利用者からの本格的なフィードバックはまだない。Prisma Blogの著者は、フィードバックが集まり次第、この比較記事を更新する意向を示している。

この記事のポイント

  • Vercelはリクエスト単価で優位だが、メモリ、CPU、帯域ではPrisma Computeが大幅に安い予定価格を提示している
  • 月間2000万リクエストの試算ではPrisma Computeが約98ドル、Vercel Proが約236ドルと2.4倍の開きがあった
  • 請求差の主因はワークフロー課金(シート料金、エッジリクエスト)とデータベース隣接によるエグレス抑制
  • VercelのFluid Computeは適切なワークロードで削減効果を発揮する一方、トラフィックに比例しない請求急増の事例も報告されている
  • Prisma Computeはまだベータ版であり、本番利用のフィードバックを踏まえた判断が今後必要になる