ベイズ隠れマルコフモデルで「見えない解約リスク」を可視化する

SaaSビジネスにおいて、解約率（チャーンレート）の管理はLTV（顧客生涯価値）を左右する最重要指標のひとつです。多くの企業がログイン頻度や機能利用率、サポート問い合わせ件数といった行動指標をダッシュボードで監視していますが、「数字が下がったことに気づいたときにはすでに手遅れだった」という経験をお持ちの方も少なくないのではないでしょうか。

その背景には、観測できる行動データの裏に「見えない心理状態」が存在するという本質的な課題があります。ログイン頻度が週に3回あったとしても、その顧客が「満足して使い続けている」のか「惰性でログインしているだけ」なのかは、数値だけでは判別できません。

本記事では、ベイズ統計と隠れマルコフモデル（HMM）を組み合わせた手法を用いて、顧客の行動ログから「満足」「不安」「離脱気味」という3つの隠れた心理状態を推定し、解約リスクを事前に可視化するアプローチを検証します。

Salesforce Data CloudやSnowflakeに蓄積された行動ログを「ただ眺める」段階から、「AIが自動でリスクを検知し、施策を提案する」段階へ進めるための具体的な方法論を、1,000ユーザーのシミュレーション結果とともにお伝えします。

データは集まった。でも「次に何をすればいいかわからない」

近年、生成AIの活用を見据えたデータ統合の動きが加速しています。Salesforce Data Cloud、Snowflake、Databricksなどのプラットフォームを導入し、CRMの顧客情報、プロダクトの利用ログ、サポートのチケット情報などを一元管理する企業が増えてきました。

しかし、多くの企業が直面するのが「データは溜まったが、そこから何をすればいいかわからない」という壁です。ダッシュボードでグラフを見ることはできても、「この数字をどう読み取り、どんなアクションにつなげるか」が明確でないまま、データが眠ってしまうケースが少なくありません。

この課題は、SaaSの解約防止でも同じです。解約率は月次で1%改善するだけで年間収益に大きな差が出る重要指標ですが、現在多くの企業が採用している方法には、構造的な限界があります。

従来の「しきい値アラート」方式では限界がある

「データを集める」の次のステップへ

この限界を突破するのが、本記事で紹介するベイズ隠れマルコフモデルというアプローチです。蓄積された行動ログを統計モデルに入力することで、数値の裏にある「顧客がいま何を感じているか」を確率的に推定できるようになります。

つまり、「ダッシュボードを眺める」段階から、「AIが自動でリスクを検知し、誰に・いつ・どんなフォローをすべきか提案する」段階に進めるということです。以降のセクションで、この手法を順を追ってご説明します。

直感的な理解

隠れマルコフモデル（Hidden Markov Model, HMM）は、「直接は観測できない状態」と「観測できるデータ」の関係を確率的にモデル化する統計手法です。一見難しそうな名前ですが、考え方はシンプルです。

日常生活に例えると、天気と体調の関係に似ています。友人の体調（「元気」「だるそう」「体調不良」）を毎日電話で聞くことはできますが、友人の住む街の天気は直接見えません。しかし、「晴れの日は元気な確率が高い」「雨の日はだるそうな確率が高い」という傾向があれば、体調の報告から天気を逆推定できます。

SaaSの解約予測に当てはめると、次のようになります。

HMMがやっていることをシンプルに言えば、「毎週の行動データの組み合わせパターンから、この顧客はいま満足しているのか、不安を感じているのか、離脱しかけているのかを自動で判定する」ということです。しかも単一の時点ではなく、過去からの行動の「流れ」を見て判断するため、たとえば「先月まで活発だったのに急に使わなくなった」といった変化も捉えられます。さらに、「満足している顧客が来週不安を感じ始める確率は約12%」のように、将来の変化を確率として予測することもできます。

モデルの3つの構成要素

HMMは、以下の3つの要素で定義されます。

