概要

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を持つことで、サブスクリプションビジネスは以下のことを実現できます。

価格戦略 — 顧客獲得と維持のための代表的な手法

柔軟なProduct Catalogがあるからこそ実現できる、顧客獲得・維持のための代表的な価格戦略が4つあります。

参考: How do I handle free trials in Zuora?

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という明示的な操作が必要です。

Grandfathering ― 旧価格のまま既存顧客を維持する

Grandfatheringとは、価格改定後も既存顧客だけを旧価格・旧プランのまま継続させることです。Rate Planのステータスを「新規販売は停止・更新のみ許可」に切り替えることで実現します。

たとえば月額プランを¥1,000から¥1,200に値上げする場合、既存顧客には¥1,000のまま契約を続けてもらい、新規顧客だけ¥1,200を適用したいケースがあります。この場合、旧Rate Planを削除せず「新規契約向けには非表示、既存顧客の更新には引き続き利用可能」という状態に設定します。

Charge（チャージ）

「実際にいくら請求するか」の計算ルールを表します。1つのRate Planに複数のChargeを持てるため、「初期費用＋月額料金＋従量料金」のように異なる性質の料金を組み合わせられます。

3層の責任分界を整理するとこうなります。

データモデルの拡張：FeatureとProductRatePlanChargeTier

公式データモデルは実際には6階層です。Product/Rate Plan/Chargeの3層に加えて、Chargeより上にFeature/ProductFeature、Chargeより下にChargeTierが存在します。

Chargeの3タイプ：いつ課金するかを決める

ChargeのタイプはOne-time・Recurring・Usageの3種類。「いつ課金が発生するか」によって使い分けます。

重要なのは、これらを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が異なるためです。

「月払いプラン（Monthly）」と「年払いプラン（Annual）」は別のRate Planとして作成するのが基本設計です。それぞれのRate PlanにRecurring Chargeを持たせ、Billing Periodと金額を変えることで、「月払いは¥1,200/月、年払いは¥12,000/年（2ヶ月分お得）」という構成を表現します。

Usage Rating Option（Usageの集計タイミング）

Usageチャージは Bill Run の前に「いつUsageを集計するか」を設定で決めます。

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で終了日を揃えておくのが自然な設計になります。

Billing Period Alignment — 複数Chargeの請求周期をどう揃えるか

Coterminationの概念を実際に制御する設定が「Billing Period Alignment」です。1つのSubscriptionに開始日の異なる複数のChargeがある場合、この設定で請求周期を揃えるかどうかを選べます。

Product Rate PlanのRecurring ChargeまたはUsage Chargeには、Billing Period Alignmentとして次の3つから選択できます。

参考: Date attributes for product rate plan charges — Billing Period Alignment

Charge Modelの選び方：どう計算するかを決める

ChargeのタイプとModelの組み合わせで1つのChargeが完成します。タイプが「いつ課金するか」、Modelが「どう金額を計算するか」を決めます。

全Charge Modelの一覧

VolumeとTieredの計算の違い

VolumeとTieredは似ていますが、計算方法が異なります。

タイプとModelの組み合わせ例

タイプが「課金の発生タイミング」、Modelが「金額の計算方法」で、この2軸の組み合わせで1つのChargeが決まります。

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

Usage Chargeの集計方法：MeteringとAggregation

Usage Chargeを設定する際は、まず使用量を「計測(Metering)」し、必要に応じて「集計(Aggregation)」します。集計単位は顧客の請求期間と必ずしも一致しません。

Included Units・Overage・Rolloverの用語整理

Overage Charge Modelを理解する上で押さえておくべき3つの用語です。

参考: Overage pricing

High Water Mark Pricing — 最高値の日で課金する

High Water Mark PricingはUsage専用モデルで、請求期間中に最も使用量が多かった1日の値だけを使って課金計算を行います。累積合計ではなく「最高値の日」がベースになる点がTiered/Volumeとの根本的な違いです。

Overage Smoothing — スパイクを平滑化する

月ごとに使用量が大きく変動するビジネスでは、ある月だけ超過料金が急増するという問題が起きます。Overage Smoothingは複数期間の使用量を考慮することでこのスパイクを緩和するモデルです。

2つのSmoothing方式があります。

Multi-Attribute Pricing — フォーミュラで単価を決定する

Multi-Attribute PricingはOne-time・Recurring・Usage全タイプに対応しており、複数の属性をフォーミュラで組み合わせて単価を計算します。

一般的なCharge Modelは「数量」だけを基準に金額を計算しますが、Multi-Attribute Pricingは「地域」「品質」「車種」などの複数属性を組み合わせた複雑な価格計算が可能です。価格はPrice Formulaフィールドに数式を記述して定義します。

フォーミュラでは四則演算（+, -, /, *, ^）とカッコによる優先制御に加え、以下の関数を使用できます。

フォーミュラの例（レンタカー課金）：

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種類あります。

適用対象はChargeレベルで柔軟に制御できます。「この割引は月額料金のみに適用する」「すべてのChargeに適用する」など、Discount Chargeを作るときに適用先を指定します。

Trigger Condition：課金を「いつ始めるか」を制御する

課金開始のトリガーは「契約・開通・承認・特定日」の4種類のビジネスイベントから選べます。ChargeごとにTrigger Conditionを設定できるので、同じプランの中でも料金の種類によって課金開始タイミングを変えられます。

Rate PlanとChargeで「何をいくらで売るか」が決まりました。次の問いは「いつから課金を始めるか」です。

SaaSの契約では、「契約書にサインした日」「実際にシステムが使えるようになった日」「顧客が正式に受け入れた日」がバラバラになることがよくあります。Trigger Conditionは、これらのビジネスイベントのどれを課金開始のトリガーにするかを設定するものです。

