前回は B2A 基盤、つまり AI Agent に商品データを読ませる方法を扱いました。しかし読まれた後に何が起きるのか、ここがより大きな問題です。ユーザーが ChatGPT で商品を尋ね、AI がカタログを照会し、三つのブランドを推薦し、ユーザーが一つをクリックし、商品ページを見て、カートに入れ、Shopify で注文する。この一連の流れを一つの主体が全部見ているわけではありません。
ChatGPT は何を推薦したかを知っていますが、購入されたかは知りません。Shopify は注文を知っていますが、どの AI 推薦が起点だったかを知りません。GA4 は一部の referrer を見ますが、AI の質問文や比較相手は見えません。UCP はカタログ照会を見ますが、サイト内行動は見えません。ここに証拠ギャップがあります。
このギャップは偶然ではなく、構造から生まれています。プロトコルは機械同士の相互運用性を解きます。AI プラットフォームは外に出たユーザーの行動を追いません。商家の分析ツールは AI の上流文脈を理解しません。その結果、AI が売上にどれだけ貢献したのかが過小評価されます。
CitationGraph はこの中間地帯を AIAA の五層で埋めます。Answer は AI 回答での言及、Request は Agent の取得、Visit は AI 経由の到着、Commerce はサイト内行動、Attribution は注文との接続です。GEO ツールが上流だけを見て、帰属ツールが下流だけを見るなら、CitationGraph は両者を証拠でつなぎます。
ブランドはプロトコルの成熟を待つべきではありません。完全な相互運用には時間がかかりますが、AI の影響はすでに起きています。まず一方 JS で AI 到着を見える化し、次に Edge Lite で Agent request を拾い、最後に session-to-order join で売上証拠につなげるべきです。
実務上の要点は、AI 推薦から注文までの証拠ギャップを単発のコンテンツ施策として扱わないことです。商品データ、AI 回答での表現、Agent request、到着後の行動、注文との接続を同じ証拠線で見なければ、チームは「AI で何か起きている」以上の判断ができません。経営会議で必要なのは流行語ではなく、どの層で証拠が強く、どこが推測なのかを分けた説明です。
もう一つ重要なのは、過剰な断定を避けることです。AI 検索と Agentic Commerce の測定はまだ成熟途上であり、prompt sampling、referrer、server log、Shopify order のどれも単独では完全ではありません。だからこそ、複数の弱い証拠を雑に足すのではなく、層ごとに信頼度を置き、改善順序を決める必要があります。
補足: 証拠ギャップを工程別に分解する
証拠ギャップは抽象論ではありません。実際には、同じ購買の中で各システムが別々の断片だけを持つことから起きます。
工程 | 見えている主体 | 見えていないこと |
|---|---|---|
ユーザーが AI に質問する | AI プラットフォーム | ブランド、GA4、Shopify |
AI がカタログやページを読む | AI プラットフォーム、場合により Edge log | 通常のブラウザ分析 |
AI が候補を推薦する | AI プラットフォーム | 商家側の売上システム |
ユーザーがサイトへ来る | GA4、First-party JS | 元の質問、比較候補 |
商品を閲覧し比較する | GA4、Shopify Pixel | AI 側の推薦理由 |
カートに入れる | Shopify、Web Pixel | AI プラットフォーム |
注文する | Shopify、決済基盤 | 上流 AI 文脈 |
注文後に再訪する | CRM、サポート | 最初の AI 接点 |
この分断を一つの完璧なログで解決するのは現実的ではありません。必要なのは、証拠の強さを分けて接続することです。Answer は推薦の存在、Request は Agent の取得、Visit は到着、Commerce は行動、Attribution は注文との接続を示します。
欠けている証拠 | CitationGraph の役割 | 主なデータ源 |
|---|---|---|
AI が自社を推薦したか | Answer evidence と SOV を保存 | Prompt sampling、回答スナップショット |
AI Agent が読みに来たか | Request visibility を作る | Edge Lite、server log、bot signature |
ユーザーが AI から来たか | AI referrer と first-party visit を識別 | JS、UTM、referrer、landing path |
到着後に何をしたか | Commerce 行動を接続 | Shopify Pixel、GA4、event stream |
売上につながったか | Session-to-order join を行う | Order、session id、campaign context |
この設計で重要なのは、弱い証拠を強い証拠のように扱わないことです。AI 回答での露出は因果ではありません。AI referrer は到着証拠であり、売上証拠ではありません。注文接続は強いですが、上流の推薦理由を単独では説明できません。層を分けて見れば、意思決定はむしろ速くなります。
補足: AI 商流の証拠ギャップを実務で判断する
この論点を現場で扱う時は、AI 商流の証拠ギャップを単なるトレンド解説としてではなく、日々の運用判断として扱う必要があります。特に見るべきなのは、推薦、到着、行動、注文の断片化がどの部署の責任で、どのデータに支えられ、どの頻度で更新されるかです。ここを曖昧にしたまま記事や FAQ だけを増やしても、AI が参照する証拠は安定しません。
実務では、まず「AI が何を読めるか」と「人間が何を見ているか」を分けます。商品ページの見た目が良くても、構造化データ、feed、ポリシー、レビュー、内部リンクが弱ければ Agent は自信を持って推薦できません。逆に、派手なキャンペーンをしなくても、Answer、Request、Visit、Commerce、Attributionが揃っていれば、比較型の質問で候補に残る可能性が上がります。
次に、測定の粒度を決めます。週次では露出、Agent request、AI 由来 visit、サイト内行動、注文接続を分けて確認します。月次では、同じ定義で前月と比較できる数字だけを成長として扱います。新しいタグや Edge 計測を入れた直後の増加は、需要増ではなく観測範囲の拡大かもしれません。
最後に、改善順序を固定します。まず誤読を減らし、次に読めるデータを増やし、その後に到着後の体験を整え、最後に収益との接続を強くします。この順序を守れば、短期の数値が揺れても、チームはどの層を改善しているのかを見失いません。
この考え方は、日本語のコンテンツだけでなく、英語、韓国語、ドイツ語、フランス語、スペイン語、ポルトガル語、アラビア語の各市場にもそのまま必要です。翻訳文を置くだけでは不十分で、各市場の検索行動、比較基準、配送や返品の期待、レビュー文化に合わせて証拠を整える必要があります。
もう一つの実務ポイントは、証拠の所有者を決めることです。Answer の証拠はコンテンツとブランドチーム、Request の証拠はインフラとログ、Visit の証拠はアナリティクス、Commerce の証拠は EC 運営、Attribution の証拠はデータチームが持つ、というように責任線を明確にします。所有者が曖昧なままだと、AI の影響が増えても誰も改善に責任を持てません。
この責任線を作ると、次の実験も設計しやすくなります。llms.txt を直した後は Answer と Request を見る。商品ページを直した後は Visit と Commerce を見る。注文接続を直した後は Attribution を見る。すべてを売上だけで判断しないことが、AI 商流の証拠ギャップを狭める第一歩です。
この基準があれば、短期の数字が小さくても改善の場所を説明できます。
逆に基準がなければ、同じ改善を別々のチームが別々の成果として語ってしまいます。
その重複を避けることも、証拠設計の役割です。
責任線と重複排除は必ず一緒に設計します。
FAQ
Q1: 証拠ギャップとは何ですか?
A: AI 推薦から注文までの中間の計測空白です。
Q2: プロトコルが成熟すれば消えますか?
A: 消えません。プロトコルは配管であり、人間のサイト内行動や商業帰属までは測りません。
Q3: どこから始めるべきですか?
A: Visit 層から始め、Edge Lite、session-to-order join へ進むのが現実的です。
Q4: 広告チームへの意味は?
A: AI の貢献が Direct や Organic に吸収され、予算配分で過小評価されます。