x402とは？AI決済の仕組み・使い方と自動課金の注意点

AIエージェントにAPIを使わせるとき、毎回人がアカウントを作り、APIキーを発行して渡す必要があるのでしょうか。x402は、HTTPの「402 Payment Required」を使い、必要なリソースへの支払いをリクエストの流れに組み込むオープンな決済プロトコルです。

結論から言えば、x402は「AIが無制限に安全に支払える仕組み」ではありません。サービス側が提示した条件をクライアントが確認し、ウォレットが支払いを承認して、検証後にリソースを受け取るための標準です。利用料金の上限や人間の承認は、別途アプリケーション側で設計する必要があります。

この記事では、従来のAPI課金との違い、支払いが成立するまでの5段階、CoW Protocolの公開事例、費用の考え方、v1からv2への変更点を整理します。公式資料の仕様をもとに解説し、実際のAPI呼び出しや支払いを試した結果としては扱いません。

x402とは？HTTP 402を使う決済プロトコル

x402は、APIやウェブサービスがHTTPリクエストに対して支払い条件を提示し、クライアントがプログラムから支払えるようにするオープンな決済標準です。名称の「402」はHTTPステータスコード「402 Payment Required」に由来します。x402の仕様そのものはApache-2.0ライセンスで公開され、特定の取引所や単一の決済会社だけが利用できる製品ではありません。

この方式は、呼び出し単位で価格を設定しやすく、アカウントやAPIキーの発行フローを省ける点が特徴です。AIエージェントやサーバー間通信のように、人が都度ログインしない用途にも適します。ただし、支払い先が信頼できるか、返されるデータに価値があるか、実行回数を制御できているかは、プロトコルだけでは保証されません。

従来のAPI料金とx402を比較

従来型のAPIキー課金は、月額契約や組織管理、継続利用の予算管理に向いています。一方、x402は支払い条件をリクエスト時に扱えるため、アカウント登録なしの従量利用や、小さな単位の機械間決済に向く設計です。どちらが優れているというより、利用形態と管理要件が異なります。

また、x402が「キー不要」と説明される場合でも、支払いを行うウォレットの署名機能や秘密鍵管理まで不要になるわけではありません。APIキーを配らずに済むことと、認証・権限・セキュリティ設計が不要になることは別です。

支払いが完了するまでの5段階

x402の基本フローは、サービスへのアクセス要求、HTTP 402による支払い条件の提示、支払い情報の準備と送信、支払い検証・決済、リソース提供の順です。以下は公式ドキュメントの概念図を、利用者側の確認点と合わせて簡略化したものです。

1. クライアントがリソースを要求する

クライアント（人が操作するアプリやAIエージェント）が、データやAPIエンドポイントにHTTPリクエストを送ります。この時点で無料公開されていれば通常のレスポンスが返ります。有料のリソースなら、次の段階で支払い条件が提示されます。

2. サービスが402と支払い条件を返す

サーバーはHTTP 402とともに、金額、受取先、ネットワーク、トークン、支払い方式などの条件を返します。クライアントは、金額だけではなく、要求元のドメイン、受取先、チェーン、トークン、条件の有効期限など、実装で提供される情報を確認する必要があります。

3. ウォレットが支払い情報を準備する

条件がポリシー内であれば、対応するクライアントやウォレットが支払い用のペイロードを作り、必要な署名を行います。これは単にAPIキーをHTTPヘッダーに付けるのとは異なり、資産を動かす権限に結び付く処理です。

秘密鍵をAIチャットの入力欄へ貼り付けてはいけません。鍵や署名権限は、権限を限定した署名サービスや安全な実行環境で管理し、エージェントに無制限の鍵操作権を持たせないことが重要です。

4. サーバーまたはfacilitatorが検証・決済する

サーバーは受け取った支払い情報を自ら検証・決済するか、x402 facilitatorの検証・決済機能を利用します。facilitatorは支払い処理の一部を担うサービスで、x402仕様自体と同じものではありません。利用するfacilitatorの運営者、対応ネットワーク、可用性、プライバシー条件も別途確認対象です。

5. 支払い確認後にリソースを受け取る

