量が共有モデルとぶつかるとき

🌐 ほかに 19 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む このセクションは英語版が更新されたため、まだ再翻訳されていません。 (35)

モジュール3／4：Data Architectコース第7章「大規模に向けた設計」。各モジュールは単独でも読めます。 前へ：ホットスポット：所有、親、参照のスキュー · 次へ：今日アーカイブしていないなら…

このモジュールが答える問い： 共有を尊重するモデルを、量が多くても速く保つにはどうするか？

前のモジュールではホットスポットを見つけました。ここでセキュリティを加えます。妥当に見えるデータアーキテクチャが高くつくのは、ここです。900万件の作業指示は量の問題です。900万件の作業指示のそれぞれが、ちょうど正しい社内ユーザーと、ちょうど正しい小売パートナーにだけ見える状態は、量の多い共有の問題です。レコードはただ保存されるだけではありません。Salesforceは**誰がそれを見られるのか？**にも答えなければなりません。大規模では、その答えはデータアーキテクチャの一部です。

共有もデータである

アーキテクトが量を数えるとき、数えるのはビジネスのレコードです。でもSalesforceは、アクセスを支えるものも維持しています。所有者、ロール、グループ、共有ルール、明示的な共有、メンバーシップです。規模が小さければ、その仕事が存在することを忘れていられます。規模が大きければ、そうはいきません。だから私は「共有はあとでセキュリティチームが何とかする」とは決して言いません。私が選ぶリレーション、所有者、親、外部ユーザーのモデル、そのどれもが共有に影響します。データアーキテクトと共有のアーキテクトは別の人かもしれませんが、二人のアーキテクチャはつながっています。

The Share Table Has Its Own Number of Zeros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing （新しいタブで開きます）; Sharing a Record Using Apex （新しいタブで開きます）). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros. ⟲

Salesforce describes three kinds of tables behind record access. The object record tables hold the records and who owns each one. The object sharing tables, the __Share objects, “store each access grant in separate rows called sharing rows, each of which grants a user or group access to a particular record.” And the group maintenance tables store who belongs to each group, and the access people inherit through roles and groups (Record-Level Access: Under the Hood （新しいタブで開きます）, Winter ‘27, archived copy （新しいタブで開きます）). When we talked about recalculation, this is where the work happens: rows being added and removed in those tables. ⟲

So do the math for the share table the way we did it for the records. Say each of Steve Trucking’s 9 million work orders is shared by three sharing rules: to its Retail Partner’s users, to its distribution center’s managers, and to an operations region. Work Order’s share object is WorkOrderShare, “a sharing entry on a work order” (WorkOrderShare （新しいタブで開きます）). That’s three of those rows per work order, about 27 million sharing rows behind 9 million records, before the owner’s own rows. Share the same records with individual users instead of groups, and the rows multiply by the number of people. The share table can be far bigger than the object it protects. ⟲

クリックで拡大

Step 1 of 3: the records. Nine million work orders. ⟲

クリックで拡大

Step 2 of 3: the share table, three rules to groups. ⟲

クリックで拡大

Step 3 of 3: the same access, shared person by person. Count the share table, not just the records. ⟲

That’s why the levers that keep sharing fast are mostly levers on the number of rows: ⟲

• Share with groups, not people. Salesforce’s own advice: grant access to the group instead of to the individuals, which “results in fewer sharing rows, thus reducing your organization’s record access data volume” (same source). ⟲
• A detail object has no share object at all. Its access comes from its master, so a master-detail child adds no sharing rows (chapter 3, and module 2’s Master-Detail at Volume for what that costs). ⟲
• High-volume community users don’t use sharing rows. They reach records through sharing sets instead, one of the reasons those licenses scale (chapter 3). ⟲
• Use a public default where the data isn’t confidential. A Public Read Only or Read/Write default needs no sharing rows to grant what everyone may already read (see Don’t Optimize Away Security, below). ⟲

