サブスクリプション vs 従量課金：最初から何を保存するか

なぜ価格モデルにデータ設計が必要か

価格は単なるウェブページではありません。どのデータを記録するか、どう報告するか、数か月後に請求を説明できるかどうかを決めます。サブスクリプションと従量課金を選ぶということは、課金データの形を決めるということでもあります。

単純なサブスクリプションは、プラン、請求期間、開始日、割引などの数個の事実から計算できることが多いです。従量課金はそれより多くの情報を必要とします：何が使われたか、いつ起きたか、どの顧客に属するか、その使用がどう金額に変わるか。これらの記録がなければ請求書を送ることはできても、正当性を説明することはできません。

後から使用量を追加すると計画がない場合、よく次の三点で壊れます：

• 信頼できる使用履歴がないため、顧客が請求を争う
• チームごとに「使用」の定義が違い、分析が推測になる
• 元データが欠けている、または上書きされているため経理が監査できない

目標は地味ですが必須です：いつでも同じ請求書を同じ方法で計算できること。つまり保存した事実（プラン条件、メータールール、使用イベント、その時点で適用された正確な価格バージョン）から計算を再生できるようにすることです。

「モデリングの視点」とは、エンジニアでなくても課金を構成要素として記述することです。例えばチームチャット製品を想像してください：

• サブスクリプション：ワークスペースあたり月額$99
• 使用：50,000メッセージを超えた分はメッセージあたり$0.01

後でこれをサポートするために、データは次の質問に答えられる必要があります：どのワークスペースか、どの月か、メッセージ数はいくつか、何が含まれていたか、どの価格ルールが有効だったか。

サブスクリプションと従量課金：実務上の違い

サブスクリプションは利用権への対価を請求し、従量課金は消費に対して請求します。アップグレード、ダウングレード、按分（プローション）、実際のエッジケースが出てくると振る舞いは大きく異なります。

サブスクリプションの場合、重要な問いは「顧客がこの期間に製品を利用する権利があったか」です。主にプラン、シート数、請求期間、請求が支払われたかどうかを追跡します。使用は重要ではありますが、多くの場合は行としてではなく制限（ソフト/ハード）として現れます。

従量課金では、重要な問いが「何が、正確に、いつ起きたか」になります。信頼できるメータリング、いつ使用がカウントされるかの明確なルール、そして後で各請求を説明する方法が必要です。UIが「1,243 APIコール」のように一つの数値を示していても、その背後には一連のイベントがあり、一貫性があり監査可能でなければなりません。

多くのB2B SaaSチームはハイブリッド価格、つまりバンドルをカバーする基本料金と超過分という組み合わせに落ち着きます。

よくあるハイブリッドのパターン

ほとんどのハイブリッドモデルは以下のような形に収まります：

• 基本プラットフォーム料金＋席ごとの課金
• 基本料金＋含まれる単位（メッセージ、タスク、APIコール）＋超過単価
• 階層化プラン＋使用のアドオン（有効化時のみ請求）
• 最低コミット＋使用クレジットの取り崩し

予測可能性は、顧客が予算承認や安定した月次支出を必要とする場合に役立ちます。従量課金は価値が活動に応じて増減する場合（例：「処理した請求書ごと」）や、顧客が試用してリスクを低くしたい場合に向いています。

プラン変更は確実に発生します。価格、バンドル、パッケージングは変わります。請求を設計する際は、新しいメーターを追加したり、新しい階層を導入したり、「含まれる」の意味を変更しても履歴を書き換えなくて済むようにしてください。実用的なルール：請求時点での顧客のプランと価格条件を、その時点の状態として保存しておくことです（現在の状態だけを保存しない）。

信頼して計測できるメーターを定義する

メーターとは、課金する対象を明確に書き下したもので、二人が数えれば同じ数になるようなものです。構成はイベント（何が起きたか）、単位（何を数えるか）、タイミング（いつカウントするか）の三つです。

多くの紛争はここから始まります。一方は成果に対して請求していると思い込み、もう一方は測定可能な活動に対して請求していることがあります。

メーターを曖昧にしない

実際のプロダクト操作に紐づき自動で記録できるメーターを選んでください。よくある例：

