Pega 権限設計：Access Group と Role の多層モデルと肥大化回避

結論から：新しい権限は「まず Role、次に条件」。Access Group は安易に増やさない

Pega で権限設計をしていると、「この人たちに新しい権限を与えたい」という要望が繰り返し発生します。そのたびに Access Group を新しく作るのか、それとも Role を足すのか を迷い、深く考えずに「部門ごとに Access Group をコピーして少しずつ変える」という運用に流れてしまう——これが後で必ず破綻する典型パターンです。

結論を先に言います。

新しい権限が必要になったら、まず「再利用可能な Role を足す／合成する」で対応する。行やレコード単位の見え方の違いは Role を増やすのではなく条件（Access When／アクセス制御ポリシー）で吸収する。Access Group を新設するのは「新しいペルソナ × アプリ文脈」が本当に登場したときだけに限定する。

Access Group は「増やしやすい」がゆえに、部門・拠点・役職の掛け算で爆発します。増えた Access Group は組織変更のたびに全数メンテナンスが必要になり、誰がどの権限を持っているのかが追えなくなります。本記事では、Pega の権限が積み重なる多層モデルを正確に押さえたうえで、この分岐をどう判断するかを整理します。

Pega の権限は多層になっている

判断を誤らないために、まず Pega のアクセス制御が何層にも積み重なっていることを正確に押さえます。権限は次の順に絞り込まれていきます。

• Operator（オペレーター ID） — 個々のユーザー。ログインする主体で、1 つの Access Group に紐づいて動作します（複数所属できても、ある時点でアクティブなのは 1 つです）。
• Access Group（アクセスグループ） — オペレーターに対して「どのアプリケーション（バージョン）を・どのポータルで・どのロール群で使うか」を束ねる文脈。既定のワークプール（ワークグループ）もここで決まります。ペルソナ × アプリ文脈の単位です。
• Access Role Name（アクセスロール） — 再利用可能な権限バンドルの名前。1 つの Access Group に複数のロールを割り当てられ、権限は合成されます。
• ARO（Access of Role to Object） — ロールとクラス（オブジェクト）を結びつけ、そのクラスに対するアクセスレベル（参照・更新・削除・オープンなど）を定義するルール。実際の「見える・触れる」はここで決まります。
• Privilege（プリビレッジ） — さらに細かい名前付きの権限。特定のフローアクションやアクティビティ、レポートなどが「この Privilege を持つ人だけ実行可」と要求し、ARO がロールにその Privilege を付与します。

つまり、あるオペレーターがある操作をできるかどうかは、Operator → Access Group → Role → ARO → Privilege という多層 RBAC を順にたどって決まります。この分業を理解していないと、「権限を足したいだけなのに Access Group を丸ごと増やす」という過剰な対応をしてしまいます。

Access Group と Role の役割はまったく違う

同じ「権限まわり」でも、Access Group と Role は担っている責務が別物です。ここが設計の核心です。

• Access Group = ペルソナ × アプリ文脈の束。 「営業担当としてこのアプリをこのポータルで使う」という利用文脈を表します。アプリケーション／バージョン、ポータル、既定のワークプール（ワークグループ）といった「その人がどんな入口でシステムに入るか」をまとめます。
• Access Role = 再利用可能な権限バンドル。 「案件を承認できる」「マスタを編集できる」といった権限のかたまりに名前を付けたもの。Access Group に依存せず、複数の Access Group から使い回せます。

言い換えると、Access Group は「誰が・どの入口で」を、Role は「何ができるか」を担当します。新しい権限が欲しいときに触るべきなのは、原則として後者です。ポータルもアプリ文脈も変わらないのに Access Group を増やすのは、本来 Role で足りる話を重い単位で解決していることになります。

分岐：Access Group を増やすか、Role を足すか

冒頭の図が示すとおり、判断は 3 つの問いで機械的に下せます。

① 新しいペルソナ・アプリ文脈が登場したか

