HubSpot ライフサイクルステージ運用 — 定義設計から自動更新まで

本記事のポイント

• ライフサイクルステージが形骸化する原因は機能不足ではなく、標準 8 ステージの「名前の裏にある判定基準」を言語化していないことにあります
• HubSpot の自動更新は「前進のみ」が仕様です。この 1 点を前提に設計すれば、後戻りによるファネルレポートの崩壊は防げます
• 自社の営業プロセスを文章で渡すと、8 ステージの定義書と自動更新ルールを生成する AI 実行キットを配布します

「ライフサイクルステージ、一応 MQL とか SQL とか付けてはいるんですが、営業と定義が食い違っていて誰も数字を信じていません」。HubSpot 導入支援のなかで、ステージ運用の相談はこの一言から始まることがほとんどです。原因は担当者の怠慢でも HubSpot の機能不足でもありません。標準ステージの名前をそのまま使い、その名前が自社にとって何を意味するのかを一度も文章にしていないことにあります。本記事では、標準 8 ステージの定義書づくりから、自動更新の設計、運用の落とし穴までを、リード管理を数字が信用される状態に組み直す手順として解説します。特別なスキルは不要で、型と巻末の AI 実行キットがあれば再現できます。

1. なぜステージ運用が形骸化するのか — 名前だけ導入して定義を書いていない

「MQL の定義って何ですか、と新人に聞かれて、うまく答えられませんでした」。運用が半年も回っているのに、こう打ち明けるマーケ担当は珍しくありません。

原因は、ステージの「名前」を導入して「定義」を導入していないことにあります。HubSpot の標準ライフサイクルステージは Subscriber / Lead / Marketing Qualified Lead / Sales Qualified Lead / Opportunity / Customer / Evangelist / Other の 8 段階です (HubSpot 公式ナレッジベース、2026-07 時点)。この 8 つの名前は最初から入っていますが、「自社にとって Lead と MQL の境目はどこか」は空欄のまま渡されます。名前は共有されていても基準が共有されていないので、マーケが MQL と判定したリードを営業が Lead 相当だと見なし、同じレコードに対して部門ごとに別の現実が同時に存在します。

やることはシンプルで、8 ステージそれぞれに次の 4 項目を貼るだけです。

• 判定基準: どの条件を満たしたらこのステージに入るか (行動 + 属性で言い切る)
• 所有部門: このステージへの遷移を誰が判断するか (マーケ / 営業)
• 入口イベント: 何が起きたら遷移するか (フォーム送信 / スコア到達 / Deal 作成 など)
• 自動化可否: その遷移を自動化してよいか、人の判断を残すか

よくある失敗は、この定義づくりをマーケだけで完結させてしまうことです。SQL は営業が受け取る側のステージなので、営業が納得していない基準は現場で無視されます。定義書は必ずマーケと営業が同席して埋める。順番はこれが先で、HubSpot の設定画面を触るのはその後です。

→ 自社の営業プロセスから 8 ステージの定義書を起こす作業は、巻末の 実行キット① (所要 40 分) でそのまま実行できます。

2. 標準 8 ステージの定義書を先に作る — 名前の裏に判定基準を貼る

「うちは BtoB だから Subscriber なんて要らないのでは、と思って飛ばしていました」。ステージを部分的にしか使わない運用は、実はよく見かけます。

結論から言うと、8 ステージを全部使う必要はありませんが、使わないステージも「使わない」と明記するのが定義書の役割です。HubSpot は標準 8 ステージに加えて、全プランでカスタムステージの追加もできます (HubSpot 公式、2026-07 時点)。ただし多くの BtoB では、まず標準 8 つのうち自社で使うものを確定させるほうが先です。定義書は次の粒度で書きます。

判定基準は「行動 + 属性」の 2 軸で言い切るのがポイントです。「興味がありそう」ではなく「価格ページを 3 回閲覧、かつ従業員 50 名以上」のように、誰が読んでも同じ判定になる文にします。この一文が書ければ、後の自動化ルールはこの文をほぼそのまま HubSpot の条件に写すだけになります。

よくある失敗は、Customer と Evangelist の定義を後回しにすることです。ファネル前半 (Lead〜SQL) は熱心に定義しても、受注後のステージを空欄にしておくと、既存顧客が Customer のまま止まり、アップセルや紹介の起点になる Evangelist が一度も付かないデータになります。受注後の 2 ステージこそ、CS を巻き込んで基準を決めておくと後の分析が効きます。

3. MQL と SQL の線引き — マーケが持つ境界、営業が持つ境界

「マーケが MQL を大量に流してくるが、営業からするとほとんど商談にならない」。マーケと営業のあいだで最も揉めるのが、この MQL と SQL の受け渡しです。