1. 状態遷移確率（Transition Probability）

ある隠れ状態から別の隠れ状態に遷移する確率を表します。たとえば「今週Engagedだった顧客が、来週もEngagedである確率は85.0%」「At-Riskに移る確率は12.0%」のように定義されます。この確率は3×3の行列（遷移行列）として表現され、各行の合計が1になります。

2. 出力確率（Emission Probability）

各隠れ状態において、どのような観測データが生成されるかの確率分布です。たとえばEngaged状態のユーザーは「ログイン回数が平均18回」「セッション時間が平均45分」といった特徴を持ちます。本記事では正規分布（ガウス分布）を用いてモデル化しています。

3. 初期状態確率

最初の時点（観測開始時）に顧客がどの状態にいるかの確率分布です。

「ベイズ」を加える意味

通常のHMMでは、パラメータの点推定（もっともらしい一つの値を求める）を行います。一方、ベイズ隠れマルコフモデルでは、パラメータそのものに「事前分布」を設定し、データを観測した後の「事後分布」を推定します。

具体的には、状態遷移確率にディリクレ分布（Dirichlet Distribution）と呼ばれる事前分布を設定します。ディリクレ分布は「確率の確率分布」であり、「遷移確率はこのあたりの値をとりやすいだろう」という事前知識を表現できます。

理論の有効性を検証するため、既知のパラメータでダミーデータ（シミュレーションデータ）を生成し、モデルがそのパラメータを正しく復元できるかを確認しました。実際の顧客データを使う前に、モデルの推定精度を担保するための重要なステップです。

データ設計の概要

200人のSaaSユーザーについて、52週間（1年間）分の行動ログを生成しました。各ユーザーは毎週4つの指標が記録されます。

観測変数	Engaged（平均）	At-Risk（平均）	Disengaged（平均）
ログイン回数/週	18.0	8.0	2.0
機能利用回数/週	12.0	5.0	1.0
サポート問い合わせ件数/週	0.3	1.5	2.5
セッション時間（分）/週	45.0	20.0	5.0

Engaged状態のユーザーは高頻度でログインし、長時間利用しており、サポートへの問い合わせは少ないという直感的に理解しやすいパターンになっています。反対にDisengaged状態のユーザーはほとんどログインせず、サポートへの問い合わせだけが多い（不満を感じている）傾向を示しています。

真の遷移行列

データ生成に使用した状態遷移確率（真の遷移行列）は以下の通りです。

遷移元 → 遷移先	Engaged	At-Risk	Disengaged
Engaged	0.850	0.120	0.030
At-Risk	0.150	0.700	0.150
Disengaged	0.050	0.180	0.770

この行列からは、いくつかの重要なビジネス上の意味が読み取れます。Engaged状態は比較的安定しており、85%の確率で翌週も維持されます。一方、At-Risk状態は不安定で、Engagedに回復する確率（15%）とDisengagedに悪化する確率（15%）が拮抗しています。Disengagedに一度陥ると、そこから脱出する確率は比較的低く（Engagedへ5%、At-Riskへ18%）、いわば「吸い込み状態」に近い性質を持っています。

モデルの学習は、「仮の答えで計算する → 結果をもとに答えを修正する → また計算する…」というサイクルを繰り返すことで、徐々に正しいパラメータに近づけていく仕組みです。最初は大雑把な推測から始まりますが、繰り返すたびに精度が上がり、最終的に安定した答えに落ち着きます。

今回のシミュレーションでは、1,000ユーザー×52週間＝52,000データポイントを入力として、モデルはわずか数回の繰り返しで安定しました。下のグラフは、繰り返しのたびにモデルの精度（対数尤度）が改善していく様子を示しています。

最終的に得られた推定パラメータを使い、ビタビアルゴリズム（Viterbi Algorithm）で各ユーザーの各週における最尤状態系列を復元しました。ビタビアルゴリズムは、観測データに対して最も確率の高い隠れ状態の系列を動的計画法で効率的に求める手法です。

