Pega の Picklist と Data Reference の使い分け

結論から：起点は「値だけ要るのか、レコード＋属性/関係が要るのか」

Pega でケースやデータモデルを設計していると、「マスタや選択肢をどうフィールドに紐づけるか」という判断が必ず出てきます。都道府県、契約種別、担当部署、取引先——こうした参照データを画面のフィールドに結びつけるとき、Pega には主に Picklist と Data Reference という 2 つのやり方があります。どちらも「参照データを扱う」仕組みなので混同されがちですが、性質はまったく違います。

結論を先に言うと、選択の起点はたった 1 つの問いです。

そのフィールドで欲しいのは「値そのもの」だけか、それとも「マスタのレコード（＋その属性や関係）」か？——値だけなら Picklist、レコードを参照するなら Data Reference。

「どちらでも動くから、慣れているほう」で選んでしまうと、後から Report Definition の join を手書きしたり、UI で参照先の名称を引くためにわざわざクエリを組んだり、という追加工数が積み上がります。Pega が model-driven（メタデータ駆動）を志向している以上、マスタを参照する場面では Data Reference を使い、Pega に後工程を肩代わりさせるのが実務の型です。本記事では、この判断を具体的な分岐として整理します。

Picklist とは — 「値」を選ばせる仕組み

Picklist は、フィールドに対して「選べる値の一覧」を提供する仕組みです。参照データを 値として 保持し、ユーザーはその中から 1 つを選びます（Picklist は単一値フィールドで、選ばれた値がプロパティに格納されます）。ドロップダウンで「未着手／進行中／完了」を選ばせる、といった典型的な選択肢がこれにあたります。

ポイントは、Picklist が扱うのは あくまで値である ということです。フィールドには選ばれた値（コードやラベル）が入るだけで、その値の「向こう側にあるレコード」への参照は持ちません。値の一覧をローカルに列挙する場合もあれば、Data Page から動的に一覧を取得する場合もありますが、いずれにせよ結果としてフィールドに格納されるのは単一の値です。

• 長所 — シンプル。値の集合が固定的・単純なとき（区分値、ステータス、Yes/No 的な選択）に軽量で分かりやすい
• 短所 — 選んだ値に紐づく他の属性（名称、住所、担当者など）を後から使いたくなると、自前でクエリして引き当てる必要がある

Data Reference とは — マスタの「レコード」を参照する仕組み

Data Reference は、フィールドを マスタのレコードそのものへの参照 として結びつけます（Data Type にリンクしたフィールドで、ユーザーはその Data Type のレコード＝インスタンスを選択します）。値だけでなく、そのレコードが持つ 属性全体、さらに関連する他レコードとの関係 までを扱えるのが決定的な違いです。

たとえば「取引先」を Data Reference で参照すると、フィールドには取引先レコードへの参照が保持されます。取引先コードだけでなく、取引先名・住所・与信ランク・担当営業といった属性に、参照経由でそのままアクセスできます。ユーザーが画面で取引先を選べば、Pega が裏側でそのレコードを（主キーをパラメータに取る単一ページの Data Page 経由で）解決し、UI 側は関連属性を自動で引いて表示します。

Data Reference は Pega のデータモデルにおいて「エンティティ同士をつなぐ」役割を担います。単なる入力補助ではなく、データモデル上の関係を宣言する 手段だと捉えると位置づけが明確になります。

なお、参照先データの 取得挙動は構成で選べます。データページを「参照する（refer to a data page）」構成にすると、フィールドはマスタを指し続け、アクセスのたびに最新のレコードが解決されます。一方「コピーする（copy data from a data page）」構成にすると、取得時点のスナップショットがケースに保存され、以降はマスタ側の変更は自動では反映されません。常に最新のマスタを見せたいのか、ある時点の状態を固定したいのかで選び分けます（＝「Data Reference なら常に最新」と一括りにはできず、参照構成のときにその特性が効きます）。

判断軸：値か、レコード＋属性/関係か

両者を分ける本質的な問いは、繰り返しになりますが「値だけで足りるか、レコードとその属性・関係が要るか」です。表で整理します。

判断ポイント	Picklist	Data Reference
保持するもの	選ばれた値（コード/ラベル）	マスタレコードへの参照
属性へのアクセス	選んだ値のみ。他属性は自前で引く	参照経由で属性全体にアクセス可
他レコードとの関係	扱わない	関係（関連レコード）を扱える
クラス間の関係のモデル化	されない（値のみ）	参照としてモデルに載る
Report Definition の join	レポートごとに class join を手組み	Association ルールで宣言・再利用できる
UI での参照先解決	自前で名称等を引き当てる	UI が自動解決
向いている場面	固定的・単純な選択肢、区分値	マスタ参照、エンティティ間の関連
default 判断	選択肢はこちら	マスタはこちら

default（既定の判断）は明快です。単純な選択肢なら Picklist、マスタを参照するなら Data Reference。 迷ったときは「このフィールドの値をキーに、あとで別の属性や関連データを引きたくなるか？」を自問してください。少しでも Yes の気配があれば Data Reference が正解です。

Data Reference が肩代わりしてくれること

Data Reference を選ぶ最大の理由は、Pega が model-driven の思想に沿って 後工程を省力化してくれる 点にあります。ここが Picklist との実装工数の差を生みます。

1. クラス間の関係がモデルに載る