線引きの原則は、MQL はマーケが所有し、SQL は営業が所有するという所有権の分離です。MQL はマーケティング側のシグナル (行動スコアと属性の閾値) で判定できます。一方 SQL は「営業が中身を見て商談に値すると受理した」という人の判断が入るステージです。HubSpot でも SQL には Lead Status (New / Open / In Progress / Unqualified など) という下位の状態管理が用意されており、営業の受理プロセスを段階的に持てるようになっています (HubSpot 公式、2026-07 時点)。

この所有権の分離を決めておくと、自動化の範囲も自動的に決まります。マーケが所有する Lead・MQL への遷移は自動化してよい。SQL への遷移は営業の受理を挟むので、自動では飛ばさない。境界がそのまま自動化の境界になります。

よくある失敗は、マーケの行動データだけで SQL まで自動的に上げてしまうことです。営業が「自分が受理していないのに SQL になっている」状態を経験すると、CRM の数字そのものを信用しなくなります。いったん失われた信用を取り戻すコストは、ステージ定義をやり直すより高くつきます。マーケのシグナルで上げるのは MQL まで、SQL からは営業が手を挙げる — この一線を最初に引いておいてください。

4. 自動更新の設計 — 「前進のみ」を前提にした 3 つのスイッチ

「自動でステージが動くようにしたら、顧客が急に Opportunity に戻ってしまって混乱しました」。自動化に踏み切った直後、この手の事故報告が届くことがあります。

ここで押さえるべき HubSpot の最重要仕様が 1 つあります。ライフサイクルステージの自動更新は「前進のみ (forward-only)」です (HubSpot 公式、2026-07 時点)。無値から Subscriber、Subscriber から Opportunity のように前へは自動で進みますが、Customer から Opportunity へ戻すような後戻りは自動では起きません。既に Customer のコンタクトに新しい Deal を関連付けても、ステージは Opportunity に下がらず Customer のままです。この仕様を知らないと「なぜ戻らないのか」と悩み、知っていれば「戻らないのが正しい」と設計できます。

HubSpot が用意している自動化のスイッチは 3 つです (Settings → Objects → Contacts → Lifecycle Stage、2026-07 時点)。

1. 新規作成レコードのデフォルトステージ — フォームや連携アプリ経由で作られたレコードに初期ステージを付与する
2. 関連付けに基づく同期 — 会社のステージを関連コンタクトに適用する。方向は会社 → コンタクトの一方通行で、コンタクトのステージ変更は会社に波及しない
3. Deal 連動 — Deal が作成されたら関連コンタクト/会社を Opportunity に、Deal が成約 (won) したら Customer に自動更新する

設計の型としては、この 3 つのうち「定義書で自動化可と決めたステージ」に対応するスイッチだけを ON にします。Lead・MQL はマーケ所有なので自動化、Opportunity・Customer は Deal 連動で自動化、SQL は営業判断なので手動のまま。定義書の「自動化可否」列が、そのまま ON にするスイッチの一覧になります。

よくある失敗は、3 つのスイッチを「便利そうだから」と全部 ON にすることです。特に関連付け同期は、会社のステージが意図せずコンタクト全員に伝播するため、1 社に複数の温度感のコンタクトがいる BtoB では過剰更新を起こしがちです。まず Deal 連動だけを ON にして挙動を確認し、関連付け同期は自社の会社-コンタクト構造を見てから判断する。段階的に開けるのが安全です。

→ 定義書からどのスイッチを ON にすべきかの自動更新ルール設計は、巻末の 実行キット② (所要 30 分) で作れます。

5. 運用の落とし穴 — 後戻り・Deal 誤爆・営業不信を先回りで潰す

「失注した商談のコンタクトが Customer のまま残っていて、受注数が水増しされていました」。運用を数ヶ月続けると、こうしたデータの歪みが表面化します。

落とし穴は事故が起きてから気づくものがほとんどなので、先に 3 つ潰しておきます。1 つ目は後戻りの扱いです。前進のみ仕様のため、MQL が冷めても自動では Lead に戻りません。かといって手動で戻すと「Became a MQL date」などの日付プロパティがクリア・再設定され、ファネルの履歴が壊れます (HubSpot 公式、2026-07 時点)。冷めたリードは無理にステージを下げず、「MQL 失効」のような別プロパティでフラグを立てて除外するのが定石です。

2 つ目は Deal 連動の誤爆です。Deal 成約でコンタクトも会社も自動で Customer になりますが、テスト用の Deal や、社内検証で作った Deal をうっかり won にすると、無関係なコンタクトまで Customer に昇格します。Deal のパイプライン運用ルール (テスト Deal は別パイプライン、あるいは won にしない) を先に決めておくと防げます。

