業界キーパーソンをAIで特定する方法｜根拠を確認する6工程

法人営業や新規事業の提案において、特定企業の商談に関わるキーパーソンを調べる際、役職名だけを頼りに一人の決裁者を探そうとして行き詰まることがあります。実際の購買判断には複数の人物が関わるため、役職だけで決裁権を決めるのではなく、対象の案件に必要な役割を定義し、複数の人物を候補として整理するアプローチが必要です。

本記事では、業界のキーパーソン候補をAIで絞り込み、人が根拠を確認して接点づくりへ進むための設計方法を解説します。AIの役割は公開情報と利用を許可されたCRM情報をもとに候補表と未確認事項を作ることにとどめます。AIに人物の性格や購買意欲を推測させたり、役職や要約だけで決裁権を確定させたりすることはしません。

また、非公開名簿の収集や自動送信ツールへの流用も対象外とします。

あくまでAIが整理した情報に対して、人が原典となるページを開き、人物の同一性、現職、案件との関係、連絡可否を確認するという境界を厳格に維持します。本編では、役割の定義から始まり、AIへの指示書の作成、検索と候補整理、原典確認、CRMへの登録、そして接点づくりに至るまでの根拠を確認する6工程を順番に解説します。

この手順を踏むことで、AIへ任せる作業と人が最終判断する範囲を明確に分けた実務フローを整えることができます。

キーパーソンを役職ではなく案件での役割に分ける
AIへ渡す調査条件と禁止事項を1枚にまとめる
検索サービスとAI調査で役割別の候補表を作る
氏名・現職・案件との関係を原典で照合する
複数の関係者をCRMへ登録し更新履歴を残す
個人情報・権限・停止条件を決めてから接点を作る
よくある質問
調査手法について

キーパーソンを役職ではなく案件での役割に分ける

AIを使ったキーパーソン特定では、役職名から一人の「決裁者」を当てる作業を目指すのではなく、対象案件に関わる複数の人物を候補化し、それぞれの役割を整理します。検索条件としての役職や職位は、その人物が対象案件の意思決定者であることを直接証明するものではないため、役職だけで決裁権を確定してはいけません。

顧客側の関係者を複数管理する設計は、主要なCRMツールでも標準とされています。Microsoft Dynamics 365の公式資料では、関係者として意思決定者だけでなく、推進者、利用者、予算責任者、影響者、技術評価者を別の役割として挙げています。

また、Salesforceでも、取引先と人物の関係を「主な意思決定者」や「影響者」などの役割として記録する設計を案内しています。

したがって、誰を探すのかをAIへ指示する前に、案件に必要な関係者の空欄をあらかじめ定義します。たとえば、架空の製造業向け解析サービスを提案する場面であれば、「導入判断」「予算承認」「技術評価」「利用部門」「調達・法務」「社内推進」という6役割の空欄を設けたstakeholder-map.csvを手元に作成します。

見つけ出した人物名は、最初はこの空欄を埋めるための仮の候補として扱います。AIには公開情報をもとに候補表と未確認事項を作らせるにとどめ、非公開名簿の収集や自動送信は行いません。また、AIに人物の性格や購買意欲、決裁権を推測させることも避けます。

AIが提示した候補に対して、人が根拠となる原典を開き、人物の同一性、現職、案件との関係、連絡可否を確認するという境界を維持します。検索条件を決めるより先に案件ごとの役割を固定することで、推測による誤った役割付与を防ぐことができます。

AIへ渡す調査条件と禁止事項を1枚にまとめる

案件に必要な関係者の役割を定義したら、それらを具体的な調査入力へと変換します。調査を再現可能なものにするため、AIへ何を渡し、何を推測させないのかを1枚の指示書にまとめます。

具体例として、手元にkey-person-brief.mdというテキストファイルを作成し、調査の前提条件を記述します。ここには、対象の企業名、公式ドメイン、今回の商談テーマ、対象地域、そしていつ時点の情報を探すのかを指定する基準日を記載します。また、自社のCRMに記録されている過去の接点履歴のうち、社内ルールでAIへの入力が許可された項目のみを追記します。

