自社のカスタマーサクセスが「顧客がプロダクトを使いこなせている」ことを、自信を持って数字で答えられるでしょうか。
MRRや解約率は毎月見ているのに、その手前にある「顧客がどれだけ機能を使えているか」は感覚で語られがちです。結果、解約の兆候に気づくのが更新面談の直前になったり、時間をかけて作った新機能が誰にも見つけられないまま埋もれたりします。
この記事では、顧客向けプロダクトにおけるアダプション率(機能活用率)の測り方を、定義の整理から指標の選び方、測ったあとの打ち手までまとめて解説します。難しい指標ほど、具体的な数字の例をつけて噛み砕いて説明します。
- アダプション率とは何か
- 顧客向けと従業員向けでは、設計が変わる
- 測定を始める前に決める3つの前提
- 1. 分母は誰か
- 2. 「使った」とは何をしたことか(コアイベントの定義)
- 3. 期間をどう区切るか
- 顧客のアダプションを可視化する4つの指標
- 指標1:機能アダプション率
- 指標2:利用頻度とスティッキネス(定着度)
- 指標3:Time to Value(TTV/価値実感までの時間)
- 指標4:離脱ポイント(ファネル完了率)
- よくある3つの失敗
- 測ったあと、どう改善するか
- 課題別の打ち手
- Onboardingで、測定から改善までを1か所で回す
- 測る:開発を待たずに現状値を出す
- 気づく:月次レポートを待たずに動く
- 直す:気づかれていない機能を、その場で案内する
- 確かめる:改善が当たったかを同じ場所で判定する
- よくある質問
- まとめ
アダプション率とは何か
アダプション(Adoption)は「採用・定着」を意味し、アダプション率とは、ユーザーがプロダクトの価値ある機能を実際に使いこなしている度合いを指します。
カスタマーサクセスの文脈では、顧客ライフサイクルは「導入 → オンボーディング → アダプション → 拡大」と進みます。オンボーディングが「最初の成功体験まで運ぶ」フェーズであるのに対し、アダプションはそこから先、日常業務のなかで継続的に使われている状態を指します。
顧客向けと従業員向けでは、設計が変わる
デジタルアダプションという言葉は、社内システムの定着(従業員向け)文脈で語られることが多いですが、顧客向けプロダクトでは前提が大きく異なります。

顧客向けの場合、「使われていない」がそのまま収益の毀損につながります。だからこそ、離脱の兆候を早期に検知できる指標設計が必要になります。
なお、社内システムと顧客向けDAPの違いは
「従業員向けDAPと顧客向けDAPの違い|活用場面・KPI・選び方」をご参照ください。
測定を始める前に決める3つの前提
指標の話に入る前に、ここを曖昧にしたまま集計すると、部署ごとに違う数字が出回ることになります。
1. 分母は誰か
「アダプション率80%」の80%が何に対する割合なのかを固定します。
契約ユーザー数(発行済みID全体) …… アカウント内の未活性ユーザーが見える。営業・CSの拡大提案に向く
アクティブユーザー数(期間内にログインした人) …… プロダクトの使い勝手を見る。PdMの改善判断に向く
アカウント(企業)数 …… BtoBで、企業単位の健全性を見る

どれか一つが正解ということはありません。ただし用途ごとに分母を明示して呼び分けることは必須です。「ユーザー基準のアダプション率」「アカウント基準のアダプション率」と名前を分けておくと、後の議論が混乱しません。
同じ100人が50人使っている状態でも、分母を発行済みID(200)に取れば25%、アクティブユーザー(80)に取れば62.5%になります。分母を揃えないまま「先月より上がった/下がった」を議論しても、意味のある結論には至りません。
2. 「使った」とは何をしたことか(コアイベントの定義)
画面を開いた時点を「使った」とするのか、処理を完了した時点とするのかで、数字は倍近く変わります。
推奨は「価値が発生した瞬間」を完了イベントとすることです。

