ワークフローオートメーション：初日から実装すべき10のCRMオートメーション

著者: Calvin D. · 更新日: 2026年4月8日

12人のインサイドセールスチームが2週間でHubSpot CRMにこれら10のオートメーションを追加しました。オートメーション前、担当者は管理作業に1日平均45分かけていました：インバウンドリードの手動ルーティング、デモ後のフォローアップタスク作成、テリトリー変更後の案件オーナー更新、クローズ日のズレの記録。オートメーション後：1日23分。チーム全体で週22時間が実際の営業活動に解放されました。McKinseyの営業オートメーションに関する調査では、既存のテクノロジーで営業タスクの約30%を自動化でき、最も効果が高いのはリードルーティング、フォローアップのスケジューリング、Pipelineデータ品質管理であることが示されています。同じオートメーション機能がプラットフォームごとにいくらかかるかについては、CRMの真のTCOをご覧ください。

計算はシンプルです。問題は、ほとんどのチームが3つ（リード割り当て、案件作成、ウェルカムメール）を自動化して完了と思ってしまうことです。このガイドでは実際に効果のある10のオートメーションを説明します。

CRMオートメーションの考え方

すべてのCRMオートメーションには同じ3つの部分があります：

トリガー：オートメーションを開始するイベントまたは条件。新しいコンタクトが作成された。案件ステージが変わった。フィールド値が更新された。日付が到来した。

条件：オートメーションが発動するタイミングを絞るオプションのフィルター。「リードソース = インバウンドWebの場合のみ」「案件金額 > $5,000の場合のみ」「従業員数 > 50人の場合のみ」

アクション：何が起きるか。タスクを作成する。通知を送る。フィールドを更新する。シーケンスに登録する。担当者にルーティングする。

アクションについて心配する前にトリガーと条件を正しく設定してください。多くの壊れたオートメーションはアクションが間違っているからではありません。トリガーが広すぎる（すべてにタグが付く）か条件がルーズすぎる（間違ったレコードが影響を受ける）ために壊れています。

HubSpotでは、これらはWorkflows（オートメーション → Workflows）で構築します。SalesforceではFlow Builderで構築します。SalesforceのFlow Builderドキュメントは、レコードトリガー型オートメーションを構築するための決定版リファレンスです。Pipedriveでは「オートメーション」の下にあります。ロジックは同じですがUIは異なります。

---

オートメーション1：テリトリーまたはラウンドロビンによるリード割り当て

トリガー：リードステータス = 「新規」のコンタクトが作成された 条件：リードソースが空欄でない（ソースなしで手動作成されたコンタクトを除外） アクション：テリトリー（都道府県/地域フィールド）に基づいてコンタクトオーナーを割り当てるか、担当者リストをローテーションする

このオートメーションは手動リードルーティングのキューを排除します。これがなければ、誰か（通常はマネージャーかSDRリード）がリードキューを確認し、各リードを担当者に振り分けます。その人がボトルネックになります。しかも、振り分けの判断にばらつきが出ます。より完全なリードプロセスを構築するチームには、リードルーティングオートメーションガイドが、テリトリー、アカウントベース、ラウンドロビンの各モデルを含むルーティングロジック全体を解説しています。

HubSpotでの設定：ラウンドロビンには「レコードをオーナーにローテーション」ワークフローアクションを使用し、特定の地域に特定の担当者を割り当てるにはテリトリーフィールド値による分岐を追加します。

Salesforceでの設定：アサインメントルールを使用します（Setup下のリードアサインメントルール）。テリトリー/Industry/サイズ基準のルールエントリを特定の担当者またはキューを割り当て先として作成します。Salesforce Trailheadのリード管理モジュールが、アサインメントルールの設定全体を解説しています。

Pipedriveでの設定：オートメーション → 「案件が作成された」または「リードが追加された」によってトリガーされるワークフローを作成し、フィルター基準に基づいてオーナーを割り当てるアクションを設定します。

重要な条件：ソースが入力されているリードにのみこれを発動させてください。管理者またはインポートで作成されたコンタクトはルーティングが不要な場合があります。

---

オートメーション2：見込み顧客からの案件作成

トリガー：コンタクトのプロパティ「リードステータス」が「見込み顧客」（または相当するステージ名）に変わった 条件：このコンタクトにすでにオープン案件が関連付けられていない アクション：案件レコードを作成し、コンタクトと企業に関連付け、案件オーナー = コンタクトオーナーに設定し、Pipelineステージ = 最初のアクティブステージに設定する

