エージェント間決済が実は完了していない——x402の31件の脆弱性が示した外部連携の落とし穴

AIエージェントや外部サービスに仕事を頼んだとき、返ってきた「完了しました」を、どうやって確かめていますか。多くの実装が確認しているのは「返事が返ってきたこと」であって、「仕事が本当に終わったこと」ではありません。今回の論文は、この差が失敗として見えやすい機械間決済を大規模に実測しました。USENIX Security 2026で発表された研究です。

これは決済だけの話ではありません。AIエージェントが外部のサービスや別のAIエージェントに仕事を頼んだとき、その仕事が本当に終わったのかを、頼んだ側が確かめられないという構造の問題です。たとえば、外部のエージェントに在庫引当やデータ登録を頼み、「完了しました」という返事を受けて自社側で次の処理へ進むケースです。返事が来たことだけを完了の根拠にすると、x402と同じ形のズレが起こり得ます。

この記事では、こうして仕事を外部に任せることを「委任」、頼まれる外部サービスやエージェントを「委任先」と呼びます。以降はこの言葉も使いますが、意味は「外部に仕事を頼むこと／頼まれた相手」です。

「支払い確認OK」は、入金を意味しない

x402は、HTTPの 402 Payment Required を使ってAPIやリソースへの支払いを自動化するオープン標準です。買い手（多くはAIエージェント）が署名済みの支払いデータを送り、売り手のサーバーはそれをファシリテーターと呼ばれる第三者に渡して検証してもらい、実際のブロックチェーン上の決済もその第三者に委ねます。

問題は、この流れが一度で完結しないことです。

3と5のあいだには、トランザクションの構築、ブロードキャスト、ネットワーク伝播、ブロックへの取り込みという実時間の遅延があります。2で「有効」と言われたことは、4が成功することを保証しません。論文はこの意味的なギャップを起点に、実装がどう壊れるかを体系的に調べました。

この構造を、自社のAIエージェント連携に置き換える

ここで、x402を使っていない自社システムに置き換えてみます。決済の「検証」と「成立」のズレは、外部サービスやAIエージェントに仕事を頼む場面にもほぼそのまま対応します。

x402が示したのは、この差を埋める仕組みを設計しないと、失敗が静かに通過してしまうということでした。決済では失敗が金額として即座に見えます。それ以外の委任では、見えないまま蓄積します。

仲介先を選び直しても回避できない

論文の著者らは半自動検査ツール X402SCOPE を使い、主要ファシリテーター15社を外部から検査しました。

49件の規則違反は、手動確認を経て31件の新規脆弱性に整理されました。重要なのは、特定の一社だけの問題ではなく、15社すべてが少なくとも1つの規則に違反していたことです。

つまり「評判の良い仲介先を選ぶ」だけでは回避できません。委任先を信頼することと、委任結果を検証できることは別です。

外部に任せた処理が失敗したとき、誰が損をするか

検出された違反から、論文の著者らは4つの攻撃ベクトルを導きました。注目したいのは攻撃手法そのものより、損失が誰に着地するかです。

ここで一つ、断っておくべきことがあります。この表では、仕事を頼んだ側だけが損をする行はありません。 x402では支払う側よりも、受け取る側（売り手）や決済を仲介する側に損失が出やすいからです。ただし、決済を伴わない外部連携では話が変わります。外部サービスやAIエージェントに処理を任せ、その返事を受けて自社の処理を進める場合、「完了した」という報告を信じて次に進むのは自社側です。同じ確認不足が、今度は自社の損失として現れます。

1億1900万件の実取引でも、失敗コストは発生した

論文は2025年10月1日から12月26日までのBaseとSolanaの取引1億1900万件超も分析しています。実験環境だけではなく、実取引でも問題の影響を確認するためです。

取引は主要事業者に集中しており、 1社の欠陥がエコシステム全体の露出になりやすい 構造でした。これは、AIエージェントの外部処理を単一のサービスやエージェントに寄せる設計でも同じです。

決済の試行でファシリテーターが負担したガス・手数料は、累計で約20万2000ドルにのぼります。このうち失敗して巻き戻された送信によるものは約5800ドルで、残りは成立した決済のコストです。失敗分に限れば金額は大きくありません。それでも、支払いが成立しなかった取引のコストを回収する手段はなく、負担しているのは仲介側です。委任が失敗したときのコストを誰が負担するかは、設計で決まります。

「相手の条件」と「本当に終わったか」の両方を確認しにくい

