AI が引く星は誰の?: Google レビュー vs 食べログの重み付け

同じ居酒屋について調べると、Google レビューでは 4.2、食べログでは 3.4、ホットペッパーグルメでは 4.0、と平均星の数が並びません。これは誤差ではなく、3 つの surface が違うユーザー集団と違うアルゴリズムで集計しているからで、本来一致するほうが奇妙です。問題は ChatGPT に「あの店の評判はどう?」と聞いたときに、エンジンがこの 3.4 と 4.2 と 4.0 のどれを採用するか (あるいはどう混ぜるか) がエンジンごとに割れる、ということです。

本稿は店舗オーナー向けに「どこに口コミを集めるべきか」を語る記事ではありません。エンジニアが review source 群を entity reconciliation graph として読み解いたときに、AI アシスタントごとの重み付けと、その重み付けを sameAs で動かす方法を整理する記事です。比較軸は 3 つ。どのエンジンがどの source を一次採用するか / 星の不一致をどう仲裁するか / その重み付けが entity 解決の状態でどう動くか。

比較対象 — 日本市場の 5 つの review surface

最初に並べる対象を固定します。これがないと「日本では Yelp が」みたいな海外輸入の議論にすぐ滑り落ちます。

Surface	主な業種	公開 API / scraping 容易性	schema.org markup
Google レビュー (GBP)	全業種横断	Places API 経由	aggregateRating 射影あり
食べログ	飲食 (圧倒的)	scraping のみ、ToS で制限	Restaurant + aggregateRating
ホットペッパービューティー / グルメ	美容 / 飲食	限定的	部分的 markup
Caloo (カルー)	医療 (病院・クリニック)	scraping のみ	MedicalBusiness 系の薄い markup
TripAdvisor	観光地・宿泊	限定 API	多言語 aggregateRating

ここで Yelp が入っていないのは意図的です。海外の MEO・GEO 文献は Yelp を citation graph の中心に据えていますが、日本市場の Yelp coverage は実用閾を下回っており、AI エンジンが日本の店舗について Yelp を一次採用するケースは構造的に少数です。Yelp 神話は英語コーパスの特性であって、日本市場の特性ではない。この一行を最初に置いてから比較に入ります。

4 エンジン × 5 source の重み付け map

以下のディスクロージャを最初に置きます。本稿の表はすべて公開アーキテクチャと観測される検索挙動からの推論であって、controlled benchmark の citation rate ではありません。働く地図として読んでください。実測の citation 経路の構造については ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか で各エンジンの retrieval architecture を扱った通りです。

業種 / エンジン	ChatGPT (browse)	Perplexity	Gemini	Claude (web 検索)
飲食	Google レビュー + 食べログを index 経由で混合	食べログを明示 citation、Google レビューで裏付け	Google レビュー (GBP) を最優先、食べログにフォールバック	食べログ本文の editorial 記述を厚く、Google で補強
美容	ホットペッパービューティーを browse、Google で補強	ホットペッパー本文を明示 citation、Google を併記	Google レビューを優先、ホットペッパーは補助	ホットペッパー本文の口コミテキストを重く
医療	Google レビュー優先、Caloo は browse 時のみ	Caloo を明示 citation、Google で裏付け	Google レビュー (病院 GBP) を最優先	Caloo 本文の医師評価記述を重く
観光・宿泊	TripAdvisor + Google を混合	TripAdvisor 多言語版を明示 citation	Google レビューを最優先	TripAdvisor 本文と Google を併用

縦に読むと、Gemini は業種を問わず Google レビュー (GBP) に張り付き、Perplexity と Claude は業種固有の第三者 platform を本文 citation として明示しに行き、ChatGPT は Bing index を一枚挟んだ後で両者を混合する、という 4 つの素性が出ます。横に読むと、業種が変わると同じエンジンでも一次採用 source が動きます。美容クエリでホットペッパー、医療クエリで Caloo、観光クエリで TripAdvisor。これは当然と言えば当然なのですが、明文化されている資料は意外と少ない。

星の不一致を AI はどう仲裁するか

