BtoBリード獲得自動化の設計図｜スクレイピング×AI営業メールを10社から安全に始める方法

「見込み客を探すだけで午前中が終わる」「企業ごとの営業メールを書く時間がない」「自動送信したいが、誤送信や迷惑メール判定が怖い」

BtoB営業では、商談そのものよりも、企業検索、情報整理、提案理由の作成、CRMへの転記に時間を取られがちです。

これらの作業は、次のパイプラインに分解できます。

1. 公開情報から候補企業を収集する
2. 対象外企業と重複を除外する
3. 提案根拠がある企業だけを採点する
4. AIが企業別の営業メールを下書きする
5. 法務・品質ゲートを通過した文面だけを承認する
6. 返信、商談、配信停止、苦情を記録する
7. 結果を次回のターゲット条件へ反映する

この仕組みを構築すれば、毎朝ゼロから営業リストを探す必要はありません。夜間に候補企業を収集し、翌朝には「連絡する理由」「取得元」「AI下書き」「送信可否」が並んだ状態を作れます。

ただし、BtoBリード獲得の自動化は、無差別な大量送信ではありません。取得先の利用規約、個人情報、広告宣伝メールの規制、送信ドメインの評価を守り、異常時に自動停止できる設計が前提です。

本記事では、初心者が10社の手作業検証から始め、スクレイピングとAI営業メールを段階的に自動化する手順を解説します。

BtoBリード獲得の自動化とは

BtoBのリード獲得とは、将来顧客になる可能性がある企業との接点を作る活動です。

たとえば、採用支援会社が「営業職を募集中のSaaS企業」を見つけ、求人ページを根拠にサービスを提案する活動が該当します。

営業自動化システムは、次の7層に分けると管理しやすくなります。

1. 情報源
   企業公式サイト、官公庁の公開データ、業界団体、プレスリリースなど

2. スクレイピング
   企業名、公式URL、事業内容、採用状況などを取得する処理

3. データ整形
   表記ゆれ、重複、欠損、古い情報を整理する処理

4. リードスコアリング
   課題シグナルや対象条件を点数化する処理

5. AI営業メール生成
   確認できた事実から提案理由とメール下書きを作る処理

6. 法務・品質ゲート
   営業拒否表示、根拠不足、重複送信、誤った固有名詞などを検査する処理

7. CRM・改善ログ
   返信、商談、失注、配信停止、苦情を記録する仕組み

スクレイパーからメール送信機能を直接呼び出してはいけません。取得データをいったん保存し、重複排除、抑止リスト照合、根拠確認を通過したレコードだけを送信候補へ移します。

この分離により、誤取得がそのまま誤送信につながる事故を防げます。

実行ログから確認できた自動化資産の条件

私は2026年7月19日、このサイトのローカルリポジトリを実際に確認しました。検証時のGitコミットは8ad0a28です。

記事数は、次のPowerShellコマンドと同等の条件でMarkdownファイルを集計しました。

rg --files sites/ai-tech/content/posts -g "*.md"
rg --files sites/business/content/posts -g "*.md"
rg --files sites/real-estate/content/posts -g "*.md"

集計結果は次のとおりです。

これは公開済みURL数、検索流入、営業施策の成果ではありません。確認時点のローカル作業ツリーに存在した記事ファイル数です。下書きや未公開ファイルが含まれる可能性があるため、公開本数としては扱えません。

同じリポジトリでは、次の運用設定も確認できました。

• generator/config.yamlで本文の目安を5,000〜7,000字に設定
• 同ファイルのsite_mapで3サイトへの振り分けを管理
• generator/ai_slop_guidelines.jsonで最低品質スコアを8に設定
• 同JSONに独自情報、数字の根拠、画像、限界、読後アクションなど10項目の検査条件を保存
• run_daily.batからscripts/run_daily_guarded.pyを起動
• 実行前に日次・週次の生成上限を確認し、上限到達時は生成を止める

この807本から「営業メールを自動化すれば売上が増える」とは結論づけられません。確認できるのは、設定、生成、検査、配信を分離し、上限と停止条件をコード化すれば、反復作業を蓄積可能な運用へ変えられるという点です。

同じ設計をBtoB営業へ移すなら、次の形になります。

