概要
ZuoraのProduct Catalogは「Product → Rate Plan → Charge」の3層構造で、複雑なサブスクリプションの課金ロジックを設定として表現します。
- 従来の商品マスタとは根本的に設計思想が異なる
- ChargeのタイプとModelの組み合わせで、あらゆる課金パターンを表現できる
- 課金開始タイミング・日割り計算・会計連携まで、Chargeレベルで細かく制御できる
なぜProduct Catalogが「普通の商品マスタ」と違うのか
SaaSの「売り物」は価格モデルそのもの。従来の商品マスタの考え方では、サブスクリプション特有の複雑さを表現できません。
ERPやCRMにも「商品マスタ」と呼ばれるものはあります。しかしZuoraのProduct Catalogは、それらとは根本的に異なる思想で設計されています。
従来の商品マスタは「モノを売る」ために作られています。商品コード・商品名・単価の3点セットがあれば十分で、「このモノを1個いくらで売る」という情報を管理するためのものです。
ZuoraのProduct Catalogが解決しようとしている問題はまったく違います。SaaSのようなサブスクリプションビジネスでは、同じ「商品」を売っていても、顧客ごとに以下のような複雑さが発生します。
- 初月だけ初期費用がかかる
- 月額料金と、使った分だけ課金される従量料金が混在する
- 同じ商品でも「月払いプラン」と「年払いプラン」がある
- 途中でプランをアップグレードすると料金が変わる
これを「商品コード＋単価」の1行で表現しようとすると、プランの数だけ商品コードが増殖し、管理が破綻します。実際、既存のシステムで無理やりサブスクを管理しようとした企業が「コードが数千行になって誰も把握できない」という状況に陥るのはよくあるケースです。
ZuoraのProduct Catalogは、この問題を「商品と価格を分離する」という設計思想で解決します。「何を売るか（Product）」「どういう料金体系で売るか（Rate Plan）」「個々の料金はどう計算するか（Charge）」の3層に分けることで、複雑な課金ロジックを整理された構造で表現できるようにしています。
従来の商品マスタ：プランの数だけ商品コードが増える
ZuoraのProduct Catalog：1つのProductに料金体系がぶら下がる
柔軟なProduct Catalogがもたらすメリット
Product Catalogを柔軟に設計することで、ビジネスの変化に素早く対応できるようになります。
柔軟で設定可能なProduct Catalogを持つことで、サブスクリプションビジネスは以下のことを実現できます。
| メリット | 内容 |
|---|---|
| 価格・パッケージ戦略の迅速な変更 | 新プランや割引キャンペーンをすぐにCatalogに追加できる |
| 国際市場への展開 | 多通貨・地域別料金体系をCatalog内で管理できる |
| 新製品ローンチ時間の短縮 | テンプレートとなるRate Planを複製して素早く展開できる |
| 会計・収益情報の正確な計算 | ChargeごとにAccounting Codeと収益認識ルールを紐づけることで自動仕訳が可能 |
3層構造：Product / Rate Plan / Charge
3層のそれぞれが「何を売るか」「どう売るか」「いくら請求するか」を分担することで、複雑な課金体系を整理された構造で管理できます。
Product（プロダクト）
会社が販売するサービスそのものを表します。「クラウドストレージ」「分析ツール」のような単位で、カタログ上の「商品のくくり」です。顧客が選ぶのはProductではなく、その下のRate Planです。Productは複数のRate Planをグループ化するコンテナの役割を担います。
Product Rate Planには**有効期間（Effective Start / End Date）**を設定でき、Rate PlanのEffective期間は親ProductのEffective期間内に収める必要があります。
Rate Plan（レートプラン）
「どういう料金体系で買うか」を表します。顧客が実際に選ぶのはこの層です。たとえば「月払いプラン」「年払いプラン」「エンタープライズプラン」がそれぞれ1つのRate Planになります。1つのProductに複数のRate Planを持てるため、同じサービスを異なる料金体系で販売できます。
Product Catalog上のRate Plan（テンプレート）は、顧客が契約するとSubscription Rate Plan（インスタンス）としてコピーされます。
この仕組みのおかげで、Product Catalogを変更しても既存のSubscriptionには影響しません。Product Catalog側で価格や条件を更新しても、すでに契約している顧客のSubscription Rate Planはそのまま維持されます。既存顧客への変更を反映したい場合は、Amendmentという明示的な操作が必要です。
Charge（チャージ）
「実際にいくら請求するか」の計算ルールを表します。1つのRate Planに複数のChargeを持てるため、「初期費用＋月額料金＋従量料金」のように異なる性質の料金を組み合わせられます。
3層の責任分界を整理するとこうなります。
Chargeの3タイプ：いつ課金するかを決める
ChargeのタイプはOne-time・Recurring・Usageの3種類。「いつ課金が発生するか」によって使い分けます。
| タイプ | 課金タイミング | 典型的な用途 |
|---|---|---|
| One-time | 1回だけ | 初期費用・セットアップ費用・解約違約金 |
| Recurring | 一定周期で繰り返し | 月額・年額の基本料金 |
| Usage | 使った量に応じて後払い | API呼び出し回数・ストレージ使用量・通話時間 |
重要なのは、これらを1つのRate Planに組み合わせられる点です。「契約時に初期費用（One-time）、毎月の基本料金（Recurring）、使った分だけの従量料金（Usage）」を1つのRate Planとして束ねられます。
Billing Period（Recurringの請求周期）
Recurring Chargeの「月払いと年払いの違い」はBilling Periodで設定します。
Recurring Chargeには請求周期（Billing Period）を設定する必要があります。同じProductに「月払いプラン」と「年払いプラン」が別のRate Planとして並んでいるのは、Billing Periodが異なるためです。
| Billing Period | 説明 | 典型的なユースケース |
|---|---|---|
| Monthly | 毎月1回請求 | 一般的なSaaSの月額プラン |
| Quarterly | 3ヶ月ごとに請求 | 四半期契約 |
| Semi-Annual | 6ヶ月ごとに請求 | 半期契約 |
| Annual | 1年ごとに請求 | 年払い割引プラン |
| Specific Months | 指定月数ごと | 2年・3年契約のカスタムサイクル |
「月払いプラン（Monthly）」と「年払いプラン（Annual）」は別のRate Planとして作成するのが基本設計です。それぞれのRate PlanにRecurring Chargeを持たせ、Billing Periodと金額を変えることで、「月払いは¥1,200/月、年払いは¥12,000/年（2ヶ月分お得）」という構成を表現します。
Usage Rating Option（Usageの集計タイミング）
UsageチャージはBill Runの前に「いつUsageを集計するか」を設定で決めます。
| Rating Option | 集計タイミング | 使いどころ |
|---|---|---|
| End of Billing Period | 請求期間の終わりに一括で集計 | 通常の月次従量請求 |
| On Demand | ロード後の次のBill Runで即時集計 | 解約後の最終請求など、即時反映が必要なケース |
Cotermination — 複数契約の終了日を揃える
Coterminationとは、途中から追加した契約やオプションの終了日を、既存契約の終了日に合わせて揃える設計です。
たとえば1月1日〜12月31日の年次契約がある顧客に、7月1日からオプションを追加する場合を考えます。
既存契約（年次）
1月1日 ─────────────────── 12月31日
オプション（Coterminationなし）
7月1日 ──────────────────── 翌6月30日（1年間）
オプション（Coterminationあり）
7月1日 ────── 12月31日（既存契約に合わせて短縮）
Coterminationを使う主な理由は契約管理の単純化です。終了日がバラバラだと「どの契約がいつ終わるか」の管理が煩雑になります。B2Bの法人契約では「すべての契約を一括で更新・解約したい」という要件がよくあるため、Coterminationで終了日を揃えておくのが自然な設計になります。
Charge Modelの選び方：どう計算するかを決める
ChargeのタイプとModelの組み合わせで1つのChargeが完成します。タイプが「いつ課金するか」、Modelが「どう金額を計算するか」を決めます。
全Charge Modelの一覧
| Charge Model | 対応タイプ | 計算方法 | 向いているケース |
|---|---|---|---|
| Flat Fee | One-time / Recurring / Usage | 数量に関係なく固定金額 | 月額固定のSaaSプラン |
| Per Unit | One-time / Recurring / Usage | 数量 × 単価 | シート数・ライセンス数で課金 |
| Volume | One-time / Recurring / Usage | 到達した数量帯の単価を全数量に適用 | 大口顧客に割引を提供したい |
| Tiered | One-time / Recurring / Usage | 数量の段階ごとに異なる単価を積み上げ | 使えば使うほど段階的に単価が下がる |
| Overage | Usage専用 | 基本料金に含まれる上限を超えた分だけ追加課金 | 「月100GBまで定額、超過分は¥10/GB」 |
| Tiered with Overage | Usage専用 | Tiered構造＋最終帯を超えた分にOverage課金 | 段階単価＋超過分の組み合わせ |
| High Water Mark | Usage専用 | 請求期間中の「最高値の日」の使用量だけで課金 | データストレージ容量など最大値で課金したい |
| Overage Smoothing | Usage専用 | 複数期間にわたって超過分を平滑化 | 月ごとの使用量スパイクを緩和したい |
| Multi-Attribute | One-time / Recurring / Usage | 複数の属性（例：地域×品質）を組み合わせてフォーミュラで単価を決定 | 複合条件で単価が変わる複雑な課金 |
| Discount | One-time / Recurring / Usage | 同じRate Plan内の他のChargeに対して割引を適用 | キャンペーン割引・長期契約割引 |
VolumeとTieredの計算の違い
VolumeとTieredは似ていますが、計算方法が異なります。
タイプとModelの組み合わせ例
タイプが「課金の発生タイミング」、Modelが「金額の計算方法」で、この2軸の組み合わせで1つのChargeが決まります。
| Charge名 | タイプ | Model | 意味 |
|---|---|---|---|
| 初期費用 | One-time | Flat Fee | 契約時に¥5,000を1回だけ請求 |
| 月額基本料 | Recurring | Flat Fee | 毎月¥1,000を固定で請求 |
| シート料金 | Recurring | Per Unit | 毎月「シート数 × ¥500」を請求 |
| ストレージ従量 | Usage | Tiered | 使った量を段階単価で翌月請求 |
| 超過通信費 | Usage | Overage | 上限を超えた分だけ翌月請求 |
1つのRate Planにこれらを複数組み合わせることで、「初期費用＋月額固定＋シート数＋使った分」という複合的な料金体系を1つのプランとして表現できます。
Overageの計算例
OverageはRate Planに含まれる使用量上限（Included Units）を超えた分だけ追加課金します。
たとえば「月100GBまで¥1,000、超過分は¥10/GB」というプランをOverageで設定した場合、実際の請求は以下のようになります。
月 80GB使用 → ¥1,000（上限内のため超過なし）
月100GB使用 → ¥1,000（上限ちょうどのため超過なし）
月150GB使用 → ¥1,000 + (150 - 100) × ¥10 = ¥1,500
月200GB使用 → ¥1,000 + (200 - 100) × ¥10 = ¥2,000
High Water Mark Pricing — 最高値の日で課金する
High Water Mark PricingはUsage専用モデルで、請求期間中に最も使用量が多かった1日の値だけを使って課金計算を行います。累積合計ではなく「最高値の日」がベースになる点がTiered/Volumeとの根本的な違いです。
| 通常のVolume/Tiered | High Water Mark | |
|---|---|---|
| 計算の基準 | 期間中の累積合計使用量 | 期間中の最高値の1日の使用量 |
| 向いているケース | API呼び出し回数・データ転送量 | データストレージ容量（最大保持量が重要） |
| 単価の適用方法 | Volume または Tiered を選べる | Volume または Tiered を選べる |
Overage Smoothing — スパイクを平滑化する
月ごとに使用量が大きく変動するビジネスでは、ある月だけ超過料金が急増するという問題が起きます。Overage Smoothingは複数期間の使用量を考慮することでこのスパイクを緩和するモデルです。
2つのSmoothing方式があります。
| 方式 | 仕組み | 特徴 |
|---|---|---|
| Rolling Window | 直近N期間の使用量の合計で超過を判定 | 未使用分が翌期間に持ち越される |
| Rollover | 固定N期間ごとに使用量をリセットして判定 | 設定した固定周期でリセットされる |
Multi-Attribute Pricing — フォーミュラで単価を決定する
Multi-Attribute PricingはOne-time・Recurring・Usage全タイプに対応しており、複数の属性をフォーミュラで組み合わせて単価を計算します。
一般的なCharge Modelは「数量」だけを基準に金額を計算しますが、Multi-Attribute Pricingは「地域」「品質」「車種」などの複数属性を組み合わせた複雑な価格計算が可能です。価格はPrice Formulaフィールドに数式を記述して定義します。
フォーミュラでは四則演算（+, -, /, *, ^）とカッコによる優先制御に加え、以下の関数を使用できます。
| 関数 | 用途 |
|---|---|
usageQuantity() | 現在のUsageレコードの数量を返す（Usageチャージのみ） |
fieldLookup("object", "field") | Account・Subscription・Usageオブジェクトの任意フィールドの値を参照する |
objectLookup("CustomObj", "field", [conditions]) | カスタムオブジェクトをルックアップして値を参照する |
min(arg1, arg2, …) | 複数の数値の中から最小値を返す |
max(arg1, arg2, …) | 複数の数値の中から最大値を返す |
フォーミュラの例（レンタカー課金）：
usageQuantity() * objectLookup("CarRental", "multiplier__c",
["type__c" = fieldLookup("usage.type__c"),
"state__c" = fieldLookup("usage.state__c")])
この例では、Usageレコードの「車種」と「州」の組み合わせをカスタムオブジェクト（CarRental）からルックアップし、対応する乗数をかけて料金を算出しています。
Discount Chargeの具体例
Discount ChargeはOne-time・Recurring・Usage全タイプのChargeに対してパーセントまたはAmountで割引を適用します。
割引の方法は2種類あります。
| 割引タイプ | 設定方法 | 例 |
|---|---|---|
| Percentage Discount | 割合で指定 | 10%オフ → ¥2,000の月額なら¥200引き |
| Amount Discount | 固定金額で指定 | ¥300オフ → 金額に関わらず¥300引き |
適用対象はChargeレベルで柔軟に制御できます。「この割引は月額料金のみに適用する」「すべてのChargeに適用する」など、Discount Chargeを作るときに適用先を指定します。
Trigger Condition：課金を「いつ始めるか」を制御する
課金開始のトリガーは「契約・開通・承認・特定日」の4種類のビジネスイベントから選べます。ChargeごとにTrigger Conditionを設定できるので、同じプランの中でも料金の種類によって課金開始タイミングを変えられます。
Rate PlanとChargeで「何をいくらで売るか」が決まりました。次の問いは「いつから課金を始めるか」です。
SaaSの契約では、「契約書にサインした日」「実際にシステムが使えるようになった日」「顧客が正式に受け入れた日」がバラバラになることがよくあります。Trigger Conditionは、これらのビジネスイベントのどれを課金開始のトリガーにするかを設定するものです。
| Trigger Condition | 課金開始タイミング | 典型的なケース |
|---|---|---|
| Upon Contract Effective | 契約が成立した日 | 契約と同時に課金開始でよいシンプルなケース |
| Upon Service Activation | サービスが開通した日 | 開通工事や環境構築が必要なケース |
| Upon Customer Acceptance | 顧客が受け入れた日 | 検収期間がある受託型・エンタープライズ契約 |
| Upon Specific Date | 指定した日付 | キャンペーン開始日など任意の日付 |
重要なのは、同じRate Plan内のChargeごとに異なるTrigger Conditionを設定できる点です。たとえば「初期費用は契約日から、月額料金はサービス開通日から」という設定が可能です。
Proration：月の途中の変更を日割りで計算する
Prorationは「請求サイクルの途中でChargeの内容が変わったとき」に自動で日割り計算する仕組みです。ChargeレベルでオンオフできるのでChargeの性質に合わせて制御します。
Proration（按分計算）とは、月の途中でプランが変わったときに、使った日数分だけ料金を計算する仕組みです。「按分」という会計用語が出てきますが、要は「日割り計算」のことです。
たとえば月額¥3,000のプランに月の途中（15日）から加入した場合、その月は半分しか使っていないので¥1,500だけ請求するのが自然です。これをZuoraが自動で計算してくれるのがProrationです。
Prorationが発生するのは主に以下のケースです。
| ケース | 何が起きるか |
|---|---|
| 月の途中で新規契約 | 契約日〜月末までの日割り料金を請求 |
| 月の途中でプランをアップグレード | 旧プランの残り日数分をクレジット、新プランの残り日数分を請求 |
| 月の途中でプランをダウングレード | 同上（差額を次回請求に充当） |
| 月の途中で解約 | 解約日までの日割り料金を請求（設定による） |
請求日を毎月1日に固定しているサービスでは、月の途中に起きる契約・変更・解約の都度、次の1日時点で日割り計算が発生します。請求日を固定しているサービスほどProrationが頻繁に発生するため、設計時に意識しておく必要があります。
Prorationを活用することで以下のメリットが得られます。
| メリット | 内容 |
|---|---|
| 売上の取りはぐれを防ぐ | 請求期間の途中から課金することで、使った分の料金を確実に回収できる |
| 製品ごとの正確な課金 | ChargeごとにProration設定を変えることで、初期費用は日割りせず月額料金だけ日割りするといった柔軟な制御が可能 |
設定前に準備すること
Product Catalogの設定を始める前に、経理チームと「会計コード」と「収益認識ルール」を決めておく必要があります。後から変更すると過去の請求データへの影響が生じます。
Product Catalogを設定する前に、Zuora外で決めておくべきことが2つあります。どちらも「Chargeを作るときに必ず入力を求められる項目」なので、後回しにすると設定が止まります。
Chargeを設定する前に用意すべき4つの前提設定：
| 前提設定 | 内容 |
|---|---|
| Chart of Accounts / Accounting Codes | どの勘定科目（GL番号）に請求を紐づけるか |
| Revenue Recognition Codes | 収益認識に使う分類コード |
| Accounting Rules | 会計処理のルール定義 |
| Revenue Recognition Rules | 売上をいつ・どう計上するかのルール |
この4つはProduct Rate Plan Chargeに紐づけるため、Catalog設定を始める前に経理チームと確定させておきます。
会計コード（Accounting Code）
会計コードとは、売上をどの勘定科目に分類するかを示すコードです。たとえば「月額サブスクの売上」と「初期費用の売上」を別々の勘定科目で管理したい場合、それぞれ異なる会計コードをChargeに紐付けます。
Zuoraは請求書を発行するたびに、このコードをもとに会計システムへの仕訳データを自動生成します。コードが設定されていないと、経理側で手動で仕分け直す作業が発生します。
収益認識ルール（Revenue Recognition Rule）
収益認識とは「売上をいつ計上するか」のルールです。たとえば年間契約で¥120,000を一括で受け取っても、会計上は毎月¥10,000ずつ売上として計上するのが原則です（サービスを提供した月に売上を立てる）。
ZuoraはChargeに収益認識ルールを紐付けることで、入金タイミングと売上計上タイミングを自動的に分けて管理します。