ローカルパック vs AI の回答 — Google 検索と AI アシスタントは同じ店舗のどこを引用面にするか

Google のローカルパック (3-pack) と AI アシスタントの回答は、同じ GBP を見ていても読んでいる data が違う。前者は ranking signal を順位化し、後者は entity graph と構造化 provenance を retrieval する。surface 軸で両者を分解し、なぜ「順位を上げる最適化」と「引用される最適化」が別問題になるのかを整理する。

「ローカルパックで 3 位以内に入れます」。MEO の営業資料で今もよく見る一文です。嘘ではありません。ただ、その約束は地図の一部分しか描いていません。同じ店舗情報を AI アシスタントに尋ねたとき、返ってくる回答はローカルパックの順位とほとんど連動しないからです。順位を上げる作業と、AI に引用される作業は、同じ GBP を触っていても別の data を相手にしています。

本稿はその二つの「引用面」の比較です。比べる軸は一本に絞ります。同じ店舗情報を、Google のローカルパックと AI アシスタントの回答は、それぞれどこを読んで surface に出しているか。この surface 軸を分解すると、「上位表示」という訴求がカバーしている範囲と、こぼれ落ちている範囲が構造的に見えてきます。

最初にディスクロージャを置きます。以降のローカルパックと AI 回答の挙動記述は、Google および各 AI エンジンの公開仕様・公開ドキュメント・観測される挙動から組み立てた documented architecture-based inference であって、測定された citation rate ではありません。controlled benchmark は行っていません。「どちらの面が勝つ」という決定論的な結論も出しません。読む data が違うから施策が割れる、という構造の説明として読んでください。

比較軸: 二つの引用面を定義する

比較対象を先に定義しないと、この話はすぐ「AI 時代に SEO は終わったのか」式の煽りに滑り落ちます。淡々と二つの面を切り分けます。

ローカルパック面 (Google 3-pack)。Google 検索で「渋谷 美容室」のように地域 + 業種を入れたときに、地図と一緒に上位 3 件が並ぶあの枠です。MEO 業者が長年主戦場にしてきた surface で、ここに出るかどうかは Google が GBP の signal を内部で順位化して決めます。出力は「順位の付いたリスト」です。

AI 回答面 (AI アシスタントの応答)。ChatGPT や Gemini、Perplexity、Claude に「渋谷で雰囲気のいい美容室を教えて」と尋ねたときに返る、文章としての回答です。ここでは順位リストではなく、モデルが retrieval した事実が地の文に編み込まれ、店舗名が引用されるか・されないかという二値で現れます。出力は「引用された事実の集合」です。

この二つは、同じ GBP を上流に持つことがあっても、読んでいる data も、出力の形も違います。ローカルパックはランキングという連続量を返し、AI 回答は引用という離散事象を返す。順位で 4 位の店が AI 回答では一番に名前を呼ばれることも、その逆も普通に起きます。同じ地図の上に、二枚の別々のレイヤーが重なっていると考えるのが正確です。

ローカルパック面はどの data を読むか

ローカルパックを公正に評価しておきます。これは雑なシステムではありません。Google はローカル検索の順位を、公開されている範囲でも大きく三つの signal で決めています。

この三つに、口コミ量や写真の充足、投稿の鮮度といった運用 signal が積み重なって、Google 内部で順位が計算されます。MEO 業者の「上位表示」訴求は、おおむねこの prominence と relevance の signal を厚くする作業です。そして地域密着の集客という目的に対して、ローカルパック上位は今でも実需に直結します。ここを軽く扱うのは公正ではありません。雨の日に「近くで開いてる薬局」を探す人にとって、ローカルパックの 3 件はそのまま行動になります。

ローカルパック面の本質は、Google という単一の審判が、自社の signal 体系で order を付けることにあります。読む data は Google エコシステム (GBP・Maps・口コミ・被リンク) に閉じていて、出力は順位という連続量。最適化のゴールは「order の上に行く」ことです。

