こんにちは！
「エージェンティックコマース（Agentic Commerce）」という言葉を耳にすることはありませんか？
普段Webエンジニアをしている筆者の視点から、調査・整理しましたので是非ご覧ください！

なお注意点として、エージェンティックコマースは以下2つの標準化の流れがあります。

  • ACP (Agentic Commerce Protocol)：OpenAIとStripeが共同開発を発表したプロトコル
  • UCP (Universal Commerce Protocol) & AP2 (Agent Payments Protocol)：Googleが提唱するオープンプロトコル群

本記事では、Googleの視点・技術を中心に解説しますことご了承ください。

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

エージェンティックコマースが思い描く世界観

エージェンティックコマースとは、AIエージェントを通じた自律的な購買体験を指します。
ユースケースを3つ挙げてみましょう。

【シチュエーションに合った提案を含めた購買】

今週末、小学生の子供2人を連れて初めてのデイキャンプに行くんだけど、手持ちのテント以外で足りない必須アイテム（防寒具・調理器具・虫除けなど）をピックアップして、初心者向けで評価が高くコスパの良いセットを金曜夜までに届くように一括注文しておいて。

【様々な制約が課せられた、複数サービスにまたがる複雑な購買】

来週火曜日の福岡出張で、13時の〇〇ビルでの商談に間に合う新幹線と、夜の懇親会（天神周辺）後に泊まれる大浴場付きの禁煙ホテルを手配して。予算は交通＋宿泊で4万円以内、会社の経費規程（領収書宛名：⚫︎⚫︎株式会社）に沿って決済して。

【方針に基づき、バックグラウンドで継続的に最適化される購買】

我が家の日用品（洗剤・オムツ・ミネラルウォーター）を切らさないように常時在庫を管理しておいて。月間予算2万円以内で、各モールのポイント還元率や定期便割引が最も有利になるタイミングを見計らって自律的に発注・補充して。もし指定ブランドが終売になった時だけ確認して。

重要なのは、エージェンティックコマースは「従来の検索やレコメンドの延長線」ではないということです。
人間は「購入条件や決済の承認」という意思決定のみを行い、それに至る探索・比較・購入手続き・タイミング監視といった購買活動のすべてを、AIエージェントに代行させることを目指す、非常に野心的なアプローチです。

エージェンティックコマースの成熟度モデル

自動運転のSAEレベルになぞらえた、米マッキンゼーが提示するエージェンティックコマースの自動化曲線を一部解釈を加えて紹介します。

レベル エージェントの役割・自律範囲 人の関与
0: Programmed convenience 該当なし（定型ルールの実行のみ） ルールの設計・変更・停止
1: Assist 探索・比較・要約まで カート投入以降の全アクション
2: Assemble 提案・カートインまで カート内容の確認
決済手続き
3: Authorize ルール範囲内の決済まで（命令型） 決済条件の設定
条件外時の対応
4: Autonomize ポリシーに基づく自律運用まで（宣言型） 目的・制約ポリシーの設定
事後確認や例外時の対応
5: Networked autonomy エコシステム・エージェント間での
自律交渉・最適化		 ガバナンス・監査体制作り

2026年9月現在、エージェンティックコマースを謳うサービスの多くは「レベル2〜3」を指しています。
日用品や消耗品といった、買い物を「タスク」と感じる人が多い領域は自動化が進みやすいとされます。
領域ごとに自動化の受け入れやすさに違いはあるものの、AIエージェントに正しく商品の情報を伝え、条件が合致すれば検討対象に上がることは、エージェンティックコマースからの流入確保には必須となります。

エージェンティックコマースのAIエージェント形態

エージェンティックコマースのAIエージェント形態は、大きく以下2種類が考えられます。

タイプ 想定経路 メリット・デメリット
ECサイト組み込み型 　ユーザー
→既存流入経路
（Google検索など）
→ECサイト
→AIエージェント
→出品者/カート/決済		 【メリット】
・UIを独自に設定できる
【デメリット】
・ECサイト側でAIエージェントの管理が必要
・取り扱いはECサイト内にとどまる
連携基盤型 　ユーザー
→汎用AIエージェント
　（Geminiなど）
→連携基盤
→出品者/カート/決済		 【メリット】
・複数サイトを横断した購買体験を提供
【デメリット】
・AIプラットフォーム側のUIに依存する
・自律取引に向けたプロトコルの整備と準拠が必要

本記事では「連携基盤型」を中心に扱います。
Googleは既に以下のような連携基盤を持っています。

  • Google Merchant Center：家電、衣類、日用品（一般消費財）
  • Google Hotel Center：ホテル、旅館（空室・宿泊予約）
  • Actions Center：レストラン、美容院、デリバリー、チケット（各種予約・注文）
  • Google Maps Transit：列車、バス（運行情報・ルート案内）
  • Google Flights：航空券（フライト検索・運賃）

従来の仕組みは「情報参照」を目的とした一方向のデータ連携（フィード）が中心であり、実際の購入や予約手続きは外部の販売サイトへリダイレクト（送客）する形が一般的でした。
エージェンティックコマースには、AIエージェントとEC/予約システムが双方向でやり取りできる自律取引プロトコルが不可欠です。
2026年9月現在、Google Merchant Center（GMC）の物販領域を中心にこの対応が進められています。

