Salesforceのロール階層をマスターする：管理者のためのデータアクセスセキュリティ完全ガイド

背景と適用シナリオ

Salesforce管理者として、私たちの最も重要な責務の一つは、組織のデータを保護することです。データは企業の生命線であり、適切な人物が適切な情報にのみアクセスできるようにすることは、信頼を維持し、規制を遵守し、ビジネスを円滑に運営するための基本です。Salesforceはこの課題に対処するために、堅牢で多層的なセキュリティモデルを提供しており、その中核をなすのがRole Hierarchy（ロール階層）です。

想像してみてください。あなたの会社には、営業担当副社長（VP）、その下に2人の地域ディレクター（東日本と西日本）、各ディレクターの下に複数の営業マネージャー、そして各マネージャーの下に数名の営業担当者がいるとします。この組織構造において、以下のようなアクセス要件はごく一般的です。

営業担当者は、自分が所有する商談や取引先のみ閲覧・編集できる。
営業マネージャーは、自分のチームメンバーが所有するすべてのデータにアクセスできる必要がある。
地域ディレクターは、自分の地域（例：東日本）に属するすべてのマネージャーとその部下のデータにアクセスできる必要がある。
営業担当副社長（VP）は、会社のすべての営業関連データにアクセスできる必要がある。

このような縦方向のデータ可視性の要件を、手動で一つ一つ設定するのは非現実的です。ここでRole Hierarchyが真価を発揮します。これは、組織の役職やデータアクセス権限の階層を模倣したツリー構造であり、上位のロールに割り当てられたユーザーは、階層内で自分より下位のロールに割り当てられたユーザーが所有するレコードに対して、自動的にアクセス権を持つようになります。

Role Hierarchyは、Organization-Wide Defaults (組織の共有設定 - OWD) と密接に連携します。OWDが特定のオブジェクト（例えば「商談」）に対して「非公開」に設定されている場合、デフォルトではユーザーは自分が所有するレコードしか見ることができません。Role Hierarchyは、この「非公開」の壁を、組織の階層に沿って「上方向」に開放するための、最も効率的で基本的な仕組みなのです。

原理説明

Role Hierarchyの原理は非常にシンプルでありながら強力です。「上位のロールは、下位のロールのデータにアクセスできる」という一点に尽きます。この「アクセス」には、レコードの参照、編集、削除、そしてレポートでのデータ集計が含まれます（ただし、具体的な操作権限はユーザーのProfile（プロファイル）やPermission Set（権限セット）に依存します）。

この垂直方向のアクセス権付与は、Salesforceの共有モデルの根幹をなす機能であり、以下の要素によって制御されます。

1. 階層構造

ロール階層は、CEOや社長といった最上位のロールから始まり、部門、チームといった形で枝分かれしていきます。ユーザーはそれぞれ一つのロールに割り当てられます。例えば、「東日本営業マネージャー」ロールのユーザーは、「東日本営業担当」ロールのユーザーが所有するすべてのレコードにアクセスできます。同様に、「東日本ディレクター」は「東日本営業マネージャー」とその部下のデータすべてにアクセスできます。このアクセス権は階層を遡って継承されるため、最上位のCEOロールのユーザーは、組織内の全ユーザーのデータにアクセスできることになります。

2. 「Grant Access Using Hierarchies」（階層を使用したアクセス許可）

この魔法のような機能が有効になるためには、重要な設定があります。共有設定（[設定] > [セキュリティ] > [共有設定]）において、各オブジェクトごとに「Grant Access Using Hierarchies」というチェックボックスがオンになっている必要があります。

ほとんどの標準オブジェクト（取引先、商談、ケースなど）では、この設定はデフォルトで有効になっており、無効にすることはできません。これは、Salesforceが標準的なビジネスプロセスにおいて階層ベースのアクセスが一般的であると想定しているためです。

しかし、カスタムオブジェクトを作成した場合、このチェックボックスはデフォルトでオンになっていますが、管理者が意図的にオフにすることも可能です。例えば、機密性の高い監査ログを保存するカスタムオブジェクトがあり、マネージャーであっても部下のログを閲覧できないようにしたい場合、このチェックボックスをオフにすることで、Role Hierarchyによる自動的なアクセス権の付与を無効化できます。この設定は、オブジェクトレベルでの階層共有を制御する重要なスイッチです。

3. ロールとプロファイルの違い

Salesforceを学び始めた管理者がよく混同するのが、ロールとプロファイルの違いです。

Role (ロール): 「どのレコードを閲覧できるか」を決定します。これはレコードレベルのアクセス権、特に垂直方向の共有を管理します。（例: マネージャーは部下の商談レコードを見ることができる）
Profile (プロファイル): 「何ができるか」を決定します。これはオブジェクトレベルの権限（作成、参照、編集、削除）、項目レベルのセキュリティ、アプリケーションの可視性などを管理します。（例: 営業プロファイルは商談オブジェクトの編集権限を持つが、経理プロファイルは参照権限しか持たない）

たとえRole Hierarchyによってマネージャーが部下のレコードを「見る」権利を得たとしても、そのマネージャーのプロファイルが商談オブジェクトの「編集」権限を持っていなければ、レコードを編集することはできません。この二つは連携して、ユーザーのアクセス権全体を定義します。

示例コード

Role Hierarchyの構成は宣言的な設定（ポイント＆クリック）で行うため、直接的なApexコードで階層を「作成」することは一般的ではありません。しかし、SOQLクエリを使用して現在のロール階層の構造を確認することは、管理やトラブルシューティングにおいて非常に役立ちます。

