Pega設計の分岐点：ケースにすべきか、データインスタンスか
Pega 設計で最初に直面する「これはケース？それともデータインスタンス？」という判断を、独立したライフサイクル・業務の進行管理（割当・承認・SLA・監査）・件数と寿命の観点で整理し、実案件での判断基準を具体例とともに解説します。
結論から：ケースは「独立したライフサイクルと業務の進行管理が要るもの」に限定する
Pega でアプリケーションを設計するとき、最初に、そして最も頻繁に迷うのが「この情報をケース（Case Type）として持つべきか、それともデータインスタンス（Data オブジェクト）として持つべきか」という判断です。
結論を先に言うと、判断基準はシンプルです。
独立したライフサイクル（開始 → 処理 → 完了）を持ち、担当者への割当・承認・SLA・監査といった業務の進行管理が必要なものをケースにする。それ以外はデータインスタンスで持つ。
「業務上重要そうだから」「実体があるから」という理由でケースにするのは誤りです。重要かどうかとケースにするかどうかは別の軸です。本記事では、この判断を具体的な判断軸に分解し、実案件での判断基準まで落とし込みます。
ケースとデータインスタンスは何が違うのか
まず両者の性質を整理します。
- ケース（Case Type） — Pega の中心概念。ステージ・ステップからなるライフサイクルを持ち、担当者への割当・承認・SLA・監査証跡を標準機能として備える。「1件の業務の進行そのもの」を表現する単位。
- データインスタンス（Data オブジェクト） — 参照・保持のためのデータ。マスタ的・明細的な情報を持つが、それ自体は「進行」しない（独立したワークフローを持たない）。
ケースは強力ですが、そのぶん一般に重い（ステージ管理・インデックス・監査などのオーバーヘッドがある）。だから「何でもケース」にすると、性能・保守性・レポートのすべてで代償を払うことになります。
実際、Pega Academy のデータモデリング関連トピックでも、業務データはケース（ワークオブジェクト）に直接持たせず、再利用可能なデータオブジェクトに寄せることが基本方針として示されています。ケースタイプはワークフローとケースのメタデータの器、データオブジェクトは業務データの器、という役割分担です。本記事の判断軸は、この公式の考え方を実務の意思決定に落とし込んだものです。
判断の4軸
実案件では、次の4つの軸で判断すると迷いません。
軸1：独立したライフサイクルを持つか
その情報自体が「開始 → 処理 → 完了」という独自の進行を持つか。
- 持つ → ケースの候補
- 持たない（ただ保持・参照されるだけ） → データインスタンス
例：「リース申込」は申込 → 審査 → 契約 → 開始という進行を持つのでケース。一方「顧客マスタ」は進行しないのでデータ。
軸2：割当・承認・SLA・監査が要るか
担当者への割当、承認フロー、SLA 管理、変更の監査証跡といったケースの標準機能（＝業務の進行を管理する仕組み）を実際に使うか。
- 使う → ケース
- 一つも使わない → データインスタンスで十分（ケースの重さを払う理由がない）
補正軸：件数と寿命
上の2軸で方向を決めたうえで、件数と寿命で最終調整します。
- 少量・業務の単位・比較的長寿命 → ケース向き
- 大量・短命・マスタ的/明細的 → データインスタンス向き
ここが最もよく間違えるポイントです。「大量に発生し、短命で、独自の進行管理も要らないもの」をケースにすると、ケース数が業務量に比例して膨れ上がり、一般にインデックスなどを圧迫して性能問題を招きやすくなります。
判断早見表
| 観点 | ケース | データインスタンス |
|---|---|---|
| 独立したライフサイクル | 持つ | 持たない |
| 割当・承認・SLA・監査 | 必要 | 不要 |
| 件数・寿命 | 少量・業務単位 | 大量・短命・マスタ的 |
| ワークフロー | ある | ない |
ライフサイクルと割当/承認/SLA のどちらも当てはまらないなら、データインスタンスにする——これが実務での判断の型です。
よくある2つの失敗
ケース設計の失敗は、経験上ほぼ2方向しかありません。
失敗1：ケースにしすぎる
「データで持つべきもの」までケースにしてしまうパターン。典型例：
- 座席予約の各席（例：便あたり数百席）を1席ずつ子ケースにする
- 注文の明細行を1行ずつケースにする
- 点検チェックリストの各項目をケース化する
これらは大量・短命で、独自の進行管理（割当・承認・SLA）もワークフローも不要なので、**データインスタンス（または親ケース内の埋め込みデータ）**で持つのが正解です。ケース化すると、ケース数が業務量に比例して膨れ上がり、実装上は性能とケース数管理の面で問題が生じやすくなります。
失敗2：1つのケースに詰めすぎる
逆に、本来分割すべき複数のライフサイクルを1つの巨大ケースに同居させるパターン。典型例：
- 「申込」から「契約」「期中管理」「満了」までを、数年生きる1つのケースに押し込む
期中管理と満了は別の SLA・別の担当・別のタイミングで動くので、子ケースや別ケースに分割すべきです。1つのケースが数年生き続けると、ルール変更の影響範囲・レポート・パフォーマンスのすべてで問題が出ます。
迷ったら軸1と軸2に戻る。「ケースにしすぎ」と「1ケースに詰めすぎ」——この2つを避けるだけで、ケース設計の大半は正しくなります。
データにする場合、どう持つか（次の分岐）
データインスタンスにすると決めたら、次は「そのデータをどう持つか」という分岐が来ます。ケースに**埋め込む（aggregation）のか、外部・マスタを参照する（association）**のか。この判断は設計文書で必ず明示すべき重要な分岐で、性能とデータの整合性を左右します。
- そのケースが所有する「その時点の記録」（申込時点の申告内容など） → 埋め込み
- 外部・マスタが権威を持ち、常に最新を見たいもの（顧客マスタ・料率表など） → 参照
参照データの持ち方（Picklist か Data Reference か、DataType かクラスか）については、別記事で詳しく扱います。
まとめ
- ケースは「独立したライフサイクル＋業務の進行管理」が要るものに限定する。 重要かどうかは判断軸ではない
- 判断はライフサイクル / 割当・承認・SLA・監査 / 件数と寿命の観点で行う
- 失敗は2方向だけ——ケースにしすぎ（データで持つべきものをケース化）と1ケースに詰めすぎ（分割すべきライフサイクルの同居）
- データにすると決めたら、次は「埋め込みか参照か」を設計文書で明示する
この判断は、Pega アプリケーションの性能・保守性・拡張性の土台になります。設計の初期にここを正しく決めておくことが、後工程での大きな手戻りを防ぎます。
Pega の設計・実装でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、設計判断からご支援します。
関連リンク
関連記事
Pega データページの種類とスコープ設計｜Thread / Requestor / Node の使い分け
「なんとなく Thread スコープ」で作られたデータページが、外部連携の呼び出し回数を無駄に増やしていませんか。本記事ではデータページの種類（Read-Only / Editable / Savable）とスコープ（Thread / Requestor / Node）の組み合わせを、キャッシュ範囲・データ鮮度・再読み込みの観点から使い分ける判断軸を、LSA 目線で整理します。
記事を読むPega DX API で独自フロントを作る判断｜標準 Constellation UI との使い分け
Constellation は DX API 経由で UI メタデータを受け取りクライアントで描画する。この API は独自フロントの構築にも開放されているが、わずかな見た目調整のために独自フロントへ踏み込むと保守とアップグレードの負担が跳ね上がる。どこまで OOTB で、どこから DX API か——設計判断の分岐点を扱う。
記事を読むPega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読む