はじめに：HTTPには「支払い」のステータスコードがある

知ってた？HTTPには最初から 402 Payment Required というステータスコードが予約されている。

1997年のHTTP/1.1仕様から存在するのに、約30年間ほぼ使われなかった。理由は単純で、当時は「HTTPリクエストに対してシームレスに支払いを行う」インフラが存在しなかったからだ。

クレジットカードは手数料が高い。最低決済額がある。アカウント登録が必要。チャージバックのリスク。とてもじゃないが「1リクエスト0.01ドル」みたいなマイクロペイメントには使えない。

そして2025年、Coinbaseがこの眠れるステータスコードを叩き起こした。それが x402 だ。

x402とは

x402は、HTTPプロトコルにネイティブな決済標準だ。

サーバーがリソースへのアクセスに支払いを要求するとき、HTTP 402レスポンスを返す。クライアントはそのレスポンスに含まれる支払い情報を読み取り、暗号通貨（主にステーブルコイン）で支払いを行い、再度リクエストする。たったこれだけ。

クライアント → GET /api/weather → サーバー
クライアント ← 402 Payment Required ← サーバー
  （支払い先アドレス、金額、対応チェーン等の情報）
クライアント → GET /api/weather + 支払い署名 → サーバー
クライアント ← 200 OK + データ ← サーバー

アカウント登録不要。APIキー不要。DB不要。

Coinbaseが開発し、オープンソースとして公開。2025年9月にはCloudflareと共同で x402 Foundation を設立し、標準化を推進している。

サーバー側の実装：たった1行

Express.jsの場合、ミドルウェアを追加するだけ：

import { paymentMiddleware } from "@x402/express";

app.use(
  paymentMiddleware({
    "GET /weather": {
      accepts: [
        {
          scheme: "exact",
          network: "base",
          maxAmountRequired: "0.01", // USDC
          resource: "https://api.example.com/weather",
          description: "Weather data",
        }
      ],
    },
  })
);

これだけで /weather エンドポイントにアクセスするたびに0.01 USDCの支払いが必要になる。支払いがなければ自動的に402を返し、支払いが確認されればリソースを返す。

クライアント側の実装

import { wrapFetch } from "@x402/fetch";

const x402Fetch = wrapFetch(fetch, wallet);
const response = await x402Fetch("https://api.example.com/weather");

通常の fetch をラップするだけ。402が返ってきたら自動で支払い→リトライしてくれる。

技術的な仕組み

フロー詳細

x402の決済フローには3つの主要アクターがいる：

1. クライアント — リソースにアクセスしたい側（人間 or AIエージェント）
2. リソースサーバー — APIやコンテンツを提供する側
3. ファシリテーター — 支払いの検証・決済を仲介するサーバー

┌──────────┐     ┌──────────────┐     ┌──────────────┐
│  Client  │     │   Resource   │     │ Facilitator  │
│          │     │   Server     │     │              │
└────┬─────┘     └──────┬───────┘     └──────┬───────┘
     │  GET /resource   │                    │
     │─────────────────>│                    │
     │  402 + 支払情報  │                    │
     │<─────────────────│                    │
     │                  │                    │
     │  GET /resource   │                    │
     │  + 支払い署名    │                    │
     │─────────────────>│                    │
     │                  │  POST /verify      │
     │                  │───────────────────>│
     │                  │  検証結果          │
     │                  │<───────────────────│
     │                  │  POST /settle      │
     │                  │───────────────────>│
     │                  │  決済結果          │
     │                  │<───────────────────│
     │  200 OK + data   │                    │
     │<─────────────────│                    │

重要なのは、クライアントは秘密鍵でトランザクションに署名するだけで、実際のオンチェーン決済はファシリテーターが行うということ。クライアントはガス代やRPCノードのことを一切考えなくていい。

支払いスキーム

x402は「スキーム」という概念で支払い方法を抽象化している：

