x402とは？AIがAPIの利用料を払う仕組みとデータの流れ

AIに天気データを使わせ、販促案を作らせたい。その際、必要なデータを1回分ずつ、手動の支払いを挟まずに取得する選択肢がx402です。外部の有料APIをAIに使わせたいサイト・EC運営担当者に関係する仕組みです。[1]

x402は、APIやコンテンツの利用料をWebの通信に組み込む公開規格です。ここで扱う支払いは、カード番号を送る方法ではなく、対応する暗号資産とウォレットを使う方法です。 AIと連携したプログラムが、許可された範囲でウォレットの署名機能を使って支払いを進めます。[1][6]

API側へ送るのは、支払条件と署名を含む支払いデータです。秘密鍵そのものは渡しません。この記事では、天気APIへの同じ1回の支払いを、条件の提示から結果まで追います。

1. 先に接続先と予算を決める

例は、通販店の担当者がAIへ「天気を踏まえた販促案」を依頼する場面です。天気APIの接続先は設定済みとし、AI側にはx402対応クライアントとウォレットを用意します。APIを見つけることと、その利用料を払うことは別の工程です。

担当者は、使ってよいAPI、1回の上限、累計予算を決めます。例えば「この天気APIだけ、API利用料は合計0.01 USDCまで」と制限します。こうした予算管理は利用側で設計するもので、x402の基本仕様に含まれる機能ではありません。[5]

API提供者は、課金対象のURL、価格、受取先、ネットワークを設定します。検証と決済は自ら行うか、facilitatorという補助サービスへ依頼します。以下はfacilitatorを使う構成です。[3][4]

facilitatorは、支払いデータを検証してブロックチェーンへ取引を送り、結果をAPI提供者へ返します。利用者の資金を預かる役割ではなく、担当者の予算や天気情報の内容も決めません。[4]

なお、x402は物品の商品登録や注文・配送を処理する規格ではありません。この例で買うのは、商品の代金ではなく天気APIの利用1回分です。

2. 0.001ドルの設定は何になるか

ここからはv2の固定額を払うexact方式のうち、EVM系ネットワークでUSDCの送金を許可するEIP-3009方式に絞ります。Base Sepoliaという試験用ネットワークを使い、設定価格は公式サンプルと同じ$0.001です。実際の米ドル送金や本番決済の例ではありません。[3][6]

以下のJSONは通信内容を読むための説明例です。 0xPAYER_EXAMPLEなどの支払人・受取先、nonce、署名、取引識別子は実行できない置き換え文字で、時刻も固定の説明値です。assetだけは固定版の公式仕様に掲載されたBase SepoliaのUSDCアドレスを使います。[5][6]

提供者の設定では、次のように価格を指定します。これは課金設定の一部分で、通信で返す支払条件そのものではありません。[3]

{
  "scheme": "exact",
  "price": "$0.001",
  "network": "eip155:84532",
  "payTo": "0xSELLER_EXAMPLE"
}

通信上のPaymentRequirements.amountは、ドル表記ではなく、対象トークンの最小単位を整数の文字列で表します。小数6桁のUSDCで0.001 USDCを払う例なら、0.001 × 1,000,000 = 1000なので"amount": "1000"です。priceをそのままamountへコピーしてはいけません。[3][5]

この例では$0.001の価格設定に対して0.001 USDCを要求するものとします。どの資産でいくら払うかは、次の応答に含まれるnetwork、asset、amountを組み合わせて読みます。

3. 402で支払条件を受け取る

AI側が支払いデータなしでGET /weatherを呼ぶと、API側は402 Payment Requiredを返します。この段階の402は故障ではなく、「利用には支払いが必要」という案内です。[2]

v2では、支払いに次の3つのヘッダーを使います。いずれもJSONをBase64という通信向けの表記に変えて入れます。Base64自体は暗号化や署名ではありません。[2]

ヘッダー	送る側 → 受け取る側	中身
PAYMENT-REQUIRED	API → AI側	支払条件のPaymentRequired
PAYMENT-SIGNATURE	AI側 → API	署名を含むPaymentPayload
PAYMENT-RESPONSE	API → AI側	決済結果のSettlementResponse

