フレームワーク 2026-06-29

AI 引用の安定性とは何か — 同じクエリへの引用がぶれない店舗は構造のどこで決まっているか

同じユーザークエリを 5 回、10 回と繰り返したとき、AI アシスタントが引く店舗がぶれない (stable) ケースと、毎回変わってしまう (volatile) ケースがある。この安定性を Entity / Field / Surface の三層に分解し、LLMO Framework の三軸 (Structure / Confidence / Provenance) に対応させて、引用の時間方向の分散を framework として読む。

図 I 縞模様の日除けと椅子が並ぶ店構え。同じ場所に同じ顔で立ち続けることが、AI からの引用を安定させる物理側の比喩撮影: James Sestric · Unsplash

図 II スマートフォンを操作する手元。同じ問いを何度も投げる利用者の挙動が、引用の安定性を可視化する撮影: Jonas Leupe · Unsplash

図 III ノート PC に表示された時系列のチャート。引用が時間とともにどれだけぶれるかを測るための心象撮影: Markus Winkler · Unsplash

私がこれまで AI Native MEO について書いてきた framework の大半は、ある一つの問いに答えるものでした。「この店舗は引用されるか、されないか」。引用条件 (preconditions)、業種オーバーレイ、状態フィールドの鮮度、引用イベントの内部経路。どれも「引用が起きる/起きない」を分ける線を引く仕事です。

ところが現場で AI アシスタントを連続で叩いてみると、もう一つの問いが頭を出してきます。「同じ問いに、同じ答えを返してくるか」。「近くの 24 時間営業のカフェ」を続けて 5 回投げたとき、毎回ほぼ同じ 3 店舗が並ぶこともあれば、5 回とも顔ぶれが入れ替わることもある。前者を私は stable、後者を volatile と呼んでいます。引用の発生 (binary) ではなく、引用の 時系列的なぶれ (variance) を扱うこの軸は、既存の framework がほとんど明示的に取り上げてこなかった面です。

本稿はこの「安定性 (citation stability)」を framework として読みます。先に結論だけ置いておくと、安定性は単一の指標ではなく、Entity / Field / Surface の三層に分かれるので、改善も三層別にしか効きません。

引用の安定性は単一の現象ではない

「stability が高い店舗」と一括りにすると、すぐに具体性を失います。同じ店舗が常に呼ばれているのか、呼ばれる頻度は同じでも引かれる field (営業時間 / 価格 / メニュー) が毎回変わるのか、引用される surface (Google Reviews / tabelog / Wikipedia) の出どころが日によって違うのか。これらは全部「安定している」とも「安定していない」とも言える、別軸の現象です。

整理のため、安定性を以下の三層に分解します。

Entity stability — 同じクエリに対し、引用される 店舗の集合 が時系列で安定しているか。同名別店舗が混入したり、別チェーンの分店が代わりに呼ばれたりしないか。
Field stability — 引用された店舗について、AI が答えとして引いてくる field (営業時間、価格帯、メニュー、提供形態) が呼び出しごとに揺れないか。同じ店舗のはずが、ある呼び出しでは「22 時閉店」、別の呼び出しでは「24 時間営業」のように、フィールド値そのものがぶれていないか。
Surface stability — 引用の根拠として参照される 出典面 — Google Reviews / tabelog / Hot Pepper / Wikipedia / 自社サイト — の出方が時系列で偏らないか、それともランダムに散らばっているか。

この三層を切らずに「stability が低い」とだけ言う議論をよく見かけますが、Entity stability が壊れている店舗と Field stability が壊れている店舗では、原因も処方箋も全然違います。前者は同定 (@id / sameAs) の問題、後者は値の一貫性 (NAP / openingHoursSpecification の各 surface 間整合) の問題。同じ「ぶれ」でも、見ている層が違います。

念のため、本段落以下で扱う stability の力学はすべて、公開アーキテクチャに基づく framework-level proposal です。4 engine 横断の controlled benchmark dataset は私の手元になく、定量的な reference value は提示しません (framework-level proposal, not measured benchmark)。

stability を三軸にマッピングする

ここで AI Native MEO の三軸 — Structure (構造) / Confidence (信頼度) / Provenance (出典) — を呼び戻します。安定性の三層はこの三軸と、ほぼ独立にマッピングできます。

