Salesforceでカスタムオブジェクトを設計・運用する手順｜実務で使える構築ガイド

2026.04.09

#Salesforce #カスタムオブジェクト

Salesforceのカスタムオブジェクトは、自社固有の業務やデータに合わせて標準オブジェクトと同じようにSalesforceを使用するためのものです。
ただし、設計時に考慮が欠けていると、項目が増えすぎる、検索しづらい、権限が破綻する、改修が困難といった状況に陥ることがあります。

この記事では、設計→構築→権限→運用改善までを、実務で使える順序で説明していきます。

設計の前に決めること｜「実現したいこと」を固める

設計に取り掛かる前に、Salesfroceで何を実現したいかをしっかりと固めておく必要があります。
実現したいことが決まっていなければ、不要な開発をしたり、後から実現が不可能であることが発覚するなど問題が発生するため、設計前に必ず押さえておきましょう。

標準で作るのか？カスタムで作るのか？

(設定_オブジェクトマネジャーの画面：標準オブジェクトとカスタムオブジェクト)

最初に「標準オブジェクト（取引先・取引先責任者・商談など）で表現できないか」を確認します。
標準オブジェクトを使用すれば、他の標準オブジェクトとのリレーションも構築されているため、開発予算も削減することができます。
また、標準オブジェクトを使用する場合、Salesforceのレポートや拡張機能（AppExchangeや将来導入される機能）との相互性も高いです。

一方で、標準オブジェクトにない業務概念または複雑な契約管理、製品構成、申請フローなどを管理する必要があるなら、カスタムオブジェクトが適しています。

「親子関係（リレーション）」を決める

データモデルが破綻する最大要因は「後からリレーションを継ぎ足す」ことです。
最初に業務の実体を「親オブジェクト→子オブジェクト」で表し、リレーションを整理しましょう。

リレーションには参照関係と主従関係の２種類があります。

• 参照関係：比較的ゆるい関連。親子の独立性を保ちやすい
• 主従関係：強い親子。親の共有設定の影響を受けやすく、集計もしやすい

どちらも、親子関係を構築することに変わりありませんが、データ同士の結びつきの強さが異なるため、下記表のような違いがあります。

比較項目	参照関係	主従関係
親レコードなしで子レコード作成	可能	不可
親レコード削除時	子は残る（参照が外れる）	子も一緒に削除される
子レコードの所有者	あり	なし（親に従う）
共有設定・権限	親子で別々に設定可能	親の共有設定を継承
ロールアップ集計項目	不可	可能（件数・合計など）
承認プロセス	子単体で設定可能	親レコード基準
リレーションの数制限	（主従＋参照の）合計リレーション数が最大40 Salesforceサポートに依頼して 合計上限を最大40→50に引き上げることも可能	1オブジェクトにつき最大2つ

※主従関係では、標準オブジェクトは子に設定することはできません。
(参考公式ヘルプページ：オブジェクトリレーションの考慮事項)

注意点：リレーションは“運用ルール”まで含めて決める

このようにリレーションはデータの動きに直接関与するため定義が曖昧だと、削除事故やデータ不整合につながります。したがって、リレーションを定義するには、具体的な業務を元に運用ルール（データの動き）まで決めることが必要となります。

構築手順｜オブジェクトマネージャー

それではここから、カスタムオブジェクトの具体的な構築手順とポイントについて説明していきます。

カスタムオブジェクトの作成

カスタムオブジェクトの作成は設定の「オブジェクトマネージャー」から行います。

1. 「設定」画面に遷移



2. 「オブジェクトマネージャー」画面に遷移


上部の「オブジェクトマネージャー」をクリックするか、左にある検索バーからの検索でも「オブジェクトマネージャー」の画面に遷移できます。

3. 「作成」から「カスタムオブジェクト」を選択



4. 必要な項目の入力


新規カスタムオブジェクト作成画面にて必要な項目を入力し、「保存」ボタンを押下します。入力必須の項目は赤色の帯が表示されています。（上記画像の青色枠）

項目設計｜項目の目的とデータ型

Salesforceの項目にはデータ型があり、用途に合わせて使い分けることが重要です。データ型は数多くありますが、よく使用される主要なものを見ていきましょう。

データ型	使用用途
テキスト	文字、数字、または記号を任意の組み合わせで入力できる。 自由に入力できるため、検索や分析には不向き。
数値	任意の数値を入力できる。 桁数・小数点を指定することができる。
選択リスト	あらかじめ定義されたリストから1つの値を選択できる。 入力を統一することができる。
数式	他の項目や値に基づいて値を自動的に計算することができる。
積み上げ集計	関連レコードのレコード件数を表示したり、関連レコードの合計値、最小値、または最大値を計算することができる。

 
同じ情報でも、テキストで持つか、選択リストで持つか、数値で持つかで、検索性・レポート精度・自動化の作りやすさ・運用コストが大きく変わります。
(参考公式ヘルプページ：カスタム項目のデータ型)

主要なデータ型を把握したところで、実際の項目の作成について説明していきます。

1. オブジェクトマネージャーから作成したカスタムオブジェクトを選択し、「項目とリレーション」、「新規」の順番に押下



2. データ型を選択



3. 項目を参照、編集できるプロファイルを選択（項目レベルセキュリティ）



4. 項目を配置するレイアウトを選択し、「保存」ボタンを押下



※項目の作成完了後でも、これらのステップは編集することができます。

