Cloudflare が HTTP 402 で AI エージェントに課金する Monetization Gateway をクローズドベータ公開

要約

Cloudflare は 2026-09-30、AI エージェントに対して Web サイト・API・MCP ツール・データセットへのアクセスを有償提供できる Monetization Gateway をクローズドベータで公開しました。Birthday Week 2026 の発表群の1つです。

仕組みの中心は HTTP 402 Payment Required です。

402 は HTTP の仕様に最初から存在しながら、長く使われてこなかったステータスコードです。 「支払いが必要」を意味しますが、人間向けの決済は画面遷移を伴うため、402 を返すより決済ページへリダイレクトする方が実用的でした。結果として、402 は仕様書に載っているだけの番号でした。

エージェントが相手なら、話が変わります。 画面を見る必要がなく、プログラムとして応答を解釈します。402 で支払い指示をインラインで返し、エージェント側が支払いを承認し、確定後にリソースが返る——この流れが成立します。リダイレクト型のチェックアウト画面も、別建ての決済 API も不要です。

決済レールは暗号通貨です。 **Base チェーン上の USDC（ステーブルコイン）**を使い、精算は Coinbase の x402 Facilitator が担います。x402 はオープンプロトコルで、Cloudflare 独自の仕組みではありません。

価格設定の柔軟性が実務的です。 固定価格に加えて、リクエスト単位 / トークン単位 / クエリ単位の変動価格を選べます。課金ルールは URL・ヘッダー・クエリパラメータへのマッチで定義します。つまり、同じエンドポイントでもパラメータによって価格を変えることができます。

既に本番で使われている事例が4つ挙げられています。

1つ目は Cloudflare 自身の AI Gateway です。推論1回ごとの支払いに Monetization Gateway を使っています（同日発表の Machine Payments）。提供元が自社製品の課金に使っているという形です。残る3つは Ceramic.ai（Web 検索 API）、Stocktwits（株式センチメントのシグナル）、API2PDF（PDF 生成）です。

いずれも「エージェントが使いたくなる種類のサービス」である点が共通しています。 検索、データのシグナル、ファイル変換。人間が月額契約するには細かすぎるが、エージェントがその場で1回使うには価値があるという領域です。

提供範囲には明確な制限があります。 現状は米国内の売り手・買い手に限定されたクローズドベータです。他地域への拡大は予定されているとされていますが、時期は明記されていません。申請は Cloudflare Dashboard の Request access から行います。

何が変わったか

• HTTP 402 Payment Required を使い、リソース要求への応答として支払い指示をインラインで返せる
• リダイレクト型のチェックアウトや別建ての決済 API が不要
• 対象は Web サイト・API・MCP ツール・データセット
• 決済レール: Base チェーン上の USDC、精算は Coinbase の x402 Facilitator
• オープン標準 x402 に準拠（Cloudflare 独自プロトコルではない）
• 価格設定: 固定価格、およびリクエスト / トークン / クエリ単位の変動価格
• 課金ルール: URL・ヘッダー・クエリパラメータへのマッチで定義
• 本番利用事例: Cloudflare AI Gateway（推論ごとの支払い）、Ceramic.ai（Web 検索 API）、Stocktwits（株式センチメント）、API2PDF（PDF 生成）
• 提供範囲: 米国内の売り手・買い手のみのクローズドベータ。他地域は拡大予定
• 申請: Cloudflare Dashboard の Request access

業務インパクト（一般企業向け）

日本の企業にとって、現時点では「使える機能」ではなく「設計の前提が変わる予兆」として読むべき発表です。 米国限定のクローズドベータであり、今すぐ導入する話ではありません。

それでも今から考える価値があるのは、収益モデルの前提が変わるからです。

API やデータを提供している事業では、課金モデルは実質的に2択でした。 月額のサブスクリプション（プラン制）か、エンタープライズ契約です。どちらも「契約を結ぶ」という工程を前提としています。 契約には、与信、請求書、担当者、稟議が伴います。この工程のコストが、小口の利用を構造的に排除してきました。

「1回だけ使いたい」という需要に応える手段が、なかったのです。 月1,000円のプランを、年に3回しか使わない人へ売ることはできません。売っても解約されます。

エージェントが顧客になると、この制約が外れます。 エージェントは稟議を通しません。使う瞬間に支払い、終わったら去ります。 この性質に合う課金は、リクエスト単位の従量課金です。

自社のサービスで考えるべき問いは、こうです。「自社の提供物の中で、1回単位で売れるものは何か」。

具体的に言えば、社内で既に API になっているが外販していないものが候補です。住所の正規化、業界固有のデータ変換、独自の計算ロジック、社内で整備した参照データ。これらを月額プランで売るには需要が細すぎるが、1回数円で売るなら成立する可能性があります。

MCP ツールという形での提供も、同じ枠に入ります。 公式は課金対象に MCP ツールを明記しています。自社のナレッジや業務ロジックを MCP サーバーとして公開し、エージェント経由の利用に課金する——この構成が商売として成立する経路ができた、ということです。

一方で、現実的な障壁を正確に把握しておく必要があります。