• シート（ログイン可能なアクティブユーザー）
• APIコール（成功リクエスト、あるいは全リクエスト）
• ストレージ（ある時点のGB、または期間平均）
• メッセージ（送信、配信、開封など）
• コンピュート分（ジョブが動いている時間）

次に、何がカウントされ何がカウントされないかを定義します。APIコールで課金するなら、リトライをカウントするか、4xx/5xxをカウントするか、社内の統合からの内部コールをカウントするかを決めてください。

タイミングは単位と同じくらい重要です。シートは請求期間ごとの時点スナップショットが向くことが多いです。APIコールはウィンドウ内で合算するのが普通です。ストレージは曲者で、顧客は「どれだけ保存したか」に対して支払うことを期待するため、ピークではなく期間平均を使うことが多いです。

またスコープ（アカウント単位かワークスペース/プロジェクト単位か）も決めてください。チームごとに別請求できるなら、メーターはワークスペース単位にする、というシンプルなルールがあります。

限度、階層、利用権（エンタイトルメント）

利用権は顧客が購入によって何をできるかを定めるルールです。何人のユーザーを追加できるか、どの機能が有効か、月あたりどの程度のボリュームが許されるかなどに答えます。利用権はアクセスと課金のあいだに位置し、プロダクトが許可することを形作り、メータリングは実際に何が起きたかを記録します。

利用権はメータリングロジックと分けて保存してください。利用権は読み取り可能で安定しているべきです（プラン、アドオン、契約条件）。メータリングはプロダクトの進化に合わせて増えたり変わったりするので、メーター変更がアクセスを壊さないようにしたいです。

ハードリミット、ソフトリミット、超過課金はUIでは似て見えることがありますが、挙動は異なります：

• ハードリミットは上限到達後に操作をブロックする
• ソフトリミットは警告して許可する
• 超過課金は許可して追加料金を請求する
• グレース期間は一時的にハードリミットをソフトリミットのように扱う
• トライアルやフリーティアは利用権を適用するが、価格は日付や閾値まで通常はゼロである

上限超過時の挙動を事前に決めてください。例：スターターティアはシート5、APIコール10,000／月を含む。6人目を招待したらブロックしますか、追加シートごとに課金しますか、7日間は猶予しますか？各選択は請求書とサポートログに示せるルールである必要があります。

利用権は時間バウンドのレコードとして保存してください：顧客、プランまたはアドオン、開始／終了タイムスタンプ、制限値、強制モード（ハード／ソフト／超過）。これでアクセス判断と請求判断が一貫します。

監査可能な請求書と請求期間

請求書は単なるPDFではなく、誰に、何を、どの期間、どのルールのもとで請求したかに答える監査証跡です。価格を変更しても、過去の請求書を正確に再構築できるべきです。

最初にいくつかのコアレコードを用意してください：顧客、サブスクリプション（または契約）、請求期間、そして行アイテム付きの請求書。各行アイテムはそのソースに紐づくべきです：プラン料金、使用の要約、または一時的な課金。これが請求を説明可能にする鍵です。

請求期間にはアンカーとタイムゾーンが必要です。「月次」だけでは足りません。サイクルのアンカーデート（例：15日00:00）と期間を区切るために使うタイムゾーンを保存してください。これを一貫して扱わないとサマータイム周りで1日ずれる問題が発生します。

監査可能な請求書には通常次の要素が必要です：

• 各請求書と行アイテムに対する period_start と period_end
• その請求書に使われた価格バージョン（プラン／価格ID）
• 不変の合計：小計、税、割引、請求額、通貨
• 従量課金行アイテムの正確な使用ウィンドウ
• 外部決済参照（決済プロセッサのチャージID）を該当する場合に含める

収益認識は請求と関連しますが同じではありません。前払のサブスクリプション料金は通常サービス期間にわたって認識され、使用は提供時に認識されることが多いです。高レベルにしていても後で対応できるように十分な日付を保存してください。

クレジットノート、返金、調整は第一級オブジェクトとして扱い、古い請求書を編集する形にしてはいけません。顧客が途中でアップグレードした場合は、元の請求書を参照する調整行やクレジットノートを作り、使用した按分ルールを明記してください。

