店舗LLMOの答えはllms.txtでなくGBPだった — 私が綺麗に書いたファイルを、AIは一度も引用しなかった
知り合いの店舗オーナーに「うちもLLMO対策したい」と相談されて、私はまず自社サイトに llms.txt を綺麗に書きました。営業時間、メニュー、アクセス、強み。AIが読みやすいように構造化して、JSON-LDも足して。我ながら整った仕事でした。
AIは一度も、その店を引用しませんでした。
数週間、Perplexityにも、ChatGPT Searchにも、Google AI Overviewsにも、その店の名前は出てこない。原因を探って、私はやっと自分の間違いに気づきました。店舗集客のLLMOは、自社サイトに何を書くかではほとんど決まらない。Googleビジネスプロフィール(以下GBP)に一次データを置くかで、ほぼ決まっていたのです。
私は普段、llmoframework.comというAI引用最適化のフレームワークを多言語で運営していて、llms.txtやJSON-LD、パッセージ設計といった「サイト側の技術」をさんざん書いてきました。だからこそ正直に書きます。店舗ビジネスでは、そのフレームワークの大半が要りません。答えはGBP一点に収束します。今回はその話です。
なぜサイトのllms.txtは店舗集客に効かないのか
理由はシンプルで、AIが店舗情報を取りに行く場所が、あなたのサイトではないからです。
「新宿 ラーメン 一人で入りやすい」「梅田 整体 腰痛」みたいなローカル検索で、AIが答えを組み立てるとき、信頼するファクトソースはGBPです。写真、カテゴリ、レビュー、メニュー、属性。これらがAI応答に直接反映されることはGoogle公式でも示されています。そしてChatGPT SearchやPerplexityは、Bing経由と独自スクレイプで、すでにGBP由来のデータを持っています。
数字で見ると流れがはっきりします。Google AI Modeは2026年のSearch I/Oで月間10億ユーザーを突破し、AI Overviewsに至っては月間25億ユーザー超。Googleを使う人の半分以上が、AIの生成した答えを日常的に見ています。その答えの裏側で参照されているのが、自社サイトのllms.txtではなくGBPだとしたら。綺麗なファイルを書く前に、見るべき場所が違っていたわけです。
私のllms.txtは、誰も来ない裏口に貼った貼り紙でした。立派な貼り紙でしたが、客はそもそも表のGBPから入ってきていたのです。
「LLMOとは」を定義しておく(そして店舗では大半が不要だと言う)
念のため言葉を揃えます。LLMO(Large Language Model Optimization)は、ChatGPT・Claude・Perplexity・Google AI OverviewsといったAI検索に引用されるための情報設計を指します。llms.txt、JSON-LD構造化データ、パッセージ最適化、引用トラッカー。私がllmoframework.comで多言語に整理してきたのは、まさにこの一式です。
ですが、これはメディアサイトやSaaS、つまり「読まれるコンテンツを自社ドメインに持っている事業者」のための道具立てです。店舗ビジネスは前提が違います。サイトを持っていない店も多いし、持っていても集客の主戦場はマップとローカル検索です。だからフレームワークの技術レイヤは、店舗ではほとんど発火しません。代わりに全部がGBPの一次データ整備という一点に収束します。
フレームワークを作っている本人が「ここではフレームワークは要りません」と言うのは妙な気分ですが、地図は現地に合わせて畳むものです。
店舗LLMOで本当に効く一次データ
ではGBPに何を置くか。決め手はE-E-A-Tの「経験(Experience)」です。Googleは2025年9月11日に品質評価ガイドラインを改訂し、AI要約を評価する基準の例を追加しました。AIが引用したがるのは、E-E-A-Tの高い情報源です。
店舗オーナーにとって、この「経験」は最大の武器になります。「実際にその場所を運営している」という事実は、代行業者には絶対に作れない一次情報だからです。具体的にはこの3つが、AIにとっての引用シグナルになります。
- 店主自身が撮った写真: スマホで撮った店内・メニューの実物。Exif情報込みの一次データ
- 店主の声で返したレビュー返信: 顧客とのやり取りが滲み出る本人の言葉
- 属性とQ&Aの網羅: 「静か」「無料Wi-Fi」「一人客歓迎」など、AIが自然言語クエリと照合できる構造化情報
ストック写真を貼り、テンプレでレビューに返し、属性を空欄のままにした店。逆に、自分でカウンター席を撮り、常連の名前を出してお礼を返し、属性を埋めた店。AIが「この店には経験がある」というシグナルを受け取るのは、後者です。そしてこれは、あなたの店で働いていない人間には、原理的に作れません。
代行業者の月3万円を開けてみた
ある店が契約していた「月3万円のLLMO対策」の中身を、頼まれて分解したことがあります。期待して開けました。
- 順位計測(月500円の自動ツールで代替できる)
- 口コミ返信(Claudeで下書きすれば5分)
- 投稿予約(月1回のテンプレ運用で10分)
- 月次レポート(Excelテンプレで自動化できる)
そして肝心の「LLMO対策」の実体は、結局GBPに写真を上げ、属性を埋めることでした。つまり、店主の経験という一番大事な一次データを「持っていない」業者が、定型作業に月3万円を取っていた。豪華な箱を開けたら、中身はスマホ1台でできる作業だった、という話です。
月の追加作業は60〜90分
では店主が自分でやるとして、どれくらいの手間か。MEOの基本運用に、LLMO視点の項目を足しても、月の追加作業は合計60〜90分程度です。
- 月1〜2回、店内とメニューを自分で撮ってGBPに上げる
- 届いたレビューに、店主の声で返す
- 属性とQ&Aの抜けを月1回見直す
- AI Overviewsで自店が出るか、実際に検索して確認する
これだけです。llms.txtは1行も要りません。JSON-LDのスキーマも、店舗集客の本筋ではない。代行に月3万円払う代わりに、スマホで店内を1枚撮って、自分の言葉で口コミに返す。地味すぎて代行には真似できないこの作業が、AIに引用される店とされない店を分けます。
まとめ
店舗オーナーに頼まれて、私は綺麗なllms.txtを書きました。それは誰も通らない裏口の貼り紙でした。AIが店を探しに来る表口はGBPで、そこに店主の一次データ(自前の写真、本人の口コミ返信、埋まった属性)があるかどうかで、引用されるかどうかがほぼ決まっていたのです。
LLMOというと、技術的なファイルを書く話に聞こえます。私自身、多言語のフレームワークでそれをやっています。でも店舗ビジネスに限っては、その大半が不要でした。やるべきは1つ。店主自身が、GBPに店の経験を出すこと。月60〜90分のこの一点を外さなければ、AIの仕様がどう変わっても、店は見つけられ続けます。
GBP運用を起点にMEOとLLMOを両輪で回す全体像(代行の月3万円を分解するセルフサーブMEOから、AI Native MEOという到達点まで)は 店舗オーナーのためのAI Native MEO・LLMO実践ガイド にまとめています。この記事は、その「LLMOは結局GBPに収束する」という結論を、現場で確かめた実録です。
この記事は役に立ちましたか？