初期プロダクトの KPI 設計：作る前に決めるべき数字
作ってから測るのではなく、測るために作る。
この記事の結論
- 初期プロダクトでは、開発前に検証仮説と KPI を決める ことで、作るべき機能とログ設計が明確になります。
- 重要なのは、「これがどうなれば事業として成立か」を Yes / No か数値で判定できるレベルまで具体化 することです。
- toB と toC で見るべき KPI は違いますが、アクティベーション、継続、価値創出、機能利用、課題シグナル の 5 カテゴリは共通です。
- KPI が決まると、ログ設計、画面設計、データモデルが自動的に決まります。逆も真で、KPI が決まっていないと、必要なログが取れず、後から振り返れません。
- 「リリースしてから KPI を考える」は、リリース初日からのデータを永久に失う判断です。
「MVP を作ってリリースしたんですが、何を測ったらいいか分からなくて」
リリース直後のスタートアップから聞く相談です。リリースは速かった。でも、ユーザーがどう使っているか、事業として伸びているかを判断する材料がない。
これは、KPI を決める前にリリースしてしまった 結果です。リリース後に「Day 30 Retention を見たい」と思っても、ユーザーごとの操作履歴を残していなければ、過去 30 日のデータは取れません。KPI は、作る前に決めておくのが原則 です。
この記事では、初期プロダクトの KPI 設計を、検証仮説からログ設計、画面設計まで連動させる形で整理します。
なぜ作る前に KPI を決めるのか
開発前に KPI を決めるべき理由は 4 つあります。
1. 必要なログ設計が決まる
「Day 30 Retention を測りたい」と言った瞬間、ユーザー単位の操作履歴を残す必要があると分かります。逆にこれを決めずに作ると、後から過去データが取れません。
2. 必要な機能が決まる
「課金転換率を測りたい」なら、無料 → 有料の動線と課金画面が必要です。「業務削減時間を測りたい」なら、業務開始時刻と終了時刻のログが必要。KPI が決まれば、機能が自動的に決まります。
3. 「やらないこと」が決まる
KPI を決めると、それに直接効かない機能は後回しにできます。スコープ膨張の防止につながります。
4. 投資家・社内への説明材料になる
「何で成功と判断するか」が決まっていると、進捗報告がしやすくなります。資金調達時にも、KPI ベースで説得力が出ます。
Anthropic の創業者向けプレイブックでも、AI ネイティブ・スタートアップは Launch 段階で PMF を初期の盛り上がりと区別する測定フレームワーク を持つことの重要性が示されています (The founder's playbook / Anthropic)。事業を測れる状態にしておくのは、AI で速く作れる時代でも変わらない前提です。
初期プロダクトで見るべき KPI
toB SaaS と toC サービスで KPI は変わりますが、5 つのカテゴリは共通です。
1. アクティベーション
「新規ユーザーが、最初の主要操作を完了したか」
- toB: 招待した会社のうち、最初の予約 / 申込み / レコード作成を完了した社数
- toC: 初回登録から、主要アクション (検索、購入、投稿など) までの完了率
2. 継続利用
「7 日後、30 日後に戻ってきたか」
- toB: 7 日後、30 日後にログインしている会社の割合
- toC: Day 7 / Day 30 Retention
3. 価値創出
「ユーザーが事業価値を得ているか」
- toB: 業務削減時間、利用部門数、担当者の継続率
- toC: 主要価値指標 (購入金額、投稿数、視聴時間など)
4. 機能利用
「どの機能が、どれだけ使われているか」
- toB: 機能別の利用社数、利用回数、利用時間
- toC: 機能別のアクティブ率
5. 課題シグナル
「どこで詰まっているか」
- toB: 問い合わせの種類別件数、解約理由
- toC: 離脱ポイント、解約理由、不満コメント
toB と toC の KPI 例
具体的な KPI 例を、toB / toC で比較します。
toB SaaS
| KPI | 目標例 | 計測方法 |
|---|---|---|
| 招待 → アクティベーション率 | 50% | 招待した会社数 / 主要操作完了社数 |
| 7 日継続率 | 70% | 招待から 7 日後にログインしている割合 |
| 30 日継続率 | 50% | 招待から 30 日後にログインしている割合 |
| 課金転換率 | 20% | 無料 → 有料の転換率 |
| MRR | 100 万円 / 3 ヶ月後 | 月間定期収入 |
| 業務削減時間 | 月 10 時間 / 社 | ヒアリングベース |
toC サービス
| KPI | 目標例 | 計測方法 |
|---|---|---|
| Activation 完了率 | 40% | 登録 → 主要アクション完了 |
| Day 7 Retention | 25% | 7 日後にログインしている割合 |
| Day 30 Retention | 10% | 30 日後にログインしている割合 |
| Referral Rate | 1.2 | 既存ユーザーが連れてくる新規数 |
| LTV / CAC | 3 倍以上 | 顧客生涯価値 / 獲得コスト |
数値はあくまで目安です。事業特性によって変わるので、「事業として成立する最低ライン」 を社内で議論して決めます。
ここまでで「自社の KPI 設計が必要」と感じたら、構想段階から相談するのが現実的です。
ログ設計とイベント設計
KPI を計測するためのログ設計は、イベントベース で考えます。
イベントの基本構造
type Event = {
user_id: string
tenant_id: string
event_name: string // 'login', 'create_booking', 'pay_success' など
timestamp: Date
properties: {
// イベント固有のデータ
}
}
KPI に必要な最小限のイベント
| KPI | 必要なイベント |
|---|---|
| アクティベーション率 | signup, first_main_action |
| 7 日継続率 | login (タイムスタンプ付き) |
| 機能利用分布 | 各機能の feature_used |
| 課金転換率 | signup, subscription_start, payment_success |
| 離脱ポイント | 主要ページの page_view + funnel_step |
これらを リリース日から記録 するのが鉄則です。リリース後に追加すると、過去データが取れません。
計測ツール
- Mixpanel: イベントベース分析、ファネル、Cohort 分析が得意
- PostHog: オープンソース、Self-host 可、フィーチャーフラグ機能あり
- Amplitude: 大規模対応、エンタープライズ向け
- Google Analytics 4: 無料、Web 中心
- 自前 (PostgreSQL + Metabase): カスタマイズ可、エクスポート簡単
MVP 段階なら、PostHog または Mixpanel の無料枠で十分です。
OpenAI のワークスペースエージェントの設計でも、利用状況の 監視・分析 がエージェント運用の前提に組み込まれています (Introducing workspace agents in ChatGPT / OpenAI)。プロダクトの利用ログも同じ位置づけで、運用の前提です。
KPI から機能を逆算する
KPI が決まると、「KPI を測れる状態にする」ために必要な機能 が決まります。
例: 業務 SaaS の場合
KPI: 利用 30 日後の継続率 50%、業務削減時間 月 10 時間 / 社
必要な機能:
- ユーザー登録、ログイン (
signup,loginを記録) - 主要操作 (
feature_usedで記録) - 業務開始・終了の打刻 (削減時間計測のため)
- 月次レポート画面 (顧客向けに削減時間を見せる)
必要なログ:
- 全イベントにタイムスタンプ
- 業務開始・終了のペアで残す
- 月次集計用の
monthly_summaryバッチ
このように、KPI が決まれば、機能とログが連動して決まる のが理想です。逆に、KPI を決めずに機能を作ると、後から「あの数字を出すには、この機能が足りない」が発覚します。
初期 KPI 設計チェックリスト
開発前に確認するチェックリストです。
| 項目 | 確認すること |
|---|---|
| 検証仮説 | Yes / No か数値で判定できる |
| 成功条件 | 何の数字が、どこに達したら成功か |
| アクティベーション | 何をもって「使い始めた」と判定するか |
| 継続指標 | 7 日 / 30 日 / 90 日のどれを見るか |
| 価値指標 | 削減時間、購入金額など |
| 課題シグナル | 何が起きたら警戒するか |
| 計測ツール | Mixpanel / PostHog / 自前 |
| イベント設計 | 主要イベントの一覧 |
| データ保存期間 | どれくらい遡って分析できるか |
| 振り返りサイクル | 週次 / 月次のいつ見るか |
これが揃った状態で開発に入ると、リリース後の改善が大きく速くなります。
定量だけでなく定性も入れる
KPI 計測は定量だけでなく、定性的なフィードバック も組み合わせます。
- ユーザーヒアリング (週 1〜2 件)
- アンケート (NPS、満足度、要望)
- 解約理由のヒアリング
- サポートチケットの分類
定量で「どこで詰まっているか」が見え、定性で「なぜ詰まっているか」が見えます。両方を合わせて、改善優先順位が決まります。
min's の KPI 設計支援
min's では、MVP / 本番開発時に、KPI 設計を以下の形で支援しています。
Phase 1: KPI 設計 (1〜2 週間)
- 検証仮説と成功条件の整理
- 必要な KPI とイベントの一覧化
- 計測ツールの選定
Phase 2: ログ設計
- イベント定義書の作成
- データモデルへの反映
- ダッシュボードの初期設計
Phase 3: 実装
- イベントトラッキングの組み込み
- KPI ダッシュボードの構築 (Metabase / Looker Studio)
- 週次レビューの仕組み化
Phase 4: 振り返り並走
- 週次 / 月次の KPI レビュー
- 改善優先順位の整理
- 次の打ち手の決定
費用感は、設計のみで 30〜80 万円、実装込みで 100〜300 万円が典型的です。
KPI 設計について相談したい方へ
min's では、MVP / 新規事業プロダクトの KPI 設計、ログ設計、ダッシュボード構築、振り返り並走を支援しています。
以下のような状態であれば、ご相談ください。
-
リリース前に KPI を設計したい
-
既にリリースしたが、何を測ったらいいか分からない
-
ログ設計とイベントトラッキングを組み直したい
-
KPI レビューの運用を作りたい
次に読む記事
参考
- The founder's playbook / Anthropic — PMF を初期の盛り上がりと区別する測定フレームワーク
- Introducing workspace agents in ChatGPT / OpenAI — エージェント運用での監視・分析の前提