Pega Constellation UI と Cosmos の違いを徹底比較
Pega の次世代 UI アーキテクチャ「Constellation」と従来の「Cosmos」を、設計思想・開発体験・パフォーマンス・移行戦略の観点から実装経験者の視点で徹底比較します。
はじめに — Pega UI アーキテクチャの変遷
Pega Platform の UI フレームワークは歴史的に複数の世代を経てきました。古くは HTML ベースの Section（Legacy UI）があり、その後レスポンシブデザイン時代に対応した Cosmos が登場し、2022 年以降にモダン SPA 相当の Constellation が投入されました。本記事では主に現在主流となっている Cosmos と、Pegasystems が新規プロジェクトで推奨している Constellation の 2 つを比較します。
Cosmos の設計思想
Cosmos は Pega が長年主力としてきた UI アーキテクチャで、以下のような特徴があります。
- Section ベース — Pega の Rule として定義される「Section」という UI 単位を組み合わせて画面を構成
- サーバーサイドレンダリング中心 — 画面の生成ロジックがサーバー側で実行される
- 宣言的 + 命令的のハイブリッド — Section の構成は宣言的に定義するが、動的挙動は Activity 等の命令的ロジックで実装することが多い
- 成熟したエコシステム — 長年使われてきたため、実装パターンや既存プロジェクトの資産が豊富
Cosmos はレスポンシブ対応や Pega 既存機能との親和性が高く、現在も多くの本番環境で稼働しています。一方で、モダンな SPA 的な UX（ページ遷移のない滑らかな画面更新、リッチなコンポーネント）を実現しようとすると、カスタム JS の作り込みが必要になり、保守性が下がりがちという課題がありました。
Constellation の設計思想
Constellation は Pega が 2022 年以降に提供を開始した次世代 UI アーキテクチャで、以下の根本的な変更を含みます。
- React ベースのクライアントサイドレンダリング — モダン SPA 相当の画面更新体験
- 宣言的 UI コンポーネント — Pega のメタデータから UI が自動生成される
- Constellation DX API — フロントエンドと Pega のロジック層を API で疎結合化
- 標準化された UX パターン — Pegasystems 公式の UX ガイドラインに従った統一感のある画面
- 外部フロントエンドからも利用可能 — Constellation DX API を使えば、React 以外の独自フロントエンドからも Pega のロジックを呼び出せる
Constellation は、Pega が「モダン Web アプリケーションの標準的な作り方」に寄せてきた、という点で大きな方針転換と言えます。React エコシステムの成果を取り込みながら、ローコードのメリットを維持する設計です。
主要項目の比較表
| 項目 | Cosmos | Constellation |
|---|---|---|
| レンダリング方式 | サーバーサイド中心 | React クライアントサイド |
| UI 単位 | Section | React コンポーネント（宣言的） |
| 画面遷移 | ページ遷移が発生しがち | SPA 的な滑らかな更新 |
| パフォーマンス | 中 | 高（入力項目が多い画面で特に体感差） |
| カスタマイズ | Section + Custom JS | 標準コンポーネント + Custom React コンポーネント (DX API) |
| 学習コスト | Pega 固有の Rule 理解が必要 | React 経験者には馴染みやすい |
| 成熟度 | 高（長年の運用実績） | 発展途上（機能追加中） |
| 推奨ユースケース | 既存 Cosmos 資産の維持 | 新規プロジェクト、UX を重視する案件 |
開発体験の違い
実際に開発していて感じる違いは、「メンタルモデル」の違いです。
Cosmos 開発では、「Section をどう組み合わせて画面を作るか」「動的挙動をどの Rule で実装するか」を考えます。Pega 固有の Rule タイプ（Section、Flow Action、When、Data Transform 等）を深く理解していることが生産性に直結します。
一方 Constellation 開発では、「Pega のメタデータを宣言的に定義すれば、React ベースの UI が自動で生成される」というメンタルモデルです。大半のケースでは Pega 標準の UI コンポーネントで事足り、カスタマイズが必要な部分のみ React の作法で実装します。React や TypeScript の経験がある開発者にとっては、むしろ馴染みやすい構造です。
実装経験から言うと、Constellation のほうが「標準の範囲でどこまでできるか」の見極めが重要です。標準コンポーネントで実現可能なものは絶対に標準を使い、どうしても標準では足りない部分だけカスタマイズするという判断ができるかどうかで、コードベースの保守性が大きく変わります。
パフォーマンスの違い
Constellation は Cosmos と比較して、以下の点でパフォーマンスが改善しています。
- 初回読込は Cosmos と同程度（クライアント側のバンドルロードがあるため）
- 画面遷移・入力応答は大幅に高速（SPA 的な差分更新のため）
- フォーム入力の応答性が体感で明らかに改善（入力項目が多い業務画面でオペレーターから好評）
特に、コンタクトセンターの Pega Customer Service のような「1 画面に多くの入力項目があり、1 日に何百件も操作する」ユースケースでは、Constellation の応答性向上が現場の負担軽減に直結します。
Cosmos から Constellation への移行
既存の Cosmos プロジェクトから Constellation への移行を検討する場合、以下のポイントを押さえる必要があります。
1. 段階的移行が基本
Cosmos と Constellation は同居可能です。画面単位・ケース単位で段階的に移行し、並行運用しながら切り替えていくのが現実的なアプローチです。
2. カスタム Section の扱い
既存プロジェクトでよくある「カスタム Section」や「独自の JS カスタマイズ」は、Constellation では React コンポーネントとして再実装する必要があります。単純な自動変換では対応できない部分がほとんどなので、移行前にカスタム要素の棚卸しが重要です。
3. DX API への設計変更
Constellation はフロントエンドとバックエンドを DX API で疎結合化するため、既存の Cosmos 前提の設計（サーバーサイドでの画面制御）を API 前提に再設計する必要があります。移行というよりは、部分的に再設計に近い作業になります。
4. Constellation の成熟度に注意
Constellation は発展途上のアーキテクチャで、バージョンごとに新機能が追加されています。プロジェクトで必要な機能が現在の Constellation バージョンでサポートされているか、事前に必ず確認する必要があります。
どちらを選ぶべきか
あくまで一般論ですが、以下が当社の見解です。
新規プロジェクト
原則として Constellation を推奨します。Pegasystems 公式も新規プロジェクトでの Constellation 採用を推奨しており、長期的な保守性・将来性を考えると Constellation が有利です。ただし、Constellation で必要な機能がサポートされているか、プロジェクト要件とのマッチングを事前に確認することが必要です。
既存 Cosmos プロジェクト
既存プロジェクトは「今すぐ全面移行」よりも、新機能追加や改修のタイミングで段階的に Constellation に切り替えていくのが現実的です。全面移行は工数が大きく、中途半端に始めると保守コストが跳ね上がるためです。
意思決定が難しい場合
Pega Platform 全体の中で UI アーキテクチャの選択は、中長期の保守性・開発者採用・パフォーマンスに大きく影響します。判断に迷う場合は、Cosmos と Constellation 両方の実装経験を持つパートナーに相談することを強く推奨します。当社は両方を扱ってきた実装実績があるため、お気軽にご相談ください。