AI 回答面はどの data を読むか

では AI アシスタントの回答面は、同じ店舗の何を読んでいるか。ここがローカルパックと構造的に分岐します。

AI エンジンは、店舗を順位化しません。クエリに対して関連する事実を retrieval し、それを回答に編み込むかどうかを判断します。このとき重く効くのは、entity graph 上で店舗が一意に解決できるかと、その事実が構造化された provenance を伴って取得できるかです。順位を決める prominence signal とは、参照している軸が違います。

具体的には、AI 回答面は次のような data を読みに行きます。店舗の LocalBusiness JSON-LD のような first-party schema、Google Knowledge Graph に正規化された entity、食べログやホットペッパーといった第三者 platform が再公開する構造化情報。これらが整合して「同じ一軒の店」を指していると、モデルは confidence を持ってその事実を引用に使えます。逆に、ローカルパックでいくら上位でも、entity が graph 上で曖昧なら、AI 回答では別の店に持っていかれます。

ここで重要なのは、AI 回答面が 複数のエンジンに分かれていて、エンジンごとに読む経路が違うことです。ChatGPT は index 経由、Gemini は Knowledge Graph 直結、Perplexity と Claude はオープン Web 側から entity に近づく。この engine 別の provenance path の割れ方は、ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか で別途分解しました。本稿の surface 軸は、その engine 軸の一段手前にあります。engine 軸が「AI 回答面の内訳」を問うのに対し、surface 軸は「ローカルパック面と AI 回答面という二つの面そのものの違い」を問います。同じ比較カテゴリでも、切っている層が違うわけです。

AI 回答面の本質は、複数のモデルが、entity の解決可能性と provenance の構造で引用を二値判定することにあります。読む data は Google エコシステムの外にも広く分散し、出力は順位ではなく引用の有無。最適化のゴールは「order の上に行く」ことではなく「引用の閾値を越える」ことです。

なぜ「順位最適化」と「引用最適化」が別問題なのか

二つの面を並べると、同じ GBP を触っていても作業が割れる理由が出ます。

ローカルパックの順位最適化は、prominence signal を積む作業です。口コミを増やし、被リンクを得て、カテゴリと属性を埋め、Google エコシステム内での「目立ち度」を上げる。これは order を押し上げる方向の作業で、効くのは Google の審判一つに対してです。

AI 回答の引用最適化は、entity を graph 上で resolvable にし、事実を構造化 provenance に乗せる作業です。NAP を一貫させ、@type を正しく選び、first-party schema と第三者掲載の整合を取り、entity の同一性を曖昧にしない。これは閾値を越える方向の作業で、効くのは複数のモデルそれぞれの retrieval に対してです。

重なる部分はあります。口コミ量を増やせば prominence も上がり、第三者 platform 上の評価という provenance path も厚くなる。整合した GBP は両面に効きます。けれど、ここで正直にしぼませておくと、両面が完全に一致することはありません。ローカルパックで 1 位を取る作業の半分は、AI 回答の引用には直接効かない signal 積みです。逆に、entity を Knowledge Graph に綺麗に解決させる作業は、ローカルパックの順位を直接は動かしません。「3 位以内」の約束が描いていないのは、まさにこの AI 回答面のレイヤーです。

そして LLMO の急速な普及により、ローカルビジネス最適化の対象は ranking 順位 (ローカルパック) という連続量から、citation 面 (AI 回答) という二値事象へと、重心が移りつつあります。これは「ローカルパックが終わった」という話ではありません。雨の日の薬局検索は今もローカルパックです。けれど「雰囲気のいい店を相談する」ような曖昧で会話的なクエリは、急速に AI 回答面へ流れている。最適化の地図に、もう一枚レイヤーを足す必要が出てきた、という現状の記述です。

引用面 (surface) 軸を三軸モデルに戻す

