Google旅行広告の仕様とフォーマット要件を徹底解説

表示される場所｜Google検索とGoogleマップ

旅行広告が表示される主な場所は、Google検索とGoogleマップです。ユーザーが「京都　観光」「沖縄　民泊」「新宿　ホテル」のように、特定の都市・目的地・宿泊に関心を示す行動をとったとき、その文脈に合わせて、料金や空き状況を含む構造化されたカードとして表示されます。テキストの広告文を読ませるというより、「今いくらで、予約できるか」という具体的な在庫情報そのものを見せるのが旅行広告の見せ方です。

これは、検討が進んだユーザーにとって極めて自然な体験です。旅行者は「どこに行こうか」だけでなく「いくらで、空いているか、予約できるか」を知りたい。旅行広告は、その問いに在庫データで直接答えるため、予約という最終アクションに近い場所で機能します。

3フォーマットの守備範囲

3つのフォーマットは、扱う「在庫の種類」で住み分けます。ざっくり言えば、「やること（アクティビティ）」を扱うのがおすすめスポット広告、「泊まるところ」を扱うのが民泊広告とホテル広告です。宿泊側がさらに「ホテル」と「ホテル以外（民泊・貸別荘）」で分かれている、という構造です。

このあとの章で1つずつ掘り下げますが、まず押さえておきたいのは、どれも「在庫データを連携して自動的に表示する」点で共通しているということ。だからこそ次章で、この共通の本質——「フィード連携型」とは何か——を先に腹落ちさせておきます。ここが理解できれば、3フォーマットの仕様はすべて同じ枠組みで読み解けるようになります。

「フィード連携型」とは何をする広告か

フィード連携型とは、ざっくり言えば「商品（在庫）データの台帳をGoogleに渡しておけば、Googleが文脈に合う在庫を選んで自動表示してくれる」仕組みです。考え方は、ECのGoogleショッピング広告（商品フィードを連携し、検索意図に合う商品を自動表示する）に近いと言えます。旅行広告では、その「商品」が、アクティビティの空き枠であり、宿泊施設の料金・空室なのです。

つまり、運用者の仕事は「キーワードを当てる」ことから、「在庫データを正確・最新・規定どおりに保つ」ことへと、重心が移ります。料金が古い、空室情報がズレている、必須項目が欠けている——こうしたデータの不備が、そのまま表示機会の損失や非承認につながります。旅行広告の運用は、広告運用というより「在庫データ運用」の色彩が濃いのです。

検索広告との発想の違いを対比する

この対比表が腹に落ちれば、旅行広告の8割は理解できたと言っても過言ではありません。「キーワードがない」のではなく、「キーワードの代わりに在庫データが主役」なのです。ショッピング広告のフィード設計に通じた事業者なら、その経験はかなり活きます（参考：Googleショッピング広告の仕様とフィード要件）。

どこに、誰に表示されるか

Google公式の説明によれば、おすすめスポット広告はGoogle検索やGoogleマップで、特定の都市・目的地に関心を示すユーザーに表示されます。たとえば「京都　観光」「ローマ　観光　チケット」「ハワイ　アクティビティ」のように、ある目的地で「何をしようか」を探している文脈に対して、関連するツアーや体験、入場チケットの在庫が表示される、というイメージです。

ここで重要なのが、公式が明言しているとおり「キャンペーンの広告やターゲットキーワードの作成が不要」という点です。運用者がキーワードや広告文を1つずつ作る必要はなく、連携したアクティビティのフィード（在庫）をもとに、Googleが文脈に合うものを自動的に選んで表示します。第2章の「フィード連携型」が、まさにここに当てはまります。

在庫＝アクティビティのフィードとは

おすすめスポット広告の在庫は、アクティビティのフィードです。フィードには一般に、アクティビティの名称・説明、提供場所（目的地）、価格、予約可能な日程・空き枠、予約導線（ランディング先）といった情報が含まれます。Googleはこのフィードを読み取り、ユーザーの関心に合う在庫を表示し、予約サイトへ送客します。

