エージェンティックコマース対応への3ステップ　データ構造化、API、認証

作成者: ryota.kondo｜2026年07月22日

TL;DR

この記事の3行まとめ

次世代の購買体験： 人間に代わりAIが自律的に決済まで完結させる「エージェンティックコマース」の全貌を解説。
3つの必須実装： Google推奨の標準規格「UCP」に準拠した、データ構造化・API・認証の具体的なステップを網羅。
日本の課題： 2026年現在の国内普及の鍵を握る「特商法」と「ポイント経済圏」への対応策を考察。

1.はじめに

エージェンティックコマースとは

「エージェンティックコマース」とは、消費者に代わってAIエージェントが自律的にショッピングの全工程を代行する、次世代のデジタルコマースの形態です。

ここで指すエージェンティックコマースは、ECサイト内に搭載されたAIチャットなどではなく、GeminiやChatGPTなどの外部AIが、ECサイトにユーザーがアクセスしなくても、検索から決済までをすべて代行する仕組みを指します。

海外や日本の対応状況

海外では大手スーパーマーケットのWalmartやECプラットフォームのShopifyなどがエージェンティックコマースに対応しており、従来の受動的な検索（キーワード）から能動的な解決（エージェント型AI）へと移行することで、コンバージョン率（購入まで至った割合）の向上や、かご落ち防止の効果があると報告されています。^[1]

日本国内では2026年4月現在、本格的な実運用には至っていません。しかし、GoogleとShopifyが共同開発した「Universal Commerce Protocol（UCP）」^[2]や、OpenAIとStripeによる「Agentic Commerce Protocol（ACP）」^[3]といった標準規格が2026年から普及し始めており、日本にもこの波が押し寄せようとしています。

そんなエージェンティックコマースの波に乗り遅れないために、今回はGoogleが提供する「Universal Commerce Protocol（UCP）」にフォーカスし、GeminiやGoogle検索のAIモードから自社ECサイトの商品を購入できるようにするための3つのステップを解説します。

2.【Step 1】発見され、理解されるための下地作り（データ構造化）

商品データをGoogleと共有する

AIエージェントが商品を正しく認識・比較できるようにするためには、まずGoogleがECサイトの商品を「読める状態」にする必要があります。

人間がECサイトを訪れると、画像や価格、レビューなどを目で見て判断します。しかしAIエージェントはページを見るのではなく、構造化されたデータを読み取って商品を理解します。この構造化データの世界標準が「Schema.org（JSON-LD）」^[4]と呼ばれる形式です。

Schema.orgは商品名・価格・在庫状況・レビューなどの情報を、AIが正確に解釈できる形式で記述するための仕様です。この形式でデータを整備し、Google Merchant Centerに登録することで、GoogleはECサイトの商品を理解できるようになります。

この仕組みはエージェンティックコマース特有のものではなく、GoogleショッピングやGoogle検索の表示など、従来のSEO対策としても広く活用されています。すでにSchema.orgのマークアップを実装済みのECサイトであれば、その構造化データをそのまま活用することができます。（参考：商品データをGoogleと共有する（Google公式ガイド））

UCPプロファイル

Schema.orgで商品データを整備したら、次にAIエージェントへの案内板を設置します。これがUCPプロファイル^[5]です。

UCPプロファイルとは、ECサイトのサーバー上の決まった場所に置く設定ファイルです。Googleのエージェントは最初にこのファイルを参照し、「このECサイトはエージェンティックコマースに対応しているか」「何ができるのか」「どこにリクエストを送ればよいか」を確認します。

UCPプロファイルは認証不要の誰でもアクセスできる公開ファイルとして配置する必要があります。ここには「対応しているサービスの種類（チェックアウト・配送・割引など）」と「それぞれのAPIの場所」を記載します。これにより、GoogleのAIはどんな操作ができるかを事前に把握した上で、適切なAPIを呼び出せるようになります。

3.【Step 2】自律的に注文を行うためのインターフェース（API）

APIの準備

UCPプロファイルを宣言したら、次はその宣言を実現するためのAPIを用意します。人間がECサイトを使う場合、画面上のボタンをクリックして購入を進めますが、AIエージェントは代わりにAPIを通じて、カートへの追加・住所入力・決済完了まで一連の処理を実行します。

購入完了までの流れ

GoogleのAIエージェントが実際にユーザーの代わりに購入を完了させるまでの流れは以下のとおりです。

このフローを実現するために、ECサイト側は「チェックアウトセッションの開始」「配送先変更への対応」「決済完了の受け取り」「キャンセル処理」など、購入フローの各ステップに対応したAPIを用意する必要があります。（参考：Google UCP Guide ネイティブチェックアウト）

実装の現実的なコスト

GoogleのUCP実装ガイドには、各APIで必要なデータ項目が詳細に定められています。一から構築するには相応の開発工数がかかりますが、UCPが公式に提供するSDK（開発支援ツール）を活用することで、複雑な仕様の実装を大幅に簡略化できます。

また、構築したAPIがUCPの仕様に正しく準拠しているかを自動チェックできるテストツールもUCP公式から提供されており、品質担保と開発スピードの向上に役立ちます。

4.【Step 3】必要なセキュリティ（認証・認可）

ECサイトのAPIを誰でも呼び出せる状態にすると、なりすましや不正注文のリスクが生じます。また、適切な認証があれば購入者情報や支払い情報をユーザーと紐づけて管理でき、AIが正確に購入を代行するための基盤にもなります。しかし、注文のたびにユーザーがEC側のパスワードを入力して逐一ログインをしていては、AIによる自動購入の意味がありません。

