営業会議で「今月の新規リードは何件ですか」と聞くと、マーケティング部門はフォーム送信数を、インサイドセールスは架電した件数を、営業部門は商談化した件数を答える。3つの数字はどれも正しいのに、どこで何件落ちたのかを誰も説明できない——CRMを全社導入した大企業で、最初に起きる断絶です。
この断絶を埋めるのがリードステータスです。ライフサイクルステージが「組織として顧客をどう定義するか」を決めるプロパティーだとすれば、リードステータスは「その1件に、いま誰が何をしているか」を記録するプロパティーです。本記事では、私たちがHubSpotの導入支援で実際に設計している順序に沿って、既定値の意味、ライフサイクルステージとの使い分け、更新を人手に頼らない運用設計までを整理します。
目次
リードステータス（内部名 hs_lead_status）は、HubSpotに標準で用意されているプロパティーの一つです。HubSpotの既定のコンタクトプロパティーには「購買サイクルのリードとして、コンタクトまたは会社がどの段階にいるかを示すコンタクトプロパティーまたは会社プロパティー」と記載されています（2026年7月2日更新時点）。
定義文で見落とされやすいのは「コンタクトプロパティーまたは会社プロパティー」という部分です。リードステータスは人（コンタクト）だけでなく、法人（会社）にも同じ名前で存在します。私たちが大企業のポータルを設計するとき、この2つを混同したまま運用が始まっているケースを頻繁に見ます。同一企業の複数担当者がそれぞれ別のステータスを持ったとき、会社としての状態をどちらで判断するのかが決まっていないと、営業は結局Excelに戻ります。
弊社のHubSpotポータルでプロパティーAPIから実際に取得した結果を示します（2026年9月24日取得）。既定値は編集していないため、標準のまま出てきた8つです。ここで重要なのは日本語ラベルではなく、括弧内の内部値のほうです。インポートやAPI連携で指定するのは内部値であり、画面表示のラベルではありません。
| ラベル（内部値） | 何を意味するか | 運用上の注意 |
|---|---|---|
New（NEW） |
取得したが、まだ誰も触っていない | ここに滞留した日数が、そのまま初動の遅さになる |
Open（OPEN） |
担当者が確認し、対応対象として開いた | NewとOpenの違いを定義しないと、両方に溜まる |
In Progress（IN_PROGRESS） |
アプローチが進行中 | 最も曖昧になりやすい。終了条件を先に決める |
Open Deal（OPEN_DEAL） |
取引（商談）が作成されている | 取引オブジェクト側の情報と二重管理になりやすい |
Unqualified（UNQUALIFIED） |
要件を満たさないと判断した | 理由を別プロパティーで持たないと再利用できない |
Attempted to Contact（ATTEMPTED_TO_CONTACT） |
接触を試みたが到達していない | 試行回数を持たないと「何回かけたか」が消える |
Connected（CONNECTED） |
相手と会話が成立した | インサイドセールスのKPIに直結する分岐点 |
Bad Timing（BAD_TIMING） |
関心はあるが時期が合わない | 再アプローチ日を持たないと二度と戻ってこない |
同じAPIで会社オブジェクトのリードステータスも取得しましたが、値の構成は同一で、説明文だけが「The company's sales, prospecting or outreach status」に変わります。つまりHubSpotは、人に対する接触状況と法人に対する接触状況を、同じ語彙で別々に持てる設計になっています。どちらを正とするかは、製品ではなく運用ルールで決める領域です。
できます。リードステータスは選択式（enumeration）のプロパティーなので、プロパティーの作成と編集の手順で、設定内のプロパティー画面からオプションを追加・並べ替え・非表示にできます。
ただし私たちがプロジェクト初期に必ず止めるのが、この「値を増やす作業」です。既定の8つを日本語に置き換えたうえで、さらに自社の営業プロセスに合わせて15個、20個と増やした設計を持ち込まれることがありますが、値が増えるほど入力されなくなります。増やすかどうかの判断基準は後述します。
この2つの使い分けが、リードステータス設計でいちばん多い相談です。どちらも「段階」を表すため、片方だけで足りるのではないかという疑問が出ます。結論から言えば、測っている対象が違うので両方必要です。
ライフサイクルステージは、ライフサイクルステージの使用に記載のとおり、マーケティングからセールスへ至るプロセスのどこにいるかを示します。既定ではサブスクライバー、リード、MQL、SQL、商談、顧客、エバンジェリスト、その他が用意されています。
対してリードステータスは、同じ1件に対して「営業活動として、いまどこまで手をつけたか」を記録します。両者の関係を1行で言えば、ライフサイクルステージは組織の定義、リードステータスは担当者の行動です。
| 観点 | ライフサイクルステージ | リードステータス |
|---|---|---|
| 答える問い | この人は自社にとって何者か | この人に誰が何をしたか |
| 決める人 | 経営・マーケ・営業の合意（定義） | 現場の担当者（実行） |
| 変更頻度 | 低い。前進が基本 | 高い。行き来する |
| レポートの使い道 | ファネルの歩留まり | 活動量とボトルネック |
| 自動化 | オブジェクト間で同期する仕組みがある | ワークフローで個別に設計する |
表の最終行は実務上の差が大きい部分です。ライフサイクルステージには、レコードのライフサイクルステージの自動設定と同期に記載のとおり、コンタクト・会社・取引の間でステージを同期させる標準の仕組みがあります。リードステータスには同等の標準同期がないため、会社とコンタクトの整合は自前のワークフローで設計する必要があります。ここを設計せずに走り出すと、会社レコードのステータスだけが半年前のまま止まります。
ライフサイクルステージ側の設計はHubSpotのライフサイクルステージ徹底解説で個別に扱っています。本記事と併せて読むと、2つのプロパティーの役割分担が決めやすくなります。
2つを掛け合わせると、単独では出てこない異常が見えます。たとえば「ライフサイクルステージ＝MQL、リードステータス＝New」のまま2週間以上滞留している件数は、マーケティングが渡したのに営業が触っていない量そのものです。この数字は、部門間の責任論を主観から外す材料になります。
逆に「ライフサイクルステージ＝リード、リードステータス＝Connected」が多い場合、現場は会話まで到達しているのに、MQLの定義がそれを拾えていないということです。この場合に直すべきはリードステータスではなく、MQLの定義のほうです。
HubSpotには、プロパティーとしてのリードステータスとは別に、「リード」という独立したオブジェクトがあります。名前が近いため混同されますが、利用条件がまったく違います。
リードの管理によれば、リードオブジェクトはSales HubのProfessionalおよびEnterpriseで利用でき、一部の機能にはシートが必要です（2026年7月24日更新時点）。つまり無料版やStarterのアカウントでは、リードオブジェクトは使えません。各エディションで何が使えるかはSales Hubの製品ページとSales Hubの料金ページで確認できます（価格ページは表示が動的に変わるため、稟議に使う金額は必ず画面上の実値を取得してください）。一方のリードステータスは既定のコンタクトプロパティーなので、エディションを問わず存在します。
この差は、段階導入を計画している組織の設計順序に直結します。私たちがStarterから始める企業のポータルを設計するときは、まずリードステータスで接触管理の運用を確立し、Professionalへの移行時にリードオブジェクトへ移すかどうかを再判断します。最初からリードオブジェクト前提で業務フローを書くと、エディションを上げられなかった時点で設計が丸ごと使えなくなるためです。
リード（見込み客）パイプラインの自動化を設定するには、Sales Hub Professional・Enterprise向けに、テンプレート化された自動化として、ライフサイクルステージに基づくリードの自動作成、見込みなしの理由が選択されたときのフォローアップ用リードの自動作成、メール送信や通話記録の完了に応じた段階の自動進行、返信やミーティング予約に応じた段階の自動進行が挙げられています（2026年9月16日更新時点）。
同ページには、リード段階に変更不可の2つの進行として「試行」と「接続済み」が設定されていることも記載されています。既定のリードステータスにあるATTEMPTED_TO_CONTACTとCONNECTEDと同じ語彙です。私たちがリードオブジェクトを併用するポータルを設計する際は、この2つの語彙を両方で同じ意味に固定し、レポートでどちらを正とするかを先に決めています。決めないまま両方を運用すると、同じ名前の指標が2つできます。
なお、リードの一覧や優先順位付けは営業ワークスペースから行います。リードのステージ構成自体はパイプラインの設定とカスタマイズの手順で編集します。リードオブジェクト側の設定手順はHubSpotで行うリード管理とは？で詳しく扱っています。
設計に入る前に決めるべきことが3つあります。順序を守らないと、あとから値を足す作業が延々と続きます。
1つ目は、このプロパティーを見る人を1人に決めることです。インサイドセールスのマネージャーなのか、営業企画なのか、マーケティング責任者なのかで、必要な粒度が変わります。全員が満足する粒度は存在しません。
2つ目は、各値の終了条件を書き下すことです。「In Progressは、いつIn Progressでなくなるのか」に一文で答えられない値は、必ず滞留します。私たちがワークショップで最初にやるのは、値の追加ではなく、この終了条件を8個ぶん埋める作業です。
3つ目は、更新する人と更新のきっかけを決めることです。人が手で変えるのか、ワークフローが変えるのか、外部システムからの連携で変わるのか。3つが混在する設計は運用が破綻します。
現場が英語ラベルに抵抗を示す場合、ラベルは日本語化して構いません。ただし内部値は変えないでください。HubSpotにデータをインポートする方法で扱っているCSVインポートでも、オブジェクトのインポートに記載のとおりファイル内の値がプロパティーの値と突き合わされるため、内部値の一致が前提になります。外部システムとのAPI連携でも同様です。ラベルだけを日本語化すれば、画面は日本語、連携は既定値のまま維持できます。
実際に最も多いトラブルは、内部値まで日本語に作り替えた結果、MAやSFAからの連携が通らなくなるというものです。移行後にこれを直すには、既存レコードの値をすべて置換したうえで連携側の定義も直す必要があり、片手間ではできません。
既定値のうち、実務で最も情報を失うのがUNQUALIFIEDです。予算が合わない、時期が合わない、決裁者ではない、そもそも対象業種ではない——これらをすべて1つの値に落とすと、年間で数千件の「不適格」が積み上がった時点で、そこから何も学べなくなります。
私たちが設計する際は、リードステータスの値は増やさず、別途「不適格理由」の選択式プロパティーを作ってセットで入力させます。理由の粒度はリードステータスとは独立して変えられるため、営業プロセスを変えるたびにリードステータスの定義をいじらずに済みます。ICPの定義を見直す際、この理由別の内訳が最も使える材料になります。
リードステータスが機能しない原因のほとんどは、値の設計ではなく更新運用にあります。入力されていないプロパティーは、どれだけ設計が正しくてもレポートに何も映しません。
手動更新だけの運用では、更新が2種類の場面に偏ります。商談化したとき（成果報告になるため）と、月末の棚卸しのとき（まとめて処理されるため）です。その結果、Newに滞留した期間が実態より短く記録され、初動の遅さがデータから消えます。経営に「初動は問題ない」と報告され続ける状態が、いちばん危険です。
ワークフローの作成を使えば、フォーム送信時にNewを設定する、営業担当者が割り当てられたらOpenにする、といった機械的な遷移は自動化できます。HubSpot ワークフローとは？で扱っている分岐やデータ操作のアクションを組み合わせれば、条件付きの遷移も作れます。
一方で自動化してはいけない遷移もあります。CONNECTEDとUNQUALIFIEDの2つです。会話が成立したかどうかと、要件を満たさないと判断したかどうかは、人の判断そのものです。ここを「通話記録が1件でもあればConnected」といったルールで自動化すると、数字は綺麗になりますが、指標としての意味が消えます。私たちが自動化の線を引くときは、事実で判定できるものだけを自動化し、判断が入るものは人に残しています。
「いつ更新されたか」を追うには、ステージの計算プロパティーが使えます。同ページには、各ステージに入った日付、出た日付、そのステージにいた最後の時間、累積時間、現在のステージに入った日付、現在のステージの時間が自動計算されると記載されています（2026年9月15日更新時点）。対象オブジェクトと必要なエディションは同ページの一覧で確認してください。
リードステータス自体は選択式プロパティーなので、滞留日数を直接は持ちません。そのため私たちは、ステータスが変わった日を記録するカスタムプロパティーをワークフローで更新し、そこからの経過日数でアラートを出す設計をよく使います。アクティブリストまたは静的リストの作成で「Newのまま14日超」を抽出すれば、週次で潰す対象が自動的に溜まります。
リードステータスを整備する目的は、入力させることではなく、部門間の議論を数字に載せ替えることです。カスタムレポートの作成で作れるレポートのうち、私たちが最初に必ず作るのは次の3本です。
1本目は、リードステータス別の件数推移です。どの値が増え続けているかを見るだけで、ボトルネックの位置が特定できます。2本目は、流入元別のステータス分布です。特定のチャネルだけUNQUALIFIED比率が突出していれば、広告か獲得フォームの設計を直す判断になります。3本目は、担当者別のATTEMPTED_TO_CONTACT比率です。到達していない量が個人差として出るのか、リストの質として出るのかが切り分けられます。
これらをHubSpotのレポートとダッシュボードで1枚にまとめ、営業会議の冒頭で必ず開く運用にします。開かれないダッシュボードは、作った瞬間から更新されなくなります。
なお、スコアリングと組み合わせる設計も有効ですが、順序を逆にしないでください。リードステータスの入力が安定していない段階でリードスコアリングを導入すると、母集団が歪んだままスコアが計算されます。スコアの設計そのものは効果の高いイベントに基づくリードスコアリングが参考になります。スコアリングは、ステータスの入力率が安定してからの施策です。
従業員1,000名規模のCRM全社導入で、リードステータスが機能しなくなるパターンは概ね3つに絞られます。
1つ目は、事業部ごとに値を分けてしまうことです。事業部Aは10個、事業部Bは6個という状態になると、全社のパイプラインが合算できなくなります。合算できないパイプラインは経営会議に出せないため、結局Excelでの再集計が復活します。値は全社で1セットにし、事業部固有の事情は別プロパティーで持たせてください。
2つ目は、既存SFAからの移行時に、旧システムのステータスをそのまま持ち込むことです。旧システムの値は旧システムの業務に最適化されているため、そのまま移すと使われない値が半分以上を占めます。移行時は、旧値と新値のマッピング表を作り、使用実績の少ない値を統合してから移します。
3つ目は、更新を現場の善意に任せることです。入力率が上がらない原因は、多くの場合「入力しても自分に返ってこない」ことにあります。ステータスを更新すると次のタスクが自動で生成される、担当者のダッシュボードの数字が動く、といった見返りを設計に含めてください。この観点はCRM全社導入で失敗する企業と成功する企業で詳しく扱っています。
これらは製品の問題ではなく組織の問題です。IPAが2026年7月16日に公表した国内企業のDX動向・AI活用動向のポイントは、回収1,799社（調査期間2026年4月17日〜6月12日）の規模で国内企業のDX推進状況を調べたものです。「DX動向2026」では、業務の効率化による生産性向上に比べ、組織横断・全体の業務プロセスのデジタル化は相対的に低い割合にとどまると報告されています。リードステータスは、まさにその組織横断の接点に置かれるプロパティーです。
いずれの失敗も、データ基盤としてのCRMを「誰の、どの判断に効くのか」から設計していないことに起因します。SSOT（信頼できる唯一の情報源）の観点から言えば、リードステータスは最も更新頻度が高く、最も壊れやすいプロパティーです。だからこそ、値の数を絞り、更新の主体を1つに決めることが効きます。
リードステータスは万能ではありません。導入を決める前に、できないことも把握しておいてください。
| 観点 | メリット | デメリット・限界 |
|---|---|---|
| 導入コスト | 既定プロパティーのため追加費用なしで使える | 設計と教育の工数は別途かかる |
| 粒度 | 接触状況を1つの軸で全社共通にできる | 1件につき1つの値しか持てない。複数商材の並行接触は表現できない |
| 履歴 | プロパティー履歴で変更の経緯を追える | 滞留日数を標準では保持しない。自前の設計が要る |
| 自動化 | ワークフローで機械的な遷移を自動化できる | 判断が入る遷移は自動化すべきでない |
| 対象範囲 | コンタクトと会社の両方に存在する | 両者を自動同期する標準機能がない |
2行目の「1件につき1つの値」は、複数事業を持つ企業で必ず問題になります。同じ担当者に対してA事業は商談化済み、B事業は未接触という状態は、リードステータス単独では表現できません。この場合は取引オブジェクトで分けるか、カスタムオブジェクトで事業別の接触記録を持つ設計になります。HubSpotの営業管理・商談管理と合わせて、どこで分けるかを決めてください。
使えます。リードステータスは既定のコンタクトプロパティーおよび会社プロパティーであり、エディションによる提供有無の記載は確認できませんでした。一方、独立した「リード」オブジェクトはSales Hub Professional・Enterprise向けと明記されているため、こちらは無料版では使えません。
ライフサイクルステージが先です。組織としてMQLやSQLの定義が固まっていない状態でリードステータスの運用ルールを作ると、定義変更のたびにステータス設計をやり直すことになります。定義が先、行動記録が後です。
ありません。使わない値は非表示にしてください。ただし削除ではなく非表示を推奨します。過去のレコードがその値を持っている場合、削除するとレポートの過去分に影響します。
入力を義務化する前に、更新すると何が起きるのかを設計してください。ステータス更新をトリガーに次のタスクが自動生成される、上長への報告資料が自動で埋まる、といった見返りがない限り、入力率は上がりません。督促の運用を足すより、見返りを1つ作るほうが効きます。
全件をそのまま移すことは推奨しません。直近12か月など期間を区切り、それより古いレコードは移行対象から外すか、まとめて1つの値に寄せてください。過去データを完全に再現しようとすると、移行期間が延び、その間に現行業務のデータが二重管理になります。
製品側にどちらを正とする定義はありません。運用ルールで決める領域です。私たちが設計する際は、原則としてコンタクト側を実態、会社側を代表値とし、会社側はワークフローで機械的に更新する形にしています。両方を人が手で更新する設計は避けてください。
最初に疑うのは、値が未入力のレコードです。未入力は集計対象から外れるため、母数が合わなくなります。データ品質ツールで未入力と重複の状況を確認してから、レポートの定義を疑ってください。
内部値（NEWなど大文字の値）を渡してください。日本語ラベルを渡しても一致しません。コンタクトを他のアプリと同期するのようなデータ同期型の連携では、同期時のライフサイクルステージの指定と同じく、どちらのシステムを優先するかをフィールドマッピングで先に決めてください。大量件数をAPIで更新する場合はAPIの利用ガイドラインとレート制限も確認が必要です。連携先の設定画面でプルダウンから選べる場合も、実際に送信されている値が内部値かどうかをテストレコードで確認することをおすすめします。
リードステータスは既定で用意された小さなプロパティーですが、設計を間違えると全社のパイプラインが合算できなくなります。押さえるべきは3点です。ライフサイクルステージが組織の定義、リードステータスが担当者の行動という役割分担を崩さないこと。値を増やさず、不適格の理由など粒度が必要な情報は別プロパティーに逃がすこと。そして、事実で判定できる遷移だけを自動化し、判断が入る遷移は人に残すことです。
私たちはHubSpotの認定エリートパートナーとして、従業員1,000名規模の組織におけるCRM全社導入を支援しています。プロパティー設計そのものよりも、部門間で定義を合意させる工程に時間がかかることがほとんどです。設計に着手する前の合意形成からご相談いただけます。お問い合わせはこちらからご連絡ください。