CloudflareのMonetization Gateway | Googleより「決済のVisa」に近い理由

未分類

CloudflareのMonetization Gateway | Googleより「決済のVisa」に近い理由

X(Twitter)で、Cloudflareが発表したMonetization Gatewayについて「Googleが検索の時代の王者だったように、Cloudflareが次の王者になるかもしれない」という見立てを見かけた。面白い着眼点だと思う一方、比喩の精度は確かめておく価値がありそうだったので、技術のしくみと戦略上の位置づけを整理する。

結論を先に書く。Monetization Gatewayが握ろうとしているのは「検索の関所」ではなく「決済の関所」であり、比喩としてはGoogleよりVisaやMastercardに近い。技術的には、HTTPのステータスコード402(Payment Required)を実際に使い倒し、1回のリクエスト往復の中でステーブルコイン決済まで完結させる設計になっている。ただし、この決済レールを狙っているのはCloudflareだけではない。StripeもGoogleもカード会社も同じ場所を目指しており、独占にはまだ遠い。

何が起きたか

これまでのWebのビジネスモデルは「コンテンツと引き換えに人間の注意を獲得する」ことで成り立っていた。広告を見せる、会員登録させる、月額課金する。どれも「見るのは人間」が前提にある。

しかしAIエージェントは広告を見ないし、会員登録も面倒がらないうえに、人間の何百倍・何千倍というリクエストを送ってくる。Cloudflareはこの変化を「AIクローラーが主要な訪問者になる未来」と位置づけ、2025年の「AIクローラーへの課金機能」の延長線上に、今回のMonetization Gatewayを置いている。

できることは、ダッシュボードまたはAPIで設定する柔軟な課金ルールだ。

  • 特定のルートへの GET / POST リクエストに0.01ドルを課金する
  • 画像生成タスクの複雑度に応じて価格を段階的に変える
  • 認証していないユーザーだけに課金する(HTTP 401を402に読み替える)

対象はCloudflareの既存顧客全般だ。Webページの提供者・データセットの所有者・API開発者・MCPツール開発者が、AIエージェントによるアクセスから収益を得られるようにするのが狙いである。

Cloudflareは買い手であるAIエージェントと売り手であるオリジンサーバーの間に立つエッジという位置にあり、そこで決済を検証する。検索の入口ではなく決済の通り道を握っている
図1: Cloudflareが握るのは検索ではなく「決済の通り道」。買い手と売り手の間に立つエッジで、決済を検証してから通す。

Cloudflareは元々、Webサイト運営者がbot対策やCDNのために経由させている「逆プロキシ」であり、買い手(AIエージェント)と売り手(オリジンサーバー)の間に立つ立場にある。今回の発表は、この立地を決済の検証点として転用したものだと見るとわかりやすい。

技術のしくみ — 支払いは1回のHTTP往復の中で完結する

x402というプロトコルに基づいており、新しいのはステップの一部だけだ。全体は次の8ステップで進む。

x402プロトコルのシーケンス図。AIエージェントが通常のリクエストを送ると402 Payment Requiredが返り、ステーブルコインで支払いに署名して証明を添えて再送し、Cloudflareエッジがその場で検証してからオリジンサーバーへ転送し、レスポンスが返る8ステップを、支払う側・検証する層・コンテンツを持つ側の3列で示す。決済に関わる②から⑤だけがマゼンタで強調されている
図2: 新しいのは②〜⑤だけ。①⑥⑦⑧はふつうのHTTPの意味論のまま。

順に説明する。

  1. クライアント(AIエージェント)が、いつも通りのGETリクエストを送る。
  2. サーバー(Cloudflareエッジ)が、通常の200 OKの代わりに402 Payment Requiredと価格情報を返す。
  3. クライアントが、手元のステーブルコイン(USDCなど)で支払いに署名する。ここはクライアント側で完結する処理で、チェックアウトページも人の操作も要らない。
  4. クライアントが、支払い証明を添えて同じリクエストを再送する。
  5. Cloudflareのエッジが、その場で支払い証明を検証する。オリジンサーバーまで問い合わせに行く必要はない。
  6. 検証済みのリクエストだけが、オリジンサーバーへ転送される。
  7. オリジンサーバーが、通常通りレスポンスを返す。
  8. エッジがクライアントにコンテンツを返却する。ここまで1秒未満で完了する設計になっている。