このように入力情報を管理するのは、個人情報保護委員会の通則編において、個人情報の利用目的を本人が一般的かつ合理的に想定できる程度まで具体的に特定することが求められているためです。インターネット上の公開情報であっても、利用目的や社内ルールを確認せずに収集や再利用をしてよいわけではありません。

秘密情報や用途外の個人情報は避け、公開URLと情報の取得日、そして許可済みのCRM項目だけをAIへ渡す手順とします。

同時に、このファイルにはAIへの推測禁止条件も明記します。具体的には、前段で定めた6役割の空欄を埋めるよう依頼しつつ、「確認できない項目は推測せずに未確認と表記すること」「人物の性格、購買意欲、決裁権を推測しないこと」を指示します。役職名や特定のツールが算出する行動スコア、AIによる要約だけを根拠にして、その人物に決裁権があると確定してはいけません。

AIの役割は、公開情報に基づく候補表と未確認事項の作成にとどめます。提示された候補に対し、最終的に人が原典となるページを開いて、人物の同一性、現職、今回の商談テーマとの関係、そして連絡可否を確認するという境界を維持したうえで、実際の検索作業へと進みます。

検索サービスとAI調査で役割別の候補表を作る

前工程でまとめた条件をもとに、実際の画面操作を通じて関係者の候補を集めます。まずは公式の検索サービスを利用して、対象企業に関わる人物を絞り込みます。

LinkedIn Sales Navigatorの検索フィルターでは、現在および過去の勤務先や会社規模に加えて、職能、現在の役職、職位、地域といった条件を設定できます。

あらかじめ定義した「導入判断」や「技術評価」といった役割に近い人物を探すため、対象地域の指定とともに職能や職位のフィルターを適用し、候補となる人物の公開プロフィールURLを取得します。ただし、これらの検索条件はあくまでプロフィール等から得られた属性であり、特定の商談における決裁経路を直接証明するものではありません。

検索された役職名だけを根拠にして、その人物に決裁権があると確定させることは避けます。

次に、取得した公開URLや調査条件をAIへ渡し、候補表の作成を依頼します。Web上の複数資料を横断する調査には、ChatGPT Deep Researchなどが利用できます。目的と必要な成果物を入力すると、AIから調査計画が提案されます。まずはこの提案された調査計画の内容を確認し、必要に応じて修正を行ってから実行を指示します。

AIへの指示では、事前に定義した役割ごとに候補を整理させます。その際、各判断には必ず根拠URLと情報の取得日を付けること、確認できない項目は推測せずに未確認と記載することを徹底します。非公開名簿の収集や自動送信への流用は行わず、人物の性格、購買意欲、決裁権の推測も明確に禁止します。

AIの実行が完了すると、引用またはソースリンクが付与された構造化レポートが出力されます。この結果を変換し、氏名、現職、所属、想定役割、根拠URL、取得日、未確認事項を列として持つ stakeholder-candidates.csvというファイルを作成します。

この段階の stakeholder-candidates.csv は、あくまでAIが公開情報を整理した仮の候補と未確認事項のリストにすぎません。AIの出力をそのまま事実として扱うのではなく、作成された表の根拠URLを人が開き、人物の同一性や現職、今回の案件との関係性、そして連絡可否を確認するという境界を維持したうえで、次の検証作業へ進みます。

氏名・現職・案件との関係を原典で照合する

前工程で出力された stakeholder-candidates.csvのリストは、あくまでAIが検索条件や要約から生成した仮の候補にすぎません。検索条件やAIの要約だけでは、その人物が実際に対象案件へ関与していることを証明できないため、AIが提示した候補を検証可能な記録へと変える手続きが必要になります。

AI製品の信頼性を高めるための自主的な枠組みであるNISTのAI Risk Management Frameworkに照らしても、キーパーソン調査においては誤人物の混入、古い役職のままの登録、根拠のない役割付与を防ぐことが求められます。

そのため、AIが自動で取得した情報をそのまま事実とするのではなく、出力された表の根拠URLを人が直接開き、人物の同一性、現職、根拠日付、案件との関係を原典と照合します。

