「渋谷 個室 4人 予算5000円くらいの店」。ChatGPT Searchでお店を探す人は、条件をいくつも並べて相談します。
そのとき、自店のメニューや座席の情報が、自社サイト・食べログ・ぐるなび・Googleビジネスプロフィールの4か所に分かれたままだと、条件のそろった答えは返しにくくなります。どれだけ丁寧に書いてあっても、です。
この記事は、その分散した情報をどこから整えるのかを、schema.orgの構造化データと、飲食業に固有の表示ルールを土台にして解説します。「グルメサイトには登録した。それ以外に何をすればいいのか分からない」という飲食店のWeb担当者・経営者の方に向けて書きました。
こんなふうに調べていませんか
- 「飲食店 ChatGPT Search メニュー」で検索して、AIに拾われる載せ方を探している
- グルメサイトには登録したのに、AIの答えに自店が出てこない理由が分からない
- アレルギー対応をどこまで書いてよいのか、法律の線引きがつかめない
この記事を読み終えたときに手に入るもの
- メニュー情報が4か所に分かれる理由と、どこから直すのかを説明できるようになります
- schema.orgの型で書ける条件と、文章で書くしかない条件を切り分けられます
- 条件を並べた相談に対して、自店の何が足りていないかを点検できます
結論30秒でわかる、この記事の結論
- 飲食店のChatGPT Search対策とは、4か所に散らばったメニュー情報を、AIが取り出せる形へ整え直すことです。
- 4か所のうち、内容を自分で決められるのは自社サイトだけです。だから、そこが起点になります。
- 個室・利用シーン・アレルギー対応には、専用の型がありません。型が無いところは、自社サイトの文章で補います。
この記事は、飲食店の集客を担当する3人と、専門家の会話をはさみながら進みます。ご自身に近い立場の人の質問から読んでいただいて構いません。
- 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
- 高梨課長（マーケ課長）— 「誰が、どこまでやるんですか？」を聞く役
- 大森部長（マーケ部長）— 「経営として、どこに投じるんだ」を聞く役
- 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役
01飲食店のChatGPT Search対策とは、メニューのAI対策として何をすることですか？
若葉さんあの、そもそもなんですが…飲食店のChatGPT Search対策って、グルメサイトに登録するのとは違うんでしょうか。
鈴木さん違います。ひとことで言うと、散らばっている情報を、AIが取り出せる形にそろえ直す作業なんですよ。ページを増やす話ではありません。
AIOはAI検索最適化のことで、LLMOと呼ばれることもあります。呼び方は違っても、目指す先は同じです。AI検索の答えの中で、情報源として選ばれることです。
飲食店の場合、その情報がもともと1か所にありません。予約は食べログやぐるなび、口コミの確認はGoogleビジネスプロフィール、メニューの詳細は自社サイト。長いあいだ、この分担で回してきました。
ChatGPT Searchは、その分担を前提にしません。利用者の1つの質問に対して、1つの答えを組み立てます。だから飲食店側の実務は、分散した情報をAIが参照しやすい形へ統合し直す作業に近いとWEBMARKSは考えます。
Google AI Overviews側の対応は、別記事『飲食業界のAI Overviews対策｜ローカル検索との重なり方』で扱っています。この記事はChatGPT Search側、なかでもメニュー情報の設計に絞ります。
この章のまとめ
飲食店のChatGPT Search対策とは、4か所に分かれた情報を、AIが取り出せる形へ整え直す取り組みです。
02メニュー情報が4か所に分かれているのは、AI検索で何が困るんですか？
高梨課長情報が分かれていること自体は、これまで困りませんでした。何が変わったんでしょう。
鈴木さん変わったのは、答えを組み立てるのが人からAIになったところですね。人なら4つのサイトを見比べます。AIは、読み取れたものだけで答えを作ります。
分散する理由は、プラットフォームごとに役割が違うからです。食べログ・ぐるなびは予約と口コミの蓄積を担い、Googleビジネスプロフィールは地図表示と簡易な情報を担います。
そして、文章量や表現の自由度に制約を受けないのは、自社サイトだけです。
| 情報の置き場所 | 主な役割 | 編集の自由度 |
|---|---|---|
| 自社サイト | メニュー詳細・アレルギー対応・座席の説明 | 飲食店が内容を完全にコントロールできる |
| 食べログ・ぐるなび等 | 予約受付・口コミの蓄積 | 各社の入力フォームの形式に従う |
| Googleビジネスプロフィール | 地図表示・営業時間・簡易メニュー | Google提供の専用編集機能の形式に従う |
もう1つ、動かせない前提があります。食べログやぐるなびがAI検索のクローラーをどう扱うかは、各社が個別に設定する領域です。設定そのものは各社のrobots.txtを開けば誰でも確認できます。ただし、掲載店舗の側から変更することはできません。
自社サイトの整備を先に進める理由は、ここにあります。
この章のまとめ
4か所のうち、内容を自分で決められるのは自社サイトだけです。だから、そこが起点になります。
03ChatGPT SearchのAI検索は、飲食店の情報をどこから取っているんですか？
若葉さんAIはどこを見にきているんでしょうか。見にくる場所が分かれば、そこに合わせられますよね。
鈴木さんそこは公式に公開されています。ChatGPT Searchは、検索専用のクローラー「OAI-SearchBot」が巡回した結果をもとに動いています。
ChatGPT Searchは、OAI-SearchBotの巡回結果をもとに動作します（出典: OpenAI公式）。答えの中に文としての引用が入り、あわせてSourcesパネルにも表示されます。
役割の違うボットが、ほかにもあります。学習用のGPTBotと、利用者が質問したときだけ動くChatGPT-Userです。この3種は、robots.txt上の設定が独立しています（出典: 同）。
3種のボットの技術仕様とrobots.txtの書き方は、別記事『GPTBot・OAI-SearchBotの違いとは？3つのAIボットを図解で比較』で解説しています。引用条件の全体像は、別記事『ChatGPT Searchに引用される条件とは？今日確認する9項目【チェックリスト】』も参考になります。
この章のまとめ
入口は、検索専用クローラーの巡回です。学習用のボットとは、設定を分けて考えます。
04robots.txtの設定は、飲食店のAI検索対策としてどこを見ればいいんですか？
高梨課長設定を見るのは制作会社になります。何を確認してもらえばいいでしょうか。
鈴木さん見るところは3つです。自社サイト・学習用ボットとの区別・予約サイト側。この順で確認してもらってください。
| 確認項目 | 内容 |
|---|---|
| robots.txt | 自社サイトでOAI-SearchBotをDisallowしていないか |
| GPTBotとの区別 | 学習用GPTBotの拒否設定と混同していないか |
| 予約プラットフォーム側 | 食べログ・ぐるなび等は各社が個別に管理し、自社側のrobots.txtとは扱いが別になる |
よく起きるのが、設定の取り違えです。「AIに学習させたくない」という理由でまとめて拒否すると、検索表示のための巡回まで止まります。
この章のまとめ
見るのは3か所です。ここが閉じたままだと、このあとの工夫が届きません。
05schema.orgのRestaurantとMenuは、飲食店のAI検索最適化でどこまで書けますか？
高梨課長構造化データを入れる、という話になりますよね。うちの規模でも書けるものでしょうか。
鈴木さん覚えるのは3階層だけです。店・メニュー全体・1品ずつ。この3つの関係が分かれば、あとは埋めていく作業になります。
自社サイトでメニューを構造化データとして表す基本形は、Restaurant型・Menu型・MenuItem型という3階層です（出典: schema.org公式）。RestaurantはFoodEstablishmentのサブタイプで、hasMenuプロパティでMenu型につながります。
| 型 | 役割 | 主なプロパティ |
|---|---|---|
| Restaurant | 店舗そのものを表す | servesCuisine（料理ジャンル）・priceRange（価格帯）・acceptsReservations（予約可否） |
| Menu | メニュー全体を表す | 個別の料理をまとめて保持する接続層 |
| MenuItem | 個別の料理・ドリンクを表す | offers（価格）・suitableForDiet（食事制限への適合）・nutrition（栄養情報） |
MenuItemの価格を表すoffersプロパティは、Offer型を使います。ネット販売のページで使うProduct schemaと、設計としては同じ考え方です。価格や在庫の書き方は、別記事『Product schemaの書き方｜価格・在庫がズレる3つの落とし穴【図解つき】』が参考になります。
ここまでは、型に沿って埋めれば書けます。むずかしいのは、この先です。
この章のまとめ
店・メニュー全体・1品ずつ。この3階層が、機械可読なメニューの骨格になります。
06飲食店の個室や利用シーンは、なぜ構造化データだけのAI対策では足りないんですか？
若葉さん個室があることも、構造化データで書けるんですか？
鈴木さんそこは正直にお伝えします。個室にも、細かいアレルギー対応にも、専用のプロパティが用意されていません。
MenuItemには、食事制限への適合を示すsuitableForDietというプロパティがあります（出典: schema.org公式）。対応する値は、GlutenFreeDiet（グルテンフリー）やVeganDiet（ヴィーガン）など11種類です。
卵・乳・小麦・えびといった個別のアレルゲンを直接指定する専用プロパティは、用意されていません。
個室の有無や座席数も同じです。Place型が持つamenityFeatureプロパティは構文上は使えますが、飲食店の設備を示す定型の値は定義されていません。
つまり、構造化データだけでは、個室やアレルギー対応の詳細を機械可読な形で表現しきれないのが実情です。この部分は、自社サイトの文章で補うことになります。
正直に書いておきます。Restaurant・Menu・MenuItemを実装した結果、ChatGPT Search経由の来店や問い合わせが増えたという実名・数値付きの公開事例は、本稿執筆時点で確認できていません。構造化データの実装は、AIが情報を機械的に理解しやすくする土台づくりとして意味があるとWEBMARKSは考えます。
この章のまとめ
型があるものは型で、無いものは文章で。無いことを理由に省かないのが分かれ目です。
07アレルギー対応は義務ではないのに、飲食店のAI検索対策では書くんですか？
大森部長法律で決まっていないことを、わざわざ書く必要があるのか。手間に見合うのかを聞きたい。
鈴木さん判断の分かれるところです。ただ、義務ではない情報こそ、利用者がAIに条件として投げてくる項目なんですよ。
まず、法律上の位置づけを正確に押さえます。食物アレルギー表示は、外食（飲食店での料理提供）には法律上の表示義務がありません。食品表示法にもとづく表示義務の対象は、容器包装に入れられた加工食品です。レストランや食堂での料理提供は、対象外になります（出典: 消費者庁）。
原産地表示も、原則として任意です。農林水産省は「外食・中食における原料原産地情報提供ガイドライン」を公表し、事業者の自主的な取り組みを推奨しています（出典: 農林水産省）。
| 開示項目 | 法的位置づけ | 根拠 |
|---|---|---|
| 食物アレルギー情報 | 義務ではない（任意の情報提供） | 食品表示法（対象は容器包装された加工食品）・消費者庁 |
| 米飯類の産地情報 | 義務 | 米トレーサビリティ法（農林水産省） |
| 米飯類以外の原産地情報 | 義務ではない（任意の情報提供） | 外食・中食における原料原産地情報提供ガイドライン（農林水産省） |
ここで言う「義務ではない」は、書かなくてよいという意味ではありません。法的な義務がない情報ほど、開示している店とそうでない店の差が、AIの回答内容に反映されやすいとWEBMARKSは考えます。
この章のまとめ
義務の有無と、利用者が知りたいことは別の軸です。書いてあるかどうかが、そのまま差になります。
08アレルギー対応は、飲食店のメニューでどう書けばAI検索最適化になりますか？
若葉さん書いたほうがいいのは分かりました。でも、うちのページには「アレルギー対応可」とだけ書いてあります。
鈴木さんそこが分かれ目です。その一言だけでは、条件つきの相談には答えられないんですよ。
「小麦アレルギーの子どもと入れる和食店」という相談に、「アレルギー対応可」の一言は届きません。どのアレルゲンに、どんな条件で対応できるのか。そこまで書いて、はじめて相談の答えに使える文になります。
対応できない場合も同じです。できないことを書いておけば、来店してから困る人が減ります。読者にとって役立つ書き方が、結果としてAIにも読み取りやすい形になる、という関係です。
この章のまとめ
「対応可」の一言では届きません。アレルゲンと条件をそろえて、はじめて答えに使えます。
09米飯類の産地は、飲食店のLLMO対策としてどこに書けばいいんですか？
若葉さんさっきの表で、お米だけ「義務」になっていました。あれはどうしてですか？
鈴木さん唯一の例外が米飯類なんです。米トレーサビリティ法という別の法律があって、こちらは産地情報の伝達が義務づけられています。
米トレーサビリティ法（正式名称: 米穀等の取引等に係る情報の記録及び産地情報の伝達に関する法律）は、米飯類を提供する外食事業者を対象にしています。この法律は、産地情報の伝達を義務付けています（出典: 農林水産省）。
伝達の方法は、1つに限られていません。メニューへの記載・店内掲示・問い合わせへの回答のいずれかで足ります。
ここに、AI検索の観点からの補足が入ります。店内掲示や問い合わせへの回答は、店に来た人・電話をかけた人には届きます。一方でAIが読み取れるのは、Web上に書かれたものだけです。
法令を満たす方法として3つが認められていることと、AI検索で拾われる方法が同じかどうかは、別の話になります。義務を満たしたうえで、メニューのページにも書いておく。LLMO対策としては、この形が無理のない進め方です。
この章のまとめ
産地情報の伝え方は3つから選べます。AIにも届けたいなら、そのうちWebに残る形を選びます。
10条件を並べた相談は、飲食店のAI検索ではどんな文で届くんですか？
高梨課長実際の相談って、どんな文で来るんでしょうか。そこが分かれば、用意するものも決まりますよね。
鈴木さんいい着眼点です。飲食店の場合、条件が最初から1文にまとまって寄せられます。ここが、ほかの業種と違うところですね。
ChatGPT Searchへの店探しの相談は、複数の条件が1つの文に混ざった形で届きます。次のような相談文が典型です。
| 相談文の例 | 含まれる条件 |
|---|---|
| 「渋谷 個室 4人 予算5000円くらいの店」 | エリア・座席形態・人数・予算 |
| 「小麦アレルギーの子どもと入れる和食店」 | アレルギー対応・客層・料理ジャンル |
| 「接待で使える 20時から入れる静かな個室」 | 利用シーン・時間帯・座席形態 |
| 「ヴィーガン対応してるイタリアン」 | 食事制限・料理ジャンル |
観光業でも、条件が会話の中で具体化していく現象が起きています。旅行の相談は段階を追って条件が増えていく形で、その設計は別記事『観光業界のChatGPT Search対策｜旅行計画への入り込み方』で解説しています。
飲食店探しは、条件が最初から1文にまとまって寄せられる点が違います。会話を重ねて足りない条件を補う余地が、そのぶん少なくなります。
この章のまとめ
相談文は、条件の束です。まずは自店に届きそうな文を、実際に書き出してみてください。
11相談の条件は、メニューのAI検索最適化でどこに書き分けますか？
若葉さん条件を書き出したあとは、どこに書けばいいんでしょうか。全部を構造化データにするんですか？
鈴木さんいえ、条件の種類で置き場所が変わります。ここを分けておくと、更新のときに迷わなくなりますよ。
分解したら、条件の種類ごとに置き場所を決めます。
| 条件の種類 | 対応する情報源 |
|---|---|
| エリア・料理ジャンル・予算帯 | Restaurant型のaddress・servesCuisine・priceRange |
| 営業時間・予約可否 | Restaurant型のopeningHoursSpecification・acceptsReservations |
| 個室・座席数・利用シーン | 専用プロパティがなく、自社サイトの文章記述が必要 |
| アレルギー対応 | suitableForDietでは表現しきれず、自社サイトでの個別記述が必要 |
エリア・料理ジャンル・予算帯・営業時間は、構造化データで機械可読に表せます。一方で、個室や利用シーン、細かなアレルギー対応は、自社サイトの本文でしか表現しきれません。
条件つきの相談に答えるには、構造化データと文章記述を、条件の種類に応じて使い分ける設計が要ります。
この章のまとめ
束をほどいて、型で書くものと本文で書くものに振り分けます。振り分けの基準は、条件の種類です。
12食べログやぐるなびに載せれば、飲食店のAI対策は足りているんですか？
大森部長予約サイトには掲載料を払っている。それとは別に自社サイトへ投じる理由を、はっきりさせたい。
鈴木さん掲載をやめる話ではありません。役割が違うので、両方が要るという話です。
予約プラットフォームの入力フォームは定型化されています。予約と口コミという役割にはよく合っていますが、個室の詳細やアレルギー対応の細かな条件までは書ききれません。
やっておきたいのが、基本情報の突き合わせです。営業時間やメニューが自社サイトと食い違ったままだと、AIがどちらを引用するかで答えの内容が変わります。更新は、片方だけで終わらせないでください。
点検の形にすると、次のようになります。
- Restaurant・Menu・MenuItemの階層を自社サイトに実装している
- 個室・座席数・利用シーンを自社サイトの文章で具体的に説明している
- アレルギー対応の可否と対象アレルゲンを、条件を添えて自社サイトに明記している
- 米飯類を提供している場合、産地情報をメニューまたは店内掲示で伝達している
- 食べログ・ぐるなび・GBPの基本情報（営業時間・メニュー）が自社サイトと一致している
- robots.txtでOAI-SearchBotを許可している
この章のまとめ
掲載サイトと自社サイトは、役割が違います。競わせるものではなく、突き合わせて使うものです。
13飲食店のChatGPT Search対策とメニューのAIO、やりがちな遠回りは何ですか？
ここまでの内容を、失敗の側から整理します。どれも「よかれと思って」起きるものです。
1. グルメサイトへの掲載だけで満足し、自社サイトを整備しないまま置いておく
入力フォームでは、個室の詳細やアレルギー対応の条件までは書ききれません。掲載を続けながら、自社サイト側を厚くしていく形になります。
2. アレルギー表示が義務ではないことを理由に、対応状況を一切書かない
法的な義務の有無と、利用者が実際に知りたい情報は、別の軸にあります。
3. 学習を断つつもりで、検索表示のためのクローラーまで閉じてしまう
GPTBotとOAI-SearchBotは、robots.txt上で別々に設定できます。まとめて拒否すると、答えの中に出てくる可能性まで無くなります。
この章のまとめ
遠回りの3つは、どれも善意から起きます。季節の変わり目ごとに、この3つで自店を点検してください。
14よくある質問
アレルギー対応の情報は、法的に書かなくてもよいのですか？
外食（飲食店での料理提供）には、食品表示法にもとづく表示義務はありません（出典: 消費者庁）。ただし、義務がないことと、利用者がChatGPTに条件として尋ねてくることは別の話です。書いていない店は、この種の相談で候補に挙がりにくくなるとWEBMARKSは考えます。
食べログやぐるなびのメニュー情報を充実させれば十分ですか？
各プラットフォームの入力フォームは定型化されており、個室の詳細や利用シーンまでは表現しきれません。自社サイトでの文章による補足が要ります。また、ChatGPT Searchが各プラットフォームをどう扱うかは各社の個別の設定に依存し、掲載している飲食店側からは確認できません。
米飯類を提供していない飲食店にも、米トレーサビリティ法は関係しますか？
産地情報の伝達義務は、米飯類を提供する事業者が対象です（出典: 農林水産省）。米飯類を提供しない業態であれば、この義務そのものは生じません。ほかの食材の原産地表示は原則として任意で、書くかどうかは自店の判断になります。
schema.orgのMenuItemだけ実装すれば、アレルギー対応も表現できますか？
suitableForDietプロパティは、グルテンフリーやヴィーガンなど11種類の食事制限に対応します（出典: schema.org公式）。卵・乳・小麦といった個別のアレルゲンを直接指定する専用プロパティはありません。対象アレルゲンの詳細は、自社サイトの文章で補うことになります。
個室や座席数は、どこまで細かく書けばいいですか？
目安になるのは、実際に寄せられる相談文です。座席形態・人数・利用シーンが条件として並ぶのであれば、その3つが読み取れる形になっているかを見てください。Place型のamenityFeatureは構文上使えますが、飲食店の設備を示す定型の値が定義されていないため、文章での説明が中心になります。
15まとめ｜飲食店のAI検索対策として、今日やること
飲食店のメニュー情報が複数のプラットフォームに分散する構造は、当面変わりません。だからこそ、自分で決められる自社サイト側から、構造化データと文章記述を整えることをおすすめします。
法的な義務の有無にかかわらず、条件を並べた相談に答えられる情報を持っているかどうかが、引用の分かれ目になるとWEBMARKSは考えます。着手の順番は、次の3つです。
今日この順でやります
Restaurant・Menu・MenuItemを実装する
店・メニュー全体・1品ずつの3階層でつなぎます
個室とアレルギー対応を、文章で書き出す
専用の型が無い条件を、本文で読み取れる形にします
米飯類の産地情報を、Webにも残す
義務を満たしたうえで、メニューのページにも書いておきます
AI検索では、こう聞かれています
ChatGPTで飲食店を探されたとき、自分の店が候補に入るには何をすればいいですか？
「飲食店のChatGPT Search対策とは、メニューのAI対策として何をすることですか？」の章で、情報を整え直すという考え方から説明しています
飲食店のメニューは、グルメサイトに載せておけばAI検索でも十分ですか？
「食べログやぐるなびに載せれば、飲食店のAI対策は足りているんですか？」の章で、役割の違いと突き合わせの手順を書いています
アレルギー対応は法律上の義務がないのに、サイトに書く意味はありますか？
「アレルギー対応は義務ではないのに、飲食店のAI検索対策では書くんですか？」の章に、法的な位置づけと書き方があります
次に読むなら、この記事です
