次世代のコマースに向けたインフラストラクチャの開発は大きく進展しています。過去 6 カ月間に、買い手、AI エージェント、売り手が API を通じて取引できるようにするオープンソース仕様である Agentic Commerce Protocol (ACP) をリリースしました。また、Agentic Commerce Suite を備えた初の完全なエージェンティックソリューションを導入し、URBN (Anthropologie、Free People、Urban Outfitters を含む) や Etsy などの主要ビジネスをオンボーディングしました。さらに、AI エージェント全体で AI ショッピング体験を強化しました。最近では、マシン決済のサポートを開始し、エージェントがコンテンツやデータを直接収益化できるようにしました。
その過程で、アジャイルな SaaS スタートアップ企業や B2B プラットフォームから、大手通信会社、公益事業会社、フォーチュン 500 に名を連ねる小売企業まで、多数のビジネスと協議してきました。すべてのセクターがエージェンティックコマースに備えています。
どの会話でも、ビジネスは同じような疑問を抱いています。どのチャネルを最初に立ち上げるべきか、どのようにしてエージェントに見つけてもらうか、そしてこれを構築するための適切なパートナーをどう見つけるかという点です。
これらの質問は、主に 5 つのテーマに集約されます。
- エージェントへの認知度の確保
- エージェントによるサイトの使用方法の理解の支援
- 人間以外のトラフィックを処理するためのサイトの構成
- エージェンティックコマースに向けた組織の連携
- AI ガバナンスの確立
このガイドは、実際の会話や、エージェンティックコマースを準備、導入している主要ビジネスとの連携における Stripe の深い専門知識に基づいています。エージェンティックコマースを初めて検討する場合でも、既存の戦略を改善する場合でも、この技術的なフィールドガイドでは、ビジネスをエージェンティックコマースに最適化するために今すぐ実行できる具体的な方法を説明しています。これは網羅的なリストではなく、他のビジネスが実装して成功を収めている主要な戦術をカバーしています。
1. エージェントに存在を認識させる
エージェントに推奨されるには、可視性を高める必要があります。これには、技術的なインフラストラクチャがエージェントを遠ざけるのではなく受け入れるようにし、最適化された商品カタログフィードを展開する必要があります。モデル自体がまだ進化している段階で、ディスカバリー戦略を正式なものにするのは時期尚早ですが、エージェントがウェブサイトや商品カタログを解析して理解する方法を改善するために、今すぐ実行できる具体的なステップがあります。
robots.txt ファイルとファイアウォール設定でエージェントが許可されていることの確認
一部の企業は、データを保護しようとして、これらの AI レコメンデーションを強化するクローラー (GPTBot や Google-Extended など) を無意識のうちにブロックしています。エージェントをブロックすると、ウェブサイトは実質的に見えなくなります。
機密性の高い管理ルートを公開することなく、robots.txt をエージェンティックなディスカバリーに最適化するには、検証済みのコマースエージェントと一般的なスクレイパーを区別する必要があります。まずは、既知のエージェントのユーザーエージェント (GPTBot、ClaudeBot、Google-Extended など) と現在の構成を照らし合わせることをお勧めします。更新されたリストと構成の例は、OpenAI、Anthropic、Google の公式クローラードキュメントで直接確認できます。これにより、検証済みの AI エージェントと悪意のあるスクレイパーを区別できます。
また、価値の高い静的コンテンツ (商品詳細ページやカテゴリーアーカイブなど) へのアクセスを明示的に許可し、コストのかかる動的パス (内部検索結果、カートへの追加アクション、動的価格設定の API エンドポイントなど) を厳密に禁止することもできます。これにより、無駄なコンピューティングサイクルからインフラストラクチャを保護しつつ、最も重要なページにエージェントを誘導できます。
大きな注意点が 1 つあります。ビジネスモデルがコンテンツ自体 (ニュースパブリッシャー、専門的なデータプロバイダー、クリエイティブライターなど) である場合、LLM のトレーニングのために無料で提供することは理にかなっていない可能性があります。代わりに、無料で公開するコンテンツ (要約や概要など) とゲート付きにするコンテンツ (記事全体など) を戦略的に選択できます。また、マシン決済を使用してエージェントを収益化することもできます。これにより、データを有料で提供できるようになり、AI エージェントはコンテンツスクレイパーではなく料金を支払う顧客になります。
コンテンツがサーバー側でレンダリングされていることの確認
多くのエージェントは、コンテンツを読み込む JavaScript を実行できないため、クライアント側でレンダリングされたコンテンツの処理に苦労しています。商品ページ、価格、または在庫状況の情報がクライアント側でレンダリングされている場合、エージェントは重要な詳細を見逃す可能性があります。
サーバー側のレンダリングは、エージェンティックな準備に向けた推奨アプローチです。サーバー側のレンダリングを使用すると、サーバーはリクエスターに送信する前に完全な HTML を生成します。つまり、エージェントは JavaScript を実行することなく、解析可能な完全なコンテンツを取得できます。サイト全体で完全なサーバー側のレンダリングを実装できない場合は、静的サイトの生成やハイドレーションを検討してください。
/llms.txt ファイルを使用したエージェント向けの商品情報の最適化
Google 向けに sitemap.xml が用意されていますが、エージェントはナビゲーションメニューや広告が乱立する重い HTML ページを効率的に解析するのに苦労することがあります。シグナルの高いテキストファイルを提供することで、ページが見つかりやすくなります。
これを実現するには、/llms.txt ファイルの公開を検討してください。これは、ルートにあるシンプルな Markdown ファイルで、AI のキュレートされたインデックスとして機能します。コア商品のコレクション、返品ポリシー、ドキュメントをプレーンテキストでリストする必要があります。クリーンで構造化されたテキストをモデルに提供することで、エージェントが商品やポリシーを正しく引用する確率を高めることができます。
Stripe ではこのアプローチを採用しています。stripe.com/llms.txt にある /llms.txt ファイルは、提供する機能の明確なディレクトリーをエージェントに提供します。また、エージェントが効率的に参照できるように、すべてのドキュメントを Markdown 形式で利用できるようにしています (例: docs.stripe.com/payments/accept-a-payment.md を参照)。この 2 つのアプローチにより、エージェントは提供する機能とその使用方法の両方を理解しやすくなります。
詳細を表示するには llmstxt.org で公式標準を確認し、llmsdirectory.com でテクノロジーを推進する他のブランドの本番環境での実装のディレクトリーを確認してください。
商品フィードのデプロイ
商品フィードはまだすべてのエージェントで利用できるわけではありませんが、エージェントが商品を検出するための最も重要なエントリーポイントになることが期待されています。エージェントはウェブサイトをクロールして商品情報を収集できますが、ダイレクトデータフィードを使用すると、遅くて予測不可能な場合があるクロールサイクルを待つことなく、エージェントは商品の変更をすぐに受け取ることができます。また、エージェンティックなサーフェスに商品を表示する正確な日付を設定できるため、立ち上げのタイミングを正確に制御できます。さらに、エージェントが最も正確な価格、在庫状況、仕様を確実に取得できるようにすることで、ハルシネーションの排除にも役立ちます。
課題の 1 つは、エージェントごとに異なる形式のデータが求められる可能性があることです。SFTP へのファイルのドロップが必要な場合もあれば、カスタム API 連携が求められる場合もあります。まったく独自のフィード仕様を持つ場合もあるでしょう。複数のエージェントに掲載するために、ブランドが同じ商品カタログを 6 つの異なる方法で再フォーマットしているケースはすでに確認されており、時間とリソースを消費する継続的なメンテナンスの負担が生じています。
カタログをどこにでも配信できる Stripe などのコマースプロバイダーと提携することで準備できます。Stripe の Agentic Commerce Suite を使用すると、カタログを Stripe に直接アップロードするか、既存のシンジケーターに接続できます。商品情報は各 AI エージェントに自動的に配信されます。
2. エージェントによるサイトの使用方法の理解の支援
従来のマシンとは異なり、LLM はセマンティックな理解に基づいて動作します。その結果、人間の自然な言語を反映した方法でエージェントとやり取りすることが特に重要になります。エージェントがビジネスとやり取りするには、明確な技術的指示が必要です。これには、エージェントの検出とやり取りの取扱説明書として機能する一連の特定のファイルをドメインでホストする必要があります。
well-known/ai-plugin.json を使用して、自身が誰であり、API が何を実行できるかをエージェントに伝える
これはエージェント検出のエントリーポイントです。ブランドの自己紹介のようなものであり、自分が誰であり、API が何を実行できるかをエージェントに伝えます。
description_for_model フィールドは特に重要であり、プロンプトエンジニアリングが行われている必要があります。つまり、API をいつ使用するか、何を実行できるかを説明する、明確で実用的な言語を使用します。エージェントは、一般的なマーケティング言語ではなく、特定の機能と具体的なユースケースで最も優れたパフォーマンスを発揮します。
たとえば、単に「靴を販売しています」と言うのではありません。代わりに、「このウェブサイトを使用して、運動靴の検索、リアルタイムのサイズ在庫状況の確認、配送見積もりの取得を行います」のような表現を検討してください。これにより、顧客の買い物をどのようにサポートするかをエージェントにうまく伝えることができます。
manifest.json でブランドを定義する
エージェントがチャットウィンドウに製品を表示する場合、ロゴ、名前、ビジュアルスタイルなど、ブランドアイデンティティを使用してレンダリングする必要があります。
エージェントは、manifest.json ファイルからこの情報を取得して、製品カードやその他の UI 要素を作成します。このファイルを使用して、公式の short_name と高解像度の icons を定義します。これにより、エージェントはすべてのやり取りにおいて一貫してブランドをレンダリングします。
実装の詳細とコピーアンドペーストの例については、業界標準のドキュメントである MDN Web Docs: Web app manifest をご覧ください。
openapi.yaml を使用してタスクの実行方法をエージェントに指示する
エージェントには、どのエンドポイントを呼び出すか、どのパラメーターを含めるか、リクエストをどのように構成するかなど、API とやり取りする方法に関する正確な指示が必要です。製品の検索、在庫の確認、注文の処理などのタスクを正確に実行する方法を理解するために、openapi.yaml ファイルに依存しています。
description_for_model フィールドと同様に、概要と説明のフィールドをプロンプトのように扱います。summary: “Get Users” ではなく、summary: “Retrieve a list of active users filtered by subscription tier” を使用します。機能、必須パラメーター、およびユースケースについて具体的に記述してください。
技術仕様については、OpenAPI Specification (OAS) 3.1.0 をご覧ください。
3. 人間以外のトラフィックを処理するようにサイトを設定する
エージェントは、人間の買い物客とは根本的に異なる動作をします。読み取り速度が速く、より多くの製品を同時にクエリし、厳格な計算予算とタイムアウトの制約の下で動作します。インフラストラクチャーが人間のトラフィックパターンに対してのみ最適化されている場合、エージェントはカタログへのアクセスに苦労したり、応答が遅かったり、ブロックされたり、処理にコストのかかるページに遭遇したときにサイトを離脱したりする可能性があります。
サイトがエージェンティックトラフィックに確実に応答できるようにするためのいくつかの方法を以下に示します。
エッジコンピューティングロジックを使用してエージェントのトークン効率を向上させる
エージェントは、ウェブサイトを読み取るために (計算トークンで) 「支払い」を行います。製品説明が 2,000 語の場合、エージェントが処理するにはコストがかかりすぎる可能性があります。その結果、エージェントはサイトの優先順位を下げたり、サイトを完全にスキップして、より無駄がなく効率的なソースを優先したりする可能性があります。
これを解決するには、エッジコンピューティングロジックを実行できる最新の CDN の使用を検討してください。着信 User-Agent ヘッダーを検査するようにエッジ関数を設定します。エージェント (GPTBot など) が検出された場合、リクエストをインターセプトし、重いビジュアルサイトの代わりに、軽量なデータのみのテンプレート (Markdown または JSON) を提供します。これにより、トークンのコストを約 90% 削減できます。
「エージェンティックバースト」を防ぐためにレート制限を設定する
人間の買い物客は 1 つずつ製品を閲覧しますが、顧客の代わりに買い物をするエージェントは、2 秒間に 50 個の製品をクエリし、カタログ全体の在庫状況の確認、価格の比較、仕様の読み取りをほぼ瞬時に行う可能性があります。標準のファイアウォールは、これを DDoS 攻撃としてフラグ付けし、IP を禁止する場合があります。
正当なエージェント (GPTBot など) に専用のレート制限ルールを適用するように Web Application Firewall (WAF) を設定します。ハードな「ブロック」ではなく、アクションを Challenge に設定するか、Retry-After ヘッダー付きで 429 Too Many Requests ステータスコードを返します。これにより、「ここでは許可されていますが、5 秒お待ちください」とエージェントに明示的に伝えることができます。
タイムアウトを防ぐために「読み取りが多い」 API エンドポイントをキャッシュする
エージェントは厳格なタイムアウト予算で動作します。API が在庫確認に応答するのに 2 秒かかる場合、エージェントはタイムアウトするか、障害をハルシネーションする可能性があります。
これを防ぐには、stale-while-revalidate ディレクティブを使用して、CDN エッジで「読み取りが多い」 API エンドポイント (「価格」や「在庫」など) を積極的にキャッシュします。これにより、CDN はバックグラウンドで更新を取得しながら、キャッシュされたデータを即座に提供できます。
非同期キャッシュ更新の公式仕様である RFC 5861: HTTP Cache-Control Extensions for Stale Content をお読みください。
4. エージェンティックコマースに向けた組織の連携
エージェンティックコマースへの準備には、インフラストラクチャー以外の変更も必要です。これには、リーダーシップチームがデータを中心にどのように連携するかや、どのような新しい役割が創出されるかが含まれます。最も迅速に行動している企業は、リーダーシップの優先事項、チーム構造、および部門横断的なコラボレーションにおいて、意図的な組織変更を行っています。
部門の移行を探る
エージェンティックコマースの準備を進めている企業のマーケティングチームや IT チームにおいて、移行が見られます。マーケティングチームは、説得に焦点を当てたコピーから、精度を重視したコンテンツへと移行しています。これらのチームは、感情的なストーリーテリングよりも、構造化されたデータと明確な製品仕様を優先しています。
IT およびセキュリティチームは、エージェントのスループットの管理に重点を置いています。準備が最も整っている組織は、セキュリティチームをトレーニングして、悪意のあるスクレイパーと正当なエージェントを区別できるようにし、有効なマシントラフィックがブロックされるのではなく、優先されるようにしています。
データの使用方法について経営陣を調整する
エージェンティックコマースへの準備を無事に完了した企業には、CIO、CTO、および CDO (最高デジタル責任者または最高データ責任者) の間で、データの使用方法の根本的な変化に関する連携という共通のパターンが見られます。これらの組織は、データを単なる分析ツールとして見ることから脱却し、トランザクションのインフラストラクチャーとして扱い始めています。
- これらの組織の CIO は、社内のコンプライアンスから外部の API の可用性へと焦点を拡大しています。バックオフィスの ERP システム (かつては社内専用と考えられていた) に、リアルタイムの購入決定を行うフロントラインのエージェントがアクセスできるようにする必要があることを認識しています。
- CTO は、戦略的優先事項としてコンポーザブルアーキテクチャーを推進しています。最も準備が整っている企業は、特に高速なエージェントトラフィックをサポートするためにマイクロサービスに移行しています。
- CDO は、収益機能としてのデータハイジーンのオーナーシップを担っています。これらのリーダーは、エージェンティックコマースにおいて、不適切なデータが売上の損失につながる可能性があることを理解しています。エージェントのハルシネーションを防ぎ、正確な製品情報を保証する「グラウンディングトゥルース」の責任を負います。
エージェンティック AI プロダクトマネージャーの雇用を検討する
ウェブやモバイルのプロダクトマネージャーに加えて、トップ企業は新しい役割を定義しています。それは、さまざまなチャネルで推論、計画、行動ができる自律型システムの開発を主導するエージェンティック AI プロダクトマネージャーです。
これらの人材は通常、API エンジニアリングとマーチャンダイジングを融合したバックグラウンドを持ち、技術的な実装と顧客体験の両方を理解しています。従来の PM とは異なり、ビジュアルインターフェイスを所有していません。代わりに、エージェンティック体験を所有し、エージェントがブランドをどのように認識しているかをテストし、llms.txt の「コピー」を最適化し、マシン主導のトランザクションのコンバージョン率を監視します。
5. AI ガバナンスの確立
エージェンティックな取引により、新たな運用上の考慮事項が生じ、新しいポリシーが必要になる場合があります。これには、不正利用やエージェントのアクセスを管理するための技術的な制御、エッジケースの取引を処理するための財務ポリシー、ファーストパーティエージェントが顧客とやり取りする方法に関するガイドラインの確立などが含まれます。
新しい不正利用とリスクのパターンの管理
エージェンティックコマースにより、不正利用の検出方法が再構築されています。人間のトラフィックに合わせて調整された不正利用のシグナルは時代遅れになりつつあります。AI エージェントには人間のようなばらつきがないため、不正利用として誤ってフラグが立てられる可能性があります。また、悪意のあるアクターがエージェントを操作してリスクの高い注文を行ったり、通常のガードレールを回避したりできるため、新しい不正利用のパターンが発生する可能性もあります。適切なシステムが導入されていない場合、エージェンティックな決済を受け付けるビジネスは不正利用との戦いにより多くのリソースを費やすことになり、結果として売上の損失、チャージバックの増加、顧客の信頼の低下につながります。
多くのビジネスは、AI コマース向けの新しい決済プリミティブである Stripe の Shared Payment Tokens (SPT) を使用してこの問題を解決しています。SPT を使用すると、エージェントは資格情報を公開することなく、買い手の許可と希望する決済手段を使用して決済を開始できます。Stripe で使用すると、SPT は Stripe Radar とシームレスに連携し、取引や決済手段の詳細を使用して基盤となるリスクシグナルを中継できます。これには、不審請求の申し立て、カードテスティング、盗難カード、カード発行会社による拒否などの可能性が含まれます。
エージェントトラフィックの技術的な制御の実装
エージェントの動作は、エージェントのロジックのバグ、または特定のエージェントがカタログや API を解釈する方法が原因で、予測できない場合があります。ビジネスはインフラストラクチャに詳細な制御を組み込み、全体の運用を中断することなくこれらの状況に対応できるようにしています。人間のトラフィックに影響を与えることなく、特定の Shared Payment Tokens を無効にしたり、特定の User-Agent 文字列のアクセスを調整したりする機能を実装しています。これにより、エージェントの動作を管理する際の精度と柔軟性が向上します。
エッジケースの財務ポリシーの設定
財務および法務チームは、異常な取引が発生する前に処理するためのポリシーを確立しています。たとえば、エージェントが、通常とは異なる割引コードや配送先など、予期しないパラメーターで取引を処理したとします。事前定義されたしきい値 (50 ドル未満の差異の自動承認やそれを超える場合の手動確認など) を設定することで、プレッシャーの中でケースバイケースの決定を下すのではなく、一貫した対応が可能になります。
エージェントのインタラクションにおけるブランドの一貫性の確保
ファーストパーティエージェントがサイトに組み込まれている Organizations は、予期しないユーザー入力に対するシステムの応答をテストしています。これには、システムプロンプトの定義や出力フィルター (Azure AI Content Safety など) の実装が含まれ、ユーザーが通常とは異なるリクエストやブランドから逸脱したリクエストを行った場合でも、エージェントの応答がブランドガイドラインに沿ったものになるようにします。
構築は 1 回のみ、Stripe の Agentic Commerce Suite であらゆる場所で販売する準備を整える
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 にアップロードするか、主要な製品シンジケーターから既存の製品カタログを接続できます。その後、製品情報を各 AI エージェントにシンジケートし、サポートされているすべてのエージェントで自動的に決済の受け付けを開始できるようにします。
顧客体験のコントロールを維持する
Agentic Commerce Suite は、Stripe の Checkout Sessions API を利用しており、配送料や税金など、決済のさまざまな側面をサポートします。Stripe Tax などの Stripe の組み込み製品を使用して Stripe に管理を委託することも、既存のコマーススタックを使用して、システムへの変更を最小限に抑えながら、税コードのアップロード、ほぼリアルタイムの在庫チェックの管理、動的な配送料金の設定を行うこともできます。
顧客がエージェント取引を完了したあと、事業者は既存の社内注文およびフルフィルメントプロセスを利用するだけです。また、マーチャントオブレコードとして、返金や不審請求の申し立ての管理方法など、顧客関係に関するすべての管理権限も保持します。
エージェンティック決済を受け付け、新たな不正利用パターンから保護する
ビジネスの保護を強化するため、Agentic Commerce Suite は、エージェンティックコマースの新しい決済プリミティブである Shared Payment Tokens (SPTs) を処理します。すべてのトークンは、特定の売り手にスコープを設定し、時間と金額で制限し、ライフサイクル全体で監視して、承認されていないエージェントのアクションを防ぎ、不審請求が申請される可能性を減らすことができます。
Stripe で使用する場合、SPT は Radar と連携して潜在的なリスクシグナルを伝達することも可能です。取引や決済手段の詳細を利用することで、購入意欲の高いエージェントと信頼性の低い自動ボットを判別できます。その結果、自社で長期間のデータを蓄積する前から、エンタープライズレベルの不正利用対策をすぐに導入できます。
Stripe からカスタマイズされたサポートを受ける
エージェンティックコマースへの移行は複雑です。スキーマを監査し、コンポーザビリティのために API をリファクタリングし、MCP や ACP などの新しいプロトコルを実装する必要があります。この移行を単独で進める必要はありません。Stripe は、組織のニーズに基づいて実行を支援する明確なパスを提供します。
エンドツーエンドソリューションのためのパートナーエコシステム
Stripe の認定システムインテグレーター (SI) パートナーは、エージェンティックコマースの開始をサポートします。戦略的インサイトと、特定の業界に合わせた高性能な実装を構築するために必要な技術的厳密さを兼ね備えています。
専門的なアドバイザリーサービスのための Stripe プロフェッショナルサービス
提供元からの直接的なアーキテクチャーのガイダンスを求める企業向けに、Stripe のプロフェッショナルサービスチームは、集中的な技術的エンゲージメントを提供します。エンジニアリングチーム (またはパートナー) と協力して、実装がセキュリティ、拡張性、コンポーザビリティのベストプラクティスに従っていることを確認します。