[初級] Salesforce 権限セットグループで効率的な権限管理を実現する方法

Posted at 2025-12-15

はじめに

Salesforce では、ユーザーに複数の権限セットを割り当てることができますが、組織が成長するにつれて権限セットの数も増加し、管理が複雑になることがあります。権限セットグループ（Permission Set Group）は、複数の権限セットを1つのグループにまとめて管理できる機能で、権限管理を大幅に効率化します。

本記事では、権限セットグループの基本概念から実践的な活用方法、設計のベストプラクティスまでを詳しく解説します。

学習目標

この記事を読むことで、以下のスキルを習得できます：

権限セットグループの概念と利点を理解する
権限セットグループの作成と管理方法を習得する
権限セットとの使い分けを理解する
効率的な権限管理の設計パターンを学ぶ
システムアドミニストレータ試験の関連問題に対応できる

権限セットグループとは

基本概念

権限セットグループは、複数の権限セットを1つのグループとしてまとめて管理できる機能です。

主な特徴：

複数の権限セットを含む
- 1つのグループに複数の権限セット
- グループの割り当てで一括付与
ユーザーへの一括割り当て
- グループを割り当てると全ての権限セットが適用
- 個別に割り当てる手間を削減
原則は権限の追加のみ
- 権限セットと同様の動作
- プロファイルに権限を追加する形
- ただし、ミューティング権限セットによりグループ内の一部権限を無効化可能
ネストは不可
- グループの中にグループは含められない
- グループに含められるのは権限セットのみ

権限セットとの違い

項目	権限セット	権限セットグループ
目的	個別の権限を付与	複数の権限セットを一括管理
構成	権限の集まり	権限セットの集まり
割り当て	ユーザーに直接割り当て	ユーザーに直接割り当て
管理	個別に管理	グループとして管理
ネスト	N/A	グループ内にグループは不可
ミューティング権限セット	非対応	対応（グループ内の権限を無効化可能）
使用例	レポート作成権限	営業マネージャーに必要な全権限

権限セットグループを使うべき場面

使用が推奨される場面

役割ベースの権限管理

例：営業マネージャー
- 基本的な営業権限セット
- レポート作成権限セット
- 商談View All権限セット
- ダッシュボード作成権限セット

→ 「営業マネージャーグループ」として一括管理

プロジェクトベースの権限付与

例：新製品ローンチプロジェクト
- 製品カタログアクセス
- マーケティング資料編集
- キャンペーン管理
- レポート閲覧

→ 「新製品ローンチグループ」として期間限定で付与

部門横断的な役割

例：データアナリスト
- データエクスポート権限
- 全レポート閲覧権限
- ダッシュボード作成権限
- API アクセス権限

→ 「データアナリストグループ」として統一管理

使用を避けるべき場面

単一の権限のみが必要な場合

権限セットを直接割り当てる方が効率的
グループ化するメリットがない

頻繁に変更される権限

グループの変更は全ユーザーに影響
個別の権限セットで柔軟に対応

ユーザーごとに権限が大きく異なる場合

カスタマイズが必要な場合は個別管理が適切

権限セットグループの作成手順

ステップ1: 必要な権限セットの準備

まず、グループに含める権限セットを用意します。

例：営業マネージャー用の権限セット

基本営業権限 (Sales_Basic)
- 取引先、取引先責任者、商談のCRUD
- 活動の作成と編集
商談全参照権限 (Opportunity_View_All)
- 商談：View All権限
- チーム全体の商談を参照
レポート作成権限 (Report_Creator)
- レポートとダッシュボードのCRUD
- レポート作成システム権限
売上予測権限 (Forecasting_User)
- 売上予測の参照と編集
- 予測カテゴリの管理

ステップ2: 権限セットグループの作成

設定手順：

設定 → ユーザー → 権限セットグループに移動
新規をクリック

基本情報を入力：

ラベル: 営業マネージャー
API参照名: Sales_Manager
説明: 営業マネージャーに必要な全ての権限を含むグループ
     - 基本営業権限
     - 商談全参照
     - レポート作成
     - 売上予測

保存をクリック

ステップ3: 権限セットの追加

作成したグループの詳細ページを開く
権限セット関連リストで「追加」をクリック
グループに含める権限セットを選択：
- Sales_Basic
- Opportunity_View_All
- Report_Creator
- Forecasting_User
保存をクリック

ステップ4: ユーザーへの割り当て

個別割り当て：

グループの詳細ページで「割り当ての管理」をクリック
「割り当ての追加」を選択
対象ユーザーを選択
「割り当て」をクリック

一括割り当て（Data Loader使用）：

