項目もアーキテクチャである

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

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール6／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。 前へ：正しいオブジェクトを選ぶ · 次へ：リレーションには結果が伴う

このモジュールが答える問い： Salesforceは、それぞれのデータを物理的にどう表現すべきか？

項目を作るのには1分ほどしかかかりません。新規項目、データ型を選び、名前を付け、次へ、次へ、保存。だからこそ、項目はアーキテクチャとして扱われないのです。

10年続いている組織に入って、取引先を開いてみてください。500個の項目。Status2__c、Legacy_Status__c、Old_Status__c、Status_New__c。3種類の顧客番号。どの連携がまだ使っているのか誰も知らないので、誰も削除しようとしないチェックボックス。項目を作るのは1分でした。それと付き合うのは何年もです。ですから、このモジュールの考え方はシンプルです。項目はアーキテクチャ上の判断である。 いつも大きな判断とは限りませんが、どの項目もデータの意味、振る舞い、識別、品質について何かを表しています。そしてオブジェクトと同じように、項目は足すのは簡単で、取り去るのは意外なほど難しいのです。

このデータは実際に何を意味するのか？

第2章で、エンティティに属性を与えました。配送には予定の時間帯があり、トラックにはVINがあります。今度はそれを実装するのですが、ここで多くの人がいきなり「テキスト項目」に飛びつきます。待ってください。データ型の前に、そのデータが何を意味するのかを知りたいのです。数値か、それともたまたま数字を含む識別子か？　日付か、それともある瞬間か？　自由記述か、それとも承認された集合の一つか？　人が入力するのか、それとも別のシステムが所有しているのか？　変わり得るか？　一意でなければならないか？　欠けていてもよいか？　そもそも保存すべきか、それとも計算すべきか？　これらは設定画面の問いではありません。データアーキテクチャの問いであり、データ型はそれに答えた後で決まります。

数字はいつも数値とは限らない

Steve Truckingはすべてのトラックに車両番号を付けています。たとえば001247。数値項目でしょうか？　おそらく違います。車両番号を足し合わせるでしょうか？　トラック1247からトラック1246を引いたら、トラック1台でしょうか？　それはたまたま数字を含む識別子であり、数値項目にすると先頭のゼロまで落ちてしまいます。郵便番号、製品コード、口座番号、追跡番号も同じです。値の見た目は、その意味を教えてくれません。サンプルデータの見た目ではなく、必要な振る舞いでデータ型を選びましょう。

人がそれを識別する必要があるか？

すべてのカスタムオブジェクトにはName項目があり、最初の判断はテキストか自動採番かです。私は問います。人がこれを識別する必要があるか？　人は小売パートナーを名前で、トラックを車両番号で知っています。でも、システムが毎晩生成する積荷目録は？　Salesforceが名前を必須にしたからといって、誰かが「積荷目録 10-02 3番」と入力すべきではありません。自動採番にしましょう。ただし、生成されたNameをレコードの識別と混同しないでください。自動採番はユーザーを助け、Salesforce IDはレコードを識別し、小売パートナー自身の積荷目録の参照番号は、システムをまたいで同じものを識別するかもしれません。3つの別々の仕事です。

詳細の画面

データ型を選んで次へをクリックすると、設定が詳細を尋ねてきます。このモジュールの判断のほとんどが実際に下されるのは、この画面です。たいていは急いで。

新規カスタム項目のステップ2：詳細（スクリーンショット、2026-10-12）。 原寸で表示

似て見える2つの欄が、別々の仕事をします。説明は組織を保守する人々のため、そして今ではそれを読むAIツールのためのものです。その項目が何を意味し、誰が所有し、どこから来るのか。ヘルプテキストは画面の前のユーザーのためのものです。ここに何を入力するか。両方を埋めましょう。その次に必須、一意、外部IDが来ますが、それぞれに独自のセクションを割く価値があります。その下のデフォルト値には数式を使えるので、新しいレコードは空欄ではなく、筋の通った値から始められます。

必須は見た目より大きな判断

項目作成ウィザードには必須という小さなチェックボックスがあり、第1章で見たように、それは時限爆弾になり得ます。5年使ってきた200万件のレコードを持つオブジェクトがあり、誰かが新しい項目に常に値が入っていなければならないと決めたとします。その前からある200万件はどうなるでしょう？　それを送ってこない連携は？　値がわかる前にレコードを作成する自動化は？　値が3ステップ後にしか出てこないプロセスは？