Data Reference を定義すると、参照元クラスが「どのクラスの、どのレコードを、どのキーで参照しているか」という関係がデータモデル上に明示されます。この関係を土台に、レポートで参照先を跨いで集計したくなったときは Association ルール（Rule-Obj-Association） を定義します。Association は「このクラスとあのクラスは、このキーでつながっている」という関係の宣言で、一度作れば複数のレポートから再利用でき、後続の join や属性参照がすべてこの関係の上に乗ります。

一方 Picklist が保持するのは値だけで、参照先クラスとの関係はモデルに残りません。つながりは開発者の頭の中だけに存在し、レポートで別属性を引きたくなるたびに join を個別に組むことになります。Data Reference で関係が明示されているぶん、この Association 定義も素直に組めます。

補足（バージョン依存）: Association ルールは、Data Reference を作れば必ず自動生成される、というものではありません。レポート用途に応じて作成し、複数レポートで再利用する設計要素です。App Studio の Explore Data／Insights など一部の文脈では単純な関連が自動的に提示されることもありますが、挙動は Pega のバージョンによって異なります。利用中の版の公式ドキュメントで確認してください。

2. Report Definition の join が宣言的に書ける

Association を一度定義しておけば、Report Definition では参照先の属性を 宣言的に 引けます。「取引先の与信ランクでフィルタしたい」「担当営業名を列に出したい」といった要件を、定義済みの Association を選ぶだけで表現でき、レポートごとに join 条件を手で書く必要がありません。Pega は Association を参照したレポートで、生成される SQL に適切な JOIN を自動的に追加します。

Picklist ＋手動クエリの場合、そもそも参照関係がモデルに無いため、join 対象のクラス・結合キー・条件をレポートごとに（class join として）手書きします。1 箇所なら大した手間ではありませんが、同じマスタを 10 のレポートで参照していれば、10 箇所で同じ join を書き、マスタ構造が変われば 10 箇所を直す羽目になります。再利用可能な Association なら、定義は 1 つ、直すのも 1 箇所です。

3. UI が参照先を自動解決する

画面でも差が出ます。Data Reference では、ユーザーが参照先レコードを選ぶと UI がそのレコードを自動解決 し、関連する属性（名称や付随情報）を追加実装なしで表示できます。Picklist で同じ体験を作るには、選ばれた値をキーに名称等を引くロジックを都度用意することになります。

つまり Picklist ＋手動クエリは、Data Reference の省力化をあえて捨てた版 です。捨てるだけの理由（値しか要らない、マスタと呼べる実体がない）があるなら妥当ですが、マスタ参照でこれをやると model-driven のメリットを手放し、宣言で済むものを命令的コードで書き直すことになります。

具体例で見る使い分け

• ステータス区分（未着手／進行中／完了） → 値だけで足り、向こう側にレコードはない。Picklist。
• 優先度（高／中／低） → 単純な区分値。Picklist。
• 取引先 → 名称・住所・与信・担当など属性を後で使う。関連レコードもある。Data Reference。
• 担当部署 → 部署マスタのレコード。部署長や上位組織との関係を辿りたい。Data Reference。
• 商品 → 商品マスタ。価格・カテゴリ・在庫と関連づく。Data Reference。

見分け方はシンプルで、「それは単なる 値の集合 か、それとも 台帳（マスタ）に実体のあるレコード か」です。台帳側に 1 行として存在し、他の属性を伴うなら Data Reference を選びます。

よくある失敗

マスタ参照を Picklist で済ませてしまう。 最も多い失敗です。「コードを選べればいい」と Picklist にした結果、後から名称表示・レポートでの絞り込み・関連データの参照が要件に加わり、その都度クエリを手書きすることになります。参照関係がモデルに残らないため関係が可視化されず、保守の手掛かりも残りません。初手で Data Reference にしていれば、関係がモデルに載り、Association を定義して宣言的に片付けられたはずの作業です。

逆に、単純な区分値を Data Reference にして重くする。 これも起こります。向こう側にレコードとしての実体がない（属性も関係もない）区分値まで Data Reference にすると、参照先のデータクラスやレコードを無用に用意することになり、モデルが不必要に複雑化します。属性も関係も持たない値は Picklist で十分 です。

「動くから」で選び、後から整合性が崩れる。 どちらの方式でも初期の画面は動きます。問題は、マスタ側の構造変更やレポート追加が発生したときに顕在化します。設計時点で「値か、レコードか」を言語化しておかないと、同じマスタが Picklist と Data Reference で混在し、参照方法がフィールドごとにバラバラという保守しづらい状態に陥ります。

まとめ

Picklist と Data Reference の使い分けは、機能比較ではなく データの性質 で決まります。

• 値だけ要るなら Picklist — 単純な区分値・選択肢。軽量でシンプル。
• レコード＋属性/関係が要るなら Data Reference — マスタ参照。関係のモデル化・Association による宣言的で再利用可能な join・UI 自動解決という Pega の省力化をフル活用できる。
• default は明快 — 選択肢は Picklist、マスタは Data Reference。
• Picklist ＋手動クエリは省力化を捨てた版 — マスタ参照でこれを選ぶと、model-driven のメリットを手放し、命令的コードで書き直すことになる。

「値か、レコードか」——この 1 問を設計の最初に言語化しておくだけで、後工程のレポート・UI・保守の工数が大きく変わります。判断を機械的に下せる型として、チームで共有しておく価値があります。

関連リンク

• Pega Platform 開発支援
• Pega のケースとデータインスタンスの使い分け
• Pega Constellation UI と Cosmos の違いを徹底比較
• 無料相談に申し込む