Pega Constellation とは｜従来 UI との違いと移行の考え方
Pega Constellation とは何か。従来の Section ベース UI との違い、構成要素の役割、標準でできないことへの向き合い方、新規ケース・共存・全面移行という 3 つの移行パターンと、移行前に見ておくべき点を 1 本にまとめました。
Constellation とは
Pega Constellation は、Pega Platform 8.8 以降で提供されている、View を単位に画面を組み立てる UI アーキテクチャとデザインシステムです。画面はブラウザ側で動く React 製のエンジンが組み立て、ケースのデータと画面の定義（UI メタデータ）は Constellation DX API を通じてサーバーから受け取ります。従来の Section ベースの UI に比べて作り込みの自由度を絞る代わりに、標準の部品と画面パターンを設定で組み合わせることで、開発と保守の手間を小さくする考え方をとっています。
名前の経緯にも触れておきます。Pega の公式ドキュメントによると、8.7 で「Cosmos React」と呼ばれていたものが 8.8 以降は「Constellation デザインシステム」になり、あわせて DX API v2 は「Constellation DX API」、SDK は「Constellation SDK」と呼ばれるようになりました。一方で、Section ベースの「Theme Cosmos」は現在も別の UI として存在しており、これが「Cosmos と Constellation の違い」を分かりにくくしています。
公式ドキュメントは Constellation を「カスタマイズよりも構成（configuration over customization）を優先する、処方的（prescriptive）なデザインシステム」と説明しています。本記事はこの考え方を土台に全体像を整理し、各節から詳しい記事へ案内します。
Traditional UI（UI Kit・Theme Cosmos）との違い
Pega のドキュメントでは、Constellation 以前の UI を「traditional UI（従来 UI）」と呼び、その代表が UI Kit と Theme Cosmos です。どちらも Section と Harness というルールを組み合わせて画面を作る Section ベースのアーキテクチャで、公式ドキュメントは Theme Cosmos を「Section ベースでサーバー側描画（server-rendered）の UI」と説明しています。
違いの本質は、見た目よりも「画面をどこで、何を単位に組み立てるか」にあります。公式ドキュメントの比較表をもとに整理すると次のとおりです。
| 観点 | 従来 UI（UI Kit・Theme Cosmos） | Constellation |
|---|---|---|
| 画面の単位 | Section・Harness ルール | View ルールとテンプレート |
| 画面を組み立てる場所 | サーバー側で HTML を生成 | ブラウザ側の React エンジンが UI メタデータから組み立てる |
| データ・ロジックとの関係 | Section・Harness がデータ、業務ロジック、表示をまとめて持つ | View はデータと一部の業務ロジックを、テンプレートによる表示から切り離す |
| ボタンなどの操作 | UI 要素にアクションセットを設定 | Case Designer でアクションとしてモデル化 |
| 見た目の調整 | スキン、カスタム CSS | ブランディング（テーマ）設定 |
| 標準にない UI | カスタムコントロール、HTML ルール | DX Component（React）で拡張 |
| 外部サイトへの組み込み | マッシュアップ | Web embed、または Constellation SDK |
| 一覧の一括操作・Excel 出力 | アクションセットや Activity で自作 | リストビューの設定で有効化 |
| ブラウザの戻る・進む | 非対応 | セマンティック URL で対応 |
従来 UI は画面のあらゆる部分を作り込めるのが特長でした。Pega Academy は、その柔軟さがルール保守の負担、アプリケーション間の体験のばらつき、アップグレードの難しさにつながってきたと説明しています。Constellation は作り込める範囲を意図的に狭め、標準の部品とパターンに業務を乗せる方向を選んでいます。
また、UI アーキテクチャの選択はアプリケーション全体に効きます。公式ドキュメントは、選んだアーキテクチャ専用の UI ルールが生成されるため、あとから変えるには大幅な手作業での再構成が必要で、推奨しないとしています。新規開発での選択は後戻りの難しい判断です。詳しい比較は Pega Constellation UI と Cosmos の違いを徹底比較 をご覧ください。
構成要素: View・Template・DX API・DX Component の役割
Constellation の画面は、いくつかの部品の分業で成り立っています。役割を分けて見ると、設定で済ませる部分とコードを書く部分の境界が見えてきます。
View — 何を表示し、何を入力させるか
View は、ケースやデータオブジェクトの情報を表示・入力する画面の単位です。公式ドキュメントでは、ケースを処理する Full Page View、サイドパネルなどに出す Partial View、一覧を出す List View、入力を受け付ける Form View が定義されています。Form View は、ワークフローのステップでユーザーアクションを設定すると自動で作られます。
設計者が決めるのは「どのフィールドを、どの View に置くか」です。View にフィールドを置けば、表示に使う部品は標準の組み合わせから自動で選ばれます。そのため、フィールドの使われ方を最初からデータモデルに反映しておくことが前提になります。
Template — どう並べるか
Template は View のレイアウトとレスポンシブ対応を受け持つ定義済みの型です。たとえば既定のフォームテンプレートは最大 3 列のレスポンシブなレイアウトに対応しています。ブレークポイントや余白の扱いはアクセシビリティ要件を満たすよう設計されており、公式ドキュメントによると、損なうおそれがあるため変更できないようになっています。自由に並べられない代わりに、画面の一貫性とアクセシビリティを個別に作り込まずに済みます。設計の判断は Pega Constellation の View/Template 設計 で扱っています。
DX API — サーバーとの通り道
Constellation DX API は、ケースやアサインメントの表示・作成・更新に使うモデル駆動の REST API で、データと、View ルールに保存された UI メタデータを返します。標準の Constellation UI 自身がこの API で動いており、同じ API で React、Angular、Vue などの別のフロントエンドからもケースを処理できます。認証には OAuth 2.0 が使われます。ただし独自フロントを作ると、画面の保守責任はすべて自社側に移ります。判断の観点は Pega DX API で独自フロントを作る判断 をご覧ください。
DX Component と SDK — 標準で足りない部分の拡張
標準の部品で要件を満たせない場合の拡張手段が DX Component です。React で作るカスタム部品で、公開すると標準の部品と同じように画面設定の中で配置できます。公式ドキュメントは、DX Component をプロのフロントエンド開発者向けの高度な用途と位置づけ、npm や Git などの知識が必要としています。標準の Constellation 部品そのものは変更できません。
自社のデザインシステムに沿った画面を一から作る場合は Constellation SDK を使います。公式ドキュメントは、顧客向け Web サイトやモバイルのセルフサービスに向き、React の開発チームと高いデザインの専門性が要るとしています。DX Component の作りどころは Pega カスタム DX Component(React) の作りどころ で整理しています。
Constellation で「できないこと」と回避の考え方
Constellation の制約は、大きく 2 種類に分かれます。
1 つは、プラットフォームとして対応していない機能です。執筆時点（Pega Platform ‘26）の公式ドキュメントでは、位置情報の追跡、匿名認証サービス、複雑なモバイル機能などが非対応とされ、画像の扱いも URL フィールドに限られます。オフラインで使うモバイルアプリが必要な場合は、従来 UI を使うよう案内されています。これらは設計の工夫では埋めにくいため、要件にあるかを最初に確認します。
もう 1 つは、作り方の制約です。画面の任意の場所にボタンを置いて処理を起動する、Section に JavaScript を埋め込む、テンプレートの並びを細かく変えるといった従来の作り方は、そのままでは使えません。こちらは多くの場合、別の方法で業務上の目的を満たせます。回避は次の順で検討するのが現実的です。
- 標準の機能で代替できるか確認する。 任意のボタンはケースのアクションとして、Excel 出力や一括操作はリストビューの設定として置き換えられることがあります。
- 業務要件を標準に寄せられないか相談する。 当時の標準機能の不足を補うために作り込んだ画面は、今の標準で同じ目的を果たせることがあります。
- 残るものだけを拡張で扱う。 DX Component、SDK による独自画面、その部分だけ従来 UI に残す、の 3 つを保守の手間も含めて比較します。
DX Component で作った部品は、バージョンアップのたびに動作確認と保守の対象になります。拡張は最後の手段として件数を絞るほうが、長く使いやすいアプリケーションになります。代表的な制約と回避策は Pega Constellation UI で「できないこと」と現実的な回避策 にまとめています。
移行パターン（新規ケースから・共存・全面移行）と選び方
公式ドキュメントは、移行方法として段階的な移行（incremental migration）と全面移行（full migration）の 2 つを示しています。段階的な移行には複数の進め方があるため、実務では次の 3 パターンで考えると判断しやすくなります。
| パターン | 進め方 | 向いている状況 | 注意点 |
|---|---|---|---|
| 新規ケースから | 従来 UI のアプリケーションに、新しいケースタイプだけを Constellation で作る | 既存の画面は当面変えず、新しい業務から慣れたい | 公式ドキュメント上、バックオフィス用途に限られ、テーマも別々に定義が必要。操作感が混在する |
| 共存（ブレンド） | Constellation のアプリケーションで、従来 UI のケースタイプも同じポータルで動かしながら順に移す | ケースタイプが多く、業務を止めずに少しずつ移したい | 移行期間中は 2 つの UI を保守する。共存の終わりを計画に入れる |
| 全面移行 | 移行先のアプリケーションを別に用意し、ケースタイプを一通り作り直す | 画面の大幅な見直しが予定されている、または対象の規模が限られている | 公式ドキュメントでも、複雑な作業で大幅な作り直しになり得るとされている |
共存には、従来 UI のアプリケーションをブレンド UI に変換するウィザードも用意されており、従来のケースタイプとランディングページを保持したまま新しい Constellation アプリケーションを作れます。全面移行では、現行と移行先を同じケースデータで並行稼働させると移行が単純になりやすく、一部のユーザーだけ先に新しい UI へ移すこともできる、移行の変更はブランチではなく専用のルールセットで管理する、といった進め方が公式ドキュメントに示されています。
選び方は、既存アプリケーションにどれだけ手を入れる予定があるかで整理できます。公式ドキュメントの UI 選択の指針は、新規アプリケーションと大きな作り直しが必要な既存アプリケーションには Constellation を、小さな変更で済む既存アプリケーションは現在のアーキテクチャのまま、拡張部分に Constellation の部品を検討するよう案内しています。「移行するかどうか」より「次の大きな手入れをどの UI で行うか」と問うと、選択肢を絞りやすくなります。
移行前のアセスメントで見る点
移行方法を決める前に、現状の UI 資産を棚卸しします。公式ドキュメントは、作業量の見積もりで考慮する要素として次を挙げています。
- ケースタイプとステップの数
- データモデルの複雑さ
- ケースの画面（View）の複雑さ
- JavaScript やサードパーティのライブラリなどのカスタマイズ
- ポータルのカスタマイズ
- Constellation に対応したフレームワークアプリケーションの有無
- Constellation のデザインシステムとベストプラクティスへの準拠度
実務では、これに加えて画面ごとの作り込みの度合いを見て、「そのまま置き換えられる」「標準に寄せて再設計する」「DX Component 化を検討する」の 3 段階に仕分けます。見積もりの前提がはっきりします。
公式の支援ツールである Constellation Modernization Assistant は、分析モードで移行時に対応が必要になりそうな課題を一覧化して XLSX で出力でき、移行モードでは Constellation 用のアプリケーションなどを新しく作って Section を View に変換します。ただし、変換後の View が業務要件に合っているかは人が判断します。支援ツールは版によって名称や提供形態が変わることがあるため、着手時点の公式ドキュメントで確認してください。
データまわりも見落としやすい点です。Constellation ではフィールドの表示方法がデータモデルから決まるため、データモデルの整理が画面移行の前提になります。公式ドキュメントの全面移行の手順にも、従来のデータオブジェクトやピックリストの調整、データモデルの再構成が含まれています。棚卸しの進め方は Constellation 移行の事前アセスメント で解説しています。
工数を左右する要素
Constellation 移行の工数は、画面の数だけでは決まりません。次の要素で大きく変わります。
作り込みの分布。 標準的なフォームや一覧が中心の画面と、カスタム JavaScript で表示を制御した画面では、作業量がまったく違います。平均単価を掛けるより、作り込みの度合いごとに分けて積み上げるほうが外れを小さくできます。
標準に寄せる合意。 既存画面の忠実な再現を目指すと、標準で済む画面まで拡張の対象になります。標準のパターンへ寄せる方針を、業務部門と早い段階で合意しておくことが工数に直結します。
データモデルの手直し。 画面のためだけにデータページを参照していた箇所や、ケースのデータ構造が整理されていない箇所が多いほど、画面以前の作業が増えます。
ポータルと外部連携。 独自に作り込んだポータルや、マッシュアップによる外部サイトへの組み込みは、ポータル設定や Web embed への置き換えが別途必要です。
フレームワークの対応状況。 公式ドキュメントでは、Customer Service と Sales Automation には Constellation 版の実装ガイドがある一方、戦略アプリケーション（strategic applications）とフレームワークはまだ Constellation に対応していないとされています。
テストの作り直し。 Automation Toolkit によるシナリオテストは Constellation では利用できないため、既存の UI テスト資産がある場合は組み直しも見込みます。
共存期間の長さ。 段階的な移行では 2 つの UI を並行して保守します。どこで従来 UI を閉じるかを計画に含めると、総工数を見通しやすくなります。
よくある質問
Q. Theme Cosmos と Constellation は同じものですか？
別のものです。Theme Cosmos は Section ベースでサーバー側描画の従来 UI、Constellation は View ベースでブラウザ側描画の新しいアーキテクチャです。8.7 の「Cosmos React」が 8.8 以降に Constellation デザインシステムと呼ばれるようになったため、名前が混同されやすくなっています。
Q. 既存の従来 UI アプリケーションは、すぐに移行する必要がありますか？
公式ドキュメントの指針では、小さな変更で済む既存アプリケーションは現在のアーキテクチャのまま維持し、Theme Cosmos のアプリケーションは Theme Cosmos のルールセットを最新版に更新するよう案内されています。移行の時期は、次に大きく手を入れるタイミングと合わせて考えるのが現実的です。
Q. 1 つのアプリケーションで従来 UI と Constellation を共存させられますか？
できます。ただし公式ドキュメントでは、操作感やナビゲーションが一貫しないこと、テーマを UI ごとに定義する必要があることなどの制限が示されています。共存は移行期間の形として計画するのが無難です。
Q. Constellation の開発に React のエンジニアは必要ですか？
標準の View とテンプレートで構成する範囲では不要です。公式ドキュメントでも、DX Component はプロのフロントエンド開発者向けで、ローコード開発者や業務アーキテクトが作るものではないとされています。React の知識が要るのは、DX Component や、SDK・DX API による独自画面を作る場合です。
まとめ
- Pega Constellation は 8.8 以降の View ベースの UI アーキテクチャで、ブラウザ側の React エンジンが DX API から受け取った UI メタデータで画面を組み立てる
- 従来 UI（UI Kit・Theme Cosmos）との違いは、画面の単位、組み立てる場所、作り込みの許容範囲にある
- View・Template・DX API・DX Component（と SDK）が役割を分担し、拡張は標準で足りない部分に限る
- 移行は新規ケースから・共存・全面移行の 3 パターンで考え、アセスメントで作り込みの分布、データモデル、フレームワークの対応状況を先に把握する
Constellation の採否や移行の進め方は、既存資産の状況によって答えが変わります。UI 資産の棚卸しから移行方針の整理までのご相談は、Pega Constellation UI 導入支援サービス で承っています。
関連記事
このテーマの記事をまとめて読む: Pega Constellation と画面設計 用語は Pega 用語集 で引けます
関連記事
Constellation 移行の事前アセスメント｜工数を左右する UI 資産の棚卸し方法
Constellation 移行の見積もり精度を上げる事前アセスメントの方法を解説。UI 資産(セクション・カスタム CSS/JS)の棚卸しと移行難易度の仕分け方を整理します。
記事を読むPega Constellation UI と Cosmos の違いを徹底比較
Pega の次世代 UI アーキテクチャ「Constellation」と従来の「Cosmos」を、設計思想・開発体験・パフォーマンス・移行戦略の観点から実装経験者の視点で徹底比較します。
記事を読むレガシーシステム刷新に Pega を使う｜Wrap & Renew という現実解
レガシー刷新の現実解「Wrap & Renew」を解説。既存システムを API で包み、業務プロセス層を Pega に移して段階的に作り替えるアプローチの適用条件を整理します。
記事を読む