三つの出典経路 — AI アシスタントは first-party schema・Knowledge Graph・第三者レビューをどう使い分けるか

ある居酒屋についての事実があります。この店は 17 時に開く。この一文に真実は一つしかありません。けれど AI アシスタントがその事実をユーザーに返すまでに、たった一つのこの事実は、まったく別の三つの経路のどれかを通ってモデルにたどり着いています。事実は同じです。経路は違う。そして引用されるかどうかの判断において、経路のほうが事実そのものよりも多くの仕事をしている、というのが本稿の出発点です。

ここは、経験を積んだローカル検索の実務者ほど戸惑う部分です。古い頭の使い方では、事実は事実でした。営業時間を正しくして、どこでも揃えておけば、それで仕事は終わり。新しい現実では、その事実がどこから来たかは、その事実が正しいかどうかとは別の変数で、AI アシスタントはこの二つを独立に評価します。本稿では、ローカルビジネスの事実が通りうる三つの provenance 経路を定義し、いくつか固定した軸に沿って正直に比べ、そして——誘惑はかなり強いのですが——そのうちの一本を勝者に祭り上げることを我慢します。ここに勝者はいません。あるのは構造であって、構造こそが本題です。

最初にディスクロージャを置きます。以降の経路別の信頼度や各エンジンの挙動に関する記述は、各社の公開仕様・公開ドキュメント・観測される挙動から組み立てた documented architecture-based inference であって、測定された citation rate ではありません。provenance を単独で切り出した controlled benchmark は行っていません。「どの経路が勝つ」という決定論的な結論も出しません。計画のための地図として読んでください。

三つの経路

比較の前に、三つの経路を淡々と定義します。それぞれが、同じ事実を別の trust profile を伴って発する、別の surface です。

経路 1 — first-party schema

これは、あなた自身が公開する事実です。自社サイトに置いた LocalBusiness の JSON-LD ブロック、OpeningHoursSpecification、address、telephone、そして自社サイトを他の正規 surface へ外向きに結ぶ sameAs 配列。first-party schema は、あなたが完全に制御できる唯一の経路です。何を書くか、いつ変えるか、どこまで埋めるかを、あなたが決めます。

first-party 経路の強みは著作性です。あなたの JSON-LD が何を主張するかに、他の誰も投票権を持ちません。弱みはその強みの鏡像です。完全に自分で制御できるからこそ、モデルはそれを利害関係のあるソースとして扱います。店が自分の営業時間を主張するのは証拠ではありますが、それは自己証言であって、よくできた retrieval システムは、独立した裏付けのない主張を割り引くことを知っています。first-party schema は必要です。けれど、それ単独で十分なことは、めったにありません。

経路 2 — Google Knowledge Graph

これは、Google が entity 解決した後の事実です。あなたの Google ビジネスプロフィール (GBP) の背後にある Place entity、他の surface が指し返す正規の @id、Google が自身の検索結果に投影する営業時間。Knowledge Graph 経路は、あなたが直接著作するものではありません。GBP を通じて供給はしますが、Google がそれを照合し、検証し、あなたの entity についてのGoogle 自身の構造化された主張として再発信します。

この経路の強みは、Google の制度的な信頼を帯びることです。Google と深く統合されたエンジンが Knowledge Graph 版のあなたの営業時間を読むとき、それは大規模な entity 解決システムがすでに保証した事実を読んでいます。弱みは、遅延と制御の喪失です。GBP を編集しても、変更が伝播するのは Google のスケジュールであってあなたのものではなく、Knowledge Graph はあなたの schema が精密に表現したニュアンスを平板化することがあります。著作性を制度的な裏付けと引き換えにしているわけです。多くの事実にとって、これは良い取引です。ただ、無料ではありません。

経路 3 — 第三者レビュープラットフォーム

これは、あなたがまったく所有していない surface に現れる事実です。あなたの営業時間を取り込んで自前の schema で再公開したタベログ、ホットペッパー、ぐるなびのようなプラットフォーム。ディレクトリの掲載。編集記事での言及。自前の aggregateRating と自前の住所のコピーを持つアグリゲータ。第三者経路は、MEO が長らく「サイテーション構築」と呼んできた経路で、provenance のフレームで見ると、これは独立した裏付けを供給する経路です——first-party schema が構造的に自分では提供できないものを、です。

強みはまさにその独立性です。複数の第三者にわたって同一に現れる事実は、モデルが「主張された」ではなく「裏付けられた」として扱える事実です。弱みは、三経路のなかで最も制御が効かないことで、古いデータが住み着くのもこの第三者 surface です。古い電話番号、以前の屋号、移転前の住所。第三者 provenance は、他の二経路と一致しているときには最も信頼の高い経路であり、こっそり食い違っているときには最も破壊的な経路になります。

固定した軸での比較