シミュレーションでは、あらかじめ正解がわかっているダミーデータを使っているため、「モデルが推定した結果」と「本当の答え」を比べることができます。結果として、モデルはほぼ正確に正解を再現できました。

各状態の特徴をどれだけ正確に捉えたか

下の表は、正解の数値とモデルが推定した数値の比較です。ほぼ一致していることがわかります。

観測変数	状態	真の値	推定値
ログイン回数	Engaged	18.0	18.1
ログイン回数	At-Risk	8.0	8.0
ログイン回数	Disengaged	2.0	2.1
機能利用回数	Engaged	12.0	12.0
機能利用回数	At-Risk	5.0	5.0
機能利用回数	Disengaged	1.0	1.1
サポート問い合わせ	Engaged	0.3	0.4
サポート問い合わせ	At-Risk	1.5	1.5
サポート問い合わせ	Disengaged	2.5	2.5
セッション時間	Engaged	45.0	45.0
セッション時間	At-Risk	20.0	19.8
セッション時間	Disengaged	5.0	5.0

すべての変数において、推定値が真の値とほぼ一致していることがわかります。最大の誤差はセッション時間のAt-Risk状態で0.2分（真の値20.0に対して推定値19.8）であり、実用上まったく問題のない精度です。

遷移行列の復元精度

遷移パターン	真の値	推定値	誤差
Engaged → Engaged	0.850	0.856	+0.006
Engaged → At-Risk	0.120	0.118	-0.002
Engaged → Disengaged	0.030	0.026	-0.004
At-Risk → Engaged	0.150	0.149	-0.001
At-Risk → At-Risk	0.700	0.706	+0.006
At-Risk → Disengaged	0.150	0.144	-0.006
Disengaged → Engaged	0.050	0.051	+0.001
Disengaged → At-Risk	0.180	0.186	+0.006
Disengaged → Disengaged	0.770	0.764	-0.006

すべての遷移確率において、誤差は0.006以内に収まっています。モデルが状態間のダイナミクスを極めて正確に復元できていることが確認できました。

モデルの有用性をより具体的に理解するため、個別ユーザーの状態推移を見てみましょう。以下の図は、あるユーザーの52週間にわたる行動データと、モデルが推定した隠れ状態の変化を示しています。

この図からは、行動指標の変化に先立って、あるいは連動して、隠れ状態が遷移していく様子が読み取れます。注目すべきは、ログイン回数や機能利用率が徐々に低下し始める「変曲点」で、モデルがEngagedからAt-Riskへの遷移を検知している点です。

単一の指標にしきい値を設けるアプローチでは、「ログイン回数が週10回を下回ったらアラート」のように定義するしかなく、グラデーション的な変化を捉えることが困難です。HMMは4つの観測変数を同時に考慮しながら、確率的に状態を推定するため、より繊細な変化を検知できます。

状態確率の時系列

上の図は、同じユーザーについて、各週で3つの状態それぞれに属する確率をプロットしたものです。ビタビアルゴリズムでは最も確率の高い状態を1つ選びますが、Forward-Backwardアルゴリズムを使えば、各時点の「確信度」を確率として出力できます。

個別ユーザーの状態推移だけでなく、ユーザー基盤全体の「健全性」を俯瞰的に把握することも重要です。以下の図は、52週間にわたるユーザー基盤の状態構成比の推移を示しています。

この図は、経営層やマネージャーにとって非常に価値のある情報源になります。たとえば、以下のような判断に活用できます。

• トレンドの早期察知 Engaged比率が徐々に低下し、At-Risk比率が上昇しているトレンドがあれば、プロダクトや価格設定に構造的な問題がある可能性を示唆する
• 施策効果の検証 カスタマーサクセス施策を投入した時期の前後で、At-RiskからEngagedへの回復率が変化したかを確認できる
• 季節性の把握 年度末や四半期末に特定の状態遷移が集中するパターンを発見できる

