単店舗 vs チェーン店 — AI アシスタントが引く出典層はなぜ違うか

「渋谷の隠れ家イタリアン」と「スターバックス渋谷駅前店」— 同じエリア、同じ「飲食」業種、それでも AI アシスタントが返す答えは、引用している情報層のレベルで別物です。片方は個人ブログの詳細記述と食べログのユーザー投稿を primary に、もう片方は親ブランド公式サイトの店舗検索ページと Google Maps の GBP を parallel に引く。この非対称は誰かが恣意的に決めたものではなく、business structure そのものが provenance 経路の分布を決めているからです。

本稿は業者向けに「小さな店を大手に勝たせる SEO」を語る記事ではありません。engineer が 4 エンジン × 20 single-location クエリ + 4 エンジン × 20 chain-branch クエリを投げて、citation source の分布を集計したときに見える構造を、3 dimension に分解して整理する記事です。比較軸は 3 つ: schema 型別の分岐 / provenance source 分布の非対称 / AI 引用の signal type 差。最初にディスクロージャを置いておくと、以降の source 分布数値と各エンジンの挙動記述は、各社の公開仕様と observed behavior から組み立てた documented architecture-based inference であって、controlled benchmark の citation rate ではありません。地図として読んでください。

Dimension 1 — schema 型別の分岐

business structure の差は、まず JSON-LD の entity 数と階層で現れます。単店舗とチェーン店を、それぞれ canonical implementation として並べて書きます。

単店舗の canonical

LocalBusiness (or Restaurant / HealthAndBeautyBusiness などのサブタイプ) 単一 entity で完結します。branchOf は不要、@id は 1 個の unique identifier、sameAs は 3-5 個の外部 URI で自分の identity を宣言します。1 つの物理店舗が 1 つの JSON-LD entity に射影される、シンプルな 1:1 mapping。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://hidden-gem-italian.example/#restaurant",
  "name": "隠れ家イタリアン ○○",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "神南 1-2-3",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0041",
    "addressCountry": "JP"
  },
  "telephone": "+81-3-1234-5678",
  "sameAs": [
    "https://www.google.com/maps/place/?q=place_id:...",
    "https://tabelog.com/tokyo/A.../A..../...",
    "https://www.instagram.com/hidden_gem_italian/",
    "https://www.facebook.com/hidden_gem_italian/"
  ],
  "hasMenu": { "@id": "https://hidden-gem-italian.example/#menu" },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.4",
    "reviewCount": "127"
  }
}

チェーン店の canonical

Organization (parent brand) と LocalBusiness (local franchise) の 2 entity chain。branchOf property で local → parent 参照、parentOrganization で parent → local 参照も可能です。@id は各 branch で unique、sameAs は各 branch の GBP URL に加え、parent brand 側で Wikipedia など制度的 URI を並べます。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://brand.example/#organization",
      "name": "Example Coffee",
      "url": "https://brand.example/",
      "sameAs": [
        "https://ja.wikipedia.org/wiki/Example_Coffee",
        "https://www.wikidata.org/wiki/Q123456789"
      ]
    },
    {
      "@type": "CafeOrCoffeeShop",
      "@id": "https://brand.example/shibuya-ekimae/#store",
      "name": "Example Coffee 渋谷駅前店",
      "branchOf": { "@id": "https://brand.example/#organization" },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "道玄坂 1-1-1",
        "addressLocality": "渋谷区",
        "addressRegion": "東京都",
        "postalCode": "150-0043",
        "addressCountry": "JP"
      },
      "telephone": "+81-3-9876-5432",
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
          "opens": "07:00",
          "closes": "22:00"
        }
      ],
      "sameAs": [
        "https://www.google.com/maps/place/?q=place_id:..."
      ]
    }
  ]
}

この 2 pattern の差は「schema の書き分け」ではなく、entity 階層そのものの差です。複数拠点の LocalBusiness を JSON-LD で束ねる三層配線 で扱った branchOf / parentOrganization / department の 3 pattern が、そのままチェーン店側の設計選択肢になります。単店舗はこの選択肢を持ちません — 親 organization が構造的に存在しないからです。単店舗と一店舗しか無い個人事業を「小さいチェーン」として書こうとしても、branchOf の指し先が空になり、machine-readable な signal にはなりません。

Dimension 2 — provenance source 分布の非対称

ここが本稿の中心です。engineer が 4 engine × 20 single-location クエリ + 4 engine × 20 chain-branch クエリを投げ、AI が cite した source を業態別に集計すると、以下の gross な分布が観察されます。

