Pega が本番で遅い時の調べ方｜性能トラブル切り分けの実践手順
Pega の本番性能トラブルを切り分ける実践手順を解説。測定による事実化から、画面・サーバ・DB・連携の切り分け、典型原因の確認順序を整理します。
結論から：「体感の遅さ」を測定で事実に変えてから、層を外側から順に切り分ける
本番運用が始まると、「Pega が遅い」という申告は必ず一度は受け取ります。このとき最もやってはいけないのが、感覚で当たりを付けていきなりチューニングを始めることです。結論から言うと、調査の手順は次の 3 ステップに固定します。
① 事象の定量化（どの画面・どの操作・どの時間帯・全員か特定ユーザーか）→ ② 測定（ブラウザ開発者ツール／Performance ツール／PDC）→ ③ 層の切り分け（クライアント／ネットワーク／アプリケーション／DB／外部連携）
「遅い」は主観です。主観のまま調査を始めると、調べる場所も直す場所も運任せになります。逆に、この 3 ステップで「どの操作が・どの層で・何秒失っているか」まで事実化できれば、原因の大半は本記事の後半に挙げる 5 つの典型パターンのどれかに収束します。
手順①：事象の定量化 —「遅い」を再現条件に変える
最初にやるのは調査ではなくヒアリングです。次の 4 点を必ず特定します。
- どの画面・どの操作か（ログイン？ 検索ボタン押下？ ケースを開く操作？）
- どの時間帯か（終日か、始業直後や月末だけか）
- 全員か、特定のユーザー・拠点だけか
- いつから遅いか（直近のリリースやデータ量の増加と突き合わせる）
この 4 点の組み合わせだけで、疑うべき方向はかなり絞れます。
| 事象のパターン | まず疑う方向 |
|---|---|
| 特定の画面・操作だけ遅い | その画面のデータ取得（データページ・リスト取得・宣言的ルール） |
| 特定の時間帯だけ遅い | 同時アクセスの集中・バッチ処理との競合・外部システム側の負荷 |
| 特定のユーザー・拠点だけ遅い | そのユーザーの担当データ量・アクセス権の構成・端末や拠点の回線 |
| 全画面・全ユーザーで遅い | 基盤リソース（ノード・DB）・直近のデプロイ・共有キャッシュ |
例えば「午前 9 時台だけ全員遅い」なら始業直後の同時ログイン集中や夜間バッチの残りを疑いますし、「あの部署の人だけ遅い」なら担当データ量や拠点の VPN を疑います。事象の輪郭が曖昧なまま先へ進むと、後の測定で「いつ・何を測ればいいか」が決まりません。
手順②：測定 — 3 つの道具で数字を取る
ブラウザ開発者ツール：クライアントとサーバを大別する
最初の測定はブラウザの開発者ツール（F12）の Network タブで十分です。該当操作を再現し、リクエストのウォーターフォールを見ます。
- サーバの応答待ち（TTFB）が大半 → 原因はサーバ側。手順③でサーバ内を分解する
- ダウンロードや描画に時間がかかっている → クライアント／ネットワーク側。画面部品の過多、静的資産のサイズ、拠点回線・VPN を調べる
この 1 回の測定で、調査対象が半分に絞れます。冒頭の図の分岐がまさにこれです。
Performance ツール：サーバ内の時間の使い道を見る
サーバ側と分かったら、Dev Studio の Performance ツール（PAL：Performance Analyzer）で、要求ごとの経過時間・ルール実行時間・DB アクセス時間などの統計を取ります。さらに深掘りが必要なら、Tracer（個別セッションのルール実行を追跡）や DB Trace（実際に発行された SQL とその所要時間を確認）を使います。これらは測定自体に負荷がかかるため、本番での常時有効化は避け、再現環境または時間を限定して使うのが原則です。特に DB Trace は、公式ドキュメントでも出力が大量になり性能に影響するため、デバッグ用環境で短時間・最小限のオプションに絞って使うことが推奨されています。
PDC とアラートログ：しきい値超過を自動で拾う
Pega Platform は、性能上問題になりうる事象をしきい値付きのアラートとして記録します。代表的なものは次のとおりです。
- PEGA0001 — HTTP 要求（インタラクション）の処理時間の超過
- PEGA0005 — DB クエリ実行時間の超過
- PEGA0004 — DB クエリで取得したデータ量（バイト数）の超過
- PEGA0020 — 外部連携（コネクタ）の合計応答時間の超過
**PDC（Pega Diagnostic Center、旧称 Pega Predictive Diagnostic Cloud）**はこれらのアラートやシステムの健全性情報を収集・集計し、傾向をダッシュボードで示してくれる監視サービスです。Pega Cloud 環境は標準で PDC にデータを送るよう構成されており、追加構築なしで利用を始められます。「ユーザーが騒ぐ前にアラートの増加傾向で気づく」のが理想の運用です。
注： ツールの名称・メニュー位置・アラートの既定しきい値は Pega Platform のバージョンによって異なります（PDC のように製品名自体が改称された例もあります）。適用の際は、お使いのバージョンの公式ドキュメント（Pega Docs）で必ず確認してください。
手順③：層の切り分け — どこで時間を失っているか
測定結果を、次の 5 層のどこに時間が乗っているかで整理します。
| 層 | 主な手がかり | 代表的な原因 |
|---|---|---|
| クライアント | TTFB は短いのに表示完了が遅い | 画面部品の過多・重い描画・端末性能 |
| ネットワーク | 特定拠点のみ遅い・ダウンロードが遅い | 拠点回線・VPN・プロキシ |
| アプリケーション | サーバ時間の大半がルール実行 | データページの同期ロード・宣言的ルールの連鎖 |
| DB | PEGA0005/0004 が出る・DB 時間が支配的 | インデックス不足・リストの全件取得 |
| 外部連携 | PEGA0020 が出る・コネクタ待ちが支配的 | 外部 API の応答遅延・タイムアウト設計不備 |
層が特定できたら、あとは各層の典型原因を順に確認するだけです。
典型原因トップ 5 と対処の方向
実案件で遭遇する性能問題の多くは、次の 5 パターンに収束します。
1. 重いデータページを同期ロードしている
画面表示と同時に、その画面ではすぐに使わないデータまで同期で読み込んでいるケースです。ユーザーは「画面を開くだけで待たされる」と感じます。対処は、読み込みタイミングの見直し（本当にその瞬間に必要か、非同期ロードにできないか）と、キャッシュの範囲（スコープ）・リフレッシュ戦略の再設計です。同じデータを要求のたびに取り直していないかも確認します。
2. リストを全件取得している
検証環境の数百件では快適でも、本番の数十万件で破綻する典型パターンです。取得後に画面側で絞り込むのではなく、フィルタとページングをデータ取得側（ソース側）に押し込むのが原則です。PEGA0004（取得データ量の超過）が出ていたら真っ先に疑います。
3. 宣言的ルールが連鎖している
プロパティ変更のたびに宣言的な再計算（前方連鎖）が走り、計算ネットワークが大量のプロパティや大量の行に及ぶと、入力のたびに待ちが発生します。「入力するたびに引っかかる」という申告はこのパターンのことが多いです。依存関係を整理し、本当に即時再計算が必要か、計算のタイミング（前方連鎖か、参照時計算か）を見直します。
4. DB インデックスが足りない
レポートや検索の条件に使う列に索引がなく、データ量の増加とともに徐々に遅くなるパターンです。「最近だんだん遅くなってきた」という申告と PEGA0005 が手がかりになります。DB Trace で実際に発行されている SQL を確認し、実行計画と突き合わせて索引を設計します。
5. 外部 API を同期で待っている
連携先システムの応答が遅いと、Pega 側の画面も巻き込まれて止まります。PEGA0020 の増加が典型的なシグナルです。対処は、タイムアウトの適切な設計、業務上許されるなら非同期化・キュー化、そして遅延時に画面側をどう振る舞わせるかの設計です。連携先の性能は自分たちで直せないからこそ、「待ち方」を設計しておく必要があります。
よくある失敗
失敗 1：測定せずに「当てずっぽうチューニング」を始める
キャッシュを足す、ノードを増やす、といった対処を測定なしで行うパターンです。たまたま改善しても原因は不明のままなので、高い確率で再発します。「測定 → 特定 → 対処 → 再測定」のループを崩さないことが、結局いちばんの近道です。
失敗 2：検証環境で「再現しない」と結論づける
性能問題の多くはデータ量と同時アクセスに依存します。数百件のデータしかない検証環境で再現しないのは当然で、それは「問題がない」ことを意味しません。本番相当のデータ量で検証するか、それが難しければ本番の測定データ（PDC・アラートログ）を一次情報として扱います。
失敗 3：直して終わりにする
データは増え続け、機能は追加され続けるので、性能問題は必ず再発します。1 回の対処で終わらせると、数か月後に同じ申告を受け、また一から調査することになります。対処のたびに「次は自動で気づける仕組み」を残すのが運用の腕の見せどころです。
まとめ：場当たり対応で終わらせず、監視と性能予算をセットで入れる
- 「遅い」の申告は ① 定量化 → ② 測定 → ③ 層の切り分け の順で事実化してから手を付ける
- 測定はブラウザ開発者ツール（クライアント／サーバの大別）→ Performance ツール（サーバ内の内訳）→ PDC・アラートログ（しきい値超過の自動検出）の 3 点セット
- 原因の多くは 5 つの典型（同期ロード・全件取得・宣言的ルールの連鎖・インデックス不足・外部 API 待ち）に収束する
- 対処したら、PDC による定常監視と性能予算（主要画面の応答は○秒以内、対象アラートは週○件以内、といった数値基準）を運用・リリース判定に組み込み、劣化の兆候に自動で気づける状態にする
トラブルシュート手順を持っているチームと持っていないチームの差は、障害対応の速さだけでなく、「性能が劣化し始めた兆候に気づけるか」に表れます。
Pega の性能改善・本番運用でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。実案件での性能トラブル対応の経験をもとに、測定から恒久対策・監視設計までご支援します。
関連リンク
関連記事
Pega データページの種類とスコープ設計｜Thread / Requestor / Node の使い分け
「なんとなく Thread スコープ」で作られたデータページが、外部連携の呼び出し回数を無駄に増やしていませんか。本記事ではデータページの種類（Read-Only / Editable / Savable）とスコープ（Thread / Requestor / Node）の組み合わせを、キャッシュ範囲・データ鮮度・再読み込みの観点から使い分ける判断軸を、LSA 目線で整理します。
記事を読むPega DX API で独自フロントを作る判断｜標準 Constellation UI との使い分け
Constellation は DX API 経由で UI メタデータを受け取りクライアントで描画する。この API は独自フロントの構築にも開放されているが、わずかな見た目調整のために独自フロントへ踏み込むと保守とアップグレードの負担が跳ね上がる。どこまで OOTB で、どこから DX API か——設計判断の分岐点を扱う。
記事を読むPega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読む