Pega カスタム DX Component(React) の作りどころ｜OOTB 設定と自作の使い分け
Constellation は React 製のカスタム DX Component で拡張でき、App Studio の作成者が view に配置できる。だが自作は SDK 契約への準拠と、Constellation 版更新ごとの再検証・保守を伴う。標準で満たせるか、コードに踏み込むか——自作の分岐点を扱う。
結論から：まず「OOTB ＋ 設定」、自作は真のギャップに限る
Pega の Constellation は、UI を React 製のカスタム DX Component で拡張できます。自作したコンポーネントを登録すれば、App Studio の作成者（ローコード開発者）が OOTB（Out-of-the-Box）コンポーネントとまったく同じ感覚で、view や template に配置できるようになります。これは強力な仕組みで、「コードで作った部品を、ローコードの人が設定だけで使える」という理想的な役割分担を実現します。
ただし、その強力さゆえに使いどころを誤ると保守の負債になります。結論を先に言うと、判断の型はシンプルです。
まず OOTB コンポーネント＋設定（デザインシステム／template）で満たせないかを検討する。標準で満たせない「真のギャップ」がある場合に限って自作へ進み、着手する前に upgrade-safe な設計と保守オーナーを固める。
「React で書けるから」「凝った見た目にしたいから」という理由で最初から自作に飛びつくのは誤りです。自作コンポーネントは Constellation の SDK／契約に準拠する必要があり、そのバージョンは Constellation リリースに結び付きます。つまり プラットフォームをアップグレードするたびに、再検証と改修の保守コストを背負うことになります。本記事では、この「作るか、設定で済ませるか」の意思決定を、具体的な分岐として整理します。
カスタム DX Component とは — Constellation を React で拡張する
Constellation は React ベースの UI アーキテクチャで、DX Component はその正式な拡張ポイントです。開発者が Constellation のコンポーネント SDK に沿って React コンポーネントを実装し、アプリケーションに登録すると、そのコンポーネントは App Studio 上で OOTB コンポーネントと並んで一覧に現れます。
ここが重要な点です。登録された自作コンポーネントは、ローコードの作成者が view や template に「配置するだけ」で使えます。プロパティのバインドやレイアウトへの組み込みは、OOTB コンポーネントと同じ App Studio の操作で完結します。つまり自作 DX Component は、「フルコードで作った部品を、ローコードの運用に橋渡しする」ための仕組みだと捉えると位置づけが明確になります。
この橋渡しは魅力的ですが、橋の維持には費用がかかります。次に、それでも「まず OOTB」を原則とする理由を整理します。
それでも「まず OOTB」が原則である理由
Pega の設計思想は、メタデータ駆動（model-driven）とデザインシステムの徹底——公式の言葉でいえば 「カスタマイズより設定（configuration over customization）」 です。OOTB コンポーネントを設定で使う限り、次のことがプラットフォーム側で保証されます。
- 統一された UX — Constellation のデザインシステムに沿った、アプリ全体で一貫した見た目と操作感
- アクセシビリティとレスポンシブ — 標準コンポーネントが担保する対応を、個別に作り込まなくてよい
- アップグレード追従 — OOTB コンポーネントの改善・修正は、プラットフォームのアップグレードで自動的に取り込まれる
自作 DX Component は、この 3 つを 自分の責任で引き受けることを意味します。SDK の契約に準拠し、アクセシビリティを自前で担保し、そして後述するとおり、Constellation の版が上がるたびに動作を再検証する必要があります。だからこそ「まず OOTB、自作は真のギャップに限る」が原則になります。標準で満たせるものを自作するのは、支払う理由のないコストを恒久的に背負う選択です。
実際、プラットフォーム自身がこのコストを可視化する方向に進んでいます。Pega Platform ‘26 時点では、Constellation DX Component を使用するとガードレール警告が表示され、その部品が保守性・アクセシビリティ・ユーザビリティ・セキュリティ上のリスクを持ち込みうることを注意喚起します（バージョンにより挙動が異なるため、詳細は対象版の公式ドキュメントで確認してください）。「作れるが、無条件に推奨されるわけではない」というプラットフォームの姿勢が、そのまま警告として現れていると捉えてください。
「真のギャップ」とは何か
では、自作を検討してよい「真のギャップ」とはどういうものか。実務では、おおむね次の 3 類型に整理できます。
特殊な可視化
OOTB のフィールドやチャートでは表現できない、業務固有のビジュアライゼーション。たとえば、独自の座席マップ、工程を図示するガントライクな表現、地図上へのカスタムオーバーレイなど、標準の入力・表示部品の組み合わせでは形にならないものです。
サードパーティ widget の埋め込み
外部ライブラリや外部サービスが提供する UI 部品を画面に組み込む必要があるケース。決済ウィジェット、外部の署名コンポーネント、専用のリッチエディタなど、Pega 標準にない部品を React で包んで取り込む用途です。
OOTB が未サポートの操作・インタラクション
標準コンポーネントでは提供されていない操作性や、特殊なユーザーインタラクションが要件として明確にある場合。ここで大切なのは、「設定や template の工夫で近づけられないか」を先に潰しておくことです。多くの“未サポートに見える要件”は、実際にはデザインシステムの設定範囲で寄せられます。
これら 3 類型に当てはまり、かつ設定・template・標準コンポーネントの組み合わせでは代替できないと確認できて初めて、自作は正当化されます。
OOTB ＋ 設定 と 自作 DX Component の比較
判断を早見表にまとめます。
| 観点 | OOTB ＋ 設定 | カスタム DX Component（自作） |
|---|---|---|
| 実現できる範囲 | デザインシステムの設定範囲 | React で書けるものはほぼ何でも |
| UX の統一・アクセシビリティ | プラットフォームが担保 | 自前で担保する責任を負う |
| アップグレード時 | 自動追従（基本ノーコスト） | 再検証・改修が必要になりうる |
| SDK／契約への準拠 | 不要 | 必須（版に結び付く） |
| 実装・学習コスト | 低（App Studio の設定） | 高（React ＋ SDK の作法） |
| 保守オーナー | Pega 側 ＋ 設定担当 | 自チームで明確に持つ必要 |
| 使いどころ | 大多数の UI 要件 | 真のギャップに限定 |
表が示すとおり、自作は「実現できる範囲」だけが優位で、それ以外のすべての列でコストを払います。だから **判断は機能の可否ではなく、「そのギャップが、これらのコストを恒久的に払う価値があるか」**で下します。
自作を決めたら — upgrade-safe に作るための前提
真のギャップだと確認し、自作に踏み切ると決めたら、着手前に必ず次を固めます。ここを飛ばして作り始めると、次のアップグレードで壊れて手戻りします。
- SDK／契約への準拠を前提に設計する。 自作コンポーネントは Constellation のコンポーネント SDK が定める契約に従う必要があり、そのバージョンは Constellation リリースに結び付きます。契約から外れた作り方をすると、版が上がった瞬間に動かなくなります。
- 対象バージョンのドキュメントで作法を確認する。 コンポーネント API・ビルドツール・ビルド手順は、Constellation のリリースごとに進化します。「以前のプロジェクトではこう作った」を流用せず、利用中の版の公式ドキュメントで現在の作法を確認してください。
- 保守オーナーを明確にする。 自作コンポーネントは Pega Infinity の各リリースに追従して保守し続ける必要があり、Pega 公式も「その保守負担が、将来リリースへのアップグレード自体を妨げないかを見極めよ」と促しています。アップグレードのたびに再検証・改修が発生する前提で、「誰がこのコンポーネントを持ち続けるのか」を設計段階で決めます。オーナー不在の自作コンポーネントは、数バージョン後に誰も触れない負債になり、最悪の場合はアプリ全体のアップグレードを止めます。
バージョン依存の注意: DX Component の API・SDK・ビルド手順は版によって異なります。本記事の判断軸は版に依存しませんが、具体的な実装手順やコンポーネント契約の詳細は、必ず対象 Constellation バージョンの公式ドキュメントで確認してください。
よくある失敗
失敗1：設定で足りるのに自作する
最も多い失敗です。「凝った見た目にしたい」「React で書けるから早い」という理由で、デザインシステムの設定や template で寄せられる要件まで自作してしまう。初期の開発は速く進むように見えても、以降のアップグレードごとに再検証と改修のコストが乗り続けます。自作の前に、設定・template・標準コンポーネントの組み合わせを必ず先に試す——図の①〜③を潰すのはこのためです。
失敗2：upgrade-safe を考えずに作る
真のギャップであっても、SDK 契約を無視した作り方をすれば同じことです。契約から外れた実装は、Constellation の版が上がった瞬間に動かなくなります。「今動くコード」ではなく「次のアップグレードでも生き残るコード」を、対象版のドキュメントに沿って作る必要があります。
失敗3：保守オーナーを決めずにリリースする
作った本人が案件を離れ、誰もその DX Component を再検証できなくなるパターン。アップグレードのたびに保守が発生する部品なので、オーナー不在は「アップグレードできないアプリ」に直結します。作る判断と同時に、持ち続ける人を決めておきます。
まとめ
- Constellation は React 製カスタム DX Component で拡張でき、登録すれば App Studio の作成者が OOTB と同じように view／template へ配置できる。強力だが、使いどころを誤ると負債になる。
- 原則は 「まず OOTB ＋ 設定」。標準で満たせない 真のギャップ（特殊な可視化・サードパーティ widget・未サポートの操作）に限って自作へ進む。
- 自作は SDK／契約への準拠を伴い、そのバージョンは Constellation リリースに結び付く。アップグレードのたびに再検証・改修の保守コストを背負う。
- 踏み切るなら着手前に、upgrade-safe な設計・対象版ドキュメントでの作法確認・保守オーナーを固める。
「設定で満たせるか、コードに踏み込むか」——この分岐を設計の最初に言語化しておくだけで、Constellation アプリの保守性とアップグレード耐性は大きく変わります。判断を機械的に下せる型として、チームで共有しておく価値があります。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む