データベース以上のもの

ほかに 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)

An apartment building at dusk, every window lit and every apartment furnished differently, above one shared glass lobby with its elevator and mailboxes. — AI で生成した画像

モジュール1／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。次へ：母船を見よ：標準データモデル

このモジュールが答える問い： Salesforceは従来のデータベースと何が違うのか？

しばらくSalesforceの管理者をしてきたなら、オブジェクトの作り方はもう知っているでしょう。設定、オブジェクトマネージャー、新規カスタムオブジェクト。名前を付け、項目をいくつか追加し、ページレイアウトを作れば、10分後にはユーザーがそれを使えます。

でも、保存をクリックしたとき、実際には何が起きたのでしょうか？

データベースの経験がある人なら、Salesforceが新しいテーブルを作ったと想像するでしょう。そうではありません。そしてその理由を理解することが、管理者や開発者のように考えることから、アーキテクトのように考えることへと移り始めるきっかけの一つです。

もちろんSalesforceはデータを保存しますし、その下にはデータベースがあります。しかしSalesforceは、きれいな画面を載せたデータベースではありません。メタデータ駆動のアプリケーションプラットフォームであり、その違いがこのコースのほとんどすべての判断を形づくります。

プラットフォームには形がある

第2章では、Salesforceのことをまったく気にせずにモデルを作りました。それは意図的でした。名詞に耳を傾け、概念モデルを作り、属性、キー、関係を加え、そのあとで初めて、Salesforceがそれをどう実装すべきかを問いました。今度は、実装する先のものを理解しなければなりません。

私はこれをシンプルな言葉で表しています。プラットフォームには形がある。 Salesforceはオブジェクト、項目、リレーション、セキュリティ、自動化、API、トランザクション、レポート、検索を提供し、それらはすべてつながっています。オブジェクトを作るとき、私はただ行を置く場所を作っているのではありません。セキュリティモデルに参加し、自動化が働きかけることができ、APIが公開し、レポートが使え、ほかのオブジェクトが関連づけられ、ユーザー、連携、そしてますますエージェントが依存することになるものを作っているのです。テーブルよりずっと大きなものです。

メタデータは設計図である

建物を考えてみてください。建物そのものがあり、それを記述する設計図があります。壁がどこにあり、ドアがどこに付き、部屋がどうつながっているか。Salesforceも同じように動きます。オブジェクトの定義はメタデータです。項目の定義もメタデータです。リレーションもメタデータです。設定画面で設定するもののほとんどはメタデータであり、プラットフォームは実行時にそれを読んで、組織に構造と振る舞いを与えます。

Salesforceはプラットフォームの心臓部を、マルチテナントであり、かつメタデータ駆動であると説明しています。オブジェクトや項目を定義すると、その定義はメタデータとして保存され、私たちの組織のために新しい物理的なテーブルや列が作られるわけではありません（Platform Multitenant Architecture (opens in a new tab)、英語）。

これを教えるとき、私はボンネットを開けて見せます。オブジェクトを追加するたびに、Salesforceがあなたのために新しいデータベースを作っているわけではありません。自分自身のテーブルにレコードを1件追加しているのです。オブジェクトのテーブル、項目のテーブル、データのテーブル、そしてインデックスとリレーションのためのピボットテーブル。すべてが、あなたの組織のデータをほかの全員のデータから分ける組織IDをキーにしています。ですから、項目を追加するのは、エントリを1つ追加するだけのことです。だからこそ、昼休みに本番環境で、その場で項目を作れるのです。

これは、多くの人がつまずくことも説明してくれます。SELECT Id, Name, Special__c FROM Accountと書くと、一つのテーブルのように見えます。その下では、標準オブジェクトとそのカスタム項目を別々の構造から読んでいるので、プラットフォームはあなたが書いていない結合を行っています。インデックスは存在しますが、従来のデータベースのインデックスと同じようには動きません。試験のために内部の仕組みを知る必要はありません。しかし、オブジェクトマネージャーで見ているものが物理テーブルの1対1の姿ではないこと、そしてその抽象化こそがプラットフォームの力であり、プラットフォームがそのように振る舞う理由でもあることは知っておく必要があります。