PermissionSetGroupId,AssigneeId
0PG5j000000XXXXX,0055j000000YYYYY
0PG5j000000XXXXX,0055j000000ZZZZZ

実践例：組織の権限セットグループ設計

例1：小規模組織（20-50ユーザー）

シンプルな役割ベース構成

1. 営業担当グループ
   ├─ Sales_Basic（基本営業権限）
   ├─ Calendar_Public（予定表公開）
   └─ Mobile_Access（モバイルアクセス）

2. 営業マネージャーグループ
   ├─ Sales_Basic（基本営業権限）
   ├─ Opportunity_View_All（商談全参照）
   ├─ Report_Creator（レポート作成）
   ├─ Forecasting_Manager（予測管理）
   └─ Dashboard_Editor（ダッシュボード編集）

3. サポート担当グループ
   ├─ Service_Basic（基本サポート権限）
   ├─ Knowledge_User（ナレッジ利用）
   └─ Case_Management（ケース管理）

4. マーケティンググループ
   ├─ Campaign_Manager（キャンペーン管理）
   ├─ Report_Creator（レポート作成）
   └─ Marketing_User（マーケティングユーザー）

例2：中規模組織（100-500ユーザー）

部門と役割の組み合わせ

営業部門：
├─ 営業担当グループ
│  ├─ Sales_Core
│  ├─ Activity_Management
│  └─ Territory_Access
│
├─ 営業マネージャーグループ
│  ├─ Sales_Core
│  ├─ Opportunity_ViewAll
│  ├─ Report_Advanced
│  ├─ Forecasting_Manager
│  └─ Team_Management
│
└─ 営業役員グループ
   ├─ Sales_Core
   ├─ All_Data_View
   ├─ Dashboard_Executive
   └─ Analytics_Access

サポート部門：
├─ サポート担当グループ
│  ├─ Service_Core
│  ├─ Case_Management
│  ├─ Knowledge_User
│  └─ Live_Agent
│
└─ サポートマネージャーグループ
   ├─ Service_Core
   ├─ Case_ViewAll
   ├─ Report_Advanced
   ├─ Queue_Management
   └─ SLA_Management

横断的役割：
├─ データアナリストグループ
│  ├─ Report_Advanced
│  ├─ Dashboard_Creator
│  ├─ Data_Export
│  └─ API_Access
│
└─ プロジェクトリーダーグループ
   ├─ Project_Management
   ├─ Team_Collaboration
   ├─ Resource_Planning
   └─ Report_Creator

例3：プロジェクトベースの一時的グループ

新製品ローンチプロジェクト（期間限定）
├─ Product_Catalog_Access
├─ Marketing_Materials_Edit
├─ Campaign_Launch_Manager
├─ Training_Content_Creator
└─ Project_Reporting

M&A統合プロジェクト（期間限定）
├─ Data_Migration_Access
├─ Dual_System_Access
├─ Integration_Reporting
└─ Special_Object_Access

権限セットグループの管理

グループの更新と変更管理

権限セットの追加：

グループ詳細ページを開く
権限セット関連リストで「追加」
新しい権限セットを選択
保存 → 自動的に全割り当てユーザーに適用

権限セットの削除：

グループ詳細ページを開く
権限セット関連リストで対象権限セットの「削除」
確認 → 自動的に全割り当てユーザーから削除

注意：グループの変更は即座に全ての割り当てユーザーに反映されます。

割り当ての確認

グループの割り当て状況を確認：

設定 → ユーザー → 権限セットグループ
対象グループを開く
「割り当ての管理」で全ユーザーを表示

ユーザーの権限セットグループを確認：

設定 → ユーザー → ユーザー
対象ユーザーを開く
「権限セットグループの割り当て」関連リストを確認

監査とコンプライアンス

変更履歴の追跡：

設定監査証跡で確認可能：
- 権限セットグループの作成
- 権限セットの追加/削除
- ユーザーへの割り当て/割り当て解除

セキュリティレビュー：

四半期ごとに確認すべき項目：
- グループの割り当て状況は適切か
- 不要なグループは削除されているか
- 一時的なグループは期限が守られているか
- グループの説明は最新か

ベストプラクティス

1. 明確な命名規則を使用する

推奨される命名パターン：

役割ベース：
- Sales_Manager_Group
- Service_Representative_Group
- Marketing_Analyst_Group

プロジェクトベース：
- Project_[プロジェクト名]_Group
- Temp_[目的]_Group

部門ベース：
- Dept_Sales_Manager_Group
- Dept_Service_Agent_Group

避けるべき命名：

