概要

ZuoraのOrdersモデルは「Subscriptionへのすべての操作をOrderという指示書として記録する」設計です。この履歴の積み重ねがあるからこそ、契約の変化を正確に追跡し、ビジネスの指標として活用できます。

• OrderはSubscriptionを操作する指示書。Order Actionが実際にSubscriptionを変える
• Order → Order Action → Subscriptionの3層構造が基本
• SubscriptionにはTerned・Evergreenの2種類があり、ビジネスモデルによって使い分ける

SubscriptionとOrderの関係 ― 「契約」と「指示」を分けて考える

ZuoraではSubscription（契約の状態）とOrder（操作の指示）が明確に分離されています。この2つの役割の違いを理解することが、Zuoraの契約管理を理解する第一歩です。

Subscriptionは「今この顧客がどんな契約を持っているか」という状態を表します。一方Orderは「その契約に対して何をするか」という指示です。そしてOrderの中にあるOrder Actionが実際にSubscriptionを変える操作の主体です。

Order（指示書）
  └── Order Action（具体的な操作）
        └── Subscription（状態が変わる）

この分離には明確な理由があります。契約は一度作ったら終わりではなく、プラン変更・一時停止・更新・解約など様々な変化を経ます。その変化の履歴をOrderとして積み重ねることで、「いつ・誰が・何を変えたか」を追跡できる設計になっています。

Subscriptionの現在の状態はOrder Actionの積み重ねによって作られます。これはバージョン管理のようなイメージです。Subscriptionそのものを直接書き換えるのではなく、Orderという差分を積み上げていく設計です。

Orderは誰が作るか

OrderはAPIを通じて自動生成されるのが基本です。 ユーザーがアプリやWebサイト上でプラン変更や契約操作をすると、バックエンドのシステムがZuora APIを呼び出してOrderを生成します。

ユーザー操作
  └── バックエンドシステム
        └── Zuora Orders API呼び出し
              └── Order生成 → Subscription更新

Zuora Admin（管理者）がUIから手動でOrderを作ることもできますが、それはデータ修正や移行作業などの例外的なケースです。SalesforceのCPQを使っている場合は、営業担当者が見積を作って承認されると自動でZuoraにOrderが作られるフローになります。

間違えたOrderへの対処

Orderを作った後に誤りに気づいた場合、Invoiceがまだ生成・確定されていない段階であればOrderを削除して元に戻せます。 ただし、Invoiceが確定済みのOrderは削除できません。

このため、実務ではOrdersのPreview機能を使って請求への影響を事前にシミュレーションしてから確定するのがベストプラクティスです。ZuoraのOrders APIにはPreviewエンドポイントが用意されており、実際にOrderを作らずに影響を確認できます。

Orderのデータ構造 ― Order / Order Action / Order Line Item

1つのOrderは複数のOrder Actionを含むことができ、各Order ActionはどのSubscriptionにどんな操作をするかを定義します。この3層構造を理解することがOrdersモデルの核心です。

3つのオブジェクトの役割をまとめると以下のとおりです。

Order Actionは「1 Action = 1 Subscription」

Order Actionは必ず1つのSubscriptionに対して操作します。 1つのOrderに複数のOrder Actionがあれば、それぞれ別のSubscriptionを操作することも、同じSubscriptionに複数の操作を加えることも可能です。

たとえば「既存のプランを外して新しいプランを追加する」という操作は、Remove ProductとAdd Productという2つのOrder Actionを1つのOrderにまとめて実行できます。

Order Line Itemはサブスクリプション外の取引に使う

Order Line Itemは、定期課金のSubscriptionとは別に「一回だけ発生する取引」をOrderの中で扱うための仕組みです。

たとえば以下のようなケースで使います。

• 初期設定費用（セットアップフィー）
• 物品の販売（ハードウェアなど）
• スポットで発生するプロフェッショナルサービス費用

Order Line ItemはSubscriptionと同じOrderの中に共存できるため、「契約と同時にハードウェアも注文する」といったビジネスをひとつのOrderで表現できます。

Order Actionの種類 ― できることの全体像

Order ActionはSubscriptionに対して「何をするか」を定義する操作の単位です。操作の種類によって「Subscriptionレベル」と「Rate Planレベル」の2階層に分かれています。

ZuoraのOrder Actionは大きく2種類に分類されます。

