x402 とは何か ― HTTP に「支払い」を組み込むインターネットネイティブ決済

Web API を有料で提供しようとすると、通常は次のような仕組みが必要になります。

• ユーザー登録
• API キーの発行
• クレジットカード登録
• 利用量の計測
• 月末請求
• サブスクリプション管理

API そのものは単純でも、「お金を受け取る仕組み」は意外と重いものです。x402 は、この問題に対してかなり大胆なアプローチを取ります ― HTTP リクエストそのものに支払いのやり取りを組み込む。 そのために使われるのが、HTTP ステータスコードの 402 Payment Required です。

x402 とは

x402 は、HTTP 上でプログラム可能な支払いを実現するオープンな決済標準です。もともと HTTP には次のステータスコードが存在します。

402 Payment Required

しかし長い間、実用的な標準フローはほとんど確立されていませんでした。x402 は、この 402 Payment Required を実際の決済プロトコルとして活用します。

なお x402 は、Coinbase が2025年5月に発表し、その後 Linux Foundation 傘下の中立的な標準(x402 Foundation)として運営されています。特定ベンダー専用の仕組みではありません。

基本的な考え方は非常にシンプルです。

Client
  |
  | GET /weather
  v
Server
  |
  | 402 Payment Required
  | 「0.001ドル支払ってください」
  v
Client
  |
  | 支払い情報を付けて再リクエスト
  v
Server
  |
  | 支払いを検証・決済
  v
200 OK

つまり、API を呼ぶ → 支払いを要求される → 支払う → 同じ API を再実行する という流れです。

具体例：1回 0.001 ドルの API

たとえば、次の API があるとします。1回 $0.001 です。

GET /weather?city=tokyo

1. クライアントが普通にアクセスする

GET /weather?city=tokyo

2. サーバーが 402 を返す

HTTP/1.1 402 Payment Required

レスポンスには、概念的には次のような支払い条件が含まれます。

{
  "amount": "0.001",
  "currency": "USDC",
  "network": "Base",
  "payTo": "0x..."
}

つまりサーバーは「このAPIを使いたければ、指定された条件で支払ってください」と機械可読な形式で伝えます。

3. クライアントが支払いを承認する

クライアントは支払い条件を確認し、秘密鍵を使って必要な支払い情報を作成します。

4. 支払い情報付きで再リクエストする

GET /weather?city=tokyo
PAYMENT-SIGNATURE: ...

5. サーバーが支払いを確認する

問題がなければ、200 OK としてデータを返します。

{
  "city": "Tokyo",
  "weather": "sunny"
}

これで API 利用と支払いが完了します。

従来の API 課金と何が違うのか

従来の API ビジネスでは、一般的に次のような流れになります。

ユーザー登録 → クレジットカード登録 → APIキー発行 → API利用 → 利用量集計 → 月末請求

x402 では、理想的には次のようになります。

APIアクセス → 402 Payment Required → 支払い → API利用

大きな違いは、事前の契約関係を必須にしない設計が可能になること です。

もちろん現実のサービスでは、認証、規制対応、レート制限などが別途必要になる場合があります。しかしプロトコルの発想としては、「誰なのか」より先に「支払えるか」でアクセスを成立させられます。

なぜブロックチェーンを使うのか

ここで重要なのは、x402 が単なる「HTTP 402 の使い方」ではないことです。

従来のクレジットカード決済で、API リクエストごとに 0.001ドル を支払うのは現実的ではありません。カード決済には、決済手数料・最低決済額・チャージバック・加盟店契約・国境・通貨・非同期な清算といった制約があるためです。

一方、USDC などのステーブルコインと低コストなブロックチェーンを使えば、小額の機械間決済(micropayments)を設計しやすくなります。そのため x402 は HTTP × ステーブルコイン × ブロックチェーン という組み合わせと相性が良いのです。

ただし、x402 自体を「特定チェーン専用プロトコル」と理解するのは正確ではありません。標準は EVM 互換チェーン全般や Solana など、より広いネットワークや価値形態へ拡張できる設計を目指しています。

Facilitator とは何か

x402 を理解するときに重要なのが Facilitator です。

