Salesforce公開グループのメンバー棚卸し｜共有ルールの過剰付与を防ぐ方法
Salesforceの公開グループは、共有ルールを読みやすくする便利なまとまりです。一方で、ユーザーだけでなくロール、配下ロール、別の公開グループなどを含められるため、設定画面に見える直接メンバーだけを確認しても、実際にレコードへ到達できる人を把握できないことがあります。異動や退職の後も古いロールや子グループが残れば、意図しない閲覧範囲が静かに広がります。
棚卸しでは、公開グループごとに直接メンバー、ロール経由の対象者、子グループを再帰的に展開し、そのグループを参照する共有ルール、レポート・ダッシュボードフォルダ、リストビューなどを照合します。そのうえで、業務上の根拠がないメンバーを外し、変更前後の代表レコードを実際の利用者権限で確認します。プロファイルや権限セットだけを見ても、レコード単位の共有範囲は確定できません。
公開グループの棚卸しが完了するのは、メンバー一覧を見た時ではなく、直接・間接の到達者と共有先を照合し、不要なアクセスを削除して実ユーザーで再確認できた時です。
本記事のポイント
- 公開グループは直接ユーザーだけでなく、ロール、配下ロール、子グループを最終利用者まで展開して確認します。
- View Summaryと設定情報から共有ルール、フォルダ、リストビュー、親グループを照合し、メンバー変更の波及先を固定します。
- 変更後は必要な人が見える正の検証と、不要な人が見えない負の検証を代表レコードで行い、実効アクセスまで閉じます。
公開グループがレコード共有へ与える影響を理解する
Salesforceの公式Trailheadでは、公開グループを、個々のユーザー、他のグループ、ロール、テリトリーなど、共通の役割を持つ対象の集合として説明しています。複数のロールや個人へ同じアクセスを渡す場合、共有ルールの受け手を公開グループにすると、ルールを作りやすく、後から意図を読み取りやすくなります。
共有ルールは、組織の共有設定で閉じられているレコードへのアクセスを追加する仕組みです。公開グループを共有先に指定すると、そのグループの構成が変わるたびに、同じルールが届く利用者も変わります。公開グループはオブジェクト権限や項目権限の代わりではありませんが、必要なオブジェクト権限を持つ利用者に、どのレコードまで見せるかを広げる重要な部品です。
公開グループの詳細にある「View Summary」では、Salesforce公式の案内上、共有ルール、レポート・ダッシュボードフォルダ、リストビュー、その公開グループが追加されている別の公開グループを確認できます。最初にこの依存一覧を保存すると、メンバー変更がどこへ波及するかを追いやすくなります。権限変更を日常業務として管理する全体像は、CRM管理者の業務一覧と合わせて役割分担を決めると整理しやすくなります。
| 確認対象 | 見る情報 | 見落とした場合のリスク | 残す証拠 |
|---|---|---|---|
| 直接ユーザー | 在籍、所属、職務、最終利用、承認根拠 | 退職者・異動者のアクセスが残る | ユーザーID、所属、追加理由、承認者 |
| ロール | 現在のロール割当、配下を含むか | 組織変更で想定外の利用者が増える | ロール名、含有方式、対象人数 |
| 子グループ | 直接・間接メンバー、さらに下のネスト | 画面上の名簿より到達者が多くなる | 親子関係、展開結果、重複ユーザー |
| 共有ルール | 対象オブジェクト、条件、共有先、アクセスレベル | 変更範囲を誤り、必要な業務も止める | ルール名、対象、権限、所有部門 |
| フォルダ・リスト | レポート、ダッシュボード、リストビューの共有 | レコード以外の分析・一覧データが残る | 共有先、アクセスレベル、所有者 |
ここで大切なのは、「公開グループにいる」ことと「すべてのSalesforceデータを見られる」ことを同一視しないことです。実効アクセスは、組織の共有設定、ロール階層、共有ルール、手動共有、チーム、テリトリー、オブジェクト権限、項目権限などの組み合わせで決まります。公開グループの棚卸しは、そのうちグループ経由の追加アクセスと依存先を明らかにする作業です。
直接・間接メンバーを一つの台帳へ展開する
最初に、公開グループを一行ずつ並べた台帳を作ります。グループID、表示名、API名、説明、所有部門、業務目的、責任者、最終確認日、直接メンバー数、子グループ数、参照先を記録します。名前だけでは「営業共有」「管理者用」のような古い意図を判断できないため、現在の業務目的と承認者を必ず別項目で持ちます。
次にメンバーを型ごとに分けます。ユーザーは在籍・有効状態・所属・職務を照合し、ロールは現在割り当てられている利用者を展開します。「ロールと内部下位ロール」など配下を含む指定は、現在の組織図に沿って対象が増減するため、人数だけでなく該当ユーザーIDの一覧まで固定します。別の公開グループを含む場合は、その子グループをさらに展開し、最終的に到達する一意の利用者集合を作ります。
同じ人が直接ユーザー、ロール、子グループの複数経路から到達することがあります。重複を消した最終人数だけを残すと、どの経路を外せばよいか分かりません。利用者ごとに「直接」「ロール」「子グループA→子グループB」のような到達経路も残します。これにより、不要な直接追加だけを消しても、別経路でアクセスが残る状況を検知できます。
| メンバー型 | 展開方法 | 人事イベントで見る点 | 削除前の確認 |
|---|---|---|---|
| 個別ユーザー | ユーザーIDで一対一に照合 | 退職、休職、異動、職務変更 | 例外付与の期限と業務根拠 |
| ロール | 現在のロール割当をユーザーへ展開 | 組織改編、兼務、空席、代理担当 | 配下を含む設定と対象範囲 |
| 子グループ | 親子を再帰展開し経路を保持 | 子グループ側の追加・削除 | 別グループからの重複到達 |
| テリトリー等 | 現在の割当と有効範囲を展開 | 担当区域・販売体制の変更 | 対象オブジェクトと運用モデル |
棚卸しをCSVの一回限りの作業にせず、ユーザー・ロール・グループ・共有ルールのIDをキーにした差分として残します。前回から追加された経路、削除された経路、所有部門が変わったグループを抽出すれば、全件を毎回ゼロから読む負荷を下げられます。変更理由と承認証跡をそろえる考え方は、監査証跡の設計方法でも確認できます。
共有ルールの過剰付与を防ぐ7ステップ
公開グループの目的は、誰に何を見せるかを分かりやすく管理することです。棚卸しでは、グループの名簿から始めるのではなく、業務目的、依存先、到達者、実効アクセス、変更後検証の順に進めます。次の7ステップを同じ台帳で管理すると、名簿の整理だけで共有範囲を壊すことを避けやすくなります。
- 対象と責任者を確定する。全公開グループを抽出し、業務目的、所有部門、承認者、見直し周期を割り当てます。責任者不明のグループは、すぐ削除せず利用停止候補として依存調査へ回します。
- View Summaryで依存先を記録する。共有ルール、レポート・ダッシュボードフォルダ、リストビュー、他グループへの所属を保存します。画面で追えない利用箇所はMetadata APIや設定情報も使い、グループID・API名で照合します。
- 直接・間接メンバーを展開する。ユーザー、ロール、配下ロール、子グループ、テリトリー等を最終利用者まで展開し、重複前の到達経路と重複後の一意ユーザーを両方残します。
- 人事・委託先台帳と照合する。退職、異動、休職、兼務終了、委託終了、緊急対応期限切れを確認します。有効ユーザーであることだけを在籍・業務必要性の根拠にしません。
- 共有先ごとの必要最小限を判定する。オブジェクト、条件、アクセスレベル、対象レコード、利用頻度を確認し、閲覧だけで足りるのか、編集が必要なのか、グループ全体である必要があるのかを決めます。
- 小さく変更して再計算を待つ。一度に複数の親子グループを変えず、影響の小さい直接追加や期限切れ例外から修正します。共有再計算中に次の変更を重ねず、ジョブとエラーを確認します。
- 代表ユーザーと代表レコードで閉じる。必要な人が見えること、不要な人が見えないこと、レポート・フォルダ・リストビューが意図どおりであることを確認し、変更前後の結果を証跡として残します。
共有ルールはアクセスを追加する仕組みなので、設定が複雑になるほど「どの経路が最終的な閲覧を許したか」が分かりにくくなります。公開グループを小さく保ち、名称に業務目的を含め、個別ユーザーを恒久的に足し続けないことが有効です。権限モデルを外部連携まで広げる場合は、SlackとSalesforce連携の権限設計でも統合ユーザーと実効権限の分け方を確認できます。
変更前後の実効アクセスを安全に検証する
削除候補を見つけても、先に公開グループから外すと、営業・サポート・承認業務が突然止まる可能性があります。変更前に、対象グループを参照する共有ルールごとに、代表オブジェクト、代表レコード、必要な利用者、不要な利用者を決めます。閲覧と編集を分け、フォルダやリストビューも別の検証項目にします。
検証は管理者の画面だけで終えません。管理者はほぼすべてを見られるため、一般営業、マネージャー、営業企画、外部委託など、実際の権限に近いテストユーザーまたは承認済みの検証方法を使います。必要な対象ではレコードの共有理由も確認し、公開グループ以外のロール階層、チーム、手動共有、テリトリーからアクセスが残っていないかを切り分けます。
| 変更 | 事前確認 | 変更後の正の検証 | 変更後の負の検証 |
|---|---|---|---|
| 直接ユーザーを削除 | 別経路、例外期限、担当案件 | 必要な別経路で業務継続 | 不要レコードが見えない |
| ロールを削除・変更 | 配下人数、組織変更、共有先 | 対象部門の必要アクセス | 旧部門・旧配下の遮断 |
| 子グループを外す | ネスト先、重複経路、依存ルール | 残す子グループの業務継続 | 外した集合の到達不可 |
| 共有ルールを変更 | 条件、所有者、アクセスレベル | 条件内レコードの閲覧・編集 | 条件外レコードの非表示 |
問題が起きた場合は、グループ全体を元へ戻す前に、変更単位、共有再計算、別経路の有無を確認します。ロールや子グループをまとめて戻すと、不要だったアクセスも一緒に復活します。変更ID、対象グループ、実施者、実施時刻、前後メンバー、共有先、検証ユーザー、代表レコード、結果を一つの記録に残します。運用担当の人数と承認分離は、CRM運用体制の役割分担を基準に決められます。
よくある質問
Salesforceの公開グループはどの機能の権限に影響しますか？
公開グループは共有ルールの共有先として使われるほか、レポート・ダッシュボードフォルダ、リストビュー、他の公開グループなどから参照されます。実効アクセスは組織の共有設定、ロール階層、オブジェクト権限、項目権限などとの組み合わせで決まります。
公開グループのユーザー・ロール・子グループをどう棚卸ししますか？
直接ユーザーを人事台帳と照合し、ロールと配下ロールを現在の割当ユーザーへ展開し、子グループは最終利用者まで再帰的に展開します。一意ユーザーだけでなく、各ユーザーがどの経路から到達したかも記録します。
退職・異動後の過剰共有をどう検知しますか？
ユーザーの有効・無効だけでなく、所属、職務、委託期限、ロール割当、子グループ所属を前回結果と比較します。削除後も別のロールや子グループ経由で到達することがあるため、代表レコードを本人相当の権限で確認します。
グループ変更前に共有ルールへの影響をどう確認しますか？
View Summaryや設定情報から参照中の共有ルール、フォルダ、リストビュー、親グループを一覧化し、対象オブジェクト・条件・アクセスレベル・代表利用者を決めます。変更は小さく分け、共有再計算後に必要アクセスと不要アクセスの両方を確認します。
公開グループを削除すれば関連するアクセスも安全に消えますか？
削除だけでは安全とは限りません。別の公開グループ、ロール階層、手動共有、チーム、テリトリーなどから同じ利用者へアクセスが残る場合があります。また、公開グループを参照する業務が止まる可能性もあるため、依存先と代替経路を確認してから変更します。
プロファイルと権限セットの棚卸しだけでは足りませんか？
足りません。プロファイルと権限セットは主にオブジェクト・項目・機能への権限を決めますが、どのレコードを見られるかは組織の共有設定、ロール階層、共有ルールなどにも左右されます。公開グループは追加のレコード共有先として別に確認します。
関連ページと関連記事
- CRM管理者が日次・月次で確認する業務一覧
- CRM運用体制と権限変更の役割分担
- SlackとSalesforce連携の権限設計
- 権限変更を説明できる監査証跡の設計
- Salesforceから顧客データを移行する手順