• ターゲット条件を設定ファイルで管理する
• 取得、採点、生成、承認、送信を分離する
• 根拠が欠けたリードには送信しない
• 上限件数を超えたら処理を止める
• 除外理由と停止理由をログへ残す
• 結果を次回のターゲット条件へ反映する

なお、記事内の図はシステム構成を理解するためのイメージであり、稼働実績を示す画面キャプチャではありません。一次情報として再検証できるのは、上記のコマンド、ファイルパス、設定値です。

ステップ1：自動化前に10社を手作業で評価する

最初からスクレイパーを作ると、不要なデータまで大量に集める可能性があります。

まず、候補企業10社を手作業で調査してください。各社について、次の5点を記録します。

企業名:
公式URL:
確認できた課題シグナル:
取得元URL:
提案する理由:

「売れそう」「成長していそう」のような主観的表現は避け、機械が判定できる条件へ置き換えてください。

採用支援サービスなら、次のように定義できます。

• 所在地が東京都内
• SaaSまたはWebサービスを提供
• 公式サイトに営業職の求人がある
• 法人向け問い合わせ窓口がある
• 既存顧客、競合、商談中の企業ではない
• 営業連絡を拒否する表示がない

10社を評価した時点で提案理由を書けない場合、問題はAIの文章力ではなく、ターゲット条件か取得項目にあります。

この10社は、後から自動判定の精度を測るための「正解データ」にもなります。人間が付けた送信可否と、自動処理の判定結果を比較できるよう、判定理由まで残してください。

ステップ2：情報源ごとに取得可否を確認する

情報源ごとに、次の台帳を作ります。

サイト名:
利用規約URL:
robots.txtの確認日:
取得を禁止されたパス:
取得予定項目:
取得頻度:
ログインの要否:
営業利用の可否:
確認者:
次回確認日:

robots.txtは、クローラーがアクセスしてよいURLを伝え、主にクロール負荷を管理するための仕組みです。Google検索セントラルの解説でも、検索結果から情報を隠す仕組みとは別であると説明されています。

したがって、次の判断を分ける必要があります。

• 技術的に取得できるか
• robots.txt上でアクセスが認められているか
• 利用規約上、取得や再利用が認められているか
• 取得した情報を営業目的で使えるか
• その宛先へ広告宣伝メールを送信できるか

robots.txtで許可されていることは、利用規約や法令上の営業利用まで許可されていることを意味しません。

ログイン必須ページ、技術的制限の回避が必要なページ、営業利用を禁止しているサービスは初期対象から外します。判断が難しい情報源は、運営者に許可を求めるか、公式APIや正規に購入できるデータへ切り替えてください。

ステップ3：保存項目と削除ルールを決める

初期版で必要な項目は次の程度です。

担当者名や個人メールアドレスを、目的や保存期間を決めずに収集する設計は避けます。

個人情報保護委員会は、ユーザー名やドメイン名から特定の個人を識別できるメールアドレスは、それ単独で個人情報に該当し得ると説明しています。個人を識別できない場合でも、通常は個人関連情報に該当すると考えられます。個人情報保護委員会のFAQを確認し、取得目的、アクセス権、保存期間、削除方法を決めてください。

少なくとも、次の削除ルールを事前に定義します。

送信不可リード: 判定から30日後に再確認または削除
根拠URLが失効したリード: 送信キューから即時除外
配信停止企業: 送信データは削除しても抑止情報は保持
担当者の個人情報: 利用目的を終えた時点で削除
監査ログ: 法務・セキュリティ担当と保存期間を決定

期間は一律の正解ではありません。業務上の必要性と法令・社内規程に合わせて決めます。

ステップ4：低負荷のスクレイピング処理を作る

静的HTMLならPythonのrequestsとBeautifulSoup、JavaScript実行後に情報が表示されるページならPlaywrightが候補になります。

実装時は次を確認します。

• 連絡先を含む固有のUser-Agentを設定する
• 同一URLを短時間に繰り返し取得しない
• 対象サイトごとにアクセス間隔を設定する
• タイムアウトと再試行回数に上限を設ける
• 403や429が続いたら自動停止する
• 必要な項目だけを保存する
• 取得日時、HTTPステータス、取得元URLを記録する
• 利用規約とrobots.txtの確認日を保存する

