Salesforce共有ルールの徹底解説：最適なレコードアクセス権限を実現する管理者ガイド

日付:

背景と適用シーン

Salesforce管理者として、私たちが日々直面する最も重要な課題の一つは、データセキュリティとアクセシビリティのバランスを適切に保つことです。誰がどのデータにアクセスできるかを制御することは、ビジネスプロセスの整合性を保ち、機密情報を保護するために不可欠です。この複雑な要件を実現するためのSalesforceのセキュリティモデルの中核をなすのが、Organization-Wide Defaults (OWD - 組織の共有設定) です。OWDは、組織内の全ユーザーに対するレコードアクセスのベースライン、つまり最も制限の厳しいアクセスレベルを定義します。例えば、取引先オブジェクトのOWDを「非公開」に設定すると、デフォルトではレコードの所有者とその上位ロールのユーザーしかそのレコードを閲覧・編集できません。

しかし、実際のビジネスシナリオはもっと複雑です。OWDでアクセスを制限した後、特定の条件下で例外的にアクセス権を広げる必要が出てきます。ここで登場するのが Sharing Rules (共有ルール) です。共有ルールは、OWDやロール階層ではアクセスできないレコードへのアクセス権を、特定のユーザーグループに選択的に付与するための強力なツールです。

具体的な適用シーンをいくつか考えてみましょう。

シナリオ1：地域別営業チーム間のコラボレーション

ある企業では、東日本営業チームと西日本営業チームが存在します。商談の所有権は各営業担当者にありますが、チームメンバーは担当地域内のすべての商談を閲覧し、協力して案件を進める必要があります。この場合、所有者に関わらず「東日本」地域の商談を東日本営業チームのメンバー全員に共有し、「西日本」地域の商談を西日本営業チームに共有するルールを作成できます。

シナリオ2：カスタマーサポートと重要顧客

サポート部門は、すべての顧客からの問い合わせ（ケース）に対応しますが、特に「プラチナ」レベルの重要顧客については、サポートチーム全体がケースを閲覧・編集できる必要があります。これにより、担当者が不在の場合でも、他のメンバーが迅速に対応を引き継ぐことができます。この要件は、取引先の種別が「プラチナ」であるすべてのケースを、サポートチームの公開グループに共有するルールで実現できます。

シナリオ3：マーケティング部門によるリード分析

マーケティングチームは、確度の高いリード（例えば、リードソースが「Webinar」で状況が「進行中」のリード）に対してキャンペーンを計画したいと考えています。しかし、リードの所有権はインサイドセールスチームにあります。この場合、特定の条件を満たすリードへの参照のみアクセス権をマーケティングチームに付与する共有ルールを作成すれば、彼らは個人情報を編集することなく、分析やリスト作成が可能になります。

このように、共有ルールは「誰のレコードを（Who）」「誰に（Whom）」「どのレベルのアクセス権で（What Level）」共有するかを定義することで、固定的になりがちなアクセス権モデルに柔軟性をもたらし、組織内のコラボレーションを促進する上で欠かせない機能なのです。

原理説明

Sharing Rulesの動作原理を理解するためには、まずその構成要素と種類を把握することが重要です。共有ルールは、大きく分けて2つのタイプが存在します。

1. 所有者に基づく共有ルール (Owner-based Sharing Rules)

このタイプのルールは、「誰が所有するレコードを共有するか」を基準に設定されます。共有元の所有者は、以下のいずれかのグループ単位で指定します。

  • Public Groups (公開グループ): 管理者が任意に作成できるユーザーの集合です。個々のユーザー、他のグループ、ロール、テリトリーなどをメンバーとして含めることができ、非常に柔軟なグルーピングが可能です。
  • Roles (ロール): 組織の役職階層に基づいたグループです。例えば、「部長」ロールが所有するレコードを、「課長」ロールに共有する、といった設定が可能です。
  • Roles and Subordinates (ロール＆下位ロール): 指定したロールとその階層下にいるすべてのユーザーを対象とします。「事業部長と配下全員」が所有するレコード、という指定ができます。
  • Territories (テリトリー): テリトリー管理機能を使用している場合に選択可能です。特定の営業テリトリーに所属するユーザーが所有するレコードを共有します。

これらのグループが所有するレコードを、別のグループ（公開グループ、ロール、テリトリーなど）に共有します。例えば、「東日本営業ロールのユーザーが所有するすべての商談を、東日本営業サポート公開グループに共有する」といった設定がこれに該当します。

2. 条件に基づく共有ルール (Criteria-based Sharing Rules)

このタイプのルールは、レコードの所有者に関係なく、「レコードが持つ特定の条件を満たすかどうか」を基準に設定されます。レコードの項目値を評価し、条件に一致したレコードを共有します。