3 つ目は営業の不信です。第 3 章でも触れたとおり、営業が受理していないのに SQL が付く状態は、CRM 全体の信頼を毀損します。自動化するのはマーケ所有ステージまでに留める、という第 4 章の設計を守ることが、そのまま不信の予防になります。

よくある失敗は、これらの落とし穴を「運用しながら気づいたら直す」と後回しにすることです。歪んだデータで一度でも役員会のファネルレポートを出してしまうと、以後その数字は疑われ続けます。ステージを自動化する前に、この 3 つの回避策を定義書に注記として書き込んでおいてください。

→ 既存のステージ運用にこれらの歪みが潜んでいないかの診断は、巻末の 実行キット③ (所要 30 分) で点検できます。

6. 分析への接続 — ステージ日付プロパティで転換率と滞留を測る

「ステージは付けているけれど、それで何がわかるのかと聞かれると答えに詰まります」。ステージ運用のゴールは色分けではなく分析なのに、ここが抜けている組織は多いです。

ステージを定義して自動化まで組んだら、最後は転換率と滞留の 2 つを測るところまで接続します。HubSpot は各ステージへの到達日を「Became a {stage} date」系のプロパティで自動記録しています。この日付を使えば、Lead → MQL → SQL → Opportunity → Customer の各段でどれだけ絞られるか (転換率) と、各ステージに何日滞留しているか (velocity) が測れます。定義があいまいなまま集計しても意味のある数字にならないので、第 1〜2 章の定義書が効いてくるのはこの段階です。

見るべき指標を最小構成で挙げると、次の 3 つです。

• 各段の転換率: どのステージ間で最も脱落しているか (ボトルネックの特定)
• ステージ滞留日数: SQL で止まっている商談が異常に多くないか (営業の手詰まり検知)
• 月次コホートでの推移: 今月の Lead が翌月どれだけ MQL に育ったか

よくある失敗は、ステージ設定だけして転換率レポートを一度も作らないことです。そうなるとステージは「メタデータ」であって「インテリジェンス」にはなりません。月に一度、この 3 指標を見る場を先に決めてから運用を始めると、ステージが数字を生む装置になります。滞留や日次スナップショットの取り方は、HubSpot の Stage Snapshot を Apps Script で記録する方法 で詳しく扱っています。

まとめ

ライフサイクルステージがうまく回らない原因は、機能でもプランでもなく「定義の言語化」と「自動化の設計」が抜けていることにあります。標準 8 ステージに判定基準と所有部門を貼った定義書を先に作り、その「自動化可否」列を HubSpot の 3 つのスイッチにそのまま写す。自動更新は前進のみという仕様を前提に、後戻りは別プロパティで扱う。ここまで組めば、ステージは転換率と滞留を測る分析装置になります。まずはキット①の定義書づくりから始めてみてください。

自動化の具体的なワークフロー設定は HubSpot ワークフローの実装例 が参考になります。humbulls では、こうしたステージ設計から自動化・分析までを伴走する Growth Partner サービス を提供しています。設計から自社で全部やるのは重いと感じたら、ご相談ください。実装テンプレを含む詳細ガイドは BtoB マーケ AI 活用ガイド で配布しています。

🤖 AI 実行キット

本文の判断と設計を、そのまま AI で実行するためのキット集です。プロンプトは Claude (ブラウザ版で可) にコピペすれば動きます。

キット① 自社の営業プロセスから 8 ステージの定義書を生成する — 40 分

種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: 自社の営業プロセスを説明した文章。箇条書きのメモや、営業への口頭説明を書き起こしたものでも動きます。完璧な整理は不要です。

プロンプト:

HubSpot のライフサイクルステージ定義書づくりを手伝ってください。

【自社の営業プロセス(思いつく限り、粒度バラバラで OK)】
- 事業: BtoB SaaS、従業員 50 名以上の企業向け(記入例)
- リード獲得: 資料 DL、問い合わせフォーム、ウェビナー(記入例)
- 営業への引き渡し: マーケが有望と判断したらインサイドセールスへ(記入例)
- (以下、自社のプロセスを貼り付け)

【定義書のルール(必ずこの基準に従うこと)】
- 対象は HubSpot 標準 8 ステージ: Subscriber / Lead / MQL / SQL /
  Opportunity / Customer / Evangelist / Other
- 各ステージに 4 項目を必ず埋める:
  (1) 判定基準 = 「行動 + 属性」で、誰が読んでも同じ判定になる一文
  (2) 所有部門 = マーケ / 営業 / CS / 全社 のいずれか
  (3) 入口イベント = 何が起きたら遷移するか
  (4) 自動化可否 = 自動化してよい / 人の判断を残す
