Pega 親子ケース設計｜子ケースに分割すべきかの判断基準と失敗例

結論から：子ケースは「独立したライフサイクルを持つ単位」だけに切り出す

Pega でケースを設計していると、必ず「この業務のかたまりを、親ケースのステージ/ステップとして表現するか、それとも独立した子ケースに切り出すか」という判断に突き当たります。ステージを追加するのと同じくらい気軽に子ケースを増やせてしまうため、明確な基準を持たないまま感覚で分割してしまいがちな部分です。

結論を先に言うと、判断軸はひとつに集約できます。

その業務が「独立したライフサイクル・別の SLA・別の担当者・別の解決タイミング」を持つなら子ケースに分割する。親と同じ解決単位・共有データで、ただ直列に進むだけならステージ/ステップに留める。

「工程が長いから」「見た目に区切りたいから」という理由で子ケースにするのは誤りです。子ケースは画面上の区切りではなく、独立して追跡・解決される業務の単位です。本記事では、この判断を実装レベルの分岐まで落とし込み、待ち合わせ（依存）の設計と、やりがちな失敗までを整理します。

子ケースとは — 親ケースとの関係

Pega の子ケース（child case / subcase）は、親ケースの中から生成される、独立したライフサイクルを持つケースです。Pega 公式でも「子ケースは親ケースを解決するために完了が必要な業務を表す」と定義されており、親と子はカバー（cover）や親子関係のプロパティによって関連づけられ、親ケースからは子の一覧・進捗を辿れます。子ケースは自分自身のステージ・ステップ・SLA・担当割当を持ち、親が待たない構成であれば親とは別のタイミングで解決できます。

ここで押さえておきたいのは、親子の関連づけのモデル（cover 関係・folder 関係など）や、それを保持するプロパティの具体名・推奨は Pega のバージョンによって差があるということです。設計の考え方（独立ライフサイクルの単位を切り出す）は普遍ですが、実装の細部は必ず対象バージョンの公式ドキュメントで確認してください。本記事は「どこで分割するか」という設計判断に絞って解説します。

一方、ステージ/ステップは1つのケースの内部の進行を表す構造です。ステージは同じケースの同じライフサイクルの一部であり、独立して解決されることはありません。つまり、「子ケースにする＝別のライフサイクルとして切り出す」「ステージにする＝同じライフサイクルの中の局面にする」という違いです。

分割すべきかを決める問い

実案件では、次の問いを順に当てて判断すると迷いません。ひとつでも「はい」なら子ケースの候補、すべて「いいえ」ならステージ/ステップに留めるのが基本です。この4つの問いは、Pega が「ケース階層の設計上の考慮点」として挙げる観点——別の役割/チームが関与する、独自のライフサイクルと固有の結果を持つ、レポートを分けたい、同時編集を避けたい——とも整合します。

独立したライフサイクルを持つか

その業務が、親の進行とは別に「開始 → 処理 → 完了」という自前の進行を持つか。親の解決とは無関係に、それ自体が独立して完了しうるかを見ます。

• 持つ → 子ケースの候補
• 持たない（親の進行の一部として直列に進むだけ） → ステージ/ステップ

例：融資審査ケースの中で「担保物件ごとの評価」が、物件ごとに別の担当・別の期限・別の完了タイミングで進むなら、物件評価は子ケースの候補です。逆に「申込内容の入力 → 確認 → 提出」のように親の中で一直線に進むだけなら、ステージ/ステップです。

別の SLA・担当者・解決タイミングか

同じ業務でも、切り出した部分に独立した SLA（期限）や別の担当チームが付くなら、それは分割のサインです。親ケースの SLA とは別の時計で管理したい、別の部署に割り当てたい、親より先に（あるいは待たない構成なら後に）解決したい——こうした「別の管理単位にしたい」要求は、子ケースが最も素直に応えます。ステージに押し込むと、1つのケースに複数の SLA・複数の担当を無理やり同居させることになり、追跡性が落ちます。

親は全子ケースの解決を「待つ」か

分割すると決めたら、次に依存の設計が要ります。親ケースが「すべての子ケースが解決するまで先に進まない/完了しない」のか、それとも「子ケースを起こしたら親は待たずに進む」のか。この違いで待ち合わせの組み方が変わります。

