「2泊3日、子連れ、雨の日の代替案も欲しい」。旅行者がPerplexityにこう尋ねたとき、返ってくる答えは、どこか1施設のページではありません。いくつもの情報を束ねた「旅程」として組み立てられます。
つまり、自社のページをどれだけ作り込んでも、その旅程に組み込まれなければ旅行者の目には触れません。ここが、観光業のAI検索対策が他業種と違うところです。
この記事は、Perplexityの公式クローラー仕様と、旅行業法・旅館業法・食品衛生法という事業形態別の表示規制を土台にしました。「AI検索に載りたいけれど、施設ページを直す以外に何をすればいいのか分からない」という方に向けて書いています。
こんなふうに調べていませんか
- 「観光 Perplexity 旅程」で検索して、旅行者のAI相談に載る方法を探している
- 施設ページは作り込んだのに、AIの答えの中に自社が出てこない理由が分からない
- 観光業は関わる法令が多く、どこまで書いてよいのか判断がつかない
この記事を読み終えたときに手に入るもの
- Perplexityの2つのクローラーの違いを、社内に自分の言葉で説明できるようになります
- 旅程を構成する5要素のうち、標準の型で書けるものと書けないものを切り分けられます
- 自社の事業形態に対応する法令が、表示のどこに効いてくるのかが分かります
結論30秒でわかる、この記事の結論
- 観光業界のPerplexity対策とは、施設単体ではなく「旅程の部品」として読み取れる形に情報を整えることです。
- 旅程の材料は、移動時間・営業時間・定休日・予約要否・季節性。この5つが文章の中に埋もれていると、部品として拾われません。
- 事業形態によって、旅行業法・旅館業法・食品衛生法のどれが効くかが変わります。表示義務とAIOは、多くの場面で同じ方向を向いています。
この記事は、観光の案件を持つマーケティング部の3人と、専門家の会話をはさみながら進みます。ご自身に近い立場の人の質問から読んでいただいて構いません。
- 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
- 高梨課長（マーケ課長）— 「誰が、どこまでやるんですか？」を聞く役
- 大森部長（マーケ部長）— 「経営として、どこに投じるんだ」を聞く役
- 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役
01そもそも観光のPerplexity対策は、旅程のAIOとして何をすることなんですか？
若葉さんあの、そもそもなんですが…観光のPerplexity対策って、ほかの業種のAI検索対策と何が違うんでしょうか。
鈴木さんいちばん大きい違いは、答えが「1ページ」ではなく「旅程」の形で返ってくるところですね。だから、自社のページを1枚だけ磨いても届きにくいんです。
AIOはAI検索最適化のことで、LLMOと呼ばれることもあります。呼び方は違っても、目指す先は同じです。AI検索の答えの中で、情報源として選ばれることです。
観光の場合、その答えが旅程の形をしています。旅行者は「何日で、誰と、どんな条件で」と尋ねます。返ってくるのは、立ち寄り先と順番が並んだ行程です。
この行程は、複数の情報源を組み合わせた複合的な成果物です。金融や製造業のAIOは「1つの情報が引用されるかどうか」を扱います。観光の旅程づくりは、複数の情報を1つの成果物に束ねる作業です。ここが構造として違います。
だから観光のPerplexity対策は、「良いページを作る」だけでは足りません。自社の情報が、旅程の部品として取り出せる形になっているか。そこを見にいく取り組みになります。
この章のまとめ
観光のPerplexity対策とは、施設単体ではなく「旅程の部品」として読み取れる形に情報を整える取り組みです。
02PerplexityのAI検索は、観光サイトのどこを見にきているんですか？
高梨課長見にくる仕組みが分かれば、そこに合わせられますよね。どういう経路で来ているんでしょうか。
鈴木さんPerplexityは、役割の違う2種類のクローラーを公式に区別しています。ここは公開されているので、自社でも確認できますよ。
Perplexity公式のクローラー資料によると、次の2種類が使い分けられています（出典: Perplexity公式）。
- PerplexityBot — 検索結果への表示やリンクのために、サイトを巡回します
- Perplexity-User — 旅行者が質問したときに、そのページを訪問します
扱われ方も違います。PerplexityBotは、robots.txtのルールに従います。一方のPerplexity-Userは、robots.txtのルールを一般的に無視すると公式に明記されています（出典: 同）。回答の精度を上げるための「その場での確認」にあたる動きです。
IPレンジは、どちらも公開されています。PerplexityBotはperplexitybot.json、Perplexity-Userはperplexity-user.jsonです（出典: 同）。また、どちらもAI基盤モデルの学習目的では用いないと公式に明記されています（出典: 同）。
この章のまとめ
経路は2つあり、robots.txtで動かせるのは片方だけです。ここは推測ではなく、公式資料で確認できます。
03robots.txtでPerplexityを許可すれば、観光のAI検索対策は足りますか？
若葉さんでは、robots.txtでPerplexityBotを許可すれば、あとは待っていればいいんでしょうか。
鈴木さんそこは、はっきり「いいえ」です。許可はスタートラインであって、ゴールではありません。
robots.txtでPerplexityBotを許可しても、ページの内容そのものが薄ければ、回答には反映されません。技術的な許可設定と、旅程の一部として選ばれる情報設計は、別の問題です。
分けて考えると、こうなります。許可設定は「入口の鍵を開ける作業」です。情報設計は「部屋の中に、持ち出せるものを置く作業」です。鍵を開けても中身が空なら、旅程には並びません。
この記事の後半は、その「持ち出せるもの」の話です。
この章のまとめ
robots.txtは入口の鍵です。鍵を開けただけでは、旅程には並びません。
04Perplexityが示す旅程は、観光のAI検索最適化ではどんな単位ですか？
大森部長旅程が単位だ、というのは分かった。それで、我々は何をどこに置けばいいんだ。
鈴木さん骨格から順に見ていきましょう。「どこを、どの順で、いつ」は、標準の型で書けます。
旅程の束ね方には、schema.orgに専用の型があります。TouristTripのitineraryプロパティは、立ち寄り先をItemListとして表現し、各地点のpositionで訪問順序を示せます（出典: schema.org公式）。tripOriginで出発地、arrivalTime・departureTimeで到着・出発の予定も扱えます。
つまり旅程の骨格は、すでに書ける状態にあります。むずかしいのは、その骨格に差し込む細部のほうです。
旅行会社自身の情報は、TravelAgency型で表現できます（出典: schema.org公式）。LocalBusiness・Organizationを継承するため、openingHoursSpecificationやcontactPointをそのまま使えます。
この章のまとめ
旅程の骨格はTouristTripで書けます。次の章で、そこへ差し込む細部を見ていきます。
05旅程の5要素は、観光のPerplexity対策・AIOとしてどう確認しますか？
高梨課長差し込む細部というのは、具体的に何を指しますか。抜け漏れなく確認したいので。
鈴木さん5つです。移動時間・営業時間・定休日・予約要否・季節性。この5つが読み取れれば、旅程の部品になります。
旅程を構成する5要素と、対応する機械可読化の手法を並べると、次のようになります。
| 要素 | 機械可読化の手法 | 備考 |
|---|---|---|
| 移動時間 | 本文への数値明記（徒歩12分等） | 地点間の移動時間に対応する標準プロパティは確認できていません |
| 営業時間 | OpeningHoursSpecificationのopens／closes | dayOfWeekで曜日ごとに指定します |
| 定休日 | 統一的な表現方法は確認できていません | schema.org自体に休業日の表現規定が無く、確認できていません |
| 予約要否 | acceptsReservations | schema.org上はFoodEstablishment向けで、汎用の観光施設向けではありません |
| 季節性 | validFrom／validThroughによる期間限定の営業時間指定 | specialOpeningHoursSpecificationで祝日等の例外も上書きできます |
この章のまとめ
旅程の細部は5要素です。次の2章で、書ける型があるものと、無いものに分けて扱います。
06移動時間と営業時間は、PerplexityへのAI検索対策としてどう書きますか？
若葉さん5つのうち、今日から手を動かせるのはどれでしょうか。
鈴木さん移動時間と営業時間ですね。この2つは、書く場所が分かれます。片方は本文、もう片方は構造化データです。
移動時間から見ていきます。地点間の移動時間に対応する標準プロパティは、確認できていません。現実的な対応は、本文に数値で書くことです。「最寄り駅から徒歩12分」のように書けば、読者にもそのまま役立ちます。
営業時間には、標準の型があります。OpeningHoursSpecificationのopensとclosesで開店・閉店を示し、dayOfWeekで曜日ごとに指定できます（出典: schema.org公式）。季節だけ変わる営業時間も、validFromとvalidThroughで期間を指定すれば表現できます（出典: 同）。
本文の数値と構造化データは、どちらか一方を選ぶものではありません。両方あって、はじめて旅程の骨格と細部の両方が機械可読になります。移動時間を本文の数値で示す書き方は、別記事『観光業界のChatGPT Search対策｜旅行計画への入り込み方』でも先に解説しています。
この章のまとめ
移動時間は本文へ、営業時間は標準の型へ。書く場所を分けて決めてしまいます。
07定休日と予約要否は、観光のLLMO対策としてどこまで機械可読にできますか？
若葉さん残りの3つも、同じように構造化データで書けるんですか？
鈴木さんここは正直にお伝えします。定休日と予約要否には、汎用的な標準の型が確認できていません。
定休日の統一的な表現方法については、schema.org自体に規定が無く、確認できていません。
予約要否も同じ状況です。acceptsReservationsはFoodEstablishment向けのプロパティで、Boolean・Text・URLの値を取ります（出典: schema.org公式）。飲食店以外の体験・アクティビティ向けの標準プロパティは、確認できていません。本文に「要予約」「予約不要」と明記する運用が現実的です。
季節性は、標準の型で書けます。前の章のvalidFrom・validThroughに加えて、specialOpeningHoursSpecificationで祝日等の例外も上書きできます（出典: 同）。
「標準の型が無いから書かなくていい」ではありません。型が無いところは、本文で読み取れる形にしておく。これがLLMO対策として現実的な落とし所になります。
この章のまとめ
型があるものは型で、無いものは本文で。無いことを理由に省かないのが分かれ目です。
08旅行業法・旅館業法・食品衛生法は、観光のAI対策とどう関わるんですか？
大森部長法令の話が出たな。表示義務を満たすほど、AIに読ませる情報も増えるということか。
鈴木さんそのとおりです。ただ、その前に自社がどの法令の対象なのかを確かめる必要があります。ここを取り違えると、義務そのものを見落とします。
観光業のAI対策を語るときは、まず区別が要ります。どの事業者の話をしているかで、適用される法令が変わるためです。
| 事業形態 | 適用法令 | 許可・登録の主体 | 表示に関わるポイント |
|---|---|---|---|
| 旅行会社・OTA（企画旅行を実施） | 旅行業法 | 観光庁長官または都道府県知事 | 登録番号の表示・広告の必須表示事項・誇大広告の禁止 |
| 宿泊施設 | 旅館業法 | 都道府県知事（保健所設置市は市長・区長） | 営業種別（旅館・ホテル／簡易宿所／下宿）ごとの許可 |
| 飲食提供 | 食品衛生法 | 都道府県等（保健所） | 営業許可・営業届出の区分 |
旅行業法は、報酬を得て旅行業務を事業として営む者に登録を義務づけています（出典: 観光庁公式）。宿泊施設が対象になる旅館業法には、旅館・ホテル営業／簡易宿所営業／下宿営業の区分があります（出典: 観光庁minpakuポータル）。飲食提供には食品衛生法が別途関わり、営業許可または営業届出の対象になります（出典: 厚生労働省公式）。
宿泊・食事提供・旅行手配のどれに該当するかで、根拠法令が変わります。制作に入る前に、ここを確認してください。
この章のまとめ
最初にやることは実装ではありません。自社がどの法令の対象かを確かめることです。
09Perplexityが示す旅程は、企画旅行のAI検索対策とどう違うんですか？
高梨課長AIが旅程を出すのなら、それは企画旅行の広告にあたるのでしょうか。判断がつかなくて。
鈴木さんそこは分けて考えてください。AIが束ねた旅程は、要約であって企画旅行そのものではありません。
まず、企画旅行と手配旅行の違いを押さえます。募集型企画旅行は、旅行会社があらかじめ目的地・日程・料金を定め、旅行者を募集して実施する旅行です（出典: JTB総合研究所）。手配旅行は、旅行者の依頼で運送・宿泊等を手配する契約で、旅程管理の責任範囲が異なります（出典: 同）。
そのうえで、押さえておきたい重なりがあります。義務づけられる表示事項（目的地・日程・提供サービスの内容等）は、AIに引用されやすい具体的な情報でもあります。法令順守とAIOの方向性は、ここで重なります。
この章のまとめ
AIの旅程は要約です。表示義務は自社の広告に生じます。そして、その義務項目こそAIに拾われやすい情報です。
10旅行業の登録番号を書くことは、観光のAI検索最適化にもつながりますか？
高梨課長登録番号は、パンフレットの隅に小さく載せるもの、という印象でした。
鈴木さんそれを、読み取れる場所に出すという話です。正規の事業者である証を、機械にも伝える手段になりますから。
旅行業法の登録区分は、第1種・第2種・第3種・地域限定・旅行業者代理業のほか、観光圏内限定旅行業者代理業・旅行サービス手配業を含む7種類あります。区分ごとに、登録番号の表示書式が決まっています（出典: 観光庁公式）。
- 第1種 — 「観光庁長官登録旅行業第○○○号」
- 第2種・第3種 — 区分番号を挟んだ「○○都道府県知事登録旅行業第2-○○○号」型
- 旅行業者代理業 — 「○○都道府県知事登録旅行業者代理業第○○○号」
登録番号の明記は、消費者保護の観点でも重要です。無登録業者による詐取被害や、日本での登録を持たない海外事業者が保護の対象外になる点は、観光庁の注意喚起ページのとおりです（出典: 観光庁公式）。
登録番号をPropertyValue（propertyIDに「旅行業登録番号」）で示す設計は、正規の事業者である証をAIにも伝える手段になります（出典: schema.org公式）。ただし順番があります。本文に無いものは、構造化データだけ足しても読者には届きません。本文に書いてから、構造化データにも載せてください。
この章のまとめ
登録番号は、規制対応であると同時に信頼の手がかりです。本文が先、構造化データが後です。
11インバウンドの多言語ページは、観光のAI検索対策としてどこまで要りますか？
大森部長多言語は費用がかかる。どこまでやるかの線引きを聞きたい。
鈴木さん全部を訳す必要はありません。主要な言語で、予約導線まで含む最小限のページから始める形が現実的です。
Googleは、多言語サイトに別URL方式（サブディレクトリ・サブドメイン・国別ドメイン）を推奨しています（出典: Google Search Central公式）。Cookieやブラウザ設定だけでの出し分けは推奨していません（出典: 同）。
hreflangは、どの言語・地域版のページを表示すべきかをGoogleに伝えるアノテーションです（出典: 同）。ただしGoogleは、言語判定にページの可視テキストを使い、hreflangなどのコード上の情報だけには依存しないと明記しています。
Perplexityがhreflangをどう扱うかは、公式には確認できていません。それでも、独立URLでの多言語ページ設計はAIO上も理にかなっています。理由は2つです。
- 各言語版に固有の構造化データを持たせられること。営業時間や予約要否を、言語ごとに機械可読に保てます。
- AI翻訳では、予約フォーム等の行動可能な要素までは変わらないこと。日本語ページしかなければ、回答は英訳されても予約導線は日本語のままです。
海外OTAが多言語対応に投じる規模は、別記事『観光業界のAIO動向｜Expedia・Booking.comの対応』で扱っています。まず主要言語（英語・中国語・韓国語等）で、予約導線を含む最小限のページを独立URLで用意する。ここから始める設計が現実的です。
この章のまとめ
翻訳されるのは文章だけです。行動に移すための導線は、自分で用意するしかありません。
12季節・イベント情報が古いままだと、観光のPerplexity・AIOはどうなりますか？
若葉さん桜や紅葉のページって、毎年は書き直していないことが多いんです。あれも影響しますか。
鈴木さんします。どちらのクローラーで来ても、ページが前年のままなら古い情報が取られますからね。
観光情報には、他業種にあまり見られない陳腐化のリスクがあります。桜の開花予想・紅葉の見頃・花火大会の開催日は、毎年内容が変わります。それなのに、ページ自体は前年のまま残りやすい情報です。
PerplexityBotは巡回内容を事前にインデックスし、Perplexity-Userは質問時にページへアクセスします。しかしページ自体が前年の日付のままなら、どちらの経路でも取得される情報は古いままです。
季節性のある情報を機械可読にする方法は、2つあります。
- 花火大会等のイベント日程は、schema.orgのEvent型のstartDate・endDateで明示します（出典: schema.org公式）。周期的な開催は、eventScheduleとrepeatFrequencyの組み合わせでも表現できます（出典: 同）。
- 季節限定の営業時間は、前の章のOpeningHoursSpecification（validFrom・validThrough）で示せます。
構造化データだけでなく、本文中の更新日表記も引き続き有効です。「この情報は◯年◯月時点のものです」という一文は、AIにも読者にも鮮度を判断する手がかりになります。毎年内容が変わるページほど、更新日の明記を運用ルールに組み込んでください。
この章のまとめ
季節情報は、構造化データと本文の時点表記をセットで運用します。
13予約サイトにも載っている情報は、観光のAI検索対策としてどう揃えますか？
高梨課長実は、同じ施設の情報を予約サイト側にも登録しています。あちらは別管理なんです。
鈴木さんそこが盲点になりやすいところです。自社サイトを直しても、予約サイト側は自動では変わりません。
じゃらん・楽天トラベル・Booking.comなどに登録した営業時間や季節料金は、自社サイトの更新に連動しません。片方だけが古いまま残ると、AIがどちらを引用するかによって回答の内容が食い違います。
対策はむずかしくありません。季節情報を更新するときに、自社サイトと各予約サイトの更新をひとつの作業としてまとめておくことです。更新のたびに手順書を見なくて済むよう、掲載先の一覧を作っておくと続きます。
この章のまとめ
更新の単位は「自社のページ」ではなく「掲載しているところ全部」です。
14観光のPerplexity対策・AIOで、やってしまいがちな遠回りは何ですか？
ここまでの内容を、失敗の側から整理しておきます。どれも「よかれと思って」起きるものです。
1. 単一ページの完成度だけを追ってしまう
自社の施設紹介ページをどれだけ作り込んでも、移動時間や営業時間が数字で書かれていなければ、旅程の一部としては選ばれません。ページの美しさと、部品としての取り出しやすさは別の話です。
2. AIO対策を理由に、法定の表示事項を省いてしまう
「シンプルなほうが引用されやすい」という思い込みで登録番号等を削ると、法令違反のリスクを負ったうえ、信頼の手がかりまで減らす結果になります。
3. 多言語対応を「AIが翻訳するから不要」と判断してしまう
回答文自体は翻訳されても、予約導線やお問い合わせ先が日本語のままでは、インバウンドの読者は行動に移せません。
この章のまとめ
遠回りの3つは、どれも善意から起きます。シーズンの節目に、この3つで自社を点検してください。
15よくある質問
PerplexityとChatGPT Searchでは、観光業のAI検索対策は何が違いますか？
クローラーの技術仕様が違います。Perplexityは、PerplexityBotとPerplexity-Userという2区分と、robots.txtへの対応の違いを公式に示しています（出典: Perplexity公式）。一方で、旅程の会話に入り込むための基本設計は、別記事『観光業界のChatGPT Search対策｜旅行計画への入り込み方』と共通する部分が多いとWEBMARKSは考えます。
旅行業登録を持たない個人経営の宿泊施設にも、この記事は関係ありますか？
関係します。旅行業法が対象にするのは旅行会社・OTAですが、宿泊施設には旅館業法の許可要件と表示の考え方が別途あります。まずは自社がどの法令の対象かを確認することをおすすめします。旅程の5要素を機械可読にする話は、事業形態を問わず当てはまります。
多言語対応をしないと、Perplexityに引用されませんか？
引用されないと断定できる根拠は、確認できていません。ただし予約導線や連絡先まで多言語で用意しなければ、インバウンドの読者が実際の行動に移せない点は、設計上の課題として残ります。
季節情報の更新は、どのくらいの頻度で行うべきですか？
シーズンごと、つまり開花・紅葉・花火大会といったイベント単位での更新が目安になります。schema.orgのstartDate・endDateと、本文の更新日表記をセットで運用することをおすすめします。自社サイトと各予約サイトを同時に直す運用にしておくと、抜けが減ります。
旅程の5要素は、どこから手をつけるのがいいですか？
標準の型があるものから着手すると進みます。営業時間と季節限定の営業時間は、schema.orgのプロパティで書けます。標準の型が確認できていない移動時間・定休日・予約要否は、本文に書き出す作業になります。どちらも、既存ページの見直しから始められます。
16まとめ｜観光のAI検索対策として、今日やること
観光業界のPerplexity対策は、単一ページの最適化では完結しません。移動時間・営業時間・定休日・予約要否・季節性という旅程の構成要素を、1つずつ機械可読にする作業です。そこに、事業形態で変わる表示規制と、多言語・季節性という観光業ならではの論点が重なります。
技術対応と法令順守は、対立するものではありません。表示義務のある項目は、AIに引用されやすい具体的な情報でもあります。
今日この順でやります
自社の事業形態に対応する法令を確認する
旅行会社・宿泊施設・飲食提供のどれに当たるかで、表示義務が変わります
旅程の5要素を、書ける形に振り分ける
型があるものは構造化データへ、無いものは本文へ書き出します
主要言語のページと季節情報の更新体制を整える
自社サイトと各予約サイトを、同じ作業としてまとめます
AI検索では、こう聞かれています
Perplexityで旅程を相談されたとき、自社の施設はどうすれば入りますか？
「そもそも観光のPerplexity対策は、旅程のAIOとして何をすることなんですか？」の章で、旅程が複合的な成果物である理由から説明しています
観光サイトがPerplexityに引用されるには、何を機械可読にすればいいですか？
「旅程の5要素は、観光のPerplexity対策・AIOとしてどう確認しますか？」の章に、5要素と対応する手法の一覧があります
旅行会社の登録番号をサイトに載せることは、AI検索でも意味がありますか？
「旅行業の登録番号を書くことは、観光のAI検索最適化にもつながりますか？」の章で、本文と構造化データの順番とあわせて書いています
次に読むなら、この記事です