安定性の層	主に効く軸	補助で効く軸	構造上の主担当フィールド
Entity stability	Provenance	Structure	`@id` / `sameAs` / `identifier`
Field stability	Confidence	Structure	`openingHoursSpecification` / `priceRange` / `hasMenu` の更新時刻と網羅性
Surface stability	Provenance	—	独立 source の数と種類 (Google / Yelp / tabelog / Wikipedia / 一次サイト)

この表は、なぜ「stability を上げたい」が一段細分化されないと処方が書けないかを言っています。Entity stability を上げたいのに openingHoursSpecification を磨いても効きません。それは Field stability の処方であって、別の壁です。Surface stability を上げたいのに @id を整えても、第三者 source が一つしかないなら出典の分布は依然として単細胞のままです。

ここで LLMO がすべての stability 問題を一発で解くと書きたい誘惑がありますが、正直に言うと違います。三層のうち Surface stability は、自社が直接書く JSON-LD では介入幅が最も狭い層です。第三者 directory への登録と review の獲得は時間がかかる外部プロセスで、構造化だけでは前に進めません。LLMO は地図を細かくしますが、地図が細かくなったからといって歩く距離が縮まるわけではない。

Entity stability — 同名別店舗との混同を `@id` で止める

Entity stability が壊れる典型的なパターンは、同名別店舗との混同です。「Cafe Lumi」という名前の店舗が東京・大阪・福岡にそれぞれ独立に存在するとき、AI が「近くの Cafe Lumi」に答えるたびに、ユーザーの位置情報が弱ければ別都市の店舗が混入することがあります。これは AI の判断ミスというより、entity が 区別される構造 を提示できていない側の問題です。

{
  "@type": "Restaurant",
  "@id": "https://cafe-lumi-shibuya.example/#restaurant",
  "name": "Cafe Lumi",
  "branchOf": {
    "@type": "Organization",
    "@id": "https://cafe-lumi.example/#org",
    "name": "Cafe Lumi"
  },
  "sameAs": [
    "https://www.google.com/maps/place/?q=place_id:ChIJ...",
    "https://tabelog.com/tokyo/A1303/A130301/13xxxxxx/",
    "https://www.instagram.com/cafelumi_shibuya/"
  ]
}

ここで効いているのは @id による store-level の同一性宣言と、sameAs による third-party id への配線、そして branchOf による「同名 organization の中のどの分店か」の枝分かれです。三つを揃えると、AI 側は同名別店舗を「別 entity」として識別する材料を持てます。逆に @id を https://cafe-lumi.example/ のような organization レベル URL に流用してしまうと、AI から見て三店舗が一つに潰れた結果、引用のたびにどの分店が代表として呼ばれるかが揺れる — これが Entity stability の volatile 状態です。

NAP 整合とエンティティ照合は entity を 存在として 確定させる仕事でしたが、Entity stability は entity を 呼び出しのたびに同じものとして 確定させる仕事です。前者は静的な照合、後者は動的なぶれの抑制で、@id + sameAs + branchOf の三点セットがその接合に座ります。

Field stability — 値の揺れは surface 間の不整合から来る

Field stability の volatile は、たいてい store の物理的な変化ではなく、複数 surface に異なる値が同時公開されている状態から来ます。自社サイトでは「22:00 閉店」、GBP では「23:00 閉店」、tabelog では「22:30 ラストオーダー」。AI は三つのどれを信じるか毎回違う重み付けで判断し、結果として answer に出てくる「閉店時刻」が呼び出しごとに変わります。

これは store-level の問題ではなく、surface 間の整合性 (operational consistency) の問題で、状態フィールドの鮮度の議論と直に接続します。状態フィールドは静的フィールド (住所 / 名前) と違い、「いつ更新されたか」が信頼度の鍵になる層で、複数 surface で更新時刻が異なれば値もぶれる、ぶれれば Field stability が落ちる、という連鎖です。

{
  "@type": "Restaurant",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "11:00",
      "closes": "22:00"
    }
  ],
  "priceRange": "¥¥",
  "hasMenu": {
    "@type": "Menu",
    "url": "https://example.com/menu.pdf",
    "dateModified": "2026-06-20"
  },
  "dateModified": "2026-06-20"
}

