Constellation 移行の事前アセスメント｜工数を左右する UI 資産の棚卸し方法

結論から：移行工数は「画面数」ではなく「作り込み度の分布」で決まる

Cosmos から Constellation への移行を検討するとき、最初に聞かれるのはほぼ必ず「で、いくらかかるのか？」です。そして最もよく見る見積もり方が「画面数 × 画面単価」——これが、Constellation 移行では高い確率で外れます。

結論を先に言うと、こうです。

Constellation 移行の工数は、画面の「数」ではなく「作り込み度の分布」で決まる。見積もりの前に UI 資産を棚卸しし、各画面を「そのまま置換可能／再設計が必要／DX Component 化を検討」の 3 段階に仕分ける。この分布を測ることが、見積もり精度のほぼすべてを左右する。

Constellation は、別記事で述べたとおり Cosmos の画面をそのまま移植する仕組みではなく、一部作り直しを含む移行になります。Pega の公式ドキュメント自身が、Constellation への完全移行（full migration）を「アプリケーションの複雑さによっては大幅な rework（作り直し）を伴い得る、複数ステップの複雑なプロセス」と位置づけています。Section を View に自動変換する公式ツールも提供されていますが（後述）、自動変換で片づくのは標準的な構成の部分までです。標準構成の画面は驚くほど速く移行できる一方、カスタム JS で作り込んだ画面はその数倍の工数がかかる。つまり同じ「100 画面」でも、その内訳次第で総工数は倍以上ブレます。本記事では、この分布を見積もり前に測るための事前アセスメント（UI 資産の棚卸し）の方法を、実案件での進め方に沿って解説します。

なぜ「画面数 × 単価」の見積もりは外れるのか

Cosmos の画面は Section という Rule の組み合わせで構成されており、そこにカスタム CSS・カスタム JavaScript・独自コントロールがどれだけ埋め込まれているかは、画面の一覧を眺めているだけでは分かりません。しかし Constellation 移行の実作業では、この「埋め込まれた作り込み」こそが工数の主因になります。

• 標準構成の画面 — Constellation では画面はメタデータ（View と標準コンポーネント）から自動生成されるため、標準的なフォーム・一覧画面は Constellation 側で構成し直すだけで済みます。1 画面あたりの工数は小さく、数もこなせます。
• 作り込まれた画面 — カスタム JS による動的制御や独自レイアウトは、Constellation にそのまま持ち込めません。公式ドキュメントでも、セクションベース UI におけるカスタムコントロール・HTML ルール・カスタム JavaScript による作り込みは、Constellation では DX API／DX Component で同等の結果を実現する方式に置き換えると整理されています。標準パターンへの再設計、場合によっては React によるカスタムコンポーネント（DX Component）としての再実装が必要になり、実装上は工数が標準画面の数倍に跳ね上がります。

つまり「1 画面あたり平均 X 人日」という単価が、そもそも成立しないのです。平均値でならすと、標準画面が多い案件では過大見積もりに、作り込みが多い案件では深刻な過小見積もりになります。外れ方が対称ではなく、作り込みの見落としは常に「炎上する方向」に外れる——だからこそ、見積もりの前に分布を測る事前アセスメントが必要になります。

事前アセスメントで棚卸しする 4 つの観点

実案件では、次の 4 つを定量的に洗い出します。いずれも Dev Studio 上の Rule を対象に機械的に数えられるものが中心で、実務感覚としては数日〜規模によっては 1〜2 週間程度の調査で分布の全体像がつかめます。

なお、この棚卸しは完全な手作業ではありません。Pega は公式の解析ツール Application Modernization Assistant（Constellation Modernization Assistant） を提供しており、解析モードで Section・Flow Action・プロパティ・ケースタイプ等を 50 以上の観点でチェックし、検出した課題を重大度・複雑度つきで一覧化（Excel エクスポート可）できます。移行モードでは Section から View への自動変換も行われますが、テーブルや repeating dynamic layout などセクションの構成をすべて変換できるわけではなく、DX Component の移行・新規作成は対象外です。つまりツールが拾ってくれるのは「機械的に判定できる範囲」までで、本記事で述べる難易度の仕分け——分布をどう読むか——は人の設計判断として残ります。また、Marketplace 版の Constellation Modernization Assistant コンポーネントは本稿執筆時点（2026 年）では非推奨（deprecated）となり、後継として Pega Application Signature への移行が案内されています。この種の支援ツールは版ごとの入れ替わりが激しいため、着手時点で対象バージョンの公式ドキュメントを必ず確認してください。

