AP2とx402の比較：AIエージェントによる支払い承認と自動決済の仕組み

AP2（Agent Payments Protocol）とx402は、AIエージェントコマース向けに設計された2つの決済プロトコルです。それぞれ、決済承認とプログラムによる決済処理の観点から、自律的な取引のためのインフラを提供します。AP2は、AIエージェントによる購入がユーザーから承認されていることの証明に重点を置いています。一方、x402は標準化されたHTTP決済インタラクションを使用し、ソフトウェアシステムがAPI、データ、その他のデジタルサービスをオンデマンドで購入できるようにします。

エージェント間コマースの発展に伴い、AIエージェントは情報検索ツールから、購入、サブスクリプション管理、サービス呼び出しを実行できる自動化システムへと進化しています。エージェントがユーザーまたは企業に代わって資金を使用し始めると、手動でのクリックや確認に依存する従来の決済プロセスは新たな課題に直面します。システムはどのようにして、エージェントに決済権限があるかを判断できるのでしょうか。決済金額はどのように制限できるのでしょうか。異なるシステムはどのようにして自動的に決済を完了できるのでしょうか。

AP2とx402は、相互補完的な2つのアプローチを提供します。本記事では、両プロトコルの中核的な仕組み、技術的な違い、連携ワークフローを紹介し、AIエージェント決済におけるステーブルコインの役割を分析するとともに、自動取引に伴う可能性のあるセキュリティおよびコンプライアンス上のリスクを考察します。

要点

• AP2（Agent Payments Protocol）は、AIエージェントの決済承認に関するオープンプロトコルです。エージェントがユーザーに代わって決済できるかどうか、および取引がユーザーの意思を反映していることをどのように検証するかに重点を置いています。
• x402は、HTTPの「402 Payment Required」ステータスコードに基づくプログラム可能な決済プロトコルです。AIエージェントは、サーバーから返される決済要件に基づき、APIやデジタルサービスに対して自動的に支払いを行えます。
• AP2とx402は異なるレイヤーに対応します。AP2は承認と説明責任の検証に重点を置き、x402は決済リクエスト、認証情報の検証、決済処理に重点を置きます。両プロトコルは併用できます。
• ステーブルコインは、AIエージェントにプログラム可能なデジタル決済手段を提供します。従量課金制のAPI、データサービス、マシン間取引に適していますが、すべてのエージェント決済シナリオで必要なわけではありません。
• AIエージェントによる自動決済には、予算上限、ウォレット権限管理、取引相手の検証、異常取引への対応が依然として必要です。自動実行を、資金使用に対する無制限の承認とみなすべきではありません。

AP2とx402とは何か？AIエージェントに専用の決済プロトコルが必要な理由

AP2とx402はいずれもAIエージェントによる自動コマースを支援しますが、解決する問題は異なります。AP2は、Googleが決済・テクノロジー業界の参加者とともに2025年9月に開始したプロトコルです。エージェント決済承認のための、クロスプラットフォームかつ決済手段に依存しないフレームワークの構築を目指しています。ユーザーが特定の購入をエージェントに承認したことを証明し、決済機関がその承認を検証できるようにすることに重点を置いています。

一方、x402はCoinbaseによって推進され、HTTPプロトコルの402 Payment Requiredステータスコードに基づいています。Webサイト、API、その他のデジタルサービスは、決済要件をクライアントに直接送信できます。AIエージェントは決済情報を受け取ると、管理されたウォレットを使用して決済認証情報を生成し、検証および決済処理の完了後に該当リソースへアクセスできます。

これら2つのプロトコルの登場は、AIエージェントコマースにおける2つの異なる課題を反映しています。第一に、エージェントは製品やサービスを自律的に発見できますが、ユーザーから承認を受けていることを証明する必要があります。第二に、エージェントに決済権限がある場合でも、外部サービスと連携し、自動的に支払いを完了する手段が必要です。

従来のオンライン決済システムは一般的に、消費者が自ら製品を確認し、クリックして確定し、本人確認を完了することを前提としています。しかし、AIエージェントはユーザーがリアルタイムで関与しないままタスクを実行する可能性があります。そのため決済システムは、取引が有効かどうかだけでなく、エージェントの行動があらかじめ定められた権限に準拠しているかどうかも判断する必要があります。

AP2とx402はそれぞれ、これら2つの段階に技術的なサポートを提供します。ただし、すべてのAIエージェント決済で両方のプロトコルが必要になるわけではありません。

AP2はどのようにAIエージェントの決済承認を検証するのか？