このオートメーションは担当者が手動で案件を作成せずに、リードのワークフローをPipelineのワークフローに変換します。重複案件を防ぐ条件（「このコンタクトに関連付けられたオープン案件がない」）が重要です。これがないと、リードステータスが更新されるたびに重複案件が作成されます。

HubSpotでは、「レコードを作成」→ 案件のワークフローアクションを使用し、次に「レコードを関連付け」でコンタクトと企業をリンクします。案件名の数式は、コンタクトの企業名、または複数のフィールドの組み合わせから取得するように設定します。HubSpotのワークフローに関するドキュメントでは、レコード作成アクションの設定全体を順を追って解説しています。

Salesforceでは、これはリードがコンバートされたときにOpportunityを作成するFlowまたはプロセスで行います。

---

オートメーション3：ステージベースのタスク作成

トリガー：案件のPipelineステージが特定のステージに変わる 条件：不要（更新を除外したい場合は案件タイプ = 「新規ビジネス」） アクション：案件オーナーに特定の指示と期日を持つタスクを作成する

案件が「ディスカバリー完了」に入ったとき、次の担当者のアクションは明確であるべきです：フォローアップコールのアジェンダを送る、または技術レビューをスケジュールする。ステージベースのタスク作成は担当者が次に何をすべきかを覚える必要がないことを意味します。CRMが教えてくれます。このオートメーションが十分に機能するのは、Pipelineステージが担当者のアクティビティではなく購買マイルストーンを軸に構築されている場合だけです。ステージが曖昧なら、ステージ変更時に作成されるタスクも曖昧になります。

案件固有の内容に関わらず一貫した次のステップがあるステージの遷移ごとに1つのタスクワークフローを構築してください。すべてのステージにタスクを作成する必要はありません。案件固有の内容に関わらず次のステップが同じになるステージにだけ作成してください。

ステージごとのタスク例：

• ディスカバリー完了 → タスク：「ディスカバリーサマリーを送付してソリューションデモをスケジュール」（24時間以内）
• デモ完了 → タスク：「ユースケースドキュメントと価格の概要を含むフォローアップメールを送付」（48時間以内）
• 提案受諾 → タスク：「契約レビューコールをスケジュールして法務にMSAを送付」（72時間以内）

HubSpotでは：ワークフローアクション「タスクを作成」で案件オーナーに割り当て、相対的な期日を設定し、指示を含むタスクの説明を追加します。 Salesforceでは：Flowアクション「Create Task」で、ActivityDateを数式で設定します。

---

オートメーション4：期限切れ案件アラート

トリガー：案件の「最終活動日」が X 日以上前で、Pipelineステージがクローズウォンまたはクローズロストでない 条件：案件がアクティブなステージにある（クローズウォン/ロストを明示的に除外） アクション：案件オーナーに高優先度でタスクを作成する：「X日間活動なし、案件が停滞している可能性あり」

このオートメーションがなければ、停滞した案件はPipelineに静かに居座り予測を膨らませます。マネージャーは案件レビューで発見して担当者に手動で催促します。このオートメーションはPipelineの驚きになる前に問題を浮上させます。

閾値Xはサイクル期間に依存します。30日のSMBサイクルには5日間活動なしでフラグを立てます。90日のエンタープライズサイクルには14日間でフラグを立てます。

HubSpotでは：固定スケジュール（毎日）で実行される「案件ベース」のワークフローを使用し、最終活動日がX日より前であることでフィルターします。これはイベントトリガーではなく、日付範囲フィルターです。

Salesforceでは：毎日実行され、条件に合致するOpportunityを照会してタスクを作成するスケジュールFlowを構築します。

---

オートメーション5：デモ後のフォローアップリマインダー

トリガー：案件のPipelineステージが「デモ完了」（または相当するステージ）に変わる 条件：なし アクション：ステージ変更から24時間後の期日で案件オーナーにタスクを作成する：「デモ後フォローアップ：ユースケースカバレッジを要約し、次のステップを確認し、関連するケーススタディを送付する」

デモ後24時間以内のフォローアップはB2B営業で最も影響力の高いアクションの1つです。購買者はソリューションを見た24時間以内が最も関与度が高いです。Harvard Business Reviewの営業対応速度に関する研究では、購買者とのやり取りから1時間以内にフォローアップする担当者は、数時間待つ担当者と比べて、そのリードを有望と判断できる確率が7倍高いことがわかりました。その窓内でフォローアップする担当者はより高い確率でコンバートします。しかし手動のフォローアップリマインダーは忘れられます。

このオートメーションにより、タスクが作成されないままフォローされないデモはなくなります。シンプルで、的が絞られていて、ROIも直接的です。

---

オートメーション6：30日間コールドリードの再エンゲージメント

