論文は特に、これらの脆弱性が「x402プロトコル自体の設計上の欠陥」ではなく「facilitatorおよびサーバー実装における弱点」であると強調している——この区別には実際にどのような重要性があるのか？
この区別は、誰が責任を負うべきか、そして問題を完全に解決できるかどうかを左右する。もし脆弱性がプロトコル仕様そのものにあったなら、x402標準全体の設計ロジックに根本的な問題があることを意味し、プロトコルレベルでの再設計が必要になり、この標準に従うすべての実装が影響を受け、修正にかかる調整コストは非常に高くなる。しかしこの研究が発見した問題は、異なる事業者がそれぞれ「仕様を実際に動くコードに変換する」という工程で、セキュリティルールに適合しない実装上の判断を下していたというものだ——これはx402というこの設計自体は合理的であり、問題は実装面にあることを意味し、理論上は各事業者がプロトコル全体の再策定を待たずに、それぞれ独立して自社の実装を修正できるということになる。
しかしこの朗報には限界もある。問題がそれぞれ独立した実装の中に散らばっているため、「プロトコル設計に問題はない」ことは「ユーザーは安心してよい」ことを意味しない。むしろ、各facilitatorの安全性のレベルは、その事業者自身のエンジニアリング品質に依存しており、ユーザーは「このサービスはx402標準に準拠している」という一言だけでは、それが安全だと推測することはできない。この標準自体は、すべての実装が稼働開始前にこの研究のようなブラックボックステストに合格することを義務づけてはいない。
Coinbaseのような大手事業者は理論上、セキュリティに投じられるリソースが多いはずなのに、なぜこの研究で脆弱性を見つけられてしまったのか？これは何を意味するのか？
この研究が明らかにした核心的な事実の一つは、x402 facilitatorが比較的新しいタイプのインフラであり、従来の決済システム（クレジットカードの決済ネットワークなど）と似た責任を負っているものの、この役割が対処すべき攻撃対象は、AIエージェントによる自動決済というまったく新しい場面とともに初めて登場したものだ、ということだ。従来の決済セキュリティの経験が、「支払う側がリアルタイムで人間による監視のないソフトウェアである」という状況にそのまま応用できるとは限らない。研究チームが定義した8つのルールのうち、いくつか（「決済前の再検証」など）は、まさにこの新しい場面に特有のタイムラグリスクを狙ったものだ。支払い証明が生成された瞬間から、それが実際に決済に使われる瞬間までの間にタイムラグがあり、システムが決済前にその証明がまだ有効かを再確認していなければ、そこが悪用され得る。この種の問題はリソースの多寡だけで解決できるものではなく、この種の新興リスクに対する業界全体の体系的な理解が、まだ初期段階にあることを反映している。
注目すべきは、Coinbaseが問題を指摘された後、期限内に対応と修正を行ったことで、これ自体が責任ある開示の仕組みが正常に機能した一例だといえる。リソースの多い事業者も新興リスクの落とし穴を踏むことは他と変わらないが、通知を受けた後はより迅速に修正を完了させる能力を持っていることが多い。ユーザーにとっての実際的な意味は、単に「この事業者がどれだけ大きいか、どれだけ有名か」を見るのではなく、「この事業者が過去にセキュリティの開示に直面した際、どれだけ迅速かつ透明性を持って対応・修正してきたか」を具体的に見ることだ。
「無料ショッピング」と「資産盗難」という2つの攻撃は、影響を受ける対象が違うように聞こえる——一方は加盟店が損をし、もう一方はユーザーが損をするということか？自分はどちらを心配すべきか？
その区別は正しく、それぞれが誰に対してより大きなリスクをもたらすのかを分けて理解する価値がある。無料ショッピング攻撃で直接被害を受けるのは、サービスや商品を提供する加盟店（x402エコシステムにおける売り手側）だ。攻撃者は脆弱性を悪用し、有効な支払いを完了させないまま、本来支払いが必要なはずのものを取得してしまう。加盟店の損失は「受け取るべきだったお金を受け取れなかった」ことにある。一方、資産盗難攻撃の被害対象はfacilitator自身が保有する資産だ。もしあなたのエージェントが単にx402でサービス代金を支払っているだけなら、通常のフローでは資金のほとんどの時間はあなたのウォレットから加盟店へ直接移動しており、長時間facilitatorに預けられているわけではない。そのため、資産盗難が一般ユーザーに与える直接的なリスクは、通常facilitator自身や加盟店に与えるリスクより小さい。
しかし、これはユーザーがまったく心配しなくてよいということではない。本記事のタイトルで強調されている「ガス濫用」こそが、一般ユーザーの財布に最も直接的に影響し得る攻撃タイプだ。もしあなたのエージェントが使っているfacilitatorにガス代のスポンサー機構があり、その上限が正しく執行されていなければ、理論上はコスト構造に穴が開いていることになる。その穴を最終的に誰が吸収するかにかかわらず、それは将来あなたがそのサービスを利用する際の料金や条件に反映される可能性がある。ユーザーが最優先で確認すべきなのは、自分が実際に使っているfacilitatorが、「スポンサーされるガス代に明確な上限があるか」という点について、具体的な技術的コミットメントを示しているかどうかだ。
研究チームがどの脆弱性がどの事業者に対応するかという詳細な技術情報を公開しないことを選んだのは妥当なのか？一般ユーザーは、自分が使っているfacilitatorが実際に修正されたかどうかをどうやって知ればよいのか？
これはセキュリティ研究の分野における標準的な責任ある開示の原則であり、特例ではない。まだ完全に修正されていない脆弱性の具体的な技術詳細を公開することは、この論文をまだ読んでいない悪意ある行為者に攻撃の手引きをそのまま渡すことに等しく、それがユーザーにもたらすリスクは、詳細を曖昧にしておくことの不便さをはるかに上回る。研究チームの取ったアプローチ——まず影響を受ける事業者に非公開で通知し、合理的な修正期間を与え、事業者自身が公に対応することを選んだ場合（Coinbase、PayAI、Mogamiの3社がすでに行っているように）にのみ詳細が表に出る——は、それ自体がユーザーを守る仕組みであり、問題を隠蔽するものではない。
一般ユーザーにとって実務上できることは、論文の技術詳細が公開されるのを待つことではなく、自分が使っているfacilitatorに対していくつかの具体的な質問を能動的に投げかけることだ。この研究チームが実際にテストした対象に含まれていたか。含まれていた場合、その事業者は開示内容に対して公式な声明を出しているか。その声明には、具体的に何を修正したかが明記されているか。セキュリティ開示に対して、たとえ自社にかつて脆弱性があったことを認める形であっても、オープンで透明性のあるコミュニケーションを取る事業者は、一般的に、まったく公式な対応を示さない事業者よりも信頼に値する。沈黙は問題がないことを意味するのではなく、単にユーザーが判断材料となる情報を得られていないことを意味するにすぎない。
スイス連邦工科大学ローザンヌ校（EPFL）と浙江大学の研究チームによる論文が、トップクラスのセキュリティ会議USENIX Security 2026に採択された。この論文は、主要なx402中継検証者（facilitator）15社に対する初の体系的なセキュリティ評価を実施し、その結果、15社すべてが少なくとも一つの重要なセキュリティルールに違反しており、合計で31件の未公開だった脆弱性が発見された。この15社のfacilitatorは合わせて6万人以上の売り手と36万人以上の買い手にサービスを提供しており、研究期間中に観測された取引量の99%をカバーしていた。7月末の論文公開後、業界内で急速に注目を集め、Coinbaseを含む影響を受けた事業者の一部はすでに問題を確認し、修正を完了している。
研究チームはまず、facilitatorが重要な共有決済インフラとして理論上守るべき8つのセキュリティルールを定義した。支払い証明がサーバー要件に確実に紐づいているか、支払い者の承認が本物か、鮮度（有効期限）のチェック、決済が正当な根拠に基づいているか、無意味な支払い証明を迅速に拒否できるか、スポンサーされる実行のガスに上限があるか、決済前に再検証が行われるか、決済のセマンティクスがホワイトリストによって制約されているか、といった項目だ。その後、チームは半自動化されたブラックボックステストツールを開発し、実験室環境でのシミュレーションのみに頼るのではなく、実際に展開されている15社のfacilitatorに対してテストを行った。
ルール違反のパターンの分析に基づき、研究チームは4つの新しい攻撃ベクトルを導き出した。「無料ショッピング（Free Shopping）」は、買い手が有効な支払いを完了することなく商品やサービスを取得できてしまうもので、加盟店に直接的な金銭的損失をもたらす。「資産盗難（Asset Theft）」は、攻撃者がfacilitator自身が保有する資産を盗み出せるというものだ。「サービス拒否（Service Denial）」は、正常な決済フローを妨害・中断させる。「ガス濫用（gas Abuse）」は、facilitatorがガス代を代わりに支払う仕組みを悪用し、スポンサー側に無制限のオンチェーン手数料負担を押し付けるものだ。これら4つの攻撃はいずれも、x402プロトコル自体の設計上の欠陥ではなく、実際のfacilitatorおよびサーバー実装における弱点を狙ったものだ。つまり、問題は「仕様がどう実装されたか」にあり、「仕様そのものが間違っていた」わけではない。
研究チームは2026年1月の時点ですでに、発見した問題を14社の影響を受ける事業者へ責任を持って開示しており、2月6日までにCoinbase、PayAI、Mogamiの3社が合計6件の脆弱性を確認し、一部の修正を完了させていた。論文発表時点でまだ修正されていない脆弱性もあったため、研究チームは完全な修正が完了する前に悪用されるのを防ぐため、どの脆弱性がどの事業者に対応するかという具体的な技術詳細は公開しないことを選んだ。
あなたのエージェントがx402を通じて何らかの自動決済を行っているなら、この研究はいくつか具体的に確認・質問できる方向性を示している。あなたが使っているfacilitatorが、研究チームが実際にテストしたこの15社のうちの一つかどうか——もしそうであれば、その事業者がすでに公に対応し、修正を完了させているかを直接確認する価値がある。この研究の対象に含まれていたかどうかにかかわらず、そのfacilitatorに対して、「決済前に支払いの有効性を再検証しているか」と「スポンサーされるガス代に明確な上限があるか」という2点について、具体的にどのような防護策を講じているかを能動的に尋ねることができる。これはまさに、研究チームが最も悪用されやすいと指摘した2つの領域だ。この研究から得られる最も重要なメッセージは、どこか特定の事業者が特に危険だということではなく、「エージェント決済経済の共有中間層であるfacilitatorが、テストされた15社すべてにおいて少なくとも一つのルールを守れていなかった」という事実そのものだ。x402エコシステムに依存するあらゆるユーザーにとって、これは単に知名度の高いfacilitatorを選ぶことが、安全性が証明されたサービスを選ぶことと同じではない、ということを意味する。