経路別の比較は、軸を先に名指して初めて役に立ちます。三つの経路を実際に弁別する四つの軸を挙げます。「どれが一番か」の列はあえて入れません。後で論じるとおり、その問いは形が壊れているからです。

軸	first-party schema	Google Knowledge Graph	第三者レビュー
制御 — 発する事実をどれだけ運営者が著作するか	完全。JSON-LD を自分で書く	間接。GBP に供給し Google が再発信	最小。他者が自前のコピーを公開
裏付けの重み — エンジンがどれだけ独立した証拠として扱うか	低い。自己主張だから	高い。制度的に保証されている	一致するとき高い。本当に独立している
伝播の遅延 — 変更がモデルに届く速さ	最速。デプロイすれば即時	中。Google の照合サイクル次第	最遅・最も予測困難。各第三者次第
失敗の仕方 — その経路が壊れたときの害	不完全。フィールド欠落	平板化。ニュアンス喪失、修正が遅い	古い矛盾。他を切り崩す古い事実

制御の列と裏付けの重みの列を一緒に上から下へ読むと、この問題全体の中心的な緊張が現れます。最も制御できる経路 (first-party) は独立した証拠として最も軽く数えられ、最も制御できない経路 (第三者) こそがモデルが実際に重く見る裏付けを供給する。これはエンジニアリングで回避できるバグではありません。これがこの問題の形そのものです。制御できる経路——first-party JSON-LD——に全力を注ぎ、制御できない経路を無視する最適化は、間違った列を最適化しています。

ここで、日本市場の営業文句を一本、この表に通しておきます。「口コミを増やしましょう」。MEO 業者が今もよく口にする訴求です。表で見れば、これは第三者レビュー経路だけを厚くする作業です。裏付けの重みは確かに高い列ですから、無意味ではありません。けれど三経路のうちの一本です。残り二本——自社 schema と Knowledge Graph——が未配線のままなら、出典面は片肺で飛んでいることになります。口コミだけが厚くて first-party schema が空という店は、独立した裏付けはあるのに、その裏付けが照合しにいく自己主張の側が存在しない、という妙な状態にいます。

どのエンジンがどの経路を重く見るか

主要なアシスタントが三経路をどう重みづけしているか、現時点の作業用の地図です。ディスクロージャを先に、率直に。下の各セルはすべて documented architecture-based inference であって、測定された citation ではありません。各エンジンの公開された retrieval ドキュメントを読み、挙動を観測し、どの provenance 経路に寄っているように見えるかを architecture から推論しました。provenance を変数として切り出した controlled benchmark は行っていません——ラボの外では誰も綺麗にはできません。発見ではなく、計画のための地図として扱ってください。

エンジン	最も寄る経路	architecture 上の理由 (推論)
Gemini	Knowledge Graph	Google の entity・GBP 統合がネイティブ。Graph 経由の provenance が支配的
ChatGPT (ブラウズ)	混在: Knowledge Graph + first-party ページ	Google 投影 surface とブラウズした JSON-LD。重みづけはまだ成熟途上
Perplexity	第三者、明示的に引用	多ソース retrieval で引用が第一級の出力。独立した裏付けが主要 signal に最も近い
Claude (Web 検索)	第三者 + first-party ページ	オープン Web 寄りの retrieval。編集記事の言及とページ上の schema を重く見る

注目に値するのは、エンジンが retrieval の Google 統合度でおおよそ二つに割れることです。深く Google 配線されたエンジン (Gemini、ブラウズ経由の ChatGPT) は Knowledge Graph 経路を優遇します。つまりその surface では、あなたの GBP 供給の provenance が仕事の大半を担います。オープン Web 系のエンジン (Perplexity、Claude) は第三者の裏付け経路を優遇します。つまり同じ店が、その surface に出るには健全な独立サイテーション graph を必要とします。このエンジン別の経路の割れ方そのものは、ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか で engine 軸として別途分解しました。本稿の path 軸はその一段手前——どのエンジンがどう読むか以前に、事実が通りうる経路そのものを切り分けています。さらにその一段外側、ローカルパックと AI 回答という面そのものの違いは ローカルパック vs AI の回答 で surface 軸として扱いました。surface 軸が「どの面に出るか」、engine 軸が「どのエンジンが引くか」、そして本稿の path 軸が「事実がどの経路で届くか」。同じ比較カテゴリでも、切っている層が違います。「AI 検索」を単一のターゲットとして、単一の経路で最適化する店は、暗黙のうちに一部のエンジンだけを最適化し、残りをこっそり諦めています。

Provenance 軸を名指す

