はじめに

x402プロトコルは2025年12月にV2仕様をリリースしました。V1からV2への変更は単なるマイナーアップデートではなく、スキーマ構造の再設計、ネットワーク識別子の標準化、拡張メカニズムの導入など、プロトコルの根幹に関わる変更が含まれています。

この記事では、V2仕様の全体像を解説したうえで、V1からの具体的な移行ポイントをまとめます。

対象読者

• x402 V1を使って実装済みのサーバー/クライアント開発者
• V2の新機能を理解したい方
• 移行作業の影響範囲を把握したい方

目次

V1が抱えていたビジネス・実装上の課題

V2の技術的な変更点を見る前に、そもそもなぜV2が必要だったのかを整理します。V1は「HTTP上で暗号資産決済を動かす」という概念実証としては成功しましたが、プロダクション運用やエコシステム拡大に向けてはいくつかの壁がありました。

マルチチェーン対応のスケーラビリティ

V1ではネットワーク識別子にbase-sepoliaのような独自文字列を使っていました。新しいチェーンをサポートするたびに、プロトコル側で文字列を定義し、全クライアント・サーバーが対応を追加する必要がありました。

これはBaseとAvalancheだけの世界では問題になりませんでしたが、Solanaへの対応や将来のL2チェーン拡大を見据えると、スケールしない仕組みでした。加えて、WalletConnectやWeb3ウォレットなど既存のエコシステムとの連携にも独自の変換レイヤーが必要でした。

支払い方法の柔軟性

V1では「リソース情報」と「支払い条件」が1つのオブジェクトに密結合していました。たとえば1つのAPIエンドポイントに対して「BaseのUSDCで払う」と「SolanaのUSDCで払う」の2つの選択肢を提示したい場合、リソースのURL・説明・MIMEタイプまで2回繰り返し記述する必要がありました。

ビジネス的には「同じ商品に複数の支払い方法」は当然のニーズです。この冗長性はデータサイズの問題だけでなく、サーバー実装の複雑さにも直結していました。

プロトコルの拡張性

V1にはオプション機能を追加する仕組みがありませんでした。たとえば「サブスクリプション決済」「レート割引」「使用量ベース課金」といった機能を追加しようとすると、コアプロトコルの仕様を変更するしかなく、既存の実装が壊れるリスクがありました。

プロトコルが広く採用されるためには、コアを安定させたまま機能を足せる拡張ポイントが不可欠です。

リソース発見の不在

V1ではx402対応のAPIを見つける標準的な方法がありませんでした。クライアント（特にAIエージェント）は、事前にURLを知っている必要がありました。

AIエージェントが自律的に「使えるAPI」を発見し、比較し、最適なものを選んで支払う — そんなマーケットプレイス的な世界観を実現するには、リソース発見の仕組みが必要でした。

ヘッダー設計の一貫性

V1では支払い条件がレスポンスボディにJSON直書き、決済ペイロードはヘッダーにBase64、と伝送方式が混在していました。これは実装者にとって混乱の元であり、ミドルウェアやプロキシとの相性にも課題がありました。

V2が解決したこと

V2はこれらの課題に対して、以下のアプローチで応えています。

業界標準への準拠で「つなぐコスト」を削減

ネットワーク識別子をCAIP-2（Chain Agnostic Improvement Proposal）形式に統一しました。eip155:8453（Base）、solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp（Solana）のように、業界で広く使われている標準に乗ることで、新チェーン追加時のプロトコル変更が不要になり、WalletConnectなど既存ツールとの統合もスムーズになりました。

さらにach:usやsepa:euのように、将来的にフィアット決済ネットワークまで表現できる拡張性も持っています。

1つのリソースに複数の支払い方法を提示

リソース情報（ResourceInfo）を支払い条件から分離しました。リソースの情報は1回だけ記述し、accepts配列に複数の支払い方法を列挙する構造です。これにより「Base USDC」「Solana USDC」「Avalanche USDC」を並べても冗長にならず、サーバー実装もシンプルになりました。

コアを壊さず機能を足せるExtensions

extensionsフィールドの導入により、コアプロトコルの仕様を変更することなくオプション機能を追加できるようになりました。サブスクリプション、使用量課金、レート交渉といった将来の機能が、既存実装を壊すことなく追加可能です。

