エージェントが自らデータを買い、APIを呼び出し、計算資源を購入するには、機械が直接使える決済基盤が必要だ。カード情報を入力したり、サービスごとにAPIキーやサブスクリプションを管理したりする方法だけでは、円滑な利用は難しい。だからこそ、x402はエージェンティックコマースで重要になる。
リクエスト単位の支払いには明確な魅力がある。長期契約やサブスクリプションを先に結ばず、必要な一回のリクエストに料金を払って利用できることだ。ただし、これを持続可能な事業にするには区別が必要だ。リクエストごとに価格を付けることと、毎回オンチェーンで精算することは同じではない。
マイクロペイメントの成立を決めるのは、金額の小ささだけではない。どれほど頻繁に支払いが発生し、その都度どのような費用と遅延が生じるかも見なければならない。
小さな決済にも費用の下限がある
CoinbaseのCDP変更履歴には、この問題が具体的な数字で表れている。2025年12月1日の料金告知に続き、12月3日にはファシリテーターの最低決済額0.001米ドルが記載された。2026年1月1日からは、月1,000件の無料枠を超えた取引に1件0.001米ドルの課金が始まった。
現在の課金単位は正確に理解する必要がある。CDPの0.001米ドルは、APIリクエスト数ではなくオンチェーン取引数に対する料金だ。検証は無料なので、同じAPI呼び出し量でも、精算の設計次第で課金される取引数は変わる。
また、x402がすべてのサービスに同じ手数料を課すわけではない。プロトコルとファシリテーターの商用料金は別だ。CDPの数字は、エコシステム全体の固定費ではなく、製品の決済・精算構造を評価する具体例として捉えるべきだ。
0.001米ドルを稼ぐために0.001米ドルを払うなら
無料枠を超え、各リクエストで有料のオンチェーン精算が一件発生し、売り手が費用を負担すると仮定しよう。一回の価格が0.001米ドルなら、同額のファシリテーター費用だけで売上の100%を使う。0.01米ドルでも比率は10%だ。
これは売上に占める手数料の比率であり、ROI全体の計算ではない。計算資源、データ、運用にかかる費用まで含めると、残る金額はさらに減る。単価の低いAPIほど、一件の決済処理の固定費が収益性を大きく左右する。
手数料が一定なら、総費用は取引数に比例して増える。規模が大きくなるだけで一件当たりの費用が自動的に下がるわけではない。人間より高い頻度で呼び出すエージェントでは、リクエスト単位をそのまま精算単位にする設計を慎重に検討すべきだ。
V2がセッションと前払いに道を開いた理由
2025年12月11日発表のx402 V2は、一回限りの決済からより広いモデルへ展開した。ウォレットに基づく再利用可能なアクセス、セッション、前払い、サブスクリプション型のフローの基盤を整え、反復利用のたびに決済全体をやり直さない方向を示した。
公式発表が高頻度ワークロードの費用と遅延に直接触れている点は重要だ。LLM推論や複数のツールを続けて呼び出すエージェントでは、一回ごとに独立した決済手続きを待つ構造が負担になり得る。
私はこれを、課金の体験と資金移動を分ける設計だと読む。利用量はリクエスト単位で計測・価格設定しながら、アクセス権を再利用し、実際の精算回数を減らす。無料枠の存在だけで内部の採算判断は断定できないが、製品の経済性を設計する際に減らすべき処理は見えてくる。
小さく利用し、まとめて精算する
現在のCDP文書は、バッチ精算を一つの解決策として説明している。リクエストごとのバウチャーをオフチェーンで検証し、一回のオンチェーン取引でまとめて請求できる。多くのリクエストを処理しても、その都度ファシリテーターの精算手数料が発生する必要はない。
もちろん、まとめるだけですべての費用が消えるわけではない。チャネルへの入金、返金、出金もオンチェーン取引として数えられ得る。比較すべきなのは、一定の利用量を処理するために、実際には何回の資金移動と精算が必要かだ。
この観点では、マイクロペイメントの核心は精算の頻度を下げることにある。利用量を小さな単位で記録し、精算はまとめられる。リクエスト単位の料金を維持しながら、毎回個別に精算する費用を避ける方式だ。
資金確保 → 利用 → 後精算
より現実的な製品モデルは、先に資金を確保するか一定額の利用を承認し、その範囲内で繰り返しサービスを使い、実際の利用量で後から精算する構造だ。対応する仕組みがあれば、残額は返金できる。
前払い残高から引き落とす方式もあれば、一定額をロックしたり利用限度を承認したりして後から精算する方式も考えられる。どれを選ぶ場合も、利用可能額、許可する支払先、有効期間、返金条件を明確にする必要がある。これらは各サービスが実装すべき設計だ。
これにより、エージェントは毎回人の決済承認を待たずに動き、呼び出し頻度とオンチェーン精算回数を切り離せる。ただし、資金が拘束される負担やチャネル開閉の費用も比較する必要があり、すべてのサービスに同じ方式が最適とは限らない。
x402の可能性は依然として大きい。ただ、リクエストごとの決済がすべてのオンラインサービスの基本経済モデルになると期待するより、何をリクエスト単位で測り、いつ資金を動かすかを分けて設計すべきだ。私が現実的だと考えるのは「資金確保 → 利用 → 後精算」である。x402はサブスクリプションを単純に置き換えるより、サービスの使い方に合わせて決済の選択肢を広げている。