Click to enlarge

母船を見よ

クラスで私がよく言うことの一つが、母船を見よです。Salesforceで何かをする複雑な方法を発明する前に、Salesforce自身がそれをどうやっているかを見るのです。

取引先を例にとりましょう。あなたが作ったのではなく、Salesforceが作りました。でも、項目を追加し、その周りを自動化し、レイアウトを変え、APIで公開し、ほかのオブジェクトを関連づけることができます。カスタムオブジェクトも同じ仕組みの上で動いています。だから標準オブジェクトとカスタムオブジェクトは、その上に何かを作るときにとてもよく似た感触なのです。Apexでは、基底クラスまで共有しています。sObjectです。

これが、この章の土台となる習慣です。次のモジュールでは、Salesforceがすでに作ってくれている標準データモデルを、きちんと見ていきます。

私たちはSalesforceの横に作っているのではありません。Salesforceを拡張しているのです。

APIはオブジェクトと一緒についてきた

従来のデータベースでテーブルを作れば、テーブルが一つできます。別のアプリケーションがそれを扱う必要があるなら、誰かがもうひと仕事しなければなりません。Salesforceでオブジェクトを作れば、プラットフォームはアプリケーション層と連携層を通じて、すでにそれを理解しています。同じメタデータを使ってRESTとSOAPのAPIを提供しているので、オブジェクトが存在した時点から、それらのAPIでそのレコードを作成、参照、更新、削除できます（Platform Multitenant Architecture (opens in a new tab)、英語）。

オブジェクトを作ったからといって、私がAPIを設計したわけではありません。プラットフォームが、オブジェクト、その項目、そのデータ型、そのリレーション、そのセキュリティを知っているのです。それがSalesforceの開発がこれほど速く進む理由の一つです。そして、オブジェクトを作ることが見た目以上に大きな判断である理由でもあります。アプリケーションプラットフォーム全体に構造を一つ差し込んでいるのです。逆の面もあります。SQL ServerやOracleから来た人に、データベースに直接データをロードする方法を聞かれることがあります。それはできません。すべてはAPIを通じて入ってきます。

マンション

次は、いつも耳にする言葉、マルチテナンシーです。私はこれをマンションのように考えています。

あなたには自分の部屋があります。家具はあなたのものですし、あなたの鍵で私の部屋のドアが開いてはいけません。でも建物は共有しています。電気、水道、エレベーター、ロビー。あなたの組織は、あなたのデータ、あなたのオブジェクト、あなたの自動化がある、自分だけの環境のように感じられます。その下でSalesforceは、各組織をテナントとして扱い、インフラとサービスを共有しながら、各テナントのデータ、メタデータ、ロジックを分離していると説明しています（Platform Multitenant Architecture (opens in a new tab)、英語）。そうやって、顧客ごとに別のスタックを動かすことなく、すべての顧客にこれほどカスタマイズ可能なプラットフォームを提供できるのです。

しかし建物を共有することには結果が伴います。ある住人が巨大なエアコンを買い、ドライヤーとオーブンを同時に使ったら、ブレーカーが落ちて、フロア全体が真っ暗になります。

エレベーターを独占することはできない

もう少しマンションにとどまりましょう。ある住人が「8時から正午までエレベーターが必要です。ほかの人は使えません」と宣言したとします。共有の建物ではそれは通りませんし、Salesforceでも通りません。一つのテナントが共有リソースを際限なく使い、ほかの全員のためにプラットフォームの性能を落とすことは許されません。

そこから生まれるのがガバナ制限です。Salesforceで開発したことがあるなら、暗記すべき数字のリストとして出会ったことがあるでしょう。そういうふうに考えてほしくはありません。Salesforceは、一つのテナントの処理が共有のコンピューティングを独占しないよう、トランザクションと組織のレベルで制限を適用しています（Architecture Basics (opens in a new tab)、英語）。それがアーキテクチャであり、個々の制限はその実装にすぎません。コースの後半では、設計を変えるという理由で特定の制限を気にするようになります。今はマンションを思い出してください。部屋のリフォームには大きな自由があります。エレベーターを独占することはできません。

