大量のロード

🌐 ほかに 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で翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む このセクションは英語版が更新されたため、まだ再翻訳されていません。 (52)

モジュール2／5：Data Architectコース第10章「移行と同期」。各モジュールは単独でも読めます。 前へ：移行は何よりもまず品質のプロジェクト · 次へ：ロード中の自動化

このモジュールが答える問い： ゼロの数は、Salesforceへのデータのロードのしかたをどう変えるか？

10件のレコード？　ほとんど手で打ち込めます。1,000件？　ツールが要ります。100万件？　それはアーキテクチャの問題です。操作は変わっていません（レコードを作成または更新する）が、ゼロの数がそのやり方を変えます。モデル化、クエリ、共有、統合で見てきたとおりで、移行も同じです。大量になると私が気にするのは、データをどう動かすか、どう仕事に分けるか、どの順序で動かすか、ロードしている間にSalesforceがほかに何をしているか、何かが失敗したときどう復旧するか、そして全体をもう一度実行できるかです。

Start With the Picture

Same landscape, same amber arrow as module 1: RouteDesk’s open work coming into Salesforce the weekend RouteDesk retires. ⟲

クリックで拡大

Module 1 decided what moves on this arrow. This module is about how it moves. ⟲

Module 1 decided what comes in: the deliveries not yet made and the ones still inside the 60-day claim window, about 196,400 deliveries. Each one becomes a Work Order, with its line items (about 1.6 per delivery, so about 314,000) and its Service Appointment (about 196,400 more). That’s roughly 707,000 records, prepared in the preparation data store and ready to go. Not millions, but well past anything I’d send one record at a time. So, how do they get in? ⟲

銀行の裏の搬入口

Bulk APIを教えるとき、私は銀行を使います。預け入れの束を持って入ると、窓口係が200件を受け取り、あなたを列の最後尾に戻します。100万件のレコードなら、列に並ぶのが5,000回、APIの呼び出しが5,000回です。その間に、銀行の脇にトラックが止まり、大量の預け入れを降ろし、20分後には走り去っていきます。あなたはまだ列に並んでいるのに。それが搬入口で、その名前がBulk APIです。

The 200 is still real. A REST sObject Collections request takes “up to 200 records” (Create Records Using sObject Collections （新しいタブで開きます）, REST API Developer Guide), and a SOAP create() call the same: “If a create request exceeds 200 records, then the entire operation fails” (create() （新しいタブで開きます）, SOAP API Developer Guide; both checked 2026-10-27). Every 200 more records is another call. RouteDesk’s 707,000 records would be over 3,500 trips to the teller. ⟲

クリックで拡大

Same records, different door. ⟲

搬入口には5つのステップがあります。

1. **ジョブを開く。**赤いブザーを押して整理券、つまりジョブIDをもらいます。
2. **アップロードする。**搬入口が開き、その整理券に対してCSVファイルを積み込みます。1ファイルでも100ファイルでも。
3. **ジョブを閉じる。**大きな青いボタン、「アップロード完了」を押すまで、Salesforceはあなたが終わったことを知りません。ここで処理が始まります。
4. **「まだ着かないの？」**後部座席の私の子どもたちのように、ジョブIDを使って終わったかどうかを尋ねます。終わった？　終わった？
5. **結果を受け取る。**成功したレコード（新しいSalesforceのIDつき）か、失敗したもの（エラーつき）をダウンロードします。

クリックで拡大

Submit, wait, collect. ⟲

100万件のレコードが、何千回ではなく、ほんの数回の呼び出しで済みます。でも何が変わったかに注目してください。仕事が非同期になったのです。レコードごとの答えは返らず、提出し、待ち、回収します。だから呼び出し側は、何を提出したか、何がまだ処理中か、何が終わったか、何が失敗したか、何が戻ってきたかを知っている必要があります。それはAPIの細部ではありません。移行の管理です。

2つの搬入口：Bulk API 2.0とBulk API