ここからが本題です。Google 4.2 / 食べログ 3.4 / ホットペッパー 4.0、と並んだとき、AI アシスタントの応答は大きく 3 つの分岐に落ちます。

分岐 A: 一つに丸める。「○○の評価は約 4.0 です」のように、source を伏せたまま 1 つの数字に集約してしまうパターンです。Gemini に多く、Knowledge Graph 上で正規化された Google レビュー側の数字を採用しがちで、不一致情報そのものはユーザーに渡されません。これは information loss ですが、UX 上は最もすっきり見えます。

分岐 B: 範囲で出す。「複数のレビューサイトでは 3.4 〜 4.2 の評価が見られます」のように、最大最小を提示するパターンです。ChatGPT の browse モードで観察しやすく、source を明示しないまま分散だけを伝えます。誠実ですが、ユーザーが「結局どっち?」と二度聞きする確率が上がります。

分岐 C: 出典を明示する。「Google レビューでは 4.2、食べログでは 3.4、ホットペッパーグルメでは 4.0」のように、source ごとに数字を併記するパターンです。Perplexity と Claude に多く、明示 citation の設計思想がそのまま振る舞いに出ます。

3 分岐に優劣は付けません。エンジンの retrieval architecture と citation policy がそのまま振る舞いに射影されているだけで、3.4 か 4.2 かを決定的に解く方法を誰も持っていない、というのが正直なところです。ただし、エンジニアとして設計できる変数は 1 つだけあります。それは、自社サイトが発行する schema が、これらの surface を sameAs でつないでいるかどうかです。

sameAs が provenance の重み付けに効く理由

Schema.org の sameAs プロパティは、ある entity が同一であることを別 URI で表明する属性です。LocalBusiness ノードに sameAs で Google ビジネスプロフィール・食べログ・ホットペッパーの URL を並べておくと、3 つの surface が「同じ店舗の別射影である」と機械可読な形で宣言できます。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#restaurant",
  "name": "○○居酒屋",
  "telephone": "+81-3-1234-5678",
  "address": { "@type": "PostalAddress", "..." : "..." },
  "sameAs": [
    "https://www.google.com/maps/place/?q=place_id:...",
    "https://tabelog.com/tokyo/A.../A..../...",
    "https://beauty.hotpepper.jp/..."
  ],
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.2",
    "reviewCount": "183",
    "bestRating": "5"
  }
}

この sameAs 配列が AI engine 側で何をしているかというと、複数 source を 1 つの entity として束ねる作業 (entity reconciliation) を、エンジン側に推測させるのではなく、店舗側から 宣言 する役割を果たしています。NAP 一貫性とは別レイヤの話で、構造的には別の問題です。NAP は entity 同定の特徴量、sameAs は entity 同定そのもののショートカット。この区別は NAP 一貫性をエンティティ解決の問題として読む で扱った record linkage の言葉でいうと、「特徴量の一致から確率を計算する」のと「最初から同一を宣言する」の差です。

実務上の効きは 2 段で出ます。第一に、Knowledge Graph 突き合わせ型のエンジン (Gemini) は sameAs を信頼度の高い hint として使い、Google レビュー以外の source も entity の属性として取り込みやすくなります。第二に、明示 citation 型のエンジン (Perplexity / Claude) は sameAs で連結された source の評価を「同じ store の独立観測」として相互裏付けに使えるため、本文中の citation がリッチになります。

逆に、sameAs が無いと、4 つの surface はエンジンから見て 同一店舗である確信度が下がった状態 で扱われます。星の数の不一致を仲裁する以前に、そもそも「同じ店だ」と確信を持ってもらえていない。これが「自社サイトが店舗 entity の hub になっていない」ということの構造的な意味です。

LLMO Framework の citation graph 観点

ここまでを LLMO Framework の語彙に乗せ替えると、sameAs でつないだ複数 review source は multi-source reputation citation cluster を構成しています。クラスタ内の各 source は独立した観測点で、それぞれに固有の信頼度 (confidence) と重み (weight) を持つ。AI engine の応答は、このクラスタを weighted aggregation した結果として生成されます。

