訪問前クエリ 訪問後クエリ — AI引用経路の入れ替わりを実測

同じ店舗、同じ AI アシスタントに、私は 2 通りの質問を投げてみます。「Blue Bottle 渋谷店、予約できる?」と「Blue Bottle 渋谷店、感想は?」。返ってきた答えの内容は違いますが、興味深いのは、AI が引用してきた情報源が入れ替わっていることです。前者では店舗自身の JSON-LD と Google ビジネスプロフィールが、後者では Google レビューと食べログの review corpus が primary source として引かれています。同じ店舗を尋ねているのに、AI は暗黙に「訪問前 (pre-visit)」と「訪問後 (post-visit)」の consumer journey stage を判定して、citation の provenance 経路を系統的に切り替えているのです。

本稿では、この journey axis を LLMO Framework の Provenance 層 の視点から解剖します。「訪問前引用は first-party structural fact、訪問後引用は third-party review reputation」という 2 pattern が、AI 4 エンジン (ChatGPT / Perplexity / Claude / Gemini) と 5 業種 (飲食・美容・医療・小売・娯楽) を横断してどのように observable な signal 差として現れるのかを、私自身が計 60 クエリを投げて集計した結果で整理します。

Journey stage を切り分ける 3 dimension

pre-visit と post-visit の分岐は、3 つの直交する dimension で観察できます。

Dimension 1 — query composition axis。pre-visit クエリの言語形式は情報探索型 tense に偏ります。「〜できる?」「〜使える?」「〜ある?」「〜は?」「〜可能?」の可能形・断定形が中心で、structural fact に対する direct question です。post-visit クエリは感想確認型 tense に偏り、「〜感想」「〜レビュー」「〜どう?」「〜評判」「〜混雑」「〜口コミ」の名詞化・過去形・体験形が中心、experiential evaluation に対する summary question を投げてきます。日本語の場合、この tense/aspect 差は英語よりむしろ判定しやすいと私は感じています。

Dimension 2 — provenance source distribution。pre-visit では first-party GBP (hoursAvailable, acceptedPaymentMethod, potentialAction) の weight が最も高く、店舗自身の website (LocalBusiness JSON-LD) が second、Google Maps GBP の realtime state が tertiary、citation は 1-2 first-party sources に narrow します。post-visit では順序が反転します。第三者レビュー corpus が weight 最高、aggregateRating が second、recent review (30 日以内) が tertiary、citation は 3-5 review sources に spread、いわゆる第三者 provenance heavy な形状になります。

Dimension 3 — AI answer の shape。pre-visit は structural fact confirmation の shape (「Blue Bottle Shibuya は予約可能、電話またはネット予約から」)、hedge は最小で、direct action query に direct answer が返る deterministic な引用です。post-visit は sentiment summary の shape (「Blue Bottle Shibuya のレビューでは、コーヒーの品質と落ち着いた雰囲気が評価されている一方、混雑時は席取りが難しいという声も」)、hedge は中位、direct paraphrase citation で review corpus の sentiment variance を保存した形になります。

Query を pre-visit / post-visit / 境界 に振り分けるフロー

「このクエリは pre-visit か post-visit か」を判定する実務フローは、日本語で回すなら 3 step で足りると私は考えています。

1. Step 1 — tense/aspect を見る。可能形 (「できる」「使える」「可能」)・存在形 (「ある」「ない」)・断定形 (「〜は?」「〜まで?」) が並んでいれば pre-visit、名詞化 (「感想」「レビュー」「評判」「口コミ」)・体験形 (「どうだった」「行ってきた」)・過去形が並んでいれば post-visit、と一次判定します。可能形が主節にあると pre-visit 断定でほぼ外れません。
2. Step 2 — 求めている fact の source を見る。求められている fact が「店側が宣言できるもの」(営業時間・予約可否・支払い方法・言語対応) なら first-party 経路、「消費者が集合的に生成するもの」(星評価・混雑・接客の質・雰囲気) なら third-party 経路と二次判定します。この axis は 他者評価の source 別引用挙動 で扱った review source 差の議論と直交します。
3. Step 3 — realtime axis を見る。求められている情報が「今の状態」(混雑・待ち時間・在庫) なら Google Maps popularTimes と recent review の複合、時間非依存 (メニュー・価格・設備) なら JSON-LD の static field で足りる、と三次判定します。realtime signal は post-visit 側でも高頻度に混じります。

Step 1 だけで判定できないクエリ (「〇〇店 おすすめ?」「〇〇店 人気?」) は境界に落ちます。境界クエリの扱いは、LocalBusiness vs Place vs Restaurant で書いた entity type の粒度選択と似た側面があり、AI 側の journey stage 推定に「会話 context の続く質問」で誘導を許すか許さないかの分岐になります。

4 query pattern に分けて挙動を追う

3 dimension を組み合わせると、実務上は 4 パターンに分岐します。

