Pega環境間移送の設計｜製品ルール(RAP)とDeployment Managerの使い分け
「開発から本番までどう配布するか」はPega案件の品質を左右する土台。製品ルール(RAP)で何を束ね、Deployment Managerで何を自動化し、環境固有の設定値をどこで分離するか。移送の設計判断を体系立てて解説する。
結論から：まず RAP で「何を束ねるか」を設計し、その上に Deployment Manager を乗せる
Pega 案件で意外と後回しにされがちなのが、「開発した成果物を、開発 → 検証 → 本番へどう配布するか」という環境間移送の設計です。しかしここは、リリースの安全性とスピードを左右する土台であり、設計の初期に決めておくべき領域です。
結論を先に言うと、移送設計の順序は次の通りです。
まず製品ルール（RAP, Rule-Admin-Product）で「1つのアーカイブに何を束ねるか」を正しく設計する。配布・検証の自動化（Deployment Manager）は、その正しい RAP の上に乗せる。
製品ルールと Deployment Manager は「どちらを使うか」という排他の関係ではありません。RAP が移送の単位を定義し、Deployment Manager がその移送を自動化するオーケストレーション層として上に乗る、という階層関係です。この位置づけを取り違えると、「Deployment Manager を入れたのに移送が壊れる」という事故につながります。本記事では、RAP の設計を起点に、両者の使い分けを具体的な判断として整理します。
製品ルール（RAP）とは — 移送の「単位」を宣言する
製品ルール（RAP, Rule-Admin-Product） は、ルールセットとそのバージョン・データインスタンス・その他の成果物を、1つのアーカイブに束ねて移送する宣言的な単位です。ある環境で作ったものを別の環境へ持っていくとき、「何を、どのバージョンで、どのデータとともに運ぶか」を定義するのが RAP の役割です。
ここで最も重要なのは、移送作業の起点は「何を含めるか」の設計にあるという点です。ツールの操作手順ではありません。RAP の中身を正しく定義できていれば、その先が手動エクスポートでも Deployment Manager でも、移送は成功します。逆に中身の設計を誤れば、どんな自動化を被せても移送先で壊れます。
RAP に含める代表的な要素は次の通りです。
- ルールセットとバージョン — アプリケーションを構成するルールの本体。どのバージョン範囲を含めるかが肝
- prerequisites（前提ルールセット） — 対象ルールセットが依存している下位のルールセット・バージョン
- データインスタンス — アプリケーションの動作に必要なデータレコード（マスタ的な設定データなど）
- その他の成果物 — アクセスグループやオペレーターなど、移送先で必要になる管理系のインスタンス
なお、オペレーター ID・アクセスグループ・DB レコードといったデータインスタンスは、あらかじめルールセットに関連付けておくと、製品ルールを生成した際に自動でアーカイブへ取り込まれます。個々のデータを RAP に一つずつ列挙する必要がなくなり、「何を束ねるか」を関連付けの設計としてルールセット側で一元管理できます。
Deployment Manager とは — RAP の上に乗る自動化層
Deployment Manager は、製品ルールを土台に、パッケージ生成 → 配布 → 検証というパイプラインを自動化するオーケストレーション層です。手動の export/import と排他の関係ではなく、その上位に乗る位置づけだと理解するのが正確です。
手動移送では、担当者が RAP をエクスポートし、次の環境にインポートし、動作を確認し……という一連の作業を環境の数だけ人手で繰り返します。Deployment Manager はこの流れをパイプラインとして定義し、承認ゲートや自動テスト・検証ステップを挟みながら、環境から環境へ成果物を自動で送り出します。CI/CD の考え方を Pega の移送に持ち込むものだと捉えると位置づけが明確です。
ただし、Deployment Manager が運ぶ中身は結局 RAP です。パイプラインが立派でも、RAP に必要なバージョンや prerequisites が入っていなければ、移送先は同じように壊れます。自動化は「正しい移送単位」を前提に初めて価値を持ちます。
バージョン依存の注意: Deployment Manager の機能・UI・パイプラインの構成要素は版によって異なります。パイプラインの組み方や利用できる検証ステップは、採用しているバージョンの公式ドキュメントに沿って設計してください。
手動 export/import と Deployment Manager の使い分け
両者は排他ではありませんが、「どこから自動化に投資するか」という判断は必要です。目安を表に整理します。
| 判断ポイント | 手動 export/import | Deployment Manager |
|---|---|---|
| 位置づけ | RAP を直接移送 | RAP を土台に配布・検証を自動化 |
| 向いている規模 | 少数環境・単発・小規模 | 多環境・反復的なリリース |
| 移送の再現性 | 手順書と人手に依存 | パイプラインとして定義・再現 |
| 検証・承認ゲート | 都度手作業 | パイプラインに組み込み可 |
| 導入・維持コスト | 低い（すぐ始められる） | 初期構築が必要 |
| ヒューマンエラー | 起きやすい | 起きにくい（自動化された範囲で） |
| 共通の土台 | RAP | RAP |
判断の型はシンプルです。移送が反復的で、環境が複数あり、検証込みで安全に回したいなら Deployment Manager。少数環境の単発・小規模なら手動 export/import で十分。ただしどちらを選んでも、設計すべき対象は同じ RAP だという点は変わりません。継続的なリリース体制の構築については Pega DevOps 導入支援 の観点も併せて検討すると全体像が見えます。
RAP 設計の核心 — ここを外すと必ず壊れる
移送の失敗はほぼ「RAP の中身の設計ミス」に集約されます。特に重要な2つの論点を掘り下げます。
論点1：バージョン依存と prerequisites を取り違えない
最も多い事故が、ルールセットのバージョン依存と prerequisites の取り違えです。
- バージョン依存 — 移送する対象ルールセットの、どのバージョン範囲を含めるか
- prerequisites — その対象ルールセットが動作するために前提とする、下位のルールセット・バージョン
移送先の環境には、対象ルールセットだけでなく、それが前提とする下位ルールセットも正しいバージョンで存在していなければなりません。正確には、アーカイブに含めるルールセットの prerequisites は、RAP 自体に同梱するか、移送先にすでに存在しているかのいずれかを満たす必要があります。RAP に含めるバージョン範囲が狭すぎて移送先にも無ければ、「前提ルールセットが足りない／古い」状態になり、ルールが解決できずにアプリケーションが壊れます。逆に不要なバージョンまで巻き込むと、移送先の既存資産と衝突するリスクが生まれます。
移送対象のバージョン範囲と前提を正しく含めることが、失敗回避の要です。RAP を作ったら、含めたバージョンとその prerequisites が移送先の状態と整合するかを、必ず机上で確認してください。
論点2：環境固有値を RAP に含めない
接続設定・エンドポイント URL・認証情報といった環境固有の値は、開発・検証・本番で異なります。これを RAP に含めて移送すると、開発環境の接続先を本番に持ち込んでしまう、という典型的な事故が起きます。
そこで、環境ごとに変わる値は RAP に含めず、Dynamic System Settings（DSS）などで環境側に分離するのが定石です。RAP には「どの環境でも共通のロジックと構成」を入れ、環境固有値は各環境が自前で保持する、という切り分けです。DSS はプラットフォームのデータベースに保持され、アプリケーションを再デプロイせずに値を変更できるため、環境ごとの差分を持たせる置き場所として適しています。
| 対象 | RAP に含める | 環境側で分離（DSS 等） |
|---|---|---|
| アプリケーションのルール・ロジック | ○ | |
| マスタ的な設定データ（環境非依存） | ○ | |
| 接続先エンドポイント・URL | ○ | |
| 認証情報・シークレット | ○ | |
| 環境ごとに変わるフラグ・閾値 | ○ |
設計時に「この値は環境で変わるか？」を1つずつ問い、変わるものは RAP から外す——この機械的なチェックが事故を防ぎます。
RAP の分割戦略 — 層ごとに分けて再利用と依存管理を楽にする
大規模なアプリケーションでは、すべてを1つの RAP に詰めると、依存関係が絡み合って移送が扱いにくくなります。そこで有効なのが、アプリケーションの層構造に沿って RAP を分割する戦略です。これは Pega の Enterprise Class Structure（ECS）が定める層——組織（Organization）／部門（Division）／フレームワーク（Framework）／実装（Implementation）——に対応します。ここでは代表的な3層で説明します。
- 組織層（Organization） — 複数アプリケーションで共有する組織共通の資産
- フレームワーク層（Framework） — 業務ドメインで再利用する共通機能
- アプリケーション層（Implementation） — 個別アプリ固有の実装
これらを別々の RAP に分割すると、次のメリットが得られます。
- 依存管理がしやすい — 各層の依存関係が RAP 単位で明示され、どの層を更新したのかが追いやすい
- 再利用しやすい — 共通のフレームワーク層 RAP を、複数のアプリケーションで使い回せる
- 移送の粒度を選べる — アプリ層だけを差し替えたいとき、共通層まで巻き込まずに済む
Pega 自身も、複数の built-on アプリケーションで構成される場合は、依存の下位から順に、アプリケーションを個別に配布することを推奨しています。層ごとに RAP を分ける設計はこの考え方と整合します。
逆に全部を1つの RAP にまとめると、アプリ固有の小さな変更のたびに共通資産まで移送することになり、影響範囲が無用に広がります。層の責務に沿って RAP を切ることが、長期的な保守性につながります。
よくある失敗
環境間移送の失敗は、経験上いくつかの定番パターンに収束します。
失敗1：prerequisites を含め忘れて移送先で壊れる
対象ルールセットだけを RAP に入れ、それが前提とする下位ルールセットを含め忘れるパターン。開発環境では既に下位ルールセットが存在するため気づかず、クリーンな移送先で初めて「ルールが解決できない」と発覚します。RAP を作った時点で、含めたバージョンと prerequisites の整合を必ず確認してください。
失敗2：環境固有値を RAP に混ぜて本番の接続先を汚染する
接続設定を RAP に含めて移送し、本番環境の接続先が開発環境のものに書き換わる、という事故。環境で変わる値は DSS などで分離し、RAP には共通のものだけを入れる、という切り分けを徹底すれば防げます。
失敗3：Deployment Manager を入れれば安全だと誤解する
自動化パイプラインを構築したことで移送が安全になったと錯覚するパターン。Deployment Manager が運ぶのは RAP であり、RAP の中身が誤っていればパイプラインは「誤りを高速に・確実に本番へ届ける」装置になります。自動化は正しい RAP 設計を前提にしてこそ機能します。
失敗4：全部を1つの RAP に詰めて依存が絡む
層を分けずに巨大な単一 RAP を作り、小さな変更のたびに全資産を移送するパターン。組織層・フレームワーク層・アプリ層を分割し、変更した層だけを移送できる構造にしておくべきです。
まとめ
- 移送設計の起点は「RAP に何を束ねるか」。 ツール操作ではなく中身の設計が品質を決める
- 製品ルール（RAP）と Deployment Manager は排他ではない。 RAP が移送の単位、Deployment Manager がその上に乗る自動化層という階層関係
- バージョン依存と prerequisites を取り違えない。 移送対象のバージョン範囲と前提を正しく含めることが失敗回避の要
- 環境固有値は RAP に含めず DSS 等で分離する。 接続設定を巻き込むと本番を汚染する
- RAP は層（組織／フレームワーク／アプリ）で分割する。 依存管理と再利用がしやすくなる
- Deployment Manager の仕様は版により異なる。 採用バージョンの公式ドキュメントに沿って設計する
環境間移送は「最後にやる作業」ではなく、案件の初期に設計しておくべき土台です。ここを正しく組んでおくことが、リリースのたびに繰り返される手戻りとダウンタイムのリスクを大きく減らします。
Pega の環境間移送・CI/CD 体制の設計でお困りの際は、Pega DevOps 導入支援 や Pega Platform 開発支援、無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、移送設計からリリース自動化までご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む