Group1, Group2（内容が不明）
Test（本番環境で使用）
日本語のみ（API参照名の問題）

2. 詳細な説明を記載する

説明の推奨フォーマット：

目的: 営業マネージャーの業務に必要な全権限
対象: 営業部のマネージャー職（課長以上）
含まれる権限セット:
- Sales_Basic: 基本的な営業オブジェクトCRUD
- Opportunity_ViewAll: チーム全体の商談参照
- Report_Creator: レポート・ダッシュボード作成
- Forecasting_Manager: 売上予測管理
最終更新: 2024-01-15
更新者: システム管理者 山田太郎

3. 適切な粒度で設計する

推奨される構成：

1グループ = 3-8個の権限セット
   - 管理しやすい数
   - 目的が明確

グループ数 = 組織の役割数の1-2倍程度
   - 小規模: 3-5グループ
   - 中規模: 8-15グループ
   - 大規模: 15-30グループ

避けるべき構成：

1グループに20個以上の権限セット
   - 管理が複雑化
   - 目的が不明確に

50個以上のグループ
   - 管理コストが高い
   - 選択が困難

4. プロファイルとの関係を明確にする

設計原則：

プロファイル: 基本権限（職種・部門）
  ↓
権限セット: 追加機能（個別の役割）
  ↓
権限セットグループ: 複合的な役割（役職・プロジェクト）

具体例：

営業マネージャーAさん:
├─ プロファイル: 標準ユーザー
│  └─ 基本的なCRMアクセス
│
├─ 権限セットグループ: Sales_Manager_Group
│  ├─ Opportunity_ViewAll
│  ├─ Report_Creator
│  ├─ Forecasting_Manager
│  └─ Dashboard_Editor
│
└─ 個別権限セット: API_Access
   └─ 外部システム連携が必要な場合のみ

5. 変更管理プロセスを確立する

推奨プロセス：

1. 変更申請
   - 目的と影響範囲を明確化
   - 承認プロセスを経る

2. テスト環境での検証
   - Sandbox で動作確認
   - テストユーザーで検証

3. 本番環境への適用
   - 変更セット or 手動展開
   - ロールバック手順を準備

4. ドキュメント更新
   - 変更内容を記録
   - 説明欄を更新

5. ユーザーへの通知
   - 影響するユーザーに連絡
   - 変更内容を説明

6. 定期的なレビューを実施する

月次レビュー：

- 新規グループの作成状況
- 一時的グループの有効期限確認

四半期レビュー：

- 全グループの割り当て状況確認
- 不要なグループの削除
- グループ構成の最適化
- 説明の更新

年次レビュー：

- 組織全体の権限戦略の見直し
- グループ構成の再設計
- 命名規則の改善
- ベストプラクティスの更新

よくある間違いと対処法

間違い1: グループの乱立

問題：

役割ごと、プロジェクトごとに無計画にグループを作成
→ 50個以上のグループが存在
→ 管理が困難に

対処法：

グループ作成基準を明確化
   - 3人以上が同じ権限セットの組み合わせを必要とする場合のみ
   - 一時的なニーズは個別の権限セットで対応

定期的な棚卸し
   - 四半期ごとに使用状況を確認
   - 割り当てユーザーが0のグループを削除
   - 類似グループを統合

間違い2: グループに1つの権限セットのみ

問題：

権限セットグループに1つの権限セットしか含まれていない
→ グループ化する意味がない
→ 管理の複雑化のみ

対処法：

- 1つの権限セットのみの場合は直接割り当て
- 将来的に複数になる予定がある場合のみグループ化
- 最低2つ以上の権限セットを含むようにする

間違い3: ネストの試み

問題：

権限セットグループの中に別のグループを含めようとする
→ エラーが発生
→ Salesforce はネストをサポートしていない

対処法：

- グループのネストは不可能と理解する
- 複雑な階層が必要な場合：
   - 共通の権限セットを作成
   - 各グループに同じ権限セットを含める
   - プロファイルで基本権限を定義

代替設計例：

ネストの試み（不可）：
営業グループ
└─ 営業マネージャーグループ（ネスト不可）

正しい設計：
共通権限セット: Sales_Core

営業担当グループ:
├─ Sales_Core
└─ Sales_Basic

営業マネージャーグループ:
├─ Sales_Core
├─ Sales_Basic
├─ Opportunity_ViewAll
└─ Forecasting_Manager

間違い4: プロファイル代替としての使用

問題：

プロファイルを「標準ユーザー」のみにして
全ての権限を権限セットグループで管理
→ 1ユーザーに10個以上の権限セット
→ パフォーマンス低下の可能性

対処法：

