量がすべてを変えるとき
ほかに 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)
モジュール1／4：Data Architectコース第7章「大規模に向けた設計」、第2部の始まりです。各モジュールは単独でも読めます。 次へ：ホットスポット：所有、親、参照のスキュー
このモジュールが答える問い： データが増えると何が壊れ、それはいつなのか？
A design can be perfectly reasonable at 70,000 records and completely wrong at 70 million. That’s one of the things that makes data architecture difficult. The object is the same. The fields are the same. The relationships are the same. The business requirement may even be the same. But add a few zeros and the architecture changes. ⟲
ここで私たちは見るから設計するへ移ります。第1部では、ビジネス、データモデル、企業のシステム全体像、ガバナンス、権威を見ることを学びました。これからそのアーキテクチャに重みをかけていきます。そして私が最初に尋ねるのは、**これはどこまで大きくなるのか？**です。
Built for Transactions
Section titled “Built for Transactions”Salesforce runs some of the largest CRM implementations in the world, and its core database handles “upwards of 1.1 trillion transactions per month.” Salesforce’s own architects describe that database as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow （新しいタブで開きます）). It’s built for that: transactional work on structured data. And every record comes with a lot of built-in capabilities and functionality that are part of the core Salesforce platform: the object model, sharing and security, pages, reports, automation, search. All of it runs on a multitenant database, where Salesforce writes the SQL, not you. ⟲
I once taught this class at Dreamforce to a room with a lot of database administrators from Oracle and SQL Server, and of course they were asking, “Why doesn’t Salesforce act this way? Why doesn’t Salesforce do this?” By the end they were smiling, because they’d understood why. Chapter 3 described Salesforce as a multitenant, metadata-driven platform: the apartment building. We’re not tuning our own dedicated database. Salesforce’s storage, indexing, sharing, locking, query optimization and resource protections are designed for many tenants at once. That’s not bad; it’s why we get so much capability without running database infrastructure. But it means the architect needs to understand the platform’s shape. ⟲
Salesforce says it plainly in its own guide: as data sets get larger, “the time required for certain operations grows,” and the architect’s choices change that time “by several orders of magnitude” (Best Practices for Deployments with Large Data Volumes （新しいタブで開きます）). That’s not a weakness. It’s the design. At small volumes you can sometimes ignore the platform’s shape. At large volumes, it reminds you it’s there, and we’ll see that very clearly with selectivity and indexes in the next chapter. That’s why the architect has to know how big this gets. ⟲
The same guide ends with the other half of the story. Salesforce is “a robust environment in which native and custom applications can scale to large volumes of data very quickly while continuing to perform well,” and it names the two ways you get there: make queries selective, and reduce the amount of active data. Millions of records can perform well on Salesforce. They perform well because somebody designed for them. That’s what this part of the course is about. ⟲
私の大量データのものさし
Section titled “私の大量データのものさし ”When I’m teaching large data volumes, I use a rough ruler. It’s not a Salesforce limit. The numbers are general figures discussed in the community, and Salesforce itself calls a large data volume “an imprecise, elastic term”: tens of thousands of users, tens of millions of records, or hundreds of gigabytes of storage (Best Practices for Deployments with Large Data Volumes （新しいタブで開きます）). And when I say records, I mean records in a single object, not across all your objects. ⟲
Like every number in this course, the ruler has a date on it. More on that in a moment. ⟲
At about 1 million records in an object, there’s just a little bit of drag as dashboards and reports show up. Not a lot, depending on how you filter. Around 10 million, there’s some effect, but it’s still performing. Heading toward 50 million, you start to notice it: list views taking two, three, four seconds, reports and dashboards taking time. Past 50 million, I like to say you’re driving a convertible with your head out the window, and your hair is blown back. Don’t stick your head out the window: past 50 million you’ve got to be streamlined, and you’ve got to know what you’re doing. And once we’re talking about 100 million records or more, I start asking a different question: should these records be here at all? I’ve heard of people running a hundred million or more in an object. But if you’re at 50 million today, you’re going to 100, 150, 200 million in the years ahead. If you’re not archiving today, when will you? If somebody tells me they have 150 million records in an object and almost nobody ever looks at the old ones, that’s not an operational object any more. That’s an audit log. ⟲
このものさしが100万件から始まるのは偶然ではありません。次の章で見るように、プラットフォーム自体のクエリの計算が「最初の100万件」で変わります。とはいえ、正確な数字が教訓なのではありません。教訓は、量が設計を変えるということです。
Every zero changes what you notice. A rule of thumb, not a limit. ⟲
The Platform Keeps Growing
Section titled “The Platform Keeps Growing”Salesforce ships three releases a year. Over time the platform grows, some limits are raised, and systems get faster. So I don’t want you to treat any number in this course as if it were permanent, including mine. Salesforce keeps every release’s edition of its guides online, which means we can do something useful: put ten years side by side. Here’s Winter ‘16, from late 2015, next to Winter ‘27, from 2026. ⟲
| Winter ‘16 (2015) | Winter ‘27 (2026) | |
|---|---|---|
| Big objects | Didn’t exist yet | “Consistent performance, whether you have 1 million records, 100 million, or even 1 billion” |
| Skinny table columns | 100 | 200 |
| Index selectivity thresholds | Capped at 1 million records (standard) and 333,333 (custom) | No published cap, and the optimizer can add an index on its own |
| Minimum data storage | 1 GB per org, or 20 MB per user | 10 GB per org, plus storage per user |
| Bulk API batches a day | 5,000 | 15,000 |
| Parent-to-child levels in one SOQL query | 1 | 5 |
| Apex heap per transaction | 6 MB (12 MB asynchronous) | 10 MB (25 MB asynchronous) |
That’s the upward direction: limits raised, caps removed, new kinds of storage, and an optimizer that now “recognizes that an index can improve performance for frequently run queries” and adds one (Working with Very Large SOQL Queries （新しいタブで開きます）). ⟲
Now look at what didn’t move in those ten years. The definition of a large data volume is word for word the same: “tens of thousands of users, tens of millions of records, or hundreds of gigabytes.” The advice to avoid having any user own more than 10,000 records is the same. And an Apex transaction still gets 100 SOQL queries, 50,000 records and 10 seconds of CPU (Execution Governors and Limits （新しいタブで開きます）). Those are the house rules of the apartment building, the guardrails that keep one tenant from hurting the others, and they’ve barely moved. ⟲
Salesforce is open about the pace, too. It ships three releases a year, each with a new API version, and it commits to “supporting each API version for a minimum of 3 years from the date of first release,” with at least a year’s notice before support for a version ends (SOAP API End-of-Life Policy （新しいタブで開きます）). In practice versions live much longer: as I write this, version 41.0, from Winter ‘18, is still supported. If you’re new, you don’t need the history. But it does change decisions. The org you inherit was designed under older limits, and some of its workarounds may not be needed any more. The integration you build today is pinned to an API version with a clock on it. And study material written a few releases ago may still teach yesterday’s numbers. ⟲
So when you read a number in this course, read the date next to it. The specific limits will keep changing, mostly upward, and Salesforce will keep pivoting. The thinking won’t: know your Number of Zeros, keep the active data small, make your queries selective, and check the current edition of the guide before you commit to a number. That’s why I teach the ruler as a ruler, not a law. For now, it’s a good place to start. ⟲
The sources, both editions: Best Practices for Deployments with Large Data Volumes, Winter ‘16 （新しいタブで開きます） (archived copy （新しいタブで開きます）) and Winter ‘27 （新しいタブで開きます） (archived copy （新しいタブで開きます）); Salesforce Limits Quick Reference Guide, Winter ‘16 （新しいタブで開きます） (archived copy （新しいタブで開きます）), and Salesforce Developer Limits and Allocations Quick Reference, Winter ‘27 （新しいタブで開きます） (archived copy （新しいタブで開きます）); Data and File Storage Allocations （新しいタブで開きます） (10 GB “starting in late March 2019”); Execution Governors and Limits （新しいタブで開きます）, Winter ‘27. ⟲
今日の大きさを尋ねない
Section titled “今日の大きさを尋ねない ”One of the easiest mistakes is sizing an architecture from today’s data. Steve Trucking has about 1 million deliveries a year. If I only ask “can Salesforce handle one million deliveries?”, I’m asking the wrong question. Steve Trucking expects about 30% annual growth: 1.0 million in year one, 1.3 in year two, 1.69 in year three, about 2.2 in year four, about 2.86 in year five. That’s annual volume. If we keep all five years, we’re not designing for 2.86 million deliveries; we’re designing for roughly 9.04 million. And that’s before we ask how much history already exists. ⟲
だから私はスティーブのゼロの数を教えます。早い段階で見せかけの精度にこだわらないこと。桁を正しくつかむことです。1万、10万、100万、1,000万、1億？ ゼロを一つ足すたびに、アーキテクチャは変わり得ます。
次に子を掛け合わせる
Section titled “次に子を掛け合わせる ”The delivery isn’t the only record. Steve Trucking averages about 1.6 line items a delivery, so over five years that’s about 14.5 million work order line items. And there are around eight status changes a delivery: about 72.3 million status events. The requirement sounded like “track deliveries.” The architecture has to deal with tens of millions of related records. One million parents with eight children each is not a one-million-record problem. You have to follow the model. ⟲
そして、コアに置かなかったデータ
Section titled “そして、コアに置かなかったデータ ”Checkpoint 1 also gave us four to five million photos a year, and FleetLink produces about 200,000 GPS readings a day: roughly 73 million a year before growth. That’s why we decided not to put every GPS reading, every photo or every status change into the Salesforce operational model. We hadn’t even started this chapter, and the Number of Zeros was already telling us something. It’s like telling the doctor, “It hurts when I raise my arm,” and the doctor says, “Then don’t raise your arm.” Sometimes the best way to solve a large-data-volume problem is don’t create it in the first place. ⟲
遅くなるのはクエリだけではない
Section titled “遅くなるのはクエリだけではない ”When people hear large data volumes, they think “queries get slow.” Yes, and the next chapter is all about query and retrieval. But it’s bigger than that. As volume grows, I care about sharing calculations, ownership, record locking, parent-child relationships, list views, related lists, reports, search results, batch processing, integrations, data loads, deletes, archiving, backups and recovery. Even a harmless-looking decision gets expensive when it’s repeated millions of times. ⟲
That’s the lesson: what works today may fail tomorrow. Maybe nobody notices at 50,000 records, or at 500,000. Then growth pushes the object through several million, and an old design assumption becomes the bottleneck. The system didn’t randomly go bad. The architecture crossed the scale where that decision mattered. ⟲
きれいなモデルが高くつくモデルになることがある
Section titled “きれいなモデルが高くつくモデルになることがある ”My starting position is still: design clean first, then back off when necessary. Understand the entities and relationships; don’t duplicate data because it’s convenient. But normalization is a principle, not a rule. If a report or operational query constantly has to walk several relationships across tens of millions of records to get one value, at some scale I may copy that value closer to where it’s used. That’s denormalization. ⟲
たとえば、作業指示品目についてのパートナー別のレポートが、きれいなモデルでは2段階先にある小売パートナー（Retail Partner）を常に必要とするとします。明細 → 作業指示 → パートナーです。十分な規模になれば、パートナーの識別子の管理されたコピーを明細に直接置く理由があるかもしれません。これで重複データを作ったことになり、そこに責任が生まれます。どう値を入れるのか？ 変わり得るのか？ どう正しく保つのか？ どちらのコピーが権威を持つのか？ これらは本物のコストで、ビジネスに必要な性能を得るために、管理された重複を受け入れることもあります。**正規化に向けて設計し、規模が理由を与えたときに意図して後退する。**作りやすいから非正規化するのではありません。得られる効果と受け入れるコストを説明できるから非正規化するのです。
コアのCRMをウェアハウスにしない
Section titled “コアのCRMをウェアハウスにしない ”私が目にする規模の間違いは、もう一つあります。ビジネスがレポートを求めるので、業務用のCRMに履歴データを足し続け、さらに足し、やがて理由が「レポートに必要だから」になる。そのとき私は、業務用のシステムを分析用のシステムに変えてしまっていないかを問います。両者は別のワークロードです。Steve TruckingがSalesforceに求めるのは、今日の配送を回すことです。エージェントには今日の状況、配車担当には今日のルート、パートナーには今日の進捗が必要です。地域、パートナー、トラック、天候、クルー、配送時間帯ごとに5年分の配送実績を比べ、財務と結合するアナリストは、分析のワークロードです。Salesforceは業務データについてレポートできます。だからといって、履歴に関するあらゆる分析の問いが業務用のストアに属するわけではありません。Steve Truckingにはすでに Snowflake があります。だから問いましょう。**業務用のシステムが答えなければならない問いはどれで、分析プラットフォームに属する問いはどれか？**ウェアハウスは第3部でしっかり扱います。
そして、レポート用のスナップショットはウェアハウスの戦略ではありません。平坦化したレポート用オブジェクト、スナップショットのレコード、レポートを楽にするための値のコピー。正当な場合もあります。でも、アーキテクチャの問いを先送りする方法にもなり得ます。すでにある数百万件についてレポートするために、さらに数百万件のレコードを作っているなら、それがどこで終わるのかを知りたくなります。ウェアハウスの話を誰もしたがらないからといって、業務用のレコードを作り続けてはいけません。
量には形がある
Section titled “量には形がある ”2つのシステムがそれぞれ2,000万件のレコードを持っていても、振る舞いはまったく違うことがあります。一方は2,000万件の履歴レコードで、ほとんど更新されず、たいてい既知の識別子で1件ずつ取得され、共有も複雑ではありません。もう一方は2,000万件の現役のレコードで、常に更新され、所有が複雑で、レポートが多く、ユーザーも多く、親子の大きな集中があり、統合も頻繁です。同じ問題ではありません。だからレコード数だけでは足りないのです。どれだけ速く増えるのか？ どれだけ頻繁に変わるのか？ どう照会され、共有され、関連づけられるのか？ どれだけの期間、現役でいなければならないのか？ 一度にどれだけ届き、あるいは変わるのか？ 削除したら何が起きるのか？ 「Salesforceは2,000万件を扱える」は答えではありません。面白い問いは、**その2,000万件は何をしているのか？**です。
AIがさらにゼロを足す
Section titled “AIがさらにゼロを足す ”Agents can create data very quickly: interactions, tasks, summaries, recommendations, logs, intermediate results, events, audit information. Maybe that’s useful. But AI doesn’t make storage free, or sharing calculations, or indexing, and it certainly doesn’t make useless history valuable. If an agent creates ten records where a human process used to create one, our volume assumptions may be wrong before the business itself grows. I’m not yet seeing agents generate more records in the orgs I work with, but it’s the natural progression of more and more data being tracked. ⟲
試験の先へ：AIが変えること。 AIは、システムがデータを作成し取得する速さを劇的に高めることがあります。過去の人間の取引の速さが将来の規模を予測すると仮定するのではなく、エージェントが生み出す量を明示的にモデル化しましょう。
Steve Trucking：アーキテクチャはすでに変わりつつある
Section titled “Steve Trucking：アーキテクチャはすでに変わりつつある ”At the end of Part 1 we made several decisions that are now reinforcing each other. The work order is central. The current status lives in the org, and the history of every status change is published to the warehouse, Snowflake. Photos live outside the core. Raw GPS stays with FleetLink. At five years of 30% growth, we’re approaching 9 million work orders, 14.5 million line items and 72.3 million status events, and hundreds of millions of GPS readings if we’d copied them all. ⟲
Was keeping raw GPS out of the operational model just an integration decision? No; it was a scale decision too. Was putting photos off-core just a storage decision? No; scale again. And the status history? It has real business value, so we keep it. But at 72.3 million events, keeping it outside the operational database is the difference between an org that carries its history and an org that’s buried by it. The question that remains for what we do keep in core: how long should those records stay active? That’s module 4. ⟲
Follow the model, and the zeros multiply. ⟲
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 今日の量がうまくいくかどうかだけでなく、ゼロの数が今日、想定される成長、そして保持期間全体でどうなるか。
- どのきれいな構造を正規化したまま保ち、どこで規模が管理された非正規化を正当化するか。
- どのデータをSalesforceの業務用のコアに残し、どれを専用のストレージ、分析プラットフォーム、他のシステムに置くか。
- レポートの要件が本当に業務用のものか、それともビジネスが分析のアーキテクチャを必要としているしるしなのか。
- エージェントのような新しい生産者が、そのレコードが明日の問題になる前に、量の前提をどう変えるか。
Large data volume architecture isn’t about being afraid of big numbers. Salesforce runs very large implementations. One million records isn’t automatically a problem; neither is ten million or a hundred million. But every zero should make me ask another question: how will we find them, who owns them, how are they shared, what are they related to, how often do they change, how long do we need them, and where should they live? In Part 1 we learned to recognize the right entities and relationships. Now we make sure those bones can carry the weight, because what works today may fail tomorrow. ⟲
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Help, Data and File Storage Allocations （新しいタブで開きます）: 10 GB of data storage since late March 2019, checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes, Winter ‘27 edition （新しいタブで開きます） (release 264, archived copy （新しいタブで開きます）), checked 2026-10-20. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes （新しいタブで開きます）, Winter ‘27, checked 2026-11-01. ⟲
- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow （新しいタブで開きます）, checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes, Winter ‘16 edition （新しいタブで開きます） (archived copy （新しいタブで開きます）) (release 198), checked 2026-10-20. ⟲
- Salesforce, Developer Limits and Allocations Quick Reference, Winter ‘16 edition （新しいタブで開きます） (archived copy （新しいタブで開きます）) and Winter ‘27 edition （新しいタブで開きます） (archived copy （新しいタブで開きます）), checked 2026-10-20. ⟲
- Salesforce Developers, SOAP API End-of-Life Policy （新しいタブで開きます）, checked 2026-11-01. ⟲
- Salesforce Developers, Execution Governors and Limits （新しいタブで開きます）, Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
- Salesforce Developers, Working with Very Large SOQL Queries （新しいタブで開きます）, Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
- SteveTechArc, Salesforce Documents by Release: the guides cited here, once a year from Winter ‘16 to today, each with an archived copy. ⟲
- Steve Truckingの概要資料、セクション4（ボリューム）（英語）。