SaaS事業のデータ基盤設計――PLG時代のプロダクトアナリティクス基盤

SaaSは、他のどの業態よりも「データ活用が事業運営そのもの」となるビジネスモデルです。MRR・Churn・LTVといったメトリクスが投資家との対話の言語であり、プロダクト内の行動データはそのまま機能改善とカスタマーサクセスに直結します。特にPLG(Product-Led Growth)モデルでは、プロダクトアナリティクスが営業・マーケ・CSの共通OSとなり、データ基盤の質がそのまま事業成長の天井を決めます。本記事では、SaaS事業のデータ基盤設計を3つの軸――SaaSメトリクスのモデリング、プロダクトアナリティクス基盤、マルチテナント設計――から具体的に整理します。

SaaS事業におけるデータ基盤の重要性

SaaSビジネスにおけるデータ基盤の役割は、単なる経営レポート作成ツールではありません。MRRやARRの自動計算、解約予兆の検知、トライアルから有償転換までのファネル最適化、機能利用状況に基づくアップセル提案まで、事業運営の全方面にデータが組み込まれます。これらを手作業で集計していては、事業の成長速度に人手が追いつきません。

特にPLGモデルのSaaSでは、プロダクト利用状況の可視化がカスタマーサクセスの生命線です。営業が接点を持たずにプロダクトだけで顧客を獲得・拡大するモデルでは、「誰がどの機能をどれくらい使っているか」をリアルタイムに把握できなければ、Churnや失注を防げません。従来の手動QBR(Quarterly Business Review)では間に合わない時代に、データ基盤が担う役割は決定的に大きくなっています。また、投資家との定期的なコミュニケーションでも、MRRや純収益維持率(NRR)といった数字を即時に出せるかどうかで資金調達の信頼度が変わります。

SaaSメトリクスのデータモデリング

SaaS事業でまず整備すべきは、MRR・Churn・LTVの3大メトリクスを自動計算するデータマートです。これらは定義が一見シンプルに見えますが、新規・アップセル・ダウンセル・解約・プロレーション(日割り)を全て考慮すると、想像以上に複雑な計算ロジックが必要になります。

メトリクス	定義	活用場面
MRR	月次経常収益(月額換算の継続収益)	成長スピードの把握、投資家レポート
New MRR	当月新規顧客から得たMRR	獲得施策の評価
Expansion MRR	既存顧客のアップセル・シート増加分	カスタマーサクセスの成果
Churn MRR	解約によって失ったMRR	Churn対策の効果測定
Net New MRR	New + Expansion – Churn	実質成長の判定
Logo Churn Rate	顧客数ベースの解約率	中小顧客の健全性
Revenue Churn Rate	金額ベースの解約率	大型顧客の健全性
LTV	顧客生涯価値	CAC許容上限の設定
NRR	純収益維持率	Expansionの強さの指標

これらを一つのSQLで計算する際、サブスクリプションの状態遷移(アクティブ、解約、プロレーションなど)を時系列で展開するロジックが鍵になります。以下はシンプルなMRR計算SQLの骨格です。

-- 月次MRR計算
SELECT
  DATE_TRUNC(usage_month, MONTH) AS month,
  SUM(IF(is_new, mrr_amount, 0))        AS new_mrr,
  SUM(IF(is_expansion, delta_mrr, 0))   AS expansion_mrr,
  SUM(IF(is_churn, -prev_mrr, 0))       AS churn_mrr,
  SUM(mrr_amount)                        AS total_mrr
FROM mart.subscription_monthly
GROUP BY month
ORDER BY month;

このSQLが成立する前提として、subscription_monthly テーブルには「顧客×月」単位で、その月のMRR額、前月比の差分、新規/解約フラグが格納されている必要があります。この「顧客月次スナップショット」こそがSaaSデータモデリングの心臓部です。メトリクスの定義は会計と整合する必要があるため、ファイナンスチームとの合意を取り付けてから実装することが重要です。データモデリングとELT vs ETLの考え方も併せて参考にしてください。

プロダクトアナリティクス基盤の設計

プロダクトアナリティクスは、ユーザーがプロダクト内でどの機能をどう使っているかを分析する領域です。SaaSでは機能の利用深度がChurnやExpansionの先行指標となるため、イベントトラッキング基盤の設計は最優先事項となります。全体構成を図で示します。

【プロダクトアナリティクス基盤】

[Webアプリ]   [モバイルアプリ]   [バックエンドAPI]
    |               |                    |
    v               v                    v
  +------------------------------------------+
  |   イベント収集SDK(Segment等)           |
  +--------------------+---------------------+
                       |
                       v
         +---------------------------+
         |  イベントルーター          |
         +------+----------+---------+
                |          |
                v          v
        [BigQuery]    [Amplitude等]
        生イベント     ツール型PA
                |          |
                v          v
         +---------------------------+
         |  dbtモデリング層           |
         | (user, session, feature)  |
         +------+-------------+------+
                |             |
                v             v
         [Looker/Metabase]  [Reverse ETL]
         PAダッシュボード   CRM/CS連携

※ 生イベントはDWHに保存し、ツール型PAは用途限定で併用する。

