本文へ移動
MakeAI

MAKEAI JOURNAL / 活用事例

Claudeで企業調査する方法|出典確認から商談前メモまで【2026年10月更新】

MakeAI編集部 公開 2026.10.06 更新 2026.10.20

Claudeで企業調査。事実と仮説を、分けて読む。MakeAI実務ガイド。

Claudeで商談前の企業調査をするときは、営業側の立場と調べる公式URLを指定し、「公開ページの事実」「営業側の仮説」「商談で確かめる質問」を分けて出力します。リンク先の本文まで確認し、会社が掲げる方針から、実際の課題や予算を決めつけないことが大切です。

この記事では、MakeAIの公開サイト3ページをClaudeに読み込ませた操作と、回答を修正した過程を紹介します。実際に行ったのは企業調査の操作検証です。顧客案件や受注成果ではなく、提案するサービスも検証用の架空設定です。

情報確認・操作日:2026年9月8日。ブラウザー版Claude、Maxプラン、画面表示「Opus 5/最大」。ウェブ検索を有効にし、このチャットのメモリはオフで試しました。

ClaudeのWeb検索を有効にし、調査対象を指定する

Claudeの新しいチャットで、入力欄の「+」から「ウェブ検索」にチェックが付いていることを確認します。公式ヘルプでは、Web検索を有効にすると、渡したURLのページ本文を取得する機能も使えると説明されています。Team・Enterpriseで利用する場合は、組織側の有効化が必要です。操作の基準はClaude公式のWeb検索の案内をご確認ください。

最初の調査は、会社概要・関係する事業・事例など、商談準備に必要な少数のページへ絞ると照合しやすくなります。今回指定したのは、次の3ページです。

対象ページ 確認したいこと そのページだけで決めないこと
MakeAIの会社概要 会社が掲げる事業、行動指針 人員構成や社内の実際の運用状況
生成AI導入支援・業務自動化 提供内容、説明されている工程 今回の調達予算や購入意思
制作事例 掲載されている制作物と説明 掲載物の数を顧客社数や売上成果へ読み替えること

ページにある「当社はこう支援します」は、その会社の説明として記録します。自分たちが現場を見て検証した事実とは区別してください。読む範囲が3ページなら、「3ページに記載がない」と書き、会社全体で情報を公開していないとは断定しません。

最初の回答で、情報の正しさと質問の用途を別々に確認した

初回は「3ページだけを開き、事実5件、未確認事項3件、商談で検証する仮説2件をまとめる」と依頼しました。取得できないページは明記し、出典にない予算や課題を補わない条件も付けています。

実行履歴に3URLの取得が表示され、回答には会社概要、事業内容、導入支援の工程、制作物の掲載についての表が出ました。一方、商談質問には、過去案件の測定結果や受託体制を確認するものが含まれていました。

これらは発注先を検討する場面では使える質問ですが、営業担当者が相手へ提案する準備とは目的が違います。「商談前」という指定だけでは、売り手なのか買い手なのかが伝わっていませんでした。そこで営業側の立場と提案内容を追加し、質問を作り直しました。

確認した項目 今回の結果 編集時の判断
指定URLを参照したか 3件の取得履歴が表示された 回答だけを信じず、こちらでもページ本文を読んだ
従業員数・調達予算・最優先課題を補っていないか 指定ページの範囲では未確認とされた 「不明」を具体的な人数・金額・課題に書き換えない
質問が今回の営業の目的に合うか 初回は発注先を審査する質問に寄った 架空の提案内容を追加して再生成した
根拠を開き直せるか 初回の事実表ではURLが短い表記だった 修正版では完全なURLと見出しを指定した

修正後:会社の方針を、決めつけない確認質問へ変える

追加した設定は「架空の営業担当が、MakeAIへ複数案件の手順・確認記録を引き継ぎやすく整理する支援を提案する」というものです。MakeAIがその支援を求めていると確認したわけではない、と明記しました。

以下は修正版の回答を読みやすく要約したものです。事実欄は、実際の公開ページの見出しと本文へ戻って照合しました。仮説と質問は営業準備用の案であり、相手から聞いた話ではありません。

会社概要の行動指針から作った質問

  • 公開記載:会社概要の行動指針04では、属人化を避け、手順とテンプレートとして残す方針を示している。
  • 根拠:会社概要「Principles/行動指針」の「属人化させない」。
  • 未検証の仮説:複数案件で、引き継ぎの形式をどこまで共通にするかを確認する場面があるかもしれない。
  • 確認質問:案件をまたいで、形式を揃えている部分と、あえて揃えていない部分はありますか。

