Salesforce共有ルールの深掘り：最適なデータセキュリティのためのガイド

背景と適用シナリオ

Salesforce管理者として私たちの重要な責務の一つは、組織のデータを適切に保護し、同時に必要なユーザーが必要な情報にアクセスできるようにすることです。この繊細なバランスを実現するための中核的な機能が、Salesforceの共有モデルです。

共有モデルの基盤となるのは、Organization-Wide Defaults (OWD)、日本語では「組織の共有設定」です。これは、各オブジェクトに対する最も基本的なアクセスレベルを定義します。「非公開(Private)」、「公開/参照のみ(Public Read Only)」、「公開/参照・更新可能(Public Read/Write)」などがあり、通常はセキュリティのベストプラクティスとして、最も制限の厳しい「非公開」から設定を始めます。

しかし、OWDを「非公開」に設定すると、レコードの所有者とその上位ロールのユーザーしかそのレコードを閲覧・編集できなくなります。実際のビジネスシナリオでは、これでは不十分なケースが多々あります。

例えば、以下のようなシナリオを考えてみましょう。

東日本営業チームと西日本営業チームは、通常はそれぞれの担当地域の取引先のみを管理します。しかし、全国規模の大型案件については、互いの進捗を確認し、協力し合う必要があります。
製品Aのサポートチームと製品Bのサポートチームは、それぞれ担当する製品に関連するケースのみを扱います。しかし、製品AとBが連携する複雑な問い合わせについては、互いのケース情報を参照できる必要があります。
特定の業界（例：「金融」）を専門とする営業担当者は、その業界に属するすべての取引先レコードにアクセスできる必要がありますが、取引先の所有者は地域ごとに異なります。

このような、Role Hierarchy (ロール階層) だけでは解決できない、部門横断的または特定の条件に基づくアクセス権の付与を実現するのが、今回解説する Sharing Rules (共有ルール) です。Sharing Rulesは、OWDで制限されたアクセス権を、特定のユーザーグループに対して選択的に拡張するための強力な宣言的ツールです。

原理説明

Sharing Rulesは、OWDの設定を上書きして、追加のアクセス権をユーザーに付与するものです。重要なのは、Sharing Rulesはアクセス権を「付与」するだけであり、「制限」することはできないという点です。つまり、OWDが「公開/参照のみ」であれば、Sharing Rulesで特定のユーザーのアクセスを「非公開」にすることはできません。

Salesforceの共有モデルにおける共有ルールの位置づけ

Salesforceのレコードアクセス権は、以下の階層で決定されます。

Organization-Wide Defaults (組織の共有設定): 最も基本的なアクセスレベルを定義します。
Role Hierarchy (ロール階層): 上位ロールのユーザーが下位ロールのユーザーのレコードにアクセスできるようにします。（垂直方向の共有）
Sharing Rules (共有ルール): OWDやロール階層ではカバーできない例外的なアクセス権を付与します。（水平方向または条件に基づく共有）
Manual Sharing (手動共有): ユーザーが個々のレコードを特定のユーザーやグループと手動で共有します。

Sharing Rulesは、このモデルの中で3番目に評価され、組織全体のルールとして体系的なアクセス制御を実現します。

共有ルールの種類

Sharing Rulesには、主に2つの種類があります。

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

これは、「誰が所有するレコード」を「誰と共有するか」を定義するルールです。レコードの所有者（特定のPublic Groups (公開グループ)、ロール、テリトリーに属するユーザー）を基点として、そのレコードを別の公開グループ、ロール、またはテリトリーのユーザーと共有します。

例: 「東日本営業部」ロールに属するユーザーが所有するすべての商談レコードを、「営業企画部」ロールのユーザーと共有する。

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

これは、レコードの項目値が特定の条件を満たす場合に、そのレコードを「誰と共有するか」を定義するルールです。レコードの所有者に関係なく、レコード自体のデータに基づいて共有が決定されます。

例: 取引先オブジェクトの「業種」項目が「製造」であるすべてのレコードを、「製造業担当チーム」という公開グループと共有する。

アクセスレベル

どちらの種類の共有ルールでも、共有する際のアクセスレベルとして以下のいずれかを設定できます。

参照のみ (Read-Only): 共有されたユーザーはレコードを閲覧できますが、編集はできません。
参照・更新 (Read/Write): 共有されたユーザーはレコードの閲覧と編集ができます。

どのアクセスレベルを選択するかは、共有先のユーザーがそのレコードに対してどのような操作を行う必要があるかに基づいて慎重に決定する必要があります。

共有ルールの設定とメタデータ

Salesforce管理者として、私たちは通常、[設定]メニューから宣言的にSharing Rulesを作成・管理します。しかし、本番環境へのリリースや、複数のSandbox環境間での設定の同期を行う際には、Metadata API を利用して共有ルールをコードとして管理・デプロイすることが一般的です。

これにより、変更管理が容易になり、バージョン管理システム（Gitなど）で設定の履歴を追跡できるようになります。管理者であっても、このようなメタデータの構造を理解しておくことは、より高度な環境管理を行う上で非常に有益です。

サンプルコード（メタデータAPI）

以下は、「取引先」オブジェクトに対する「条件に基づく共有ルール」をMetadata APIで定義した際のXMLファイル（`Account.sharingRules`）の例です。このルールは、「種別」が「Customer - Direct」または「Customer - Channel」であるすべての取引先レコードを、「Project Managers」という名前の公開グループと「参照・更新」権限で共有するものです。

このコードはSalesforce公式ドキュメントに基づいています。