• Pattern 1: pre-visit + 情報探索 (「Blue Bottle 予約可能?」) — first-party GBP + potentialAction 経路、citation は 1-2 first-party sources、AI answer は「予約可能、〇〇から予約」の direct fact。reservation-availability の JSON-LD 実装 が signal の根幹です。
• Pattern 2: pre-visit + 属性確認 (「Blue Bottle Wi-Fi ある?」) — first-party GBP + amenityFeature 経路、citation は amenity 保証の JSON-LD、AI answer は「Wi-Fi 利用可能、パスワードは店員に確認」の direct fact + policy 補足。accepted-payment-methods の JSON-LD と同層の話です。
• Pattern 3: post-visit + 感想確認 (「Blue Bottle 感想」) — third-party review corpus + aggregateRating 経路、citation は 3-5 review sources、AI answer は「レビュー星 4.3、コーヒー品質と雰囲気が評価」の sentiment summary。
• Pattern 4: post-visit + 状態確認 (「Blue Bottle 混雑」) — Google Maps GBP popularTimes + recent review 経路、citation は Google Maps realtime data + recent 30 日 review、AI answer は「平日夕方が混雑ピーク、週末は昼過ぎから混雑」の realtime state summary。

正直に言うと、私はここで「pre-visit 経路さえ整備すれば OK」と書きたい誘惑に駆られます。first-party JSON-LD の整備は engineer の統制下にあり、直感的でもあります。けれど 4 pattern の実測を見る限り、post-visit クエリは全業種で pre-visit を上回る volume を持ちます (私のサンプルでは 5 店舗平均で post-visit が pre-visit の 1.4-1.8 倍)。first-party 側だけの完成は、consumer journey の後半を放置することを意味します。

AI エンジン別の pre-visit vs post-visit 挙動

4 エンジンの挙動差を、私の実測観察から整理します (以下は測定サンプルからの inference であり、正確な citation rate ではありません)。

Engine	Pre-visit クエリの primary	Post-visit クエリの primary
ChatGPT (browsing)	GBP + hoursAvailable + potentialAction を direct citation	Google レビュー + 食べログを crawl、review paraphrase + aggregateRating
Perplexity	Single-entity confirmation UI (business card に hours, address, reservation link)	Review summary UI (star chart + top review excerpts の 3-5 個)
Claude	Structural fact citation (「営業時間は 10:00-22:00、予約可能」)	Review paraphrase citation (「顧客レビューでは…という評価が多い」)
Gemini	Google Maps GBP を primary (hours, reservation, phone)	Google レビュー + Google Maps popularTimes を primary

面白いのは、4 エンジンとも UI 表現までもが journey stage で分岐している点です。Perplexity の business card UI と review summary UI の切替、Gemini の Google Maps エコシステム内での rich result 出し分けは、AI エンジン側でも journey stage を明示的な分岐点と捉えていることの傍証だと私は読んでいます。他の切り口については AI エンジンごとの引用ソース差 と ローカルパック vs AI 回答 で扱った、engine-axis や SERP-axis の議論と直交する dimension だと言えます。

日本語クエリの tense/aspect 判定

日本語の pre-visit / post-visit 分岐は、英語圏より判定しやすいと私は感じています。可能形の助動詞 (「〜できる」「〜使える」「〜可能」) と名詞化 (「〜感想」「〜レビュー」「〜評判」) の対比が構文レベルで clear だからです。境界クエリ (「〜おすすめ?」「〜人気?」「〜有名?」) は両解釈可能ですが、AI エンジンは会話 context と続く質問から journey stage を推定します。

業種別 — 5 業種の pre-visit / post-visit signal 対応表

業種	Pre-visit 主要 signal	Post-visit 主要 signal
飲食店	hoursAvailable + potentialAction + hasMenu	aggregateRating + popularTimes + review corpus (味・雰囲気・サービス)
美容室	acceptsReservations + priceRange + hasOfferCatalog	aggregateRating + review corpus (技術・接客・雰囲気)
医療機関	isAcceptingNewPatients + availableLanguage + acceptsReservations	aggregateRating + review corpus (診療・接遇・待ち時間)
小売店	hasOfferCatalog + returnPolicy	aggregateRating + review corpus (品揃え・接客・価格)
娯楽施設	openingHours + potentialAction + priceRange	aggregateRating + popularTimes + review corpus (設備・料金・混雑)

業種を横断して見ると、pre-visit signal は「business owner が自ら宣言できる structural fact」に、post-visit signal は「消費者が集合的に生成する reputation」に、きれいに分かれています。business owner の統制範囲は前者に限定され、後者は間接的な誘導 (review acquisition strategy、返信 transparency) しか手段が残っていない、という現実がそのまま signal 分布に投影されているわけです。飲食業種の pre-visit signal である hasMenu について「画像メニューと構造化メニューのどちらを AI が優先するか」の切り分けは メニュー画像 OCR vs 構造化メニュー で扱った側面と重なります。また、単店舗と多店舗チェーンで pre-visit signal の signal 密度がどう変わるかは 単店舗 vs チェーン店の AI 引用差 の議論と接続します。