例えば、「取引先の業種が『製造業』である」や「ケースの優先度が『高』である」といった条件を設定できます。このルールは非常に動的であり、レコードが作成・更新されて条件を満たすようになると自動的に共有され、条件を満たさなくなると共有が解除されます。前述のシナリオ2や3は、この条件に基づく共有ルールの典型的な例です。

アクセスレベル

どちらのタイプの共有ルールでも、共有先に付与するアクセス権のレベルを以下のいずれかから選択します。

  • Read-Only (参照のみ): 共有されたレコードを閲覧できますが、編集、削除、所有者の変更はできません。
  • Read/Write (参照・更新): 共有されたレコードの閲覧と編集が可能です。ただし、削除や所有者の変更は、別途プロファイルや権限セットで許可されていない限りできません。

注意点として、共有ルールで付与できるアクセス権は、オブジェクトに対するプロファイルの権限を超えることはありません。例えば、あるユーザーのプロファイルが取引先オブジェクトに対して参照権限しか持っていない場合、共有ルールで参照・更新アクセスを付与しても、そのユーザーは取引先を編集することはできません。

内部的な仕組み: Shareオブジェクト

Salesforceの内部では、共有ルールが適用されると、Share Object (共有オブジェクト) と呼ばれる特殊なオブジェクトにレコードが作成されます。例えば、取引先オブジェクトを共有すると `AccountShare` オブジェクトに、カスタムオブジェクト `MyCustom__c` を共有すると `MyCustom__Share` オブジェクトにレコードが挿入されます。

このShareレコードには、共有対象のレコードID、共有先のユーザーIDまたはグループID、アクセスレベル、そして共有の理由を示す `RowCause` という項目が含まれています。共有ルールによって作成されたShareレコードの `RowCause` には `Rule` という値が設定されます。この仕組みを理解することで、なぜ共有ルールの変更に再計算が必要なのか、といった技術的な背景をより深く把握できます。

サンプルコード

Salesforce管理者として共有ルールを設定する際は、主にSalesforceのUI（設定画面）を使用します。しかし、変更セットやメタデータAPIを介して環境間で設定を移行する場合、共有ルールはXMLファイルとして表現されます。ここでは、メタデータAPIで共有ルールを定義する際のXML形式のサンプルを見てみましょう。これにより、共有ルールの構造的な理解が深まります。

以下のサンプルは、「年間売上が100万ドルを超え、かつ有効な取引先を、営業担当公開グループに参照・更新アクセス権で共有する」という条件に基づく共有ルールを `Account.sharingRules` メタデータファイルで定義した例です。 

<?xml version="1.0" encoding="UTF-8"?>
<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
    <!-- ここから条件に基づく共有ルールの定義 -->
    <sharingCriteriaRules>
        <!-- fullName: API参照名。組織内で一意である必要があります -->
        <fullName>Share_High_Value_Active_Accounts</fullName>
        
        <!-- label: Salesforce UIに表示されるルール名 -->
        <label>重要かつ有効な取引先の共有</label>
        
        <!-- sharedTo: 共有先のグループを定義します -->
        <sharedTo>
            <!-- group: 公開グループのAPI参照名を指定します -->
            <group>Sales_Team_Group</group>
        </sharedTo>
        
        <!-- criteriaItems: 共有の条件を定義します (複数指定可能) -->
        <criteriaItems>
            <!-- field: 条件の対象となる項目のAPI参照名 -->
            <field>AnnualRevenue</field>
            <!-- operation: 評価演算子 (より大きい) -->
            <operation>greaterThan</operation>
            <!-- value: 比較する値 -->
            <value>1000000</value>
        </criteriaItems>
        <criteriaItems>
            <field>Active__c</field>
            <!-- operation: 評価演算子 (次と等しい) -->
            <operation>equals</operation>
            <value>Yes</value>
        </criteriaItems>
        
        <!-- accessLevel: 付与するアクセスレベル (参照・更新) -->
        <accessLevel>ReadWrite</accessLevel>
        
        <!-- description: ルールの説明 (任意) -->
        <description>年間売上が100万ドルを超え、かつ有効な取引先を営業チームに共有します。</description>
    </sharingCriteriaRules>
</SharingRules>

このXMLファイルは、`package.xml` で指定することで、Salesforce DXやAnt移行ツールなどを用いて本番環境や他のSandboxにデプロイすることができます。管理者であっても、このようなメタデータの構造を理解しておくことは、デプロイ時のトラブルシューティングや開発者との円滑なコミュニケーションに役立ちます。

注意事項

共有ルールは非常に便利ですが、設計や運用を誤るとパフォーマンスの低下や意図しないデータ公開につながる可能性があります。管理者として特に注意すべき点を以下に挙げます。

1. 共有の再計算 (Sharing Recalculation)