請求書生成や支払い試行では冪等性キーが重要です。ジョブが二度実行されても請求書は一つ、課金は一つで、履歴が明確である必要があります。

按分（プローション）と期間途中の変更

期間途中の変更は請求上の議論が始まる場所です。誰かが20日にアップグレードし、1週間一時停止してからキャンセルしたら、それらの行為を請求書上で意味のある数値に変換するルールが必要です。

どの変更をいつ許可するかを決めてください。多くのチームはアップグレードを即時適用して顧客にすぐ価値を与え、ダウングレードは更新時に適用して複雑な返金を避けます。

説明できる按分ポリシーを選ぶ

按分は日単位、時間単位、あるいは按分しない、などがありえます。精度を上げるほどタイムスタンプ、丸めルール、エッジケースが増えるため、保存とテストが必要になります。

ポリシーを早めに固めてください：

• アップグレードは即時按分、ダウングレードは更新時に適用
• 日単位の按分（時間単位より簡単で十分なことが多い）
• 丸めルールを定義（例えばセント単位で切り上げ）
• 一時停止の挙動（時間をクレジットするか期間を延長するか）を決める
• キャンセル時の返金ポリシーを明確にする（全額、部分、なし）

按分を請求書行としてモデル化する

隠れた計算を避けてください。按分は請求書上の明示的な調整として表現します。新プランの残存時間に対する借方（デビット）や旧プランの未使用時間に対する貸方（クレジット）のように、それぞれの行を変更イベント（change_id）に紐づけ、按分ウィンドウ（start_at, end_at）、数量／時間基準、税カテゴリを含めてください。

メーターはさらに判断を必要とします：プラン変更時にメーターをリセットするか、累積を続けるか、セグメントに分けるか。シンプルで監査可能な方法はプランバージョンごとに使用をセグメントすることです。例：月の途中で10席から25席にアップグレードしたとき、使用イベントはそのまま保持し、評価（レーティング）は各イベントが発生した時点の利用権期間でグループ化します。

どこまで取り消し可能にするかを決めてください。使用イベントは受け入れ後は最終扱いにし、サブスクリプション変更は請求書確定まで取り消し可能にするなどのポリシーがあると便利です。変更イベントと請求調整を保存すれば、ルールが変わっても請求書をきれいに再生成できます。

最初から保存すべきデータ

顧客からのクレームが出てから課金データを設計すると推測で対応することになりがちです。サブスクリプション、従量課金、あるいはハイブリッドのどれを選んでも、最も安全な出発点は将来いつでも監査できる小さなデータセットです。

まずは明確な顧客階層を作ってください。B2B SaaSでは支払者は通常企業アカウントですが、使用はワークスペースやプロジェクト内で発生し、アクションは個々のユーザーから来ます。アカウント、ワークスペース、ユーザーの三層を保存し、誰が何をしたかを記録してください。課金紛争はよく「どのチームがやったのか？」に帰着します。

実際の請求書と調査を支える最小限の課金データベース設計：

• アカウントと組織構造：アカウント、ワークスペース（またはプロジェクト）、ユーザー、役割、請求連絡先、必要なら税関連フィールド
• サブスクリプション：プラン、ステータス、開始／終了日、更新設定、解約理由、開始時に適用された価格バージョン
• 価格カタログ：製品、プラン構成要素（基本料金、シート、メーター）、階層、通貨、有効日
• 使用メータリングデータ：タイムスタンプ、ワークスペース、ユーザー（可能なら）、メーター名、数量、一意の冪等性キーを含む追記専用のイベントログ
• 請求書アーティファクト：請求期間境界、行アイテム、合計、税／割引調整、使用した入力のスナップショット

速度のために集計カウンタに頼るのは構いませんが、イベントログをソース・オブ・トゥルースとして扱ってください。簡単なルール：イベントは不変、修正は新しいイベント（例：負の数量）、各イベントは特定のメーター定義に紐づく。

例：顧客が「先月APIコールが倍増した」と言った場合、ワークスペースと日別で生イベントを引ければどこでスパイクが発生したか、統合ループが原因かどうかを示せます。