この問題を解決するのが、アイデンティティリンクという仕組みです。

アイデンティティリンクとは

ユーザーがGoogleにECサイトのアカウントを連携する操作を一度行うと、GoogleはECサイトから「AI専用のトークン」を受け取ります。以降はGoogleがそのトークンを使ってAPIを呼び出すため、ユーザーが毎回ログインしなくても、AIが安全に代わりに購入を完結させられます。

この認証・認可にはOAuth 2.0が採用されており、「誰の代わりに」「何の操作を」Googleに許可するかが明確に管理されます。

ECサイト側で必要な準備

ECサイト側がこの仕組みに対応するには、3つの実装が必要です。

OAuth 2.0 認証・認可基盤： AIが「誰の代わりに」「何の操作を」行うかを管理する基盤を実装する
連携窓口の公開： GoogleがECサイトの認証・認可APIを自動で読み取れるよう、決められた場所にメタデータファイルを配置する
権限設定： AIに「注文関連の操作だけ」を許可する専用スコープを実装する

（参考：アイデンティティリンク - OAuth 2.0）

注文後の対応

なお、本記事では詳細には触れませんが、チェックアウトが完了して注文が確定した後も、実装すべき要素があります。

注文Webhookの実装： 注文確定・発送・配達完了・キャンセル・返金といったステータスの変化を、Google所定のエンドポイントにリアルタイムで通知する必要があります。これにより、GoogleのAIはユーザーに対して注文の進捗を正確に伝えられます。
PSP（決済事業者）との連携： 2026年1月23日時点でUCPガイドに公開されている決済ハンドラーはcom.google.pay（Google Pay）のみであり、Google Payが発行した支払いトークンをPSPに渡して、実際の決済処理を完結させる実装も必要です。トークンの扱いはPSPごとに異なるため、利用するPSPのガイドラインに従った実装が求められます。

これらはいずれもUCPの公式ドキュメントに仕様が定義されており、Step 2・Step 3と合わせて対応が必要な領域です。（参考：注文ライフサイクル（購入後）、Google Pay決済ハンドラー仕様）

Googleへの申請・承認

上記の開発が完了したら、Googleへの申請が必要です。Googleヘルプセンター^[6]からエージェンティックコマース統合の承認申請を行い、Googleによる審査を経て初めて本番環境での利用が可能になります。

※ ただし2026年4月時点で、UCPを利用した購入機能は、米国における資格のある製品および参加する加盟店のみ対象と明記されており、日本国内での導入時期に関しては未定です。^[7]

5.エージェンティックコマース導入への課題

日本固有の課題

海外プラットフォームではエージェンティックコマースへの対応が進む一方、日本国内で本格展開するには、2つの構造的な障壁があります。

1. 法規制の壁

特定商取引法（特商法）は、通信販売において「最終確認画面での表示義務」や「意図しない注文を防ぐ措置」を事業者に課しています^[8]。AIエージェントが人間に代わって注文を完結させるフローでは、「誰が最終意思確認をしたか」という点が法的にグレーになりえます。

また、消費者契約法における取消権（誤認・困惑による契約の取消し）は、AI代理購入において責任の所在を曖昧にするリスクがあります。^[9]

2. ポイント経済圏の壁

日本のEC消費者は複数のポイント経済圏に分散しており、楽天ポイント（利用率 32.3%）、dポイント（14.6%）、PayPayポイント（13.7%）などが独立したエコシステムを形成しています（2025年12月時点）。^[10]

UCPが前提とする決済フローはGoogle Pay・クレジットカード中心ですが、日本では楽天ペイ・d払い・PayPayといった独自の決済手段も多く使われており、AIエージェントが「ポイントを最大活用しながら最安値で購入する」という行動を取るには、各経済圏のAPIと個別に連携する必要があり、標準プロトコルだけでは対応できません。

各ポイント経済圏がUCP対応の独自APIを公開するか、またはAIエージェント側が各経済圏を横断して最適化できる仕組みが整うまで、日本のエージェンティックコマースはポイント活用の面で海外より機能が限定される状況が続く見込みです。

6.まとめ

エージェンティックコマースが普及するにあたって、AIエージェントはGUIを使わないという一つの根本的な変化があります。

従来のECサイトは、人間がブラウザで操作することを前提に設計されてきました。商品ページを見て、カートに入れて、フォームに住所を打ち込む。これらはすべて「人間の目と手」を前提としたインターフェースです。しかしGeminiやChatGPTといったAIエージェントは、ページをレンダリングしてボタンをクリックする代わりに、APIを直接呼び出して、商品検索・カート操作・決済を完結させます。

そのため、APIがないECサイトは、AIエージェントから発見・利用されにくくなります。

この変化は「ヘッドレスコマース」の重要性を問い直しています。ヘッドレスコマースとは、フロントエンドとバックエンドを分離し、バックエンドをAPIとして公開するアーキテクチャであり、従来は「フロントの自由度を高める」ための技術選択でしたが、エージェンティックコマース時代においてはAIという新たなフロントエンドに対応するための基盤として、その意味が変わりつつあります。

Shopify・commercetoolsなどAPIファーストで設計されたプラットフォームほど、エージェンティックコマースへの対応が早く、実装コストも低い傾向があります。一方、UIに依存した従来型の構成のままでは、UCPやACPといった標準プロトコルへの対応が困難になります。

UCPやACPへの対応は2027年には「当たり前の要件」になるとも言われており、今から動き始めることが、顧客流入経路を確保するうえで不可欠です。まずは自社のECがAPIとして機能するか棚卸しすることが、エージェンティックコマース対応への第一歩です。