トリガー：コンタクトのプロパティ「リードステータス」= 「オープン」で「最終活動日」が30日以上前 条件：コンタクトがアクティブなシーケンスに登録されていない アクション：コンタクトを「再エンゲージメント」メールシーケンス（2週間で3〜4通のメール）に登録する

リードが複数のチャネルから流入している場合、このオートメーションを構築する前にマルチチャネルリードの重複排除ガイドを読むことをおすすめします。チャネルをまたいで重複コンタクトが存在すると、再エンゲージメントシーケンスが同じ人物に2回発動することがあります。

静かになったリードは必ずしも死んでいるわけではありません。単に優先順位が下がっただけのことがよくあります。軽い再エンゲージメントシーケンス（重いセールスピッチではなく、「まだXについて考えていますか？」というアプローチ）は、コールドなコンタクトの相当数を再活性化できます。

HubSpotでは：コンタクトベースのワークフローで登録トリガーを使用します。コンタクトが現在アクティブなシーケンスに登録されているかを確認する条件を追加してください。二重登録は避けたいです。

Salesforceでは：Flowを通じてCadence（Sales Engagement）への登録をトリガーし、先に現在のCadenceメンバーシップを確認します。

Pipedriveでは：オートメーションを使ってフォローアップ活動を作成し担当者にフラグを立て、シーケンス自体には連携したメールツールを使用します。

---

オートメーション7：SlackまたはTeamsへの新規案件通知

トリガー：新しい案件が作成され、Pipelineステージが最初のアクティブステージである 条件：案件金額が閾値以上（オプション、例えば$5k以上の案件のみ通知） アクション：案件の詳細（案件名、企業、金額、オーナー）を指定されたSlackチャンネルに送る

これは担当者のシステム全体への賛同を得るオートメーションです。担当者は自分の新規案件がSlackで発表されるのを好みます。マネージャーはPipelineが生きていることがわかり喜びます。そして小さなポジティブな強化ループが生まれます：新規案件 = チャンネルでのお祝い。

HubSpotでは：ワークフローでSlackインテグレーションを使用します。アクションは案件プロパティが結合された「Slackメッセージを送信」です。

Salesforceでは：Salesforce → Slackインテグレーション、またはSlackのWebhookを呼び出すFlowを使用します。

メッセージはシンプルに保ってください：「新規案件：[企業名] - [案件金額] - オーナー：[担当者名]」。誰もが無視する長文のテキストは避けてください。

---

オートメーション8：クローズ日変更アラート

トリガー：案件の「クローズ日」プロパティが更新された 条件：案件が以前は今月クローズする予定だったか、クローズ日が2回以上変更された（インクリメントする「クローズ日変更回数」フィールドが必要） アクション：案件オーナーのマネージャーにSlackまたはメールで通知：「[案件名]のクローズ日が変更されました、新しい日付：[日付]。オーナー：[担当者]。」

クローズ日のズレは予測問題の先行指標です。1回の変更は正常です。2回はパターンです。3回は今四半期中にクローズしない可能性があります。これはPipelineデータ品質管理カルチャーに直結します。オートメーションは兆候を捉えますが、マネージャーが実際に行動するかどうかを決めるのはカルチャーです。

「クローズ日変更回数」フィールドの構築には追加のオートメーションが1つ必要です：クローズ日が変わったとき、カスタムフィールドの「クローズ日変更回数」を1増やします。次にアラートオートメーションでそのカウンターが2を超えているかどうかを確認します。

HubSpotでは：ワークフローを2つ用意します。1つ目は、クローズ日の変更をトリガーにして、カスタムフィールド「クローズ日変更回数」に対して「数値プロパティを増やす」アクションを実行します。2つ目は、そのフィールドが2を超えたことをトリガーにして、「担当者のマネージャーに通知」を実行します。

これは営業マネージャーにとって最も価値の高いオートメーションの1つです。毎週すべての担当者を問い詰めなくても、組織的に先送りされている案件が浮かび上がります。

---

オートメーション9：失注タグ付けと失注理由必須化

トリガー：案件のPipelineステージが「クローズロスト」に変わる 条件：「失注理由」フィールドが空欄 アクション：担当者にタスクを送信：「案件がクローズロストになりました、このタスクをクローズする前に失注理由をドキュメントしてください。」フィールドが入力されるまでステージの前進をブロックする（HubSpotではステージ変更時の必須フィールド、Salesforceではバリデーションルールを使用）。

失注理由データは営業プロセス改善のための最も価値あるインプットの1つです。そして一貫して最も少ないキャプチャです。担当者は案件を失注としてクローズして次に進みます。誰も理由をドキュメント化しません。