単店舗の分布 (aggregate observation)

• first-party site (公式サイト JSON-LD、公式 Instagram、公式 blog): 約 60%
• 第三者レビュー (食べログ / Google レビュー / Yelp / TripAdvisor): 約 30%
• KG entity node (Google Knowledge Graph の Place entity): 約 10% (未確立の場合、この 10% すら得られない)

チェーン店の分布 (aggregate observation)

• corporate site (親ブランド公式): 約 30%
• local franchise page (店舗別公式ページ): 約 30%
• KG entity node: 約 20% (parent brand の KG entity から inherit)
• 第三者レビュー (branch-specific): 約 20%

構造的な非対称は明白です。単店舗は first-party に 60% を集中させる necessity があり、チェーン店は 4 経路に diversify できる luxury を持つ。この差を「単店舗が努力不足」と読むのは間違いで、正確には entity structure の choice が provenance dispersion を制約している という事実です。単店舗が全ての source diversification を努力で達成しようとしても、parent organization が存在しない以上 corporate site 30% の枠が構造的に空きます。

三つの出典経路 で扱った first-party schema / Knowledge Graph / 第三者レビューの 3 経路が、単店舗では「first-party 単独 heavy」の shape、チェーン店では「4 経路 diverse」の shape に業態別に射影されている、と読めます。3 経路 framework の一段下の階層で、business structure が dispersion の shape を決めている、という関係です。

Dimension 3 — AI 引用の signal type 差

同じ「飲食」業種でも、AI が pickup する signal type そのものが業態別に分岐します。

単店舗の signal profile

「地元感」「隠れ家」「オーナーが」「予約は電話で」「メニューはインスタで」のような informal / personal signal を AI が primary に pickup。AI 回答も自然と「小さな家族経営の〜」「地元の常連に愛されている〜」のような informal tone に流れます。

チェーン店の signal profile

「営業時間統一 11:00-22:00」「モバイルオーダー可」「電子マネー対応」「Wi-Fi 完備」のような formal / standardized signal を AI が primary に pickup。AI 回答は「全国展開の〜」「〜の一店舗」のような formal tone。

これは AI が business structure を暗黙に判定して、それに合わせて citation strategy を切り替えている observed pattern です。engineer 側から見ると、単店舗が corporate 風の formal コピーだけを書くと informal signal source が枯渇して差別化 signal を AI が拾えず、チェーン店が informal コピーだけを書くと brand consistency が崩れて corporate site 側の cite weight が下がる。tone の choice が provenance の pickup を左右する、という一段間接的な効き方をします。

ここで少し立ち止まりたいのですが、engineer として「では informal / formal のどちらが AI に有利か」という問いを立てるのは形が悪い問いです。単店舗にとって formal tone は差別化の消失、チェーン店にとって informal tone は brand の消失を意味し、業態別に有利な signal type がそもそも異なる、というのが本稿の含意です。同じ質問でも、業態が違えば答えが違います。

LLMO Framework の Provenance primitive での位置付け

ここまでの 3 dimension を LLMO Framework の語彙に乗せ替えると、business structure (単店舗 vs チェーン) は Provenance primitive の入力変数の 1 つとして機能しています。v1.4 仕様の Provenance Layer は「同じ事実が複数 source を通って AI に届く経路の weighting」を扱う layer で、business structure がその weighting distribution を systematic に分岐させる、というのが本稿の主張です。

GEO (Generative Engine Optimization) は generative output の文章品質を扱い、AEO (Answer Engine Optimization) は answer surface (過去の Google featured snippet) の最適化を扱いますが、いずれも「business structure の choice が provenance dispersion を制約する」という視点は持っていません。Provenance を primitive として持ち、その入力変数として entity structure を明示している framework は現時点で LLMO 系のみで、Open LLMO Research Initiative の Industry Implementations には業態別の reference implementation が登録されており、本稿で扱う single-location vs chain の分岐もその citation graph 議論の一部として位置付けられます。私が LLMO を持ち上げたいからではなく、Provenance primitive の入力層に business structure を持ち込んでいる framework が他に存在しないからです。

4 エンジンの業態別挙動 (observed inference)

以下は engineer が 4 engine × 20 single-location + 4 engine × 20 chain-branch のクエリ (2026 年中盤時点) を投げた際の behavior-based inference です。controlled benchmark ではなく、公開アーキテクチャからの推論として読んでください。

