「見込み客を探すだけで午前中が終わる」「企業ごとに営業メールを書く余裕がない」「自動送信を試したら、返信より配信停止依頼が増えた」——BtoB営業では、リスト作成から初回接触までの反復作業が担当者の時間を奪います。
この作業を減らす方法が、スクレイピングによる企業情報の収集、AIによる適合判定、営業メール生成、送信、返信分類、CRM更新を一つの流れにする営業自動化です。
適切に設計すれば、人が毎朝リストを検索しなくても、条件に合う企業が蓄積され、送信可能と判断した相手に個別化されたメールを届けられます。人が対応するのは、判断が難しい例外や、返信・商談が発生した案件です。データと改善履歴が蓄積されるため、仕組みそのものが継続的に価値を生む「営業資産」になります。
ただし、無差別な大量送信は完全自動化ではありません。企業の評判と送信ドメインを傷つける、自動化された迷惑行為です。
本記事では、単に送信件数を増やすのではなく、対象選定、取得根拠、法令確認、品質ゲート、停止条件、収益KPIまで含めて、リード獲得システムを設計する手順を解説します。
スクレイピングとAI営業メールを連携する全体像
スクレイピングとは、Webページから必要な情報をプログラムで取得する処理です。たとえば企業サイトから、会社名、事業内容、所在地、採用状況、問い合わせ窓口などを収集します。
営業自動化の流れは、次の7工程に分けると理解しやすくなります。
- 公開Webページや利用を許諾されたデータソースから企業情報を取得する
- 表記揺れを正規化し、重複を排除する
- 自社サービスとの適合度をAIとルールで判定する
- 送信可否、営業拒否表示、除外条件を確認する
- 相手企業の状況に合わせてAI営業メールを生成する
- 品質検査を通過したメールだけを段階的に送信する
- 返信、商談、受注、粗利を記録し、選定条件へフィードバックする
公開・許諾データ
↓
スクレイピング
↓
正規化・重複排除・送信可否確認
↓
AIとルールによる適合度スコアリング
↓
営業メール生成・品質検査
↓
段階的な送信
↓
返信分類 → CRM → 商談
↑ ↓
└── 受注データで改善 ──┘
一般的な解説では、「リストを集めてAIに文章を書かせる」ところで終わりがちです。本記事で扱うのは、1件の取得元から最終的な粗利までを追跡し、採算のよい条件だけを残す閉ループ設計です。
「完全自動化」という言葉も整理しておきましょう。目指すのは、正常系では人が触らず、拒否、異常値、クレーム、法的判断が必要なケースだけを例外キューへ送る運用です。
人間をゼロにするのではなく、人間の時間を売上に近い判断へ集中させる設計と考えるほうが現実的です。
Hiroの運用ログから分かる「動く自動化」と「稼ぐ自動化」の違い
2026年7月23日、Hiroのローカル運用環境を監査したところ、各サイトのcontent/posts直下には投稿Markdownが合計935本ありました。内訳は、businessが419本、ai-techが374本、real-estateが142本です。
同日の生成台帳generator/.budget_ledger.jsonには、当日11本、当該週96本という記事処理記録が残っていました。一方、同じ台帳の画像生成数は、当日・週ともに0件でした。
確認対象と集計方法は次の通りです。
sites/business/content/posts/*.md 419本
sites/ai-tech/content/posts/*.md 374本
sites/real-estate/content/posts/*.md 142本
合計 935本
generator/.budget_ledger.json
articles_today: 11
articles_this_week: 96
images_today: 0
images_this_week: 0
これらは、2026年7月23日時点のリポジトリ内ファイルと生成台帳を確認した結果です。営業メールの送信実績、返信実績、売上実績を示す数字ではありません。
このログから分かるのは、スケジュール実行によって成果物を増やせても、画像生成や検証など、接続されていない工程は自動では埋まらないということです。
リード獲得でも同じです。取得件数だけが増えていても、送信可否確認、返信分類、商談記録、受注計測が欠けていれば、収益装置とは呼べません。
自動化の稼働率と、営業としての収益性は分けて評価する必要があります。
ステップ・バイ・ステップで作るBtoBリード獲得システム
1. 売りたい相手ではなく「成果が出る相手」を定義する
最初にICPを作ります。ICPはIdeal Customer Profileの略で、受注しやすく、継続価値も高い理想顧客像です。
「中小企業」のような広い条件ではなく、機械判定できる項目へ分解します。
- 業種:不動産管理、士業、SaaSなど
- 地域:国内全域、東京都内など
- 規模:従業員区分、拠点数、店舗数
- 課題の兆候:採用強化、新拠点、新サービス、手作業の多い業務
- 除外条件:競合、既存顧客、過去の拒否先、営業拒否表示のある企業
- 提供価値:作業時間削減、問い合わせ増加、入力ミス削減など
- 検証可能性:選定理由を公式ページのURLで確認できるか
「自動化コンサルを販売する」だけでは判定条件になりません。
「複数店舗を運営し、採用ページで事務スタッフを募集している企業に対して、定型入力の削減を提案する」まで具体化します。
さらに、手作業による営業で一度も反応を得られていない提案は、すぐに自動化しないでください。自動化は、検証済みの営業活動を拡張する技術であり、売れない提案を売れる提案へ変える技術ではありません。
2. データ取得の可否を先に確認する
取得できる技術と、取得してよい権限は別問題です。
各サイトについて、次の項目を確認します。
- 利用規約
- APIや公式データ提供手段の有無
- robots.txt
- 著作権とデータベースに関する権利
- アクセス負荷
- ログインの必要性
- 営業利用に関する明示的な制限
- 個人情報や個人関連情報の有無
robots.txtは、クローラーに対する技術的な指示を示すものであり、それだけで取得や商用利用の法的許可を与えるものではありません。利用規約や取得対象の性質と合わせて判断します。
データソースの優先順位は次の通りです。
- 公式APIやオープンデータ
- 利用許諾を得たデータベース
- 自社が適法に取得した問い合わせ、名刺、イベントデータ
- 一般公開ページ
- ログインや回避操作を必要とするページ
5番目は、原則として自動取得対象から外します。CAPTCHA、アクセス制限、技術的防御を回避する設計も避けてください。
取得間隔を空け、同一ページの再取得を減らすキャッシュを設け、エラー率が上昇した場合は自動停止させます。
メールアドレスも、公開されているから無条件に営業利用できる情報とは限りません。ユーザー名やドメイン名から特定の個人を識別できる場合は、それ自体が個人情報に該当し得ます。個人情報に該当しない場合も、通常は個人関連情報に該当すると個人情報保護委員会は説明しています。
個人情報保護委員会「メールアドレスは個人関連情報に該当しますか」
3. 小さなスクレイパーを作り、取得根拠を残す
Pythonなら、HTTP取得にはrequests、HTML解析にはBeautifulSoup、JavaScriptで描画されるページにはPlaywrightなどを利用できます。
ただし、最初から大規模な並列取得は行いません。まず5〜20社程度で、取得精度、規約、負荷、データの有用性を確認します。
保存する項目の例は次の通りです。
{
"lead_id": "lead_20260723_0001",
"company_name": "サンプル株式会社",
"source_url": "https://example.jp/company/",
"source_type": "official_company_page",
"industry": "不動産管理",
"public_contact": "info@example.jp",
"contact_context": "corporate_contact_page",
"sales_rejection_found": false,
"evidence_text": "営業事務スタッフを募集しています",
"fetched_at": "2026-07-23T09:00:00+09:00",
"content_hash": "sha256:..."
}
source_url、evidence_text、fetched_atを残すと、取得元の事実とAIが推測した情報を区別できます。
content_hashも記録すれば、取得後にページ内容が変わったかを検知できます。証拠URLがないデータや、取得元を再確認できないデータは送信対象にせず、再確認キューへ移します。
4. データを正規化し、重複送信を防ぐ
同じ会社が「株式会社ABC」「(株)ABC」「ABC Inc.」として保存されることがあります。
法人番号、公式ドメイン、電話番号、住所などを組み合わせて、同一企業かどうかを判定します。
最低限、次の状態を管理してください。
new:新規取得review:人による確認が必要eligible:送信候補suppressed:拒否・除外contacted:送信済みreplied:返信ありconverted:商談または受注invalid:取得失敗・誤情報
メールアドレスだけを主キーにすると、同じ会社の別アドレスへ重複送信する恐れがあります。企業単位のIDと、担当者・窓口単位のIDを分けて管理します。
抑止リストは、CRM、メール配信ツール、スクレイピングDBで別々に持たせてはいけません。送信直前に全システムが参照する共通テーブルを用意します。
SELECT 1
FROM suppression_list
WHERE company_id = :company_id
OR email = :email
OR domain = :domain
LIMIT 1;
この照合結果が1件でも返った場合は、AIの判定にかかわらず送信を停止します。
5. AIとルールを併用してリードを採点する
AIには、企業情報とICPを渡し、適合理由を構造化データで返させます。
{
"fit_score": 78,
"evidence": [
{
"fact": "公式採用ページで営業事務を募集",
"source_url": "https://example.jp/recruit/"
},
{
"fact": "3拠点を運営",
"source_url": "https://example.jp/company/"
}
],
"uncertain": [
"現在の顧客管理方法は不明"
],
"recommended_angle": "拠点間の入力作業削減",
"send_decision": "review"
}
スコアの数字には、明示的な採点ルールを付けます。
| 評価項目 | 配点例 | 必要な証拠 |
|---|---|---|
| 対象業種との一致 | 30点 | 公式の事業紹介 |
| 課題の具体的な兆候 | 30点 | 採用、新拠点、業務案内 |
| 企業規模との一致 | 20点 | 会社概要、拠点一覧 |
| 直近の活動 | 20点 | 日付のあるニュース |
| 合計 | 100点 | 各項目の証拠URL |
たとえば、運用開始時は次のように扱います。
- 80点以上:品質ゲートへ進む
- 60〜79点:人による確認
- 59点以下:送信しない
- 証拠URLなし:点数に関係なく送信しない
- 営業拒否・配信停止履歴あり:点数に関係なく送信しない
AIの78点は、受注確率78%を意味しません。設定した採点基準に対する評価値にすぎません。
また、AIだけに送信可否を決めさせてはいけません。営業拒否表示、過去の配信停止、競合、既存顧客などは、決定的なルールで除外します。
6. AI営業メールを「事実限定」で生成する
AIへ自由作文を依頼すると、「急成長中と拝見しました」のような根拠のない文章が混ざります。
生成プロンプトには、次の制約を含めます。
- 証拠URLに記載された事実だけを使う
- 不明な課題を断定しない
- 観察事実と提案仮説を明確に分ける
- 1通につき提案は一つにする
- 誇大な成果や保証を記載しない
- 件名と本文を分けて返す
- 送信者情報と受信拒否方法を削除しない
- 禁止語や要配慮個人情報を使わない
- 参照した証拠IDを出力させる
本文は、観察した事実→仮説→小さな提案→返信しやすい質問の順に組み立てます。
採用ページで営業事務職を募集されている点を拝見しました。
複数拠点の顧客情報入力に手作業が残っている場合、入力と通知を連携できる可能性があります。現状、同じ情報を複数の台帳へ転記する工程はありますか。
この文章は、相手が公開していない課題を断定していません。「監視されている」と感じさせる過剰な個別化も抑えられます。
7. 送信前に機械的な品質ゲートを置く
送信前に、次の条件をすべて検査します。
- 会社名と公式ドメインが一致している
- 引用した事実ごとに証拠URLがある
- 証拠ページを現在も取得できる
- 営業拒否表示が見つかっていない
- 過去に配信停止を受けていない
- 既存顧客や商談中企業ではない
- 同一企業への送信間隔を満たしている
- 差出人名、事業者情報、受信拒否方法がある
- SPF、DKIM、DMARCなどの送信ドメイン認証を整えている
- テスト送信で文字化けやリンク切れがない
- AIが出力した固有名詞を元データと照合できる
判定ロジックは、次のように単純化できます。
def can_send(lead):
if lead.sales_rejection_found:
return False, "sales_rejection"
if lead.suppressed:
return False, "suppression_list"
if not lead.evidence_urls:
return False, "missing_evidence"
if lead.fit_score < 80:
return False, "score_below_threshold"
if not lead.identity_verified:
return False, "identity_mismatch"
return True, "eligible"
日本の特定電子メール法では、広告宣伝メールは原則として事前同意が必要です。団体や営業を営む個人がWeb上で公表しているメールアドレスには例外がありますが、アドレスと併せて受信拒否の意思が表示されている場合、その例外は適用されません。
同法では、送信者の名称、受信拒否を通知するためのメールアドレスまたはURL、送信者の住所などに関する表示義務も定められています。公開アドレスなら何を送ってもよい、という意味ではありません。
運用前に最新の法令・ガイドラインを確認し、判断が難しい場合は弁護士などの専門家へ相談してください。
8. 少量送信から始め、異常時には自動停止する
最初から大量送信すると、誤りの影響も一気に広がります。
送信件数は、利用するメールサービス、ドメインの運用履歴、受信者との関係、社内基準を踏まえて段階的に決めます。固定の「安全な送信件数」が存在するわけではありません。
停止条件の例は次の通りです。
- 配信停止依頼が社内基準を超えた
- バウンス、つまり宛先不明が急増した
- 苦情または法務確認が必要な返信を受けた
- 同じ文面が複数の企業向けに重複生成された
- 取得元URLを検証できない
- 会社名とドメインの不一致が発生した
- 送信サービスから警告を受けた
- 返信分類の信頼度が基準を下回った
停止条件には、計測期間と再開責任者も設定します。
stop_rules:
hard_bounce_rate:
window: 100_messages
threshold: 0.05
action: pause_campaign
complaint_detected:
window: immediate
threshold: 1
action: pause_and_notify_legal
evidence_check_failed:
window: immediate
threshold: 1
action: block_lead
resume_authority: sales_ops_manager
ここで示した数値は設定例であり、業界共通の安全基準ではありません。自社の送信実績、メールサービスの規約、法務判断に基づいて決定してください。
「止まらず動く」ことより、異常時に安全側へ停止できることのほうが、長期的な自動化資産には重要です。
9. 返信分類とCRM更新まで自動化する
返信は、AIで次のように分類できます。
- 興味あり
- 時期未定
- 担当者違い
- 不要
- 配信停止
- 自動返信
- 苦情・要確認
- 分類不能
「配信停止」は即時に共通抑止リストへ登録します。「苦情・要確認」と「分類不能」は、人へ通知します。
「興味あり」だけを営業担当へ渡し、日程候補、選定理由、証拠URL、生成メール、過去の接触履歴をCRMに表示します。
AIの分類結果には、ラベルだけでなく信頼度と判断根拠を残します。
{
"reply_category": "interested",
"confidence": 0.91,
"reason": "具体的な打ち合わせ希望日時が記載されている",
"requires_human_review": false
}
一方、否定表現や皮肉を誤分類する可能性があるため、信頼度が基準未満の返信を自動処理してはいけません。
この状態になると、担当者は検索、転記、定型メール作成から離れ、商談と提案へ時間を使えます。夜間や休日にもデータ整理は進みますが、返信速度より、相手の営業時間と迷惑にならない配信時刻を優先します。
専門家目線のチェックポイント
送信件数より証拠密度を見る
個別化された文章が長くても、根拠が一つしかなければ品質が高いとは限りません。
「なぜこの企業を選んだのか」「その事実はどのページにあったのか」を、第三者がURLから再現できるか確認します。
おすすめは、リードごとに次の3項目を記録することです。
- 選定に使用した事実数
- 再確認できた証拠URL数
- 証拠のない推測数
証拠のない推測が1件でも本文に使われた場合は、送信を停止します。
AIスコアを正解として扱わない
AIのスコアは確率ではなく、設定した採点基準による評価値です。
受注データがたまるまでは、スコア帯別に次の数字を比較します。
- 到達率
- 肯定返信率
- 商談化率
- 受注率
- 配信停止率
- 苦情件数
- 1商談当たり原価
高スコア帯の成果が低スコア帯と変わらない場合、採点基準または取得データに問題があります。
収益と工数を同じ表で見る
月間売上だけでは、採算を判断できません。
次の費用を含めます。
- データ取得費
- AI API費
- メール配信費
- サーバー・監視費
- 保守時間
- 例外確認時間
- 商談対応時間
- 法務・セキュリティ確認費
自動化によって生まれた粗利と、削減できた作業時間の両方を記録してください。
データを無期限に保存しない
利用目的、保存期間、削除方法、アクセス権限、バックアップからの削除方針を決めます。
個人情報保護委員会のガイドラインでは、利用目的の特定、不適正利用の禁止、適正取得、安全管理措置などが示されています。
個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」
画像で説明すべき箇所と視覚的証拠
記事に実画面を追加するなら、最も有効なのは同一リードIDを使った横長の証跡図です。
- 左:取得元ページ、取得日時、証拠文
- 中央左:正規化後の企業レコード
- 中央:AIスコア、採点内訳、未確認事項
- 中央右:生成されたメールのプレビュー
- 右:送信結果、返信分類、CRM登録結果
APIキー、個人名、実際のメールアドレスはマスキングします。
各画面に同じリードIDと処理時刻を表示すると、別々に作ったデモ画面ではなく、一連の処理が動いた証拠になります。
さらに、成功例だけでなく、次のような停止例も1件掲載すると信頼性が高まります。
lead_id: lead_20260723_0042
fit_score: 86
evidence_check: passed
sales_rejection_found: true
send_decision: blocked
block_reason: recipient_declines_promotional_email
スコアが高くても拒否表示を優先して停止した記録は、安全装置が実際に働いていることを示す視覚的証拠になります。
よくある失敗と対策
取得件数を成果として報告する
原因: スクレイピングの成功と営業成果を混同している。
対策: 取得数、適格数、送信数、到達数、返信数、商談数、受注粗利を分けて記録する。
問い合わせフォームへ自動投稿する
原因: メールアドレスがない企業にも送信できると考える。
対策: 規約、フォームの用途、営業拒否表示を確認する。自動投稿を禁止しているサイトや、顧客サポート専用フォームは対象外にする。
AIが架空の称賛を書く
原因: Web本文を渡さず、会社名だけで文章を生成している。
対策: 証拠文とURLを入力し、根拠のない記述が1件でもあれば送信を止める。
配信停止先へ再送する
原因: CRM、メール配信ツール、スクレイピングDBで抑止リストが分断されている。
対策: 全システムが参照する共通抑止テーブルを作り、送信直前にも照合する。
AIの点数だけで送信する
原因: 適合度と送信可否を同じ判断として扱っている。
対策: 適合度はAIで評価し、拒否表示、配信停止、既存顧客などは決定的なルールで除外する。
売れない仕組みを自動化する
原因: 手作業で一度も受注できていない提案を大量配信する。
対策: 少数の手動検証で課題と提案の一致を確かめ、その後に反復部分を自動化する。
成果を測るKPI
| KPI | 計算方法 | 判断できること |
|---|---|---|
| 取得成功率 | 正常取得件数÷対象URL数 | スクレイパーの安定性 |
| 証拠充足率 | 証拠URLのある候補数÷全候補数 | 選定根拠の品質 |
| 適格リード率 | 送信候補数÷取得企業数 | データソースとICPの相性 |
| 到達率 | 到達数÷送信数 | 連絡先データと配信環境の品質 |
| バウンス率 | 不達数÷送信数 | 連絡先データの劣化 |
| 肯定返信率 | 興味あり返信数÷到達数 | 提案と個別化の妥当性 |
| 配信停止率 | 配信停止数÷到達数 | ターゲティングや頻度の問題 |
| 商談化率 | 商談数÷到達数 | リード獲得の事業価値 |
| 受注率 | 受注数÷商談数 | 商談後の提案力 |
| 1商談当たり原価 | 全運用費÷商談数 | 営業自動化の採算 |
| 自動処理率 | 人の修正なしで完了した件数÷全件数 | 正常系の自動化水準 |
| 例外解決時間 | 例外発生から解決までの時間 | 保守負担 |
| 誤送信件数 | 誤った相手・内容への送信数 | 品質ゲートの有効性 |
たとえば、月間運用費を3万円、商談数を6件と仮定すると、1商談当たり原価は5,000円です。
これは説明用の仮定であり、実績値ではありません。受注粗利がこの原価と商談対応費を上回るか、自社の数字で判断します。
この方法が使えないケースと限界
次のケースでは、スクレイピングとAIメールの高度な自動化は適しません。
- 顧客候補が少なく、1社ごとの関係構築が受注を左右する
- 医療、採用、金融など、慎重な個人情報処理や表現審査が必要
- 取得元の規約が自動取得を禁止している
- 提案内容が企業ごとに大きく変わり、事前診断が必要
- クレーム発生時に対応できる責任者がいない
- 商品価値や成約パターンがまだ検証されていない
- 正しい送信先かを公開情報から判断できない
- 営業対象が個人中心で、プライバシー侵害の危険が高い
自動化は収益を保証しません。市場に需要がなければ、効率よく断られるだけです。
また、サイト構造、利用規約、法令、AIモデル、メール事業者のルールは変わります。正常系を無人化しても、定期監査と例外対応は残ります。
AIには、公開情報の読み違い、古い情報の採用、否定表現の誤認、返信意図の誤分類といった限界があります。重要な判断をAIだけで完結させず、誤りが発生する前提で停止条件と人による確認経路を設けてください。
読了後30分で実行するアクション
まず、販売したいサービスを一つ選び、次の列を持つ表を作ってください。
企業ID
企業名
公式URL
選定理由
根拠URL
根拠文
営業拒否表示
送信可否
送信不可理由
返信結果
商談結果
次に、候補企業を5社だけ手作業で調べます。5社という数字は、小規模な初期確認のための目安であり、成果を保証する件数ではありません。
各社について、次の質問に答えてください。
- この企業を選んだ理由を、公式URLで説明できるか
- 営業利用してよい連絡先か判断できるか
- 営業拒否の表示はないか
- 相手ごとに変える一文は何か
- 公開情報だけでは判断できない点は何か
- 誤送信した場合に、どの条件で止められるか
この5社を調べるだけでも、「自動取得できる情報」「人による判断が必要な情報」「そもそも取得すべきでない情報」が見えてきます。
いきなりコードを書くより、先に失敗条件を発見できます。
自分が働き続けなくても育つ営業資産へ
BtoBリード獲得の自動化は、企業情報を集めるだけでは完成しません。
必要なのは、適格判定、取得根拠、法令確認、メール生成、品質ゲート、段階送信、返信分類、CRM更新、収益計測までを一つの流れとして設計することです。
適切に構築したパイプラインは、新しい候補企業を継続的に発見し、商談可能性のある返信だけを担当者へ届けます。担当者の作業量ではなく、データ、ルール、プロンプト、抑止リスト、改善ログが成果を支える状態です。
これらは蓄積するほど再利用しやすくなり、担当者が常時張り付かなくても運用できる収益基盤に近づきます。
ただし、「完全自動化」を「監視不要」と解釈してはいけません。
拒否先へ送らない。根拠のない文章を出さない。異常時には停止する。停止後は、権限を持つ人が原因を確認してから再開する。
この安全装置があるからこそ、長期間運用できる営業資産になります。
本気で自動化・継続収益の仕組みを構築したい方へ
毎日リストを探し、文章を考え、同じ画面へ入力する働き方から抜け出したいなら、必要なのは断片的なツール情報ではありません。
必要なのは、情報取得、AI判定、自動配信、障害監視、収益計測までを一つにつなぐ実践手順です。
商品一覧ページでは、人が常時張り付かなくても動く仕組みを構築するための実践マニュアルを公開しています。
副業を単発作業で終わらせず、夜間もデータと導線が育つ自動化資産へ変えたい方は、次の一歩として確認してください。