このオートメーションは問題を完全には解決しませんが、適切なタイミングに摩擦を生み出します。担当者は失注としてマークするために案件レコードにいます。タスクはすぐに失注理由を要求して表示されます。ほとんどの担当者は記入するでしょう。

厳格に強制するバージョン：HubSpotでは、案件がクローズロストに移動する前に失注理由フィールドを必須にするようPipelineステージを設定します。Salesforceでは、Close Reasonフィールドが入力されていないOpportunityをクローズロストとして保存できないようにするバリデーションルールを使用します。

---

オートメーション10：カスタマーサクセスへのOnboardingハンドオフ

トリガー：案件のPipelineステージが「クローズウォン」に変わる 条件：案件タイプ = 「新規ビジネス」（更新や拡張はスキップ） アクション：新しいOnboardingレコード（またはCSプラットフォームのタスク）を作成し、テリトリーまたはアカウントサイズに基づいて適切なCSM担当者に割り当て、SlackでCSチャンネルに通知し、案件をCSオーナーで更新する

このオートメーションは営業とCS間のブリッジです。これがなければ、クローズされた案件はCRMの宙ぶらりんの状態で待機し、営業マネージャーがCSに「これが勝利した」と手動でメールします。これがあると、ハンドオフは自動的、即座、そしてドキュメント化されます。

これがうまく機能するためには：CSのテリトリーまたは割り当てルール（リードルーティングと同じロジック）、CSが新しいアカウントを受け取るためのSlackチャンネルまたはタスクベースのシステム、そして定義されたハンドオフレコード構造（Day 1にCSが必要な情報は何か？）が必要です。

HubSpotでは：クローズウォンをトリガーとするワークフローを作成し、オンボーディング用のチケットまたはカスタムオブジェクトレコードを作成して、CSオーナーのルックアップフィールドに割り当て、CSチームのチャンネルにSlack通知を送ります。

Salesforceでは：ケースまたはカスタムのOnboardingオブジェクトを作成し、主要なアカウントフィールドを入力して、CSキューに割り当てるFlowを使用します。

---

よくある失敗

広すぎるオートメーション。 リード割り当てオートメーションが作成されたすべてのコンタクト（新しいインバウンドリードだけでなく）に発動すると、アクティブな案件の途中で既存のコンタクトを再割り当て始めます。常に条件を追加して適切なレコードにスコープしてください。

通知の過負荷。 10のオートメーションがすべてSlackメッセージを送ると、担当者はSlackを読まなくなります。デジタルワークプレイスの生産性に関するDeloitte Insightsの調査では、通知疲れが営業チームのテクノロジー離れを招く主な原因の1つであることが示されています。数時間以内に人間の応答が必要なアクションに通知を予約してください。タスクは1日以内に応答が必要なものに向いています。メールは記録を残す必要があるものに向いています。

パイロット後に誰も無効にしなかったオートメーション。 パイロットチームで全体公開前に実行する場合、テストオートメーションを構築します。作成するすべてのオートメーションをドキュメント化してください。全体公開前に、オートメーションリストを監査して、テストだったものを無効化してください。放置されたオートメーションは予期しないタイミングで発動し、データ品質の問題を引き起こします。

トリガーを検証する前に複雑さを構築する。 フルデータベースでオンにする前に、1つのレコードで各オートメーションをテストしてください。HubSpotの登録履歴とSalesforceのデバッグログは、トリガーが正しく発動し、アクションが期待どおりに実行されたかを確認するのに役立ちます。

次のステップ

これらのオートメーションを構築した後、最初の30日間は毎週オートメーションログを監査してください。HubSpotのWorkflow登録履歴とSalesforceのデバッグログには、どのレコードがどのオートメーションをトリガーしたか、アクションが実行されたかどうかが表示されます。予期しない登録、間違ったレコードで発動したアクション、誰も確認しなかった通知を探しています。

30日後、条件を調整し、閾値を修正し、どのオートメーションが望んでいた行動の変化を生み出しているかを確認するのに十分なデータが得られます。

次の主要なステップはフルチームへの展開です。構成済みのCRMからチーム全体が実際に使うものへの移行方法についてはCRM展開と採用ガイドを参照してください。

関連記事

• 実際の販売方法に合ったPipelineステージ
• CRM展開：パイロットチーム、フルチーム、採用追跡
• CRMデータモデル設計：オブジェクト、フィールド、リレーションシップ
• Zapier vs n8n vs Make：どの自動化ミドルウェアがスタックに合うか
• CRMに入る前のマルチチャネルリードの重複排除
• Rework vs Salesforce：オートメーション機能の比較