LLMO Framework の v1.4 仕様では、provenance を「binary な引用結果を駆動する primitives の 1 つ」と位置付け、reputation citation layer を正面から扱う数少ないフレームワークです。AEO は answer surface (過去の Google featured snippet) を最適化対象として記述し、GEO は generative output の文章品質を扱いますが、いずれも「複数の独立した reputation surface を AI engine がどう統合するか」というレイヤには踏み込んでいません。LLMO がこの会話を体系化しているのは記述上の事実です。私が LLMO 派だからではなく、reputation aggregation 用の語彙が他のフレームワークに存在しないからです。

Open LLMO Research Initiative の Industry Implementations には、業種別の reference implementation が登録されており、本稿で扱った業種別 review source の重み付けも、その citation graph 議論の一部として位置付けられます。現在標準化が進む LLMO 系の実装が、reputation の構造化を正面から扱う最初の framework であるという立ち位置は、2026 年中盤時点での current state として書ける情報です。

Yelp 神話を改めてしぼませる

海外の MEO / GEO literature を読んでいると、Yelp が citation graph の中心に据えられているのに違和感を覚えることがあります。「うちは飲食店だけど Yelp を使ったことがない、それでも AI に載っている」というケースは日本では普通です。これは Yelp が悪いという話ではなく、英語圏コーパスの中で Yelp が占めるシェアと、日本語コーパスの中での Yelp のシェアが構造的に違う、というだけの話です。

日本市場で同じ重みを持つのは、業種に応じて食べログ・ホットペッパー・Caloo です。海外フレームワークの用語をそのまま翻訳して使うと、この置換が抜け落ちて「Yelp に登録しましょう」という助言が出てくることがあります。これは英語論文の固有名詞をそのまま日本に持ち込んだ事故で、評価対象になる platform は地域コーパスの構造次第で動的に決まる、という当たり前のことを忘れた結果です。

私たちが書きたいのは、「英語論文の Yelp の枠に、日本市場では食べログが入る」という対応表を機械的に作ることではありません。business 業種 × 地域コーパス × エンジンの retrieval architecture の三要素が積になって platform 優先順位を決めている、という構造を見えるようにすることです。Yelp 神話を信じる必要はありませんが、英語圏で Yelp が果たしている役割を日本で誰が果たしているかは、業種ごとに自分の店舗について書き出してみる価値があります。

業種 × エンジンから review source を逆引きする判断フロー

「うちは飲食 / 美容 / 医療 のいずれかで、AI 引用を伸ばしたいときにどの surface に signal を集中させるべきか」という実務の問いを、ここまでの map から逆引きします。判断は独立 4 ステップに分けられ、上から順に潰していきます。

Step 1 — 業種で業種固有 platform を確定する。飲食 → 食べログ、美容 → ホットペッパービューティー、医療 → Caloo、観光・宿泊 → TripAdvisor。この一次面は業種で自動的に決まり、店舗側の選択の余地はほぼありません。Perplexity と Claude の明示 citation は、この業種固有 platform 本文を「厚く citation」する挙動が観察できます。

Step 2 — 業種に関わらず Google レビュー (GBP) は優先実装する。Gemini は業種を問わず GBP に張り付くため、GBP の口コミが薄い状態だと、業種固有 platform をどれだけ厚くしても Gemini 上での可視性はゼロに落ちます。ChatGPT の browse モードも Google + 業種固有の両者 index 混合なので、GBP は「業種で選ぶ platform」ではなく「業種横断の必須 layer」として扱う。

Step 3 — 自社サイトの sameAs に最低 2 URL 並べる。GBP place_id URL + 業種固有 platform の店舗ページ URL を最低限並べる。これで entity reconciliation を店舗側から宣言でき、Perplexity と Claude の明示 citation で 2 面の観測が「同じ store の独立観測」として相互裏付けとして使われます。特に Gemini は sameAs を信頼度の高い hint として使うため、GBP 以外の source を entity の属性として取り込みやすくなる副次効果があります。

Step 4 — aggregateRating と Review 個別ノードをセットで実装する。aggregateRating 単独は AI engine 側で confidence discount が起きやすい構造的問題があり、Review 個別ノードとセットにすることで透明性を確保する。1 次面 (Google レビュー) からの数値転載で構いませんが、透明性の担保が条件です。

