x402は、私たちが普段使っているクレジットカードの自動引き落としやサブスクリプション決済と、本質的に何が違うのか？
クレジットカードの自動引き落としは「既存のアカウント関係がある」ことを前提としている——まず加盟店やプラットフォームとアカウントを結び、カードを紐づけてから初めて引き落としが始まり、銀行やカード発行会社自体が審査機構として機能し、異常な引き落としをリスク管理システムが検知したり、事後に異議申し立てをしたりできる仕組みがある。x402は「アカウント関係を結ぶ」というステップを完全に飛ばす。エージェントは初めて遭遇したリソースに対して、事前登録なしに、そして裏でリスク審査を行う発行機関もないまま、その場で支払いを行える。
この違いが直接もたらす結果はこうだ。クレジットカードのシステムでは「引き落としへの異議申し立て、返金請求」は明確な手順を伴うユーザーの既存の権利である。一方x402の支払いは、いったんオンチェーンで決済が完了すれば、取り消し不能なステーブルコイン送金であり、組み込みの異議申し立て機構は存在しない。だからこそx402は「少額、高頻度、1件あたりの金額が異議申し立てのコストに見合わないほど低い」場面（1回のAPI呼び出しが数セントなど）に特に適している。これが大口の支払いに使われた場合、リスクの構造はまったく別物になる。
なぜエージェント間決済にはまったく新しいプロトコルが必要なのか？人間がすでに使っている決済手段（クレジットカードAPIなど）をそのままエージェントに使わせてはいけないのか？
理論上は可能だが、そこには根本的なミスマッチがある。人間の決済手段（クレジットカード、銀行振込）はいずれも「責任を負える一人の人間」を中心に設計されている。本人確認、与信審査から異議申し立ての処理まで、システム全体が「取引の一方は追跡可能で、責任を問える自然人または法人である」ことを前提としている。支払う側も受け取る側も両方エージェントで、取引頻度が1秒間に何件も、1件あたりの金額がわずか数セントというような場合、人間向けに設計されたこのシステムでは、本人確認とアカウント作成のコストだけで取引そのものの金額をはるかに上回ってしまう。
x402が成立するのは、まさにこのロジックを逆転させているからだ。相手が誰かを事前に知る必要はなく、アカウントを作る必要もない。暗号署名によって「この支払いは確かに承認されたものである」ことを直接証明し、検証と決済はいずれもオンチェーンで行われ、中央集権的な本人確認機関に依存しない。これは「規模」の問題を解決するが、まさに本人確認という層を取り除いたからこそ、本記事で触れたリプレイ攻撃やプロンプトインジェクションといった新しいリスクが生まれる。これは問題を解消したのではなく、ある問題を別の問題と交換しているにすぎない。
本文で触れた「支払いリプレイ攻撃」は実際にはどのように起きるのか？一般的な暗号資産送金のリスクとは何が違うのか？
一般的なオンチェーン送金では、各取引には固有の署名とノンス（重複実行を防ぐための連番の仕組み）があり、同じ取引を理論上は二度送信できない。x402の支払いリプレイ攻撃が狙うのは、基盤となるブロックチェーンの送金メカニズムそのものではなく、x402プロトコル層における「支払い認証情報」と「リソースリクエスト」の対応関係だ。もし特定の実装が各リクエストを一度限り使用可能な支払い認証情報と厳密に紐づけていなければ、攻撃者は正当な支払い認証情報を傍受し、本来一度しかアクセスできないはずのリソースやサービスに再利用できてしまう——同じ支払いで、複数回サービスを受け取ることになる。
これが単純なブロックチェーン送金のリスクと異なるのは、問題が根底の暗号アルゴリズムではなく、プロトコル層のロジック設計にあるからだ。これがまさに、セキュリティ研究者がx402のセキュリティリスクはアプリケーション層（つまりfacilitatorの検証ロジックとサーバー側のリクエスト処理）で対処する必要があり、根底のブロックチェーン自体のセキュリティによって自動的にカバーされるものではない、と強調する理由でもある。
自分のエージェントにx402を使った自動支払いを始めさせる場合、何か問題が起きてから対処するのではなく、実務上優先的に設定すべき防護策は何か？
3つの優先順位を提案する。第一に、エージェントに無制限で自律的に支払わせるのではなく、「人間の承認が不要」な支払い上限をまず設定すること——その上限は「全部騙し取られても惜しくない」金額に設定し、それを超えたら強制的に人間の確認に戻す仕組みにする。これは最も直接的で、他の技術的手段に依存せずに機能する防衛線だ。第二に、自分が使っているx402の実装（エージェントフレームワークやウォレットツール）が、支払いリクエスト内のメタデータ（リソースURL、説明、支払い理由）をすでにフィルタリングまたはサニタイズしているかを確認すること——隠された指示のテキストがエージェントに正当な文脈として誤認されるのを防ぐためだ。確信が持てない場合は、ツールの提供元に直接尋ねればよい。これは明確な回答を求めてよい質問である。第三に、完全な支払い記録を保持し、定期的に照合すること——「機械対機械の支払いには監査が不要」と決めつけてはならない。事後の監査こそが、攻撃が発生した後に被害の範囲を把握し、原因を明らかにできる唯一の仕組みだ。
この3つの防護策に共通するロジックは、「支払いミスを防ぐ」責任を、「エージェントの判断を信じる」ことから、「エージェントが誤った場合の最大の影響範囲を制限し、事後に検証可能な記録を残す」ことへと移すという点だ——これは本サイトがBankr事件やMetaMask Agent Walletの記事で繰り返し強調してきた原則と一致している。
AIエージェントが別のエージェントの有料APIを呼び出す必要がある場合、あるいは別のエージェントからサービスを購入する場合、従来のやり方は、人間のユーザーがまずそのプラットフォームでアカウントを登録し、クレジットカードを紐づけ、残高をチャージするというものだった——この一連の流れは「間に人間が介在して支払いを処理する」ことを前提としている。x402プロトコルが解決しようとしているのは、まさにこの前提だ。人間の介入をまったく必要とせず、エージェントがステーブルコインでリクエストごとの少額決済を直接完了できるようにする。
x402という名前は、HTTPステータスコード402「Payment Required（支払いが必要）」に由来する——このステータスコードはHTTPプロトコル内で数十年前から存在していたが、実際にはほとんど使われてこなかった。x402プロトコルはこれを再び活性化させる。エージェントがあるリソースをリクエストし、サーバーが支払いを要求する場合、サーバーは402ステータスと支払い要件を付けて応答する。エージェントはその要件を読み取り、ステーブルコインの支払い承認に署名し、支払い証明をリクエストに添付して再送信する。サーバーは支払いを検証し、それが完了して初めて要求されたリソースを返す。この一連のサイクルは数秒で完了し、アカウント登録は不要で、人間が確認ボタンをクリックする場面もループのどこにも存在しない。
現在、x402の取引の大半はUSDCで決済されており、BaseとSolanaが最もよく使われる決済チェーンだ。Coinbaseが主導し、Cloudflareが支援するx402ファウンデーションは、このプロトコルをエージェント間決済の共通標準として確立しようと推進しており、2026年第1四半期時点で、このプロトコルの年換算取引量は約6億ドルと推定されている。
x402の最大の売りは、人間の承認なしに機械の速度で決済を完了することだが、その売りこそが最大のリスクの源でもある。すべてのx402支払いには、リソースURL、説明、理由という3つのメタデータフィールドが平文で伝送される。これらはオンチェーン決済が完了する前に、支払いサーバーと仲介検証者（facilitator）へ暗号化されないまま送信される。セキュリティ研究者はすでにいくつかの具体的な脆弱性クラスを整理している。支払いリプレイ攻撃（同一の支払い認証情報の再利用）、過払いによるウォレット枯渇、プロンプトインジェクションによるエージェントへの不正な支払いの誘発、そして取引グラフのリンク可能性を通じたプライバシー漏洩だ。
これらの問題に共通しているのは、このプロトコルの設計目標が「機械が中断される頻度をできる限り減らすこと」にある一方で、従来の決済システムにおいて「人間が一目見てから確認をクリックする」というステップは、もともと異常な支払いを検知する最後の防衛線だったという点だ。x402はこの防衛線を取り除く代わりに速度を得ている。これはつまり、エージェントの判断ロジックを騙せる手法であれば何であれ、途中で誰かが「待った」をかけることなく、そのまま実際の資金損失へと直結してしまうことを意味する。
あなたのエージェントがx402（あるいは類似のプロトコル）を使ってAPIアクセスやデータサービスを自動的に購入したり、他のエージェントと決済したりしているなら、確認すべき具体的な点がいくつかある。あなたのエージェントは、1回あたりの支払い金額に上限を設けており、一定の閾値を超えたら強制的に人間の承認に戻る仕組みになっているか。支払いリクエスト内のリソースURL、説明、理由といったフィールドは、送信前にフィルタリングされ、悪意ある指示が紛れ込むのを防いでいるか。そして、どの支払いがエージェントに本当に必要だったサービスで、どれが異常な支出だったのかを照合するための明確な支払い記録を実際に取得できるか。x402はエージェント間の商取引を可能にするが、「機械対機械」は「監督が不要」を意味しない——監督の形が「1件ごとに人間がクリックする」から「自分自身で境界線と事後の監査の仕組みを設計する」へと変わるだけである。