別のポータルを使う、別のアプリケーション（またはバージョン）を割り当てる、別のペルソナとしてシステムに入る——このように利用文脈そのものが変わるなら、Access Group を新設します。これは「文脈が変わったのだから箱も分ける」という正当な理由です。逆に言えば、Access Group を増やす理由はこれくらいに限定すべきです。

② 既存ペルソナに権限を足す・減らすだけか

同じポータル・同じアプリを使う人たちに「承認権限を追加したい」「この機能だけ許可したい」なら、対応は Role を足す（または合成する） です。承認用のロール、参照専用のロール、マスタ編集用のロール……と権限をバンドル単位で切り出しておけば、Access Group にそのロールを追加するだけで済みます。Access Group は増えません。

③ 同じ役割で、行・レコードの見え方だけ変えたいか

「同じ営業ロールだが、自分の担当拠点の案件しか見せたくない」のように、権限の種類は同じでレコードの見える範囲だけが違うケースがあります。ここで拠点ごとにロールや Access Group を量産するのは最悪手です。これは 条件付き ARO（Access When 条件） で制御します。さらに厳密な項目単位・1 件単位の見せ分けが必要なら、属性ベースの制御（ABAC）に寄せます。詳しくは Pega の ABAC でフィールド単位のアクセス制御を実現する を参照してください。

部門ごとに Access Group を複製すると破綻する

現場で最もよく見る失敗が、部門・拠点・役職の掛け算で Access Group を複製する設計です。「東京営業」「大阪営業」「名古屋営業」……と Access Group をコピーし、それぞれ中身をほんの少しだけ変えて運用する。最初は動きます。破綻するのは組織変更のときです。

• 拠点が 1 つ増えるたびに Access Group を 1 つ作る必要がある
• 「営業全員に新権限を配る」ような横断変更が、全 Access Group への一括修正になる
• どの Access Group が何を持っているのか、差分が人間には追えなくなる
• 同じような ARO・Privilege 割り当てがコピーで散らばり、修正漏れが発生する

正しい設計は、権限をロールに正規化し、レコードの見え方の違いは条件で吸収することです。営業という役割は 1 つのロール群で表現し、拠点による見え方の違いは Access When 条件（ABAC）で制御します。こうすれば、拠点が増えても Access Group もロールも増えません。増えるのは、せいぜい条件が参照する「拠点」というデータだけです。組織構造をロール階層に写し取ろうとしない——これが肥大化回避の要諦です。

判断早見表

要望の性質	使うべき手段	増やすもの
別ポータル・別アプリ（バージョン）で使わせる	Access Group を新設	Access Group（例外的に）
既存ペルソナに権限のかたまりを足す／減らす	Role を足す・合成する	Access Role（推奨・既定）
特定機能・特定アクションだけ許可／不許可	Privilege を切り、ARO で付与	Privilege
同じ役割でレコードの見える範囲だけ変える	条件付き ARO（Access When）	条件（データ）のみ
項目単位・1 件単位の厳密な見せ分け	ABAC（アクセス制御ポリシー）	ポリシー条件

原則は「下の行ほど軽い手段で、上の行（Access Group 新設）は最終手段」です。要望を聞いたら、まずこの表の下から順に「これで足りないか？」と当てていくと、無用な Access Group の増殖を防げます。

よくある失敗

失敗1：Privilege を使わず ARO のアクセスレベルだけで粗く制御する

ARO のアクセスレベル（参照・更新など）だけでコントロールしようとすると、「このクラスは触れる／触れない」の粗い粒度でしか制御できません。「同じ画面の中で、この操作だけは特定ロールに限定したい」といった要件に応えられず、結局ロールや Access Group を増やして回避する羽目になります。アクションやフローアクション単位の制御は Privilege を切って ARO で付与するのが正解です。Privilege を使いこなせるかどうかが、ロール爆発を防げるかどうかの分かれ目になります。

失敗2：既定ロールに過剰な権限を残す

