プロトコル・標準2026年5月21日

Google Marketing Live 2026でUCPがホテル・フードへ拡張 — 「商品の購入」から「サービスの予約」へ広がるエージェンティックコマース

Google Marketing Live 2026でUCPがホテル予約とフードデリバリーへ拡張。多次元の在庫・料金を機械可読にする垂直仕様と、Merchant of Recordを事業者に残す設計を、小売・EC事業者の視点で読み解きます。

この記事のポイント

  1. 2026年5月20日のGoogle Marketing Live 2026で、GoogleはUniversal Commerce Protocol(UCP)を小売の外へ広げ、ホテル予約とフードデリバリーの垂直仕様を発表しました。LodgingにはAmadeus・Booking.com・Expedia Group・Hilton・Marriott・Trip.comが、FoodにはDoorDash・Uber Eats・Toast・Squareがco-developerとして参加します
  2. 商品の購入を扱ってきたエージェンティックコマースが、日付や料金プランで姿を変える「サービスの予約」へ踏み出した転換点です。取引主体(Merchant of Record)を事業者に残したまま、検索のAI ModeやGoogle Mapsの会話を受注チャネルに変える設計が示されました
  3. 在庫・価格・オプションといった複雑な商品データを機械可読にできるかが、エージェント経由の受注を得る前提条件になります。同日発表の運用エージェントAsk Advisorも含め、買い手側のプロトコルと売り手側の運用が同じ基盤に揃い始めたことへの備えが問われます

買い物のプロトコルが小売の外へ出た

2026年5月20日に開催されたGoogle Marketing Live 2026で、GoogleはUniversal Commerce Protocol(UCP)をホテル予約とローカルフードデリバリーへ拡張すると発表しました。広告・コマース担当VP兼GMのVidhya Srinivasan氏名義の公式ブログは、「検索のAI Modeから次のホテルを予約し、Google Mapsの会話からフードデリバリーを注文できるようになる」と説明しています。前日のGoogle I/Oで発表されたUniversal Cartが買い物体験のお披露目だったとすれば、Marketing Liveはプロトコルの適用範囲を業界横断へ広げる宣言でした。

UCPは、AIエージェントと事業者の間で商品情報の照会からチェックアウトまでをやり取りするオープン標準です。プロトコル自体の設計思想や小売側の参加企業は解説記事で扱っているため、本記事では「小売以外の産業へ広がったこと」が何を意味するのかに焦点を絞ります。公式ポータルのucp.devにはShoppingに加えてLodgingとFoodの項目が追加され、いずれも詳細仕様は近日公開と告知されています。

UCP for Lodgingが試す多次元の商品データ

拡張の柱のひとつが、ホテル予約向けのUCP for Lodgingです。ucp.devは、この垂直仕様の狙いを次のように説明しています。

AI面の中で高品質な予約フローを実現する。リアルタイムの料金・空室確認、複雑なレートプランのスムーズな処理、容易なゲスト登録、そしてセキュアなチェックアウトを含む。

なぜホテルに専用の仕様が必要なのでしょうか。物販の在庫が原則として「あるか、ないか」で表せるのに対し、宿泊の在庫は日付、部屋タイプ、人数、キャンセルポリシー、朝食の有無で価格が変わります。同じ部屋でも条件の組合せごとに別の商品になる、多次元の商品データです。エージェントに予約を任せるには、この構造をリアルタイムで機械可読にする必要があり、物販向けの商品カタログ仕様だけでは扱いきれません。垂直仕様は、この差分を吸収するための拡張として位置づけられています。

顔ぶれも異例です。ucp.devのLodging欄には、GDS(航空・ホテルの流通システム)最大手のAmadeus、OTA(オンライン旅行代理店)のBooking.com・Expedia Group・Trip.com、直販を強化してきたチェーンのHiltonとMarriott、そしてGoogleがco-developerとして並びます。これまで在庫と顧客を取り合ってきたOTAと直販チェーン、その間をつなぐGDSが、同じ仕様策定のテーブルに着いた構図です。Skiftは、Googleがエージェンティックコマースの基盤を旅行へ広げると公言したと報じています。

体験の入口は検索のAI Modeです。GoogleのLodging向け開発者ページは、AI Modeの会話から直接・即時の予約に到達できるようにすると述べています。プロトコルはAP2(Agent Payments Protocol。エージェントによる決済の権限や上限を扱う仕様)、A2A、MCPといった既存標準と相互運用し、OAuth 2.0などの業界標準の上に構築されます。ただし予約フローの詳細仕様やオンボーディング手順はまだ公開されておらず、現時点は参加希望者のウェイトリストを受け付ける段階です。

Merchant of Recordを事業者に残す設計判断

今回の発表で一貫して強調されたのが、取引主体の扱いです。Lodging向け開発者ページは「あなたがMerchant of Recordであり続ける。顧客データと顧客関係はすべて手元に残る」と明記し、事業者・クレデンシャル提供者・決済サービスの間に「透明な説明責任の連鎖」を作ると説明しています(Google)。公式ブログも、買い方にかかわらず小売事業者が常にMerchant of Recordであり続けると強調しました。