• exact — 固定金額の支払い（「この記事を読むのに$0.01」）
• deferred — 後払い・バッチ決済（Cloudflareが提案中。クロールの従量課金等）
• upto — 上限付き従量課金（「LLMのトークン数に応じて最大$1まで」）※構想段階

最初にリリースされた exact スキームでは、EVM上で EIP-3009（transferWithAuthorization） を使っている。これはクライアントがオフチェーンで署名し、ファシリテーターがオンチェーンで実行するパターンだ。

対応チェーン・トークン

現時点で対応しているのは：

チェーン	トークン	備考
Base	USDC	メインのサポート対象。L2なのでガス代が安い
Ethereum	USDC	ガス代が高いのでマイクロペイメントには不向き
Solana	USDC	SVMスキームとして対応
Arbitrum	USDC	EVM互換

SDK的には @x402/evm（EVM系チェーン全般）と @x402/svm（Solana）が提供されている。原則として チェーン・トークン非依存 を掲げており、将来的にはフィアット（クレジットカード・銀行振込）への対応も視野に入れている。

従来の決済手段との比較

従来のAPI課金フロー

1. プロバイダーのサイトでアカウント作成
2. KYC（本人確認）を通す
3. クレジットカードを登録
4. クレジットを購入 or サブスクリプション契約
5. APIキーを発行・管理
6. やっとAPIが使える

ステップが多すぎる。

特にAIエージェントにとっては致命的だ。エージェントはアカウントを作れない。KYCを通せない。クレジットカードを持っていない。

x402のフロー

1. HTTPリクエストを送る
2. 402が返ってくる
3. ステーブルコインで支払う
4. データが返ってくる

以上。

項目	従来（Stripe等）	x402
アカウント	必須	不要
KYC	必要な場合あり	不要
最低決済額	~$0.50	実質なし（ガス代のみ）
手数料	2.9% + $0.30	ガス代のみ（Base上で~$0.001）
決済速度	数日（チャージバック期間含む）	数秒
プロトコル手数料	あり	ゼロ
エージェント対応	困難	ネイティブ対応
導入の手間	SDK統合 + ダッシュボード設定	ミドルウェア1行

ユースケース

1. API課金（最も明確なユースケース）

天気API、翻訳API、画像生成API…あらゆるAPIをリクエスト単位で課金できる。サブスクリプション不要、前払い不要。

GET /api/translate?text=hello&to=ja
→ 402 Payment Required ($0.001)
→ 支払い
→ 200 OK {"result": "こんにちは"}

2. AIエージェント間決済

ここがx402の キラーユースケース だ。

エージェントAがデータを必要とする → エージェントBに402で支払う → エージェントBがデータを返す。人間の介入ゼロ。

エージェントA（データ分析）: 「AAPLの株価データが欲しい」
エージェントB（データ提供）: 「402 Payment Required $0.20」
エージェントA: [支払い]
エージェントB: [データ提供]

これが連鎖すると、エージェントCがエージェントAの分析結果を$0.50で購入し、レポートを生成してエージェントDに$1.00で販売する…というように、自律的な経済圏が生まれる。

3. コンテンツペイウォール

記事やメディアへのマイクロペイメント。月額サブスクの代わりに、1記事$0.05で読める。

4. Webクローリングの従量課金

Cloudflareが提案している pay per crawl がまさにこれ。AIクローラーがWebサイトをスクレイピングする際に、ページ単位で課金する。

5. 分散コンピューティング

推論、レンダリング、ストレージなど、コンピュートリソースの利用をリクエスト単位で課金。

対応SDK・フレームワーク

TypeScript（メインのエコシステム）

# サーバーサイド
npm install @x402/express  # Express用ミドルウェア
npm install @x402/hono     # Hono用ミドルウェア
npm install @x402/next     # Next.js用

# クライアントサイド
npm install @x402/fetch    # fetch wrapper
npm install @x402/axios    # axios wrapper

