はじめに
Salesforce のセキュリティモデルにおいて、ロール（Role）とロール階層（Role Hierarchy）は、組織のデータ共有戦略の中核を担う重要な概念です。ロール階層を適切に設計することで、組織構造に沿った効率的なデータアクセス制御を実現できます。
本記事では、ロールの基本概念から階層設計のベストプラクティス、実践的な設計パターンまでを詳しく解説します。
学習目標
この記事を読むことで、以下のスキルを習得できます：
- ロールとロール階層の概念と目的を理解する
- 組織構造に適したロール階層を設計できる
- データ共有におけるロールの役割を理解する
- ロール階層の設計ベストプラクティスを習得する
- システムアドミニストレータ試験の関連問題に対応できる
ロールとロール階層とは
基本概念
ロール（Role）は、組織内のユーザーの職位や役割を表す概念です。ロールは階層構造を形成し、この階層によってレコードへのアクセスが制御されます。
主な特徴：
-
階層構造
- ツリー構造でロールを配置
- 上位ロールは下位ロールのデータにアクセス可能
-
データ共有の基盤
- OWD（組織の共有設定）が Private の場合に重要
- 上位への暗黙的な共有を実現
-
任意設定
- ユーザーへのロール割り当ては技術的には必須ではない
- ただし、以下の機能では実質必須：
- 商談レポート（ロール階層ベースのフィルタリング）
- 売上予測（Forecast）
- ロール階層に基づくレポートとダッシュボード
- データ共有を制御する場合は強く推奨
-
柔軟な設計
- 組織構造と完全一致させる必要はない
- ビジネス要件に応じて設計
ロール階層の仕組み
CEO（最上位）
├─ 営業部長
│ ├─ 営業マネージャーA
│ │ ├─ 営業担当者A-1
│ │ └─ 営業担当者A-2
│ └─ 営業マネージャーB
│ ├─ 営業担当者B-1
│ └─ 営業担当者B-2
└─ サポート部長
└─ サポート担当者
データアクセスの原則：
- 営業担当者A-1 が所有するレコード
- 営業担当者A-1：参照・編集可能（所有者）
- 営業マネージャーA：参照可能（※プロファイルのオブジェクト権限で
編集が許可されている場合。ロール階層により所有者レベルのアクセスを継承） - 営業部長：参照可能（※編集可否はオブジェクト権限・共有設定に依存）
- CEO：参照可能（※編集可否はオブジェクト権限・共有設定に依存）
- 営業担当者A-2：アクセス不可（同レベル）
- 営業マネージャーB：アクセス不可（別の枝）
- サポート担当者：アクセス不可（別の部門）
ロールの重要性と目的
なぜロールが必要なのか
- 組織階層に沿ったデータアクセス
実際のビジネスシーン：
営業マネージャーは、チームメンバーの商談を
確認・サポートする必要がある
↓ ロール階層で実現
マネージャーロールを営業担当ロールの上位に配置
→ 自動的に部下の商談にアクセス可能
- 権限の階層的な付与
従来の方法：
共有ルールを複数作成
→ 管理が複雑化
ロール階層を使用：
階層構造で自動的に共有
→ シンプルな管理
- レポートとダッシュボードの効率化
マネージャー用レポート：
「自分とチームの商談」
ロールがあれば：
条件 = ロール階層：営業マネージャーA
→ 自分 + 部下のデータを自動集計
ロールが影響する機能
| 機能 | ロールの影響 |
|---|---|
| レコード共有 | 上位ロールは下位ロールのレコードにアクセス可能（※編集可否は権限・共有設定に依存） |
| レポート | 「ロール階層」フィルターで部下のデータも含む |
| ダッシュボード | 動的ダッシュボードで閲覧者のロールに応じた表示 |
| リストビュー | 「自分のチーム」で階層内のレコードを表示 |
| 承認プロセス | 承認者を上長（Manager）やロール、特定ユーザー等で指定可能 |
| テリトリー管理 | ロールとテリトリーの組み合わせで複雑な共有 |
ロール階層の設計手順
ステップ1: 要件の整理
確認すべき項目：
-
組織構造
- 部門構成（営業、サポート、マーケティング等） - 階層の深さ（担当者→課長→部長→役員） - 地域構造（日本、アジア、欧州等） -
データ共有要件
- マネージャーは部下のデータにアクセスが必要か - 部門間でのデータ共有は必要か - 地域間でのデータ共有は必要か -
OWD設定
- 主要オブジェクトのOWD - Private の場合：ロール階層が重要 - Public Read/Write の場合：ロール階層の影響小
ステップ2: ロール階層の作成
設定手順：
-
設定 → ユーザー → ロール に移動
-
「ロールを設定する」をクリック
-
基本構造を作成：
最上位ロールの作成：
ラベル: CEO
このロールのユーザーはこのロールの下位に属する
ユーザーが所有するすべてのレコードにアクセスできます: ☑
- 下位ロールを追加：
CEO の下に：
├─ 営業部長
└─ サポート部長
営業部長ロールの作成：
上位ロール: CEO
ラベル: 営業部長
このロールのユーザー...: ☑
- さらに下位を追加：
営業部長の下に：
├─ 営業マネージャー（東日本）
└─ 営業マネージャー（西日本）
ステップ3: ユーザーへの割り当て
個別割り当て：
- 設定 → ユーザー → ユーザー
- ユーザーを選択
- 「編集」
- ロールを選択
- 保存
一括割り当て（Data Loader）：
Id,UserRoleId
005...,00E...
005...,00E...
ステップ4: 階層の検証
確認ポイント：
階層の可視化
設定 → ユーザー → ロール
→ 「ツリーの並び替え」で全体を確認
アクセス権のテスト
1. テストユーザーでログイン
2. 上位ロールのユーザーが所有するレコードを参照
3. 下位ロールのユーザーが所有するレコードを参照
4. 期待通りのアクセス権か確認
実践例：組織のロール階層設計パターン
パターン1: シンプルな階層（小規模組織）
適用：20-50名の組織
CEO
├─ 営業部長
│ ├─ 営業マネージャー
│ │ └─ 営業担当者
│ └─ 営業アシスタント
│
├─ サポート部長
│ └─ サポート担当者
│
└─ 管理部門
└─ 管理者
特徴：
- 3-4階層のシンプルな構造
- 部門ごとに明確な分離
- 管理しやすい
OWD設定例：
取引先：Public Read/Write
商談：Private
ケース：Private
パターン2: 地域別階層（中規模組織）
適用：100-300名の組織、複数拠点
CEO
├─ 営業統括
│ ├─ 営業部長（東日本）
│ │ ├─ 営業マネージャー（東京）
│ │ │ └─ 営業担当者（東京）
│ │ └─ 営業マネージャー（大阪）
│ │ └─ 営業担当者（大阪）
│ │
│ └─ 営業部長（西日本）
│ ├─ 営業マネージャー（福岡）
│ │ └─ 営業担当者（福岡）
│ └─ 営業マネージャー（名古屋）
│ └─ 営業担当者（名古屋）
│
└─ サポート統括
├─ サポート部長（東日本）
│ └─ サポート担当者（東日本）
└─ サポート部長（西日本）
└─ サポート担当者（西日本）
特徴：
- 地域ごとの階層構造
- 統括レベルで全地域のデータにアクセス
- 地域間の横のつながりはなし
共有ルールで補完：
例：西日本の大型案件を東日本でもサポート
→ 条件ベース共有ルールで特定レコードを共有
パターン3: マトリクス型（大規模組織）
適用：500名以上、複雑な組織構造
CEO
├─ 営業本部
│ ├─ エンタープライズ営業部
│ │ ├─ エンタープライズ営業マネージャー
│ │ │ └─ エンタープライズ営業担当
│ │ └─ エンタープライズSE
│ │
│ ├─ SMB営業部
│ │ ├─ SMB営業マネージャー
│ │ │ └─ SMB営業担当
│ │ └─ インサイドセールス
│ │
│ └─ パートナー営業部
│ └─ パートナーマネージャー
│
├─ カスタマーサクセス本部
│ ├─ サポート部
│ │ ├─ L1サポート
│ │ ├─ L2サポート
│ │ └─ L3サポート（エスカレーション）
│ │
│ └─ カスタマーサクセス部
│ └─ CSM（Customer Success Manager）
│
└─ マーケティング本部
├─ デジタルマーケティング
└─ フィールドマーケティング
特徴：
- 深い階層（5-6レベル）
- 職能別の専門チーム
- 部門横断的なプロジェクトも想定
補完設定：
1. 共有ルール：部門間連携が必要なレコード
2. チーム機能：特定の取引先/商談で協業
3. パブリックグループ：プロジェクトチーム
パターン4: フラット型（特殊ケース）
適用：階層がほぼない組織、スタートアップ
CEO
├─ セールス
├─ カスタマーサポート
├─ マーケティング
└─ 開発
特徴：
- 2階層のみ
- 各部門が独立
- マネージャー層が少ない
OWD設定：
ほとんどのオブジェクト：Public Read/Write
または Public Read Only
理由：階層が浅いためロールでの制御が限定的
ロール階層の設計原則
原則1: ビジネス要件優先
避けるべき例：組織図をそのまま反映
問題：
- IT部門も営業部門も全て階層に含める
- 実際のデータアクセス要件を無視
- 不要に複雑な階層
推奨：データアクセス要件に基づく設計
- データ共有が必要な部門のみロール階層に含める
- IT部門は階層外でもOK（全データアクセス不要）
- シンプルな構造を維持
原則2: 適切な階層の深さ
推奨：3-5階層
理想的な深さ：
レベル1: CEO / 経営層
レベル2: 部長 / Director
レベル3: マネージャー / Manager
レベル4: リーダー / Team Lead
レベル5: 担当者 / Individual Contributor
これ以上深いと：
- 管理が複雑化
- パフォーマンスへの影響
- 共有計算の負荷増加
原則3: ロールの命名規則
推奨パターン：
職位ベース：
Sales_Manager
Sales_Representative
Support_Agent
部門_職位：
Sales_Director
Sales_Manager_East
Sales_Rep_Tokyo
地域_部門_職位：
APAC_Sales_Manager
EMEA_Support_Lead
避けるべき命名：
- Role1, Role2（内容不明）
- 太郎のロール（個人名）
- 一時的な名前（Temp_Role）
原則4: 「ロール階層なし」オプションの活用
Grant Access Using Hierarchies のチェックを外す
重要: この設定はカスタムオブジェクトでのみ変更可能です。標準オブジェクト（取引先、商談、ケース等）では階層共有は常に有効で、無効化できません。
使用場面（カスタムオブジェクトのみ）：
- 機密文書オブジェクト：作成者のみアクセス ☐
- 人事評価オブジェクト：担当者のみアクセス ☐
- 社内提案オブジェクト：部門内のみ共有 ☐
設定場所：
設定 → セキュリティ → 共有設定
→ カスタムオブジェクトの「ロール階層の参照権限を付与」
標準オブジェクトでプライバシーが必要な場合の代替手段：
- OWDをPrivateに設定
- 必要なユーザーのみ共有ルールや手動共有でアクセス付与
- Apex Managed Sharingの活用
効果：
カスタムオブジェクトで階層共有を無効化：
- 担当者Aの機密文書レコード
- マネージャーはアクセス不可
- プライバシー保護、情報の分離が可能
ロール vs その他の共有メカニズム
比較表
| 仕組み | 目的 | 設定の柔軟性 | 管理の複雑さ |
|---|---|---|---|
| OWD | 基本的なアクセスレベル | 低 | 低 |
| ロール階層 | 組織階層に沿った共有 | 中 | 中 |
| 共有ルール | 部門・条件ベースの共有 | 高 | 中-高 |
| 手動共有 | 個別レコードの共有 | 最高 | 高 |
| チーム | 特定レコードへの協業 | 高 | 中 |
| プロファイル | オブジェクトレベル権限 | 中 | 中 |
| 権限セット | 追加権限の付与 | 高 | 低-中 |
使い分けの例
シナリオ1: 営業組織のデータ共有
要件：
- マネージャーはチームの商談を参照・編集
- 営業担当者は自分の商談のみ編集
- 他チームの商談は参照のみ
設計：
1. OWD（商談）: Private
2. ロール階層:
営業マネージャー
└─ 営業担当者
3. 共有ルール:
全営業担当者に全商談を「参照のみ」で共有
シナリオ2: サポート組織の独立性（カスタムオブジェクト例）
要件：
- 担当者は自分の機密レコードのみアクセス
- マネージャーもチームのレコード全体は見ない
- 必要時のみ特定レコードを共有
設計（カスタムオブジェクト「機密文書」の場合）：
1. OWD（機密文書__c）: Private
2. ロール階層: 作成するが階層共有を無効化
設定 → セキュリティ → 共有設定
→ 機密文書__c → 「ロール階層の参照権限を付与」☐
3. 手動共有: 必要時に個別に共有
注意：ケースなどの標準オブジェクトでは階層共有の
無効化はできません。標準オブジェクトでプライバシーを
確保する場合は、OWDをPrivateにし、共有ルールや
手動共有で必要最小限のアクセスを付与します。
シナリオ3: 地域別の営業組織
要件：
- 地域マネージャーは自地域の商談のみ
- 営業統括は全地域の商談にアクセス
- 地域間での横の共有はなし
設計：
1. OWD（商談）: Private
2. ロール階層:
営業統括
├─ 東日本マネージャー
│ └─ 東日本担当者
└─ 西日本マネージャー
└─ 西日本担当者
3. 追加設定不要（階層で自動的に実現）
よくある間違いと対処法
間違い1: 組織図をそのまま反映
問題：
全部門を階層に含める
├─ 営業
├─ サポート
├─ マーケティング
├─ IT
├─ 人事
├─ 経理
└─ 法務
→ 不要に複雑
→ IT部門が全営業データにアクセス（意図せず）
対処法：
- データ共有が必要な部門のみ階層化
- IT、人事、経理などはロール不要でもOK
- または、別の枝で分離
CEO
├─ 営業統括（データ共有必要）
│ └─ ...
└─ 管理部門（データ共有不要）
└─ IT、人事、経理
間違い2: 階層が深すぎる
問題：
10階層のロール構造
→ 共有計算の負荷増大
→ 管理が困難
→ パフォーマンス低下
対処法：
- 3-5階層に抑える
- 細かい役職はロールで表現しない
- 同じレベルの役職は1つのロールに統合
例：
- 避けるべき: 営業担当1年目、2年目、3年目（3ロール）
- 推奨: 営業担当（1ロール）
間違い3: ロールの乱立
問題：
100個以上のロール
→ 管理不能
→ ユーザー割り当てが困難
→ 階層の理解が困難
対処法：
ロール数の目安：
小規模: 5-15
中規模: 15-40
大規模: 40-100
統合を検討：
- 地域ごとに同じ役職は統合できないか
- プロジェクトチームはパブリックグループで
間違い4: すべてのユーザーにロールを割り当て
問題：
全ユーザーに必ずロールを割り当て
→ データ共有が不要なユーザーも含む
→ 意図しないデータアクセスが発生
対処法：
- ロール割り当てはオプション
- データ共有が不要なユーザーは割り当て不要
- 外部ユーザー（Community）
- システム連携ユーザー
- 特定機能のみ使用するユーザー
間違い5: ロール階層だけで全てを解決しようとする
問題：
複雑な共有要件を全てロール階層で実現
→ 階層が複雑化
→ 柔軟性が失われる
対処法：
- ロール階層：基本的な組織階層
- 共有ルール：部門間・条件ベースの共有
- チーム機能：特定レコードへの協業
- 手動共有：個別の例外対応
適切に組み合わせることでシンプルな設計を維持
ロールの制限事項と考慮点
技術的な制限
| 項目 | 制限 | 備考 |
|---|---|---|
| ロール数 | 制限あり（公式ヘルプを参照） | パフォーマンスのため少なめを推奨 |
| 階層の深さ | 制限なし | 推奨は3-5階層 |
| ポータルロール | 別階層 | 内部ユーザーとは分離 |
ロール数に関する補足：
- 組織の作成時期により初期制限が異なる
- 最新の制限値は公式ヘルプを参照
- ベストプラクティス：パフォーマンスと管理性のため、できるだけ少なく保つことを推奨
パフォーマンスへの影響
共有計算の負荷：
ロール階層が深い + レコード数が多い
→ 共有の再計算に時間がかかる
影響する操作:
- ロール階層の変更
- ユーザーのロール変更
- OWDの変更
- 大量データのインポート
対策:
- シンプルな階層を維持
- 共有ルールの数を最小化
- 変更は業務時間外に実施
ポータルユーザーとの違い
内部ユーザーのロール：
通常のロール階層
- CEO
└─ 営業部長
└─ 営業担当者
ポータルロール（Community/Experience Cloud）：
別の階層として管理
- Partner Manager
└─ Partner User
- Customer Manager
└─ Customer User
注意：
内部ロールとポータルロールは混在不可
移行と変更管理
既存組織へのロール導入
段階的なアプローチ：
フェーズ1: 設計
1. 現在のデータアクセス状況を調査
2. OWD設定を確認
3. ロール階層を設計
4. Sandboxで検証
フェーズ2: 準備
1. Sandboxでロール階層を作成
2. テストユーザーに割り当て
3. アクセス権をテスト
4. 問題があれば修正
フェーズ3: 移行
1. 本番環境でロール階層を作成
2. 小グループのユーザーに試験的に割り当て
3. 問題がなければ全ユーザーに展開
4. モニタリングと調整
フェーズ4: 最適化
1. ユーザーフィードバックを収集
2. 不要なロールを削除
3. 階層を調整
4. ドキュメント更新
ロール階層の変更
変更時の影響：
ロールの移動・削除：
→ 共有の再計算が発生
→ 大量データがある場合は時間がかかる
→ 業務時間外に実施推奨
ユーザーのロール変更：
→ そのユーザーのレコード共有を再計算
→ 影響は限定的
新規ロールの追加：
→ 既存の共有への影響なし
→ いつでも実行可能
変更手順：
1. Sandboxで変更をテスト
2. 影響範囲を確認
3. メンテナンスウィンドウを設定
4. 本番環境で実施
5. 共有の再計算完了を確認
6. ユーザーに通知
試験対策ポイント
重要な知識ポイント
- 基本概念：
- ロール階層は組織の階層構造を表す
- 上位ロールは下位ロールのレコードにアクセス可能
（※編集可否はオブジェクト権限や共有設定に依存）
- 同レベルのロール間ではアクセス不可
- ロールの割り当ては任意（必須ではない）
- データ共有：
- OWDがPrivateの場合に効果的
- 上位への「暗黙的な共有」を実現
- オブジェクトごとに階層共有を有効/無効化可能
- 共有の再計算が発生する操作を理解
- 設計原則：
- 組織図ではなくビジネス要件に基づく
- 3-5階層が推奨
- シンプルな構造を維持
- 他の共有メカニズムと組み合わせる
試験によく出る問題パターン
パターン1: アクセス権の判断
Q: 以下のロール階層で、営業担当者Aが所有する
商談レコードに誰がアクセスできますか？
CEO
└─ 営業部長
└─ 営業マネージャー
├─ 営業担当者A
└─ 営業担当者B
OWD（商談）: Private
A:
- 営業担当者A（所有者）: アクセス可
- 営業マネージャー（上位ロール）: アクセス可
- 営業部長（さらに上位）: アクセス可
- CEO（最上位）: アクセス可
- 営業担当者B（同レベル）: アクセス不可
パターン2: ロール階層の必要性
Q: 以下の場合、ロール階層は必要ですか？
シナリオ1: OWD（商談）= Public Read/Write
A: 不要。全ユーザーが全レコードにアクセス可能なため、
ロール階層による共有は意味がない。
シナリオ2: OWD（商談）= Private、
マネージャーがチームの商談を参照する必要がある
A: 必要。ロール階層により上位ロールに共有される。
パターン3: 階層共有の無効化
Q: カスタムオブジェクト「機密文書__c」のプライバシーを
保護するため、マネージャーでもチームのレコードを
参照できないようにしたい。どうすれば良いですか？
A:
1. 設定 → セキュリティ → 共有設定
2. 機密文書__cの「ロール階層の参照権限を付与」の
チェックを外す
3. ロール階層による自動共有は無効化される。アクセス可否は OWD、共有ルール、手動共有、Apex Managed Sharing、権限設定などにより決まる。
重要：この設定はカスタムオブジェクトでのみ変更可能です。
ケースなどの標準オブジェクトでは階層共有は常に有効です。
標準オブジェクトでプライバシーを確保するには、OWDを
Privateにし、共有ルールで必要なアクセスのみ付与します。
パターン4: 共有の再計算
Q: 以下の操作のうち、共有の再計算が発生するのは？
A:
- ロール階層の変更（ロールの移動・削除）: 発生する
- OWDの変更: 発生する
- 共有ルールの変更: 発生する
- ユーザーのロール変更: 発生する
- 権限セットの変更: 発生しない（共有には影響しない）
- プロファイルの権限変更: 発生しない（オブジェクト権限のみ）
実務シナリオ問題
シナリオ1：
組織には営業部とサポート部があります。
営業マネージャーは自チームの商談を参照する必要があります。
カスタムオブジェクト「機密報告書__c」は担当者のみアクセス可能にしたい。
どのように設計すべきですか？
推奨設計:
1. ロール階層:
CEO
├─ 営業部長
│ └─ 営業マネージャー
│ └─ 営業担当者
└─ サポート部長
└─ サポート担当者
2. OWD設定:
商談: Private（階層共有：標準オブジェクトは常に有効 ☑）
機密報告書__c: Private（階層共有 無効 ☐）
※ケース等の標準オブジェクトは階層共有の無効化不可
3. 結果:
- 営業マネージャーはチームの商談を参照可能
- 機密報告書__cは所有者のみアクセス可能
- カスタムオブジェクトでプライバシーを保護
シナリオ2：
現在OWDが全てPublic Read/Writeの組織で、
セキュリティを強化したい。どのような手順で
ロール階層を導入すべきですか？
推奨手順:
1. Sandboxで現状を再現
2. ロール階層を設計・作成
3. OWDをPrivateに変更（Sandboxで）
4. 必要な共有ルールを追加
5. テストユーザーでアクセス権を検証
6. 問題なければ本番環境で実施
（業務時間外に変更を推奨）
7. ユーザーに周知とサポート提供
注意点:
- OWDの変更は共有の再計算が発生
- 大量データがある場合は時間がかかる
- 段階的に移行（まず1オブジェクトから）
まとめ
ロールとロール階層は、Salesforce のデータ共有戦略の基盤となる重要な機能です。
重要ポイント
ロール階層の目的
- 組織の階層構造に沿ったデータアクセス制御
- 上位ロールは下位ロールのレコードに自動アクセス
- OWDがPrivateの場合に特に重要
設計の原則
- ビジネス要件優先（組織図そのままではない）
- 3-5階層を推奨
（公式ドキュメントでは具体的な数値は示されていませんが、
パフォーマンスのため階層をできるだけ少なく保つことが推奨されています） - シンプルな構造を維持
- 他の共有メカニズムと組み合わせる
運用上の考慮点
- ロールの割り当ては任意（必須ではない）
- 階層の変更は共有の再計算が発生
- オブジェクトごとに階層共有を制御可能
- 定期的な見直しと最適化が重要
他の機能との関係
- OWD：基本的なアクセスレベル
- 共有ルール：部門間・条件ベースの共有
- プロファイル/権限セット：オブジェクトレベルの権限
設計のチェックリスト
□ ビジネス要件を整理したか
□ OWD設定を確認したか
□ 階層は3-5レベルに収まっているか
□ 命名規則は統一されているか
□ Sandboxでテストしたか
□ アクセス権は期待通りか
□ ドキュメントは作成したか
□ ユーザーへの説明は準備したか
次のステップ
ロールとロール階層を理解したら、次は以下のトピックに進みましょう：
- 共有ルール - ロール階層で対応できない共有要件への対処
- キューの設定 - チームベースのレコード割り当て
- パブリックグループ - プロジェクトチームの管理
参考資料
動画解説 (自分用)
スライド (自分用)