「必須」はデータ品質の判断に聞こえますし、そういうこともあります。しかし、値がいつわかるかはビジネスプロセスの一部です。ですから、誰かが「それはいつもほしい」と言ったからといって必須にチェックを入れないでください。いつわかるのか、誰が提供するのか、わからないときに何が起きるのかを問いましょう。モジュール7で、これを一貫性のはしご全体の中に位置づけます。

一意にも意味がある

項目を一意にするなら、私はビジネスについてある主張をしていることになります。「たいてい重複しない」ではなく、「2つのレコードがこの値を持つことは決してない」。強い主張です。そして画面は、もう一つ決めることを求めてきます。「ABC」と「abc」は同じ値か、違う値か？　人が入力するものについては、大文字と小文字を区別しないほうが安全なデフォルトです。第2章のキーのルール、一意、変わらない、意味を持たない、決して個人情報ではないがここで当てはまります。社員のメールアドレスは一意だと言われたら、私は問い始めます。変わることはあるか、退職して戻ってくる人はいるか、アドレスは再利用されるか、買収の後はどうなるか？　メールアドレスは役に立つかもしれませんし、今日は一意かもしれません。だからといって、よい識別になるわけではありません。

外部ID：境界をまたぐ識別

ここで外部IDが真価を発揮します。画面の説明がうまく言い表しています。その項目は「外部システムの一意のレコード識別子」になります。ERPには顧客873492があり、Salesforceには独自のレコードIDがあります。ERPが更新を送ってきたとき、それがどのレコードのものかをどう知るのでしょう？　項目を外部IDとしてマークすれば、連携はそれでupsertできます。レコードがなければ作成し、あれば更新します（Upsert a Record Using an External ID (opens in a new tab)、英語）。そして子レコードをロードするときは、先にSalesforce IDをクエリする代わりに、外部IDで親を指せます。私はよく、Salesforceに照合を任せるのだと言っています。とても強力です。

ERPの番号が、Salesforceのレコードの識別になるわけではないことに注目してください。それは属性であり、一つのレコードがいくつも持つことがあります。ERPの顧客ID、従来システムのID、パートナーのID。それでかまいません。一つのビジネスエンティティが、複数のシステムで別々に知られていることはあり得ます。アーキテクチャ上の問いは、どのシステムがそれぞれの識別子を所有し、それがどんな約束をしているかです。ビジネスが本当にそれを保証している場合にだけ、一意にしましょう。

データ型ごとに見る

次はデータ型そのものです。どのオブジェクトでも新規項目を開くと、設定がすべての一覧を表示してくれます。私がこれから順に説明するのと同じまとまりで並んでいます。Salesforceが計算してくれる項目、リレーションの項目、そしてデータ型です。

設定、新規カスタム項目のステップ1：データ型（スクリーンショット、2026-10-12）。 原寸で表示

一覧全体をひと目で見られるようにし、それぞれについて覚えておいてほしいことを一つずつ添えました。

グループ	データ型	覚えておくこと
計算	自動採番	最大30文字、うち20文字が接頭辞または接尾辞。人のためのラベルであり、レコードの識別ではない
	数式	保存されず、読まれるときに計算される。3,900文字
	積み上げ集計	従レコードの件数、合計、最小値、最大値。主従関係のみ
リレーション	参照関係、主従関係、外部参照関係	モジュール7
データ	チェックボックス	真か偽で、デフォルトは自分で選ぶ。それでもフローではnullが現れ得る
	数値、パーセント、通貨	丸めのルール。先頭のゼロは落ちる。小数点以下15桁
	日付、日付/時間、時間	日、瞬間、または一日のうちの時刻。瞬間はUTCで保存される
	メール、電話、URL	保存時に書式が整えられ、チェックされる。80、40、255文字
	地理位置情報、住所	1項目より多く数えられる複合項目：3と9
	選択リスト、複数選択	管理された語彙で、管理者が所有する
	テキスト、テキストエリア、ロング、リッチ、暗号化	255文字まではレコードとともに保存され、インデックス可能。それを超えると、インデックスも絞り込みもない

Salesforceが計算してくれる項目

