salesforce オブジェクト：db構造と構成図
Salesforceの組織を運用する中で、「どのオブジェクトがどう繋がっているのか把握しきれない」「新しいメンバーが仕様を理解するのに時間がかかる」という声は非常に多く聞かれます。
特にカスタムオブジェクトが増えるほど全体像の見通しは悪くなり、開発の手戻りや項目の重複が発生しやすくなります。
さらに近年、SalesforceはAIエージェント（Agentforce）が業務データを横断的に参照・活用する「Agentic Enterprise」構想を打ち出し、急速な進化を遂げています。
AIにデータを正しく活用させるためには、オブジェクト構造を論理的かつ整然と設計し、その構成を可視化しておく必要があります。
本記事では、SalesforceオブジェクトのDB構造の基本から、カスタム設計のポイント、そして構成図（ER図）の作成手順までを体系的に解説します。
Salesforce オブジェクトとデータベース（DB）構造の基本
なぜ今、DB構造の理解が不可欠なのか
近年、SalesforceはAgentforceやData 360といったAI機能を急速に拡充しています。
AIエージェントが適切な回答や提案を行うためには、裏側のデータが「正しい構造」で格納されている必要があります。オブジェクト設計が雑だと、AIが正確なデータを取得できず、ハルシネーション（誤った回答生成）のリスクが高まります。
つまり、AI時代においてオブジェクト構造の理解は「あると便利」ではなく「必須の前提条件」です。
Salesforceのデータ構造をRDBと比較して理解する
Salesforceのデータ管理は、一般的なリレーショナルデータベース（RDB）と非常に近い概念で成り立っています。
RDBの用語に馴染みがある方なら、以下の対応関係を押さえればスムーズに理解できるでしょう。
- オブジェクト ＝ テーブル（データの「箱」に相当）
- レコード ＝ 行（1件ごとの具体的なデータ）
- 項目（フィールド） ＝ 列（データの属性情報）
たとえば「取引先（Account）」オブジェクトは「会社情報を管理するテーブル」に相当し、「○○株式会社」や「××有限会社」といった個別の企業情報が「レコード」として格納されます。会社名や住所、電話番号はそれぞれ「項目」です。
ただし、SalesforceのDB構造は一般的なRDBと異なる特徴も持っています。
- マルチテナントアーキテクチャを採用しており、物理的なデータベースは複数の組織で共有されている
- テーブル定義の変更（カスタムオブジェクト・カスタム項目の作成）がGUIから即座に行える
- トリガー、入力規則、ワークフローといったビジネスロジックがデータモデルと密接に結びついている
この仕組みにより、SQLを直接記述してDDL文を実行するような操作は不要になります。
一方で、自由度が高い分だけ設計の良し悪しが運用効率に直結する点は、従来のRDB設計と変わりません。
標準オブジェクトとカスタムオブジェクトの根本的な違い
Salesforceが初期状態で提供しているオブジェクトが「標準オブジェクト」です。
CRMの基本機能に必要なオブジェクトは、最初から利用可能な状態で準備されています。
たとえば、取引先（Account）、取引先責任者（Contact）、商談（Opportunity）、ケース（Case）などです。
一方、「カスタムオブジェクト」は自社の業務要件に合わせて独自に作成するオブジェクトです。
API名の末尾に「__c」が付与される点が外見上の大きな違いとなります。
両者の違いを整理すると次のようになります。
標準オブジェクト
- Salesforceが事前定義済み
- 削除不可（非表示は可能）
- リリースごとに機能が拡張される
- 項目の追加は可能だが、既存項目の削除は不可
カスタムオブジェクト
- ユーザーが自由に作成・削除可能
- API名の末尾に「__c」が付く
- 最大2つの主従関係、合計40のリレーション定義が可能
- Big Objects（大量データ格納用の特殊オブジェクト）も作成可能
カスタムオブジェクト設計で押さえるべきデータ型とリレーション
適切なデータ型選定がデータ品質を左右する
カスタムオブジェクトに項目を追加する際、データ型の選定は非常に重要です。
型の選択を誤ると、さまざまな問題が発生します。レポートの集計が正常に動作しない、入力規則のエラーが頻発する、AIが数値を文字列として処理してしまう、といったケースが代表例です。
主要なデータ型を選定する際の、重要な指針は以下の通りです。
テキスト型
AIによる自然言語処理の対象にしたい項目は、リッチテキストではなくプレーンテキスト型（Text Area等）にするとデータのクレンジングが容易になります。
選択リスト型
自由記述を防いでデータの表記ゆれを根本的に排除できるため、レポートの集計やAIの分析精度を高めるのに最適です。
数値・日付・数式型
計算対象は必ず数値型を選び、時刻不要な場合はDateTime型ではなくDate型を徹底します。
また、他の項目を参照して自動計算・集計を行う場合は、数式型や積み上げ集計型を活用しましょう。
主従関係と参照関係の使い分け — データベースへの影響を理解する
Salesforceのリレーション設計は、DB構造全体の振る舞いを大きく左右します。
主要なリレーション種別の違いを正確に理解しておきましょう。
主従関係（Master-Detail Relationship）
主従関係は「親子が不可分」な関係性を表現します。
- 親レコードを削除すると、子レコードも連鎖的に削除される（カスケード削除）
- 子レコードの所有者項目は存在せず、親レコードの所有者がそのまま適用される
- 子レコードの共有設定は親レコードのセキュリティ設定を継承する
- 積み上げ集計項目（Roll-Up Summary）が利用可能になる
- 子レコードの数は10,000件以下に抑えるのがベストプラクティス
たとえば「請求書（親）」と「請求明細（子）」のように、親なしで子が存在し得ない関係に適しています。
参照関係（Lookup Relationship）
参照関係は「緩やかなリンク」を表現します。
- 親レコードを削除しても、子レコードはそのまま残る（参照項目はクリアされる）
- 子レコードは独自の所有者を持ち、独立した共有ルールを適用できる
- 積み上げ集計項目は使用不可（フローやApexで代替する必要がある）
- 参照項目を必須にも任意にも設定可能
- 削除時の動作を3パターンから選択可能（値クリア／削除禁止／連鎖削除）
「商談」と「キャンペーン」の関連付けなど、独立性を保ちながらデータを紐づけたい場合に選択します。
多対多（Many-to-Many）— ジャンクションオブジェクトの活用
2つのオブジェクト間で「1対多」ではなく「多対多」の関係を表現したい場合、ジャンクションオブジェクト（中間オブジェクト）を作成します。
ジャンクションオブジェクトには2つの主従関係項目を設定し、両方のオブジェクトを親として定義します。
たとえば「社員」と「プロジェクト」の関係は多対多です。
1人の社員が複数のプロジェクトに所属し、1つのプロジェクトには複数の社員が参画します。
この場合、「プロジェクトメンバー」というジャンクションオブジェクトを作成し、社員マスタとプロジェクトマスタの両方と主従関係を結びます。
オブジェクト構成図（ER図）を作成して構造を可視化するコツ
なぜ構成図の可視化が必要なのか
カスタムオブジェクトが10個、20個と増えていくと、どのオブジェクトがどのリレーションで結ばれているかを頭の中だけで管理するのは不可能になります。
構成図（ER図）を作成しておけば、次のようなメリットが得られます。
- 新規メンバーのオンボーディング工数を大幅に短縮できる
- リレーション設計のミス（循環参照やリレーション上限超過）を事前に発見できる
- 影響調査やデータ移行計画の精度が向上する
- AI活用（Agentforce連携やSOQLクエリの自動生成）の際に、データ構造をAIに正しく伝える基礎資料になる
Salesforce標準「スキーマビルダー」を活用した構成図の確認方法
Salesforceには、標準機能として「スキーマビルダー（Schema Builder）」が搭載されています。
すべてのエディションで利用可能であり、追加コストは発生しません。
アクセス手順は以下の通りです。
- 設定（Setup）画面を開く
- クイック検索ボックスに「スキーマビルダー」と入力する
- 「スキーマビルダー」を選択する
スキーマビルダーでは、次の操作が可能です。
- 標準オブジェクトとカスタムオブジェクトの項目・リレーションを視覚的に確認する
- ドラッグ＆ドロップでカスタムオブジェクト・カスタム項目を新規作成する
- 参照関係と主従関係の線をたどり、オブジェクト間の繋がりを直感的に把握する
- レイアウトは自動保存されるため、移動した配置は次回アクセス時にも維持される
スキーマビルダーで追加可能な要素は以下の通りです。
- カスタムオブジェクト
- 参照関係
- 主従関係
- すべてのカスタム項目（※地理位置情報型を除く）
ただし、スキーマビルダーにはいくつかの制約もあります。
- オブジェクト数が多いと画面が煩雑になり一覧性が低下する
- PDF等への直接エクスポート機能がない
- プロジェクト全体のER図としてドキュメント化するには力不足
外部ツールでオブジェクト構成図（ER図）を起こす際のポイント
スキーマビルダーの制約を補うため、外部ツールを使ってER図を作成するケースも多くあります。
代表的なアプローチを紹介します。
外部ツール選定と作成のアプローチ
外部ツールでER図を作成する場合、大きく分けて2つのアプローチがあります。
- 手動で描画する手法
無料でチーム共有しやすい「draw.io」などを使い、直感的に図を作成する方法です。
- メタデータから自動生成する手法
「Lucidchart」やAppExchangeアプリを使い、抽出したオブジェクト定義から効率的に自動生成する方法です。
構成図作成時のベストプラクティス
- 全オブジェクトを1枚の図に詰め込まず、業務領域ごとに分割する（営業管理、請求管理、顧客管理など）
- リレーション種別（主従 or 参照）を線の太さや色で区別する
- 各オブジェクトには主要項目のみ記載し、全項目の詳細は別ドキュメントに切り出す
- 作成日と最終更新日を明記し、定期的に最新化するルールを設ける
- 命名規則（API名・表示ラベル）を統一し、図中の表記がブレないようにする
まとめ：オブジェクト構成図を共通資産にして開発効率を高める
SalesforceのオブジェクトはRDBのテーブルに相当し、レコードが行、項目が列という基本構造を持ちます。
標準オブジェクトで足りない業務要件をカスタムオブジェクトで補い、主従関係・参照関係・多対多といったリレーションを適切に設計する必要があります。
データ型の選定では「将来のAI活用」を念頭に置き、テキスト型と数値型の使い分けや、選択リストによる表記ゆれ防止を徹底しましょう。
リレーション設計では、ビジネスルール上の親子関係の強さを見極め、主従関係と参照関係を正しく使い分ける判断力が求められます。
そして、設計した構造はスキーマビルダーや外部ツールを活用してER図として可視化し、チーム全員がアクセスできる場所に保管しておくべきです。
構成図は「一度作って終わり」ではなく、オブジェクト追加やリレーション変更のたびに更新する「生きたドキュメント」として運用する姿勢が大切です。
属人化を防ぎ、新メンバーの立ち上がりを加速させるためには、こうした設計資産を組織の共通ナレッジとして蓄積・活用する仕組みが欠かせません。
◆Salesforceノウハウ共有ツール「KnowhowBase」は‘ノウハウを作る、探す、活用する’をコンセプトに、Salesforceプラットフォーム上で利用できる便利な機能をご提供しています。また、「Salesforce導入サービス」 「Salesforce伴走・開発支援サービス」により、Salesforceを新規導入される方、Salesforceの定着・活用や運用保守・開発を要望される方に合ったサービスもご提案しております。ご興味のある方は、お気軽にお問い合わせください。
★当サイトでノウハウ共有やSalesforceの定着促進・保守運用・開発を検討している方へ、様々なダウンロード資料をご用意しております。ぜひ資料をダウンロードいただき、ご活用ください。
