Pega Deployment Manager でCI/CDを設計｜品質ゲート組み込みと外部ツール連携の判断
「Deployment Manager を入れたのにテストは手動のまま」——CI/CD の器だけ用意して品質ゲートが形骸化する現場は少なくありません。本記事では、パイプラインの各ステージに何を自動化し、どこを純正で完結させ、どこから全社CI/CDへ委ねるかを、LSA視点の設計判断として整理します。
結論から：ゲートは「止まる」ものにし、統合範囲は要件で決める
Pega で CI/CD を設計するとき、多くの現場が Deployment Manager（Pega 純正のモデル駆動 CI/CD オーケストレーション）を採用します。ところが「器は入れたが、テストは相変わらず手動」「本番リリースだけ承認ボタンがあって、あとは素通り」という状態に陥りがちです。これでは CI/CD の本来の価値——品質を機械的に担保しながら速く回す——が出ません。
結論を先に言うと、設計判断は 2 つの問いに集約されます。
① 各ステージの品質ゲートを「警告」ではなく「不合格なら止まる」ブロッキングにできているか。② Pega 純正の Deployment Manager だけで完結させるか、Jenkins / Azure DevOps / GitHub Actions といった全社 CI/CD に組み込むか。
①はほぼ常に「止める」が正解です。②は組織のガバナンス要件で分岐します。本記事では、この 2 つを LSA 視点の具体的な設計判断として整理します。
Deployment Manager とは — モデル駆動の CI/CD オーケストレーション
Deployment Manager は、Pega が提供する純正の CI/CD オーケストレーションツールです。パイプラインを宣言的に定義し、開発 → QA → ステージング → 本番といった環境の連なりに沿って、アプリケーションの変更を自動で移送します。
移送の単位になるのが 製品ルール（RAP：Rule-Admin-Product） です。対象アプリケーションのルールセットとバージョンを製品ルールにまとめ、これをアーカイブとして生成し、リポジトリ（成果物置き場）経由で次の環境へインポートする——この一連を Deployment Manager がステージごとに実行します。手作業のインポート／エクスポートを廃し、「どのバージョンが、いつ、どの環境に入ったか」を追跡可能にするのが基本価値です。
重要なのは、Deployment Manager が単なる「移送の自動化」ではなく、各ステージに品質ゲートを差し込める点です。ここを使いこなせるかどうかで、導入効果が大きく変わります。
パイプラインの各ステージに何を差し込むか（品質ゲート）
Deployment Manager のステージには、移送だけでなく以下のような検証タスクを組み込めます。いずれも閾値未達なら次のステージへ進ませないように構成できるのがポイントです。
| ゲート種別 | 目的 | 止め方の考え方 |
|---|---|---|
| PegaUnit 実行 | ルール・ロジックの自動テスト | 失敗が 1 件でもあれば停止 |
| Compliance Score チェック | ガードレール遵守度の測定 | スコア閾値（Pega は高パフォーマンスなアプリで 97 を推奨）未満で停止 |
| セキュリティチェックリスト | セキュリティ観点の確認漏れ防止 | 未完了項目があれば停止 |
| 手動承認 | 本番前などの人手ゲート | 承認者の明示承認まで待機 |
| 独自検証タスク | 案件固有の追加チェック | REST 等で外部検証を呼び、結果で停止 |
設計の勘所は、これらを「警告」ではなく「ブロッキング（不合格なら停止）」で入れることです。PegaUnit を回していても、失敗しても先に進めてしまえば、テストは事実上ないのと同じです（Pega の「Run Pega unit tests」タスクは合格率が 100% 未満だとエラーを返します）。Compliance Score も同様で、閾値を設けて割り込めるようにして初めて、ガードレール違反の混入を機械的に防げます（Pega は高パフォーマンスなアプリケーションでコンプライアンススコア 97 を推奨しています）。
具体的には、たとえば「QA ステージへ移送する前に PegaUnit スイートを実行し、1 件でも失敗すれば移送を止める」「ステージング → 本番の間に Compliance Score が基準を割っていれば止め、加えてセキュリティチェックリストの完了と担当者の手動承認を必須にする」といった構成にします。開発の初期段階ほど自動テスト中心に軽く、本番に近づくほど承認や追加検証を重ねる、という多段構えが実務では扱いやすい形です。
純正で完結させるか、全社 CI/CD に統合するか（LSA の分岐）
ここが最も設計判断らしい分岐です。Deployment Manager 単体でパイプラインを完結させるか、Jenkins・Azure DevOps・GitHub Actions といった全社標準の CI/CD の一部として組み込むか。
純正 Deployment Manager で完結させる
対象が Pega アプリケーション中心で、チームも Pega を主戦場にしているなら、純正で完結させるのが素直です。モデル駆動で宣言的に構成でき、Pega の内部状態（ルールセット、製品ルール、テスト結果）と密に連動するため、構築と保守のコストが低いのが利点です。追加の連携基盤を持たなくてよいぶん、立ち上がりも速くなります。
全社 CI/CD へ統合する
一方、Pega 以外の成果物（マイクロサービス、フロントエンド、インフラ）と同じパイプラインで束ねたい、監査・可視化・承認フローを全社の CI/CD 基盤に一元化したい、という要件があるなら、統合を選びます。統合には主に 2 つの経路があります。1 つは、Deployment Manager が公開する REST API を全社 CI/CD 側から叩き、Pega のパイプラインを起動・制御する方法（Deployment Manager 側にも、逆に Jenkins ジョブを呼び出す Run Jenkins タスクが用意されています）。もう 1 つは、Deployment Manager のオーケストレーションを使わず、コマンドラインツール prpcServiceUtils で製品アーカイブ（RAP）の取り込み／書き出しを Jenkins 等から直接実行する「オープン DevOps」型の方法です。いずれも全社 CI/CD 側をマスターにし、その 1 ステップとして Pega のデプロイを呼び出す構成になります。
| 判断軸 | 純正で完結 | 全社 CI/CD へ統合 |
|---|---|---|
| 対象の広がり | Pega アプリ中心 | Pega＋他成果物を横断 |
| ガバナンス | Pega 内で完結 | 全社基盤に一元化 |
| 構築・保守コスト | 低い（モデル駆動で宣言的） | 連携実装のぶん高い |
| 可視化・監査 | Pega の範囲 | 全プロダクト統一ダッシュボード |
| 立ち上がり | 速い | 相対的に遅い |
| 向く組織 | Pega 専任チーム | 全社 DevOps を敷く組織 |
トレードオフは明快です。純正はシンプルさ、統合は全社ガバナンス。どちらが「正しい」ではなく、組織の CI/CD ガバナンスがどこにあるかで決まります。図の①②のいずれかが「はい」なら統合、どちらも「いいえ」なら純正で完結、と機械的に落とせます。
ブランチベース開発か、分散ブランチベース開発か
もう 1 つ、開発体制に関わる選択があります。Deployment Manager は、開発環境が 1 つに集約された ブランチベース開発と、開発環境が複数に分かれた 分散ブランチベース開発の両方に対応します。どちらの場合も、ブランチをパイプラインに投入すること（Dev Studio の Merge Branches ウィザードでマージ依頼を出すこと）でデプロイを起動でき、マージが完了する前に CI 条件（PegaUnit・ガードレール等）を通す「ゲート付きマージ」が基本形です。両者の違いは「起動のトリガー」ではなく、開発環境が 1 つか複数かにあります。
- 開発環境が 1 つで、複数チーム・複数ブランチが同じ環境で並行開発する → ブランチベース開発。ブランチのマージ契機でそのままパイプラインを起動します。
- 開発環境が拠点・チームごとに複数に分かれている → 分散ブランチベース開発。この場合はブランチをいったんメイン開発システムへエクスポートしてからマージする運用になり、アプリケーションごとに複数のパイプラインを持たせる構成も取れます。
ここで大事なのは、チームの開発フローを先に決め、それに CI/CD を合わせることです。ツールの構成が先にあってチーム運用を歪めると、開発者がパイプラインを迂回するようになり、結局ゲートが形骸化します。
Deployment Manager のホスティング形態（クラウド提供か自前構築か）や、ステージに差し込める検証タスクの種類は Pega のバージョンによって異なります。ここで挙げた品質ゲートや連携方式も、利用中の版で提供されているかを前提に設計してください。実装前に対象バージョンの公式ドキュメントで必ず確認することを推奨します。
よくある失敗
CI/CD パイプラインの失敗は、経験上ほぼ 3 つに集約されます。
失敗1：ゲートを「警告」扱いにして形骸化させる
最も多い失敗です。PegaUnit や Compliance Score のチェックは入れたが、不合格でも移送を止めない（＝非ブロッキング）設定にしてしまう。これでは赤いテスト結果を横目に本番が進み、ゲートは飾りになります。止まらないゲートはゲートではありません。 少なくとも本番手前のステージでは、テスト失敗とスコア未達は停止条件にすべきです。
失敗2：本番承認だけ手動で、自動テストが存在しない
「本番リリースの前に承認ボタンがあるから大丈夫」という思い込みです。承認者は、テストが通っている前提で承認します。その前提を担保する自動テスト（PegaUnit・Compliance Score）がなければ、承認は「見ていないものにハンコを押す」行為になります。手動承認は自動テストの代わりにはなりません。 自動ゲートで品質を担保したうえで、最後の意思決定として手動承認を置くのが正しい順序です。
失敗3：リポジトリ資格情報や環境定義をハードコードする
リポジトリの接続情報、各環境のホスト名やクレデンシャルをパイプライン定義に直書きする失敗です。環境が増えたり資格情報が変わったりするたびに定義を書き換えることになり、秘匿情報が成果物に混入するリスクも生みます。環境定義と資格情報は構成として外部化し、パイプライン定義から切り離しておくべきです。
まとめ
- 品質ゲートはブロッキングで入れる。 PegaUnit・Compliance Score・セキュリティチェックリストを、不合格なら止まる形で各ステージに差し込む。止まらないゲートは形骸化する
- 純正で完結か、全社 CI/CD へ統合かは、組織のガバナンスがどこにあるかで決める。Pega 中心なら純正のシンプルさ、全社 DevOps があるなら REST API 経由の統合
- ブランチベース開発か分散ブランチベース開発かは、開発環境が 1 つか複数かというチームの体制を先に決めてから合わせる
- 失敗は 3 つ——ゲートの非ブロッキング化・自動テストなしの手動承認・資格情報／環境定義のハードコード。この 3 つを避けるだけで大半は健全になる
Deployment Manager は「入れれば速くなる」ツールではなく、何を自動で止め、どこを人が承認し、どこまで全社基盤に委ねるかを設計して初めて効くツールです。対象バージョンの前提を押さえたうえで、ここを設計の初期に決めておくことが、リリースの安全と速度を両立させる土台になります。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む