Pega Constellation UI で「できないこと」と現実的な回避策

結論から：制約は「縛り」ではなく「標準に乗るための設計指針」

Pega Constellation UI に移行して最初にぶつかるのは、「Section/Harness 時代にできていたことができない」という壁です。ボタンを好きな場所に置けない、連続画面が思うように組めない、一覧に出したい列が出ない——実装者からは「不便になった」と映ります。

しかし結論を先に言うと、これらは Pega が設計思想を変えた結果であり、正しく理解すれば回避策は明確です。

Constellation は宣言的で DX API 準拠が前提。「作り込まない（Configuration > Customization）」ことで、保守性とバージョンアップ耐性を得るための仕組みである。

つまり「できないこと」の大半は、標準の枠内に設計を寄せることで解決します。カスタム JS で無理やり実現するのではなく、標準の型に業務を乗せ替える——これが Constellation 時代の実装の基本姿勢です。本記事では、実装で頻出する4つの制約と、それぞれの現実的な回避策を整理します。

そもそも Constellation は何が変わったのか

従来の Section/Harness ベースの UI は、開発者が自由にレイアウトを組み、JavaScript を差し込み、独自のコントロールを作り込めました。柔軟な反面、アップグレードのたびに独自実装が壊れ、保守コストが積み上がる構造でもありました。

Constellation はこれを根本から変えます。

• 宣言的（Declarative）／モデル駆動 — 「どう描画するか」ではなく「何を表示するか」を宣言する。描画は Pega 標準のコンポーネントに委ねる。
• DX API 準拠 — UI はサーバーが返す DX API のメタデータに従って構成される。フロントエンドの描画は Pega が提供する Constellation コンポーネント（React 製）が担う。
• Configuration > Customization — 標準設定で実現するのが原則。カスタマイズは最終手段。

この前提を飲み込めるかどうかで、Constellation プロジェクトの生産性は大きく変わります。「作り込めないこと」を欠点と捉えるとストレスが溜まりますが、「標準に乗せることでアップグレードで壊れない」という利点と表裏一体だと理解すると、設計の判断が速くなります。

注意： 本記事で挙げる制約と回避策は、Pega Infinity ‘25 時点の一般的な挙動を基準にまとめたものです。Constellation の仕様は Pega Infinity のバージョンごとに改善・変更され得ます。標準で置けるアクションや List view の対応範囲なども版によって差があるため、実装前には必ず公式ドキュメントで現行バージョンの仕様をご確認ください。

制約1：アサインメント画面に任意のボタンを置けない

Section 時代は、フォーム内に好きなボタンを配置し、そこから任意のアクティビティやフローを起動できました。Constellation のアサインメント画面（作業画面）は Pega 標準のフォームとして描画され、置けるアクションボタンは、原則として次の標準アクションに限られます。

• Submit（送信） — アサインメントを完了して次へ進む
• Save（保存） — 入力を保存して後で再開する（「save for later」。利用可否はケースタイプ側の設定に依存します）
• Cancel（キャンセル） — 作業を中断する

なお、後述の Multi-step Form（連続画面）では、これに加えて画面遷移用の Next / Previous が標準で表示されます。いずれにせよ「この画面から追加のリクエストを起動したい」「別の処理を任意のタイミングで走らせたい」といった任意アクションを、フォーム内のボタンとして自由に置くことはできません。

回避策：ケースの Actions メニューから起動する

任意アクションは、フォーム内ボタンではなく**ケースの Actions メニュー（optional action / process）**から起動する設計にします。Constellation では、ケースに紐づくオプショナルアクションが実行時に Actions メニューに集約され、ユーザーはそこから追加処理を呼び出します。オプショナルアクションは、1 ステップで済むなら user action、複数ステップが必要なら process として構成でき、ケース全体（case-wide）にもステージ限定（stage-only）にも定義できます。

したがって UX 設計の段階から、「このボタンをどこに置くか」ではなく「この操作は Actions メニューの選択肢として成立するか」という発想で画面を描く必要があります。ワイヤーフレームを引く時点で Actions メニュー前提のレイアウトにしておかないと、後から「ボタンが置けない」と手戻りします。

