Pega Constellation の View/Template 設計｜自動生成 UI を活かす判断とアンチパターン
Constellation では UI を view と template（定義済みレイアウト）で構成し、フィールドを領域に配置して組み立てる。自由な HTML やネストした section を書く旧来発想は通用しない。自動生成を土台に、再利用と一貫性をどこまで設計するか——low-code 前提の UI 設計判断を扱う。
結論から：まず「標準 template と field」で満たせるかを検証する
Constellation で UI を設計するとき、最初に頭を切り替えるべき点があります。それは、**画面を自由な HTML やネストした section で「組み立てる」のではなく、view と template（定義済みレイアウト）でフィールドを「配置する」**という考え方です。
結論を先に言うと、設計判断の型はシンプルです。
まず標準の template と field 設定だけで要件を満たせるかを検証する。満たせるなら view + template で構成し、自動生成を土台に再利用可能な view を整備する。標準では実現不可能なレイアウト要件が本当に必須のときだけ、カスタムコンポーネントに踏み込む。
「凝った見た目にしたいから」「旧 UI ではこう作っていたから」という理由でいきなりカスタムに走るのは誤りです。Constellation の生産性は、標準 template と自動生成 view をどこまで活かせるかにかかっています。本記事では、この判断を具体的な分岐として整理します。
Constellation の UI は「view」と「template」でできている
判断の前に、Constellation の UI モデルを正確に押さえておきます。旧来の Cosmos / Legacy UI の section 発想を持ち込むと、ここでつまずきます。
- view — UI の再利用単位です。クラスに紐づいて定義され、複数の画面・複数のケースタイプから再利用できます。ケースを定義すると、作成（Create）・編集（Edit）・詳細（Details）・一覧（List）といった標準の view や、ケース全体を三面レイアウトで表す Full case view を、Pega が自動生成します。
- template — view の中で使う定義済みレイアウトです。One column、Two column、Details といった固定の枠組みが用意されており、開発者はその領域（region）にフィールドを配置していきます。
ここで決定的に重要なのは、Constellation では任意の HTML を埋め込んだり、section を自由にネストして独自レイアウトを組んだりする、という発想を基本的に採らないという点です。UI は「template という決められた器に、field を置く」ことで組み立てます。この制約こそが、標準化された一貫した UX と、メタデータ駆動の自動生成を成立させています。
自動生成をどこまで委ね、どこを設計するか
Constellation は、ケースを定義すると Create（作成）・Edit（編集）・Details（詳細）・List（一覧）などの標準 view を自動生成します（Infinity ‘25 時点の標準セット。提供される view は版により差異があるため、対象環境で確認してください）。フィールドをケースに追加すれば、対応する view にも自動で反映されます。つまり**「何もしなくても動く UI」がまず手に入る**のが出発点です。
ここで LSA（Lead System Architect）に求められる判断は、どこまでを自動生成に委ね、どこを手を入れて再利用可能な view として整備するかの線引きです。
自動生成に委ねてよいもの
- 単純な入力・確認画面で、標準の並びとラベルで十分なもの
- 一度しか使われず、他画面と揃える必要のない画面
- プロトタイプ段階で、まず動かして要件を検証したい段階
これらは自動生成に任せ、開発工数をかけないのが正解です。Constellation の最大の利点は、この「作らなくてよい部分」の広さにあります。
手を入れて再利用 view として整備すべきもの
- 複数の画面・複数のケースで同じ見せ方を繰り返すフィールドの集合（顧客サマリ、契約サマリなど）
- 業務上、表示ルールやフィールドの並びを一元管理したいもの
- 将来の変更時に、1 箇所直せば全画面に反映させたいもの
こうした部分は、名前を付けた再利用 view として明示的に設計します。ここを怠って各画面で個別に組むと、同じ内容の view が画面数だけ増殖し、変更のたびに全箇所を直す保守地獄に陥ります。
template 選定という設計判断
template は固定セットであり、ピクセル単位の任意レイアウトは、カスタムコンポーネントを作らない限り実現できません。これが Constellation UI 設計の境界線です。要件が標準 template の表現力の内側にあるか外側にあるかを、設計の早い段階で見極める必要があります。
もう一つの注意点は、提供される template の種別や機能はバージョンによって異なることです。ある版で使える template が別の版には無い、あるいは機能差がある、というケースがあります。したがって設計は、必ず対象バージョンで実際に利用可能な template を前提に進めます。「一般論としてこういう template があるはず」で設計を固めず、利用中の環境で使えるものを確認してから決めるのが実務の鉄則です。
設計判断の早見表
| 判断ポイント | 標準 template + field で構成 | カスタムコンポーネント |
|---|---|---|
| 実現手段 | 定義済みレイアウトに field を配置 | React 等で独自 UI を実装 |
| レイアウトの自由度 | template の枠内（One column 等） | ピクセル単位で自由 |
| 開発・保守コスト | 低い（メタデータ中心） | 高い（コードの実装・保守が発生） |
| 一貫性・アクセシビリティ | 標準で担保される | 自前で担保する必要がある |
| バージョン追従 | プラットフォームが吸収 | 追従作業が自チーム負担になりやすい |
| 使いどころ | 大半の業務画面 | 標準で代替不可の要件のみ（最終手段） |
まず左列（標準構成）で満たせるかを検証し、どうしても無理なときだけ右列（カスタム）に踏み込む——これが判断の型です。カスタムは「できない」わけではなく、払うコストに見合う必然性があるときだけ選ぶものだと捉えてください。
よくある失敗
Constellation の UI 設計でつまずくパターンは、経験上ほぼ 3 つに集約されます。いずれも旧 UI のメンタルモデルを引きずることに根があります。
失敗1：旧 UI の section ネスト発想を持ち込む
Cosmos / Legacy の「section を入れ子にして自由にレイアウトを組む」感覚のまま Constellation に臨み、「なぜ思い通りに配置できないのか」と行き詰まるパターンです。Constellation は template に field を置くモデルであって、任意レイアウトの組み立ての場ではありません。まず標準 template と field 設定で要件を満たせないかを検証する——ここを飛ばしていきなりカスタムを検討すると、不要なコストを背負い込みます。
失敗2：一度きり view を量産して再利用性を失う
画面ごとにその場限りの view を作り続け、同じ内容の view が乱立するパターンです。個々の view は動きますが、共通で見せたいはずのサマリ表示などが画面ごとにバラバラになり、変更時に全画面を横断修正する羽目になります。繰り返し使う見せ方は、名前付きの再利用 view として先に設計しておくのが対策です。
失敗3：UI にロジックを埋め込む
表示条件や業務判断のロジックを UI（view）側に埋め込んでしまうパターンです。UI は「見せる」責務に徹し、判断ロジックはケースのライフサイクルやデータモデル側に置くべきです。UI にロジックを混ぜると、再利用が効かなくなり、テストも保守も難しくなります。
まとめ
- Constellation の UI は view と template（定義済みレイアウト）で構成し、フィールドを領域に配置する。任意 HTML やネスト section を書く旧来発想は通用しない
- 設計判断は 「まず標準 template と field 設定で満たせるか」を検証することから始める。満たせるなら view + template、満たせず標準で代替不可の要件のときだけカスタムコンポーネント（最終手段）
- 自動生成を土台にしつつ、繰り返し使う見せ方は再利用 view として明示的に設計する。一度きり view の量産は保守負債になる
- template は固定セットで版により異なるため、対象バージョンで使えるレイアウトを前提に設計する
- 失敗の多くは 旧 UI のメンタルモデルの持ち込み（section ネスト発想・view 量産・UI へのロジック埋め込み）に由来する
Constellation は「作らなくてよい部分」が広いプラットフォームです。その広さを活かせるかどうかは、標準の範囲を見極める設計判断にかかっています。ここを最初に正しく決めておくことが、後工程の保守性と開発速度を大きく左右します。
Constellation の UI 設計・移行でお困りの際は、Pega Constellation UI 導入支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、UI 設計の判断からご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む