「属人化させない」という方針があることから、「現在属人化して困っている」とは言えません。すでに十分な仕組みがある場合も含めて答えられる質問にします。

サービスの納品内容から作った質問

  • 公開記載:導入支援ページでは、手順・テンプレート・NG規則・確認方法を運用キットにまとめると説明している。
  • 根拠:導入支援「02/Delivery」の「運用キットとして渡す」。
  • 未検証の仮説:案件ごとのキットを比較・再利用しやすく整理する需要があるかもしれない。
  • 確認質問:運用キットは案件をまたいで共通の形式にしていますか。改訂の記録は、今の方法で足りていますか。

この質問への回答によって、提案の必要がないと分かることもあります。AIの調査メモは、提案を押し通す理由を作るものではなく、次に確かめる内容を絞るために使います。

企業調査に使えるプロンプト

今回の修正を踏まえ、最初から営業側の立場を入れたMakeAIのテンプレートです。下の完成形そのものを別条件で再試験した結果ではありません。括弧内を埋め、自社の商談に合わせて質問の数を調整してください。

企業調査のメモを作成してください。

営業側の立場:[何を提供する会社・担当者か]
提案を検討する内容:[仮の支援内容]
今回の目的:[初回面談で何を確認したいか]
対象企業:[名称]
参照する公式URL:[会社概要・対象事業・事例など]
対象企業に需要があることは、まだ確認できていません。

指定URLの本文を実際に開いてください。
取得できなかったURLは明記し、読んだものとして扱わないでください。
過去チャットや検索結果の短い説明だけを根拠にしないでください。

出力:
1. 各URLの取得可否とページ名
2. 公開記載として確認できる事実
   [事実/完全な根拠URL/見出し/出典で分かる範囲]
3. 商談で確認する仮説と質問
   [根拠となる事実/営業側の未検証仮説/決めつけない質問]
4. 提案に必要だが、指定ページでは分からないこと

条件:
・企業の方針と、現場で起きている課題を混同しない。
・掲載された制作物を、顧客側の成果の証明に変えない。
・従業員数、予算、決裁者、購入意思を推測で補わない。
・見出し・引用・URLを作らず、根拠がなければ未確認とする。
・根拠URLは開けるリンクで示す。
・外部への連絡やメール送信は行わない。

対象ページに商品名や関係会社が複数出てくる場合は、どの法人・事業について書いているかも確認します。別会社の情報を対象企業の事実として混ぜないようにします。

出典付きでも、そのまま営業メモへ採用しない

確認は「リンクが開くか」で終わりません。原文がその主張を支えているかを、次の順で見ます。

  1. 対象:その会社・事業・製品についての記載か。
  2. 範囲:本文で説明されている条件を省いていないか。
  3. 時点:公開日や更新日、対象期間が分かるか。取得日と混同していないか。
  4. 表現:「掲載している」「予定している」が「実施済み」に変わっていないか。
  5. 用途:今回の商談で確かめる必要のある情報か。

例えば、自社制作物を紹介するページを根拠に「多数の導入企業で効果が出ている」と書くのは範囲を広げすぎです。事実として採用できるのは、そのページに何が掲載されているかまでです。

商談準備の記録には、担当者、確認日、対象URL、採用した事実、保留した仮説を残します。調査結果を共有するときは、受け取った人も原文へ戻れる形にしてください。

よくある質問

URLを渡せば、必ずページを読めますか?

必ず取得できるとは限りません。今回の3ページは取得できましたが、ログインや接続状況、ページの条件によって結果は変わります。取得できなかった場合は対象から外すか、利用できる本文を出典と確認日付きで渡し、その方法で作ったメモだと記録します。

企業サイトに書いていないことは、検索範囲を広げれば分かりますか?

調べられる範囲は増えますが、記載のない予算や購入意思が確定するわけではありません。追加するなら公表資料の発行者・対象企業・時点を確認し、商談でしか確かめられない事項は質問に残します。

調査メモをそのまま提案書に入れてもよいですか?

採用する事実を照合したうえで、提案書の目的に合うものを選びます。営業側の仮説は仮説として明示し、相手の承認や合意を得た内容として書かないでください。

調査を商談前の十五分で読めるメモに整える

