GoogleのAgent Payments Protocol (AP2)
GoogleのAgent Payments Protocol (AP2) は、AIエージェントがユーザーに代わって開始する安全で信頼性の高い取引を可能にするために設計された、新しく発表されたオープン標準です。60以上の決済およびテクノロジー組織（主要な決済ネットワーク、銀行、フィンテック企業、Web3企業を含む）との協力により開発されたAP2は、「エージェント型」決済、すなわち自律型エージェント（AIアシスタントやLLMベースのエージェントなど）がユーザーのために実行できる購入や金融取引のための共通言語を確立します。AP2の創設は、根本的な変化によって推進されています。従来、オンライン決済システムは人間が直接「購入」をクリックすることを前提としていましたが、ユーザーの指示に基づいて行動するAIエージェントの台頭がこの前提を打ち破りました。AP2は、AI主導の商取引における承認、信頼性、説明責任といった課題に対処しつつ、既存の決済インフラとの互換性を維持します。本レポートでは、AP2の技術アーキテクチャ、目的とユースケース、AIエージェントおよび決済プロバイダーとの統合、セキュリティとコンプライアンスの考慮事項、既存プロトコルとの比較、Web3/分散型システムへの影響、および業界での採用/ロードマップについて考察します。
技術アーキテクチャ: AP2の仕組み
AP2の核となるのは、検証可能なデジタルクレデンシャル (VDC) に基づいて構築された暗号学的に安全な取引フレームワークです。VDCは、ユーザーが承認した内容のデジタルな「契約」として機能する、改ざん防止された署名付きデータオブジェクトです。AP2の用語では、これらの契約はマンダートと呼ばれ、各取引の監査可能な証拠の連鎖を形成します。AP2アーキテクチャには、主に3種類のマンダートがあります。
- 意図マンダート (Intent Mandate): 購入に関するユーザーの初期指示または条件を捕捉します。特に*「人間が不在の」シナリオ（ユーザーがオンラインでない状態でエージェントが後で行動する場合）に適用されます。これは、ユーザーがエージェントに与える権限の範囲*を定義します。例えば、「コンサートチケットが200ドル以下になったら、2枚まで購入する」といったものです。このマンダートは、ユーザーによって事前に暗号学的に署名され、特定の制限内での同意の検証可能な証拠として機能します。
- カートマンダート (Cart Mandate): ユーザーが承認した最終的な取引詳細を表し、*「人間が同席する」*シナリオやチェックアウト時に使用されます。これには、正確なアイテムやサービス、その価格、および購入のその他の詳細が含まれます。エージェントが取引を完了する準備ができたとき（例えば、ショッピングカートに商品を詰めた後）、まずマーチャントが カートの内容を暗号学的に署名し（注文詳細と価格を保証）、次にユーザーが（デバイスまたはエージェントインターフェースを介して）署名してカートマンダートを作成します。これにより、表示されたものが支払うものであることが保証され、ユーザーに提示された通りの最終注文が確定されます。
- 決済マンダート (Payment Mandate): AIエージェントが取引に関与していることを決済ネットワーク（カードネットワークや銀行など）に通知するために送信される別のクレデンシャルです。決済マンダートには、承認時にユーザーが同席していたかどうかなどのメタデータが含まれ、リスク管理システムのためのフラグとして機能します。このマンダートは、ユーザーの意図の暗号学的に検証可能な証拠を取得銀行および発行銀行に提供することで、コンテキストを評価し（例えば、エージェントが開始した購入を一般的な不正行為と区別する）、それに応じてコンプライアンスや責任を管理するのに役立ちます。
すべてのマンダートは、関連当事者（ユーザー、マーチャントなど）の鍵によって署名された検証可能なクレデンシャルとして実装され、すべてのエージェント主導の取引に対して否認防止可能な監査証跡を生成します。実際には、AP2は機密情報を保護するためにロールベースのアーキテクチャを使用します。例えば、エージェントは生の決済詳細を一切見ることなく意図マンダートを処理することができ、決済詳細は必要なときにのみ制御された方法で開示され、プライバシーが保護されます。ユーザーの意図 → マーチャントのコミットメン ト → 決済承認という暗号学的連鎖は、取引がユーザーの真の指示を反映しており、エージェントとマーチャントの両方がその指示を遵守したという、すべての当事者間の信頼を確立します。
取引フロー: AP2がエンドツーエンドでどのように機能するかを説明するために、人間が関与する簡単な購入シナリオを考えてみましょう。
- ユーザーリクエスト: ユーザーはAIエージェントに特定のアイテムまたはサービスの購入を依頼します（例：「この靴を私のサイズで注文して」）。
- カートの構築: エージェントはマーチャントのシステムと通信し（標準APIまたはエージェント間の相互作用を使用）、指定されたアイテムのショッピングカートを特定の価格で組み立てます。
- マーチャントの保証: カートをユーザーに提示する前に、マーチャント側がカートの詳細（アイテム、数量、価格など）を暗号学的に署名します。このステップにより、正確な条件を保証するマーチャント署名付きオファーが作成されます（隠れた変更や価格操作を防ぎます）。
- ユーザーの承認: エージェントはユーザーに確定されたカートを表示します。ユーザーは購入を確認し、この承認によりユーザー側から2つの暗号学的署名がトリガーされます。1つはカートマンダート（マーチャントのカートをそのまま受け入れるため）に対するもので、もう1つは決済マンダート（選択した決済プロバイダーを通じて決済を承認するため）に対するものです。これらの署名済みマンダートは、それぞれマーチャントと決済ネ ットワークに共有されます。
- 実行: カートマンダートと決済マンダートを携えて、マーチャントと決済プロバイダーは取引を安全に実行します。例えば、マーチャントはユーザー承認の証拠とともに決済リクエストを決済ネットワーク（カードネットワーク、銀行など）に送信し、決済ネットワークは決済マンダートを検証できます。その結果、ユーザーの意図と最終的な決済を結びつける暗号学的監査証跡を伴う購入取引が完了します。
このフローは、AP2がAI主導の購入の各ステップにどのように信頼を組み込むかを示しています。マーチャントは、ユーザーがどの価格で何を購入することに同意したかについて暗号学的証拠を持ち、発行者/銀行は、AIエージェントがプロセスを促進したにもかかわらず、ユーザーがその決済を承認したという証拠を持っています。紛争やエラーが発生した場合、署名済みマンダートは明確な証拠として機能し、説明責任の判断に役立ちます（例えば、エージェントが指示から逸脱した場合や、請求がユーザーが承認したものでなかった場合など）。本質的に、AP2のアーキテクチャは、エージェントの行動への信頼ではなく、検証可能なユーザーの意図が取引の基礎であることを保証し、曖昧さを大幅に軽減します。
AP2の目的とユースケース
なぜAP2が必要なのか: AP2の主な目的は、AIエージェントがユーザーに代わって資金を使うことができるようになったときに生じる、新たな信頼とセキュリティの問題を解決することです。Googleとそのパートナーは、自律型エージェントが関与する場合に、今日の決済インフラでは適切に答えられないいくつかの重要な問題を特定しました。
- 承認: ユーザーが実際にエージェントに特定の購入を行う許可を与えたことをどのように証明するか？（言い換えれば、エージェントがユーザーの十分な同意なしに物を購入していないことを確認する。）
- 信頼性: マーチャントは、エージェントの購入リクエストが本物であり、間違いやAIの幻覚ではなく、ユーザーの真の意図を反映していることをどのように知ることができるか？
- 説明責任: エージェントを介して不正な取引や誤った取引が発生した場合、誰が責任を負うのか？ユーザー、マーチャント、決済プロバイダー、それともAIエージェントの作成者か？
解決策がなければ、これらの不確実性はエージェント主導の商取引に「信頼の危機」を生み出します。AP2の使命は、安全なエージェント取引のための統一プロトコルを確立することで、その解決策を提供することです。標準化されたマンダートと意図の証明を導入することで、AP2は各企業が独自の場当たり的なエージェント決済方法を考案する断片化されたエコシステムを防ぎます。代わりに、準拠するAIエージェントは、共通のルールと検証の下で、準拠するマーチャント/決済プロバイダーと対話できます。この一貫性は、ユーザーとマーチャントの混乱を避け るだけでなく、金融機関が独自のパッチワークのアプローチに対処するのではなく、エージェントが開始する決済のリスクを管理するための明確な方法を提供します。つまり、AP2の目的は、「エージェント経済」が決済エコシステムを破壊することなく成長できるようにする基盤となる信頼レイヤーとなることです。
意図されたユースケース: 上記の問題を解決することで、AP2は、人間が手動でクリックして購入するだけでは不可能な、新しい商取引体験とユースケースへの扉を開きます。AP2がサポートするエージェント対応の商取引の例をいくつか示します。
- よりスマートなショッピング: 顧客はエージェントに「この冬のジャケットを緑色で欲しい。現在の価格より20%までなら喜んで支払う」と指示できます。これらの条件をエンコードした意図マンダートを携えて、エージェントは小売業者のウェブサイトやデータベースを継続的に監視します。ジャケットが緑色で（かつ価格しきい値内で）利用可能になった瞬間、エージェントは安全な署名付き取引で自動的に購入を実行し、そうでなければ見逃されていたであろう販売機会を捉えます。ユーザーの最初の要求から自動チェックアウトまでのすべてのやり取りは、エージェントが承認されたものだけを購入することを保証するAP2マンダートによって管理されます。
- パーソナライズされたオファー: ユーザーはエージェントに、今後の旅行のために特定のマーチャントから特定の製品（例えば、新しい自転車）を探していると伝えます。エージェントは、この関心（意図マンダートの範囲内で ）を、旅行日などの関連するコンテキストとともに、マーチャント自身のAIエージェントと共有できます。ユーザーの意図とコンテキストを知っているマーチャントエージェントは、カスタムバンドルや割引で応答できます。例えば、「自転車+ヘルメット+トラベルラックを15%オフで、今後48時間利用可能」といったものです。AP2を使用することで、ユーザーのエージェントはこのカスタマイズされたオファーを安全に受け入れて完了させることができ、単純な問い合わせをマーチャントにとってより価値のある販売に変えることができます。
- 協調タスク: 複雑なタスク（例えば、週末旅行）を計画しているユーザーは、それを完全に委任します。「これらの日付で、合計予算700ドルでフライトとホテルを予約して。」エージェントは、複数のサービスプロバイダーのエージェント（航空会社、ホテル、旅行プラットフォーム）と対話し、予算に合う組み合わせを見つけます。適切なフライトとホテルのパッケージが特定されると、エージェントはAP2を使用して複数の予約を一括で実行します。各予約は暗号学的に署名されます（例えば、航空会社とホテルに別々のカートマンダートを発行し、両方ともユーザーの意図マンダートの下で承認されます）。AP2は、この協調取引のすべての部分が承認されたとおりに行われることを保証し、途中で一部が失敗するリスクなしにチケットと予約が同時に行われるようにすることも可能です。
これらのシナリオは、AP2が意図するユースケースのほんの一部を示しています。より広範には、AP2の柔軟な設計は、従来のeコマースフローとまったく新しい商取引モデルの両方をサポートします。例えば、AP2はサブスクリプションのようなサービス（エージェントが条件が満たされたときに購入することで必需品を補充し続ける）、イベント駆動型購入（トリガーイベントが発生した瞬間にチケットやアイテムを購入する）、グループエージェント交渉（複数のユーザーのエージェントがマンダートをプールしてグループ取引を交渉する）、その他多くの新たなパターンを促進できます。すべての場合において、共通のテーマは、AP2が信頼フレームワーク（明確なユーザー承認と暗号学的監査可能性）を提供し、これらのエージェント主導の取引が安全に行われることを可能にすることです。信頼と検証レイヤーを処理することで、AP2は開発者や企業が決済セキュリティをゼロから再発明することなく、新しいAIコマース体験の革新に集中できるようにします。
エージェント、LLM、および決済プロバイダーとの統合
AP2は、AIエージェントフレームワークと既存の決済システムの両方とシームレスに統合するように明示的に設計されており、両者の間の橋渡し役を果たします。GoogleはAP2をAgent2Agent (A2A) プロトコルおよびModel Context Protocol (MCP) 標準の拡張機能として位置付けています。言い換えれば、A2Aがエージェントがタスクを通信するための汎用言語を提供し、MCPがAIモデルがコンテキスト/ツールを組み込む方法を標準化するならば、AP2は商取引のためのトランザクションレイヤーをその上に加えます。これらのプロトコルは補完的です。A2Aはエージェント間の通信（例えば、ショッピングエージェントがマーチャントのエージェントと会話できるようにする）を処理し、AP2はそれらの相互作用内でのエージェントからマーチャントへの決済承認を処理します。AP2はオープンで非独占的であるため、フレームワークに依存しないことを意図しています。開発者はGoogle独自のAgent Development Kit (ADK) または任意のAIエージェントライブラリで使用でき、同様にLLMを含むさまざまなAIモデルと連携できます。例えば、LLMベースのエージェントは、自由形式のテキストだけでなく、必要なマンダートペイロードを（AP2仕様に沿って）生成および交換することでAP2を使用できます。構造化されたプロトコルを強制することで、AP2はAIエージェントのハイレベルな意図（LLMの推論から来る可能性のあるもの）を具体的で安全な取引に変換するのに役立ちます。
決済側では、AP2は従来の決済プロバイダーや標準と連携して構築されており、既存システムを置き換えるものではありません。このプロトコルは決済方法に依存しないため、クレジットカード/デビットカードネットワークから銀行振込、デジタルウォレットまで、さまざまな決済レールを資金移動の基盤となる方法としてサポートできます。最初のバージョンでは、AP2はオンライン商取引で最も一般的なカード決済との互換性を重視しています。AP2の決済マンダートは、既存のカード処理フローに組み込まれるように設計されています。AIエージェントが関与しているかどうか、およびユーザーが同席していたかどうかに関する追加データを決済ネットワーク（Visa、Mastercard、Amexなど）および発行銀行に提供することで、既存の不正検出および承認チェックを補完します。本質的に、AP2は決済自体を処理するのではなく、ユーザーの意図の暗号学的証拠で決済リクエストを強化します。これにより、決済プロバイダーはエージェントが開始した取引を適切な注意または速度で処理できます（例えば、発行者は、ユーザーが事前に承認したことを証明する有効なAP2マンダートがある場合、通常とは異なる購入を承認する可能性があります）。特に、Googleとパートナーは、AP2を「プッシュ」決済方法（インドのUPIやブラジルのPIXシステムのようなリアルタイム銀行振込など）やその他の新たなデジタル決済タイプもサポートするように進化させることを計画しています。これは、AP2の統合がカードを超えて拡大し、世界中の現代の決済トレンドと連携することを示しています。
マーチャントや決済処理業者にとって、AP2の統合は、追加のプロトコルメッセージ（マンダート）のサポートと署名の検証を意味します。多くの大規模な決済プラットフォームはすでにAP2の形成に関与しているため、それらがAP2のサポートを構築することが期待できます。例えば、Adyen、Worldpay、Paypal、Stripe（ブログでは明示的に名前が挙げられていませんが、関心がある可能性が高い）などの企業は、AP2をチェックアウトAPIやSDKに組み込み、エージェントが標準化された方法で決済を開始できるようにする可能性があります。AP2はGitHubで公開されたオープン仕様であり、リファレンス実装も提供されているため、決済プロバイダーやテクノロジープラットフォームはすぐに試用を開始できます。Googleはまた、サードパーティのエージェントをリストできるAIエージェントマーケットプレイスについても言及しており、これらのエージェントは取引機能のためにAP2をサポートすることが期待されています。実際には、AIセールスアシスタントや調達エージェントを構築する企業は、このマーケットプレイスにそれをリストすることができ、AP2のおかげで、そのエージェントは購入や注文を確実に実行できます。
最後に、AP2の統合は幅広い業界の支持から恩恵を受けています。主要な金融機関やテクノロジー企業と共同でプロトコルを開発することで、GoogleはAP2が既存の業界ルールとコンプライアンス要件に適合することを保証しました。決済ネットワーク（Mastercard、UnionPayなど）、発行者（American Expressなど）、フィンテック企業（Revolut、Paypalなど）、eコマースプレーヤー（Etsyなど）、さらにはID/セキュリティプロバイダー（Okta、Cloudflareなど）との協力は、AP2が最小限の摩擦で現実世界のシステムに組み込まれるように設計されていることを示唆しています。これらのステークホルダーは、KYC（顧客確認規制）、不正防止、データプライバシーなどの分野で専門知識をもたらし、AP2がこれらのニーズに最初から対処するのに役立っています。要するに、AP2はエージェントフレ ンドリーで決済プロバイダーフレンドリーに構築されています。既存のAIエージェントプロトコルを拡張して取引を処理し、既存の決済ネットワークの上にレイヤーを重ねてそのインフラを利用しながら、必要な信頼保証を追加します。
セキュリティ、コンプライアンス、および相互運用性の考慮事項
セキュリティと信頼はAP2設計の核心です。プロトコルが暗号技術（マンダートへのデジタル署名）を使用することで、エージェント型取引におけるすべての重要なアクションが検証可能で追跡可能であることが保証されます。この否認防止は非常に重要です。マンダートが安全な記録として機能するため、ユーザーもマーチャントも、承認され合意された内容を後で否認することはできません。直接的な利点は、不正防止と紛争解決にあります。AP2を使用すると、悪意のある、またはバグのあるエージェントが不正な購入を試みた場合、有効なユーザー署名済みマンダートがないことが明らかになり、取引を拒否または取り消すことができます。逆に、ユーザーが「この購入は承認していない」と主張しても、ユーザーの暗号学的署名付きカートマンダートが存在する場合、マーチャントと発行者は請求を裏付ける強力な証拠を持つことになります。この説明責任の明確さは、決済業界にとって主要なコンプライアンス上の懸念に応えるものです。
承認とプライバシー: AP2は、エージェント主導の取引に対してユーザーからの明示的な承認ステップ（または複数のステップ）を強制し、これは強力な顧客認証のような規制トレンドと一致しています。AP2に組み込まれたユーザーコントロールの原則は、ユーザー（またはユーザーから委任された者）が検証可能な指示を提供しない限り、エージェントが資金を使うことはできないことを意味します。完全に自律的なシナリオでも、ユーザーは意図マンダートを通じてルールを事前に定義します。このアプローチは、特定の取引についてエージェントに委任状を与えるのと似ていますが、デジタル署名され、きめ細かな方法で行われます。プライバシーの観点から、AP2はデータ共有について配慮しています。プロトコルはロールベースのデータアーキテクチャを使用し、機密情報（決済クレデンシャルや個人情報など）が絶対に必要な当事者とのみ共有されるようにします。例えば、エージェントはアイテムと価格情報を含むカートマンダートをマーチャントに送信するかもしれませんが、ユーザーの実際のカード番号は、エージェントやマーチャントではなく、決済処理業者との決済マンダートを通じてのみ共有される可能性があります。これにより、データの不必要な露出が最小限に抑えられ、プライバシー法や決済データ処理に関するPCI DSS規則への準拠が促進されます。
コンプライアンスと標準: AP2は、確立された金融機関からの意見を取り入れて開発され たため、決済における既存のコンプライアンス標準を満たすか、補完するように設計されています。このプロトコルは、通常の決済承認フローを迂回するものではなく、追加の証拠とフラグでそれらを強化します。これは、AP2取引が不正検出システム、3-Dセキュアチェック、または必要な規制チェックを依然として活用できることを意味し、AP2のマンダートは追加の認証要素またはコンテキストキューとして機能します。例えば、銀行は決済マンダートを顧客の取引に対するデジタル署名と同様に扱い、ユーザー同意の要件への準拠を合理化できる可能性があります。さらに、AP2の設計者は、「業界のルールと標準と連携して」作業していることを明示的に述べています。AP2が進化するにつれて、グローバルな金融標準に準拠することを確実にするために、正式な標準化団体（W3C、EMVCo、ISOなど）に持ち込まれる可能性があると推測できます。Googleは、標準化団体を通じてAP2のオープンで協力的な進化へのコミットメントを表明しています。このオープンなプロセスは、規制上の懸念を解消し、以前の決済標準（EMVチップカード、3-Dセキュアなど）が業界全体の協力によって行われたのと同様に、幅広い受け入れを達成するのに役立ちます。
相互運用性: 断片化の回避はAP2の主要な目標です。そのため、このプロトコルは公開されており、誰でも実装または統合できます。Google Cloudサービスに縛られていません。実際、AP2は**オープンソース（Apache-2ライセンス）**であり、仕様とリファレンスコードは公開GitHubリポジトリで入手できます。これにより、複数のベンダーがAP2を採用し、システムを連携させることができるため、相互運用性が促進されます。すでに、相互運用性の原則が強調されています。AP2は既存のオープンプロトコル（A2A、MCP）の拡張であり、非独占的であるため、単一ベンダーソリューションではなく、競争力のある実装エコシステムを育成します。実際には、企業Aが構築したAIエージェントは、両者がAP2に従っていれば、企業Bのマーチャントシステムと取引を開始できます。どちらの側も単一のプラットフォームにロックインされることはありません。
考えられる懸念の1つは、一貫した採用を確保することです。一部の主要なプレーヤーが異なるプロトコルやクローズドなアプローチを選択した場合、断片化が依然として発生する可能性があります。しかし、AP2を支える幅広い連合を考えると、デファクトスタンダードになる態勢が整っているようです。AP2エコシステムに多くのIDおよびセキュリティに特化した企業（例えば、Okta、Cloudflare、Ping Identity）が含まれていることは、相互運用性とセキュリティが共同で対処されていることを示唆しています。これらのパートナーは、AP2をID検証ワークフローや不正防止ツールに統合するのに役立ち、AP2取引がシステム間で信頼できることを保証します。
技術的な観点から見ると、AP2が広く受け入れられている暗号技術（JSON-LDまたはJWTベースの検証可能なクレデンシャル、公開鍵署名など）を使用しているため、既存のセキュリティインフラと互換性があります。組織は既存のPKI（公開鍵インフラ）を使用して、マンダート署名用の鍵を管理できます。AP2は分散型IDシステムとの統合も想定しているようです。Googleは、AP2がエージェント承認のための分散型IDのような分野で革新する機会を生み出すと述べています。これは、将来的にAP2がDID（分散型識別子）標準または分散型識別子検証を活用して、エージェントとユーザーを信頼できる方法で識別できることを意味します。このようなアプローチは、単一のIDプロバイダーに依存しないことで、相互運用性をさらに強化するでしょう。要するに、AP2は暗号技術と明確な説明責任を通じてセキュリティを強調し、設計上コンプライアンスに対応することを目指し、オープン標準の性質と幅広い業界サポートを通じて相互運用性を促進します。
既存プロトコルとの比較
AP2は、既存の決済およびエージェントフレームワークがカバーしていなかったギャップ、すなわち自律型エージェントが安全かつ標準化された方法で決済を実行できるようにするという問題に対処する、斬新なプロトコルです。エージェント通信プロトコルの観点から見ると、AP2はAgent2Agent (A2A) プロトコルのような先行研究に基づいて構築されています。A2A（2025年初頭にオープンソース化）は、異なるAIエージェントが基盤となるフレームワークに関係なく相互に通信できるようにします。しかし、A2A自体は、エージェントが取引や決済をどのように行うべきかを定義していません。それはタスクの交渉とデータ交換に関するものです。AP2は、会話が購入につながっ たときに任意のエージェントが使用できるトランザクションレイヤーを追加することで、この状況を拡張します。本質的に、AP2はA2AやMCPと競合するのではなく、補完的であると見なすことができます。A2Aは通信とコラボレーションの側面をカバーし、MCPは外部ツール/APIの使用をカバーし、AP2は決済と商取引をカバーします。これらが一体となって、将来の「エージェント経済」のための標準のスタックを形成します。このモジュラーアプローチは、インターネットプロトコルにいくらか似ています。例えば、データ通信のためのHTTPとセキュリティのためのSSL/TLSのように、ここではA2AがエージェントのHTTPのようなものであり、AP2が商取引のための安全なトランザクションレイヤーであると言えます。
AP2を従来の決済プロトコルおよび標準と比較すると、類似点と相違点の両方があります。従来のオンライン決済（クレジットカード決済、PayPal取引など）は、通常、安全な送信のためのHTTPSなどのプロトコル、カードデータ処理のためのPCI DSSなどの標準、および追加のユーザー認証のための3-Dセキュアなどを含みます。これらはユーザー主導のフロー（ユーザーがクリックし、場合によってはワンタイムコードを入力する）を前提としています。対照的に、AP2は、セキュリティを損なうことなく、第三者（エージェント）がフローに参加する方法を導入します。AP2のマンダートの概念は、OAuthスタイルの委任された権限の拡張として、決済に適用されたものと比較できます。OAuthでは、ユーザーはトークンを介してアプリケーションにアカウントへの限定的なアクセスを許可します。同様にAP2では、ユーザーはマンダートを介して、特定条件下でエージェントに資金を使う権限を付与します。主な違いは、AP2の「トークン」（マンダート）が金融取引のための特定の署名済み指示であり、既存の決済承認よりもきめ細かい点です。
もう1つの比較点は、AP2が既存のeコマースチェックアウトフローとどのように関連するかです。例えば、多くのeコマースサイトは、W3C Payment Request APIやプラットフォーム固有のSDKなどのプロトコルを使用して決済を効率化しています。これらは主に、ブラウザやアプリがユーザーから決済情報を収集する方法を標準化するものであり、AP2は、エージェントがユーザーの意図をマーチャントと決済処理業者に証明する方法を標準化します。AP2が検証可能な意図と否認防止に焦点を当てている点は、より単純な決済APIとは一線を画します。決済ネットワークの上に信頼の追加レイヤーを追加しているのです。AP2は決済ネットワーク（Visa、ACH、ブロックチェーンなど）を置き換えるのではなく、むしろそれらを強化していると言えるでしょう。このプロトコルは、あらゆる種類の決済方法（暗号通貨でさえも）を明示的にサポートしているため、ゼロから新しい決済レールを作成するのではなく、これらのシステムとのエージェントの相互作用を標準化することに重点を置いています。
セキュリティおよび認証プロトコルの分野では、AP2はEMVチップカードのデジタル署名やデジタル契約の公証のようなものと共通の精神を持っています。例えば、EMVチップカード取引は、カードが存在していたことを証明するために暗号グラムを生成します。AP2は、ユーザーのエージェントが承認されていたことを証明する暗号学的証拠を生成します。どちらも不正防止を目的としていますが、AP2の範囲はエージェントとユーザーの関係、およびエージェントとマーチャントのメッセージングであり、これは既存の決済標準では対処されていません。もう1つの新たな比較は、**暗号通貨におけるアカウント抽象化（例：ERC-4337）**です。ユーザーは事前にプログラムされたウォレットアクションを承認できます。暗号通貨ウォレットは、特定の自動取引（スマートコントラクトを介したサブスクリプションの自動支払いなど）を許可するように設定できますが、これらは通常、1つのブロックチェーン環境に限定されます。一方、AP2はクロスプラットフォームであることを目指しています。一部の決済にブロックチェーンを活用できますが（その拡張機能を通じて）、従来の銀行とも連携します。
主流の決済業界には、AP2に直接「競合する」プロトコルはまだありません。AIエージェント決済のためのオープン標準に向けた最初の協調的な取り組みであるように見えます。独自の試みは発生する可能性があり（または個々の企業内で既に進行中である可能性もあります）、しかしAP2の幅広い支持は、その標準となる上で優位性をもたらします。IBMなどがAgent Communication Protocol (ACP) やエージェントの相互運用性のための同様のイニシアチブを持っていることは注目に値しますが、それらはAP2が包括的に行うような決済の側面を含んでいません。むしろ、AP2はこれらの取り組みと統合または活用する可能性があり ます（例えば、IBMのエージェントフレームワークは、商取引タスクのためにAP2を実装する可能性があります）。
要約すると、AP2はAIと決済の独自の交差点に焦点を当てることで差別化を図っています。古い決済プロトコルが人間ユーザーを前提としていたのに対し、AP2はAI仲介者を前提とし、その結果生じる信頼のギャップを埋めます。既存の決済プロセスと競合するのではなく、それらを拡張し、A2Aのような既存のエージェントプロトコルを補完します。今後、AP2は確立された標準と並行して使用される可能性があります。例えば、AP2カートマンダートは従来の決済ゲートウェイAPI呼び出しと連携して機能したり、AP2決済マンダートは銀行のISO 8583メッセージに添付されたりするかもしれません。AP2のオープンな性質は、代替アプローチが出現した場合でも、コミュニティの協力によってAP2がそれらを吸収または調整できることを意味します。この段階で、AP2はこれまで存在しなかったベースラインを設定しており、AIと決済スタックにおける新しいプロトコルレイヤーを効果的に開拓しています。
Web3と分散型システムへの影響
当初から、AP2はWeb3および暗号通貨ベースの決済を包含するように設計されてきました。このプロトコルは、将来の商取引が従来の法定通貨チャネルと分散型ブロックチェーンネットワークの両方にまたがることを認識していま す。前述のとおり、AP2はクレジットカードや銀行振込からステーブルコインや暗号通貨まで、さまざまな決済タイプをサポートしています。実際、AP2の発表と同時に、Googleは暗号通貨決済に特化した拡張機能であるA2A x402を発表しました。この拡張機能は、Coinbase、Ethereum Foundation、MetaMaskなどの暗号通貨業界のプレーヤーと共同で開発され、「エージェントベースの暗号通貨決済のための本番環境対応ソリューション」です。「x402」という名前は、Webで広く使用されることのなかったHTTP 402「Payment Required」ステータスコードへのオマージュであり、AP2の暗号通貨拡張機能は、オンチェーンで相互に請求または支払いを行いたい分散型エージェントのために、HTTP 402の精神を効果的に復活させます。実際には、x402拡張機能はAP2のマンダートの概念をブロックチェーン取引に適合させます。例えば、エージェントはユーザーからの署名済み意図マンダートを保持し、条件が満たされたらオンチェーン決済（例えば、ステーブルコインの送信）を実行し、そのオンチェーン取引にマンダートの証明を添付できます。これにより、AP2のオフチェーン信頼フレームワークとブロックチェーンのトラストレスな性質が結びつき、オンチェーン決済が*オフチェーンの当事者（ユーザー、マーチャント）*によって承認されたと信頼できるという、両方の世界の利点が得られます。
AP2とWeb3の相乗効果は、協力者のリストに明らかです。暗号通貨取引所（Coinbase）、ブロックチェーン財団（Ethereum Foundation）、暗号通貨ウォレット（MetaMask）、Web3スタートアップ（SuiのMysten Labs、Lightning NetworkのLightsparkなど）がAP2の開発に関与しています。彼らの参加は、AP2が分散型金融と競合するのではなく、補完的であると見なされていることを示唆しています。AIエージェントが暗号通貨決済と対話するための標準的な方法を作成することで、AP2はAI主導のアプリケーションにおける暗号通貨の使用を促進する可能性があります。例えば、AIエージェントはAP2を使用して、ユーザーの好みやマーチャントの受け入れに応じて、クレジットカードでの支払いとステーブルコインでの支払いをシームレスに切り替えることができます。A2A x402拡張機能は、エージェントがオンチェーン手段を通じてサービスを収益化または支払いできるように特別に設計されており、これは将来の分散型マーケットプレイスで非常に重要になる可能性があります。これは、ブロックチェーン上で自律的な経済主体として機能するエージェント（一部ではDACやDAOと呼ばれる概念）が、サービスに必要な支払い（情報のために別のエージェントに少額の手数料を支払うなど）を処理できる可能性を示唆しています。AP2は、そのような取引のための共通言語を提供し、分散型ネットワーク上であっても、エージェントがその行動に対する証明可能なマンダートを持っていることを保証できます。
競争という観点から見ると、純粋な分散型ソリューションがAP2を不要にするのか、あるいはその逆なのか、という疑問が生じるかもしれません。AP2はWeb3ソリューションと階層的なアプローチで共存する可能性が高いです。分散型金融はトラストレスな実行（スマートコントラクトなど）を提供しますが、「AIが人間からこれを行う許 可を得たか？」という問題を本質的に解決するわけではありません。AP2は、決済自体がオンチェーンであっても重要な、その人間とAIの信頼のつながりに焦点を当てています。ブロックチェーンプロトコルと競合するのではなく、AP2はそれらをオフチェーンの世界と橋渡しするものと見なすことができます。例えば、スマートコントラクトは、有効なAP2マンダート署名への参照が含まれている場合にのみ特定の取引を受け入れることができ、これはオフチェーンの意図証明とオンチェーンの強制を組み合わせるために実装できます。逆に、暗号通貨ネイティブなエージェントフレームワーク（一部のブロックチェーンプロジェクトは、暗号通貨資金で動作する自律型エージェントを模索しています）がある場合、それらは独自の承認方法を開発するかもしれません。しかし、AP2の幅広い業界サポートは、それらのプロジェクトでさえも一貫性のためにAP2を採用または統合するように誘導する可能性があります。
もう一つの側面は分散型IDとクレデンシャルです。AP2が検証可能なクレデンシャルを使用していることは、Web3のIDへのアプローチ（W3Cによって標準化されたDIDやVCなど）と非常に一致しています。これは、AP2が分散型IDシステムに接続できることを意味します。例えば、ユーザーのDIDを使用してAP2マンダートに署名し、マーチャントはそれをブロックチェーンまたはIDハブに対して検証できます。エージェント承認のための分散型IDの探求に言及されていることは、AP2がWeb3のID革新を活用して、集中型機関にのみ依存するのではなく、分散型でエージェントとユーザーのIDを検証する可能性があ ることを裏付けています。これは相乗効果のポイントであり、AP2とWeb3の両方が、ユーザーにより多くの制御と行動の暗号学的証明を与えることを目指しています。
潜在的な対立は、大規模な仲介者の役割がない完全に分散化された商取引エコシステムを想定した場合にのみ発生する可能性があります。そのシナリオでは、AP2（Googleとそのパートナーによって最初に推進された）が集中化されすぎているか、従来のプレーヤーによって統治されすぎていると見なされる可能性があります。AP2がオープンソースであり、標準化可能であることを意図しているため、Google独自のプロトコルではないことに注意することが重要です。これは、オープンプロトコルを重視するWeb3コミュニティにとってより受け入れやすいものとなります。AP2が広く採用されれば、エージェント向けのWeb3固有の決済プロトコルの必要性を減らし、それによって取り組みを統一する可能性があります。一方で、一部のブロックチェーンプロジェクトは、特に集中型機関のないトラストレスな環境では、エージェント取引のために純粋なオンチェーン承認メカニズム（マルチシグウォレットやオンチェーンエスクローロジックなど）を好むかもしれません。これらは代替アプローチと見なされるかもしれませんが、オフチェーンシステムと相互作用できない限り、ニッチなままである可能性が高いです。AP2は両方の世界をカバーすることで、AIエージェントが暗号通貨をシームレスに使用できるもう1つの決済方法にするという点で、Web3の採用を実際に加速させるかもしれません。実際、あるパートナーは、「ステーブル コインは、レガシーインフラを持つエージェント型システムの[スケーリングの]課題に対する明白な解決策を提供する」と述べ、暗号通貨がAP2を補完して規模や国境を越えたシナリオを処理できることを強調しました。一方、Coinbaseのエンジニアリングリードは、x402暗号通貨拡張機能をAP2に導入することは「理にかなっていた。エージェントにとって自然な遊び場であり、エージェントが相互に支払いを行うことがAIコミュニティに響くのを見るのはエキサイティングだ」と述べました。これは、AIエージェントが暗号通貨ネットワークを介して取引することが単なる理論的なアイデアではなく、AP2を触媒として期待される結果であるというビジョンを示唆しています。
要約すると、AP2はWeb3に非常に密接に関連しています。暗号通貨決済を第一級市民として組み込み、分散型IDおよびクレデンシャル標準と連携しています。分散型決済プロトコルと真っ向から競合するのではなく、AP2はそれらと相互運用する可能性が高いです。AP2が承認レイヤーを提供し、分散型システムが価値移転を処理します。ステーブルコインやCBDCなどで伝統的な金融と暗号通貨の境界が曖昧になるにつれて、AP2のような統一されたプロトコルは、AIエージェントとあらゆる形態の通貨（集中型か分散型かに関わらず）との間の普遍的なアダプターとして機能する可能性があります。
業界での採用、パートナーシップ、およびロードマップ
AP2の最大の強みの一つは、この初期段階にもかかわらず、広範な業界の支持を得ていることです。Google Cloudは、AP2に関して「60以上の多様な組織と協力している」と発表しました。これには、主要なクレジットカードネットワーク（例：Mastercard、American Express、JCB、UnionPay）、主要なフィンテックおよび決済処理業者（PayPal、Worldpay、Adyen、Checkout.com、Stripeの競合他社）、eコマースおよびオンラインマーケットプレイス（Etsy、Shopify（Stripeなどのパートナー経由）、Lazada、Zalora）、エンタープライズテクノロジー企業（Salesforce、ServiceNow、Oracle（パートナー経由の可能性あり）、Dell、Red Hat）、IDおよびセキュリティ企業（Okta、Ping Identity、Cloudflare）、コンサルティング会社（Deloitte、Accenture）、そして暗号通貨/Web3組織（Coinbase、Ethereum Foundation、MetaMask、Mysten Labs、Lightspark）などが含まれます。これほど幅広い参加者は、業界の関心と今後の採用の強力な指標です。これらのパートナーの多くは公に支持を表明しています。例えば、Adyenの共同CEOは、エージェント型商取引のための「共通のルールブック」の必要性を強調し、AP2を新しい決済構成要素でマーチャントをサポートするという彼らの使命の自然な延長と見なしています。American ExpressのEVPは、AP2が信頼と説明責任が最重要となる「次世代のデジタル決済」にとって重要であると述べました。Coinbaseのチームは、前述のとおり、AP2への暗号通貨決済の統合に期待を寄せています。この支持の合唱は、業界の多くの人々がAP2をAI主導の決済の有力な標準と見なし、その要件を満たすようにAP2を形成することに熱心であることを示しています。
採用の観点から見ると、AP2は現在、仕様および初期実装段階にあります（2025年9月発表）。完全な技術仕様、ドキュメント、および一部のリファレンス実装（Pythonなどの言語）は、開発者が試用できるようにプロジェクトのGitHubで入手できます。Googleはまた、AP2がエージェント向けの自社製品およびサービスに組み込まれることを示唆しています。注目すべき例は、前述のAIエージェントマーケットプレイスです。これは、サードパーティのAIエージェントをユーザーに提供できるプラットフォームです（おそらくGoogleの生成AIエコシステムの一部）。Googleは、エージェントを構築する多くのパートナーが、「AP2によって可能になる新しい、取引可能な体験」とともにマーケットプレイスでそれらを利用可能にすると述べています。これは、マーケットプレイスが立ち上がるか成長するにつれて、AP2が、Google Cloud Marketplaceからソフトウェアを自律的に購入したり、エージェントがユーザーのために商品/サービスを購入したりするなど、取引を実行する必要があるエージェントの基盤となることを意味します。自律調達（企業に代わってあるエージェントが別のエージェントから購入する）や自動ライセンススケーリングなどの企業ユースケースは、AP2がすぐに促進できる分野として具体的に言及されています。
ロードマップに関しては、AP2のドキュメントとGoogleの発表からいくつかの明確な兆候が示されています。
- 短期: コミュニティの意見を取り入れながら、プロトコルのオープンな開発を継続します。GitHubリポジトリは、実際のテストが行われるにつれて、追加のリファレンス実装と改善で更新されます。AP2をエージェントアプリケーションに統合しやすくするライブラリ/SDKの登場が期待されます。また、パートナー企業によって初期のパイロットプログラムや概念実証が実施される可能性があります。多くの大手決済企業が関与していることを考えると、それらは管理された環境（例えば、少数のユーザーベータ版でのAP2対応チェックアウトオプション）でAP2を試用するかもしれません。
- 標準とガバナンス: Googleは、AP2をオープンガバナンスモデルに移行するコミットメントを表明しており、おそらく標準化団体を通じて行われるでしょう。これは、AP2をLinux Foundation（A2Aプロトコルで行われたように）に提出したり、それを維持するためのコンソーシアムを形成したりすることを意味するかもしれません。Linux Foundation、W3C、さらにはISO/TC68（金融サービス）のような団体も、AP2を正式化する候補となる可能性があります。オープンガバナンスは、AP2が単一企業の管理下になく、中立的で包括的であることを業界に保証するでしょう。
- 機能拡張: 技術的には、ロードマップには、より多くの決済タイプとユースケースへのサポートの拡大が含まれています。仕様に記載されているように、カードの後、焦点は銀行振込や地域のリアルタイム決済スキーム、デジタル通貨などの「プッシュ」決済に移ります。これは、AP2が、カードプルとはフローが少し異なる直接銀行振込や暗号通貨ウォレット送金の場合に、意図/カート/決済マンダートがどのように機能するかを概説することを意味します。A2A x402拡張機能は暗号通貨のためのそのような拡張機能の1つであり、同様に、オープンバンキングAPIやB2B請求シナリオのための拡張機能も登場するかもしれません。
- セキュリティとコンプライアンスの強化: 実際の取引がAP2を通じて流れ始めると、規制当局やセキュリティ研究者からの精査が行われるでしょう。オープンプロセスは、マンダートをさらに堅牢にするために反復される可能性が高いです（例えば、マンダート形式が標準化されていることを確認する、おそらくW3C検証可能なクレデンシャル形式を使用するなど）。IDソリューションとの統合（ユーザーがマンダートに署名するための生体認証の活用、またはマンダートをデジタルIDウォレットにリンクするなど）は、信頼を強化するためのロードマップの一部となる可能性があります。
- エコシステムツール: 新たなエコシステムが生まれる可能性が高いです。すでに、スタートアップ企業はギャップに気づいています。例えば、Vellum.aiの分析では、Autumnというスタートアップが「AIのための請求インフラ」を構築しており、本質的にStripeの上にAIサービスの複雑な価格設定を処理するためのツールを提供していると述べられています。AP2が普及するにつれて、エージェントに特化した決済ゲートウェイ、マンダート管理ダッシュボード、エージェントID検証サービスなどのツールが増えることが期待されます。Googleの関与は、AP2がGoogle Cloud製品にも統合される可能性があることを意味します。DialogflowやVertex AI AgentsツールでのAP2サポートを想像してみてください。これにより、エージェントが取引を処理する（必要なすべての鍵と証明書がGoogle Cloudで管理される）ことがワンクリックで可能になります。
全体として、AP2の軌跡は、他の主要な業界標準を彷彿とさせます。強力なスポンサー（Google）による初期の立ち上げ、幅広い業界連合、オープンソースのリファレンスコード、それに続く反復的な改善と実際の製品への段階的な採用です。AP2がすべてのプレーヤーを「私たちと共にこの未来を築く」よう招待しているという事実は、ロードマップがコラボレーションに関するものであることを強調しています。勢いが続けば、AP2は数年後には、OAuthやOpenID Connectがそれぞれの分野で今日そうであるように、目に見えないが機能を実現する上で不可欠なレイヤーとして普及する可能性があります。
結論
AP2 (Agents/Agent Payments Protocol) は、AIエージェントが人間と同じくらい信頼性高く安全に取引できる未来に向けた重要な一歩を表しています。技術的には、検証可能なマンダートとクレデンシャルの巧妙なメカニズムを導入し、エージェント主導の取引に信頼を植え付け、ユーザーの意図が明確で強制可能であることを保証します。そのオープンで拡張可能なアーキテクチャにより、急成長するAIエージェントフレームワークと確立された金融インフラの両方と統合できます。承認 、信頼性、説明責任という核となる懸念に対処することで、AP2はセキュリティやユーザーコントロールを犠牲にすることなく、AI主導の商取引が繁栄するための基盤を築きます。
AP2の導入は、初期のインターネットプロトコルがウェブを可能にしたように、一部の人々が「エージェント経済」と呼ぶもののための新しい基盤を築くものと見なすことができます。それは、パーソナルショッパーエージェント、自動ディール検索ボット、自律型サプライチェーンエージェントなど、すべてが共通の信頼フレームワークの下で動作する、数え切れないほどの革新への道を開きます。重要なことに、AP2の包括的な設計（クレジットカードから暗号通貨まですべてを包含）は、伝統的な金融とWeb3の交差点に位置し、共通のエージェント仲介プロトコルを通じてこれらの世界を橋渡しする可能性があります。
これまでの業界の反応は非常に好意的で、幅広い連合がAP2が広く採用される標準になる可能性が高いことを示唆しています。AP2の成功は、継続的な協力と実世界でのテストにかかっていますが、それが対処する明確なニーズを考えると、その見通しは明るいです。より広い意味で、AP2はテクノロジーがどのように進化するかを示しています。新しい機能（AIエージェント）が登場し、古い前提を打ち破り、その解決策は、その機能に対応するための新しいオープン標準を開発することでした。今、オープンでセキュリティ第一のプロトコルに投資することで、Googleとそのパートナーは、商取引の次の時代に必要な信頼アーキテクチャを効果的に構築しています。「未来を予測する最善の 方法は、それを構築することである」という言葉があるように、AP2はAIエージェントが私たちのためにシームレスに取引を処理する未来への賭けであり、その未来を可能にするために必要な信頼とルールを積極的に構築しています。
情報源:
- Google Cloud Blog – 「新しいAgent Payments Protocol (AP2)でAIコマースを強化」 (2025年9月16日)
- AP2 GitHub ドキュメント – 「Agent Payments Protocol 仕様と概要」
- Vellum AI Blog – 「GoogleのAP2: AIエージェント決済のための新しいプロトコル」 (分析)
- Medium記事 – 「Google Agent Payments Protocol (AP2)」 (Tahirによる要約、2025年9月)
- AP2に関するパートナーのコメント (Google Cloud Blog)
- A2A x402拡張機能 (AP2暗号通貨決済拡張機能) – GitHub README
