HTTP 402が30年ぶりに動き出した——Cloudflare x402プロトコルがAPIマネタイズの設計を変える理由

こんにちは。

もるふぉです。

先週、CloudflareがMonetization Gatewayの待機リストを公開しました。

x402プロトコルというオープン規格が、AIエージェント時代のAPIマネタイズを根本から変える、と話題になっています。

ただ本質はもっとシンプルで、約30年間RFCに眠っていたHTTP 402が、ようやく実装された、という話です。

HTTP 402は約30年間なぜ放置されていたのか

Payment Requiredは1997年、HTTP/1.1の初期仕様(RFC 2068)にすでに書かれていました。

「支払いが必要なコンテンツ」を示すためのステータスコードです。

書かれていたのに、約30年間、事実上どのブラウザもどのサーバも使ってこなかった。

理由はシンプルで、当時のインターネットに「リクエスト単位で決済できるインフラ」が存在しなかったからです。

クレジットカードは1回の決済に数秒と数十円の手数料がかかる。

1リクエスト0.01円の課金には桁が合いません。

HTTPプロトコル側にステータスコードは用意してあっても、その先の決済経路が空白のまま放置されていた、という構図です。

この空白を埋めたのがステーブルコインを軸にした分散決済網でした。

1秒未満で決済が完了し、手数料はほぼゼロになる経路がここ数年で立ち上がってきた。

HTTP 402の下に敷ける決済レイヤーがようやく揃った、という順番です。

x402プロトコルの仕組み——リクエスト1本の中で課金が完結する

クライアントがGETを打つと、サーバは402 Payment Requiredと一緒に「このリソースはいくら、この経路で払え」という情報を返します。

クライアントは指定された経路で支払いを実行し、支払い証明ヘッダーを付けて同じリクエストを再送する。

サーバ側ではfacilitatorと呼ばれる検証層が支払い証明を確認し、問題なければオリジンに通してリソースを返す。

決済アセットはUSDCやOpen USDといったステーブルコインで、1秒未満で決済が終わり、手数料はほぼゼロです。

面白いのはCloudflareのfacilitatorがエッジで動く点です。

オリジンサーバに到達する前に検証も実行も終わっている。

オリジン側のアプリケーションから見ると「認証済みで支払い済みのリクエストしか届かない」状態になります。

既存のCloudflare Workersと同じ「エッジで前処理を吸収する」思想を、そのまま課金に持ち込んだ形です。

Web3の知識がなくても、HTTPの仕様として理解できる。

実装する側にとってはここが一番効いてきます。

Cloudflare Monetization Gatewayが追加するもの

x402プロトコル単体は、ただの規格です。

それをCloudflare配下の任意のリソースにルール1つで適用できるようにしたのがMonetization Gatewayです。

Cloudflare公式ブログによると、対象はWebページ、REST API、データセット、MCPツールまで含みます。

価格ルールの柔軟さがこの発表の肝です。

RESTの動詞ごとに単価を変えられる(たとえば/api/premium/*へのGETとPOSTに一律$0.01を設定できる)、画像生成のような計算量が読めない処理は最大$2までの可変料金にできる、認証済みユーザーには課金せず未認証だけ課金する、といった条件が組める。

成功時のみの課金モードにも対応できるため、失敗時に返金処理を自前で書く必要もありません。

そしてこれらの価格ルールは、DashboardだけでなくAPIでも、Terraformでも管理できます。

Terraformでコード化できる、というのが個人的には一番大きい変化だと思っています。

インフラのコードとビジネスロジックのコードの境界がここでずれる。

今まで「請求周りは業務システム側の仕事」と思っていた領域が、インフラ側の宣言的な設定に降りてきます。

業務APIの設計視点から見ると何が変わるか

業務APIで従量課金を実装しようとすると、少なくとも次の3つを自前で書きます。

1つ目にAPIキーの発行と管理、2つ目にレートリミットと利用量のカウント、3つ目に月次の集計と請求処理。

これらを一通り作ると、コア機能と同じくらいのボリュームになります。

x402が省略するのはこの3つほぼ全部です。

APIキー配布は不要、契約プランと利用者のマッピングも不要、月次集計も請求書生成もいらない。

リクエストごとに検証と決済が完了しているので、後工程がそもそも発生しません。

もう1つの視点は、呼び出す側がAIエージェントになる前提です。

従来のAPI設計は「呼び出す人間が事前に契約を結び、キーを受け取り、コードに埋め込む」流れでした。

呼び出し元をAIエージェントに置き換えた瞬間、この前提は成立しません。

エージェントは事前登録なしにその場で判断してAPIを叩きたい。

x402はここに直接対応します。

呼び出し側にとっては「ウォレットの上限をどう管理するか」「どのAPIまでは自動決済していいか」という別の設計問題が出てきますが、それはエージェント側の責任範囲として整理できます。

サーバ側の設計者は「支払い済みリクエストだけを見る」ところに立てるので、責任分界点がクリアになります。

今の段階でエンジニアがやっておくこと

まず待機リストに登録しておくと、正式提供時にすぐ手を動かせます。

並行してやっておきたいのは、自社のAPIごとに「1リクエストあたりの原価」を出せるようにしておくこと。

ここが出せないと価格ルールそのものが書けません。

Terraformで管理しているインフラなら、価格ルール用のディレクトリを先に切っておく。

正式提供が来てから価格を考え始めるとどうしても後手に回るので、「どこに書くか」だけでも決まっていると、後の意思決定の速度が明らかに違います。