Discovery APIでマーケットプレイスが実現

「Bazaar」と呼ばれるDiscovery APIの追加により、x402対応リソースの検索・発見が標準化されました。AIエージェントが「翻訳APIで一番安いのはどれか」を自律的に検索し、支払いまで自動で完結させる世界が技術的に可能になっています。

ヘッダーの統一設計

全方向の通信をPAYMENT-REQUIRED / PAYMENT-SIGNATURE / PAYMENT-RESPONSEの3つのヘッダーに統一し、すべてBase64エンコードJSON形式で揃えました。レスポンスボディはエラーメッセージやアプリケーション固有のデータに使えるようになり、ミドルウェアの実装もシンプルになっています。

x402 V2の採用状況とOpenClawでの活用

V2がもたらした変化は仕様書の上だけにとどまりません。実際のエコシステムで急速に採用が進んでいます。

x402プロトコルの成長数値

x402はリリース以来、急速な成長を記録しています。

Galaxy Digitalは2026年の予測として、x402がBaseの日次トランザクションの30%、Solanaトランザクションの**5%に到達する可能性があるとレポートしています。Coinbases x402プロトコルのトランザクションボリュームは、ローンチ後1ヶ月で10,000%**の増加を記録しました。

OpenClawエコシステムでのx402採用

V2のマルチチェーン対応とExtensions機構は、AIエージェントフレームワークOpenClaw（GitHub 209k+ stars）のエコシステムで実際に活用されています。

OpenClaw Foundry — スキルマーケットプレイスの決済基盤

OpenClaw Foundryは、OpenClawの自己拡張メタエクステンションです。エージェントが自律的にワークフローパターンを学習し、新しいスキルとして公開できる仕組みを持っています。

このFoundryのスキルマーケットプレイスでは、スキルの公開・ダウンロードの決済にx402プロトコル + Solana USDCが採用されています。エージェントがスキルを購入する際、HTTP 402レスポンスを受け取り、Solana上のUSDCで自動決済してスキルをインストールする — まさにV2のDiscovery API + マルチチェーン対応が想定したユースケースです。

ClawRouter — LLMルーティングにx402決済を統合

ClawRouterは30以上のLLMモデルをスマートルーティングするプロバイダープラグインで、モデル推論の課金にx402決済を統合しています。Circle主催のUSDC × OpenClawハッカソン（賞金プール$30,000 USDC）の受賞プロジェクトでもあり、「エージェントが自身のUSDCウォレットを管理し、モデル推論を自律的に購入する」というフローを実現しています。

自動売買エージェントとの連携

OpenClawのSolanaスキル群（solana-skills、pump-fun、Bankr）は、Jupiter DEXを通じた自動売買やPump.funでのトークンローンチを実行できます。これらのスキルがx402の決済レイヤーと組み合わさることで、「APIアクセスの決済」から「実際のトークン売買」まで、エージェントの経済活動が一気通貫で動作する基盤が整いつつあります。

Trawling Tradersは、OpenClawエージェントをDigitalOcean上にデプロイし、トレンドフォロー・ミーンリバージョン・ブレイクアウトの3戦略で自動売買を行うプラットフォームです。USDC建てペアに限定し、日次損失キャップやドローダウンサーキットブレーカーなどのリスク管理機能を備えています。

なぜV2がOpenClawに必要だったか

OpenClawのエコシステムが示しているのは、V1の課題がそのまま現実の障壁だったということです。

• マルチチェーン: スキルマーケットプレイスはSolana、自動売買はBase — 複数チェーンをシームレスに扱う必要があった
• Extensions: スキルの種類や課金モデル（従量課金、サブスクリプション）はスキルごとに異なり、コアプロトコルの柔軟な拡張が求められた
• Discovery API: エージェントが「どのスキルが使えるか」を自律的に発見するには、標準化されたリソース検索の仕組みが不可欠だった

V1とV2の変更点一覧

ここまでの課題と解決策を、技術的な変更点として一覧にまとめます。

以降のセクションでは、各変更点の技術的な詳細と具体的な移行手順を解説します。

技術詳細: CAIP-2ネットワーク識別子