以下は、本記事の実操作をもとにMakeAIが提案する編集手順です。商談時間や受注率が改善した実測ではありません。企業情報を多く集めても、営業担当者が面談の直前に使えなければ調査の目的を果たせません。完成したメモは、会社の事実、今回聞きたいこと、聞いた答えによって変わる提案、の順に整理します。沿革や所在地は、今回の面談で必要な場合だけ残します。

仮に制作会社へ「制作後の引き継ぎ資料を整理する支援」を提案する場合を考えます。事実として採用するのは、相手の公式ページに記載された納品物や支援範囲です。そこから「引き継ぎで困っているはず」と決めず、「今は誰がどの資料を受け取り、更新しているか」を質問にします。相手が現在の運用に満足しているなら、こちらの支援が不要である可能性も含めて面談を進めます。

商談前メモを一枚に整理してください。
冒頭:今回の面談で確かめたいことを一文。
事実:指定公式ページで確認できた事実を最大三件。
各事実に、根拠URLとその記載の対象を付ける。
質問:事実に対応する質問を三件。回答を誘導しない。
分岐:相手の回答がAの場合とBの場合に、次に何を聞くか。
未確認:予算、時期、担当、既存の仕組みで分からないこと。
調査で分かったことと、面談で確認することを混ぜない。
営業側が望む結論へ質問を誘導しない。

答えによって次の行動を変えられる質問にする

「AIに興味がありますか」だけでは、次に何を提案するか決めにくくなります。「引き継ぎ資料を作るとき、転記、確認、更新のどこに時間がかかっていますか」なら、相手の言葉から対象業務を絞れます。ただし、時間がかかっていること自体をまだ確認していない場合は、「今の作業で変えたい部分はありますか」と先に聞きます。問題があることを前提にしない順番が必要です。

面談後は、仮説を確定情報へ自動で昇格させず、実際に聞けた答えだけを追記します。たとえば「資料の形式は共通化済み」と分かれば、形式統一の提案は外します。「改訂時に差分を確認する作業が負担」と分かったなら、その工程について別の調査をします。調査メモは提案書を量産する材料ではなく、相手の答えに応じて提案を変えるための材料です。

調査先が複数の法人にまたがる場合

会社概要、サービスサイト、採用サイトで表記が違う場合は、運営法人と対象事業を確認します。グループ全体の人数を一事業部の人数として書かないこと、親会社の事例を対象法人の実績へ置き換えないことが基本です。記事やインタビューを追加する場合も、発言者の所属と掲載時点を記録します。企業名が同じ検索結果だからという理由だけでは採用しません。

一つの確認表に「主張/対象法人/対象事業/対象時点/根拠」を並べると、混ざった情報を見つけられます。対象が確定しない行は商談前メモの事実欄から外し、必要なら未確認欄に残します。これは不都合な情報を消す作業ではなく、相手について言い切れる範囲を揃える作業です。

検索結果が取得できないときの切り替え方

Claudeがページを開けない場合は、同じURLを何度も依頼するより、取得できなかったページを一覧にします。担当者が利用可能な公式資料を別途確認し、必要な部分を出典付きで渡せるか判断してください。その場合は「ClaudeがWebを確認した調査」ではなく、「担当者が渡した本文に基づく整理」と記録します。取得方法の違いを残せば、後から確認すべき箇所が分かります。

公式ヘルプは、検索結果に出典が付く仕組みを説明していますが、出典があることと、営業側の解釈が正しいことは別です。2026年10月20日に再確認した公式ヘルプを参照し、現在の画面で検索機能の利用条件を確認したうえで、本記事の根拠照合を組み合わせてください。画面の操作を再実行した新たな検証ではありません。

出典と検証条件

製品の操作説明は本文のClaude公式ヘルプを2026年9月8日に確認しました。同日、MakeAIの公開ページ3件を、ブラウザー版Claudeで1チャット・2回の入力を通じて参照しました。記事内の結果はこの操作の記録です。調査時間の短縮率、他社サイトでの正確性、商談・受注への効果は測定していません。

企業調査を、営業チームで使える手順にする

MakeAIでは、営業前の調査、記録項目、根拠の確認方法を整理し、担当者が使うテンプレートや業務フローを設計します。現在の調査メモと、商談で確かめたい項目からご相談いただけます。

営業業務のAI活用を相談する →
導入支援・業務自動化の内容を見る
支援内容をまとめた資料を見る