自動採番は、新しいレコードごとに、T-{000000}のように自分で決めた形式で、連番の次の番号を割り当てます。人にとってわかりやすい呼び名が必要で、誰かにそれを考えさせるべきではないときに使います。値全体は最大30文字で、そのうち20文字が接頭辞または接尾辞のために確保されています。ただ、第2章を思い出してください。それは人のためのラベルであり、レコードの識別ではありません。そして番号は必ずしも厳密に連続するとは限りません。

数式項目は、ほかの項目から値を計算します。強力で、しかも保存されるときではなく、レコードが読まれるときに計算されるので、保存されて古くなるものがありません。数式が何を返すかは自分で選びます。チェックボックス、通貨、日付、日付/時間、数値、パーセント、テキスト、時間です。

新規カスタム項目、数式：戻り値のデータ型を選ぶ（スクリーンショット、2026-10-12）。 原寸で表示

それから、項目、演算子、関数を使って数式そのものを書き、構文をチェックします。数式アシスタントを使用ボタンに注目してください。今ではSalesforceのAIが数式を書くのを手伝ってくれます。使ってください。そして、それが書いたものを読んでください。数式を所有するのはアシスタントではなく、あなたです。

数式エディターと数式アシスタント（スクリーンショット、2026-10-12）。 原寸で表示 数式は最大3,900文字まで書けますが、保存時またはコンパイル時に15,000バイトを超えることはできません。長い数式は、互いを参照し合う複数の数式項目に分けることができます。ロングテキストエリア、暗号化項目、説明項目は数式の中で使えません。

積み上げ集計項目は主側に置かれ、その従レコードの件数、合計、最小値、最大値を求めます。主従関係をまたいでしか機能せず、それが主従関係を選ぶ最大の理由の一つです。積み上げ集計とその制限には、モジュール7で戻ってきます。

保存か、導出か？

そもそもこの値を保存する必要があるか？　数量と単価があるなら、誰か、あるいは何かの自動化が合計を保守する必要があるでしょうか？　数式で導出すべきかもしれません。計算の源は一つで、読まれるときに再計算されるので、数量を変えれば答えもついてきます。数式にも独自の制限があり（保存サイズと表示の長さ。Formula Field Limits and Restrictions (opens in a new tab)、英語）、複雑な数式は保守が難しくなります。

しかし、ビジネスが今日の答えではなく、当時の答えをほしがることもあります。割引のルールが来年変わったら、昨年の請求書の金額が急に変わるべきでしょうか？　もちろん違います。ですから問いは「Salesforceがこれを計算できるか？」ではありません。**「これは現在の計算か、それとも過去の事実か？」**です。過去の事実は保存します。

リレーションの項目

参照関係、主従関係、外部参照関係も項目であり、モデルの線が現実のものになる場所です。参照関係はゆるいつながりです。主従関係は、子の生涯、所有、セキュリティを親に結びつけます。外部参照関係は、モジュール4の外部オブジェクトに、その外部IDで照合して届きます。それらのどれを選ぶかは、独自のモジュールに値するほど大きな判断です。

チェックボックス

チェックボックスは、最もシンプルな項目です。真か偽か、チェックありかなしか。レコードについての「はい／いいえ」の事実にぴったりです。有効かどうか、設置が必要か、受領サイン済みか。作成するとき、Salesforceはデフォルト値、チェックありかなしかを選ばせます。これは本当の判断です。その項目を送らずに連携が作成するレコードも含めて、すべての新しいレコードがその値から始まるからです。レポートやリストビューではTrueとFalseで絞り込みますが、インポートツールや週次エクスポートでは1と0で表示されます。

知っておくべき罠が一つあります。レコード上の項目には2つの値がありますが、その周りの自動化には3つ目の値があり得ます。フローでは、一度も設定されていないチェックボックス変数は偽ではなくnullであり、それをレコードに保存すると失敗します（Trailblazer Community (opens in a new tab)、英語。Salesforceの既知の問題W-11208535 (opens in a new tab)も参照）。筋の通ったデフォルトを選び、フローやコードではnullを意図して扱いましょう。

数値、パーセント、通貨

