はじめに
Salesforceの「権限セット（Permission Set）」は、プロファイルで定義された基本権限に、追加の権限を柔軟に付与する仕組みです。プロファイルは1ユーザー1つに制限されますが、権限セットは1ユーザーに複数割り当てることができます。この特性により、プロファイルの数を最小限に抑えながら、個々のユーザーに必要な権限を柔軟に提供できます。本記事では、権限セットの基本から実践的な活用方法まで詳しく解説します。
学習目標
この記事を読むことで、以下の内容が理解できます：
- 権限セットの概念と特徴
- プロファイルとの違いと使い分け
- 権限セットの作成方法
- 権限セットグループの活用
- 権限セット割り当ての管理
- 実践的な設計パターンとベストプラクティス
権限セットとは
権限セットの定義
権限セット（Permission Set）: ユーザーのプロファイルに追加する権限のコレクション
ユーザーの権限 = プロファイル + 権限セット(複数)
例:
営業担当者プロファイル
+ レポート作成権限セット
+ データエクスポート権限セット
= 営業担当者 + レポート作成 + データエクスポート
権限セットの特徴
1. オプション
すべてのユーザーが持つ必要はない
2. 複数割り当て可能
1ユーザーに複数の権限セットを割り当て可能
3. 権限の追加のみ
プロファイルで付与された権限を弱めることはできない
常に権限を追加する方向のみで、削除方向には働かない
ただし、権限セットグループには Muting Permission Set による権限除外がある
4. 柔軟性
一時的な権限付与に最適
プロジェクトベースの権限管理
プロファイルとの比較
| 項目 | プロファイル | 権限セット |
|---|---|---|
| 必須/オプション | 必須 | オプション |
| 割り当て数 | 1ユーザー1つ | 1ユーザー複数可 |
| 権限の方向 | 追加のみ | 追加のみ |
| ページレイアウト | 管理可能 | 管理不可 |
| レコードタイプ | 管理可能 | 管理可能（アクセス割り当て） |
| ログイン時間 | 設定可能 | 設定不可 |
| IP制限 | 設定可能 | 設定不可 |
| 使用場面 | 基本権限 | 追加権限 |
注： プロファイルも権限セットも「権限を付与する」ことはできますが、「権限を削除（拒否）する」ことはできません。Salesforce公式ドキュメントには「You can use profiles, permission sets, and permission set groups to grant access but not to deny access」と明記されています。また、権限セットでレコードタイプへのアクセス割り当ては可能ですが、ページレイアウトとの関連付けはプロファイルでのみ管理できます。
権限セットで管理できる権限
1. オブジェクト権限
プロファイルと同様のCRUD権限:
• Create (作成)
• Read (参照)
• Update (編集)
• Delete (削除)
• View All (すべて参照)
• Modify All (すべて変更)
重要な概念:
権限セットは常に追加方向のみ
例:
プロファイル: Account Read
権限セット: Account Edit, Delete
→ 結果: Account の Read, Edit, Delete が可能
2. 項目レベルセキュリティ
項目ごとの権限:
• 参照可能 (Visible)
• 編集可能 (Editable)
プロファイルで非表示の項目を
権限セットで参照可能にできる
3. システム権限
主なシステム権限:
• API の有効化
• 一括 API の実行
• すべてのデータの参照
• すべてのデータの編集
• レポートの作成・編集
• ダッシュボードの作成・編集
• アプリケーションのカスタマイズ
• 週次データエクスポート
4. アプリケーション権限
Lightning アプリケーションへのアクセス:
• 割り当て済みアプリ
• タブの可視性設定
（注：タブの表示/非表示は制御できるが、
アプリのナビゲーションメニュー順序までは制御できない）
5. Apex クラスと Visualforce ページへのアクセス
カスタムコードへのアクセス制御:
• 有効化された Apex クラス
• 有効化された Visualforce ページ
6. カスタム権限
カスタム権限（Custom Permissions）:
• 組織固有のカスタム機能へのアクセス
• Apexコードで参照
• プロセスビルダーやFlowで使用
権限セットの作成
作成手順
ステップ1: 権限セット作成画面へアクセス
設定 > ユーザー > 権限セット > 新規
ステップ2: 基本情報の入力
必須項目:
-
表示ラベル（Label）
例: レポート作成者 命名規則: • わかりやすい日本語名 • 権限の内容を明確に表現 • 5〜20文字程度 -
API 参照名（API Name）
例: Report_Creator 規則: • 英数字とアンダースコア • 自動生成されるが変更可能 -
説明（Description）
例: 「レポートとダッシュボードの作成・編集権限。 営業マネージャーおよびデータ分析担当者に割り当て。 作成日: 2025-01-15」 推奨内容: • 権限セットの目的 • 対象ユーザー • 含まれる主要権限 • 作成日・作成者 -
ライセンス（オプション）
ライセンスの種類: • なし: すべてのライセンスで使用可能 • Salesforce: Salesforceライセンス専用 • Salesforce Platform: Platformライセンス専用 推奨: 特定のライセンスに依存する権限がない限り 「なし」を選択して柔軟性を確保
ステップ3: オブジェクト権限の設定
権限セット > オブジェクト設定 > [オブジェクト名]
設定例: レポート作成者権限セット
Report:
• Read
• Create
• Edit
• Delete
Dashboard:
• Read
• Create
• Edit
• Delete
Folder:
• Read
• Create
• Edit
ステップ4: 項目レベルセキュリティの設定
権限セット > オブジェクト設定 > [オブジェクト名]
> 項目レベルセキュリティ
設定例: 営業マネージャー権限セット
Opportunity.Amount:
• 参照可能
• 編集可能
Account.Annual_Revenue__c:
• 参照可能
• 編集可能
ステップ5: システム権限の設定
権限セット > システム権限
設定例: データエクスポート権限セット
• 週次データエクスポート
• レポートの実行
• レポートのエクスポート
ステップ6: 割り当て済みアプリの設定
権限セット > 割り当て済みアプリ
設定例: カスタムアプリアクセス権限セット
• Custom HR App
• Project Management App
権限セットの実例
例1: レポート作成者権限セット
権限セット名: レポート作成者
目的:
レポートとダッシュボードの作成・編集権限を付与
対象ユーザー:
• 営業マネージャー
• データ分析担当者
• 経営企画部
権限内容:
オブジェクト権限:
Report: CRUD
Dashboard: CRUD
Folder: Create, Edit
システム権限:
• レポートの作成・編集
• ダッシュボードの作成・編集
• レポートのエクスポート
• レポートスケジュールの作成
例2: データエクスポート権限セット
権限セット名: データエクスポート
目的:
データのエクスポート権限を一時的に付与
対象ユーザー:
• データ移行担当者
• 監査担当者
• 一時的にエクスポートが必要なユーザー
権限内容:
システム権限:
• 週次データエクスポート
• レポートの実行
• レポートのエクスポート
• API の有効化
使用期間:
必要な期間のみ割り当て、完了後は削除
例3: 営業マネージャー権限セット
権限セット名: 営業マネージャー
目的:
チームメンバーのデータ参照と売上管理
対象ユーザー:
• 営業部門のマネージャー
権限内容:
オブジェクト権限:
Opportunity: View All
Account: View All
Lead: View All
システム権限:
• レポートの作成・編集
• ダッシュボードの作成・編集
• 売上予測の管理
項目レベルセキュリティ:
Opportunity.Amount: 参照可能、編集可能
Opportunity.Probability: 参照可能、編集可能
例4: Marketing User 権限セット
権限セット名: Marketing User
目的:
マーケティング機能へのアクセス
対象ユーザー:
• マーケティング担当者
• キャンペーン管理者
権限内容:
Feature License:
• Marketing User
注：Marketing User などの Feature License は、
ユーザー詳細画面のチェックボックスから直接付与する方法と、
権限セットを通じて付与する方法の両方が可能です。
権限セットを使用する方が、一括管理や変更履歴の追跡が
しやすいというメリットがあります。
オブジェクト権限:
Campaign: CRUD + View All
Campaign Member: CRUD
List Email: CRUD
システム権限:
• キャンペーン管理
• リストメール送信
権限セットの割り当て
単一ユーザーへの割り当て
方法1: 権限セットから割り当て
設定 > ユーザー > 権限セット
> [権限セット名]
> 割り当ての管理
> ユーザーを追加
> [ユーザーを選択]
> 割り当て
方法2: ユーザーから割り当て
設定 > ユーザー > ユーザー
> [ユーザー名]
> 権限セット割り当て
> 割り当ての編集
> [権限セットを選択]
> 保存
複数ユーザーへの一括割り当て
データローダーを使用
PermissionSetAssignment オブジェクト:
PermissionSetId,AssigneeId
0PS000000000001,005000000000001
0PS000000000001,005000000000002
0PS000000000001,005000000000003
手順:
1. 権限セットのIDを取得
設定 > 権限セット > [権限セット] > URLからIDをコピー
2. ユーザーIDを取得
レポートまたはデータローダーでエクスポート
3. CSVファイルを作成
4. データローダーで挿入
オブジェクト: PermissionSetAssignment
操作: Insert
割り当ての確認
ユーザーごとの権限セット確認
設定 > ユーザー > ユーザー
> [ユーザー名]
> 権限セット割り当て
権限セットごとの割り当て確認
設定 > ユーザー > 権限セット
> [権限セット名]
> 割り当ての管理
レポートでの確認
レポートタイプ: 権限セット割り当て
フィルター:
• 権限セット名 = [特定の権限セット]
• ユーザー: アクティブ = True
列:
• ユーザー名
• メール
• プロファイル
• 権限セット名
• 割り当て日
権限セットグループ
権限セットグループとは
権限セットグループ（Permission Set Group）: 複数の権限セットをグループ化したもの
権限セットグループ = 複数の権限セット
例:
営業マネージャーグループ
├─ レポート作成権限セット
├─ データエクスポート権限セット
└─ View All 権限セット
権限セットグループのメリット
1. 管理の簡素化
複数の権限セットを一括で割り当て
2. 一貫性
同じ役割のユーザーに同じ権限セットを保証
3. メンテナンス性
グループに権限セットを追加/削除するだけで
全ユーザーに反映
4. 可視性
役割ごとの権限が明確
権限セットグループの作成
ステップ1: グループ作成
設定 > ユーザー > 権限セットグループ > 新規
ステップ2: 基本情報入力
表示ラベル: 営業マネージャー
API 参照名: Sales_Manager_Group
説明: 営業マネージャーに必要な権限セットのグループ
ステップ3: 権限セットの追加
権限セットグループ > 権限セット
> 権限セットを追加
ステップ4: グループの有効化
権限セットグループ > 状況
> 「有効化」をクリック
重要：Permission Set Group Recalculation について
- 有効化後、権限セットの追加/削除には再計算が必要
- 再計算プロセスは即座に実行されず、数分～数十分かかる場合がある
- 再計算時間は以下の要因で変動：
• 権限セット数 × ユーザー数
• 含まれるシステム権限・オブジェクト権限の量
• 組織全体のメタデータ数
（環境により大きく異なるため、事前にサンドボックスで検証推奨）
- 再計算が完了するまで、ユーザーに新しい権限が反映されない点に注意
権限セットグループの例
例1: 営業マネージャーグループ
グループ名: 営業マネージャー
含まれる権限セット:
1. チームデータ参照
- Opportunity: View All
- Account: View All
2. レポート作成者
- Report, Dashboard: CRUD
3. 売上予測管理
- 予測管理の権限
例2: サポートマネージャーグループ
グループ名: サポートマネージャー
含まれる権限セット:
1. ケース管理者
- Case: View All, Modify All
2. Knowledge 管理者
- Knowledge: CRUD, Publish
3. レポート作成者
- Report, Dashboard: CRUD
プロファイルと権限セットの使い分け
基本的な設計方針
プロファイル: 役割の基本権限（最小権限）
権限セット: 追加機能・一時的な権限
推奨アプローチ:
1. プロファイルで最小限の権限を設定
2. 権限セットで必要な権限を追加
3. プロファイルの数を最小化（5〜10個）
4. 権限セットで柔軟に対応
使い分けの判断基準
プロファイルを使用すべき場合
✓ すべてのユーザーに共通の権限
✓ 役割や部門の基本権限
✓ ページレイアウト・レコードタイプの制御
✓ ログイン時間・IP制限
例:
• 営業担当者プロファイル
→ 営業部門全員が持つ基本権限
権限セットを使用すべき場合
✓ 一部のユーザーのみに必要な権限
✓ 一時的な権限付与
✓ プロジェクトベースの権限
✓ Feature License の割り当て
✓ 特定機能へのアクセス
例:
• レポート作成権限セット
→ 一部の営業担当者のみ
• データエクスポート権限セット
→ 一時的に必要なユーザー
実践的な設計例
パターン1: シンプルな構成
プロファイル（3個）:
1. 営業ユーザー（基本権限のみ）
2. サポートユーザー（基本権限のみ）
3. 管理者
権限セット（10個）:
1. レポート作成者
2. ダッシュボード管理者
3. データエクスポート
4. Marketing User
5. Knowledge User
6. View All - Opportunity
7. View All - Account
8. API Access
9. Apex 開発者
10. カスタムアプリアクセス
メリット:
• プロファイル数が少ない
• 柔軟な権限管理
• 一時的な権限付与が簡単
パターン2: 役割ベース構成
プロファイル（8個）:
1. 営業担当者
2. 営業マネージャー
3. サポート担当者
4. サポートマネージャー
5. マーケティング
6. 人事部
7. 経理部
8. 管理者
権限セット（5個）:
1. プロジェクトリーダー（一時的）
2. データエクスポート（一時的）
3. 監査権限（一時的）
4. カスタムアプリA
5. カスタムアプリB
メリット:
• 役割が明確
• プロファイルで主要権限を管理
• 権限セットは一時的・特殊な用途
ベストプラクティス
1. 命名規則
推奨形式:
[機能/目的]_[詳細]
例:
• Report_Creator
• Data_Export
• Marketing_User
• View_All_Opportunities
• API_Access
• Temporary_Project_Alpha
避けるべき:
• PS1, PS2（意味不明）
• User_Permission（曖昧）
2. 説明の充実
権限セットの説明に記載すべき内容:
1. 目的
「何のための権限セットか」
2. 対象ユーザー
「誰に割り当てるべきか」
3. 含まれる権限
「主要な権限の概要」
4. 使用期間
「一時的か恒久的か」
5. 作成日・作成者
「いつ誰が作成したか」
例:
「レポートとダッシュボードの作成・編集権限。
営業マネージャーおよびデータ分析担当者に割り当て。
一時的なプロジェクトメンバーにも必要に応じて付与。
作成: 2025-01-15 by 山田太郎」
3. 最小権限の原則
必要最小限の権限のみを含める
例:
❌ 悪い例:
「営業権限セット」
→ すべての営業関連権限を詰め込む
✅ 良い例:
「商談View All権限セット」
→ OpportunityのView All権限のみ
4. 定期的なレビュー
四半期ごと:
□ 割り当て状況の確認
□ 不要な権限セットの削除
□ 一時的な権限セットの回収
年次:
□ 権限セット構成の見直し
□ 統合・整理の検討
□ ドキュメントの更新
5. ドキュメント化
# 権限セット設計ドキュメント
## レポート作成者
### 目的
レポートとダッシュボードの作成・編集
### 対象ユーザー
- 営業マネージャー: 5人
- データ分析チーム: 3人
### 含まれる権限
- Report: CRUD
- Dashboard: CRUD
- システム権限: レポート作成・編集
### 作成日
2025-01-15
### 更新履歴
- 2025-01-15: 初版作成
- 2025-02-01: Dashboard権限追加
6. テスト
権限セット作成後:
1. テストユーザーで動作確認
□ 意図した権限が付与されているか
□ 不要な権限が含まれていないか
2. 実際の業務フローで確認
□ レコードの作成
□ レポートの実行
□ データのエクスポート
3. 本番環境への展開
問題なければ実際のユーザーに割り当て
よくある間違いと対処法
間違い1: 権限セットの過剰な作成
問題:
ユーザーごと、または細かい要件ごとに
権限セットを作成してしまう
結果:
- 権限セット数が100個以上に
- 管理が複雑化
- どの権限セットを使うべきか不明確
対処法:
1. 類似の権限セットを統合
2. 権限セットグループでまとめる
3. 10〜30個程度に抑える
4. 定期的に整理
間違い2: プロファイルの代わりに権限セット
問題:
プロファイルを最小限にしすぎて
すべての権限を権限セットで管理
結果:
- 1ユーザーに10個以上の権限セット
- 権限の全体像が不明確
- 管理の複雑化（メンテナンス困難、トラブルシューティング困難）
※ 権限解析処理が増えるため理論上パフォーマンスへの影響もありますが、
実務上、顕著なパフォーマンス低下が発生することは一般的ではありません。
主な問題は管理面の複雑化です。
対処法:
1. プロファイルで基本権限を設定
2. 権限セットは追加機能のみ
3. 1ユーザー3〜5個程度の権限セットが目安
間違い3: 一時的な権限の放置
問題:
プロジェクト終了後も権限セットが
割り当てられたまま
リスク:
- 不要な権限の付与
- セキュリティリスク
- ライセンスの無駄遣い
対処法:
1. 一時的な権限セットには期限を設定
2. 四半期ごとにレビュー
3. 使用期間を説明欄に記載
4. プロジェクト終了時に回収
間違い4: ライセンス指定の誤り
問題:
権限セットに誤ったライセンスを指定
例:
Salesforce Platform ライセンス指定の権限セット
→ Salesforce ライセンスのユーザーが使用できない
対処法:
1. 特定ライセンス依存の権限がない限り
ライセンス指定は「なし」
2. Feature Licenseが必要な場合のみ指定
試験対策ポイント
重要な試験トピック
-
権限セットの特徴
- オプション、複数割り当て可能
- 権限の追加のみ（削除不可）
ただし、権限セットグループには Muting Permission Set による権限除外がある
-
プロファイルとの違い
- プロファイル: 必須、1つのみ
- 権限セット: オプション、複数可
-
管理できない設定
- ページレイアウト割り当て（レコードタイプとの関連付け）
- ログイン時間・IP制限
- 注：レコードタイプへのアクセス割り当ては権限セットで可能
-
権限の方向（プロファイル・権限セット共通）
- 常に追加方向のみ
- 権限を削除（拒否）することはできない
-
権限セットグループ
- 複数の権限セットをグループ化
- 一括割り当て可能
よく出る試験問題パターン
問題例1:
Q: 1ユーザーに割り当てられる権限セットの数は？
A: 複数（制限なし、ただし実用上は3〜5個程度）
問題例2:
Q: 権限セットで管理できないものはどれですか？
a) オブジェクト権限
b) 項目レベルセキュリティ
c) ページレイアウト割り当て
d) システム権限
A: c) ページレイアウト割り当て
問題例3:
Q: プロファイルで「Read」権限のみのオブジェクトに、
権限セットで「Edit」権限を追加できますか？
A: はい、権限セットは常に追加方向です
問題例4:
Q: 権限セットグループの目的は？
A: 複数の権限セットを一括で管理・割り当て
問題例5:
Q: 一時的なプロジェクトメンバーに権限を付与する
最適な方法は？
A: 権限セットを作成し、プロジェクト期間中のみ割り当て
まとめ
Salesforceの権限セットは、ユーザーに必要な権限だけを柔軟に追加できる仕組みで、プロファイルで定義する基本権限を最小限に保ちながら運用できるのが特徴です。複数の権限セットをまとめて管理できる権限セットグループを活用すれば、役割ごとの一貫した権限設計が可能になります。運用面では、一貫した命名、最小権限の徹底、目的のドキュメント化、定期的な見直し、そして一時的な権限の確実な回収が重要です。
参考資料
Trailhead
動画解説(自分用)
スライド(自分用)