概要

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

• OrderはSubscriptionを操作する指示書。Order Actionが実際にSubscriptionを変える
• Order → Order Action → Subscriptionの3層構造が基本
• SubscriptionにはTermed・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はProduct Catalogに載せない単発取引に使う

Order Line Itemは「Subscriptionという継続契約の文脈を持たない、単発の売上」をOrderの中で直接表現するための仕組みです。

SubscriptionはRecurringやUsageのように継続的に課金が発生するものを管理するオブジェクトです。One-timeチャージであってもSubscriptionの中に格納できますが、それは「契約（Subscription）に付随する初期費用」という文脈がある場合です。

Order Line Itemが想定しているのはそれとは異なる、Product Catalogに定義するほどでもない、その商談限りの売上です。

具体的にOrder Line Itemを使う場面はこういったケースです。

• この顧客のためだけの初期構築費用（毎回金額が違う）
• スポットで発生したコンサルティング費用
• ハードウェアの販売（繰り返し売るものではない）

1つのOrder
  ├── Order Action → Subscription（月額SaaS ¥10,000/月）
  └── Order Line Item（初期構築費用 ¥500,000 ← Catalogには載せない）

SaaSの月額契約とスポットの構築費用を1つのOrderにまとめて表現でき、同じInvoiceに載せることもできます。

Order Line Itemの制限事項とFulfillment

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が発生する3つの条件

Invoice Separatelyの設定

Subscriptionを新規作成するOrder Actionには「Invoice the Subscription Separately（個別に請求書を作成する）」という設定があります。

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を使う、という判断軸になります。

Orders Harmonization と Hybrid Order Orchestration

「Orders Harmonization」は旧モデルからの移行手段、「Hybrid Order Orchestration（Hybrid Order）」は1つのOrderで複数の性質を組み合わせる取引パターンです。名前は似ていますが目的がまったく違うので区別して覚えます。

Orders Harmonization ― Subscribe and Amendとの共存モード

古くからZuoraを使っているテナントは、Ordersモデルより前の「Subscribe and Amend」というAPIモデルで契約を管理していました。Orders Harmonizationは、このSubscribe and Amendのテナントを、既存のAPI連携を壊さずにOrdersモデルへ橋渡しする移行手段です。

Hybrid Order Orchestration ― 1つのOrderに異なる性質の取引を混在させる

「Hybrid Order Orchestration」は、Order Line Item（単発の非サブスク取引）とSubscription操作（Order Action）を同じOrderの中に混在させ、まとめて処理するという取引パターンを指す一般的な呼び方です。公式ドキュメントの見出しとしては「Hybrid Order」や「hybrid order containing both subscriptions and order line items」という表現で説明されており、独立した機能名というよりOrder Line Itemの活用パターンの1つと捉えておくと実態に近いです。[[BI4]]前半で説明したOrder Line Itemの仕組みをベースに、両者を1つの取引としてオーケストレーションします。

2つの違い

101/201補足 — Co-termination・日付・Ramp関連の周辺論点

101/201の学習記事から、本記事の内容と関連する周辺論点を補足します。

Co-termination（101視点）

101の教材では、Co-terminationを「開始日の異なる複数のSubscriptionの終了日を同一日に揃える仕組み」と定義しています。BI2記載のCotermination（追加オプションの期間短縮という切り口）と対象は同じ現象ですが、視点が異なります。

Default Initial Term / Renewal Termは上書き可能な既定値

Default Initial TermとDefault Renewal Termはテナント設定の既定値にすぎず、Subscription作成時に個別に上書きできます。自動更新される期間の長さは、Auto-Renewの有無ではなくRenewal Termの設定値に従います。Auto-Renewは「するか/しないか」、Renewal Termは「何ヶ月か」という別軸の役割分担です。

Order作成時の必須日付

Require Service Activation of OrdersとRequire Customer Acceptance of Ordersを両方Yesにすると、新規Subscription作成時にContract Effective・Service Activation・Customer Acceptanceの3日付すべてが入力必須になります。

サブスクリプション番号のプレフィックス

アカウント番号・サブスクリプション番号のA-／A-Sといったプレフィックスはデフォルト値にすぎず、Billing Settingsで変更できます。「必須で変更不可」という記述は誤りです。

Proration計算例（201）

日割り計算では「単価」と「残日数／月の総日数」を正しく特定することが最初のステップです。たとえばマルチデバイスプラン（月額$14.99）を3月10日から開始した場合、3月10日〜3月31日の22日間が対象で、月全体は31日のため、日割り額は $14.99 ×（22 ÷ 31）＝ $10.64 になります。単価の取り違え・日数の取り違えが典型的な失点パターンです。

Invoice The Subscriptions Separately（201の補足）

Billing Settingsで「Enable Subscriptions to be Invoiced Separately」をYesにしても、それは"個別請求できる選択肢を出す"だけです。実際に個別請求書が生成されるのは、Subscription側で「Invoice The Subscriptions Separately」を選んだものだけです（本記事の「Invoice Separatelyの設定」と対応）。

まとめ

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

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