ペイメントの現状：エージェンティックコマース、決済、エッジ

AIエージェントは、個人や企業に代わって、検索、比較、推奨、交渉、そして場合によっては取引の完了を行うようになっています。これにより、Web には新たな機会が生まれています。

Web は、人間主導の商取引を処理するのに非常に優れています。人間がオンラインストア内をクリックして移動し、ログインし、商品をカートに追加し、支払い情報を入力して、チェックアウトを行います。このフローには、ブラウザ、ユーザーセッション、チェックアウトページ、そして最終的な決定を下す人間が存在することが前提となっています。

エージェンティックコマースは、この流れを一変させます。買い手は AI エージェントであるかもしれず、売り手は、API、マーケットプレイス、小売サイト、あるいはその他の自動化されたサービスである可能性があります。取引の内容は、通常のカートからの決済、代理購入、定期購読、あるいは単一のリクエストに対するごく少額のマシン間決済など、多岐にわたります。

これにより、プロトコルレイヤーには新たな負荷がかかります。

エージェンティックコマースには、意図、アイデンティティ、認可、支払い要件、支払い証明、および加盟店の応答を表現するための共通の方法が必要です。それがなければ、すべてのエージェント、加盟店、決済プロバイダー、およびプラットフォームが、個別に統合システムを構築することになってしまいます。デモであればそれで機能するかもしれませんが、実際のコマースエコシステムへと規模を拡大することはできません。

本記事は、エージェンティックコマースと、そこにエッジがどのように組み込まれるかについて解説する技術シリーズの第一弾です。本記事では、エージェンティックコマースの現状を概観し、エージェント主導のトランザクションにおいて、なぜエッジが重要な実行ポイントとなりつつあるのかを探ります。

M2M 決済 vs. エージェンティックコマース

マシン間決済とは、あるシステムが別のシステムに支払いを行う仕組みです。プリンターが自らインクを注文するケースがよい例です。その流れは限定的です。インクの残量が少なくなると支払いが発生し、プリンターが支払いの証明を提供すると、注文 API から確認応答が返されます。

一方、エージェンティックコマースの範囲はより広範です。新しい服の購入を支援するチャットボットは、ユーザーの意図、好み、予算、サイズ、スタイル、加盟店の選択肢、カートの変更、決済、返品、サポートなどを理解する必要があります。支払いは、そのプロセスにおける単なる一つのステップに過ぎません。

重複する部分はありますが、これらは同じものではありません。M2M 決済は、特にエージェントが API、ツール、サービスに直接支払いを行う場合に、エージェンティックコマースを支えることができます。しかし、エージェンティックコマースには、AI エージェントが Webサイト、マーケットプレイス、チェックアウトフローなどの通常の加盟店体験を通じてユーザーの購入を支援するケースも含まれます。

その違いはエッジにおいて重要です。

M2M の決済フローは、アクセス制御のように見える場合があります。

• このリクエストは支払いが必要ですか？

• 支払証明は提出されていますか？

• 検証済みですか？

• リクエストはオリジンに届けるべきですか？

エージェンティックコマースのフローは、より広範な検討事項を含みます。

• これは信頼できるエージェントですか？

• リクエストはユーザーの指示と一貫していますか？

• エージェントはこのプロダクトデータを見る必要がありますか？

• リクエストは不審なものですか？

• コンプライアンス、デバッグ、または紛争解決のために、何をログに記録する必要がありますか？

どちらのモデルも、リクエストの近くで処理されることでメリットが得られます。そこでは、決済ポリシー、本人確認、ルーティング、不正の兆候、および発信元保護が一体となって機能し始めます。

eコマースの変化

これには、出版業界との有用な類似点があります。検索、ソーシャルメディア、AI による要約は、読者がコンテンツを見つける方法を変えています。コンテンツを作成するのは依然として出版社ですが、読者との関係の多くは、コンテンツを集約・ランク付けするプラットフォームへと移行しています。