バージョンは2つあり、どちらを使っているかが重要です。

• Bulk API 2.0 is the one to start with. You upload the data for a job and Salesforce splits it into batches for you, retries for you and runs them in parallel. A job can take 150 MB, measured after Salesforce encodes it, so Salesforce advises uploading no more than 100 MB of CSV per job. ⟲
• Bulk API (1.0) makes you create the batches yourself, up to 10,000 records each. It’s older, but it still has two levers 2.0 doesn’t give you: serial mode for loads, and PK chunking for very large exports (module 5). ⟲

Both share a rolling 24-hour allowance of 15,000 batches, and either can load up to 150 million records in 24 hours. Job results are kept for seven days after the job completes (Bulk API and Bulk API 2.0 Limits and Allocations （新しいタブで開きます）, checked 2026-10-27). Salesforce’s line between the doors: “Any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0”; below that, “bulkified” synchronous calls are fine (Loading Data from the API （新しいタブで開きます）, Best Practices for Deployments with Large Data Volumes, Winter ‘27, checked 2026-10-27). Those are today’s numbers: check them before you plan around them. ⟲

1件ずつ、まとまり、一括は、仕事の形についての私の考え方です。ユーザーの操作による1件の更新、ビジネスのプロセスによる数百件の関連レコード、移行での何百万件もの過去のレコード。製品の名前ではありません。道具を選ぶ前に、仕事の形が何かを問いましょう。

Test knowledge. Know when the Bulk API is the answer: more than about 2,000 records, asynchronous, a job you submit and collect. Know the two versions apart: Bulk API 2.0 splits the batches for you and runs them in parallel; Bulk API (1.0) has you build batches of up to 10,000 records, and only it offers serial mode and PK chunking. Both share 15,000 batches in a rolling 24 hours. ⟲

道具はアーキテクチャをなくさない

「Bulk APIを使います」。いいでしょう。でもそれでは、どのオブジェクトを先にロードするか、挿入かアップサートか、外部キーは何か、リレーションをどう組み直すか、一部のレコードが失敗したら何が起きるか、ジョブを並列に実行できるか、並列の仕事が同じ親を奪い合わないか、どんな自動化が実行されるか、どう照合し再開するかがわかりません。Bulk APIが解くのは輸送の問題です。移行を解くわけではありません。

The order comes from the model, and module 1 drew it for RouteDesk: reference data first, then the Work Orders, then their line items and appointments, then the claim Cases that point at them (Preserve the Source Identity, and Load by Keys). Each wave is its own job, and the next one doesn’t start until the last one’s results are in. Junction objects depend on two parents, self-referencing hierarchies may need several passes, and circular relationships may need records first and relationships second. Don’t discover these on cutover weekend. ⟲

レコードを先に、リレーションをあとにロードすることもあります。親会社、子会社、地域の子会社がどれも移行で作られます。一度の処理ですべてのリレーションを解決しようとするのではなく、安定したソースのキーを持つ取引先をロードし、2回目の処理で階層を設定します。同じ考えが、自己参照や循環する依存関係にも役立ちます。目標は一度で済ませることではありません。決定的で繰り返せる結果です。

挿入、更新、アップサート

Insert says create this as new. Update says I already know the Salesforce record I’m changing. Upsert says use this key to find out whether the record exists; update it if it does, create it if it doesn’t. With stable External IDs, upsert makes rehearsals far easier: load, find a transformation problem, fix it, rerun, without the run assuming everything is a first-time insert. Keys are architecture, not just integration plumbing. RouteDesk’s Work Orders upsert on the partner key, the same field the integration uses, so a manifest Redrock resends on cutover weekend updates the migrated record instead of duplicating it. ⟲

