訪問前クエリと訪問後クエリ — AI引用経路はどう切り替わるか
AI アシスタントは『予約可能?』の訪問前クエリと『感想』の訪問後クエリで first-party GBP と第三者レビューの引用経路を systematic に切り替える。4 エンジン × 5 業種の実測を Provenance 軸で整理する。
同じ店舗、同じ 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 を保存した形になります。
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 分布に投影されているわけです。
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 だと位置付けられます。
競合用語との整理も短く挟んでおきます。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 クエリの実測を眺めながら私は考えています。
よくある質問
- 訪問前クエリと訪問後クエリの違いは何ですか?
- 訪問前クエリは『予約できる?』『営業時間は?』『PayPay 使える?』のような structural fact に対する direct question で、tense は可能形・断定形が中心です。訪問後クエリは『感想』『混雑』『評判』のような experiential evaluation に対する summary question で、tense は名詞化・過去形が中心になります。AI アシスタントはこの tense と語彙を暗黙に判定して citation strategy を切り替えます。
- pre-visit クエリで hoursAvailable が最重要な理由は?
- 『〇〇店 営業時間』の pre-visit クエリに structural fact 経路で応えられないと、AI は『営業時間は Google Maps で確認してください』という redirect hedge に落ちます。hoursAvailable と specialOpeningHoursSpecification の JSON-LD が first-party に存在して初めて、direct answer citation が成立します。私が 4 エンジンで実測した範囲では、hoursAvailable 未実装の店舗は pre-visit direct citation 率が 20-30% 程度まで下がっていました。
- post-visit クエリで aggregateRating と popularTimes が主要になるのはなぜですか?
- post-visit クエリは experiential evaluation を求めているため、AI は first-party 情報を primary source として使いません。第三者レビュー corpus (Google レビュー・食べログ・ホットペッパー) の aggregateRating と Google Maps の popularTimes が primary、citation は 3-5 sources に spread する傾向があります。第三者 provenance heavy な引用形状は、消費者が『店側の言い分』ではなく『他者の体験』を求めていることに対応した結果です。
- 『〇〇店 おすすめ?』のような境界クエリはどう扱われますか?
- 『おすすめ?』『人気?』『有名?』は pre-visit (訪問前の情報探索) と post-visit (訪問後の他者評価確認) の両解釈が可能な境界クエリです。AI エンジンは会話 context や続く質問から journey stage を判定します。business owner 側は description prose に『初訪問におすすめ』『リピーター多数』のような anchor phrase を自然に埋め込むと、AI の journey stage 判定を支援できます。