AIで営業リードを整理する方法｜情報収集と要約

営業リードをAIで整理するときは、会社名だけを並べるより、「誰に連絡するか判断するために必要な情報」を先に決め、公開情報を同じ項目で集めると比較しやすくなります。

確認日 2026年10月12日AIものさし編集部

このワークフローでは、AIを営業判断そのものではなく、Web情報の探索・整理・要約に使います。

先に結論：作業前に整理する4点

表は横にスクロールできます

判断・工程	要点
調べる項目を固定する	会社名、業種、事業内容、所在地、従業員規模、最近の発表、採用動向、利用technologyなど、営業仮説に必要な項目を決めます。
まず一次情報を優先する	会社公式site、IR、press release、採用page、product documentationなどを優先します。
AI検索で候補情報を集める	OpenAI APIではResponses APIからweb search ツールを利用でき、Web情報を調査ワークフローへ組み込めます。
Source URLと確認日を残す	要約文だけを保存すると後から確認できません。

入力と判断材料をそろえる

調べる項目を固定する

会社名、業種、事業内容、所在地、従業員規模、最近の発表、採用動向、利用technologyなど、営業仮説に必要な項目を決めます。

まず一次情報を優先する

会社公式site、IR、press release、採用page、product documentationなどを優先します。

第三者記事だけで重要情報を確定しないようにします。

AI検索で候補情報を集める

OpenAI APIではResponses APIからweb search ツールを利用でき、Web情報を調査ワークフローへ組み込めます。

検索クエリには会社名だけでなく、「公式」「料金」「採用」「導入事例」など調べたい観点を入れます。

AIで整理する

Source URLと確認日を残す

要約文だけを保存すると後から確認できません。

各項目に情報源 URLと確認日を残し、更新されやすい情報を追えるようにします。

Factと営業仮説を分ける

「新店舗を3店出した」はfactでも、「出店管理の課題がありそう」は仮説です。

AIに要約させるときも、確認済み情報と推測を分離します。

同じTemplateで要約する

会社ごとに文章量を変えず、事業概要、最近の動き、想定課題、確認すべき点のように同じformatへ揃えます。

運用へつなぐ

優先順位は条件で付ける

AIの印象だけで「有望」と判定せず、対象業界、規模、地域、trigger eventなど事前条件で絞ります。

CRMへ入れる前に確認する

会社名、URL、担当候補、数字、日付を確認し、重複leadを除外します。

調査前に「営業判断で使う項目」を絞る

企業情報を集めすぎると、調査時間が増えるだけでなく、事実と推測が混ざります。営業する相手を選ぶために必要な条件を、先に3〜6項目ほどチームで決めます。例は対象業界、事業地域、提供サービスとの適合、最近の公開イベント、既存取引の有無です。従業員規模や売上などを使う場合は、定義・対象期間・出典が確認できる項目だけにし、見つからないことを「小さい」「該当しない」と扱わないでください。

表は横にスクロールできます

項目	保存する値	根拠にする資料	未確認時
会社名 / 公式URL	法人・ブランドの表記	公式About / 法人情報	同名企業を区別できるまで保留
事業内容	公式説明の短い要約	公式サービスページ	「不明」としてURLを残す
最近の動き	発表名・日付・要点	Newsroom / IR / 採用ページ	公開情報なしと記録
利用状況の兆候	公開された採用条件など	公式求人・技術資料	導入済みとは推定しない
適合仮説	自社条件との一致 / 未確認	上記Factと営業条件	Factと別fieldに保存
次の確認	人が聞く質問	不足情報一覧	接触可否は人が決める

この表は調査の型であり、特定企業についての実測や推薦結果ではありません。検索結果のsnippetだけで値を確定せず、公式ページを開いて公開日・更新日・対象組織を確認します。

Sourceを再確認できるメモにする

企業ごとに1行だけの要約を保存するのではなく、重要な主張ごとにURLと確認日を紐付けます。たとえば「海外拠点を新設した」は、発表ページの文言と発表日を記録します。「海外進出の支援が必要そう」は営業仮説へ別に記録し、確定Factの列へ入れません。第三者記事が公式発表を引用しているだけなら、可能な限り元の発表に戻ります。ページが削除される場合に備えて、社内規則で許される範囲に短い引用や見出しを残します。