Upsert has a price, though. Salesforce’s own Large Data Volumes guide ranks the operations: “insert() is fastest, update() is next, and upsert() is next after that. If possible, also break upsert() into two operations: create() and update()” (Loading Data from the API （新しいタブで開きます）, checked 2026-10-27). How do you know which records are new and which already exist? The preparation data store knows, because it pulled down what Salesforce already has and keeps the IDs that came back (module 1). So the 190,000 delivered Work Orders that nothing in Salesforce has touched can go in as a plain insert, and only the open ones the integration may already have created need the upsert. ⟲

Two more lines from the same guide. Load clean data: “Errors in batches trigger single-row processing for that batch, and that processing heavily impacts performance.” That’s module 1 paying off at the loading dock. And when you update, “send only fields that have changed.” A reload that resends every field of 196,400 Work Orders does work nobody asked for. ⟲

でもアップサートは魔法ではありません。キーの戦略が間違っていれば、操作も間違います。同じ顧客の2件のソースレコードが別々のキーを持てば、Salesforceにとっては2件のレコードです。複数のターゲットを特定し得るソースのキーは、カーディナリティを誤解していたことを意味します。モジュール1の品質の仕事は今も重要で、APIの機能がそれに取って代わることはありません。

Test knowledge. Insert is the fastest operation, then update, then upsert; Salesforce suggests splitting an upsert into creates and updates where you can. Upsert needs an External ID, and it’s what makes reruns safe. Load clean data, because errors in a Bulk API batch push that batch into slow single-row processing, and send only the fields that changed. ⟲

並列は速い、そうでなくなるまでは

並列処理はスループットを上げます。でもロードの多くのレコードが同じ親を指していれば、トランザクションはその親のロックを奪い合い、速くするためにしたことが、ロックの競合、エラー、再試行を生みます。それは第7章のホットスポットです。100万件の子が少数の親に集まるなら、データの形がロードにとって重要になります。2つのバッチがそれぞれ相手の持つロックを待てば、デッドロック、交差点で動けなくなった2台の車です。

RouteDesk is exactly that shape. Almost 196,400 Work Orders, and nearly every one points at one of three Retail Partner Accounts. Load them in parallel in the order RouteDesk exported them, and every batch holds Work Orders for all three partners. ⟲

クリックで拡大

In export order, every batch needs every parent. One locks, the others wait. ⟲

Two levers. First, sort the files by parent, so the children of one parent travel together in the same batch instead of being spread across batches that collide. Salesforce gives the same advice: “When changing child records, group them by parent—group records by the field ParentId in the same batch to minimize locking conflicts” (Loading Data from the API （新しいタブで開きます）, checked 2026-10-27). ⟲

クリックで拡大

Sorted by partner, each batch works on its own parent. ⟲

Second, on Bulk API 1.0, serial mode processes one batch at a time: slower, but it removes the contention. I reach for serial mode when the data is complex and we’re running into collisions and timeouts. Salesforce’s own guide is more cautious: serial mode “is used only when previously submitted asynchronous jobs have accidentally produced contention because of locks. Use only when advised by Salesforce” (Limits （新しいタブで開きます）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-27). So sort first, and treat serial as the fallback. And it’s only on the older dock: Bulk API 2.0’s job reference says “Currently only parallel mode is supported,” and if other modes ever arrive, “the mode will be chosen automatically by the API and will not be user configurable” (Create a Job （新しいタブで開きます）, Bulk API 2.0, checked 2026-10-27). A load that needs serial processing is a reason to use Bulk API 1.0. ⟲

Serial mode is a setting on the job, chosen when you create it. On Bulk API 1.0, RouteDesk’s Work Orders would be: ⟲

POST /services/async/68.0/job
{
  "operation": "upsert",
  "object": "WorkOrder",
  "externalIdFieldName": "Partner_Delivery_Key__c",
  "contentType": "CSV",
  "concurrencyMode": "Serial"
}

Leave concurrencyMode out and you get Parallel, the default. Salesforce’s job reference says when to change it: “If parallel mode results in too many failed records or failed jobs, submit the job with Serial concurrency mode,” and adds that it “can significantly increase the processing time” (JobInfo （新しいタブで開きます）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-31). ⟲