ステップバイステップ：使用イベントから請求書まで

難しいのは数式ではなく、結果を数か月後でも説明できるようにすることです。プランや価格、顧客が変わった後でも説明できることが重要です。

1) 時間を遡れる価格カタログを用意する

製品、プラン、メーター、価格を有効日付きでセットアップしてください。古い価格は上書きしないでください。顧客が3月に請求されたなら、3月の計算は3月時点のカタログを使って再実行できる必要があります。

例：「API Calls」が4月1日から1回$0.002になった場合、3月の請求は旧レートを使うべきです。

2) 期間中に顧客が何を利用権として持っていたかをスナップショットする

各請求期間開始時（または変更発生時）に利用権スナップショットを保存してください：プラン、含まれる単位、制限、階層ルール、割引、税設定。これを「その期間に約束した内容」と考えてください。

3) 使用イベントを取り込み、早期に検証する

使用は不変のイベントとして到着させてください：タイムスタンプ、顧客、メーター、数量、重複除去用の一意ID。到着時に基本的な検証を行い（メーター欠如、負の数量、不可能なタイムスタンプなど）、未加工のイベントを記録してください。クリーン版を別に保存しても構いません。

その後、二段階で計算を行います：

• イベントを顧客／メーター／請求期間ごとに集計し（集計バージョンも保存）、
• カタログと利用権スナップショットを使って合計を金額に変換（レーティング）する

生成した請求書の行アイテムは、使った正確な入力（カタログバージョン、スナップショットID、集計ID）を参照するようにします。

最後に請求書をロックします。計算に使った入力と出力を保存し、確定済みの請求書は遅延イベントが来ても変更されないようにします。遅延イベントは次の請求書（または別の調整）に回し、明確な監査メモを残してください。

顧客と社内のレポートニーズ

顧客はあなたがサブスクリプションか従量課金かに興味があるわけではありません。彼らが望むのはあなたの数字が自分たちの期待と合っていること、そして次の請求を事前に予測できることです。

顧客向けレポートは、サポートチケットを作らずにいくつかの質問に答えられるシンプルな請求ホームが最良です：

• 私はどのプランで、何が含まれているか？
• 今期どれだけ使っていて、使用はどうカウントされるか？
• 私の制限は何で、超過したらどうなるか？
• 請求期間はいつ終わり、次の請求の推定額は？
• 過去の請求書と支払いはどこで見られるか？

社内的には、サポートと経理は単に数値を表示するだけでなく、その数字を説明できる必要があります。スパイクの発見、変化の追跡、プレビュー計算と確定請求の区別ができることが重要です。

請求プレビューは請求書と分けてください。プレビューは遅延使用が来たりメーター定義を修正したときに再計算できますが、請求書はそうではありません。

内部レポートは異常（急な使用増、負の使用、重複イベント）をフラグにし、生の使用とルールから請求行を再現でき、期間中のプラン変更と按分ルールを見られるようにしてください。

監査証跡は多くのチームが思う以上に重要です。顧客が「12日にアップグレードした」と言ったら、タイムスタンプ、実行者（ユーザー、管理者、自動化）、プランやシート、制限、メーター率の正確な前後値が必要です。

保存方針としては、生の使用イベントと確定済みの請求アーティファクトは長期保持してください。実務的なルール：請求額を変え得るもの、または紛争を弁護するのに役立つものは不変で保存する、です。

紛争を招く一般的な落とし穴

ほとんどの請求紛争は価格そのものではなく、請求書上の数値を説明できないこと、または同じ入力が後で違う合計を生むことから起きます。

よくある失敗は月次合計しか残さないことです。生イベントがなければ「どの日に閾値を超えたのか？」という簡単な質問にも答えられません。イベントを保持してから集計してください。

もう一つよくある問題は、メーターの意味を変えてそのバージョン管理をしていないことです。「アクティブユーザー」が最初は「少なくとも一度ログインしたユーザー」だったのに、後で「レコードを作成したユーザー」になったら、顧客は古い請求書と新しい請求書を比較して混乱します。メーター定義にバージョンを付けてください。

紛争は次のようなパターンから来ることが多いです：

