GoogleのAI予約とは？空席探しから予約成立まで

GoogleのAIによる予約支援は、複数の予約サイトを行き来せず、希望の日時・人数に合う空席を探せる機能です。カナダのAI Modeでは、候補とともに提携先で予約を仕上げるリンクを案内します。利用者の店探しを助け、店舗にとっては来店条件の合う人を予約先へ迎える接点になります。[1]

ただし、空席が見つかることと、予約が成立することは別です。 日本でサイトや外部予約サービスを管理する担当者は、「どこで予約手続きを行い、店はどこで成立結果を受け取るのか」を押さえると、自店が整える情報と予約サービス側の仕事を分けられます。

1. まず二つの経路を分ける

カナダ向けに発表されたAI Modeは、複数の予約サービスや飲食店サイトを調べ、条件に合うリアルタイムの空席を探します。利用者は候補から選び、OpenTableやLibroなどの提携先で予約を仕上げる流れです。[1]

一方、Actions Centerには、Google検索やマップ上で飲食店を直接予約できる「Reservations End-to-End」という連携があります。こちらは、Googleと予約を扱う連携事業者のシステムをつなぐ仕組みです。[3]

経路	利用者が行うこと	予約を仕上げる場所
カナダのAI Mode	希望を伝え、空席候補から予約先へ進む	提携先の予約サービスなど
Reservations End-to-End	Google検索・マップ上で予約する	Google上の予約経路。連携事業者の予約システムと接続

二つの経路では、予約を仕上げる場所が異なります。ただし、連携を担う事業者まで必ず別という意味ではありません。

店舗が外部予約サービスを使っているなら、自店で新しいシステムを作る前に、そのサービスのGoogle連携がどちらの経路を指すのかを見極めることが先です。「Google対応」という名称だけでは、空席検索からの案内なのか、Google上での直接予約なのかは分かりません。

2. 4人席の予約を最後まで追う

ここからは説明用に、「寿司店Aを2026年9月11日（金）18時・日本時間、4人で予約したい」という希望を追います。実在する店舗や日本での機能提供を示す例ではなく、日時・人数を変えずに各段階の役割を見るための設定です。

空席を探す

利用者は、場所、料理、日時、人数などの希望を伝えます。AIによる空席検索では、それらの条件に合う候補と予約先へのリンクが示されます。[1]

この段階で分かるのは、寿司店Aに希望に合う空席候補があるということです。利用者が複数のサイトで「金曜18時・4人」を入力し直す手間を減らせますが、まだ店に受け入れる予約が作られたわけではありません。

予約先で条件を確かめる

利用者は候補を選び、予約先で「寿司店A・9月11日18時・4人」になっているかを確かめます。一般的な予約時の確認として、提示された料金やキャンセル条件も読み、必要な情報を入力して手続きを進めます。

日時や人数が違っていれば、元の希望に合う条件に戻して判断します。たとえば4人席を選べず3人に変更したなら、それは最初の希望とは別の予約です。

手続き後の成立結果を受け取る

予約手続きを終えたら、予約先の成立表示や通知で、店舗・日時・人数を確かめます。空席の表示やリンクのクリックではなく、予約先が返す成立結果が区切りになります。

店側でも、受け付けた予約が「寿司店A・9月11日18時・4人」として予約管理に反映されていることが重要です。次の節では、この区切りを理解するため、別経路であるActions Centerの公開APIで空席確認と予約作成を見ます。

3. APIでは何が違うのか

ここで扱うのは、Actions Centerの連携事業者向けAPIです。AI Mode内部の通信仕様ではありません。 Googleが連携事業者の予約サーバーへ要求を送り、事業者が空席や予約作成の結果を返します。[5][6][7]

非エンジニアの店舗担当者にとっては、項目を暗記するより「空席を答える処理」と「予約を作る処理」が別である点が大切です。以下は公式の項目を使った説明用の抜粋で、完成した送信データではありません。

空席確認は「今、予約できるか」

BatchAvailabilityLookupでは、Googleから問い合わせを受けた連携事業者の予約サーバーが、指定された枠が現在有効で、空いているかを確認します。店舗を示すmerchant_idと、確認したい枠の配列slot_timeを受け取り、各枠の空き状況を返します。[6]

項目	寿司店Aの例での意味
merchant_id	寿司店Aを識別するID。説明用にexample-sushi-aとする
slot_time[].service_id	予約対象のサービスID。説明用にexample-dinnerとする
slot_time[].start_sec	9月11日18時・日本時間に対応するUnix時刻（秒）
slot_time[].duration_sec	予約枠の長さ。例では7,200秒、つまり2時間とする
slot_time[].resource_ids	人数など、その枠を指定するためのリソース情報
slot_time_availability[].available	問い合わせた枠が空いているかを返す真偽値

人数4人という条件も、枠を特定する情報として扱います。空席確認側はresource_ids、後述の予約作成サンプル側はresourcesという項目名なので、二つのデータをそのまま同じ形として扱わないことがポイントです。[4][6]

結果がavailable: trueなら、その問い合わせ時点で指定枠が空いているという回答です。これは予約を保存した結果ではなく、予約作成までに空席がなくなれば、後の処理は失敗することがあります。[5][6]

予約作成は「この条件で予約を作る」

利用者が予約を開始すると、Googleから連携事業者の予約サーバーへCreateBookingの要求が送られます。公式定義では、予約する枠slot、利用者情報user_information、要求を識別するidempotency_tokenが必須です。[4][5]

同じ寿司店A・日時・4人を指定する枠部分は、次のように表せます。1789117200は、例の2026年9月11日18時・日本時間をUnix秒で表した値です。

