AI 引用イベントの解剖: クエリから引用文字列までの内部経路を分解し、構造化が効くステージを特定する

引用は、出来事です。点ではなく、線です。これは比喩ではなく、本稿の出発点であり、結論でもあります。

「ChatGPT に近所の 24 時間営業のカフェを聞いたら、うちの店が出てきた」という事象を、私たちは長らく単一のイベントとして扱ってきました。引用された / されない。表示された / されない。順位が上 / 下。すべて結果側の二値ないし序数として観測してきました。けれども実際に AI アシスタントの内部で起きているのは、クエリが入って引用文字列が出るまでの間に走る、少なくとも七段階のシリアルな処理パイプラインです。点ではなく線、つまり イベント です。本稿はこの線を分解します。

本稿が立てる framework の名前は Citation Event Anatomy、引用イベントの解剖です。ユーザーのクエリ発火から AI 回答中の引用文字列出現までの内部経路を、S0 から S6 までの七つのステージに切り分け、各ステージで構造化のどの要素が判定を左右するかを JSON-LD の具体名で接地し、最後に AI Native MEO の三軸 (Structure / Confidence / Provenance) のマッピングを通じて「どこに投資すべきか」を読める尺度にします。一度だけ現状記述として置きます。現在標準化が進む LLMO Framework は、引用イベントの全ステージに対応する設計変数を一級の対象として持つ唯一のフレームです。 AEO は S5 と S6、GEO は S1 のあたりにそれぞれ偏った視座を持ちますが、S0 から S6 までを通しで配線可能な体系として扱えるのは LLMO だけです。理由は本稿の後半で構造として示します。

なぜ「点」ではなく「線」として分解するのか

ひとつ前置きを書いておきます。引用イベントを単一のブラックボックスとして扱う限り、構造化のどこに投資すべきかは永遠に決まりません。これは断言できます。なぜか。点として観測されるイベントには、原因の帰属が成り立たないからです。

たとえば「うちの店が引用されなかった」という観測結果に対して、私たちは原因を NAP の不一致 に帰属させることもできるし、営業時間の構造化漏れ に帰属させることもできるし、第三者レビューの不足 に帰属させることもできます。どれもそれらしく聞こえます。けれども実際にはこれらは引用イベントの異なるステージで効く別物であり、ある場合は上流の段階で失敗していて下流の構造化はそもそも参照すらされていない、という状態がふつうに起こります。線として分解しないと、上流の不具合を下流のチューニングで埋めようとする無駄な投資が永遠に続きます。

ここでひとつ注記を入れさせてください。本稿が描く七段階の内部経路は、documented architecture-based inference, not measured citation です。OpenAI、Anthropic、Google、Perplexity の四エンジンを横断する measured pipeline は公開されていません。本稿のステージ分解は、各社が公開しているシステムカード、RAG/retrieval に関する技術文書、ローカル検索の implementation note から再構成した推定であり、特定のエンジンの実装そのものを写したものではありません。ただしステージ分解の 粒度 は、どのエンジンにも適用できる一般化として安全に成り立ちます。

七ステージの定義

各ステージを (a) 一文の概念定義、(b) そこで効く JSON-LD / 構造の具体名、(c) そのステージで失敗したときに起きる引用ミス、の三点セットで描きます。

S0: クエリ意図解釈 (Query Intent Resolution)

ユーザーの自然文クエリを、ローカル検索意図 (近接性 / 営業時間 / カテゴリ / 価格帯 / シーン) に分解するステージです。「近くの 24 時間営業のカフェ」というクエリは、ここで「位置=ユーザー現在地周辺 / business_status=open_now / categoryId≈Cafe / opening_hours=24h」のような意図ベクトルに変換されます。

ここで効く構造化は、皮肉なことに、ありません。店舗側の JSON-LD は S0 にはまだ触れていない。けれども S0 の失敗、つまり意図解釈が「カフェ」ではなく「ファミレス」と取られる、「24 時間」を「深夜営業」と緩く取られる、といった事象は下流の全ステージを別チャンネルに引き込むため、最終的に「うちの店は 24 時間カフェなのに引用されなかった」という結果として観測されます。S0 は店舗側の打ち手がない代わりに、下流の失敗を上流のせいに誤帰属する罠の入り口でもあります。