以下のSOQLクエリは、UserRoleオブジェクトを照会し、組織内に存在するすべてのロールとその親ロール（階層内での上位ロール）の情報を取得します。これにより、階層が意図通りに構成されているかをデータとして確認できます。

// このSOQLクエリは、組織内のすべてのロールとその階層構造を取得します。
// 開発者コンソールのクエリエディタなどで実行できます。

SELECT 
    Id,                  // ロールの一意のID
    Name,                // ロールの表示名 (例: 「東日本営業マネージャー」)
    ParentRoleId,        // このロールの親となるロールのID。最上位のロールではnullになります。
    DeveloperName,       // API参照名。数式やコードで使用されます。
    RollupDescription,   // レポートに表示されるロールの説明
    PortalType           // ロールがポータル/コミュニティ用かどうかを示します (None, CustomerPortal, Partner)
FROM 
    UserRole
ORDER BY 
    ParentRoleId, Name   // 親ロールIDと名前でソートし、階層を分かりやすく表示します。

このクエリを実行すると、各ロールがどのParentRoleIdに紐付いているかが一覧で表示され、組織のロール階層の全体像を把握することができます。例えば、あるロールのParentRoleIdが別のロールのIdと一致する場合、それらの間に親子関係があることがわかります。この情報は、特に複雑な階層を持つ大規模な組織において、アクセス権の問題を調査する際の重要な手がかりとなります。

⚠️ このコードはSalesforce Developerの公式ドキュメントで定義されている標準オブジェクトUserRoleとその項目に基づいています。

注意事項

Role Hierarchyは非常に強力ですが、その挙動を正しく理解し、注意深く設計しないと、意図しないデータ公開やパフォーマンスの問題を引き起こす可能性があります。

権限の誤解

前述の通り、Role Hierarchyはあくまでレコードへのアクセス権を付与するものです。オブジェクトへのアクセス権（CRUD権限）や項目レベルのセキュリティは、プロファイルと権限セットによって制御されます。マネージャーが部下のレコードにアクセスできても、プロファイルで特定の項目が非表示に設定されていれば、その項目を見ることはできません。

パフォーマンスへの影響

レコードの所有者が変更されたり、共有ルールが変更されたりすると、Salesforceはバックグラウンドで「共有再計算」を実行します。Role Hierarchyが非常に深く、複雑である場合や、一つのロールに多数のユーザーが所属している場合、この再計算に時間がかかり、システムのパフォーマンスに影響を与える可能性があります。特に、階層の最下層にいる一人のユーザーが膨大な数のレコード（数百万件など）を所有している「所有権スキュー」と呼ばれる状況は、パフォーマンス劣化の一般的な原因です。

ロールの変更に伴う影響

ユーザーのロールを変更すると、そのユーザーがアクセスできるデータが即座に変わります。異動や昇進などでユーザーのロールを変更する際は、その変更がデータアクセスにどのような影響を与えるかを十分に理解した上で行う必要があります。特に上位ロールへの変更は、予期せぬ広範なデータへのアクセスを許可してしまう可能性があるため、慎重な確認が求められます。

ロールは1ユーザーにつき1つ

一人のユーザーは、一つのロールしか持つことができません。もしユーザーが複数の部門やプロジェクトを兼務しており、それぞれの階層のデータにアクセスする必要がある場合は、Role Hierarchyだけでは要件を満たせません。このような場合は、Sharing Rules（共有ルール）や手動共有、チームセリングなどを組み合わせて対応する必要があります。

まとめとベストプラクティス

Role Hierarchyは、Salesforceのレコードレベルのセキュリティモデルの基盤です。組織のデータアクセス構造を反映し、垂直方向のデータ共有を自動化することで、管理を大幅に簡素化し、一貫性のあるセキュリティポリシーを適用することができます。

効果的なRole Hierarchyを設計・維持するためには、以下のベストプラクティスを推奨します。

1. 組織図ではなく、データアクセス階層をモデル化する

Role Hierarchyは、必ずしも人事上の組織図と完全に一致させる必要はありません。「誰が誰のデータを見る必要があるか」という観点から設計してください。時には組織図と一致しますが、プロジェクトベースのチームなど、データアクセス要件が組織図と異なる場合もあります。

2. 階層をシンプルに保つ

必要以上に複雑な階層は、管理を困難にし、パフォーマンスに悪影響を与える可能性があります。可能な限りフラットな（階層が浅い）構造を維持し、本当に必要なロールのみを作成するよう心がけてください。一般的に、10階層を超えるような深い階層は避けるべきとされています。

3. 適切なツールを使い分ける

Role Hierarchyは万能ではありません。

基本的な垂直アクセス: Role Hierarchyを使用します。
水平または例外的なアクセス (例: 営業部門とサポート部門間でのデータ共有): Sharing Rulesを使用します。
オブジェクトや項目の権限: ProfilesとPermission Setsを使用します。

これらのツールを適切に組み合わせることで、柔軟かつ堅牢なセキュリティモデルを構築できます。

4. 定期的なレビューと監査

ビジネスは常に変化します。組織の変更、人員の異動、新しいビジネス要件の発生に合わせて、Role Hierarchyが依然として適切であるかを定期的にレビューすることが重要です。半年に一度、または年に一度は、階層構造全体を見直し、不要なロールの削除や新しいロールの追加を検討してください。

結論として、適切に設計されたRole Hierarchyは、Salesforce管理者にとって最も強力な武器の一つです。それは、組織のデータを保護し、ユーザーが必要な情報にシームレスにアクセスできる環境を提供するための、最初の、そして最も重要なステップなのです。

にゃんこのSalesforce日記

このブログを検索