「AIエージェントに買い物をさせる ― Universal Commerce Protocol（UCP）の紹介」というタイトルで DevelopersIO 2026 【会場・Day】に登壇しました #devio2026
こんにちは、リテールアプリ共創部の西田です。
2026年9月29日に開催された DevelopersIO 2026 Osaka Day 2 で、「AIエージェントに買い物をさせる ― Universal Commerce Protocol（UCP）の紹介」というタイトルで登壇しました。
この記事では、登壇資料と発表の要点を紹介します。
登壇資料
ポイントのご紹介
発表の概要
Universal Commerce Protocol（UCP）は、AIエージェントが商品を探し、カートに入れ、購入手続きを済ませて注文するまでの流れを標準化する仕様です。2026年1月11日に発表され、Apache License 2.0 のオープンな標準仕様として GitHub で公開されています。Google、Shopify、Etsy、Wayfair、Target、Walmart などが共同開発しています。
発表では、デモでと、次の3つの章で仕組みを説明しました。
- デモで何が起きていたか
- UCP の仕組み
- 購入の流れと支払いの安全対策
仕様のバージョンは、発表時点で最新の v2026-08-25 を基準にしています。
デモ
チャットで「在庫のあるクッキーを見せて」と話しかけると、エージェントが商品を提示し、カートに入れ、住所を受け取り、支払い方法を選んで注文を確定するまでを見せました。
デモは、UCP の公式サンプル（Agent2Agent〔A2A〕サンプル、UCP 2026-01-23 版）を、手元で日本語・円表示に改変して動かしたものです。決済はモックになっており、実際の請求は発生しません。
エージェントの応答には、チャットの中の会話に必要な文章と一緒に UCP のチェックアウト情報（a2a.ucp.checkout）が入っています。チャット画面は、そのデータを商品カードや購入内容として表示しています
{ "kind": "text",
"text": "チョコチップクッキーを2つ追加…" },
{ "kind": "data", "data": {
"a2a.ucp.checkout": {
"id": "ba317280-…",
"status": "incomplete",
"currency": "JPY",
"line_items": [{
"item": { "id": "COOKIE-001",
"title": "チョコチップクッキー",
"price": 380 },
"quantity": 2 }],
"totals": [
{ "type": "subtotal", "amount": 760 },
{ "type": "total", "amount": 760 }],
"payment": { "handlers": [ … ] }
} } }
1. デモで何が起きていたか
事業者の側から見ると、デモ相当の購入手続きに必要な最小構成は次の2つです。
/.well-known/ucpを公開する（対応機能・エンドポイント・決済ハンドラ・公開鍵をまとめた JSON）- チェックアウト API を実装する（作成・取得・更新・確定・キャンセルの5つ）
必要に応じて、商品検索（Catalog）・カート（Cart）・注文の確認（Order）の API を追加します。プラットフォームへの登録や商品フィードは、これら以外に別途必要です。
2. UCP の仕組み
商品が見つかる入口は既存の仕組み
UCP には、ショップを探す仕組みそのものは定義されていません。AI が商品を見つける入口は、Merchant Center などへの商品フィード、Shopify の横断カタログ、通常の検索といった既存の仕組みです。UCP が標準化しているのは、ショップが見つかった後の商品検索（Catalog）と購入（Checkout）のやり取りです。
なお補足ですが、 Google は、AIに引用されるために、追加の要件や特別な最適化は必要ないと説明しています（AI features and your website）。
Google 検索全般と同様に、AI 機能にも基本的な SEO ベスト プラクティスを適用できます。具体的には、Google 検索の技術要件を満たすこと、検索ポリシーを遵守すること、信頼性の高い有用なユーザー第一のコンテンツを作成することなどの主なベスト プラクティスを重視します。
/.well-known/ucp とネゴシエーション
事業者は /.well-known/ucp に、対応する通信方式（REST / MCP / A2A / 埋め込み）、機能とバージョン、決済ハンドラ、署名検証用の公開鍵をまとめて載せます。
プラットフォームはリクエストのたびに自分のプロファイルの URI を送ります。事業者は、双方が対応する機能とバージョンの共通部分を計算して、応答で返します。配送（fulfillment）や割引（discount）のような拡張機能は、親の機能（checkout や cart）に付け足す形で、親がすべて除外されると一緒に除外されます。
通信方式は選べる
同じ操作を、REST のエンドポイントとしても、Model Context Protocol（MCP）のツールとしても公開できます。たとえばチェックアウトの確定は、REST では POST /checkout-sessions/{id}/complete、MCP では complete_checkout です。
3. 購入の流れと支払いの安全対策
金額と選択肢は事業者が出す
公式の参照実装（Python / FastAPI、UCP 2026-04-08 版）で、プロファイル取得からカート作成、割引の適用、チェックアウトへの移行、配送先と配送方法の選択、決済と注文作成までを通しました。金額は毎回事業者が計算して返し、配送方法などの選択肢も事業者が出します。金額は最小通貨単位の整数で扱います。
Merchant of Record は事業者のまま
購入手続きが AI エージェントや Google の画面で進んでも、売り手（Merchant of Record）は事業者のままです。Google も Merchant Center のヘルプで同じ説明をしています。決済・返品・問い合わせの窓口も事業者に残ります。
カード番号を誰が扱うかで PCI DSS（カード業界のセキュリティ基準）の範囲が決まる
決済代行が発行したトークンだけを受け取る構成なら、事業者の PCI DSS の範囲を抑えられます。暗号化されたカード情報を自分で復号するなど、カード番号そのものに触れる構成では準拠が必要です。
AP2 Mandates 拡張
通常、注文の確定は購入者が信頼された画面で行います。UCP には、AP2（Agent Payments Protocol）の Mandate を使う拡張もあり、交渉で有効になったセッションでは、購入者の同意を署名で示して注文を確定できます。
- 事業者が「この内容・金額で売ります」と署名する
- 購入者の同意を Checkout Mandate（購入への同意）と Payment Mandate（支払いの承認）にする
- 事業者と決済側がそれぞれ署名を検証する
メリットは、購入者の同意を、事業者や決済側が検証できる証拠として受け取れることです。AP2 の利用は必須ではありません。
UCP で使う署名
UCP では、目的の違う署名を使い分けています。
| 通信を守る署名（HTTP 署名） | 取引の証拠を残す署名（AP2 の2つ） | |
|---|---|---|
| 何を証明するか | 通信が本物で、改ざんされていない | 誰が何に合意・承認したか |
| 主な用途 | 受け取った時点での検証 | 保存・中継し、後から検証することを想定 |
| 正規化 | しない（届いたバイト列で検証） | JCS（RFC 8785）でそろえる |
HTTP 署名は RFC 9421 で定められた標準で、UCP はその使い方（署名するタイミング、アルゴリズム、公開鍵の置き場所など）を定めています。
補足: 日本での状況
UCP の仕様自体は、日本の事業者も実装できます。一方、Google の UCP チェックアウトは、2026年9月時点で米国が中心です（カナダ・豪州で展開中、英国は予定）。日本向けの提供時期は発表されていません。
UCP のロードマップでは、インド・アジア太平洋・中南米などへの段階的な展開が方針として挙がっていますが、日本は名指しされていません。
最後に
この記事が誰かの参考になれば幸いです