V2で最もインパクトが大きい変更の一つが、ネットワーク識別子のCAIP-2（Chain Agnostic Improvement Proposal 2）形式への移行です。

V1の識別子

V1では独自の文字列を使用していました。

base-sepolia
base
avalanche-fuji
avalanche

V2の識別子

V2ではnamespace:reference形式を採用しています。

eip155:84532      # Base Sepolia
eip155:8453       # Base メインネット
eip155:43113      # Avalanche Fuji
eip155:43114      # Avalanche メインネット
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp  # Solana メインネット
solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1  # Solana Devnet

CAIP-2は業界標準の識別方式で、以下のメリットがあります。

• チェーン非依存: EVM、Solana、将来の新チェーンを統一的に識別
• 既存ツールとの互換性: WalletConnectなど多くのWeb3ツールがCAIP-2を採用済み
• 非ブロックチェーンへの拡張: ach:usやsepa:euのようにフィアット決済ネットワークも表現可能

移行時の注意

ネットワーク文字列のマッピングを一括で更新する必要があります。ハードコードしている箇所を検索し、すべてCAIP-2形式に置き換えてください。

// V1
const network = "base-sepolia";

// V2
const network = "eip155:84532";

技術詳細: HTTPヘッダーの変更

V2ではHTTPトランスポートのヘッダー名と、支払い条件の伝送方式が変更されました。

V1のヘッダー構成

V2のヘッダー構成

重要な変更点は、V1ではレスポンスボディに支払い条件のJSONを直接含めていたのに対し、V2ではPAYMENT-REQUIREDヘッダーにBase64エンコードして格納する方式に変わった点です。これにより、レスポンスボディを別の用途（エラーメッセージなど）に使えるようになりました。

技術詳細: PaymentRequired構造の変更

V1の構造

{
  "x402Version": 1,
  "error": "X-PAYMENT header is required",
  "accepts": [
    {
      "scheme": "exact",
      "network": "base-sepolia",
      "maxAmountRequired": "10000",
      "asset": "0x036CbD53842c...",
      "payTo": "0x209693Bc6afc...",
      "resource": "https://api.example.com/premium-data",
      "description": "Access to premium market data",
      "mimeType": "application/json",
      "outputSchema": null,
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USDC", "version": "2" }
    }
  ]
}

V2の構造

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "resource": {
    "url": "https://api.example.com/premium-data",
    "description": "Access to premium market data",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "amount": "10000",
      "asset": "0x036CbD53842c...",
      "payTo": "0x209693Bc6afc...",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USDC", "version": "2" }
    }
  ],
  "extensions": {}
}

主な変更点

1. ResourceInfoの分離

V1ではresource、description、mimeTypeが各PaymentRequirements要素の中にフラットに含まれていました。V2ではこれらがトップレベルのresourceオブジェクトとして分離されています。

// V2のResourceInfo
interface ResourceInfo {
  url: string;        // 必須
  description?: string;
  mimeType?: string;
}

同じリソースに対して複数の支払い方法を提供する場合、リソース情報を繰り返し記述する必要がなくなりました。

2. 金額フィールド名の変更

maxAmountRequired → amountに変更されました。シンプルな命名になりましたが、既存のコードでmaxAmountRequiredを参照している箇所はすべて修正が必要です。

3. outputSchemaの削除

V1にあったoutputSchemaフィールドはV2では削除されています。

4. extensionsフィールドの追加

V2ではトップレベルにextensionsフィールドが追加されました。これにより、コアプロトコルを変更せずにオプション機能を追加できるようになりました。

技術詳細: PaymentPayload構造の変更

V1の構造

{
  "x402Version": 1,
  "scheme": "exact",
  "network": "base-sepolia",
  "payload": {
    "signature": "0x2d6a7588...",
    "authorization": {
      "from": "0x857b0651...",
      "to": "0x209693Bc...",
      "value": "10000",
      "validAfter": "1740672089",
      "validBefore": "1740672154",
      "nonce": "0xf3746613..."
    }
  }
}

V2の構造

