Pega データページの種類とスコープ設計｜Thread / Requestor / Node の使い分け
「なんとなく Thread スコープ」で作られたデータページが、外部連携の呼び出し回数を無駄に増やしていませんか。本記事ではデータページの種類（Read-Only / Editable / Savable）とスコープ（Thread / Requestor / Node）の組み合わせを、キャッシュ範囲・データ鮮度・再読み込みの観点から使い分ける判断軸を、LSA 目線で整理します。
結論から：種類とスコープの2軸で決める（Node スコープは Read-Only 専用）
Pega でデータページ（Data Page）を設計するとき、多くの現場が「なんとなく Thread スコープ」でページを量産し、結果として外部連携（REST や DB 参照）の呼び出し回数を無駄に増やしています。同じマスタデータを 1 日に何千回も取りに行っている、というのは珍しくありません。
結論を先に言うと、データページの挙動は次の2つの軸で決まります。
「種類」＝ Read-Only / Editable / Savable（そのページを読むだけか、編集するか、書き戻すか）と、「スコープ」＝ Thread / Requestor / Node（どこまで共有し、いつまで生きるか）。基本はこの2軸の組み合わせで共有範囲とライフサイクルが決まるが、1点だけ強い制約があり、Node スコープは Read-Only 専用（Editable / Savable は Node スコープに置けない）。
設計の順序としては、まずスコープを「データの鮮度」と「共有範囲」で決め、そのうえで種類を選びます。ただし1つだけ強い制約があります——Editable / Savable なデータページは Node スコープに置けません（Thread または Requestor のみ）。言い換えると、Node スコープは Read-Only 専用です。この制約が2軸の組み合わせに効いてくるので、まずはスコープ選択の判断フローから見ていきます。
データページの「種類」— Read-Only / Editable / Savable
まず1つ目の軸、種類を整理します。データページには大きく3つの種類があります。
- Read-Only（読み取り専用） — 一度ソースからロードしたら、そのページの内容はロード／リフレッシュ時以外は書き換えない前提。参照データ・マスタ・外部システムから取得した情報の「表示・参照」に使う、最も一般的な種類です。3つのスコープ（Thread / Requestor / Node）すべてを選べるのは、この種類だけです。
- Editable（編集可能） — ロードした内容をアプリケーション側で書き換えて保持する種類。ケース処理の中で一時的に組み立てる作業用データなどに使います。このタイプは Node スコープに置けません（Thread または Requestor スコープになります）。リフレッシュ戦略（再読み込み条件）は持てません。
- Savable（保存可能） — ページの内容を、定義した保存プラン（データベース保存やアクティビティなど）経由でソース側へ書き戻せる種類。UI からの明示的な保存や、コミット処理と組み合わせて使います。Editable と同様、Node スコープには置けません（Thread または Requestor のみ）。
ポイントは、大半のデータページは Read-Only で足りるということです。「後で値を1つ書き換えるかもしれない」という程度の理由で安易に Editable にすると、後述するスコープ選択の自由度（特に Node スコープ）を自ら狭めることになります。
データページの「スコープ」— Thread / Requestor / Node
2つ目の軸、スコープは「そのページのインスタンスを誰と共有し、いつまで保持するか」を決めます。
- Thread スコープ — 実行スレッド（1つのリクエスタスレッド、おおむね1件のケース処理コンテキスト）単位でインスタンスを持ちます。共有範囲が狭いぶん、参照するたびに比較的新しいデータが得られますが、そのぶんソースへの呼び出し回数は多くなります。
- Requestor スコープ — 1つのユーザーセッション（リクエスタ）単位でインスタンスを持ち、そのリクエスタの全スレッドから同じインスタンスを参照できます。Thread と Node の中間解にあたる位置づけです。
- Node スコープ — 同一ノード（サーバー）上でそのノード上の全リクエスタが1つのインスタンスを共有します。一度ロードすれば、そのノードの全ユーザーが同じインスタンスを参照するため、外部呼び出しを劇的に削減できます。反面、共有される1インスタンスの鮮度は「再読み込み条件」で管理する必要があります。
呼び出し回数と鮮度はトレードオフの関係にあります。Thread は最新に近いが重い、Node は軽いが鮮度管理が要る、Requestor はその中間、と覚えておくと選択が速くなります。
なぜ Editable / Savable は Node スコープに置けないのか
ここが設計者がつまずきやすい核心です。Editable / Savable なデータページは Node スコープを選べません（Thread または Requestor になります）。逆に言うと、Node スコープは Read-Only 専用です。
理由はスコープの共有モデルにあります。Node スコープは「1ノードの全リクエスタが同一インスタンスを共有する」仕組みです。もしこれを複数のユーザーが自由に編集できてしまうと、あるユーザーの書き換えが、無関係な別ユーザーの画面にそのまま影響してしまいます。複数リクエスタが1つのインスタンスを共有更新する、という状態は整合性を保てないため、Pega はこれを設計段階で禁止しています。
したがって、
- ノード全体で共有して更新したい → そもそもデータページの責務ではない（ケースや保存可能な仕組みで扱う）
- 共有して参照だけしたい → Read-Only の Node / Requestor スコープ
- 自分の処理の中だけで組み立てて書き換えたい → Editable の Thread スコープ（セッション内の複数スレッドで共有しつつ書き換えたいなら Editable の Requestor スコープ）
という切り分けになります。「ノード全体で共有したい」と「編集したい」は同時には成立しない（＝Node は Read-Only 専用）、と理解しておくと迷いません。なお Requestor スコープはセッション内の複数スレッド間で共有されますが、Editable / Savable も選べます——同時に成立しないのはあくまで Node（全リクエスタ共有）× 編集の組み合わせです。
スコープ選択の判断軸（比較表）
3つのスコープを、実装で効いてくる観点で並べます。
| 観点 | Thread | Requestor | Node |
|---|---|---|---|
| 共有範囲 | スレッド（1処理）単位 | ユーザーセッション単位 | ノード内の全リクエスタ |
| データ鮮度 | 高い（最新に近い） | 中（セッション内で保持） | 再読み込み条件に依存 |
| ソース呼び出し回数 | 多い | 中 | 少ない（大幅削減） |
| Editable / Savable の可否 | 可 | 可 | 不可（Read-Only 専用） |
| 向いているデータ | 都度最新が要る取引・状態 | セッション内で使い回す参照 | めったに変わらないマスタ |
| 主な注意点 | 呼び出し過多になりやすい | セッション跨ぎで共有されない | 鮮度（再読み込み）の設計 |
判断の型はシンプルです。 めったに変わらない参照データ（国コード、区分値マスタ、料率表など）で、全ユーザーが同じ内容を見てよいものは Node。取引ごと・画面ごとに最新が要るものは Thread。セッション内で何度も使うが、他ユーザーとは共有しなくてよい中間的なものは Requestor、という順で当てはめます。
多くの参照系プロジェクトでは、**「マスタ＝Node、トランザクション＝Thread」**を基本方針に置くだけで、無駄な外部呼び出しの大半を削減できます。外部連携の負荷や応答性が課題になっている場合、この見直しは Pega Platform 開発支援 の初期改善としても効果が大きい領域です。
再読み込み戦略とパラメータ化
Node スコープ（および Read-Only の Thread / Requestor スコープ）の鮮度を担保するのが再読み込み（reload）条件です。「一度ロードしたら永遠にそのまま」では、マスタが更新されても古い値を返し続けてしまいます。再読み込みは、代表的に次のような条件から選べます。
- 相互作用ごとに再読み込み — 1回のユーザー操作につき1度ロードし直す（＝最新志向）。この設定は Thread / Requestor スコープ向けで、Node スコープでは選べません。Node は次の時間ベースや条件ベースで鮮度を管理します。
- 一定時間が経過したら再読み込み（Reload if older than） — 前回ロードから指定時間を過ぎていたらロードし直す（マスタに最適。鮮度と呼び出し回数のバランスを取れる）
- 条件（When）が成立したら再読み込み（Do not reload when） — 指定した When 条件が false のときにロードし直す。特定の状態変化を検知したときだけ更新したい場合に使う
Node スコープのマスタは、「一定時間経過での再読み込み」を基本にすると、鮮度と負荷のバランスが取りやすくなります。更新頻度が1日1回のマスタなら、数時間単位の再読み込みで十分なことが多いはずです。
もう1つ重要なのがパラメータ化データページです。パラメータを取るデータページは、パラメータ値の組み合わせごとに別インスタンスとしてキャッシュされます（インスタンスの削除も、特定のパラメータ値を指定して個別に行えます）。たとえば「都道府県コードを受け取って市区町村一覧を返す」ページなら、都道府県ごとに別インスタンスが保持され、同じ都道府県の2回目以降はキャッシュから返せます。これによって「よく使うパラメータのぶんだけ」効率的にキャッシュが効きます。
スコープの内部挙動、再読み込みの詳細な設定項目、キーを指定したインスタンスアクセスなどの機能は、Pega のバージョンによって差があります。実装時は必ず対象環境の公式ドキュメントで挙動を確認してください。
よくある失敗
データページ設計の失敗は、経験上いくつかのパターンに集約されます。
失敗1：すべてを Thread スコープにする
最も多い失敗です。マスタのような「めったに変わらず全員が同じ内容を見てよいデータ」まで Thread スコープにすると、スレッドごと・参照ごとに外部呼び出しが発生し、連携先に不要な負荷をかけます。Node スコープ＋時間ベースの再読み込みにするだけで、呼び出し回数が桁違いに減るケースは珍しくありません。
失敗2：安易に Editable にしてスコープを狭める
「後で1項目だけ書き換えるかも」という理由で Editable にすると、そのページは Node スコープを選べなくなり（Thread か Requestor に限られる）、ノード全体で共有する強力なキャッシュ効果を得られなくなります。参照が主目的なら Read-Only を選び、書き換えが必要な一時データは別の作業用ページに切り出すのが定石です。
失敗3：Node スコープにしたのに再読み込みを設計しない
Node は「一度ロードしたら共有し続ける」仕組みなので、再読み込み条件を設計しないと古いマスタを返し続けるバグになります。しかもノード単位で共有されるため、「特定のノードだけ古い」という再現しづらい不具合として現れます。Node を選んだら、鮮度管理はセットで必ず設計します。
失敗4：パラメータ化を活かさず全件ロードする
本来パラメータで絞れるデータを、パラメータなしで全件ロードしてからアプリ側で絞り込むと、キャッシュ効率も転送量も悪化します。絞り込みキーはパラメータに渡し、パラメータ値ごとのキャッシュを効かせるのが正解です。
まとめ
- データページの挙動は種類（Read-Only / Editable / Savable）とスコープ（Thread / Requestor / Node）の2軸で決まる（ただし Node スコープだけは Read-Only 専用という制約がある）
- Editable / Savable は Node スコープに置けない（Thread または Requestor のみ）。Node スコープは Read-Only 専用で、複数リクエスタが Node の1インスタンスを共有更新することはできない
- スコープは鮮度と共有範囲と呼び出し回数のトレードオフ。マスタは Node、都度最新が要るものは Thread、中間は Requestor
- Node を選んだら再読み込み条件（特に時間ベース）はセットで設計する。パラメータ化データページはパラメータの組み合わせごとにキャッシュされる
- 「なんとなく Thread」をやめ、マスタ＝Node、トランザクション＝Threadを基本方針にするだけで、外部連携の呼び出しは大きく減らせる
データページのスコープ設計は、アプリケーションの応答性と連携先への負荷を直接左右します。設計の初期に「このデータは誰と共有し、どのくらい古くてよいか」を言語化しておくことが、後工程での性能問題を未然に防ぎます。
関連リンク
関連記事
Pega DX API で独自フロントを作る判断｜標準 Constellation UI との使い分け
Constellation は DX API 経由で UI メタデータを受け取りクライアントで描画する。この API は独自フロントの構築にも開放されているが、わずかな見た目調整のために独自フロントへ踏み込むと保守とアップグレードの負担が跳ね上がる。どこまで OOTB で、どこから DX API か——設計判断の分岐点を扱う。
記事を読むPega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読むPega 親子ケース設計｜子ケースに分割すべきかの判断基準と失敗例
業務を子ケースに切り出すべきか、それとも親ケースのステージ/ステップに収めるべきか。判断を誤ると、独立追跡できずに再設計になったり、逆にケースインスタンスが増えすぎて運用とレポートが破綻したりする。この記事では、親子ケースに分割する境界線を「独立したライフサイクルを持つか」を軸に、待ち合わせ(依存)設計まで含めて解説する。
記事を読む