万人共通の「安全なアクセス間隔」はありません。最初は10〜30ページに限定し、エラー率、応答時間、欠損率を確認してから対象を広げます。

初期検証では、次の結果を残してください。

対象URL数:
取得成功数:
取得失敗数:
平均応答時間:
403件数:
429件数:
必須項目の欠損数:
HTML構造の例外数:
開始時刻:
終了時刻:

アクセス間隔だけでなく、並列数も制限します。1秒間隔でも10並列なら、対象サイトには毎秒10リクエストが届く可能性があります。

ステップ5：重複排除と抑止リストを作る

企業名だけでは、「株式会社ABC」と「ABC株式会社」を別企業と誤判定する可能性があります。

可能であれば、次の項目を組み合わせて同一企業を判定します。

• 正規化した企業名
• 公式ドメイン
• 法人番号
• 電話番号
• 住所

次の企業は、通常のリード一覧とは別の抑止リストへ保存します。

• 配信停止を依頼した企業
• 苦情があった企業
• 営業連絡を拒否している企業
• 既存顧客
• 商談中の企業
• 競合
• 取得根拠が確認できない企業

抑止リストは、リード登録時だけでなく、送信直前にも照合します。過去のCSVを再投入したときに、配信停止済み企業が復活する事故を防ぐためです。

抑止リストには、必要以上の個人情報を保存せず、照合に必要な識別子、登録理由、登録日時、確認者を記録します。

ステップ6：説明可能なリードスコアを設定する

初期段階では、AIに最終判定を任せず、説明可能なルールで採点します。

対象業種に一致: +3
明確な課題シグナルがある: +3
法人向け連絡窓口がある: +2
取得から30日以内: +1
自社事例との共通点がある: +1

取得元URLがない: 送信不可
営業拒否表示がある: 送信不可
抑止リストに一致: 送信不可
企業名とドメインが一致しない: 要確認

「30日以内」や各配点は検証用の仮ルールです。求人情報なら短く、変更の少ない企業情報なら長くするなど、情報の更新頻度に合わせて調整します。

たとえば、合計7点以上を送信候補にすると決めた場合も、点数だけで送信してはいけません。送信不可条件はスコアより優先します。

if suppression_match:
    status = "送信不可"
elif refusal_notice:
    status = "送信不可"
elif source_url_missing:
    status = "送信不可"
elif company_domain_mismatch:
    status = "要確認"
elif score >= 7:
    status = "承認待ち"
else:
    status = "保留"

AIには公開情報の要約と仮説作成を担当させ、送信可否は決定ルールと人間の承認で管理したほうが監査しやすくなります。

ステップ7：AI営業メールの入力と出力を固定する

AIへ企業のURLだけを渡して「自然な営業メールを書いて」と依頼すると、根拠のない課題を作る可能性があります。

入力を次の形式へ固定します。

企業名:
事業内容:
確認できた課題シグナル:
課題シグナルの取得元URL:
提案サービス:
提供できる根拠:
使用禁止表現:
本文の文字数上限:

出力形式も固定します。

件名:
本文:
連絡する理由:
本文で使用した事実:
推測として扱った箇所:
根拠URL:
送信前の確認事項:

たとえば、「営業職を募集している」は求人ページで確認できる事実です。一方、「採用に苦戦している」は、公開情報だけでは確認できない推測です。

推測を本文に入れる場合は、「採用強化の過程で、候補者対応の工数が増えている可能性はないでしょうか」のように、質問または仮説として表現します。

入力から承認までの具体例

以下は実在企業の事例ではなく、検証用の架空例です。

企業名: 株式会社サンプルクラウド
事業内容: 法人向け勤怠管理SaaS
確認できた課題シグナル: 営業職を3職種募集している
課題シグナルの取得元URL: https://example.com/recruit/sales
提案サービス: SaaS企業向け営業採用支援
提供できる根拠: 同規模SaaS企業での支援事例がある
使用禁止表現: 採用に苦戦している、急成長している
本文の文字数上限: 350字

AIの下書きが次のようになったとします。

件名: 営業採用の候補者対応について

