GoogleのUCPは決済リクエストごとに4つのヘッダーを載せる。うち3つは後日の争いのためにある

2026年1月11日、GoogleがUniversal Commerce Protocolを公開しました。AIエージェントが商品を購入できるようにするオープンソース標準で、Shopifyと共同開発され、Etsy、Wayfair、Target、Walmart、Adyen、American Express、Mastercard、Stripe、Visa、Zalandoを含む20社超のパートナーが支持を表明しています。

続いた報道は、どれも買い物の話でした。代わりに探してくれるエージェント、代わりに決済してくれるエージェント、ショッピングカートの終わり、といった具合です。

ところが仕様書を読むと、買い物がそのなかで最もつまらない部分だと分かります。UCPが異例なほど丁寧に標準化しているのは、購入そのものではありません。その購入が双方の言うとおりに行われたという証拠のほうです。

要点:

• 変更を伴うUCPリクエストには必ず4つのヘッダーが載ります。 そのうち3つ、request-signature、idempotency-key、request-id は取引そのものには何も寄与しません。後になって誰かが、何が依頼されたか、それが一度だけ依頼されたか、その記録をもう一度たどれるかを証明するために存在します。
• 否認防止が名前のついた機能です。 任意のAP2マンデート拡張（dev.ucp.shopping.ap2_mandate）では、事業者が決済条件に暗号学的に署名し、プラットフォームはユーザーがそれを承認したことを証明する暗号学的マンデートを提供します。仕様が掲げる目的は「改ざんと紛争のリスクを大幅に低減すること」です。
• 支持社数は導入社数ではありません。 「20社超のグローバルパートナー」はGoogleが公表した表現であり、支持を意味します。本稿執筆時点で、UCPを実際に稼働させている販売事業者数を示す一次資料は見つかりませんでした。

ヘッダー構成はGoogleの公開当日のチュートリアルから引用しました。出典は末尾にまとめています。

誇張を削ってもなお残るUCPの姿

議論に入る前に、自分で確認できる事実を並べます。以下はucp.devで公開されている仕様書とGoogleの開発者ブログからのもので、いずれも2026年9月5日に取得しました。

この表のうち二点は立ち止まる価値があります。多くの解説記事がどちらも飛ばすからです。

一つ目はトランスポートの行です。UCPはMCP専用でもRESTでもありません。同じ宣言データをREST、MCP、A2A、埋め込みバインディングのすべてで提供し、どれを使うかは事業者が選びます。どのエージェント配管が勝つかに賭けないという、意図的な拒否です。

二つ目は日付ベースのバージョニングです。2026-04-08 はセマンティックバージョンではなく、日付です。仕様が挙げる理由は時系列の順序づけと明確な比較ですが、実務上の効果は別のところにあります。交渉されたすべてのセッションが、そのセッションを支配したルールの日付を一緒に記録することになる、という点です。バージョニングの決定を装った保存記録の決定であり、文書全体の性格を先に告げています。

UCPが潰そうとしている N×N のボトルネック

Googleの説明は N×N 問題です。会話型サーフェスに現れたい事業者は、サーフェスごとに専用の連携を作らなければならず、サーフェス側も事業者ごとに個別にオンボードしなければならず、結局は何も出荷されません。

同じ日に公開されたShopifyのエンジニアリング記事は、同じ問題を下から掘り下げます。著者のIlya Grigorikディスティングイッシュト・エンジニアは、20年以上、数十億件の取引、数百万の販売事業者を経て、コマースは正規化を拒むと述べます。「決済オプションとルールはカート、購入者、市場の性質によって変わる。割引には税法にも匹敵する重ね掛けと組み合わせのルールがある。フルフィルメントの選択肢は手に負えない順列で爆発する」。そして残しておく価値のある一文が続きます。「この複雑さはバグではなく、多様なリテーラーから創発する性質である」。

この一行がアーキテクチャ全体を説明しています。販売事業者は根本的に互いに異なると受け入れるなら、振る舞いを標準化することはできません。標準化できるのは、事業者が自らの振る舞いを宣言する方法と、エージェントが今しがた何に同意したのかを知る方法だけです。

事業者が /.well-known/ucp に公開する構造。出典: UCP仕様 2026-04-08、Overview。

会話はディスカバリーが終わってから始まる

仕様書とGoogleのチュートリアルが説明する流れは次のとおりです。順序そのものが論点なので、文字どおりたどる価値があります。

