パイプラインとライフサイクルステージの設計｜MQL→SQL→顧客の定義と自動化

パイプラインとライフサイクルステージの違いと関係性 — 2つの概念を混同せず、それぞれの役割と連動の仕組みを正しく理解できます。

「MQLの定義が曖昧で、マーケと営業の間で認識がずれている」「パイプラインのステージ定義が担当者によってバラバラ」——CRM運用で頻出するこれらの課題は、パイプラインとライフサイクルステージの設計が不十分であることに起因しています。

パイプラインは「商談の進捗」を管理する軸、ライフサイクルステージは「顧客との関係性の進捗」を管理する軸です。この2つを正しく設計し、自動化で連動させることで、マーケティングから営業、カスタマーサクセスまでの一気通貫のプロセス管理が実現します。

本記事では、パイプラインとライフサイクルステージの設計思想から、HubSpotでの具体的な実装パターンまでを解説します。

本記事は「CRMデータベース設計の基本｜オブジェクト・プロパティ・関連付けの設計思想」シリーズの一部です。

この記事でわかること

• パイプラインとライフサイクルステージの違いと関係性 — 2つの概念を混同せず、それぞれの役割と連動の仕組みを正しく理解できます
• MQL・SQLの定義方法と、マーケ・営業間の合意形成プロセス — スコアリングやBANT/MEDDICを使った具体的な判定基準の設計方法を解説します
• パイプラインステージの設計原則と具体的なステージ例 — 5-7ステージに収める原則から、BtoB SaaSの標準的なステージ構成まで紹介します
• ライフサイクルステージの設計原則とHubSpotでの実装方法 — HubSpotの標準ステージをベースに、自社に合わせたカスタマイズの考え方を解説します
• 自動化ワークフローによるステージ遷移の設計パターン — MQL→SQL遷移時の取引自動作成や、失注時のリサイクルフローなど実務で使える自動化設計を紹介します

CRM導入を検討中の方や、パイプライン設計を見直したい営業マネージャーの方に向けた内容です。

パイプラインとライフサイクルステージの違い

2つの概念を混同しない

この領域に関心がある方にはCRMデータベース設計の基本もおすすめです。

パイプラインとライフサイクルステージは、しばしば混同されます。この混同が運用の混乱を招く原因になるため、まず2つの概念の違いを明確にしておきましょう。

ライフサイクルステージ: コンタクト（個人）や会社と自社の関係性がどの段階にあるかを示します。Webサイトの訪問者→リード→MQL→SQL→商談中→顧客→プロモーターといった流れを管理します。マーケティングから営業、CSまでを横断する概念です。

パイプライン: 個別の商談（取引）がどのステージにあるかを示します。初回接触→ヒアリング→提案→交渉→受注/失注といった、商談固有の進捗を管理します。主に営業プロセスの管理に使います。

両者の関係: ライフサイクルステージが「コンタクトの旅の全体像」だとすれば、パイプラインはその旅の中の「商談フェーズの詳細地図」です。コンタクトのライフサイクルステージが「SQL」に遷移するとき、パイプラインに新しい取引が作成される、というのが一般的な連動パターンです。

ライフサイクルステージの設計

HubSpotの標準ライフサイクルステージ

具体的な実践方法は売上予測のCRM・AI設計で詳しく解説しています。

HubSpotには以下の標準ライフサイクルステージが用意されています。

• サブスクライバー（Subscriber）: メルマガ購読者など、メールアドレスのみが判明しているコンタクト
• リード（Lead）: フォーム送信や資料ダウンロードにより、基本情報が取得できたコンタクト
• MQL（Marketing Qualified Lead）: マーケティング基準で「営業に渡す価値がある」と判断されたリード
• SQL（Sales Qualified Lead）: 営業がコンタクトし、「商談化の価値がある」と判断されたリード
• 商談中（Opportunity）: 取引が作成され、商談が進行中の状態
• 顧客（Customer）: 取引が受注となり、契約関係にあるコンタクト
• エバンジェリスト（Evangelist）: 自社を積極的に推薦してくれるファン顧客

MQLの定義方法

MQLの定義は、マーケティングと営業の間で最も摩擦が生じやすいポイントです。以下のアプローチで定義します。

定量基準（スコアリング）: コンタクトの行動にポイントを付与し、閾値を超えたらMQLとする。

• Webサイトの料金ページ閲覧: +10点
• 導入事例のダウンロード: +15点
• セミナー参加: +20点
• 問い合わせフォーム送信: +30点
• 閾値: 50点以上でMQL

定性基準（フィット）: 企業属性がターゲットICP（Ideal Customer Profile）に合致するかを評価する。

• 業種: SaaS/IT企業 → +20点
• 従業員数: 50-300名 → +15点
• 役職: 部長以上 → +10点

スコアリングの「行動スコア」と「フィットスコア」の組み合わせでMQLを定義することで、「行動は積極的だがターゲット外の企業」「ターゲットだがまだ興味が薄い企業」を区別できます。