1. セクション／ハーネスの数と種類

まず母数の把握です。アプリケーションに含まれる Section・Harness を列挙し、「ケースのフォーム画面」「一覧・ダッシュボード」「ポータル画面」「共通部品」といった種類に分類します。ポイントは単純な総数ではなく、再利用されている共通 Section と、画面固有の Section を分けて数えること。共通部品は 1 回移行すれば複数画面に効くため、総数だけを見ると工数を過大に見積もることになります。

2. カスタム CSS／JavaScript の量

最重要の観点です。スキンへの CSS 上書き、Section に埋め込まれた JavaScript、独自のスクリプトファイルを洗い出します。これらは Constellation に持ち込めない資産であり、「何のためにその CSS/JS が書かれたのか」という目的単位で棚卸しします。見た目の微調整のためなのか、業務ロジック（表示制御・入力補助）のためなのかで、移行時の扱いが変わるからです。前者は Constellation の標準テーマ設定で吸収できることが多く、後者は再設計の対象になります。Constellation ではスタイルを App Studio のブランディング（テーマ）設定で一元管理する方式が公式の前提で、画面ごとのカスタム CSS 上書きという手段自体がなくなる、と考えておくのが安全です。

3. 非標準コントロールの有無

Pega 標準以外のコントロール——独自開発のカスタムコントロール、サードパーティのウィジェット、iframe による外部画面の埋め込みなど——を列挙します。なお iframe ベースのマッシュアップは、Constellation では div ベースの Web embed への置き換えが公式の前提になっている点にも注意が必要です。これらは 1 つひとつが「標準コンポーネントで代替できるか、DX Component として作り直すか」の個別判断を要する、難易度ランクの上位に直結する要素です。数は少なくても工数インパクトが大きいため、漏れなく拾います。

4. 画面あたりのカスタマイズ度

最後に、画面（業務上のひとまとまりの UI）ごとに上記 1〜3 を突き合わせ、カスタマイズ度をスコアリングします。厳密な点数化は不要で、「カスタム要素ゼロ／軽微なカスタムあり／カスタムが画面の中核」の 3 段階で十分です。これが次節の難易度 3 分類の入力になります。

移行難易度の 3 分類

棚卸しの結果を、冒頭の図のフローで 3 つのランクに仕分けます。

ランク	典型的な画面	Constellation での対応	相対工数（目安）
A：そのまま置換可能	標準コントロールだけのフォーム・一覧。カスタム CSS/JS なし	標準の View・コンポーネントで構成し直す	小（基準）
B：再設計が必要	カスタム JS で表示制御した入力画面、独自レイアウトのダッシュボード	標準の UX パターンに寄せて画面設計からやり直す	中（A の数倍）
C：DX Component 化を検討	独自ウィジェット、外部ライブラリ依存の特殊 UI、iframe 埋め込み	React によるカスタム DX Component として再実装、または要件自体を見直す	大（1 件ごとに個別見積もり）

見積もりはこの分布の上に立てます。たとえば同じ「画面 100」の案件でも、A:70／B:25／C:5 の案件と A:30／B:50／C:20 の案件では、総工数は感覚的にも倍以上変わります。そして C ランクは 1 件ごとの振れ幅が大きいため、平均単価に混ぜず個別に積むのが原則です。アセスメントの成果物としては、「画面 × ランク」の一覧表と、C ランク各件の個別所見をセットで出すのが実務の型です。

移行を機に「標準へ寄せる」方針が総コストを下げる

分布を測ったあと、見積もりを大きく左右する方針判断が 1 つあります。既存 UI の忠実再現を目指すか、Constellation の標準 UX パターンへ寄せるかです。

