「ライフサイクルステージを設定したが、リードとMQLの違いを誰も説明できない」「パイプラインのステージが形骸化していて、正確な予測が立てられない」「マーケと営業で"商談化"の定義がずれていて、いつもMTGで揉める」
CRM導入支援の現場で、パイプラインとライフサイクルステージの設計に関する相談は極めて多く寄せられます。そして、これらの課題に共通する根本原因は、「なぜこのステージ構成にするのか」という設計哲学が曖昧なまま運用を始めてしまっているという点にあります。
パイプラインとライフサイクルステージは、CRMにおける「顧客の旅路」を可視化する仕組みです。前者は商談プロセスのステップを管理し、後者はコンタクトが認知から顧客化に至るまでの段階を示すフラグとして機能します。この2つの設計が的確であれば、マーケティングから営業、カスタマーサクセスまでのプロセスが一気通貫で可視化され、チーム間の連携が円滑になります。
本記事では、CRM導入支援の現場で培った知見をもとに、パイプラインとライフサイクルステージの設計哲学を解説します。MQL・SQLの定義方法、ステージ設計の判断基準、自動化による運用効率化、そしてHubSpotでの具体的な実装パターンまで、CRM設計者・運用担当者がすぐに実践できる内容をお伝えします。なお、CRMデータベース設計の基本（オブジェクト・プロパティ・関連付け）についてはS-1の記事で解説していますので、あわせてご参照ください。
ライフサイクルステージとは、コンタクト（個人）や会社が、自社との関係においてどの段階にいるかを示すフラグです。マーケティングの認知段階から始まり、商談化を経て顧客になるまでの「旅路」を可視化するために使います。
このフラグは、コンタクトレコードに1つだけ設定されるプロパティです。つまり、1人のコンタクトは常に「リード」「MQL」「SQL」「顧客」などのいずれか1つのステージに属します。ライフサイクルステージを正しく設計・運用することで、以下のメリットが得られます。
パイプラインとは、商談（取引）の進行状況をステージごとに管理するかんばん方式の仕組みです。ライフサイクルステージがコンタクトの「全体的な段階」を表すのに対し、パイプラインは取引オブジェクトに紐づく「商談プロセスのステップ」を管理します。
HubSpotでは、取引をパイプラインのボード上でドラッグ＆ドロップしてステージを進めることができます。各ステージに確度（受注確率）を設定することで、加重パイプライン金額の算出やフォーキャスト（売上予測）にも活用できます。
この2つは混同されがちですが、明確な役割の違いがあります。
| 項目 | ライフサイクルステージ | パイプライン（取引ステージ） |
|---|---|---|
| 対象オブジェクト | コンタクト・会社 | 取引（Deal） |
| 管理する範囲 | 認知〜顧客化の全プロセス | 商談開始〜受注/失注 |
| 設計の責任部門 | マーケティング＋営業＋CS | 営業 |
| ステージ数の目安 | 5〜8程度 | 4〜7程度 |
| HubSpotの表示 | コンタクト/会社のプロパティ | 取引ボード（かんばん） |
重要なのは、ライフサイクルステージとパイプラインは「連動するが別の概念」であるという点です。コンタクトのライフサイクルステージが「SQL」になったタイミングで取引レコードが作成され、その取引がパイプライン上で進行していく――この一連の流れを設計段階で明確にしておくことが、スムーズな運用の前提条件になります。
ライフサイクルステージを設計する前に、まず「なぜステージを分けるのか」という根本的な問いに答える必要があります。
その答えは明快です。ステージを分けることで、各段階に最適なアクションを定義できるからです。リードには認知拡大のコンテンツを、MQLにはウェビナー招待を、SQLにはISや営業からの直接アプローチを、商談中には提案資料を——このように、ステージごとに「何をすべきか」が明確になることで、マーケティングと営業の連携が機能します。
逆に言えば、「ステージは分けたけれど、各ステージに対応するアクションが定義されていない」状態は、設計として不完全です。ステージの数だけでなく、各ステージで「誰が」「何を」するかまでセットで設計することが重要です。
CRM導入支援の現場で最もよく使われるBtoB企業向けのライフサイクルステージ構成を紹介します。
| ステージ | 定義 | 主な担当 | 代表的なアクション |
|---|---|---|---|
| リード（Lead） | フォーム送信やCVで接点が生まれたコンタクト | マーケティング | メルマガ配信、ナーチャリングメール |
| MQL | マーケティング活動を通じて温度感が上がったリード | マーケティング / IS | ウェビナー招待、個別フォローメール |
| SQL | 営業がアプローチすべきと判断されたリード | IS / 営業 | 架電、メールでの商談打診 |
| 商談（Opportunity） | ミーティングが設定され、案件化したコンタクト | 営業 | 提案、見積もり提出、クロージング |
| 顧客（Customer） | 受注して取引が成立したコンタクト | CS / アカウント管理 | オンボーディング、クロスセル提案 |
| 失注掘り起こし | 商談が不成立となり、再ナーチャリング対象のコンタクト | マーケティング / IS | 再ナーチャリングメール、イベント招待 |
| アプローチNG | 連絡不可、競合、対象外などの理由で除外 | ― | マーケ施策の対象外として除外 |
| 社内 | 自社の社員や関係者 | ― | マーケ施策の対象外として除外 |
ここで重要なのは、最後の2つ「アプローチNG」と「社内」は、本来の購買プロセスのステージではなく、ノイズを除外するためのステージであるという点です。CRMに入ってくるコンタクトの中には、競合企業の担当者や自社社員など、マーケティング・営業の対象外となるレコードが一定数含まれます。これらを明確にステージとして定義しておくことで、マーケティングのKPI計測やレポートの精度が向上します。
BtoCビジネスの場合、MQLやSQLという概念はそのまま適用しにくい場合があります。BtoCでは一般的に、ステージ構成がシンプルになります。
ただし、BtoCでも高額商材や長い検討期間がある商材（不動産、保険、教育など）では、BtoBに近いステージ設計が有効です。ステージ設計は業種や商材の性質によって変わりますが、「各ステージに対応するアクションを定義する」という考え方は、BtoBでもBtoCでも共通です。
MQL（Marketing Qualified Lead）とは、マーケティング活動を通じて一定の関心度・適合度を示し、営業アプローチの候補となったリードのことです。「マーケティングが"この人は見込みがある"と判断したリード」と捉えるとわかりやすいでしょう。
MQLの定義が曖昧だと、以下の問題が発生します。
MQL定義の設計は、マーケと営業の協業の起点です。この定義を両チームで合意しておくことが、健全なファネル運用の前提条件になります。
MQLの判定基準は、大きく「行動（Behavior）」と「属性（Fit）」の2軸で設計します。
| 軸 | 評価内容 | 判定に使う情報の例 |
|---|---|---|
| 行動スコア | リードの「関心度」を測定 | ウェビナー参加、資料ダウンロード、料金ページ閲覧、メール開封回数 |
| 属性スコア | リードの「適合度」を測定 | 業種、従業員規模、役職、地域 |
行動スコアだけで判定すると、「関心は高いが自社のターゲットではないリード」までMQLに含まれてしまいます。逆に、属性スコアだけで判定すると、「ターゲット企業だが全く関心を示していない人」が対象になります。この2軸を組み合わせることで、「自社のターゲットに合致し、かつ関心度が高い」リードだけをMQLとして抽出できます。
実務では、以下のようなルールでMQL判定を行うケースが一般的です。
行動条件（いずれか1つ以上を満たす）：
属性条件（すべてを満たす）：
このような条件を社内で明文化し、マーケティングチームと営業チームの双方で合意しておくことが重要です。なお、条件は固定ではなく、運用データを分析しながら四半期ごとに見直すことを推奨します。
HubSpotでMQL判定を実装する方法は主に2つあります。
方法1：リードスコアリングを使う
HubSpotのリードスコアリング機能を使い、行動や属性に応じてポイントを付与します。合計スコアが閾値（例：50点）を超えたらMQLとする方法です。スコアリングの条件はHubSpotの設定画面で柔軟に定義でき、行動にはプラス点、ネガティブ行動（配信停止など）にはマイナス点を設定できます。
方法2：ワークフローの条件分岐を使う
特定のアクション（例：ウェビナー参加フォーム送信）をトリガーにワークフローを発火させ、属性条件をif/then分岐でチェックし、条件を満たした場合にライフサイクルステージを「MQL」に自動変更する方法です。スコアリングよりもシンプルで、初期段階の運用には適しています。
SQL（Sales Qualified Lead）とは、営業チームが「商談化の見込みが高い」と判断し、直接アプローチすべきと認定されたリードのことです。MQLが「マーケティング視点で見込みがある」という判定であるのに対し、SQLは「営業視点で商談に進む可能性がある」という判定です。
MQLからSQLへの移行は、多くの企業においてインサイドセールス（IS）が担います。ISがMQLに対して架電やメールでヒアリングを行い、以下のような基準で商談化の可能性を判断します。
SQL判定の基準として広く使われているのが、BANTフレームワークです。
| 要素 | 英語 | 確認内容 |
|---|---|---|
| B | Budget（予算） | 予算が確保されているか、または確保の見込みがあるか |
| A | Authority（決裁権） | 意思決定者、または意思決定に影響力のある担当者か |
| N | Need（ニーズ） | 自社のサービスで解決できる課題を持っているか |
| T | Timeline（時期） | 導入時期の目安があるか、検討中か |
BANTの4要素すべてを満たすことを要件とするか、一部（例：NとTの2つ）を満たせばSQLとするかは、企業の営業戦略や商材特性によって判断します。高単価の商材であれば4要素すべてを厳格にチェックし、低単価の商材であればNeedとTimelineの2つでSQLと判定する、といった調整が実務では行われます。
MQLからSQLへの移行は、通常以下のプロセスで行われます。
ここで重要なのは、ISが「SQL認定」の判断をCRM上で記録する運用ルールを明確に定めておくことです。口頭やチャットだけで引き渡しが行われると、データとして残らず、後からの分析やプロセス改善に活用できません。
パイプラインの設計においては、以下の3つの原則を押さえることが重要です。
原則1：顧客の購買プロセスに沿って設計する
パイプラインのステージは、自社の営業プロセスではなく、顧客の購買プロセスを反映させるのが理想です。「顧客がどのような意思決定ステップを踏むか」を起点に考え、そのステップに対応する形で取引ステージを設計します。
原則2：各ステージの「完了条件」を明確にする
「いつこのステージからに次のステージに進むのか」の基準が曖昧だと、営業担当者によってステージの進め方がバラバラになります。各ステージに明確な完了条件（Exit Criteria）を定義しておくことが不可欠です。
原則3：ステージ数は4〜7に収める
ステージが少なすぎると商談の進捗が見えず、多すぎると管理が煩雑になります。実務上は4〜7ステージが運用しやすい範囲です。
| ステージ | 定義 | 完了条件（次に進む基準） | 確度目安 |
|---|---|---|---|
| 見込み（Prospecting） | SQLから取引が作成された初期段階 | 初回ミーティングの日程が確定 | 10% |
| 商談中（Meeting / Discovery） | ミーティングでニーズのヒアリングを実施中 | 課題と要件が明確化し、提案の許可を取得 | 30% |
| 提案済み（Proposal） | 提案書または見積書を提出した段階 | 顧客からの提案内容に対するフィードバックを取得 | 50% |
| 内示（Verbal Agreement） | 口頭またはメールで受注の意向を確認した段階 | 正式な発注書または契約書の締結 | 80% |
| 受注（Closed Won） | 契約が成立し、取引が完了 | ― | 100% |
| 失注（Closed Lost） | 商談が不成立で終了 | ― | 0% |
上記は汎用的なパターンですが、商材の性質によって調整が必要です。長期の検討期間を要するエンタープライズ向け商材であれば「稟議中」「予算策定中」といったステージを追加する場合もあります。逆に、SMB向けの短期大量販売型であれば「見込み→デモ→受注/失注」の3ステージで十分なケースもあります。
パイプラインの設計は、企業の業種やビジネスモデルによって大きく異なります。以下に代表的なパターンを示します。
| ビジネスモデル | 特徴 | ステージ設計の方向性 |
|---|---|---|
| SaaS（サブスクリプション） | 無料トライアルやデモを経て契約、月額課金 | トライアル→デモ→提案→契約 のフロー。トライアルの利用状況もステージ判定に活用 |
| コンサルティング | 長い検討期間、提案が複数回、稟議が必要 | ヒアリング→課題定義→提案→稟議中→受注 の多段階設計 |
| EC / 物販（BtoB卸） | 短い商談期間、大量の取引を高速で処理 | 見積依頼→見積提出→受注 のシンプル設計。速度重視 |
| 製造業 | 仕様確認や見積精査が複雑、納品まで長い | 仕様確認→見積→検証→内示→受注 に加え、納品後ステージも設計 |
ここで鍵となるのは、「自社の営業プロセスの実態」と「理想のプロセス」のギャップを認識した上で設計することです。理想だけで設計すると現場が運用できず、現状のまま設計すると改善が起こりません。両者のバランスを取りながら、段階的に理想に近づけていく設計が現実的です。
HubSpotでは、Sales Hub Professional以上のプランで複数のパイプラインを作成できます。以下のようなケースでは、複数パイプラインの設計が有効です。
ただし、パイプラインを増やしすぎるとレポートの統合が難しくなるため、「本当にステージ構成が異なる場合のみパイプラインを分ける」という基準で判断することを推奨します。単にチームを分けたい場合は、パイプラインではなく取引のプロパティ（「担当チーム」など）で管理する方が適切です。
ライフサイクルステージやパイプラインの設計がどれほど優れていても、ステージの更新を人力に依存していては、データの正確性は維持できません。営業担当者が商談ステージの更新を忘れる、ISがMQL→SQL変更を後回しにする——こうしたことは日常的に発生します。
ステージ遷移の自動化は、「人が判断すべきところ」と「システムが自動で処理すべきところ」を切り分け、後者をワークフローで実装することで実現します。
ステージ遷移のすべてを自動化する必要はありません。以下の基準で「自動化すべきもの」と「人が判断すべきもの」を切り分けます。
| 遷移パターン | 自動化の推奨度 | 理由 |
|---|---|---|
| 新規コンタクト → リード | 自動化推奨 | フォーム送信やインポートをトリガーに自動設定可能 |
| リード → MQL | 自動化推奨 | スコアリングやトリガー条件で判定可能 |
| MQL → SQL | 半自動（人の判断＋記録を自動化） | ISのヒアリング結果に基づく判断が必要。プロパティ変更をトリガーに自動化 |
| SQL → 商談 | 自動化推奨 | 取引レコード作成をトリガーに自動変更可能 |
| 商談 → 顧客 | 自動化推奨 | 取引ステージが「受注」になったことをトリガーに自動変更 |
| 商談 → 失注掘り起こし | 自動化推奨 | 取引ステージが「失注」になったことをトリガーに自動変更 |
HubSpotのワークフロー機能を使った、代表的な自動化パターンを紹介します。
パターン1：フォーム送信 → リード設定
ワークフローのトリガーを「フォーム送信」に設定し、アクションとして「ライフサイクルステージをリードに設定」を実行します。これにより、Webサイトからコンバージョンしたすべてのコンタクトが自動的にリードとして登録されます。再登録設定を有効にしておくことで、同じコンタクトが別のフォームを送信した際にもワークフローが再度発火するように設定できます。
パターン2：スコア到達 → MQL設定
トリガーを「HubSpotスコアが50以上になった時」に設定し、条件分岐で属性条件（従業員規模、業種など）をチェックします。条件を満たした場合にライフサイクルステージを「MQL」に変更し、同時に担当ISに通知メールを送信します。
パターン3：取引作成 → 商談ステージ設定
トリガーを「取引が作成された時」に設定し、アクションとして関連コンタクトのライフサイクルステージを「商談（Opportunity）」に自動変更します。これにより、取引レコードの作成とライフサイクルステージの更新が連動します。
パターン4：受注 → 顧客設定 → CS通知
トリガーを「取引ステージが受注（Closed Won）に変更された時」に設定します。アクションとして、関連コンタクトのライフサイクルステージを「顧客」に変更し、CSチームにオンボーディング開始の通知を送信します。必要に応じて、チケット（オンボーディングタスク）を自動作成する処理も組み込めます。
ワークフローによるステージ自動化を設計する際には、以下の点に注意が必要です。
商談が失注に終わった場合、そのコンタクトへのアプローチを完全にやめてしまう企業は少なくありません。しかし、失注した商談の相手は、一度は自社サービスに興味を持ち、商談まで進んだ「最も見込みの高い潜在顧客」です。
失注の理由が「時期が合わなかった」「予算が確保できなかった」「競合と比較した結果」であれば、状況が変わった時点で再度商談化する可能性は十分にあります。だからこそ、失注後のナーチャリング（再育成）フェーズをライフサイクルステージの設計に組み込んでおくことが重要です。
失注掘り起こしフェーズは、以下の流れで設計します。
| 失注理由 | 想定される再アプローチのタイミング | 効果的なコンテンツ例 |
|---|---|---|
| 予算不足 | 次年度予算策定期（四半期末 / 年度末前） | ROI事例、コスト削減効果のレポート |
| 時期尚早 | 失注から3〜6ヶ月後 | 業界トレンドレポート、新機能リリースの案内 |
| 競合選定 | 契約更新時期の1〜2ヶ月前 | 乗り換え事例、比較資料のアップデート版 |
| ニーズ不一致 | 新サービス・新機能のリリース時 | 新機能の紹介、ユースケースの拡充記事 |
このように、失注理由をデータとして蓄積しておくことで、適切なタイミングに適切なコンテンツでの再アプローチが可能になります。失注理由の記録は、営業プロセスの改善にも活用できるため、「失注理由を記録する運用ルール」は必ず設計に組み込むことを推奨します。
最も頻度の高い失敗パターンです。MQLの基準が「なんとなくホットっぽいリード」レベルにとどまっていると、マーケティングと営業の間で認識のズレが生じ、「マーケから渡されるリードの質が低い」「営業がフォローしてくれない」という不毛な対立が発生します。
対策：MQL・SQLの定義を文書化し、行動条件と属性条件を明確に定める。定義はマーケティングチームと営業チームの合同ミーティングで合意し、四半期ごとに見直す運用サイクルを設ける。
「細かく管理したい」という意図でライフサイクルステージを10以上に設定するケースがあります。しかし、ステージが多すぎると、各ステージの定義が曖昧になり、正確な分類が困難になります。さらに、営業担当者のステージ更新の負荷が上がり、結果としてデータの正確性が低下します。
対策：ライフサイクルステージは5〜8、パイプラインのステージは4〜7を目安に設計する。それ以上の粒度が必要な場合は、別のプロパティ（「サブステータス」など）で管理することを検討する。
パイプラインの最終ステージが「受注」と「失注」だけで、失注後のプロセスが設計されていないケースは非常に多いです。失注したリードが放置され、再アプローチのタイミングを逃してしまいます。
対策：ライフサイクルステージに「失注掘り起こし」を設け、失注理由の記録と再ナーチャリングのプロセスを設計する。ワークフローで失注→掘り起こしフェーズへの遷移を自動化する。
ライフサイクルステージは設定しているが、取引ステージの変更と連動していないケースです。取引が受注になっても、コンタクトのライフサイクルステージが「SQL」のままになっているなど、データの不整合が発生します。
対策：取引ステージの変更をトリガーに、関連コンタクトのライフサイクルステージを自動更新するワークフローを設定する。特に「受注→顧客」「失注→失注掘り起こし」の遷移は必ず自動化する。
ステージ設計を一度決めたら、以後見直しを行わないケースです。ビジネスの変化に伴い、ステージ構成やMQL/SQLの定義は当然変わるべきものですが、設計の見直しがされないまま運用が形骸化していきます。
対策：四半期に一度、ステージ設計の見直しミーティングを設ける。見直しの際は、ステージ間のコンバージョン率、ステージ滞留時間、営業からのフィードバックをデータとして確認し、必要に応じてステージ定義や自動化ルールを調整する。
ライフサイクルステージの設計において見落とされがちなのが、チーム間の引き渡しにおけるSLA（サービスレベルアグリーメント）の設計です。SLAとは、ステージが変わった後に「誰が」「いつまでに」対応するかを取り決めたルールです。
| 遷移ポイント | 引き渡し元 | 引き渡し先 | SLA例 |
|---|---|---|---|
| リード → MQL | マーケティング | IS | MQL認定から24時間以内に初回コンタクト |
| MQL → SQL | IS | 営業 | SQL認定から48時間以内に商談アポ取得 |
| 受注 → 顧客 | 営業 | CS | 受注から3営業日以内にオンボーディング開始 |
SLAを設定することで、ステージ遷移後の対応速度が可視化され、ボトルネックの早期発見と改善が可能になります。HubSpotでは、SLAの遵守状況をダッシュボードで監視する仕組みも構築できます。
ステージ設計を運用に落とし込んだら、以下のKPIをダッシュボードで監視することを推奨します。
これらのKPIを定期的にモニタリングすることで、ステージ設計の有効性を検証し、継続的に改善するサイクルを回すことができます。
ここまで解説した設計内容をHubSpotで実装する際のチェックリストを整理します。
パイプラインとライフサイクルステージの設計は、CRM運用の根幹を成す要素です。この設計が的確であれば、マーケティングから営業、カスタマーサクセスまでの一連のプロセスが可視化され、チーム間の連携が円滑になります。
本記事で解説した設計のポイントを整理すると、以下の通りです。
ステージ設計は一度作って終わりではなく、運用データをもとに継続的に改善していくものです。まずは本記事で紹介した基本パターンをベースに設計を始め、四半期ごとの見直しサイクルの中で自社に最適な形に磨き上げていくことを推奨します。
A. HubSpotのデフォルトステージ（Subscriber、Lead、MQL、SQL、Opportunity、Customer、Evangelist、Other）は汎用的に作られており、そのまま使える部分も多いですが、ほとんどの企業ではカスタマイズが必要です。自社のビジネスプロセスに合わせて、不要なステージの削除や、必要なステージ（「失注掘り起こし」「アプローチNG」など）の追加を行うことを推奨します。デフォルトを出発点にしつつ、自社の設計哲学に基づいて調整するのが現実的なアプローチです。
A. MQLの基準を厳しくすれば、MQLの数は減ります。しかし、本質的に重要なのは「MQLの数」ではなく「MQLから商談化・受注に至る確率（コンバージョン率）」です。MQLの基準を適切に設定することで、営業チームが効率的にフォローできる質の高いリードが増え、結果としてROIが向上します。まずは少し厳しめの基準で運用を開始し、コンバージョン率と営業からのフィードバックを見ながら調整するのがよいでしょう。
A. 営業プロセスが全社で統一されている場合は、1つのパイプラインで十分です。複数パイプラインが必要になるのは、「新規営業とアップセルでステージ構成が大きく異なる」「商材カテゴリによって営業フローが根本的に違う」といったケースです。単に「チームを分けて管理したい」という理由であれば、取引のプロパティ（担当チーム、担当地域など）で分類する方が、レポートの統合性を維持できるため推奨されます。
A. ライフサイクルステージは基本的に「前進する」設計が推奨されますが、実務上は逆戻りが必要なケースもあります。例えば、顧客が契約を解約した場合や、商談が保留になり再ナーチャリングが必要な場合です。HubSpotではデフォルトでライフサイクルステージの後退が制限されていますが、ワークフローを使えば強制的に変更できます。重要なのは「どのケースで逆戻りを許可するか」を事前にルール化しておくことです。
A. 四半期に一度の定期見直しを推奨します。見直しの際には、ステージ間のコンバージョン率の変化、ステージ滞留時間の異常値、営業チームからのフィードバックを確認します。加えて、ビジネスの大きな変化（新商材の追加、組織変更、ターゲット市場の変更など）があった場合は、定期見直しを待たずに臨時で設計を再検討するべきです。