Administrator 練習問題 Q13
営業担当副社長は、ロール階層のさまざまな部分に属するユーザーが所有するレコードについてレポートを作成する必要があります。組織の共有設定は［非公開］です。これを実現するために、プラットフォーム管理者は何を設定すべきでしょうか？
左の○で回答を選択。本文を押すと横線で除外でき、もう一度押すと戻せます。
1つ選択してください（0/1）
正答：B. 共有ルール
解説
前提知識
組織の共有設定（OWD）とは
オブジェクトごとに決める、レコードアクセスの最低ラインです。［非公開（Private）］にすると、所有者以外のユーザーは、ロール階層、共有ルール、手動共有、チーム、特別な権限など、別の共有経路がない限りそのレコードへアクセスできません。標準オブジェクトでは、通常、ロール階層で所有者より上位のユーザーにもアクセスが継承されます。
ロール階層とは
組織の上下関係を表すツリーです。ユーザーは、通常、自分より下位のロールに属するユーザーが所有または共有されたレコードへアクセスできます。ただし、ロール階層だけでは別の分岐へ横断的にアクセスは広がりません。 別部門・別分岐の所有レコードを見せるには、共有ルールなど別の共有経路が必要です。
共有ルールとは
OWD で閉めたアクセスを、例外的に拡げるためのルールです。「この範囲の人が所有するレコードを、この人たちに共有する」という形で定義します。
- 共有する対象：所有者に基づく（特定のロールや公開グループが所有するレコード）または項目値の条件に基づく
- 共有する相手：ロール、ロールと下位ロール、公開グループ
- 与えるアクセス：参照のみ、または参照・更新 重要なのは、共有ルールはアクセスを広げることしかできないという点です。OWD より厳しくすることはできません。
💡 ここがまだモヤッとする方へ：組織の共有設定を理解する：OWD・ロール階層・共有ルール
レポートとアクセス権の関係
ここが本問の核心です。レポートには、自分がアクセスできるレコードしか表示されません。 レポートはデータを集計する道具にすぎず、アクセス権を突破する手段ではありません。したがって、「レポートを作れるようにしたい」という要望の本体は、常に「その人のレコードアクセスを広げる」という話になります。
設問の状況を分解する
- 営業担当副社長が、レポートを作りたい。
- 対象は、ロール階層のさまざまな部分に属するユーザーが所有するレコード。
- OWD は非公開。
- 必要なのは、対象レコードをレポート利用者へ追加で公開する仕組み。 「さまざまな部分」という表現は、営業担当副社長の直下だけでなく、別の分岐や部門の所有レコードを含むことを示します。対象者が全員その副社長の配下であれば、ロール階層だけでアクセスできるため、追加の共有ルールは不要です。 本問はロール階層だけでは届かない所有者範囲を前提としており、その範囲を自動的に開くのが共有ルールです。 初学者がやりがちなのは、「レポートを作る話なのだから、レポート関連の権限を与えればよい」と考えることです。しかしレポートを作る権限と、そのレポートにデータが出てくるかは別の話です。アクセス権のないレコードは、どんなレポートを作っても行として現れません。
選択肢の検討
A. フィールドレベルのセキュリティ → ✕
制御の層が違います。項目レベルセキュリティは「見えているレコードの中の、どの項目を見せるか」を決めるものです。レコード自体が見えていない状態には無力です。
B. 共有ルール → ⭕ 正解
OWD が非公開で、ロール階層では届かない範囲のレコードを見せたいときの、まさにそのための機能です。対象のロール群や公開グループが所有するレコードを、副社長（または副社長を含むロール・公開グループ）に参照のみで共有すれば、レポートに必要なデータがすべて現れます。OWD を厳しく保ったまま、必要な人に必要な範囲だけを開けるので、最小権限の原則にも適します。
C. 権限セット → △（惜しいが不正解）
権限セットは、オブジェクトを参照・作成・編集・削除できるか、どの項目を使えるか、どの機能を実行できるかという基礎権限を追加する仕組みです。広範な「すべて参照」系の権限を使えば共有を超えてアクセスできる場合がありますが、対象の所有者やロール分岐を絞れない過剰な開放になります。特定の所有者範囲のレコードを自動共有するという本問の要件には、所有者ベースの共有ルールが適合します。
D. 制限ルール → ✕
向きが真逆です。制限ルール（Restriction Rule）は、既存のアクセスをさらに狭めるための機能です。見せたいという要望に対して、見えなくする機能を選んでいることになります。
管理者としての対処手順
- 共有先を整える。副社長を含むロールがすでにあればそれを使い、なければ［設定］→「公開グループ」で対象者をまとめた公開グループを作成する。
- ［設定］→クイック検索に「共有設定」と入力し、［共有設定］を開く。
- 対象オブジェクトの共有ルールセクションで［新規］をクリックする。
- 共有するレコードを［レコードの所有者に基づく］で指定し、対象のロールや公開グループを選ぶ。
- 共有先に副社長を含むロールまたは公開グループを指定する。
- アクセスレベルに［参照のみ］を選ぶ（レポート目的なら書き込み権は不要）。
- 保存し、共有再計算の完了状況を確認する。
- 承認された検証方法で副社長のアクセスを確認し、レポートに必要な行だけが表示されることをテストする。
あわせて覚えておきたいポイント
レコードアクセスは、下から上へ「閉じてから選んで開ける」順番で考えます。
| 層 | 役割 |
|---|---|
| 組織の共有設定（OWD） | 最低ラインを決めて閉める |
| ロール階層 | 上司に部下のレコードを見せる（縦方向） |
| 共有ルール | ロール階層では届かない範囲に拡げる（横方向） |
| 手動共有・チーム | レコード単位で例外を作る |
| 権限セットのオブジェクト・システム権限 | 操作の基礎権限を追加する。広範な「すべて参照」系権限は共有を超えるため慎重に使う |
| 制限ルール | 上記で開いたアクセスをさらに狭める |
試験では「OWD は非公開です」という一文が頻出します。この一文は「今のままでは見えないので、何かしら開ける仕組みが必要です」という合図です。そして、特定の人・チームに対して範囲を指定して開けるのは共有ルールです。なお、共有ルールはアクセスを強める方向にしか使えないこと、非公開以外のOWD（例：参照可能）でも更新権を与える目的で使えることも押さえておいてください。
出典（Salesforce公式）
- Sharing Rules — 共有ルールは、組織の共有設定に対する自動的な例外として、公開グループ、ロール、テリトリーのユーザーへ追加アクセスを与える。所有者または条件に基づいて共有対象を選べる。
- Sharing Considerations — ロール階層では上位ユーザーが下位ユーザーの所有・共有レコードへアクセスする。共有モデルはOWD、ロール階層、ユーザー権限、共有ルールなどの組み合わせで決まる。
- Salesforce Hierarchical Sharing Structure and Record Visibility Concepts — OWDが非公開の場合、所有者とロール階層上の上位ユーザーがレコードを参照・編集・レポートできるという基本動作を説明している。
- Enable Object Permissions in Permission Sets — 権限セットのオブジェクト権限は、オブジェクトレコードに対する作成・参照・編集・削除の基礎アクセスを管理する。
- Restriction Rules — 制限ルールは、OWDや共有ルールなどで既にアクセスできるレコードを条件でさらに絞り込む。