前回の記事では、公開A2Aエージェント194件を調べました。前回の実測では、認証要件の記載があるのは1件、認証方式も1件、ライセンスと料金情報は0件でした。つまり、外から見ただけでは「このエージェントに何を、どんな条件で頼めるのか」が分かりにくい状態でした。今回の論文が見ているのは、その先で支払いを確認・決済する仲介側です。

対象も調査方法も違うため、数字を直接比べることはできません。ただ、共通しているのは、外部の相手に仕事を頼むとき、「どんな条件で動く相手なのか」と「頼んだ仕事が本当に終わったのか」の両方を、外から確認しにくいことです。前回は「頼む前の情報不足」、今回は「頼んだ後の成立確認の不足」を見ている、と考えるとつながりが分かりやすくなります。

x402を使っていなくても、今日確認できる5点

ここまでの論点を、x402を使っていない会社でも今日確認できる項目に落とします。外部サービスやAIエージェントに仕事を頼んでいるなら対象です。

• 完了の定義：外部サービスやAIエージェントから「完了しました」と返ってきただけで、仕事が終わったとみなしていないか。相手側の状態を別の方法で確認しているか
• 失敗したときに戻せるか：外部側で失敗したとき、自社側ですでに進めた処理（在庫引当、通知、後続の依頼）を戻す手段があるか
• タイムアウトの整合：依頼の有効期限が、実際の処理時間より短くなっていないか
• 失敗コストの帰属：外部処理が失敗したとき、コストを負担するのは自社か、相手か、その先か。契約上の想定と実装が一致しているか
• 依存先の集中：重要な処理を1社・1サービス・1エージェントに寄せすぎていないか。その相手の不具合がそのまま自社の障害にならないか

x402を実装している場合の追加5点

すでにx402を実装・検証している場合は、論文の指摘から直接確認できる項目があります。

• 保護リソースの解放境界：検証成功で返しているか、決済成立を待っているか。前者なら Free Shopping の前提条件を満たします
• マーチャントSDKのバージョン：Coinbase Flask SDK は v0.2.1以下が該当します。利用中のSDKが決済成立で応答をゲートしているか確認してください
• 決済失敗時の補償設計：業務ロジックの副作用を巻き戻す手段がアプリケーション側にあるか
• validBefore の設定値：論文は3〜7秒という極端に短い設定を多く観測しています。検証から決済送信までの遅延を吸収できず、失敗率を上げます
• ファシリテーターの多重化：単一の仲介者への依存が、そのままシステミックリスクになります

参考：論文が導出した8つのセキュリティ規則

論文の著者らはファシリテーターが決済インフラとして満たすべき規則を8つ定義しました。前半4つは「いつ支払い済みと認可してよいか」（認可の正しさ）、後半4つは「決済時にチェーン上で何を実行してよいか」（実行安全性）を規定します。

最も頻出したのはSR5・SR7・SR8です。加えて、少なくとも1つの実装はSR1〜SR4という基礎的な要件を満たしていませんでした。SR1〜SR4、SR6の個別の違反社数は論文に明記されていないため、上表では「—」としています。

論文自身が明示する制約

論文の著者らは影響を受ける各社へ責任ある開示を行い、Coinbaseを含む複数社が問題を認め、緩和策を導入したと報告しています。個別の修正が進んでいること自体は前向きな材料です。一方で、外部の相手が規則を守っているかを継続的に確認する仕組みは、まだ存在しません。

最後に一つ。いま自社が外部サービスやAIエージェントに任せている仕事を1つ挙げて、「完了を何で確認しているか」と「失敗したとき何を戻せるか」に答えられるか、確かめてみてください。 答えられない仕事が1つでもあれば、それは今回の論文が示したのと同じ「返事」と「実際の成立」のズレを抱えている可能性があります。決済を使っているかどうかは関係ありません。

一次資料：Qinying Wang, Yong Yang, Yuan Chen, Shouling Ji, Mathias Payer, "When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments," USENIX Security 2026（arXiv: 2607.19545, v1: 2026-07-21）。本文中の数値は、断りのない限りすべて同論文の記載によります。オンチェーン実測期間は2025-10-01〜2025-12-26。売り手側の数値は当社の2026-08-09実測記事によります（同記事の見出しにある「31件」はx402に言及するエージェントの数で、本記事の「31件」＝脆弱性とは無関係です）。仕様参照：x402 Client / Server、A2A Protocol Specification。