サブスクリプションのエクスポートデータをMRRおよびARRレポートに変換する方法（2026年版ガイド）

サブスクリプションのエクスポートデータには、顧客、プラン、金額、インターバル（周期）、ステータス、開始日といった行が含まれています。一方、MRRレポートに必要なのは、月ごとの単一の数値です。前者から後者への変換は一見すると単なる計算のように思えますが、その大部分は定義の整理にあります。

完成したレポートのすべての数値を左右するのは、2つの選択肢です。それは、「どのサブスクリプションをアクティブとみなすか」と「割引を金額から差し引くか」です。

どちらか一方でも間違えると、レポートの内部的な整合性は取れているように見えても、財務データや請求ダッシュボード、さらには先月のレポートと数値が一致しなくなってしまいます。

本ガイドでは、最初に決定すべき事項、3つの手動による作成方法、そしてそれぞれの方法が機能しなくなる限界について解説します。

始める前に必要なもの

必要なのは、インボイス（請求書）ごとではなく、サブスクリプションごとに1行となっているエクスポートデータです。インボイスは「請求された内容」を示しますが、サブスクリプションは「継続して発生するもの」を示します。

また、すべての行に請求インターバルが必要です。月次プランと年次プランは、年次プランを月換算（標準化）するまで合算することはできません。

さらに、ステータス列も必要です。Stripeの請求分析ドキュメントでは、MRRを「月換算された金額の合計」と定義しています。これには、ステータスがactiveおよびpast_dueのサブスクリプションのみがカウントされます。

この定義はそのまま採用する価値があります。公式に公開されており、具体的であるため、数値が変動した理由を尋ねられた際に、根拠のある回答を提示できます。

まず、以下の3つの決定を下す必要があります。

どのステータスをカウントするか。 ドキュメント上のデフォルトは「アクティブ」と「期限切れ」です。「キャンセル」と「未払い」はチャーン（解約）として扱われ、除外されます。

割引を差し引くか。 Stripeではこれを設定可能で、継続的な割引と単発の割引で個別に設定できます。永久割引は常に差し引かれます。

いつから購読者としてカウントするか。 Stripeでは、最初の請求期間の開始時、または最初の支払いの受領時のいずれかを選択できます。一般的には、前者のオプションが最も多く使われています。

数式を書き始める前に、これら3つのルールをシートに明記しておきましょう。これらを明確にしておくことが、不毛な議論を避け、信頼できるレポートを作成するための鍵となります。

計算自体が簡単である理由

月換算（標準化）の計算はシンプルです。Stripeの具体的な計算例では、100ドルの月次プランの購読者が100人、600ドルの年次プランの購読者が50人いる場合、(100 × 100) + (50 × (600 / 12)) = 12,500ドルとなります。

複雑なのは「除外対象」であり、これらはスプレッドシートで見落とされがちです。

税金は除外。 StripeはMRRから税金を除外しています。エクスポートデータに税込金額が含まれている場合、毎月の数値を過大評価することになります。

トライアルは除外。 トライアル期間中のサブスクリプションは、有料プランに移行するまで除外されます。

無料プランは除外。 0円のプランを利用している購読者は収益を生まないため、アクティブな購読者としてもカウントされません。

従量課金制の収益は除外。 これは多くの人が驚く点です。従量課金制の製品はMRRから完全に除外されるため、一部に従量課金を導入しているビジネスでは、設計上、MRRが実際の収益を下回ることになります。

また、クーポンに関するケースもあります。これはドキュメントに記載されていますが、直感に反する仕様です。購読者のMRRが0になった場合、その購読者はその期間にチャーン（解約）したものとして扱われます。

100%割引クーポンを適用すると、まさにこの現象が起きます。後でクーポンを削除すると、その購読者は再びアクティブになり、「リアクティベーション（再活性化）」として表示されます。

つまり、顧客が一人も離脱していなくても、プロモーションによってレポート上でチャーンが発生する可能性があるのです。

手動で行う方法

オプション 1：インターバルを月換算し、月ごとに集計する

月換算の金額列を追加します。年次金額を12で割り、週次金額には約4.33を掛け、月次金額はそのままにします。