{
  "x402Version": 2,
  "resource": {
    "url": "https://api.example.com/premium-data",
    "description": "Access to premium market data",
    "mimeType": "application/json"
  },
  "accepted": {
    "scheme": "exact",
    "network": "eip155:84532",
    "amount": "10000",
    "asset": "0x036CbD53842c...",
    "payTo": "0x209693Bc6afc...",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USDC", "version": "2" }
  },
  "payload": {
    "signature": "0x2d6a7588...",
    "authorization": {
      "from": "0x857b0651...",
      "to": "0x209693Bc...",
      "value": "10000",
      "validAfter": "1740672089",
      "validBefore": "1740672154",
      "nonce": "0xf3746613..."
    }
  },
  "extensions": {}
}

主な変更点

1. scheme/networkからacceptedオブジェクトへ

V1ではトップレベルにschemeとnetworkを個別に持っていましたが、V2ではacceptedフィールドの中にPaymentRequirementsオブジェクト全体を含めます。これにより、クライアントがどの支払い条件を選択したかが明示的に伝わります。

2. resourceフィールドの追加

PaymentPayloadにもResourceInfoが含まれるようになりました（オプション）。

3. extensionsフィールドの追加

PaymentPayloadにもextensionsが含まれ、サーバーがPaymentRequiredで提示した拡張情報をクライアントがエコーバックできるようになりました。

技術詳細: Extensions機構

V2で導入されたExtensions（拡張）メカニズムは、コアプロトコルを変更せずにオプション機能を追加するための仕組みです。

{
  "extensions": {
    "extensionId": {
      "info": { /* 拡張固有のデータ */ },
      "schema": { /* infoのJSONスキーマ定義 */ }
    }
  }
}

サーバーがPaymentRequiredでextensionsを提示し、クライアントはPaymentPayloadでそれをエコーバックします。クライアントは受け取ったinfoに情報を追加することはできますが、既存のinfoを削除・上書きしてはなりません。

SettlementResponseにもextensionsフィールドが追加されており、決済結果に拡張データを含めることが可能です。

技術詳細: GET /supported レスポンスの拡張

FacilitatorのGET /supportedエンドポイントのレスポンスもV2で拡張されました。

V1のレスポンス

{
  "kinds": [
    { "x402Version": 1, "scheme": "exact", "network": "base-sepolia" }
  ]
}

V2のレスポンス

{
  "kinds": [
    { "x402Version": 2, "scheme": "exact", "network": "eip155:84532" }
  ],
  "extensions": [],
  "signers": {
    "eip155:*": ["0x1234..."],
    "solana:*": ["CKPKJWNdJE..."]
  }
}

V2ではextensions（対応済み拡張のリスト）とsigners（ネットワークごとの署名者アドレスのマップ）が追加されています。signersはCAIP-2のワイルドカードパターンをキーとして使用します。

技術詳細: Discovery API（Bazaar）

V2で新たに追加されたDiscovery APIは、x402対応リソースを検索・発見するための仕組みです。「Bazaar」と呼ばれるマーケットプレイスコンセプトに基づいています。

GET /discovery/resources?type=http&limit=10

レスポンスには、リソースURL、支払い条件、プロバイダー情報などが含まれます。これにより、AIエージェントが利用可能なAPIを自律的に発見し、必要なリソースに自動で支払いを行う仕組みが実現されます。

まとめ

x402 V2はプロトコルの成熟に向けた大きなステップです。

• CAIP-2: 業界標準のネットワーク識別子で相互運用性を向上
• ResourceInfo分離: 同一リソースへの複数支払い方法を整理
• Extensions: コアプロトコルを変更せずに機能を拡張
• ヘッダー標準化: PAYMENT-REQUIRED/PAYMENT-SIGNATURE/PAYMENT-RESPONSEの統一命名
• Discovery API: リソース発見のための標準化されたメカニズム

V1から移行する場合は、ネットワーク識別子、ヘッダー名、スキーマ構造の3点が主な変更箇所です。公式SDKを利用している場合は、アップデートにより大部分は自動的に対応されますが、ハードコードされた部分は手動での修正が必要です。

参考リンク

公式ソース

• x402 Protocol Specification V2
• x402 Protocol Specification V1
• x402 HTTP Transport V2
• x402 HTTP Transport V1
• coinbase/x402 GitHub

参考記事

• x402 Coinbase Developer Documentation

この記事が参考になったら

Xをフォローする