ネットレベニューリテンション（NRR）の分析方法：ステップ・バイ・ステップ
ある企業はこの指標で130%を記録していても縮小している可能性があり、別の企業は95%でもより健全な経営状態にある、ということが起こり得ます。
矛盾しているように聞こえるかもしれませんが、新規顧客を意図的に除外した比率を計算すると、まさにこのようなことが起こるのです。
ネットレベニューリテンション（Net revenue retention）は、サブスクリプションのレポートにおいて最もよく引用される数字であり、最も誤解されている数字でもあります。計算式自体はすぐに理解できますが、何が除外されているかを理解することこそが、意思決定を左右する重要な部分です。
本ガイドでは、計算式と、なぜ分母がすべてを物語るのかについて解説します。その後、結果の読み解き方、3つの手動での算出方法、そしてそれぞれの方法が破綻するポイントについて説明します。
ネットレベニューリテンションが測定するもの
これは、すでに獲得していた売上がどうなったか、という1つのことだけを測定します。
Workdayの算出ガイドでは、その対象範囲を明確に示しています。この指標は「既存顧客からの継続売上の増減率」を追跡するものです。
新規顧客は除外されます。ウェイトを下げたり、調整したりするわけではありません。完全に「除外」されるのです。
この設計上のたった1つの選択こそが、この数字が有用である理由であり、同時に誤解を招く理由でもあります。既存の顧客ベースが拡大しているのか縮小しているのかを切り離して示してくれますが、全体の成長については何も教えてくれません。
計算式と4つの変動要素
Workdayは以下のように定義しています。
NRR = (Starting RR + Expansion RR – Contraction RR – Churn RR) / Starting RR × 100
| 構成要素 | 定義 |
|---|---|
| Starting RR | 対象期間の開始時点における継続売上 |
| Expansion RR | アップセルおよびクロスセルによる売上 |
| Contraction RR | プランのダウングレードによる損失売上 |
| Churn RR | 解約または非更新による損失売上 |
これら4つのうち3つは、同一の顧客コホート内での変動です。コホートの設定を誤ることは最もよくある間違いであり、しかもその誤りは出力された結果からは見えません。
これらを行う前に、クリーンな継続売上のベースデータが必要です。当社のサブスクリプションのエクスポートデータをMRRおよびARRレポートに変換する方法に関するガイドでそのステップを解説しており、そこでの定義がそのまま今回の計算に適用されます。
なぜ分母がすべてを物語るのか
分母は期首継続売上であり、それ以外の要素が入り込む余地はありません。
したがって、この指標が答えるのは「手元にあった資金のうち、どれだけが維持され、どれだけ増やせたか」ということです。「前四半期よりも規模が拡大したか」という問いに答えることはできません。
2つの企業を例に挙げると、このギャップがよく分かります。ある企業は、新規顧客を全く獲得していないものの、既存ベースを維持しつつ強力なアップセルによって130%を記録します。もう一方の企業は、既存ベースでは95%にとどまるものの、新規ビジネスを3倍に増やしています。
どちらの数字も正確です。しかし、実際に成長しているのはこれらの企業のうち1社だけであり、この指標だけではどちらが成長しているのかを判断することはできません。
実践的なルールは極めてシンプルです。決してこの数字だけを単独で提示してはいけません。新規売上、または顧客ベースそのものとセットで提示し、読み手が「何の何パーセントなのか」を把握できるようにしてください。
注意すべき分母の罠がもう1つあります。課金プラットフォームにおける継続売上の定義は、多くの人が想定しているよりも狭いものです。Stripeの請求分析ドキュメントでは、税金、無料プラン、従量課金制製品、トライアルが除外されています。分母をプラットフォームのエクスポートデータから取得している場合、これらの除外条件がそのまま引き継がれることになります。
数字が意味するもの
Workdayによる各範囲の解釈は非常に明快であり、引用するのに適しています。
| 結果 | Workdayの解釈 |
|---|---|
| 100%超 | 「ネットエクスパンション（純拡大）：既存顧客が失った以上の売上をもたらしている状態。」 |
| 90–100% | 横ばい、またはわずかな縮小 |
| 90%未満 | 「警告サイン：解約とダウングレードが拡大を上回っている状態。」 |
期間は自由に選択できます。同ページでは、「レポートの頻度に合わせて、NRRを月次、四半期、または年次ベースで計算することを選択できる」と説明されています。
しかし、不用意に扱うと、この柔軟性が罠になります。同一ビジネスにおける月次の数字と年次の数字は全く異なるものであり、単純に掛け算をしても互いに変換することはできません。
算出頻度を一度決定したら、それをレポートに明記し、異なる頻度の数値を決して比較しないでください。Amplitudeのこの指標に関する解説でも、プロダクト分析の観点から同様の内容が説明されています。
手動で算出する方法
オプション 1：4つの合計値を算出し、最後に1回だけ割り算をする
まずはコホートから始めます。期首時点で継続売上があったすべての顧客をリストアップし、そのリストを固定（フリーズ）します。
次に、顧客フィルターと日付範囲を指定したSUMIFS関数を使用し、その固定されたリストのみを対象に各変動額を合計します。これにより、4つの明確な合計値が得られます。
最後に1回だけ割り算を行います。4つの合計値を別々のセルに分けておくことで、「どの部分が変動したのか」という、具体的なアクションにつながる唯一の問いに答えることができるようになります。
この方法の限界は、特定の期間に対して1つの数字しか得られない点です。104%という結果は分かっても、誰がそれを牽引したのかは分かりません。
オプション 2：顧客レベルの変動テーブルを作成する
コホート内の顧客ごとに1行、変動ごとに1列を割り当てます。期首売上、期末売上、そしてその差分（デルタ）を拡大、縮小、解約に分解します。
これにより、レポートをプラン別、セグメント別、契約期間別、獲得コホート別などに細分化（スライス）できるようになります。
この細分化こそが、インサイトの宝庫です。一見健全に見える総合数値の裏で、あるセグメントが急拡大している一方で、別のセグメントが静かにダウングレードしていることがよくあります。当社のコホート分析に関する解説では、総合的な視点だけではなぜ数値の変動理由を見落としてしまうのかを説明しています。
この方法の限界は、データ量と結合（ジョイン）の複雑さです。サブスクリプションのエクスポートデータとアカウントテーブルを照合する作業は、数式だけで快適に処理できる限界を超えてしまいます。
オプション 3：定義タブを用意する
コホートのルールと算出頻度を記録します。次に、何をもって新規販売ではなく「拡大（エクスパンション）」とみなすか、期中の変更をどのように相殺するか、そしてエクスポートデータがどの売上定義を使用しているかを記録します。
特に議論を呼ぶのが「拡大」の境界線です。既存顧客が2つ目の製品を購入した場合、それを「拡大」とみなすか「新規ビジネス」とみなすかは、どちらの解釈も成り立ちます。
この方法の限界は、ルールを文書化しても自動的に適用されるわけではない点です。結局のところ、誰かが毎サイクル同じフィルターを再構築しなければなりません。
共通する限界： これら3つの方法はすべて、対象期間の初日時点におけるコホートを再現できることを前提としています。エクスポートデータに現在の状態しか表示されない場合、その再現作業こそが最も骨の折れる仕事になります。
手動ルートで行き詰まるポイント
最初の計算には半日かかります。4回目の計算にはさらに時間がかかるでしょう。なぜなら、誰も気づかないうちに定義がブレてしまうからです。
プラン変更は、拡大と縮小の分類を狂わせます。顧客を新しい料金体系に移行させるパッケージの改定は、成長でも損失でもない変動を生み出します。そして、それはフィルターの設定次第で、たまたま引っかかったバケットに分類されてしまいます。
100%割引は、誰もが陥るエッジケース（例外的な事例）です。Stripeのドキュメントによると、売上がゼロに減少した場合はその期間の「解約」として記録されます。そのため、完全に割引されたアカウントは、顧客が離脱していないにもかかわらず「失われた顧客」として表示されてしまう可能性があります。
設定変更の反映にもタイムラグがあります。Stripeは、分析設定の調整が反映されるまでに24〜48時間かかると指摘しています。設定を変更した当日に再計算を行っても、その変更は反映されません。
さらに、取締役会になって初めて露呈するコストもあります。「なぜこの数字が前四半期の資料と異なるのか」と質問されたとき、その原因はたいてい「定義の違い」にあります。そして、その定義は、その場に持ってきていないスプレッドシートのタブの中に眠っているのです。
Powerdrill Bloomで構築する方法
ステップ 1：サブスクリプションのエクスポートデータをアップロードする
サブスクリプションファイル、またはサブスクリプションファイルとアカウントファイルを一緒にアップロードします。Powerdrill Bloomはアップロード時に対象列のプロファイリングを行うため、比率が計算される前に、重複する顧客ID、プラン値の欠落、不整合な通貨フィールドなどが検出されます。
ステップ 2：自然言語で定義を記述する
ルールを構築するのではなく、言葉で指示します。コホートの日付、算出頻度、何をもって拡大とするか、および期中の変更をどのように相殺するかを指定します。
次に、罠を暴くための質問を投げかけます。期首コホートのうち、売上がゼロになった顧客は誰か。顧客の意思決定ではなく、プランのパッケージ改定によって生じた変動はどれか。そして、セグメント別や契約期間別で数値がどのように分かれるかを質問します。
ステップ 3：チャート、レポート、またはスライド資料をエクスポートする
変動テーブル、4つの構成要素のウォーターフォール図、または結果とともにコホートのルールが記載されたスライドなどを出力します。
よくある間違い
ベースとなる数値を提示せずに割合だけを示す。 元の数字が明記されていないパーセンテージは、単なる飾りにすぎません。期首継続売上を必ず横に並べて表示してください。
分母に新規顧客を含めてしまう。 この指標は既存のコホートのみを対象に定義されています。新規ビジネスを含めてしまうと、別の、そして有用性の低い比率になってしまいます。
月次の数字と年次の数字を比較する。 これらは異なる測定基準であり、変換することはできません。どちらか一方の頻度に固定し、ラベルを明記してください。
明確なルールなしに、2つ目の製品購入を「拡大」としてカウントする。 それは拡大かもしれないし、新規ビジネスかもしれません。一度ルールを決定して文書化し、一貫して適用してください。
割引で売上がゼロになったアカウントを「解約」と解釈する。 プラットフォームの定義では、売上ゼロをその期間の解約として扱います。顧客が実際に離脱したかどうかを確認してください。
プランのパッケージ改定を無視する。 顧客を新しい料金体系に移行させることは、顧客の意思決定によるものではない変動を生み出します。これらの行には個別にフラグを立ててください。
課金設定を変更した直後に再計算を行う。 プラットフォームの設定が反映されるまでに24〜48時間かかる場合があるため、取得される数値は古いデータのままになります。
結論
コホートを固定し、4つの変動を合計し、期首継続売上のみで割り算を行い、算出頻度を固定し、パーセンテージの横には常にベースとなる数値を表示する。これこそが、取締役会のレビューを乗り切るためにこの数値を正しく機能させる方法です。
数字そのものが成果物ではありません。拡大、縮小、解約の内訳こそが、次に取るべきアクションを教えてくれるのです。
もしその内訳の再現作業に四半期を費やしてしまっているなら、サブスクリプションのエクスポートデータを使ってPowerdrill Bloomをお試しください。また、SaaS指標追跡のためのAIツールのまとめや、AIレポートジェネレーターのページもあわせてご覧ください。
よくある質問
ネットレベニューリテンションの計算式は？
Workdayは、期首継続売上に拡大を足し、縮小と解約を引いたものを、すべて期首継続売上で割り、100を掛けたものとして定義しています。
新規顧客は含まれますか？
いいえ、含まれません。この指標は、既存顧客のみからの継続売上の増減率を測定します。だからこそ、ビジネスが成長しているかどうかをこれだけで判断することはできないのです。
どのような結果が良いとされますか？
Workdayは、100%超をネットエクスパンション（純拡大）、90%未満を警告サイン、90〜100%を横ばいからわずかな縮小と解釈しています。ベンチマークはセグメントによって異なるため、まずは自社の推移と比較することをお勧めします。
月次と年次のどちらで計算すべきですか？
固定して運用するのであれば、どちらでも構いません。これら2つは異なる測定基準であり、相互に変換することはできないため、どちらか一方の頻度を選択し、すべてのレポートにそれを明記してください。
算出された数値が課金プラットフォームの数値と異なるのはなぜですか？
通常、売上の定義が原因です。プラットフォームの数値では、税金、無料プラン、従量課金制製品、トライアルが除外されていることが多いため、総請求額に基づいて作成されたスプレッドシートの数値とは一致しません。