• 待たない → 親側に依存（Wait ステップ）を置かず、子を独立して進める
• 待つ → 親側に Wait ステップ（ケース依存）を組み、全子ケースの解決を合流点で待ち合わせる

この待ち合わせを設計し忘れると、「子ケースが未解決なのに親が完了してしまう」「逆に永遠に待ち続ける」といった不整合が起きます。分割と依存は必ずセットで考えてください。

ステージ/ステップに留めるか、子ケースに分割するか

上の問いを一覧に落とすと、判断は表で機械的に下せます。

観点	ステージ/ステップに留める	子ケースに分割する
ライフサイクル	親と同じ（同一の進行）	独立（自前の開始→処理→完了）
SLA	親ケースの SLA に従う	子ごとに別 SLA を持てる
担当者	親の割当の延長	別チーム・別担当に割当可
解決タイミング	親の中で直列に完了	親と別のタイミングで解決
追跡・レポート	ケース単位でまとめて見る	子単位で独立して追跡・集計
再利用性	そのケース内に閉じる	他ケースからも生成・再利用しやすい
コスト	軽い（インスタンスが増えない）	重い（インスタンス数が増える）

判断の型はシンプルです。左列（独立ライフサイクル・別 SLA・別担当・別タイミング）が一つも当てはまらないなら、ステージ/ステップに留める。 迷ったら「これは親と別の時計・別の担当で動くか？」を自問してください。

子ケースの生成と依存の設計

分割すると決めたら、子ケースは Create Case ステップ（ライフサイクルに配置する Create Case オートメーション）で生成します。子を1件だけ生成することも、「リストを使って複数のケースを生成（create multiple cases using a list）」を選んでページリスト等の各要素に対して子を複数生成することもできます。明細行・対象ごとにまとめて子を起こしたいときは、この「複数生成」を使います。

ここで重要なのは、親が子の解決を待つかどうかは「生成のしかた」ではなく「依存（待ち合わせ）を組むかどうか」で決まるという点です。Pega では親側に Wait ステップ（ケース依存, case dependency） を置くと、全子ケース（または特定タイプの子）が指定したステータス（たとえば「解決済み」）に達するまで親の進行が止まります。待つ必要がなければ Wait ステップを置かず、子を独立に走らせます。

部品	役割	親は待つ？
Create Case（1件）	特定の局面で子を1件生成	Wait ステップの有無で決まる
Create Case（複数, list）	リストの各要素に対して子を複数生成	Wait ステップの有無で決まる
Wait ステップ（ケース依存）	全子／特定タイプの子が指定ステータス（例：解決）に達するまで親を停止	待たせるための部品

つまり設計の型は「生成は Create Case、待ち合わせは Wait ステップ」です。たとえば「複数の物件評価がすべて終わってから契約に進む」なら、各物件を Create Case（複数生成）で子ケースにし、親側に Wait ステップを置いて全解決を待ち合わせます。逆に「本体の処理と並行して通知業務を独立に走らせる」だけなら、Wait ステップを置かず投げっぱなしにします。

補足：Pega には spin-off・split-for-each・split-join といった並列処理の仕組みもありますが、これらはサブプロセス（サブフロー）を並列に走らせるためのフロー shape であり、独立したインスタンスを持つ子ケース（サブケース）の生成とは別レイヤです（ロックの扱いも子ケースとサブフローで異なります）。子ケース設計では、まず Create Case ＋ Wait ステップで「待つ/待たない」を表現するのが基本です。なお各機能の正確な名称・挙動・構成方法はバージョンにより異なることがあるため、実装は対象バージョンの公式ドキュメントで確認してください。

多数の子ケースを生成するときはデータ集約とセットで

子ケースを1件2件生成するだけなら問題は起きませんが、1つの親から多数の子ケースを生成する設計では、データの集約を必ずセットで考えます。