ただし、フィードに含めるべき項目の正確な定義・データ形式・必須/任意の区分・上限といった技術仕様は、公式ヘルプではなくデベロッパー向けドキュメントに定義されています。具体的には developers.google.com/travel/things-to-do/ 配下のドキュメントです。項目の細部は更新されることがあるため、実装時は必ず最新のデベロッパー仕様を確認してください（本記事では未公開・流動的な項目数や桁数を断定しません）。

掲載に必要な前提

おすすめスポット広告を表示するには、いくつかの前提が必要です。代表的なものを整理します。

• アクティビティのフィード提供：自社の在庫（ツアー・体験・チケット）を、規定の形式でGoogleに連携できること。多くの場合、Googleパートナーやアグリゲーター（在庫を束ねる中間事業者）経由での連携が前提になります。
• フィード要件の充足：必須項目が揃い、価格・空き枠・予約導線などのデータが正確で最新であること。
• コンテンツ／広告ポリシーの遵守：表示される情報やランディング先が、Googleの旅行関連ポリシー・広告ポリシーを満たしていること。

逆に言えば、「キーワードを設定すれば出せる」ものではなく、「在庫を規定どおり連携し、要件・ポリシーを満たす」ことが出稿の条件です。アクティビティ事業者にとっては、まず自社（または利用するアグリゲーター/予約システム）がGoogleへの在庫連携に対応しているかが、出発点になります。

仕組み｜在庫はHotel APIで管理する

民泊広告の在庫（料金・空室）は、Hotel APIを通じて管理・連携されます。Hotel APIは、宿泊施設の料金（レート）と空室（アベイラビリティ）といった、頻繁に変動するデータをGoogleへ提供するための仕組みです。ユーザーが日程を指定して宿泊施設を探すと、その日程に対する「今いくらで、空いているか」が、APIで連携された在庫に基づいて表示されます。

ここがホテル/民泊広告の難所であり、同時に強みでもあります。料金や空室は秒単位で変わる動的データです。これを正しく表示し続けるには、固定的な「フィードファイルを定期アップロード」する以上に、API経由で鮮度の高い在庫を継続的に供給する体制が要ります。民泊広告は、まさにそのための仕組みなのです。

民泊（バケーションレンタル）特有のデータ要件

民泊・貸別荘は、ホテルとはデータの性質が少し異なります。一棟まるごとの貸切である、最低宿泊日数の設定がある、清掃料などの追加料金が発生する、施設の説明や写真・設備（アメニティ）情報が成果に直結する——といった特徴があります。こうしたバケーションレンタル固有のデータ項目・要件は、Googleのデベロッパー向けドキュメント、具体的には developers.google.com/hotels/vacation-rentals/ 等の宿泊系ドキュメントに定義されています。

必須項目・データ形式・料金や追加費用の表現方法・最低宿泊日数の扱いといった細部は、ドキュメントに従って実装する必要があり、ここでも正確な数値・項目は最新のデベロッパー仕様で確認するのが原則です（本記事では未公開の項目仕様を断定しません）。

掲載に必要な前提

• Hotel APIによる在庫連携：料金・空室を、規定どおりAPIで継続的に提供できる体制（自社実装、またはPMS/チャネルマネージャー/連携パートナー経由）。
• 施設情報・コンテンツの整備：施設名、所在地、写真、設備、料金体系、ポリシー（チェックイン/アウト、キャンセル等）が正確に揃っていること。
• ポリシー・要件の遵守：表示価格の正確性（実際に予約できる価格と一致していること）など、Googleの宿泊系ポリシーを満たすこと。

民泊広告は、単体の小規模事業者が直接Hotel APIを実装するのはハードルが高い場合が多く、実務上はバケーションレンタル系プラットフォームや連携パートナー経由で在庫を流すケースが一般的です。「自社で直接連携するか、パートナーに乗るか」の判断が、最初の分かれ道になります。

料金カードという見せ方

ユーザーがホテル名や「エリア＋ホテル」を検索すると、検索結果やマップに、複数の料金（自社サイト価格、各OTAの価格など）が並ぶ料金カードが表示されることがあります。ホテル広告は、その料金表示の枠に、自社（または代理する事業者）の料金・予約導線を載せるフォーマットです。ユーザーは料金を比較し、そのまま予約サイトへ進めます。

