この記事の対象範囲
上記でサーベイした内容をもとに、EC 事業者が Agentic Commerce に フル対応 しようとした場合のアーキテクチャを検討してみました。この記事では Shopify のような EC Platform を使わず自社で EC を開発運用する場合（内製・外注を問わず）を想定しています。また、GUI 操作により購買する AI Agent への対応については人が GUI 操作をする場合と同じとしてアーキテクチャ上の特段の記載はありませんが、関連項目としては Product Schema の整備が該当します。
この記事の中での用語一覧表
用語一覧
| グループ | 用語（日本語） | 用語（英語） | 定義 | 範囲/特徴 | 使用例 |
|---|---|---|---|---|---|
| アクター | 消費者 | Consumer | 商品を探索し、最終的に購入する一般人 | 生成AIアプリを通じて商品を発見・選択 | 消費者が生成AIアプリで商品を探す |
| アクター | EC事業者 | EC Merchant | ECサイトを運営し、商品を販売する事業者 | 商品情報提供、在庫管理、注文処理、配送手続き | EC事業者がProduct Feedを提供する |
| アクター | AI Platform事業者 | AI Platform Provider | 消費者向けに生成AIアプリを提供する事業者 | AI Agentによる商品探索・選択・購入支援（例: OpenAI, Google） | AI Platform事業者がCommerce Protocolを実装する |
| アクター | 決済プロバイダー事業者 | Payment Provider | 決済処理を提供する事業者 | 支払いトランザクション処理（例: Stripe, Google Pay, Apple Pay） | 決済プロバイダー事業者が決済を実行する |
| 購買プロセス | 購買する | Purchase | 消費者視点での一連の行為全体 | 商品探索 → 商品選択 → 注文確定 → 決済 → 購入完了 | 消費者が生成AIアプリを通じて購買する |
| 購買プロセス | 購入する | Buy | 商品を取得する意思決定と注文確定 | 商品選択 → カートへ追加 → 注文内容確定（決済の前段階） | AI Agentが消費者に代わって商品を購入する |
| 購買プロセス | 決済する | Pay / Checkout | 金銭の支払い処理 | 支払い方法選択 → 決済情報入力 → 決済実行 → 決済完了 | Commerce Protocolを通じて決済する |
| 購買プロセス | 注文する | Order | EC事業者に対して商品の提供を依頼する行為 | 注文データ生成 → EC事業者への送信 | AI AgentがEC APIを通じて注文する |
| 商品発見 | 商品を検索する | Search Products | 特定の条件やキーワードに基づいて商品を探す行為 | 手段: Web Search, Product Feed, MCP Server, EC API | 生成AIアプリがProduct Feedから商品を検索する |
| 商品発見 | 商品を発見する | Discover Products | 消費者のニーズに合致する商品を見つけ出すプロセス | 検索より広義で、推薦を含む | AI Agentが複数のECサイトから商品を発見する |
| 商品発見 | 商品を推薦する | Recommend Products | AI Agentが消費者の意図を解釈し、適切な商品を提案する行為 | AI Agentによる能動的な提案 | ChatGPTが3-5個の商品カードで推薦する |
| データ・情報 | Product Schema | Product Schema | Schema.orgで定義された商品情報の構造化マークアップ | 形式: JSON-LD、含む情報: 商品名、価格、在庫、GTIN、ブランド、レビュー | ECサイトにProduct Schemaを実装する |
| データ・情報 | Product Feed | Product Feed | 構造化された商品データファイル | 形式: CSV, JSON, XML、提出先: OpenAI, Google Merchant Center, Klarna APP | Product FeedをAI Platform事業者に提出する |
| データ・情報 | GTIN | Global Trade Item Number | 国際的な商品識別番号（日本ではJANコード） | AI Agentが同一商品を複数サイト間で識別・比較するために必須 | GTINを使って商品を一意に識別する |
| プロトコル・技術 | MCP | Model Context Protocol | AI Agentが外部ツール、データソース、システムと統合する際の標準プロトコル | リアルタイム性、双方向通信、提供機能: 商品検索、カート管理、注文管理 | MCP Server経由でリアルタイムに商品情報を取得する |
| プロトコル・技術 | Commerce Protocol | Commerce Protocol | AI AgentがECサイトで購入を実行するための標準化されたプロトコル | 種類: ACP, UCP、関与者: AI Platform、EC事業者、決済プロバイダー | Commerce Protocolで決済処理を標準化する |
| プロトコル・技術 | ACP | Agentic Commerce Protocol | StripeとOpenAIが開発したCommerce Protocol | ChatGPTのInstant Checkout機能の技術基盤 | ACPを実装してChatGPT経由の購入を可能にする |
| プロトコル・技術 | UCP | Universal Commerce Protocol | GoogleとShopifyが開発したCommerce Protocol | Geminiでのゼロクリック購入を目指す | UCPを実装してGemini経由の購入を可能にする |
| プロトコル・技術 | MCP Apps | MCP Apps | AI Agentとのやり取りにインタラクティブなビジュアルUIを組み込める拡張仕様 | テキストのみの応答を超えた、リッチなUI体験を提供 | MCP Appsでブランド認知を維持する |
| システム構成要素 | 生成AIアプリ | Generative AI App | 消費者が直接利用するフロントエンドアプリケーション | AI Agent搭載、会話を通じて商品発見から購入まで支援（例: ChatGPT, Gemini, Amazon Rufus） | 生成AIアプリで商品を検索する |
| システム構成要素 | AI Agent | AI Agent | 自律的にタスクを実行するAIシステム | ツールの使用、タスク立案・実行、複数システムの統合が可能 | AI Agentが商品を推薦する |
| システム構成要素 | EC API | EC API | EC事業者が提供するプログラマティックなインターフェース | 商品情報取得、在庫確認、注文処理、決済処理を外部システムから実行可能 | EC APIを通じて在庫を確認する |
| システム構成要素 | MCP Server | MCP Server | MCPプロトコルに準拠したサーバー | AI Agentからのリクエストを受け付け、ECシステムの機能を提供 | MCP Serverを構築してリアルタイム連携を実現する |
| システム構成要素 | Commerce Protocol Server | Commerce Protocol Server | Commerce Protocolに準拠したサーバー | AI Agentからの購入リクエストを受け付け、注文処理と決済を実行 | Commerce Protocol Serverで決済を処理する |
| システム構成要素 | Product Feed Provider | Product Feed Provider | Product Feedを生成・提供するシステム | ECの商品データベースから定期的にFeedを生成し、AI Platform事業者に提供 | Product Feed Providerで自動的にFeedを更新する |
| システム構成要素 | Product Schema Provider | Product Schema Provider | ECサイトのHTMLにProduct Schemaを埋め込むシステム | 商品ページの機械可読性を向上させる | Product Schema Providerで自動的にSchemaを挿入する |
| 最適化 | AEO | Answering Engine Optimization | 生成AIアプリがユーザーに回答する際に、自社のブランド・商品が引用・推薦されるように最適化する戦略的手法 | 目的: AI Agentの推薦候補（3-5個）に選ばれること、手段: Product Schema実装、Product Feed整備、情報密度向上、権威性構築 | AEO戦略でAI Agentに選ばれる確率を高める |
| 最適化 | SEO | Search Engine Optimization | 従来の検索エンジン（Google等）で上位表示されるための最適化手法 | AEOとは最適化対象が異なる | SEOとAEOを並行して実施する |
| 補足用語 | Instant Checkout | Instant Checkout | ChatGPT内で商品発見から決済まで完結する機能 | ACPを技術基盤とする | Instant Checkoutで購入体験を簡素化する |
| 補足用語 | ゼロクリック購入 | Zero-Click Purchase | Webサイトへの遷移なしに、AI Agent内で購入が完了する体験 | UCPが目指す世界 | ゼロクリック購入で摩擦を削減する |
| 補足用語 | GUI操作 | Browser Automation | AI Agentがブラウザを自動操作してECサイトで購入する方式 | Commerce Protocol整備前の過渡的手段 | GUI操作で既存ECサイトから購入する |
| 補足用語 | 在庫引当 | Inventory Allocation | 注文確定時に在庫を確保する処理 | 購入プロセスの一部 | 注文時に在庫引当を実行する |
| 補足用語 | 配送手続き | Shipping Arrangement | 注文確定後の配送準備処理 | 購入プロセスの一部 | 購入後に配送手続きを開始する |
| 補足用語 | Payment Token | Payment Token | 実際のクレジットカード番号や銀行口座情報を直接やり取りせず、トークン（代替文字列）で代用する | 決済プロバイダーからAI Agentに返却される | Payment Tokenで決済完了を確認する |
この記事の中での重要用語の使い分けマトリクス
用語の使い分け
| 用語 | 範囲 | 主体 | タイミング | 使用場面 |
|---|---|---|---|---|
| 購買する | 探索〜決済完了 | 消費者 | 全体プロセス | 消費者視点での全体プロセス、ビジネス分析、マーケティング文脈 |
| 購入する | 選択〜注文確定 | 消費者/AI Agent | 決済前 | 商品選択と注文確定の行為、AI Agentの動作説明 |
| 決済する | 支払い処理 | 決済プロバイダー | 注文確定後 | 金銭の支払い処理、決済プロバイダーとの連携説明 |
| 注文する | 注文データ送信 | AI Agent/消費者 | 購入意思決定後 | EC事業者への注文データ送信、システム間連携の説明 |
システムアーキテクチャ (機能要件での論理設計概要)
各処理の必要性と役割
なぜ必要か:
消費者の購買行動の起点が「EC サイト訪問」から「AI 対話」へと根本的にシフトしています。2026 年現在、Salesforceの調査では、米国消費者の 39%、Z 世代の半数以上がすでに AI を商品発見に利用しており、この変化は単なるトレンドではなく構造的な転換です。従来の「検索→複数結果を比較→選択」という段階的なプロセスが、「質問→AI が回答→推薦された商品を確認」という会話的インタラクションに圧縮されつつあります。
処理内容:
消費者は自然言語で商品ニーズを表現します。例えば「150 ドル以下の防水ハイキングブーツを探して」といった具体的な要求を生成 AI アプリに伝えます。生成 AI アプリはこの意図を解釈し、商品探索から決済までの全プロセスを支援します。従来のキーワード検索とは異なり、会話的インタラクションを通じて購買プロセス全体が実行されるため、消費者は複雑な検索条件を考える必要がなくなります。
関連用語: 購買する、生成 AI アプリ、AI Agent
なぜ必要か:
AI Agent はリアルタイムで全 EC サイトをスクレイピングしているわけではありません。事前に提出された構造化データ、つまり Product Feed が、AI Agent の商品検索における主要なデータソースとなっています。OpenAI の Product Feed Specification や Google Merchant Center が実際にこの仕組みを採用しており、ChatGPT や Gemini の商品検索の基盤となっています。AI Platform 事業者が独自に収集し、独自に利用する Feed です。以下の記事のクローズドな Feed に該当します。
処理内容:
AI Agent は消費者の意図に基づいて Product Feed のインデックスを検索します。構造化データには商品名、価格、在庫、GTIN、ブランド、画像 URL などが含まれており、条件に合致する商品を効率的に抽出できます。検索結果を元に AI Agent が 3-5 個の商品カードを生成して推薦します。Feed 形式は CSV、JSON、XML などで、更新頻度は定期的です。リアルタイム更新ではない点が MCP との大きな違いとなります。データソースは EC 事業者が事前に AI Platform 事業者に提出したものです。
関連用語: 商品を検索する、Product Feed、商品を発見する
なぜ必要か:
AI Platform 事業者が自社で保持する Feed のみを検索対象にすると、商品の選択肢が限定されてしまいます。複数マーチャント横断検索を実現し、消費者に最適な商品を提案するためには、Open Standard な Product Feed 提供サービスが必要です。Klarna APP では、1 億以上の商品のアクセスが可能になります。
処理内容:
AI Agent は Open Standard な Product Feed 提供サービス（例: Klarna APP）にクエリを送信します。サービスは複数 EC 事業者の Feed を横断検索し、同一商品（GTIN 基準、日本では JAN が該当）の価格・在庫を複数マーチャント間で比較します。統一タクソノミーにより、異なる EC 事業者の商品分類を統一的に扱うことができます。永続的な商品 ID（GTIN）による同一商品の識別と、既存 Feed 形式（Google Merchant Center、Shopify、Amazon、Facebook Catalog）のサポートが技術的特徴です。
Open なので REST API にアクセスして実際に商品情報を取得することができます。詳細はこちらです。
関連用語: Product Feed、GTIN、商品を発見する
なぜ必要か:
Product Feed に登録されていない商品や、最新情報が反映されていない場合の補完手段として、Web Search 経由での商品検索が必要です。AI Agent が Web 全体から商品情報を収集する従来型の検索手法であり、Product Schema が実装されていれば、AI Agent が商品情報を正確に理解できます。
処理内容:
AI Agent は Web Search 機能を使用して EC サイトにアクセスします。EC サイトの HTML から商品名、価格、在庫、GTIN、レビュー等のデータを取得します。 Product Schema（JSON-LD 形式）を設定しておくと生成 AI の理解を助けることができます。こうして取得した情報を元に商品を推薦します。OpenAI の OAI-SearchBot クローラーが Product Schema を読み取りますが、robots.txt で許可が必要です。
Product Schema がない場合、HTML から推測するため精度が低下します。調査によると 89%の EC サイトが SKU Schema を誤実装しているという課題があり、リアルタイム性はあるものの、Product Schema の実装が推奨となります。
関連用語: 商品を検索する、Product Schema、Web Search
なぜ必要か:
AI Agent が EC サイトから商品情報を正確に理解するためには、Product Schema が不可欠です。HTML の視覚的レイアウトからの推測では精度が低く、エラーが発生しやすくなる可能性があります。Product Schema の有無により、AI Agent による引用確率が 200% 以上増加され得ることが報告されています。
実際に実験してみた内容はこちら:
処理内容:
Product Schema Provider は EC の商品データベースから商品情報を取得し、Schema.org の Product Type に準拠した JSON-LD 形式のマークアップを生成します。生成されたマークアップは EC サイトの HTML 内の<script type="application/ld+json">タグに挿入されます。ページ表示には影響を与えず、機械可読なデータのみを提供します。必須フィールドとして、name（商品名）、price（価格）、priceCurrency（通貨）、availability（在庫状況）、GTIN（商品識別番号）、brand（ブランド）、image（商品画像 URL）が含まれます。
関連用語: Product Schema、GTIN、AEO
なぜ必要か:
AI Platform 事業者（OpenAI、Google）が商品情報をインデックス化するためには、Product Feed が必要です。Product Schema は個別ページの情報を提供しますが、Feed は全商品の一括データ提供を実現します。ChatGPT や Gemini の商品検索における「Single source of truth」となります。
処理内容:
Product Feed Provider は EC の商品データベースから全商品情報を定期的に抽出します。OpenAI Product Feed Specification または Google Merchant Center 形式に変換し、CSV、JSON、XML 形式で Feed ファイルを生成します。生成された Feed は AI Platform 事業者に提出されるか、自動取得可能な場所に配置されます。Feed 更新頻度は定期更新が基本で、例えば日次や週次で更新されます。リアルタイム更新ではない点が MCP との違いです。提出先としては、OpenAI Product Feed、Google Merchant Center、Klarna APP、その他 Open Standard Feed Service が挙げられます。
関連用語: Product Feed、Product Feed Provider
なぜ必要か:
Product Feed や Web Search は定期更新または静的データですが、MCP はリアルタイムデータアクセスを実現します。AI Agent 内でブランド認知を維持するため、テキストのみではなくビジュアル UI を提供する必要があります。在庫状況、価格、配送情報、レビューなどの動的情報をライブで提供できます。
処理内容:
MCP Apps Server は AI Agent から MCP プロトコル経由でリクエストを受信します。EC API を通じてリアルタイムに商品情報、在庫、価格を取得し、MCP Apps プロトコルにより、インタラクティブな UI（商品画像、カラースウォッチ、サイズセレクター等）を返します。返された UI は AI Agent 内に埋め込み可能な形式でレスポンスとして返却されます。ただし、EC 事業者側の API 化が必要でバックエンド改修が必要であり、AI Platform 側の統合がまだ進んでいないという課題があります。
MCP Apps を試したみた記事はこちらです。
関連用語: MCP、MCP Apps、MCP Server、リアルタイム
なぜ必要か:
AI Agent 内で購入を完結させるためには、EC サイトへの遷移なしに決済を実行する仕組みが必要です。従来の GUI 操作（ブラウザ自動化）では精度に課題があり、誤注文が発生していました。標準化されたプロトコルにより、予測可能かつ制御可能な購入フローを実現できます。
処理内容:
消費者が AI Agent 内で購入を決定すると、AI Agent は Commerce Protocol（ACP/UCP）経由で決済リクエストを送信します。Commerce Protocol Server が注文データを受信し、EC API を通じて商品情報取得、在庫引当、配送手続きを実行します。その後、決済プロバイダーに決済処理を委譲し、Payment Token を受け取って AI Agent に返却します。対応プロトコルとしては、ACP（Agentic Commerce Protocol）が Stripe + OpenAI により開発され、ChatGPT の Instant Checkout の基盤となっています。UCP（Universal Commerce Protocol）は Google + Shopify により開発され、Gemini のゼロクリック購入を目指しています。標準化されたインターフェースにより個別統合が不要となり、「意図→発見→確認→決済→領収書」を単一の AI コンテキスト内で完結できます。
関連用語: 決済する、Commerce Protocol、ACP、UCP、Instant Checkout、ゼロクリック購入
やってみた記事はこちら！
なぜ必要か:
決済時に最新の商品情報（価格、在庫、配送オプション）を確認する必要があります。Product Feed や Schema は定期更新ですが、決済時はリアルタイム情報が必須です。在庫切れ商品の誤注文を防ぐためにも、この処理は不可欠です。
処理内容:
Commerce Protocol Server は商品 ID（SKU/GTIN）を指定して EC API にリクエストを送信します。EC API は商品データベースから最新情報を取得し、価格、在庫状況、配送オプション、商品詳細をレスポンスとして返します。
関連用語: EC API、商品情報
なぜ必要か:
注文確定前に在庫を確保し、他の注文との競合を防ぐ必要があります。割引コード、クーポン、ポイント利用などの価格調整を適用し、配送先住所に基づいた配送オプションと料金を計算する必要があります。
処理内容:
まず割引処理として、クーポンコード、プロモーション、ポイント利用を適用します。次に在庫引当として、注文数量分の在庫を確保し、他の注文でロックされないようにします。最後に配送手続きとして、配送先住所、配送方法、配送料金を確定します。
関連用語: 購入する、在庫引当、配送手続き
なぜ必要か:
Commerce Protocol Server は決済処理を直接実行せず、EC 事業者のビジネスロジックを尊重します。EC 事業者が決済プロバイダーとの契約や手数料体系を管理し、注文データの記録、顧客情報の管理を EC 側で一元化する必要があります。
処理内容:
Commerce Protocol Server は EC API に決済リクエストを送信します。EC API は注文データを記録し、注文 ID 生成と顧客情報保存を行います。その後、EC API が決済プロバイダーに決済処理を委譲します。
関連用語: 決済する、EC API
なぜ必要か:
実際の金銭の支払い処理を専門事業者に委譲する必要があります。PCI DSS 準拠などのセキュリティ要件を決済プロバイダーが担保し、複数の決済手段を統一的に扱うことができます。
処理内容:
EC API は決済プロバイダーの API に決済リクエストを送信します。決済金額、通貨、支払い方法、顧客情報を送信し、決済プロバイダーが決済トランザクションを実行します。
関連用語: 決済する、Payment Provider
最後に
Agentic Commerce に EC 事業者が対応する場合にどのようなシステム要素や機能が必要になりそうか、概要を整理してみました。OpenStandard Product Feed の Klarna APP や MCP Apps の記事をリンクしているように、今後、それぞれの記事に試してみた記事をリンクしていこうと思います。そして、最終的には今回のアーキテクチャ全てを実装したいと思います。
番外編 (非機能系)
WBA (Web Bot Auth)
WBA は、AI Bot が HTTP リクエストに暗号署名を付与し、WAF がその署名を検証する仕組みです。
WBAの標準化状況
WBA は IETF（Internet Engineering Task Force） のドラフト仕様 に基づいています：
- 基盤技術: RFC 9421 - HTTP Message Signatures（2024年2月標準化済み ✅）
- WBA仕様: draft-meunier-web-bot-auth-architecture（Internet-Draft、2025年10月期限）
従来の課題
- User-Agent だけでは偽装が簡単
- IP アドレスベースの許可は管理が大変
- 正規の AI Bot と悪意のある Bot を区別できない
WBA の利点
- 暗号署名による確実な検証
- 非対称鍵暗号（RSA、EC、Ed25519）を使用
- WAF Bot Control で自動的にラベル付与
やってみた！
この Publication に投稿している記事は、アマゾン ウェブ サービス ジャパン合同会社または Amazon Web Services, Inc. 所属社員による個人の見解であり、所属する組織の公式見解ではありません。参加したい従業員の方は、Sugiyama Suguru までお知らせください。
Discussion