API サーバーが自前でブロックチェーン決済を扱うと、ノード接続・RPC 管理・署名検証・トランザクション送信・決済確認・チェーンごとの差異などを実装する必要があります。そこで x402 では、検証と決済を支援する Facilitator を利用できます。

Client
   |
   | API Request
   v
Resource Server
   |
   | verify / settle
   v
Facilitator
   |
   v
Blockchain

Facilitator は仕様上、「1つまたは複数のネットワークについて、支払いの検証(verify)と実行(settle)を代行するサーバー」と定義されています。概念的には、

• この支払いは有効か
• 条件を満たしているか
• オンチェーンで決済できるか
• 決済を実行する

といった役割を担います。重要なのは、Facilitator が必ずしも中央集権的な唯一の決済事業者ではないことです。x402 はオープンなプロトコルであり、Facilitator も複数存在でき、自前で運用することも可能です。

ウォレットは必要か

ここは最初に疑問になりやすい点です。結論として、現在主流のオンチェーン x402 実装では、基本的に支払い側には署名能力が必要です。

API 利用者(Buyer)

支払う側は、ウォレット・秘密鍵・USDC などの支払い資産を持ちます。ただし「ウォレット」といっても、必ずしも MetaMask の画面を人間が操作する必要はありません。たとえば Node.js プログラムなら、次の構成が可能です。

AI Agent → Wallet / Signer → x402 Client → Paid API

秘密鍵を持つプログラムが自動署名できます。

API 提供者(Seller)

受け取る側には、少なくとも支払い先アドレスが必要です。

payTo = 0x...

ただし通常、API レスポンスを返すたびに Seller 側が秘密鍵で署名するわけではありません。整理すると、

• Buyer：支払いのための署名能力が必要
• Seller：受取先アドレスが必要

となります。

実装イメージ

Node.js / Express では、概念的には次のように有料 API を定義できます(eip155:84532 は Base Sepolia テストネット)。

app.use(
  paymentMiddleware({
    "GET /weather": {
      accepts: [
        {
          scheme: "exact",
          price: "$0.001",
          network: "eip155:84532",
          payTo: "0xYourAddress"
        }
      ]
    }
  })
);

app.get("/weather", (req, res) => {
  res.json({
    weather: "sunny"
  });
});

この API に普通のクライアントがアクセスすると 402 が返ります。一方、x402 対応クライアントでは、次のように呼び出せます。

const response = await fetchWithPayment(
  "https://example.com/weather"
);

これで、

最初のリクエスト → 402を受信 → 支払い条件を解析 → 署名 → 再リクエスト → 200 OK

までを自動化できます。ここが x402 の面白いところです。アプリケーションコードから見ると、await fetch(...) に近い感覚のまま、支払い付き HTTP 通信を実現できます。

AIエージェントとの相性

x402 が特に注目されている理由の一つが、AI エージェントです。

現在の Web サービスは基本的に人間向けです(ログイン、カード登録、プラン選択、購入ボタン)。AI エージェントにとって、これは扱いにくいものです。

たとえば AI が「東京の現在の詳細な気象データが必要」と判断したとします。x402 対応 API なら、次の処理を自律的に行えます。

AI Agent
   | GET /weather
   v
402 Payment Required
   | $0.001
   v
AI Agent
   | 支払い
   v
200 OK

人間がアカウントを作る・API キーをコピーする・カードを登録する必要がありません。

AIエージェント経済の可能性

さらに進むと、AI エージェント自身が予算を持つ世界が考えられます。

AI Agent
  +-- 天気API       $0.001
  +-- 翻訳API       $0.003
  +-- 市場データ    $0.01
  +-- GPU推論       $0.05
  +-- 別AI Agent    $0.02

たとえば「100ドル以内で競合調査を行って」と指示すると、AI が必要に応じて検索 API を購入し、論文データを購入し、高性能モデルを一時利用し、他の専門 AI に仕事を依頼する、といった世界です。

ここでは AI は単なる「API 利用者」ではなく、経済主体に近づきます。 x402 の本質的な可能性は、この点にあります。

MCP との関係

AI エージェントの文脈では、MCP との組み合わせも興味深いです。

