Cloudflareが自動課金ゲートウェイを発表：AIがあなたのウェブページやAPIをクロールしたら、自動でお金を払ってくれる

人間とAIクローラー、実際にコンテンツを消費しているのはどちらか

30年間、ウェブはシンプルな交換で回ってきた——コンテンツで人の注意（アテンション）を得て、それを広告・サブスク・ECでマネタイズする。しかしAIエージェントがウェブの主な訪問者になったとき、この交換は成り立たなくなり始めた。エージェントは広告を見ないし、使いたいツールごとに月額サブスクに入るわけでもない。ページやデータソースを一度読んで、必要なものを取っていくだけで、去っていく。

Cloudflare独自のデータによれば、ウェブ全体を見ると、AIクローラーがあるサイトに1人の人間の訪問者を連れてくるたびに、実際のコンテンツ取得回数は100回から数万回に及ぶという。アテンション課金という旧モデルは、こうした一度きりで蓄積しないアクセスの前ではもはや成り立たない。課金の単位を「月」「シート」から「1リクエスト」「1トークン」「1結果」へと変える必要がある。

従量課金は、なぜこれまで実現できなかったのか

従量課金というアイデア自体は昔からあったが、実装は常に2つの現実的な壁にぶつかってきた。

クラウドサービスやAPIは以前から従量・時間単位で売られてきたが、それは常に「既知の買い手」向けだった：ユーザーがまず登録し、APIキーを受け取り、利用量に応じて課金される。コンテンツの大半は課金をスキップし、広告で運営されてきた。見知らぬ呼び出し元への少額課金には、これまで適したチャネルがなかった。

1回のHTTPリクエストの中で、支払いはどう完結するのか

「従量課金」をついに実現可能にしたコアは、x402というオープンプロトコルだ。支払いを普通のウェブリクエストに直接組み込み、全体を1回のHTTPリクエストとレスポンスの中で完結させる。

具体例で見てみよう：航空券を予約してくれるカスタマーサービスAIエージェントがいて、あるサイトの「フライトのリアルタイム遅延」データを照会したいとする。このデータは1回照会するごとに1セントの従量課金だ。エージェントとこのサイトの間では、たった1回の普通のウェブリクエストで「データ照会」と「支払い」の両方が完結する：

① エージェントがリクエストを発行
GET /flight-delay?flight=CA981 HTTP/1.1

② サイトが支払いを要求し、見積もりを添付
HTTP/1.1 402 Payment Required
{
  "price":  "0.01",
  "asset":  "USDC",
  "payTo":  "0x…（サイトのウォレットアドレス）"
}

③ エージェントが支払い後、証明を添えて再送
GET /flight-delay?flight=CA981 HTTP/1.1
X-Payment: <PAYMENT_PROOF>

④ facilitatorの検証が通り、データを返す
HTTP/1.1 200 OK
{"flight": "CA981", "delay_minutes": 40}

ここで見慣れない役割が2つ登場するので、それぞれ説明しておく。1つ目はfacilitator（支払い検証者）：x402のプロセスにおいて「この支払いが確かに行われた」ことを仲介検証する第三者。買い手が支払った後、証明が有効かどうかをこの役割がチェックし、検証が通って初めてサーバーがリソースを渡す。facilitator自身はこのお金を扱うわけではない。

2つ目はピアツーピア決済（peer-to-peer settlement）：買い手が支払ったお金は直接売り手自身のウォレットに入り、銀行やプラットフォームの口座といった中継・バッチ清算の工程を経ない。だからほぼリアルタイムでの着金が可能になる。Cloudflareはこの仕組みの目標を「1秒未満での決済」としている。

x402プロトコル公式のシーケンス図。出典：x402プロトコルのGitHubリポジトリ（coinbase/x402）。上記の4ステップの説明よりさらに一段細かい：facilitatorがサーバーに対して行うのは実は2回の独立した呼び出しで、まず支払いの署名が有効かどうかを「検証」（verify）し、サーバーが処理を終えた後に「決済」（settle）を行う——このステップで初めて取引が実際にブロックチェーンに提出され、オンチェーンでの確定を待つ。

