Administrator 練習問題 Q268
Cloud Kicks には、Containers__c と Purchase__c という 2 つのカスタムオブジェクトがあります。管理者は、Purchase__c レコードごとに Containers__c レコードの一覧を表示し、Purchase__c レコードが削除されたときに関連する Containers__c レコードも削除されるようにしたいと考えています。この組織では標準の既定設定のみを使用し、Salesforceサポートによる追加機能の有効化は行いません。管理者はどの項目を使用する必要がありますか?
左の○で回答を選択。本文を押すと横線で除外でき、もう一度押すと戻せます。
1つ選択してください(0/1)
正答:A. 主従関係
解説
前提知識
リレーション項目とは
オブジェクト同士をつなぐ項目です。つなぐと、親のレコード画面に子のレコードの関連リストを表示できます。代表的なのは主従関係と参照関係の2つです。
主従関係とは
親と子を強く結びつける関係です。親が子の動作を制御し、親を削除すると子も削除されます(標準動作)。子は必ず親を持つ必要があり、子のレコードの所有者と共有は親から引き継がれます。積み上げ集計項目を使えるのもこの関係だけです。
参照関係とは
主従関係より独立性の高い関係です。公式ヘルプは「参照関係は主従関係と似ているが、共有と積み上げ集計項目をサポートしない」と説明しています。つまり関連リストの表示自体は参照関係でもできます。参照先レコードを削除したときの動作は、既定では[この項目の値をクリア]または[参照されているレコードの削除を許可しない]です。
積み上げ集計項目と数式項目とは
どちらも計算結果を表示する項目です。積み上げ集計項目は主従関係の子レコードを件数や合計で集計し、数式項目は同じレコードや親の値を使って計算します。どちらもオブジェクト同士を新たにつなぐ機能ではありません。
設問の状況を分解する
求められているのは3つです。
- Purchase__c レコード上に Containers__c の一覧を表示する(親子のつながり)
- Purchase__c を削除したら、紐づく Containers__c も削除される(連鎖削除)
- 標準の既定設定だけで実現する(追加機能の有効化なし) ここで大切なのは、1だけなら主従関係でも参照関係でも成立するという点です。初学者が「関連リストを出せるのは主従関係だけ」と覚えてしまうのは誤りです。勝負を決めているのは2と、それを3の制約のもとで満たせるかという点です。
選択肢の検討
A. 主従関係 → ⭕ 正解
主従関係では主レコードが詳細レコードの動作を制御し、主レコードを削除すると関連する詳細レコードも削除されます。Containers__c 側に、Purchase__c を主オブジェクトとする主従関係項目を作成すれば、関連リストの表示と連鎖削除の両方を、追加の有効化なしで標準動作のまま満たせます。これが本問の唯一の正解です。
B. 積み上げ集計項目 → ✕
主従関係がすでにあるときに、子レコードの件数や合計を親に表示する項目です。関係自体を作る機能でなく、削除の挙動にも影響しません。「コンテナの合計本数を購入レコードに表示したい」要件ならこれが正解です。
C. 数式項目 → ✕
数式項目は計算結果を表示する読み取り専用の項目で、レコードの削除や関連リストの表示には関与しません。
D. 参照関係 → ✕(ただし設定次第では実現可能)
最も惜しい選択肢です。前半の要件だけならこれでも満たせます。Containers__c 側に Purchase__c への参照項目を作れば、Purchase__c の画面に Containers__c の関連リストを表示できます。 不正解なのは削除の挙動です。参照関係の既定動作は「参照値をクリアする」または「参照先の削除を禁止する」であり、子レコードを一緒に消してはくれません。 なお、設定次第では参照関係でも連鎖削除は可能です。両方がカスタムオブジェクトで、「カスタム参照関係の連鎖削除」機能が組織で有効化され、項目作成時に[このレコードも削除]を選んだ場合に限り、親の削除で子も削除されます。ただしこの機能は既定で無効で、有効化にはSalesforceによる対応が必要です。さらにこの連鎖削除は共有とセキュリティの設定をバイパスして子レコードを消します。本問は「標準の既定設定のみ」という前提なので、Dは選べません。
試験テクニック:解が分かれる問題の判定軸
💡 本番でも、このように「設定を追加すれば別の選択肢でも実現できてしまう」問題が出題されることがあります。その場合は、標準設定(デフォルト)のままで要件を満たせる選択肢が正解になりやすいと覚えてください。ベータ機能、Salesforceサポートによる有効化、カスタム開発、回避策を前提とする選択肢は、設問にその条件が明記されていない限り後回しになります。 判定の手順はこの3ステップです。
- 要件を分解し、最も条件が厳しい一文を見つける(本問なら「削除されたときに関連レコードも削除」)
- 各選択肢がその一文を標準動作で満たせるかを見る
- 複数満たせる場合は、追加の有効化や例外設定が不要な方を選ぶ 反対に、設問に「ベータ機能を有効化している」「サポートに依頼済み」などの一文があれば、その一文は正解をそちらに寄せるために置かれていると見て判断します。
管理者としての対処手順
- [設定]→[オブジェクトマネージャー]で詳細側の Containers__c を開く
- [項目とリレーション]→[新規]をクリックし、データ型で[主従関係]を選択する
- 関連先の主オブジェクトに Purchase__c を指定する
- 項目ラベル、API参照名、再親子化の許可など必要な設定を確認して保存する
- Purchase__c のページレイアウトまたはLightningレコードページで、Containers__c の関連リストを表示する
- Sandboxなどで Purchase__c を削除し、関連する Containers__c も削除されることを確認する
あわせて覚えておきたいポイント
| 比較項目 | 主従関係 | 参照関係 |
|---|---|---|
| 関連リストの表示 | できる | できる(ここに差はない) |
| 参照先を削除したとき | 詳細レコードも削除される(標準) | 既定は値のクリアまたは削除禁止。連鎖削除は機能有効化が必要 |
| 主/参照先の必須性 | 必須 | 任意または必須に設定可能 |
| 所有者・共有 | 詳細側は主レコードに制御される | 参照元レコードが独自に持つ |
| 積み上げ集計項目 | 使える | 使えない |
- 主従関係と参照関係を見分ける決め手は、**関連リストではなく「削除の連動」「共有の継承」「積み上げ集計」「子側での必須性」**の4点です。
- カスタムオブジェクトには主従関係を最大2つまで作成できます。将来別の親を増やす予定があるなら、設計時に枝を決めておきます。
- 既存データがあるオブジェクトに主従関係を追加する場合、すべての既存レコードに有効な主レコードが必要です。通常は参照関係を先に作成して全レコードの参照先を設定し、その後に主従関係へ変換します。
出典(Salesforce公式)
- Object Relationships Overview — 「参照関係は主従関係と似ているが、共有と積み上げ集計項目をサポートしない」「主従関係は主レコードが詳細レコードの動作を制御する」(関連リスト表示は両方で可能であることの根拠)
- Create Object Relationships(Trailhead) — 「物件とオファーの間に主従関係があれば、物件とそれに紐づくすべてのオファーを削除できる」
- Considerations for Object Relationships — カスタムオブジェクト上のカスタム参照項目では、組織で機能が有効な場合に[このレコードも削除]を選択でき、連鎖削除が共有とセキュリティをバイパスすることの根拠
- Enable ‘cascade delete on custom lookup relationships’ feature — 参照関係の連鎖削除機能が既定で無効であることの根拠
- Unable to create a master-detail relationship — 既存レコードがある場合は、参照関係を作成して全レコードに主レコードを設定した後、主従関係へ変換する必要があることの根拠
- Increase the maximum relationships (master-detail plus lookup) allowed per object — カスタムオブジェクトに作成できる主従関係は最大2件であることの根拠