ライフサイクルステージとは何か。HubSpotでの定義と、設計で先に決めること

ライフサイクルステージとは、ある人や会社が自社といまどういう関係にあるかを表す、1レコードにつき1つだけ持つ状態のことです。 HubSpotでは既定で8段階が用意され、前にしか進まない仕様になっています。案件の進み具合を表す取引ステージとは、数えているものが違います。

この記事で分かること。

• ライフサイクルステージと、取引ステージ・リードステータスの違い
• HubSpotの既定8段階が、それぞれ何を指しているか
• 前にしか進まない仕様の中身と、戻すときの正しい手順
• 設計で最初に決めるべきこと（段階の名前ではありません）

HubSpotとSalesforceの実装を担当してきた立場から、設計の判断基準として書きます。ツールの操作手順ではなく、どこで壊れるかを中心に置いています。

ライフサイクルステージは「関係」を、取引ステージは「案件」を数えている

3つの項目がよく混ざります。混ざる理由は、どれも「進んでいる感じ」を表すからです。数えている対象を並べると、別物だと分かります。

項目	何についた状態か	1件あたりの数	動かす人
ライフサイクルステージ	コンタクト、または会社	1つだけ	マーケティングと営業の両方
取引ステージ	取引（案件）	取引ごとに1つ	案件の担当営業
リードステータス	コンタクト	1つだけ	接触している担当者

決定的な違いは2行目です。1人の顧客が同時に3件の案件を持つことは普通にあります。 そのとき取引ステージは3つ並びますが、ライフサイクルステージは1つしかありません。

だから「この会社は今どこまで進んでいますか」という問いに、ライフサイクルステージは答えられません。

答えられるのは「この会社とうちは、どういう関係にあるか」だけです。

ここを一本の流れにまとめると、集計と自動化が同時に壊れます。実際にそうなった案件の話はライフサイクルステージと取引ステージの違い、混同した結果に書きました。

リードステータスは3つ目の軸で、「連絡がついたか、追跡中か、脈がないと判断したか」を表します。これは案件の進行でも関係の深さでもなく、接触の状況です。

営業が日々動かすのはここで、ライフサイクルステージではありません。

なお、HubSpotはコンタクトのリードステータスとは別に、「リード」を独立したオブジェクトとして扱う機能も提供しています。どちらで接触の状況を管理しているかで、表の3行目の置き場所が変わります。

ここはプランと設定によって違うので、自社のアカウントで確かめてください。

既定の8段階は、増やす前提ではなく減らす前提で見る

HubSpotの既定は次の8つです。日本語の表示名はアカウントの世代によって揺れるため、原語で並べます。

プランによっては段階の名前や数を編集できるようになっているので、既定から変えているかどうかも先に確認します。

1. Subscriber：メールを受け取ることに同意しただけの状態。まだ何も要求していない
2. Lead：何らかの形で連絡先を渡した状態。資料請求、問い合わせ、名刺交換
3. Marketing Qualified Lead（MQL）：マーケティング側が「営業が接触する価値がある」と判断した状態
4. Sales Qualified Lead（SQL）：営業側が接触して「追う価値がある」と確認した状態
5. Opportunity：具体的な案件として動き出した状態
6. Customer：契約した状態
7. Evangelist：他社に紹介してくれる状態
8. Other：上のどれでもない状態。取引先、パートナー、採用応募者など

実装の現場で最初に出る要望は、ほぼ必ず「段階を足したい」です。足す前に確認してほしいのは、その段階を動かす人が決まっているかどうかです。

動かす人が決まっていない段階は、名前がどれだけ精密でも埋まりません。半年後に見ると、全件がLeadのまま止まっています。

逆に、既定8段階のうち実際に使われるのは4つか5つであることが多い。Subscriber と Evangelist は、運用が回り始めるまで空のまま置いておいて構いません。

前にしか進まない仕様を知らないと、レポートの数字が説明できなくなる

ここがHubSpot特有の、そして日本語の解説であまり正面から書かれていない部分です。