Monetization Gatewayでは具体的にどんな課金ルールを設定できるのか

プロダクトのレベルに落とし込むと、Monetization Gatewayは柔軟な課金ルールのインターフェースを提供し、どのトラフィックに課金が必要かを正確に指定できる。ルールの書き方はCloudflareの他のルールを設定するときの記法と似ていて、ダッシュボード上でクリックして設定することも、API経由で行うことも、Terraform（設定をコードとして管理するツール）で行うこともできる——1つの有料エンドポイントがインフラ設定の一部になる、というわけだ。公式は3つの想定機能例を挙げている。

このゲートウェイの着地点は、課金と支払い検証をオリジンサーバーからCloudflareのエッジへと移すことにある。

なぜ他でもなくステーブルコインが主役を担うのか

課金単位は数セント、時には数厘にまで小さくなり、従来の決済レールでは割に合わない。ステーブルコインはここを補う存在だ。

ステーブルコイン（Open USD、USDCなど）はネット上でごく少額の送金ができ、手数料はほぼゼロ、決済も1秒以内で完結する——これは従来の決済レールが今日実現できていないことだ。x402自体は決済レールに依存せず、ステーブルコインと自然に相性がよく、チャージバック（支払い後の取り消し）も発生しない。

もう1点はっきりさせておきたい：x402はオープンプロトコルであり、Cloudflareが25社以上の業界パートナーとともに、x402 Foundation（Linux Foundation傘下）を通じて共同開発しているものだ。GitHub上の最初のリファレンス実装はCoinbaseによるものである。Cloudflare一社の独自プロトコルではない。

開発者やクリエイターにとって、実際に何が節約でき、何が稼げるようになるのか

これまでの機構と決済方式を、1つの問いに落とし込んでみよう——これを使うと、実際に何が得られるのか。原文によれば、主に次の3点だ。

• サービス提供者（ウェブサイト、API、MCPサービス）は自前で課金・決済システムを構築する必要がなく、Cloudflare上でルールと価格を設定するだけでよい。収益はステーブルコインの形でそのままウォレットに入り、自由に取引したり法定通貨に換えたりできる。
• 呼び出し元（AIエージェントを含む）は事前のアカウント登録もAPIキーの取得も不要で、支払い自体がアクセス証明になる。これまで金額が小さすぎて従来の決済チャネルでは割に合わず見送られてきた呼び出し（たとえば1回数セント）にも向いている。
• クリエイターや小規模なAPI提供者にとって新しい課金チャネルが生まれ、これまでほとんど誰も対価を払わなかった呼び出しに自動で課金できるようになる。さらにWeb Bot Auth（「このアクセス者は本当に名乗っているそのAIか」をCloudflareが検証する仕組み）と組み合わせれば、課金と同時に呼び出し元の身元確認もできる。

今すぐ使えるのか

念のため断っておくと、Monetization Gatewayは現時点で候補リスト（waitlist）の受付段階にあり、既存のCloudflare顧客向けに申し込みを受け付けている。

原文は一貫して「will」（will give / will provide / will scaleなど）という表現で機能を説明しており、これらの機能はまだ構築・展開の途上にあって、すでに全面公開された成熟プロダクトではなく、公開の価格ページもない。自分のウェブページ、データセット、API、あるいはMCPツールに従量課金したい顧客は、まず早期アクセスのリストに参加できる。

この仕組みが広がっていけば、インターネットのお金はどう流れるのか

現在の段階や目先のメリットはひとまず脇に置いて、Cloudflareはもっと大きな構想を描いている。

エージェントはユーザーに代わって自律的に行動するソフトウェアであり、人の手を介さずにウォレットを持ってネットに出て、データセット・API呼び出し・ツール・計算リソースに対価を払い始めている。無料のリソースもあれば、まず「あなたは誰か」（身元）の検証が必要なもの、両方が必要なものもある。Cloudflareは自らを、1回のリクエストの中で身元検証（Web Bot Authと組み合わせ可能）と支払い検証の両方を完結させ、そのままオリジンサーバーへ通す——リクエストそのものを1つの取引にする——数少ないインフラの1つとして位置づけている。