エージェンティックコマースのスコープ

契約締結プロセスの観点から、商取引の契約形態は大きく以下の2種類に整理できます。

契約区分 特徴 具体例
定型約款・附合契約 あらかじめ事業者が定めた
定型的な取引条項に対し、
相手方が包括的に同意して成立する契約。
交渉余地がなく、即時・反復的に締結される。		 ・鉄道/航空券の購入
・ホテル宿泊予約
・日用品・家電のEC購入
・フードデリバリー注文
個別交渉契約 当事者双方が個別の条件
（価格、保証期間、契約不適合責任など）
を擦り合わせ・交渉して合意に至る契約。
締結には個別の意思決定が必要となる。		 ・不動産売買・賃貸契約
・医療行為・手術の同意
・M&A・企業間取引契約

エージェンティックコマースが主にスコープとするのは「定型約款・附合契約」です。
UCPをはじめとする標準化プロトコルでは、出品者がAPI等であらかじめ定義・公開した条件（定価、所定のクーポン・割引ルール、配送規約など）の範囲内でのみ取引が完結するよう設計されており、意図しない個別交渉の発生を防ぐ仕組みになっています。

個別交渉契約においては、合意条件のドラフト作成等のAI支援は可能であっても、最終締結には人間当事者間の意思決定が不可欠です。
そのため完全自動化が困難であり、自律取引を前提とするエージェンティックコマースの主対象からは外れます。

Google Merchant Centerでエージェンティックコマースを実現するイメージ

ここでは大変ザックリとどこが何を担当しているかを把握しましょう。
在庫切れやキャンセルなどは考慮せず、ハッピーパスで大まかなイメージを示します。

Phase 0：事前データ同期

Google Shopping Graphへ商品データを連携します。

GMCにおけるエージェンティックコマースPhase0シーケンス図

Phase 1：商品探索

商品を探索します。自動化のレベルによってユーザーの承認を得ます。

GMCにおけるエージェンティックコマースPhase1シーケンス図

Phase 2：リアルタイム確認

マーチャントに直接、在庫と決済金額を確認します。自動化のレベルによってユーザーの承認を得ます。

GMCにおけるエージェンティックコマースPhase2シーケンス図

Phase 3：決済

決済を実行し、それに伴い注文確定・在庫引当を行います。Phase 0に戻り商品情報が更新されます。

GMCにおけるエージェンティックコマースPhase3シーケンス図

エージェンティックコマースにおけるプロトコル

前章で紹介したシーケンスを念頭に置きながら、以下2つのプロトコルを紹介します。

  • UCP (Universal Commerce Protocol)
  • AP2 (Agent Payments Protocol)

UCPはREST API / MCP(Model Context Protocol) / A2A(Agent2Agent)上で実現します。
MCPとA2Aはエージェンティックコマース固有のプロトコルではないので説明を割愛します。

UCP (Universal Commerce Protocol)

UCPは、AIエージェントがマーチャントのサービスを発見（Discovery）し、カタログを検索し、チェックアウトを完了するための標準API仕様です。
今回は必須機能に絞って紹介します。

1. Discovery（サービスの発見と機能ネゴシエーション）

エージェントはマーチャントのエンドポイント（/.well-known/ucp など）にアクセスし、対応している機能セットや認証仕様を動的に取得します。

UCPのDiscoveryシーケンス図

2. Catalog API（構造化カタログ検索）

セマンティックな条件指定や絞り込みを行い、リアルタイムな商品スペック・価格を取得します。

UCPのCatalogシーケンス図

「定型約款URL / ダイジェスト」の受け渡しには、LCP (Legal Context Protocol) が関連します。
UCPやAP2が「取引・決済の実行」を担うのに対し、LCPは「どの利用規約に合意したかという法的証跡」を機械可読に担保するプロトコルです。
本記事では詳細を割愛します。

3. Checkout API（カート生成・発注処理）

配送先・決済トークンを紐付けて注文を確定します。

【状態遷移図】

UCPのCheckout状態遷移図

【シーケンス図】

UCPのCheckoutシーケンス図

AP2 (Agent Payments Protocol)

AP2は、エージェントがユーザーに代わって安全に決済を実行するためのプロトコルです。
取引のライフサイクルを3つの暗号署名付きオブジェクト（Mandate）で連鎖させることで、取引の改ざんやリプレイ攻撃を防止します。

Intent Mandate

ユーザーが事前に設定した「予算上限」や「有効期限」などの購買ポリシーと、エージェントへの自律実行権限を暗号署名した委任トークンです。

AP2のIntentシーケンス図

Cart Mandate

マーチャントが対象商品・数量・確定合計金額を暗号署名し、決済前の価格変動や注文改ざんを防ぐための価格ロックトークンです。

AP2のCartシーケンス図

Payment Mandate

ウォレットが委任条件（Intent）と見積もり（Cart）の整合性を検証し、条件合致時に発行される金額・店舗バインド済みの決済トークンです。

AP2のPaymentシーケンス図

おわりに

今回はGoogleでのエージェンティックコマースについて概要を見てきました。
私もまだまだ勉強中の領域ですが、皆様の理解の一助になれば幸いです！