Subscriptionレベルのアクション

Rate Planレベルのアクション

Rate Plan（料金プラン）とは、Subscriptionの中に含まれる個々の商品・サービスの課金設定のことです。1つのSubscriptionに複数のRate Planを持てます。

Subscriptionのライフサイクルとステータス

Subscriptionは作成から解約まで、いくつかのステータスを経て変化します。ステータスは「このSubscriptionが今どういう状態にあるか」を表し、請求や操作の可否にも影響します。

Subscriptionのライフサイクルは、Create Order Actionによって始まり、Cancelled が唯一の終点です。

Create Order Action → Pending or Active → （Suspend → Resume） → Cancelled

Active は「通常稼働中の状態」であり、ここからSuspend・Resume・Cancelledへと変化します。SuspendedはActiveかCancelledへ移行する一時的な状態です。Cancelledからは他のステータスに戻れません。

Subscriptionのステータス一覧は以下のとおりです。

なぜPendingが存在するのか

PendingステータスはZuoraの「先にOrderを作っておき、後でトリガーを引く」という設計から生まれます。

たとえば法人向けのビジネスでは、営業が契約書を送付してから顧客が署名・返送するまで数日かかることがあります。このとき「署名が返ってくる前にZuoraにSubscriptionを作りたいが、課金はまだ始めたくない」というニーズが生じます。

TermedとEvergreen ― 終わりのある契約・ない契約

ZuoraのSubscriptionには「契約期間を持つTermed型」と「期間を持たないEvergreen型」の2種類があります。どちらを選ぶかはビジネスモデルによって決まります。

Termed ― 期間で管理する契約

Termedは「1年契約」「3年契約」のように、契約期間が明確に決まっているモデルです。期間が終わると自動更新またはそのまま終了します。法人向けの年次契約や、コミットメント型の複数年契約に向いています。

Evergreen ― 期間を持たない契約

Evergreenは終了日を持たず、キャンセルされるまで永続するモデルです。「いつでも解約できる月次プラン」がその典型です。月次・週次のSaaSプランや従量課金モデルに向いています。更新という概念がないため、Renewal Order Actionは使いません。

どちらを選ぶか

Rampディール ― 段階的に変化する複雑な契約

Rampディールとは、契約期間中に価格や数量が段階的に変化する契約形態です。複数年の大型契約でよく使われ、Zuoraはこれを1つのSubscriptionとOrderで管理できます。

典型的なRampディールの例を見てみましょう。

この例では、年が進むにつれてシート数が増え、単価が下がっています。大量購入による段階的な値引きをコミットさせる、というビジネスでよく見られるパターンです。

Rampがない場合の問題

Rampという仕組みがなければ、この3年契約を表現するために3つの別々のOrderやSubscriptionを作る必要があります。

そうなると「この3つは同じ顧客の同じ契約の続き」という文脈がZuora上で失われ、MRR（月次定期収益）の推移をひとつの契約として追跡できなくなります。

Rampを使えば、これを1つのSubscription・1つのOrderで表現できます。 契約全体の文脈が保たれ、各期間（Ramp Interval）ごとのMRRやTCV（Total Contract Value、契約総額）といった指標も自動で計算されます。

RampとOrderの積み重ねは何が違うのか

Orderを積み重ねた結果として、Rampに似た状態になることはあります。たとえば「100席で契約 → 半年後に150席に増やす → さらに半年後に200席に増やす」という3つのOrderの履歴はRampに見えます。しかしRampとOrderの積み重ねは本質的に別物です。

Rampは「2年目に150席になること」を顧客が最初に約束する契約です。Orderの積み重ねはあくまでその時々の変更であり、将来の変化は約束されていません。「複数年にわたって価格や数量が変わる大型契約を最初に合意させたい」という要件があるときにRampを使う、という判断軸になります。

まとめ

ZuoraのOrdersモデルは「Subscriptionへのすべての操作をOrderという指示書として記録する」設計です。この履歴の積み重ねがあるからこそ、契約の変化を正確に追跡し、ビジネスの指標として活用できます。

Orderという概念があることで、Zuoraは単なる請求システムを超えた「契約ライフサイクル管理システム」として機能します。すべての契約操作がOrderとして記録されるため、「いつ・何が・なぜ変わったか」を常に追跡できる状態が保たれます。