最大の障壁は決済レールです。 Base チェーン上の USDC による決済は、日本の多くの企業にとって会計・税務・コンプライアンスの観点で即時には採用できません。 暗号資産の受領は、その取り扱い規程を社内に持っていない組織では、技術的な可否より先に止まります。

x402 がオープン標準である点は、ここで希望になります。 プロトコルが標準であれば、将来的に他の決済手段（従来のカード決済、銀行振込ベースの精算）を扱う実装が出る余地があります。 現時点で暗号資産しか選べないのは、Cloudflare の実装の都合であって、プロトコルの制約ではありません。

2つ目の障壁は、買い手側の存在です。 課金の仕組みがあっても、支払う意思と手段を持ったエージェントが来なければ収益になりません。 現状はクローズドベータで、買い手も米国限定です。「収益化できる」と「収益が出る」の間には距離があります。

今やるべきことを現実的に挙げます。 (1) 自社の提供物のうち、1回単位で価値が計れるものを棚卸しする。 (2) それらが現在どう提供されているか（API か、人手か、提供していないか）を確認する。 (3) 暗号資産を受領できるかを、経理・法務へ事前に確認しておく。

3番目が実は最も時間がかかります。 技術的な実装は数日で終わりますが、社内の決済・会計規程の変更は数か月かかります。 日本へ提供範囲が広がったときに動けるかどうかは、この確認を済ませているかで決まります。

逆方向の論点も忘れないでください。自社が買い手になる側の話です。

自社でエージェントを運用している場合、エージェントが外部の有料 API を 402 経由で買い始める可能性があります。 これは支出管理の問題です。「エージェントがいくら使ったか」を把握し、上限をかける仕組みがなければ、予算が制御できません。 Monetization Gateway の発表は売り手側の話ですが、買い手側の統制設計を先に用意しておく必要があります。

副業・個人活用視点

個人にとって、この発表は「小さく売る」という選択肢の話です。

個人開発者が API やツールを収益化しようとすると、決済の実装が最初の壁でした。 Stripe を入れ、プラン設計をし、請求とキャンセルを扱い、サブスクリプションの状態管理を書く。「月額500円のツール」を売るために、この一式を作るのは明らかに割に合いません。

402 ベースの従量課金は、この構造を変える可能性があります。 支払いがリクエストへの応答として完結するため、契約状態の管理が不要です。 顧客テーブルも、プラン管理も、解約フローもありません。使われた回数だけ入金されるという形です。

何を売るか。考え方を具体的に書きます。

狙うべきは「人間には月額で売れないが、エージェントには1回で売れるもの」です。

例を挙げます。特定業界の専門用語の正規化辞書。 人間が月額で買うほどの頻度では使いませんが、エージェントが文書処理のたびに1回引くなら成立します。ニッチな形式のファイル変換。 月に数回しか必要ないが、必要なときには確実に欲しい。自分が整備した参照データ。 公的データを使いやすく加工したもの、業界慣行をまとめたもの。

共通するのは、「深さは不要だが、代替が面倒」という性質です。 エージェントは「自分で実装するか、買うか」を判断します。実装が面倒で、価格が十分に安ければ、買う方が選ばれます。

MCP サーバーという提供形態が、ここで効いてきます。

MCP サーバーとして公開すると、エージェントから直接使える状態になります。 公式が課金対象に MCP ツールを含めているため、MCP サーバー + 402 課金という組み合わせが、個人が作れる最小の商売の形になります。サーバー1つ、ロジック1つ、価格1つ。これだけで売れる構成です。

ただし、期待値は正しく置いてください。

1回あたりの単価は小さくなります。 エージェントが「買う」と判断する水準は、自分で実装するより安い価格です。数円から数十円のレンジが現実的です。 ここから意味のある収入を得るには、回数が必要です。 個人が作ったニッチなツールに、月に何万回のリクエストが来るかは、楽観してはいけません。

それでも試す価値がある理由は3つあります。

1つ目は、初期投資が小さいこと。 決済実装が不要なら、作るのはロジックだけです。失敗しても失うのは作業時間だけです。

2つ目は、作ったものが残ること。 MCP サーバーとして公開したものは、課金が成立しなくても自分のポートフォリオになります。 「エージェント向けの有料ツールを作って運用している」という実績は、受託の提案で効きます。

3つ目が最も大きい。この領域の実務経験を持つ人が、まだほとんどいないことです。

「エージェントに課金する設計」を実際にやったことがある人は、2026年10月時点で極めて少数です。 日本では、米国限定という制約もあって、ほぼいません。ここで先に手を動かしておくと、企業がこの課題に直面したときに相談される側に立てます。

現実的な制約を2つ、明確に書きます。

1つ目。現状は米国内の売り手・買い手限定です。 日本在住の個人が売り手として参加できるかは、公式には書かれていません。「米国内の売り手」という条件は、法人所在地か、決済アカウントの所在かが不明です。 申請してみる以外に確認する方法がありません。

2つ目。暗号資産での受領です。 USDC の受領は、個人の確定申告で雑所得または事業所得として扱い、受領時のレートで円換算する必要があります。取引記録を自分で管理する手間が発生します。 少額の入金が大量に発生する形態では、この記録管理が実務上の負担になります。始める前に、記録の取り方を決めておいてください。 後から1年分をまとめて整理するのは、現実的ではありません。