SQLの定義方法

SQLは、営業がMQLをコンタクトした結果、「商談化する価値がある」と判断したリードです。

BANT基準: Budget（予算がある）、Authority（意思決定権がある）、Need（明確なニーズがある）、Timeline（導入時期が明確）の4項目のうち、少なくとも3項目が確認できたらSQLとします。

MEDDIC基準: より高度な判断基準として、Metrics（効果指標）、Economic Buyer（経済的意思決定者）、Decision Criteria（評価基準）、Decision Process（意思決定プロセス）、Identify Pain（課題の特定）、Champion（社内推進者）の6項目を確認します。

Sansanのような企業では、名刺データとCRMを連携し、コンタクトの役職や部署情報を自動取得することで、SQLの判断に必要な情報を効率的に収集しています。

マーケ・営業間のSLA設計

MQL→SQLの定義だけでなく、「MQLが発生してから営業が対応するまでの時間」をSLA（Service Level Agreement）として設計することが重要です。

• MQL発生から初回コンタクトまで: 24時間以内
• SQLの判定期限: 初回コンタクトから5営業日以内
• SQL不適格の場合のフィードバック: 理由をCRMに記録し、マーケに返却

このSLAを設計し、遵守状況をダッシュボードで可視化することで、マーケと営業の連携精度が大幅に向上します。

パイプラインの設計

パイプラインステージ設計の5原則

原則1：ステージは5-7個に収める

多すぎると管理が煩雑になり、少なすぎると商談の進捗が見えなくなります。5-7個が運用しやすい範囲です。

原則2：各ステージに客観的な完了条件を設定する

「提案中」「検討中」のような主観的な名称ではなく、「何が完了したらこのステージに入るのか」を明確にします。

原則3：ステージは「営業のアクション」ではなく「顧客の状態」で定義する

「提案書を送った」（営業のアクション）ではなく「提案内容を顧客が評価している」（顧客の状態）で定義します。これにより、顧客視点でのパイプライン管理が可能になります。

原則4：受注確率を各ステージに設定する

過去の実績データに基づいて、各ステージの受注確率を設定します。これにより、パイプラインの加重金額（Weighted Pipeline）を算出でき、売上予測の精度が向上します。

原則5：失注理由を構造化する

失注ステージに「失注理由」のドロップダウンプロパティを設定し、構造化して記録します。「予算不足」「競合に負けた」「ニーズが消滅した」「意思決定の延期」などの理由を分析することで、営業プロセスの改善に活用できます。

具体的なパイプラインステージ例

BtoB SaaS企業を想定した標準的なパイプラインステージ例を紹介します。

ステージ1：アポイント確定（受注確率10%）

• 完了条件: 初回商談の日程が確定している
• 必須プロパティ: 顧客の会社名、担当者名、商談の目的

ステージ2：ヒアリング完了（受注確率20%）

• 完了条件: 顧客の現状課題、期待する成果、導入時期を確認済み
• 必須プロパティ: 課題の内容、期待ROI、想定導入時期

ステージ3：提案・デモ実施（受注確率40%）

• 完了条件: 提案書またはデモを実施し、意思決定者がレビュー済み
• 必須プロパティ: 提案金額、意思決定者の氏名、競合情報

ステージ4：見積・条件交渉（受注確率60%）

• 完了条件: 正式な見積書を提出し、契約条件の協議に入っている
• 必須プロパティ: 最終見積金額、契約予定日

ステージ5：最終承認待ち（受注確率80%）

• 完了条件: 顧客側の社内承認プロセスに入っている
• 必須プロパティ: 承認予定日、契約形態

ステージ6：受注（受注確率100%）

• 完了条件: 契約締結

ステージ7：失注（受注確率0%）

• 完了条件: 商談の終了が確定
• 必須プロパティ: 失注理由、失注の主要因

複数パイプラインの運用

事業が複数ある場合や、新規と既存で商談プロセスが異なる場合は、複数のパイプラインを運用します。

新規商談パイプライン: 新規顧客の獲得プロセス。上記の7ステージ構成。

アップセル・クロスセルパイプライン: 既存顧客への追加提案。ヒアリングのステージが簡略化され、「活用状況の確認→追加提案→受注」の3-4ステージ構成になることが多い。

パートナー経由パイプライン: 販売パートナーを通じた商談。パートナーとの情報共有ステージが追加される。

自動化による連動設計

ライフサイクルステージとパイプラインの自動連動

HubSpotのワークフロー機能を使って、ライフサイクルステージとパイプラインを自動連動させます。

パターン1：MQL→SQL遷移時に取引を自動作成

リードスコアが閾値を超えてMQLになり、営業がコンタクトしてSQLに遷移したタイミングで、取引（Deal）を自動作成します。取引にはコンタクト情報と会社情報が自動で関連付けられます。