プロファイルで基本権限を定義
   - 職種や部門の基本的な権限
   - ページレイアウトとレコードタイプ

権限セットグループは追加権限のみ
   - 役職による追加権限
   - プロジェクトベースの一時権限
   - 特殊な機能へのアクセス

間違い5: 説明の不足

問題：

説明欄が空欄または「営業用」のみ
→ 何が含まれているか不明
→ 使用すべきか判断できない

対処法：

必ず詳細な説明を記載：
   - 目的
   - 対象ユーザー
   - 含まれる権限セット一覧
   - 使用期間（一時的な場合）
   - 作成者・作成日・更新日

権限セットグループの制限事項

技術的な制限

制限項目	制限値	備考
組織ごとのグループ数	Edition・総割り当て数に依存	明示的な上限は公開されていない
グループあたりの権限セット数	Edition・総割り当て数に依存	推奨は3-8個
ユーザーあたりのグループ数	Edition・総割り当て数に依存	推奨は1-3個
ネスト	不可	グループの中にグループは含められない

重要: 上記の制限値は明示的な上限が公開されておらず、ご利用の Salesforce Edition や組織全体の総割り当て数に依存します。実務で設計を行う際は、必ず最新の公式ドキュメントを参照してください。

参考: Salesforce 制限クイックリファレンスガイド

機能的な制約

できること：

複数の権限セットをグループ化
ユーザーへの一括割り当て
グループ単位での権限管理
変更セットでの移行

できないこと：

グループのネスト
権限の直接削除（ただしミューティング権限セットで無効化は可能）
プロファイルの包含
条件付き割り当て

移行と展開

Sandbox から本番環境への移行

方法1: 変更セット

1. Sandbox で権限セットグループを作成
2. 変更セットに追加
   - 権限セットグループ
   - 含まれる権限セット（既に本番になければ）
3. 本番環境にアップロード
4. 検証とデプロイ
5. ユーザーへの割り当て

方法2: メタデータAPI

<!-- PermissionSetGroup.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<PermissionSetGroup xmlns="http://soap.sforce.com/2006/04/metadata">
    <description>営業マネージャーに必要な全権限</description>
    <label>Sales Manager Group</label>
    <permissionSets>
        <permissionSet>Sales_Basic</permissionSet>
        <permissionSet>Opportunity_ViewAll</permissionSet>
        <permissionSet>Report_Creator</permissionSet>
        <permissionSet>Forecasting_Manager</permissionSet>
    </permissionSets>
</PermissionSetGroup>

ユーザー割り当ての移行

個別権限セットからグループへの移行：

移行手順:
1. 現在の権限セット割り当てをエクスポート
2. 権限セットグループを作成
3. テストユーザーで検証
4. グループをユーザーに割り当て
5. 個別の権限セットを削除
6. 割り当て状況を確認

Data Loader を使用した一括移行：

1. 現在の割り当てをクエリ：
   SELECT AssigneeId, PermissionSetId
   FROM PermissionSetAssignment
   WHERE PermissionSetId IN (...)

2. グループ割り当てCSVを準備：
   PermissionSetGroupId,AssigneeId
   0PG...,005...

3. 一括挿入

4. 古い割り当てを削除

試験対策ポイント

重要な知識ポイント

基本概念：

- 権限セットグループは複数の権限セットをまとめたもの
- ユーザーに一括で割り当て可能
- グループのネストは不可
- 原則は権限の追加のみ
- ただし、ミューティング権限セットでグループ内の一部権限を無効化可能

使用場面：

- 役割ベースの権限管理
- プロジェクトベースの一時権限
- 複数の権限セットを頻繁に一緒に割り当てる場合

管理：

- グループの変更は全割り当てユーザーに即座に反映
- 設定監査証跡で変更履歴を追跡可能
- 変更セットで Sandbox から本番環境へ移行可能

試験によく出る問題パターン

パターン1: 適切な使用場面の判断

Q: 営業マネージャー10名に、同じ4つの権限セットを
   割り当てる必要があります。最も効率的な方法は？

A: 権限セットグループを作成し、4つの権限セットを含め、
   グループを10名に割り当てる

パターン2: 制限事項の理解

Q: 権限セットグループについて正しい記述は？

A:
正しい：
- 複数の権限セットを含むことができる
- ユーザーに直接割り当てることができる
- グループの中にグループを含めることはできない

誤り：
- 権限セットグループでユーザーの権限を削除できる
  （実際は追加のみ。グループから権限セットを除外することは
   可能だが、ユーザーの既存権限を削除する機能ではない。
   ミューティング権限セットによる無効化は「削除」ではなく
   「グループ内での無効化」である点に注意）