• 利用権がUIだけで強制され、バックエンドは追加使用を許したり正しい使用をブロックしたりしている
• 一つのタイムスタンプフィールドを全部に使っている（イベント時間、取り込み時間、請求期間時間を区別していない）
• タイムゾーンを無視している（現地0:30の使用が誤って別の日や月に入る）
• 請求アンカーを忘れている（顧客によって1日請求する場合とサインアップ日請求する場合が混在）
• プラン、価格、制限変更の監査証跡がない

例：東京の顧客が月末の31日に現地時間でアップグレードしたとします。UTCタイムスタンプしか保存しておらず請求アンカーがないと、そのアップグレードがシステム上では30日に起きたように見え、按分や使用が誤った期間に入ってしまいます。

信頼を失う最短ルートは、古い請求書の計算を再現する方法がないことです。イベント、バージョン、アンカー、適用価格といった入力を保存しておけば、プロダクトが変わっても同じロジックを再実行して同じ結果が得られます。

出荷前の簡単チェックリスト

ローンチ前に一つのドリルを行ってください：ランダムな顧客を一人選び、保存したデータだけで最後の請求書を復元できるか試します。もし「当時のコードが何をしたかわからない」となるなら監査証跡が不足しています。

各メーターが曖昧でないことを確認してください。メーターは明確な単位（リクエスト、シート、GB、分）、信頼できる発信元（どのサービスが発行するか）、時間ウィンドウ（日ごと、請求期間ごと、カレンダ月ごと）を持つ必要があります。一文で説明できないメーターは顧客の信頼を失います。

多くの課金問題を発見する簡単なチェック：

• 保存した入力（プランバージョン、価格、使用合計、税、割引、按分パラメータ）から請求書を再生できる
• 使用イベントは追記専用、不変、重複排除されている（冪等性キーやイベントID）
• プランと価格変更は有効日付きでバージョン管理されている（古い価格は上書きしない）
• 按分ルールは文書化されテストされている
• サポートが保存された事実を使って「なぜ請求されたか」を短時間で答えられる

例：顧客が18日に10席から25席にアップグレードし、23日に使用閾値を超えた場合、システムは（1）各日付でどのプランバージョンが有効だったか、（2）席変更イベントのタイムスタンプ、（3）按分で使った数式、（4）最終合計に寄与した使用イベントを示せるべきです。

次のステップ：自分を袋小路に追い込まない実装

小さく始めてください、しかし曖昧には始めないでください。最も安全な道は、数か月後に「なぜこの金額を請求したのか？」に答えられる最小限のデータモデルです。

請求スキーマと管理画面のプロトタイプを最初に作って、最初の価格変更がある前に検討してください。販売チームが新しい階層や期間途中のアップグレードを要求してから対応すると、あちこちにパッチを入れることになりがちです。

実用的な分担は次の通りです：請求やレシート、支払い再試行はStripeに任せ、評価（使用を行アイテムにするロジック）は自社で持つ、という形です。つまり生の使用イベント、価格バージョン、請求プレビュー生成に使った計算結果を自分のシステムに保存します。

柔軟性を保ちながら素早くローンチするためのシンプルな計画：

• 測定可能な1〜2個のメーターを選ぶ（例：日ごとのアクティブシート、APIコール）
• 初日から価格ルールにバージョンを付ける（古い請求書が古いルールに合致するように）
• 使用状況、オーバーライド、クレジット、紛争を閲覧できる内部の課金管理パネルを作る
• 基本的な顧客ポータルビューを追加する：現在のプラン、今期の使用量、想定請求額
• すべての請求書を監査可能なスナップショットとして扱い、再計算された推測にしない

多くのカスタムバックオフィスコードを書かずに高速に進めたいなら、これらのエンティティをAppMasterでモデル化し、管理画面とポータル画面をそのビジュアルツールで作り、PostgreSQLをイベントと請求書のシステム・オブ・レコードとして使うことができます。

具体例：最初はシートメーターで開始します。3か月後にストレージGBを追加します。メーター、利用権、価格ルールがバージョン管理されていれば、新しいメーターを導入しても古い請求書を壊さず、サポートはどの行アイテムも数分で説明できます。