本文:
株式会社サンプルクラウドの採用ページで、営業職を3職種募集されていることを拝見しました。
採用強化の過程で、母集団形成や候補者対応の工数が増えている可能性はないでしょうか。
弊社では、同規模のSaaS企業を対象に営業採用を支援しています。
ご関心があれば、支援内容を1枚にまとめた資料をお送りします。

この下書きは、そのまま送らず、次を確認します。

文章が自然でも、根拠、送信者表示、受信拒否方法、履歴照合が欠けていれば送信不可です。AIの評価と送信可否を分けることが、事故を防ぐポイントです。

ステップ8：品質ゲートと自動停止条件を設定する

無人送信へ進む前に、次の検査を自動化します。

• 取得元URLへアクセスできる
• 企業名と公式ドメインが一致する
• 抑止リストに含まれない
• 本文中の企業名とサービス名が正しい
• 固有の事実を取得元で確認できる
• AIの推測が断定表現になっていない
• 法令上必要な送信者情報と受信拒否方法が記載されている
• 同一企業への送信履歴がない
• 1日あたりの送信上限を超えていない

さらに、次の異常を検知したら処理を止めます。

初期値の例は次のとおりです。

1日の送信上限: 10件
同一企業への再送禁止期間: 90日
根拠URL欠損: 1件でも送信停止
企業名不一致: 1件でも該当レコードを隔離
連続バウンス: 3件で対象リストを停止
苦情: 1件でも全送信を停止して確認

これらは推奨値ではなく、少量検証を始めるための保守的な例です。自社の法務判断、ドメイン評価、リスト品質、送信実績に合わせて調整してください。

最初は下書き生成までを自動化し、人間が全件承認します。誤判定の種類と頻度を把握した後で、根拠が明確な低リスクセグメントだけを自動送信へ移します。

ステップ9：特定電子メール法と個人情報を確認する

日本の広告宣伝メールには、特定電子メール法などが関係します。広告宣伝メールは原則として事前同意が必要で、取引関係やメールアドレスの公表など、法令上の例外があります。

ただし、「Webサイトにメールアドレスが掲載されている」という事実だけで、すべての営業メールが適法になるわけではありません。公表と併せて広告宣伝メールを拒否する表示がある場合や、取得方法、利用目的、メールの内容、送信先、表示事項によって判断が変わります。

送信者情報や受信拒否方法などの表示義務もあります。運用開始前に、消費者庁の特定電子メール法ページと、同庁の特定電子メール法のポイントから現行の法令・ガイドラインを確認してください。

次の条件がある場合は、法務担当者または専門家へ個別に確認します。

• 個人名を含むメールアドレスを収集する
• 問い合わせフォームへ営業文を自動投稿する
• 海外企業や海外在住者へ送信する
• 医療、金融、人事など機微性の高い情報を扱う
• 第三者から購入したリストを利用する
• 大量配信や追客メールを自動化する

問い合わせフォームは、メールとは規約や技術的な扱いが異なります。フォームの利用目的が「顧客からの問い合わせ」に限定されている場合、営業投稿が規約違反になる可能性があります。CAPTCHAやアクセス制限を回避する実装も行わないでください。

本記事は技術・運用上の一般情報であり、個別案件の法的判断を示すものではありません。法令やガイドラインは改正される可能性があるため、実装時点の公的資料を確認してください。

ステップ10：返信結果を次回の選定へ戻す

送信後は、少なくとも次の状態を記録します。

未送信 / 承認待ち / 送信済み / 返信あり / 商談化
対象外 / 保留 / 配信停止 / 苦情 / 不達 / 送信失敗

返信文をAIに作らせる場合も、次の内容は人間へ戻します。

• 価格交渉
• 契約条件
• クレーム
• 個人情報
• セキュリティに関する質問
• 競合比較
• 法的責任を伴う回答

自動化の目的は営業担当者を排除することではありません。調査、転記、初稿作成を減らし、人間を商談と例外判断へ集中させることです。

返信がなかった企業を、根拠なく「関心なし」と分類するのも避けてください。不達、未開封、タイミング、提案との不一致を区別できなければ、次回のターゲット条件を誤って調整する可能性があります。

専門家が確認する5つのポイント

1. 「送信できる」と「送る価値がある」を分ける

法令・規約上の確認を通過しても、提案との関連が薄ければ送るべきではありません。

