リード獲得広告のリードを取りこぼさない｜CRMとウェビナー登録を15分ごとに自動でつなぐ

リード獲得広告とは、広告の中に申込フォームを開き、ユーザーが広告から離れずに氏名やメールアドレスを送れる広告の形式です。Meta（Facebook・Instagram）では「インスタントフォーム」と呼ばれます。入力の手間が少ないぶん申込は集まりやすい一方、集まったリードはMetaの中に溜まります。誰かが取り出してCRMに入れ、案内を送らない限り、申込は申込のまま止まります。

当社（株式会社etika）は、2026年9月25日のオンラインセミナーの集客にこの広告を使いました。そして、集まったリードを約1週間、手つかずにしてしまいました。この記事では、その取りこぼしと、リードをCRMとウェビナー登録へ15分ごとに自動でつなぐ形に変えた構成を、つまずいた点も含めてお伝えします。

当社で何が起きたのですか？リードの取り込みが約1週間止まっていた

構成はこうでした。広告のフォームでセミナーに申し込んでもらい、完了画面のボタンからZoho Meeting（当社が使うウェビナーツール）の登録ページへ進んでもらう。あわせて、リードをZoho CRMの見込み客として取り込み、CRMから「参加登録のご案内」メールを自動で送る。取り込みのスクリプトは、広告の配信前に手で動かして、通しのテストまで済ませていました。

ところが、広告は予定より1週間早く配信が始まっていました。開始予定は9月15日でしたが、実際には9月8日の夕方から配信されていました。設定が変わった記録は残っておらず、気づいたのは9月11日です。取り込みのスクリプトは「配信が始まったら定期実行に切り替える」つもりで、まだ手動のままでした。

その結果、9月8日から14日まで、取り込みは一度も動きませんでした。この間に届いたリードは3件です。9月14日に定期実行へ切り替え、初回の実行で、残っていた新規の2件をCRMに登録し、案内メールが送られました。もう1件は、その時点でCRMに登録があり、ウェビナーにも自分で登録を済ませていました。

申込から案内まで、長い人で5日かかったことになります。リードへの初動は早いほど良いと言われますが（Speed to Leadの記事）、当社はその逆をやってしまいました。

なぜ取りこぼしたのですか？

技術の問題ではありませんでした。原因は3つです。

1. 取り込みが手動前提だった：「誰が、いつ動かすか」が決まっていなかった
2. 配信の開始を誰も見ていなかった：開始日が変わったことに3日気づかなかった
3. 止まっていることを知らせる仕組みがなかった：リードが溜まっても、どこにも警告が出なかった

広告は、申込が入った瞬間から成果になります。後ろの処理が人の手待ちだと、広告費は使われているのに、相手には何も届きません。

リードをCRMとウェビナー登録に自動でつなぐ構成

9月14日以降、次の形に変えました。

順	処理	担当
1	Metaのフォームに申込が入る	広告
2	15分ごとに、新しいリードをAPIで取り込む	定期実行のスクリプト
3	CRMに見込み客を作る。会社名・役職・フォームの回答と、広告名などの流入情報（UTM）も入れる	スクリプト（Zoho CRM API）
4	ウェビナーに参加登録する。視聴URL付きの確認メールはウェビナーツールから届く	スクリプト（Zoho Meeting API）
5	登録に失敗したリードがあれば、担当者のパソコンに通知を出す	スクリプト
6	通知が出たら、人が手で登録する	人

ウェビナーへの自動登録（4）は9月17日に加えました。それまでは、CRMから案内メールを送り、相手に登録ページへ進んでもらう形でした。自動登録に切り替えた時点で、CRMからの案内メールは止めています。お客様に届くのは、ウェビナーツールからの確認メール1通だけです。

ポイントは、人の出番を「失敗したときだけ」に絞ったことです。うまく流れているときは、誰も何もしません。リードの取得には、Metaのleads_retrievalという権限が要ります（Meta公式：リードの取得）。当社はこの権限を付けたトークンを発行し直してから、取り込みを始めました。

自動化でつまずいた4点

1. 定期実行が、手動では動くのに定期だと動かない

スクリプトはMacの定期実行の仕組み（launchd）で15分ごとに動かしています。最初はシェルスクリプトを挟んで起動していましたが、一度も動きませんでした。原因はmacOSのプライバシー保護で、定期実行から起動したシェルは、デスクトップ配下のフォルダを読めませんでした。手で実行すると問題なく動くため、気づきにくい不具合です。nodeを直接起動する形に変えて解決しました。詳しくはlaunchdの定期実行が動かない原因の記事に書いています。

2. ウェビナーのAPIで、組織IDを取り違えた

Zoho MeetingのAPIには、組織を表すIDを渡します。当社は最初、CRMで使っている組織IDをそのまま渡し、登録が「権限がない」というエラーで失敗しました。CRMとMeetingでは、組織IDが別物でした。しかも、ウェビナーの一覧を取るAPIは、間違ったIDでも正常に応答を返しました。一覧が取れたのでIDは合っている、と考えると詰まります。手順はCRMサポートセンターのZoho Meeting APIの記事にまとめています。

3. CRMに先に入った見込み客の項目が空のままだった