エージェンティックコマースも、eコマースと同様の展開を見せる可能性があります。買い物客がエージェントに「50 USD 未満で最も良いランニングシューズを買って」と頼むと、エージェントは複数の小売店の選択肢を比較し、プロダクトを選んで、買い物客が加盟店のサイトを訪れることなく購入を完了させることができます。

それは購入者にとっては便利ですが、加盟店にとっては深刻な問題を引き起こします。オンラインストア、プロダクトページ、ロイヤルティオファー、バンドル、アップセル、ブランド体験はどうなるのでしょうか？エージェントが発見や比較をコントロールする場合、加盟店がロイヤルティを築いたり最終決定に影響を与えたりする機会が減る可能性があります。

Google Shopping、Amazon、マーケットプレイスにおいて、このパターンの傾向がすでに一部で見られます。エージェンティックコマースでは、ショッピングの過程のさらに多くが自動化されたレイヤーへと移行することで、その動きがさらに加速する可能性があります。

つまり、eコマースチームには、決済サポート以上のものが必要になるということです。チームには、エージェントアクセスのコントロール、プロダクトおよびチェックアウト API の保護、信頼できるエージェントの検証、自動化されたトラフィックの理解、そしてオリジンにリクエストが到達する前のポリシーの強制を行う方法が必要になります。

エッジにおけるエージェンティックトラフィックの管理

エッジは、エージェンティックコマースのポリシーと実際のトラフィックが交差するプログラム可能なコントロールポイントとなり得ます。Fastly の Edge Cloud Platform はリクエストパスに位置しており、トラフィックの検査、ポリシーの適用、シグナルの検証、リクエストのルーティング、オリジンの保護、コマースフローの可視化を行うことができます。

エッジは、クライアントとアプリケーションの間にすでに配置されているため、エージェンティックコマースにとって自然な実行ポイントとなります。リクエストが到着すると、Fastly はそれを検査し、ポリシーを適用し、ID および認可シグナルを評価し、決済関連のメタデータを検証し、そのリクエストを配信するか、ブロックするか、確認を求めるか、あるいはルーティングするかを決定します。API やマシントラフィックの場合、これはオリジンに到達する前に支払いを強制することを意味します。コマースフローの場合、これは加盟店が、どのエージェントがどのルート、プロダクト、またはチェックアウト操作にアクセスできるかを制御できるよう支援することを意味します。

これは、決済プロバイダーに取って代わるものではありません。決済は、引き続き Stripe、Visa、Mastercard、Coinbase、ウォレット、ファシリテーター、銀行、あるいはアプリケーションが選択する決済経路を通じて行われます。

Fastly の役割は、トランザクションの周りにあるプログラム可能なエッジレイヤーです。

そのレイヤーが重要なのは、エージェンティックコマースによって新たなトラフィックパターンが生まれるためです。

• より自動化されたプロダクト発見

• より API に近いチェックアウトフロー

• 委任されたアクションの増加

• ボットのように見えるが、実際には本物の購入者である可能性のあるリクエストの増加

• トラフィックがオリジンに到達する前に、明確なポリシー、検証、ルーティング、およびオブザーバビリティの必要性の増加

エージェンティックコマースのエコシステムは、まだ形成段階にあります。新しいプロトコル、フレームワーク、決済の基本要素が急速に台頭しています。既存の取り組みも急速に変化しており、どの標準が長期的に採用されるかを判断するにはまだ時期尚早です。

こうした不確実性は、Fastly にとって馴染み深い領域です。当社は、IPv6 や TLS 1.3 から HTTP/2、HTTP/3 に至るまで、主要なプロトコルの移行において、お客様が適応できるよう支援してきました。最近では、お客様がエッジで AI ボットトラフィックに対応できるよう支援しています。どの AI ボットがクロールしているかを把握し、許可またはブロックするボットを決定し、不要な自動処理がアプリケーションに到達する前にポリシーを適用する支援を行っています。