つまりホテル広告は、「比較検討の真っ只中にいる、予約直前のユーザー」に対して、自社の料金で勝負する面です。ここで表示される価格は、実際に予約できる価格と一致している必要があり（価格の正確性は宿泊系ポリシーの核です）、料金・空室の鮮度がそのまま機会損失や信頼に直結します。

在庫データ（料金・空室）の要件

ホテル広告で連携する中心データは、シンプルに言えば「いつ・いくらで・空いているか」です。Hotel API経由で、日付別の料金（レートプラン、税・手数料の扱いを含む）と空室状況を提供します。これらは動的に変動するため、更新の鮮度・整合性が要件の中心になります。価格が古い、表示価格と決済価格がズレる、といった事態はポリシー違反や表示停止のリスクになります。

料金の構成要素（基本料金・税・手数料・通貨）、レートプランの種類、キャンセルポリシーの表現、対象とする宿泊施設の識別（マッチング）といった具体仕様は、宿泊系のデベロッパー向けドキュメント（developers.google.com/hotels/ 配下）に定義されています。ここでも正確な項目・形式・上限は最新の公式/デベロッパー仕様を確認するのが鉄則です。

誰が連携するのか

ホテル広告の在庫連携は、ホテル単体が直接APIを実装するケースもありますが、実務ではOTA、ホテルチェーン本部、コネクティビティパートナー（チャネルマネージャー等）が連携の担い手になることが多いです。個々のホテルは、自社が利用するチャネルマネージャーや予約エンジンがGoogleのHotel連携に対応しているか、という形で関わるのが一般的です。

前提①：フィード／APIの要件を満たすこと

旅行広告で表示されるには、まず在庫データが規定の要件を満たしている必要があります。アクティビティならフィード、宿泊ならHotel API。いずれも、必須項目が揃い、データ形式が正しく、価格・空室・空き枠が正確で最新であることが求められます。データの不備は、表示機会の損失や、項目の非承認に直結します。

ここは「一度作って終わり」ではありません。料金や空室は変動し続けるため、継続的なデータ運用（鮮度の維持・整合性の監視）が前提です。旅行広告の運用が「在庫データ運用」だと述べたのは、この継続性の重さゆえです。

前提②：コンテンツ・広告ポリシーを満たすこと

表示される在庫情報・ランディング先・価格表示は、Googleの広告ポリシーおよび旅行/宿泊関連のポリシーを満たす必要があります。とりわけ宿泊では「表示価格と実際に予約できる価格の一致（価格の正確性）」が重視されます。安く見せて実際は高い、税・手数料を隠す、といった表示はユーザー体験を損なうため、ポリシー違反として扱われます。

アクティビティでも、提供内容・価格・予約条件が正確であること、誤解を招く表現がないことが求められます。旅行は高単価かつ「失敗できない」買い物が多いため、Googleは情報の正確性に厳しい、と理解しておくとよいでしょう。

前提③：パートナー／アグリゲーター連携

実務上、最も見落とされがちな前提がこれです。多くの事業者は、Googleへ在庫を直接連携するのではなく、Googleのパートナーやアグリゲーター（在庫を束ねて連携する中間事業者）、あるいは自社が利用する予約システム/チャネルマネージャー/PMS経由で在庫を流します。

• アクティビティ事業者：利用している予約システムやアグリゲーターが、Googleのアクティビティ（Things to do）連携に対応しているか。
• ホテル：利用しているチャネルマネージャー/予約エンジンが、GoogleのHotel連携に対応しているか。
• 民泊：掲載しているバケーションレンタル系プラットフォームが、Googleへ在庫を連携しているか。

つまり、旅行広告に「出せるかどうか」は、自社の在庫が、どの経路でGoogleに届くのかという連携の地図で決まります。まずこの地図を描くことが、旅行広告活用の第一歩です。

カスタマージャーニー上の位置づけ

旅行者の検討プロセスは、ざっくり「行き先を考える → 比較・検討する → 宿/体験を予約する」と進みます。各フォーマットは、この流れの中で得意な位置が違います。