制約2：Screen flow で連続画面を組めない

複数の入力画面を順番に見せる「ウィザード」的な UI を、従来は Screen flow（スクリーンフロー）で実装していました。Constellation では、この legacy な harness ベースの Screen flow の作り方はそのままでは通用せず、後継として Multi-step Form が用意されています。

回避策：Multi-step Form と Process flow を使い分ける

連続画面の作り方は、分岐の有無で2つに分けて考えます。

• 分岐しない一直線の連続入力 → Multi-step Form を使う。Multi-step Form は「1 人のユーザーが完了する 1 つのアサインメント」を、複数の view（画面）に分割して見せる仕組みです。1 つの入力ステップ（Collect information）に複数の view を並べることで、ユーザーには連続した複数ステップの入力画面として見えます。
• 条件によって工程が分岐する → Process flow / Subprocess で組む。Multi-step Form はあくまで一直線（linear）のフォームであり、分岐やループを伴う工程はフローの責務です。Multi-step Form に無理に押し込みません。

判断の型はシンプルで、「途中で道が分かれるか？」を問えば済みます。分かれないなら Multi-step Form、分かれるなら Process flow。ここを混同して、分岐ロジックを Multi-step Form 側に詰め込もうとすると破綻します。

Multi-step Form は設計上、1 フローあたりのステップを増やしすぎない（目安として 7 ステップ以内）・1 画面のフィールドを詰め込みすぎない、といったガイドラインが公式に示されています。連続画面が長くなりそうなら、工程自体をフローで分割することも検討してください。

制約3：List view の列に出したい property が出ない

Constellation の List view（一覧表示）でよく遭遇するのが、「optimize したのに、その property が列の選択肢に出てこない」という問題です。

原因は明確で、List view の列に出せるのは、行クラスの top-level にある scalar（Single Value）property だけだからです。embedded page（埋め込みページ）や page list の中にある property は、expose しても optimize しても、そのままでは列に出せません。

回避策：データを top-level に持ち上げる

対処は「その値を、一覧の行クラスの top-level scalar として参照できる形にする」ことに尽きます。具体的には次のいずれかを選びます。

• 参照データクラス駆動にする — 一覧の対象そのものを、必要な項目を top-level に持つデータクラスにする
• list 自体を Table のソースにする — 見せたいリストを直接テーブルのデータソースに据え、そのクラスの top-level property を列にする
• Data Reference で top-level 化する — 深い階層の値を Data Reference で行クラスの top-level に引き上げ、列に出せるようにする

「なぜこの property は列に出ないのか」で止まらず、「その値を top-level scalar として持てるデータ構造になっているか」を先に確認するのが、この制約の勘所です。

制約4：マスタ保守のための delegated-rules ガジェットが無い

従来は、マスタデータ（料率表・区分マスタなど）を業務ユーザー自身が保守できるよう、delegated rules のガジェットをセクションに埋め込む手法がありました。Constellation にはこの従来型の埋め込みガジェットがありません。

ただし、委譲（delegation）という機能そのものが失われたわけではありません。Constellation でもルール／データタイプの委譲はサポートされており、業務ユーザーによるマスタ保守は、より整理された UI で実現できます。

回避策：List view の CRUD（データモデル委譲）で行う

マスタ保守は、**List view の CRUD 機能（データモデルへの委譲）**で実現します。データオブジェクト（データタイプ）に対する一覧・追加・編集・削除を List view で構成し、必要なら複数タブを持つランディングページに並べて、業務ユーザーがそこからレコードを保守できるようにします。ガジェットを画面に貼るのではなく、データモデルを直接操作する UI を List view として用意する、という発想の転換です。

なお、データオブジェクトの List view による CRUD（複数タブのランディングページ構成を含む）は Pega ‘23 以降で利用できる構成です。旧 UI Kit の委譲 UX と比べて操作性が改善されている点も、Constellation に寄せる動機になります。

判断早見表：制約と回避策の対応

実装で迷ったら、次の対応表に立ち返ると判断が速くなります。