エージェンティックコマースも同様のパターンをたどります。AI エージェントの中には、実際の顧客や正当な購入意図を代表するものもあれば、プロダクトデータをスクレイピングしたり、チェックアウトフローを悪用したり、新たな不正行為やオリジンへの負荷を生み出したりするものもあるでしょう。

Fastly なら、エッジインフラストラクチャがエコシステムの変化に合わせて適応できるよう構築されているという確信を持てます。そのため、貴社のチームは優れたカスタマーエクスペリエンスの提供に集中し続けることができます。

関連するエージェントプロトコル

コマースや決済に特化したプロトコルについて掘り下げる前に、MCP や A2A のようなより広範なエージェントインフラストラクチャとそれらを区別しておく価値があります。MCP は、AI アプリケーションがツール、データ、ワークフローに接続するのを支援します。A2A は、エージェント間の通信と調整に焦点を当てています。どちらもエージェンティックコマースのフローに現れる可能性はありますが、それら単体ではコマースの課題を解決することはできません。これらはエージェントの行動や連携を支援します。以下のプロトコルは、ショッピング、認可、決済、信頼に重点を置いています。

コマースプロトコル

現在、業界では、AI エージェントが実際のショッピング体験を円滑に進められるよう支援するため、2つの主要なコマースフレームワークを中心に動きが活発化しています。

1. UCP (ユニバーサルコマースプロトコル)

これは Google と Shopify が支援しています。このプロトコルは、加盟店のカタログ、商品の在庫状況、価格、カート、チェックアウト、フルフィルメント、顧客コンテキスト、注文状況など、AI エージェントとコマースシステムとのやり取りを簡素化するものです。その核心となる考え方は、加盟店が AI インターフェースごとに独自の統合を行う必要がないようにすることです。コマースデータやアクションが共通のフォーマットで表現できれば、エージェントはより一貫した方法で商品を検索し、カートを作成し、チェックアウトへと進むことができます。

UCP プロトコルについて詳しくはこちら

1. ACP (エージェンティックコマースプロトコル)

これは OpenAI と Stripe が支援するオープンスタンダードです。ACP は、買い手、エージェント、事業者間のプログラマブルなコマースフローに重点を置いています。これは OpenAI が Stripe と連携して取り組む Instant Checkout を支えるプロトコルであり、加盟店がプロダクトやチェックアウトフローをエージェント主導の体験に展開する手段を提供します。ACP は単なる決済処理というよりも、コマースのインタラクション自体をエージェント対応にすることに焦点を当てています。

ACP プロトコルについて詳しくはこちら

UCP と ACP のどちらも AI エージェントがユーザーのために自律的に買い物をできるようにするものですが、そのアプローチは異なります。UCP は、オープン Web 全体にわたる広範なプロダクト発見とカタログ化を目的として設計された、オープンで分散型の標準規格です。一方、ACP は、特定の AI プラットフォーム内での迅速かつトークン化された決済を実現するための、一元化され高度に最適化されたチェックアウトレールです。最終的には、これらは相互に補完的な関係にあります。加盟店は、オープンウェブでの可視性を高めるために UCP を活用しつつ、安全で摩擦のない最終的なチェックアウトを実行するために ACP を利用することができます。

認可および決済プロトコル

商品を見つけてカートに追加すること自体は、インフラ面での課題としてはそれほど難しいものではありません。複雑さが生じるのは、AI エージェントが取引を承認し、実際にお金を移動させる必要がある場合です。

人間とは異なり、ボットはクレジットカード番号を入力したり、CAPTCHA を解決したりすることはできません。

これらの自律型トランザクションを機能させるには、2つの異なるステップを処理できるバックエンドインフラストラクチャが必要です。

1. 認可 (エージェントが、金銭を支出するためのユーザーからの明示的な委任を受けていることを証明すること)

2. 決済 (プログラムによる資金のルーティングで、従来のクレジットネットワークから機械間 API の生の ping まで多岐にわたります)