- MQL まではマーケ所有=自動化可、SQL は営業の受理を挟む=手動、を原則とする
- 自社で使わないステージは「使わない」と明記する

【出力】
1. 8 ステージの定義書(表形式。上記 4 項目を列に)
2. 判定基準が「行動 + 属性」の 2 軸で書けているかのセルフ点検コメント
3. マーケと営業で解釈が割れそうな箇所の指摘(合意形成が必要な論点)

出力の確認ポイント:

• 判定基準が「興味がありそう」のような曖昧語で終わっていないか。行動と属性の両方が入った一文になっているかを見てください
• SQL の自動化可否が「人の判断を残す」になっているか。ここが「自動化可」になっていたら営業不信の火種です

うまくいかないとき:

• 定義が一般論に寄って自社の実態と合わない → 実際の失注理由・受注理由を 3 件ずつ貼り付けて再実行すると、判定基準が自社仕様に寄ります

キット② 定義書から自動更新ルールを設計する — 30 分

種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: キット①で作った定義書 (特に「自動化可否」列)

プロンプト:

HubSpot のライフサイクルステージ自動更新の設計を手伝ってください。

【前提: HubSpot の仕様(必ずこの制約の中で設計すること)】
- 自動更新は「前進のみ」。後戻りは自動では起きない
- 使える自動化スイッチは 3 つ:
  (A) 新規作成レコードのデフォルトステージ
  (B) 関連付けに基づく同期(会社→コンタクトの一方通行)
  (C) Deal 連動(Deal 作成→Opportunity、Deal 成約→Customer)

【自社の定義書(キット①の結果を貼り付け)】
- (ここに 8 ステージの定義書を貼る)

【出力】
1. 3 つのスイッチ(A/B/C)それぞれを ON にすべきか OFF にすべきかの判定と根拠
2. ON にするスイッチの具体設定(どのステージを、どの条件で自動化するか)
3. 手動運用に残すステージ一覧と、その手動オペレーションの担当
4. 後戻りが必要なケース(冷めた MQL など)を、ステージを下げずに扱う代替プロパティの設計案

出力の確認ポイント:

• 関連付け同期 (B) を安易に ON にしていないか。1 社に複数コンタクトがいる BtoB では過剰更新の原因になります。根拠が薄ければまず OFF が安全です
• 後戻りの代替案が「手動でステージを下げる」になっていないか。日付プロパティが壊れるので、別フラグ方式になっているかを見てください

うまくいかないとき:

• スイッチの判定が全部 ON に寄る → 「まず Deal 連動 (C) だけ ON、他は 1 ヶ月挙動を見てから」と制約を追記して再実行

キット③ 既存のステージ運用の歪みを診断する — 30 分

種別: 判断キット 使うもの: Claude (ブラウザ版で可。HubSpot MCP があればレコードを直接読ませても可) 事前に用意するもの: 現在のステージ別コンタクト件数、および気になっている症状のメモ (「Customer が多すぎる」など)

プロンプト:

HubSpot のライフサイクルステージ運用に潜む歪みを診断してください。

【現状データ】
- ステージ別コンタクト件数: Subscriber ○件 / Lead ○件 / MQL ○件 /
  SQL ○件 / Opportunity ○件 / Customer ○件 / Evangelist ○件 / Other ○件
- 気になっている症状(あれば): (記入例: 失注後も Customer のまま残っている)

【診断の観点(必ずこの 3 つを点検すること)】
1. 後戻りの歪み: 前進のみ仕様のため、冷めた MQL や失注コンタクトが
   上位ステージに滞留していないか
2. Deal 連動の誤爆: テスト Deal の won 化などで、不自然に Customer が
   膨らんでいないか
3. 営業不信の兆候: 営業の受理を経ていない SQL が自動で付いていないか

【出力】
1. 3 観点それぞれの疑わしさ(高 / 中 / 低)と、そう判断した根拠
2. 高・中と判定した項目の具体的な確認クエリ(HubSpot でどう絞り込むか)
3. 修正の優先順位(ファネルレポートへの影響が大きい順)

出力の確認ポイント:

• 「高」と判定された歪みの確認クエリが具体的か。「Customer かつ関連 Deal が全て失注」のように、HubSpot のフィルタに落とせる粒度になっているかを見てください

うまくいかないとき:

• 件数だけでは診断が浅い → ステージ別の「最終更新日」の分布を追加で貼ると、滞留の診断精度が上がります

参考文献

• Use contact and company lifecycle stages — HubSpot Knowledge Base (取得日: 2026-07)
• Create and customize lifecycle stages — HubSpot Knowledge Base (取得日: 2026-07)
• Automatically set and sync record lifecycle stages — HubSpot Knowledge Base (取得日: 2026-07)