支払いが有効と確認されると、サーバーが要求されたデータや処理結果を返します。失敗時に再試行する実装では、タイムアウトや応答消失の際に二重課金が起きないか、リトライの条件や識別子を確認してください。

一度の支払いで複数回分を処理するバッチ方式など、支払いスキームによって具体的な流れは変わります。「HTTP 402に応答したら必ず即時にオンチェーン取引が一件発生する」とは限らず、採用方式とサービスの実装が判断材料になります。

CoWのx402事例：1 quote 0.001ドル

2026年10月9日付のCoW DAO公式発表では、CoW Protocolのquote APIに、ボットやAIエージェント向けのx402対応経路「x402.cow.fi」を追加したと説明されています。発表時点の料金は1 quoteあたり0.001米ドルで、APIキーやアカウント登録を前提にしない従量アクセスとして案内されています。

同発表では、クライアントが最初に1米ドル相当のUSDCを用意し、以後のquoteごとに署名を行う仕組みを説明しています。毎リクエストごとに個別のガス支払い・取引を行うのではなく、後からまとめて決済する方式です。ただし、これはCoWの特定サービスが発表した条件であり、x402全体の標準料金や全サービス共通の決済方式ではありません。

支払いに使うチェーンと、quoteを取得する対象チェーンは独立すると公式発表に記載されています。つまり、あるチェーン上で支払いながら、別の対応ネットワークを対象とするquoteを問い合わせられる設計です。具体的にどの支払資産・チェーンが使えるかは、利用時に公式ドキュメントで最新条件を確認してください。

同じ発表は、フロントエンドや人間の利用を想定した無料の api.cow.fi と、パートナー向けのAPIキー経路にも触れています。したがって「CoWのquote APIはすべて有料」ではありません。まず無料APIの利用条件やレート制限を確認し、キーなしの自動利用が必要な場合にのみx402経路と比較するのが自然です。

費用試算：1,000回・1万回・10万回

CoW公式発表時点の0.001米ドル/quoteを単純に掛けると、1,000回で1ドル、1万回で10ドル、10万回で100ドルです。これは一定単価が全呼び出しに適用されると仮定した算術例で、実際の利用量や請求額を測定した結果ではありません。

また、CoW以外のx402サービスでは価格設定、無料枠、ネットワーク、決済頻度が異なります。利用前に、課金単位が成功したレスポンスだけなのか、失敗・再試行も対象か、プリペイド残高の扱いや返金条件はどうかを確認します。単価が小さく見えても、エージェントのループや異常な再試行で呼び出しが増えれば、総額は想定を超えます。

試す前に確認したい準備

最初から本番ウォレットに資金を入れるのではなく、まずサービスの無料経路や無料枠がないか確認します。CoWの例なら、公式発表が案内する無料APIとx402の用途・レート制限を比較できます。無料で要件を満たせるなら、決済機能を追加しないほうが管理対象を減らせます。

1. 無料利用を確認：公式ドキュメントで無料枠、APIキー方式、レート制限を調べます。
2. テストネット対応を確認：自分が使うクライアント・サービス・ネットワークの組み合わせがテストネットに対応しているか確認します。テストネットの存在を、対象サービスがテスト利用できる証拠と取り違えないようにします。
3. 上限と承認を設計：1回あたり・日次・総額の上限、呼び出し回数、許可ドメインを設定し、初期段階は人間の承認を必須にします。
4. 必要になってから本番へ：料金条件、支払先、ネットワーク、失敗時の挙動を確認し、専用の少額ウォレットで最小範囲から始めます。

テストネットは実際の資産を使う本番ネットワークとは異なります。また、サービス側の環境がテストネットに対応していない場合もあります。テストネットで動作確認できたとしても、本番への移行時はアドレス、チェーンID、トークン、支払い条件を改めて検証してください。

この記事の作成にあたり、テスト呼び出しや支払いは実施していません。そのため、画面操作の実測、決済時間、実際の手数料、成功率は報告できません。仕様・利用条件は変更されることがあるので、実装前に各公式ドキュメントを再確認してください。

古いv1とv2の違い

x402を実装する際は、バージョンの違いを無視できません。公式移行ガイドでは、v1からv2にかけて支払いヘッダー、レスポンスヘッダー、ネットワーク識別子、パッケージ構成が変更されています。チュートリアルのコードだけを切り貼りして、異なる世代のクライアント・サーバーを混ぜると、ヘッダーを読み取れない、ネットワーク指定が認識されないといった問題につながります。