こうした認可および決済の課題に対処するため、いくつかの競合するプロトコルが登場しつつあります。

• AP2 (Agent Payments Protocol) は、安全なエージェント決済のためのオープンプロトコルとして Google によって導入されました。AP2における重要な概念は認可です。エージェントがユーザーに代わって支出を行う際、加盟店や決済事業者は、ユーザーが実際にその権限を委任したことの証明を必要とします。AP2 では、ユーザーの意図、制約、承認を表すことができる署名付き委任状が導入されています。https://ap2-protocol.org/ 

• Visa TAP (Trusted Agent Protocol) は、エージェントと加盟店との間に信頼を構築するための Visa のアプローチです。TAP は、加盟店が正当な委任代理人の活動と、正体不明の自動プログラムや悪質なボットによる活動を区別できるよう支援することを目的としています。エージェントが誰であり、誰を代表し、何を行う権限があるかを識別する信頼できる方法がない限り、エージェントトラフィックはボットトラフィックのように見える可能性があるため、これは重要です。https://developer.visa.com/capabilities/trusted-agent-protocol 

• Mastercard Agent Pay は、Mastercard のエージェンティック決済フレームワークです。このフレームワークは、Mastercard のネットワーク、トークン化、管理機能、認証機能を活用して決済フローに参加する、信頼性の高い AI エージェントに焦点を当てています。また、Mastercard は、バックグラウンドで継続的に発生する高頻度かつ少額の機械決済を対象とした Agent Pay for Machines も導入しました。https://www.mastercard.com/us/en/business/artificial-intelligence/mastercard-agent-pay.html 

• x402 は異なるアプローチをとっています。これは、HTTP 402 Payment Required ステータスコードを復活させ、それをウェブネイティブな決済チャレンジとして利用するものです。クライアントが保護されたリソースをリクエストすると、サーバーは支払い要件を伴う 402 を返します。クライアントは支払いを行い、支払い証明を添付して再リクエストを行います。決済が HTTP リクエストフローの一部となるため、これは特に API の収益化、エージェントアクセス、およびマシン間決済において興味深い仕組みです。https://www.x402.org/ 

• Stripe MPP (Machine Payments Protocol) は、エージェントとサービス間のプログラムによる支払いのための Stripe と Tempo によるオープンプロトコルです。MPP はマイクロトランザクション、定期支払い、自動サービス間購入などの機械決済向けに設計されています。x402 と同様に、完全なショッピングフローレイヤーよりも決済プリミティブレイヤーに近い位置づけとなります。https://stripe.com/blog/machine-payments-protocol 

これらの注目度の高いプロトコルイニシアチブに加え、第三者はエージェンティックコマースを中心としたアイデンティティ、ウォレット、決済、認証レイヤーも構築しています。

次に取り上げる内容

本シリーズの続きでは、エージェンティックコマースを形成するコマースプロトコルや、認可および決済プロトコルについてさらに詳しく掘り下げていきます。

まず、x402 から取り上げます。これはリクエストパスに明確にマッピングされ、支払いがどのように HTTP アクセス制御の一部となり得るかを示しているからです。その後、Stripe MPP、ACP、およびその他の新興プロトコルに関する関連記事やデモを紹介していきます。

目標は、実用的な実装に即した内容にすることです。具体的には、これらのプロトコルが実際のリクエストフローでどのように動作するか、エッジがポリシーとルーティングの連携にどのように役立つか、そして Fastly が、エージェンティックコマースのエコシステムが成熟するにつれて、そのエコシステム全体にどのような価値をもたらせるか、といった点に焦点を当てます。

Skyfire の Know Your Agent (KYA) 認証情報と Fastly Compute を使用して AI エージェントの検証、決済シグナルの妥当性確認、コマースおよびコンテンツ体験へのアクセス制御を行う実践的な導入例について詳しくは、「How Fastly and Skyfire Enable Trusted Agentic Commerce at the Edge」をご覧ください。