📅 2026年10月10日 ⏱️ 9分で読めます

Salesforceの管理の委任を棚卸しする方法｜対象ユーザーと操作範囲を確認

執筆ファネルAi編集部編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年10月9日

Salesforceの担当者が異動したり、管理作業を部門へ分けたりすると、委任管理グループの設定だけを見て「この人はこの部門だけを管理できる」と判断しがちです。しかし、複数グループへの所属や、プロファイル・権限セットなど別経路の権限が重なると、実際に扱える対象は設定画面の一つのグループから想像する範囲を超えることがあります。

棚卸しでは、委任グループごとの対象と操作を確認したうえで、担当者を横断して複数グループと独立した権限を照合します。ここではSalesforceの内部ユーザーに対する委任管理を対象に、設定の読み方、重複の見つけ方、変更後の確かめ方をまとめます。OAuthアプリ、レコード共有、外部ポータルの委任管理は別の確認範囲です。

先に押さえたいのは、委任管理を「管理者を減らす設定」だけでなく、「誰が、どの対象に、何をできるかを確認する運用」として扱うことです。画面上の設定と実際の担当者一覧をつなげて初めて、異動や役割変更の影響を判断できます。

本記事のポイント

委任管理は、設定したグループや対象に管理作業を任せる仕組みであり、他経路の権限まで遮断する境界ではありません。
担当者が複数の委任グループに所属する場合、各グループの設定を別々に見ても、実際に扱える対象を狭く見積もるおそれがあります。
異動後はグループ設定と独立した権限付与を人ごとに照合し、必要・禁止の操作をテストして根拠を保存します。

委任グループとデータ共有を分けて読む

Salesforce公式HelpのDelegate Administrative Dutiesでは、Salesforce ClassicとLightning ExperienceのEnterprise、Performance、Unlimited、Developer、Database.comエディションが対象として示されています。契約エディションと利用者の権限を確認してから、組織の設定を点検します。

委任管理では、委任先のユーザーと、そのユーザーが管理できる対象や操作をグループ単位で設定します。対象として、特定のロールとその配下、指定したプロファイル、権限セットや公開グループなどが関係します。実際に使える範囲は、組織でそのグループに登録した内容を確認して判断します。

ここでいう委任グループは、レコードへのアクセス範囲を決める「公開グループ」と同じものではありません。名前に「グループ」が含まれていても、前者は管理作業を委ねる設定、後者は共有ルールなどで利用する対象者のまとまりです。委任管理グループに公開グループの管理を許可する構成もあり得るため、二つの設定を同じ一覧として扱わず、管理権限とデータ共有を別の列で記録します。公開グループのメンバー構成を見直す手順も、共有側の確認を切り分ける際に役立ちます。

委任管理者を設定する公式手順に沿って確認するときは、Setup の Quick Find から「Delegated Administration」を開き、グループの一覧と関連する担当者・管理対象をたどります。ログインアクセスを委ねる設定がある場合も、チェック欄だけで判断せず、誰がどの条件でアクセスを許可するかを組織側の設定と合わせて確認してください。設定変更の権限を持つ管理者と、委任された管理者が同じ画面を同じ範囲で操作できるとは限りません。

棚卸しの目的は、委任グループの数を減らすことではありません。業務上必要な担当者、対象、操作が現在の設定と一致しているかを説明できる状態にすることです。承認者、運用責任者、実作業者が異なる場合は、それぞれの役割も記録に残すと、設定の意図と実際の運用を照らしやすくなります。

グループ設定とユーザー一覧を突き合わせる

棚卸しでは、まずグループごとの設定を採取し、その後に委任管理者ごとの所属を横断してまとめます。片方だけでは見落としが残ります。グループ単位の表は許可範囲を読み取るのに向きますが、同じ人が複数のグループに参加している事実や、別の付与経路から得ている権限までは一目で分からないからです。

対象の委任グループを洗い出す。有効なグループ、登録済みの委任管理者、管理対象に指定されたロール・配下ロール、プロファイル、権限セット、公開グループを記録します。設定が空欄の項目も、未確認と区別して残します。
担当者ごとに所属を集約する。氏名やユーザー識別子で名寄せし、一人が属するグループをすべて並べます。部署名だけでは同姓同名や異動前後の追跡が難しいため、変更前後を比較できる識別情報を使います。
想定する操作と管理対象を照合する。「どの利用者・ロールを対象にするか」と「ユーザー管理、権限セットの割り当て、公開グループの管理など何を許すか」を別々に整理します。委任グループの設定に列挙されているものと、担当者の実務上の役割を並べて、不要な対象・不足している対象を確認します。
独立した権限付与を追加で確認する。担当者のプロファイル、権限セット、権限セットグループ、ロールなど、委任管理グループ以外から得る権限を調べます。委任設定の一覧に見えない権限を「ない」と扱わないための工程です。
変更後の確認者と証跡を決める。変更を承認する人、設定を実施する人、確認結果を保存する場所を先に決めます。後から画面を見直せるよう、取得日時、対象組織、変更前後、判断理由を記録します。

運用表は、一人を一行にして、委任管理者か、所属するグループ、管理対象ロールと配下、対象プロファイル、割り当て可能な権限セット、管理する公開グループ、別経路の権限、許可・禁止のテスト結果、承認者を列にすると使いやすくなります。グループごとの設定一覧と担当者ごとの集約表は別に保管し、ユーザー識別子でつなぎます。これにより、設定の変更と担当者の異動のどちらからでも影響を追えます。

