「眠れるリード」を起こす設計図 — 海外屋根工事の事例を、日本のSMBに翻訳する

参照している事例

2026年、米屋根工事業向けに「Project Phoenix」と名付けられた営業自動化システムが LinkedIn で公開された。発信者は、アウトリーチ自動化プラットフォーム OpenClaw に関わる Todd Anderson 氏。CRM に眠っていた約 4,000 件のリードに対し、嵐が発生した数時間後に AI 生成の SMS を自動配信して掘り起こすというシナリオで、$100K+ の追加売上を試算している。

出典: Todd Anderson 氏の LinkedIn 投稿。リンクはページ末尾。

パターンの本質: 「外部シグナル × 休眠リード × 個別配信」

ここから先は、Anderson 氏の投稿の再記述ではなく、CosmoSketch が DX 案件で同種のシステムを設計するときの観察を共有する。

Project Phoenix の設計が効くのは、3 つの要素が組み合わさるからだ。

• →外部トリガー: 業種特有の需要を喚起する、外部で確認可能なシグナル
• →休眠アセット: 過去に問い合わせ・見積依頼で接点を持ったが連絡が途絶えたCRMレコード
• →個別最適化された配信: テンプレ一斉送信ではなく、相手の状況に紐づいた個別文面

組み合わせの強みは、「いま欲しい」と一度言ってきた人に、「今思い出すべき理由」をピンポイントで届けることにある。CosmoSketch の DX 案件で観察してきた肌感では、SMB の CRM には アクティブリードの 3〜5 倍の死蔵レコードが存在する。掘り起こしの設計が標準化されていないだけで、原資はある。

$100K の数字を分解してみる

Anderson 氏の試算（4,000 件 × クローズ率 0.2% × 客単価 $12,000 ≒ $96,000）はきれいだが、現場運用の経験から見るといくつか割り引きが要る。

クローズ率 0.2% は楽観的な前提。リードの鮮度に強く依存する。直近 6 ヶ月の問い合わせと、5 年前の問い合わせは別物だ。実効リード数は半分前後とみるのが現実的。

「営業の手作業ゼロ」は誇張表現。AI が SMS を出した後、返信対応・現地調査の予約・見積もり作成は依然人手だ。アウトリーチの工数だけが消える。

それを織り込んでも、リード再活性化フレーム自体の費用対効果は本物だ。 「全件にばら撒く営業」と比較して、期待リターンが10〜30倍にスケールする。眠れるリードは資産であり、ばら撒きは負債、と整理した方が経営的には正しい。

日本のSMBに翻訳するとき、何を差し替えるか

「嵐」は米国南部・中西部の屋根工事文脈では強力な外部シグナルだが、日本ではそのままでは弱い。日本仕様に翻訳するときの差し替え候補を、CosmoSketch がよく提案する形でまとめる。

特に 台風通過後 は、屋根・外壁業界では明確に効く。気象庁の台風経路データは公開されており、自動取得・判定が可能だ。

日本実装で必ず詰まる、3 つのポイント

CosmoSketch の DX 案件で、この種のシステムを組むときに毎回議論になる詰まりポイントを共有する。

1. SMS / メール送信の「同意」

日本の特定電子メール法・電気通信事業法の枠組みでは、事前同意のない営業 SMS / メールは原則 NG。過去の問い合わせ時点で受信同意（オプトイン）を取得しているかがスタート地点になる。同意のない 4,000 件を一斉に送ると違法だ。

解決の方向性: 旧 CRM データを監査し、同意状態を 3 分類（取得済み／取得不明／オプトアウト済み）に整理。取得不明分には、まず「再オプトインを取り直す」用の軽い通知を別フローで走らせる。これは AI 自動化以前の整地仕事だ。

2. データ品質（5 年前の CRM は別の世界）

5 年前の CRM レコードには、引っ越し、廃業、改名、メールアドレス変更が混入する。配信前に名寄せ・現存確認のレイヤーが必須。経験則として、3 割は無効リードと見ておくのが現実的だ。

解決の方向性: 配信プロセスの前段に「自動疎通チェック（メール疎通確認 / SMS エラー検知）」を挟み、無効リードを早期に脱落させる。死蔵 CRM の品質改善は副産物として残るので、別の業務にも効く。

3. 反応の引き受けキャパシティ

AI が SMS を一斉に出した直後、返信が 10〜50 件単位で帰ってくる。それを受ける電話・メール・LINE 体制が整っていないと、せっかくの反応が腐る。送信能力 ≠ 対応能力。これは技術というより業務設計の問題だ。

解決の方向性: 配信は対応キャパシティに合わせて段階リリース。一度に 4,000 件は送らず、500 件 × 8 バッチで分割。最初のバッチの応答率と対応コストを実測してから次に進む。

CosmoSketch の標準シーケンス

同種の DX を設計するとき、私たちが基本としている順序を共有する。

1. CRM 監査 — 何件が現存し、何件が同意保有、何件が連絡可能か
2. トリガー定義 — 業種特性に合った外部シグナル候補を 3 つ挙げ、データ取得経路を確認
3. 小バッチ実証 — 500 件で配信、反応率と対応コストを実測
4. スケール判断 — 期待 ROI が対応コストを上回るなら全件展開、そうでなければトリガーやセグメントを再設計

LinkedIn の投稿は「最初から $100K」の絵を描いているが、現場での通常解は 「最初の 500 件で 2 件の受注、$24,000 を回収」から始まることの方が多い。そこで信頼関係を作って、精度を上げていく。最初に最大値を出すより、最初に「動くこと」を確認する方が、結果的に短い距離で大きな数字に届く。

小さく始めて、大きく育てる

「眠れるリード × 外部トリガー × 個別配信」のフレーム自体は、業界を問わず再利用できる骨格だ。屋根工事のように外部要因が露骨な業種では今すぐ動く。一方で、保険更新や車検のように内部時計 で動く業種でも、トリガーを差し替えるだけで同じ枠組みが乗る。

CosmoSketch では、こうした「枠組みの汎用性」と「実装の地味さ」の両方を尊重したい。派手な 自動化の話に乗りつつ、実際に動かすときには同意 / データ品質 / 対応キャパの3点を地道に整える。今回の事例も、私たちにとっては「何を翻訳すれば日本でも回せるか」のヒント集として読める良いケースだった。