商談前の企業調査をDeep Researchで短時間にまとめる方法

商談前に相手企業のサイト、ニュース、IR資料を開き続けても、商談で何を聞くかまで整理できなければ準備は終わりません。会社概要を短くしただけのメモは読みやすくても、提案の入口にはなりにくいからです。

Deep Researchは、公開ウェブやアップロードしたファイルなど複数のソースを調査し、引用付きの構造化されたレポートにまとめる機能です。調査計画を開始前に確認し、実行中も範囲を調整できます。これを企業情報の収集だけに使わず、確認済み事実、営業側の仮説、商談で聞く質問を分けた一枚まで作ります。

ONE TASK / SAL-01商談準備メモを一枚作る

BEFOREタブだけが増える

企業情報は集まるが、今回の提案とどう結び付くか説明できない。

INPUT一次資料と調査条件

対象、期間、優先ソース、除外条件、読み手を指定する。

OUTPUT事実・仮説・質問

根拠を確認し、商談で確かめる順番に並べる。

最初に答え

「この会社を調べて」ではなく、商談目的、相手の役職、対象期間、優先する一次資料、除外する情報、完成形を指定します。出力は確認済み事実、そこから考えた仮説、商談で確認する質問へ分けます。

売上、拠点数、サービス名、発表日などの重要な情報は、引用先を開いて人が確認します。

調査前に商談の目的を一文にする

同じ会社でも、初回挨拶、業務課題の聞き取り、製品提案、契約更新では必要な情報が違います。最初に次の形で書きます。

A社の営業企画責任者との初回商談で、営業会議後の報告とCRM入力にどの程度の負担があるかを確認し、次回デモの対象業務を一つ決める。

この一文があれば、沿革を詳しく調べるより、営業体制、DX方針、利用中の関連システム、最近の組織変更に優先順位を置けます。相手の個人情報や非公開情報を集めるのではなく、会社が公開している方針と商談目的を結びます。

企業調査を4区分にする

01会社事業、規模、地域、顧客

02変化直近の発表、投資、組織

03仮説起こり得る業務課題

04質問商談で事実を確かめる

会社の基本情報は、提案対象との関係が分かる範囲に絞ります。変化については、直近一年などの期間を指定します。仮説は断定せず、必ず質問へ変換します。

たとえば「拠点が増えた」という確認済み事実から、「会議報告の形式が拠点ごとにばらついている可能性がある」という仮説を置きます。質問は「拠点別の定例報告は同じ様式ですか。集約にどのくらい時間がかかりますか」です。仮説が外れても、相手の業務を知る質問として機能します。

ソースの優先順位を決める

企業調査では、検索上位だから採用するのではなく、主張に近い発信元を優先します。

企業の公式サイト、ニュースリリース、製品ページ
有価証券報告書、決算説明資料、統合報告書
官公庁、自治体、業界団体の公開資料
相手企業の公式採用情報
信頼できる報道や専門媒体
比較サイト、個人の投稿

売上や拠点数は企業の基準日つき資料を確認します。市場規模は調査会社の記事の孫引きではなく、可能なら元調査へ戻ります。公式発表にも企業側の見せ方があるため、競合比較や社会的評価は別ソースと照合します。

非上場企業はIR資料が少ないことがあります。その場合は、会社概要、公式ニュース、採用情報、官公庁の法人情報など、確認できる範囲を明記します。資料が少ないことを、事業が小さい、投資がない、と推測してはいけません。

Deep Researchへ渡す依頼文

調査依頼の型

目的: 誰との何の商談で、最後に何を決めたいか
対象: 企業名、事業、地域、対象部署、調査期間
ソース: 公式サイト、IR、官公庁を優先。二次情報は補助
出力: 確認済み事実、仮説、質問、要確認、出典
除外: 古い情報、出典不明、個人の推測、競合の広告

実際には次のように依頼します。

A社の営業企画責任者との初回商談準備です。目的は、営業会議後の報告とCRM入力の負担を確認し、次回デモの対象業務を一つ決めることです。直近12か月を中心に、公式サイト、ニュースリリース、IR資料、官公庁資料を優先してください。会社の事業構成、営業拠点、直近の組織・DX関連の変化を調べてください。出力は（1）確認済み事実、（2）事実から考えられる営業仮説、（3）商談で確認する質問、（4）根拠不足、（5）出典と基準日に分けます。仮説を事実として書かず、古い情報と最新情報が違う場合は両方を示してください。

会社名が似ている場合は法人番号、所在地、公式URLなど識別情報を添えます。製品名と会社名が違う場合も、調査対象を明確にします。