具体的には、候補として挙がった人物の同一性を複数の原典で確認する作業を行います。たとえば田中一郎という同姓同名の候補が提示された場合、該当企業の公式プロフィール、過去の登壇者紹介、直近のプレスリリースという3列の情報を用いて照合します。それぞれの原典に記載された現職や根拠日付を確認し、今回の商談テーマとの関わりが読み取れるかを判定します。

照合の結果、情報が一致しない場合や、別人物である可能性が残る場合は、無理に役割を割り当てず、対象項目を未確認の状態へ戻します。

ここでも、役職名やAIの要約だけを根拠にして決裁権の推測を行うことは避けます。人物の性格や購買意欲を推測して案件関与を断定することも行いません。また、未確認のまま非公開名簿の収集へ移行したり、自動送信へ連絡先を流用したりすることも対象外です。

AIは候補表と未確認事項を作り、人が同一性、現職、案件との関係、連絡可否を確認するという境界を厳格に維持します。この照合作業を経ることで、誤人物や古い肩書を除外し、原典で確認した記録だけを次の工程へ渡すことができます。

複数の関係者をCRMへ登録し更新履歴を残す

前工程で原典をもとに人物の同一性や現職の確認を終えた候補を、営業チーム全体で共有し接点づくりの判断へ進める状態にするため、CRMへ正式な関係者として登録します。

B2Bの購買判断は一人の決裁者だけで行われるわけではありません。Gartnerの調査によると、購買グループは5人から16人に及び、最大4職能にまたがるとされています。さらに、74％の購買チームで意思決定中に不健全な対立が見られ、合意へ達した購買グループは高品質な取引だったと答える確率が2.5倍になったと報告されています。

したがって、一人の上位役職者だけを推測で決裁者として扱うのではなく、意思決定者以外の役割を含めて複数人を登録する設計が必要です。

具体的な操作手順として、Microsoft Dynamics 365を利用する場合を例にします。まず、該当する商談のStakeholders欄を開き、前工程で確認が完了した連絡先を追加します。

追加した時点では仮の役割が付与されている場合があるため、営業責任者や担当者が手動で意思決定者、推進者、利用者、予算責任者、影響者、技術評価者といった具体的な役割へ変更します。

また、Dynamics 365ではリードや商談の要約機能を用いて関係者候補を確認できますが、ここでも候補となる連絡先を接続し、提案された値をレコードへ反映する操作は人の手で行うよう分かれています。AIが提示した候補表や要約結果をCRMの人物台帳へ自動で上書き反映させることはしません。

登録の際も、役職名やAIの要約だけを根拠にして決裁権を確定させることは避けます。人物の性格や購買意欲を推測して役割を決めることも避けます。また、自動送信ツールへの連携や非公開名簿からの情報補完も行いません。

AIはあくまで公開情報に基づく候補表と未確認事項を作り、人が同一性、現職、案件との関係、連絡可否を確認してCRMへの接続と役割の変更を行うという境界を厳格に維持します。

最後に、営業責任者が商談画面に戻って役割の変更と更新結果を確認し、誰がいつ情報を確定させたかの更新履歴を残します。これにより、営業チームは未確認の役割や人物間の関係を把握し、組織全体で共有できる判断材料を用意しながら、次のアプローチへ進むことができます。

個人情報・権限・停止条件を決めてから接点を作る

前工程でCRMに登録した関係者へ向けて実際の接点づくりへ進む前に、データ利用と誤特定の境界を固定するためのルールを設けます。どこまでの情報処理をAIに許可し、どのような条件を満たさなかった場合に連絡を止めるのかをあらかじめ決めておきます。

まず、個人情報を取り扱うための要件を整理します。インターネット上の公開情報であっても、個人情報保護委員会の通則編では、個人情報の利用目的を本人が一般的かつ合理的に想定できる程度まで具体的に特定することが求められています。そのため、AIへの入力は公開Webとあらかじめ社内で許可されたCRM項目だけに制限します。

さらに、作成した stakeholder-candidates.csv やCRMのレコードには、取得元や取得日に加えて、利用目的、データの保存先、そしてどのようなタイミングで破棄や修正を行うのかという更新・削除条件を明記します。非公開名簿を用いた情報の収集は行いません。

