Agent Factory のハイライト: エージェントによる買い物代行
Shir Meir Lador
Head of AI, Product DevRel
※この投稿は米国時間 2025 年 9 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。
Agent Factory のエピソード 8 では、Ivan Nardini と私が、Agent Payment Protocol チームのプロダクト マネージャーである Prateek Dudeja を迎え、e コマースにおける AI エージェントの大きなハードルである信頼、特にお金に関する信頼について掘り下げます。
この投稿では、今回の対談からの重要なアイデアをいくつか紹介します。なお、この投稿は、トピックをすばやく振り返ったり、リンクやタイムスタンプを使用して特定のセグメントを詳しく調べたりできるような構成になっています。
Agent Payment Protocol のご紹介
タイムスタンプ: [01:43]
チケットの発売が開始される特定の時間に、エージェントが代わりにコンサートのチケットを購入してくれたらどうでしょうか。ぜひ活用したいですよね。チケットを 2 枚購入したいが、200 ドル以上は使いたくない、そしてステージがよく見える席に座りたいと考えているとしましょう。エージェントにチケット購入を依頼する場合、エージェントがさまざまな希望条件を満たすことを信じ、クレジット カードをエージェントに委ねる必要があります。エージェントがチケットを 200 枚購入したり、アヒルのおもちゃを大量に買ったりしないと、どうしたら確信できるでしょうか。
このコンサート チケットのリクエストで起こりうるアクシデントに対する懸念こそが、エージェント コマースの導入障壁となる「信頼の危機」です。幸いなことに、これを乗り越えて信頼を築く方法はあります。
この「信頼の危機」を解決するために、Google は新しいオープン スタンダードである Agent Payment Protocol（AP2）を導入しました。これは新しい決済システムではなく、既存のインフラストラクチャの上に置かれる「信頼レイヤ」です。AP2 は、ロールベースのアーキテクチャと検証可能な認証情報を使用して、エージェントが商取引を行うための安全な共通言語を提供するように設計されています。
エージェント決済と現在の決済システム
タイムスタンプ: [02:29]
現在の決済システムは、ブラウザなどの信頼できるインターフェースを使用する人間向けに構築されたものであり、自律エージェント向けではありません。そのため、エージェントには承認、エージェント エラー、説明責任という 3 つの主な課題が生じます。
Agent Payment Protocol は、エージェントが販売者や決済パートナーと安全にコミュニケーションできるようにすることで、これらの課題に対処します。このプロトコルは現在、A2A（Agent2Agent）プロトコルの拡張機能として利用可能で、エージェントが Model Context Protocol（MCP）を使用していることを条件としています。
Agent Payment Protocol の仕組み
コンセプトやフローなど、このプロトコルの仕組みについて詳しく説明します。
ロールベースのエコシステム
タイムスタンプ: [04:33]
このプロトコルは「関心の分離」に基づいて構築されています。1 つのエージェントがすべてを行う必要はなく、それぞれのエージェントが専門的なロールを担います。
-
ショッピング エージェント: 商品検索に優れた、ユーザーが構築する AI エージェント。
-
販売者エンドポイント: 販売者の API。
-
認証情報プロバイダ: 支払い情報を管理する安全なデジタル ウォレット（PayPal、Google Pay など）。
- 販売者の決済代行業者: 決済ネットワークの最終的な承認メッセージを作成するエンティティ。
重要: ショッピング エージェントが未加工のクレジット カード番号にアクセスすることはありません。専門の安全なプロバイダに支払いを委任するため、PCI に対する準拠は不要です。
検証可能な認証情報（VC）
タイムスタンプ: [06:15]
Agent Payment Protocol エコシステムでは、こうしたロール間の「ハンドシェイク」が検証可能な認証情報（VC）によって保護されます。認証情報は、合意内容を証明する、プロトコル化された暗号署名付きのデジタル領収書のようなものです。
検証可能な認証情報には、次の 3 種類があります。
Cart Mandate:「人間が関与する」シナリオの場合。ユーザーは最終的なカートを確認し、承認の証明として暗号署名します。
Intent Mandate:「人間が不在」のシナリオ（コンサート チケットの例など）の場合。ユーザーが Intent（「200 ドル以下のチケットを購入して」などの意向）に署名し、エージェントがそのガードレール内で行動することを許可します。
Payment Mandate: AI エージェントが取引に関与したことを決済ネットワークと銀行に明確に通知します。
契約型、会話型モデル
タイムスタンプ: [08:03]
Agent Payment Protocol プロセスでは「契約型、会話型モデル」が作成され、単純な API 呼び出しを超え、検証可能な証明に基づいて構築されたフローに移行します。
このフローを理解するために、人間が関与するシナリオを見ていきましょう。
-
委任: ユーザーがエージェントに「コンサートのチケットを 2 枚買って」と指示します。
-
検出と交渉: エージェントが販売者のエンドポイントに接続してカートを準備します。
-
カートの確定: エージェントが認証情報プロバイダ（デジタル ウォレットなど）に連絡します。ユーザーが支払い方法を選択します。エージェントが取得するのは参照情報（下 4 桁など）のみで、認証情報の全体は取得しません。
-
Mandate による承認: エージェントが最終的なカートをユーザーに提示します。
-
ユーザーが Cart Mandate に暗号署名します。これが否認できない証明、つまり「契約」となります。
-
購入: エージェントは署名された Mandate を販売者に送ります。こうすることで、販売者は購入の指示がユーザーからのものであるという確証を得られます。販売者の決済代行業者は、Mandate を使用して認証情報プロバイダから支払いトークンを安全に取得し、取引を完了します。
このフローはすべて信頼に基づいています。短期的には、承認されたエージェントと販売者の手動による許可リストを使用して、この信頼を構築します。長期的には、HTTPS や DNS 所有権などのオープンウェブ標準を使用して ID を検証する計画です。
Prateek Dudeja との質疑応答
タイムスタンプ: [13:07]
コンセプトの説明が終わると、Prateek との質疑応答に移りました。
新しい支払いプロトコルが必要な理由
タイムスタンプ: [13:30]
Prateek はブラウジングのベースライン プロトコルである HTTPS の例を挙げました。HTTPS でのログインには強力な認証が必要ですが、支払いを行うには、さらに高いレベルの信頼が必要です。AP2 は、A2A や MCP などのベースライン プロトコルに加えて「決済グレードのセキュリティ」を提供し、取引の信頼性が高く、実際に人間によって行われたものであることを保証します。
代理店はどのように信頼できるパートナーを見つけるか
タイムスタンプ: [14:42]
短期的には、エージェントは「信頼の分散型レジストリ」（または許可リスト）を使用して、やり取りできる販売者を見つけます。Prateek は、すべてのロール（販売者、認証情報プロバイダなど）がすでに今日の決済業界に存在すると指摘しました。新しいロールはショッピング エージェントのみです。
説明責任: 問題が発生した場合の対処方法
タイムスタンプ: [16:03]
これは大きな疑問です。たとえば、エージェントがブルーの靴を提示したとします。ユーザーはティール ブルーの靴が欲しかったのですが、それでも「承認」をクリックしてしまいました。
Prateek は、署名付きの Cart Mandate でこの問題を解決できると説明しました。ブルーの靴を表示した改ざん防止認証情報に生体認証で署名したため、この場合、責任はユーザーにあります。販売者は、ユーザーが同一の商品を見て承認したという暗号化された証拠を持っています。これにより、不正なチャージバック（代金請求の差し戻し）から販売者を保護し、エージェントによる未承認の行動からユーザーを保護します。
デモ: リファレンス実装
タイムスタンプ: [18:04]
Prateek は、人が関与するフローを示すデモを行いました。ユーザーがエージェントにプロンプトを入力し、エージェントが商品を見つけ、認証情報プロバイダ（PayPal）が関与する様子が示されています。ユーザーは配送先情報と支払い情報を PayPal から選択し、エージェントは参照情報のみを確認しました。その後、ユーザーは Cart Mandate に署名し、購入手続きが完了しました。
互換性とスタートガイド
タイムスタンプ: [19:43]
LangGraph や CrewAI などのフレームワークと互換性があるかどうか、という大きな問題がありますが、答えはイエスです。このプロトコルはあらゆるフレームワークと互換性があると Prateek は断言します。エージェントが A2A または MCP を介して通信できる限り、AP2 を使用できます。
使用を開始するにはまず GitHub リポジトリにアクセスします。どのロール（販売者、認証情報プロバイダなど）を担うかを決め、そのロールのサンプルコードを確認してください。
今後の展望: 動的な交渉
タイムスタンプ: [21:13]
今後の展望として、Prateek は「動的な交渉」というエキサイティングなビジョンを共有しました。あるユーザーが「在庫切れのあの赤いワンピースが欲しい。明日までに必要です。30% 増しの料金を支払います」と自分のエージェントに指示するとします。
販売者のエージェントは、この「意向」を確認し、ワンピースが入手可能になったら自動的に販売を完了できます。販売者にとっては、逃したはずの販売機会がさらに高い利幅での注文の完了となり、ユーザーは切実に求めていた商品を正確に手に入れることができます。
構築してみる
この対談では、安全な決済インフラストラクチャの構築が、実世界で真に有用なタスクを実行できるエージェントを作成するための基礎的なステップであることが明らかになりました。シンプルでプログラマティックなウェブの時代から、会話型 / 契約型のウェブの時代へ移行が進むなか、このプロトコルは、そのためのフレームワークを提供します。
Agent Payment Protocol の GitHub リポジトリをチェックして、この新しいエコシステムでどのロールを担うかを検討し、今すぐ構築を始めてみましょう。
ソーシャル メディア
-プロダクト DevRel、AI 担当責任者 Shir Meir Lador
