AIエージェントにAPIを課金する方法 — HTTP 402とx402プロトコルの実装まとめ

エージェントが「顧客」になる時代、既存の課金モデルは崩れる

インターネット上のトラフィックの主体が、人間からエージェントへと移りつつあります。しかし、エージェントは私たちが知っている方法ではお金を使いません。

従来のSaaSの課金はこうです。

• 月額サブスクリプション、またはプリペイドクレジット
• 購入者がアカウントを作成し、カードを登録
• 最小決済単位は数ドル〜数十ドル

一方、エージェントは違います。ある問いを解決するために、一度検索し、一度APIを呼び、一度データを取得します。結果が不十分なら別のサイトへ移動します。「とりあえず年間契約しておこう」という判断はしません。

つまり、課金単位はリクエスト1件、検索1回、トークン1個まで細分化される必要があります。既存のカード決済網ではこれを支えられません。承認遅延、最低決済額、本人確認がボトルネックになります。

そこで登場するのがHTTP 402です。もともと1990年代のHTTP仕様に「Payment Required」として予約されながら、誰も使っていなかったステータスコードが、30年を経て実際に機能し始めました。この流れの一次情報はCloudflare公式ブログで確認できます。

HTTP 402の決済フローをコードで確認する

仕組みはシンプルです。未払いなら402、支払い済みなら200。 リダイレクトも、別途の決済API呼び出しもありません。1つのリクエストに決済交渉がインラインで乗る構造です。

1) 支払いなしでリクエストすると402が返る

$ curl -iX POST https://v2.api2pdf.com/chrome/pdf/html \
  --header "Content-Type: application/json" \
  --data '{"html":"Hello from an AI agent"}'

HTTP/2 402
content-type: application/json
payment-required: eyJ4NDAy...   # 支払い案内ペイロード（Base64）

レスポンスヘッダの payment-required に支払い条件が格納されています。エージェントはこれをパースして署名し、再リクエストします。

2) 支払い方法を明示して呼び出すと通過する

Cloudflare AI Gatewayのように独自の課金エンジンを持つ場合、ヘッダ1行を追加するだけで済みます。

$ curl -iX POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Payment-Method: x402" \   # ← この1行がポイント
  --header "Content-Type: application/json" \
  --data '{
    "model": "z-ai/glm-4.7-flash",
    "input": {
      "max_tokens": 9001,
      "messages": [
        { "role": "user", "content": "What is Cloudflare?" }
      ]
    }
  }'

決済はCoinbaseのx402 Facilitatorを経由し、**Baseチェーン上のUSDC（ステーブルコイン）**で行われます。販売者は価格ルールを定義するだけで、決済検証・リトライ・精算・分析はゲートウェイが処理します。

3) 価格ポリシーはリクエストの任意の部分に設定可能

• Fixed pricing: リクエストあたり固定価格（例：Ceramic.aiの検索1回）
• Variable pricing: 最大コストを事前提示し、実消費分のみ精算（例：API2PDFのPDF生成）
• Origin-controlled pricing: 価格情報をオリジンから直接取得（例：AI Gatewayのトークン単位課金）

URL、ヘッダ、クエリパラメータのいずれもマッチ条件に使えるため、既存の料金体系をそのままゲートウェイに載せることも可能です。

実運用中の4事例から見る適用パターン

特にAPI2PDFの事例が実務的です。従来はアカウント作成 → APIキー発行 → 1ヶ月後にカード登録という流れで、コンバージョンが50%以上低下していました。現在はAPIキーなしでリクエストすると402を返し、決済後にPDFを返します。オンボーディングファネルを丸ごと撤去した形です。

この技術の限界と注意点

率直に言えば、まだ万能ではありません。

• 地域制限: 現在は米国拠点のセラー・バイヤー向けクローズドベータです。日本企業がすぐに使える状況ではありません。
• ステーブルコイン依存: 精算はBaseチェーンのUSDCで行われます。日本の会計・税務処理の観点では、暗号資産決済の売上計上について別途検討が必要です。
• エージェントの身元問題: 匿名エージェントにリソースを開放する構造のため、悪意ある大量呼び出しへの防御は別レイヤーで必要です。
• コンテンツとAPIの区別: ページクロールのように「一度取得して千回使う」リソースにはこのモデルは適しません。Cloudflareもこのケースでは別のPay Per Useモデルを推奨しています。

次のステップ

1. x402プロトコル仕様を直接読むことをおすすめします。HTTP 402のヘッダ規約と署名検証フローが核心です。
2. **MCP（Model Context Protocol）**サーバーに課金レイヤーを載せるパターンを試してみてください。エージェントのツール呼び出しに自然に組み込めます。
3. エージェントを作る側であれば、402レスポンスを受けた際に自動で支払い・リトライするクライアントロジックを先に習得しておくと有用です。

まとめ：「サブスク」から「消費」へ移行する決済パラダイム

要点を整理します。

• エージェントは結果単位で消費します。リクエスト1件、検索1回、トークン1個。
• 既存のカード決済網はこの単位を支えられません。だからHTTP 402 + ステーブルコインが登場しました。
• Cloudflareはこれを数クリックで有効化できるゲートウェイとして提供しています。

日本のSI・B2B SaaS環境ではすぐの導入は難しくても、**「自社APIをエージェントが消費するなら、どの単位で課金するか」**という問いは今から検討する価値があります。この問いに答えられなければ、エージェントトラフィックが押し寄べったとき、ただ無償で提供し続けることになります。

エージェントが予測可能な結果を出すためのフィードバックループ設計に関心があれば、AIコーディングエージェントのフィードバックループ設計ガイドも参考になります。大規模データ収集パイプラインを扱う組織であれば、Metaのデータ収集システム移行の回顧も文脈理解に役立つでしょう。

あわせて読みたい

• AIコーディングエージェント、予測可能な結果を生む強力なフィードバックループ
• Metaの大規模データ収集システム移行、成功の鍵は？