決済ソリューションx402のV2アップデートとは
こんにちは、FractonのKeitaです。
前回取り上げたOpenClaw*Cryptoの潮流の勃興に伴い、その決済ソリューションとして採用率が高まっているx402について、その特徴、昨年末に出たV2アップデートの内容を詳しく取り上げます。
はじめに: x402のおさらい
特徴:
まずわかりやすい特徴として、HTTPのステータスをベースに決済有無の判定を行う背景故に、アカウント作成不要、APIキー不要、1アクセスごとのマイクロペイメント決済可能などがあり、Agent Nativeな決済手段の要件に強くマッチしています。
基本構造
x402は役割別に大きく分けると
HTTP決済の トランスポート標準
それを成立させる 支払い実行層
検証や仲介を担う ファシリテーション層
開発者体験を担う SDK層
の4分割構造になっています。(実装コンポーネント側は以下に記す6層に分かれます)
① Transport
役割:
支払い要求と支払い証明をHTTP通信に埋め込む層。
ここがx402の“名前の由来”で、HTTP 402 Payment Required を実運用可能な形にした層。
フロー:
ClientがAPIリクエスト
Serverが 402 + 支払い条件 を返す
Clientが支払い実行
支払い証明をheaderに付与
Serverが検証しアクセス許可
② Payment Rails
役割:
実際にお金を動かす層。
Transport層は「払えと指示する役割」で、この層が実際の送金処理を行います。
③ Facilitator
役割: 以下の役割を担い、API提供者が自前でブロックチェーン検証ロジックを書く必要をなくしています。
支払い検証
署名検証
送金確認
価格提示
ルーティング
分配
④ Paywall
役割/ 機能
402発行
支払い条件提示
支払い証明検証
アクセス解放
⑤ SDK
役割
Client / Server / Facilitator接続を簡単化
⑥ Discovery Layer
役割
x402対応サービスのindex化と自動発見
V2で追加されたレイヤー。
採用数と直近の割合
x402 V1は去年の5月より本格稼働していて、順調にその採用サービスを増やしています。
現在は1000以上のエンドポイントが公開範囲で観測されています(1サービスが複数エンドポイントを出してる場合があるのでユニーク数はもう少し少ないと思います)。
例えば直近はCoingeckoがx402支払いの対応を発表しました。Coingecko APIをAgent経由で、x402ベースで利用できるようになっています。（今後このように人間向けAppsではなくAgent向けAPIの提供チャネルに変更するサービスは増えると思います）
ちなみに、先週あつかったOpenClawエコシステムの中で、「Agent決済機能付きプロジェクト」のうちの約半数はx402を採用しています。
また採用エコシステムでは発起元であるBaseがもちろん多いですが、ついでSolanaも急速にその採用数とトラフィックを伸ばしています。
x402 Scanを見ると、直近15日のトラフィック量ではdexter, virtuals, blockrun.aiの順で多くなっています。
ファシリテーターではCoinbase, PayAI, Dexterの順になっています。
PayAIは、Avalanche, Base, Polygon, Sei, Solanaなどのほぼ全てのx402支払いに対応したgenericなファシリテーター、次ぐDexterはSolanaとBaseに対応したx402ファシリテーターで、AgentのMCP発見と支払いをサポートしています。
(ファシリテーターはエコシステムごとにそれぞれあるのが基本的な傾向です)
V2について
V2は去年の12月に発表され、着々とV1からの移行が進んでいます。
V2は雑に言うと、V1の「HTTP 402で1回ごとの支払い」のミニマムな機能を土台にしつつ、実運用ででた課題を潰して「拡張可能な設計」「動的分配」「セッション」「多チェーン/法定通貨レール」「自動発見」を足して、エコシステムが勝手に増殖できる土台に寄せたアップデートです。
主な追加アップデート内容
単発の厳密な1回払いから拡張
V2は「単一コールのexact payment」前提を超えて、セッション的なアクセスやサブスク的な支払いパターンに対応。
ウォレットIDで「毎回払う」をスキップできるように。すでに購入済みのリソースに対して、ウォレット制御のセッションなどでフルの支払いフローを省略できる設計が含まれています。
実際V1を使ってみると、都度支払いは人間側、Agent側の両方のUXとして面倒だったりするので、セッションごとのバッチ支払いはUX向上の観点で効くと思います。
支払いインターフェースの統一
マルチチェーン前提（例: Base, Solana など）で、独自ロジックなしに拡張可能。
ACH/SEPA/カード等のレガシーレールも “facilitator” として同じモデルに載せられるように。
payTo の動的ルーティング（リクエストごとに送金先やロール、コールバックで分配ロジックの変更が可能に）: マーケットプレイスやマルチテナントAPI向けで、入力に応じた動的価格の設定も可能になっています
拡張可能な構造と互換性Up
client, server, facilitator, reference SDK の分離がより明確に。
SDKをプラグイン駆動にして、チェーン/アセット/スキームを「登録」する形へ（SDK内部改造を前提にしない）。
ライフサイクルフック（送金前後、検証前後など）で、条件付きルーティング、メトリクス、失敗復旧などのカスタムロジックを差し込めるように。
Discovery強化（自動APIディスカバリー）
x402対応サービスがメタデータを公開し、facilitatorがクロールしてエンドポイントや価格などを自動インデックスする仕組みの導入。
マルチfacilitator対応
複数facilitatorを同時利用でき、目的にあった最適なファシリテーター選択が可能に。「Solana優先」「mainnet回避」「USDCのみ」みたいな選好を宣言的に書けるようです
まとめ
全体的に実利用場面に即したpracticalな機能の追加が目立っていて、非常につかいやすくなっていると思います。
実状、大手のAPIサービスの多くはまだx402未対応で、x402対応のサービスが少なくてAgent側がメインで採用しにくい問題がありました。今回のアップデートで今後採用サービスの伸び率がかなり改善されると予想しています。
Agent向けサービス自体の増加傾向も採用増の追い風になりそうです。
また、個人的にも現在x402を使ったプロダクトの開発も行っているので、x402を使って何かプロダクトを作りたい、アイデアがあると言う方はDM等で気軽にご連絡ください。何かお役に立てるかもしてません。
それではまた👋