所有とライフサイクル

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

モジュール8／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。 前へ：リレーションには結果が伴う · 次へ：データの一貫性を保つ

このモジュールが答える問い： 誰がレコードを所有し、その生涯を通じてレコードに何が起きるのか？

データモデルを見るとき、私はオブジェクトが何で、どうつながっているかだけを知りたいのではありません。レコードに時間とともに何が起きるのかを知りたいのです。誰が作るのか？　誰が所有するのか？　誰が再割り当てできるのか？　ビジネス上の関係が変わったら、もう有効でなくなったら何が起きるのか？　削除されるべきときは来るのか、どれくらいの期間保持するのか？　どれもERD、つまりエンティティ・リレーションシップ図（第2章のデータモデルの箱と線）には現れません。どれもデータアーキテクチャです。そしてSalesforceでは、所有こそがデータモデルとセキュリティモデルがぶつかり合う場所なのです。

所有は項目の中の名前以上のもの

管理者はレコードの所有者を見て、それをラベルとして読みます。バートがこの取引先を所有し、リサがあのケースを所有している。そういう意味のこともあります。しかしSalesforceでは、所有はプラットフォームの仕組みでもあります。所有者を持つオブジェクトでは、ロール階層、共有ルール、キュー、再割り当てを通じて、所有者が誰がレコードを見られるかを決めます。ですから私が「このレコードの所有者は誰か？」と尋ねるとき、ページにどの名前が載るかを尋ねているのではありません。それにどんなセキュリティとライフサイクルの振る舞いを結びつけているのかを尋ねているのです。所有者はユーザーにも、一部のオブジェクト（カスタムオブジェクト、ケース、リードなど）ではキューにもなれます。どちらの場合も、所有者はレコードへのフルアクセスを得ます（Understanding Sharing (opens in a new tab)、英語）。

だから私は、ビジネス上の責任とレコードの所有を分けます。同じ人のこともあれば、そうでないこともあります。ビジネスが配車担当者に配送の責任があると言っても、それで自動的に配車担当者が所有者になるわけではありません。責任は独自の項目に置き、所有はセキュリティと規模を支えるように設定できます。両方に「オーナー」という言葉が使われているからといって、二つを混同しないでください。

共有テーブル：所有がアクセスになる場所

共有テーブルが何なのかさえ知らない人もいます。データアーキテクトなら誰もが知っておくべきです。

レコードの共有のほとんどは、関連する共有オブジェクトに保持されています。Salesforce版のアクセス制御リストです（Understanding Sharing (opens in a new tab)、英語）。取引先にはAccountShare、取引先責任者にはContactShareがあり、カスタムオブジェクトには独自のものができます。Truck__cにはTruck__Shareです（Sharing a Record Using Apex (opens in a new tab)、英語）。その各行は4つのことを言っています。

• どのレコードか：親のID。
• 誰に：ユーザー、またはグループ（公開グループ、ロールのグループ、テリトリー）。
• どれだけ：参照、編集、またはすべて（フルアクセス）。
• なぜ：行の理由（row cause）。所有者にはOwner、共有ルールにはRule、手動共有にはManual、Team、Salesforceが取引先とその子の間に追加する暗黙の理由、そして開発者がApex共有のために定義する理由。

クラスでは、Workbenchを開き、レコードを共有しながら共有テーブルをクエリします。行が現れたり消えたりするのを見てもらうのです。誰かが「なぜこの人はあれを見られるのか？」と尋ねたら、答えはたいてい、理由付きで1行の中にあります。

しかし、すべてがそこにあるわけではありません。組織の共有設定は行ではありません。ロール階層もそこには保存されていません。所有者より上の人たちのアクセスは、必要になったときに算出されます。そして「すべて表示」「すべて変更」「すべてのデータの参照」「すべてのデータの編集」は、共有テーブルを完全に飛ばします（Sharing a Record Using Apex (opens in a new tab)、英語）。クラスではこう言っています。「すべて表示」にチェックを入れたら、共有テーブルを迂回したことになる。