新しい共有ルールを作成したり、既存のルールを編集・削除したりすると、Salesforceはバックグラウンドで共有の再計算を実行します。これは、組織内のすべての対象レコードを評価し直し、`Share` レコードを適切に作成または削除するプロセスです。データ量が数百万件を超える大規模な組織では、この再計算に数時間、場合によってはそれ以上かかることがあります。再計算中は、一部の管理操作（例：ロール階層の変更）がロックされる可能性があるため、ルールの変更は業務時間外に計画的に行うことが推奨されます。

2. パフォーマンスへの影響

共有ルール、特に複雑な条件を持つルールが多数存在すると、レコードの保存処理のパフォーマンスに影響を与える可能性があります。ユーザーがレコードを保存するたびに、Salesforceはそのレコードがどの共有ルールに該当するかを評価する必要があるためです。不要になったルールは定期的に見直し、削除または簡素化することを検討してください。

3. ルールの上限数

Salesforceでは、1つのオブジェクトに対して作成できる共有ルールの数に上限があります。通常、所有者に基づくルールと条件に基づくルールは、それぞれ最大300個までです（エディションやオブジェクトによって異なる場合があります）。上限に近づいている場合は、ルールを統合できないか検討が必要です。例えば、複数のルールが同じグループに共有している場合、公開グループのメンバーシップを調整したり、ルールの条件をより包括的にしたりすることで、ルール数を削減できるかもしれません。

4. 他の共有メカニズムとの相互作用

Salesforceのレコードアクセス権は、単一の機能ではなく、複数のメカニズムが階層的に作用して決定されます。管理者はこの全体像を理解しておく必要があります。

  1. 組織の共有設定 (OWD): ベースラインとなる最も制限的な設定。
  2. ロール階層: 上位ロールのユーザーに下位ロールのユーザーが所有するレコードへのアクセス権を自動的に付与。
  3. 共有ルール: OWDとロール階層の例外として、横方向（同階層）や特定のグループにアクセスを拡大。
  4. 手動共有 (Manual Sharing): ユーザーが個々のレコードを他のユーザーやグループに手動で共有。
  5. Apexによる共有管理 (Apex Managed Sharing): 開発者がApexコードを用いて、より複雑で動的な共有ロジックを実装。

共有ルールは、この階層の3番目に位置することを意識し、他の機能とどのように連携するかを考慮して設計する必要があります。

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

Sharing Rulesは、Salesforceの宣言的な（コードを書かない）セキュリティ機能の要であり、OWDで固めたセキュリティ基盤の上に、ビジネス要件に応じた柔軟なアクセス権を提供する強力なツールです。所有者やレコードの属性に基づいてアクセスを拡大することで、チーム間のコラボレーションを促進し、業務効率を向上させることができます。

最後に、Salesforce管理者として共有ルールを効果的かつ安全に活用するためのベストプラクティスをまとめます。

1. OWDは常に厳しく: データアクセスの基本原則は「最小権限の原則」です。まずはOWDを可能な限り制限的（例：「非公開」）に設定し、必要なアクセス権を共有ルールや他の機能で段階的に付与していくアプローチを取りましょう。

2. ロール階層を優先する: 役職に基づいた上下関係のアクセス権（上司が部下のデータを見るなど）は、ロール階層で実現するのが最もシンプルで効率的です。共有ルールは、ロール階層ではカバーできない横方向の共有に使いましょう。

3. 公開グループを積極的に活用する: 共有先に個々のユーザーやロールを多数指定するのではなく、公開グループを作成して管理を一本化しましょう。将来的にメンバーの追加や削除が必要になった場合でも、共有ルール自体を変更する必要がなくなり、メンテナンス性が大幅に向上します。

4. ドキュメント化を徹底する: なぜその共有ルールが必要なのか、ビジネス上の背景や目的をルールの説明欄や別途管理ドキュメントに必ず記載してください。組織が成長し、管理者が交代しても、設定の意図が明確に伝わるようにすることが重要です。

5. Sandboxで必ずテストする: 新しい共有ルールを本番環境に適用する前に、必ずSandboxでテストを行ってください。意図した通りにアクセス権が付与されるか、逆にアクセスできてはいけないユーザーがアクセスできないか、複数のユーザープロファイルで入念に確認します。特に、大規模な組織では再計算の影響も考慮に入れるべきです。

6. パフォーマンスを意識する: ルールはシンプルに保ち、不要になったルールは定期的に棚卸ししましょう。特に、頻繁に更新されるオブジェクトに対する複雑な条件の共有ルールは、パフォーマンスに与える影響を慎重に評価する必要があります。

これらのベストプラクティスを遵守することで、Salesforce管理者はSharing Rulesを最大限に活用し、セキュアで効率的なデータアクセス環境を構築・維持することができるでしょう。

コメント

コメントを投稿