データの一貫性を保つ

🌐 ほかに 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で翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール9／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。 前へ：所有とライフサイクル · 次へ：Salesforceの物理モデルを設計する

このモジュールが答える問い： データの一貫性をどう保ち、それぞれの層にはどんなコストがあるのか？

誰もがきれいなデータをほしがります。要件定義の会議で「本当にほしいのは一貫性のないデータです」と言う人には、一度も出会ったことがありません。意見が分かれるのはその後です。ルールをどこで強制するのか？　画面で？　必須項目で？　選択リスト、入力規則、重複ルール、フロー、Apex？　どれも役に立ちます。互いに置き換えられるものではなく、どの層にもコストがあります。

私の一般的なルールは、ルールを無理のない範囲でできるだけ下の層に置くことです。値が5つのうちのどれかにしかなり得ないなら、何でも入力させておいて後から自動化で片付けるのはやめましょう。2つのレコードが決して同じ識別子を共有してはならないなら、誰かがレポートで気づくのを当てにしないでください。レコードが画面、API、連携、データロード、エージェントのどこから来てもルールが守られなければならないなら、UIだけで強制しないでください。ルールがデータに近いほど、迂回するのは難しくなります。私はこれを一貫性のはしごと呼んでいます。

1段目：データ型と語彙

最初の一貫性のルールは、モジュール6のものです。正しいデータ型を選ぶ。 日付は日付型、瞬間は日付/時間型、お金は通貨型。誰かがルールを書く前の一貫性です。

配送のステータスをテキスト項目にすれば、Delivered、delivered、DELIVERED、Complete、Done、Dropped offが入ってきて、その6つが同じ意味なのかを誰かが突き止めなければならなくなります。あるいは語彙を一度だけ定義しましょう。Delivered、一つの値、一つの意味。制限付き選択リストにすれば、APIからであってもリストにない値を拒否します。複数の項目がリストを共有するならグローバル値セットにします（詳しくはモジュール6にあります）。

でも、入力をさせないためだけに選択リストを使わないでください。それは本当に値なのか、それとも別のエンティティなのか？　名前だけを持つ9つの物流センターは選択リストに見えるかもしれません。住所、責任者、処理能力、トラックを持つ9つの物流センターはレコードです。ルールはモデルを補強すべきであって、悪いモデルを埋め合わせるべきではありません。そして本当に管理された語彙なら、項目で管理しましょう。混乱を許しておいて、AZ、Arizona、Ariz、Phoenix areaを最初からほしかった値に変換するフローを作るのはやめましょう。

2段目：必須と一意

必須と一意はシンプルなので魅力的です。チェックを入れれば問題は解決。ときには。すべてのトラックが作成された日から車両番号を持ち、2台のトラックが同じ番号を共有することがないなら、両方のチェックボックスが本当のビジネスルールを表しています。それは強い一貫性です。

しかし、プラットフォームがいったんルールを強制し始めると、あなたのプロセスに火曜日の午後の例外があることなど気にかけません。私はクラスでこの例を何年も使ってきました。あるオブジェクトが以前からあり、レコードもたくさんあります。誰かが項目を追加し、必須にチェックを入れます。レコードの作成をテストすると、見事に動きます。そして土曜の夜、デプロイ、テストが走り、古いテストクラスが新しい項目なしでそのオブジェクトを作成します。ドカン。あるいは誰かが、その項目ができる前の古いレコードを編集します。あるいは連携が、5年間送ってきたのと同じペイロードを送ってきます。ドカン。「でも、その項目は変えていない」。プラットフォームは気にしません。有効なレコードとは何かという契約を、あなたが変えたのです。新しいルールは新しいデータだけに影響するのではありません。古いデータでできることを変えるのです。

3段目：入力規則

入力規則を使えば、ずっと豊かなことを言えます。ステータスが配送済みなら、実際の配送時刻が入っていなければならない。停車地が設置なら、停車地を閉じる前にチェックリストが完了していなければならない。入力規則はレコードが保存されるときに動くので、ページ、API、データロード、連携、エージェントのどこから保存されてもレコードを守ります。そこが肝心です。ルールがレコードを守らなければならないなら、すべての書き込みが通る場所に置きましょう。

入力規則には歯もあります。それが強みであり、コストでもあります。

古いレコードの問題

ここで厄介なことになります。100万件のレコードがあり、今日ルールを追加します。配送時刻はルートの出発時刻より前であってはならない。もっともなルールです。しかし、7年前の移行のせいで、古いレコードのうち2万件がそれに違反しています。ユーザーがそのうちの1件を開き、電話番号を変えます。保存。ルールが発動します。「電話番号を変えただけなのに。なぜ2019年の配送時刻の話をされるのですか？」もっともな疑問です。

ですから入力規則は、何が真でなければならないかだけでなく、いつそれを強制するかも言うべきです。ISNEW()やISCHANGED()のような関数を使えば、ルールの対象を新しいレコードや、関係する項目が実際に変わる保存に絞れます（Validation Rule Considerations (opens in a new tab)、英語）。

しかし、レコードが変わるのは人が編集したときだけではなく、その理由の多くはあなたの手の届かないところにあります。連携が夜間にステータスを更新します。フローが日付を記録します。マネージャーがテリトリーを再割り当てし、1万件のレコードで所有者が変わります。誰かが配送品目を編集すると、配送の積み上げ集計が再計算され、それが配送を保存するので、配送に一度も触れていないユーザーに対して配送の入力規則が起動します（Roll-Up Summary Field (opens in a new tab)（英語）は、入力規則のエラーが詳細にも主にも表示され得ると注意しています）。それらの保存のどれもが、あなたの新しいルールに出会います。ですから新しいルールごとに問いましょう。このルールはその保存に適用されるべきか？

選択肢は次のとおりで、それをルールに織り込みます。

• 常に、すべての保存で。ルールが本当にレコードについてのもので、古いデータも通るなら正解です。ただし「すべての保存」が何を意味するかを知っておきましょう。所有者を変えるだけのバッチジョブも、レコードのどこかの項目へのちょっとした編集も、それを通らなければなりません。
• 新規レコードのみ、ISNEW()で。ルールはレコードを作成時に一度だけ確認し、二度と確認しません。過去はそのままですが、未来もそのままです。後の編集で新しいレコードがルールに違反しても、誰も止めません。それが問題なら、次のものと組み合わせましょう。
• 対象の項目が変わったときのみ、ISCHANGED()で。電話番号を編集しても、配送時刻のルールは目を覚ましません。
• 特定の書き手には適用しない。 数式の中で$Permissionとして確認するカスタム権限を使えば、人にはルールを守らせたまま、連携ユーザーやデータ移行を通せます（How to Reference a Custom Permission in a Validation Rule (opens in a new tab)、英語）。意図的に、少数にだけ与えましょう。
• ある日付以降、CreatedDateをルールが稼働した日と比べます。「新規」が「これを強制し始めてから」を意味する場合です。ISNEW()と違い、それらのレコードを後の保存のたびに確認し続けるので、同じ警告が当てはまります。バッチでの所有者の更新のような小さな変更が、ずれてしまったレコードで失敗することがあります。

すでにあるレコードにルールを追加しますか？ オンにする前に、その影響を考え抜きましょう。既存のレコードはすべて、次の保存でそれを通らなければなりません。そしてその保存は、思いもよらないところから来るかもしれません。夜間の連携、バッチでの所有者変更、積み上げ集計、リストビューからの一括更新。そのどれがぶつかり、1件のレコードが失敗したらそのジョブはどうなるのか？　私が使う順序は、オンにする前にの節にあります。

ルールを満足させるために履歴を書き換えない

では、2万件の古いレコードはどうするのでしょう？　データが間違っていて、正しい値がわかっているなら、訂正しましょう。しかし私は別の種類の「修正」も見てきました。過去の真実は誰も知らないのに、ただレコードを通過させる必要があるので、今日のルールを満たす値で更新するのです。私はそれが好きではありません。古いレコードをルールに合わせて更新するとLastModifiedDateが変わって重要な履歴情報が失われますし、値をでっち上げることは、知らない過去について知っているふりをすることです。履歴を書き換えるのではなく、ルールより前からあるレコードにはルールの迂回を用意しましょう。 不格好かもしれませんが、正直です。

UIでの入力チェックはデータの入力チェックではない

ページレイアウトで項目を必須にすれば、ユーザーはそれなしでは保存できません。そこで夜間の連携が5万件のレコードを挿入します。あなたのページを使ったでしょうか？　いいえ。一括ロードも、APIクライアントも、エージェントも使っていません。UIでの必須が守るのはその画面であって、データではありません。動的フォームでの項目の入力チェックも同じように回避されることがあります。ですから問いましょう。このデータはどこから入ってくるのか？　Lightning、ポータル、モバイル、連携、API、一括ロード、フロー、Apex、エージェント。入口が多いほど、そのうちの一つだけを守るルールは信頼できなくなります。

4段目：重複ルール

ここから、レコードの中の一貫性から、レコード間の一貫性に移ります。Acme Corporation、ACME Corp、Acme Inc.。顧客は4社か、それとも1社か？　項目のルールではそれに答えられません。一致ルールがレコードをどう比較するかを定義し、重複ルールが重複の可能性があるものが見つかったときに何をするかを決めます。警告付きで許可する、ブロックする、報告する。オブジェクトごとに有効な重複ルールは最大5つ、それぞれに一致ルールは最大3つまで持て、照合キーによって各比較は最も重複の可能性が高い100件に絞られます（Things to Know About Duplicate Rules (opens in a new tab)、英語）。

そのコストは摩擦です。営業担当者が作る取引先すべてに重複の可能性がありますと表示されるなら、それがまさに望んでいることの場合もあれば、人々が読まずにクリックして先に進むことを覚えてしまう場合もあります。正当なレコードが似て見えることもありますし、連携には人とは違う振る舞いが必要かもしれません。そしてその警告はSalesforce自身のものです。そのアラートと重複の可能性があるレコードの一覧は、自分で作ったカスタム画面になじまないかもしれません。保存がヘッドレス、つまり連携、データロード、エージェントによるものなら、それを表示する画面そのものがありません。ですから、すべての経路で重複がどう表に出るかを決めましょう。人には警告、APIには保存のブロックとエラー、あるいは後で誰かが確認できるように「レポート」オプションと重複レコードセット。よいアーキテクチャとは最大限の強制ではなく、正しい強制です。

そして、重複ルールが実際にどの扉を守っているかを確認しましょう（Things to Know About Duplicate Rules (opens in a new tab)、英語）。APIやデータインポートツールでは、誰も警告を目にしません。警告に設定されたルールは、単に保存をブロックします。ルールをまったく通らない経路もあります。クイック作成、復元ボタン、手動のマージ、Lightning SyncやEinstein活動キャプチャが追加したレコード。そして同時に保存されたレコードどうしは比較されず、すでにSalesforceにあるレコードとだけ比較されます。同じ顧客が2回入ったファイルをロードすれば、両方の行が通り抜けることがあります。重複ルールはよい網です。扉の鍵ではありません。

試験に出やすい知識。 重複ルールは同時に保存されたレコードどうしを比較せず、すでにSalesforceにあるレコードとだけ比較します。APIやインポートツールではアラートは出ません。ルールが捕まえた重複は、単に保存されません。そして保存とそれが引き起こすすべては一つのトランザクションとして実行されます。どこかが失敗すれば、すべてがロールバックされます。

一つの境界があります。重複ルールは一つの組織をきれいに保ちます。企業全体の識別は解決しません。SalesforceにAcme Corporationがあり、ERPにACME-10382があり、請求システムに顧客77193があるとき、重複ルールはそれらが同じ会社だとは教えてくれません。それはマスターデータ、第6章の話です。

5段目：自動化

下の段には複雑すぎるルールもあります。関連レコード、別のシステム、依存するレコード、複数ステップのプロセスが必要なものです。それがフロー、Apex、ときには連携のロジックです。（ワークフロールールやプロセスビルダーではありません。それらはサポートが終了しています。）自動化は強力で、そしてより高くつきます。動く部品が増え、テストが増え、エラー処理が増え、ある自動化が別の自動化につまずく可能性が増えます。そしてコードは独自のエラーを持ち込みます。データ型で強制できるなら、私はApexを書きません。入力規則で明確に言えるなら、フローがあるからといってフローを作りません。項目の問題をプロセスエンジンで解かないでください。

すべてか無か：レコードが一緒に変わるとき

ここまで、それぞれの段は1回の保存を守ってきました。しかしレコードは一緒に変わります。配送とその品目、注文とその明細、3つのオブジェクトを更新するフロー。ここでプラットフォームは強い保証を与えてくれます。保存とそれが引き起こすすべて、つまりトリガ、フロー、それらが呼び出すクラスは、一つのトランザクションとして実行されます。どこかが失敗すれば全体がロールバックされ、何もコミットされません（Apex Transactions (opens in a new tab)、英語）。半分だけの配送はできません。

バルクの作業は、自分で選ぶ例外です。データロードやApexのDatabaseメソッドは部分的な成功を許せます。よいレコードは保存され、悪いレコードはエラーとともに戻ってきて、誰かがそれに対処しなければなりません（DML Statements vs. Database Class Methods (opens in a new tab)、英語）。100万行のロードではそれが正しいことが多いのですが、そうなると一貫性はプロセスになります。誰がエラーファイルを読み、失敗したレコードはどうなるのか？

そしてタイミングの問題があります。同時に行われた2つの保存は、それぞれ単独なら失敗するはずのチェックを、両方とも通ってしまうことがあります。既存の注文を探してから注文を作るフローは2つとも通してしまうことがありますし、重複ルールが同時に保存されたレコードを比較しないことは、さっき見たとおりです。一意とマークされた項目や外部IDは、すべての保存でプラットフォームが確認するので、勝つのは一方だけです。一意性を項目まで押し下げる理由がもう一つ増えました。ロック、競合、再試行はそれだけで一つのテーマです。第11章『トランザクション、同時実行、信頼性』で深く扱います。

ルールを下へ押し下げる。そこに属さなくなるまで

「無理のない範囲でできるだけ下」は「常に一番下」という意味ではありません。ある項目が商談が特定のフェーズに達したときにだけ必須になるなら、スキーマで必須にするのは間違いです。ルールが条件付きなので、入力規則が正しい段です。重複について人には警告すべきだけれど、承認された連携には独自の照合があるなら、両方の経路に向けて設計しましょう。目標は、ビジネスルールを正しく表す最も下の層です。

どの層にもコストがある

Click to enlarge

見てほしいトレードオフはこれです。データ型と管理された値はシンプルで強力ですが、項目で表せることにしか使えません。必須と一意は大ざっぱです。いったんオンにすれば、すべての書き込みがそれを満たさなければなりません。入力規則はより豊かな条件を表せますが、古いレコードの編集をブロックしたり、デプロイを驚かせたりすることがあります。重複ルールはレコード間を守りますが、ユーザーと連携に摩擦を加えます。自動化は何でもこなせますが、オーケストレーション、エラー、テスト、性能を抱えることになります。無料の層はありません。それぞれのルールの層を、それがどう失敗するかを知った上で選びましょう。

オンにする前に

既存の組織にルールを追加するのは、チェックボックスではなくロールアウトです。今日何件のレコードがそれに違反し、それはなぜか？　それは本当に間違っているのか？　正しい値を知ることはできるか？　そのルールは過去にも当てはまるのか、それとも今後だけか？　どの連携、テスト、自動化がそれにぶつかるか？　よい順序はこうです。測定する、間違っていると証明できるものを片付ける、ルールの対象を絞る、正当な履歴のために意図的な迂回を用意する、すべての書き込み経路をテストする、そして強制する。測定と片付けは、それ自体が一つの規律です。プロファイリング、標準化、監視、スチュワードシップ。第5章『データの品質とガバナンス』で扱います。金曜日にチェックを入れて、土曜の夜にその結果を知るよりずっとよいはずです。

試験の先へ：AIが変えること。 エージェントはどんな人よりも速くレコードを作れますし、悪いレコードも同じくらい速く作れます。ユーザーがエージェントなら、「ユーザーはそれをしてはいけないと知っている」は守りになりません。重要なルールは、すべての書き手が通るデータの層に置きましょう。そうすれば、エージェントが会社の暗黙のルールを覚えておく必要はありません。

Steve Trucking：配送を守る

配送を例にとりましょう。ステータスは一つの語彙から来ます。制限付きの選択リストです。小売パートナーの注文番号はパートナーごとに一意でなければならないので、一意に設定した外部IDにし、積荷目録のupsertに使います。実際の配送時刻はステータスが配送済みになったら必須です。その変更に対象を絞った入力規則です。設置の停車地は、チェックリストが完了し、必要な写真（食器洗い機なら給水管、排水管、水平）が撮られるまで閉じられません。入力規則か、プラットフォームの外に保存された写真を確認する必要があるなら自動化です。再送された積荷目録から同じ注文が2回届いた場合は、外部IDが捕まえます。似て見える2つの別々の注文は、一致の問題です。

「全部フローに入れる」とは言わなかったことに注目してください。それぞれのルールが自分の段に置かれています。どのルールについても問いましょう。重要なすべての書き込み経路に対して、これを正しく強制できる最も下の層はどこか？

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

• それぞれのルールがどの段に属するか：データ型、管理された語彙、必須または一意、入力規則、重複ルール、自動化。
• どの書き込み経路を守らなければならないか：UI、ポータル、モバイル、連携、一括ロード、API、自動化、エージェント。
• 新しいルールが過去のレコードにも適用されるのか、それとも新規と変更されたデータに対象を絞り、過去には迂回を用意するのか。
• 既存の悪いデータを、通過させるために書き換えるのではなく、証拠に基づいて訂正できるか。
• あるルールに、どれだけの摩擦、複雑さ、保守の価値があるか。

きれいなデータは、人によいデータを入力してもらうよう頼むことからは生まれません。正しいことを簡単にし、間違ったことを難しくし、重要なルールを迂回しにくくするアーキテクチャから生まれます。次は、Steve Truckingの一部分で、この章をまとめます。

さらに学ぶ

• Salesforceヘルプ、How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab)とRoll-Up Summary Field (opens in a new tab)（英語）、2026-10-13確認。
• Salesforceヘルプ、Picklist Limitations (opens in a new tab)（英語）、2026-10-02確認。
• Salesforceヘルプ、Validation Rule Considerations (opens in a new tab)（英語）、2026-10-02確認。
• Salesforceヘルプ、Things to Know About Duplicate Rules (opens in a new tab)（英語）、2026-10-13確認：制限、ルールが実行されない経路、APIとインポートでの保存はアラートなしでブロックされること、同時の保存は比較されないこと。
• Apex開発者ガイド、Apex Transactions (opens in a new tab)とDML Statements vs. Database Class Methods (opens in a new tab)（英語）、2026-10-13確認：一つのトランザクションは単位としてロールバックされる。Databaseメソッドは部分的な成功を許せる。
• Salesforceヘルプ、Workflow Rules & Process Builder End of Support (opens in a new tab)（英語）、2026-10-02確認。