Zoho MeetingはCRMとつながっていて、ウェビナーに登録した人を、氏名とメールアドレスだけの見込み客としてCRMに作ります。スクリプトはそれを「既にいる人」と判断して作成を飛ばしていたため、会社名・役職・UTM・フォームの回答がCRMに入っていませんでした。9月18日に気づき、既存の見込み客は「空いている項目だけを埋める」処理を足しました。値がある項目は上書きしません。UTMが入らないと、広告から来た人だとCRMで追えなくなります。流入元を受注まで追う考え方はリードソースを受注まで引き継ぐ設計で書いています。

4. 申込フォームに「何で知ったか」の設問がなかった

ウェビナーの登録フォームに、流入経路を選ぶ設問（メール・広告・検索・紹介など）を入れる予定でした。8月の勉強会に続き、9月も入れないまま終わりました。広告からの登録はリードとの照合で数えられますが、それ以外の6件が、メールから来たのか検索から来たのかは分かりません。短い作業でも、配信開始の条件にしておかないと後回しになります。

結果：広告リード10件が全件つながり、5件が参加

9月25日のセミナー後に集計した結果です（Meta・Zoho MeetingのAPIで取得し、メールアドレスで照合）。

指標	件数
広告のリード（テストを除く）	10件
うちウェビナー登録とつながった件数	10件
うち当日参加	5件（参加率50%）
ウェビナーの承認済み登録（全経路）	16件
当日参加（全経路）	8件

広告費は40,957円で、参加1件あたり約8,200円でした。

ただし、登録と参加の数だけで広告を評価していません。集客の途中、リードが9件だった時点で確かめると、そのうち4件は、マーケティング支援などサービスを提供する側の会社で、決裁者は0件でした。つながる仕組みはできましたが、誰に届いているかは別の課題として残っています。セミナーの内容は開催レポートをご覧ください。

リード獲得広告のリードは、CRMにどう連携すればいいですか？

取り出し方は大きく3つあります。どれが正解というより、件数と、後ろでやりたい処理の多さで選びます。

方法	向いている場合	注意点
管理画面からダウンロードして手で取り込む	月に数件で、担当者が毎日広告を見ている	担当と時刻を決めないと、当社のように止まる
CRMや連携サービスの標準機能を使う	見込み客を作るだけで足りる	ウェビナー登録や流入情報の書き込みまで届かないことがある
APIで取り込むスクリプトを定期実行する	見込み客の作成・ウェビナー登録・流入情報の記録を一度に行いたい	定期実行の置き場所と、止まったときの通知を自分で用意する

当社が3つ目を選んだのは、CRMの見込み客を作るだけでなく、ウェビナー登録とUTMの記録まで一度に済ませたかったからです。スクリプトはAIエージェントと一緒に書き、テスト用のリードで「取り込み→見込み客作成→メール到着」まで通してから本番に切り替えました。テストで作った見込み客は、確認後にCRMから消しています。

同じ構成を自社で作るときの最小セット

いきなり全部を作る必要はありません。次の順で足していくのがおすすめです。

1. 取り込みの担当と頻度を決める：手動なら「毎朝9時に誰が」まで決める。自動なら15分〜1時間ごと
2. CRMに入れる項目を決める：氏名・会社名・メールに加え、広告名などの流入情報を必ず入れる
3. 案内を1通だけ送る：CRMからもウェビナーツールからも送ると二重になる。どちらか一方に決める
4. 止まったら知らせる：失敗や未処理があれば、人に通知が届くようにする
5. 申込フォームに流入経路の設問を置く：広告を出す前に入れる。配信開始の条件にする
6. 配信の開始・停止を記録する：予定と実際の開始日がずれていないかを、初日に確かめる

当社の構成は、Mac1台が起動していることが前提です。電源が切れている間のリードは、次の起動時に処理されます。止まると困る規模なら、クラウドの定期実行やCRMの標準連携を検討してください。広告や展示会から入った見込み客を、取りこぼさず商談・受注までつなぐ仕組みづくりは、受注プロセス管理のページで紹介しています。

よくある質問

リード獲得広告のリードはどこに溜まりますか？

Metaのリード獲得広告（インスタントフォーム）の回答は、Metaの側に保存されます。管理画面からのダウンロード、CRMとの連携機能、APIのいずれかで取り出す必要があります。取り出す人や仕組みが決まっていないと、申込があったことに誰も気づかないまま時間が過ぎます。

リード獲得広告とCRMはどう連携すればいいですか？

CRM側に標準の連携機能があれば、まずそれを試すのが手軽です。当社はウェビナー登録やUTMの記録まで一度に行いたかったため、APIで取り込むスクリプトを15分ごとに動かしています。どちらの場合も、取り込みが止まったときに人へ知らせる仕組みを入れておくことが大切です。

ウェビナーの申込を自動で登録するとき、二重登録は起きませんか？

当社が使っているZoho MeetingのAPIでは、同じメールアドレスで登録をやり直しても、二重には登録されませんでした（当社の実測）。ただし製品によって動きは違うため、テスト用の申込で一度確かめてから本番に切り替えてください。

広告経由の申込が何件だったかは、どう確かめればいいですか？

ウェビナーの登録フォームに「何で知りましたか」という選択式の設問を置くのが確実です。当社は2回続けてこの設問を入れ忘れ、広告以外の申込の経路が分からないままになりました。広告からの分はリードのメールアドレスと登録者を照合して数えています。