次に、ステータスでフィルタリングしながら、SUMIFS関数を使って月ごとに集計します。レポートの対象となる月末日を作成するには、EOMONTH関数を使用します。

MRRは、今日時点ではなく、月末時点の数値として報告してください。Stripeからダウンロードできるレポートは、明示的に「月末時点における各購読者のMRR」となっており、この慣例に合わせることで、後々のデータ照合の手間を省くことができます。

この方法の限界は、履歴の追跡にあります。当月の数値はきれいに算出できますが、なぜその数値に変動したのかという理由までは分かりません。

オプション 2：変動要因の列を作成する

これこそが、レポートを有用なものにする方法です。数値の変動を、新規、再活性化、拡大、縮小、チャーンに分解します。

Stripeにおける成長の定義は、「期首の数値 ＋ 新規 ＋ 再活性化 ＋ 拡大 － 縮小 － チャーン」に為替レートの調整を加えたものです。Stripeの計算例では、まさにこれらの要素を経て、1,000ドルから1,045ドルへの推移が示されています。

最後の項目に注意してください。他通貨で支払う顧客がいる場合、為替の影響を処理しない限り、単純な数式モデルだけでは数値が一致しません。

複数通貨の取り扱いには、もう一つ知っておくべき影響があります。Stripeによると、サブスクリプション収益が複数の通貨で処理されている場合、製品や価格によるフィルタリングやグループ化は利用できなくなります。

この方法の限界は、メンテナンスの手間です。変動要因の列を作成するには前期のスナップショットが必要になるため、先月のデータのコピーを常に手元に残し続ける必要があります。

オプション 3：請求システムから変動データを直接取得する

ほとんどの請求プラットフォームでは、変動データをエクスポートできます。Stripeは、月別の購読者ごとのMRR、サブスクリプション指標のサマリー、およびすべての顧客のMRR変動ログの3つのCSVを提供しています。

取得すべきなのは、この3つ目のファイルです。これにより、オプション2における最も困難な作業が不要になります。

なお、指標の定義を変更した場合、反映までに時間がかかることがあります。Stripeは、設定の変更が反映されるまでに24〜48時間かかると説明しています。

共通する限界。 これら3つの方法はすべてMRRの算出にとどまります。これをARR、ARPU、チャーン、リテンション（維持率）へと展開するには、同じテーブルの上にさらに別の定義や判断を重ねる必要があります。

手動ルートの作業効率が落ちる理由

最初の月は半日ほどで終わるかもしれません。しかし、4ヶ月目になるとさらに時間がかかるようになります。それは、データが複雑になったからではありません。

その頃には、ワークブックの中に「アクティブ」の定義が2つ混在し、手動で修正された為替列が存在し、誰も触りたがらない変動要因タブができあがっているからです。

派生する指標が問題をさらに複雑にします。ARPUは総MRRをアクティブな購読者数で割ったものです。LTV（顧客生涯価値）はARPUをチャーンレートで割ったものです。

チャーンレートにも罠があります。Stripeの分母は「30日前にアクティブだった購読者 ＋ その期間中に追加された新規購読者」であり、計算式は 100 / (1000 + 100) = 9.1% となります。期首の件数だけで割るスナップショット的なスプレッドシートでは、これよりも高い数値が算出されてしまいます。

リテンション（維持率）も予想外の動きをします。コホート内での拡大がチャーンを上回るため、売上リテンションは100%を超えることがあります。

これら自体は難しいことではありません。It is just five judgement calls that have to be made identically every month, by whoever happens to be building the report.

Powerdrill Bloomでレポートを作成する方法

ステップ 1：サブスクリプションのエクスポートデータをアップロードする

サブスクリプションのCSV、またはサブスクリプションと変動データのファイルを一緒にアップロードします。Powerdrill Bloomはアップロード時に対象列をプロファイリングするため、集計が計算される前に、インターバルの欠落、金額の空白、重複したサブスクリプションIDなどを検出できます。

ステップ 2：自然言語で定義を指定する

数式を構築するのではなく、ルールを言葉で説明します。どのステータスをカウントするか、金額は割引適用後のものか、どの月末を報告対象とするかを指示します。

同時に、データのチェックも依頼できます。想定外のインターバルを持つ行や、割引適用後に0になっているサブスクリプションを特定させたり、月次の合計値が請求サマリーと一致しているかを確認させたりすることができます。