重要なのは、同じRate Plan内のChargeごとに異なるTrigger Conditionを設定できる点です。たとえば「初期費用は契約日から、月額料金はサービス開通日から」という設定が可能です。

Billing Timing と Billing Day — いつ・どの日に請求するか

Trigger Conditionが「課金を開始するイベント」を決めるのに対し、Billing TimingとBilling Dayは「実際にどのタイミング・どの日に請求書が発行されるか」を決める設定です。

Billing Timing：Arrears（後払い）とAdvance（前払い）

Billing Day：請求日をどう決めるか

1つの顧客が複数の商品を契約し、Chargeごとに開始日が異なる場合、「どの日に請求するか」を以下の4パターンから選べます。

参考: Define billing periods

Proration：月の途中の変更を日割りで計算する

Prorationは「請求サイクルの途中でChargeの内容が変わったとき」に自動で日割り計算する仕組みです。ChargeレベルでオンオフできるのでChargeの性質に合わせて制御します。

Proration（按分計算）とは、月の途中でプランが変わったときに、使った日数分だけ料金を計算する仕組みです。「按分」という会計用語が出てきますが、要は「日割り計算」のことです。

たとえば月額¥3,000のプランに月の途中（15日）から加入した場合、その月は半分しか使っていないので¥1,500だけ請求するのが自然です。これをZuoraが自動で計算してくれるのがProrationです。

Prorationが発生するのは主に以下のケースです。

請求日を毎月1日に固定しているサービスでは、月の途中に起きる契約・変更・解約の都度、次の1日時点で日割り計算が発生します。請求日を固定しているサービスほどProrationが頻繁に発生するため、設計時に意識しておく必要があります。

Prorationを活用することで以下のメリットが得られます。

設定前に準備すること

Product Catalogの設定を始める前に、経理チームと「会計コード」と「収益認識ルール」を決めておく必要があります。後から変更すると過去の請求データへの影響が生じます。

Product Catalogを設定する前に、Zuora外で決めておくべきことが2つあります。どちらも「Chargeを作るときに必ず入力を求められる項目」なので、後回しにすると設定が止まります。

Chargeを設定する前に用意すべき4つの前提設定：

この4つはProduct Rate Plan Chargeに紐づけるため、Catalog設定を始める前に経理チームと確定させておきます。

会計コード（Accounting Code）

会計コードとは、売上をどの勘定科目に分類するかを示すコードです。たとえば「月額サブスクの売上」と「初期費用の売上」を別々の勘定科目で管理したい場合、それぞれ異なる会計コードをChargeに紐付けます。

Zuoraは請求書を発行するたびに、このコードをもとに会計システムへの仕訳データを自動生成します。コードが設定されていないと、経理側で手動で仕分け直す作業が発生します。

収益認識ルール（Revenue Recognition Rule）

収益認識とは「売上をいつ計上するか」のルールです。たとえば年間契約で¥120,000を一括で受け取っても、会計上は毎月¥10,000ずつ売上として計上するのが原則です（サービスを提供した月に売上を立てる）。

Zuoraはこの収益認識ルールをChargeに紐付けることで、入金タイミングと売上計上タイミングを自動的に分けて管理します。

Bundling と Multi-Currency — 販売の柔軟性を広げる機能

Product Catalogには、複数の商品をまとめて売る「Bundling」と、複数通貨で販売する「Multi-Currency」という2つの拡張機能があります。

Bundling — 複数Chargeを束ねて販売する

1つのProduct Rate Planに複数のChargeを追加することで、複数の商品・サービスをまとめたバンドル商品として販売できます。たとえば通信会社の「Triple Play Bundle」では、初期費用（One-time）・固定電話（Recurring）・TV（Recurring）・携帯電話（Usage）を1つのRate Planにまとめて提供します。

Multi-Currency — 複数通貨での販売

Zuoraは任意の通貨をデフォルト通貨として設定できます。価格を為替変動から独立させるため、通貨レートは自動換算されません（各通貨ごとに個別の価格を設定する）。

• Rate Planごとに、有効化する通貨を選択できる（例：ある商品はUSでは販売するがUKでは販売しないためGBPは有効化しない）
• 顧客は自分のアカウントに設定された通貨でのみ請求される。1つのアカウントで複数商品を契約している場合、すべて同じ通貨で請求される
• 各顧客アカウントはシステムで設定されたデフォルト通貨で作成され、作成後は変更できない

参考: Multiple Currencies overview

101補足 — 価格戦略とOrder Line Itemの位置づけ

101の学習記事から、本記事の内容を補強する周辺論点です。

柔軟な価格体系を求める2つの理由

価格は一度決めて終わりではなく、市場の需要変化や競合の参入に合わせて見直し続けるものです。柔軟な料金体系が求められる主な理由は新製品のローンチ（導入価格・プロモーション価格などの調整）と地域拡大（通貨・価格水準の現地化）の2つです。「製品ライフタイムを通じて同じ価格を維持する」ことは柔軟性を求める理由にはなりません。

販売チャネルは営業担当だけではない

サブスクリプションビジネスの販売経路は営業担当だけとは限りません。セルフサービスポータル・ECサイト・パートナー・APIなど多様なチャネルが存在します。「営業だけが唯一の販売手段」という断定は誤りです。

Order Line Item（OLI）との役割分担

ハードウェア代やセットアップ費のような一度きりの取引は、わざわざSubscriptionを新規作成しなくてもOrder Line Itemsとして管理できます。Product Catalog上のChargeとして定義するほどでもない単発売上を扱う仕組みで、詳細は[[BI4]]のOrder Line Itemの節を参照してください。