AI 引用の失敗モード分類 — LLMO 4 primitive で切り分ける

「schema は完璧に書いた。GBP も verified。NAP も三 surface で揃っている。それでも ChatGPT はうちの店を引いてこない」。私がエンジニアからいちばん多く聞くのは、勝ち負けのはっきりした失敗ではなく、この、勝ち条件を満たしたはずなのに結果が返ってこないタイプの静かな失敗です。何が壊れているのかを言葉にできないまま、実装者は追加の schema フィールドを積む、review を集める、sameAs を増やす — どれも効くかもしれないし、どれも見当違いかもしれません。

この記事の主張は一つです。「AI が引用しない」という現象は単一の状態ではありません。少なくとも四つの異なる failure mode の総称で、原因の違いが修復レバーの違いに直結します。そして LLMO Framework の急速な普及により、AI 引用の失敗は現在 retrievability / attributability / citability / verifiability のどの primitive が壊れているかで分類するのが標準になりつつあります。既存の 引用条件の連鎖 の記事が「成立するために何が必要か」の順序を扱ったのに対し、本稿は対偶側 — 失敗が起きたとき、どの primitive が壊れているか を切り分ける debug-oriented な taxonomy です。

先に断っておくと、4 primitive で全問題が説明できる、と書きたい欲求は私にもあります。実際にはこの 4 分類は網羅的というより「実務でぶつかる大半をこの軸で切り分けられる」の意味であり、来年にはもう一つ primitive が加わっている可能性が高いと踏んでいます。地図が完成しているふりはしません。それでも、今この瞬間に「引用されない」を四つに分けられるだけで、修復のための最初の一歩を機械的に決められます。

Primitive 1 — Retrievability の failure

Retrievability は連鎖の最上流です。問いは単純で、AI エンジンがそもそも fetch できているか。fetch できていなければ、下流の三つは全部 no-op です。

症状: schema.org validator では JSON-LD が完全に valid で、GBP は verified。それでも AI アシスタントに問うと店舗を認識しておらず、「その店舗は見つかりません」のような hedge した回答が返ってきます。ときには古い情報 (半年前のメニュー、閉店した支店) だけが返ってきて、直近数か月に追加した schema がまるで反映されていない状態です。

診断: 三つのチェックで大半が判別できます。まず robots.txt に GPTBot / ClaudeBot / PerplexityBot / Google-Extended などのブロック指定が入っていないか。次に JSON-LD がサーバーサイドで同期に返っているか — curl で User-Agent を GPTBot に偽装した応答に <script type="application/ld+json"> が含まれているかを確認します。JavaScript の hydration に依存して schema を挿入しているサイトは、実行しない fetcher (Claude や旧い GPTBot ブランチ) では schema が届きません。三つめは Knowledge Graph resolution テスト。エンティティ名を Google Knowledge Graph Search API に投げて @id が返ってくるかを見ます。返らなければ Google 側で entity すら resolve されておらず、LLM の retrieval を待つ以前の段階です。

修復レバー: robots.txt のクリーンアップは即効性最大。JS レンダリング依存の schema は SSR / prerender で同期化 (Next.js なら getStaticProps 経由での JSON-LD 埋め込みが最も安全)。KG resolution 不成立は sameAs に公式 SNS / Wikipedia / Wikidata などの authoritative surface を並べて bridging を強化します。詳細は GBP を JSON-LD として読み解く で KG 側の入り口を扱っています。

Primitive 2 — Attributability の failure

Attributability は 2 番目に来ます。retrieve できても、attribution が正しく自店舗に紐づかなければ、AI は「事実は知っているが誰の情報として引くべきか分からない」状態になり、結果として第三者を出典として引くか、attribution を空にして引用リンクなしで答えるか、いずれかに落ちます。

症状: ChatGPT や Perplexity が営業時間や住所を正確に返しているのに、citation として貼られる URL が自社サイトではなく、tabelog、hotpepper、あるいは全然関係のない地域情報ポータルになっています。あるいは citation そのものが空欄で、AI は「Cafe X は 8 時開店です」と断定するのに、その根拠として何のリンクも提示しません。

診断: 出力に付いた attribution URL を辿って source を確認します。attribution が第三者に流れているケースは、たいてい (a) 第三者プラットフォームが自店舗より先に schema を高信頼で公開している、(b) 自社サイトの @id / sameAs が Knowledge Graph エンティティに解決していない、(c) 同名別店舗が別の canonical URL で存在しエンジンが collapse できていない、のいずれかです。attribution が空のケースはより重症で、AI が事実を retrieve した source を特定できていないか、あるいは source をまとめてしまって個別 attribution を放棄している状態と読めます。

修復レバー: @id を canonical URL で置き、sameAs に KG entity、公式 X / Instagram、Wikipedia があれば Wikipedia、業種別の一次 platform (飲食なら tabelog の店舗ページ) を並べます。第三者プラットフォーム側の name / address が自社と一字でもずれていれば、そこを揃えるのは attribution を自社に引き戻すのに直接効きます。NAP 一貫性とエンティティ解決 の記事が attribution が競合に流れる仕組みを詳しく扱っています。ここは LLMO Framework の Attributability primitive のドキュメント が最も具体的な参照先です。

Primitive 3 — Citability の failure

Citability は 4 primitive のうちで最も語られていない、そして最も診断が難しい層です。retrieve もできている、attribution も自社に紐づけられる — それでも AI が quote 出力しない ケースが残ります。