Salesforce IDは抽象化の一部である

すべてのSalesforceレコードには、プラットフォームが理解する識別情報、つまりレコードIDがあり、UI、API、レポート、自動化といったすべての機能を通じて使えます。

第2章で、よいキーは一意で、変わらず、意味を持たず、決して個人情報ではないと言いました。Salesforce IDは、Salesforceにとってはそれに当てはまります。しかし、それはビジネスキーと同じものではありません。あなたの会社には今もERPの顧客番号、社員番号、システムをまたいで意味を持つパートナーの注文番号があるかもしれません。「Salesforceがこれがどのレコードかを知っている」ことと、「企業がこれがどのビジネス上のものかを知っている」ことを混同しないでください。それは別々の識別の問題であり、後者は連携とマスターデータで再び登場します。

オブジェクトは保存場所以上のもの

この章の残りに進む前に、してほしい転換があります。オブジェクトはただデータを保存する場所ではありません。項目はただの列ではなく、リレーションはただの外部キーではありません。教えるときにはデータベースとの比較を使います。人がすでに知っていることにつながるからです。でもそこで止まると、アーキテクチャを見逃してしまいます。

選ぶオブジェクトが、どの機能がついてくるかを決めます。項目のデータ型は、入力チェック、連携、検索、レポート、そしてほかのシステムがデータをどう読むかに影響します。リレーションは、ライフサイクル、所有、共有、削除を決めます。データをどこに置くかは、ストレージ、性能、規模に影響します。そしてこのすべてが共有のプラットフォームで動いているので、100件のレコードでは無害な選択が、1億件ではまったく違う振る舞いをすることがあります。こうした判断を一つずつ見ていきます。

試験の先へ：AIが変えること。 何年もの間、よい名前と説明は、私たちが作ったものを次の管理者や開発者が理解する助けになってきました。今では機械もそのコンテキストを読みます。Flag2__cという項目を扱うAIシステムは、新しい開発者と同じ問題を抱えます。これはいったい何を意味しているのか？　メタデータはもう飾りではありません。機械がアプリケーションを理解する方法の一部なのです。

ここでアーキテクトが決めること

実際に使っているプラットフォームに向けて設計しているか、それともSalesforceを汎用のデータベースのように扱っているか？
設計のどの部分がビジネス概念で、どの部分がSalesforceでの実装上の選択か？
これから作る構造には、プラットフォームのどんな振る舞いがついてくるか？
どの制限が共有アーキテクチャの表れで、そのうちどれがこの設計を形づくるか？
この構造を後から変えるのが難しいなら、アーキテクチャ上の判断として扱っているか？

第2章で、設定画面から設計しないようにと言いました。今ではもう一つの理由がわかります。新規カスタムオブジェクトをクリックしても、テーブルが一つ手に入るだけではありません。アーキテクチャのもう一つの部品を、メタデータ駆動のマルチテナントプラットフォームにつなぐのです。しかし、どのオブジェクトを作るかを決める前に、もっと基本的な問いがあります。このデータはそもそもここに置くべきなのか？　それが次のテーマです。

さらに学ぶ

Salesforce Architects、Platform Multitenant Architecture (opens in a new tab)（英語）、2026-10-02確認、2026-10-12再確認：オブジェクトと項目の定義は新しいテーブルではなくメタデータとして保存される。共有テーブル（MT_Objects、MT_Fields、MT_Data、MT_Indexes）はOrgIDをキーとする。同じメタデータがRESTとSOAPのAPIを提供する。
Salesforce Architects、Architecture Basics (opens in a new tab)（英語）、2026-10-02確認、2026-10-12再確認：コードやトランザクションが「共有のコンピューティングリソースを独占しない」ようにするためのガバナ制限と実行制限。