パターン2：取引の受注時にライフサイクルステージを「顧客」に自動変更

取引のステージが「受注」に変更されたとき、関連するコンタクトと会社のライフサイクルステージを自動的に「顧客」に変更します。

パターン3：失注時のリサイクルフロー

取引が失注になった場合、失注理由に応じてコンタクトをナーチャリングリストに戻すか、一定期間後に再アプローチのタスクを自動作成します。

通知とタスクの自動化

• MQLが発生したら、担当営業にSlack通知＋HubSpotタスクを自動作成
• SQLの判定期限（5営業日）を過ぎたら、営業マネージャーにエスカレーション通知
• パイプラインのステージが一定期間（例：14日）停滞したら、アラートを自動送信
• 取引の受注時に、CSチームにオンボーディングタスクを自動作成

設計時の注意点

ステージの「後戻り」をどう扱うか

現実の商談では、ステージが逆戻りすることがあります。提案まで進んだが、顧客の予算が凍結されて検討が止まる、といったケースです。

HubSpotでは取引のステージを前後自由に変更できますが、後戻りのルールを事前に定義しておくことが重要です。「どの条件で後戻りするか」「後戻りした場合のアクションは何か」を明確にし、パイプライン分析の精度を維持しましょう。

「コンバージョン率」の正しい測定

パイプラインの各ステージ間のコンバージョン率を測定する際は、「期間」を統一して比較することが重要です。月次でのステージ遷移率を追うことで、「どのステージにボトルネックがあるか」を正確に特定できます。

CRMで実現するパイプラインとライフサイクルステージの設計

パイプラインとライフサイクルステージの設計を実務に落とし込むには、CRMツールの活用が不可欠です。詳しくは「CRM導入の進め方完全ガイド｜準備・ツール選定・データ移行・定着化の全ステップ」で解説しています。

このテーマに関連する記事はCRM基礎・導入カテゴリで網羅的にまとめています。

あわせて読みたい

• Excel顧客管理の限界と脱却ロードマップ｜CRM移行で失敗しないデータ整理術
• SFAの選び方と主要ツール比較｜営業現場が本当に使えるSFAの見極め方
• CRM料金の相場と費用対効果｜主要6ツールの価格体系を徹底比較【2026年版】

まとめ

パイプラインとライフサイクルステージは、CRM運用の背骨です。ライフサイクルステージで「顧客との関係性の全体像」を管理し、パイプラインで「商談の進捗の詳細」を管理します。

本記事のポイントを整理します。

• パイプラインとライフサイクルステージは別概念：ライフサイクルステージはコンタクト全体の旅を管理し、パイプラインは商談の詳細を管理する
• MQL・SQLの定義はマーケと営業で合意形成し、スコアリングとフィット基準を組み合わせて判断する
• パイプラインステージは5〜7個に絞り、各ステージに客観的な完了条件と受注確率を設定する
• ワークフローによる自動連動でSQL判定・取引作成・ライフサイクル更新を自動化し、運用負荷を最小化する

まず取り組むべきアクション: MQL・SQLの定義をマーケ・営業チームで文書化し、HubSpotのリードスコアリングとワークフローに実装してください。CRM導入やパイプライン設計について不明点があれば、HubSpotゴールドパートナーのStartLinkにご相談ください。

よくある質問（FAQ）

Q. MQLの定義は一度決めたら変えないほうがよいですか？

いいえ、定期的に見直すべきです。MQLの定義は仮説であり、運用データに基づいて継続的に調整する必要があります。「MQLからSQLへの遷移率」を定期的にモニタリングし、遷移率が低すぎればMQLの基準を厳しくし、高すぎれば緩和します。四半期ごとの見直しを推奨します。

Q. パイプラインステージの受注確率はどうやって設定すればよいですか？

過去6-12ヶ月の商談データから、各ステージからの受注率を算出するのが最も正確です。データが不十分な場合は、業界の一般的な数値（アポイント10%、ヒアリング完了20%、提案40%、交渉60%、承認待ち80%）を出発点として設定し、データが蓄積されるに従って調整します。

Q. ライフサイクルステージの「後戻り」は許容すべきですか？

HubSpotの設計上、ライフサイクルステージは基本的に前進方向のみの遷移が推奨されています。「顧客」から「リード」に戻すような操作は、データの一貫性を損ないます。既存顧客に再度アプローチする場合は、ライフサイクルステージは「顧客」のまま、新しい取引をパイプラインに作成するのが正しいアプローチです。

Q. 小規模なチーム（営業3名以下）でもパイプライン設計は必要ですか？

必要です。むしろ、小規模なうちにパイプラインを正しく設計しておくことで、チーム拡大時にスムーズにスケールできます。3名以下であればステージを4-5個に絞ったシンプルな構成で十分ですが、「各ステージの完了条件」と「必須プロパティ」は最初から明確にしておくべきです。