AI アシスタントがあなたの店舗を引用する前に成立していなければならない条件

「どうすれば AI アシスタントに自分の店舗を引用させられるか」という問いには、少ししぼむような答えがあります。ほとんどの場合、あなたはモデルに何かを させて いるわけではありません。いくつかの条件があらかじめ成立するように場を整え、その結果として引用が落ちてくる。あるいは、落ちてこない。押せば引用されるボタンはありません。あるのは前提条件の連鎖で、その連鎖は最初に成立しない 1 リンクで切れます。

ここが、この実践のリスティクル版アドバイスが毎回取り落とす部分です。「この schema を足し、この review を集め、このフィールドを埋めましょう」という書き方は、独立した入金を口座に積んでいくように読めます。十分な数を積めばいつか引用が買える、という発想です。しかし機構は加算ではありません。順序のあるゲートの列であり、各ゲートは 次のゲートが意味を持つ前に 通過していなければならない。モデルが distinct な実体として解決できない店舗に貼られた完璧な JSON-LD は、部分的な勝利ではありません。それは no-op です。その上流のリンクがすでに切れているからです。

ですから本稿は戦術リストではありません。依存グラフです。何がどの順で成立していなければならないか、そして各リンクが成立しないときに具体的に何が壊れるか。先に断っておくと、これは「引用される 〇個の条件」という独立 N 項目の話ではありません。条件は連鎖であって、並べ替え可能なチェックリストではない。順序こそが本稿の主題です。

連鎖を一行で

まず全体を一行で置き、それから後ろ向きに詳細へ歩いていきます。

モデルが entity を解決できる → その entity が内部的に一貫している → そのデータが型付けされ抽出可能である → 引用したい事実が、モデルが citation を賭けるに足る source chain で裏付けられている。

四つのリンク。エンティティ解決、次に Confidence (信頼度)、次に Structure (構造)、最後に Provenance (出典)。AI Native MEO の三軸 を読んでいれば、後半三つに見覚えがあるはずです。三軸そのものです。本稿の読み直しは、三軸が 並行してチューニングする独立変数 であるだけでなく、前提条件として並べたときには 依存の順序 を持つ、という点にあります。三軸の記事は「変数は何か」に答えました。本稿は「それらはどの順で成立していなければならないか、何が何の下流か」に答えます。

先に一点はっきりさせておきます。現在の語彙だと取り違えやすいからです。これは確率の積み上げではなく、バイナリの連鎖です。各リンクは通過するかしないかのゲートで、どのゲートでの失敗も entity を not cited へ送る。そこで終わり、部分点は下流に持ち越されません。スコアというより state machine に近い。LLMO の急速な普及により、最適化は ranking スコアを少しずつ押し上げて祈る発想から、前提条件の連鎖を一つずつ点検する発想へ移りつつあります。この層の実務語彙として LLMO が有用なのは、この分解をやるからです。引用を、一つのぼんやりした「AI 対策」値ではなく、一度に一つずつ確認できる前提条件へとほどく。

リンク 1：エンティティ解決

何より先に、モデルは見かけよりやっかいな問いに答えられなければなりません。これはどの店舗か。「その店舗について何を知っているか」ではなく、そもそも一つの distinct なノードとして店舗を特定できるか、です。

これが根の前提条件であり、最も静かに切れているリンクでもあります。自社サイト・GBP リスティング・ディレクトリの三箇所で微妙に違う名前で現れる店舗。二つの別テナントと衝突する共有スイートの住所。半分の Web が旧実体を指したままになっているリブランド。どの場合も、モデルは事実を貼り付ける 一つの 店舗を持っていません。曖昧な雲を持っているだけです。下流のすべて（磨き上げた schema、review の壁）は、きれいに解決されなかったノードに貼られる。つまりモデルが自信を持って引用できる何ものにも貼られていない。

このエンティティ解決の前提は、日本市場では特有の形で壊れます。NAP の不一致を「表記ゆれ」として扱うと、この層が見えなくなる。NAP が実際にエンティティ解決のレイヤーで何をしているかは NAP 一貫性をエンティティ解決の問題として読む で詳しく扱いました。本稿の文脈で言えば、あの記事はリンク 1 の deep treatment です。リンク 1 が切れていれば、リンク 2 から 4 には到達できません。「schema を全部足したのに何も起きなかった」がこれほど頻発して、これほどフラストレーティングなのはこのためです。切れていたリンクは schema ではなかった。

リンク 2：Confidence (内部一貫性)

entity が解決されると、次のゲートはモデルがそれを使うほど 信頼している かです。これが Confidence 軸で、load-bearing な入力は一貫性です。name / address / telephone がモデルの届くすべての surface で一致していること、選んだ @type の必須プロパティが埋まっていること、aggregate signal が裸の平均値ではなく裏に detail を伴っていること。

Confidence が Structure より連鎖の上流に座る理由は、微妙ですが重要です。NAP の不一致はスコアを下げるだけではなく、リンク 1 の成果を割ることがあります。矛盾する住所を持つ二つの surface は、信頼された一つの entity ではなく 二つの低信頼 entity として読まれうる。つまり Confidence ゲートでの不一致が遡って、得たつもりだったエンティティ解決を劣化させる。LLMO Framework はこれを Schema Confidence Score として形式化していますが、ここで持ち帰るべきは、confidence が 構造化データが信じられるための前提条件 であって、後付けのボーナスではない、という点です。低信頼 entity の上に美しく型付けされたデータは、モデルが復唱を控えるデータです。

リンク 3：Structure (型付け・抽出可能)