調査計画を開始前に直す

Deep Researchが示す計画に、会社概要、競合、市場、人物、採用、技術など、何でも入っていたら広すぎます。今回の商談目的に必要な三〜五項目に絞ります。

確認するのは次の点です。

調査対象の会社が正しいか
対象期間が明記されているか
公式一次資料を優先するか
商談目的と関係の薄い項目が多くないか
比較対象や地域が広がりすぎていないか
完成形が一枚で読める量になっているか

途中で別会社の情報が多い、同じニュースが繰り返されている、古い資料に偏っていると気づいたら、実行を止めて範囲を修正します。最後まで待って長いレポートを捨てるより早く済みます。

架空の企業調査メモ

BRIEFINGA社初回商談準備（架空例）

事実: 国内三拠点で法人向け機器を販売。直近の公式発表で営業企画部の新設を確認。基準日と元URLを記録。
変化: オンライン商談比率を高める方針を採用情報で確認。ただし利用中の会議・CRM製品は未確認。
仮説: 拠点ごとの商談メモ集約と、営業企画への週次報告に転記が発生している可能性がある。
質問: 商談後に営業担当が作る成果物は何ですか。週報とCRMへ同じ情報を入力していますか。
要確認: 対象部署の人数、会議件数、現在のツール、入力ルール、社外AIへ渡せるデータ。

提案しないこと：現状を聞く前に、特定ツールの導入や完全自動化を前提にしない。

この一枚では、事実より質問の方が重要です。仮説は会話を始める材料であり、相手の課題を決めつける結論ではありません。

引用を確認する順番

すべての引用を同じ深さで確認すると時間がかかります。商談の結論を変える主張から見ます。

売上、従業員数、拠点数などの数値
組織変更、サービス開始、提携などの日付
相手企業の公式方針として引用する文
提案対象に関係する規制や制度
仮説の土台にした市場変化

引用先を開き、ページ名、発信元、公開日、対象期間を見ます。検索結果の抜粋が正しくても、資料全体の対象地域や年度が違うことがあります。引用が付いていることと、引用が主張を支えていることは別です。

確認できない情報は削除するか、「確認できないため商談で質問」と書きます。空欄を埋めるために古いブログを追加しない方が、準備メモの信頼性は上がります。

商談で使う質問へ変える

良い質問は、相手が具体的な業務を説明できるものです。

「業務効率化に課題はありますか」ではなく「商談後、同じ内容を何か所へ転記しますか」
「AIを使っていますか」ではなく「会議録や顧客情報を入力できる承認済み環境はありますか」
「時間がかかりますか」ではなく「一件の商談後処理に平均何分かかり、誰が確認しますか」
「自動化したいですか」ではなく「送信前に人が必ず判断したい箇所はどこですか」

相手が答えられない場合もあります。そのときは、次回までに測る項目を一つ決めます。想像で課題を補わず、計測へつなげます。

企業調査を短時間で終える基準

深く調べれば品質が上がるとは限りません。次の六点がそろったら一度止めます。

会社と対象事業を説明できる
直近の重要な変化が二〜三件ある
今回の提案に関係する事実がある
営業仮説が二件以内に絞られている
商談で聞く質問が五〜八件ある
重要な主張の元資料を確認した

逆に、事実が多いのに質問が一つもないなら、調査目的へ戻ります。質問が多すぎるなら、商談で決めたいことに近い順で五件へ絞ります。

入力してはいけない情報

公開情報を調べる段階で、顧客から受け取った未公開資料、個人の連絡先、契約内容を無断で追加しません。社内ファイルや接続済みアプリを使う場合は、組織が承認したアカウントとアクセス範囲を確認します。

公開情報と社内情報を同じレポートに混ぜる場合は、各主張の出所が分かるようにします。共有先も分けます。営業メンバー向けのメモと、顧客へ見せる資料を同じファイルにしない方が安全です。

商談前のチェックリスト

NOW / BRIEF一社を一枚にする

事実、仮説、質問、根拠を商談前に確認する。

NEXT / LEARN商談結果を戻す

仮説が当たったかを記録し、質問の型を改善する。

LATER / TEAM営業の共通手順へ

調査ソース、確認欄、保存先をチームでそろえる。

一度の企業調査なら、この記事の型だけで始められます。学習サービスを選ぶ場合も、検索操作だけでなく、根拠確認と商談質問まで演習できるかを見ます。完成とは、情報を多く集めることではなく、相手に確かめる準備が整うことです。