Salesforceは、関連の仕方に応じて、一部のレコードを代わりに共有してくれます。これが暗黙的な共有で、取引先とその子の間で働きます。取引先責任者、ケース、商談を見られるなら、それが属する取引先も参照できます。そして取引先の所有者は、その取引先の取引先責任者、ケース、商談へのアクセスを、所有者のロールで設定されたレベルで得ます（Implicit Sharing (opens in a new tab)、英語）。最近のリリースでは、Salesforceはその子へのアクセスの一部を行として保存せず、必要なときに算出するので、共有テーブルをクエリしても表示されなくても驚かないでください。ここではヒントを出すだけです。詳しくはリレーションと組み込みの共有にあります。

もう一つ、外部ユーザーが多いときの例外があります。大規模コミュニティユーザー、つまり何千人から何百万人もの顧客のために作られたCustomer Communityライセンスは、ロールを持たず、公開グループに入れず、共有ルールや手動共有でレコードを与えることもできません（About High-Volume Community or Site Users (opens in a new tab)、Sharing Rule Considerations (opens in a new tab)、英語）。彼らにとっての答えは共有テーブルではありません。彼らは共有セットを通じてレコードにたどり着きます。共有セットは、レコードの取引先や取引先責任者をユーザー自身のものと照合します。それが、これらのライセンスが規模を拡大できる理由の一つです。Sharing and Visibilityのコースでは外部ユーザーとの共有で扱います。

そしてモジュール7を思い出してください。詳細オブジェクトには共有オブジェクトがまったくありません。そのアクセスは、主の共有オブジェクトと、主従関係項目の共有設定から来ます。

なぜデータアーキテクトが気にするのでしょう？　所有がこのテーブルに書き込まれるからです。所有者の変更、新しい共有ルール、ロールやグループを移るユーザー、そのたびにSalesforceは行を追加し、削除します。数千件なら誰も気づきません。1,000万件で、一人のユーザーがそのほとんどを所有していれば、それがこのあとすぐ出会う再計算です。

試験に出やすい知識。 カスタムオブジェクトの共有オブジェクトはObject__Shareという名前で、Truck__Shareのようになります。詳細オブジェクトには共有オブジェクトがありません。アクセスは主から来ます。そしてレコードの所有者が変わると、その手動共有は削除されますが、開発者独自の理由を持つApex共有は残ります。

ここで、データモデルはセキュリティモデルにバトンを渡します。残りはSharing and Visibility Architectのコースで教えます。スティーブの、レコードを共有する22の方法、組織の共有設定、所有、キュー、ロール階層、暗黙の共有についてはリレーションと組み込みの共有、Apex共有の理由についてはプログラムによる共有と安全なコードです。このコースでは、第12章が人間、アプリケーション、エージェントのためにそれをまとめます。

所有は引き継がれることもある

前のモジュールで、主従関係の子には独自の所有者がなく、親に従うことを見ました。それはしばしばまさに正しいことです。ビジネスは、配送のすべての品目に別々の所有者を必要としているでしょうか？　いいえ。配送がライフサイクルを所有し、品目はそれに属しています。だからリレーションの設計と所有の設計は一緒に行われるのです。主従関係を選んだとき、所有の判断の一部はすでに下していたのです。

システムが作るレコードは誰が所有するのか？

ここから面白くなります。人が取引先を作れば、その人が所有者になるかもしれません。しかしERPが夜間に10万件のトランザクションを送ってきます。それは誰が所有するのでしょう？　連携ユーザー？　キュー？　データから割り出した地域の所有者？　5年間誰も気にかけていなかったシステムアカウント？　そして今ではエージェントもレコードを作ります。

