Pega埋め込みデータと参照データの使い分け｜スナップショットか最新かで決める
データを直接ケースに内包する埋め込みと、キーだけ持って都度取得する参照は、どちらも正解になり得ます。分岐点は「その値は時点で固定すべきか、常に最新であるべきか」。本記事では鮮度要件・性能・レポート性の3軸で、埋め込みと参照の使い分けを整理します。
結論から：スナップショットか最新かで決める
Pega でケースのデータモデルを設計していると、「顧客の住所」「商品の価格」「取引先の情報」といった関連データを、ケースの中に直接持たせるべきか、キーだけ持って必要なときに取りに行くべきか、という判断が必ず出てきます。前者が 埋め込み（aggregation）、後者が 参照（association） です。どちらも動くので「なんとなく」で選ばれがちですが、選択を誤ると後から陳腐化したデータや肥大化したケースに悩まされます。
結論を先に言えば、判断軸はたった 1 つです。
その値は「ある時点で固定すべき」か、それとも「常に最新であるべき」か。時点で固定するなら埋め込み、常に最新が要るなら参照。
注文したときの配送先住所のように「その時点の事実」を記録したい値は埋め込み、現在の商品価格のように「いま参照すべき最新値」が要る値は参照——これが原則です。「重要だから埋め込む」「軽くしたいから参照する」ではなく、データの鮮度要件で決めます。本記事ではこの判断軸を、性能・整合性・レポート性の観点まで掘り下げて整理します。
埋め込み（aggregation）と参照（association）とは何か
まず両者が技術的に何をしているのかを整理します。
埋め込み（aggregation） は、関連データを ケース自身のページ／ページリストとして内包する 方式です。データそのものがケースのクラスインスタンスの一部として保存され、Pega では通常この本体は BLOB（ストレージ・ストリーム） に格納されます。ケースを開けば、内包された値がそのまま手元にあり、外部を取りに行く必要はありません。「そのケースが所有する自分のデータ」という位置づけです。
参照（association） は、関連データそのものは持たず、そのレコードを特定できるキーだけを保持 する方式です。実際の値は必要になったタイミングで データページ（Data Page）経由で取得 します。ケースには「どのマスタの、どのレコードか」という手掛かりだけが残り、値の実体はマスタ側にあります。「外部の権威あるデータを、都度見に行く」という位置づけです。
Pega Academy の用語では、この 2 つはそれぞれ スナップショット・パターン（embedded data） と システム・オブ・レコード（SoR）パターン／参照（referenced data） と呼ばれます。データモデル上の関係として見ると、親が子を「所有」して子が独立して存在しない 1:M 関係が aggregation、親が所有せずマスタが独立したライフサイクルを持つ関係が association にあたり、前者は内包（スナップショット）として、後者は参照として実装するのが自然な対応です。なお、データページのリロード挙動や公開列（exposed column）の最適化手順といった細部はバージョンにより異なる場合があるため、実装時は公式ドキュメントで確認してください。
この違いは、そのまま「値がいつの時点のものになるか」に直結します。埋め込みは保存した瞬間の値が固定され、参照はデータページ経由で解決されて鮮度はそのデータページのリロード戦略とスコープに従います（適切に設計すれば常に最新を映せます）。だからこそ、選択の起点は鮮度要件になります。
判断軸：スナップショットか、最新か
時点で固定すべき値は埋め込み
業務では「その時点でこうだった」という事実を記録として残さなければならない場面が数多くあります。
- 注文時点の配送先住所 — 顧客がその後に引っ越しても、過去の注文の届け先は当時の住所でなければ帳簿として成立しません。
- 申込時点の申告内容 — 審査は申込時に申告された値に対して行われます。後からマスタ側が変わっても、申込の記録は当時のまま固定されている必要があります。
- 契約締結時の適用料率・条件 — 契約はその時点の条件で成立しており、以降のマスタ改定に引きずられてはいけません。
これらはいずれも「後から変わってはいけない過去の事実」です。マスタが変わっても記録は動いてはならないので、スナップショットとして埋め込むのが正解です。参照にしてしまうと、マスタ更新のたびに過去の記録まで書き換わってしまい、監査や整合性の観点で破綻します。Pega の公式ドキュメントでも、スナップショットとして埋め込んだデータは「リクエストパラメータが変わらない限りソースから再取得されない」とされており、これはまさに時点固定が要件のときに使う挙動です。
常に最新が要る値は参照
逆に、「いま現在の正しい値」を見せたい場面では参照を選びます。
- 現在の商品価格 — 価格改定があれば、画面や計算は常に最新の価格を使うべきです。
- 在庫数・与信枠 — 刻々と変わる値を、ケースにコピーした古い値で判断してはいけません。
- 顧客マスタの連絡先や属性 — マスタが SSoT（信頼できる唯一の情報源）であり、ケースはそれを参照して最新を映すだけにします。
これらは、マスタ側が権威を持ち、ケースは「その最新を映す窓」であるべき値です。埋め込んでしまうと、埋め込んだ瞬間から値が古くなり始め、マスタ更新との乖離（陳腐化）が発生します。マスタが権威を持つ最新値は、キーだけ持って参照するのが原則です。
性能とデータ整合性の観点
鮮度要件で方向は決まりますが、性能と整合性の副作用も理解しておく必要があります。
埋め込みはケースを重くします。 内包したデータはケースの BLOB に取り込まれるため、大量のデータや大きなページリストを埋め込むと BLOB が肥大化し、ケースの読み書きコストが上がります。特に、際限なく伸びるページリストを埋め込むと、更新のたびに BLOB 全体を書き換えることになり、設計上避けるべきパターンとされています。さらに、埋め込んだ時点の値が固定されるということは、マスタ側が更新されても埋め込み側は古いままという陳腐化リスクを常に抱えます。これは時点固定が要件のときは「仕様」ですが、最新であるべき値を誤って埋め込むと「バグ」になります。
参照はケースを軽く保ちます が、そのぶん データページのロードと可用性に依存 します。値を取りに行く先が応答しなければ表示・処理が滞りますし、解決のたびにコストが発生します。データページのスコープやリロード戦略、参照先の可用性を含めて設計する必要があります。裏を返せば、参照はマスタが SSoT である構造を素直にモデル化でき、整合性の面では有利です。Pega の設計ベストプラクティスでも、システムが計算を行う必要がない場合は、スナップショットとして BLOB に埋め込むのではなく、ケースからマスタへの Lookup（SoR パターン）や JOIN を使うことが推奨されており、BLOB への参照データの埋め込みは要件がある場合を除いて避けるべきだとされています。
レポートの観点
見落とされがちですが、レポート（集計）のしやすさも選択に影響します。
埋め込んだ集約データは ケースの BLOB の中 にあります。Pega では、埋め込みページ内のプロパティや非公開のプロパティは Storage Stream（BLOB）に格納され、公開列（exposed column）としてテーブルの実カラムに出す（レポート用に最適化する）といった対応をしないと、Report Definition から素直に集計・絞り込みができません。「埋め込んだから安心」ではなく、レポート要件があるなら公開・最適化の設計が別途必要になります。
一方、参照データは マスタ側の自前テーブル に実レコードとして存在するため、そのテーブルを直接レポートで扱えます。関連の定義（Association）を土台に、クラスをまたいだ集計も宣言的に組みやすくなります。実際、Association（アソシエーション）ルールはクラス間の関係を定義し、Report Definition で複数クラスをまたいでレポートの範囲を広げるために使えます。「後でこの値を軸に集計したい」という要件が濃いなら、参照のほうがレポートは扱いやすいことが多いです。
判断早見表
| 観点 | 埋め込み（aggregation） | 参照（association） |
|---|---|---|
| 保持するもの | データ本体をケースに内包 | キー（参照）のみ |
| 鮮度 | 保存時点で固定（スナップショット） | 参照時にデータページで解決（最新化はリロード戦略に依存） |
| 取得方法 | ケース内に既にある | データページ経由で取得 |
| ケースの重さ | BLOB を肥大させやすい | 軽く保てる |
| 整合性リスク | 陳腐化（マスタ更新と乖離） | 参照先の可用性に依存 |
| レポート | BLOB 内。公開/最適化が必要 | 自前テーブルで扱いやすい |
| 向いている値 | 時点固定の事実（注文時住所・申込内容） | 常に最新のマスタ（価格・在庫・顧客） |
「その値は後から変わってよいか」——変わってはいけない過去の記録なら埋め込み、常に最新であるべきならマスタを参照する。 これが実務での判断の型です。
具体例で見る使い分け
- 注文の配送先住所 → 出荷後に引っ越しても当時の住所で固定したい。埋め込み。
- 注文明細の単価・数量 → 注文時点で確定した取引条件。後の価格改定に影響されてはならない。埋め込み。
- 商品の現在価格 → 常に最新を表示・計算に使う。参照。
- 顧客マスタの連絡先 → マスタが SSoT で、最新を映すだけでよい。参照。
- 在庫数 → 刻々と変わる。古いコピーで判断してはいけない。参照。
見分け方はシンプルです。「この値をキャプチャした瞬間の姿で保存したいか、それともいつ見ても最新であってほしいか」 を問えば、ほぼ機械的に方向が決まります。
よくある失敗
頻繁に変わる大量マスタを丸ごと埋め込む。 最も多く、最も痛い失敗です。「取りに行くのが面倒だから」「1 画面で完結させたいから」と、商品マスタや顧客マスタをケースに丸ごと埋め込むと、次の 2 つの問題が同時に起きます。第一に 陳腐化 —— マスタが更新されても埋め込んだ値は古いまま乖離します。第二に BLOB 肥大 —— 大量データを内包したケースは読み書きが重くなり、性能を圧迫します。マスタは参照で持ち、最新をデータページから解決するのが正解です。
逆に、時点固定すべき記録を参照で済ませる。 「マスタにあるから参照でいい」と、注文時の住所や契約時の条件まで参照にしてしまうと、マスタ側が更新された瞬間に過去の記録まで書き換わってしまいます。監査証跡や帳簿として成立しなくなる、静かで発見の遅い不具合です。時点で固定すべき事実は、必ずスナップショットとして埋め込む必要があります。
鮮度要件と更新頻度を言語化しないまま実装する。 埋め込みか参照かは、機能比較ではなく データの性質（時点固定か最新か、更新頻度、件数）で決まります。設計時にここを言語化しておかないと、同じような値がフィールドごとに埋め込みと参照でバラバラになり、どの値がいつの時点のものか誰も追えない保守しづらい状態に陥ります。データの鮮度要件と更新頻度で構造を決める——これを設計文書に明記しておくことが、後工程の手戻りを防ぎます。パフォーマンスのためにあえてスナップショットを埋め込む場合も、「いつ時点の値をキャプチャしたか」を明確に記録しておくことが公式にも求められています。
まとめ
- 起点は鮮度要件 —— 時点で固定すべき値は埋め込み（スナップショット）、常に最新であるべき値は参照（データページで解決）。
- 埋め込みはケースを重くし陳腐化リスクを持つ —— 大量・頻繁更新のマスタを丸ごと埋め込むと BLOB 肥大と乖離を招く。
- 参照はケースを軽く保つがデータページの可用性に依存する —— マスタが SSoT である構造を素直にモデル化でき、レポートも扱いやすい。
- 失敗は 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 の視点で解説します。
記事を読む