1. 事業者が /.well-known/ucp にプロファイルを公開します。 プロトコルバージョン、一つ以上のサービス（dev.ucp.shopping）、その中のケイパビリティ、トランスポートとエンドポイント、利用可能なペイメントハンドラー、そして後で効いてくる公開鍵 signing_keys を宣言します。
2. エージェントはリクエストごとに自分のプロファイルを名乗ります。 RFC 8941のディクショナリ構文を用いる UCP-Agent ヘッダーで、UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json" のように記述します。MCPトランスポートでは同じ情報が meta オブジェクトに載ります。
3. 事業者が積集合を計算します。 自らが対応するケイパビリティのうちプラットフォームも宣言しているものを残し、残った各項目について両者の配列に共通して存在するバージョンのうち最も新しいものを選びます。共通バージョンがなければ、そのケイパビリティは丸ごと除外されます。
4. 孤立した拡張は刈り取られます。 extends: "dev.ucp.shopping.checkout" を宣言した拡張は、checkoutが残らなければ消えます。もう取り除くものがなくなるまでこの処理を繰り返すため、連鎖する依存も扱えます。
5. 選ぶのは事業者です。 UCPはサーバー選択型のアーキテクチャです。エージェントではなく販売事業者が今回のセッションで何を有効にするかを決め、有効なケイパビリティのレジストリをレスポンスに返します。

命名は慣習ではなく統治の対象です。すべてのケイパビリティは {逆ドメイン}.{サービス}.{ケイパビリティ} の形式をとります。標準は dev.ucp.shopping.checkout、事業者独自のものは com.example.payments.installments といった具合です。リテーラーは誰の許可も得ず、誰とも衝突せずに、自分だけのケイパビリティを作れます。逆ドメインそのものが権威だからです。

失敗にも独自の分類体系があり、その切り分けが示唆的です。仕様書はディスカバリー失敗（トランスポートエラー。invalid_profile_url は400、profile_unreachable は424、profile_malformed は422）と交渉失敗を分けます。交渉失敗はビジネス上の結果なので、通常の200に capabilities_incompatible を載せて返ります。「あなたに到達できなかった」と「私たちには共通点がない」は別の出来事であり、UCPはこの二つを一つの400に潰すことを拒んでいます。

変更を伴うリクエストには必ず4つのヘッダーが載る

実際の呼び出しを見てみます。Googleが公開当日の例で、サンプルの花屋に対して決済セッションを作るリクエストです。

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

ヘッダーは4つです。それぞれが何のためにあるのかを問うと、パターンが浮かび上がります。

4つのうち3つは取引のためのものではありません。その取引をめぐる紛争のためのものです。

API衛生の偶然の産物ではありません。冪等キーとリクエストIDが決済分野のごく普通のベストプラクティスであるのは確かです。しかし仕様書はそこからかなり先へ進み、進むほど意図が明確になります。

否認防止は設計目標であり、コンプライアンスの後始末ではない

UCPは事業者が受け入れうる認証方式を4つ挙げます。APIキー、OAuth 2.0、mTLS、そしてRFC 9421に基づくHTTPメッセージ署名です。前の3つはありふれています。4つ目が特別なことをしています。

メッセージ署名では、双方がケイパビリティを宣言するのとまったく同じプロファイル文書の signing_keys 配列に公開鍵を掲載します。検証側は Signature-Input ヘッダーから keyid を取り出し、署名者が公開した鍵集合の kid と突き合わせ、署名を検証します。共有秘密も、事前登録も、アカウントも要りません。仕様書はこの結果をパーミッションレス・オンボーディングと呼びます。「発見可能なプロファイルを持つプラットフォームは、事前登録なしにどの事業者とも相互作用できる」というわけです。

明らかな穴はアイデンティティ・バインディングが塞ぎます。どの方式を使うにせよ、検証側は認証された主体が UCP-Agent に記されたプロファイルの代理を務める権限を実際に持つことを確認しなければならず、両者が矛盾する場合はリクエストを拒否しなければなりません。自分として認証したうえで他人のエージェントを名乗ることはできません。

そして事業者からプラットフォームへ向かうWebhookは署名が必須です。推奨ではなく義務です。配送、到着、返品といった注文ライフサイクルの更新は、プロトコルのなかでこの要求が絶対である唯一の箇所です。お金が動いた後に届くメッセージであり、誰もリアルタイムで見ていないからです。

出典: UCP仕様 2026-04-08、Identity & Authentication および Transaction Integrity の各節。

そしてはしごの頂上があります。自律エージェントと高額取引のために、UCPは任意の拡張 dev.ucp.shopping.ap2_mandate を定義しています。双方がこの拡張を交渉すると、次が成立します。