And if three parents are too few for any sorting to help, look at the model. Checkpoint 1 already offered a way to spread them: link Work Orders to a child Account per distribution center, so nine parents share the load instead of three. That’s a design decision, made before the migration, not a loader setting. ⟲

私は「常に並列」からも「常に逐次」からも始めません。リレーションの形、ホットな親、動く自動化、ほかに何がロックするか、そしてリハーサルで何が起きたかを見ます。それから選びます。まず正しく、それから速く。

Test knowledge. Parallel loads lock parent records. When many children share a few parents, expect “unable to lock row” errors: sort the load file by parent so each batch touches as few parents as possible. Serial mode (Bulk API 1.0 only) removes the contention at the cost of speed; Salesforce reserves it for lock contention the sorting didn’t solve. ⟲

バッチサイズはチューニングの判断である

人は魔法の数字を欲しがります。私は持っていません。正しいサイズは、オブジェクト、レコードの複雑さ、自動化、リレーション、ロック、ペイロード、仕組みによって決まります。大きすぎれば失敗が高くつき、トランザクションの仕事が多すぎます。小さすぎればオーバーヘッドが支配し、実行が必要以上に長くかかります（そして1.0ではバッチの割り当てを消費します）。道具がサポートする制限の内側から始め、代表的なデータで測りましょう。

And the rehearsal data needs the same shape as production. Twenty million records in production, ten thousand in the test, and everything flies: what did we prove? Not much about scale. The test doesn’t need every record, but it must expose the architecture: heavy concentration on a few parents, millions of children, large text fields, complex relationships, historical skew, automation triggered by particular values. The Number of Zeros matters, and so does the shape behind the zeros. For RouteDesk that means a rehearsal set where a third of the Work Orders still point at Redrock. ⟲

ロード用ユーザー、そしてレコードを誰が所有するか

For a substantial migration I want a dedicated migration identity, not someone’s personal admin account: for traceability, controlled permissions, automation decisions (module 3), monitoring and troubleshooting. A million records created by the migration user during cutover tells me something. A million created by Daniel Reyes because Daniel ran Data Loader on Saturday night mixes human identity with system activity. Give it the permissions the job needs, and don’t let it become a permanent mystery superuser nobody dares disable. ⟲

Then don’t confuse who loaded a record with who should own it. Created By is provenance; Owner is architecture, with sharing and business consequences. Set business ownership deliberately. Sometimes there’s no good answer in the source: the record’s owner left years ago, or never existed. It can be hard to assign records to active users, and I’ve created a dedicated “data load” user to own them. That’s sound practice with one condition from chapter 7: a user who owns more than 10,000 records of an object is ownership skew, so that owner should have no role, or a role of its own at the top of the hierarchy (Ownership Data Skew （新しいタブで開きます）), and the records should have a path to real owners. Who owns the records, and where that owner sits in the role hierarchy, is an important decision the team makes for any bulk import, not something the loader defaults. For RouteDesk’s Work Orders, chapter 7’s question decides it: does ownership drive who sees a delivery? At Steve Trucking it doesn’t (partners see their own deliveries through the partner on the record), so one owner with no role is fine. ⟲

ツール：繰り返せるかで選ぶ

There are many ways to load data, and the tool matters less than how you use it. Salesforce’s Data Loader has been tried and true, but it’s aged: a desktop tool that works CSV by CSV. Its command-line version can be scripted and pointed at your preparation data store, which is how I’ve run repeated loads. Some tools connect a SQL database straight to Salesforce, copying data down and sending changes back with SQL. ETL and integration platforms do the same job at enterprise scale. And with the APIs you can drive the Bulk API directly: the Salesforce CLI’s sf data upsert bulk loads a CSV through Bulk API 2.0 with an External ID from one command (data upsert bulk （新しいタブで開きます）, Salesforce CLI Command Reference, checked 2026-10-27). You can even have AI write the small scripts that run each complex step. ⟲