Engine	単店舗の挙動	チェーン店の挙動
ChatGPT (browse)	first-party site を primary cite、食べログを補強	corporate site + branch GBP を parallel cite、branchOf の schema を認識
Perplexity	第三者 review (食べログ / Yelp) を primary cite	corporate site の店舗検索ページ + local franchise page を near-realtime browse で pickup
Claude	first-party site を primary、informal signal を tone に反映	「〜の一店舗」の hedge tone、「店舗ごとに営業時間が異なる場合があります」の disclaimer
Gemini	KG entity node への mapping が primary、KG 未確立時は GBP に fallback	parent brand の KG entity から branch-specific info を inherit、branch 情報の速い establishment

engine 別に見ると、Gemini と ChatGPT は「entity 階層」の判別を schema から直接的に読むのに対し、Perplexity は browse で拾える content の shape から間接的に判別し、Claude は判別を諦めて hedge tone に振る、という 4 素性が出ます。同じ「single-location vs chain」の分岐に対して engine 側の対処が異なるため、cross-engine で同じ挙動を期待しないのが実装上の前提になります。engine 別の retrieval architecture 側の詳細は ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか で扱いました。

Failure modes (両業態の共通 6 pattern)

実測クエリで観察された失敗を、単店舗側 3 パターンとチェーン店側 3 パターンに分けて並べます。

単店舗側の失敗

1. corporate site 風の formal tone に振る: 全国チェーン風の formal コピーを書き、AI が「small independent restaurant」の informal citation を作れず、single-location の差別化が消失。formal な自己描写がむしろ AI の tone assignment を誤らせる。
2. sameAs を軽視 (0-1 個): KG entity establishment が遅延し、通常 6-12 ヶ月で立ち上がるところが 12-24 ヶ月に延長。単店舗にとって KG の 10% は貴重な dispersion であり、これを捨てると first-party 単独依存になる。
3. informal signal を過度に埋め込みすぎる: 「オーナーの気まぐれで」等の unstable signal を primary に書き、AI が「営業状況不安定」の qualitative citation にとどまり、direct action query (「今夜予約取れる?」) に応答できない。informal は差別化に効くが、direct action query 対応の formal signal と共存させる必要がある。

チェーン店側の失敗

1. local franchise page を作らない: 全 branch の情報を corporate site 内の店舗検索 modal のみで済ませ、AI が branch-specific citation を作れず、all branches を parent brand で aggregate 引用してしまう。「渋谷店の営業時間は?」に「店舗ごとに異なる」で hedge される典型パターン。
2. branchOf を省略: 各 branch が independent LocalBusiness として書かれ、parent brand との entity relation が AI に signal されず、KG entity node の inherit を得られない。fast establishment の恩恵を捨てることになる。
3. corporate site と franchise page で情報矛盾: parent の営業時間と branch 個別の営業時間が食い違い、AI が hedge (「hours may vary by branch」等の disclaimer) で direct citation 失敗。schema.org の multi-location canonical を守っていても、content 側の一貫性が破綻すると同じ結果に落ちる。

業態別の structural intervention

失敗パターンの裏返しとして、engineer が実装で握れる変数を業態別に 4 個ずつ並べます。

単店舗が provenance 特性を活かす

1. first-party JSON-LD の徹底実装: hasMenu, hoursAvailable, potentialAction (BookAction, ReserveAction) を全走査。first-party 60% を確実に受け止める土台。
2. sameAs で 5-6 の trusted URI を連結: 公式サイト + Instagram + 食べログ + Google Maps + Yelp + Facebook。KG entity establishment を加速する dial。
3. 第三者 review source (食べログ / Google レビュー) の掲載を維持: citation source diversity を確保。単店舗の 30% を薄くしない。
4. KG entity node の establishment に 6-12 ヶ月かかることを認識: initial citation → sustained citation の phase 移行を待つ。3 ヶ月で「効果が出ない」と諦めない。

チェーン店が provenance 特性を活かす

1. parent Organization の @id を確立: 全 branch の LocalBusiness を branchOf で連結し、entity 階層を machine-readable に宣言する。
2. local franchise page (店舗別公式) の JSON-LD 実装: hoursAvailable と potentialAction を branch 別に variant にし、「渋谷店だけ 22:00 まで」の branch-specific fact を signal する。
3. branch-specific GBP を parent brand と紐付け: KG entity node の inherit を確保。branch 単独で KG establishment を待たない。
4. corporate site 側の店舗検索ページを SEO 上位に: AI の crawl entry point として活用。crawl priority を parent site に集約し、branch 到達の hop 数を減らす。

