%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
KPIツリーは、売上目標を掛け算で分解して現場の行動まで一本の線でつなぐ設計図です。KGIから逆算し、指標の因果関係を樹形図で可視化することで、どこを改善すれば最終目標に届くかが見えるようになります。
KPIツリーは、売上目標を掛け算で分解して現場の行動まで一本の線でつなぐ設計図です。KGIから逆算し、指標の因果関係を樹形図で可視化することで、どこを改善すれば最終目標に届くかが見えるようになります。
「KPIは設定しているけれど、各指標がどう繋がっているのか分からない」「個別のKPIは達成しているのに、最終目標には届かない」「毎月レポートは出しているが、次に何をすべきかの議論にならない」——こうした声は、マーケティング組織の立ち上げ期から拡大期まで、規模を問わずよく聞きます。
KPIツリーとは、最終的なゴール指標（KGI）を頂点に置き、その達成に必要なKPI（重要業績評価指標）を樹形図で階層的に分解・可視化したフレームワークです。BtoBマーケティングで特に有効なのは、ファネルの各段階（認知→リード獲得→育成→商談→成約）が明確に分かれているため、各段階のKPIとKGIの関係を論理的に構造化しやすいからです。
本記事では、KPIツリーの基本概念から、KGIからの逆算設計手順、すぐに使えるテンプレート、そしてスプレッドシート管理から抜け出してCRM上で運用に載せるところまでを解説します。
本記事は「BtoBマーケティングのKPI設計ガイド｜フェーズ別の具体例と管理テンプレート」シリーズの一部です。
この記事でわかること
この記事では、KPIツリーを初めて作る方にもわかるように、基本概念から実践的な運用設計までを順に解説します。読み進めることで、以下の内容が理解できるようになります。
- KPIツリーの構成要素と基本構造 — KGI・KSF・KPI・KDIの4階層がそれぞれどんな役割を持ち、どう繋がるのかを整理します。
- KGIから逆算する5ステップの設計手順 — 売上を掛け算で因数分解し、各階層に目標値を置き、行動指標まで落とし込む流れを具体例で追います。
- そのまま使える設計テンプレート2種 — 売上起点とパイプライン起点の2パターンのツリーを提示します。自社の事業構造に近い方をベースにしてください。
- レバレッジポイントの見つけ方とレビュー設計 — どの指標から手をつけるかの判断基準と、週次・月次・四半期・年次のレビューサイクルを解説します。
- KPIツリーを「更新され続ける仕組み」にする方法 — スプレッドシート管理の限界と、CRMのダッシュボードに載せ替えるときの考え方をお伝えします。
マーケティングのKPI設計をこれから整えたい方、あるいは既にKPIはあるものの運用が形骸化している方に向けて書いています。最後まで読むと、自社のKGIから逆算したKPIツリーを自分で描き、チームで合意し、日次の行動に接続するところまでができるようになります。
KPIツリーとは何か｜4つの構成要素と基本構造
KPIツリーは「指標の一覧表」ではありません。指標と指標の間に因果関係の線が引かれていることが本質です。
この線があるから、次のことができます。
- ある数字が動いたとき ── 最終的な売上がどれだけ動くのかを予測できます。
- 売上が足りないとき ── どこが原因なのかを辿れます。
実務での応用についてはBtoBマーケティングのKPI設計ガイドで具体例とともに紹介しています。
定義とKPI一覧表との違い
KPIツリーとは、最終的なゴール指標（KGI）を頂点に置き、その達成に必要なKPI（重要業績評価指標）を樹形図（ツリー構造）で階層的に分解・可視化したフレームワークです。
よくあるKPI一覧表は「セッション数」「リード数」「商談数」「受注数」が横並びに置かれているだけで、どれか一つが未達だったときに他へどう波及するかが読み取れません。
ツリー構造にすると、リード数の未達が何件の商談不足につながり、最終的に売上がいくら足りなくなるかまで一本で計算できます。この「計算できる状態」になっているかどうかが、一覧表とツリーの決定的な違いになってきます。
4つの構成要素（KGI／KSF／KPI／KDI）
| 要素 | 正式名称 | 役割 | 具体例 |
|---|---|---|---|
| KGI | Key Goal Indicator | 最終目標指標 | 年間売上3億円 |
| KSF | Key Success Factor | 成功のための重要要因 | MQLからの商談転換率向上 |
| KPI | Key Performance Indicator | KSFの進捗を測る指標 | 商談化率50%以上 |
| KDI | Key Do Indicator | 行動レベルの実行指標 | 月間8本の記事公開 |
見落とされやすいのがKSFとKDIです。
- KSF ── 「今期はどこで勝負するか」という意思決定そのもので、これが無いとツリーが全方位に広がって焦点がぼやけます。
- KDI ── 「明日の自分が何をするか」で、これが無いとKPIは数字を眺めるだけの存在になってしまいます。
この4つが揃って初めてツリーが動き始めます。
基本構造のイメージ
KGI（最終目標）
├── KPI 1（大分類）
│ ├── KPI 1-1（中分類）
│ │ ├── KDI 1-1-1（行動指標）
│ │ └── KDI 1-1-2（行動指標）
│ └── KPI 1-2（中分類）
│ └── KDI 1-2-1（行動指標）
└── KPI 2（大分類）
├── KPI 2-1（中分類）
└── KPI 2-2（中分類）ただし、この構造をそのまま自社に当てはめようとすると無理が出やすくなります。商材単価が数十万円で受注までのリードタイムが短い事業と、数千万円で一年がかりの事業では、中間に置くべき指標がまったく違ってきます。
企業様によって最適な形は異なりますので、構造はあくまで骨格として捉え、自社のカスタマージャーニーに合わせて枝を組み替えていただく前提で進めてください。
なぜKPIツリーが必要なのか｜4つの効果
KPIツリーを作る目的は、きれいな図を描くことではなく、意思決定のスピードと質を上げることにあります。ここでは実務で効いてくる4つの効果を整理します。この領域に関心がある方にはマーケティングダッシュボードの作り方もおすすめです。
因果関係が共有言語になる
個別のKPIがKGIにどう繋がっているかが明確になり、「この指標を改善すると何が起きるか」がチーム全員で共有できます。
これはマーケティング担当者個人の頭の中にあった暗黙知を、チームの共有物に変える作業でもあります。
「なんとなくリードを増やす」ではなく「リードを何件増やすと売上がいくら増える」という会話ができるようになると、施策の提案と承認のプロセスが一気に短くなります。
ボトルネックが一目で特定できる
ツリー全体を俯瞰すると、KGI達成を阻害している箇所が浮かび上がります。
リード数は計画通りなのに商談化率だけが計画の半分、といった状態が見えれば、打ち手はコンテンツ増産ではなくリードの質の見直しや営業との引き渡し基準の再定義だと判断できます。
ボトルネックを見誤ったまま予算を投下してしまうことが、マーケティング投資で最も避けたい失敗です。
優先順位づけと部門連携がしやすくなる
各KPIの改善インパクトを同じ土俵で比較できるため、どの施策に注力すべきかを感覚ではなく構造で判断できます。
またマーケティング・営業・経営層が同じツリーを見ながら議論できるので、次のような認識のズレが減っていきます。
- 「マーケはリード数だけ見ている」
- 「営業は受注しか見ていない」
部門間の連携についてはマーケティングと営業の連携を強化する方法もあわせてご覧ください。
BtoBマーケティングのKPIツリー設計手順｜5ステップ
ここからは実際の作り方です。順番を飛ばすと後から作り直しになりやすいので、KGIの確定から一つずつ進めていきます。具体的な実践方法はマーケティング戦略の立て方で詳しく解説しています。
ステップ1：KGIを設定する
KGIは経営目標と直結した、測定可能な最終指標です。ここが経営会議で使われている数字とズレていると、ツリー全体が社内で採用されません。
設定時のポイントは3つです。
- 売上目標と直結していること
- 測定可能（定量的）であること
- 期限が明確であること
KGIの例としては、次のような形が挙げられます。
- 年間売上（新規） ── 3億円
- マーケティング起点のパイプライン金額 ── 10億円
- 年間新規顧客数 ── 100社
どれを置くかは、マーケティング部門がどこまでの責任範囲を持つかによって変わります。
- 受注まで責任を持つ組織 ── 売上を置く方が、現場の納得感が出やすくなります。
- 商談供給に責任を持つ組織 ── パイプライン金額を置く方が、現場の納得感が出やすくなります。
ステップ2：KGIを因数分解する
KGIを構成する要素に、掛け算で分解していきます。
年間売上 = 受注数 × 平均受注単価
受注数 = 商談数 × 受注率
商談数 = MQL数 × 商談化率
MQL数 = リード数 × MQL転換率
リード数 = セッション数 × CVRこの分解の鎖がそのままツリーの背骨になります。
ここで大事なのは、各項目がCRM上で実際に計測できる形になっているかを同時に確認することです。
「MQL」という言葉は使っているものの、誰がいつMQLになったのかをシステム上で判定できていない、というケースは珍しくありません。その場合はツリーを描く前に、ライフサイクルステージの定義から手をつける必要が出てきます。
ステップ3：各階層のKPIに目標値を置く
因数分解した各要素に、目標値を入れていきます。以下は年間売上3億円を起点にした場合の例です。
| 階層 | KPI | 計算式 | 目標値 |
|---|---|---|---|
| L1（KGI） | 年間売上（新規） | 受注数 × 平均受注単価 | 3億円 |
| L2 | 受注数 | 商談数 × 受注率 | 100件 |
| L2 | 平均受注単価 | - | 300万円 |
| L3 | 商談数（SQL） | MQL数 × 商談化率 | 400件 |
| L3 | 受注率 | 受注数 ÷ 商談数 | 25% |
| L4 | MQL数 | リード数 × MQL転換率 | 800件 |
| L4 | 商談化率 | SQL数 ÷ MQL数 | 50% |
| L5 | リード数 | セッション数 × CVR | 3,200件 |
| L5 | MQL転換率 | MQL数 ÷ リード数 | 25% |
| L6 | セッション数 | - | 160,000 |
| L6 | CVR | リード数 ÷ セッション数 | 2% |
この数値はあくまで構造を理解するための一例です。
ステップ4：KDI（行動指標）に落とし込む
最下層のKPIを達成するために、日常的に実行すべき行動レベルの指標を設定します。
| KPI（指標） | KDI（行動指標） | 目標 |
|---|---|---|
| セッション数 160,000 | ブログ記事の公開数 | 月8本 |
| セッション数 160,000 | SNS投稿数 | 週5回 |
| CVR 2% | LP改善テスト数 | 月2回 |
| MQL転換率 25% | ナーチャリングメール配信数 | 月4回 |
| 商談化率 50% | 営業への情報引き渡し回数 | 週次 |
KDIまで落ちて初めて、ツリーが週次の定例会で使えるものになります。逆にここが無いと、月末に「数字が足りませんでした」という報告だけが繰り返されることになってしまいます。
ステップ5：整合性を検証する
最後にツリー全体を検算します。確認したい観点は次の通りです。
| 検証観点 | 確認すること |
|---|---|
| 到達性 | 最下層のKDIをすべて達成した場合、計算上KGIに到達するか |
| 論理性 | 各階層の因果関係が実際の顧客の流れと一致しているか |
| 現実性 | 目標値が過去実績から乖離しすぎていないか |
| 網羅性 | 抜け漏れている重要な流入経路・指標はないか |
| 統制可能性 | マーケティングチームが行動で動かせる指標になっているか |
特に到達性の検算は、他の検証より優先して行うことをおすすめします。各階層をそれらしい数字で埋めた結果、全部達成してもKGIに届かないツリーになっている、ということが実際に起こります。
HubSpotでKPIツリーを実装する手順｜設定画面の場所つき
ツリーを紙の上で描き終えたら、次は各ノードをHubSpotのプロパティーとして定義します。ここでは、ステップ2の因数分解（セッション→リード→MQL→SQL→受注）をそのままCRMに写すときの手順を、設定画面の場所つきで整理します。メニュー名は画面の更新で変わることがあるため、各手順の公式ナレッジで最新の表示を確認してください。
- ツリーの各ノードに「定義書」を1行ずつ書く ── 指標名・計算式・計測元オブジェクト（コンタクト／取引）・条件（いつ・誰が判定するか）の4点を決めます。この4点が書けないノードは、まだKPIとして使えません。
- プロパティーを作る ── 画面上部の設定アイコン ＞ 左サイドバーの「プロパティー」で対象オブジェクトを選び、「プロパティーを作成」から追加します（公式: プロパティーの作成と編集）。既存プロパティーのフィールドタイプを後から「計算」に変えることはできないため、計算式で持たせたい指標は最初から計算プロパティーとして作ります。
- ライフサイクルステージを定義に合わせる ── 標準では「登録読者→リード→MQL→SQL→商談→顧客→エバンジェリスト」の順に並びます（公式: ライフサイクルステージの使用）。ツリーの「MQL数」「商談数（SQL）」は、このステージへの到達日を数える形にします。
- ステージの付与をワークフローで自動化する ── 「自動化」＞「ワークフロー」から作成し、登録トリガー（フィルターベース）と「プロパティー値の設定」アクションを組み合わせます（公式: ワークフローの作成）。ライフサイクルステージはデフォルトでは前方にしか進まない点に注意してください。
- 取引パイプラインのステージ設計を揃える ── 設定の「オブジェクト」から取引のパイプラインを開き、ステージ名・受注確度・ステージ移行時の必須入力を整えます。受注数・受注率・平均受注単価はここで決まります。
- レポートとダッシュボードに写す ── 1〜5で定義した指標を、カスタムレポートビルダーでツリーの上から下の順に並べます（公式: カスタムレポートの作成。カスタムレポートは約2時間ごとに自動更新されると案内されています）。
ツリーのノードをHubSpotのプロパティーに対応させる設計例
下表は、ステップ3の例（年間売上3億円のツリー）をHubSpotに写すときの設計例です。プロパティー名やステージ名は一例なので、自社の呼び方に置き換えてください。
| ツリーのノード | プロパティー・ステージの設計例 | よくある失敗と回避策 |
|---|---|---|
| MQL数 | コンタクトのライフサイクルステージ＝MQL。到達日（「MQLになった日」）で月別に集計 | 営業が手動でMQLに変更し判定基準が人ごとに違う。フォーム種別・リードスコアなどの条件をワークフローに書いて自動付与する |
| 商談化率 | ライフサイクルステージ＝SQL到達数 ÷ MQL到達数。取引は「商談化」ステージで作成 | MQLのまま取引だけ作られ、SQLの数が合わない。取引作成時にステージを揃えるワークフローを置く |
| 受注率 | 取引ステージ「受注」への到達数 ÷ 商談数。失注には「失注理由」プロパティーを必須化 | 失注理由が自由記述で集計できない。ドロップダウン（価格・時期・競合・要件不一致など）にする |
| 平均受注単価 | 取引の「金額」プロパティー。受注ステージ移行時に入力必須 | 金額が空欄のまま受注になる。受注ステージへの移行条件に「金額」と「クローズ日」を必須で入れる |
| セッション数・CVR | トラフィック分析の流入元別セッション、フォーム送信数 | フォームを複数のツールで運用し送信数が分散する。計測対象のフォームを1か所に集約する |
以下の画面は、取引パイプラインの件数と金額をステージ別に表示したHubSpotのレポートです。ツリーの下流（商談数・受注数・受注金額）を、手集計せずステージ定義から取れている状態の例です。
定義書を先に書くのが、やり直しを防ぐ最短の道です。プロパティーの内部名や取引パイプラインの構成は後から変えにくいため、決め方はHubSpotで後から変えにくい設定も参考にしてください。
自社の状況別｜どのノードから計測するかの判断表
| 自社の状況 | 最初に計測するノード | KGIの置き方 |
|---|---|---|
| 取引は管理しているが、リードの定義が曖昧 | 受注数・受注金額・平均受注単価（取引ステージ） | 年間売上（新規） |
| 取引ステージの運用は安定している | 商談数と受注率、続けてSQLの定義 | パイプライン金額 |
| MQL・SQLの定義が営業と合意済み | MQL数・商談化率（ライフサイクルステージ） | マーケティング起点のパイプライン金額 |
| 紹介・既存顧客からの受注が中心 | 商談供給数と既存顧客との接点数 | 商談供給数 |
StartLinkの進め方｜小さく始めて広げる
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わってきました。KPIツリーのCRM実装でも、いきなり全階層を作らず、次の5つの工程に分けて進めます。
- 現状の整理・要件定義 ── 経営会議で使われているKGIと、いまの集計方法・定義のズレを洗い出します。
- 設計・構築 ── 上の定義書をもとに、プロパティー・ライフサイクルステージ・取引パイプラインを設計します。
- データ移行 ── スプレッドシートや既存CRMの過去実績を取り込み、転換率の現状値をつくります。
- テスト・検証 ── ツリーの数字をCRMの値と突き合わせ、到達性（ステップ5）を検算します。
- 定着・運用改善 ── 週次・月次のレビューを回しながら、下流から上流へ範囲を広げます。
スモールスタートで始め、準委任で伴走する進め方です。標準機能で足りない部分は、自社開発の連携アプリ（Sync for freee・Sync for Notion）で埋められます。問い合わせの一次分類などには、HubSpotのAI（Breeze）やClaudeを業務設計に組み込む選択肢もあります。進め方の詳細はHubSpot導入・構築支援とHubSpot×AIのページ、運用設計は週次パイプラインレビューとデータ品質ダッシュボードの記事にまとめています。
KPIツリー設計テンプレート｜2つのパターン
ここでは、そのまま書き換えて使えるツリーの型を2つ示します。自社の事業構造に近い方を選び、枝の名前と数字を自社のものに置き換えてください。
テンプレート1：売上起点のKPIツリー（標準版）
年間売上 3億円
├── 受注数: 100件
│ ├── 商談数（SQL）: 400件
│ │ ├── MQL数: 800件
│ │ │ ├── リード数: 3,200件
│ │ │ │ ├── オーガニックセッション: 100,000
│ │ │ │ │ └── [KDI] 記事公開: 月8本
│ │ │ │ ├── 広告セッション: 40,000
│ │ │ │ │ └── [KDI] 広告予算: 月100万円
│ │ │ │ └── その他セッション: 20,000
│ │ │ │ └── [KDI] ウェビナー: 月1回
│ │ │ └── MQL転換率: 25%
│ │ │ └── [KDI] ナーチャリングメール: 月4回
│ │ └── 商談化率: 50%
│ │ └── [KDI] 営業連携MTG: 週1回
│ └── 受注率: 25%
│ └── [KDI] 提案品質改善: 月次レビュー
└── 平均受注単価: 300万円
└── [KDI] 上位プランの訴求: 営業資料更新マーケティングが受注まで責任を持つ組織、あるいは単一プロダクトで新規獲得が中心の事業に向いた型です。
テンプレート2：パイプライン起点のKPIツリー
パイプライン金額 10億円
├── 新規パイプライン: 7億円
│ ├── マーケ起点: 5億円
│ │ ├── MQL数 × 平均商談単価 × 商談化率
│ │ └── [KPI] マーケ起点商談数: 200件
│ └── 営業起点: 2億円
│ └── [KPI] 営業起点商談数: 80件
└── 既存パイプライン（拡大）: 3億円
├── アップセル: 2億円
└── クロスセル: 1億円受注までのリードタイムが長く、年度内の売上だけでは成果を測りきれない事業に向いた型です。既存顧客からのアップセル・クロスセルが収益の柱になっている場合も、こちらの方が実態に合います。
2つのテンプレートの使い分け
| 観点 | テンプレート1（売上起点） | テンプレート2（パイプライン起点） |
|---|---|---|
| 向く事業 | リードタイムが短く新規中心 | リードタイムが長い／既存拡大が柱 |
| 主担当 | マーケ＋営業の共通目標として | マーケの供給責任を明確にしたい場合 |
| 成果の見え方 | 当期の売上で評価 | 将来の受注見込み（加重金額）で評価 |
| 注意点 | 受注時期のズレで評価が歪む | パイプラインの質を別途見る必要あり |
ただし、どちらか一方に決め切る必要はありません。経営報告は売上起点、マーケティング部門の週次運用はパイプライン起点、という二層構成にしている組織もあります。
まずは片方で走らせて、運用が回ってから増やす進め方をおすすめします。
KPIツリーを運用に載せる｜レバレッジポイントとレビュー設計
作ったツリーが半年後も使われているかどうかは、運用設計で決まります。ここでは「どこを改善するか」の判断と、「どの頻度で見直すか」の設計を扱います。
レバレッジポイントを見つける
ツリーの中で、改善したときのKGIへのインパクトが最も大きい箇所を特定し、そこにリソースを集中させます。方法はシンプルで、各KPIを10%改善した場合のKGI変動を計算して並べます。
| 改善対象 | 改善幅 | KGI（売上）への影響 |
|---|---|---|
| セッション数 +10% | 160,000 → 176,000 | +3,000万円 |
| CVR +0.2%（10%改善） | 2.0% → 2.2% | +3,000万円 |
| MQL転換率 +2.5%（10%改善） | 25% → 27.5% | +3,000万円 |
| 商談化率 +5%（10%改善） | 50% → 55% | +3,000万円 |
| 受注率 +2.5%（10%改善） | 25% → 27.5% | +3,000万円 |
| 平均受注単価 +30万円（10%改善） | 300万 → 330万 | +3,000万円 |
掛け算で連なるツリーでは、どの指標を10%改善しても理論上のインパクトは同額になります。これは一見あたり前の結果に見えますが、実務的には重要な示唆を含んでいます。
つまり優先順位を決める材料は「インパクトの大きさ」ではなく、次の2つだということです。
- 現状値と目標値のギャップの大きさ
- 改善の実現可能性
セッション数を10%増やすのに半年かかる一方、商談化率は営業との引き渡し基準を揃えるだけで1か月で動くかもしれません。
同じインパクトなら、速く動く方から手をつけるのが合理的な判断になります。
レビューの頻度を階層に合わせる
| 頻度 | レビュー内容 |
|---|---|
| 週次 | KDI（行動指標）の進捗確認 |
| 月次 | KPIの実績確認、ボトルネック特定 |
| 四半期 | KPIツリー全体の構造見直し |
| 年次 | KGIの妥当性検証、ツリーの再設計 |
ポイントは、階層ごとに見る頻度を変えることです。
- 週次の会議でKGIを眺める場合 ── 数字はほとんど動きません。
- 年に一度しかKDIを確認しない場合 ── 行動指標を置く意味がありません。
下の階層ほど高頻度、上の階層ほど低頻度という原則で組むと、会議の時間配分が自然に整います。
シンプルさを保ち、全員に共有する
KPIツリーが複雑になりすぎると、誰も見なくなります。
- 階層 ── 最大5〜6段階が目安です。
- 各階層のKPI ── 3〜5個に絞るのが目安です。
そして作ったツリーは、マーケティングチームだけでなく営業チームや経営層とも共有してください。全員が同じ全体像を理解していることが、部門間連携の前提条件になってきます。
よくある設計ミス4つと、その直し方
KPIツリーは形だけなら1時間で作れますが、使えるものにするには落とし穴を避ける必要があります。実際のご支援でよく見かけるパターンを4つ挙げます。
ミス1：KPIが相互に独立していない
あるKPIを改善すると別のKPIが悪化する関係にある場合、ツリーの計算が狂います。典型はリード数とMQL転換率です。
- 関係 ── 広告を広げてリード数を増やすとリードの質が下がり、MQL転換率が落ちます。
- 結果 ── リード数だけを追いかけると分母が増えて率が下がり、MQL数は思ったほど増えません。
相互に影響する指標のペアにはツリー上で注記を入れ、レビュー時はセットで見るようにしてください。
ミス2：コントロールできない指標を入れている
「市場規模」「景気動向」など、自社のアクションでは動かせない指標をKPIに置いても、達成・未達の議論が他責になるだけです。チームが行動で改善できる指標に限定しましょう。
外部環境は前提条件として別枠に書き出し、大きく変わったときにツリーそのものを見直すトリガーとして扱う方が建設的です。
ミス3：因数分解が数学的に正しくない
掛け算の関係と足し算の関係を正しく区別することが、地味ですが最も重要です。
| 関係 | 例 | 意味 |
|---|---|---|
| 掛け算 | 売上 = 受注数 × 単価 | 片方が0なら結果も0。どちらも同じ比率で効く |
| 足し算 | リード数 = オーガニック + 広告 + その他 | 各項目は独立。構成比の議論になる |
チャネル別の合算を掛け算の枝に混ぜてしまうと、10%改善のシミュレーションがまったく合わなくなります。ツリーを描いたら、上から下まで実際に電卓で検算してみてください。
ミス4：KDIがない（行動に落ちていない）
KPIだけあってもKDIがなければ、現場は何をすればいいか分かりません。最下層にはKDIを設定するようにしてください。
そしてKDIは「担当者が自分の意思だけで実行できる粒度」まで下ろすのがコツです。
- KDIではない例 ── 「CVRを上げる」
- KDIである例 ── 「LPのファーストビュー改善テストを月2回実施する」
スプレッドシート管理の限界と、CRMへの載せ替え
多くの組織で、KPIツリーは最初スプレッドシートで作られます。設計段階ではそれで十分ですし、むしろ自由に構造をいじれる分やりやすいのですが、運用フェーズに入ると別の問題が出てきます。
なぜスプレッドシート運用は続かないのか
スプレッドシートでのKPI管理には、構造的な弱点があります。
| 課題 | 何が起きるか |
|---|---|
| 手動転記の工数 | 集計だけで数時間かかり、月末に作業が集中する |
| 更新の属人化 | 担当者が不在・異動になると更新が止まる |
| 数字の鮮度 | 見る時点で1か月前の数字しかなく、打ち手が遅れる |
| 定義のズレ | MQLの定義が人によって違い、月ごとに数字の意味が変わる |
特に深刻なのは最後の定義のズレです。スプレッドシートには「MQL数：800」としか書かれないため、その800がどういう条件で数えられたのかが残りません。これは個人の丁寧さの問題ではなく、記録の仕組みの問題です。人の頑張りに依存する運用は、担当者が変わった瞬間に途切れます。
CRM上でツリーの各指標を定義する
解決の方向は、ツリーの各ノードを人が集計する数字ではなく、CRMが自動で持つ数字にしていくことです。HubSpotを例にすると、次のような対応関係になります。
| ツリーの階層 | HubSpot上のデータ | 定義する場所 |
|---|---|---|
| セッション数・CVR | トラフィック分析・フォーム送信 | トラッキングコードとフォーム |
| リード数・MQL数 | コンタクトのライフサイクルステージ | ステージ定義とワークフロー |
| 商談数（SQL） | 取引オブジェクトの生成 | パイプラインのステージ設計 |
| 受注率・受注数 | 取引ステージ「受注」への到達 | ステージ定義と必須プロパティ |
| 平均受注単価 | 取引の金額プロパティ | 入力必須化のルール |
ここで効いてくるのが、ライフサイクルステージとパイプラインの設計です。MQL・SQLを人の判断ではなくワークフローで自動的に付与する形にすれば、定義が全社で一つに揃います。
取引ステージの設計では、ステージ自体に加えて受注確度（角度）、各ステージの定義、ステージ移行時の必須入力プロパティの4点をセットで整えると、平均受注単価や受注率といった下流のKPIが日々正確な値のまま積み上がるようになります。
つまりKPIツリーの精度は、ツリーの美しさではなく、その手前にあるデータ設計で決まってくるということです。
こうしたステージ定義や必須プロパティをCRM側にルールとして持たせておけば、担当者が代わっても、あるいは新しいメンバーが加わっても、同じ基準で数字が積み上がる仕組みになります。
- 一次分類 ── フォーム送信時の問い合わせ内容を「営業対応が必要な商談か、通常の問い合わせか」に振り分けるような分類には、AIを組み合わせる余地もあります。
- 人が判断する部分 ── MQL・SQLの定義そのものや、ライフサイクルステージの設計自体は、事業の理解が必要な領域なので人が判断すべき部分だと考えています。
以下の画面は、HubSpotのレポートでリード獲得数を目標対比で月次表示したものです。リード数・MQL数といったツリー中段の指標を、手集計せずそのまま追える状態にしたイメージになります。
ダッシュボードでツリーを再現する
各指標がCRM上で定義できたら、それらをダッシュボードに並べ、ツリーの上から下への順序で配置します。
- 上段 ── KGI（売上・パイプライン金額）
- 中段 ── KPI（商談数・MQL数・リード数と各転換率）
- 下段 ── KDI相当の活動量
この並び順にしておくと、上から目で追うだけでどの階層で詰まっているかが分かるようになります。
以下の画面は、HubSpotのレポートをテーブル形式で一覧化した例です。グラフだけでなく数値テーブルも併置しておくと、会議中に実数を確認したいときに話が止まりません。
目標値の設定と進捗トラッキングについては「HubSpot目標（Goals）機能の設定方法｜営業・マーケ・CSのKPI目標管理と進捗トラッキング」で詳しく解説しています。
いきなり全階層の自動化は目指さない
ツリーの全ノードをCRM上で自動計測できる状態にするには、ライフサイクルステージの定義、パイプラインのステージ設計、必須プロパティの整備、ワークフローの構築まで一通り必要になります。
現実的な進め方は、最も把握しやすい下流の数字から始めることです。
- 受注まわりの数字を取る ── まずは取引オブジェクトで受注数・受注金額・平均受注単価を正確に取ります。
- 商談数と受注率を取る ── 次に取引ステージを整えて商談数と受注率を取ります。
- 上流へ広げる ── そこまで固まってから、ライフサイクルステージを設計してMQL数・商談化率に手を伸ばします。
この順番なら、各段階で「前より見える状態」になるため、途中で止まっても無駄になりません。
なお、こうしたリレーションデータベース型のKPI管理はHubSpotに限った話ではなく、コンタクト・取引・顧客が紐づく構造を持つCRMであれば同様に実現できます。既にご利用の基盤がある場合は、乗り換えを前提にせず、今の基盤でどこまで取れるかを確認するところから始めるのが現実的です。
KPIツリーが向かないケース
最後に、KPIツリーが有効に機能しにくい場面も率直にお伝えします。万能のフレームワークではありません。
- 立ち上げ初期 ── データの蓄積が無く、数字が希望的観測になります。
- 個別のリレーション中心の事業 ── 受注経路が営業の個別リレーション中心で、セッション数やCVRからの積み上げが実態を説明しません。
- 複数事業・複数商材の混在 ── 分けられていないと、平均値が実態を表さなくなります。
データの蓄積が無い立ち上げ初期
転換率の実績が一つも無い状態でツリーを組むと、すべての数字が希望的観測になります。この段階では精緻なツリーより、受注件数と商談件数という2つの実数を毎週記録することの方が価値があります。
受注経路が営業の個別リレーション中心の事業
紹介・既存顧客からの声かけ・経営層同士のつながりが受注の大半を占める事業では、セッション数やCVRから積み上げるツリーは実態を説明しません。この場合は、マーケティングのツリーを無理に売上に直結させず、「商談供給数」や「既存顧客の接点数」をKGIに置き換える方が機能します。
複数事業・複数商材が混在していて分けられていない場合
単価も購買プロセスも違う商材を1本のツリーに混ぜると、平均値が実態を表さなくなります。
- 事業・商材ごとにツリーを分ける ── これが先です。
- それが難しい場合 ── 主力事業1本に絞ってツリーを作り、他は当面ツリー外で管理する判断もあり得ます。
よくある質問
Q1. KPIとKDIは何が違いますか？
KPIは成果を測る指標、KDIは日々の行動量を測る指標です。たとえば「セッション数160,000」「CVR2%」がKPIなら、それを実現するための「ブログ記事の公開数 月8本」「LP改善テスト 月2回」「ナーチャリングメール配信 月4回」がKDIにあたります。KPIだけを並べても現場は何をすればよいか分からないため、KPIツリーではKGI・KSF・KPI・KDIの4階層で行動レベルまで落とし込みます。
Q2. KGIはどのように因数分解すればよいですか？
掛け算の関係でファネルの最下層まで分解します。具体的には「年間売上＝受注数×平均受注単価」「受注数＝商談数×受注率」「商談数＝MQL数×商談化率」「MQL数＝リード数×MQL転換率」「リード数＝セッション数×CVR」という連鎖です。注意点は掛け算と足し算の区別で、リード数＝オーガニック＋広告＋その他のようなチャネル別の合算は足し算になります。ここを誤るとツリー全体の計算が狂います。
Q3. どのKPIから改善すべきかはどう判断しますか？
各KPIを10%改善した場合のKGI変動を計算して比較します。ただし掛け算で連なるツリーでは、セッション数・CVR・MQL転換率・商談化率・受注率・平均受注単価のどれを10%改善しても、理論上のKGIインパクトは同額になります。したがって最終的な優先順位は、現状値と目標値のギャップの大きさと、改善の実現可能性で判断することになります。同じインパクトなら、短期間で動かせる指標から着手する方が合理的です。
Q4. KPIツリーはどのくらいの頻度で見直すべきですか？
週次でKDI（行動指標）の進捗、月次でKPIの実績とボトルネック特定、四半期でツリー全体の構造見直し、年次でKGIの妥当性検証という4段階が目安です。あわせて注意したいのが複雑化で、階層は最大5〜6段階、各階層のKPIは3〜5個に絞らないと誰も見なくなります。市場規模や景気動向のような自社でコントロールできない指標はKPIに含めません。
Q5. スプレッドシートのままKPIツリーを運用してはいけませんか？
設計段階ではスプレッドシートが最も扱いやすいので、まずはそこから始めていただいて問題ありません。課題が出てくるのは運用フェーズで、毎月の手集計による工数、担当者交代での更新停止、数字の鮮度低下、指標定義のズレといった形で表れます。月次の集計作業が負担になってきたタイミングが、CRMのダッシュボードへ載せ替える検討の目安になります。
Q6. KPIツリーをHubSpotで運用するには、まず何を設定すればよいですか？
設定アイコン＞「プロパティー」でツリーの各指標に対応するプロパティーを作り、ライフサイクルステージ（リード→MQL→SQL→商談→顧客）と取引パイプラインのステージ定義を揃えます。MQLやSQLの付与は「自動化」＞「ワークフロー」で条件を書いて自動化し、最後にカスタムレポートとダッシュボードへ上から下の順に並べます。最初は受注数・受注金額・平均受注単価の下流から始めるのが現実的です。
まとめ
KPIツリーは、KGI（売上目標）を達成するために「何を、どれだけ改善すべきか」を構造で示すフレームワークです。
KGIの因数分解 → 各階層のKPI設定 → KDI（行動指標）への落とし込みという手順で設計し、レバレッジポイントの特定と階層別のレビューサイクルで運用します。
本記事の要点を整理します。
- 設計の肝は、因数分解が数学的に正しいこと（掛け算と足し算の区別）、コントロール可能な指標に限定すること、階層5〜6段・各階層3〜5個までのシンプルさを保つことの3点です
- 10%改善シミュレーションでは掛け算の指標はどれも同じインパクトになるため、優先順位はギャップの大きさと実現可能性で決めます
- ツリーが形骸化する最大の原因は手集計による更新停止です。指標の定義をCRM側（ライフサイクルステージ・取引ステージ・必須プロパティ）に持たせ、人が変わっても回る仕組みにすることが長続きの条件になります
- 立ち上げ初期・リレーション中心の事業・複数商材が混在する場合は、精緻なツリーより実数の記録や対象の絞り込みを優先した方が機能します
次の3ステップが最初の一歩になります。
- KGIを1つだけ決める — 売上か、パイプライン金額か、商談供給数か。マーケティング部門の責任範囲に合うものを1つ選びます
- 過去実績から転換率を算出する — 受注率・商談化率・MQL転換率を実績ベースで出し、仮の目標値ではなく現状値をツリーに書き込みます
- 下流の指標から可視化する — 受注数・受注金額など確実性の高い数字をダッシュボードに置き、そこから上流へ順に広げていきます
ここまで進めてから、階層を増やすか、自動化の範囲を広げるかを判断すれば十分です。企業様によって最適なツリーの形は異なりますので、テンプレートはあくまで出発点として、自社のカスタマージャーニーに合わせて組み替えて使ってください。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
- CMO（最高マーケティング責任者）とは？役割・スキル・日本企業で広がらない理由
- マーケティングと営業の連携を強化する方法｜SLA設計からツール活用まで
- データドリブンマーケティングとは？BtoB企業の実践5ステップと成功事例
- マーケティングダッシュボードの作り方
- BtoBマーケティングのKPI設計ガイド｜フェーズ別の具体例と管理テンプレート
- HubSpot定着の運用設計｜週次パイプラインレビューとデータ品質ダッシュボードの作り方
このテーマに関連する記事はマーケティング組織・KPIカテゴリで網羅的にまとめています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