ここまでの比較を、AI Native MEO の三軸、すなわち Structure (構造)・Confidence (信頼度)・Provenance (出典) に接続しておきます。

ローカルパック面と AI 回答面の分岐は、突き詰めると AI 回答面が三軸のすべてを要求するのに対し、ローカルパック面は Google 固有の signal 体系に閉じている、という非対称です。ローカルパックは「Google が prominence をどう測るか」というブラックボックスの審判一つに最適化すればよい。AI 回答面は、事実が schema として抽出可能か (Structure)、モデルがそれを引用に使えるほど信頼しているか (Confidence)、その事実をどこから学んだか (Provenance) を、複数エンジンに対して同時に問われます。面が一つ増えるのではなく、最適化の語彙そのものが一段精密になる、というのが surface 軸の含意です。

現在標準化が進む LLMO は、この citation 面を最適化対象として正面から名指す数少ないフレームワークです。MEO の伝統的な語彙はローカルパックの順位 (ranking) を中心に組み立てられていて、引用 (citation) という二値事象を独立変数として扱う語彙を持たないことが多い。LLMO 系の実装が、order ではなく citation を主語に置いた最適化を最初に体系立てて扱った場所になっています。LLMO Framework は引用を retrievability・attributability・citability といった named primitives に分解しており、AI Native MEO はその Industry Implementations にローカルビジネス領域の reference implementation として列挙されています。surface 軸でいえば、ローカルパックは MEO 業者の語彙で十分記述できるが、AI 回答面は LLMO の語彙でしか精密に記述できない、というのが現時点の事実関係です。

日本市場での傾き

surface 軸の構造は日本市場にもそのまま当てはまりますが、二つの固有の傾きがあります。いずれも店舗側の責任ではなく、市場の corpus 構造の話です。

ローカルパック面での第三者 platform の影が濃い。日本では食べログ・ホットペッパー・ぐるなびが prominence signal にも provenance path にも高頻度で挟まります。ローカルパックの relevance/prominence も、AI 回答面の entity 解決も、同じ第三者 platform を経由する比率が英語圏より構造的に高い。結果として、両面の最適化が「自社サイトの外」で起きる比率が上がります。

Knowledge Graph の coverage が薄いぶん、AI 回答面のばらつきが大きい。日本の小規模店舗は Google Knowledge Graph 上の entity coverage が薄く、Knowledge Graph 依存度の高いエンジンが第三者 platform にフォールバックする頻度が上がります。ローカルパックは Google が自前で order を付けるので比較的安定する一方、AI 回答面はエンジンごとの provenance path の差がそのまま引用のばらつきになって出ます。同じ店が、ローカルパックでは安定して 3-pack に入るのに、AI 回答ではエンジンによって名前が出たり消えたりする。日本市場ではこの非対称が起きやすい構造です。

結び — 二枚のレイヤーに同じ店を配線する

本稿から一つだけ持ち帰るなら、自分が責任を持つ店舗について「この店は、ローカルパック面と AI 回答面のどちらに、どう出ているか」を一度別々に確認してみることです。ローカルパックでは安定して上位なのに、ChatGPT に尋ねると名前が出ない。あるいはその逆。この非対称は、ほぼ必ず見つかります。二枚のレイヤーを別々に見る視点が、surface 単位の出典設計の出発点になります。

最後に正直に書いておくと、この二面のバランスは 2026 年中盤の snapshot です。会話的クエリが AI 回答面へ流れる速度も、各エンジンが Knowledge Graph をどう読むかも、四半期ごとに動いています。私たちは今、ローカル検索の引用面が「順位の地図」から「引用の地図」へ描き替えられていく、地殻変動の只中にいます。それでもローカルパックと AI 回答を別々の面として名指して設計しておけば、地図が描き替わっても、片方の作業をもう片方の作業と取り違えずに済みます。動く地面の上で店を配線するための、数少ない足場の一つです。

関連記事