Pega の参照データはどこに置く？DataType・Picklist・クラスの判断
Pega で参照データ（コード表・選択肢・マスタ）を DataType・Picklist・専用クラスのどこに置くかを、「1回定義して再利用するか」という判断軸を起点に整理します。
結論から：起点は「その値域を1回定義して複数箇所で再利用するか」
Pega でアプリケーションを設計していると、必ず「このコード表や選択肢、マスタ的なデータをどこに置くか」という判断が出てきます。ステータス区分、都道府県、契約種別、商品カテゴリ——こうした参照データを DataType にすべきか、フィールドの Picklist で済ませるか、それとも専用のデータクラスを起こすべきか。設計初期の小さな判断に見えて、ここを外すと後工程で表記ゆれ・修正漏れ・データ移行といった手戻りが連鎖します。
結論を先に言うと、判断の起点はたった1つの問いです。
その値域を「1回定義」して、独立した複数の箇所から再利用するか？——YES なら DataType、単一箇所限定なら Picklist、値だけでなく属性や関係を持つなら専用クラス。
多くの現場で見かけるのは「業務上大事なマスタだから DataType にする」という選び方です。しかしこの発想は、たいてい過剰にも過少にもなります。判断すべきは重要かどうかではなく、再利用の広がりとデータの複雑さ——これが実務での型です。本記事では、この起点を具体的な分岐に落とし込み、あわせてコードマスタ設計の要点まで整理します。
3つの置き場所は何が違うのか
まず選択肢を正確に押さえます。3つは「軽さ」と「表現力」がきれいに逆順に並んでいます。
- Picklist（フィールドローカルな選択肢 / local list） — そのプロパティ1つに紐づく選択肢のリストを、フィールド内に直接定義する。実体（Data Type のインスタンス＝テーブルの行）を持たず、そのフィールドの中で完結する。定義コストが最も軽い一方、同じ値域が別の場所にも必要になると再利用できない。
- DataType（Data Type として実体化） — 値域を1つの Data Type として実体化し、各所からその Data Type を参照する。1箇所直せば参照している全画面・全ルールに反映される。定義の手間は増えるが、保守性が最も高い。
- 専用の Data クラス — 値そのものだけでなく、付随する属性（表示名・並び順・有効フラグ・関連する別値など）や、他のデータとの関係を持つ複合的なもの。単なる選択肢ではなく「構造を持つ参照データ」。
Pega の用語補足：Pega では「Picklist」はフィールドの型であり（フィールド追加時に Type として「Picklist」を選ぶ）、その選択肢のソースとして「ローカルリスト（local list：フィールド内に選択肢を直接定義。内部的にはプロパティの Table type が Prompt List になる）」か「Data Type／データページ参照（reference data）」かを選びます。つまり厳密には「Picklist か DataType か」ではなく、選択肢のソースが local list か Data Type かという軸です。本記事では前者を「Picklist」、後者を「DataType」と呼び分けています。Pega 公式もこの判断を reference data design pattern（参照データ設計パターン） として体系化しています（Pega Academy／docs.pega.com）。細部の UI・挙動はバージョンで異なるため、利用中の版の公式ドキュメントで確認してください。
Picklist は軽いぶん、同じ値域が複数の画面やルールに現れたときにバラバラに定義され、表記ゆれや修正漏れを生みます。逆に、1フィールドでしか使わない選択肢まで DataType として実体化するのは、定義・維持のオーバーヘッドに見合いません。適材適所こそが本質です。
判断の分岐
次の順で自問すると、迷いなく決まります。上から順に降りていくだけです。
分岐1：値だけか、属性や関係を持つか
まず「置きたいものが単なる値の集合なのか、属性や関係を持つ構造なのか」を見ます。
- 値＋属性/関係を持つ（表示名・並び順・有効期間・親子関係・別マスタへの紐づけなど） → 専用の Data クラス
- 値（＋せいぜいラベル）の集合にすぎない → 分岐2へ
例：「支店」は支店コードだけでなく、名称・地域・管轄・有効フラグを持ち、担当者マスタとも関係します。これは選択肢ではなく構造なので専用クラスです。一方「優先度（高・中・低）」は値の集合にすぎないので、次の分岐に進みます。なお「レコードとして参照したいか」の詳細な判断は、別記事のPicklist と Data Reference の使い分けも参考になります。
分岐2：1箇所限定か、複数箇所で再利用するか
値の集合だと分かったら、次は再利用の広がりを見ます。
- 独立した複数の箇所（複数のケースタイプ、複数の画面、レポート、ルール）で同じ値域を使う → DataType として実体化し、各所から参照する
- 単一のフィールドでしか使わない、そのフォーム内で完結する → Picklist で十分
ここが最も判断の分かれるポイントです。「1回定義して再利用する」を選ぶと、後の保守が劇的に楽になります。値域に1つ項目を足す・並びを変える・廃止する、といった変更が1箇所の修正で全参照に反映されるからです。逆に Picklist で同じ値域を各所に重複定義していると、変更のたびに全箇所を探して直す羽目になり、必ず表記ゆれと修正漏れが発生します。
判断に迷ったら「この値域は、いま作っている画面以外の場所でも出てくるか？」を自問してください。2箇所目が思い浮かんだ時点で、それは DataType の候補です。
判断早見表
| 置きたいもの | 選ぶべき置き場所 | 主な理由 |
|---|---|---|
| 単一フィールド限定の選択肢 | Picklist | 実体化は過剰。フォーム内で完結する |
| 複数箇所で再利用する値域（コード表） | DataType | 1箇所直せば全参照に反映。保守性が高い |
| 値＋属性/関係を持つ複合データ | 専用クラス | 選択肢ではなく構造。属性・関連を保持できる |
単一フィールド限定なら Picklist、複数箇所で再利用する値域なら DataType、値に属性や関係がぶら下がるならクラス——この3行が判断の型です。設計レビューでは、この表に照らして「なぜその置き方にしたか」を一言で説明できる状態を目指します。
レポート表示という見落としがちな観点
もう1つ、置き場所を左右する重要な観点があります。レポートでコードからラベルを解決できるかです。
コード値だけを保存していて、その値域が実体（DataType など）として存在していないと、レポートで「コード → 表示ラベル」を引けない場面があります。たとえばステータスを approved というコード値で保存していても、値域が実体化されていなければ、レポート上は approved のまま表示され、「承認済み」という日本語ラベルに解決できません。
「後でレポートに出したい」「一覧でラベル表示したい」という要件が少しでも見えているなら、それ自体が DataType（実体化）を選ぶ強い理由になります。分岐2で一見「単一フィールド限定」に見えても、レポート要件があるなら Picklist ではなく DataType を選ぶ——これは実務で頻出の判断です。
コードマスタ設計の要点：保存はコード値、ラベルはマスタ側
置き場所を DataType や専用クラスに決めたら、次は中身の設計です。ここでの鉄則は1つです。
列挙値はコード値（英小文字）で保存し、表示ラベルはマスタ側で管理する。保存値や DB の CHECK 制約に日本語ラベルを直接入れない。
これは Pega 固有というより汎用的なデータモデリングの定石（単一の真実の源＝single source of truth）ですが、Pega でもこの考え方に沿った仕組みが用意されています。ローカルリストの選択肢は Field Value ルールやプロンプト値でコード値と（ローカライズ可能な）表示ラベルを分けて保持でき、参照データを Data Type としてテーブル化しておけば、レポートでコード → ラベルを解決でき、表示名の変更にも耐えます。UI や内部挙動はバージョンにより異なる場合があるため、細部は公式ドキュメントで確認してください。
具体的には、契約種別を次のように設計します。
- 保存値（コード値）：
lease/installment/rental - 表示ラベル（マスタ側で管理）：「リース」/「割賦」/「レンタル」
こうしておく利点は明確です。
- 表示名を変えても保存値は不変 — 「リース」を「ファイナンスリース」に改称しても、
leaseというコード値はそのまま。既存データも連携先も壊れない - 多言語・表記ゆれに強い — ラベルはマスタ側で一元管理するので、表記の統一や言語追加がラベル差し替えだけで済む
- DB 制約が安定する — CHECK 制約や保存値に日本語ラベルを入れてしまうと、ラベル変更のたびにデータ移行や制約変更が必要になる。コード値なら制約が固定できる
逆に、保存値に「リース」という日本語ラベルを直接入れてしまうと、名称変更のたびに全レコードの一括更新と制約の作り直しが発生し、連携先ともズレます。保存はコード、表示はラベル——この分離が、後の一括変更のしやすさと表記ゆれ防止を生みます。
よくある失敗・誤解
失敗1：同じ値域を Picklist で各所に重複定義する
最も多い失敗です。「都道府県」や「ステータス区分」を、画面ごと・ケースタイプごとに別々の Picklist として定義してしまう。一見動きますが、値を1つ追加したい・並びを変えたいとなった瞬間に、全箇所を探して直す作業が発生し、必ずどこかを漏らします。2箇所目で使う時点で DataType に切り出すのが正解です。
失敗2：1フィールド限定の選択肢まで DataType にする
逆方向の過剰設計です。そのフォームの中でしか使わない、他のどこにも現れない選択肢まで、律儀に Data Type として実体化する。再利用がないのに実体化のオーバーヘッド（Data Type の定義・保守・データ投入）だけを払うことになり、割に合いません。単一箇所限定なら Picklist で十分です。
失敗3：保存値に表示ラベルを入れてしまう
前節の通り、保存値や DB 制約に「リース」のような日本語ラベルを直接入れる設計です。名称変更・多言語化・表記統一のすべてでコストが跳ね上がり、連携先ともズレます。コード値で保存し、ラベルはマスタ側を徹底します。
誤解：「重要なマスタだから DataType にする」
重要かどうかは置き場所の判断軸ではありません。どれだけ業務上重要でも、単一フィールドでしか使わないなら Picklist で十分ですし、逆にささいに見える区分値でも複数箇所で使うなら DataType にすべきです。判断軸は「再利用の広がり」と「データの複雑さ」であって、重要度ではない、と切り分けてください。
まとめ
- 判断の起点は1つ——「その値域を1回定義して、独立した複数箇所で再利用するか？」
- 単一フィールド限定 → Picklist / 複数箇所で再利用する値域 → DataType / 値＋属性・関係 → 専用クラス、の3分岐で決める
- レポートでラベル表示したいなら、値域を実体（DataType）として持つ強い理由になる
- コードマスタはコード値（英小文字）で保存し、表示ラベルはマスタ側で管理。保存値や DB 制約に日本語ラベルを入れない
- 「1回定義して再利用」の原則が、後の表記ゆれ防止と一括変更のしやすさを生む
参照データの置き場所は、地味に見えて Pega アプリケーションの保守性を大きく左右します。設計の初期にこの3分岐とコードマスタの鉄則を押さえておくことが、後工程での表記ゆれ・修正漏れ・データ移行といった手戻りを未然に防ぎます。
Pega の設計・実装でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。当社はデータモデル設計から実装・運用まで、豊富な Pega 実装実績をもとにご支援します。
関連リンク
関連記事
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 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読む