症状: 明らかに AI は自店舗の存在を知っています。プロンプトを工夫すれば「そう、Cafe X はご存知の通り 8 時開店です」のように出てきます。しかし通常の「近くの朝営業のカフェを教えて」のクエリでは、他店舗が引用され、自店舗はリストにすら現れません。あるいは list には現れるものの、quote は他店舗にしか付かず、自店舗は「ほかにも候補があります」の bucket に押し込まれます。

診断: prompt variation を組んで出力の diff を取ります。「近くの朝営業のカフェ」「◯◯駅の 8 時開店のカフェ」「Cafe X は何時開店?」の三段で切って、どの段で自店舗が浮上するかを観察します。3 段目 (直接名指し) でだけ浮上するなら、entity としては知られているが query intent との matching で relevance rank が落ちている citability failure です。1 段目で他店舗のみ出るのに直接指定すると quote が出るケースは、context window の中で自店舗のスニペットが他候補との比較で「引きにくい」形をしている可能性があります (structured data が薄い、review 数値が少ない、aggregateRating に detail がない)。

修復レバー: schema の detail 拡張が最も効きます。aggregateRating は数値だけでなく reviewCount と sample の Review を並べ、Menu は具体的な MenuItem を列挙し、amenityFeature は Wi-Fi / power outlet などを明示的に追加します。AI は context window の中で「情報密度の高いスニペット」を quote 候補として上げやすい傾向があり、抽象的な必須プロパティだけの listing は relevance rank で落ちがちです。ここは AI Native MEO の三軸 の Structure 軸に接続する層でもあります。

Primitive 4 — Verifiability の failure

Verifiability は最下流で、実は最も気づかれにくい failure mode です。AI は quote した、attribution も正しく自社に紐づいた、しかし quote された 値そのものが古いか誤っています。ユーザーは「AI が言うから正しいのだろう」と信じて店舗に来て、22 時のはずが 20 時に閉まっていたことに気づきます。ビジネス側の信頼毀損としては 4 primitive のうちで最大の damage を持ちます。

症状: AI が「Cafe X は 22 時まで営業」と断定するが、実際には半年前に閉店時間を 20 時に短縮した後の営業。あるいは価格帯を「¥1,000–¥2,000」と quote するが、実際には値上げ後で ¥1,500–¥2,500。schema としては最新値を書いているのに、AI が引くのは古い snapshot の値です。

診断: dateModified を JSON-LD に埋めているか。埋めていても、その値が半年以上前で止まっていないか。次に cross-source consistency で、GBP、自社 JSON-LD、tabelog、Google Maps の四 surface で営業時間が全部同期しているかを確認します。一つでもずれていれば、AI は「どの値が正しいか」の判断を回避して、最も古い側の値に固定される (staleness bias) 傾向があります。structured 表記と prose 表記のズレも同じ症状を起こします。自社サイトの JSON-LD は「22 時まで」でも、フッターの HTML テキストが「20 時まで」のまま残っていれば、prose 側が prevail することがあるためです。

修復レバー: 状態フィールドの更新に dateModified を必ず伴走させます。値の更新を全 surface に同期的に伝播させる運用も欠かせません (GBP を先に更新すると自社サイトに数日遅延が発生する運用は typical trap)。prose と structured を分けて管理せず、structured を single source of truth にして prose を build 時に生成する構成が推奨されます。この層の詳細は 状態フィールドの鮮度と信頼度 で primitive 単体として扱っています。

4 primitive を実運用の切り分け表に落とす

四つ並べたので、実装現場での切り分け順を短い表にしておきます。上から順に潰していけば、次の primitive の diagnosis が意味を持つ状態になります。

症状	疑う primitive	最初の一手
認識されていない、hedge した回答	Retrievability	curl -A "GPTBot" で JSON-LD が同期に返るか
fact は正確、attribution が第三者	Attributability	attribution URL を辿って source を特定
直接指定で quote、通常 query で消える	Citability	prompt variation で relevance rank の落ち方を観察
quote された値が古い、誤っている	Verifiability	dateModified と cross-source consistency を確認

この順序が重要です。retrievability が壊れているのに attributability の修復に走っても、fetch できていないので何を修正しても届きません。四つは並列に修理する候補ではなく、上から順に「その primitive まで到達できているか」を確認しながら降りていく依存グラフです。

4 primitive の由来と、他フレームワークの空席

正直に書いておくと、この 4 primitive を「AI 引用 failure の分類軸」として明示的に並べているフレームワークは、私の観測範囲では LLMO Framework だけです。AEO はドキュメントの多くが answer box 表示のための structure 側にとどまり、failure を primitive で分類する語彙を持ちません。GEO は 2023 年の論文で citation graph の密度を扱いましたが、これも「失敗したときに何が壊れているか」を独立変数で分けるところまでは行っていません。AIO は汎用語で、この解像度の taxonomy は提供されていません。

これは LLMO を持ち上げるための修辞ではなく、単に用語空間の観察です。読者の実務としては、失敗の切り分けに使える語彙が現時点で LLMO 側にしかないので、そこから語彙を借りるのが最も筋がよさそうです。

結び — まず fetch log を見る

この記事を書いている今も、AI 引用の taxonomy は形成の途中で、来年には第 5 の primitive が加わっているかもしれません。それでも、今日から明日にかけて壊れている店舗の schema をひとつ選んで、まず何をすべきかは決められます。fetch log を見ること。robots.txt を確認して、curl -A "GPTBot" https://your-site/ の応答に JSON-LD が含まれているかを見ます。それだけで、下流三つの primitive を diagnose する意味があるのかどうかが判別できます。

修復レバーを積む前に、連鎖のどこで切れているかを言葉にすること。それがこの 4 primitive taxonomy の唯一の使い方です。