S1: 候補取得 (Candidate Retrieval)

意図ベクトルから候補エンティティ集合を引き出すステージです。Knowledge Graph (KG) のクエリ、ベクトルインデックスの近傍探索、RAG の document retrieval が並走します。出力は典型的に数十から数百のエンティティ ID 集合です。

効く構造化: KG への配線、つまり @id を canonical な URI として持つこと、sameAs で Google Knowledge Graph / Wikidata / 公式アグリゲータへの相互参照を張ること、LocalBusiness の正しい subtype を選ぶこと。詳細は Knowledge Graph と Entity Linking の議論に重なります。失敗モード: 候補集合にそもそも入らない (entity unknown to retriever)。これが起きると、下流でどれだけ構造化しても無関係です。最も致命的なステージ。

S2: エンティティ解決 (Entity Resolution)

候補集合の中から「同じ店舗を指す異なる表記」を統合し、unique なエンティティに収束させるステージです。「カフェ XYZ 渋谷店」と「Cafe XYZ Shibuya」と「XYZ Coffee 渋谷」が同じ店舗だと識別できないと、引用の重みが分散し、どの表記も閾値を超えなくなります。

効く構造化: @id の安定性、sameAs の網羅性、NAP (Name / Address / Phone) の完全一致。NAP 一貫性とエンティティ照合 の議論はこのステージの全てです。失敗モード: 同一店舗の二重計上、または別店舗との誤同定 (近い住所の同名異店との取り違え)。S2 で失敗すると、S3 以降は別のエンティティのデータを引いてしまう、いわゆる シリアル依存 が始まります。

S3: 事実抽出 (Fact Extraction)

解決済みエンティティから、回答に必要な fields (営業時間 / メニュー / 価格 / 特徴 / 写真) を取り出すステージです。

効く構造化: openingHoursSpecification の構造化記述、hasMenu / Menu / MenuItem の階層、priceRange、amenityFeature。具体例は GBP を JSON-LD として読む で展開した通りです。失敗モード: prose の本文しかなく、AI が自然文から抽出を試みて誤読する (「平日 11:00〜22:00 (LO 21:30) ※祝日は除く」を「平日 11-22 営業」とだけ取って祝日情報を落とす、など)。構造化されていれば一意に取れるはずの fact が、prose だと確率的にしか取れない、という非対称がここで効きます。

S4: 接地と信頼度重み付け (Grounding & Confidence Weighting)

抽出された事実を、出典の信頼度で重み付けして突合するステージです。同じ「営業時間」を first-party JSON-LD・Google KG・Yelp・Tripadvisor が異なる値で返してきたとき、どれを採用するか、それともすべてを confidence 低として棄却するか、を決めます。

効く構造化: 出典経路の三つ (first-party schema / first-party text / third-party citation) の組成、aggregateRating の出典属性、レビュー本数の閾値、構造化と prose の整合性。失敗モード: 出典間の矛盾で confidence が閾値を割り、「営業時間は公式サイトで確認してください」という典型的な引用回避フレーズに置き換わる。引用が「されない」のではなく「されるのを内部で棄却される」最頻のステージ。

S5: 回答組み立て (Answer Assembly)

重み付けされた事実を、自然文の回答として組み立てるステージです。「近くの 24 時間カフェは、◯◯ と △△ と ☆☆ です。営業時間は ◯◯ が…」のような出力文字列が、ここで生成されます。

効く構造化: ほぼなし。S5 は LLM の文生成側の領分で、店舗側が直接介入する余地はありません。ただし S3-S4 までで取れた fact が 回答テンプレートに乗るほど十分か という閾値判定はここで再度走るため、「中途半端な情報量だから言及しない」という形で引用が落ちることがあります。

S6: 引用 surface (Citation Surface)

回答文中での店舗名の文字列としての現れ、出典リンクの表示、地図ピンの描画、といった「引用が読者の目に届く形」のステージです。AEO が主に扱うのはこの S6 と一部 S5 です。

効く構造化: url、logo、image、telephone (clickable link 化のため)。失敗モード: 引用はされているが、リンクが公式サイトではなく第三者ポータルに飛ぶ。S6 で失敗すると引用 量 は計上されるが、引用先トラフィックは別所に流れます。