ポイントは、①⑥⑦⑧が何の変哲もないHTTPのリクエスト・レスポンスだということだ。「新しい決済の仕組み」に見えて、実際に新しいのは②〜⑤の4ステップだけであり、しかもそれは既存のHTTPステータスコード(402)の意味をそのまま使っている。特別なAPI呼び出しも、専用のSDKも要らない。

なぜ今まで「1円未満の決済」は無理だったのか

マイクロペイメント(1セント未満の取引)は、これまで実装できなかった。理由は単純で、支払い処理のコスト(クレジットカードの決済手数料には固定費部分がある)が、商品価値そのものを上回ってしまうからだ。1円の記事を売るのに、決済処理だけで数円かかっては商売にならない。

x402は、ステーブルコインでの直接決済とエッジでの即時検証を組み合わせることで、この固定費構造を回避している。カード会社を経由しない分、極小額の取引でも採算が合う設計になっている。AIエージェントが1回のアクセスごとに0.01ドルを払う、という商売が初めて成立し得る。

比喩の検証 — GoogleよりVisa/Mastercardに近い

ここで、冒頭の「次のGoogleになるのでは」という見立てを検証しておきたい。

GoogleとCloudflareの比較図。握っているものは検索窓という入口とトラフィックの通り道、強さの源泉は需要側ネットワーク効果と供給側の導入シェア、独占の性質は消費者が能動的に選ぶ入口と運営者が気づかず依存する通り道という違いを示す。比喩はGoogleよりVisa・Mastercardに近い
図3: 検索は消費者が選ぶ入口、決済レールは供給側が気づかず通す土管。

Googleが検索を独占できたのは、ユーザーが自分の意思で「Googleを使う」と選び続けたからだ。みんなが使うから使われる、という需要側のネットワーク効果が源泉になっている。

一方でCloudflareが握っているのは、Webサイト運営者がbot対策やCDNのために「気づけばすでに経由させている」通り道だ。ユーザーが積極的に選ぶ入口ではなく、供給側がすでに依存している土管である。この構造は、検索エンジンよりもクレジットカードの決済網に近い。VisaやMastercardも、消費者が意識的に選んでいるわけではないが、店舗側の決済インフラとして深く食い込んでいる。

つまり「王者になる可能性」を評価するなら、x402という技術そのものの独自性ではなく、「決済レールとしてどこまで導入シェアを取れるか」を追うのが筋が良い読み方になる。

まだ独占ではない — 4陣営が同じレールを狙っている

そしてこのレール争いは、Cloudflareの独走ではない。

エージェント決済のレールを狙う4陣営の一覧図。Cloudflareのx402、StripeとOpenAIのACP、GoogleのAP2、Visa・Mastercardのトークン化が並行して走っており、x402はオープン規格のためCloudflareの独走ではないことを示す
図4: x402はオープン規格。独走ではなくレール争いの最中。

x402プロトコル自体はオープン規格で、Cloudflare固有の技術ではない。StripeはOpenAIとACP(Agentic Commerce Protocol)を推進し、GoogleはAP2(Agent Payments Protocol)を提唱している。VisaやMastercardも、エージェント向けのトークン化を進めている。

Cloudflareの優位は、プロトコルの独自性ではなく「導入の手軽さ」にある。すでにCloudflareを経由させているサイト運営者が、ダッシュボードで即座に価格ルールを設定できる。この「導入コストの低さ」は確かに強みだが、決済レールの主導権争いはまだ始まったばかりだと見ておくべきだ。

まとめ

Monetization Gatewayの面白さは、2つの異なる話が混ざっているところにある。ひとつは、HTTP 402というステータスコードを本当に実装で使い倒したという技術的な面白さ。もうひとつは、Cloudflareが「土管の立地」を収益化に転用する構造的な面白さだ。

「王者になる可能性」を評価するなら見るべきは以下の点になる。

  • x402の技術的な独自性ではなく、Stripe・Google・カード会社との導入シェア争い
  • AIエージェントが実際にどれだけの決済ボリュームを生むか(現時点ではまだ仮説段階の需要)
  • ステーブルコイン決済への依存度と、それに伴う規制環境の変化

「検索の関所」を探すのではなく、「決済の関所」を誰が最初に押さえるかという、まだ勝敗の見えていないレースとして見ておくのが実態に近い。