ステップ 3：チャート、レポート、またはスライドをエクスポートする

月次の推移、要素別の変動テーブル、あるいは数値と定義が記載された役員会向けのそのまま使えるスライドなどを出力します。

毎月作り直すよりも優れている理由

	手動ルート	Powerdrill Bloom
年次プランの月換算	ファイルごとに関数列を追加	アップロードしてルールを指定するだけ
変動要因の分解	前月のスナップショットの管理が必要	構成要素の出力を指示するだけ
トライアルや従量課金行の除外	毎回の作業で手動フィルターを適用	除外対象を指定するだけ
請求サマリーとの照合	手動での確認	合計が一致するか確認を指示するだけ

表の中ほどにある作業こそが、多くの時間を費やす原因です。列の合計を計算すること自体は大変ではありません。大変なのは、何ヶ月にもわたって5つの定義を一貫して維持し続けることなのです。

よくある間違い

サブスクリプションではなくインボイスを集計している。 インボイスには単発の請求や日割り計算が含まれます。継続収益は、請求書ではなくサブスクリプションに紐づく属性です。

金額に税金を含めたままにしている。 税金は毎月の数値を膨らませるだけで、相殺されることはありません。月換算する前に税金を除外してください。

トライアルを収益としてカウントしている。 トライアル期間中にはまだ継続的な収益は発生していません。これを含めると、翌月の成長を前借りすることになります。

断りなくMRRの12倍をARRとして扱っている。 ARRは月換算された年間ランレートであり、実際に回収された現金ではありません。受注額と誤解されないよう、適切にラベルを貼ってください。

クーポンによるチャーン効果を無視している。 全額割引を適用すると購読者のMRRは0になり、チャーンとして処理されます。後から説明に追われないよう、あらかじめこれらの行にフラグを立てておきましょう。

期首の件数でチャーンを割っている。 ドキュメントに記載されている分母には、その期間中に追加された購読者が含まれます。この2つの計算方法では、同じデータであっても異なる比率が算出されます。

毎月ゼロから作り直している。 変わるのはエクスポートデータだけであり、定義は変わりません。ルールはそのまま維持し、ファイルだけを差し替えるようにしましょう。これは予算対実績レポートを作成する際と同じ原則です。

結論

ステータスリストを確定させ、割引の扱いを決め、インターバルを月換算し、月末時点の数値として報告する。この4つのステップを踏むことで、財務部門からの質問にも耐えうるMRRレポートを作成できます。

コストがかかるのは集計作業ではありません。エクスポートデータの形が変わる中で、毎月5つの定義をブレずに維持し続けることなのです。

もし月末の時間がそこに費やされているのであれば、サブスクリプションのエクスポートデータを使ってPowerdrill Bloomをお試しください。また、自社データからKPIターゲットを設定する方法に関するガイドもあわせてご覧ください。ツール面については、SaaSメトリクス追跡用のAIツールのまとめや、AI財務分析のページで紹介しています。

よくある質問

サブスクリプションのエクスポートデータからMRRを算出する数式は？

すべてのサブスクリプションを月換算の金額に標準化し、対象となるステータスのものを合算します。Stripeの例では、(100 × $100) + (50 × ($600 / 12)) = $12,500となります。

MRRをARRに変換するにはどうすればよいですか？

月次の数値に12を掛けます。年次プランは前払いで請求されるため、実際に回収された現金ではなく、月換算された年間ランレート（ARR）としてラベルを貼ってください。

従量課金制の収益は含めるべきですか？

Stripeは従量課金制の製品をMRRから除外しています。収益の大部分が従量課金に基づいている場合は、MRRに含めるのではなく、別個の項目として報告してください。

どのサブスクリプションステータスがアクティブとしてカウントされますか？

ドキュメント上のデフォルトは、activeとpast_dueです。キャンセルおよび未払いのサブスクリプションはチャーンとして扱われ、合計から除外されます。

チャーンレートが請求ダッシュボードの数値と異なるのはなぜですか？

最も多い原因は分母の違いです。ドキュメントに記載されている計算方法では、「30日前にアクティブだった購読者 ＋ その期間中に追加された新規購読者」で割るようになっています。