AP2の中核は、暗号学的に検証可能な承認認証情報であるMandateです。Mandateには、ユーザーがエージェントに許可した操作と適用される制約が記録され、加盟店および決済サービスプロバイダーは、取引がユーザーの意思を反映しているかどうかを判断できます。

AP2 v0.2技術仕様によると、このプロトコルでは主にCheckout MandateとPayment Mandateという2種類の認証情報を定義しています。Checkout Mandateは、エージェントが特定の製品またはサービスを購入する権限を与えられていることを証明します。Payment Mandateは、エージェントが該当する注文の決済を開始できることを証明します。この2つは注文情報を通じて関連付けられ、決済認証情報が別の取引に使用されるリスクを低減します。

たとえば、ユーザーがAIエージェントに対し、50ドル以下のデータサービスを購入するよう依頼するとします。システムは、製品カテゴリ、予算、承認条件を関連する認証情報に記録できます。エージェントが要件を満たすサービスを見つけた後、加盟店が購入承認を検証し、決済サービスプロバイダーが決済承認を検証します。取引は、関連条件が満たされた後にのみ次の決済段階へ進むべきです。

AP2は、人が関与するHuman Present取引モードと、人が関与しないHuman Not Present取引モードも区別しています。前者では、ユーザーはチェックアウト時に特定の注文を確認できます。後者では、エージェントは事前に承認された制約の範囲内で取引を実行できます。いずれのモードでも、重要な承認確認は、大規模言語モデルの判断のみに依存するのではなく、決定論的なプロセスを通じて完了する必要があります。

したがって、AP2は銀行カード、銀行口座、ステーブルコインを置き換えることを目的としていません。その価値は、異なる決済手段に対する検証可能な承認基盤を確立し、その後の監査や紛争解決のための記録を提供する点にあります。

x402はHTTP 402を通じてどのように自動決済を実現するのか？

x402の中核的な考え方は、決済プロセスをHTTPリクエストに直接組み込むことです。従来のAPIサービスでは通常、ユーザーはアカウント登録、決済手段の連携、またはサブスクリプションクレジットの事前購入を求められます。x402では、サーバーはリクエストを受信した際に標準化された決済要件を返し、クライアントは決済を完了した後、再度リソースを取得します。

公式のx402プロトコルによると、一般的なプロセスは、クライアントがリソースサーバーにHTTPリクエストを送信することから始まります。リソースの取得に決済が必要な場合、サーバーは402 Payment Requiredを返し、価格、対応ネットワーク、決済資産、その他の必要情報を提供します。クライアントは対応する決済方法を選択し、決済認証情報を生成してHTTPリクエストで送信します。

その後、リソースサーバーは決済認証情報を検証し、オンチェーン取引またはFacilitator（決済検証・決済処理サービス）を通じて決済を完了します。Facilitatorはサーバーに代わって署名検証とオンチェーン決済を実行できるため、ブロックチェーン決済インフラを維持する複雑さを軽減します。検証と決済が成功すると、サーバーは要求されたデータまたはサービス結果を返します。

x402のバージョンによって、使用されるHTTP Header名とデータ構造が異なる点に注意が必要です。たとえば、初期バージョンではX-PAYMENTが使用されていましたが、新しい仕様ではPAYMENT-SIGNATUREなどのフィールドが使用されています。そのため、開発者は使用する特定のバージョンに従って実装し、異なるバージョンのインターフェースを直接混在させないようにする必要があります。

AIエージェントにとってのx402の利点は、決済を通常のWebリクエストの一部にできることです。エージェントが有料データを購入したり、AIモデルを呼び出したりする必要がある場合、毎回別の手動チェックアウトページへ移動することなく、承認済みの予算内で決済を完了できます。

AP2とx402の違いは何か？

AP2とx402の最も本質的な違いは、その役割にあります。AP2は主に「この取引は承認されているか？」という問いに答えます。x402は主に「サーバーの要件に従って、どのようにプログラムで決済を完了できるか？」という問いに答えます。

AP2は、特定の決済通貨や決済ネットワークに依存しません。たとえば、AIエージェントはAP2を用いて購入が承認されていることを証明し、その後、銀行カードまたはその他の対応する決済手段で取引を完了できます。x402はデジタルサービス決済の技術的な実行により重点を置いており、特にステーブルコイン決済とAPIリクエストを組み合わせる用途に適しています。

両プロトコルには機能上の重複もあります。x402はクライアントが送信した決済認証情報を検証できますが、この検証は主に、決済がサーバーの要件を満たしているかどうかに関するものです。これは本質的に、ユーザーの商取引上の意思が完全に承認されていることと同義ではありません。AP2は、ユーザーの意思、製品、決済条件に関するより広範な情報を記録できます。