弱い定義を使うと、アダプション率は簡単に高く出ます。しかしその数字では、なぜ解約が起きたのかを説明できません。「レポート画面を開いた人は8割いる」という数字は、開いて何もできずに閉じた人を含んでいるからです。
3. 期間をどう区切るか
利用頻度の想定に合わせます。日次で使う想定のプロダクトを月次で見ると、月1回しか使っていない顧客も「アダプション済み」に含まれてしまいます。
日次利用が前提 → 週次・28日ローリング
月次業務で使う(経費精算、月次レポート等) → 月次・四半期
年次イベント型(年末調整、確定申告等) → イベント発生期間で区切る
顧客のアダプションを可視化する4つの指標
前提が決まったら、以下の4つを組み合わせます。すべてを一度に導入する必要はありません。まずは1と3から始めるのが現実的です。
以下では、説明を具体的にするため請求管理SaaSを例に統一します。機能構成は次のとおりとします。
請求書を発行する(使わなければ話にならない機能)
入金データと請求データを自動で照合する(他社との差になる機能)
データをCSVで書き出す(一部のユーザーだけが使う機能)
指標1:機能アダプション率
機能アダプション率 = その機能を使ったユーザー数 ÷ 分母となるユーザー数 × 100
一言でいうと:その機能が「何人に届いているか」
最も基本となる指標です。分母を月間アクティブユーザー400人とし、自動照合機能を今月使ったのが120人だったとすると、この機能のアダプション率は30%になります。「差別化のために作った機能が、来ている人の3割にしか届いていない」と読めます。
重要なのは、すべての機能を平等に並べないことです。全機能を一覧化しても改善の優先順位はつきません。次の3層に分けて管理します。

なぜ3層に分けるのか。コア機能が70%なら、残る30%は「契約したのに本来の用途に使えていない人」であり、緊急対応が必要です。一方で補助機能が15%でも、それは想定どおりで何の問題もありません。層を分けずに数字だけ並べると、この2つが同じ「低い機能」として扱われ、優先順位を誤ります。
「差別化機能のアダプション率」は、多くのプロダクトで更新率との相関が最も強く出る指標です。ここを単独のKPIに据える価値があります。
指標2:利用頻度とスティッキネス(定着度)
一言でいうと:その機能が「どれだけ繰り返し使われているか」
指標1の「使った人数」だけを見ると、「一度は触った」ユーザーが定着ユーザーとして計上されてしまいます。先ほどの自動照合機能を使った120人のなかには、月に20回使っている人と、1回試して二度と使っていない人が同じ1人として混ざっています。そこで頻度と定着を併せて見ます。
利用頻度:機能ごとの1人あたり実行回数(月/週)
120人の合計実行回数が150回なら、1人あたり1.25回です。「使われている」というより「試された」に近い状態だと分かります。
スティッキネス(定着度):DAU ÷ MAU(または WAU ÷ MAU)
スティッキネスは日次・週次・月次アクティブユーザーの比率で算出され、ユーザーが定期的に戻ってくるプロダクトかどうかを判断する指標として広く使われています。

言葉だけだと分かりにくいので、噛み砕きます。DAU(1日に来る人)が200人、MAU(1か月に来る人)が1,000人なら、スティッキネスは20%です。これは「平均的なユーザーは、1か月のうち5日に1日しか来ていない」という意味になります。毎日開いてほしい業務ツールなら低すぎますが、月末にまとめて請求処理をするプロダクトなら妥当な水準です。絶対値の良し悪しは、そのプロダクトの利用リズム次第であり、他社の数値と比べる意味はほとんどありません。自社の推移とセグメント間の差を見るための指標です。
「人数」と「頻度」をクロスさせる
指標1で見た「何人が使ったか」と、この指標で見た「どれだけ繰り返し使われたか」は、掛け合わせると打ち手が明確になります。

先ほどの自動照合機能(400人中120人・1人あたり1.25回)は左下、つまり「そもそも気づかれておらず、気づいた人も続かない」状態です。この場合、機能を追加するより、告知と初回の操作案内を直すほうが効きます。
指標3:Time to Value(TTV/価値実感までの時間)
一言でいうと:契約してから「使えるようになる」までに何日かかっているか

