Pega 設計判断の早見表
Pega の設計と導入で迷いやすい 80 の場面について、当社が既定として選ぶ選択肢と理由をまとめました。詳しい根拠と例外は、各行の技術記事で説明しています。
この早見表の使い方
Pega の設計と導入で迷いやすい場面について、当社が既定として選ぶ選択肢と、その理由を 1 行で並べました。いずれも技術記事で根拠と例外を詳しく説明しています。既定は出発点で、業務の条件によっては別の選択肢が適します。判断の前提は各記事でご確認ください。
製品選定・比較
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 新規プロジェクトの UI アーキテクチャを選ぶとき | Constellation / Cosmos | 原則 Constellation（必要機能のサポートは事前確認） | 公式も新規での採用を推奨しており、長期の保守性・将来性で有利。 | 記事を読む |
| コンタクトセンター向け製品を選ぶとき | Salesforce Service Cloud / Pega Customer Service / 両者の組み合わせ | 単純な B2C 問い合わせ中心なら Service Cloud、複数部門・複数日・複雑な業務ルールの案件管理なら Pega CS | CRM 起点かプロセス起点かで設計思想が根本的に異なる。 | 記事を読む |
| 業務を Salesforce と Pega のどちらに載せるか迷うとき | Salesforce / Pega / 共存（SF フロント・Pega バック） | 顧客関係の管理は Salesforce、開始から完了まで完遂すべき業務は Pega、両方の性質なら共存構成 | 両者は競合ではなく、中心に置くもの（顧客データかケースか）が違う。 | 記事を読む |
| ワークフロー基盤を ServiceNow と Pega で比較するとき | ServiceNow / Pega / 領域ごとに共存 | 社内 IT 業務は ServiceNow、顧客向け業務プロセスは Pega、両方なら共存 | 出自（ITSM 起点か BPM 起点か）が得意領域を決める。 | 記事を読む |
| BPM プラットフォームを 3 製品から選ぶとき | Pega / Appian / Camunda | 長期・複雑なケース業務＋AI 意思決定なら Pega、業務部門主導のローコードなら Appian、開発者が既存システムに組み込むなら Camunda | 機能の優劣はリリースごとに入れ替わるが、思想と体制の適合は簡単には変わらない。 | 記事を読む |
| BPM・ワークフロー製品を選定するとき | 国産ワークフロー / 汎用ローコード / グローバル BPM | 製品比較の前に層を決める。複雑さ・変更頻度・関与者数・連携数のいずれかが閾値超えならグローバル BPM、定型の申請承認なら国産ワークフロー | 層が違う製品は解く問題が違い、同じ比較表に並べても判断できない。 | 記事を読む |
| 基幹業務システム刷新の方式を選ぶとき | スクラッチ開発 / 業務パッケージ / プラットフォーム（Pega） | 競争力の源泉で変化が速いプロセスはプラットフォーム、独自性不要ならパッケージ、超高性能・完全独自エンジンはスクラッチ | 3 択の本質は「何を自分で持つか」という責任分担ラインの違い。 | 記事を読む |
導入プロジェクト
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 導入の進め方を決めるとき | 全機能を作り切って一括公開 / MLP を早期稼働して段階展開 | MLP を早期に本番稼働させ、段階展開で育てる | 公式方法論 Pega Express がこの前提で、共有できないと初回リリースへの要件詰め込みが起きる。 | 記事を読む |
| 最初に Pega 化する業務を選ぶとき | 効果が見える定型業務 / 例外の多い審査業務 / 非協力部門の業務 | 効果が数値化でき、ステークホルダーが協力的で、8 割が定型で回る業務 | 最初のジャーニーは社内のショーケースになり、例外の吸収は 2 本目以降の方が安全。 | 記事を読む |
| 要件に対してカスタマイズするか判断するとき | 標準機能（OOTB）で満たす / 業務を標準に寄せる / カスタム開発 | 標準で満たせるか → 業務を標準に寄せられるか → 差別化領域だけ作る、の 3 段階 | カスタムは初期費用だけでなく保守で払い続けるため、TCO を左右する最大の変数になる。 | 記事を読む |
| PoC を設計するとき | 技術検証 / 業務適合検証 / 体制検証 | 目的を 3 つに分解して今回どれをやるか先に決め、成功基準は定量で事前合意 | 何を検証するか決めずに作り始めると「デモが動いた」で終わり、導入判断に繋がらない。 | 記事を読む |
| PoC で作った成果物の扱いを決めるとき | 使い捨てにする / MLP へ引き継ぐ | ケース型・データモデルは MLP へ引き継ぐ資産として作る | 捨てる PoC にせず、作ったものを最初の本番リリースに繋げるため。 | 記事を読む |
| 参考にする導入事例を選ぶとき | 有名・大規模事例 / 同業他社事例 / 業務構造が近い事例 | 業務構造（申請→審査型か受付→解決型か）が自社と近い事例 | 業務構造が違えば、スコープの切り方もケース設計の勘所も別物になる。 | 記事を読む |
| 開発委託の契約形態を決めるとき | 準委任 / 請負 / ラボ型（チーム月額） | フェーズで切り替え：構想・PoC は準委任、MLP は範囲を絞った請負か準委任、継続改善はラボ型 | 全要件固定の一括請負は、MLP → 継続拡張を前提とする Pega Express と構造的に相性が悪い。 | 記事を読む |
| 着手前の準備を段取りするとき | 逐次で準備 / 3 領域を並行で準備 | 体制・業務データ・審査環境を並行で整え、セキュリティ・法務審査と業務有識者の確保は前倒し | セキュリティ・法務審査は数週間かかり、開発着手のクリティカルパスになりやすい。 | 記事を読む |
| コンタクトセンターへの導入範囲を決めるとき | ビッグバン導入 / 画面統合のみ / 照会系 1 業務から段階拡大 | 照会系の 1 業務から始めて手続き系へ拡大 | ビッグバン導入と「画面統合止まり」を避け、AHT・ACW などの指標で効果を測りながら広げるため。 | 記事を読む |
| 大規模レガシーを刷新するとき | 一括リプレース / Wrap & Renew | レガシーをデータと機能の置き場として残し、業務プロセス層と UI を Pega で先に刷新 | 数百機能・数十年分のロジックを抱えたシステムでは、全要件洗い出しと一斉切替の前提が成立しない。 | 記事を読む |
| 発注前に体制と計画を固めるとき | 従来型 SI の進め方 / 有識者専任＋認定アーキテクトのリード＋反復前提の契約 | 業務有識者の専任参画と認定アーキテクトのリード配置を契約前に合意し、反復を許す契約と稼働後の予算を確保 | 7 つの典型的な失敗パターンのうち 5 つは開発開始前に仕込まれる。 | 記事を読む |
| 初回リリースのスコープを切るとき | MVP（動く最小）/ MLP（愛される最小）/ 複数ジャーニー同時投入 | 1 マイクロジャーニー（≒1 ケースタイプ）のハッピーパスを端から端まで通す | 例外・別チャネル・追加ジャーニーを盛り込むとリリースと価値検証が遅れ、プロジェクト全体が失速する。 | 記事を読む |
運用・内製化
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 内製化の範囲を決めるとき | 全面内製 / 全面外注 / 役割分担 | 日々の改善・小規模開発は内製 SA、大規模改修と設計レビューは外部 LSA | 内製化は 0/100 ではなく役割分担の再設計で、それが実案件で機能する現実解。 | 記事を読む |
| SIer から内製チームへ移管するとき | 一括移管 / 段階移管 | 軽微改修 → 新規の小機能 → ケース型の追加、の 3 段階 | いきなり全面移管すると事故のもとになる。 | 記事を読む |
| 市民開発に任せる範囲を決めるとき | 業務部門（市民開発）/ IT・CoE | 画面内で完結するものは現場、データ・連携・セキュリティは IT/CoE、迷ったら IT 側 | 線引きは要望の大小ではなく影響範囲で決める。 | 記事を読む |
| ローコードを全社展開するとき | ツール配布のみ / 統制の 4 点セットを敷く | 導入初日から CoE・開発標準とガードレール・レビューゲート・資産カタログを敷く | 統制なしでは、開発スピードの速さがそのまま野良アプリの増殖スピードになる。 | 記事を読む |
| 保守ベンダーに不満があるとき | 即乗り換え / 現状維持 / 段階移行 | まず改善要請。乗り換えるなら並走期間 → 軽微改修で習熟 → 本格移管 | ルールが一元管理される Pega は引き継ぎの成立性が高いが、並走の省略や解約先行が典型的な失敗。 | 記事を読む |
| 本番稼働後の運用体制を組むとき | 保守のみ（塩漬け運用）/ 保守・監視・継続改善の 3 機能 | 3 機能で設計し、継続改善の工数枠を稼働初日から予算化 | Pega の投資対効果は稼働後にどれだけ改善を回せるかで決まる。 | 記事を読む |
| プロセスマイニングを導入するとき | 可視化で完了 / 発見 → 再設計 → 実行 → 測定のループ | 実行の手段・予算・体制まで企画段階で確保し、ループを一周させる | 可視化止まりの原因は「見つける手段」と「直す手段」の分断にある。 | 記事を読む |
| 保守費を下げたいとき | 値引き交渉 / 構造改革（標準回帰・自動テスト・軽微改修の内製化） | 内訳を分解し、カスタム過多・属人化・手動テスト依存という構造要因に対処 | 構造を変えずに金額だけ削ると、品質と改善スピードが先に壊れる。 | 記事を読む |
| 肥大化したテーブルの古いデータを処理するとき | パージ（物理削除）/ アーカイブ（退避） | 監査・法的保持か後続参照が要るならアーカイブ、どちらも不要ならパージ（参照整合性を壊さない順序で） | 先に削除に走ると監査要件で足をすくわれ、全部残すとコールドストレージが第 2 の肥大化を起こす。 | 記事を読む |
ケース設計
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 業務上の対象をモデル化するとき | ケース / データインスタンス | 独立したライフサイクルと割当・承認・SLA・監査が要るものだけケース、それ以外はデータ | 業務上の重要度とケースにするかどうかは別の軸。 | 記事を読む |
| 業務のかたまりを分けるか迷うとき | 親ケースのステージ/ステップ / 子ケース | 独立したライフサイクル・別 SLA・別担当・別の解決タイミングがあるときだけ子ケース | 子ケースは画面上の区切りではなく、独立して追跡・解決される業務の単位。 | 記事を読む |
| 処理をステージに置くかフローに書くか迷うとき | ステージ/ステップ / フロー | 業務のマイルストーンはステージ/ステップ、ステップ内の手続きはフロー | 2 つの責務を混ぜると、業務ロジックと遷移制御が一体化した巨大フローが生まれる。 | 記事を読む |
| 並列・非同期のサブプロセスを組むとき | spin-off / split-for-each / split-join | 待たないなら spin-off、可変個を待つなら split-for-each、固定・少数の異なる分岐を待つなら split-join | 選定の主軸は、親フローが結果を待ち合わせるかとその粒度。 | 記事を読む |
| ケースのロック方式を決めるとき | 悲観ロック（Allow one user）/ 楽観ロック（Allow multiple users） | 既定は悲観ロック、長時間保持 × 低競合の処理だけ楽観ロック | 確実な排他が要る短時間の更新は悲観、保持が長く競合が稀な処理は楽観が向く。 | 記事を読む |
| AI エージェントを基幹業務に組み込むとき | プロンプト駆動の自律 / ワークフロー統制下の自律 | AI の自律性をケース/ワークフローの枠内に置き、先に業務プロセスを構造化 | 統制なき自律は幻覚の実行・権限逸脱・監査不能を招く。 | 記事を読む |
| Blueprint の生成設計をどこまで採用するか決めるとき | 生成案をそのまま採用 / たたき台にして LSA が上書き | 骨格・ペルソナ・命名・標準ワークフローは活かし、例外・非機能・統合制約・アクセス制御・ケース粒度・正規化は LSA が再設計 | Blueprint の出力は完成品ではなく、よくできた初稿。 | 記事を読む |
データモデル・宣言的処理
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 参照データをフィールドに紐づけるとき | Picklist / Data Reference | 値だけなら Picklist、マスタのレコードを参照するなら Data Reference | Data Reference なら関係のモデル化・Association による join・UI 自動解決を Pega が肩代わりする。 | 記事を読む |
| コード表・選択肢・マスタの置き場所を決めるとき | Picklist / DataType / 専用クラス | 単一フィールド限定は Picklist、複数箇所で再利用する値域は DataType、属性・関係を持つなら専用クラス | 判断すべきは重要度ではなく、再利用の広がりとデータの複雑さ。 | 記事を読む |
| コードマスタの保存値を決めるとき | 日本語ラベルで保存 / コード値で保存しラベルはマスタ側 | コード値（英小文字）で保存し、表示ラベルはマスタ側で管理 | 保存値や DB 制約に日本語ラベルを入れず、表記ゆれを防ぎ一括変更しやすくするため。 | 記事を読む |
| 関連データをケースに持たせるとき | 埋め込み（aggregation）/ 参照（association） | 時点で固定すべき事実は埋め込み、常に最新が要る値は参照 | 判断軸は重要度や軽さではなく、データの鮮度要件。 | 記事を読む |
| データクラスの主キーを決めるとき | 業務（自然）キー / 代替キー（GUID） | 値が変わりうるなら代替キー、真に不変なときだけ業務キー | 可変な業務属性を主キーにすると同一性が揺らぎ、参照が崩壊する。 | 記事を読む |
| データの一意性を担保するとき | DB 一意制約 / アプリ層の検証 / データページのキー定義 | 3 層すべてで担保する | どれか 1 つに頼ると、単一取得の破綻や取り違えとして表面化する。 | 記事を読む |
| クラスの継承を設定するとき | パターン継承 / 直接継承 | 業務クラスはパターン継承で作業プール配下に束ね、作業プールから基底クラスへは直接継承 | ルール解決はパターン継承の祖先を先に探索し、尽きたら直接継承の親へ引き継ぐ。 | 記事を読む |
| データページのスコープを決めるとき | Thread / Requestor / Node | マスタは Node（再読み込み条件とセット）、都度最新が要るものは Thread、中間は Requestor | 「なんとなく Thread」は同じマスタを何度も取りに行き、外部連携の呼び出しを無駄に増やす。 | 記事を読む |
| 計算プロパティの置き場所を決めるとき | Declare Expression / Data Transform・Activity | 常に整合が要る派生値は Declare Expression、順序依存・外部呼び出し・複雑な分岐は Data Transform | 全部手続きなら整合保証の負債を抱え、全部宣言なら再計算の連鎖で性能が落ちる。 | 記事を読む |
| ページリストを集計するとき | Activity のループ / Declare Expression の集計関数 | Declare Expression（Sum / Count / Average など） | Activity のループより整合も保守性も上。 | 記事を読む |
| 宣言的処理の連鎖方式を選ぶとき | 前方連鎖 / 後方連鎖 | 読み取り主体なら前方連鎖、更新主体・稀にしか読まないなら後方連鎖 | 前方連鎖は書き込み時、後方連鎖は読み取り時にコストを払う。 | 記事を読む |
連携・API
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| RPA と BPM の役割分担を決めるとき | RPA を増やし続ける / BPM に全面乗り換え / 併用 | Pega をプロセスの司令塔にし、接続は API 優先、API の無いレガシー画面操作だけ RPA | RPA は作業の代行でプロセスは変えず、担当する層が違う。 | 記事を読む |
| 外部システムを呼び出すとき | 同期（コネクタ直呼び）/ 非同期（キュープロセッサ） | 結果をその場で使う呼び出しだけ同期、それ以外は非同期へ逃がす | 全部同期にすると、相手が遅い・落ちているだけでケースが進まなくなる。 | 記事を読む |
| キュープロセッサの種類を選ぶとき | Standard / Dedicated | 既定は Standard、独立した設定や隔離が要るなら Dedicated | Dedicated は即時/遅延を選べ、専用トピックを持つ。 | 記事を読む |
| 外部連携のリトライを設計するとき | exactly-once 前提 / at-least-once 前提で冪等化 | 冪等性を先に作り、その後リトライの回数と間隔を決める | キュープロセッサやネットワーク層のリトライは同じ処理を複数回実行しうる。 | 記事を読む |
| 二重処理を防ぐ手段を選ぶとき | 相手に冪等キー/相関 ID を渡す / Pega 側で処理済み判定 | 基本は冪等キーを相手に渡す。非対応なら Pega 側で処理済み判定してから副作用を実行 | リトライで同じキーを再利用すれば、相手側で重複を弾ける。 | 記事を読む |
| DWH へデータを抽出するとき | 増分抽出 / 全件洗い替え | 大量・増加するデータは増分抽出、全件は小さく頭打ちのマスタに限定 | 全件抽出は業務量に比例して重くなり、いずれバッチ枠に収まらなくなる。 | 記事を読む |
| DX API で独自フロントを作るか判断するとき | OOTB Constellation UI / DX API で独自フロント | Pega 外への埋め込み・OOTB にないチャネル・既存デザインシステム統合という構造的動機があるときだけ独自フロント | 独自フロントは SDK 追従とアップグレード検証を自チームで恒常的に負う。 | 記事を読む |
Constellation・UI
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 既存 Cosmos アプリを移行するとき | 今すぐ全面移行 / 改修時に段階移行 | 新機能追加・改修のタイミングで段階的に Constellation へ切り替える | 全面移行は工数が大きく、中途半端に始めると保守コストが跳ね上がる。 | 記事を読む |
| Constellation 移行を見積もるとき | 画面数 × 単価 / 作り込み度の分布で見積もる | UI 資産を棚卸しし、置換可能・再設計・DX Component 検討の 3 段階に仕分けてから見積もる | 同じ画面数でも作り込み度の内訳で総工数が倍以上ブレる。 | 記事を読む |
| フォームから任意のアクションを起動したいとき | 画面にカスタムボタン / ケースの Actions メニュー | ケースの Actions メニュー（optional action / process）から起動 | アサインメント画面に置けるボタンは標準アクションのみ。 | 記事を読む |
| 連続した入力画面を作るとき | Screen flow / Multi-step Form / Process flow・Subprocess | 分岐なしは Multi-step Form、分岐ありは Process flow / Subprocess | Multi-step Form は linear で分岐を扱えず、legacy の Screen flow はそのまま使えない。 | 記事を読む |
| Constellation の画面を設計するとき | 標準 template + field / カスタムコンポーネント | まず標準 template と field で満たせるか検証し、代替不可の要件だけカスタム | カスタムは開発・保守・バージョン追従のコストを自チームで負う。 | 記事を読む |
| 繰り返し使う見せ方を作るとき | 一度きりの view を量産 / 再利用 view を明示設計 | 再利用 view として明示的に設計する | 一度きりの view の量産は保守負債になる。 | 記事を読む |
| 標準にない UI 部品が必要なとき | OOTB コンポーネント + 設定 / 自作 DX Component（React） | まず OOTB + 設定、真のギャップに限り自作（着手前に upgrade-safe 設計と保守オーナーを決める） | 自作はアップグレードのたびに再検証・改修の保守コストを背負う。 | 記事を読む |
セキュリティ・権限・監査
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 項目・レコード単位で見せ分けるとき | RBAC / ABAC（Access Control Policy + PropertyRead） | 役割で切れるものは RBAC、属性でしか切れないものだけ ABAC で補完 | ABAC は RBAC を置き換えず補完し、RBAC で拒否したものは ABAC で許可できない。 | 記事を読む |
| ABAC を設計する時期を決めるとき | 後付け / データモデル設計と同時 | データモデル設計と同時に決める | 後付けだと判定に使う属性がデータモデルに無く、大改修になる。 | 記事を読む |
| 新しい権限の要望が来たとき | Access Group 新設 / Role 追加・合成 / Privilege / 条件付き ARO / ABAC | まず Role を足す・合成し、見え方の違いは条件で吸収。Access Group 新設は新ペルソナ × アプリ文脈のときだけ | 部門ごとの Access Group 複製は、組織変更のたびに全数メンテが必要になり必ず破綻する。 | 記事を読む |
| 認証方式を設計するとき | SAML 2.0・OIDC / OAuth 2.0 / Basic 認証 | 人の対話ログインは SAML/OIDC、サービス間・API は OAuth 2.0。認証サービスは用途ごとに分ける | 1 つの認証サービスで兼ねたり Basic 認証を使い回したりすると、後から作り直しになる。 | 記事を読む |
| 監査証跡を設計するとき | フィールド監査 / ケース履歴 / セキュリティイベントログ / 全項目一律 | 要件から逆算し、業務証跡はフィールド監査＋ケース履歴、セキュリティ証跡はイベントログ（SIEM へ転送） | 全項目を一律に有効化すると性能・容量を確実に圧迫する。 | 記事を読む |
| 生成 AI 機能の利用可否を決めるとき | 全面禁止 / 無条件解禁 / データの流れで層別 | 設計段階の機能はルール付きで許可、本番の業務データを扱い得る機能は審査制 | 全面禁止は野良利用と競合劣後を招くだけで、統制として機能しない。 | 記事を読む |
| 導入前のセキュリティ審査を進めるとき | 全項目を一律に質問 / 責任分界で仕分けてから証跡を求める | プラットフォーム側・利用者側・境界領域に仕分け、それぞれ認証報告書・設計書・分界文書で確認 | 仕分けずに一律に質問すると、質問→回答→再質問の往復が増えて審査が長引く。 | 記事を読む |
性能・レポート
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| 本番で「遅い」と申告されたとき | 感覚で即チューニング / 定量化 → 測定 → 層の切り分け | 事象を定量化し、測定してから層を外側から順に切り分ける | 主観のまま調べると、調べる場所も直す場所も運任せになる。 | 記事を読む |
| レポートの条件・結合・ソートに使う列を決めるとき | 公開列 / BLOB 内の未公開プロパティ | 必ず公開列で行う | BLOB 内の未公開プロパティを条件にした瞬間、全行を展開するスキャンに落ちる。 | 記事を読む |
| どのプロパティを公開（最適化）するか決めるとき | 全部公開 / SQL で使う列だけ公開 / BLOB のまま | フィルタ・ソート・結合に使う列だけ公開し、Page List 内の値は Declare Index | 公開列とインデックスは読みを速くするが、書き込みと更新を重くする。 | 記事を読む |
| レポートの作り方を選ぶとき | Report Definition / Insights | 定型・再利用・統制が要るものは Report Definition、アドホックな探索は Insights | 判断の起点はガバナンスで、統制要件が強いほど Report Definition が向く。 | 記事を読む |
DevOps・テスト・品質
| 迷う場面 | 選択肢 | 当社の既定 | 理由 | 詳しく |
|---|---|---|---|---|
| どちらのスタジオで作るか迷うとき | App Studio / Dev Studio | まず App Studio、表現できない部分だけ Dev Studio に降りる | 安易に降りるほど、モデル駆動性・ガードレール順守・アップグレード容易性を失う。 | 記事を読む |
| パイプラインに品質ゲートを入れるとき | 警告のみ（非ブロッキング）/ 不合格なら止まる（ブロッキング） | PegaUnit・Compliance Score・セキュリティチェックをブロッキングで各ステージに差し込む | 止まらないゲートは形骸化する。 | 記事を読む |
| CI/CD の統合範囲を決めるとき | Deployment Manager で完結 / 全社 CI/CD（Jenkins 等）へ統合 | Pega 中心なら純正で完結、全社 DevOps があるなら REST API 経由で統合 | 統合範囲は組織のガバナンスがどこにあるかで決まる。 | 記事を読む |
| 環境間移送を設計するとき | 製品ルール（RAP）の手動移送 / Deployment Manager | まず RAP で束ねる単位を設計し、その上に Deployment Manager を乗せる | 両者は排他ではなく、RAP が移送の単位で Deployment Manager はその上の自動化層。 | 記事を読む |
| 環境固有の設定値を移送するとき | RAP に含める / DSS 等で分離 | RAP に含めず DSS 等で分離する | 接続設定を巻き込むと本番を汚染する。 | 記事を読む |
| ガードレール警告が出たとき | 直す / justify（正当化）/ 設計に戻す | justify でスコアだけ上げず根本対処し、justify 済みは定期的に棚卸し | justify は説明責任の記録であって、根本対処の代替ではない。 | 記事を読む |
| Compliance Score を品質判断に使うとき | 品質保証の指標とみなす / 保守性の品質ゲートとして使う | 高スコア（目安 90+）を CI/CD ゲートの閾値にし、負荷試験・脆弱性診断・機能テストは別に行う | スコアは保守性の集約指標で、性能・セキュリティ・機能の正しさを保証しない。 | 記事を読む |
| テスト自動化の配分を決めるとき | PegaUnit / シナリオテスト / 手動 QA | ビジネスロジックは PegaUnit で厚く、重要フローの端から端はシナリオテストで少数、速い PegaUnit を CI ゲートに | シナリオテスト偏重は UI を直すたびにテストが壊れ、保守が破綻する。 | 記事を読む |
| Constellation アプリの UI を自動テストするとき | 組み込みシナリオテスト / Selenium Starter Kit | Pega 公式の Selenium Starter Kit | 組み込みのシナリオテストは従来型 UI 向けで、Infinity '24〜'25 時点では Constellation に非対応。 | 記事を読む |