UCP・ACP・MCPの違いは何か ── どれかを選ぶ話ではなく、層で分かれる（2026年10月時点）
UCP・ACP・MCPは競合規格のように並べられがちですが、層が分かれています。OpenAI・Google・Shopify・UCP公式の発表10本を日付順に読み、2025年9月から2026年10月までに何が決まり、誰が決める席にいて、どこまでが予告のままなのかを整理しました。
読むホテル・宿泊のUCP対応は、まだ「予約」だけ ── draft仕様に今あるもの・まだ無いもの
UCPの宿泊向け仕様とは、AIエージェントを載せたサービスと宿泊事業者が、1つの予約を作り終えるまでのやり取りを決めた共通の作法です。最初のdraft版が取り込まれたのは2026年9月25日（UCP公式サイトのお知らせページ）で、仕様ページは今も、データ構造も処理の流れも変わり続けると断っています。この記事では、draftにある欄・まだ置かれていない欄・公開の場に残っている問いを整理しました。自社の予約条件がdraftの形で表せるかを決めるために、今ある欄を見る。それがこの記事の目的です。
UCPの宿泊向け仕様（dev.ucp.lodging.booking）とは
UCPの宿泊向け仕様とは、AIエージェントを載せたサービス側と宿泊事業者側が、空室と料金の確認から予約の確定までを同じ形式でやり取りするための取り決めで、2026年10月16日時点ではdraft段階にあります。UCP公式サイトの仕様ページは、予約セッションを端から端まで扱う機能として置いています。
お金と責任の置きどころも、仕様の側で決まっています。同ページは、宿泊事業者が販売者（merchant of record）のままで、この機能でカード決済を受けるのにPCI DSS準拠は必要ないとしています。さらに、AP2の権限付与の拡張に対応していない限り、予約は信頼できるUIで利用者自身が確定させることになるとも書いています（原文［2］）。
同ページは本文の先頭で、この機能がdraft段階にあり、データ構造・通信の割り当て・処理の流れが現在も動いているため、仕様が進むにつれて互換性を壊す変更が入ることがあると断っています（原文［1］）。draftであるという断りは、仕様ページの1行目に置かれています。私たちが足した注意書きではありません。
UCPそのものの位置づけと、ACPやMCPとの層の違いはUCP・ACP・MCPの違いは何かで扱っています。この記事は、その地図のうち宿泊の区画を開けます。
なぜいま、宿泊事業者がdraftを見ておくのか
1 draftにあるのは「予約」で、探される側はこれから
今あるdraftが扱うのは、見つかったあとの工程です。仕様ページは、予約セッションを始めるときに、施設のIDと、宿泊の束のIDまたは部屋種別とレートプランのIDを、上流の検索で得たものとして渡す前提を置いています。探す工程は、この機能の外です。
UCP公式サイトのロードマップは、宿泊について、予約の先にあるものとして、ホテルの発見、さまざまなレートでの部屋の選択、ロイヤルティ、割引を挙げています。ただし同ページは冒頭で、ロードマップは現時点の方向を示すもので、特定の機能を届ける約束にはならず、取り組みは変更・削除・追加の対象になると書いています（原文［12］）。予定として読めるのは、ここまでです。時期は示されていません。
探す工程がこの機能の外にある点は、当事者からも問われています。UCP公式リポジトリの宿泊draft公開の議論（2026年9月25日投稿）では、英国で6室規模の宿を営むという投稿者が、大手の流通網や予約エンジンの配信に乗っていない施設をどう見つけるのかと尋ねています。自社のドメインに置いたプロフィールを直接見つけてもらう形なのか、接続事業者を通して届く形なのか分からないという趣旨です（原文［14］）。これは第三者の投稿で、仕様の決定ではありません。
2 draftは、日付のついた版の外に置かれている
UCPの仕様は、draftと、日付で名前を付けた版に分かれます。公式サイトの版の切り替えに並ぶのは、draftと、2026年1月11日・1月23日・4月8日・8月25日の4つです。
宿泊の仕様が置かれているのは、このうちdraftの側です。私たちが2026年10月16日にブラウザで開いて確かめたところ、直近の2026年8月25日の版では、仕様全体のページは表示される一方で、宿泊のページは表示されず、目次にも宿泊の項目は出てきません。パスの書き方の違いではなく、その版に宿泊が入っていない形です。直近の日付版は、宿泊draftが取り込まれた2026年9月25日より前にあたります。
ここから言えるのは、宿泊の機能がまだどの日付版にも入っていないことまでです。いつ入るのかについての記述は、今回見たページには見当たりません。
3 変わるときの手続きは、先に決められている
draftが動くこと自体は、見張る場所が決まっています。UCP公式サイトの版の管理のページは、互換性を壊す変更について、変更要求の表題に印を付ける運用と、取り込む2週間前に公式の議論の場で知らせる運用を書いています。例外は安全に関わる修正で、開示の時期は運営の評議会が個別に決めるとしています（原文［11］）。
ここは私たちの解釈ですが、宿泊事業者が毎週仕様を読み直す形にはならず、公式の議論の場を見る担当を決めておけば追えます。
draftにある欄のうち、値段・支払いの時期・宿泊者を見る
2026年10月16日に取得したdraft仕様に置かれている欄を見ます。以下はすべてdraftの記述で、変わることがあります。
1 値段の内訳と、いつ払うかが、別建てになっている
仕様ページは、宿泊の予約が全額表示の規則に従うとし、理由として米国や欧州の価格表示に関する消費者保護の決まりを挙げています。そのうえで、滞在の支払い全体は、予約の確定時に前払いするぶんと、チェックインやチェックアウトのときに施設が直接受け取るぶんに分かれることが多いとしています。
この2つを、仕様は別の配列で表します。内訳を表すのが totals で、小計・料金・税、および任意の割引が入り、総額以外の行の合計が総額と一致することが求められます。いつ払うかを表すのが payment.terms で、時期ごとの明細を持ちます。内訳と時期を分けたのが、宿泊向けの仕様の設計です。
支払いの時期は3種類です。予約の確定時に払うぶん、将来の日付や出来事の時点で払うぶん、施設が現地で直接受け取るぶん。3つ目の区分が at_property で、仕様は例として地域の宿泊税と、支払いが必須の施設利用料を挙げています。
現地で受け取るぶんの扱いも書かれています。仕様は、予約時に納められない必須の税や料金があるときは、警告の伝達欄に開示として出し、該当する支払いの明細を指し示すことを推奨しています。そのお知らせには地域の税率・免除の条件・支払いの方法を記さなければならないとされ、正式な規定のリンクも置くこととされています（原文［3］・原文［4］）。
2 仕様の作例は東京のホテルだが、日本での提供の予告ではない
ここは、作例と提供の予告が混ざりやすいところです。宿泊のdraft仕様には、支払いの時期を説明する作例が2つあり、その1つが東京のホテルで書かれています。
中身はこうです。3泊の滞在で、室料と前払いのサービス料は予約時に請求し、支払いが必須の施設利用料と東京都の宿泊税は施設が現地で受け取る。通貨は日本円で、施設名は架空の名前です。警告の伝達欄には、東京都の定めにより1泊1人あたりの宿泊税が一定額以上の室料に適用され、施設がチェックイン時に直接受け取るというお知らせが開示として置かれています（原文［5］）。
これは仕様の書き方を示すための作例です。日本での提供の予告としては読めません。日本でいつ使えるかについての記述は、今回見たUCP公式サイトのページにも、Googleの2026年5月20日のブログにも見当たりません。同ブログは、UCPを使ったチェックアウトの展開先として、これからの数か月でカナダとオーストラリア、その後に英国を挙げ、ホテル予約とローカルのフードデリバリーへの拡張についても、これからの数か月という表現を使っています（原文［13］）。UCP公式サイトのロードマップが段階的な展開先として挙げるのは、インド、アジア太平洋、ラテンアメリカ、その他で、日本を名指しした記述は置かれていません。アジア太平洋に含まれるかどうかも書かれていないため、この記事では推測しません。ただしこのブログは2026年5月20日のもので、取得日（2026年10月16日）の約5か月前にあたります。その後に展開先や時期を更新した記述は、今回見たページには見当たりません。
作例の金額も、仕様の説明のための数字です。実際の料金水準を示すものとしては使えません。
3 宿泊者の情報は、送る時期と範囲が決められている
仕様は、支払いの契約主体（予約者）と、実際に部屋に泊まる人（宿泊者）を分けています。予約者は、支払いと連絡と予約の帰属を負う契約上の相手です。法人や代理の予約、複数の部屋にまたがる予約を扱えるように、2つは切り離されています。
宿泊者を指すIDの扱いには、強い制限があります。仕様は、このIDが1件の予約セッションの中だけで通じる文字列であるとし、サービス側は販売者をまたぐ継続的な追跡用IDを使ってはならず、IDの中に個人を特定できる情報を出してはならないとしています。事業者の側も、このIDをもとに別の予約セッションとのあいだで同一人物を推定したりつなげたりしてはならないとされています（原文［6］）。
送る時期にも指示があります。仕様は、予約が確定可能な状態に達する前は、サービス側が宿泊者のIDを超える身元の項目を送らないことを推奨し、送るのは事業者が伝達欄で求めた項目だけにすることも推奨しています。
宿泊者名簿に関わる項目が固定の欄として置かれていないのは、ここの延長です。仕様の事業者側の決まりは、確定可能な状態を返す前に代表者を特定することを求めたうえで、追加で必要な身元の項目については、旅券番号、国籍、生年月日を例に挙げ、事業者ごとに伝達欄を通じて取り決めることとしています（原文［7］）。固定の欄に並んでいるのは、氏名・メール・電話番号・年齢までです。
日本の法令が宿泊事業者に求める記録の内容は、この記事では扱いません。ここで言えるのは、仕様の側に固定の欄が置かれておらず、事業者ごとの取り決めになっているということまでです。実際の運用は、法令に詳しい専門家の確認を取ってから決めてください。
あわせて押さえる、draftに置かれている欄
| 欄・区分 | draftに置かれている内容 | 読み方 |
|---|---|---|
| 予約の状態 | 情報が足りない／人の手に渡す必要がある／確定可能／確定の処理中／確定済み／無効または期限切れの6つ | どの状態かで、次に何をするかが決まる形になっています |
| 伝達欄の重さ | サービス側が入力を直して再試行できる／事業者が機械では集められない情報を求めている／利用者の確認と承認が必要／対象が無く作り直しが必要の4段 | 真ん中の2つは利用者の画面に渡す形で、4つ目は新しい対象で作り直すか画面に渡すかのどちらかとされています |
| 標準のエラー | 在庫が尽きた／割り当てた人数が部屋の定員を超えた／決済に失敗した／資格の申し立てが確定時に確かめられなかったの4種 | 宿泊の商習慣に固有の制約を表すコードは、draftには置かれていません |
| 総額が動いたとき | 室料・税・必須の料金が変動したときは、計算し直した内訳を返し、総額が変わったことを警告として報告しなければならないとされています。買い手に強く知らせる必要がある金額のときは開示として扱い、サービス側は自動で閉じたり隠したりしてはならないとされています | 値段が動く商売の側に、表示の決まりが付いています |
| 規定のリンク | プライバシーポリシーと利用規約のリンクは、応答の根元で必須。仕様は法令遵守のために必須と書いています | すぐ用意できる一方、無いと形が成立しない欄です |
| セッションの期限 | 期限の時刻を示すこと、期限のあいだ在庫を仮に押さえること、更新のたびに在庫を確かめて確定時に割り当てることは、いずれも任意とされています | 仮押さえは求められておらず、事業者が選べる形です |
| 部屋の定員 | 大人・子ども・合計の上限と、子どもの年齢の区切り。年齢はチェックイン日時点の満年齢で判定するとされています | 定員と年齢の判定は、事業者側がしなければならないこととして書かれています |
いずれも2026年10月16日にブラウザで取得した宿泊の予約のdraft仕様の記述です。draft段階のため、欄の構成も語も変わることがあります。表の7行は、仕様ページの該当する節から私たちが抜き出したもので、仕様が立てている分類の見出しではありません。予約の状態・標準のエラー・規定のリンクの原文は原文［9］。
今日、宿泊事業者が手を動かせること
draftが動くとしても、先に整えて損のない欄があります。以下の3つは、draftの現在の記述で事業者側の決まりとして書かれている内容に直接当たります（1つ目と2つ目はしなければならないとされ、3つ目は全額を示すことがしなければならないとされる一方、現地徴収の開示は推奨です）。
1 レートプランの名前と説明文を、それだけで条件が分かる形にする
プランの名前の書き方は、仕様の側でしなければならないこととして書かれています。draftのレートプランに置かれている欄は、ID・名前・説明文の3つです。そのうえで仕様は事業者側の決まりとして、名前がそのレートプランを他と区別し、説明文があるときは名前と合わせて、買い手が規定の欄を読まなくても重要な商業上の条件を理解できるものであることを求め、名前と説明文のどちらも規定の欄と矛盾してはならないとしています（原文［8］）。
朝食が付くか、館内の利用券が付くかといった内容を構造化して表す欄は、draftには置かれていません。宿泊draft公開の議論でも、こうした内容が現状ではレートプランの文章でしか表せないという指摘が第三者の投稿として出ています。構造化された欄にしてほしいという提案も同じ投稿にありますが、未採択の提案です。
手を動かす先は、自社の予約システムのプラン名です。社内の略称や記号のままのプラン名を、外に出して条件が読めるかを見る。今日から着手できます。
2 キャンセル条件を、3つの区分と文章の両方に落とす
キャンセル条件は、宿泊の予約とは別のdraftのページ（キャンセル条件の拡張）に置かれています。同拡張のページは、これが購入前の機械で読めるキャンセル条件を足すものだとし、無料で解約できるか、違約金がかかるか、返金されないかという問いに、外部の規定のページを読み解かずに答えられるようにするためだとしています。
draftに置かれている区分は3つです。いま無料で解約できる状態、違約金がかかる状態、返金されない状態。それぞれ refundable・partially_refundable・non_refundable という値が当たります。
段階的なキャンセル料の表は、この3区分では表せません。同拡張のページは、宿泊のキャンセルの決まりが施設の現地時間の締切や季節ごとの規則をたびたび含むため、事業者が説明文に期限と条件の全体を記すことをしなければならないこととして求め、説明文と3つの区分が互いに矛盾してはならないとしています（原文［10］）。
やることは2つです。各プランが3つの区分のどれに当たるかを決め、何時間前までならいくらという表を1つの文章として書き起こすことです。後者は、人が読む文章としてもそのまま使えます。この拡張もdraft段階で、区分の数も語も変わることがあります。
3 現地で受け取るぶんを、支払いの時期として切り出す
3つ目は、1節目の at_property の形に合わせて自社の料金表を仕分けることです。前払いで受け取っているもの、チェックイン時に現地で受け取っているもの、宿泊税のように自治体の定めで現地徴収になっているもの。3つが混ざったまま1つの金額になっていると、内訳と時期を分けて返す形に合わせられません。
仕分けの材料は、自社の料金表と予約システムの中にあります。外部データを買う話ではありません。考え方の土台はAIエージェントが買う時代に、自社に残る顧客データは何かに、進め方はデータ基盤・MAに置いています。
自社の予約データと顧客データが資産になっているかは、顧客資産化診断で分解できます（7問・約3分）。
宿泊のUCP対応について、よくある質問
UCPの宿泊向け仕様は、もう決まった仕様ですか？
draft段階です。UCP公式サイトの宿泊の予約の仕様ページは、本文の先頭で、この機能がdraft段階にあり、データ構造・通信の割り当て・処理の流れが現在も動いているため、仕様が進むにつれて互換性を壊す変更が入ることがあると断っています（2026年10月16日にブラウザで取得）。宿泊の機能は、直近の日付版（2026年8月25日）には入っていません。
AI経由のホテル予約は、いつから使えるようになりますか？
時期は、今回見た公式のページには示されていません。Googleは2026年5月20日のブログで、プロトコルをホテル予約とローカルのフードデリバリーに広げるとし、検索のAI Modeからホテルを予約できるようになる時期を、これからの数か月と書いています。ただしこのブログは取得日（2026年10月16日）の約5か月前のもので、その後に展開先や時期を更新した記述は、今回見たページには見当たりません。UCP公式サイトのロードマップも、宿泊について予約の先にある取り組みを挙げる一方、特定の機能を届ける約束にはならないと断っています。
日本のホテルも対象ですか？ 仕様に東京の作例があると聞きました。
作例があることは、提供の予告ではありません。宿泊の予約のdraft仕様には、支払いの時期を説明する作例として、3泊の東京のホテルの滞在で、室料と前払いのサービス料を予約時に請求し、施設利用料と東京都の宿泊税を施設が現地で受け取る形が置かれています（2026年10月16日にブラウザで取得）。これは仕様の書き方を示すものです。日本でいつ使えるかについての記述は、UCP公式サイトの各ページにも、Googleの2026年5月20日のブログにも見当たりません。
最低宿泊日数や到着日の締めは、draft仕様のどこで表せますか？
それを表す欄は、2026年10月16日に取得したdraft仕様には置かれていません。標準のエラーは、在庫が尽きた、割り当てた人数が部屋の定員を超えた、決済に失敗した、資格の申し立てが確定時に確かめられなかったの4種です。UCP公式リポジトリの宿泊draft公開の議論では、ホテルの料金管理の実務経験があるという投稿者が、販売の制約を表せないと在庫が尽きたという返答になり立て直せないと指摘し、滞在の束に制約の欄を置く案とエラーコードを提案しています。これは第三者の提案で、末尾は担当者への問いかけの形であり、採択されたものではありません。
宿泊者名簿に必要な項目は、draft仕様のどこに入りますか？
固定の欄としては置かれていません。draft仕様の事業者側の決まりは、追加で必要な身元の項目について、旅券番号、国籍、生年月日を例に挙げ、事業者ごとに伝達欄を通じて取り決めることとしています（2026年10月16日にブラウザで取得）。固定の欄に並ぶのは、氏名・メール・電話番号・年齢までです。この記事は法令についての助言ではありません。日本の法令がどこまで求めるかは、法令に詳しい専門家の確認を取ってください。
まとめ
UCPの宿泊向け仕様はdraft段階です。仕様ページ自身が本文の先頭で、互換性を壊す変更が入ることがあると断っており、宿泊の機能は直近の日付版（2026年8月25日）には入っていません。
そのdraftにあるのは予約の工程で、探される側の仕組みは置かれていません。公式のロードマップは予約の先の取り組みを挙げる一方、特定の機能を届ける約束にはならないとも書いています。
今ある欄のうち宿泊事業者がすぐ使えるものは3つです。レートプランの名前と説明文だけで商業上の条件が分かる形にすること。キャンセル条件を3つの区分と1つの文章に落とすこと。現地で受け取るぶんを支払いの時期として切り出すこと。いずれもdraftの現在の記述で事業者側の決まりとされている内容です（現地徴収の開示は推奨にとどまります）。
最低宿泊日数や到着日の締め、朝食などの付帯内容、施設の公的な登録番号については、公開の議論で第三者から提案や質問が出ています。いずれも未採択です。互換性を壊す変更は取り込みの2週間前に公式の議論の場で知らされる運用です。見る場所は、そこです。
出典と、書けなかったこと
出典と注記を開く
出典
・UCP 公式サイト「Booking Capability」（宿泊の予約のdraft仕様）ページを見る ── draft段階である旨の断り、宿泊事業者が販売者（merchant of record）のままでありPCI DSS準拠が不要である旨、AP2の権限付与の拡張に対応していない限り信頼できるUIで利用者が確定させる旨、上流の検索で得たIDを渡す前提、全額表示の規則、値段の内訳と支払いの時期の分離、支払いの時期の3種類、現地徴収の開示、総額が変わったときの報告、予約者と宿泊者の分離、宿泊者のIDの扱いの制限と送る時期、追加の身元の項目を事業者ごとに取り決める旨、レートプランの名前と説明文についてしなければならないとされている点、予約の状態の6つ、伝達欄の重さの4段、標準のエラーの4種、規定のリンクが必須である旨、セッションの期限と在庫の押さえ方、部屋の定員と子どもの年齢の判定、東京のホテルの作例。2026年10月16日にブラウザで取得・UCP 公式サイト「Cancellation Policy Extension」（キャンセル条件の拡張のdraft仕様）ページを見る ── 購入前の機械で読めるキャンセル条件を足す拡張である旨、3つの区分とそれぞれの意味、説明文に期限と条件の全体を記すことをしなければならないとしている点、説明文と区分が矛盾してはならない旨。2026年10月16日にブラウザで取得
・UCP 公式サイト「Versioning」（版の管理）ページを見る ── 日付による版の付け方、互換性を壊す変更の表題への印、取り込みの2週間前に公式の議論の場で知らせる運用、安全に関わる修正の例外。2026年10月16日にブラウザで取得
・UCP 公式サイト「Roadmap」（ロードマップ）ページを見る ── 特定の機能を届ける約束にはならない旨の断り、宿泊について予約の先にあるものとしてホテルの発見・さまざまなレートでの部屋の選択・ロイヤルティ・割引を挙げている旨、段階的な展開先としてインド・アジア太平洋・ラテンアメリカ・その他を挙げている旨。2026年10月16日にブラウザで取得
・UCP 公式サイト「Announcements」（お知らせ）ページを見る ── 宿泊の予約の機能の最初のdraft版が2026年9月25日に取り込まれた旨、各版の日付。2026年10月15日にブラウザで取得し、2026年10月16日にブラウザで再確認
・UCP 公式サイト「Universal Commerce Protocol」トップページページを見る ── 宿泊のdraft仕様が利用可能である旨の現況表示、宿泊の仕様ページへの入口。2026年10月15日にブラウザで取得し、2026年10月16日にブラウザで再確認。本稿では引用しておらず、1本目の出典として併記しています
・UCP 公式サイト「Overview」（2026年8月25日の版の仕様）ページを見る ── 同じ版の仕様全体のページが表示されること。同じ版で宿泊のページが表示されず、目次にも宿泊の項目が出てこないことは、2026年10月16日にブラウザで開いて確かめました
・UCP 公式リポジトリ Discussion「Announcing UCP Lodging: Booking Capability Draft Spec Release!」ページを見る ── 宿泊の予約の機能の最初のdraft版が取り込まれた旨、公開のフィードバックと貢献を受け付けている段階である旨、第三者の投稿（販売の制約が表せないという指摘と制約の欄・エラーコードの提案／付帯内容がレートプランの文章でしか表せないという指摘／独立系の施設の見つけ方についての質問／施設の公的な登録番号を載せる欄についての指摘）。2026年9月25日投稿、最新のコメントは2026年10月14日。2026年10月16日にブラウザで取得
・UCP 公式リポジトリ Discussion「Announcing the new Lodging Tech Council members」ページを見る ── 宿泊の作業体の発足と初期メンバー、空席が今後の選挙で埋まり技術的な貢献が主要な判断材料の1つになる旨。2026年8月11日投稿。2026年10月16日にブラウザで取得。本稿では引用しておらず、1本目の出典として併記しています（名簿と発足の日付は1本目で扱っています）
・Google ブログ「How we’re helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google」ページを見る ── ホテル予約とローカルのフードデリバリーという新しい分野への拡張の予告（原文はこれからの数か月）、UCPを使ったチェックアウトの展開先としてカナダ・オーストラリア、その後に英国を挙げている旨。2026年5月20日付。2026年10月15日にブラウザで取得
書けなかったこと
・この記事が扱う仕様は、すべてdraft段階のものです。欄の構成も語も変わることがあり、仕様ページ自身が互換性を壊す変更が入ることがあると断っています・宿泊の機能がどの日付の版に入る予定なのかについての記述は、今回見たページには見当たりません。本文も、入る時期については書いていません
・日本での提供時期、日本の宿泊事業者が対象になるかについての記述は、今回見たUCP公式サイトの各ページとGoogleの2026年5月20日のブログには見当たりません。仕様に東京のホテルの作例があることは、提供の予告としては扱っていません
・UCP公式サイトのロードマップが段階的な展開先として挙げるのは、インド・アジア太平洋・ラテンアメリカ・その他です。日本を名指しした記述は置かれておらず、アジア太平洋に含まれるかどうかも書かれていないため、本稿では推測していません
・作例の金額は、仕様の説明のための数字です。実際の料金水準を示すものとしては扱っていません。作例の施設名も架空の名前です
・支払いの時期の作例は2つ置かれていますが、頭金と残金に分ける形の作例は、タブの切り替えの先にあるため本文を取得しておらず、本稿では扱っていません
・UCP公式リポジトリの宿泊draft公開の議論（2026年9月25日投稿）に出てくる投稿は、第三者によるものです。提案・質問はいずれも未採択で、仕様の決定ではありません。本稿では、投稿者が自ら述べた立場（宿の運営者、料金管理の実務経験者など）をそのまま紹介しており、第三者による確認は取っていません
・宿泊draft公開の議論（2026年9月25日投稿）で言及されている変更要求や提案の個別の番号については、議論の本文での言及を確認したのみで、各提案の本文は取得していません。そのため本稿では番号を記していません
・宿泊draft公開の議論（2026年9月25日投稿）に対する仕様の担当者からの回答は、2026年10月16日に取得した時点のコメント欄には見当たりません。提案が採択されるかどうか、その時期についての記述もありません
・宿泊draft公開の議論（2026年9月25日投稿）には、イタリアや欧州連合の制度に関する投稿者の記述もありますが、制度そのものの一次情報は取得していないため、本稿では制度の内容を扱っていません。日本の法令についても一次情報を取得していないため、法令が求める内容は書いていません。本稿は法令についての助言ではありません
・宿泊の通信の割り当て（RESTとMCP）の各ページ、および規定の提示の仕組みを定めた節の本文は取得していないため、本稿では扱っていません
・draftという段階そのものを1文で定義したページは、今回の探索では見つけられませんでした。本稿がdraftの位置づけの根拠にしているのは、仕様ページの先頭の断りと、公式サイトの版の切り替えの構成の2つです
・宿泊の作業体の名簿と発足の日付は1本目で扱っているため、本稿では繰り返していません
・フードについては、2026年10月16日時点で仕様が公開されていないため、本稿では扱っていません
引用した原文
原文を開く（14件）
［原文］引用した資料の記載
［1］UCP 公式サイト「Booking Capability」（宿泊の予約のdraft仕様／2026年10月16日にブラウザで取得）、ページ冒頭の断り：「Draft – Work in Progress This capability is in draft status. Implementers are cautioned that data models, protocol bindings, and operational flows are under active iteration and may undergo breaking changes as the specification evolves.」／同ページ：「Capability Name: dev.ucp.lodging.booking」
［2］同draft仕様：「The Lodging Booking capability allows Platforms to facilitate and manage end-to-end lodging reservation sessions with Businesses.」／同draft仕様：「The Business remains the Merchant of Record (MoR) and does not need to become PCI DSS compliant to accept card payments through this capability. Unless the AP2 Mandates extension is supported, the booking must be finalized manually by the user through a trusted UI.」／同draft仕様のプラットフォーム側の決まり：「MUST supply valid property.id, and either a pre-composed stay.id OR both accommodation_type.id and rate_plan.id identifiers sourced from upper-funnel discovery mechanisms when creating a booking session.」
［3］同draft仕様：「Lodging reservations follow strict all-in pricing rules to comply with consumer protection regulations (such as FTC and EU price transparency directives). In lodging, the full financial commitment for a stay is often divided between charges prepaid at the time of reservation confirmation and charges collected directly by the accommodation property upon check-in or check-out (e.g., resort fees, municipal occupancy taxes, or a remaining stay balance).」／同draft仕様：「Price Transparency and All-Inclusive Cost: Platforms and Businesses MUST ensure that the guest is presented with the complete stay liability before booking confirmation. Hidden fees or undisclosed property charges violate price transparency standards.」
［4］同draft仕様：「Pricing Breakdown vs. Payment Timing: In lodging reservations, pricing breakdown and payment timing are decoupled: totals[] defines the pricing breakdown (subtotal, fee, tax, and optional discount). All non-total entries are price addends that sum to total (sum(non-total entries) == total). payment.terms[] (dev.ucp.common.payment.terms) defines the payment timing and schedules for moving funds.」／同draft仕様：「Schedules with type: “immediate” represent payments due upon booking completion. Schedules with type: “deferred” represent payments due at a specified future date or event (e.g., balance due upon check-in or a scheduled deposit date indicated in description or due_at). Schedules with type: “at_property” represent payments collected directly by the accommodation property (e.g., local tourist taxes or mandatory resort fees paid upon arrival/departure).」／同draft仕様：「When mandatory taxes or fees are collected locally by the lodging property and cannot be remitted at booking, the Business SHOULD provide a warning message in messages[] with presentation: “disclosure” and a path pointing directly to the relevant payment schedule (e.g., $.payment.terms[0].schedules[1]). This disclosure notice MUST state the applicable local rates, exemptions, and payment instructions, complemented by formal policy links in links[].」／同draft仕様：「When stay rates, taxes, or mandatory fees fluctuate during an active booking session, the Business returns the updated session with recomputed totals[] and MUST report the modification using a warning message in messages[] with code: “totals_changed” and path: “$.totals”. The Business MUST set presentation: “disclosure” when the revised amount requires prominent Buyer awareness. The Platform MUST present the updated totals and the warning content to the buyer, and MUST NOT auto-dismiss or hide the disclosure.」
［5］同draft仕様の作例の説明：「A 3-night Tokyo hotel stay where base room rates (64,000) and prepaid service fees (6,400) are charged immediately, while mandatory resort fees (6,000) and Tokyo Accommodation Tax (1,200) are collected at the property. In totals[], non-total addends sum strictly to the total stay cost (77,600):」／同作例の表示文：「Room Rate (3 nights for 1 room, includes 10% consumption tax)」「Service Fee (10% prepaid)」「Resort & Facility Amenity Fee (Pay at hotel, ¥2,000/night)」「Tokyo Accommodation Tax (Pay at hotel, ~¥200/guest/night)」「Total Stay Cost」／同作例の警告：「**Tokyo Accommodation Tax Notice**: In accordance with Tokyo Metropolitan Government regulations, a local accommodation tax of JPY 200 per guest per night applies to room rates of JPY 15,000 or higher. This tax is collected directly by the property upon check-in.」／同作例の支払いの明細：「Pay room rate and service fee today; mandatory resort fee and Tokyo Accommodation Tax are paid at check-in.」「Due today when you book (Room rate + service fee).」「Due at check-in on October 1, 2026 (Resort fee + Tokyo Accommodation Tax).」／同作例の施設名：「Ginza Grand Hotel」（作例上の名前）
［6］同draft仕様：「Separation of Booker and Guests: The data model strictly separates the legal purchaser from the physical accommodation occupants: booker: The legal contracting party responsible for payment, contact obligations, and reservation ownership. guests: The individuals who will physically occupy the accommodations. A booker MAY also be listed as a guest in the root pool, but the entities remain decoupled to support corporate, proxy, and multi-stay bookings.」／同draft仕様：「Guest identifiers are opaque strings scoped strictly to the individual booking session (e.g., “gst_01”, “gst_02”). Platforms MUST NOT use persistent cross-merchant user tracking identifiers or expose personally identifiable information (PII) within guest.id. Businesses MUST NOT infer or link identity across distinct booking sessions based on guest.id.」／同draft仕様：「Timing: Platform SHOULD NOT send guests[] identity fields beyond id before the booking reaches ready_for_complete, and SHOULD send only the fields the business requests via messages[].」
［7］同draft仕様の事業者側の決まり：「MUST NOT return a booking session with statuses ready_for_complete, complete_in_progress, or completed without an identified lead – a booker with full legal name and a contact channel, a guest in guests[] with full legal name and a contact channel who is assigned as primary in some stays[].guest_assignments[], or in corporate or proxy bookings, a named primary guest alongside a booker providing the contact channel. Additional identity fields a Business needs (such as passport number, nationality, or date of birth) MUST be negotiated per Business through messages[].」／同draft仕様の宿泊者の欄：「id」「first_name」「last_name」「email」「phone_number」「age」
［8］同draft仕様の事業者側の決まり：「MUST make rate_plan.title distinguish the rate plan and, together with rate_plan.description when present,is sufficient for a Buyer to understand its material commercial terms without having to read into policies[]; both fields MUST NOT contradict policies[].」／同draft仕様のレートプランの欄：「id」（Required）「title」（Required）「description」（Optional）
［9］同draft仕様の標準のエラー：「inventory_exhausted The selected accommodation unit or inventory hold is no longer available」「occupancy_exceeded_capacity Number of assigned guests exceeds physical capacity bounds」「payment_failed Payment processing failed」「eligibility_invalid Eligibility claim could not be verified at completion」／同draft仕様の規定のリンクの欄：「Links to be displayed by the platform (Privacy Policy, TOS). Mandatory for legal compliance.」／同draft仕様の状態：「incomplete」「requires_escalation」「ready_for_complete」「complete_in_progress」「completed」「canceled」
［10］UCP 公式サイト「Cancellation Policy Extension」（キャンセル条件の拡張のdraft仕様／2026年10月16日にブラウザで取得）：「It adds pre-purchase, machine-readable cancellation terms to policies that carry this type, so platforms can answer questions like “Can I cancel this booking?”, “Is it free cancellation or is there a fee?”, and “Is this rate completely non-refundable?” without leaving to parse external policy pages.」／同ページ：「refundable: Free cancellation is currently available. The booker can cancel without penalty before the deadline stated in description. partially_refundable: The booking can be cancelled, but a cancellation fee applies (e.g., a one-night room charge or fixed administrative fee), or the booking is currently inside a partial penalty window. non_refundable: The reservation cannot be refunded upon cancellation (the full booking price is retained by the business, subject to local regulation).」／同ページ：「Because lodging cancellation rules frequently incorporate specific property local cutoff times (e.g., “by 3:00 PM property time 2 days before check-in”) and seasonal rules, businesses MUST articulate the full timeline and terms in description. The description and refundability field MUST NOT contradict each other.」
［11］UCP 公式サイト「Versioning」（版の管理／2026年10月16日にブラウザで取得）：「UCP uses date-based version identifiers in YYYY-MM-DD format」／同ページ：「Breaking PRs Breaking changes should include ! in the PR title Timing: We will announce the breaking change in Discussions 2 weeks before the change is merged. Security-sensitive fixes are the exception: the Governance Council sets the disclosure timeline case by case, so a fix is not announced before it is safe to disclose.」
［12］UCP 公式サイト「Roadmap」（ロードマップ／2026年10月16日にブラウザで取得）：「Note: This roadmap reflects our current direction and intends to guide planning, but it does not constitute a commitment to deliver specific features. Our approach to these challenges may evolve, and initiatives are subject to change, removal, or addition as business priorities shift and we receive community feedback.」／同ページ：「Lodging: New UCP capabilities and schema beyond Booking, supporting hotel discovery, room selection with various rate options, loyalty, and discounts.」／同ページ：「We plan to do this through a phased rollout across markets, including India, Asia Pacific, Latin America, and others.」
［13］Google ブログ「How we’re helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google」（2026年5月20日付／2026年10月15日にブラウザで取得）：「This momentum extends globally — and to new industries. UCP-powered checkout will roll out across Canada and Australia in the coming months, and later to the U.K. We’re also partnering with industry leaders to bring the protocol to entirely new categories, including hotel booking and local food delivery. In the coming months, people will be able to easily book their next hotel right from AI Mode in Search, or order food delivery from a conversation in Google Maps.」
［14］UCP 公式リポジトリ Discussion「Announcing UCP Lodging: Booking Capability Draft Spec Release!」（2026年9月25日投稿／2026年10月16日にブラウザで取得）、公式の発表本文：「It’s now open for public feedback and contributions.」／同議論の第三者の投稿（宿の運営者を名乗る投稿者）：「The booking capability itself looks implementable for a property my size. … My question is about the step before this capability starts. Create Booking Session expects a property.id and a rate_plan.id “discovered from upper-funnel search”, but the draft doesn’t say how a platform finds a property that isn’t in a GDS, a chain CRS or a channel manager’s feed. Is the intent that a self-hosted /.well-known/ucp profile is enough for a platform to discover and index an independent property directly, or does the Lodging Tech Council expect small properties to arrive through a connectivity partner?」／同議論の第三者の投稿（料金管理の実務経験者を名乗る投稿者）：「Without a way to express these restrictions, an agent can only propose a stay and find out on create that the booking is invalid due to restrictions. The current standard errors don’t have a code for “this rate has a 3-night minimum length of stay restriction during your stay”, and would likely return inventory_exhausted, which gives the agent nothing to recover with. … Does stay seem like the right home for this, or would it be better modeled elsewhere?」／同議論の第三者の投稿：「Breakfast and resort credits can only be described in rate plan text today.」／UCP 公式リポジトリ Discussion「Announcing the new Lodging Tech Council members」（2026年8月11日投稿／2026年10月16日にブラウザで取得）：「We encourage all community members to contribute to the protocol, as active technical contribution will serve as one of the primary criteria to fill open seats in future elections for the Lodging TC.」
執筆者
永野 陽平
お問い合わせ
御社の現在地を教えてください。
7つの質問で、御社の顧客がいま資産に変わっているかが分かります。
3分・登録不要。結果を見てからご相談いただけます。