この構成の要点は、生イベントを必ずDWH(BigQueryやSnowflake)に保存することです。初期はMixpanelやAmplitudeなどのツール型プロダクトアナリティクスで素早く分析を始められますが、スケール時には自社でメトリクスを計算する柔軟性が必要になります。両方に同じイベントを送り、段階的にDWH側の比重を上げていくハイブリッド運用が現実的です。dbtによる変換層では、イベントログを「ユーザー×日次×機能」単位の集計テーブルに変換し、BIツールやML基盤で使いやすい形に整えておきます。ダッシュボード層はLookerなどLookMLベースのBIが相性良く、複雑な指標を一元管理できます。

マルチテナントデータの取り扱い

SaaSプロダクトのバックエンドDBは、ほとんどの場合マルチテナント構造になっています。データ基盤側でもテナント(顧客企業)ごとのデータを正しく分離する設計が必要です。主な分離方式は3つあり、それぞれトレードオフが異なります。

方式	概要	メリット	デメリット
論理分離(tenant_id列)	全レコードにtenant_id列を付与	コスト低、実装容易	クエリミスでデータ漏洩リスク
スキーマ分離	テナントごとにスキーマを分ける	クエリ単位で独立	テナント数が多いと運用負荷
物理分離(DB/プロジェクト別)	テナントごとに完全に別DB	セキュリティ最高	コストと複雑さが急増

SaaS事業のデータ基盤では、論理分離(tenant_id列)が最も一般的です。この場合、行レベルセキュリティ(RLS)を併用し、分析者のロールごとに「自社のテナントしか見えない」制御を入れることで、データ漏洩リスクを抑えます。BigQueryやSnowflakeでは行レベルセキュリティポリシーがネイティブ機能として提供されているので、これを積極的に使うのが定石です。

一方、医療SaaSや金融SaaSのように規制要件が厳しい領域では、スキーマ分離や物理分離を選ぶ必要があります。その場合はデータ基盤のコストと運用負荷が数倍に跳ね上がるため、セキュリティと経済性のトレードオフを事業要件と照らし合わせて決めてください。マルチテナントの詳細設計はパイプライン設計パターンでも補足しています。

PLG(Product-Led Growth)を支えるデータ活用

PLGモデルのSaaSでは、プロダクト内行動データが営業・CSの「情報源」そのものとなります。代表的な活用パターンは「PQL(Product Qualified Lead)」の自動検出です。トライアルユーザーのうち、特定の機能を一定回数以上使ったユーザーを自動でPQLとしてフラグ立てし、営業チームに通知する仕組みを作ります。

同様に、既存顧客のExpansion予兆やChurn予兆もプロダクト利用データから検知できます。利用頻度の低下、特定機能の未利用、管理者ログインの途絶などが予兆指標です。これらをスコア化して日次でCRMにReverse ETLで同期することで、CSチームが先回りしてフォローできる体制が整います。スコアリングロジックはシンプルなルールベースから始め、データが蓄積してきたら機械学習モデルに移行するのが現実的な進め方です。PLGを実現する際の最大のポイントは、営業・マーケ・CS・プロダクトのチームが同じデータを見て同じ言語で議論できる状態を作ることで、データ基盤はそのための共通OSとなります。

SaaS特有の課題と対策

SaaSのデータ基盤運用では、いくつか特有の落とし穴があります。第一に「指標の二重定義問題」です。MRRの定義が財務チームとプロダクトチームで微妙に違い、会議で数字が合わず混乱するケースがよくあります。対策は、dbtでの変換層で一元的にメトリクスを定義し、全てのBIがそれを参照する運用です。

第二に「トライアルと有償の境界の曖昧さ」です。プロダクトアナリティクスでMAUを見るとき、トライアル・無料・有償をどう区別してカウントするかは早めに定義しないと、後から全社の数字がブレます。第三に「テナント規模のばらつき」です。従業員1万人のエンタープライズ顧客と、個人事業主の顧客が同じテーブルに混在するため、平均値を見ても意味がないことが多く、セグメント別の分析が不可欠になります。これらの課題は、いずれもデータモデリング段階で明確な定義を置いておくことで予防可能です。

まとめ

SaaSのデータ基盤は、MRR/Churn/LTVの自動計算、プロダクトアナリティクス基盤、マルチテナント設計の3つを柱に据えるのが王道です。生イベントを必ずDWHに保存し、dbtで統一的に変換し、Reverse ETLでCRM/CSに還流させる流れを作れば、PLGモデルでも成長を支えられます。近接する業態の設計はECデータ基盤やスタートアップのデータ基盤と併せて参照してください。

よくある質問

SaaS事業で最初に構築すべきデータ基盤は?

MRR・Churn Rate・LTVの3大メトリクスを自動計算するパイプラインです。これにより投資家向けレポートと事業判断の両方をカバーできます。プロダクトアナリティクスやCSスコアリングは、この基本指標が整ってから追加するのが効率的です。

プロダクトアナリティクスにどのツールを使うべきですか?

初期はMixpanelやAmplitudeの導入が早いですが、スケール時にはDWH(BigQuery等)に生イベントを集約し自社でメトリクスを計算する構成が柔軟です。両方に同じイベントを送るハイブリッド運用で段階的に移行するのが現実的です。

マルチテナントのデータをどう分離すべきですか?

DWH内ではテナントIDによる論理分離が一般的です。行レベルセキュリティ(RLS)と組み合わせることで、テナント間のデータ漏洩を防止します。金融・医療のように規制要件が厳しい領域では、スキーマ分離や物理分離も検討してください。