• 事業者が決済条件に暗号学的な署名を提供します。
• プラットフォームがユーザーによる承認を証明する暗号学的マンデートを提供します。

エージェントは非エージェント的なサーフェス上で、ユーザーの秘密鍵を用いてマンデートオブジェクトに署名します。つまり人間は、これから自分のお金を使おうとしているエージェントのループの中ではなく、自分が制御する画面の上で承認します。仕様書自身が述べる目的は、そのまま引用する価値があります。セキュリティの定型文ではないからです。この仕組みは「取引の詳細と参加者の同意について、強力なエンドツーエンドの暗号学的保証を提供し、改ざんと紛争のリスクを大幅に低減する」と書かれています。

要点はこうです。エージェントに買い物をさせるだけのプロトコルなら、これらは一つも要りません。販売者側の署名された条件と、ユーザー側の署名されたマンデートは、購入の機能ではありません。6週間後に、どちらが正しかったかを判断しなければならない人の前で、その購入をめぐって争うことの機能です。

語りが証拠を追い越しているのはどこか

UCPについて繰り返される話のうち、一次資料がそのままには裏づけないものが三つあります。

「20社超」は支持社数です。 Googleの表現は、UCPが「20社を超えるパートナーによって共同開発され支持された」というものです。支持とは公的な支援表明です。出荷された連携ではありませんし、稼働中の販売事業者ではなおさらありません。UCPで実際に取引している販売事業者数を示す一次資料を探しましたが、見つかりませんでした。

「オープン標準」と「Googleの標準」はどちらも真であり、その緊張は実在します。 仕様書はオープンソースで、GitHubリポジトリはプルリクエストを受け付け、命名規則は誰もが自分の名前空間を主張できるよう意図的に設計されています。同時に、最初のリファレンス実装を作ったのはGoogleであり、その実装に参加するには決済対象商品を備えた有効なGoogle Merchant Centerアカウントが必要です。中立なプロトコル、しかし門のある最初の舞台、というわけです。

UCPは販売事業者を消しません。 しばしば誤解されるので明記します。UCPのもとで事業者は自らのビジネスロジックを保持し、Merchant of Recordの地位を維持します。ShopifyのEmbedded Checkout Protocolは反対方向から同じ約束をします。フローに人が必要になると、エージェントは continue_url を読み込み、販売事業者の実際の決済画面がJSON-RPC 2.0チャネルを介してエージェントのサーフェス内にレンダリングされ、取引を確定するのは販売事業者です。エージェントはサーフェスであって代替物ではありません。

確認できなかった4点、そのまま明記する

取得時点でucp.devに公開されている仕様書はバージョン 2026-04-08 であり、その標準ケイパビリティ一覧はCart、Checkout、Identity Linking、Orderです。これは1月11日のチュートリアルとは異なります。あちらの例はバージョン 2026-01-11 で動作し、checkout、discount、fulfillmentを示しています。二つの日付の間に何かが追加されました。時期を特定できる一次の変更履歴も、中間バージョンの日付入りリリースノートも見つからなかったため、リリースという出来事ではなく差分そのものを報告します。

Google、Shopify、支持パートナーのいずれからも、UCPで稼働中の販売事業者数を公表した資料は見つかりませんでした。数字がないことは数字が小さいことの証拠にはなりませんが、私たちが数字を書かない理由にはなります。

Googleは、検索のAI ModeとGeminiアプリ内での購入を動かす最初のリファレンス実装を構築したと述べています。その提供範囲、地域、規模については独立に検証していません。

UCPがエージェンティック・コマースの標準になるかどうかは、本稿執筆時点では分かりません。分かると書いている記事は推測しています。誠実な読み方はもっと狭いものです。仕様書が存在し、公開されており、証明について異例なほど丁寧であり、非常に大きな企業がいくつも発表に名を連ねた、ということです。

署名されていない半分

コマースから一歩下がります。興味深い部分は一般化できるからです。

UCPが描くのは、機械が私の代わりに行動し、その行動のすべての段階が何かを残す世界です。誰が依頼したかは署名で、どんな条件だったかも署名で、何回だったかはキーで、どんな順序だったかは相関IDで残ります。6週間後に請求が争われたとき、そこには成果物があります。誰も記憶している必要がありません。

では、その行動の権限がどこから来たのかを考えてみます。エージェントが400個を購入するのは、調達の意思決定が下されたからです。契約が更新されるのは、誰かが条件に同意したからです。スコープが変わるのは、二人が木曜日に話し合い、一方がそうしようと言ったからです。

