Salesforceオブジェクトリレーションシップの設計戦略：アーキテクトが知るべきルックアップと主従関係の深層

執筆者：Salesforce アーキテクト

背景と応用シーン

Salesforceプラットフォーム上で堅牢かつスケーラブルなソリューションを構築する際、その心臓部となるのがデータモデル (Data Model) の設計です。データモデルがビジネスプロセスを正確に反映していなければ、どんなに優れた自動化やUIを構築しても、その価値は半減してしまいます。そして、データモデルの根幹を成すのがオブジェクトリレーションシップ (Object Relationships)、つまりオブジェクト間の関連性を定義する仕組みです。これらは単にデータを繋ぐ線ではなく、システムのセキュリティ、データ整合性、パフォーマンス、そして将来の拡張性にまで直接的な影響を及ぼす、アーキテクチャ上の極めて重要な意思決定です。

例えば、人材紹介アプリケーションを設計するシナリオを考えてみましょう。ここには「求人ポジション (Position__c)」、「候補者 (Candidate__c)」、「応募 (Application__c)」という3つの主要なカスタムオブジェクトが存在します。これらのオブジェクト間の関係をどのように設計するかが、アプリケーションの振る舞いを決定します。

ある「求人ポジション」が削除されたら、それに関連する「応募」情報も同時に削除されるべきか？
「応募」情報の閲覧権限は、「求人ポジション」の担当者と同じであるべきか、それとも独立して設定できるべきか？
1つの「求人ポジション」に何件の「応募」があったかを、コーディングなしで簡単に集計したいか？

これらの問いに対する答えが、どのリレーションシップを選択すべきかを導き出します。本記事では、Salesforceアーキテクトの視点から、最も基本的ながら最も重要な2つのリレーションシップ、Lookup Relationship (参照関係) と Master-Detail Relationship (主従関係) を中心に、その原理、技術的な違い、そしてアーキテクチャ設計における選択基準を深く掘り下げていきます。

原理説明

Salesforceにおけるオブジェクトリレーションシップは、データベースにおける外部キー制約に似ていますが、それ以上の機能と制約をプラットフォームレベルで提供します。アーキテクトとして、それぞれの特性を正確に理解することが不可欠です。

Lookup Relationship (参照関係)

Lookup Relationshipは、2つのオブジェクトを緩やかに結合するリレーションシップです。これは最も標準的で柔軟性の高い関係と言えます。

独立性: 関連付けられた2つのオブジェクトは、所有権 (Ownership) とセキュリティ設定 (Sharing Settings) において完全に独立しています。親レコードの所有者が子レコードの所有者と異なる場合もあり得ます。
任意性: デフォルトでは、子レコードの参照項目は必須ではありません。つまり、親レコードと関連付けられていない子レコード（孤立レコード）の存在が許容されます。
削除の振る舞い: 親レコードが削除されても、子レコードはデフォルトでは削除されません。子レコードの参照項目は単にクリアされるか、あるいは設定によって削除を禁止することも可能です。
オブジェクト上限: 1つのオブジェクトに最大40個まで作成可能です（他の項目タイプとの合計上限数にも依存します）。

アーキテクトとしての視点: 柔軟性が高い反面、データ整合性の維持には注意が必要です。オブジェクト間のライフサイクルが独立しており、異なる部署やユーザーグループがそれぞれのオブジェクトを管理するようなシナリオ（例：「取引先」と「サポート契約」など、契約が取引先とは別のライフサイクルを持つ場合）に適しています。セキュリティモデルを分離したい場合に最適な選択です。

Master-Detail Relationship (主従関係)

Master-Detail Relationshipは、2つのオブジェクトを緊密に結合する、より特殊で強力なリレーションシップです。