従来のMRR（Monthly Recurring Revenue）やNRR（Net Revenue Retention）といったトップラインの指標は「結果」を示しますが、状態構成比は「原因」に近い先行指標として機能します。Disengaged比率の上昇は、数か月後のチャーン増加を予告するシグナルとなります。

推定されたHMMのパラメータを活用して、各ユーザーに「チャーンリスクスコア」を付与することで、実際のビジネスオペレーションに接続できます。イメージとしては、顧客一人ひとりに「解約の危険度を0〜100で示す体温計」をつけるようなものです。

スコアの算出ロジック

チャーンリスクスコアは、各ユーザーの直近の状態確率と遷移行列を組み合わせて算出します。具体的には、直近時点のDisengaged確率に重みを置きつつ、At-Risk状態からDisengagedへの遷移確率も加味した複合的なスコアです。

このスコアに基づいて、200ユーザーを3つのリスクカテゴリに分類した結果は以下の通りです。

リスクカテゴリ	ユーザー数	割合	推奨アクション
Low（低リスク）	88	44%	アップセル・クロスセルの提案
Medium（中リスク）	69	34%	ヘルスチェックの実施・活用支援
High（高リスク）	43	22%	即時のエスカレーション・経営層面談

従来のしきい値アラートとの違い

冒頭で紹介した「しきい値ベース」のアラート（例：ログインが週5回を下回ったら警告）と、HMMベースのリスクスコアはどう違うのでしょうか。

HMMの推定結果は、具体的な介入戦略の設計に直接活用できます。特に重要なのは、状態遷移のパターンごとに異なるアクションを定義することです。

遷移パターン別の介入アクション

遷移パターン	確率	推奨アクション	タイミング
Engaged → At-Risk	11.8%	プロアクティブなヘルスチェック連絡	遷移検知から1週間以内
At-Risk → At-Risk（継続）	70.6%	活用事例の共有・トレーニング提案	At-Risk状態が2週間継続時
At-Risk → Disengaged	14.4%	経営層を含めたエスカレーション面談	遷移検知後すぐ
Disengaged → At-Risk（改善兆候）	18.6%	回復を後押しするサポートの強化	遷移検知のタイミング
At-Risk → Engaged（回復成功）	14.9%	回復要因の分析とナレッジ蓄積	回復確認後

At-Risk状態の「猶予期間」

この3.4週間という数値は、カスタマーサクセスチームのオペレーション設計において非常に重要です。たとえば、週次でモデルを更新し、新たにAt-Riskに遷移したユーザーを自動で担当者にアサインするワークフローを構築すれば、理論上は2〜3週間の介入猶予を確保できます。

従来のしきい値ベースのアラートでは、「ログイン頻度が下がった」時点で初めて検知するため、実質的にはDisengagedに近い状態で発見されることが多く、介入が間に合わないケースが頻発していました。HMMを使えば、行動パターンの微細な変化からAt-Riskへの遷移を早期に検知できるため、介入のリードタイムを大幅に確保できます。

本記事では、ベイズ隠れマルコフモデル（HMM）を用いて、SaaSユーザーの行動ログから「見えない心理状態」を推定し、解約リスクを事前に可視化するアプローチを検証しました。

データ統合プラットフォームに蓄積されたデータは、ダッシュボードで眺めているだけでは宝の持ち腐れです。本記事で紹介したベイズHMMのような統計モデルを活用することで、「データを集める」から「データが自動で判断する」へとステップアップできます。

Salesforce Data Cloud、Snowflake、Databricksなどに行動ログデータをお持ちであれば、まずは小規模なデータで試してみることをおすすめします。「自社のデータでも本当にこんなことができるのか」を確認する第一歩として、ぜひ検討してみてください。