Pega 計算ロジックの置き場所｜Declare Expression と Data Transform の使い分け
「この派生値、Declare Expression にすべきか Data Transform で書くべきか」——Pega の設計レビューで繰り返し問われる分岐です。宣言的ルールは常に整合を保てる一方、前方連鎖の依存が広がると 1 回の更新が大量の再計算を招きます。本記事では再計算タイミングと保守性・性能のトレードオフから、計算ロジックの置き場所を判断する基準を示します。
結論から：常に整合が要る派生値は宣言的、順序・外部・分岐は手続き的
Pega で「合計金額」「割引率」「与信スコア」といった計算プロパティを設計するとき、必ず出てくるのが「この計算をどこに書くか」という問いです。選択肢は大きく 2 つ——依存元の変化に応じて Pega が自動で再計算してくれる Declare Expression（宣言的ルール） と、明示的に呼び出したときだけ動く Data Transform / Activity（手続き的ロジック） です。
結論を先に言うと、判断の起点は 1 つです。
依存元が変われば「常に整合していてほしい」派生値は Declare Expression。順序依存・外部呼び出し・複雑な分岐を含む計算は Data Transform / Activity。
「慣れているから全部 Data Transform」でも「宣言的が今風だから全部 Declare Expression」でも、どちらも設計の失敗につながります。前者は値の整合を人手のロジックで保証し続ける負債を抱え、後者は再計算の連鎖が広がって性能を落とします。本記事では、この判断を具体的なゲートに分解します。
Declare Expression と Data Transform は何が違うのか
まず両者の性質を整理します。
- Declare Expression（宣言的） — 「このプロパティ ＝ 別のプロパティを使った式」という関係を宣言するルール。Pega が依存プロパティ（式の入力）の変化を検知し、明示的に呼ばなくても自動で再計算します。書くのは「何が正しいか（結果と入力の関係）」であって、「いつ・どの順で計算するか」ではありません。
- Data Transform / Activity（手続き的） — 上から順にステップを実行するロジック。呼び出されたときだけ動きます。順序制御、外部データの取得、条件分岐、ループなど「どう処理するか」を明示的に書きます。
決定的な違いは 「整合の維持を誰が保証するか」 です。Declare Expression は関係を宣言した時点で、以降 Pega が整合を保ち続けます。Data Transform は、入力が変わるたびに開発者が「再計算のステップをまた呼ぶ」ことを設計に組み込まなければ、値は古いまま取り残されます。
2 つの判断ゲート
ゲート1：常に整合していてほしい派生値か
その値が「依存元が変わったら、必ず追随してほしい」ものかを問います。言い換えると、結果が入力プロパティの純粋な関数として書けるか、です。
- 書ける → Declare Expression の候補
- 書けない（外部状態・順序・副作用に依存する） → ゲート2 で手続き的へ
例：「合計金額 ＝ 単価 × 数量」は、単価か数量が変われば合計も必ず変わってほしい純粋な関数です。ここを Data Transform で書くと、数量を変えた画面イベントごとに再計算処理を呼ぶ配線が必要になり、呼び忘れれば合計がずれます。Declare Expression なら、依存を宣言するだけで整合が保たれます。
ゲート2：順序依存・外部呼び出し・複雑な分岐を含むか
ゲート1 を通っても、計算そのものが手続き的な性質を持つなら宣言では表現しきれません。次のいずれかを含むなら Data Transform / Activity です。
- 順序依存 — 「顧客ランクで基本割引を決め → キャンペーン加算し → 上限でクリップする」のように、ステップの実行順序が結果を左右する
- 外部呼び出し — 信用情報 API・外部マスタ・コネクタを叩いて値を取得する（宣言的ルールに副作用のある取得処理を持たせるべきではない）
- 複雑な分岐・ループ — 多段の条件、明細を走査しての判定など、式 1 本では読めなくなるロジック
これらは「いつ・どの順で・何を呼ぶか」を制御する必要があり、手続き的ロジックの領分です。無理に宣言に押し込むと、かえって読めない式になります。
前方連鎖と後方連鎖 — 再計算のタイミング
Declare Expression を選んだら、次に決めるのが再計算のタイミングです。ここが性能設計の要になります。
- 前方連鎖（Whenever inputs change） — 入力プロパティが変わった瞬間に即再計算する。常に最新値が用意されているが、更新のたびに計算コストがかかる。
- 後方連鎖（Whenever used／必要時） — その値が参照された時点で計算する。使われるまで計算しないぶん無駄がないが、参照時に計算コストが発生する。
| 観点 | 前方連鎖（Whenever inputs change） | 後方連鎖（Whenever used） |
|---|---|---|
| 計算の起点 | 入力プロパティの変更時 | 値が参照された時 |
| 値の鮮度 | 常に最新が保持される | 参照した瞬間に確定 |
| 向いている場面 | 頻繁に参照・表示される値 | まれにしか使われない値、重い計算 |
| コストの出方 | 更新のたびに計算 | 参照のたびに計算 |
| 注意点 | 依存が広いと連鎖が暴走 | 参照が多いと都度計算が積む |
判断の目安は「参照頻度と入力更新頻度、どちらが高いか」です。画面に常時表示され頻繁に読まれる値は前方連鎖、めったに使われないが計算が重い値は後方連鎖が向きます。
計算オプションの名称や設定 UI は Pega のバージョンによって異なる場合があります（Declare Expression フォームの計算タイミング欄は版により「Calculate value」等と呼称が変わります）。実装時は、対象バージョンの Declare Expression の計算タイミング設定を公式ドキュメントで確認してください。
ページリストの集計は Declare Expression が効く
見落とされがちですが、ページリスト（明細）の集計は Declare Expression の最も効果が出る使いどころです。Sum・Count・Average・Max・Min といった集計や、条件付きの合計を、式として宣言的に書けます。
たとえば「注文明細の金額合計」を Activity のループで書くと、行の追加・削除・金額変更のたびに集計処理を呼び直す配線が要り、呼び忘れれば合計が狂います。Declare Expression の集計（Sum of 等）なら、明細に行が追加・削除・変更されるたびに合計が自動で追随します——これは Pega 公式でも代表例として挙げられている使い方です。ロジックが 1 箇所に集約され、「合計はどこで決まるのか」が一目で分かるため、保守性も監査性も上がります。
- 明細の合計・件数・平均 → Declare Expression の集計
- 在庫数や残高の積み上げ → Declare Expression の集計
- 走査しながらの複雑な判定（条件が多段で分岐する等） → Data Transform / Activity
判断早見表
| 観点 | Declare Expression | Data Transform / Activity |
|---|---|---|
| 性質 | 宣言的（関係を定義） | 手続き的（順に実行） |
| 実行契機 | 依存の変化で自動 | 明示的に呼んだとき |
| 整合の維持 | Pega が保証 | 開発者が配線して保証 |
| 向いている計算 | 常に整合が要る派生値・集計 | 順序依存・外部呼び出し・複雑な分岐 |
| 再計算タイミング | 前方連鎖／後方連鎖を選べる | 呼び出し時のみ |
| 監査性 | 値の決定箇所が 1 つに集約 | 呼び出し箇所が分散しがち |
| 主なリスク | 依存が広いと再計算の連鎖が暴走 | 呼び忘れ・順序ミスで値がずれる |
上の判断軸で「常に整合が要る」かつ「順序・外部・分岐を含まない」なら Declare Expression、いずれかを外れるなら Data Transform——これが実務での型です。
よくある失敗
失敗1：前方連鎖の依存を広げすぎて再計算が暴走する
最も深刻な失敗です。前方連鎖の Declare Expression は、依存プロパティが変わるたびに再計算します。この依存が広く・深く連なっていると、1 つのプロパティを更新しただけで、それに連なる大量の Declare Expression が芋づる式に再計算され、1 回の更新が重い処理に化けます。
- A が B を参照し、B が C を参照し……と依存チェーンが長い
- 1 つの入力を、多数の Declare Expression が共有して参照している
こうした構造では、頻繁に更新される入力に前方連鎖をぶら下げると性能が急激に劣化します。対策は、頻繁には使われない重い派生値を後方連鎖に回す、依存チェーンを浅く保つ、そもそもその値が常時最新である必要があるかを問い直す、の 3 点です。連鎖の影響が疑わしいときは、Pega の Performance ツール（Rule Execution Counts 等）で宣言的処理の実行回数を実測して確認します。
失敗2：手続き的に書くべきものを宣言に押し込む（またはその逆）
外部 API 呼び出しや順序依存の判定を Declare Expression の式に詰め込むと、副作用や実行順序が式の裏に隠れ、挙動が追えなくなります。逆に、単純で常に整合が要るだけの派生値を Data Transform で書くと、入力変更のたびに再計算を呼ぶ配線が増え、呼び忘れによる不整合の温床になります。ゲート1・ゲート2 に立ち返って選び直すのが正解です。
失敗3：計算箇所が散らばって監査性が下がる
同じ「合計金額」を、ある画面では Declare Expression、別のフローでは Data Transform、さらに Activity でも上書き——という混在は、実際の現場でよく起きます。こうなると「この値は結局どこで決まっているのか」を追うのに時間がかかり、不具合調査も監査も難航します。加えて Pega 公式は、Declare Expression が算出するプロパティを、Property-Set・Data Transform・画面入力など別経路で書き換えないことを明記しています（宣言的計算の前提が崩れるため）。つまりこれは単なる可読性の問題ではなく、正しく動かすための制約でもあります。1 つの派生値の決定箇所は 1 つに集約するという原則を、設計時に明示しておくことが重要です。
まとめ
- 常に整合が要る派生値は Declare Expression、順序依存・外部呼び出し・複雑な分岐は Data Transform / Activity。 これが起点の判断。
- Declare Expression を選んだら、前方連鎖（入力変更で即）／後方連鎖（参照時） を参照頻度とコストで選び分ける。
- ページリストの集計（Sum / Count / Average / Max / Min）は Declare Expression が最も効く——Activity のループより整合も保守性も上。
- 失敗は 3 方向——前方連鎖の連鎖暴走・宣言と手続きの取り違え・計算箇所の分散による監査性低下。いずれもゲート1・2 と「決定箇所を 1 つに集約」で防げる。
計算ロジックの置き場所は、Pega アプリケーションの性能・保守性・監査性を静かに左右します。設計の初期に「この値は宣言的か手続き的か、再計算はいつか」を言語化しておくことが、後工程の手戻りを防ぐ最短ルートです。
Pega の設計・実装でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、設計判断からご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む