MCP が「AI が何を使えるかを標準化する」ものだとすれば、x402 は「AI がどう支払うかを標準化する」方向にあります。概念的には、

AI Agent
   v
MCP  「このツールが使える」
   v
x402 「利用には0.01ドル必要」
   v
Payment
   v
Tool Execution

となります。つまり、

• MCP：Capability Discovery
• x402：Payment
• Blockchain：Settlement

という分業が考えられます。

x402 は「暗号資産決済API」なのか

狭く理解すると「USDC で API 料金を払う仕組み」です。しかし、それだけでは本質を捉えきれません。

より重要なのは、HTTP リクエストと価値交換を同じプロトコルフローに載せる という発想です。

これまでの Web では、「情報の通信」と「お金の移動」は別々のシステムでした(HTTP / OAuth / API Key / Stripe / Invoice / Bank)。x402 は、この分離に対して、

Request → Payment Required → Payment → Response

という、かなり原始的で強力なモデルを提示しています。

課題も多い

もちろん、x402 がそのまま普及するとは限りません。

1. ウォレット UX

一般ユーザーに、ウォレット作成・秘密鍵管理・USDC 入金を要求するのは依然として大きな障壁です。AI エージェントでは問題が小さく見えますが、今度は「AI に秘密鍵を持たせてよいのか」という問題が生まれます。

2. 秘密鍵管理

エージェントが自由に支払えるなら、次のような権限制御が必要です。

1回最大 $0.01
1日最大 $10
weather APIのみ許可
未知ドメインは禁止

単に PRIVATE_KEY=... を AI プロセスに渡す設計は危険です。

3. マイクロペイメントの経済性

1回 $0.001 の API に対して、決済コストが同程度なら成立しません。チェーン、トークン、Facilitator、バッチ処理、オフチェーン化などの設計が重要になります。

4. 法規制と会計

技術的に支払えることと、事業として運用できることは別です。KYC・AML・税務・売上認識・返金・不正利用・制裁対応などは残ります。

5. すべての API に向いているわけではない

既存顧客との長期契約や大企業向け SaaS では、月額契約・請求書・SLA・ボリュームディスカウントの方が合理的な場合も多いでしょう。x402 は既存決済をすべて置き換えるものではありません。

面白いと思う点

x402 を単なる「クリプトで API 課金できる技術」として見ると、それほど新しく感じないかもしれません。しかし、機械が自分でサービスを発見し、自分で価格を判断し、自分で支払う ための基盤として見ると、かなり面白いものです。

これまでのインターネットでは、人間が契約する → API キーを取得する → プログラムに渡す、という流れが必要でした。x402 的な世界では、

Agentがサービスを発見 → 価格を確認 → 予算内か判断 → 支払い → 利用

まで自律化できます。これは単なる決済技術ではなく、ソフトウェア同士が経済活動を行うためのプロトコル になり得ます。

まとめ

x402 は、HTTP の 402 Payment Required を活用し、Web API やデジタルリソースにプログラム可能な支払いを組み込むオープンな決済標準です。基本フローは単純です。

1. APIを呼ぶ
2. 402 Payment Required
3. 支払い条件を確認
4. 支払い情報を生成
5. 再リクエスト
6. APIレスポンスを取得

技術的には HTTP・ウォレット・ステーブルコイン・ブロックチェーン・Facilitator を組み合わせます。しかし本当に重要なのは個々の技術ではなく、x402 が提示している 「インターネット上で、機械が機械に直接支払う」 というモデルです。

人間向け Web ではウォレット UX や規制など多くの課題があります。一方、AI エージェントの世界では、API 利用・データ購入・推論購入・計算資源購入・他エージェントへの依頼を自律的に行う必要があります。その意味で x402 は、単なるクリプト決済技術ではなく、AIエージェント時代の HTTP ネイティブな経済レイヤー として見ると、その可能性が理解しやすくなります。

参考

• Coinbase: Introducing x402 — a new standard for internet-native payments (2025-05-06)
• x402 公式サイト
• GitHub: coinbase/x402（仕様・実装）
• Coinbase Developer Platform Docs: x402