{
  "slot": {
    "merchant_id": "example-sushi-a",
    "service_id": "example-dinner",
    "start_sec": "1789117200",
    "duration_sec": "7200",
    "resources": { "party_size": 4 },
    "confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
  }
}

party_sizeが人数4人、confirmation_modeが同期で確認する予約であることを表します。この抜粋は枠部分だけであり、利用者情報や要求識別用のトークンは省略しています。[4]

Googleから送られる利用者情報には、氏名、電話番号、メールアドレスが含まれます。連携事業者はその情報と予約枠を受け取り、自社の予約システムで作成した結果を返す役割です。[5]

同期成功は予約IDと状態で見る

公式の同期成功サンプルでは、応答のbookingに、作成された予約のbooking_idとstatus: "CONFIRMED"が含まれます。同じ店舗・日時・人数の枠情報も返されるので、要求した予約と結果を対応させられます。[4]

{
  "booking": {
    "booking_id": "example-booking-001",
    "status": "CONFIRMED",
    "slot": {
      "merchant_id": "example-sushi-a",
      "service_id": "example-dinner",
      "start_sec": "1789117200",
      "duration_sec": "7200",
      "resources": { "party_size": 4 },
      "confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
    }
  }
}

この予約IDは説明用の値で、実際の成立記録ではありません。成功時のIDは、後の予約照会や更新で対象を識別するために使われます。[5]

失敗した場合は、booking_failureに空席がなくなったなどの業務上の理由を返します。業務上の失敗はHTTPの非200エラーではなく応答本文に入れる仕様なので、通信が成功したことだけで予約成立とは判断できません。[4][5]

また、通信の再試行で同じ予約を二重に作らないため、idempotency_tokenが使われます。同じトークンですでに予約が作成されていれば、その予約を返す仕組みです。[4][5]

ここまでの例は同期成功に限定しています。予約成立と支払いも別で、公式サンプルにはCONFIRMEDとPREPAYMENT_NOT_PROVIDEDが併記されており、成立状態だけで事前支払い済みとは判断できません。[4]

4. 提供地域と参加条件

機能の対象地域は、発表ごとに読み分けます。2026年9月10日時点の参照資料では、カナダでの提供開始と、米国向けの展開予定がそれぞれ示されています。

資料	発表・記載内容	読み取れる対象
2026年4月10日のカナダ向け記事	AI Modeによる飲食店の空席検索と予約先への案内を当日から提供	カナダの利用者向け[1]
2026年5月19日の検索発表	地域の体験・サービスにも予約支援を拡大し、価格・空き状況・予約先リンクを提示	発表時点では米国で同年夏に展開予定[2]
Reservations End-to-Endの概要	検索・マップ上の直接予約と連携の参加条件	条件を満たす連携事業者と対応店舗[3]

5月の発表では、一部業種でGoogleに事業者への電話を頼める機能も説明しています。同じ記事に世界向けの検索機能が載っていても、それを予約支援の全世界提供の根拠にはできません。[2]

Actions Centerの参加条件には、連携事業者が対象店舗すべてと直接の契約関係を持つこと、店舗データがGoogleマップの場所と対応すること、サービスが所定の定義に沿って予約可能であることがあります。店名や住所を掲載するだけで満たせる条件ではありません。[3]

参加の経路は、技術的な実装能力を確認したうえで、Partner interest formまたはGoogleの担当者を通じて進める形です。Actions Centerで連携を管理する段階は開始の招待後であり、個々の店がフォームを送れば直ちに使えるという案内ではありません。[3]

5. 店が整える三つの対象

店舗担当者がまず整理したいのは、自店で編集できる情報と、予約サービスが管理する仕組みです。寿司店Aの例なら、店の説明、4人を受け付ける枠、成立後の予約記録を、それぞれ誰が管理するかを明確にします。

管理する対象	店舗側で押さえること	予約サービス側に関係すること
店舗情報	店名・所在地・料理などを実態に合わせる	Google上の店舗情報との対応
予約できる枠	受付日時、人数、所要時間を実際の運用と合わせる	空席データと予約作成時の在庫の整合
成立した予約	どの管理先に予約が入り、店がどう受け入れるかを把握する	予約ID・状態の保存、失敗や再試行への対応

とくに空席の更新は、集客情報の更新とは別の運用です。公式資料でも、空席確認が実際の在庫を正確に反映せず、予約作成時の空席エラーが多い場合は、連携が無効になる可能性を示しています。[5]

外部予約サービスを使う店なら、まず自店の受付条件と、そのサービスから入る予約の確認先を整理できます。APIや認証の実装は連携事業者の領域であり、店舗の掲載担当者全員が自前で開発する必要があるという話ではありません。

自社で予約システムを運営する場合には、空席を返すだけでなく、予約作成、失敗処理、二重作成の防止までが検討対象になります。公式の予約サーバー実装資料には、HTTPS、HTTP Basic認証、サンドボックスでの試験、Node.js・Javaのひな型への案内があります。[7]

6. 判断の前に確認する範囲

日本の店は、まず契約中の予約サービスがどの経路に対応し、成立した予約が既存の管理先に入るのかを見ると、検討対象を絞れます。店の情報や受付条件を整える作業と、Googleとの技術連携を進める作業を分けることが出発点です。

参照した公式資料だけでは、日本での同じAI予約支援の提供・掲載条件、米国向け機能の展開完了、AI ModeとActions Centerの技術的な接続関係は確定できません。個別の予約先での条件の引き継ぎや確認画面も、利用するサービスごとに確認する範囲です。

本稿は2026年9月10日時点の資料に基づく基礎解説です。API例は公開仕様の一部を説明用に置き換えたもので、実際の予約・決済や管理画面の操作を再現したものではありません。