Test knowledge. Know the share object (AccountShare, Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. ⟲

アクセスの要件から始める

I don’t start with which sharing feature to use. I start with who needs access to what? For Steve Trucking, one requirement is clear: each Retail Partner sees its own deliveries, never another’s. Simple to say. At scale I immediately want to know how many partner users there are, how many deliveries, how a delivery relates to its partner, who owns the delivery, and what happens when a user changes roles, a partner user is added or removed, or a partner relationship changes, and how often any of that happens. The access requirement comes first; then a model that supports it at the zeros we expect. ⟲

Ownership Drives Access

That’s why “who should own the delivery?” can’t be answered in isolation. If one integration user owns every work order, ingestion is easy, but if the business expected ownership to drive access, we’ve given up that way of controlling access. And if ownership doesn’t drive access, forcing millions of records through complicated ownership assignments adds complexity for nothing. So my rule for machine-created records applies here too: does ownership matter for sharing? If it does, ownership should reflect the access model. If it doesn’t, we have more freedom. One decision, made by the data architect and the sharing architect together. ⟲

ロール階層は組織図ではない

チームはロール階層を組織図の写しとして設計しがちです。やがて会社が再編され、誰かがロールを動かし、Salesforceはアクセスへの影響を計算し直さなければなりません。規模が小さければ誰も気づきません。何百万件ものレコードがあれば、再編は大きなデータ操作です。だから大量のレコードを所有するユーザーについての推奨は、ロールを与えないか、階層の最上位にある別の安定したロールに置くことなのです（Ownership Data Skew （新しいタブで開きます））。この原則は一般化できます。**大規模では、安定性は設計上の特徴です。**共有の構造にぶら下がるレコードが多いほど、それを変えるときは慎重になります。

グループも同じです。公開グループは共有ルールに使われ、ユーザーはグループに属し、グループはグループを含みます。便利な道具ですが、膨大な数のユーザーとレコードが、常に変わるグループのメンバーシップに依存しているなら、再計算を理解しておく必要があります。だから大量のレコードを所有するユーザーは、共有ルールの元として使う公開グループの外に置くのです（同じ資料）。教訓は「公開グループは悪い」ではありません。最大のレコードの集中を、最も変わりやすいアクセスの構造に、よく考えずに結びつけてはいけないということです。

共有の再計算は本物の仕事である

Steve Truckingが業務モデルを変えます。何百人ものユーザーが異動し、所有が変わり、ロールとグループが変わり、大きな共有ルールが変わります。設定作業のように聞こえます。でも、プラットフォームは大量のレコードにわたってアクセスを計算し直さなければならないかもしれないので、私はそれをデータ操作として扱います。ユーザーは何人、レコードは何件、所有とメンバーシップの変更はいくつ？　再計算はどれだけ？　実際の量でテストできるか？　いつ実行すべきか、その間ユーザーには何が見えるか？　大きなセキュリティの再編成には、大きなデータ移行と同じ規律がふさわしいのです。

And don’t recalculate everything after every change. Making one change, waiting for everything to recalculate, then the next, then the next, rebuilds access over and over while the design is still moving. Salesforce’s answer for large realignments is deferred sharing calculations: prepare all the role, group and sharing-rule changes, apply them in a negotiated maintenance window, and let the recalculation run once (Deferred Sharing Maintenance （新しいタブで開きます）). Change, change, change, recalculate once. Two more of Salesforce’s suggestions keep the work down: process role hierarchy changes from the bottom (leaf) nodes up, “to avoid duplicate processing,” and remove redundant paths of access, “such as sharing rules that provide access to people who already have it through the hierarchy” (Designing Record Access for Enterprise Scale （新しいタブで開きます）, Winter ‘27). ⟲

Test knowledge. Know the tools for large access changes: deferred sharing calculations (prepare every change, apply them in an agreed maintenance window modeled in a full copy sandbox, recalculate once) and granular locking, on by default, which lets unrelated role and group operations run at the same time. ⟲

クリックで拡大

At scale, access realignment is a data operation. ⟲

「延期」は「気軽に」という意味ではありません。共有を延期するほど大きな変更なら、私は計画を求めます。現実的な量でのテスト、ビジネスが合意したメンテナンス時間帯、検証、終わらなかったときの代替策、そしてその間ユーザーがどんな体験をするかの理解です。Salesforceの推奨は、まずフルコピーサンドボックスでモデル化することです（同じ資料）。5,000件のテストレコードで見事に動くセキュリティモデルは、5,000万件については何も証明しないからです。本当に設計の対象にしているゼロの数でテストしましょう。

きめ細かなロックは役立つが、特効薬ではない

Role and group updates lock the group-membership tables while they run, which used to make unrelated sharing operations collide. Granular locking, now on by default, lets unrelated group operations run at the same time (Group Membership Locking （新しいタブで開きます）); retry logic, serial processing, and scheduling separate group maintenance jobs so they don’t overlap help with what’s left. The idea is worth remembering: don’t lock more of the access structure than the operation needs. But don’t conclude “locking is solved.” Granular locking reduces some contention. It doesn’t rescue a poor ownership model, a volatile hierarchy, or an access design that constantly forces massive recalculation. Platform features help; architecture still matters. ⟲

Steve Trucking：大規模でのパートナーの分離

チェックポイント1では、パートナーの分離が要件なので、すべての作業指示が小売パートナーを恒久的に持つことにしました。規模の数字は、それをより重要にこそすれ、軽くはしません。Redrockが事業の40%なら、5年で約360万件のRedrockの作業指示になります。リレーションは正しく、Redrockは本当に一つのパートナーです。だからアクセスの設計は、モデルを歪めるのではなく、本物のビジネス上の関係（パートナーのユーザーは自社の作業指示を見て、物流センターのマネージャーは自分のセンターのものだけを見る）に従わなければなりません。前のモジュールの、物流センターごとの子取引先という構造は、ここで二重に役立ちます。子を分散させ、物流センター単位のアクセスに本物のよりどころを与えるのです。

And keep authorization separate from identity. At the checkpoint we decided not to unify Recipients across partners, precisely because a shared identity is exactly the kind of link that can expose one partner’s data to another. Even where identity resolution is used inside one partner, it answers who might this person be? Sharing answers who may see this record? Blur them, and at this scale the mistake isn’t wrong once. It’s wrong millions of times. ⟲

社内のアクセスはまた別の話

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them. ⟲

セキュリティがモデルを変えるべき場合もあります。2種類の情報が、所有者、ライフサイクル、利用者、共有の必要性でまったく異なるなら、一つのレコードに項目レベルの制御を積み重ねることもできますし、データを分けて独自の境界を持つ独自のオブジェクトにすることもできます。項目レベルのセキュリティの設定を避けるためだけに分けることはしませんが、セキュリティは物理モデルを変える正当な理由です。

共有にも独自のゼロの数がある

それぞれ1,000万件のレコードを持つ2つの設計。一方は単純な所有、安定した階層、少ない共有ルール、メンバーシップの変動もわずか。もう一方は非常に分散した所有、頻繁に変わるロール、大きな入れ子のグループ、多くの共有ルール、絶え間ない再編。レコード数は同じでも、規模の問題はまったく違います。だから大量の各オブジェクトについて、アクセスモデルの数字も知りたいのです。所有者は何人で、どれだけ集中しているか、既定のアクセス、どの階層の関係、ルール、グループが重要か、外部ユーザーは何人か、そして誰かがロールを変えたとき、パートナーが追加されたとき、地域が再編されたときに何が起きるか。そして一つの問い。**この設計が引き起こし得る最大の再計算は何か？**それが、私がテストしたいシナリオです。

クリックで拡大

Count the access model, not just the records. ⟲

最適化のためにセキュリティを捨てない

There’s a dangerous conclusion to avoid: sharing is expensive, so make everything public. No. Performance isn’t an excuse to abandon a security requirement. Salesforce’s own guidance draws the line in the right place: “Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data” (same guide). Non-confidential data can be public; confidential data stays protected, and the design has to carry it. The job is an architecture that satisfies both: simpler ownership, more stable hierarchies, better group design, splitting data with different security needs, different relationships, planned realignments. “Private is slower, so make it public” is not an architecture strategy. ⟲

試験の先へ：AIが変えること。 エージェントはどんな人よりも速く取得し集約するので、広すぎるアクセスモデルはより危険になります。「BrightwaveのデータをRedrockに見せるな」と言うプロンプトに頼ってはいけません。境界はアーキテクチャに置くべきです。エージェントが何を明かすかを指示で決めるのではなく、エージェントが何に届くかを認可で制限するのです。認可モデルをデータモデルと一緒に拡張しましょう。

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

• 大量の各オブジェクトについて、どのリレーション、所有者、ロール、グループ、共有ルールがアクセスを決めるか。
• 大量のレコードを所有するユーザーやその他のホットスポットが、変わりやすい階層やグループの構造から切り離されているかどうか。
• 大きなアクセスの再編成を、本番の量でどうテストし、計画し、一度で再計算し、検証するか。
• 異なるセキュリティの必要性が、一つのレコードへのアクセスを複雑にするのではなく、データを分けることを正当化するかどうか。
• パートナー、従業員、アプリケーション、エージェントのアクセスを、IDの近道ではなくビジネス上の関係にどう結びつけておくか。

1,000件のレコードのための安全な設計を描くのは簡単ですし、全員が全部を見られる速い設計を描くのも簡単です。アーキテクトの仕事は、その両方が生き残るシステムです。正しい人が正しいデータを見て、ゼロを足しても動き続けるシステム。大規模では、共有はデータアーキテクチャの一部です。

さらに学ぶ

• Object Reference for the Salesforce Platform, WorkOrderShare （新しいタブで開きます） (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance （新しいタブで開きます） (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew （新しいタブで開きます）, Group Membership Locking （新しいタブで開きます） and Deferred Sharing Maintenance （新しいタブで開きます）, checked 2026-11-01. ⟲
• さらに深く：Sharing and Visibility Architectコース、大規模な共有 (coming soon)。
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲
• Salesforce, Record-Level Access: Under the Hood （新しいタブで開きます） (Winter ‘27, archived copy （新しいタブで開きます）), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing （新しいタブで開きます） and Sharing a Record Using Apex （新しいタブで開きます）, checked 2026-11-01. ⟲