Pegaパターン継承と直接継承の使い分け｜ルール解決とクラス設計の勘所
Pegaのクラス設計では、パターン継承と直接継承のどちらをどこで使うかがルール解決の挙動を左右します。命名規則がそのまま継承構造になるため、設計段階の判断ミスが後々の再利用性とデバッグ性に直結します。本記事では両者の違いと使い分けの勘所を実務目線で整理します。
結論から：業務クラスは「パターン継承で束ね」、Pega 基底クラスへは「直接継承で橋渡し」する
Pega のクラス設計には、親クラスの決まり方が異なる 2 種類の継承があります。クラス名のハイフン区切りをたどって親を暗黙に決める「パターン継承（Pattern inheritance）」と、親クラスを明示指定する「直接継承（Directed inheritance）」です。どちらをどこで使うかは好みの問題ではなく、ルール解決（どのルールが選ばれるか）の挙動そのものを左右します。
結論を先に言うと、実務での型はこうです。
業務クラス同士は命名規則（ハイフン区切り）に沿ってパターン継承で束ね、その束ね先となる作業プール（クラスグループ）から Pega 基底クラス（Work-、Data-、Assign- など）へは直接継承で橋渡しする。ルール解決はこの順（パターン継承の祖先を先にたどり、祖先が尽きたら直接継承の親へ引き継ぐ）で探索される。
つまり命名規則がそのまま継承構造になります。だからこそ、クラス名を決めた瞬間に継承パスも決まり、後からの改名コストが跳ね上がります。本記事では、この 2 つの継承の違いとルール解決の探索順を整理し、具体的な使い分けの判断基準まで落とし込みます。
2 種類の継承 — パターン継承と直接継承
まず両者の性質を整理します。ここを混同したまま設計に入ると、後述の「意図しない再利用」や「未解決」に直行します。
パターン継承（Pattern inheritance）
パターン継承は、クラス名のハイフン区切りを 1 階層ずつ削りながら親を暗黙にたどる継承です。親を明示指定する必要はなく、命名規則そのものが継承関係を定義します。
たとえば Acme-HR-Work-LeaveRequest というクラスは、末尾を 1 つずつ削って Acme-HR-Work → Acme-HR → Acme と親をたどります。開発者が親を書かなくても、名前の形が親子関係になっているわけです。業務ドメインごとに階層を切って業務クラスを束ねるのに向いています。
直接継承（Directed inheritance）
直接継承は、親クラスを明示的に指定する継承です。クラス名の形とは無関係に、任意の親を指せます。
パターン継承をどれだけたどっても、Work- や Data-、Assign-、History- といった Pega が用意する基底クラスには届きません。これらの基底クラスは命名の階層（Acme-…）とは別系統だからです。そこで、業務クラス階層の中の適切なクラス——たとえば作業プール（クラスグループ）Acme-HR-Work から Work- へ、データクラス Acme-HR-Data-Employee から Data- へ——を、直接継承で明示的に橋渡しします。橋渡しの起点は業務内容ごとに異なり、Work- 系と Data- 系は別々のクラスから継ぐため、1 つのクラスがすべての基底クラスを兼ねることはありません。
ルール解決はどう探索するか（核心）
ルール解決とは、あるクラス文脈で「最も適切な 1 つのルール」を選ぶ Pega の仕組みです。継承の張り方は、この探索経路を直接決めます。
探索順は次のとおりです。
- まずパターン継承の祖先を順にたどる。 起点クラスから末尾を 1 階層ずつ削りながら、祖先方向へルールを探しにいきます。
- パターン継承の祖先が尽きたら、そのクラスに設定された直接継承の親へ引き継ぐ。 名前の形での親をたどり切ったクラス（多くは作業プール）から、明示指定された親（多くは Pega 基底クラス）に探索を渡します。
- その先も、渡された親のパターン継承 → 直接継承…という順で、
@baseclass（究極の基底クラス）まで探索が続きます。
重要なのは、パターン継承を無効化すると、そのクラスは直接継承のみで解決されるという点です。パターン継承を使うかどうかはクラスの設定（クラスフォームの「Find by name first (Pattern)?」）で決まり、無効にすると「名前の形での祖先」を飛ばして、明示指定した親だけを継ぎます。なお、この設定はクラスの作成時に決め、保存後は変更できないのが原則です（挙動はバージョンにより異なる場合があるため、実装時は公式ドキュメントで確認してください）。業務クラスでは通常パターン継承を有効にします。
この探索順を理解していれば、「なぜこのルールが拾われた／拾われなかったのか」を継承パスから説明できます。逆に言えば、継承の張り方を誤ると、拾ってほしくないルールを拾い、拾ってほしいルールに届かなくなります。
パターン継承と直接継承の比較
| 観点 | パターン継承 | 直接継承 |
|---|---|---|
| 親の決まり方 | クラス名のハイフンを削って暗黙に | 親クラスを明示指定 |
| 命名規則との関係 | 命名がそのまま継承構造になる | 命名の形に依存しない |
| ルール解決での順序 | 先に祖先を探索 | 祖先が尽きたら引き継ぐ |
| 主な用途 | 業務クラスを作業プール配下に束ねる | Pega 基底クラス（Work-/Data- 等）へ橋渡し |
| 無効化 | 無効化できる（→ 直接継承のみで解決） | 常に有効 |
| 典型例 | Acme-HR-Work-* を Acme-HR-Work に束ねる | Acme-HR-Work を Work- に継がせる |
上 3 行が本質です。 パターン継承は「名前で暗黙にたどる／先に探索される」、直接継承は「明示で指定する／祖先が尽きたら引き継ぐ」。この非対称を押さえておけば、どちらをどこに置くかは自然に決まります。
定石：クラスグループ（作業プール）とパターン継承は一体で設計する
現場での使い分けは、実は「クラスグループ（作業プール、work pool）の設計」と切り離せません。
作業プールは、複数の業務ケースを束ねて 1 つのテーブルに載せる器です。この束ね方はパターン継承と表裏一体で、命名規則を決めることが、そのまま継承構造を決めることになります。
具体的には、次のように組みます。
Acme-HR-Work（作業プール）配下に、Acme-HR-Work-LeaveRequest・Acme-HR-Work-Onboardingなどの個別ケースクラスをパターン継承で束ねる。共通ルール（共通の UI・データ変換・検証など）はAcme-HR-Workに置けば、パターン継承で全ケースに行き渡る。Acme-HR-Work自体は、直接継承でWork-へ橋渡しする。これで Pega のケース管理機能（ステージ・割当・SLA・監査など）を継承できる。- 参照系のデータクラス（
Acme-HR-Data-Employeeなど）は、同様にData-へ直接継承でつなぐ。
この構造は、後から変えるのが非常に高コストです。命名規則が継承構造そのものなので、クラスを 1 つ改名するとパターン継承の親子関係が変わり、ルール解決の経路も、そのクラスを参照している箇所も影響を受けます。だからこそ、命名規則は設計初期に固める——これが定石です。
よくある失敗
継承まわりの失敗は、経験上ほぼ 3 パターンに集約されます。いずれも「後で顕在化して、原因追及が難しい」種類のものです。
失敗 1：継承設定ミスで、意図しないルール再利用が起きる
親クラスに置いたルールが、パターン継承を通じて想定外の子クラスにまで拾われるパターンです。あるいは、クラス階層の切り方を誤って、別業務のルールを共有してしまうこともあります。「動いてはいるが、なぜかこのケースで別業務向けの挙動が出る」という形で表れ、原因が継承経路にあると気づきにくいのが厄介です。
失敗 2：橋渡し漏れで、ルールが未解決になる
作業プール（クラスグループ）などの束ね先クラスを Pega 基底クラスへ直接継承でつなぎ忘れると、基底クラスが備えるはずのルールに探索が届かず、未解決になります。「名前の形の親」は尽きているのに「明示の親」を指していない、という状態です。新しい業務クラス階層を切ったときに起こりがちです。
失敗 3：どの経路で解決されたか追えず、デバッグが困難になる
上の 2 つは、いずれも「継承パスが頭の中だけにあって、可視化されていない」ことが根本原因です。ルール解決は継承経路に沿って進むため、経路が曖昧なままだと「なぜこのルールが選ばれた／選ばれなかったか」を再現的に説明できません。
対策：クラス名の設計段階で継承パスを図示して検証する
これらは実装時ではなく、クラス命名を決める段階で防ぐ問題です。作業プールなどの束ね先クラスがどの Pega 基底クラスへ直接継承でつながるか、パターン継承でどのルールがどこまで行き渡るかを、一度図に起こして検証してください。命名規則がそのまま継承構造になる以上、命名レビュー＝継承レビューです。図示しておけば、失敗 1〜3 のほとんどは着手前に潰せます。
まとめ
- Pega の継承は 2 種類。パターン継承は名前で暗黙にたどり先に探索され、直接継承は明示指定の親（多くは作業プール → 基底クラス）へ引き継ぐ。
- ルール解決はパターン継承の祖先を先に探索し、尽きたら直接継承の親へ引き継ぐ（
@baseclassまで繰り返す）。パターン継承を無効化すれば直接継承のみで解決される。 - 使い分けの定石は、業務クラスはパターン継承で作業プール配下に束ね、その作業プール（クラスグループ）から Pega 基底クラス（Work-/Data- 等）へは直接継承で橋渡しする。
- 命名規則がそのまま継承構造になるため、改名コストが高い。クラス名の設計段階で継承パスを図示し、意図しない再利用・未解決・デバッグ困難を先に潰す。
継承構造はアプリケーション全体のルール再利用性と保守性の土台です。設計初期にここを正しく決めておくことが、後工程での大きな手戻りを防ぎます。
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 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読む