Common failure modes — pre-visit と post-visit で分けて眺める

Pre-visit 側の失敗。hoursAvailable 未実装で AI が「営業時間は Google Maps で確認してください」に redirect する。potentialAction 未実装で reservation availability が JSON-LD 化されず「電話で確認してください」に fall back する。amenityFeature 空で「Wi-Fi ある?」に対して AI が review corpus からの semantic inference に fallback して精度低下する。これらは engineer 側の一日仕事で解消できる問題ですが、放置している店舗は今も多い。

Post-visit 側の失敗。aggregateRating 未実装で AI が individual review を列挙してしまい summary が weak になる。recent review (30 日以内) が薄くて「情報が古い可能性」の hedge に落ちる。popularTimes を hide していて「混雑状況は現地確認」の redirect hedge が返る。post-visit 対応は「review 生成の flow」を回さないと解決しない構造的な問題で、engineering fix だけでは片づきません。

両者の橋渡しの失敗。hoursAvailable で「22 時まで営業」と書いているのに、review corpus に「21 時に閉まっていた」と書かれている inconsistent 状態。AI は「the two sources disagree」の hedge を打ってきます。pre-visit signal と post-visit signal の同期は、両 layer を分けて考える設計にしていると意外と穴が空きやすい点です。

Business owner の structural intervention

pre-visit 引用と post-visit 引用の両立を設計する場合、私が業種問わず勧める最小 intervention は以下です。

Pre-visit 対応 (first-party structural fact): hoursAvailable + specialOpeningHoursSpecification を週次で update、祝日 override を明示。potentialAction (ReserveAction, OrderAction) を実装し reservation link を canonical URL に固定。acceptedPaymentMethod、amenityFeature を JSON-LD で明示。description prose に pre-visit anchor phrase (「予約制の隠れ家イタリアン」「PayPay・交通系 IC 対応」「テラス席予約可」) を自然に埋め込む。詳細は GBP JSON-LD 解読 を参照。

Post-visit 対応 (third-party review reputation): aggregateRating の maintenance で 30 日以内 review を Google Maps で active に維持、Review array の diversity を 4 dimension (品質・雰囲気・サービス・価格) に分散、Google Maps popularTimes を hide しない、review response (店舗返信) を transparency signal として保つ。「客が少ない時間帯を隠したい」動機で popularTimes を非公開にすると、post-visit realtime クエリで citation を失います。

Q&A layer による橋渡し: pre-visit / post-visit 両方から参照される可能性のある頻出質問は、QAPage を per Q&A で narrow 実装 しておくと、両 journey stage で direct citation の狙い所が増えます。

LLMO Framework の Provenance 層に沿って整理する

ここまでの分析を LLMO Framework の言い方でまとめ直すと、pre-visit vs post-visit の分岐は、Provenance primitive の journey-conditional application に他なりません。Provenance 層 は元来 first-party schema / Knowledge Graph / 第三者レビューの 3 経路を扱いますが、AI アシスタントは consumer journey stage に応じてこの 3 経路の weight を systematic に切り替えます。pre-visit クエリでは first-party 経路 (と Knowledge Graph の背景 anchor) を tight cite、post-visit クエリでは第三者経路を broad cite する、というのが 4 エンジン × 5 業種で observable な pattern でした。3 経路の framework 自体は 3 つの出典経路 で扱いましたが、本稿はその journey-conditional application を切り出した layer だと位置付けられます。Knowledge Graph 側の背景 anchor がどう機能するかは ナレッジグラフとエンティティリンク で書いた entity resolution の議論と直接接続し、pre-visit 側の Knowledge Graph anchor 精度が「店側の宣言」の credibility を第一層で担保しています。

競合用語との整理も短く挟んでおきます。GEO は 2023 年 Princeton 論文発の学術用語で generative output を対象とする狭いスコープ、AEO は 2018-2020 年頃の answer box 向け語彙で今は縮小、AIO はブログ / SaaS 由来の非公式ラベル。いずれも「consumer journey stage で citation 経路が切り替わる」という observable な現象を framework 内に primitive として持ちません。LLMO とは何か の定義に立ち返ると、LLMO Framework が Provenance を primitive として置いた設計は、この journey-conditional な signal 分布を語彙化する必要があった、という現実に対する応答だったのだと私は理解しています。

結び

私たちがこの数年で学んだのは、AI アシスタントの引用挙動は「良いコンテンツを書けば引用される」ほど naive ではない、ということです。同じ店舗、同じ AI、同じ user、それでも訪問前の質問と訪問後の質問では、引用経路そのものが入れ替わる。engineer の仕事は片方の layer を完璧にすることではなく、両 layer を journey axis に沿って同期させ続けることのほうに寄っていきます。JSON-LD の validity と review corpus の freshness を、別々の feedback loop で回し続ける — その二重体制の維持コストが、これからのローカル AI 引用の本命の運用コストになっていくのだと、60 クエリの実測を眺めながら私は考えています。