私の立場は、所有が共有にとって重要かどうかによるというものです。連携ユーザーやエージェントユーザーは正当なユーザーであり、レコードを所有できます。そのオブジェクトで所有がアクセスを決めている（ロール階層や共有ルールを通じて）なら、レコードを正しい所有者に割り当てましょう。実在のユーザー、キュー、あるいは専用の所有者ユーザーです。そうでないなら、システムユーザーを所有者のままにしておくほうがよい選択かもしれません。そうすれば、監査証跡がレコードを作ったものにまっすぐたどり着くからです。

どちらにしても、意図的に決めましょう。すべてを所有する連携アカウントは、知らないうちにセキュリティアーキテクチャの一部になっています。それが無効化されたら何が起きるのかを、誰かが知っておく必要があります。

所有は規模の問題になり得る

分布も重要です。1,000万件のレコードが何千人もの所有者に散らばっているのは一つの形です。1,000万件のレコードを1人のユーザーが所有しているのは、まったく違う形です。Salesforceは、一人のユーザーがあるオブジェクトのレコードを1万件を超えて所有している状態を所有データスキューと呼んでいます（Ownership Data Skew (opens in a new tab)、英語）。たいていは、誰かがすべてを一人のユーザーやキューに置いたときに起きます。未割り当てのリードをすべてプレースホルダーのユーザーに、連携のレコードをすべて連携ユーザーに。そのユーザーがロール階層の中で移動したり、共有ルールが依存するグループに出入りしたりするまでは無害です。そうなるとSalesforceは膨大な数の共有エントリを調整しなければならず、長時間かかる再計算が起きます。

ガイダンスは実践的です。できるところでは、所有をより多くのユーザーに分散させましょう。一人のユーザーが多くを所有しなければならないなら、そのユーザーをロール階層の外に置きましょう。ロールが必要なら、最上位に専用のロールを作ってそこに置き、動かさないこと。そして共有ルールが使う公開グループには入れないことです（Ownership Data Skew (opens in a new tab)、英語）。同じ考え方は、前のモジュールの子が多すぎる親、つまり親子データスキューにも当てはまります。

ですから分布は物理モデルの一部です。レコードが何件かだけでなく、どう分布しているかを問いましょう。これはゼロの数のもう一つの形です。ゼロがいくつあるかだけでなく、ゼロがどこに集中しているかです。第2部でスキューを深く掘り下げます。ここでは、それが来ることに気づいてほしいのです。Sharing and Visibilityのコースでは、大規模な共有で再び取り上げます。

「デフォルトの所有者」はアーキテクチャになる

いつも見かけるパターンがあります。何を誰が所有すべきか誰にもわからないので、誰かが「全部連携ユーザーに割り当てておけばいい」とか「Systemという汎用ユーザーを作ろう」と言います。それが正しいのかもしれません。でも、うっかりそうしないでください。一時的なデフォルトは永続化する癖があります。2年後にはすべてのレコードがintegration@company.comのものになっていて、誰もその理由を覚えておらず、変えるのは一つのプロジェクトになります。第1章の可逆性テストです。100万件のレコードを一人の所有者に渡す前に、後でそれを変えるには何が必要かを問いましょう。

再割り当てはライフサイクルの出来事である

所有者は変わります。営業担当者が辞め、テリトリーが動き、チームが再編され、地域が組み替えられます。何が所有者に依存しているでしょう？　共有、自動化、レポート、キュー、エスカレーション、連携？　所有者を変えると誰がレコードを見られるかが変わるなら、再割り当ては管理上の片付けではありません。セキュリティ上の出来事です。 そして100万件になれば、運用上の出来事でもあります。そのときは共有テーブルを見てください。所有者が変わると手動共有は削除されますが、開発者独自の理由を持つApex共有は変更後も残ります（Understanding Sharing (opens in a new tab)、英語）。クラスでは、レコードを誰かと共有してから所有者を変えると、その人はアクセスを失います。教室はいつも驚きます。