HubSpotのドキュメントによれば、インポート、フォーム、API、Salesforce連携、そしてワークフローの「プロパティ値を設定」アクションは、既定のライフサイクルステージを前方向にしか設定できません。

後ろに戻したい場合は、まず既存の値をクリアし、そのうえで新しい値を設定する、という2段階が必要になります。

この仕様は、意図としては正しい。顧客になった相手が、古いフォームに再入力しただけでLeadに戻ってしまったら、レポートは毎週壊れます。

一方で、知らずに設計すると次の形で表面化します。案件が失注したのでライフサイクルステージをOpportunityからLeadに戻すワークフローを作る。テストでは動かない。原因が分からないので手動で戻す運用にする。手動なので抜ける。

数か月後、Opportunityの件数が実態よりずっと多くなっている（説明のための例です）。

Opportunityが膨らんでいるときに、最初に確認する設定があります。

HubSpotには、取引の作成や受注に合わせて、関連するコンタクトと会社のライフサイクルステージを自動で進める設定があります（取引パイプラインの設定にあります。名称と場所は時期とプランによって違います）。

これが有効だと、取引を作っただけでOpportunityに進み、失注しても戻りません。手動の運用を疑う前に、この設定の有無を見てください。

対処は2つです。1つは、戻す運用をやめること。失注は取引側で表現し、ライフサイクルステージは触らない。

もう1つは、どうしても戻す必要があるなら、クリアと設定の2アクションをワークフローに明示的に置くことです。

設計時の判断としては、前者を勧めます。戻す運用を入れた瞬間、「いつ戻したか」という履歴が必要になり、管理する項目が1つ増えるからです。

後者を選ぶ場合は、連鎖に注意してください。クリアして設定し直すと、「ライフサイクルステージが◯◯になった」を登録条件にしている別のワークフロー（MQLの通知、営業への割り当て、ナーチャリングの開始など）が、もう一度動く可能性があります。

通知や割り当てが二重に走り、各段階に到達した日付の項目やライフサイクル系のレポートの値も変わりえます。挙動は設定によって違うので、関連するワークフローの再登録の設定を確認したうえで、少数のテスト用レコードで一度流してから本番に入れます。

段階の定義が意味を持つのは、2部門が同じ数字を見ているときだけ

MQLとSQLの定義を精密にする作業には、時間をいくらでも使えます。ただ、定義を細かくすること自体が成果につながる場面は、思ったより少ない。

ソフトブレーンの「部門間連携に関する課題調査」（調査実施はIDEATECH、2024年10月4〜6日実施、2024年12月17日公表、営業n=159・マーケティングn=139の計298、営業支援を行う企業の自社調査です）では、連携が「満足にできていない」と答えたのが営業29.5%、マーケティング37.4%でした。

不満はマーケティング側のほうが約8ポイント高い。 営業からマーケへの不満は「リードの情報が不十分」42.1%、マーケから営業への不満は「フォローアップの改善を行っていない」47.5%です。

この構図でMQLの定義だけを精密にすると、何が起きるか。マーケティング側は基準を満たしたリードを渡し、営業側は渡された後の扱いを変えない。

MQLの件数だけが正確になり、その先は前と同じです。

だからライフサイクルステージの設計は、定義の議論より先に、MQLからSQLに進んだ件数を、両部門が同じ画面で毎週見る場を作れるかで決まります。場がないなら、段階を分けても数字が読まれません。

キーウォーカーの調査（2025年10月8〜10日実施、2025年11月11日公表、n=1,034、SFA・CRM・BIツールを導入済み企業の営業部門の担当者と管理職、PRIZMAによるインターネット調査。BIツールの導入支援を提供する事業者の自社調査です）では、管理職がダッシュボードを使う用途の1位は「営業会議の数値確認」58.2%で、「次のアクションの検討」は15.4%でした。

数字は会議で確認されていますが、そこから打ち手に変わる割合は低い。段階を増やしても、この比率は変わりません。

顧客になった後の段階は、解約率と直結している

ライフサイクルステージの議論は、たいていCustomerで終わります。実務上、その先のほうが金額は大きい。

HiCustomerの「カスタマーサクセス白書2023」（2023年4月18〜30日実施、有効回答n=203、カスタマーサクセスツールを提供する企業の自社調査です）では、営業からカスタマーサクセスへの引き継ぎが不十分な企業の63.3%が解約率2%以上で、引き継ぎが十分な企業の1.7倍でした。

NRRが100以上の企業の割合も、引き継ぎが十分な企業で60%と、不十分な企業の1.4倍です。

n=203と小さく、自己申告で、相関であって因果ではありません。解約率が低い企業ほど組織が成熟していて引き継ぎも整っている、という逆向きの説明も成り立ちます。

それでも、Customerに入った瞬間にレコードが「完了」扱いになる設計は避けたほうがいい、という判断材料にはなります。

具体的には、Customer に入った時点で何が起動するかを設計に入れます。担当の切り替え、初回のオンボーディング、90日後の確認。

段階を足すのではなく、段階の変化を引き金にする、という考え方です。

設計の順番は、段階の名前ではなく所有権から

まとめとして、実装で使っている順番を置きます。

1. どの段階を使うか決める前に、自社に実在する関係の種類を数える。 既定8つに合わせにいかない
2. 各段階について、誰がいつ進めるかを1行で書く。 書けない段階は、その時点では作らない
3. 進める手段を決める。 手動か、ワークフローか、フォーム送信か。混在させると、あとで原因が追えなくなる
4. 戻す運用を入れるかどうかを決める。 原則は入れない。入れるなら、クリアと設定の2アクションを明示し、他のワークフローへの連鎖を少数のレコードで確かめる
5. 最後に名前を決める。 ここは一番あとでよい

3番と4番を飛ばした設計を、これまで何度も引き継いできました。名前と定義だけが精密で、動かす人と手段が決まっていない。

この状態は、外から見ると「よく設計されたCRM」に見えます。中身が空だと分かるのは、最初のレポートを出す日です。

ライフサイクルステージの設計で先に決めるのは、段階の名前ではありません。各段階を誰がいつ進めるかです。所有者が決まっていない段階は、定義をどれだけ精密にしても埋まりません。

よくある質問

ライフサイクルステージと取引ステージ、どちらを先に設計しますか

取引ステージが先です。取引ステージは営業の実務そのものなので、現場に聞けば形が出てきます。

ライフサイクルステージは、その取引ステージとマーケティング側の活動を突き合わせて初めて決まります。順番を逆にすると、営業の実態に合わない段階ができます。

段階はいくつが適正ですか

数に正解はありません。判断の基準は、それぞれの段階に「動かす人」と「動かす条件」が1行で書けるかどうかです。書けるなら8つでも多すぎません。書けないなら4つでも多い。

MQLの定義は点数で決めるべきですか

点数（リードスコア）で決める方法は、受注実績と点数の相関を確認できている場合にだけ機能します。確認せずに導入すると、点数の高いリードが受注しない状態が続き、営業が点数を見なくなります。

行動（資料請求ではなく価格ページの閲覧、など）を条件にするほうが、立ち上がりは早い。

すでに運用しているライフサイクルステージを作り直せますか

作り直せますが、前にしか進まない仕様があるため、一括で戻すには既存の値をクリアする工程が必要です。インポートで一括して戻す場合も、上に書いたワークフローの連鎖は同じように起きます。

移行の間は、ライフサイクルステージを登録条件にしているワークフローを一時停止してください。移行前に、現在の値の分布を出してください。

全件がLeadに寄っている場合は、作り直しより先に、動かす人を決めるほうが効きます。

関連する記事

この記事は定義と設計の順番を扱いました。実際に混同したまま設計した案件で何が壊れたかは、ライフサイクルステージと取引ステージの違い、混同した結果に書いています。

段階を動かす人が決まらない問題は、CRMの推進担当に必要なのは、操作知識と運用を変える権限とも地続きです。

同じカテゴリの記事は「CRM・SFA」にまとめています。