Merchant of Recordとは、取引の売主として代金の受領、返金、法令対応の責任を負う主体を指します。エージェント経由の販売でこの立場を失えば、事業者は顧客接点とデータを仲介者へ明け渡すことになります。モール型ECや旅行のOTAへの依存で起きた、手数料負担と顧客接点喪失の構図がAIの層で再演されるかどうかの分岐点です。UCPは少なくとも建て付けの上では、取引と顧客データを事業者側に残す選択をしました。この論点の全体像は、開かれた庭と壁に囲まれた庭の議論として別記事で整理しています。

とはいえ、Merchant of Recordが残っても、発見の入口がGoogleの面へ移ること自体は変わりません。エージェントがどの宿や店舗を候補として提示するのか、露出の力学や手数料に相当する商条件がどうなるのかは、詳細仕様と契約条件の公開を待つ必要があります。発表された設計思想と、まだ確定していない運用条件は、分けて評価するのが安全です。

UCP for Foodはカスタマイズの機械可読化

もう一方の垂直仕様であるUCP for Foodについて、ucp.devは次のように記載しています。

AI面における会話型フード注文ジャーニーを支える。きめ細かな食事カスタマイズ、リアルタイムの在庫と特典、チップ、配送指示を、スケーラブルなチェックアウト体験で扱う。

宿泊の難所が多次元のレート構造だとすれば、フードの難所はカスタマイズの組合せと即時性です。トッピングや辛さの指定、配送先と時間、チップまでを会話の中で確定させるには、店舗側のメニューとオプションが構造化されていなければなりません。co-developerにはDoorDashとUber Eatsに加え、POS(販売時点管理システム)のToastとSquareが名を連ねました。デリバリープラットフォームを経由する流れだけでなく、店舗の業務システムからエージェントへ直結する経路までが視野に入っていることを示す人選です。

設計原則はLodgingと共通です。Foodの開発者ページも、事業者がMerchant of Recordであり続けること、トークン化された決済と既存の決済連携を活かせることを掲げています。詳細仕様とオンボーディングが近日公開である点も同じです。

売り手側の運用もエージェント前提になる

同じ日、売り手側にも大きな発表がありました。Merchant Centerに組み込まれるAsk Advisorは、Google AdsとGoogle Analyticsを横断してインサイトを提示し、キャンペーン設定などのタスクを代行するエージェントです。ベータ版は英語アカウント向けに提供が始まっています(Search Engine Land)。

計測の面ではAI Performance Insightsが発表されました。自社ブランドがAIの面でどれだけ言及されているかを、類似ブランドとのシェア・オブ・ボイス比較で可視化する機能で、米国、カナダ、オーストラリア、ニュージーランド、インドから展開されます。あわせて発表されたConversational Attributesは、会話調の探し方に合わせて商品説明を整えるための機能です(Google)。

個々のツールより重要なのは構造のほうです。買い手側のプロトコル(UCP)と売り手側の運用エージェント(Ask Advisor)が、同じMerchant Centerのデータ基盤の上に揃い始めました。エージェントが買う時代には、売る側の分析や広告運用もエージェントが担う。Marketing Live全体を貫いているのは、この対称性です。

小売・EC事業者が読み取るべきこと

ホテルとフードの拡張は、一見すると物販ECの外側の話に見えます。しかし問われている能力は共通です。

まず、機械可読にすべき商品データの範囲が広がります。物販でも、配送日時の指定、ギフト設定、定期購入、保証や返品条件といったサービス的な属性を含めてエージェントに渡せるかが、受注の可否を左右するようになります。多次元のレートを扱うLodging仕様は、複雑な商品データの機械可読化がどの水準まで要求されるかを示す先行例です。この整備の進め方は商品データのエージェント対応で詳しく扱っています。

チャネル戦略の再点検も避けられません。AI ModeやGoogle Mapsが受注チャネルになるなら、自社サイト、モールや代理店、エージェント経由という系統ごとに、流入の配分と計測をどう設計するかが問われます。Merchant of Recordと顧客データが残るという条件は依存のリスクを和らげますが、露出の主導権まで保証するものではありません。

一方で、拙速な投資判断は禁物です。LodgingもFoodも詳細仕様は未公開で、ウェイトリスト登録を受け付ける段階にとどまります。確定した仕様と発表段階の設計思想を区別し、仕様の公開後に自社システムとの接続コストを見積もるのが現実的な順序です。

まとめ

Google Marketing Live 2026の本質は、エージェンティックコマースが「商品の購入」から「サービスの予約」へ広がる転換点を示したことにあります。日付と条件で姿を変えるホテルの在庫、組合せが増え続けるフードの注文。これらを機械可読にする垂直仕様が、Merchant of Recordを事業者に残す設計とセットで提示されました。同時にAsk Advisorが売り手側の運用をエージェント化し、買い手と売り手の双方が同じ基盤に乗る構図が見えています。

次に注視すべきは、LodgingとFoodの詳細仕様がいつ、どんな中身で公開されるか。AI Mode経由の予約や注文の最初の事例がどこから出るか。そしてPMS(ホテルの基幹システム)やPOSのベンダーが、UCP対応をいつロードマップに載せるかです。小売・EC事業者にとっては、自社の商品データがこの水準の機械可読性に耐えるかを確かめておくことが、いま取れる最も確実な準備になります。