旅行広告は「比較〜予約直前」という、最も成果に近い面で在庫を見せるのが強みです。しかし、その手前の「そもそも検討に入ってもらう」「指名で取りこぼさない」「全面で機会を拾う」といった役割は、検索広告・P-MAX・ディスプレイ/動画が担います。旅行広告だけでは、検討の入口やブランド指名、横断的な刈り取りはカバーしきれないのです。

併用設計の考え方

観光・宿泊・アクティビティ事業者の現実的な構成は、おおむね次のようになります。

• 旅行広告：在庫（料金・空室・空き枠）を整え、比較〜予約直前の最重要面を押さえる。
• 検索広告：指名キーワード（自社名・施設名）で取りこぼしを防ぎ、一般キーワードで検討層を受ける。
• P-MAX：Google全面を横断して、認知から刈り取りまでを機械学習で拡張する（参考：P-MAXの仕様と設計）。
• ディスプレイ/動画：まだ目的地が決まっていない層に、体験の魅力を見せて検討の入口を作る。

大切なのは、「旅行広告は刈り取りに強いが、需要そのものを作る面ではない」と理解することです。需要を作る面（認知・興味）と、需要を刈り取る面（旅行広告・指名検索）を、ジャーニー全体で組み合わせる。これが、旅行系の広告設計の基本形です。広告の各フォーマットの仕様横断は、Google広告フォーマット仕様の総合ガイドや検索キャンペーンの仕様もあわせてご覧ください。

意義①：予約直前の「いま買いたい人」に在庫を直接見せられる

旅行広告の最大の価値は、検討が進み、価格と空きを確認して予約しようとしているユーザーに、自社の在庫をそのまま提示できることです。テキスト広告で「素敵な宿です」と語るよりも、「この日程、この価格、空室あり、ここから予約」と在庫で示すほうが、予約直前のユーザーには圧倒的に強い。最も成果に近い瞬間を、在庫データで押さえられるのです。

意義②：OTA依存からの脱却・自社予約の比率向上

多くの宿泊・アクティビティ事業者は、OTA（予約サイト）への手数料負担に悩んでいます。ホテル広告などを通じて自社サイトの料金・予約導線を直接表示できれば、比較検討の場で自社予約に誘導しやすくなり、手数料構造の改善につながる可能性があります。「OTAの料金カードの中で、自社価格でも勝負する」という選択肢が持てるのは、大きな意義です。

意義③：在庫の鮮度がそのまま競争力になる

旅行広告は在庫データが主役なので、料金・空室・空き枠を正確かつ最新に保てる事業者が、構造的に有利になります。逆に言えば、これまで「広告クリエイティブの巧拙」で差がついていた世界に、「在庫データ運用の精度」という新しい競争軸が加わるということ。データ運用に強い事業者にとっては、むしろチャンスです。

意義④：ペルソナ起点の設計で、媒体を横断して効かせる

ここで私たち「でもやるんだよ」（零株式会社）の視点を少しだけ。私たちは、コトラーのマーケティング理論に基づき、ペルソナごとに集客を設計することを徹底しています。旅行広告は在庫提示に強い反面、「どのペルソナの、どの旅の文脈に効かせるか」という戦略は、媒体だけでは決まりません。

たとえば「結婚記念日の特別な旅を探す夫婦」と「弾丸でアクティビティを詰め込む若者グループ」では、響く宿も体験も、見せ方も違う。旅行広告で在庫を見せつつ、その手前のディスプレイ/動画・検索広告をペルソナ単位で設計し、ジャーニー全体で一貫させる——この設計があってこそ、旅行広告の「刈り取り力」が最大化されます。在庫連携という"仕様"と、ペルソナ設計という"戦略"を両輪で回すこと。それが、旅行系マーケティングで成果を分ける分岐点だと、私たちは考えています。

二層構造：ヘルプ（概要）とデベロッパードキュメント（詳細仕様）

Google公式の旅行広告に関する情報は、おおむね次のように分かれています。

• ヘルプセンター（support.google.com）：「何ができる広告か」「どういう仕組みか」という概要が中心。事業者・運用者向けの説明で、数値仕様は薄め。まずは全体像をつかむのに使います。（例：おすすめスポット広告に関するヘルプ）
• デベロッパードキュメント（developers.google.com）：フィードの項目定義、データ形式、API仕様、必須/任意、制約・上限といった技術仕様が定義される。実装・連携の一次情報はこちら。