v2のネットワーク識別子はCAIP-2形式を使います。たとえばBase Sepoliaはeip155:84532、Base mainnetはeip155:8453と記載されます。旧形式の文字列を使うサンプルをv2の設定にそのまま持ち込まないよう、利用SDKとサーバーの両方で形式をそろえます。

移行ガイドは、facilitatorがv1とv2の双方を扱える場合があると説明していますが、すべての組み合わせや機能の互換性を保証する趣旨ではありません。クライアント・サーバー・facilitatorの対応バージョン、使用するスキーム、対象チェーンをそれぞれ確認します。独自にHTTPヘッダーを処理する場合は、v2の名称へ更新できているかも点検してください。

AIの自動課金を抑える安全ルール

AIエージェントに支払い機能を追加すると、処理を自動化できる一方で、課金判断の頻度と速さも増します。ウォレット残高を少額にするだけでは、全損害の上限を保証できません。複数の資産・アカウントにアクセスできる、再試行が連鎖する、別のシステムに損失が及ぶなど、残高以外の影響も考慮が必要です。

まず、エージェントの説明文だけに頼らず、支払い要求を機械的に拒否できるポリシーを用意します。提供者の許可リスト、チェーン・トークンの許可、1回の上限、時間あたりの回数制限、累積上限を分けて設定すると、どこで拒否されたかを監査しやすくなります。

許可先と支払い上限のポリシー例

下表は設計を考えるための例であり、特定のSDKでそのまま動く設定ファイルではありません。利用サービスが対応していない条件や単位があれば、その機能があると想定せず、プロキシや呼び出し元アプリ側で強制できるかを確認してください。

上限値は例にすぎず、用途、為替変動、決済方式、トークンの価格変動を踏まえて利用者が定める必要があります。日次上限を実装していても、複数プロセスがそれぞれ独立に支払えば上限が合算されない設計になり得ます。すべての実行経路を一元的に計測・制御できるか確認してください。

• 秘密鍵やシードフレーズをAIチャット、ログ、ソースコード、公開リポジトリに貼らない。
• 人間の承認なしで任意の金額・宛先に署名する権限を、エージェントに渡さない。
• 本番用とテスト用の資格情報・ウォレットを分け、専用ウォレットは必要最小限の権限にする。
• 料金条件、ドメイン、受取先、ネットワークが想定外なら自動決済を停止する。
• タイムアウト時の再送と二重支払いを考慮し、リトライ回数や重複排除の仕組みを確認する。
• 利用ログ、承認履歴、累積額を記録し、異常検知時に鍵・支払い機能を止める手順を用意する。

支払いを完了したからといって、期待した内容が返る、サービスが継続する、返金を受けられる、資産が保全されるといった保証にはなりません。料金、返金・異議申立ての窓口、データの利用条件、運営者情報を個別に確認してください。x402の標準手数料が0であることと、利用時の費用・リスクが0であることも同じではありません。

よくある質問

まとめ

x402の実用性は、登録を省けるかだけでなく、支払い条件を誰が検査し、上限をどこで強制し、失敗時にどう止めるかで決まります。無料の方法から確認し、テスト可能な範囲で拒否動作を確かめ、必要な場合だけ小さく本番運用へ進めるのが現実的です。

AIエージェントとAPI連携の全体像を深める場合は、Financial Datasets MCPとClaudeの記事、Perplexity MCPとClaude Codeの記事も参考にしてください。取引ボットを扱う際の自動化リスクは、HyperliquidボットとClaude Codeの記事で紹介しています。いずれもx402の利用を推奨するものではなく、各サービスの条件は公式情報でご確認ください。

出典

• x402公式ドキュメント：Introduction（プロトコル概要、基本フロー、標準手数料）
• x402公式ドキュメント：Migration Guide V1 to V2（ヘッダー、CAIP-2、移行上の差異）
• x402公式ドキュメント：FAQ（価格方式、ネットワーク、facilitator等）
• CoW DAO公式発表：Introducing x402.cow.fi（2026年10月9日発表の個別料金・利用条件）