たとえば「50件の子ケースそれぞれの金額を合計して親に表示したい」「未解決の子が何件あるかを親のダッシュボードに出したい」といった要件は、子を作った後から手当てすると重くなります。親側に集約プロパティ（ロールアップ）——Pega の集計プロパティ（aggregate calculations）——を用意し、子の値を親に積み上げる設計を最初から織り込んでおきます。集計プロパティは子ケースが保存されるたびに親側の計算プロパティを更新するので、レポートや画面で子を都度スキャンして集計する重い処理を書かずに済みます。これを怠ると、その重い集計処理を自前で書く羽目になります。

多数生成は同時に性能の観点も要ります。子ケースはそれぞれ独立したインスタンスなので、一般に生成数がそのままインスタンス数・ロック・インデックスの負荷になります。「本当にこの粒度で独立追跡が要るのか」を、生成数の見積もりとあわせて確認してください。

よくある2つの失敗

親子ケース設計の失敗は、経験上ほぼ2方向に分かれます。

失敗1：単なる手順の区切りに子ケースを使う

「工程が長いので見やすく区切りたい」という理由で、独立ライフサイクルを持たない局面まで子ケースにしてしまうパターンです。典型例：

• 申込フォームの「入力 → 確認 → 提出」を、それぞれ子ケースにする
• 承認の各段階（一次承認・二次承認）を子ケース化する
• 明細行の各行を、集計も待ち合わせも要らないのに1行ずつ子ケースにする

これらは親と同じ解決単位・同じ SLA・同じ担当の延長で直列に進むだけなので、ステージ/ステップが正解です。子ケース化すると、インスタンス数が業務量に比例して膨れ上がり、レポートと性能に無駄な負荷をかけます。区切りたいだけならステージで区切れます。

失敗2：独立追跡が必要な業務を1ケースに押し込む

逆に、本来は別の SLA・別の担当・別のタイミングで解決される業務を、1つの親ケースのステージに押し込むパターンです。典型例：

• 物件ごと・拠点ごとに別チームが別期限で処理する業務を、親のステージに並べて1ケースで回す
• 親の完了後も長く続く「期中管理」を、親ケースの延長ステージとして同居させる

これらはステージにした瞬間、子単位の独立した追跡・別 SLA の管理・他ケースからの再利用を失います。Pega も「別の役割のユーザーが関与する」「サブケースが独自のライフサイクルと固有の結果を持つ」「プロセス単位でのレポートが重要」「複数人が同時に作業する」場合は、単一の連続フローではなく子ケースへの分割を推奨しています。後から「やっぱり物件ごとに別担当・別期限で追いたい」となると、ケース構造ごと作り直しになりがちです。独立して解決される単位は、最初から子ケースに切り出しておくべきです。

迷ったら判断軸に戻る。「別の時計・別の担当で動くか」を問えば、この2つの失敗はほぼ避けられます。

まとめ

• 子ケースは「独立したライフサイクル・別 SLA・別担当・別の解決タイミング」を持つ単位だけに切り出す。 見た目の区切りは分割の理由にならない
• ステージ/ステップは同じライフサイクルの局面、子ケースは別のライフサイクルの単位——この違いを基準にする
• 分割したら依存を必ず設計する。生成は Create Case ステップ、待ち合わせは親側の Wait ステップ（ケース依存）。待たないなら Wait ステップを置かず独立に走らせる
• 多数の子ケースを生成するなら、集約（集計プロパティ／ロールアップ）と性能をセットで検討する
• 失敗は2方向だけ——手順の区切りに子ケースを乱用する過剰分割と、独立追跡が要る業務を1ケースに押し込む分割不足

親子ケースの分割は、ケース設計の中でも後戻りコストが大きい判断です。「別の時計で動くか」という問いを設計の初期にチームで共有しておくことが、後工程の大きな手戻りを防ぎます。なお、親子関係のモデルや生成手段の細部はバージョン依存があるため、実装時は対象バージョンの公式ドキュメントで裏取りしてください。

関連リンク

• Pega Platform 開発支援
• Pega設計の分岐点：ケースにすべきか、データインスタンスか
• Pega の Picklist と Data Reference の使い分け
• Pegaパターン継承と直接継承の使い分け｜ルール解決とクラス設計の勘所
• Pega の参照データはどこに置く？DataType・Picklist・クラスの判断
• 無料相談に申し込む