エージェンティックコマースは、消費者と企業が商品を発見する方法を変えています。その過程で、決済体験を根本から再設計しています。チャットインターフェイス内でネイティブに購入を完了できるエージェントもあれば、自社のウェブサイトにリダイレクトするエージェントもあります。いずれの場合でも、エージェントが商品の発見や決済をどのように処理するかに関係なく、こうしたユーザー体験要件に対応できるよう準備することが必要です。売り手にとっては大きなチャンスですが、商品発見、決済、不正利用対策へのアプローチも見直す必要があります。
過去 6 カ月間、SaaS スタートアップから Fortune 500 にリストされた小売業者まで、数十社のエージェンティックコマース準備企業と対話してきました。エージェンティックコマースは急速に進化していますが、課題は変わりません。まずどのチャネルを立ち上げるべきか、エージェントに発見されるにはどうすればよいか、この新しいチャネルで不正利用とリスクを管理するにはどうすればよいか、そして新たに立ち上がるすべてのエージェントに個別の連携を構築することなく、これらすべてを実現するにはどうすればよいか、ということです。
このガイドは、こうした対話や議論、およびエージェントを通じた販売に向けて準備を進める大手企業との Stripe の取り組みをもとにまとめたものです。
エージェンティックコマースを初めて検討する場合でも、アプローチを磨く場合でも、エージェンティックコマースを軸とした組織の整備から、カタログの最適化、適切な技術パートナーの選定まで、ビジネスの準備に向けた実践的なステップを概説します。このガイドはすべてを網羅したものではなく、企業が成功裏に実践している主要な戦術を取り上げています。
1. エージェンティックコマースで目指す目標を明確にする
エージェンティックコマースは、少なくとも 3 つの主要なモダリティに分類されており、それぞれ異なる目的に対応しています。すなわち、商品発見を目的とした会話型チャット、コンバージョン最適化のための広告内ショッピング、エンゲージメントと顧客維持のためのファーストパーティーアシスタントです。エージェンティックコマースでどの目標を達成したいかを明確にすることが重要です。
NikeAI や Ralph Lauren の Ask Ralph などのファーストパーティーエージェントは、主にエンゲージメントを目的としています。これらのエージェントは、既存顧客との関係を深め、ブランド管理を維持し、アイデンティティや好みなどの顧客コンテキストを維持しやすくします。Microsoft Copilot などのサードパーティエージェントは、主に新規顧客獲得を目的としています。顧客がすでにいる場所で接点を持ち、純粋な新規需要の獲得を支援します。
エージェントによる広告内ショッピングは、エージェントが広告画面から直接取引を完了できるようにする新たな機会です。たとえば、Stripe は Facebook への新しい決済体験の導入を支援しています。これにより、買い手は企業のウェブサイト経由でも、広告クリック後の Facebook アプリ内でも、ワンクリックで Fanatics や Quince などの企業の商品を購入できます。このモダリティは、広告のパフォーマンスと計測の改善に注力する企業にとって特に有益です。
Stripe の推奨は、顧客獲得、エンゲージメント、コンバージョンのいずれであれ、すべてのモダリティに一度に対処するのではなく、当面のビジネス目標に沿った機会に焦点を絞ることです。一方で、この状況が急速に変化することも想定しておく必要があります。新しいモダリティが出現し、エージェントの行動が進化するにつれて、事業者とともに変化に適応し、技術的な複雑さを抽象化できるベンダーとの連携がますます重要になります。
2. エージェンティックコマースを中心に組織体制を構築再編する
多くの企業は、エージェンティックコマースを純粋な技術プロジェクトとして捉えていますが、最も急速に進歩を遂げている企業は、真のボトルネックが組織にあることを認識しています。優先事項が食い違うサイロ化されたチーム、データに対する見解が異なる経営陣、明確なエージェントプロダクトオーナーの不在はすべて、社内での課題につながる可能性があります。
最も速く前進している企業は、リーダーシップの優先事項を再調整し、新たな役割を創出し、非人間トラフィックを軸とした部門間の連携方法を見直しました。
- データをインフラとして C スイート全体の方針を統一する。 エージェンティックコマースへの準備に成功した企業では、データの使用方法の根本的な変化に関して、最高情報責任者 (CIO)、最高技術責任者 (CTO)、最高データ責任者 (CDO)、最高マーケティング責任者 (CMO) の間で足並みが揃うという共通のパターンが確認されています。これらの組織は、データを純粋に分析ツールとして捉えるのではなく、トランザクションインフラとして扱うようになりました。たとえば、CIO は焦点を社内法令遵守から外部 API の可用性に拡大し、CDO は収益機能としてデータ品質管理を担う場合があります。
- マーケティングと IT の運用方法を調整する。 マーケティングチームは、構造化データと明確な仕様を、説得力のあるストーリーテリングと並行して優先しています。SEO チームはエージェントエンジン最適化 (AEO) のスペシャリストを採用しています。IT チームとセキュリティチームは、悪意のあるスクレイパーと正当なエージェントを区別する方法を習得し、正規のマシントラフィックをブロックせず優先させるよう対応しています。
- エージェントプロダクトマネージャーの採用を検討する。 大手企業は、エージェント体験を担う新たな役割を定義しています。こうした人材は通常、API エンジニアリングとマーチャンダイジングの専門知識を組み合わせています。ビジュアルインターフェイスを担う従来の PM とは異なり、エージェントプロダクトマネージャーは、エージェントがブランドをどのように認識するかをテストし、機械可読コンテンツを最適化し、エージェント主導の取引のコンバージョン率を監視しています。
3. エージェントに自社の存在を知らせる
エージェンティックコマースの準備を進めるにあたり、最初に検討すべき技術的な課題の 1 つが発見可能性 (ディスカバラビリティ) です。エージェントは、人間の買い物客とは異なる方法で商品を発見します。視覚的にウェブサイトを閲覧することも、ナビゲーションメニューをクリックすることもありません。その代わりに、構造化データを読み取り、テキストファイルを解析し、技術的なシグナルに基づいて、販売している商品や、エージェントのトラフィックを受け入れているかどうかを把握します。
インフラストラクチャーがこのような発見（ディスカバリー）に対応するよう設定されていない場合、エージェントを通じて買い物をする顧客から見えなくなるリスクがあります。
- ウェブサイトがエージェントを受け入れられるようにする。 robots.txt ファイルとファイアウォールの設定で、
GPTBot、ClaudeBot、Google-Extendedなどの既知のエージェントクローラーが許可されていることを確認します。ビジネスモデルがコンテンツ自体 (ニュース出版社やデータプロバイダーなど) である場合は、公開するコンテンツをより慎重に選択するか、マシン決済を使用してデータを無償提供するのではなくライセンス付与することも検討に値します。 - エージェントがコンテンツを読み取る方法を最適化する。 エージェントは、クライアント側のレンダリングに大きく依存するウェブサイトの処理に苦労します。クライアント側のレンダリングでは、コンテンツはブラウザーの JavaScript を介して読み込まれます。また、ナビゲーションメニューや広告が散在する重い HTML ページの解析も困難です。コンテンツをサーバー側でレンダリングするか (コードを実行せずにすぐ読める状態にする)、ルートディレクトリにシンプルなテキストファイル (/llms.txt など) を公開して、主要な商品カテゴリー、ポリシー、重要情報をわかりやすい言葉で一覧表示することを検討する価値があります。
エージェンティックコマースの技術インフラストラクチャーを最適化する方法の詳細については、エージェンティックコマースの準備に関する技術フィールドガイドをご参照ください。
4. エージェント向け商品カタログフィードに投資する
商品フィードはまだすべてのエージェントが利用できるわけではありませんが、エージェントが自社の商品を発見するための重要なエントリーポイントになることが期待されます。エージェントは自社のウェブサイトをクロールして商品情報を収集できますが、ダイレクトな商品カタログを活用すると、低速で予測しにくいクロールサイクルを待つことなく、商品の変更をすぐにエージェントへ届けることができます。また、公開タイミングを正確にコントロールでき、エージェントの画面上に商品が表示される日付を指定することも可能です。さらに、商品カタログによってエージェントに最新かつ正確な価格、在庫状況、仕様を提供することで、商品リンクの切れなどによるハルシネーションの低減にも役立ちます。
課題が 1 つあります。エージェントが異なれば、自社データを要求する形式も異なる可能性が高いという点です。1 つは SFTP ファイルのドロップが必要なケース、もう 1 つはカスタム API 連携を求めるケース、3 つ目は完全に独自のフィード仕様を持つケースもあります。すでに、同じ商品カタログを 6 種類の異なる形式に再フォーマットして複数のエージェントへの掲載を実現したブランドも見受けられますが、これは継続的なメンテナンスの負担を生み出し、時間とリソースを消耗させます。
カタログをどこにでも配布できるコマースプロバイダーと提携することで、こうした課題に備えることができます。Stripe の Agentic Commerce Suite を使用すると、カタログを Stripe に直接アップロードするか、既存のシンジケーターと連携するかを選べます。Stripe が各 AI エージェントに商品情報を自動的に配信します。
5. 新しい不正利用とリスクパターンに備える
従来の不正利用シグナルは、閲覧パターン、入力速度、マウスの動きなど、人間の行動に合わせて調整されています。エージェントはこれらのパターンを示さないため、正当なエージェントであっても不正利用としてフラグが立てられる可能性があります。同時に、エージェントは新たな不正利用の経路ももたらします。不正行為者は、エージェントを操作してリスクの高い注文を行い、通常のガードレールを迂回し、エージェントの取引速度を悪用する可能性があります。適切なシステムが整備されていなければ、チャージバックの増加、収益の損失、顧客の信頼損失といったリスクが生じます。
- 予測できないエージェントの動作に対するコントロールを構築する。 エージェントの動作は、ロジックのバグや、カタログの解釈方法の違いが原因で予測できないことがあります。たとえば、エージェントが価格ルールや商品属性を意図とは異なる方法で解釈する可能性があります。エージェンティックコマースの拡大に伴い、業務全体を中断することなく問題に対処できるきめ細かいコントロールが必要になります。具体的には、人間の買い物客に影響を与えることなく、特定の決済トークンを取り消す、または特定のエージェントのアクセスを調整する機能などが考えられます。
- エッジケースが発生する前にポリシーを確立する。 財務および法務チームは、エージェンティックコマースの開始前に、通常とは異なるエージェント主導の取引を処理するためのポリシーを定義する必要があります。たとえば、エージェントが想定外の割引コードや配送先など、予期しないパラメーターで取引を処理するケースが考えられます。$50 未満の差異は自動承認、それを超える場合は手動レビューといった、事前に定めたしきい値を設けることで、チームはプレッシャーのもとで判断を下すのではなく、一貫して対応できるようになります。
- エージェンティックコマース用に構築された決済プリミティブを使用する。 多くの企業は、AI コマース向けに設計された決済プリミティブである Stripe の共有決済トークン (SPT) を使用して、これらの課題に取り組んでいます。SPT を使用すると、エージェントは認証情報を公開することなく、買い手の許可と希望する決済手段を使用して決済を開始できます。Stripe で使用すると、SPT は Stripe Radar を搭載し、不正利用による不審請求の申し立ての可能性、カードテスティング、盗難カード、その他の不正利用インジケーターなど、背後にあるリスクシグナルを中継して、購買意図の高いエージェントと信頼性の低い自動ボットを区別します。
6. 技術スタックを見極める
エージェンティックコマースが具体化するにつれて、決済体験自体も進化しています。エージェントが顧客を自社のウェブサイトにリダイレクトして取引を完了させるケースもあれば、エージェント内でネイティブに決済を完結させるケースもあります。そのため、エージェントの決済フローに組み込む方法を把握するとともに、自社サイトでも高速で最適化された決済フローを用意することが必要です。
技術的な複雑さは決済にとどまりません。AI エージェントごとに、商品データの受信方法と取引の処理方法に関する要件が異なります。複数のエージェントをサポートするには、個別の連携を構築・維持する必要があり、エージェント 1 件あたり数カ月を要する作業に加え、要件の変化に応じた継続的なメンテナンスも発生します。組み込み型決済、企業の決済へのリダイレクト、広告内購入のいずれのモダリティが主流になるかはまだ不明です。その結果、企業は何を基準に構築すべきかという難しい問題に直面しています。
エコシステムに柔軟に対応できるパートナーの選定が重要です。プロトコルの変化や決済パターンのすべてを追跡する専任チームを配置しない限り、その複雑さを抽象化できるパートナーが必要です。つまり、単なる決済代行業者にとどまらず、商品フィード、決済の最適化、不正利用対策、プロトコル変換を処理するインフラストラクチャーが求められます。最も積極的な企業は、プロトコルや決済モダリティ間の相互運用性をサポートするパートナーを求めており、エコシステムがどの方向に進んでも、一度の対応で互換性を維持できる体制を整えています。たとえば、Stripe は Stripe の Agentic Commerce Protocol (ACP) や Google の Universal Commerce Protocol (UCP) など複数のプロトコルをサポートし、エージェントが自社サイトにリダイレクトするかネイティブで取引するかを問わず機能する、最適化された決済インフラストラクチャーを提供しています。一度構築すれば、次に何が起きても適応できます。
Stripe によるサポート
Agentic Commerce Suite を使用すると、商品を見つけやすくし、決済をシンプルにし、一度の導入でエージェントによる決済を受け付けることができるため、AI エージェントによる販売に対応できます。URBN (Anthropologie、Free People、Urban Outfitters など)、Etsy、Ashley Furniture、Coach、Kate Spade、Nectar、Revolve、Halara、Abt Electronics などの大手ブランドがすでに Agentic Commerce Suite の導入を開始しています。
Agentic Commerce Suite を使用すると、一度構築すれば、新しいモダリティ、プロトコル、エージェントの出現に適応し、エージェンティックコマースの避けられない変化に対してビジネスの将来性を確保できます。
エージェントが商品を発見できるようにする
Agentic Commerce Suite は、専用のホスト型 ACP エンドポイントを提供し、既存システムへの変更を最小限に抑えながら、AI エージェントとほぼリアルタイムで商品、価格、在庫情報を共有します。商品カタログを Stripe に直接アップロードするか、主要な商品シンジケーターから既存の商品カタログを連携させることができます。その後、Stripe が各 AI エージェントに商品情報を配信し、ワンクリックで対応するすべてのエージェントでの自動決済受付を開始できます。
決済を簡素化し、顧客関係に対する小売業者の管理権限を確保する
Agentic Commerce Suite は、Stripe の Checkout Sessions API を利用しており、配送料や税金など、決済のさまざまな側面をサポートします。Stripe Tax などの Stripe の組み込み製品を使用して Stripe に管理を委託することも、既存のコマーススタックを使用して、システムへの変更を最小限に抑えながら、税コードのアップロード、ほぼリアルタイムの在庫チェックの管理、動的な配送料金の設定を行うこともできます。
顧客がエージェント取引を完了すると、既存の社内注文およびフルフィルメントプロセスを利用するだけです。また、マーチャントオブレコードとして、返金や不審請求の申し立ての管理方法など、顧客関係に関するすべての管理権限も保持します。
エージェントによる決済を受け付け、新たな不正利用から保護する
ビジネスの保護を支援するために、Agentic Commerce Suite は、エージェンティックコマースの新しい決済プリミティブである SPT を受け付け、処理します。すべてのトークンは、特定の売り手に限定でき、時間と金額で制限され、ライフサイクル全体を通じて監視できるため、不正なエージェントによるアクションを防止し、不審請求の申し立ての可能性を低減できます。
Stripe で使用すると、SPT は Radar を活用して、取引と決済手段の詳細を用いながら背後にあるリスクシグナルを中継し、購買意図の高いエージェントと信頼性の低い自動ボットを区別することもできます。その結果、売り手固有のデータ履歴を数週間積み重ねることなく機能する、エンタープライズクラスの不正利用対策が実現します。
Agentic Commerce Suite は、AI エージェントで販売を開始できるビジネスの数を大幅に拡大する助けとなります。待機リストに登録して、導入ガイドで詳細をご確認ください。