やりたいこと	Constellation の制約	現実的な回避策
フォームから任意アクションを起動	置けるボタンは標準アクション（Submit / Save / Cancel、連続画面では Next / Previous）のみ	ケースの Actions メニュー（optional action / process）から起動
連続した入力画面（分岐なし）	legacy な Screen flow はそのまま使えない	Multi-step Form（1 つのアサインメントを複数 view に分割）
連続した工程（分岐あり）	Multi-step Form は linear で分岐を扱えない	Process flow / Subprocess で構成
一覧に深い階層の項目を列表示	列に出せるのは top-level の scalar（Single Value）のみ	参照データクラス駆動 / list を Table ソース化 / Data Reference で top-level 化
マスタを業務ユーザーが保守	従来型の埋め込み delegated-rules ガジェットが無い	List view の CRUD（データモデル委譲、Pega ‘23 以降）
標準にない独自 UI	カスタム JS の直挿しは想定外	まず標準で再検討。不可なら DX Component を最終手段

よくある失敗・誤解

Constellation の制約を前にしたとき、経験上ハマりやすいのが次の3つです。

誤解1：「できないから」とカスタム JS を直挿しする

最もやってはいけないのがこれです。標準で実現できないからといって、カスタム JavaScript を無理やり差し込むのは筋の悪い手です。Constellation は DX API 準拠の宣言的（モデル駆動）な構造であり、独自 JS の直挿しはアップグレード耐性を壊し、Constellation に移行した意味そのものを失わせます。

どうしても標準で実現できない場合に限り、最終手段として **Constellation DX Component（React ベースのカスタムコンポーネント）**を検討します。DX Component は React（TypeScript）で実装し、サーバーへ publish して App Studio から標準コンポーネントと同様に利用する、という正規の拡張手段です。ただしこれは「まず標準で本当に無理か」を徹底的に確認したうえでの最後の選択肢であり、安易に手を伸ばすものではありません。

誤解2：Section 時代の作り方をそのまま移植しようとする

「前はこう作っていた」を Constellation にそのまま持ち込もうとすると、ほぼ確実に詰まります。ボタン配置・連続画面・マスタ保守のいずれも、Constellation の標準の型は Section 時代とは別物です。移植ではなく、標準の型に業務を乗せ替える設計をゼロから考えるのが正解です。

誤解3：制約を「機能不足」と捉えてしまう

Constellation の制約は、Pega の機能が足りないから存在するのではありません。「作り込まない」という設計思想を実装レベルで方向づけるための仕組みです。制約に沿って作れば、標準コンポーネントに乗るため、プラットフォームのバージョンアップで UI が壊れにくくなります。制約は保守性とアップグレード耐性を得るための対価であり、そう捉えると設計判断がぶれなくなります。

まとめ

• Constellation は宣言的（モデル駆動）・DX API 準拠が前提。原則は Configuration > Customization（作り込まない）
• アサインメント画面のボタンは標準アクション（Submit / Save / Cancel、連続画面では Next / Previous）が中心。任意アクションはケースの Actions メニューから起動する設計にする
• 連続画面は分岐なしなら Multi-step Form、分岐ありなら Process flow / Subprocess
• List view の列に出せるのは top-level の scalar（Single Value）のみ。深い階層の値は参照データクラス駆動 / Table ソース化 / Data Reference で top-level 化する
• マスタ保守は従来型ガジェットではなく List view の CRUD（データモデル委譲、Pega ‘23 以降）で行う
• カスタム JS の直挿しは避ける。最終手段として Constellation DX Component（React）を検討する
• 制約は「縛り」ではなく、標準に乗ることで保守性とバージョンアップ耐性を得るための設計指針

Constellation で「できないこと」に直面したら、その多くは「標準の型に業務を乗せ替える」ことで解決します。設計の初期段階から Constellation の型を前提に描いておくことが、後工程での大きな手戻りを防ぎます。

---

Pega Constellation への移行や UI 設計でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、Constellation を前提とした設計判断からご支援します。

関連リンク

• Pega Platform 開発支援
• Pega Customer Service 導入支援
• Pega Constellation UI と Cosmos の違いを徹底比較
• Pega の Picklist と Data Reference の使い分け
• Pega設計の分岐点：ケースにすべきか、データインスタンスか
• 無料相談に申し込む