そして、所有はアクセスと同じではないことを忘れないでください。レコードを見る必要があるのは所有者だけではなく、Salesforceにはアクセスを付与する方法がたくさんあります。ロール階層、共有ルール、チーム、テリトリー、手動共有とプログラムによる共有。Sharing and Visibilityのコースでそれらを深く扱います。まずはスティーブの、レコードを共有する22の方法からです。アーキテクトとしてのポイントはもっとシンプルです。すべてのアクセスの問題を所有で解決しようとしないでください。 誰かにレコードを見せるためだけに所有者を動かしているなら、おそらく間違った問題を解いています。

作成は始まりにすぎない

多くのデータモデリングは作成で止まります。項目、オブジェクト、リレーション、完了。しかしレコードは10年生きるかもしれません。更新され、所有者が変わり、ステータスや関係が変わり、無効になり、履歴になり、アーカイブが必要になり、いつか削除されるかもしれません。アーキテクチャはレコードがどう生まれるかだけではありません。誕生から終わりまでに何が起きるかです。

Click to enlarge

古いというだけで削除しない

ある小売パートナーが仕事を送ってこなくなりました。取引先を削除するでしょうか？　自動的にはしません。その配送、クレーム、請求の履歴はまだ重要です。トラックが引退しました。その配送履歴や損傷クレームと一緒に削除するでしょうか？　そのもの自体はもう有効でなくても、そのデータはまだ有効です。ですから私は、無効と消えたを分けます。引退したトラックはモデルに残っていてかまいませんし、元社員は監査履歴に登場し続けられます。アーキテクチャは、業務上の関係が終わった後も重要な事実を保持しなければなりません。

保持はビジネス要件である

反対側の話です。すべてを永遠に保持するのもアーキテクチャではありません。ストレージは増え、レポートは遅くなり、検索は雑音が多くなり、プライバシー法が一部のデータを消すよう求めるかもしれません。ですから私は、**どれくらいの期間これを保持するのか？**に明確な答えがほしいのです。「Salesforceが保持している」は保持ポリシーではありません。

そしてこれは、ほとんどの場合トランザクションデータについての問いです。参照データ、つまり商品、サービスの種類、物流センターは巨大にはならず、ほかのレコードがそれを指しているので、たいてい残ります。顧客データはその中間です。顧客を終わらせる日が来るかもしれません。特に個人データを保持していて、それを保持する理由がなくなったときです。しかしボリュームはトランザクションにあります。配送、注文、ケース、予定が、毎日、永遠に作られます。それが何億行にも育つもので、そこでこそ保持を明示しなければなりません。組織には業務データを2年、財務記録はどこかに7年、一部の写真は90日、かもしれません。それらはビジネスルールであり、誰も尋ねていないならアーキテクトが尋ねるべきです。

クラスで何年も言ってきました。今日アーカイブしていないなら、いつかアーカイブすることがあるのか？　「後で対処しよう」は、3億件のレコードになったときの緊急プロジェクトに化けがちです。第2部には、同じ問いの上に作られた、アーカイブとパージについてのモジュールが丸ごと一つあります。

Steve Trucking：配送は誰が所有するのか？

配送は、小売パートナーの積荷目録から連携によって、1日に約3,300件作られます。誰が所有するのでしょう？　小売パートナーではありません。それはビジネス上の関係です。受取人でもありません。クルーがそれを実行しますが、クルーがトラックを交換するたびにレコードの所有者を変えるべきでしょうか？　配車担当者？　物流センター？　キュー？　それを作った連携ユーザー？

では、このモジュールを当てはめましょう。それを決める問いから始めます。所有は誰かの配送へのアクセスを決めているか？　Steve Truckingでは決めていません。配車担当者は自分の物流センターの配送を見て、クルーは自分のルートの配送を見て、各小売業者はパートナーポータルで自分の配送を見ます。そのどれもレコードの所有者には依存しません。物流センター、ルート、パートナーから来ています。

ですから私の答えは、連携ユーザーが配送を所有するです。システムユーザーが意図的にレコードを所有するよい例です。