どのツールでも、私のいちばん強い希望はこれです。**本番の移行を、移行を行う最初の機会にしたくない。**そして、リハーサルのたびに手作りの冒険をしたくもありません。ステップ17に「このCSVを開き、G列で並べ替え、空の行を消し、この数式を下までコピーし、この設定でData Loaderを実行する」と書いてあったら、私は不安になります。手作業のステップはどれも、間違ったファイル、漏れた行、古い版、まずい並べ替え、忘れたフィルター、リハーサルと違う設定の機会です。避けられないものもあるでしょう。文書化し、テストしましょう。でも目標は繰り返せることなので、抽出、変換、検証、ロード、結果の取得、照合は、毎回同じように実行されるべきです。

ロードをスケジュールするなら、終わりきる以上の頻度でスケジュールしないことです。ときどき90分かかる1時間ごとのジョブは、自分自身の上に重なって始まります。次の実行が始まる前に、前の実行が終わったことを確かめましょう。

Keep Every Result, and Bring the Keys Back

ロードごとに、入力の版、変換したロードファイル、ジョブID、成功と失敗の結果とそのエラー、時間、レコード件数、照合の出力を残しましょう。大きな移行のあと、誰かが「このレコードに何が起きたのか？」と尋ねます。私が欲しいのは証拠で、「土曜の朝の3つ目のCSVにあったと思う」ではありません。一括処理の結果は7日間しか保持されないので、その都度ダウンロードしましょう。これらの成果物にはあとでライフサイクルを与えればよく、移動を証明する必要があるうちに捨ててはいけません。

Then bring the keys back. The success results carry each record’s new Salesforce ID next to the key you sent. Write them back into the preparation data store, on the row that produced the record: that’s the last frame of module 1’s three sets of keys. On the Zendesk migration I described in module 1, that’s what made everything else possible. With the Salesforce IDs back on every row, I could load in phases (accounts and contacts first, then the cases, then the comments and files that hang off them), and each phase found its parents by the IDs the last one returned. I could do a partial load: just the rows that failed, or just one group. And I could reload: fix a transformation, regenerate the affected rows, and send only those, knowing exactly which Salesforce records they’d update. Without the keys back, every rerun is a guess. ⟲

失敗の規模も、ゼロの数の問いです。100件中20件の失敗はまずい。2,000万件中20件は、やはり調べる必要がありますが、別のシグナルです。件数だけでなく率を見て、失敗を分類しましょう。入力規則、親の欠落、キーの重複、ロック、データ型、自動化、権限。分類すれば、巨大なエラーファイルではなく、アーキテクチャの問題が見えてきます。

そして性能は1秒あたりのレコード数以上のものです。「スループットが倍になりました」。何が変わったのでしょう？　ロック、失敗、再試行は増えたか？　その先の自動化は遅れたか、共有の再計算は詰まったか、別の統合はあふれたか？　切り替え全体は本当に短くなったか？　移行は真空の中で動くわけではありません。

Test knowledge. The Bulk API’s success results return each record’s new Salesforce ID with the data you sent, and its failure results return each error; both are kept for seven days. Capture them, write the IDs back to the source or staging data, and you can load in phases, retry only the failures, and reconcile what landed. ⟲

全体の実行をテストする

取引先、次に取引先責任者、次に注文と、それぞれ別々にテストしたロードは、テスト済みの移行ではありません。最初から最後までの完全なリハーサルが欲しいのです。同じ順序、変換、身元、自動化の戦略、照合で、代表的な量で。ステップの間に依存関係が現れます。10分の遅れで次のロードが間違った時刻に始まり、予想外の失敗率で修正に何時間もかかり、共有の再計算が予定をずらす。全体の実行は、各コマンドが動くかどうかだけでなく、移行が動くかどうかを教えてくれます。

