はじめに：Salesforceデータモデルの重要性
Salesforceを使いこなす上で欠かせないのが「データモデル」の理解です。データモデルとは、ビジネスで扱う情報をSalesforce上でどのように整理・管理するかを定めた設計図のようなものです。
この設計図を正しく理解し、構築することで、Salesforceは単なるデータベースではなく、企業のビジネスプロセスそのものをデジタルで表現する強力なツールになります。この記事では、ITエンジニアを200名以上抱え、システム開発を25年以上経験する弊社、FS部 佐々木舞美がデータモデルを構成する基本要素である「オブジェクト」「レコード」「リレーション」を初心者にも分かりやすく徹底的に解説します。
その他、Salesforceセキュリティは神話か？データ保護の真実を開発担当者が、別記事でもまとめておりますので合わせて参考にしてください。
Salesforceの「オブジェクト」：データの種類を定義する「箱」
Salesforceにおける「オブジェクト」は、データベースでいうところの「テーブル」にあたります。特定の種類の情報を構造化して保存するための「箱」や「分類」だと考えると分かりやすいでしょう。
顧客データ、案件データ、商品データなど、ビジネスで扱うさまざまな情報をオブジェクトとして管理します。
標準オブジェクトとカスタムオブジェクト：それぞれの役割と具体例
オブジェクトには、大きく分けて以下の2種類があります。
| 標準オブジェクト（Standard Objects） | カスタムオブジェクト（Custom Objects） | |
| 定義 | Salesforceが最初から用意している、一般的なビジネスでよく使われるデータの「箱」。 | Salesforceの標準機能ではカバーできない、企業の独自の業務に合わせて作成する「箱」。 |
| 特徴 | あらかじめ定義された項目（フィールド）や機能が備わっている。削除はできない。 | 企業独自のビジネスルールや情報を管理するために設計される。完全にカスタマイズ可能で、不要になれば削除も可能。 |
| 主な例 | 取引先（企業情報）、取引先責任者（個人情報）、商談（案件情報）、リード（見込み客）など。 | 「プロジェクト」オブジェクト、「備品管理」オブジェクト、「イベント参加者」オブジェクトなど。 |
標準オブジェクトとカスタムオブジェクトを組み合わせることで、Salesforceを自社の業務に完全にフィットさせることができます。
Salesforceの「レコード」：オブジェクトの中に保存される具体的なデータ
Salesforceにおける「レコード」とは、オブジェクトという「箱」（データ型）の中に保存される、個々の具体的なデータの集まりのことです。データベースでいえば、テーブルの「行」に相当します。
オブジェクトは「データの種類や分類」を定義するのに対し、レコードは「その種類の具体的な実体やインスタンス」を指します。
具体例：
「取引先」というオブジェクトに、以下の項目（列）が定義されているとします。
| 会社名 | 業種 | 電話番号 |
| 株式会社ABC | 製造業 | 03-XXXX-YYYY |
| ABC株式会社 | ITサービス | 06-YYYY-ZZZZ |
この場合、上の表の1行目と2行目がそれぞれ1つの「取引先レコード」です。
ユーザーはSalesforce上でこれらのレコードを作成、閲覧、編集、削除することで、ビジネスに必要な情報を管理していきます。
Salesforceの「リレーション（関連）」：オブジェクト同士を紐づける仕組み
Salesforceにおける「リレーション（関連）」とは、異なるオブジェクト（データの箱）同士を論理的に紐づけ、関連する情報を結びつける仕組みのことです。
これにより、顧客の全体像を深く理解できるようになります。
リレーションは、Salesforceのデータモデル設計の根幹をなし、情報の整合性を保ちながら効率的なデータアクセスを可能にします。主に以下の2種類があります。
参照関係（Lookup Relationship）の基本とユースケース
- 特徴： 1つのオブジェクトのレコードが、別のオブジェクトのレコードを「参照」する、比較的緩やかな関連付けです。
親オブジェクト（参照される側） が削除されても、子オブジェクト（参照する側） のレコードが自動的に削除されることはありません（設定で変更可能）。
子オブジェクトは、親オブジェクトに紐づいていなくても存在できます（必須項目でない限り）。 - ユースケース： 「取引先責任者」オブジェクトが「取引先」オブジェクトを参照するケース。
ある個人（取引先責任者）がどの会社（取引先）に所属しているかを示します。
取引先が削除されても、その担当者だった個人のレコードは残しておきたい場合に適しています。
主従関係（Master-Detail Relationship）の基本とユースケース
- 特徴： 親オブジェクト（Master）と子オブジェクト（Detail）の間に、非常に密接で強い従属関係が生まれます。
子オブジェクトのレコードは、必ず親オブジェクトのレコードに紐づいている必要があります。
親オブジェクトが削除されると、それに紐づくすべての子オブジェクトのレコードも自動的に削除されます（カスケード削除）。これは、子オブジェクトが親なしには存在し得ない場合に適用されます。
子オブジェクトのレコードは、親オブジェクトのサマリー項目（例：合計金額）に集計できます。 - ユースケース： 「商談」オブジェクト（親）に紐づく「商談商品」オブジェクト（子）。商談商品レコードは単独では存在できず、必ず特定の商談に紐づいています。商談が削除されれば、関連する商談商品も自動的に削除されます。
【保存版】リレーションシップの種類と特徴を徹底比較
| 参照関係（Lookup） | 主従関係（Master-Detail） | |
| 関連性 | 緩やか | 密接で強い従属関係 |
| 紐づけ | 必須ではない（設定可能） | 必須 |
| 親レコード削除時の挙動 | 子レコードは残る（設定で変更可能） | 子レコードも自動で削除される |
| セキュリティ | 親オブジェクトとは独立 | 親オブジェクトの設定を継承 |
| 集計項目 | 作成できない | 作成できる（親に子レコードの合計などを表示可能） |
| 用途 | 多くのユースケースで利用される汎用的な紐づけ | 親子関係が明確で、親なしでは子が存在し得ない場合に利用 |
まとめ：Salesforceのデータモデルを理解するメリット
オブジェクト、レコード、そしてリレーションは、Salesforceの柔軟で強力なデータモデルを理解するための基本中の基本です。これらの概念を把握することで、以下のようなメリットがあります。
- データの一貫性と整合性の確保： 関連する情報が自動的にリンクされるため、データの重複や不整合を防ぎます。
- 顧客の360度ビューの実現： ある取引先のレコードを開けば、その会社に関連するすべての取引先責任者、商談、ケースなどを一目で確認できます。
- 効率的なデータ分析： 複数のオブジェクトをまたがるレポートやダッシュボードを簡単に作成でき、多角的なデータ分析が可能になります。
これらの基本をしっかりと理解し、自社のビジネスニーズに合わせてデータモデルを設計することが、Salesforceを最大限に活用するための第一歩となります。
Salesforce活用の第一歩を踏み出そう
この記事を読んで、Salesforceのオブジェクト、レコード、リレーションについて理解が深まったでしょうか？
もし、貴社のビジネスに合わせたSalesforceのデータモデル設計や、さらなる活用方法についてご相談があれば、専門家にご相談ください。
最適なSalesforceソリューションの導入・運用をサポートいたします。
