Pegaのテーブル肥大化対策｜アーカイブとパージの設計判断
作業テーブルや履歴テーブルは黙っていても増え続け、クエリ性能を蝕む。消してよいデータと退避すべきデータをどう切り分け、保持ポリシーと参照整合性をどう守るか。アーカイブ/パージ設計のよくある失敗と回避策を整理する。
結論から：まず「消してよいデータか、退避すべきか」を切り分ける
Pega アプリケーションを本番で運用していると、作業テーブルや履歴テーブルは、こちらが何もしなくても増え続けます。放置すればクエリが遅くなり、ストレージコストが膨らみ、やがてバックアップやインデックス再構築の時間まで蝕まれます。これは設計の巧拙とは別に、時間の経過そのものが生む負債です。
対策の入り口は、機能の話ではなく分類の話です。結論を先に言います。
保持期間が切れて処理対象になった古いデータを、まず「消してよいデータ」か「退避すべきデータ」かに切り分ける。監査・法的保持や後続参照が要るなら退避（アーカイブ）、どちらも要らないなら物理削除（パージ）。そして、いずれの場合も参照整合性を壊さない順序で実行する。
「とりあえず消せば軽くなる」と考えて先に削除に走ると、後から監査要件や参照整合性で足をすくわれます。逆に「消すのが怖いから全部残す」と退避一辺倒にすると、コールドストレージが第2の肥大化を起こします。本記事では、この切り分けを具体的な判断分岐に落とし込みます。
なぜテーブルは肥大化するのか
肥大化を「一部の設計ミス」だと思っていると対策を打ち損ねます。実際には、Pega の中核機能が動くだけで増える領域が複数あります。代表的なものを挙げます。
- ケースの作業テーブル — ケースが完了しても、レコードはそのまま残り続けます。日々発生するケースがそのまま蓄積します
- 履歴テーブル — ステージ遷移、フィールド変更、監査証跡など、1 ケースあたり何十行もの履歴が生成されます。本体より履歴のほうが速く増えることも珍しくありません
- アサインメント — 完了したアサインメントが残るケースがあり、担当者ビューやワークリストのクエリを重くします
- 宣言的インデックス（Declare Index） — 埋め込みページや集約をレポート可能にするために生成される派生行で、対象データが多いほど膨らみます
- 全文検索のキュー・索引 — 検索インデックス更新のためのキューやログが溜まります
これらは「ゴミ」ではなく、業務が回っている証拠として正しく増えていきます。問題は、増えることではなく放置することです。ホットな作業テーブルに古い完了ケースが何百万件も同居していると、日常のクエリが不要な行を舐め、性能が徐々に劣化します。ストレージ費用、バックアップ時間、DR の複雑さもすべてこの行数に比例します。
パージとアーカイブは何が違うのか
対策には大きく 2 つの手段があります。両者は「軽くする」という目的は同じでも、性質はまったく違います。
- パージ（物理削除） — 対象レコードをデータベースから物理的に消す操作です。テーブルは確実に軽くなりますが、不可逆です。消したデータは、退避していない限り戻りません
- アーカイブ（退避） — ホットなデータベースから、コールドストレージやリポジトリなどの別の保管先へ退避する操作です。本番テーブルからは消えて軽くなりますが、データ自体は保管先に残り、必要時に取り出せます
つまり選択は「軽くするかどうか」ではなく、「軽くしたうえで、そのデータを手放すか、別の場所に持っておくか」です。手放してよいならパージ、持っておく必要があるならアーカイブ、という関係になります。
Pega の標準機能との対応： Pega Platform には、解決済みケースをセカンダリのファイルストレージ／リポジトリへ退避するケースのアーカイブ（archival）と、アーカイブ済みデータを恒久的に物理削除するエクスパンジ（expunge）があり、保持期間を定めたアーカイブポリシー（リテンションポリシー）に従って動きます（ケース本体だけでなく、関連する履歴・添付・アサインメントもジョブスケジューラで整理できます）。本記事の「アーカイブ」「パージ（物理削除）」は、この考え方を一般化した呼び方です。機能の有無・手順・対応クラス・既定値は Pega のバージョンやエディションによって異なり（旧来の Purge/Archive ウィザードから、アーカイブ＋エクスパンジ方式へ刷新されています）、実装時は採用しているバージョンの公式ドキュメントで確認してください。
判断の3軸
パージかアーカイブかは、次の 3 軸で決めます。上の図はこの軸を分岐にしたものです。
軸1：監査・法的保持（リーガルホールド）が要るか
そのデータを、規制・契約・社内統制のために一定期間残す義務があるか。金融・医療・公共など、取引記録や意思決定の証跡を数年単位で保持しなければならない業種は多く、訴訟や調査に備えたリーガルホールドが掛かっているデータは、期間内は削除してはいけません。
- 保持義務がある → アーカイブ（本番からは退避しつつ、保管先で保持）
- 保持義務がない → 次の軸へ
軸2：あとで参照・復元する可能性があるか
法的義務はなくても、業務上「後から見たくなる」「戻したくなる」データがあります。過去案件の照会、分析・レポートの再集計、誤操作時の復旧などです。
- 参照・復元の可能性がある → アーカイブ
- 純粋にもう使わない（一時的な中間データ、期限切れの短命データなど） → パージの候補
軸3：参照整合性を壊さないか
ここが最も事故につながる軸です。Pega のデータは孤立していません。親子ケース、添付、履歴、宣言的インデックスは互いに依存しています。子ケースを残したまま親を消す、履歴の参照先の本体を消す、といった操作は、参照先を失った「宙に浮いた」データを生みます。
- パージ／アーカイブとも、依存関係の末端から順に処理し、親子・添付・履歴の整合性を保つ
- 依存を壊す順序でしか消せないなら、そもそも対象の切り出し方が間違っている
軸1・軸2で「アーカイブかパージか」が決まり、軸3が「どう実行するか」の制約を与える、という関係で捉えると整理しやすくなります。
判断早見表
| 観点 | パージ（物理削除） | アーカイブ（退避） |
|---|---|---|
| 何をするか | DB から物理削除 | コールドストレージ／リポジトリへ退避 |
| 可逆性 | 不可逆（退避なしなら復元不可） | 保管先から復元可能 |
| 監査・法的保持 | 保持義務がないデータ向け | 保持義務があるデータ向け |
| 後続参照・復元 | 想定しない | 想定する |
| 本番テーブルの軽量化 | される | される |
| 総保管コスト | 最小（データが消える） | ホットより安いコールド費用が残る |
| 向いている対象 | 一時・短命・再利用しない中間データ | 完了ケース、監査対象の履歴 |
上2軸（監査・法的保持／後続参照）のどちらかが「要る」ならアーカイブ、どちらも「不要」ならパージ ——これが実務での判断の型です。そして、どちらを選んでも軸3（参照整合性）の制約は常に効きます。
保持ポリシー（リテンション）をどう設計するか
パージもアーカイブも、その場の思いつきで単発実行するものではありません。「いつ、何を、どこへ」を定めた保持ポリシー（リテンション）を先に決め、定期処理で回すのが正攻法です。
- 単位はクラス／ケースタイプ — 保持期間はデータの種類ごとに違います。「申込ケースは完了後7年」「一時的な照会ケースは完了後90日」のように、クラスやケースタイプ単位で保持期間を定義します
- 期間はビジネス要件と規制から逆算する — 「なんとなく1年」ではなく、法定保存年数・契約上の保持義務・分析で遡りたい期間から逆算して決めます。ここを曖昧にすると、後から「もっと残すべきだった／こんなに残す必要はなかった」の両方が起きます
- 期限切れを定期処理で扱う — 保持期間を過ぎたレコードを定期バッチで抽出し、ポリシーに従ってアーカイブまたはパージします。日次・週次など、業務量と負荷を見て頻度を決めます
- ポリシーは文書化して合意する — 「どのデータを何年保持し、期限切れをどう処理するか」は、開発チームだけでなく業務・法務・監査部門と合意すべき事項です。実装より先に合意を取ります
保持ポリシーが定まっていれば、パージ／アーカイブは「ポリシーの実行」に過ぎなくなります。逆にポリシーなしで削除を始めると、判断が属人化し、事故の温床になります。
運用設計：削除は不可逆という前提で組む
保持ポリシーが決まったら、実行の運用設計です。削除は不可逆という一点を常に念頭に置いて、次を必ず設計します。
- バッチサイズ — 一度に数百万行を消そうとすると、長時間のロックやトランザクション肥大を招きます。適切な件数に分割し、コミットを刻みながら処理します
- 実行時間帯 — 本番の業務ピークを避け、負荷の低い時間帯に走らせます。バックアップ・バッチ・レポート生成など、他の重い処理との競合も避けます
- ロック競合 — 処理対象のケースが業務側で開かれていると、ロック競合で失敗します。稼働中のケースを対象にしない、リトライ・スキップの方針を決める、といった設計が要ります
- 復元手段（元に戻す道） — パージであっても、いきなり本削除にせず「先にアーカイブ（退避）してから消す」構成にできれば、退避先からの復元という保険が残ります。復元手順を実際に検証しておくことまで含めて運用設計です
- べき等に組む — 途中で失敗しても、再実行で二重削除や取りこぼしが起きないよう、対象抽出・処理・記録をべき等に設計します
これらを飛ばして「対象を SELECT して DELETE」を手で流すのは、最も危険なパターンです。定期実行・監視・失敗時の挙動まで含めた運用として組むべきで、CI/CD やデプロイ運用の仕組みに乗せて管理するのが望ましい領域です。
よくある失敗
肥大化対策の失敗は、経験上いくつかの型に収まります。
失敗1：肥大化してから慌てて消す
性能問題が顕在化してから初めて手を打つパターンです。すでにテーブルは巨大で、一括削除は長時間ロックと膨大なトランザクションを生み、それ自体が新たな障害になります。保持ポリシーは運用開始と同時に設計し、小さいうちから定期的に回すのが正解です。肥大化は予測できる負債なので、事後対応ではなく事前設計で潰します。
失敗2：参照整合性を無視して消す
親を残して子を消す、履歴の参照先本体を消す、添付の実体だけ消してメタデータを残す——依存関係を無視した削除は、宙に浮いたデータやエラーを生みます。依存の末端から順に処理する設計を、対象の切り出し時点で織り込んでおく必要があります。
失敗3：監査・法的保持を確認せずにパージする
「もう完了案件だから消してよい」と判断した後で、実は法定保存年数の途中だった、リーガルホールドが掛かっていた、というケースです。削除は不可逆なので、これは取り返しがつきません。パージの前に、必ず保持義務の有無を確認する分岐を入れます。
失敗4：全部アーカイブして第2の肥大化を招く
削除が怖いあまり、何でもアーカイブに退避するパターンです。コールドストレージは本番より安いとはいえ無料ではなく、退避先が際限なく膨らめば、そこでコストと管理負担が再燃します。本当に消してよいデータはパージするという判断を放棄しないことも、立派な設計です。
まとめ
- 作業・履歴・アサインメント・宣言的インデックス・検索キューは、業務が回るだけで肥大化する。放置は予測可能な負債
- 対策の入り口は「消してよいデータか、退避すべきか」の切り分け。監査・法的保持や後続参照が要るならアーカイブ、どちらも不要ならパージ
- 参照整合性（親子・添付・履歴の依存）を壊さない順序で実行する。これはパージでもアーカイブでも常に効く制約
- 保持ポリシーをクラス／ケースタイプ単位で先に定義し、規制・業務要件から逆算した保持期間を定期処理で回す
- 削除は不可逆。バッチサイズ・実行時間帯・ロック競合・復元手段・べき等性まで運用として設計する
- アーカイブ機能の有無・手順は採用バージョンに依存するため、実装は使える機能を前提に組む
肥大化対策は、派手さのない領域ですが、性能・コスト・監査対応の土台を支えます。運用が始まってから慌てるのではなく、設計段階で保持ポリシーと実行運用を決めておくことが、数年後の大きな手戻りとリスクを防ぎます。
関連リンク
関連記事
Pega GenAI Blueprint の使いどころ｜AI 生成設計をどこまで信頼し上書きするか
AI が数分で設計案を出す時代に、LSA の仕事は「ゼロから描く」から「生成案を評価し、どこを残しどこを直すか判断する」へ移る。Pega GenAI Blueprint の出力を鵜呑みにする危険と、設計判断として押さえるべき観点を整理する。
記事を読むPegaUnit とシナリオテストの使い分け｜Pega テスト戦略とCI組み込みの設計
テストを全部シナリオテストで書いたら、UI を少し直すたびに真っ赤になった——Pega に限らず起こる典型です。本記事では、PegaUnit とシナリオテストをどの層にどれだけ配置し、CI にどう組み込むかを、LSA視点の設計判断として整理します。
記事を読むPega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読む