数値は実数を保存し、先頭のゼロを落とします。だからこそ、001247のような車両番号は数値ではないのです。Salesforceは数値項目を0から遠ざかる方向に四捨五入します。12.345は12.35になり、−12.345は−12.35になります。そして差し込み項目では、項目に設定した小数点以下の桁数ではなく、ユーザーのロケールに合わせて丸めます。

パーセントは小数を保存し、パーセンテージで表示します。0.10と入力すると10%と表示されます。小数点以下15桁を超えると、値の精度が失われます。

通貨はお金の書式で表示され、複数の通貨を使う組織では通貨コードを持ち、為替レートを使えます。高度な通貨管理 (opens in a new tab)（英語）を使うと、商談は日付による為替レート、つまり案件がクローズした期間のレートを使えます。日付による為替レートを使うのは商談とその周りのもの（商品、スケジュール、分割、そしてそれらのレポート）だけで、ほかのオブジェクトの通貨項目は単一の固定レートのままです。丸めには注意してください。小数点以下の桁数がゼロなら、Salesforceは単純に切り捨てます（23.5は23になります）。1桁以上なら、0から遠ざかる方向に四捨五入します。

日付、日付/時間、時間

3つのデータ型に、3つの違う意味があります。日付は日です。契約はある日付に満了します。日付/時間は瞬間です。配送はその朝の9時42分に到着しました。時間は日付をまったく持たない一日のうちの時刻です。店は毎日7時に開きます。

罠は瞬間にあります。Salesforceは日付/時間の値をGMT（UTC）で保存します。ユーザーが入力した時刻はそのユーザーのタイムゾーンで読み取られ、変換されて保存されます。誰かがそれを読むときには、読む人のタイムゾーンに再び変換されます。たいていは、それこそが望む動きです。でも、私がクラスで出す例はこうです。ロサンゼルスのコーディネーターが、日曜日の夜遅く、太平洋時間の午後10時に配送を記録します。その下で、Salesforceが保存したのは月曜日の朝、GMTの午前5時です。別のタイムゾーンで日ごとにグループ化したレポートや、生の値を読む連携は、その日曜日の配送を月曜日に入れてしまうことがあります。「それが起きた日」は、誰の時計に尋ねるかで変わるのです。ユーザーのタイムゾーンに気を配り、ビジネスがどのタイムゾーンを意味しているのかを決めましょう。

そして、比較するときにも注意が必要です。その下では、日付/時間は一つの大きな数値です。Apexはそれを1970年1月1日 00:00:00 GMTからのミリ秒数として読みます（Datetime Class (opens in a new tab)、英語）。それは正確な瞬間であって、日ではありません。ですから、2つの日付/時間が等しいか（==）を問うと、望む結果になることはほとんどありません。9:42:00と9:42:01は等しくありませんし、「月曜日」と月曜日のどの瞬間も等しくありません。代わりに範囲で問いましょう。開始以降（>=）かつ終了以前（<=）です。「月曜日のすべての配送」とは、ビジネスが意味すると決めたタイムゾーンで、>= 月曜日00:00 かつ <= 月曜日23:59:59 のすべての配送です。

そして面白いものを一つ。Salesforceはどんな日付でも保存できるわけではありません。有効な日付は1700年1月1日から4000年12月31日までで、Salesforceは日付と日付/時間について同じ範囲を示しています（Data Import Dates (opens in a new tab)、英語）。両端でさえGMTの瞬間なので、太平洋時間のユーザーにとって最も早い有効な値は1699年12月31日の午後4時です。地元の歴史協会の創立日は入らないかもしれません。そして「終了日なし」の定番の手、9999年12月31日は拒否されます。遠い未来の仮の値が必要なら、4000年以前でなければなりません。

メール、電話、URL

これらは書式付きの項目で、文字を保存する以上のことをしてくれます。メールは最大80文字を保持し、正しい書式かどうかがチェックされます。取引先責任者やリードでは、クリックするとそのアドレスへのメール作成が始まります。電話は最大40文字を保持し、電話番号の書式で表示され、組織に電話システムが接続されていればクリックしてダイヤルできるようになります。URLは最大255文字を保持し、リンクとして開きます。プラットフォームが振る舞いを無料で与えてくれているのです。だから私は電話番号を普通のテキスト項目に保存することは決してしません。