Constellation が一部作り直しを含む以上、「Cosmos で作り込んだ画面を、見た目そのままに Constellation で再現する」アプローチは、B ランクの画面を無理やり C ランクとして扱うことに等しく、コストが最も高くつきます。逆に、移行を機に画面を標準パターンへ寄せる方針を取れば、B ランクの多くは A 寄りに、C ランクの一部は B に落とせます。Constellation 自体が「カスタマイズよりも構成（configuration over customization）」を優先する処方的（prescriptive）なデザインシステムであると公式に位置づけられており、標準へ寄せる方針はプラットフォームの設計思想とも一致します。

そもそも Cosmos 時代のカスタマイズには、「当時の標準機能では実現できなかったから作り込んだ」ものが少なくありません。実際、セクションベース UI ではカスタムアクションを自作する必要があった一括操作（bulk actions）や一覧の Excel エクスポートが、Constellation ではリストビューの設定だけで実現できるようになっています。Constellation の標準コンポーネントと UX パターンで再点検すると、カスタムを維持する理由がすでに消えているケースが実際に多くあります。事前アセスメントは単なる工数調査ではなく、「このカスタマイズは今も必要か」を業務部門と再交渉する材料づくりでもある——ここが、アセスメントに投資する最大のリターンです。

よくある失敗

画面数だけで見積もる。 冒頭のとおり最も多い失敗です。作り込みの分布を測らずに平均単価を掛けると、作り込みが多い案件ほど過小見積もりになり、移行の中盤以降に発覚して計画が崩れます。

既存 UI の忠実再現を暗黙の前提にする。 見積もり時に方針を明示しないと、業務部門は「今と同じ画面になる」と期待し、開発側は「標準に寄せる」つもりで見積もる、というすれ違いが起きます。忠実再現と標準準拠では工数が大きく違うため、どちらの前提の見積もりかを必ず文書に明記します。この構造は現行踏襲（as-is 移植）の罠としても別記事で詳しく扱っています。

Section の中のカスタム JS を拾い漏らす。 画面一覧のレビューだけでは、Section 内部に埋め込まれたスクリプトや CSS 上書きは見えません。Rule ベースで機械的に洗い出す工程を省くと、A ランクと判定した画面が着手後に B・C だったと判明します。

C ランクを後回しにする。 「特殊な画面は最後にまとめて」と計画すると、最も不確実性の高い作業がプロジェクト終盤に集中します。C ランクこそ早期に技術検証（DX Component の試作）を行い、実現可否と工数を先に確定させるべきです。

まとめ

• Constellation 移行の見積もりは**「画面数 × 単価」では外れる**。工数を決めるのは画面の数ではなく作り込み度の分布
• 事前アセスメントではセクション／ハーネスの数と種類・カスタム CSS/JS の量・非標準コントロール・画面あたりのカスタマイズ度の 4 点を棚卸しする
• 各画面を**「そのまま置換可能（A）／再設計が必要（B）／DX Component 化を検討（C）」**の 3 段階に仕分け、分布の上に見積もりを立てる。C は平均に混ぜず個別に積む
• Constellation 移行は一部作り直しを含むため、移行を機に画面を標準へ寄せる方針が総コストを下げる。「configuration over customization」という Constellation の設計思想とも一致し、アセスメントはそのための再交渉の材料づくりでもある

移行の意思決定は、この分布データが手元にあるかどうかで質が大きく変わります。「まず全体の見積もりを」の前に、「まず分布の計測を」——これが、Constellation 移行を計画どおりに着地させるための実務の型です。

---

Cosmos から Constellation への移行アセスメント・移行計画の策定でお困りの際は、Pega Constellation UI 導入支援サービス や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、UI 資産の棚卸しから移行方針の策定までご支援します。

関連リンク

• Pega Constellation UI 導入支援サービス
• Pega Platform 開発支援
• Pega Constellation UI と Cosmos の違いを徹底比較
• Pega Constellation 移行の進め方｜段階移行と並行運用の判断
• Pega カスタム DX Component(React) の作りどころ
• 無料相談に申し込む