したがって、AP2を単にx402の上位版とみなすべきではなく、x402をすべての決済承認メカニズムの代替とみなすべきでもありません。両者は個別に導入することも、併用することもできます。

AP2とx402はどのように連携してエージェント間取引を完了できるのか？

AP2とx402の連携は、有料データ分析サービスの例を通じて理解できます。

たとえば、ユーザーがリサーチエージェントに対し、1日に最大20ドル分の市場データを購入することを承認したとします。エージェントは、ニーズを満たすAPIを別のサービスプロバイダーが提供していることを発見し、1回の呼び出しにつき0.10ドルという価格提示を受けます。システムはまず、このサービスが承認された購入範囲内にあることを確認し、その後、累計支出額が予算を超えないことを確認する必要があります。

承認段階では、AP2はエージェントに対応する購入および決済権限があることを証明する、検証可能なMandateを提供できます。決済段階では、x402はサーバーの決済要件をエージェントに伝達し、管理されたウォレット、決済認証情報、決済サービスを通じて資金移転を完了できます。決済が成功すると、サーバーはデータを返し、エージェントはリサーチタスクを継続します。

この組み合わせは概念モデルにとどまりません。Google関連のオープンソースプロジェクトは、エージェントがオンチェーン決済を通じて他のエージェントが提供するサービスを購入できるA2A x402 Payments Extensionを公開しています。そのv0.2仕様では、独立型と組み込み型の決済フローも定義されています。後者は、AP2などのより上位のプロトコルに決済構造を統合できます。

ただし、上記のプロセスはプロトコルをどのように組み合わせられるかを説明するための例です。すべてのAP2またはx402実装が、すでにまったく同じ機能をサポートしていることを意味するものではありません。実際のシステムでは、承認認証情報の検証、ウォレット権限、決済失敗、重複リクエスト、取引レシートなどの詳細を処理する必要があります。

ステーブルコインがAIエージェントの自動決済に適している理由

ステーブルコインは、AIエージェントによるプログラム可能な決済の有力な候補の1つです。価格変動が大きい暗号資産と比較して、米ドルにペッグされたステーブルコインは一般的に米ドル建てであり、サービスプロバイダーがAPI呼び出し、データアクセス、コンピューティングリソースに対して比較的安定した価格を設定するのに役立ちます。

たとえば、AIエージェントが有料のデータインターフェースを毎日数百回呼び出す必要がある場合、各呼び出しで銀行カード決済を手動確認する必要があれば、取引プロセスの自動化は困難になります。x402と対応するステーブルコインネットワークを利用すれば、決済要件、署名、決済処理をプログラムによるリクエストに統合でき、エージェントは予算内でサービスに自動的に支払いを行えます。

ステーブルコインはデジタルネイティブであり、プログラム可能でもあります。開発者は、決済ロジックをAPI権限、利用制限、ウォレット制約と組み合わせることで、ソフトウェアシステムが異なるプラットフォーム間で資金を移転できるようにします。Coinbaseはx402の導入時に、API、ソフトウェアサービス、AIエージェント間の自動決済を主要な応用領域として挙げています。

ただし、ステーブルコイン決済にも制約があります。オンチェーン送金にはネットワーク手数料が発生する可能性があり、一部の取引ではファイナリティに達するまで時間がかかる場合があります。また、誤ったアドレスへの送金や不可逆的な送金は、資金の損失につながる可能性があります。ステーブルコインには、発行者、準備資産、償還、規制に関するリスクもあります。したがって、ステーブルコインは、あらゆる決済問題に対する万能な解決策ではなく、エージェントコマースにおける決済オプションの1つとして理解すべきです。

AP2とx402はどのようなセキュリティリスクおよび技術的制約に直面するのか？

第一のリスクは、承認の悪用です。AIエージェントは、ユーザーのリクエストを誤解したり、悪意あるWebページ、ツールの応答、プロンプトインジェクションの影響を受けたりして、ユーザーの実際の意思を超える購入を開始する可能性があります。システムが決済の妥当性判断をモデルのみに依存し、独立した予算および権限の確認を欠く場合、意図しない支出が発生する可能性があります。

AP2はMandateと決定論的な検証メカニズムによってこのリスクを低減しますが、そのセキュリティは依然として承認認証情報の発行、保管、検証方法に依存します。システムは過度に広範な権限の付与も避け、高リスク取引には追加確認を導入すべきです。

