x402とは？AIエージェントがAPIに支払うためのHTTPネイティブな決済プロトコル

なぜx402が必要なのか

AIエージェントが自律的に外部サービスを使うようになると、既存の課金方式が合わなくなります。APIキーの発行、月額契約、クレジットカードの登録は、いずれも「人間が事前に手続きを済ませてある」ことを前提にしているからです。エージェントが実行中に見つけた未知のAPIを、その場で一度だけ使いたい場合、通す道がありません。

x402は、この隙間をHTTPの仕組みだけで埋めます。サーバーは 402 Payment Required を返して支払い条件を提示し、クライアントは署名した支払いデータを添えて同じリクエストを再送します。事前のアカウント登録も契約も不要で、支払いはリクエスト単位で完結します。

402から決済成立までの流れ

登場する役割は3つです。クライアント（買い手。エージェントやアプリケーション）、リソースサーバー（売り手。APIやコンテンツの提供者）、ファシリテーター（支払いの検証と決済を代行する第三者）。

1. 01

   通常どおりリクエストする

   クライアントは保護されたリソースへ普通にHTTPリクエストを送ります。この時点では支払い情報を持っていません。

2. 02

   402で支払い条件を受け取る

   サーバーは 402 を返し、PAYMENT-REQUIRED ヘッダーで支払い条件を提示します。条件は accepts 配列で複数示せるため、クライアントは自分が扱えるネットワークや通貨を選べます。

3. 03

   署名して再送する

   クライアントは選んだ条件に対する支払い認可に署名し、PAYMENT-SIGNATURE ヘッダーへ載せて同じリクエストを再送します。この時点ではまだ送金は起きていません。

4. 04

   サーバーが検証を依頼する

   サーバーはファシリテーターの /verify を呼び、署名・残高・有効期限・条件の一致を確認します。結果は isValid で返ります。

5. 05

   決済を実行し、リソースを返す

   ファシリテーターの /settle がブロックチェーンへトランザクションを送信します。サーバーはリソースを返し、PAYMENT-RESPONSE ヘッダーで決済結果を伝えます。

やり取りされる4つのデータ

PaymentRequired

サーバーが402とともに返す全体。対象リソースの情報と、受け入れ可能な支払い条件の配列を持つ。

PaymentRequirements

accepts配列の1要素。scheme、network、amount、asset、payTo、maxTimeoutSecondsなどを指定する。

PaymentPayload

クライアントが署名して送る支払い認可。選んだ条件（accepted）と、署名データ（payload）を持つ。

SettlementResponse

決済の結果。success、transaction、network、payerを返す。

サーバーが提示する支払い条件は、次のような形をしています。金額は小数を避けるため最小単位の文字列で表現し、ネットワークはCAIP-2形式（名前空間:参照）で識別します。

{
  "x402Version": 2,
  "resource": { "url": "https://api.example.com/report" },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "10000",
      "asset": "0x036CbD53...",
      "payTo": "0x209693Bc...",
      "maxTimeoutSeconds": 60
    }
  ]
}

scheme は支払い方式を表し、現在の中心は exact（提示額ちょうどを支払う）です。EVM系ではEIP-3009の transferWithAuthorization を使うため、買い手はガス代を負担せず、署名だけで支払えます。Solanaでは同等の役割をSPLトークンの TransferChecked が担います。

ファシリテーターが担うもの

ファシリテーターは、支払い証明の検証とブロックチェーンへの送信を代行する第三者です。これがあるおかげで、売り手はウォレットもRPCノードもガス代の管理も持たずに済みます。売り手が実装するのは、402を返すことと、ファシリテーターのAPIを呼ぶことだけです。

設計上ここが重要な点です。x402では、支払いが正しいかどうかの判断がファシリテーターに集約されます。多数の売り手が同じファシリテーターを共有するため、その実装に欠陥があれば、利用しているすべてのサービスに影響します。ファシリテーターの選定は、決済手数料の比較ではなく、信頼をどこに預けるかの判断です。

A2A・MCPとの関係

v2でx402はトランスポート非依存になりました。HTTPヘッダーで運ぶのはあくまで一つの実装形態であり、MCPやA2Aの上でも同じ支払いフローを成立させられる設計になっています。エージェント連携の観点では、3つの標準が別々の境界を受け持ちます。

A2A

誰に、何を依頼するか。相手の発見、タスクの委任、進捗と成果物の受け渡し。

MCP

エージェントが自分の道具をどう使うか。ツール、リソース、プロンプトの供給。

x402

その依頼の対価をどう払うか。支払い条件の提示、認可、決済。

A2Aは「仕事を頼めること」までを標準化しますが、その仕事が有料である場合の支払い方は定義しません。x402はそこを埋める位置にあります。ただし現時点では、A2A上でx402を使う構成は仕様として可能になった段階であり、公開エージェントでの実装はまだ限定的です。

実装で注意すること

• 検証成功で応答を返すか、決済成立を待つかを明示的に決める。前者は未決済のままリソースが渡る可能性がある
• 決済が失敗したときに、実行済みの業務ロジックを巻き戻す手段を用意する。仕様はロールバックを提供しない
• maxTimeoutSecondsと署名の有効期限を、実際の処理時間より十分長く設定する
• ファシリテーターを単一に依存させない。/supportedで対応schemeとnetworkを確認しておく
• v1のX-PAYMENT系ヘッダーとv2のPAYMENT-*ヘッダーが混在しうるため、SDKと相手側の版をそろえる

まとめ

x402は、HTTPの402を使って「機械が機械に払う」経路を標準化します。事前契約なしにリクエスト単位で支払えること、売り手がブロックチェーンを直接扱わずに済むことが、実務上の主な利点です。

一方で、支払いの正しさの判断はファシリテーターに集約され、検証と決済のあいだには時間差が残ります。x402対応であることは、支払いが確実に成立することの保証ではありません。どこまでを完了とみなすかは、依然として実装側の設計事項です。