つまり、「うちのアクティビティのフィードに、最低何の項目が要るのか」「料金や空室はどんな形式で渡すのか」といった具体的な数値・項目は、ヘルプではなくデベロッパードキュメントを見るのが正解です。ヘルプで全体像を、デベロッパードキュメントで詳細を——という二段構えで読み解きます。

フォーマット別の参照先

確認するときの3つの注意

• 仕様は更新される：項目・形式・上限は変わることがあります。実装前・更新前には、必ず最新版のデベロッパードキュメントを確認してください。本記事の項目・数値に関する記述も、流動的なものは断定していません。
• 連携経路を先に確認：自社が直接連携するのか、パートナー/アグリゲーター/チャネルマネージャー経由かで、見るべきドキュメントも手順も変わります。まず「在庫がどう届くか」を確定させましょう。
• ポリシーも一次情報で：価格の正確性などのポリシーは、広告ポリシー・宿泊系ポリシーの一次情報で最新を確認します。ポリシー違反は表示停止に直結します。

Q. おすすめスポット広告は、キーワードや広告文を作らなくていいって本当？

本当です。Google公式も、おすすめスポット広告は「キャンペーンの広告やターゲットキーワードの作成が不要」で、在庫（アクティビティ）のフィードと連携して自動表示される、と説明しています。運用者の仕事は、キーワードを当てることではなく、アクティビティの在庫データ（名称・価格・空き枠・予約導線など）を、規定どおり正確・最新に保つことです。

Q. 民泊広告とホテル広告は、結局どこが違うの？

仕組み（Hotel APIで料金・空室を連携し、検索・マップに表示する）は共通で、扱う宿泊の種類とデータの性質が違います。ホテル広告はホテル・旅館などを対象に、レートプランや客室タイプ、税・手数料といったデータを扱います。民泊広告（バケーションレンタル）は民泊・貸別荘などを対象に、最低宿泊日数や清掃料、一棟単位の在庫といった特有の項目を扱います。詳細仕様は、それぞれ developers.google.com/hotels/ 配下と developers.google.com/hotels/vacation-rentals/ 等を参照します。

Q. 小さな宿やツアー会社でも、旅行広告は出せますか？

直接Hotel APIやフィードを実装するのは小規模事業者にはハードルが高いですが、実務上は連携パートナー経由で出せることが多いです。ホテルなら利用中のチャネルマネージャー/予約エンジン、アクティビティなら予約システム/アグリゲーター、民泊なら掲載しているバケーションレンタル系プラットフォームが、Googleへの在庫連携に対応しているかをまず確認しましょう。「自社の在庫がどの経路でGoogleに届くか」が出発点です。

Q. フィードの項目数や価格の形式など、細かい数値仕様はどこで確認すべき？

公式ヘルプは概要中心のため、細かな技術仕様はデベロッパー向けドキュメントで確認します。アクティビティは developers.google.com/travel/things-to-do/、宿泊（ホテル・民泊）は developers.google.com/hotels/ 配下です。仕様は更新されるので、実装・更新のたびに最新版を確認してください。本記事でも、公式未公開・流動的な数値は断定せず、参照先を示す形にしています。

Q. 旅行広告だけで集客は完結しますか？検索広告やP-MAXも要りますか？

旅行広告は「比較〜予約直前」の刈り取りに非常に強いですが、それだけで集客は完結しません。指名キーワードの取りこぼし防止には検索広告、横断的な拡張・刈り取りにはP-MAX、そもそも検討に入ってもらう需要創出にはディスプレイ/動画が必要です。観光・宿泊・アクティビティでは、旅行広告で在庫を見せつつ、他フォーマットでジャーニー全体を面で押さえる併用が定石です。

Q. 自社だけで正しく設計・運用できるか不安です。

旅行広告は「在庫データ連携という技術要件」と「ペルソナ起点のジャーニー設計という戦略」の両方が要る領域で、どちらも経験がものを言います。判断に迷う場合は、私たちのような運用代理店に一度ご相談ください。でもやるんだよでは、コトラー理論に基づくペルソナ設計から、媒体横断の集客設計まで、無料でご相談を承っています。