アダプションの遅れは、多くの場合オンボーディング初期に決まります。TTVは、その遅れを最も早く検知できる指標です。請求管理SaaSであれば「最初の請求書を発行して送付した日」を到達点に置きます。
測るときのポイントは2つあります。
中央値で見る。平均値は、極端に長い一部の顧客に引きずられます。9社が10日で到達し、1社が200日かかった場合、平均は29日ですが中央値は10日です。平均だけを見て「1か月かかっている」と判断すると、実態を読み違えます。
未到達者の割合も併せて見る。「30日以内に価値到達しなかったユーザーの比率」は、解約予測の材料になります。中央値が良好でも、未到達率が25%あるなら、4社に1社が価値に触れないまま契約期間を消費していることになります。
TTVが短縮すると、CSの初期支援工数と解約率が同時に下がります。ROIを説明しやすい指標でもあるため、経営報告に組み込みやすいのが利点です。
指標4:離脱ポイント(ファネル完了率)
一言でいうと:どの画面で、何人が諦めているか
ここまでの3指標は「どれだけ使われているか」を示しますが、なぜ使われていないかは教えてくれません。それを担うのがファネル分析です。
主要な機能について、開始から完了までのステップを分解し、各ステップの通過率を測ります。

読み方はシンプルです。ステップ間の矢印に書かれた数字が、次に進めた人の割合です。プロフィール入力から データ連携設定 への通過率が61%しかなく、ここだけで31ポイントが失われています。前後のステップは92%・88%と通過できているので、問題はプロダクト全体ではなくこの1画面だと特定できます。
この粒度まで下りると、「機能全体の使い勝手が悪い」という漠然とした結論ではなく、「データ連携設定の画面で、必要な情報の説明が足りていない」という具体的なアクションに落とせます。
よくある3つの失敗
1. ログイン率をアダプション率と呼んでしまう
数字は高く出ますが、解約の説明はできません。必ず「何をしたか」で定義してください。
2. 全機能を横並びで管理する
50機能の一覧表を作っても、優先順位はつきません。コア/差別化/補助の3層に整理してから測ります。
3. 平均値だけを見る
全体平均は、最も問題のあるセグメントを隠します。「全体では65%だが、利用開始90日以降の一般ユーザーだけ28%」といった形に分解して初めて、介入すべき対象が見えます。
測ったあと、どう改善するか
アダプション率の測定は目的ではなく、改善の起点です。そして測定の結果として出てくる課題の多くは、「機能が足りない」ではなく「機能に気づかれていない」「使い方がその場でわからない」という導線・体験の問題です。
このタイプの課題は、機能開発の順番待ちに並ばせると解決が数ヶ月先になります。一方で、プロダクトの画面上に案内を出すというアプローチであれば、開発リソースを使わずに短いサイクルで検証できます。
そして測定そのものも、開発を待つ必要はありません。イベント計測が未整備の場合、実装からリリースまで数ヶ月かかることも珍しくありませんが、タグ設置のみで画面上の操作を計測できるツールを使えば、開発対応なしで現状値の把握から始められます。
つまり、アダプション率の改善は「測る → 気づく → 直す → 確かめる」の4つを短いサイクルで回せるかどうかで決まります。
課題別の打ち手
ここまでの4指標で問題が見つかったとき、実際に取る手は次のように整理できます。

いずれも共通しているのは、プロダクトそのものを作り変えるのではなく、画面上の案内を足すことで解決するという点です。
Onboardingで、測定から改善までを1か所で回す
ここまで挙げた「計測の実装」「画面上の案内」「効果の検証」を、開発工数をかけずに進める方法としてOnboardingを紹介します。
Onboardingは、既存のWebサービスにタグを1行設置するだけで、機能の利用状況の計測から画面上での改善までをノーコードで行えるUI/UX改善プラットフォームです。「測る」「気づく」「直す」「確かめる」の4つを同じ場所で回せるのが特長です。