連携もチェックを受けます。不正な形式のメールアドレスのように、項目の書式に合わない値は検証に失敗し、その項目だけでなくレコード全体が拒否されます。ですから、ソースシステムのデータが乱雑なら、届く前にきれいにするか、ロードされないレコードへの対応を計画しておきましょう。

地理位置情報と住所

地理位置情報は緯度と経度を保持します。その下では、Location__cという項目は実は2つの値で、Location__Latitude__sとLocation__Longitude__sをそれぞれ個別に読み書きできます。そしてそれでクエリもできます。SOQLのDISTANCE関数とGEOLOCATION関数で、ある半径内のレコードを見つけたり、距離の近い順に並べたりできます。「このトラックから25マイル以内にある未完了の配送すべて」は、1つのクエリです。WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25（Location-Based SOQL Queries (opens in a new tab)、英語）。住所は、番地、市区町村、都道府県、郵便番号、国からなる住所全体を保持し、ユーザーは住所を検索して各部分を自動で埋めることができます。

どちらも複合項目です。画面上では1つの項目でも、その下ではいくつもの項目です。そしてオブジェクトの上限に対して、1項目より多く数えられます。地理位置情報は3つのカスタム項目として、住所は9つとして数えられます。すでに項目が混み合っているオブジェクトでは、これが効いてきます。

選択リストと複数選択

選択リストは、ユーザーが入力できるものを管理します。自分で定義したリストから1つの値を選ぶのです。状況？　おそらく選択リストでしょう。でも値はメタデータであり、管理者が追加や変更をしなければなりません。ですから私はそれでも問います。値を誰が所有するのか、どれくらいの頻度で変わるのか、複数のオブジェクトが同じリストを必要とするか、値がそれ自体の情報を持っているか、そして別のシステムが語彙を所有していないか。

値をどこに置くかも判断です。リストが1つの項目で一度だけ使われるなら、値は項目そのもの、つまりオブジェクト上に置きます。それがSalesforceのデフォルトです。でも、同じ値の集合が複数の場所に現れ始めたら、たとえば取引先、配送、倉庫のそれぞれに地域があるなら、コピーがばらばらになる前にグローバル値セットに昇格させましょう。グローバル値セットは、それらすべてのために1つのリストを保持し、有効な値と無効な値を合わせて最大1,000個まで持てます（Picklist Limitations (opens in a new tab)、英語）。設定画面自身の説明が、なぜそれが大事なのかを語っています。値セットは「ユーザーがAPIを通じて承認されていない値を追加できないよう制限されている」のです。1つのリスト、1人の所有者、そして新しい綴りをこっそり持ち込む連携はなし。

最後の点が、制限付きと制限なしの違いです。制限付き選択リストでは、管理者が定義した値だけが、どこからでも許されます。それ以外の値を送るユーザー、インポート、連携は「bad value for restricted picklist field」というエラーを受け取り、レコードは保存されません。制限なし選択リストでは、ユーザーは画面上ではリストから選びますが、API、インポート、自動化はどんな値でも送ることができ、Salesforceはそれを保存して、無効な値として追加します（Picklist Limitations (opens in a new tab)、Create a Custom Picklist Field (opens in a new tab)、英語）。こうして組織には「Delivered」「delivered」「Dlvrd」が並ぶことになります。グローバル値セットは常に制限付きです。私のデフォルトは制限付きです。制限なしは、別のシステムが本当に値を所有しているときの意図的な選択であり、その場合は無効な値の片付けを誰かが担当します。

設定、選択リスト値セット：新しいグローバル値セット（スクリーンショット、2026-10-12）。 原寸で表示

複数選択リストでは、ユーザーは複数の値を選べ、それらはセミコロンで区切られてまとめて保存されます。画面上では便利ですが、それ以外のあらゆる場所で扱いにくいものです。絞り込み、レポート、連携が難しく、積み上げ集計の絞り込み条件にも使えません。1つのレコードに複数の値があるのは、たいてい第2章の教訓です。外に出ようとしている子オブジェクトがあるのです。

選択リストには、定義した値のほかにもう一つ値があります。空白です。レコードは何も選ばれていない状態でいられ、これに人は引っかかります。数式や入力規則では、選択リストをISBLANKだけでテストすることはできません。ISBLANK(TEXT(Field__c))やISPICKVAL(Field__c, "")と書きます（Trailblazer Community (opens in a new tab)、英語）。ですから、すべての選択リストについて「値なし」が何を意味するのかを決めましょう。許されるのか、そしてそうなったときに何を意味するのか？　そのうえで、数式、入力規則、絞り込み条件でそれを扱うようにします。