検索は会社名だけでなく対象Factを限定します。例：

「株式会社X 公式事業内容」
「株式会社X ニュース 2026 新サービス」
「株式会社X IR 決算説明資料」
「株式会社X 採用エンジニア公式」
「株式会社X 製品名導入事例公式」

同名企業があるときは所在地や公式domainを照合します。AI検索を使う場合も、候補URLを集める役割にとどめ、引用先を実際に開き、主張を支える記述があるかを人が確かめます。

要約templateと指示例

毎回の文章表現を変えるのではなく、CRMで比較するfieldを固定します。文章は各fieldの説明用にし、事実の置き場はURLと日付を持つrecordにします。

指示例:

「以下の公開情報だけを使い、確認済みFactと営業仮説を別々に出してください。各Factにはsource URL、発表日またはページ日付、確認日を付けます。情報が見つからない項目はunknownのままにし、従業員数、導入済み製品、課題、予算、担当者の関心を推測しないでください。会社の順位や接触優先度を決めず、最後に人が確認すべき不足情報と質問案を最大3件出してください。」

出力例:

会社: 株式会社X

Fact: 公式発表に新サービスの提供開始が記載

Source: 公式発表URL / 公開日 / 確認日

営業仮説: 当該サービスの運用体制を確認する余地がある

Unknown: 現在の利用ツール、課題、予算

次の質問: 調査で見つけた内容が現在も正しいか確認してよいか

これは形式例です。実在企業の情報・営業実績・成約見込みではありません。営業仮説がFactの文面へ混ざらないよう、CRMでも専用fieldを分けて保存します。

リードを順位づける前の判断基準

AIの表現の強さではなく、チームが定めた必要条件を満たすかを人が確認します。必須条件を満たさないleadは保留し、条件不明なら「不適合」ではなく「要確認」とします。優先度を使う場合も、判定根拠、使ったデータ、欠損項目、最終確認者を残し、予測値だけで自動連絡しないようにします。

表は横にスクロールできます

状態	条件	次のAction
調査継続	公式情報が不足、企業同定が不確か	sourceを追加し、事実を確定
人が確認	適合仮説はあるが重要条件がunknown	確認質問を作る
接触候補	明示条件を満たし、情報が新しい	担当者が内容と宛先を承認
対象外候補	明示条件に合わないFactがある	理由を記録し、再判定条件を設定

個人情報と公開情報の境界

企業の公開ページに載っている個人名や連絡先でも、自動収集・CRM保存・営業連絡への利用が常に適切とは限りません。調査対象を法人・製品・公式発表へ絞り、個人の私的情報や推測プロフィールを集めないでください。利用目的、対象地域の法令、社内の営業ルール、各サイトの利用条件を確認し、許可された情報だけ扱います。AIへ渡す入力には認証情報、非公開顧客情報、不要な個人データを含めず、保存・削除・アクセス権を決めます。

更新される情報をCRMで管理する

企業の採用ページや製品情報は更新されるため、確認日だけでなく次回確認の条件も決めます。採用情報や料金のような変動しやすい事実は、一定期間後または接触前に再確認し、古いFactを現在形で要約しません。CRMへ入れる直前に会社名・domain・既存recordを照合し、重複lead、誤った担当者、古いsourceが混ざっていないか確認します。AIが提示した候補は人が修正できる形で保存し、仮説が外れた場合も次回の調査項目へ戻せるようにします。

Source conflictを解決する確認表

同じ会社について公式ページ、IR資料、採用情報の値が違う場合は、都合のよい方を採用せず、項目ごとに発行主体・公開日・対象期間を比べます。たとえば従業員数なら、連結か単体か、何年何月時点かが揃っていなければ直接比較できません。現在の値を確認できない場合は、古い数値を現状の事実にせず、期間付きの履歴かunknownとして保存します。

表は横にスクロールできます

確認点	見ること	未解決時
会社同定	公式domain、法人名、所在地	同名企業候補を統合しない
発行元	会社自身か転載記事か	二次引用だけで確定しない
日付	公開日、更新日、対象期間	最新とは推定しない
主張の範囲	法人全体か製品・部門単位か	範囲を狭めて記録
表現	事実か自社の宣伝文句か	客観Factと会社の自己説明を区別