ENTRY TYPE · how-to

機能の採用率を測定する方法

By Marius Bughiu Last updated 2026-06-06 Customer Success

機能の採用率とは、対象となるユーザーのうち実際にその機能を使う人の割合です。計算式はシンプルです（採用者を採用可能な母集団で割る）が、3つのことを明確にするまで数字は意味を持ちません。誰が対象に数えられるか（広さ）、どれだけ深く使うか（深さ）、どの期間で測るか（時間）です。これらを誤ると、正直な数字が 12% のときに 80% と表示するダッシュボードを出荷することになります。これは how-to です。機能を計測し、3つのメトリクスを計算し、それに基づいて行動します。

前提条件

安定したユーザー/アカウント ID に紐付いたカスタムイベントを取得する analytics ツール。Amplitude、Mixpanel、Heap、または Pendo です。Heap はクリックを自動取得します（初期計測は少なく、イベント分類は雑になります）。Amplitude と Mixpanel は明示的な track() 呼び出しが必要です（手間は増えますが、データはきれいです）。
定義された「対象母集団」。すべてのユーザーがすべての機能を使えるわけではありません。Enterprise プランの背後にある機能の分母は全シートではなく Enterprise シートです。計算を始める前にこのルールを書き出します。
「機能を使う」とは何を意味するかを、ページビューではなく1つ以上の具体的なイベントとして定義します。ページを開くことは採用ではありません。中核となるアクションを完了することが採用です。

ステップ 1 — ページではなく中核アクションを計測する

機能の価値を届けるアクションに対して、名前付きの単一イベントを発火させます。一括エクスポート機能であれば、イベントは export_page_viewed ではなく bulk_export_completed です。Amplitude または Mixpanel では、ファイルが生成された後、エクスポートの成功コールバックで track('bulk_export_completed', { row_count, format, account_id }) の呼び出しを追加します。ボタンのクリック時には決して発火させません。クリックには失敗やレイジクリックが含まれるからです。Pendo または Heap では成功状態の DOM 要素にタグを付けることもできますが、サーバーサイドのイベントの方が信頼性が高いです。ad-blocker やクライアントのクラッシュを乗り越えるからです。

account_id と plan_tier をイベントのプロパティとして付与し、後で分母を対象アカウントにフィルタできるようにします。これがないと、全ユーザーに対して広さを計算できますが、対象母集団に対しては決して計算できません。そして重要なのは対象母集団の数字です。

ステップ 2 — 3つの計算式を計算する

広さ = 採用者 / 対象ユーザー                  (そもそも触れたか？)
深さ = 中核アクション / 採用者                 (どれだけ頼っているか？)
時間 = 対象化からN日以内の採用者 / そのコホートの対象ユーザー

広さは見出しとなる採用率です。採用者とは、その期間内に中核イベントを少なくとも1回発火させた対象ユーザーです。広さは「この機能はそもそも定着したか？」に答えます。
深さは、人々が一度だけ試す機能と、人々が依存する機能を区別します。深さは採用者のみに対して計算します（ベース全体ではなく）。さもないと低い広さが高い深さを覆い隠します。広さ 15% で採用者あたり月 40 アクションの機能はパワーユーザー向けの機能であり、失敗ではありません。広さ 15% で 1.2 アクションの機能とは別物として扱います。
採用までの時間 は、コホートの時計に対して測定した広さです。「3月に対象になったアカウントのうち、30 日以内に機能を使ったのは何%か？」これは onboarding が機能を表に出しているかを教えるメトリクスであり、ほとんどのチームが飛ばすものです。

具体例：機能が 500 の Enterprise アカウントにゲートされているとします。30 日の期間で 145 が中核イベントを発火させ、合計 1,160 の中核アクションを生成しました。広さ = 145 / 500 = 29%。深さ = 1,160 / 145 = 採用者あたり 8 アクション。145 のうち 60 だけが対象化から 30 日以内に採用した場合、採用までの時間(30日) = 60 / 500 = 12% です。

ステップ 3 — 期間を意図的に選ぶ

期間は見た目だけのものではありません。毎日使う機能（ダッシュボード）は、7 日または 28 日のローリングなアクティブ期間で測定すべきです。先四半期に使った人は今日の採用者ではありません。四半期に使う機能（コンプライアンスのエクスポート）には 90 日の期間が必要です。さもないと、季節性にすぎないものを churn として報告してしまいます。期間を機能の自然なリズムに合わせ、メトリクスの定義に書き込み、異なる期間で測定した2つの機能を決して比較しません。

ステップ 4 — 分母の下限を設定する

リリースサイクルが1つ未満の機能では、対象母集団がまだ増えているため、昨日対象になったアカウントによって広さが人為的に低く出ます。機能の自然なリズム未満しか対象になっていないアカウントを除外します（例：週次利用の機能では、対象期間が 28 日未満のアカウントを除外）。広さは成熟した母集団に対して、採用までの時間は完全なコホートに対して報告します。両者は別の問いに答えます。

良い状態とは

普遍的なベンチマークはありません。採用率は機能ごとに固有です。中核となるワークフロー機能で 40-60% の広さの範囲は健全です。パワーユーザーや admin 向けの機能で 5-15% の広さに留まっていても、採用する少数の間で深さが高ければ完全に成功と言えます。警戒すべき数字は、完全なリズム期間の後に広さも深さも低い機能です。それは誰も必要としなかった機能であり、取るべき行動は enablement をさらに押すことではなく、廃止するか作り直すことです。

データに基づいて行動する

広さが低く、深さが高い — 発見の問題です。見つけた人は気に入っています。onboarding とアプリ内で表に出し（Pendo のガイド、空状態のプロンプト）、その後で採用までの時間を再測定します。
広さが高く、深さが低い — 価値が浅いか、一度きりの利用の機能です。繰り返し使われるべきなら、アクティベーションの瞬間が定着していません。2 回目の利用の離脱を調査します。
広さが低く、深さも低く、完全な期間が経過した — 廃止候補です。廃止前に churn/expansion のクロス集計で確認しますが、対象母集団が拒否した機能に enablement を投資し続けてはいけません。

よくある落とし穴

ページビューを採用とみなす。 page_viewed を数えると、偶然たどり着いた全員で広さが膨らみます。ガード：中核イベントは、価値を届けるアクションの成功コールバックで発火させ、ナビゲーションやクリックでは決して発火させません。
分母 = 全ユーザー。 機能がプランでゲートされているときに総アカウントで割ると、実際に使える人々の間での採用が過小評価されます。ガード：ステップ 1 で設定した plan_tier/entitlement で分母をフィルタします。
期間がない、または期間が不一致。 「これまでに使ったことがある」という生涯累積の数字は上がる一方で、現在の健全性については何も教えません。ガード：機能のリズムに合わせたローリングな期間を定義し（ステップ 3）、異なる期間で測定した機能を決して比較しません。
広さと深さを一緒に平均する。 ベース全体での「ユーザーあたり平均アクション」を報告すると、採用者と非採用者が意味のない中間に混ざります。ガード：深さは採用者のみに対して計算します。