# コア
npm install @x402/core     # プロトコルコア
npm install @x402/evm      # EVM チェーン対応
npm install @x402/svm      # Solana 対応

# その他
npm install @x402/paywall  # ペイウォールUI
npm install @x402/extensions # 拡張機能

Python

pip install x402

Go

go get github.com/coinbase/x402/go

メリット・デメリット

メリット

• 圧倒的に低い導入障壁 — サーバー側1行、クライアント側1関数
• マイクロペイメント対応 — $0.001単位の課金が現実的
• ステートレス — 各リクエストが独立。セッション管理不要、DB不要
• エージェントネイティブ — AIエージェントが自律的に支払いできる
• オープンスタンダード — Coinbase主導だが、特定企業にロックインしない
• プロトコル手数料ゼロ — ネットワークのガス代のみ
• HTTPネイティブ — 既存のWeb技術スタックにそのまま載る

デメリット

• 暗号通貨が前提 — 現時点ではステーブルコイン（主にUSDC）での支払いのみ。フィアット対応は将来の話
• ウォレットが必要 — クライアントは暗号通貨ウォレット（秘密鍵）を持っている必要がある
• エコシステムの成熟度 — まだ初期段階。本番環境での大規模採用例は少ない
• 規制の不確実性 — 暗号通貨決済に対する各国の規制が流動的
• ファシリテーターへの依存 — 決済処理にファシリテーターが必要（ただし自前で建てることも可能）
• UX — 一般ユーザーにとっては「ウォレット接続して暗号通貨で支払い」はまだハードルが高い

現在の採用状況

x402.orgの統計（2026年2月時点）：

• トランザクション数: 7,540万件以上
• 取引量: $2,424万以上
• バイヤー: 94,000以上
• セラー: 22,000以上

主な動き：

• Coinbase — プロトコルの開発・メンテナンス、ファシリテーターサービス提供
• Cloudflare — x402 Foundationの共同設立。Agents SDKやMCPでのx402対応。pay per crawlの実装
• thirdweb — x402対応のドキュメント・ツール提供
• QuickNode — x402チュートリアル・インフラ提供

まだ「初期のアダプター」段階だが、CloudflareとCoinbaseという巨人が後ろにいるのは心強い。

実践的な視点：Katteguchi.linkでの活用を考える

個人的に、Katteguchi.linkでx402の採用を検討している。

考えているユースケース：

• APIエンドポイントの従量課金 — サブスクリプションではなく、使った分だけ
• プレミアムコンテンツへのマイクロペイメント — 1回アクセスごとに数セント

x402の魅力は「ユーザー管理が一切不要」なこと。ユーザーテーブルもセッション管理もいらない。HTTPリクエストに支払い情報が含まれているかどうか、それだけ。

バックエンドがExpressなら本当にミドルウェア1行で済むし、Next.jsにも @x402/next がある。試す価値は十分にある。

まとめ

x402は、30年間眠っていたHTTP 402ステータスコードに命を吹き込んだプロトコルだ。

• HTTPネイティブ — 既存のWebインフラにそのまま載る
• ステートレス — アカウントもAPIキーもDB不要
• マイクロペイメント — $0.001から課金可能
• エージェント対応 — AIエージェント同士の自律的な経済活動を可能にする
• オープン — 特定企業にロックインしない

Web3的な文脈で語られがちだが、本質は 「HTTPに決済レイヤーを追加する」 というシンプルな話だ。

インターネットの「原罪」——コンテンツに対して直接支払う仕組みがなかったこと——を、x402は解決しようとしている。だからこそ広告モデルが支配的になり、個人情報が通貨になった。x402が普及すれば、もっとシンプルで健全なWebが実現するかもしれない。

まだ初期段階だが、Coinbase + Cloudflareという組み合わせは強力だ。今のうちに触っておいて損はない。

参考リンク：

• x402公式サイト
• GitHub - coinbase/x402
• Coinbase x402ドキュメント
• Cloudflare x402ブログ