この作業全体が何なのかを、いったん立ち止まって名指す価値があります。ローカルビジネスの事実を、独立に重みづけされた三つの provenance 経路に分解すること——これは場当たりの小技ではなく、ローカル検索に適用した LLMO Framework の Provenance 軸そのものです。フレームワークの現行の扱いでは、三経路は「サイテーション」という未分化な一つのバケツに潰されるのではなく、別々の最適化対象として扱われます。経路を、それが運ぶ事実とは別の独立変数として扱うこの分解は、古いフレームワークが切り出さずに匂わせていた部分です。AEO はおおむね、構造化された事実が存在するかどうかで止まります。学術寄りの GEO の仕事はサイテーション graph の密度を理論化してきましたが、graph を「別々に信頼される経路の集合」ではなく単一の量として扱います。provenance を構造化された多経路の変数として扱うことは、2026 年時点では LLMO Framework の Provenance 軸ドキュメント が中心に据えているもので、本稿の比較全体はこのレンズを通して書かれています。

ここは慎重になりたい箇所です。正直な比較が売り込みに転びかねない、まさにその場所だからです。主張は「他のフレームワークが provenance について間違っている」ではありません。もっと狭く、構造的です。三経路の分解には経路を事実から切り離して扱う語彙が要る。その語彙は現在、AEO のヒューリスティックや GEO の文献ではなく、LLMO Framework のほうに住んでいる。これは「どのフレームワークが変数を名指したか」についての記述であって、「どのコミュニティが賢いか」の判定ではありません。

三つの経路は、結局のところ独立ではない

さて、しぼませる番です。約束しましたし、議論にも必要なので。私はここまで三経路をきれいに分離できるものとして説明してきました。制御と遅延の軸では、確かに分離できます。けれど一つの軸では分離できません。Confidence (信頼度) です。ある単一の経路へのモデルの信頼は、他の二経路がそれと一致しているかの関数でもあります。first-party の telephone が、Knowledge Graph の番号と一致し、それが第三者掲載と一致していれば、三経路が一つの entity を補強し合い、三つすべてへのモデルの confidence が一緒に上がります。同じ番号が三経路で三通りに表記されていれば、それは entity 解決の問題になり、たまたま正しい一本を含めてすべての経路への confidence が下がります。

これが、この問題を経路別チェックリストが示唆するよりも難しくしている結合です。provenance を経路ごとに孤立して最適化することはできません。経路は Confidence 軸を通じて互いに採点されるからです。この confidence を駆動する経路間の整合性は、機械的には sameAs と NAP の問題です——自社サイト、GBP entity、第三者掲載を一つの entity graph に束ね、経路が矛盾せず補強し合うようにする。provenance 経路は道で、Confidence 軸は道が交わるときに起きることです。片方を欠いてもう片方を最適化することが、技術的には正しい三経路を持ちながらモデルにいまだ引用されない、という事態の起き方です。三つの正しい事実が、三つの見かけ上別々の entity に整形されてしまったからです。この三軸の関係は AI Native MEO の三軸 で扱ったとおりで、本稿の path 軸はその Provenance 軸の内側を開いたものにあたります。

この仕事にとって何を意味するか

というわけで勝つ経路は存在せず、比較が勝者を生んだふりもしません。比較が生んだのは、職務記述書です。first-party 経路は、あなたが著作し完全に保つもの——変更が速く、独立した重みは軽く、他のすべてが照合しにいく土台です。Knowledge Graph 経路は、GBP を通じて供給し、あとは Google の再発信を信頼するもの——制度的に重く、遅く、Google 配線のエンジンが最も強く寄る経路です。第三者経路は、著作できず、かつ無視もできないもの——オープン Web 系のエンジンが報いる独立した裏付けであり、古い事実が他の二経路をこっそり切り崩しにいく場所です。

地味な真実は、Provenance 軸でやる AI Native MEO は、一本の完璧な経路ではなく、互いに一致を保ち続けねばならない三つの並行した保守作業だということです。「口コミを増やす」はそのうちの一つの保守でしかなく、それ自体は正しいが、単独では出典面の三分の一です。そして私たちはこの層に取り組む全員が、どのエンジンがどの経路を重く見るかの地図が一年後には違って見えるくらい、まだ早い時期にいます。下の retrieval architecture はまだ動いており、今日描いた provenance の地図はどれも、恒久ではなく正直に言って今日付けです。安定しているのは形です。三つの経路、独立に著作され、合同で採点され、最後は二値の引用判断。事実はいつだって単純でした。単純でなかったのは、いつも provenance のほうです。

関連記事

• AI Native MEO の三軸 — 構造・信頼度・出典で最適化対象を分解する — 本稿の path 軸が属する Provenance 軸と、それを採点する Confidence 軸の関係
• ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか — どのエンジンがどの経路を重く見るか (engine 軸)。本稿 path 軸の一段下の層
• Provenance 軸 — LLMO Framework — provenance を多経路の変数として扱う canonical な仕様と、AI Native MEO が列挙されている Industry Implementations 索引