Pega ガードレール Compliance Score の運用｜品質ゲート化と『偽の緑』回避
Compliance Score が 95 でも本番障害は起きます。スコアは保守性ガードレールの集約指標であって、性能やセキュリティの保証ではないからです。本記事では、スコアを品質ゲートとして機能させつつ『偽の緑』に騙されないための解釈と運用を、LSA視点で整理します。
結論から：Compliance Score は「保守性ガードレールの集約指標」であって、性能やセキュリティの保証ではない
Pega アプリケーションの健全性を測る指標として、Compliance Score（コンプライアンススコア）がよく引き合いに出されます。「スコアが 90 を超えているから品質は大丈夫」という会話を、レビューの場で耳にした方も多いはずです。
しかし結論を先に言うと、この理解は危険です。
Compliance Score は、Pega のガードレール警告の「数」と「重大度」を重み付けして集約した 0〜100 の指標にすぎません。あくまで保守性（Pega のベストプラクティスにどれだけ沿っているか）を表す集約値であって、性能・セキュリティ・機能の正しさを保証するものではありません。
だからこそ、スコアは CI/CD パイプラインの品質ゲートとして活用する価値がある一方で、「スコアが緑だから安心」という**偽の緑（false green）**に騙されない解釈が不可欠です。本記事では、スコアの正しい読み方と、品質ゲートとしての運用を LSA 視点で整理します。
Compliance Score とは何か
Compliance Score は、アプリケーション内のルールに対して Pega が出すガードレール警告をもとに算出されます。効いてくる要素は次の 3 つです。
- 警告の重大度（severity） — 警告には重大（severe / Sev1）・中程度（moderate / Sev2）・**注意（caution）**の 3 段階がある。スコアを押し下げるのは重大と中程度で、より重い重大のほうが重み付けが大きい。注意（caution）レベルの警告はスコアを下げない
- 警告の数 — 上記の対象警告が未解決のまま多く残るほどスコアは下がる
- 正当化（justify）の状態 — 同じ警告でも、正当化済みかどうかで重み付けが変わる（後述）
現行の Pega Platform では、これらを次のように集約します。母数となる「対象ルール数」から、重大・中程度の警告を重み付けした値を差し引き、割合を 0〜100 に換算する形です。
Compliance Score = MAX(0, ( 対象ルール数 − ( 3×重大・未正当化 + 2×中程度・未正当化 + 1×重大・正当化 + 1×中程度・正当化 ) ) ÷ 対象ルール数 ) × 100
未正当化の重大警告が重み 3、中程度が重み 2、正当化済みはいずれも重み 1 という係数が、後述する justify の効き方を決めています。Pega 自身はこのスコアを 90 以上＝良好（good standing）／ 80〜89＝要改善レビュー／ 80 未満＝即対応という帯で解釈します。
この 3 要素を集約して 0〜100 の 1 つの数値に落とし込んだものが Compliance Score です。確認先は、Application Quality ダッシュボード（Dev Studio の Configure ▸ Application ▸ Quality ▸ Dashboard）の Guardrails タイルです。ここに Compliance Score が表示され、[View details] から Application: Guardrails ランディングページ（Compliance Score タブ／ Compliance Details タブ）に入ると、スコアの内訳や、どのルールがどの警告を出しているかまで辿れます。
なお、重み付けの係数やダッシュボードの表示はバージョンによって差があります。数値の絶対値だけを他プロジェクトと単純比較するのではなく、「自分たちの版で、どの警告がどれだけ効いているか」を内訳から読む姿勢が大切です。実装時は利用中の版の公式ドキュメントで係数と対象範囲を確認してください。
警告が出たら：直す・正当化する・設計に戻す
Compliance Score を上げる（＝警告を減らす）ときの判断は、実はシンプルな 3 択に集約できます。そして、この 3 択のどれを選ぶかが、スコアを「本物の品質」にするか「偽の緑」にするかの分かれ目です。
justify（正当化）は「説明責任の記録」であって、修正ではない
Pega では、個々のガードレール警告に対して正当化（justify）を付けられます。「この警告は認識したうえで、これこれの理由で意図的にこう実装している」という逸脱の記録を残す仕組みです。外部システムの制約でどうしても標準パターンに乗れない、といったケースでは正当な使い方です。ただし、リスクが大きすぎる一部の警告は justify 自体が許可されません。その場合に残された道は「正当化」ではなく「解消（直す）」だけです。
ここで最も重要な原則があります。
justify は「なぜ逸脱したか」の説明責任を果たす記録であって、根本対処の代替ではありません。
justify を付けると、その警告はスコア計算上の重み付けが下がり（前述のとおり、未正当化なら重大＝重み 3・中程度＝重み 2 のところ、正当化済みはいずれも重み 1）、結果としてスコアは上がります。ただし重みがゼロになるわけではなく、正当化済み警告もスコアには影を落とし続けます。そして何より、コードやルールそのものは 1 行も改善していません。だからこそ、justify 済みの警告は「片付いたもの」ではなく、レビューで必ず読み返すべき対象として扱う必要があります。justify がレビューされずに溜まっていく状態は、技術的負債が「正当化」という名札を付けて可視化から外れていく状態そのものです。
品質ゲートとしての閾値設計（LSA視点）
Compliance Score を「見るだけの数字」で終わらせず、パイプラインで強制する品質ゲートにして初めて、ガードレールは仕組みとして機能します。LSA として設計時に決めるべき論点を表に整理します。
| 論点 | 推奨する考え方 | 補足 |
|---|---|---|
| ゲート閾値 | 高スコア（一般に 90+ が目安）をパイプラインの合格ラインにする | 具体値は版・組織方針による。まず現状値を測り、下げない運用から始める |
| 閾値の運用 | 「絶対値」だけでなく「前回より下げない」を併用 | 大規模アプリでは 100 を狙うより退行防止が現実的 |
| justify 済み警告 | 自動で許すのではなく、レビュー対象として棚卸しする | justify を無条件に通すとゲートが形骸化する |
| 独自警告 | 組織標準を**独自警告（カスタムワーニング）**として定義し機械化する | 「命名規約」「禁止パターン」等をレビュー任せにしない |
| 対象範囲 | スコアの母数と対象を把握したうえで解釈する | プロパティルールや Pega 提供（Pega-*）ルールセットのルールは母数から除外される |
とくに実務で効くのは、独自警告による組織標準の機械化です。「この Data Transform の書き方は禁止」「この命名から外れたルールは警告」といった自社ルールを人手のレビューで守らせようとすると、必ず漏れます。ガードレールの警告として定義してしまえば、Compliance Score に自動で反映され、パイプラインが守ってくれます。SIer として複数プロジェクトに横串で品質を効かせたい場合、この仕組み化は費用対効果が高い投資です。
Compliance Score が「保証しないもの」を正しく理解する
品質ゲートとして使う以上、スコアで何が分かって、何が分からないのかを線引きしておく必要があります。ここを曖昧にしたまま経営層に「スコア 95」と報告すると、誤った安心を与えます。
| スコアで分かること | スコアで分からないこと |
|---|---|
| ベストプラクティスへの準拠度（保守性） | 実運用に耐える性能（負荷試験の代替にはならない） |
| ガードレール警告の量と重大度の傾向 | セキュリティの堅牢性（脆弱性診断の代替にはならない） |
| 保守しづらい実装の混入度合い | 機能の正しさ（要件通り動くか＝テストの代替にはならない） |
| 退行（前回比でのスコア低下）の検知 | justify で隠された逸脱の中身（記録は残るが良否は別途判断） |
つまり Compliance Score は、保守性という 1 軸を測る優れた指標である一方、性能・セキュリティ・機能正当性という別軸はカバーしません。スコアが高いことと、本番で落ちないことは別問題です。負荷試験・脆弱性診断・機能テストは、スコアとは独立に必ず実施します。
よくある失敗
Compliance Score まわりの失敗は、経験上ほぼ次の 3 パターンに集約されます。
失敗1：偽の緑 ― 直さず justify でスコアだけ上げる
最も多く、最も厄介な失敗です。リリース前に「スコアが閾値に届かない」となったとき、根本原因を直す代わりに、警告を片っ端から justify してスコアを閾値まで押し上げる。数字は緑になり、ゲートは通過します。しかしコードは何も改善していません。
これは負債を「正当化」という体裁で不可視化しているだけで、むしろ普通に警告が残っているより悪質です。対策は前述の通り、justify 済みをレビュー対象として棚卸しする運用をゲートに組み込むこと。justify の増加そのものを監視対象にすれば、「スコアは上がったのに justify が急増している」という偽の緑のシグナルを検知できます。
失敗2：スコアを性能・セキュリティの代理指標と誤認する
「スコアが高い＝良いアプリ」という短絡です。前節の通り、Compliance Score は保守性の指標であって、性能やセキュリティを一切保証しません。スコア 95 でも、N+1 的なデータアクセスで本番が詰まることも、認可設計の穴でセキュリティ事故が起きることもあります。スコアは負荷試験や脆弱性診断を代替しない——この一線を、報告のたびに明示することが誤解を防ぎます。
失敗3：スコアの母数と対象を理解せず数字を鵜呑みにする
スコアの母数（対象ルール数）からは、すべてのプロパティルールと、Pega 提供（Pega-*）ルールセットに属するルールが除外されます。つまり Compliance Score が測っているのは「自作アプリケーション層のルール品質」であって、プラットフォーム標準まで含めた全体ではありません。この点を知らずに「スコアが高い＝全ルールが健全」と解釈すると、実は母数に入っていない領域の問題を見落とします。スコアを読むときは、その数字が何を母数にし、何を対象にしているのかを必ず確認してください。ここでも係数や対象範囲にバージョンによる違いがあり得るため、利用中の版の挙動を前提に解釈します。
まとめ
- Compliance Score は保守性ガードレールの集約指標（重大・中程度の警告を重大度×正当化状態で重み付けした 0〜100）。確認先は Application Quality ダッシュボードの Guardrails タイル（詳細は Application: Guardrails ランディングページの Compliance Score タブ）
- justify は説明責任の記録であって、根本対処の代替ではない。 justify 済みはレビュー対象として棚卸しする
- 品質ゲート化がガードレールを仕組みにする。 高スコア（目安 90+、版・組織方針による）を閾値にし、独自警告で組織標準を機械化する
- 偽の緑を避ける。 直さず justify でスコアだけ上げる運用を監視し、スコアを性能・セキュリティの代理指標と誤認しない。スコアは負荷試験・脆弱性診断・機能テストを代替しない
- 母数と対象を理解して解釈する。 プロパティルールや Pega 提供（Pega-*）ルールセットのルールは母数から除外され、係数や表示は版により異なる
Compliance Score は、正しく運用すれば「品質を落とさないための自動ブレーキ」になりますが、誤用すれば「安心を偽装する装置」にもなります。スコアの数字ではなく、その裏側の警告と justify の中身を見る文化を、プロジェクトの初期に根づかせておくことが、後工程での品質事故を防ぎます。
Pega の品質保証・パイプライン設計・ガードレール運用でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、品質ゲートの設計から運用の仕組み化までご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む