正しいオブジェクトを選ぶ
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール5／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。 前へ：このデータはどこにあるのか？ · 次へ：項目もアーキテクチャである
このモジュールが答える問い： このビジネス概念は、どんな種類のSalesforceオブジェクトになるべきか。そしてライセンスは何を許すのか？
Salesforceで最も簡単にできることの一つが、カスタムオブジェクトを作ることです。だからこそ、私たちはそれを作りすぎていると思うのです。
要件のセッションで誰かが「販売代理店を管理する必要があります」と言います。新しいカスタムオブジェクト、Distributor。完了。ただ、アーキテクトにはまず別の問いを立ててほしいのです。販売代理店とは何か？ 会社です。Salesforceには会社を表すかなりよい方法がすでにあります。取引先です。答えがいつも取引先だという意味ではありません。でも、会社がなぜ取引先ではないのかを説明しなければならないなら、「ビジネスが販売代理店と呼んでいるから」よりもよい理由がほしいのです。
ここで第2章の論理モデルがプラットフォームと出会います。私の出発点はシンプルです。ビジネス概念が標準オブジェクトの本来の目的にきれいに合うなら、そこから始める。
意味から始める
Section titled “意味から始める ”あるものがオブジェクトに値する場合でも、自動的にカスタムオブジェクトに値するわけではありません。それが実際に何を表しているのかを問いましょう。どんな形であれ、事業体や組織？ 取引先から始めます。その組織と仕事をする人？ 取引先責任者。顧客が所有しているもの、購入したもの？ 納入商品。売ろうとしているもの？ それなら商談が会話に加わります。
だからこそ、モジュール2でまず母船を見たのです。こうしたモデルはすべてのビジネスに合うわけではありませんが、自分で作るほうがきれいに感じるからといって無視すべきではありません。新規カスタムオブジェクトの前に、Salesforceはこの概念をどうモデリングしているか、そのモデルの周りに何が作られてきたか、それを置き換えたら何を手放すことになるかを問いましょう。
きれいに合うかのテスト
Section titled “きれいに合うかのテスト ”私のテストは一つの問いです。このビジネス概念は、標準オブジェクトの本来の目的にきれいに合うか？ 合うなら、私は標準オブジェクトに傾きます。
販売代理店は私たちが関係を持つ会社なので、取引先にきれいに合います。ユーザーがある会社を販売代理店と呼び、別の会社を仕入先、別の会社を小売パートナー、別の会社を顧客と呼んでもかまいません。それらはビジネス上の役割であり、4つの物理オブジェクトは必要ありません。ビジネス上の名前が違っても、自動的にデータ構造が違うわけではありません。 種別、レコードタイプ、あるいはリレーションでその違いを表せます。
このテストは逆方向にも働きます。第1章で、一つの問いを残しておきました。ある顧客の事業には、配送先の拠点がたくさんあります。それぞれの拠点は取引先にすべきでしょうか、それともカスタムオブジェクトにすべきでしょうか？
取引先は多くのものを与えてくれます。住所の項目、そして取引先の住所をすでに前提としているすべてのもの、レポート、地図、連携が手に入ります。しかし、そのオーバーヘッドも手に入ります。たくさんの項目、共有、階層、所有、取引先にぶら下がるすべてのもの。そしてその大半は、別の住所には関係ありません。別の住所一つのために、使いもしない重いものをたくさん抱えることになるのです。
取引先の子であるカスタムオブジェクトなら、軽くできます。住所の項目だけを持つ、私たちが配送する場所で、独立して管理できる独自のライフサイクルを持たせられます。
ですから、これはバランスです。引き受ける重みと、得られる価値の。 必要なのが独自のライフサイクルを持つ住所だけなら、そこで私はカスタムにします。
ケースの下の副次的な問題も同じです。それぞれの副次的な問題が本当にケースであり、担当者が対応し、独自の状況とサービスレベルを持つなら、モジュール2の親ケースを使って入れ子にしましょう。でも、誰もケースとして対応しない単なるチェックリストの項目なら、完全なケースは決して使わないものをたくさん抱えることになり、シンプルなカスタムの子のほうが軽いかもしれません。カスタムのほうがきれいだからではありません。意味が違うか、重みが合わないからです。
標準オブジェクトには荷物がついてくる
Section titled “標準オブジェクトには荷物がついてくる ”標準オブジェクトを選ぶとき、あなたが選んでいるのは項目だけではありません。Salesforceの製品がすでに理解しているものを選んでいるのです。レポート、自動化、組み込みのリレーション、製品の機能、AppExchangeのパッケージ、そしてSalesforceが次に作るもの。それはとてつもなく価値のあることがあります。
標準オブジェクトには、独自の考え方もついてきます。既存の振る舞い、リレーション、セキュリティ上の考慮事項、ときにはライセンスの要件、そして必要のない機能。ですから「常に標準オブジェクトを使う」は私のルールではありません。「常に」というルールは持っていません。持っているのは傾向です。意味がきれいに合い、その周りのプラットフォームの振る舞いが設計に逆らわず助けになるなら、標準オブジェクトを使う。 営業の商談ではないものを商談のように振る舞わせるのに5年を費やすなら、標準にとどまったことで何も得ていません。逆方向に間違った妥協をしただけです。
納入商品はよい例
Section titled “納入商品はよい例 ”納入商品は、見落とされがちな標準オブジェクトの一つです。私が言える最もシンプルな言い方は、顧客が持っているものです。私たちから買ったものかもしれないし、そうでないかもしれません。顧客の現場にある競合の製品でも、私は気にかけます。それを保守しているか、置き換えようとしているか、顧客の導入基盤を理解する必要があるからです。納入商品を先に見ずにCustomer_Product__cを作るなら、アーキテクチャ上の問いを飛ばしたことになります。納入商品が自動的に勝つわけではありませんが、検討される価値はあります。
個人取引先：個人が取引先になるのはいつか？
Section titled “個人取引先：個人が取引先になるのはいつか？ ”モジュール2で個人取引先に出会いました。個人の顧客のために、取引先と取引先責任者を1つのレコードにしたものです。ここからは判断です。
私の立場は、B2Cでは、個人取引先なしで済ませるのは難しいということです。取引先と取引先責任者には最初から用意されているものがとても多いので、コストとオーバーヘッドに見合う価値があります。そしてコストは確かにあります。法人取引先の約2倍のストレージ、オフにできないスイッチ、そして一部の外部ライセンスでは使えないこと。Partner Communityは個人取引先と一緒には使えません（Experience Cloud User Licenses (opens in a new tab)、英語）。ですから問いは「データベースに人がいるか？」ではありません。どの組織にも人はいます。問いは**「このビジネスでは、その人が本当に取引先なのか？」**です。取引先責任者が人だからといって、それが個人取引先になるわけではありません。そうするのはビジネス上の関係です。
ここで全部をややこしくしましょう：ライセンス
Section titled “ここで全部をややこしくしましょう：ライセンス ”ここまで：概念を見つけ、最もきれいに合う標準を探し、意味が合わなければカスタムにする。次はアーキテクトの追加の問いです。誰がそれを使う必要があるか？ 美しいモデルを設計した後で、データを必要とする人の半分が、選んだオブジェクトのライセンスを持っていないと気づくことがあります。ライセンスはデータモデルの一部です。
3つの社内ライセンス
Section titled “3つの社内ライセンス ”まず自社の人々から始めましょう。社内には、すべてのアーキテクトに完璧に知っておいてほしいライセンスの種類が3つあります。それぞれのユーザーが何を見て何をできるかを決め、したがってデータモデルが何を当てにできるかを決めるからです。
Sales Cloud（現在はAgentforce Sales）。これらのユーザーは完全なSalesforceユーザーライセンスを持っています。標準のCRMオブジェクトと、あらゆる標準アプリやカスタムアプリです。取引先と取引先責任者に加えて、リード、商談、売上予測、さらにはケースも。営業担当者は電話の前に、顧客の未解決のケースを見ることができます。キャンペーンを作成して実行するには、もう一つ、マーケティングユーザーの機能ライセンスが必要です。
Service Cloud（現在はAgentforce Service）。同じSalesforceユーザーライセンスを、サービス向けに設定したものです。中心にあるのはケースで、サービスコンソールで対応します。Salesforce Console for Serviceを開けるようにするのが、Service Cloudユーザーの機能ライセンスです。ここには、エンタイトルメント管理とマイルストンを通じた**サービスレベル契約（SLA）**があり、ナレッジも加わります。ナレッジは、ほとんどのエディションでアドオンとして購入するものです。
Platform（Salesforce Platform）。CRMではなく、自社のカスタムアプリを必要とする人のためのものです。取引先、取引先責任者、レポート、ダッシュボード、ドキュメント、そして組織内のすべてのカスタムアプリが使えます。使えないのは、売上予測、リード、キャンペーン、商談です。コストが低く、だからこそ多くの大規模なカスタムアプリがこの上で動いていて、だからこそデータモデルの足をすくうことがあるのです。
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| ユーザーライセンス | Salesforce | Salesforce | Salesforce Platform |
| 何のためか | 販売 | 顧客のサポート | カスタムアプリ |
| 取引先、取引先責任者 | はい | はい | はい |
| リード、商談、売上予測 | はい | はい | いいえ |
| ケース | はい、顧客のケースを見るため | 中心。サービスコンソールで | いいえ |
| サービスレベル契約 | いいえ | はい、エンタイトルメントとマイルストン | いいえ |
| カスタムオブジェクトとアプリ | はい | はい | はい |
アーキテクトのようにこの表を読みましょう。大きなユーザーグループがPlatformなら、その仕事を商談に載せる設計は、始まる前から壊れています。経営層がSLAの数字を必要としているなら、それを見られるかどうかは、彼らのライセンスが決めます。この3つの種類が振る舞いを決めるのです。
ライセンスがオブジェクトを決めるとき
Section titled “ライセンスがオブジェクトを決めるとき ”私が最もよく出くわしてきた犠牲者は商談です。表で見たとおり、Platformのユーザーは商談を使えません（Standard User Licenses (opens in a new tab)、英語）。そしてCustomer Communityのユーザーも商談を扱えません。要件は商談のように見え、誰かが「商談を使おう」と言い、そこで私は誰がアクセスする必要があるのかを尋ねます。大きな集団がPlatformやCustomer Communityのライセンスなら、ライセンスはもはや調達の細かい話ではありません。アーキテクチャ上の制約であり、たいていは設計をカスタムオブジェクトのほうへ押しやります。
上の方向にも働きます。クラスで私は尋ねます。CEOがきれいなダッシュボードをほしがっています。SalesのライセンスとServiceのライセンス、どちらでしょう？ Salesのユーザーは営業のオブジェクトもケースさえも見られるので、営業のダッシュボードや未対応ケースの件数ならSalesで問題ありません。しかし経営層がSLAのKPI（ケースがサービスレベルに違反するまでどれくらいか）をほしがった瞬間、そのデータはエンタイトルメントとマイルストンにあり、エンタイトルメント管理にはAgentforce Service（旧Service Cloud）が必要です（Supported Editions for Service Features (opens in a new tab)、英語）。こうして経営層のライセンスをアップグレードすることになります。ビジネスの要件に耳を傾け、それが必要とするデータの下にどのライセンスがあるかを知りましょう。
スタジアム
Section titled “スタジアム ”私はライセンスをスタジアムの座席のように考えています。みんな同じ試合を見ています。真ん中の高い席を買えば、両チームを間近で見られます。隅の外野席の上のほうなら、座席にクッションはなく、双眼鏡で見ることになります。
それが外部ライセンス、会社の外にいる人々のためのライセンスです。Experience Cloudサイトにログインする顧客やパートナーです。知っておいてほしいものが3つあります。
Customer Community：外野席です。ケースとナレッジを必要とする膨大な数の外部ユーザーのために作られています。サポートケースの状況を確認する顧客などです。席は約半額で、膨大な数のユーザーに配れます。そこで何を失うのでしょう？ レポート、ダッシュボード、そして共有テーブル、つまり上位の席が手にするロールベースの共有です。個人取引先とは一緒に使えます。
Customer Community Plus：半分くらいまで下りてきた席です。Salesforceはこれを、レポート、ダッシュボード、標準の共有が必要な外部ユーザーのためのライセンスだと説明しています。ほかの人のアクセスを管理する顧客や、自分の数字を見る必要がある顧客です。
Partner Community：さらに近い席で、企業間取引のためのもので、営業データにアクセスできます。パートナーはリードと商談を扱います。案件を登録し、あなたと一緒にキャンペーンを実施します。これが営業オブジェクトに届く外部の席です。一つ注意点があります。個人取引先と一緒には使えません（Experience Cloud User Licenses (opens in a new tab)、英語）。
間違いは、全員が高いチケットを持っているかのように設計し、実装の段階で、ユーザーの大半がデータを置いた区画に入れないと気づくことです。そうなると選択肢は3つです。別の席を買う、体験の場所を移す、モデルを設計し直す。3つともアーキテクチャです。
支払い方が設計を変える
Section titled “支払い方が設計を変える ”人が忘れがちな問いがもう一つあります。このユーザーたちはどうやってログインするのか？ 外部ライセンスには2つの形があります。メンバーベース：ユーザー単位で支払い、毎日ログインする500のパートナーに向いています。ログインベース：月あたりのログイン数を買い、年に数回ログインする500万人の顧客に向いています。同じ日に2回以上ログインしても、1回のログインとして数えられます（Experience Cloud User Licenses (opens in a new tab)、英語）。
ですから誰かが「顧客ポータルを作っています」と言ったら、私の次の問いはどのテンプレートかではありません。顧客は誰か、何人か、どれくらいの頻度で来るのか、どんなデータが必要で、それで何をすることが許されているのか、です。
ライセンスがモデルを形づくるとき
Section titled “ライセンスがモデルを形づくるとき ”ライセンスがオブジェクトを選ぶだけでなく、モデル全体を曲げてしまうこともあります。プラットフォームのライセンスの中には、ユーザーを最大10個のカスタムオブジェクトからなる1つのカスタムアプリに制限するものがあります（たとえばLightning Platform – One App。Standard User Licenses (opens in a new tab)、英語）。
初期のあるプロジェクトで、大手の専門サービス・建設会社のために、全従業員のためのLinkedInのようなものを作らなければなりませんでした。全員の職務、スキル、資格、言語、プロジェクトを管理し、ある国で資格を持つ橋梁技術者を見つけられるようにするのです。制限がなければ、ユーザー職務、ユーザースキル、ユーザー資格、ユーザー言語、ユーザープロジェクトのオブジェクトと、資格やプロジェクトの参照リストを作ったでしょう。10オブジェクトのライセンスで、しかも全部使い切るなと言われては、それは不可能でした。そこで「イントロクイズ」のようになりました。いくつのオブジェクトでこれを作れるか？ 答えは2つでした。リストの種類（職務、スキル、資格、言語、プロジェクト）ごとにレコードタイプを持つ一つの参照オブジェクトと、対応するレコードタイプを持ち、それを指す一つのユーザー属性オブジェクトです。
最適なモデルではありませんでした。レポートが大変で、もっときれいにしたかったところです。しかし、それがライセンスで許される範囲でした。私はこれを十徳ナイフオブジェクトと呼んでいます。このパターンを奥の手として持っておき、制限で余地がなくなったら、非常用ガラスを割ってレコードタイプでの分離に頼るのです。ただ、何と引き換えにしているかは知っておきましょう。レコードタイプごとに権限が違うと、結局オブジェクトを分けざるを得なくなることがあります。
もはやユーザーは人だけではない
Section titled “もはやユーザーは人だけではない ”ライセンスについて、もう一つ重要になってきた問いがあります。人ではないものはどうでしょう？ 連携にはIDがあります。エージェントにもIDがあります。Salesforceには今、システム間連携のためのSalesforce Integrationライセンスがあります。APIのみで、人間用ではなく、Enterprise、Unlimited、Performance Editionの各組織に5つ含まれています（Standard User Licenses (opens in a new tab)、英語）。ですから、どのユーザーがアクセスする必要があるかだけを問うのではなく、どのIDがアクセスする必要があるかを問いましょう。人、顧客、パートナー、連携、エージェント。そして、それぞれが何を見て何をする必要があるのかを。
試験の先へ：AIが変えること。 エージェントがデータのもう一つの利用者であり作成者になるにつれて、オブジェクトの選択とライセンスは人間の画面だけの話ではなくなります。エージェントがどのIDで動くのか、そのIDが何にアクセスできるのか、そしてモデルが、エージェントの必要とするデータを、そのエージェントが使えないオブジェクトや権限の向こうに置いていないかを把握しましょう。
Steve Trucking：簡単なものと難しいもの
Section titled “Steve Trucking：簡単なものと難しいもの ”Steve Truckingは小売パートナー（Retail Partner）と仕事をしています。小売パートナーとは何でしょう？ 事業体です。簡単です。取引先です。誰かが「パートナー」という言葉を使ったからといって、Retail_Partner__cは作りません。
次は受取人（Recipient）、冷蔵庫を受け取る人です。取引先責任者？ 個人取引先？ それとも別の何か？ 年に100万人の新しい受取人がいて、彼らは私たちではなく小売パートナーの顧客です。これはまさに、関係、アクセス、規模を理解する前にオブジェクトに飛びつきたくない種類の問いです。第1部のチェックポイントで決めます。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- ビジネス概念が標準オブジェクトの本来の目的にきれいに合うのか、それとも意味や重みが違うのか。
- ビジネス上の異なるラベルが、異なるエンティティなのか、同じエンティティの異なる役割にすぎないのか。
- データを必要とするすべての人、外部ユーザー、連携、エージェントが、予定しているライセンスのもとで選んだオブジェクトにアクセスできるか。
- 利用者の数とログインのパターン（メンバーベースかログインベースか）が、ライセンスとモデルをどう形づくるか。
- ライセンスの制限が最適ではないモデルを正当化するのはいつか、そしてその引き換えがレポートと権限にどんなコストをもたらすか。
標準オブジェクトがよくてカスタムオブジェクトが悪い、という話ではありません。選択には結果が伴い、ときにはそれを決めるのが名詞ではなく、それを使う必要のある人々、そして機械だ、ということです。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Standard User Licenses (opens in a new tab)（英語）、2026-10-02確認、2026-10-12再確認：Platformのユーザーには売上予測、リード、キャンペーン、商談の権利がない。最大10個のカスタムオブジェクトからなる1つのカスタムアプリ。Enterprise Editionの各組織にSalesforce Integrationライセンスが5つ。
- Salesforceヘルプ、Experience Cloud User Licenses (opens in a new tab)（英語）、2026-10-02確認、2026-10-12再確認：Partner Communityは個人取引先と一緒には使えない。Customer Community Plusはレポート、ダッシュボード、標準の共有のため。1日に複数回ログインしても1回として数える。
- Salesforceヘルプ、Supported Editions for Service Features (opens in a new tab)（英語）、2026-10-02確認、2026-10-12再確認：Agentforce Serviceでのサービスレベル契約（エンタイトルメント管理）。ナレッジはほとんどのエディションで追加費用。
- Salesforceヘルプ、Available Feature Licenses (opens in a new tab)（英語）、2026-10-12確認：Service Cloudユーザーは「Salesforce Console for Serviceにアクセスする」。マーケティングユーザーはキャンペーンの作成と管理のため。