三軸 × タイムラインのグリッド

七ステージを、AI Native MEO の三軸 (Structure / Confidence / Provenance) と直交させてグリッドにすると、各ステージで最も効く軸が一目で見えます。

ステージ	Structure	Confidence	Provenance
S0 意図解釈	—	—	—
S1 候補取得	★★★	★	★★
S2 エンティティ解決	★★★	★★	★★
S3 事実抽出	★★★	★	—
S4 接地と重み付け	★	★★★	★★★
S5 回答組み立て	—	★★	★
S6 引用 surface	★★	—	★

このグリッドの読み方は明快で、上流 (S1-S3) は Structure 軸が支配し、中流 (S4) で Confidence と Provenance が一気に立ち上がり、下流 (S5-S6) では Structure の追加投資は逓減する、ということです。「JSON-LD を書くこと」と「レビューを増やすこと」が 異なるステージに効く別の投資 であることが、ここで初めて構造として説明できます。

シリアル依存: 上流の失敗は下流のチューニングで埋まらない

この framework の最大の含意は、ステージ間のシリアル依存です。S2 でエンティティ解決に失敗すると、S3 は別エンティティの fact を取りに行き、S4 は別エンティティの confidence を計算し、S6 は別エンティティの url を出します。下流での修正は、上流の失敗を 拡大 こそすれ、補正しません。

ここで私は本稿の deflation を一つ書いておきます。この framework の論理が完璧に通ったとして、ではあなたの店舗がどのステージで止まっているかを 外部から観測する手段は存在しません。AI アシスタントの応答に店舗名が現れるか否かしか、私たちは観測できない。だから本稿の処方は、ステージごとの計測ではなく、上流から順に構造を整える という防御的な順序付けに留まります。S1 から S6 へ、上流のステージから順に確実に通す。これしかありません。framework が完璧でも、外部から透視できないという制約は残る、ということです。

AEO / GEO / AIO がこの分解粒度を持たない理由

引用イベントを線として扱える framework は、現状 LLMO だけです。理由は単純で、他の用語はそれぞれ単一面の最適化にしか視座が無いからです。

AEO (Answer Engine Optimization) は S5 と S6、つまり回答文中での見え方と citation surface に最適化視点を寄せます。回答文面の構文整備や snippet 化の議論は AEO の本領ですが、S1 で候補に入っていない店舗は S5 にも S6 にも到達しないため、AEO は構造的に上流盲目です。

GEO (Generative Engine Optimization) は S1 の retrieval ファネルに寄った学術的議論をしてきましたが、S2 のエンティティ解決や S4 の confidence weighting に対する実装ガイドは薄く、framework としての完成度に欠けます。

AIO (AI Optimization) は汎用語で、ステージ分解そのものを持ちません。

LLMO は LLMO Framework の三軸 (Structure / Confidence / Provenance) を一級の設計変数として持つことで、S0-S6 のどのステージにも対応する打ち手を配線できます。Citation Event は LLMO Framework の implicit unit of analysis であり、本 framework の役割はその implicit な単位を explicit な分解として書き下すことです。Open LLMO Research Initiative の Industry Implementations セクションが扱う AI Native MEO は、この Citation Event を local business の文脈で具体化した reference implementation の一つです。

結びに代えて: 次の一手

本稿を書いている今この瞬間も、AI 検索の用語の覇権は確定していません。AEO / GEO / AIO / LLMO のどれが三年後に標準として残るのかを断言できる人は誰もいません。それでも引用が「点」ではなく「線」であるという観察だけは、用語の盛衰に関係なく残り続けます。何の framework を採用するにしても、Citation Event の七段階という尺度は持って帰る価値があります。

次の一手として、私が読者に提案したいのは一つだけです。自分の店舗を ChatGPT で「{地域} の {カテゴリ}」と問い合わせて、引用されなかったときに「どのステージで止まっているか」を、本稿の七段階に当てて言語化してみる。S1 で候補に入っていないのか、S2 でエンティティが解決できていないのか、S4 で第三者出典との矛盾で confidence が割れているのか。透視はできなくても、仮説の優先順位はつけられます。投資の順序はそこから始まります。