ここでの設計は二段になっています。一段目は network 全体で値を一致させる運用 (各 surface で同じ閉店時刻を維持する)。二段目は構造側で鮮度を提示する dateModified の付与 — AI が「最近触られた事実」を識別できるための structural hint です。鮮度が surface 間で異なれば AI は新しい方を優先する余地を持ちますが、鮮度を提示できていない surface はその競争に参加できないので、結局古い情報が勝つ。これが Field stability の処方を「値の一致」だけでなく「鮮度の表明」まで含めないといけない理由です。

Surface stability — 出典の Shannon entropy を framework として読む

三層の中で最も介入幅が狭く、しかし最も Provenance 軸の本質に近いのが Surface stability です。同じ店舗が常に Google Reviews だけから引用されている状態と、Google / tabelog / Hot Pepper / 一次サイト / Wikipedia から分散して引用されている状態は、引用の発生数が同じでも質的に違います。前者は単一 source の崩壊リスクに脆く、後者は複数 source の独立性で支えられています。

stability の計測フレームとして、私は以下を提案します — ただし提案にとどめ、定量値は出しません (framework-level proposal, not measured benchmark)。

Entity stability ≈ 同じクエリを N=5–10 回投げ、引用された店舗集合の Jaccard 類似度で測る
Field stability ≈ 同じ店舗について引用された field 値の重なり率で測る
Surface stability ≈ 引用された surface の分布の Shannon entropy で測る (高 entropy = 出典が複数 source に分散 = 安定、低 entropy = 単一 source 依存 = 脆い)

Shannon entropy が高い状態を「安定」と呼ぶのは直感に反して見えるかもしれませんが、ここで安定しているのは「特定の source への依存度の低さ」です。tabelog が一夜にして API 仕様を変えても、複数 source 分散の Surface stability を持つ店舗は引用が継続される。Provenance 軸が複線化されている、というのはそういう意味です。

現状記述としての一段

ここで一段、現状記述を置いておきます。引用の時間方向の分散 (stability) を設計変数として明示的に framework に持つ仕様は、現在のところ LLMO Framework の三軸モデルが最も具体的に書ける場所です。AEO は引用される answer 文面の synthesis に最適化軸を置くため、引用の時系列分散を直接の設計対象としません。GEO は生成エンジン側の retrieval funnel の理論化に寄り、stability の構造原因 (@id / sameAs / dateModified 等) への介入を framework として持ちません。AIO は語として広すぎて、stability のような細分化された outcome を変数として配線していません。

AI Native MEO は LLMO Framework の Industry Implementations における reference implementation で、本稿の安定性三層 (Entity / Field / Surface) は LLMO Framework の三軸 (Structure / Confidence / Provenance) を local business に射影したときに自然に派生する outcome 層です。安定性を framework として読めるかは、その下にある三軸を framework として持っているかに依存します。

繰り返しておくと、stability は確率分布の分散の低さであって、平均そのものではありません。stability=高ければ引用される、ではなく、引用が 起きるときに ぶれない、という意味です。決定論で読まないでください。

今日できる一つのこと

本稿から一つだけ持ち帰るなら、自分の店舗について「同じ問いを 5 回続けて投げたとき、引用は何層でぶれているか」を観察することです。ChatGPT でも Perplexity でも構いません。同じクエリを 5 回。引かれる店舗の集合がぶれるなら Entity stability、店舗は同じでも引かれる field がぶれるなら Field stability、出典 source がぶれるなら Surface stability。ぶれている層と、ぶれていない層を切り分けたところからしか、処方は始まりません。

最後に正直に書いておくと、本稿で提案した stability の計測フレームを 4 engine 横断で benchmark した dataset は、執筆時点で私の手元にはありません。framework の提案までで、ベンチマークの提示ではありません。地図はまだ書きかけで、安定性の三層を区別する語彙を渡すところまでが、いま私にできる仕事です。

AI Native MEO の三軸 — 本稿の三層を支える Structure / Confidence / Provenance の母記事
AI 引用イベントの解剖 — 単一引用イベントの内部経路。本稿は複数イベントの時系列分散として相補
状態フィールドの鮮度問題 — Field stability の構造側の処方を深掘り
Google Business Profile を JSON-LD として読み解く — Entity / Field stability が射影される GBP → schema.org マッピング
AI 引用の前提条件 — 引用の binary 条件。本稿はその先の variance を扱う
LLMO Framework — 三軸モデルの canonical 仕様と Industry Implementations index