依存性: 子（Detail側）レコードは、親（Master側）レコードなしでは存在できません。子レコードの所有権と共有設定は、完全に親レコードから継承されます。子オブジェクトの組織全体のデフォルト (Organization-Wide Defaults) は「親レコードに連動 (Controlled by Parent)」に自動設定され、変更できません。
必須性: 子レコードを作成する際、親レコードとの関連付けは常に必須です。
連動削除 (Cascading Delete): 親レコードを削除すると、関連するすべての子レコードも自動的に削除されます。これはごみ箱からも完全に削除されるため、非常に強力な機能です。
積み上げ集計項目 (Roll-Up Summary Fields): 親オブジェクト上で、関連する子レコードの件数 (COUNT)、合計 (SUM)、最小 (MIN)、最大 (MAX) を計算する「積み上げ集計項目」を作成できます。これはMaster-Detail関係の最も大きな利点の一つです。
オブジェクト上限: 1つのオブジェクトに最大2つまでしか作成できません。また、リレーションシップの階層は3レベルまでという制限があります。

アーキテクトとしての視点: データ整合性をシステムレベルで強制したい場合に非常に有効です。親の存在が子の存在意義そのものであるような関係性（例：「経費報告書 (親)」と「経費明細 (子)」）に最適です。積み上げ集計項目は、追加の自動化ロジックなしで複雑な集計を実現できるため、パフォーマンスと開発効率の向上に寄与します。しかし、その強力な結合性は柔軟性を犠牲にするため、将来的なビジネス要件の変更に耐えうるかを慎重に検討する必要があります。

多対多リレーションシップ (Many-to-Many Relationship)

Salesforceには直接的な多対多リレーションシップは存在しませんが、連結オブジェクト (Junction Object) を用いることで実現します。連結オブジェクトは、2つの異なるオブジェクトとMaster-Detail Relationshipで結ばれたカスタムオブジェクトです。

例えば、「学生 (Student__c)」と「コース (Course__c)」という2つのオブジェクトがあるとします。1人の学生は複数のコースを受講でき、1つのコースには複数の学生が在籍します。この場合、「履修登録 (Enrollment__c)」という連結オブジェクトを作成し、Student__cとCourse__cの両方に対してMaster-Detail関係を設定します。これにより、多対多の関係を効果的にモデル化できます。

サンプルコード

オブジェクトリレーションシップの真価は、データのクエリにおいて発揮されます。SOQL (Salesforce Object Query Language) を使用して、これらのリレーションシップをどのように辿るかを見ていきましょう。これらのクエリは、Apex、Visualforce、Lightning Web Componentsなど、あらゆる場所で活用されます。

親から子へのクエリ (Parent-to-Child Query)

このクエリは、特定の親レコード（この場合はAccount）に関連するすべての子レコード（Contacts）を取得します。子のリレーションシップ名は、通常、子オブジェクトの複数形に `__r` を付けたものになります（カスタムオブジェクトの場合）。

// 特定の取引先(Account)に紐づくすべての取引先責任者(Contact)を取得する
// 副問い合わせ(Subquery)を使用し、FROM句で子のリレーションシップ名(Contacts)を指定する
List<Account> accountsWithContacts = [
    SELECT Id, Name, (SELECT Id, LastName, FirstName FROM Contacts)
    FROM Account
    WHERE Name = 'SFDC Inc.'
];

// クエリ結果の利用
for (Account acc : accountsWithContacts) {
    System.debug('Account Name: ' + acc.Name);
    // 関連するContactレコードのリストにアクセス
    List<Contact> contacts = acc.Contacts;
    for (Contact con : contacts) {
        System.debug('  Contact Name: ' + con.FirstName + ' ' + con.LastName);
    }
}

子から親へのクエリ (Child-to-Parent Query)

このクエリは、子レコード（Contact）から親レコード（Account）の情報を取得します。リレーションシップ項目名（ドット表記）を使用することで、親オブジェクトの項目に直接アクセスできます。

// 特定の取引先(Account)に所属する取引先責任者(Contact)を取得し、
// 同時にその親である取引先の情報も取得する
// ドット表記(Account.Name)を使い、親オブジェクトの項目にアクセスする
List<Contact> contactsWithAccountInfo = [
    SELECT Id, LastName, Account.Name, Account.Industry
    FROM Contact
    WHERE Account.Name = 'SFDC Inc.'
];

