データモデルは骨格である
ほかに 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)
モジュール2／7：Data Architectコース第1章「データアーキテクトのように考える」。各モジュールは単独でも読めます。 前へ：アーキテクトのように考える · 次へ：可逆性テスト
このモジュールが答える問い： なぜデータモデルは、その上に作られるどんなものよりも重要なのか。そして、どうやって評価すればよいのか？
データアーキテクチャを教えるとき、私が何度も立ち返る言葉があります。データモデルは骨格である。
データモデルはシステムの骨格です。ほかのすべてはその周りに作られ、体全体を支えているのも骨格です。人を見ても骨は見えませんが、骨がその人の背の高さも、動き方も、運べるものも決めています。
Salesforceの導入で私たちが作るものを思い浮かべてみてください。データモデルの周りに自動化を作ります。それに対してApexを書き、それを読み書きするフローを作ります。データを送り込み、取り出す連携を作ります。その上にレポートや分析を作り、その周りにセキュリティを設計します。そしてますます、そのデータを理解して行動するAIエージェントも作るようになっています。そのすべてが、下にある構造に依存しています。
だからこそ、早い段階でデータモデルを正しくすることがとても重要なのです。骨格は後から変えられます。でも、おそらく痛みを伴います。
ビジネスから始める
Section titled “ビジネスから始める ”よいデータモデルは、シンプルな問いから始まります。ビジネスは実際に何を表現する必要があるのか？ 「どんなSalesforceオブジェクトがあるか？」ではありません。そして「何なら早く作れるか？」では決してありません。
まずはビジネスを理解しようとしています。このビジネスで重要なものは何か？ それらはどう関係しているか？ 誰が所有しているか？ 時間とともにどう変わるか？ 何を覚えておく必要があり、何がビジネスプロセスをまたいで共有されているか？ それらを理解して初めて、オブジェクト、項目、リレーションに置き換え始めるべきです。
当たり前に聞こえるでしょう。実際には、順番を逆にしてしまうのはとても簡単です。誰かが商談やケースや納入商品に似たものを見つけると、すぐにそれを中心に設計し始めます。それがまさに正しいこともあります。四角い杭を丸い穴に押し込もうとしていることもあります。そしてその判断の上に十分なものが作られてしまうと、杭を抜くのは非常に高くつきます。
いつも耳にする質問があります。お客様のビジネスには配送先がたくさんあります。それぞれの場所を取引先にすべきか、カスタムオブジェクトにすべきか？ 答える前に、まず知っておく必要があることに気づいてください。このビジネスにとって「場所」が何を意味し、それに何が起きるのか。それが、オブジェクトより先にビジネスをモデリングするということです。（私の答えは第3章でお伝えします。）
支える。成長する。性能を出す。
Section titled “支える。成長する。性能を出す。 ”データモデルを見るとき、私は3つのテストに合格してほしいと考えています。ビジネスを支える、ビジネスとともに成長する、性能を出す。
支える。 モデルは、ビジネスが実際に成し遂げようとしていることを支えなければなりません。技術的にデータを保存できるモデルと、ビジネスをよく表現しているモデルとでは大きな違いがあります。モデルがうまく合わないせいで、奇妙な項目や特別なフラグ、複雑な自動化や例外を絶えず追加しているなら、私は本当の問題は自動化なのかと問い始めます。モデルが間違っているのかもしれません。よいモデルは、ビジネスを理解しにくくするのではなく、理解しやすくするはずです。
成長する。 成長と言っても、レコードが増えることだけを指しているのではありません。ボリュームは大切です。1万件と1億件とでは、生じる問題がまったく違います。しかしビジネスは複雑さの面でも成長します。製品を増やし、新しい市場に参入し、企業を買収し、プロセスを変え、チャネルを増やし、新しいシステムを接続します。一つのものだと思っていたものが、実は5つの別々のものだったと気づくこともあります。今日のためには見事に機能するモデルも、明日のための余地がなければ罠になり得ます。だから私は、既存のものを変え続ける設計よりも、追加によって成長できる設計を好みます。新しいものを足すほうが、何十ものものが依存しているものを定義し直すより、たいてい簡単だからです。
性能を出す。 データはただそこに置かれているわけではありません。書き込み、探し、クエリし、共有し、レポートし、連携し、そしてますますAIシステムが行動する前にコンテキストとして取得します。図の上では美しく見えても、運用するとひどいモデルもあります。だから私たちは、データがどう保存されるかとデータがどう使われるかの両方に向けて設計します。
そして、性能を出し続けなければなりません。規模が大きくなっても、ユーザーが増えても、データ量が増えても、現実の条件のもとでもピーク時でも、平均的な日ではなく一年で最も忙しい日にも。そして予期しないことが起きたときにも、性能を出し続ける必要があります。
支える。成長する。性能を出す。このコースを通じて、この3つのテストに何度も立ち返ります。
フラットすぎる、複雑すぎる、あるいは単に間違っている
Section titled “フラットすぎる、複雑すぎる、あるいは単に間違っている ”データモデルがうまくいかなくなるのを、私は3つのパターンで見てきました。
1つ目は、そもそも選ぶものを間違えることです。十分近く見えるという理由で標準オブジェクトを使い、それが最初から合っていなかったせいで何年も例外を追加し続けます。これが四角い杭です。
2つ目は、モデルをフラットにしすぎることです。すべてを一つのオブジェクトに入れると、最初はすばらしくシンプルに見えます。やがてビジネスが成長し、その中のいくつかには独自のライフサイクルがあり、複数存在し得て、独自のセキュリティが必要で、独自のリレーションを持つことがわかります。突然、項目1、項目2、項目3で、あるいはどんどん複雑になるフラグと自動化で、1対多の関係を表現することになります。モデルに成長の余地がなかったのです。
3つ目はその逆の誤りで、正規化しすぎることです。オブジェクトを次々と作り、すべての概念を完璧に分けたエレガントな図を描きます。技術的には美しくても、実際には悲惨です。ユーザーは理解に苦しみ、関連リストが延々と続くページレイアウトやLightningページは、どこまでも深く感じられるようになります。クエリは複雑になり、自動化はより多くのリレーションをまたぎ、レポートは難しくなり、普通のビジネス上の質問に答えるためにプラットフォームがより多くの仕事をすることになります。
では、フラットと正規化のどちらが正しいのでしょうか？ 公式はありません。頭の中に最適なモデルの姿を持ち、そこから離れるときのトレードオフを理解するのです。それがアーキテクチャの技術であり、モジュール4と、モデリングの方法を学ぶ次の章で再び取り上げます。今は、構造そのものがアーキテクチャ上の判断であることを認識してください。
骨格を変えるときは慎重に
Section titled “骨格を変えるときは慎重に ”システムが稼働し始めたら、私はデータモデルの根本的な変更にとても慎重になります。
あるテキスト項目が何年も存在していて、誰かが「もうそういう使い方はしていないので、数値に変えましょう」と言ったとします。項目の変更に聞こえます。しかし、その項目に何が依存しているでしょうか？ フロー、Apex、レポート、連携、データパイプライン、外部アプリケーション、AIエージェント。そして過去のデータはどうなるでしょうか？ コードやフローがまだ参照している間は、プラットフォーム自体が項目のデータ型の変更を許しません。それだけでも、その変更がどこまで影響するかがわかります。
既存のものを変えないことが正解の場合もあります。変更の深刻さにもよりますが、私なら新しいものを作り、意図的に移行し、古い構造を廃止予定にするほうを選びます。
変えるより足す。驚かせるより廃止予定にする。
Salesforceには、それをメタデータで表す方法まであります。項目のField Usage（項目の使用状況）をDeprecateCandidateに設定できます。「廃止予定で、もう使われていない」という意味です。これはオブジェクトを読むすべての人にその項目を示すもので、項目を隠すわけではありません。ですから、実際に引退させるのは、やはりあなたが実行する判断です。
アーキテクチャのほかの部分が何かに依存し始めたら、その意味を変えるのは名前を変えるよりずっと危険になり得るからです。最悪なのは、名前はそのままで中身が変わる項目です。下流のすべてが、まだその名前を信頼しています。
項目の必須チェックボックスをオンにするという単純なことでさえ、時限爆弾になり得ます。すでにデータを集めていれば、その項目が入っていないレコードがあります。そして数日後、数週間後、数か月後、誰かがそのレコードの一つを更新すると、必須項目のせいで保存に失敗し、しかもその値を誰も知りません。項目を必須にするという単純な変更が、意図しない、遅れてやってくる結果を生むことがあるのです。必須について、そして値が実際にわかるのはいつかについては、第3章で改めて扱います。
試験の先へ：AIも骨格の上に作る。 AIツールにアプリケーションを作るよう頼めば、オブジェクト、項目、フロー、Apex、コンポーネント、テストを数分で生成してくれます。元のデータモデルが間違っていたなら、悪い判断の結果を避けたことにはなりません。加速させたのです。生成された層の一つひとつが、その構造に依存するものをまた一つ増やすからです。だから私は、AIが生成したデータモデルを人間のアーキテクトがレビューし、理解し、責任を持つことを求めます。モジュール7でさらに掘り下げます。
まず骨格から
Section titled “まず骨格から ”このコースでは、たくさんのテクノロジーについて話します。オブジェクトとリレーション、大規模データボリューム、クエリ、連携、移行、トランザクション、セキュリティ、Data 360、そしてAI。そのすべての下にあるのがデータモデルです。
モデルがビジネスを支え、ビジネスとともに成長でき、データの使われ方に対して性能を出せるなら、強い土台を築けたことになります。土台を誤れば、その後のすべてが難しくなります。
データモデルは骨格である。 アーキテクトは骨格を設計するとき、細心の注意を払うべきです。既存の構造に変更を加えると、連鎖的な結果を招くことがあります。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- モデルがビジネスを支え、ビジネスとともに成長でき、データの使われ方に対して性能を出せるかどうか。
- ある概念が標準オブジェクトに合うのか、それとも四角い杭なのか。
- モデルをどれくらいフラットに、あるいはどれくらい正規化するか、そしてその理由。
- 骨格への変更を、その場での変更ではなく、追加、移行、廃止予定のどれにすべきか。
さらに学ぶ
Section titled “さらに学ぶ ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab)、Salesforceヘルプ（英語、2026-10-02確認、2026-10-12再確認）：データが失われる可能性のある型変更と、Apex、フロー、プロセスが参照している項目の型を変更できない理由。
- Data Classification Metadata Fields (opens in a new tab)、Salesforceヘルプ（英語、2026-10-02確認、2026-10-12再確認）：Field Usageの値（Active、DeprecateCandidate、Hidden）と、その他の分類項目。