「なぜこの企業へ、なぜ今、この提案をするのか」を一文で説明できないリードは保留にします。

2. 収集件数より出典付きリード数を重視する

出典のない1,000件より、取得元と選定理由を追跡できる100件のほうが改善に使えます。

リード数だけを目標にすると、重複、古い情報、対象外企業が増えやすくなります。

3. スクレイパーと送信機能を分離する

収集したデータをデータベースへ保存し、品質ゲートを通過したレコードだけを送信キューへ移します。

誤取得やHTML構造の変更が、即座に誤送信へつながらない構成にしてください。

4. 自動停止を先に実装する

担当者が異常に気づくまで処理が続く設計は危険です。

送信上限、バウンス、配信停止、苦情、取得エラー、AI出力異常の停止条件を、送信数を増やす前に実装します。

5. 監査ログから同じ判断を再現できるようにする

次の情報を実行ID単位で保存します。

実行ID:
実行日時:
ターゲット条件のバージョン:
プロンプトのバージョン:
使用したAIモデル:
取得元URL:
取得日時:
判定結果:
除外理由:
承認者:
送信結果:
停止理由:

「なぜ送ったのか」「なぜ除外したのか」を後から再現できない仕組みは、件数が増えるほど修正が難しくなります。

AIモデルやプロンプトを変更すると、同じ入力でも出力が変わる可能性があります。判定の再現性を高めるため、モデル名、プロンプトのバージョン、生成日時も記録してください。

営業自動化の監査ダッシュボード

ダッシュボードには、成功件数だけでなく、失敗と停止理由も表示します。

実行ID: pilot-20260719-001
取得候補: 50件
出典確認済み: 31件
送信候補: 12件
人間承認: 8件
保留: 4件
除外: 重複7件 / 拒否表示2件 / 根拠不足10件

これは表示例であり、実績値ではありません。実運用の画面では、対象期間、ターゲット条件、母数、実行IDを併記してください。

件数の整合性も検査します。上の例では、取得候補50件に対して、出典確認済み31件と根拠不足10件だけでは全件の状態を説明できません。重複や拒否表示が出典確認前に除外されたのか、複数理由を持つ企業が重複集計されているのかを明示する必要があります。

監査用の集計では、次のどちらかに統一します。

• 各企業に主要な除外理由を一つだけ付け、合計を母数と一致させる
• 複数理由を許可し、「延べ件数」であることを表示する

数字が合わないダッシュボードは、見栄えがよくても改善判断には使えません。

よくある失敗と改善方法

最初から大量取得する

原因：必要項目と除外条件が固まっていない。
対策：10社を手作業で評価し、その後30社程度で欠損率と重複率を確認する。

AIにメール作成を丸投げする

原因：提案理由、事実、取得元が入力されていない。
対策：事実と推測を分け、根拠URLのない固有表現を禁止する。

公開情報なら自由に使えると考える

原因：公開、取得、再利用、営業送信を同じ許可として扱っている。
対策：robots.txt、利用規約、個人情報、送信規制を別々に確認する。

返信率だけを追う

原因：配信停止、苦情、不達を成果の裏側へ隠している。
対策：返信率と同じ画面に、バウンス率、配信停止率、苦情件数を表示する。

初日から完全自動送信する

原因：誤判定のパターンを把握する前に送信権限を渡している。
対策：収集、分類、下書き生成から始め、承認ログを蓄積してから対象を限定して自動化する。

AIの文章品質だけを改善する

原因：入力データの欠損を、プロンプトの修正で解決しようとしている。
対策：承認できなかった理由を「根拠不足」「対象外」「表現不良」「事実誤認」に分け、入力と生成のどちらに問題があるかを特定する。

BtoBリード獲得で追うべきKPI

初期値を業界共通の正解として固定してはいけません。最初の30〜100件を基準期間として、自社の通常値を計測してください。

改善時は、一度に複数の条件を変えず、ターゲット、件名、本文、送信タイミングのいずれか一つを変更します。複数要素を同時に変えると、何が結果に影響したか分からなくなります。

母数が少ない段階では、返信率の数ポイントの差を成功と判断できません。10件中1件の返信と20件中2件の返信は、どちらも10％ですが、再現性を判断するには不十分です。率だけでなく、母数と対象期間を必ず併記してください。

