レガシーシステム刷新に Pega を使う｜Wrap & Renew という現実解

結論から：一括リプレースではなく「包んで、少しずつ作り替える」

「20年動いている基幹システムを刷新したい。ただし業務は1日も止められない」——レガシー刷新の相談は、ほぼ必ずこの形で始まります。そして多くの企業が最初に検討するのが「全機能を洗い出して、新システムに一括で作り直す」一括リプレースです。

結論を先に言うと、当社の見解は明確です。

レガシーは「データと機能の置き場」として残し、業務プロセス層（人の判断・進行管理）を Pega に移す。UI と業務体験を先に刷新し、業務ジャーニー単位でレガシー機能を段階的に廃止していく——この「Wrap & Renew」が、大規模レガシー刷新の現実解です。

一括リプレースが悪いのではなく、数百機能・数十年分の業務ロジックを抱えたシステムに対しては、一括方式の前提（要件を全部洗い出せる・一斉切替に耐えられる）が成立しない、というのが実務での実感です。本記事では、なぜ一括リプレースが失敗しやすいのか、Wrap & Renew では何を包み何を作り替えるのか、そして適用できる条件はどこにあるのかを、判断できる粒度まで落とし込みます。

なぜ一括リプレースは失敗しやすいのか

一括リプレースの失敗要因は、プロジェクト固有の事情ではなく方式そのものに内在する構造的な問題です。大きく3つあります。

1. ビッグバンリリースのリスク

一括方式では、数年かけて作った新システムにある切替日を境に全業務を一斉移行します。つまり切替日が「プロジェクト全体で最もリスクが高い日」になります。テストをどれだけ重ねても、20年分の業務の組み合わせを事前に網羅することはできず、問題が出たときの影響は一部門ではなく全業務に及びます。切り戻しの計画はあっても、データ移行を伴う切り戻しは実際には容易ではありません。

2. 「現行踏襲」で要件が肥大化する

長年使われたシステムの全機能を移すとなると、要件定義は「現行システムに何があるか」の調査になります。ここで必ず起きるのが**「使っているかどうかわからないが、無くすのは怖いので現行踏襲」という要件の積み上げ**です。誰も仕様を説明できない機能まで移植対象になり、要件は膨らみ、工期と費用が比例して伸びます。本来の目的だった「業務を良くする」ための議論に使える時間は、現行調査に食われて消えていきます（この「現行踏襲」の構造的な問題は Pega 導入の現行踏襲という罠：as-is 移植と to-be 再設計の判断基準 で詳しく扱っています）。

3. 数年間、価値が出ない

一括方式では、新システムが稼働する日まで利用部門は1円分の改善も受け取れません。数年間投資を続けて、価値が出るのは最後の一瞬——このキャッシュフロー構造は、事業環境の変化に対して極めて脆弱です。プロジェクト途中で業務や制度が変われば手戻りになり、経営環境が変われば「まだ何も出ていないプロジェクト」として中断の判断対象になります。

Wrap & Renew とは——何を包み、何を作り替えるのか

Wrap & Renew は、システムを機能の山として一括で置き換えるのではなく、レイヤーで分けて段階的に置き換えるアプローチです。

• データと基幹機能（残す＝Wrap） — レガシーは「データと機能の置き場」として当面残します。勘定系の計算、マスタ、トランザクションデータなど、安定して動いている部分は無理に触りません。Pega からは API 経由で参照・更新します。
• 業務プロセス層（移す＝Renew の中核） — 人の判断、承認、割当、進行管理、SLA といった「業務がどう流れるか」の層を Pega のケースマネジメントに移します。実は業務の不満の多く——「進捗が見えない」「紙と Excel で回している」「担当者ごとにやり方が違う」——はこの層の問題であり、レガシー本体を作り直さなくても解決できます。
• UI と業務体験（先に刷新） — 利用者が触る画面と業務の流れを最初に新しくします。現場から見れば「システムが新しくなった」体験が早期に手に入り、プロジェクトへの支持が維持できます。