<?xml version="1.0" encoding="UTF-8"?>
<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
    <!-- ここから条件に基づく共有ルールの定義が始まります -->
    <sharingCriteriaRules>
        <!-- fullName: ルールのAPI参照名。オブジェクト名.ルール名 の形式になります -->
        <fullName>Share_Accounts_with_Project_Managers</fullName>
        
        <!-- label: Salesforce UIに表示されるルールの表示ラベル -->
        <label>Share Accounts with Project Managers</label>
        
        <!-- sharedTo: 共有先のグループやロールを定義します -->
        <sharedTo>
            <!-- ここでは公開グループと共有しています -->
            <group>Project_Managers</group>
        </sharedTo>
        
        <!-- criteriaItems: 共有の条件を定義します (1つ目) -->
        <criteriaItems>
            <!-- field: 条件の対象となる項目のAPI参照名 -->
            <field>Type</field>
            <!-- operation: 評価の演算子 (equalsは「等しい」) -->
            <operation>equals</operation>
            <!-- value: 比較する値 -->
            <value>Customer - Direct</value>
        </criteriaItems>
        
        <!-- criteriaItems: 共有の条件を定義します (2つ目) -->
        <criteriaItems>
            <field>Type</field>
            <operation>equals</operation>
            <value>Customer - Channel</value>
        </criteriaItems>
        
        <!-- booleanFilter: 複数の条件を組み合わせるための論理式。この場合、1 OR 2 を意味します -->
        <booleanFilter>1 OR 2</booleanFilter>
        
        <!-- accessLevel: 共有するアクセスレベル (Readは参照のみ, Editは参照・更新) -->
        <accessLevel>Edit</accessLevel>
        
        <!-- description: ルールの説明。なぜこのルールが必要なのかを記述します -->
        <description>Shares customer accounts with the project management team for project setup and execution.</description>
    </sharingCriteriaRules>
</SharingRules>

注意事項

Sharing Rulesは非常に強力ですが、設計と運用にはいくつかの注意点があります。

共有の再計算 (Sharing Recalculation)

共有ルールを新規作成、変更、または削除すると、Salesforceはバックグラウンドで「共有の再計算」プロセスを実行します。これは、既存のすべてのレコードに対して新しいルールを適用し直し、アクセス権を再評価する処理です。

データ量が膨大な組織（数百万レコード以上）では、この再計算に数時間、場合によってはそれ以上かかることがあります。再計算中は、関連する共有設定の変更がロックされるため、計画的に、可能であれば業務時間外に作業を行うことが推奨されます。

パフォーマンスへの影響とガバナ制限

過度に多くの、あるいは複雑な共有ルールは、レコードの保存時やクエリ実行時のパフォーマンスに影響を与える可能性があります。Salesforceにはガバナ制限があり、1つのオブジェクトに対して作成できる共有ルールの総数には上限があります（デフォルトで最大300件、そのうち条件に基づくルールは最大50件など）。

ルールを管理しやすくし、パフォーマンスを維持するためには、個々のユーザーやロールに直接共有するのではなく、Public Groups (公開グループ) を活用することが強く推奨されます。役割や機能に基づいてグループを作成し、ルールはそのグループに対して設定します。将来的にメンバーの追加や削除が必要になった場合でも、共有ルール自体を変更することなく、グループのメンバーシップを更新するだけで済みます。

Guest User Sharing Rules (ゲストユーザー共有ルール)

Experience Cloudサイト（旧Community）などで、認証されていないゲストユーザーにレコードへのアクセスを許可する必要がある場合、特別な「ゲストユーザー共有ルール」を使用します。これは、通常の共有ルールとは異なり、セキュリティ上の理由から非常に厳格な制約があります。作成できるのは条件に基づくルールのみで、アクセスレベルは「参照のみ」に限定されます。ゲストユーザーへのデータ公開は慎重に検討する必要があります。

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

Sharing Rulesは、Salesforceの宣言的なセキュリティ機能を最大限に活用し、複雑な共有要件を満たすための不可欠なツールです。OWDで基盤を固め、ロール階層で垂直的なアクセスを整理し、その上でSharing Rulesを用いて水平方向や例外的なアクセスを制御することで、堅牢かつ柔軟なデータセキュリティモデルを構築できます。

以下に、Salesforce管理者として心掛けるべきベストプラクティスをまとめます。

1. OWDは常に最も制限の厳しい設定から始める

「必要最小権限の原則」に従い、まずはOWDを「非公開」に設定し、その後、ロール階層や共有ルールを使って必要なアクセス権を段階的に付与していくアプローチが最も安全です。

2. まずはロール階層で解決できないか検討する

共有要件が組織の上下関係に基づいている場合、共有ルールを追加する前に、ロール階層の設計が適切であるかを見直しましょう。ロール階層は共有ルールよりもパフォーマンスへの影響が少ないため、優先的に活用すべきです。

3. 公開グループ (Public Groups) を積極的に活用する

共有の対象が複数のユーザーにまたがる場合は、必ず公開グループを作成して利用しましょう。これにより、ルールの数が削減され、将来的なメンテナンスが劇的に簡素化されます。

4. 条件に基づくルールの有効活用

共有の要件がレコードの所有者ではなく、レコードの特性（ステータス、種別、地域など）に基づいている場合は、所有者に基づくルールよりも条件に基づくルールの方が適しています。

5. 文書化とテストを徹底する

なぜその共有ルールが必要なのか、誰が何のためにアクセスするのかを、ルールの説明欄や外部の設計書に必ず記載しましょう。また、新しいルールを本番環境に適用する前には、必ずSandbox環境で、影響を受けるユーザープロファイルを使って徹底的にテストを行ってください。

これらのプラクティスを実践することで、Salesforce管理者は組織のデータを安全に保ちながら、ビジネスの要求に応える効果的なデータ共有戦略を実現することができます。

にゃんこのSalesforce日記

このブログを検索