開発初期の便宜で管理者相当の既定ロール（フルアクセスに近いロール）を広く割り当てたまま本番に持ち込む、というアンチパターンです。最小権限の原則に反し、監査でも指摘されます。ロールは「必要な権限だけを束ねたもの」を業務単位で用意し、既定ロールに寄りかからないようにします。

失敗3：ポータル割り当てと権限割り当てを混同する

「ポータルを与えた＝権限を与えた」と誤解するケースです。ポータルは Access Group が決める入口・見た目であり、実際に何ができるかは Role → ARO → Privilege が決めます。ポータルだけ差し替えても権限は変わらず、逆に権限を足してもポータルに導線がなければユーザーは使えません。「どの入口か（Access Group）」と「何ができるか（Role 以下）」を常に分けて考えることが、設計の混乱を防ぎます。

設計時の注意点（バージョン依存）

最後に、実装時に確認すべき版依存の論点を挙げます。ここは「一般論として覚える」より「利用中のバージョンの公式ドキュメントで確かめる」べき領域です。

• ライセンス消費は Access Group 単位ではなく「ユーザー分類」で測られる。 Pega のライセンスコンプライアンス機能は、認証済みリクエスターの特性から Named ユーザー／Invocation ユーザーといった分類で使用量を集計します。Access Group フォームに「ライセンスタイプ」を選ぶ項目はなく、Access Group が束ねるのはアプリケーション・ポータル・ロール・既定ワークプールです。したがって「Access Group を増やすとライセンス管理が複雑になる」ことを複製回避の根拠にはできません。複製を避ける本当の理由は前節までに述べた保守・監査コストの方です（使用量の分類定義は版・契約により異なるため、詳細は利用中バージョンの公式ライセンスコンプライアンス機能で確認してください）。
• 依存ロール（ロール階層）の挙動は版により異なる。 ロール同士に依存・継承関係を持たせる仕組み（あるロールが別ロールの権限を引き継ぐ）は、バージョンによって設定方法や解決順序が異なります。階層に頼った設計をするなら、実機での挙動確認が必須です。
• Access Manager などの管理 UI も版で変わる。 ロールや権限をまとめて管理する UI は Pega のバージョンで見た目も機能も変化します。ドキュメントのスクリーンショットを鵜呑みにせず、対象環境の UI で確認してください。

まとめ

• Pega の権限は Operator → Access Group → Role → ARO → Privilege の多層 RBAC。まずこの分業を正確に押さえる
• Access Group = ペルソナ × アプリ文脈、Role = 再利用可能な権限バンドル。担う責務がまったく違う
• 新しい権限が要るときの既定は Role を足す・合成する。Access Group の新設は「新しいペルソナ・アプリ文脈」が登場したときだけの例外に限定する
• レコードの見え方の違いはロールを増やさず条件（Access When／ABAC）で吸収する。部門ごとの Access Group 複製は組織変更で必ず破綻する
• よくある失敗は「Privilege を使わない粗い制御」「既定ロールに過剰権限」「ポータルと権限の混同」の 3 つ

権限設計は、初期に型を決めておかないと後から必ず肥大化し、監査・組織変更・保守のすべてでコストを払うことになります。逆に、この多層モデルと分岐の型をチームで共有しておけば、要望が来るたびに機械的に「Role で足りるか？」を判断でき、Access Group もロールも増えない健全な状態を保てます。

Pega の権限・セキュリティ設計でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、アクセス制御の設計からご支援します。

関連リンク

• Pega Platform 開発支援
• Pega の ABAC でフィールド単位のアクセス制御を実現する
• Pega DevOps 導入支援
• Pega 認証設計：SAML SSO と OAuth 2.0 の使い分けと落とし穴
• Pega 連携は同期か非同期か｜コネクタ直呼びとキュープロセッサの使い分け
• Pega Constellation の View/Template 設計｜自動生成 UI を活かす判断とアンチパターン
• 無料相談に申し込む