このデータはどこにあるのか？
ほかに 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)
モジュール4／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。 前へ：自分で作る：カスタムオブジェクト · 次へ：正しいオブジェクトを選ぶ
このモジュールが答える問い： オブジェクトを作る前に、このデータは実際にどこに置くべきか。Salesforceのコア上か、今ある場所のまま参照するか、それともアーカイブか？
一つ質問させてください。新しい要件があなたの机に届きました。最初に何をしますか？
たいていの人と同じなら、設定画面を開いてカスタムオブジェクトを作るでしょう。わかります。10分でタブとページレイアウトとリストビューができます。そして私がどのクラスでも言うのはこういうことです。その新しいオブジェクトを作った瞬間、意図していようといまいと、あなたはすでにアーキテクトとして考えています。作るオブジェクトの一つひとつが約束だからです。ストレージを使います。制限がつきまといます。設計したかどうかにかかわらず、共有モデルを持ちます。それに触れる人全員にライセンスが必要です。そして人や連携がそれに依存し始めたら、取り去るのは至難の業です。
ですから、最初のアーキテクチャ上の判断はどのオブジェクトかではありません。*このデータはどこに置くべきか？*です。そこを正しく決めれば、オブジェクトの種類はほとんど自然に決まります。
コア上とコアの外
Section titled “コア上とコアの外 ”まず、これからよく使う言葉があります。コアです。コアとは、あなたの組織が動いているSalesforceプラットフォームのことです。モジュール1のメタデータ駆動のマルチテナントプラットフォームであり、モジュール2のSalesとServiceのオブジェクトや、モジュール3で作るすべてのカスタムオブジェクトがある場所です。データがコア上にあると言うとき、それは組織の中の、そのオブジェクトに保存されているという意味です。
すべてのデータがそこにあるわけではありません。Data 360は、組織のオブジェクトの外にある独自のストアにデータを保持します（ニアコアです。コア上で管理され、データはコアの外でホストされます。詳しくは第4章で）。そして、会社が動かしているもののうち、Salesforceではないものすべてがあります。ERP、ウェアハウス、注文システム、パートナーのプラットフォーム。そのすべてがコアの外です。Salesforceはそこに届き、それを表示し、使うことができますが、組織がそれを保存しているわけではありません。
コア上には、実際にレコードを保持するオブジェクトが2種類あります。標準とカスタム（__c）のsObjectと、Big Object（__b）です。コアの外のデータには、外部オブジェクト（__x）やその他の連携ツールを通じて届きます。モジュール3の接尾辞を覚えておいてください。名前だけで、そのデータがどこにあるのかを教えてくれます。
私はこれをオフィスのように考えています。毎日使うので、自分の机の上に置くべきものがあります。ほかの誰かのファイルキャビネットで調べるだけでよいものもあります。そして、裏の物置の箱にしまうものもあります。そこから3つの答えが出てきます。
1. コア上：自分の机の上にある
Section titled “1. コア上：自分の机の上にある ”データがSalesforceの中で毎日作成され、変更され、使われるもの。取引先、ケース、商談、作業指示。それをsObjectに置くのは、オフィスの手前に置いておくようなものです。標準オブジェクトとカスタムオブジェクトはこのためにあり、すべてが手に入ります。ページレイアウト、共有、自動化、レポート、検索、そして今ではデータモデルの上に作られたAI機能も。
ただし、机はただではありません。コア上のデータはストレージを使い、それはSalesforceの数え方、つまり列ごとではなくレコードごとに数えられます。そしてドキュメントは、それとは別にファイルストレージに数えられます。どちらもモジュール2で扱いました。大量の写真やスキャンは、多くの場合コアの外に置き、Salesforceにはリンクだけを持たせるのがふさわしいのです。
2. 参照：誰かほかの人のファイルキャビネットにある
Section titled “2. 参照：誰かほかの人のファイルキャビネットにある ”データが別のシステム（ERP、データウェアハウス、注文プラットフォーム）に属し、そのシステムが真実の源であり続けるもの。ユーザーはSalesforceでそれを見る必要があり、レコードに関連づける必要もあるかもしれませんが、Salesforceが独自のコピーを持つ必要はありません。これは仮想データと呼ばれることもあります。Salesforceに一度も保存されることなく、仮想的にSalesforceに表示されるからです。
それがSalesforce Connectを通じた外部オブジェクトです。私はよく、アヒルのように見えてアヒルのように歩くけれど、アヒルではない、と言います。sObjectのように見えます。ページレイアウトや関連リストに置け、外部参照関係や間接参照関係で自分のレコードと関連づけられます。でもデータはコア上に保存されていません。触れるたびにコールアウトが発生します。 レコードを開く、関連リストを読み込む、レポートを実行する。そのたびにSalesforceは別のシステムに問い合わせに行きます。つまり遅延があり、ページの可用性はその背後にあるシステムの可用性次第です。
ライセンスのコストに難色を示す人がいるので、クラスでやるように計算してみましょう。Connectはエンドポイント単位でライセンスされ、1つのエンドポイントで多くのオブジェクトを取り込めます。では、代わりの方法を作って保守するのにいくらかかるかを問うてみてください。カスタムコンポーネント、その裏のコールアウトのコード、壊れたときに対応する開発者。ライセンスのほうが安いことはよくありますし、管理者がコードを一行も書かずに設定できます。弱いのは、ユーザーが一日中編集するデータや、頻繁にレポートするデータです。
ドキュメントも参照できます。契約書がすでにSharePoint Online、OneDrive、Google Drive、Boxにあるなら、Files Connectを使えば、ユーザーはそれをSalesforceにコピーせずにSalesforceから利用できます。
データを参照する方法はSalesforce Connectだけではありません。カスタムロジックの場合もあります。別のシステムをリアルタイムで呼び出し、そのデータをページに表示するコードで、コピーは保持しません。完全にコントロールできますが、コールアウト、エラー、保守の責任もすべて負うことになります。そしてData 360もコピーせずにフェデレーションできます。その選択には独自の章があります（仮想化、フェデレーション、ゼロコピー）。ここで大事なのは判断そのもの、コピーせずに参照することです。
3. アーカイブ：裏の物置にしまう
Section titled “3. アーカイブ：裏の物置にしまう ”履歴、監査証跡、古いトランザクション。保持しなければならず、ときには何年も保持しますが、ほとんど誰も開きません。そしてこれは、チームが後回しにするものです。クラスで、5,000万件のレコードを持つオブジェクトがあるのになぜアーカイブするのかと聞かれたら、私はこう聞き返します。今日アーカイブしていないなら、いつかアーカイブすることがあるのか？ 今日5,000万件なら、1億、1億5,000万、2億件へと向かっています。
物置は2つあります。1つはコア上：Big Objectです。データをガレージに保存するようなものだと考えてください。膨大な数のレコードを保存できますが、ページレイアウトには置けず、標準のUIもレポートもなく、Big Objectのインデックスを通じて、完全一致か範囲でクエリします（Big Objects Best Practices (opens in a new tab)、英語）。セキュリティはオブジェクトと項目の権限だけで、レコードの共有はなく、自動化もそれに対しては動きません。私はSalesforce Connectは何十回も使ってきましたが、Big Objectは1、2回だけです。機能はしますが扱いにくく、データにたどり着くための回避策をそれなりに書いてきました。ですから私の助言は、提案する前にプロトタイプを作ること、そして選ぶ前に、人がデータをどう見つけるかを計画しておくことです。
もう1つの物置はコアの外、どこか別の場所にあるウェアハウスやデータベースです（大規模に向けた設計）。多くの場合、そちらのほうがよい物置であり、目の届かない場所である必要もありません。コアの外にアーカイブしたデータも、Tableauのようなツールを通じてレポートに表示できますし、誰かが過去を振り返る必要があるときには、Salesforce Connectやその他の仮想化の方法で、Salesforceから届くようにしておくこともできます。
最初からこれを正しくやれたプロジェクトの話をしましょう。ある小売のお客様には1,200を超える拠点がありました。「1店舗で1日に予約は100件だけです。大したことはありません」と言われました。そこで計算してみました。1日100件、週6日（年に約305日）、1,200拠点で、年3,600万件を超える予約です。さらに、来店1回ごとに予約が2件、つまり受付カウンターの分と店の奥の分ができると言われました。年に7,300万件を超えるレコードです。そして5年分の履歴がほしいと。成長を見込む前の段階で、3億6,000万件以上のレコードです。まだ本番稼働もしていないのに、列車が大規模データボリューム駅にまっすぐ向かっているのが見えました。そこで、予約を1件も集める前にアーカイブを作りました。古い予約はBig Objectに移し、検索画面には現在の予約を表示し、そのすぐ下にアーカイブされた予約を表示しました。何年もたった今も、問題なく動いています。
実践：Steve Trucking
Section titled “実践：Steve Trucking ”Steve Truckingは、このコースを通じて使うシナリオです。大手量販店の物流センターで家電や電子機器を受け取り、顧客の家に配送して設置する、家族経営のラストマイル配送会社です。4種類のデータに、3つの答えがあります。
| データ | 置き場所 | 理由 |
|---|---|---|
| 今日の配送、クルー、予約 | コア上 | 配車担当者とクルーが一日中それを使って仕事をする |
| 小売業者の注文の詳細 | 参照（またはコア上の薄いコピー） | 小売業者のシステムが真実の源 |
| 3年前の配送履歴 | アーカイブ | クレームと傾向分析のために保持。ほとんど誰も開かない |
| 配送写真 | コアの外、リンク | 1日に何千枚も。Salesforceの外に保存し、配送にリンクを置く |
同じことをデータモデルで表してみましょう。配送（Delivery）はコア上にあり、人々が一日中それを使って仕事をします。3年たつと、Big Objectである配送履歴（Delivery History）に移ります。まだコア上にありますが、裏の物置です。パートナーの注文は外部オブジェクト、__xとして表示されます。Salesforceは配送をそれに関連づけますが、データは小売業者のシステムにとどまります。そして写真は完全にコアの外にあり、配送からリンクされています。1つのモデルに、3つの置き場所です。
現実の組織にはどれも3つすべてがあります。困ったことになる組織は、オブジェクトを作るのがデフォルトのボタンだったという理由で、すべてをコア上に置いていたのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- それぞれの種類のデータの置き場所。 オブジェクトを設計する前に：コア上、参照、アーカイブ。
- 真実の源。 別のシステムがデータを所有しているなら、Salesforceが知らないうちに2つ目のマスターになるべきではない。
- コアの外にあるもののアクセス経路。 参照するデータには、利用可能な源と許容できる遅延が必要。アーカイブしたデータには、人がそれを見つける方法が必要。
- ストレージの増加。 ストレージの警告が届いてからではなく、今計算する（1日あたりのレコード数×成長×保持期間）。
試験の先へ：AIは「コア上」の重みを増す。 AI機能やエージェントが最もよく働くのは、プラットフォームが理解しているデータ、つまり標準オブジェクトとカスタムオブジェクトにあり、よく名付けられ、よく説明されたデータです。それは、より多くをコア上に置きたくなる引力になります。間違ったデータについては、それに抗いましょう。ERPデータの古いコピーにグラウンディングしたエージェントは、自信満々に間違った答えを返します。多くの場合、よりよいのは生きた源を参照するか、小さくよく説明された一部分だけをコア上に置くことです。AIがどこでデータを読むかも、今ではデータの置き場所を決めることの一部なのです。
さらに学ぶ
Section titled “さらに学ぶ ”- Big Objects Best Practices (opens in a new tab)、Salesforce Developers（英語、2026-09-25確認）
- Files Connect FAQ (opens in a new tab)、Salesforceヘルプ（英語、2026-09-25確認）
- このコースの中で：仮想化、フェデレーション、ゼロコピーと大規模に向けた設計