そして、属性が実はエンティティであることもあります。誰かが物流センターの選択リストを求めます。9か所です。簡単です。そのあとで、それぞれに住所、責任者、営業時間、処理能力、地域、トラックがあるとわかります。それは選択リストではありません。「もの」です。まだ数が少ないというだけで、エンティティを選択リストにしてはいけません。 1年目は快適でも、5年目にはひどいことになります。（リストがいつ独自のオブジェクトに値するかについての私の経験則は、第2章のモジュール5にあります。）

テキストの仲間

私はテキストを2種類として教えていて、その境界線は255文字です。

255文字まで：レコードとともに保存される。 テキストは最大255文字を保持し、ほとんどどこでも使えます。数式、絞り込み条件、レポート、リストビューで、また一意の項目や外部IDとして使え、インデックスも作れます。テキストエリアも255文字を保持し、短いメモのように複数行で入力できます。

255文字超：参照で保存される。 ロングテキストエリアは最大131,072文字を保持し、リッチテキストエリアは同じ量を書式、リンク、画像付きで保持します。私はこれらを、レコードがポインタを持ち、本体は脇に保存されているものと考えています。そして実際にそう振る舞います。インデックスがないので、一意にも外部IDにもできません。SOQLのWHERE句で絞り込むことはできません（SOQL WHERE (opens in a new tab)、英語）。数式でも使えません（Formula Field Limits and Restrictions (opens in a new tab)、英語）。そしてレポートでは、カスタムのものは最初の254文字しか表示されず、レポートの絞り込み条件も最初の約255文字しか検索しません（Filter Restrictions for Text Area (Long) Fields (opens in a new tab)、英語）。リッチテキスト項目にアップロードした画像は1つにつき最大1 MBで、ファイルストレージに数えられ、テキストはデータストレージに数えられます（Rich Text Area Field Considerations (opens in a new tab)、英語）。ですから、誰かがその値で検索、並べ替え、照合、レポートをする必要があるなら、255文字未満に収めて、テキスト項目にしておきましょう。

**テキスト（暗号化）**は、クラシック暗号化を使って最大175文字を暗号化された形で保存します。組織がShield Platform Encryptionを使っているなら、代わりに普通のテキスト項目を暗号化します。ほかの多くのデータ型も、その方法で暗号化できます。

すべての項目に説明を付ける

私の基準は、すべての項目に説明を付けることです。長い間そう信じてきましたし、AIの時代にはこれまで以上に重要です。組織を読むすべてのAIツールとエージェントは、項目が何を意味するのかを理解するために説明を読みます。空の説明は、当て推量を待っているようなものです。Customer_Status__cは何を意味するのか？　誰が所有しているのか？　どこから来るのか？　ユーザーが編集できるのか、それとも今夜ERPが上書きするのか？　半年後には私も覚えていませんし、3年後に組織を保守する管理者は、私たちが伝えておかない限り知りようがありません。表示ラベルはドキュメントではありませんし、API参照名もそうではありません。

多くの人が共有するオブジェクト（取引先、取引先責任者、商談）では、特殊な項目に命名の接頭辞も使い、出どころと目的が名前そのものに表れるようにしています。たとえば、ERPが所有するものはすべて同じ接頭辞で始める、というように。12語もあるAPI参照名がほしいのではありません。モデルが自分自身を説明してくれるようにしたいのです。

大切なものを分類する：分類項目

Salesforceはすべての項目に、分類のためのメタデータを用意しています。私はこれを分類項目（taxonomy fields）と呼んでいます。データ所有者、項目の使用状況（Active、DeprecateCandidate、Hidden）、データ機密度（Public、Internal、Confidential、Restricted、MissionCritical）、そしてコンプライアンス分類（PII、HIPAA、GDPR、PCI、CCPAなど）を記録できます。カスタム項目だけでなく標準項目でも使えます（Data Classification Metadata Fields (opens in a new tab)、英語）。

なぜわざわざ？　プロセスがそれを読めるからです。項目にGDPRのフラグを付ければ、プロセスはレコード上のすべてのGDPR項目を見つけて、マスクしたり削除したりできます。そしてSalesforceのトラストレイヤーが大規模言語モデルにプロンプトを送るとき、まさにこの分類を使って機密項目をマスクできます。送り出すときに顧客の名前、たとえば「マリア・ロペス」をプレースホルダーに置き換え、モデルは名前を見ることなく、戻ってきたときに応答の中で名前が元に戻されます（Einstein Trust Layer (opens in a new tab)、英語）。

最新情報。 Salesforceは現在、LLM向けのパターンベースおよび項目ベースのマスキングがエージェントでは無効になることを文書化しています。マスキングによって、エージェントが答えるのに必要なコンテキストが失われる可能性があるためです（Data Masking Limitations in Agentforce (opens in a new tab)、英語）。分類はほかの生成AI機能では引き続きマスキングを動かしますが、個人データをエージェントから遠ざけるためにそれを当てにしないでください。それはアクセスと設計の判断です（第12章）。

私の立場は、分類は要所で重要になるということです。ガバナンスがそう言ったからといって、すべての欄を埋める3週間の作業にしないでください。重要なところで使いましょう。個人データ、財務データ、規制対象のデータ、そしてビジネスが名前の付いた所有者を必要とする項目です。大事なのは、機密性が誰かの頭の中の知識であることをやめ、項目の一部になることです。

試験の先へ：AIが変えること。 以前は、項目のドキュメントが貧弱だと困るのは次の管理者でした。今では、スキーマを読むすべてのAIツールとエージェントを惑わせます。Flag2__cは機密なのか、権威ある値なのか、まだ使われているのか？　AIはどんなチームよりも速く項目を作りもします。ですから名前、説明、分類は、片付けではなくアーキテクチャの一部なのです。

すべての項目は約束である

項目がいったん世に出てデータを集め始めると、あらゆるものがそれに寄りかかり始めます。画面が表示し、フローが分岐し、入力規則がチェックし、レポートがグループ化し、連携が送ったり読んだりし、そして今ではAIツールがそれについて推論します。そのどれもが、項目について前提を置いています。データ型、長さ、空になることがあるか、そして値が何を意味するか。後から項目を変えるなら、まずそうした前提をすべて見つけ出さなければなりません。選択リストの値の名前を変える、テキスト項目を短くする、テキスト項目を選択リストに変える。小さな変更に聞こえますが、別の会社のシステムにある連携を壊しかねません。だから項目は約束なのです。

Click to enlarge

このモジュールを読んで、項目を作るのが怖くなってほしいわけではありません。Salesforceは拡張されるように作られています。活用しましょう。問いを「どのデータ型を選ぶべきか？」から、**「このデータは何を意味し、どんな振る舞いを約束しているのか？」**へ変えてほしいのです。データ型、必須、一意、外部ID、選択リスト、数式、説明、分類。これらが合わさって、第2章の論理モデルの物理的な表現になります。

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

• データ型を選ぶ前に、その値が何を意味するのか。そしてそれが属性なのか、識別子なのか、管理された語彙なのか、実は別のエンティティなのか。
• 値が導出できる現在の計算なのか、保存しなければならない過去の事実なのか。
• どのシステムがそれぞれの識別子を所有し、その一意性が本当のビジネス上の約束なのか。
• 必須の値が実際にいつわかるのか、そしてそれを持たないレコードや連携に何が起きるのか。
• 人、プロセス、AIが安全に使えるように、項目にどんな説明、命名、分類が必要か。

さらに学ぶ

• Salesforceヘルプ、Data Classification Metadata Fields (opens in a new tab)（英語）、2026-10-02確認。
• Salesforceヘルプ、Einstein Trust Layer: Designed for Trust (opens in a new tab)とData Masking Limitations in Agentforce (opens in a new tab)（英語）、2026-10-02確認。
• Salesforce Developers、Insert or Update (Upsert) a Record Using an External ID (opens in a new tab)（英語）、2026-10-02確認。
• Salesforceヘルプ、Picklist Limitations (opens in a new tab)（英語）、2026-10-02確認。
• Salesforceヘルプ、Formula Field Limits and Restrictions (opens in a new tab)（英語）、2026-10-02確認。
• Salesforce Developers、Date Formats and Date Literals (opens in a new tab)（英語）、2026-10-02確認。