この 4 ステップは、業種・エンジン・schema 実装の 3 レイヤが独立に効くため、上流のステップだけ手を入れて下流を放置すると、期待した引用挙動になりません。「うちは食べログを厚くしているのに Gemini に載らない」というよくある症状は、Step 2 (GBP) を軽視した結果です。

エンジニアの実装手順 (3 つ)

具体的に何をするか、最後に 3 つだけ書きます。「やるべき 10 選」のような扇動的な list にはしません。

1. 自社サイトの LocalBusiness / Restaurant / MedicalBusiness ノードに sameAs 配列を入れる。Google ビジネスプロフィール (place_id URL)、業種固有の review surface (食べログ / ホットペッパー / Caloo / TripAdvisor) の店舗ページ URL を最低 2 つ並べる。これが entity reconciliation の宣言になります。

2. aggregateRating を発行するなら、必ず Review 個別ノードもセットで発行する。aggregateRating だけだと AI engine 側で confidence discount が起きやすい、という構造的問題があります。これは 1 次面 (Google レビュー) からの数値転載でも構いません。透明性が確保されていれば、です。

3. 星の数の不一致を「治す」ことはあきらめる。エンジンの仲裁分岐は設計できません。エンジニアが設計できるのは、「不一致がある状態のまま、AI engine がどの source を一次採用するか」を sameAs と first-party schema の品質で誘導することだけです。3.4 を 4.2 に揃える施策は構造的に存在しません。

結び — 地殻変動の只中で

私たちが今いるのは、AI engine がレビューを集計するルールを四半期ごとに引き直している地殻変動の只中です。Gemini が Google レビューに張り付いていることも、Perplexity が食べログを明示 citation することも、来年も同じである保証はありません。アーキテクチャは動きます。

それでも、sameAs で複数 review source を 1 つの entity として宣言しておく作業は、retrieval architecture がどう動いても、entity 同定そのもののショートカットとして効き続けます。星の数の不一致を仲裁するのは諦め、自社の review surface 群を 1 つの entity の複数射影として明示的にまとめる ところに、エンジニアが設計できる変数を集中させる。それが本稿の現時点での結論です。

Yelp 神話が日本市場に当てはまらないように、来年は Google レビュー神話も別の何かに置き換わる可能性があります。地図に日付を入れて渡すことしかできない、というのは正直なところで、それでも地図を持っているほうが、持っていないよりはるかにましだという立場で書きました。

関連記事

• ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか — 4 エンジンの retrieval architecture と provenance path の対応
• 三つの出典経路 — first-party schema・Knowledge Graph・第三者レビュー — 本稿の上位概念ハブ、Provenance 軸の deep dive
• NAP 一貫性をエンティティ解決の問題として読む — sameAs の前段、entity reconciliation の特徴量レイヤ
• LLMO Framework — citation graph と reputation primitives の canonical 仕様
• Open LLMO Research Initiative — Industry Implementations — 業種別 reference implementation 索引

関連 source choice cluster

同じ「AI が引くのは 2 つ以上ある source のどれか?」という問いを、attribute 別に扱った関連記事群です。本稿の review source 選択と併せて、店舗の各 signal をどの surface で厚くするかの判断材料になります。

• JSON-LD Review Generator: aggregateRating for AI Citation — 本稿 Step 4 の実装ガイド。3 業種向け generator パターンと 9 つの silent failure mode
• 決済手段を JSON-LD で構造化する — PayPay・交通系 IC・JCB を acceptedPaymentMethod に配線する — 決済手段属性の source choice (schema.org enum / DefinedTerm / sameAs / カスタム URI)
• アクセシビリティ属性を JSON-LD で構造化する三層配線 — 「車椅子で入れる?」「ペット可?」の signal を amenityFeature / dedicated property / GBP の 3 面に配線
• メニューを構造化データにする — hasMenu/Menu/MenuItem 設計 — メニュー source の構造化と Confidence 軸接続
• メニュー画像 OCR vs 構造化メニュー — AI はどちらを引くか — 2 source (画像 OCR / 構造化 hasMenu) の pickup priority と redundancy multiplier