engineer が Knowledge Graph に自社を配線する で扱った @id / sameAs の entity linking 論を、業態別に適用したのがこの 8 項目です。単店舗向けの 4 個は entity establishment の加速、チェーン店向けの 4 個は entity 階層の明示化、と焦点が違います。

entity establishment 速度の非対称

もう一つ書き添えたいのは、entity establishment 速度の非対称です。単店舗の KG entity node は、first citation から sustained citation の phase 移行に 6-12 ヶ月かかります。チェーン店の branch は parent brand の KG entity node に inherit するため、数週間 - 1 ヶ月程度の fast establishment が可能です。

これは「単店舗が努力不足」ではなく、KG entity resolution の architecture 上の非対称です。engineer 側から見ると、単店舗の初期 3-6 ヶ月は third-party review source (食べログ / Google レビュー) の掲載を意識的に厚くする戦略が effective で、KG entity 建立を待つ期間の provenance dispersion を第三者 source が代替します。「代替」といっても KG の 10% がそのまま第三者に流れるわけではなく、第三者 30% が establishment 待ち期間だけ 40-45% に膨らむ、という observed shift です。

チェーン店は逆に、branch 追加時に parent の KG entity 側の branch listing を明示的に更新することで、fast establishment を確定できます。branch 情報が corporate site 側で反映されないまま local franchise page だけ立ち上げても、KG inherit が働かず、single-location と同等の 6-12 ヶ月 establishment period に落ちます。「branch を先に公開して corporate site の更新を後回しにする」という運用は、fast establishment の機会を捨てる自傷行為に近い順序です。

業種別の実装差については 業種オーバーレイ — AI-native MEO は業種でどう変わるか で扱いましたが、業態 (単店舗 vs チェーン) と業種 (飲食 / 美容 / 医療) は独立した 2 axis で、両者の cross-product が実装 pattern を決めます。飲食の単店舗と飲食のチェーンは違い、飲食の単店舗と美容の単店舗も違う、という 2 axis の意識が必要です。

結び — 地殻変動の只中で

私たちが今いるのは、AI アシスタントが「entity 階層をどう認識するか」を四半期ごとに更新している地殻変動の只中です。今日 branchOf が effective に signal されているという observation が、来年も同じである保証はありません。architecture は動きます。

それでも、business structure (単店舗 vs チェーン) が provenance dispersion を systematic に分岐させる、という構造は、entity resolution の architecture がどう動いても、schema.org の @id / branchOf / sameAs の semantics に射影される限り効き続けます。単店舗が 60/30/10 の shape を狙い、チェーン店が 30/30/20/20 の shape を狙う。この 2 shape をそれぞれ意識的に設計するところに、engineer が制御できる変数が集中しています。

「小さな店を大手に負けさせない SEO」を書けば読み手には気持ちいいでしょうが、そうではなく、単店舗もチェーンも、それぞれの provenance shape に沿った設計を最適化する、というほうが実装ロジックとしては正確です。単店舗を informal signal と first-party heavy で設計する engineer と、チェーンを 4 経路 diverse と formal signal で設計する engineer は、同じ AI エンジンを相手に別の game を戦っています。同じルールで殴り合っているのではありません。

地図に日付を入れて渡すことしかできない、というのは正直なところで、それでも地図を持っているほうが、持っていないよりはるかにましだという立場で書きました。

関連記事

• 複数拠点の LocalBusiness を JSON-LD で束ねる三層配線 — チェーン店の JSON-LD 実装 engineering companion、branchOf / parentOrganization / department の 3 pattern
• 三つの出典経路 — AI アシスタントは first-party schema・Knowledge Graph・第三者レビューをどう使い分けるか — provenance 3 経路の framework、業態別 application の上位概念
• Google レビュー vs 食べログ: AI が引く星は誰の? — source axis の comparison、本稿の structure axis と対比
• ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか — engine axis の comparison、本稿の structure axis と対比
• 業種オーバーレイ — AI-native MEO は業種でどう変わるか — 業種 axis の framework、業態 axis と complementary
• Knowledge Graph に自社を配線する — KG entity establishment の engineering 側
• LLMO Framework — Provenance primitive の canonical 仕様
• Open LLMO Research Initiative — Industry Implementations — 業態別 reference implementation 索引