以下はv2だけの例です。v1のヘッダーやデータ形式とは混ぜず、連携するクライアント・サーバーの対応版をそろえます。

402応答のPAYMENT-REQUIREDをBase64から戻すと、次のようなJSONになります。任意のerrorとextensionsは省略し、受け入れる支払条件は1種類にしています。[5][6]

{
  "x402Version": 2,
  "resource": {
    "url": "https://weather.example.invalid/weather"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "amount": "1000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0xSELLER_EXAMPLE",
      "maxTimeoutSeconds": 60,
      "extra": {
        "assetTransferMethod": "eip3009",
        "name": "USDC",
        "version": "2"
      }
    }
  ]
}

resource.urlは有料の接続先、acceptsは選べる支払条件の一覧です。その1件がPaymentRequirementsに当たり、支払方式、ネットワーク、金額、資産、受取先をまとめています。[5]

maxTimeoutSecondsは支払い完了までの制限時間です。extraは方式固有の情報で、この例ではEIP-3009を指定しています。extra.versionの"2"はトークン側の情報で、x402の版を表すx402Version: 2とは別です。[5][6]

AI側はこの条件を利用先・予算の制限と照合します。例えば提示額が0.02 USDCに変わったなら、合計0.01 USDCという許可を超えるため、署名前に止めるか追加承認を求めます。

4. 送るのは署名と送金の許可内容

条件を受け入れる場合、AI側の対応クライアントが支払いデータを作ります。EIP-3009方式では、誰から誰へ、いくらを、いつまで送れるかを示すauthorizationに対して、ウォレットがEIP-712形式の署名を作ります。[5][6]

署名前に確認する中心は、次の6項目です。これらは送金許可の項目であり、PaymentPayloadの外側のJSON全体をそのまま署名するという意味ではありません。[5]

項目	この支払いでの意味
from	支払人のウォレット
to	受取先。提示されたpayToと一致させる
value	最小単位の金額。今回は"1000"
validAfter	許可が有効になるUnix時刻
validBefore	許可が失効するUnix時刻
nonce	再利用を防ぐための32バイトのランダム値

次はPaymentPayloadの抜粋です。必須のacceptedは直前のacceptsの先頭要素をそのまま入れるため、重複を避けて省略しています。任意のresourceとextensionsも省略しています。[5][6]

{
  "x402Version": 2,
  "payload": {
    "signature": "0xSIGNATURE_EXAMPLE",
    "authorization": {
      "from": "0xPAYER_EXAMPLE",
      "to": "0xSELLER_EXAMPLE",
      "value": "1000",
      "validAfter": "1740672094",
      "validBefore": "1740672154",
      "nonce": "0xNONCE_EXAMPLE"
    }
  }
}

accepted.amountとauthorization.valueはともに"1000"、accepted.payToとauthorization.toも同じ受取先です。実際のEIP-3009方式では65バイトの署名と32バイトのnonceが必要ですが、ここでは長さも形式も満たさない説明文字に置き換えています。[6]

AI側は、必須項目を含むPaymentPayload全体をBase64化し、PAYMENT-SIGNATUREに入れて同じAPIを呼び直します。ヘッダーに入るのは署名文字列だけではなく、選んだ支払条件と署名・許可内容をまとめたデータです。[2][5]

担当者の承認、APIの利用権限、ウォレットの署名、決済成功は別です。 署名は人間の身元確認や社内承認の記録を代替せず、API独自の認証が必要ならそれも用意します。

5. 検証してから決済結果を返す

API側は、受け取った支払いデータをfacilitatorのPOST /verifyへ送ります。送信本体の対応関係は次のとおりで、paymentPayloadとpaymentRequirementsには文字列の参照名ではなく、実際のオブジェクトを入れます。[5]

x402Version        ← 2
paymentPayload     ← AI側から届いたPaymentPayload全体
paymentRequirements ← API側が提示したacceptsの先頭要素

/verifyは、署名、残高、金額、有効期間、資産・ネットワークなどが条件に合うかを確認し、送金処理をシミュレーションします。この検証だけでは、ブロックチェーン上の送金は実行しません。[5][6]

有効な場合の応答例は次の形です。payerは、先ほどのauthorization.fromに対応します。[5]

{
  "isValid": true,
  "payer": "0xPAYER_EXAMPLE"
}