Salesforceの管理作業を役割別に洗い出す場合は、CRM管理タスクを棚卸しするチェックリストを使うと、設定を日々の作業と対応づけやすくなります。表へ単に「管理者」と書くのではなく、対象ユーザーや操作を具体化して記録してください。

管理の委任の棚卸しを、委任グループ、対象ユーザー、許可する操作、重複・別権限、解除後の確認の五つの観点で示した図。 — グループの設定だけでなく、担当者の複数所属と別経路の権限を照合し、変更後に必要な操作と禁止した操作を確かめます。

複数グループと独立した権限を横断する

委任グループを複数作っても、それぞれが互いに越えられない箱になるとは限りません。Salesforce公式Helpの説明では、一人の委任管理者が複数の委任グループに割り当てられている場合、その担当者は所属するグループ全体の対象を管理できます。たとえば、Aグループの担当者がBグループのユーザーに割り当てられた権限セットを扱うケースがあり得ます。グループを別々に点検しただけでは、担当者が横断して扱える範囲を見落とします。

さらに、委任管理グループは、その担当者に別途付与済みの権限を取り消したり、限定したりする仕組みではありません。プロファイルや権限セットなど別の経路で得ている権限は加算される前提で確認します。委任管理者から外すことだけをもって、独立した付与もなくなったと判断しないでください。権限セットの割り当てを委任できることと、権限セット自体を編集できることも別です。

たとえば、営業部を対象にするAグループと西日本拠点を対象にするBグループがあり、同じ担当者が両方に登録されている状況を考えます。棚卸しでは「Aは営業部、Bは西日本」と書くだけでなく、その担当者の行にAとBの両方を記載し、両グループで許可された管理対象と操作を合算して確認します。そこへプロファイルや独立した権限セットの付与があれば、別欄に並べて評価します。この例のように、グループを設計した意図と、ユーザー単位の有効な範囲を二段階で照合するのが要点です。

誤った範囲でユーザーを管理できないことを確かめるには、実データや本番アカウントで試すのではなく、承認済みのテスト利用者を用意したSandboxで、必要な操作ができるケースと、対象外の操作ができないケースを両方確認します。パスワードのリセットやログインアクセスの設定など、本人や本番環境へ影響する操作を検証目的で安易に実行しないでください。結果は「操作名」「対象」「期待結果」「実際の結果」「実施者」「日時」とともに保存します。

棚卸しの完了は、権限の一覧を保存した時点ではなく、誰がどの対象に何をできるかを根拠と一緒に説明できた時点です。意図した操作ができない場合は、まず設定の誤りか独立した付与の不足かを切り分け、広い権限を追加してテストを通す方法は避けます。

変更後に再テストし、証跡の範囲を残す

異動や役割変更では、委任グループから人を追加・削除するだけで完了にせず、グループの管理対象、担当者の他グループ所属、独立した権限付与を変更前後で比較します。ロールや公開グループの変更では共有計算に影響する場合もあるため、管理作業の委任とレコードの共有範囲は別々に確認します。レポートフォルダの閲覧者や共有ルールまで点検する場合は、Salesforceのレポートフォルダ権限を見直す方法を参照し、管理権限の一覧と混ぜないようにしてください。

設定変更の履歴を確認する際は、Setup Audit Trailの公式説明に沿って、設定変更の履歴を証跡の一つとして使えます。画面には直近20件の変更が表示され、ダウンロードでは最大180日分を取得できます。履歴を表示するには「View Setup and Configuration」が必要で、180日を過ぎた記録は削除されます。委任グループや管理対象の変更、委任管理者による設定変更をたどる手がかりになりますが、全てのデータ閲覧やユーザー操作を記録する包括的な利用監査ログとしては扱えません。

そのため、変更の根拠、設定前後の一覧、Sandboxでの許可・禁止テスト、承認記録を組み合わせて保管します。監査証跡から確認できる期間を超える前に保存が必要な記録がないかを決めておき、後日確認する人が変更理由と影響範囲を追える形にします。記録の保存期間や確認頻度に一律の正解があると決めつけず、組織の手続きに沿って定めてください。

よくある質問

委任グループは公開グループと同じですか？

別の設定です。委任グループは管理作業を任せる担当者と対象を定め、公開グループは共有設定などで利用するユーザーのまとまりです。委任管理グループに公開グループの管理を認める構成はありますが、二つの設定一覧と確認目的を分けてください。

委任管理者をグループから外せば、ほかの権限もなくなりますか？

そうとは限りません。プロファイルや権限セットなど、別経路で付与された権限は委任グループの削除だけではなくなりません。外した後も、ユーザーに残る付与を別途確認します。

複数の委任グループに属する場合、それぞれの範囲だけに制限されますか？

グループごとの対象が独立した制限になるとは限りません。複数グループに割り当てられた委任管理者は、所属するグループ全体の対象を管理できる場合があるため、ユーザー単位に所属と許可範囲を集約して確認します。

委任管理者は権限セット自体を変更できますか？

権限セットの割り当てや削除を委任できる設定と、権限セットの内容を編集できることは別です。管理者が何を割り当てられるかを明示的に設定し、セットの定義を変更する権限と混同しないようにします。

Setup Audit Trailだけで利用状況を監査できますか？

できません。Setup Audit Trailは設定変更の履歴を確認するための情報で、直近20件の画面表示や最大180日分のダウンロードに範囲が限られます。データ閲覧の全てを示す証拠として扱わず、設定一覧やテスト結果などを合わせて保存します。