完全自動化が向かないケース

次の営業では、人間承認を残したほうが安全です。

• 1件あたりの契約金額が大きい
• 対象企業が少なく、誤送信の損失が大きい
• 医療、金融、法務、人事を扱う
• 個人情報や機密情報を多く扱う
• 提案内容が企業ごとに大きく異なる
• 問い合わせフォームの規約が不明
• 海外法令の確認が必要

また、営業自動化は売上を保証しません。商材と市場の適合、実績、価格、営業担当者の対応が弱ければ、リストとメールを自動生成しても商談にはつながりません。

AIが作成した文章の自然さも、受信者にとっての価値を保証しません。企業名や公開情報を差し込んだだけの文面は、形式上はパーソナライズされていても、提案との関連性がなければ迷惑な営業メールです。

自動化の価値は大量送信ではなく、根拠のある候補を同じ基準で選び、危険な送信を止め、結果から条件を改善できることにあります。

今日から始める最小検証

次の列を持つスプレッドシートを作成してください。

企業名 / 公式URL / 取得元URL / 課題シグナル
提案理由 / 取得日 / 送信可否 / 除外理由
AI下書き / 承認結果 / 返信結果 / 配信停止

候補企業を10社だけ手作業で入力し、次の順に評価します。

1. 送信候補と除外企業を分類する
2. 各社へ連絡する理由を一文で書く
3. 事実と推測を分けてAIへ入力する
4. AIにメール下書きを生成させる
5. 事実誤認、汎用表現、根拠不足を記録する
6. 承認数をAI生成数で割り、下書き承認率を算出する
7. 承認できない理由を分類する
8. 最も多い失敗原因を一つ修正する
9. 修正後の条件で次の10社を評価する

最初の検証では、実際に送信する必要はありません。下書きの作成と人間による承認判定だけでも、取得項目とターゲット条件の問題を発見できます。

承認率が低い場合、すぐにプロンプトを書き換えるのではなく、入力データを確認してください。提案根拠が薄ければ、どれだけ文章を調整しても企業固有のメールにはなりません。

10社の検証を終えたら、次の4点を確認します。

取得元URLを確認できた企業数:
連絡する理由を一文で説明できた企業数:
AI下書きを修正なしで承認できた企業数:
送信不可・保留にした主な理由:

この結果が、次に実装すべき機能を決めます。

• 根拠URLが不足するなら、スクレイピング項目を見直す
• 対象外企業が多いなら、ターゲット条件を見直す
• 事実誤認が多いなら、AIへの入力形式と検証処理を見直す
• 重複が多いなら、企業IDと正規化処理を先に実装する
• 拒否表示を見落とすなら、送信可否の確認を自動化する

BtoB営業を「止まれる仕組み」に変える

BtoBリード獲得は、企業検索、情報整理、採点、メール下書き、結果記録へ分解すれば、広い範囲を自動化できます。

構築順序は次のとおりです。

1. 10社を手作業で評価する
2. 情報源の取得条件を確認する
3. 保存項目と削除ルールを決める
4. 小規模にスクレイピングする
5. 重複排除と抑止リストを作る
6. 説明可能なルールで採点する
7. 事実と推測を分けてAIへ渡す
8. 品質ゲートと停止条件を実装する
9. 法令と送信ルールを確認する
10. 結果を次回の選定へ戻す

最初の目標は完全無人化ではありません。

• 取得元が分かる
• 除外理由を説明できる
• 危険な候補を止められる

まずは、この3条件を満たしてください。

この条件を保ったまま対象範囲を広げれば、人間の作業時間を比例して増やさず、根拠のある商談候補を継続的に供給できる営業基盤へ近づけます。

自動化を実装したい方向けの実践マニュアル

構造を理解しても、データ設計、AIプロンプト、定期実行、監査ログ、収益導線まで一人で組み上げるのは簡単ではありません。

実践マニュアルでは、AI、Web自動化、コンテンツ販売、集客導線を、再実行できる手順へ落とし込む方法を紹介しています。

まずは本記事の10社検証を実施し、取得項目と除外条件を明確にしてください。その結果をもとに実装へ進みたい場合は、次のマニュアルを確認できます。

自動化・収益導線を構築する実践マニュアルを見る