データ品質を守る：入力規則を最初から

運用が始まると、ユーザーごとに入力内容が統一されておらず、データの統一性が損なわれる場合があります。
そこで入力規則を使用すると、項目に入力する値に対し条件を設定し、データの統一性を担保することができます。
(例：契約金額は10000未満は入力できない入力規則を設定)

入力規則は、保存前に条件を検証し、エラーメッセージで入力を戻すことで、データ品質を安定させる仕組みです。


(契約金額を10000円未満で入力し保存しようとしたため、エラーメッセージが表示されている画面)
入力規則に違反するものとしないものが混在してしまうため、入力規則を設定するなら、運用前が理想的です。
(参考公式ヘルプページ：入力規則の設定)

UI設計：Lightningページと動的フォームの活用

カスタムオブジェクトの運用は「項目の設計」だけでは完成しません。
実際の現場では、入力のしやすさ（UI） がデータ品質を大きく左右します。
そこで有効なのが、Lightning App Builderで作る Lightningレコードページ と、項目表示を柔軟に制御できる 動的フォームです。

動的フォームは、ユーザーにLightningレコードページの「詳細」を、項目・セクション単位で自由に配置、表示制御できる機能です。
表示制御ではある項目の値が「はい」のときだけ、関連項目を表示するなどの設定を行うことができます。



(動的フォームを使用し、セクションごとに項目を２列に配置している画面)

運用を支える権限設定

ここからは、作成したオブジェクト、項目、またはそのレコードに対する権限の説明をしていきます。

権限設計：プロファイル依存を減らし、権限セット中心へ

プロファイルに役割ごとの権限差分を詰め込んでいくと、「部署ごと」「チームごと」「例外対応ごと」にプロファイルが増えやすく、どの設定が誰に効いているのか把握しづらくなります。
そういった状態では「見えてはいけない人に見える」「編集してはいけない人が編集できる」ケースが発生しやすくなります。

権限セットで権限設計を構築し、プロファイル依存を回避しましょう。

• オブジェクト権限（参照／作成／編集／削除）
• 項目レベルセキュリティ（参照／編集）

プロファイルで共通の最低限の権限を設定し、権限セットで必要分だけ追加することで「見えてはいけない人に見える」「編集してはいけない人が編集できる」ケースの発生を極限まで減らすことができます。
(参照公式Trailheadページ：オブジェクトへのアクセスの制御)

共有ルール：基本（組織の共有設定）を決めてから、例外（共有ルール）で広げる

権限の設定はオブジェクト単位、項目単位のアクセス制御でした。
それに対して、レコード単位でのアクセス管理を行うのが共有ルールです。
共有ルールは “制限を強くする” ための機能ではなく、“アクセスを広げる” ための機能です。

レコードごとのアクセスを制御したい場合は、組織の共有設定で全体のアクセスを制限し、アクセスさせたいユーザ（公開グループ）のみがそのレコードにアクセスができるように設定します。

「ユーザーやメンバーによって参照、編集できるレコードを変えたい」と言う際には共有ルールの使用を考慮すると良いでしょう。

監査・追跡：項目履歴管理は“必要箇所だけ”有効化

項目履歴管理を有効化すると「いつ、誰が、何を変えたか」を追えることができ、非常に便利です。
しかし、多くの項目履歴管理を有効にすると履歴データが大量に作成され、本当にみたい項目の変更履歴の追跡が困難になります。

項目履歴管理は、顧客に影響の出る項目から有効にすることをお勧めします。
※項目履歴管理はオブジェクトごとに最大20項目まで有効にすることができます。

ただし、アドオン機能である項目監査履歴を使用すれば、最大60項目まで拡張が可能です。（Salesforce ShieldまたはField Audit Trailライセンスを購入していれば最大200項目まで拡張可能）
(参考公式ヘルプページ：オブジェクト項目履歴の追跡)
（参考公式ヘルプページ：項目監査履歴の制限を 60 件以上に拡張）

(契約金額を項目変更履歴として設定した画面)

運用フェーズの改善｜より良いシステムにするために

作成したカスタムオブジェクトは、実際に運用していく中で修正点や改善点が見えてきます。運用していく中で、より良いものにするために必要なポイントを押さえておきましょう。

使われていない項目の安全な対処法

運用をしていく中で、実際には不要な項目が出てくることがあります。
ここで、「不要＝削除」としてしまいがちですが、フローや別の機能で使用されていた場合、問題となる可能性が高いです。
したがって、下記手順を踏み、段階的に対処することが大切です。

1. ページレイアウトから非表示（影響を最小化）
2. レポート・フロー・外部連携で参照されていないか確認
3. 問題がなければ削除（最終段階）

追加機能を考慮する

また、不要な項目とは反対に、項目や入力規則、権限などの設定の追加が必要になることもあります。
運用してみて初めて必要性が明らかになることもありますので、定期的に改善していき、より良いものにしていくという姿勢が大切です。

まとめ

カスタムオブジェクトは「作ること」よりも、標準／カスタムの判断やリレーション設計、項目のデータ型選定、権限・UIまで含めて“運用を前提に設計すること”が重要です。

入力規則や動的フォームを活用して、現場が迷わず入力できる状態を作ることで、データ品質と運用効率を両立できます。
まずは小さく作って確実に回し、運用の中で改善を重ねながら“使われ続ける仕組み”に育てていきましょう。

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら