Pega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
結論から：監査は「要件から逆算」して3系統に振り分ける
Pega で監査証跡を設計するとき、多くのプロジェクトが「とりあえず全部残しておこう」から始めて、後で性能・容量の問題に直面します。監査設計の本質は、記録量を最大化することではなく、残すべきものだけを、適切な系統に振り分けることです。
結論を先に言うと、判断の型はこうです。
何を監査するかは規制・コンプライアンス要件から逆算する。「誰が・いつ・何を変えたか」という業務の証跡はフィールド監査とケース履歴で、「認証・権限・構成変更」というセキュリティの証跡はセキュリティイベントログで残す。全項目を一律に有効化してはいけない。
Pega の監査は大きく3系統あり、それぞれ目的・記録先・運用が異なります。この3つを混同すると、「業務証跡のつもりで性能を犠牲にした」「セキュリティ監査のつもりが認証イベントを取り逃していた」という失敗に直結します。本記事では、この3系統の役割分担と、要件からの逆算による設計判断を、実案件のベストプラクティスとして整理します。
Pega の監査は主に3系統
まず、3つの系統がそれぞれ「何を、どこに残すか」を押さえます。役割が違うので、片方で足りるものをもう片方でやろうとすると無駄が出ます。
1. フィールド監査（プロパティ単位の変更記録）
フィールド監査（Field-level Auditing） は、特定のプロパティ（フィールド）に対して監査を有効化し、そのフィールドの変更前後の値・変更者・変更日時をケースの History に記録する仕組みです。「契約金額が誰によって、いつ、いくらから いくらに変わったか」といった、業務上追跡すべき値の変遷を残すのに使います。記録された内容は、ケースの History ダイアログ（Field History）から参照できます。
重要なのは、監査はフィールドごとに個別に有効化するという点です。だからこそ、どのフィールドを対象にするかを設計で決める必要があります。何も考えずに全フィールドで有効化すると、後述する書き込み増幅を招きます。
2. ケース履歴（History クラスによる監査証跡）
ケース履歴は、ケースの進行そのものを記録する監査証跡です。ステージ・ステップの遷移、担当者への割当、ステータス変更、承認・却下といったケースライフサイクル上の出来事が、ワークアイテムがフローを進む過程で History-Work- クラス（pc_history_work テーブル）に時系列で記録されます。各履歴インスタンスでは pyHistory プロパティがイベント種別を、pyPerformer が実行者を保持します。フィールド監査で記録された値の変更も、この履歴上に現れます。
この pc_history_work テーブルは追記専用（insert-only）で、Pega DB 内で最も肥大しやすいテーブルの一つとして公式にも位置づけられています。つまりケース履歴は「標準で常に貯まり続ける」系統であり、容量設計から外して考えることはできません。
ケース履歴は「1件の業務がどう進んだか」を語る証跡です。フィールド監査が「値」に着目するのに対し、ケース履歴は「進行」に着目します。両者は補完関係にあり、多くの業務要件は「進行（ケース履歴）＋重要フィールドの変遷（フィールド監査）」の組み合わせで満たせます。
3. セキュリティイベントログ（認証・構成変更の追跡）
セキュリティイベントログは、業務データではなくプラットフォームのセキュリティ事象を記録します。Pega の Security Event Configuration では、大きく 認証イベント（Authentication）／データアクセスイベント（Data access）／セキュリティ管理イベント（Security administration） の3種を監査対象にでき、ログインの成功・失敗、パスワード変更、セッション終了・ログアウト、オペレータ（ユーザー）レコードの変更、セキュリティ関連ルールや構成の変更などが含まれます。記録は PegaRULES-SecurityEvent.log に JSON 形式で書き出されます。「誰がいつシステムにアクセスし、何を構成変更したか」という、業務証跡とはまったく別の観点を担います。
セキュリティイベントの設定画面や、記録できるイベント種別は Pega のバージョンによって異なります。導入時は利用中の版の公式ドキュメントで、対象イベントと設定方法を必ず確認してください。
3系統の比較表
3系統は、目的・記録先・典型的な保持先が明確に分かれます。
| 観点 | フィールド監査 | ケース履歴（History） | セキュリティイベントログ |
|---|---|---|---|
| 目的 | 値の変遷の証跡 | 業務の進行の証跡 | 認証・構成変更の証跡 |
| 記録する内容 | 対象フィールドの変更前後・変更者・日時 | ステージ遷移・割当・承認・ステータス | ログイン・ルール変更・操作・権限変更 |
| 有効化の単位 | プロパティ（フィールド）ごと | ケース単位（標準機能） | プラットフォーム設定 |
| 主な読み手 | 業務・監査（内部統制） | 業務・監査 | セキュリティ／情報システム |
| 典型的な保持先 | Pega DB（History） | Pega DB（History） | SIEM へ外部転送 |
| かけ過ぎのリスク | 書き込み増幅・容量肥大 | ― | ログ量の肥大・ノイズ |
上2つ（フィールド監査・ケース履歴）は業務証跡、3つ目はセキュリティ証跡——この線引きが設計の出発点です。
何を監査するかは要件から逆算する
監査設計で最もやってはいけないのが、「念のため全部残す」です。特にフィールド監査は、対象の選び方が性能・容量に直結します。
高頻度で更新されるプロパティにフィールド監査をかけると、書き込み増幅（write amplification）とストレージ肥大を招きやすくなります。 たとえば、バックグラウンド処理で毎分更新されるステータスフラグや、計算のたびに書き換わる中間値にまで監査を有効化すると、1回の業務操作の裏で監査レコードが何倍にも膨らみます。監査テーブルは業務量に比例して肥大し、パージ／アーカイブが追いつかなくなります。History 系のテーブルが Pega DB で最大級に育ちやすいことを踏まえれば、これは軽視できません。
だから監査対象は、規制・コンプライアンス要件から逆算して選ぶのが鉄則です。判断の順序はこうです。
- どの規制・統制要件が「誰が・いつ・何を変えたか」の証跡を求めているかを洗い出す（金融の取引記録、個人情報の変更履歴など）
- その要件が指す具体的なフィールドに限定してフィールド監査を有効化する
- 進行の証跡はケース履歴で足りることが多いので、フィールド監査を重ねない
- 認証・構成変更はフィールド監査の対象外——セキュリティイベントログで拾う
「重要そうだから」で対象を広げるのではなく、「この要件が、この証跡を求めているから」で1つずつ足す。これがかけ過ぎを防ぐ唯一の方法です。
業務証跡とセキュリティ証跡は目的が違う
3系統の中でも、業務証跡（フィールド監査＋ケース履歴）とセキュリティ証跡（イベントログ）は目的がまったく異なるため、設計を分けて考える必要があります。
- 業務証跡が答えるのは「この案件で、誰が・いつ・何を変えたか」。読み手は業務部門や内部統制で、ケースというコンテキストの中で意味を持ちます。
- セキュリティ証跡が答えるのは「誰がシステムにアクセスし、認証・権限・構成をどう変えたか」。読み手はセキュリティ／情報システム部門で、ケースとは独立した、プラットフォーム横断の観点です。
この2つを混同すると、たとえば「ログイン失敗の追跡」を業務の History で拾おうとして拾えなかったり、逆に「金額変更の証跡」をセキュリティログ側で探して見つからなかったり、といったちぐはぐが起きます。業務証跡はケースの中に、セキュリティ証跡はプラットフォーム側に——この住み分けを最初に宣言しておくことが、後工程の監査対応をスムーズにします。
なお、フィールド単位のアクセス制御（誰にどのフィールドを見せる／編集させるか）は監査とは別レイヤーの話です。アクセス制御の設計は Pega の ABAC とフィールドレベルアクセス で扱っています。監査は「起きたことの記録」、アクセス制御は「起こさせない制御」で、両方を組み合わせてコンプライアンスを満たします。
セキュリティイベントは SIEM へ外部転送する
セキュリティイベントログは、Pega の中に貯め込むだけでは片手落ちです。実務では、SIEM（Security Information and Event Management）へ外部転送することを前提に設計します。Pega 自身、Security Event Configuration を SIEM の一部と位置づけており、外部の SIEM 基盤と連携して異常を検知・対応する運用を想定しています。理由は3つあります。
- 改ざん耐性 — 監査対象のシステム自身の中にログを置き続けると、そのシステムを侵害した攻撃者にログも改ざんされ得ます。SIEM に転送して外部で保全することで、証跡の独立性を担保します。
- 保持期間 — 規制が求める保持期間（数年に及ぶこともある）を Pega DB 内で満たすと、DB が肥大します。長期保持は SIEM／アーカイブ基盤側の責務に寄せます。
- 横断的な相関分析 — Pega 単体ではなく、他システムのログと突き合わせて初めて見える攻撃兆候があります。相関分析は SIEM の得意領域です。
そのうえで、保持期間・パージ／アーカイブ方針まで含めて設計を完結させます。「どのイベントを、どこに、何年残し、いつパージするか」を決めておかないと、転送したはいいが Pega 側の元ログが無制限に溜まる、あるいは要件を満たす前にパージされる、という事故が起きます。転送・保持・パージはワンセットで設計してください。
よくある失敗
監査設計の失敗は、経験上ほぼ2方向に集約されます。
失敗1：全項目に監査を有効化して性能・容量を圧迫する
「監査は多いほど安全」という思い込みから、全フィールドでフィールド監査を有効化し、あらゆるセキュリティイベントを最大粒度で残すパターンです。結果として、監査レコードが業務量に比例して膨れ上がり、書き込み性能の低下・ストレージの肥大・パージ運用の破綻を招きます。特に高頻度更新プロパティへの監査は、体感できるレベルで書き込みを重くします。監査は「足し算」で設計する——要件が求めるものだけを1つずつ足すのが正解です。
失敗2：必要な who/when を残せずコンプライアンス要件を満たせない
失敗1の逆で、性能を気にするあまり監査を絞りすぎ、いざ監査対応や調査のときに「誰が・いつ変えたか」を答えられないパターンです。特にありがちなのが、セキュリティイベント（認証・構成変更）の設計を後回しにして、業務の History しか残していなかったケース。ログイン履歴やルール変更の証跡は業務データの監査とは別系統なので、意識して設計しないと丸ごと抜け落ちます。要件を満たせない監査は、量がどれだけ多くても価値がありません。
迷ったら要件表に戻る。「この要件は、どの系統の、どの証跡で満たすか」を1行ずつ埋めていけば、過不足のない監査設計に収束します。
まとめ
- 監査対象は規制・コンプライアンス要件から逆算する。 「念のため全部」は性能・容量を確実に圧迫する
- Pega の監査は3系統——フィールド監査（値の変遷）、ケース履歴（進行の証跡）、セキュリティイベントログ（認証・構成変更）。目的と記録先が異なる
- 業務証跡（フィールド監査＋ケース履歴）とセキュリティ証跡（イベントログ）は目的が別。 住み分けを最初に宣言する
- セキュリティイベントはSIEM へ外部転送し、改ざん耐性・保持期間・パージ／アーカイブ方針までワンセットで設計する
- 失敗は2方向だけ——かけ過ぎ（全項目有効化で性能圧迫）と絞りすぎ（who/when を残せず要件未達）
監査証跡は、平時には目立ちませんが、インシデント対応や監査対応という「最も困った瞬間」に価値が問われます。設計の初期に3系統の役割分担と要件からの逆算を固めておくことが、後からの手戻りと、いざというときの説明責任の欠落を防ぎます。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 連携の冪等性設計｜リトライで二重処理を起こさないための判断
「リトライしたら二重に登録された」——連携で最も痛い事故のひとつです。キュープロセッサやネットワークのリトライは基本 at-least-once で、重複実行は前提として設計すべきものです。本記事では、冪等キー・重複検知・副作用の分離といった手法で、何度呼ばれても安全な連携をどう組むかを整理します。
記事を読む