パターン3: プロファイルとの関係

Q: プロファイルと権限セットグループの違いは？

A:
- プロファイル: 必須、1ユーザー1つ、権限の追加と削除
- 権限セットグループ: オプション、複数可、権限の追加のみ

パターン4: 変更の影響範囲

Q: 権限セットグループに新しい権限セットを追加した場合、
   既存の割り当てユーザーへの影響は？

A: グループが割り当てられている全てのユーザーに
   自動的に新しい権限セットが適用される

実務シナリオ問題

シナリオ1：

組織に20名の営業マネージャーがいます。各マネージャーには
以下の権限が必要です：
- 商談のView All
- レポート作成
- ダッシュボード編集
- 売上予測管理

現在、これらの権限セットを個別に4つずつ割り当てています。
管理を効率化する方法は？

推奨ソリューション:
1. Sales_Manager_Group を作成
2. 4つの権限セットをグループに追加
3. グループを20名に割り当て
4. 個別の権限セット割り当てを削除

メリット:
- 管理ポイントが80個 → 1個に削減
- 新しいマネージャーへの割り当てが簡単
- 権限の変更が一箇所で可能

シナリオ2：

新製品ローンチプロジェクトで、異なる部門の15名に
3ヶ月間だけ特別な権限を付与する必要があります。
どのように管理すべきですか？

推奨ソリューション:
1. Project_NewProduct_Launch_Group を作成
2. 必要な権限セットを含める
3. 説明欄に期限（3ヶ月後）を明記
4. 15名に割り当て
5. カレンダーに削除リマインダーを設定
6. プロジェクト終了時にグループ割り当てを削除

メリット:
- 一時的な権限を明確に管理
- プロジェクト終了時に一括削除が容易
- 監査証跡が残る

まとめ

権限セットグループは、Salesforce の権限管理を効率化する強力な機能です。

重要ポイント

複数の権限セットを1つのグループとして管理

役割ベース、プロジェクトベースの権限付与に最適
ユーザーへの一括割り当てで管理を効率化

適切な設計が重要

明確な命名規則と詳細な説明
適切な粒度（1グループ = 3-8個の権限セット）
プロファイルとの役割分担を明確に

変更管理プロセスの確立

グループの変更は全ユーザーに即座に反映
テスト環境での検証が重要
定期的なレビューで最適化

制限事項の理解

グループのネストは不可
原則は権限の追加のみ（ミューティング権限セットで無効化は可能）

設計の基本原則

プロファイル（基本権限）
    ↓
権限セット（個別機能）
    ↓
権限セットグループ（複合的役割）
    ↓
ユーザー

この階層構造を理解し、それぞれの役割を明確にすることで、
スケーラブルで管理しやすい権限管理体制を構築できます。

次のステップ

権限セットグループを理解したら、次は以下のトピックに進みましょう：

ロールとロール階層 - データ共有の基盤となる組織階層の設計
共有ルール - レコードレベルのアクセス制御の詳細
キューの設定 - グループベースのレコード割り当て

[初級] Salesforce 権限セットグループで効率的な権限管理を実現する方法

はじめに

学習目標

権限セットグループとは

基本概念

権限セットとの違い

権限セットグループを使うべき場面

使用が推奨される場面

使用を避けるべき場面

権限セットグループの作成手順

ステップ1: 必要な権限セットの準備

ステップ2: 権限セットグループの作成

ステップ3: 権限セットの追加

ステップ4: ユーザーへの割り当て

実践例：組織の権限セットグループ設計

例1：小規模組織（20-50ユーザー）

例2：中規模組織（100-500ユーザー）

例3：プロジェクトベースの一時的グループ

権限セットグループの管理

グループの更新と変更管理

割り当ての確認

監査とコンプライアンス

ベストプラクティス

1. 明確な命名規則を使用する

2. 詳細な説明を記載する

3. 適切な粒度で設計する

4. プロファイルとの関係を明確にする

5. 変更管理プロセスを確立する

6. 定期的なレビューを実施する

よくある間違いと対処法

間違い1: グループの乱立

間違い2: グループに1つの権限セットのみ

間違い3: ネストの試み

間違い4: プロファイル代替としての使用

間違い5: 説明の不足

権限セットグループの制限事項

技術的な制限

機能的な制約

移行と展開

Sandbox から本番環境への移行

ユーザー割り当ての移行

試験対策ポイント

重要な知識ポイント

試験によく出る問題パターン

実務シナリオ問題

まとめ

重要ポイント

設計の基本原則

次のステップ

参考資料

動画解説 (自分用)

スライド (自分用)