この「チャネルでも基幹でもなく、中心にある業務プロセス層から作る」考え方は、Pega が公式に center-out（センターアウト）として提唱しているアーキテクチャ思想そのものです。フロントのチャネル（Web・モバイル・コールセンター）にも、バックの記録システム（基幹・レガシー）にもロジックを置かず、中央のプロセス・判断の層に集約して両側へ接続する——Wrap & Renew はこの center-out をレガシー刷新の文脈に適用したものと言えます。

「Wrap and Renew」という言葉の出自と現在地

なお「Wrap and Renew」は当社の造語ではなく、Pega 自身が政府機関向けイベントや大手医療保険会社の導入事例などで長年用いてきた、レガシーモダナイゼーションの公式な呼び方です。さらに 2026 年現在の Pega は、生成 AI を組み込んだ Pega Blueprint を使い、レガシー資産（ドキュメント・業務フロー等）を解析（Discover）→ 新しいワークフローアプリケーションとして再設計・生成（Reimagine）→ レガシーを退役（Retire）という、より「置き換え」に踏み込んだ路線（rethink and replace）を打ち出しています。呼び方とツールは進化していますが、「一括で捨てずに、業務プロセス層を中心に作り替え、レガシーの守備範囲を縮めて最後に退役させる」という骨格は共通です。Blueprint をどこまで信頼して使うかは Pega GenAI Blueprint の使いどころ で別途論じています。

比較表：一括リプレース vs Wrap & Renew

観点	一括リプレース	Wrap & Renew
リリース方式	一斉切替（ビッグバン）	ジャーニー単位の段階リリース
失敗時の影響範囲	全業務	切り出した1ジャーニーのみ
要件定義	現行全機能の調査・踏襲	対象ジャーニーの「あるべき姿」の定義
最初の価値が出るまで	数年後（稼働日）	数ヶ月後（最初のジャーニー稼働時）
レガシーの扱い	廃棄して作り直す	データと機能の置き場として残し、段階廃止
前提条件	全仕様を洗い出せること	レガシーへの API / 連携手段を確保できること
向くケース	小規模・仕様が明確なシステム	大規模・長寿命・仕様が属人化したシステム

進め方：業務ジャーニー単位で切り出す

Wrap & Renew の実行単位は「機能」ではなく業務ジャーニーです。「申込受付から契約成立まで」「住所変更の受付から反映まで」のように、業務として始まりと終わりがある一連の流れを1単位として切り出します。

Step 1：最初のジャーニーを選ぶ

初回は「業務上の痛みが大きく、かつレガシーとの連携が比較的単純なジャーニー」を選びます。たとえば、受付が紙や Excel で進捗が見えず、担当者間の引き継ぎで滞留している業務は典型的な候補です。ここで重要なのは、最初の1本で「この方式は機能する」という実績を社内に示すことです。逆に、最難関のジャーニーから着手するのは避けます。

Step 2：Pega で再構築し、レガシーは API で参照する

選んだジャーニーを Pega のケースタイプとして再構築します。進行管理・割当・承認・SLA・監査証跡（ケース履歴）はケースマネジメントの標準機能で実現し、顧客情報や契約データなどレガシー側にあるデータは、コネクタ経由で参照・更新します。この時点でレガシーの画面は（このジャーニーに関しては）使われなくなりますが、レガシーのデータと機能はそのまま生きています。作り直したのは業務プロセス層と UI だけです。

Step 3：レガシー機能を段階的に廃止する

ジャーニーの移行が進むごとに、レガシー側で使われなくなった画面・帳票・バッチを棚卸しして廃止します。この「廃止」を明示的な作業として計画に入れることが重要です。移行のたびにレガシーの守備範囲が縮み、最終的にはデータストアと少数のコア機能だけが残ります。そこまで縮小すれば、最後の置き換え（データ移行を含む）は当初の姿とは比較にならない小さなプロジェクトになっています。

適用条件：レガシーに「接続できるか」がすべての前提