測る:開発を待たずに現状値を出す
アダプション率の測定で最初の障壁になるのは、機能ごとの実行回数を取るイベント計測の実装です。カスタムイベントは、画面上の任意のボタンやページを指定するだけで実行数・訪問人数を計測できるため、開発対応の順番待ちをせずに機能別の現状値を出せます。
「まず現状値を知りたいが、イベント計測の開発は数ヶ月先になる」という状況では、先に測定だけを立ち上げて改善サイクルを回し始めることができます。
気づく:月次レポートを待たずに動く
TTVや価値到達は、月次で振り返っても手遅れになりやすい情報です。イベント通知を使うと、価値到達イベントの達成をSlackやChatworkに流せるため、到達した顧客とまだ到達していない顧客を、CSがその日のうちに把握できます。
通知条件は初回達成だけでなく、指定した回数への到達でも設定できます。「差別化機能を5回使った顧客」を検知すれば、上位プランの提案や事例取材の候補として即座に動けます。
直す:気づかれていない機能を、その場で案内する
告知にはポップアップ、操作のつまずきにはステップ形式のチュートリアルや入力欄のヒントを使います。セグメント別の出し分けができるため、初回ユーザー向けの案内と、一度使ったユーザー向けの再訪時ヒントを作り分けられます。役割・属性別の配信にも対応しているので、管理者にしか届いていない機能を一般ユーザーに広げる用途にも使えます。
確かめる:改善が当たったかを同じ場所で判定する
案内を出したあと、それが効いたのかを確認する必要があります。ガイド分析では、ガイドの表示数・完了率に加えて、設置後に対象機能の実行数が実際に増えたかまで確認できます。「ガイドは見られているが機能の利用は増えていない」といった状態も切り分けられるため、次の打ち手を判断しやすくなります。
なお、測定した数値を誰のどの意思決定に使うか、誰がいつその数字に気づくかといった運用設計は、アダプション率のKPI設計5ステップで解説しています。
よくある質問
Q. アダプション率の目標値はどのくらいが妥当ですか?
プロダクトの性質によって大きく変わるため、業界一般の基準値をそのまま当てはめることは推奨しません。まず自社の現在値を計測し、継続顧客と解約顧客の差を確認したうえで、コア機能は90%以上、差別化機能は40〜60%といった水準を出発点に設定するのが現実的です。
Q. アダプション率とエンゲージメント率の違いは?
アダプション率は「特定の機能が使われているか」を、エンゲージメント率は「プロダクト全体との接触の強さ」を測ります。改善の打ち手に直結しやすいのはアダプション率です。「エンゲージメントが下がっている」では次に何をすべきか決まりませんが、「差別化機能のアダプション率が30%」なら、その機能の告知と操作導線を直すという行動に移れます。
Q. どの指標から始めるべきですか?
コア機能・差別化機能の機能アダプション率(指標1)と、Time to Value(指標3)の2つです。この2つは実装負荷が比較的軽く、かつ解約率との関連を説明しやすいため、最初の投資対効果が高くなります。利用頻度やファネルは、この2つで課題のある機能を特定してから、その機能に絞って測るほうが効率的です。
まとめ
アダプション率は「来ているか」ではなく「使えているか」を測る指標
測る前に、分母・コアイベントの定義・期間の3点を確定させる
指標は、機能アダプション率/利用頻度とスティッキネス/Time to Value/離脱ポイントの4つ
全機能を平等に測らず、コア・差別化・補助の3層に分けて管理する
平均値ではなくセグメントで分解して初めて、打ち手が具体化する
数字が見えるようになると、改善の議論は「なんとなく使いにくい気がする」から「この画面のこのステップで31%が離脱している」に変わります。まずは主要機能を3つ選び、完了イベントを定義するところから始めてみてください。
実際に、タグ1行の設置とプロダクト内ガイドによる案内だけで、機能アダプション率やTime to Valueの改善に取り組んだ企業もあります。Onboardingの事例紹介では、そうした計測から改善までの具体的な進め方を紹介しています。
事例紹介はこちら