// クエリ結果の利用
for (Contact con : contactsWithAccountInfo) {
    // Contact自身の項目
    System.debug('Contact Name: ' + con.LastName);
    // 関連する親(Account)の項目
    System.debug('  Account Name: ' + con.Account.Name);
    System.debug('  Account Industry: ' + con.Account.Industry);
}

注意事項

アーキテクトとしてリレーションシップを設計する際には、短期的な要件だけでなく、長期的な影響も考慮しなければなりません。

データスキュー (Data Skew): 1つの親レコードに対して、10,000件を超える子レコードが紐付くと、パフォーマンスの劣化やレコードロックの問題が発生しやすくなります。これを「データスキュー」と呼びます。特に、所有権や共有設定が親にロックされるMaster-Detail関係では、親レコードの更新時にすべての子レコードに対する共有再計算が走る可能性があるため、この問題が顕著になります。設計段階で、特定のアカウントやユーザーに大量のレコードが集中する可能性がないかを評価することが重要です。
リレーションシップの変換: 既存のLookup関係をMaster-Detail関係に変換することは可能ですが、そのためにはすべての子レコードが親レコードへの参照を持っている必要があります。逆の変換も可能ですが、共有設定が大きく変わるため、セキュリティへの影響を慎重に評価する必要があります。一度設定したリレーションシップの変更は、データ移行や権限再設計を伴う大規模な作業になる可能性があります。
共有とセキュリティ: Master-Detailはセキュリティモデルを単純化しますが、柔軟性を失います。例えば、「子レコードの一部の種類だけ、特定のユーザーグループに公開したい」といった複雑な要件がある場合、Master-Detailでは実現が困難です。Lookup関係と共有ルールを組み合わせる方が適切な場合があります。常にビジネスのセキュリティ要件を最優先に考えるべきです。
必須ロックイン: Master-Detail関係の子オブジェクトは、他のオブジェクトとのMaster-Detail関係を持つことができません（2つのMaster-Detailを持つことは可能ですが、3つは不可）。これにより、将来的なデータモデルの拡張が制限される可能性があります。例えば、当初は「求人ポジション」の子であった「応募」オブジェクトを、後から「人材プール」の子にもしたい、といった要件変更に対応できなくなるかもしれません。

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

オブジェクトリレーションシップの選択は、単なる技術的な選択ではなく、ビジネスの現在と未来を形作る戦略的な決定です。Salesforceアーキテクトとして、以下のベストプラクティスを心に留めておくべきです。

1. 迷ったらLookupを選択する (Default to Lookup): Master-Detailの強力な機能（積み上げ集計や連動削除）が「絶対に必要」という明確な理由がない限り、まずはLookup関係から設計を始めるのが安全です。Lookupの方が柔軟性が高く、後からセキュリティを強化することはできても、Master-Detailで固められた構造を後から緩めるのは困難です。

2. オブジェクトのライフサイクルを分析する: 「親がなければ子は存在しない」という関係性がビジネスロジック上、絶対的であるかを自問してください。経費報告書と経費明細のように、ライフサイクルが完全に一致している場合はMaster-Detailが最適です。しかし、少しでも独立して存在する可能性があるのなら、Lookupを検討すべきです。

3. スケーラビリティを常に念頭に置く: データスキューのリスクを常に評価してください。特定の親レコードに数万件の子レコードが集中する可能性があるシステムでは、Master-Detail関係の利用は慎重になるべきです。パフォーマンスへの影響は、システムの利用が拡大するにつれて顕在化します。

4. ドキュメンテーションを徹底する: なぜそのリレーションシップを選択したのか、その理由とトレードオフを設計ドキュメントに明記してください。将来、別のアーキテクトや開発者がその判断の背景を理解し、適切な改修を行えるようにするためです。特に、Master-Detailを選択した場合は、その決定がもたらす制約事項も明確に記載することが重要です。

最終的に、優れたSalesforceアーキテクチャは、ビジネス要件を正確に反映し、将来の変更にも柔軟に対応できるデータモデルの上に成り立っています。オブジェクトリレーションシップの一つ一つの選択が、その土台を築くための重要な一石となるのです。

にゃんこのSalesforce日記

このブログを検索