次に、AIの推測による誤りを防ぐための停止条件と監視項目を設定します。AIシステムへ信頼性の観点を組み込むための枠組みであるNISTのAI Risk Management Frameworkに照らし、調査における推薦件数や時間短縮といった効果だけでなく、運用の中で誤人物率や、人がAIの提案を上書き修正した割合を記録します。

AIには候補表と未確認事項を作らせるにとどめ、役職名やAIによる要約だけで決裁権を確定したり、人物の性格や購買意欲を推測してアプローチを変えたりすることはしません。

これらの基準をもとに、実際の運用場面における具体的な停止条件を適用します。候補表に記載された根拠URLが欠落している場合や、人が原典を開いても現職であることや案件との関係が未確認のまま残っている場合は、その候補への連絡を直ちに停止します。未確認のままの連絡先を用いて自動送信を行ったり、自動送信システムへ情報を流用したりすることは避けます。

最終的な接点づくりにおいては、公開Webと許可済みCRM項目だけを入力として扱い、根拠欠落または現職未確認なら連絡を停止し、営業担当者が連絡経路を承認するというプロセスを守ります。

AIが自動でアプローチを進めるのではなく、人が人物の同一性、現職、案件との関係、連絡可否を確認するという境界を維持することで、誤特定を減らすための確認を伴う営業活動へとつなげることができます。

よくある質問

Q1. AIの調査に無料範囲のWeb検索をそのまま利用できますか

公開されているWeb情報の検索は可能ですが、公開情報だからといって目的や社内ルールを確認せずに収集や再利用をしてよいわけではありません。個人情報保護委員会の通則編では、個人情報の利用目的を、本人が一般的かつ合理的に想定できる程度まで具体的に特定することが求められています。

公開情報から候補表を作成する場合でも、取得元、取得日、利用目的、保存先、確認者、削除・更新条件をあらかじめ記録に残す必要があります。

Q2. 取得した連絡先を自動送信ツールへ連携させることはできますか

いいえ、本手順では対象外です。AIを用いたキーパーソン調査において、自動送信や非公開名簿の収集は行いません。AIには公開情報と許可されたCRM情報をもとに候補表と未確認事項を作らせるにとどめます。提示された情報に対して、人が原典となるページを開き、人物の同一性、現職、案件との関係、連絡可否を確認するという境界を厳格に維持して接点づくりへ進みます。

Q3. 検索結果に同姓同名の候補が含まれる場合はどう確認しますか

AIによる情報収集では、同姓同名や公開プロフィールの更新遅れといった限界が残ります。そのため、AIが整理した候補表の出力をそのまま確定値にはしません。必ず人が根拠となる原典のURLを開き、氏名と所属の同一性、現職、根拠の日付、案件との関係を照合します。別人物である可能性が残る場合や原典で確認できない項目は、推測せずに未確認として扱います。

Q4. 役職名や行動スコアが高ければ決裁者と判断してよいですか

役職名や、AIの要約、特定のツールが算出する行動スコアだけを根拠にして決裁権を確定させることはできません。たとえばLinkedIn Sales NavigatorのBuyer Intentは、プロフィール閲覧や広告クリックなどの観測された行動の集約であり、予算権限や最終決裁権の証明ではありません。

人物の性格や購買意欲をAIに推測させることも避け、人が原典資料や過去の接点履歴を確認して判断します。

Q5. 購買の意思決定は一人の決裁者を見つければ進みますか

一人の上位役職者だけを探す設計には不足があります。Gartnerが2024年に実施した調査では、B2Bの購買グループは5人から16人、最大4職能にまたがると報告されています。

そのため、Microsoft Dynamics 365の公式資料が示すように、意思決定者だけでなく、推進者、利用者、予算責任者、影響者、技術評価者といった複数の役割を設定し、案件に関わる複数の人物を候補として整理する必要があります。

Q6. 検索条件の変更はどのくらいの更新頻度で反映されますか

利用するシステムによって異なりますが、即時にすべての情報が更新されるわけではありません。たとえばLinkedIn Sales NavigatorのPersona機能では、職能、役職、職位、地域といった条件を変更した場合、その変更が候補通知へ反映されるまで通常24時間かかると公式資料で説明されています。

通知された候補はあくまで検索条件に合致した集合にすぎないため、対象案件への関与については人が原典をもとに確認し直す工程が不可欠です。