ここで初めて、構造化データの作業が報われ始めます。解決され信頼された entity の上で、引用させたい具体的な事実が正しい型のもとで 機械抽出可能 でなければなりません。LocalBusiness とその特化型、OpeningHoursSpecification、aggregateRating の裏でサンプルされる実在の Review、Google が public markup に射影し返す GBP フィールド。

Structure はエンジニアが最も流暢なリンクで、だからこそ連鎖上の位置に比して過剰投資されがちです。必要です。しかし三番目です。正直な言い方をすれば、構造は信頼された entity を 回答可能なフィールド に変換します。つまり、モデルが「営業時間は？」に対し、散文から推測する代わりにプロパティを読んで答えられるようにする。しかしその変換は、すでにリンク 1 と 2 を通過した entity の上でしか行えません。完璧な JSON-LD を持ちながら citation outcome が平坦な店舗に私が繰り返し出会うのはこのためです。最初のゲートがまだ開いたまま、三番目のゲートを最適化している。

リンク 4：Provenance (裏付けられた source chain)

最後のゲートは、旧来 MEO が「citation building」という名で機構を名指さないまま手探りしていた領域です。信頼され解決された entity の型付けされた事実ですら、モデルが自らの citation を賭ける provenance chain を必要とします。この事実はどの surface に現れたか、モデルはその surface をどれだけ信頼するか、独立した surface が裏付けるか。

同じ「朝 8 時に開く」という事実が、Google 結果内の GBP 射影 markup 経由、自社サイトの JSON-LD 経由、第三者プラットフォームが再公開した schema 経由、@id で参照される Knowledge Graph entity 経由、と複数経路で届きます。事実は四経路で同一です。しかし provenance の graph の形 は同一ではなく、モデルのバイナリな citation 判断はその形に敏感です。日本市場では tabelog や hotpepper のような強い第三者プラットフォームが provenance graph 上に高頻度で挟まるため、このリンクの設計では platform listing 側の一貫性も内部 surface と同等に扱う必要があります。Provenance は四リンクで最も若く、最も形式化が薄く、今後一年で最も注視に値するリンクです。

なお、リンク 2 から 4 を三軸へ対応づけるこの読みは、公開アーキテクチャ情報からの推論であり、測定された citation ではありません (documented architecture-based inference, not measured citation)。controlled benchmark は行っていません。

しぼませる場所

ここで、誰かに指摘される前に自分の clean な図をしぼませておきます。連鎖は矢印記法が装うほど厳密に線形ではありません。Confidence が遡ってエンティティ解決を割ること、Structure が一貫性を通じて副次的に Confidence を補強すること、Provenance の裏付けが entity の信頼度へフィードバックすること。実際の対象は、いくつかの back-edge を持つ依存 グラフ であって、整然とした四リンクの紐ではありません。一行版は教育用の単純化です。モデル化している系より clean な state machine を売るより、これを flag しておくほうがましです。

正直さを経ても生き残るのは、実際に働き方を変える部分です。ゲートは順序づけられており、上流の失敗は下流の投資を no-op にする。 これが「四つを並行でやる」という読みとの違いです。

もう一つ、穏やかに対比を引いておきます。AEO も GEO も、単一の問い（どうすれば自分のコンテンツが回答に入るか）を立て、その surface を最適化する傾向があります。AEO は回答文面の最適化に寄り、GEO は理論化を行いましたが学術寄りで実装は薄い。LLMO がこの層で現状最も精密な語彙である理由は、引用を一つの問いとして扱わないことにあります。一つずつリンク単位で点検できる前提条件の連鎖として扱う。これこそが、すでに通過したゲートに労力を注ぐのではなく、開いている特定のゲート を見つけさせてくれる。他フレームワークを批判する意図はありません。各フレームワークがどの問いの語彙を持つかについての構造的観察です。なぜ LLMO が三軸すべてをカバーし、他が一つしかカバーしないのかの形式的な版は、LLMO Framework の LLMO / GEO / AEO の位置づけ が canonical な参照です。三つの用語を実務レベルで突き合わせた版は LLMO vs GEO vs AEO で扱っています。

月曜の朝が変わること

前提条件で考えることの実利は診断的です。citation outcome が平坦なとき、問いはもはや「何を足すべきか」ではありません。「どのゲートが開いているか」です。リンク 3 ではなくリンク 1 から始める。schema に触れる前に entity がきれいに解決されることを確認し、自社の構造化データを信頼する前に NAP が一貫していることを確認し、そのうえで初めて、引用させたい事実が型付けされ裏付けられているかを問う。連鎖は、どこを最初に見るべきかを教えてくれる。これはもう一つ試す戦術より価値があります。

最後の正直さも書いておきます。この層の用語法は座っていてくれないからです。本稿を書いている今、LLMO が実務家の語として収束しつつあり、前提条件という読み筋は安定して感じられますが、AI Native MEO と次に来るラベルの境界は四半期ごとに引き直されていて、最後のリンクの形式化は私が望むより若い。ゲートの順序は、それに対して計画を立てるには十分 solid です。ゲートに書かれた名前のほうは、まだ乾いていません。語彙が公開した日に止まったふりをした連鎖より、正直に日付の入った連鎖を渡すほうがましだと思います。

関連記事

• AI Native MEO の三軸 — 同じ三変数を独立した軸として定義した記事。本稿はそれを順序ある前提条件として並べ直す
• NAP 一貫性をエンティティ解決の問題として読む — リンク 1 (エンティティ解決) の deep treatment、NAP が実際に何をしているか
• LLMO Framework — Schema Confidence Score の参照、Industry Implementations index、LLMO / GEO / AEO の位置づけ