それらの会話が、同じワークフローの署名されていない半分です。機械側の半分は暗号学的な受領証と、紛争を一級のシナリオとして扱う仕様書の上に築かれつつあります。人間側の半分は、たいていの組織では誰かの記憶と、それとは食い違うもう一人の記憶と、その二つから書かれた要約です。

この非対称は、良くなる前にもっと悪くなります。機械側は仕様書の速度で改善し、人間側はまったく改善していないからです。そして失敗の形は具体的です。人が嘘をつくということではありません。派生した成果物、つまり要約や議事録やアクションアイテムの一覧が、それを派生させた元が消えた瞬間から記録そのものとして扱われる、ということです。要約は構造上、情報を失います。だから役に立ちます。そして同じ理由で一次資料としては不適格であり、元が破棄された後では、情報を失った要約と正確な要約を見分ける方法はありません。

UCPの設計者はこれをプロトコル層で理解し、文書に残しました。署名された元を保管し、そこから好きなものを派生させ、その派生をいつでも動かないものと照合できるようにせよ、ということです。技術ではなく規律であり、POST /checkout-sessions に当てはまるのと同じだけ、人が一時間話し合った内容にも当てはまります。

結論: エージェンティック・コマースは買い物の衣をまとった領収書の標準である

Universal Commerce Protocolは通常、AIエージェントが商品を買うための仕組みとして説明されます。通して読むと、エージェント的な何もかもがこれから絶えず直面する問いに答えようとする試み、と呼ぶほうが的確です。機械が私の代わりに行動したとき、私が何に同意したかについて、正確に何を証明できるのか。

UCPの答えは良い答えです。ケイパビリティを公に宣言し、条件に署名し、同意に署名し、再送にキーを付け、呼び出しを相関させ、その後に起きたことを伝えるWebhookにも署名せよ、というものです。このプロトコルが勝つかどうかは本当に未知数です。しかし、このプロトコルが中心に据えた問いは、誰が勝とうと消えません。

そこで、腰を据えて考える価値のある問いが一つ残ります。まもなくあなたのエージェントは、自分が何に同意したかについて、あなたが何に同意したかよりも良い記録を持つことになります。それはどこへ行き着くのでしょうか。

---

Telli.shの位置づけ: 私たちが作っているのは、その署名されていない半分です。Telli.shは会話を録音し、話者を分離し、15言語でリアルタイムに翻訳し、生成したすべての要約のそばに元の録音と全文の文字起こしを保持します。派生した成果物が唯一の成果物にならないようにするためです。Telli.shはUCPを実装しておらず、そう主張することもありません。私たちが扱うのは同じ問題の反対側、つまりエージェントの行動を承認する意思決定がたいてい口頭で下され、どこにも残らないという側です。

次の意思決定ミーティングを記録してみる

出典

• Universal Commerce Protocol 仕様書、Overview、バージョン 2026-04-08 — サービス・ケイパビリティ・拡張のモデル、命名規則、日付ベースのバージョニング、ケイパビリティ積集合アルゴリズム、交渉および署名のエラーコード、標準ケイパビリティ（Cart、Checkout、Identity Linking、Order）、トランスポート、UCP-Agent ヘッダーとRFC 8941構文、認証方式とパーミッションレス・オンボーディング、signing_keys による鍵ディスカバリー、アイデンティティ・バインディング、Webhook署名の義務、Transaction Integrity and Non-Repudiationの節。2026年9月5日取得
• Google Developers Blog「Under the Hood: Universal Commerce Protocol (UCP)」2026年1月11日 — パートナー一覧と20社超という支持数、AP2・A2A・MCP互換性、N×Nの説明、/.well-known/ucp マニフェスト、5ステップのチュートリアルと POST /checkout-sessions のヘッダー構成、Merchant of Recordと埋め込みオプション、AI ModeとGeminiにおけるGoogleのリファレンス実装、Merchant Centerの要件。2026年9月5日取得
• Shopify Engineering、Ilya Grigorik「Building the Universal Commerce Protocol」2026年1月11日 — 20年以上・数十億件の取引・数百万の販売事業者という背景、「バグではなく創発する性質」という論、4つの設計原則、continue_url を介したJSON-RPC 2.0のEmbedded Checkout Protocolハンドオフ。2026年9月5日取得
• Agent Payments Protocol (AP2) — UCPが互換性を宣言している決済プロトコル
• GitHub上のUniversal Commerce Protocol — 両方の発表で名指しされたオープンソースリポジトリ
• GPT-6 Astraの分析と、キャプチャ層がなお決めているもの — モデル側から見た同じ論。推論の質は、それが推論する記録を作った側で上限が決まる