第二のリスクは、決済実行に関するものです。x402にはクライアント、サーバー、ウォレット、決済サービスが関与し、どの段階の実装エラーも取引結果に影響を与える可能性があります。たとえば、リクエストの重複送信によって二重決済が発生する可能性があり、決済成功後にサービス提供に失敗した場合は紛争につながる可能性があります。また、Facilitatorの障害は決済処理を遅延させる可能性があります。したがって、開発者は冪等な処理、決済失敗時の再試行、レシート照合、例外に基づく返金手順を設計する必要があります。

第三のリスクは、取引相手と本人性の検証に関するものです。エージェントが決済認証情報を正しく送信したとしても、受取人が必ずしも信頼できるとは限りません。悪意あるサーバーは、価格を偽って表示したり、無効なサービスを提供したり、製品情報を改ざんしたりする可能性があります。A2Aとx402はエージェント間の通信と決済フローを改善できますが、加盟店の身元の真正性や、サービス品質が期待を満たすことを自動的に保証するものではありません。

最後のリスクは、プライバシーと規制に関するものです。エージェントコマースには、ユーザーの消費傾向、企業の調達情報、決済データが関わる可能性があります。オンチェーン決済は公開検証可能な取引記録を提供する一方、アドレスや資金フローが公開される可能性もあります。国境を越える決済では、適用されるマネーロンダリング対策、制裁、消費者保護の要件も考慮する必要があります。

そのため、AP2とx402の実用化は、ユーザー承認、エージェント権限管理、決済認証情報の検証、取引監視、例外処理を含む多層的なセキュリティアーキテクチャに基づいて構築する必要があります。これらのメカニズムを組み合わせることでのみ、システムは自動化の水準を高めながら、資金に関連するリスクを管理できます。

まとめ

AP2とx402は、それぞれ決済承認とプログラムによる決済処理の観点から、AIエージェントコマースのためのインフラを提供します。AP2はMandateと検証可能な認証情報を通じて、加盟店および決済サービスプロバイダーがエージェントの取引がユーザー承認に準拠しているかを確認するのに役立ちます。x402はHTTP 402と決済検証プロセスを通じて、AIエージェントがAPI、データ、その他のデジタルサービスを自動的に購入できるようにします。

この2つのプロトコルは、互いに代替するものではありません。AP2は異なる決済手段と連携でき、x402はオンチェーン決済の実行メカニズムとして機能できます。A2A x402 Payments Extensionなどの技術が発展するにつれ、承認検証と自動決済処理はより密接な連携関係を形成しつつあります。

エージェント間コマースにおける重要な課題は、AIエージェントによる決済を単に可能にすることではありません。各取引には、明確に定義された承認範囲、検証可能な決済結果、信頼できる例外処理メカニズムが必要です。ステーブルコインとWeb3はこの方向性に新たな決済手段を提供しますが、エージェントコマースの広範な普及は、最終的にはセキュリティ、相互運用性、実際のビジネスニーズに左右されます。

FAQ

AP2とx402の中核的な違いは何ですか？

AP2は主にAIエージェントの購入および決済承認を検証し、x402は主にHTTPリクエストを通じたプログラムによる決済を可能にします。前者は承認に重点を置き、後者は決済実行に重点を置いています。

AP2はブロックチェーン決済プロトコルですか？

いいえ。AP2は、銀行カードやステーブルコインを含む異なる決済システムをサポートできる、決済手段に依存しない承認フレームワークです。取引をブロックチェーン上で決済する必要はありません。

x402ではUSDCしか利用できませんか？

いいえ。x402の決済機能は、特定の決済スキーム、ネットワーク、サーバーが提供するサポートに依存します。USDCは実装で一般的に使用される決済資産ですが、プロトコルでサポートされる唯一の資産と理解すべきではありません。

AP2とx402は併用できますか？

はい。AP2はエージェントの取引承認を検証するために使用でき、x402は対応するプログラムによるオンチェーン決済を実行するために使用できます。A2A x402 Extensionでは、すでにx402をAP2などの上位プロトコルと組み合わせる方法が検討されています。

AIエージェントがx402で決済するには手動確認が必要ですか？

必ずしも必要ではありません。ユーザーが有効な承認を提供し、取引が予算、受取人、その他の適用される制約を満たしている場合、システムはエージェントによる自動決済を許可できます。承認範囲外の取引については、再度確認を求めるべきです。

x402による決済が成功すれば、サービス提供は保証されますか？

いいえ。決済の成功とサービスの履行は別の段階です。API障害、サービスの利用不可、提供に関する紛争が発生する可能性は依然としてあります。そのため、必要に応じて取引レシート、例外処理、返金メカニズムによりリスクを管理する必要があります。