Wrap & Renew には明確な前提条件があります。レガシー側に API、またはそれに準ずる連携手段を確保できることです。Pega 側は REST・SOAP をはじめ、SAP・JMS・MQ・ファイル連携といった標準コネクタで外部システムと接続できます（利用できるコネクタの種類はバージョンにより異なるため、公式ドキュメントでの確認を推奨します）。しかし、レガシー側に受け口がなければ包みようがありません。

実務では、レガシーの接続性はおおむね次の順で確認します。

1. API がすでにある — そのまま Wrap 可能。最良のケース
2. API は無いが、DB 構造やファイル連携仕様が判明している — DB 参照やファイル連携で接続可能。更新系の整合性設計には注意が必要
3. 完全ブラックボックス（仕様書もベンダーサポートも失われている） — 先に接続性の確保から始める。API ゲートウェイの整備、リバースエンジニアリングによる連携仕様の復元など、「Wrap できる状態にする」工程を最初のフェーズとして計画します

3 のケースで接続性の確認を飛ばして進めると、プロジェクト中盤で「Pega から基幹のデータに触れない」ことが発覚し、計画全体が止まります。刷新の企画段階で最初に検証すべきはここです。

よくある失敗

「現行画面の完全再現」を要件にしてしまう

Wrap & Renew の価値の半分は UI と業務体験の刷新にあります。にもかかわらず「現場が混乱しないように」と現行のレガシー画面を Pega 上で忠実に再現しようとすると、一括リプレースの失敗要因だった「現行踏襲の肥大化」を段階方式に持ち込むことになります。再現すべきは画面ではなく業務の目的です。

ジャーニーの切り出しが大きすぎる

「最初のリリースで主要業務を全部」と欲張ると、それはもう小さなビッグバンです。最初の1本は数ヶ月で稼働できる規模に絞り、リリースのリズムを作ることを優先します。

廃止計画がなく、二重運用が恒久化する

新旧併存は Wrap & Renew の途中経過であって、終着点ではありません。レガシー機能の廃止をロードマップに明記しないと、「Pega でもレガシーでも同じ業務ができる」状態が固定化し、運用コストは刷新前より増えます。ジャーニー移行と機能廃止は必ずセットで計画します。

接続性の検証を後回しにする

前述の通り、レガシーに接続できるかどうかは方式全体の前提です。企画段階で PoC レベルでも実際に接続してみることを推奨します。

まとめ

• 大規模レガシーの一括リプレースは、ビッグバンリスク・現行踏襲の肥大化・数年間価値ゼロという構造的な失敗要因を抱える
• Wrap & Renew は、**レガシーをデータと機能の置き場として残し（Wrap）、業務プロセス層と UI を Pega で先に刷新する（Renew）**アプローチ。Pega が公式に提唱する center-out の考え方に沿っており、「Wrap and Renew」という呼び方自体も Pega 発の公式用語（近年は Blueprint を軸にした rethink and replace へ発展）
• 実行単位は機能ではなく業務ジャーニー。切り出し → Pega で再構築 → レガシー機能の段階廃止、を繰り返す
• 前提条件はレガシーへの API / 連携手段の確保。完全ブラックボックスなら、先に接続性の確保をフェーズとして計画する
• 失敗パターンは「現行画面の再現」「切り出しの肥大化」「廃止計画の欠如」「接続性検証の後回し」——いずれも企画段階で潰せる

刷新プロジェクトの成否は、作り始めてからの実装力より、この方式選択と最初のジャーニー選定でほぼ決まります。自社のレガシーが Wrap & Renew に向くのか、最初にどの業務を切り出すべきか——判断に迷う場合は、企画段階からの相談をおすすめします。

---

Pega によるレガシー刷新・モダナイゼーションの検討は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、方式選定・ジャーニー切り出しの設計からご支援します。

関連リンク

• Pega Platform 開発支援
• Pega Customer Service 導入支援
• Pega 移行アプローチの選択｜一括・段階・並行稼働の判断基準
• Pega 導入の現行踏襲という罠｜as-is 移植と to-be 再設計の判断基準
• Pega GenAI Blueprint の使いどころ
• Pega Constellation UI と Cosmos の違いを徹底比較
• Pega設計の分岐点：ケースにすべきか、データインスタンスか
• 無料相談に申し込む