If the rehearsal includes a performance or scale test, put Salesforce’s lead time in the plan. “All tests must be pre-approved. Unapproved testing is subject to throttling or blocking,” and for tests at 120 requests a second or below, the request goes in “at least one week before the testing date” (Salesforce Performance and Scale Test FAQs （新しいタブで開きます）, Salesforce Help, checked 2026-10-27). A rehearsal that gets throttled proves nothing about cutover weekend. ⟲

AIはスクリプトを書ける。実行の責任はやはりあなたにある

AI is very good at generating transformation scripts, load orchestration, error parsers, reconciliation queries and retry logic. Use it. But generated code can be wrong at enormous speed: a wrong transformation on ten records is ten fixes; on ten million, the Number of Zeros applies to the mistake too. The way I use it is step by step: clean, transform and migrate steps, with every generated command and action tracked. That’s deterministic, auditable automation, not unattended judgment. Test it at realistic scale before you trust it with production data. ⟲

試験の先へ：AIが変えること。 AIは移行のツールを作る手間を減らし、一括の操作を生成してすばやく実行することを容易にします。操作が大きいほど、決定的な変換、記録されたステップ、リハーサル、管理、照合の必要性は強くなります。

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

• 移行をトランザクションのトラフィックのように扱うのではなく、どのロードの仕組みとAPIのバージョンが仕事の量と形に合うか。
• 依存関係が決めるオブジェクトとリレーションの順序。レコードとリレーションに別々の処理が必要な場合も含めて。
• Which operation each set of records gets (insert, update or upsert), based on what the preparation data store knows already exists. ⟲
• Where parallel processing is safe, and where concentration, locking or automation justify sorting by parent, a model change, or serial processing. ⟲
• どの安定したキー、移行用の身元、レコードの所有、繰り返せるツールが、リハーサルと本番のロードを決定的にするか。
• How results and new IDs come back, so loads can run in phases, retry only failures, and reload safely. ⟲
• 本番規模でプロセスを信頼する前に、どんな証拠、失敗の分類、全体のリハーサルが必要か。

搬入口にも計画が要る

The loading dock moves enormous amounts of data. It doesn’t decide which truck unloads first, where the pallets go, which shipment belongs to which customer, what happens to a damaged pallet, whether two forklifts are using the same aisle, or whether everything that should have arrived did. That’s architecture. Know the Number of Zeros and the shape behind them. Load in dependency order, use stable keys, control concurrency, bring the keys back, make the process repeatable, keep the evidence, and rehearse the whole thing. Then use the loading dock as fast as the architecture safely allows. ⟲

さらに学ぶ

• Salesforce, Bulk API and Bulk API 2.0 Limits and Allocations （新しいタブで開きます）, Developer Limits and Allocations Quick Reference, checked 2026-11-01. ⟲
• Salesforce, General Guidelines for Data Loads （新しいタブで開きます） and Limits （新しいタブで開きます）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes, Loading Data from the API （新しいタブで開きます）, Winter ‘27, checked 2026-11-01. ⟲
• Salesforce, REST API Developer Guide, Create Records Using sObject Collections （新しいタブで開きます）, checked 2026-11-01. ⟲
• Salesforce, SOAP API Developer Guide, create() （新しいタブで開きます）, and Bulk API 2.0, Create a Job （新しいタブで開きます）, checked 2026-11-01. ⟲
• Salesforce, Bulk API 2.0 and Bulk API Developer Guide, JobInfo （新しいタブで開きます） (the Bulk API 1.0 job fields, concurrencyMode), API version 68.0 (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Performance and Scale Test FAQs （新しいタブで開きます）, checked 2026-11-01. ⟲
• Integration Architectコース：一括処理 *(coming soon)*でBulk APIを詳しく扱います。
• このコースの中では：大規模に向けた設計（ホットスポットと所有のスキュー）。
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew （新しいタブで開きます）, checked 2026-11-01. ⟲
• Salesforce Developers, Salesforce CLI Command Reference, data upsert bulk （新しいタブで開きます）, checked 2026-11-01. ⟲