見えない顧客の可視化：AI時代のBtoB購買プロセス設計
生成AIの普及で購買プロセスが不可視化するなか、匿名段階の顧客行動をどこまで捉え、どこから人が介在するか。マーケティング部長向けに、可視化の範囲設計・手順・統制の判断基準を整理します。
公開 2026年9月25日
結論：可視化の対象は「行動」ではなく「問いと文脈」に移す
AI時代の「見えない顧客」は、行動ログを増やしても見えません。追うべきは、どのページを見たかではなく、何を確かめようとしていたかという問いと文脈です。企画部門の仕事は、その問いを記録できる接点を設計し、部門をまたいで同じ定義で読めるようにすることに移ります。
本記事では、匿名段階をどこまで可視化の対象にするか、どの接点で人が介在するか、その線引きをどう決めるかを手順として整理します。
※本記事は2026年9月時点の情報をもとに作成しています。
「見えない顧客」とは：接点に現れないまま検討が進む状態
「見えない顧客」とは、自社の計測可能な接点に現れないまま、社内検討や比較評価を進めている買い手を指します。生成AIによる要約・比較が挟まることで、資料請求や問い合わせに至る前に候補が絞られる場面が増えています。
ここで従来のファネル指標は歪みます。フォーム到達数は購買検討の総量ではなく、「人に聞くことを選んだ人の数」に近づくためです。
併せて、次の3層に分けて考えると議論が噛み合います。
- 未到達層：自社サイトにも来ていない。外部での要約・比較の段階
- 匿名接触層：サイトには来ているが、個人が特定できない
- 顕在層：フォーム・商談などで識別できる
多くの組織は顕在層だけを前提にKPIを組んでいます。まず、どの層を議論しているのかを会議の冒頭で明示することから始めます。
可視化の範囲を決める：追える情報と追えない情報を分ける
可視化は「全部見る」を目指すと破綻します。取得可能性と意思決定への効きの2軸で、扱う情報を先に仕分けます。
| 層 | 取得できる情報 | 取得できない情報 | 企画部門の打ち手 |
|---|---|---|---|
| 未到達層 | 検索・生成AIで参照されうる公開情報の整備状況 | 個別の閲覧経路、比較対象 | 公開コンテンツの網羅性と記述の正確さを点検する |
| 匿名接触層 | 閲覧ページ、滞在、質問文（聞かれた場合） | 所属・役割・予算時期 | 質問文を構造化して蓄積する接点を置く |
| 顕在層 | 属性、商談履歴、失注理由 | 社内の反対意見、比較検討の実態 | ヒアリング項目を固定し、引き継ぎ時に必ず渡す |
重要なのは、取得できない情報を推測で埋めないことです。推測を前提にしたスコアリングは、営業からの信頼を失う最短経路になります。
手順：企画部門が回す4ステップ
1. 問いの棚卸し
営業・カスタマーサクセスに寄せられた質問を、四半期分まとめて読みます。カテゴリ（価格、機能適合、セキュリティ、導入体制、既存システム連携）に分類し、回答の一次情報がどこにあるかを紐づけます。
2. 回答の根拠を一箇所に寄せる
同じ質問に部署ごとに違う答えが返る状態を先に潰します。製品資料・セキュリティチェックシート・FAQを、版管理された一次情報として集約します。
3. 匿名段階で問いを受ける接点を置く
フォームの手前に、質問を受け取り記録できる接点を用意します。ここで得た質問文は、個人が特定できなくても、需要の分布を示す一次データになります。
4. 引き継ぎの型を決める
識別できた段階で、何を誰に、どの粒度で渡すかを事前に定義します。定義がないまま件数だけ渡すと、営業は使いません。基準の作り方はMQLの引き継ぎ基準とSLA設計で整理しています。
判断基準：どの問いをAIに答えさせ、どこから人が出るか
AIに答えさせる範囲は、回答の性質で線を引きます。担当者の判断が必要な問いを機械に投げると、統制が効かなくなります。
| 問いの性質 | 根拠の所在 | 扱い | 記録すべきこと |
|---|---|---|---|
| 事実確認（仕様・対応範囲・前提条件） | 登録済みの資料 | 資料の記述に基づいて回答する | 参照した資料と版 |
| 条件つきの適合判断（自社環境で使えるか） | 資料＋前提のヒアリング | 前提を確認したうえで、確定回答は避ける | 確認した前提と未確認項目 |
| 価格・契約・個別対応 | 社内判断 | 人に引き継ぐ | 質問の文脈と検討背景 |
| 資料に記載がない事項 | なし | 回答しない旨を明示する | 未回答として記録し、資料側へ反映する |
判断の分かれ目は「根拠が登録された文書にあるか」です。根拠がない問いに答えさせない設計は、AI活用の前提条件になります。詳しくはAIの回答統制とガバナンス設計を参照してください。
よくある失敗のパターン
行動スコアを増やして解決しようとする
ページ閲覧数や資料DLの重みづけを細かくしても、問いの内容はわかりません。直し方は、スコアの項目を減らし、代わりに「何を聞かれたか」のテキストを保存することです。
部門ごとに顧客定義が違う
マーケティングの「見込み顧客」と営業の「対象顧客」が別物のまま会議をしても、結論は出ません。直し方は、定義文を一枚にまとめ、四半期ごとに更新の合意を取ることです。
AI導入を先に決めてから用途を探す
ツール導入が目的化すると、既存FAQの焼き直しで終わります。直し方は、ステップ1の問いの棚卸しを終えてから、どの問いを自動化するか決める順序にすることです。
匿名段階の情報を推測で埋める
企業名推定やスコア補完を過信すると、営業の不信を招きます。直し方は、確からしさを併記し、未確認は未確認のまま渡すことです。
向いていないケース
この進め方は、次の条件では適しません。
- 一次情報が整っていない：製品仕様やセキュリティ回答が文書化されていない場合、可視化の前に文書整備が先です
- 商談の入口が人的紹介に偏っている：既存顧客の紹介やパートナー経由が大半なら、Web上の匿名接点を設計する優先度は下がります
- 製品が単価の低い定型商材：検討に社内合意が不要な場合、問いの文脈を記録する価値は小さくなります
- 営業組織が受け入れ体制を持たない：引き継ぎ先の担当が決まっていない状態では、可視化しても滞留します
- 短期のリード数だけを問われている：四半期内の件数確保が唯一の要件なら、別の打ち手を優先すべきです
これらに該当する場合は、無理に可視化の設計を進めず、前提条件の解消から着手します。
よくある質問
匿名段階の質問文を集めることは、個人情報の扱いとして問題になりませんか。
質問文そのものは個人を特定しない情報として扱えますが、記述内容に企業名や氏名が含まれる可能性があります。保存範囲・保存期間・社内での参照権限を事前に定め、プライバシーポリシーに記載したうえで運用してください。
生成AIの回答経由で自社が候補から外れているかを知る方法はありますか。
個別の経路を直接追う手段は限られます。現実的には、自社の公開情報が正確で網羅的かを点検し、営業ヒアリングで「どこで当社を知ったか」「他に何を比較したか」を定型項目として収集する方法を取ります。
企画部門とマーケティング部門の役割はどう分けるべきですか。
顧客定義とデータ定義の管理を企画側、施策実行と接点運用をマーケティング側に置く分け方が整理しやすいです。定義の変更権限を一箇所に集約することが要点です。
まず何から着手すべきですか。
営業に寄せられた質問の棚卸しです。既存データだけで始められ、以降の設計すべての土台になります。LP側の停滞要因は[BtoB LPのCVRが頭打ちになる構造](/knowledge/btob-lp-cvr-plateau)でも扱っています。
まとめ
「見えない顧客」への対応は、計測の精度を上げる話ではありません。問いを受け取る接点を設計し、根拠のある回答だけを返し、文脈を残して人に渡す一連の型をつくる話です。
企画部門の役割は、その型の定義を一箇所で管理することにあります。定義が揺れなければ、部門をまたいでも同じ顧客像を語れます。
関連する考え方はナレッジ記事一覧にまとめています。
なお、UniAgentは、Webサイト上で登録資料を根拠に説明とヒアリングを行い、そのやり取りの文脈を付けて担当者へ引き継ぐAIです。