API側は検証後、POST /settleへ同じ構造の本体を送って決済を依頼します。今回のexact例では、同じ支払いデータとamount: "1000"の条件を使います。facilitatorが対象トークンのtransferWithAuthorizationを呼び、署名で許可された送金を実行します。[5][6]

決済に成功した場合のSettlementResponseは次の形です。任意のamountも含めると、最初の要求額と同じ最小単位の"1000"を追えます。ただし、この項目はすべての応答に必ず返るものではありません。[5]

{
  "success": true,
  "payer": "0xPAYER_EXAMPLE",
  "transaction": "0xTRANSACTION_EXAMPLE",
  "network": "eip155:84532",
  "amount": "1000"
}

API側は、この決済結果をBase64化してPAYMENT-RESPONSEへ入れ、成功時は200 OKと天気データを返します。これで「条件の1000→署名した送金額1000→決済結果」という同じ支払いのつながりが見えます。[2][4][5]

一方、検証後に決済が失敗する場合もあります。例えば固定版仕様の残高不足エラーは次の形で、公式のHTTPフローではAPI側がエラー詳細付きの402応答を返します。[4][5]

{
  "success": false,
  "errorReason": "insufficient_funds",
  "transaction": "",
  "network": "eip155:84532"
}

取引を送信したものの確定を確認できないsettlement_pendingは、この最終的な失敗とは別です。返されたtransactionとnetworkで状況を照合してから再試行を判断し、返事が遅いだけで新しい支払いを作らない設計が必要です。[4]

なお、API処理と決済の順序は実装によります。図は「検証→API処理→決済」という公式資料の構成例であり、exactという方式だけで全実装の順序が決まるわけではありません。例えばNext.jsのwithX402は、ステータス400未満の応答後にだけ決済する設計です。[3][4]

6. 支払い成功と業務で使える情報は別

公式の天気サンプルは、応答本文として次のデータを返します。これは決済の流れを示すためのデータです。[3]

{
  "report": {
    "weather": "sunny",
    "temperature": 70
  }
}

このままでは、どの地域の、いつの天気か、温度がどの単位かが分かりません。「明日の関東向けに暑さ対策の商品を訴求する」といった判断には不足します。実務では地域・対象日時・単位を返す天気APIを別途選び、利用条件やデータの品質も確認します。

決済結果が成功でも、販促に使える情報を取得できたとは限りません。導入時は、支払いログの確認と、返された情報の業務上の確認を分けてください。

7. 導入前に確認すること

まず、AIに使わせたい外部データが有料APIとして提供され、x402に対応しているかを確認します。そのうえで、対応クライアントとウォレット、予算を止める仕組み、決済状況を記録・照合する担当を用意できるかが判断材料です。

例の0.001 USDCを10回使うと、API利用料の累計は0.01 USDCです。11回目を止める制御に加え、同時実行中や確認待ちの支払いも予算管理に含める設計が必要です。

x402の規格自体に組み込まれた手数料はゼロですが、API利用料や運用費まで無料ではありません。このEIP-3009方式ではfacilitator側がブロックチェーンの取引費用を負担するものの、補助サービスの料金やサーバー費用を含めた総額は別に確認します。[1][6]

試験用のhttps://x402.org/facilitatorは開発・テストネット向けです。本番では対象ネットワークに対応する提供者か、自前の検証・決済構成が必要です。日本の事業者向けの利用資格、契約条件、資金管理もサービスごとに確認してください。[4]

次の操作は、候補APIの出力項目と支払条件を確認し、開発担当者と販売者向けクイックスタートのテストネット設定を照合することです。AIに買わせたい情報が本当に得られるかを先に見極めれば、支払い連携だけを先行させずに済みます。[3]

確認範囲

2026年9月10日時点の公式資料を基にした基礎解説です。データ構造はコミットdd927a26cfefc98c24b3ec38b3a8f204dad0c60dのv2仕様とexact EVM仕様を参照しています。[5][6]

掲載例は実行用コードではなく、外部接続・署名検証・実決済は未実施です。採用するSDKでの動作と復旧処理、日本向けの個別サービス条件は別途確認が必要です。暗号資産の購入や投資を勧めるものではありません。