• 監査証跡が正直です。 どの配送の所有者も、それがどこから来たかを示しています。積荷目録の連携です。
• アクセスは所有ではなく共有から来ます。 物流センターに基づく条件ベースの共有ルールが、各物流センターのチームに自分の配送を与えます。パートナーはポータルを通じて自分の配送にたどり着きます。
• スキューは設計で封じ込めます。 1日3,300件なら、連携ユーザーは3日で1万件の配送を超えるので、初日から所有のスキューです。計画しておけば、それでかまいません。連携ユーザーはロールを持たないので、階層の上で再計算が必要なものは何もなく、共有ルールが使う公開グループにも入りません。
• 誰も配送を再割り当てしません。 クルーがトラックを替え、配車担当者がシフトを替えても、所有者は決して動きません。ですから再割り当ての嵐も、失われる手動共有もありません。

そして、そのユーザーが無効化されたり置き換えられたりしたら何が起きるかを書き留めておきましょう。今やそれは何百万件ものレコードを所有しているからです。それが、次のチームが見つける必要のある判断です。

試験の先へ：AIが変えること。 エージェントは機械の速さでレコードを作り、変更します。エージェントが自分のユーザーで10万件のレコードを作れば、「所有者は後で直そう」はスキューに、共有の再計算に、そして片付けのプロジェクトになります。同じ問いを使って、本番稼働の前にエージェントの所有のルールを決めましょう。ここでは所有は共有にとって重要か？

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

• 所有がビジネス上の責任を表すのか、セキュリティの仕組みなのか、その両方なのか。そして所有者項目でないなら、責任をどこに置くのか。
• レコードが独自の所有者を必要とするのか、親から引き継ぐべきなのか。
• 連携とエージェントが作るレコードを誰が所有するか。所有が共有を決めているかどうかに応じて。
• 所有がどう分布しているか、そして一人のユーザーが多くを所有しなければならないとき、所有データスキューをどう避けるか。
• レコードがいつ無効になり、いつアーカイブされ、どれくらい保持され、いつ削除が正しいのか。

物理モデルを見るときは、データがどこに保存されているかだけを問わないでください。今日誰が所有しているか、明日誰が所有するかもしれないか、そしてもう必要なくなったら何が起きるかを問いましょう。次は、正しいオブジェクト、項目、リレーション、所有者があっても、データは信頼できる状態を保たなければならない、という話です。

さらに学ぶ

• Apex開発者ガイド、Understanding Sharing (opens in a new tab)（英語）、2026-10-13確認：所有者（ユーザー、またはカスタムオブジェクト、ケース、リードではキュー）はフルアクセスを得る。ほとんどの共有は関連する共有オブジェクトにある。ロール階層は実行時に導出される。手動共有は所有者が変わると削除され、Apex管理共有は保持される。行の理由の値。
• Apex開発者ガイド、Sharing a Record Using Apex (opens in a new tab)（英語）、2026-10-13確認：AccountShare、MyCustomObject__Share。詳細オブジェクトには共有オブジェクトがない。共有オブジェクトが追跡しないもの（組織の共有設定、ロール階層、すべて表示とすべて変更）。
• Salesforceヘルプ、Implicit Sharing (opens in a new tab)（英語）、2026-10-13確認：取引先と、その取引先責任者、ケース、商談の間のアクセス。
• Salesforceヘルプ、About High-Volume Community or Site Users (opens in a new tab)とSharing Rule Considerations (opens in a new tab)（英語）、2026-10-13確認：ロールなし、共有ルールや手動共有なし。代わりに共有セット。
• Sharing and Visibility Architectコース：スティーブの、レコードを共有する22の方法、組織の共有設定、所有、キュー、ロール階層、リレーションと組み込みの共有、プログラムによる共有と安全なコード、外部ユーザーとの共有、大規模な共有。
• Salesforce Developers、Designing Record Access for Enterprise Scale、Ownership Data Skew (opens in a new tab)とParent-Child Data Skew (opens in a new tab)（英語）、2026-10-02確認。