Agent Payments Protocolで実装するAIエージェント間取引

2026/02/18
「Engineers GUILD Vol5 実装から考えるAIエージェント設計勉強会」登壇資料
https://layerx.connpass.com/event/384255/
https://engineersguildvol5.peatix.com/view

Transcript

1. Agent Payments Protocolで実装する AIエージェント間取引 2026/2/18 株式会社電通総研 事業開発室 Engineeringグループ 袴田時生 事業開発室 ©DENTSU SOKEN INC
2. 本資料のフォーマットについて 本資料は、後ほどLLMやAIエージェントが活用しやすくなるようにテキスト中心・ 情報量多めで構成しています そのため、文字の量が多く、画像の位置に違和感がある場合があります 事業開発室 ©DENTSU SOKEN INC
3. 本日の内容 1. 自己紹介 2. 会社概要 3. Agent Payments Protocol(AP2)とは 4. AIエージェント主導決済における課題 5. 課題解決のためのAP2のコア技術 6. エージェントアーキテクチャ エージェントとロール、アーキテクチャ全体像、トランザクションフロー、エージェント間の信頼確立 7. Mandateを用いた紛争解決 8. AP2の社会実装に向けての課題 署名に用いる公開鍵/秘密鍵とTrust Roots エージェント間の動的なトラスト管理 9. 電通総研でのAP2の取り組み- 分散型基盤におけるAP2 事業開発室 ©DENTSU SOKEN INC
4. 自己紹介 袴田 時生（Hakamada Tokio） 所属 株式会社電通総研 事業開発室 Engineeringグループ AIチーム 経歴・業務歴 2020年に化学メーカーへ新卒入社、化学プラントの運転計器データを用いてトラブルの要因 分析と再発防止に従事 その後Fintechにて、金融系のデータサイエンティストとして機械学習・深層学習モデルの構 築・運用に従事 2024年に株式会社電通総研へ入社し、新規事業開発におけるAIエンジニアとして要件定義、 技術検証、機能設計・開発、運用、研究開発を一気通貫で推進。 趣味 PCゲーム、漫画、技術学習 事業開発室 ©DENTSU SOKEN INC
5. 会社概要 会社名： 株式会社電通総研 設立年月日： 1975年12月11日 連結従業員数： 4,413名（2024年12月末時点） 事業概要： システムインテグレーション、コンサルティング、シンクタンクの機 能連携による、社会や企業の変革を支援するソリューションの提供 事業開発室について： 発表者が所属の事業開発室は今までにない総研の柱となる 事業創出を目指し、SIではなくプロダクト開発を実施中 事業開発室 ©DENTSU SOKEN INC
6. Agent Payments Protocol(AP2)とは 2025年9月にGoogleが発表したエージェント主導の決済を安全に開始・実行するためのオープンプロト コル Agent2Agent Protocol(A2A)やModel Context Protocol（MCP）の拡張として動作し、あらゆる種類の決済 方法に対応予定 American Express、Coinbase、PayPalなど60を超える様々な組織とパートナー提携することを発表 OpenAIとStripeが共同でAgentic Commerce Protocolを策定しており、標準化に向けた流れが加速中 事業開発室 ©DENTSU SOKEN INC
7. AIエージェント主導決済における課題 現在の決済システムは、人間が信頼できるUIを介してボタンをクリックして購入する流れが 前提 エージェント主導決済では、人間がチャット等を通じてエージェントに商品の購入を依頼す ることで、エージェントが商品の検索、条件提示、決済を自律的に行う。 エージェント主導の決済になる場合、以下のような課題が生じる。 認可：期待するユーザーがエージェントに権限を与えたことをどのように証明するのか （権限委譲） 真正性：エージェントのリクエストがユーザーの真の意図と反してないかをどのように 確認するのか（ハルシネーションの抑制） 説明責任：不正な取引や誤った取引が発生した場合の説明責任は誰にあるのか（責任境 界の分離） 事業開発室 ©DENTSU SOKEN INC
8. 課題解決のためのAP2のコア技術 暗号署名された検証可能なデジタル認証情報（VDC） であるMandateを用いて、トランザクションの監 査証跡を作成する。 Mandateは、一般的に「委任された権限」 、 「委任状」といった意味がある。 Mandateには以下の3種類があり、 「人間が介在する」場合と「人間が介在しない」場合のトランザクシ ョンをサポート Intent Mandate： 人間がエージェントに委任する購入意図の条件の証跡。対象の商品、価格、その 他条件などが記載。 「人間が介在しない」場合は、ユーザーが事前に暗号署名をしておく。 Cart Mandate： 提示・決済する商品カートの内容の証跡。 「人間が介在する」場合、この内容を確 認し暗号署名することでユーザーの意思の改ざん不可能な証明となる。 Payment Mandate： 支払い内容や認証情報が記載された証跡。目的として、決済処理業者(PSP)、 決済ネットワーク(Visa等)とIssuer(カード発行者等)に、エージェント取引の可視性を提供する。リ スク評価、不正防止、信頼構築が可能になる。ユーザーにより署名される。 事業開発室 ©DENTSU SOKEN INC
9. AP2のエージェントとロール AP2では、6つの異なる役割を通じて明確な責任・関心の分離を実施し、ロール間での機密データのアクセスを制限している ロール 種別 説明 エンティティ例 User 人間 モノ・サービスを購入するユーザー タスクの委任、Mandateに署名をする 購入者本人 User Agent / Shopping Agent AI Agent ユーザーの意図を理解しMerchantと交渉する ユーザー側のオーケストレーター スマホのユーザー エージェント Credentials Provider AI Agent ユーザーの配送先住所・支払い方法の管理、 カード決済のネットワークトークンの提供 デジタルウォレット Merchant Agent AI Agent 販売元のエージェントで、商品の検索、Cart Mandateの 作成・署名、User Agentへ提示する ECサイトの エージェント Merchant Payment Processor AI Agent Merchantから決済内容(Payment Mandate)を受け取り 決済ネットワークへの決済代行処理を行う PSP (決済サービス プロバイダー) Network and Issuer 外部組織 インフラ・カードの提供者、決済取引を承認しリスクを評価。 状況に応じてチャレンジ(3DS2, OTP)を発行する カードブランド, カード発行会社 事業開発室 ©DENTSU SOKEN INC
10. AP2のエージェントアーキテクチャ全体像 以下はクレジットカード決済を想定したAP2のエージェントアーキテクチャの模式図 エージェント間の通信はA2Aプロトコルに基づいて行われている 事業開発室 ©DENTSU SOKEN INC
11. AP2のトランザクションフロ ー（人が介在する場合） Mandateに関するやり取り 2. Intent MandateをShopping Agentが作成・ 提示 9-11. Cart MandateをMerchant Agentが作成 し、販売元が署名 19. Payment MandateをShopping Agentが作 成 20-24. ユーザーがPayment MandateとCart Mandateへ署名し、Mechant Agentへ送付 DeepWiki AP2：https://deepwiki.com/google-agentic- commerce/AP2/2.5-transaction-flows 事業開発室 ©DENTSU SOKEN INC
12. エージェント間の信頼確立 AP2における各エージェントロールにおいて、他のロールのエージェントの信頼性をどのよ うに担保して接続するかが重要となる 現実装では各エージェントの保有者が、許可リストを用意し、信頼できるエージェントを事 前に定義しておく DeepWiki AP2: https://deepwiki.com/google-agentic-commerce/AP2/2.6-trust-and-dispute-resolution 事業開発室 ©DENTSU SOKEN INC
13. Mandateによる紛争解決 各Mandate（Intent, Cart, Payment）の署名を検証することで、決済で紛争が起こった際に問題の所在を特定し責任境界 を明確にすることができる。 紛争の際には、ネットワーク裁定者はMerchantから各Mandateを収集し、署名、認証局、タイムスタンプ、コンテン ツ、意図の検証を行い、各ロールへ責任を割り当てていく シナリオ 内容 証跡 責任所在 Userの不正 Userが購入したが、後から詐欺だと主張し返金を 要求 Intent Mandate or Cart Mandate User Agentのミスピックに Userが承認 Agentが間違った商品を選択したが、Userが署名し 決済が実行 Cart Mandate User Agentのミスピックに Userが未承認 人がいないケースで、事前署名されたIntent Mandateに反してAgentが自律的に購入 Intent Mandateと取引内 容 Agent Provider 販売業者の不履行 Merchantは支払いを受け取ったが、配達に失敗 Cart Mandateと支払い確 認、履行証明 Merchant 中間者攻撃 攻撃者が転送中にペイロードの改ざん 各Mandateの署名の検証 - 事業開発室 ©DENTSU SOKEN INC
14. AP2の社会実装に向けての課題 AP2を用いたAIエージェント主導の決済が社会実装し、安定的に活用する上で課題が存 在する。以下の2つをピックアップする。 1. 署名に用いる公開鍵/秘密鍵とTrust Roots 2. エージェント間の動的な信頼の確立 事業開発室 ©DENTSU SOKEN INC
15. AIエージェントに関する脅威（1/2） セキュリティコミュニティのOWASPがAIエージェントに関する脅威を17のカテゴリで公開（OWASP, Agentic AI - Threats and Mitigation, https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ ） AP2では、なりすまし(T9)やプロンプトインジェクション(T1, T2)、DoS攻撃(T4)への対策も重要となる TID 脅威名 内容 T1 Memory Poisioning 短期および長期のメモリに、悪意のあるデータを注入し汚染させる T2 Tool Misuse 不正なプロンプトでエージェントを操作し、ツールを権限内で乱用させる T3 Privilege Compromise 権限管理の弱点や動的ロール継承・設定ミスを突いて、不正な権限で操作を行う T4 Resource Overload AIシステムの計算資源・メモリ等を過負荷状態にし、性能劣化や障害を引き起こす T5 Cascading Hallucination Attacks AIにより生成された誤情報を連鎖的に拡散させ、意思決定やツール呼び出しを誤らせる T6 Intent Breaking & Goal Manipulation エージェントの計画設定の脆弱性を突き、目的や推論を操作・逸脱させる T7 Misaligned & Deceptive Behaviors 悪意入力がなくても、目標達成のためエージェントが有害な行為を実行する T8 Repudiation & Untraceability 不十分なログや不透明な意思決定により、エージェントの行為を追跡・説明できなくなる T9 Identity Spoofing & Impersonation 認証を悪用してエージェントやユーザーになりすまし、IDを奪取して不正な操作を行う 事業開発室 ©DENTSU SOKEN INC
16. AIエージェントに関する脅威（2/2） TID 脅威名 内容 T10 Overwhelming Human in the Loop 人間が検証する仕組みを標的にし、人の誤判断や疲労を誘発させる T11 Unexpected RCE and Code Attacks AIの実行環境を悪用し、不正なスクリプト実行や意図しないシステム挙動を引き起こす T12 Agent Communication Poisoning エージェント間の通信チャネルを改ざんして、偽情報の拡散やワークフローの妨害をする T13 Rogue Agents in Multi-Agent Systems 侵害されたエージェントが監視外で不正行動、データ流出を行う T14 Human Attacks on Multi-Agent Systems 人間の攻撃者がエージェント間の委譲・信頼関係を悪用して、権限昇格や処理の操作を行う T15 Human Manipulation 人間がエージェントを過度に信頼する状況を利用して、ユーザー操作、誤情報拡散をさせる T16 Insecure Inter-Agent Protocol Abuse MCPやA2Aなどのプロトコルの欠陥を突いて不正なエージェント操作を行う攻撃 T17 Supply Chain Compromise モデル・ライブラリなどのサプライチェーンが侵害され、有害なコンポーネントを通じて操 作・データ窃取を許す脅威。 事業開発室 ©DENTSU SOKEN INC
17. 課題①： 署名に用いる公開鍵/秘密鍵とTrust Roots 各Mandateに対する署名は、ハードウェアデバイスの隔離領域(TEE/SE)に格納された秘密鍵を用いて署 名し、ペアの公開鍵を用いて検証をする想定 この秘密鍵と公開鍵のペアがユーザー本人のものであることを証明できないと、攻撃者のなりすましが 可能になってしまう（OWASP: T9） 秘密鍵/公開鍵の本人性を担保するための、認証局（CA）のようなエコシステムが必要となる 現時点では以下のような機関が公開鍵を発行/証明し、Trust Rootとすることが提案されている。 DeepWiki AP2: https://deepwiki.com/google-agentic-commerce/AP2/2.6-trust-and-dispute-resolution 事業開発室 ©DENTSU SOKEN INC
18. 課題②: エージェント間 の動的な信頼確立 現実装の許可リスト方式でのエージェン ト間の信頼確立はスケールしないため、 将来的には他のエージェントの信頼性を 動的に確認し接続する仕組みが必要にな る 現時点では実現するための仕組みとし て、以下が提案されている。 mTLSによる相互認証とAPI Key交換に よるCredentials Providerとの接続 HTTPSの証明書検証/DNSの所有権検 証によるMerchantの認証 DeepWiki AP2: https://deepwiki.com/google-agentic- commerce/AP2/2.6-trust-and-dispute-resolution 事業開発室 ©DENTSU SOKEN INC
19. AP2の電通総研の取り組み - 分散型基盤におけるAP2 現状のAP2では商取引(Commerce)を想定している部分が大きく、電通総研としては送金や企業間取引(BtoB)に着目して いる。 また分散型基盤(Web3)におけるAP2の適用を検討しており、以下のような構成で暗号資産を用いた決済のプロトタイプ を実装済み。x402プロトコルを用いて、実際にUSDCを用いた送金ができることテストチェーンで確認できた。 事業開発室 ©DENTSU SOKEN INC
20. 参考資料 Google Cloud: Powering AI commerce with the new Agent Payments Protocol (AP2) https://cloud.google.com/blog/products/ai-machine-learning/announcing- agents-to-payments-ap2-protocol?hl=en AP2 GitHub: https://github.com/google-agentic-commerce/AP2 AP2 DeepWiki: https://deepwiki.com/google-agentic-commerce/AP2 A2A-x402 GitHub: https://github.com/google-agentic-commerce/a2a-x402 事業開発室 ©DENTSU SOKEN INC