移行は何よりもまず品質のプロジェクト

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

モジュール1／5：Data Architectコース第10章「移行と同期」。各モジュールは単独でも読めます。 前へ：前の章、統合とデータの移動 · 次へ：大量のロード

このモジュールが答える問い： Salesforceにロードし始める前に、データに何が起きるべきか？

移行のプロジェクトは人をだますことがあります。こちらにデータがあり、あちらに必要なので、誰かがData Loader、Bulk API、CSVファイル、バッチサイズ、ロードの順序の話を始めます。どれも重要です。でも私はそこからは始めません。最初の問いは**私たちはまさに何を動かそうとしているのか？**です。ソースに重複した顧客、無効な住所、廃れた値、壊れたリレーション、誰も必要としない15年分のデータがあれば、Salesforceは喜んでそのすべての新しい住まいになります。ロードを速くしてもそれは直りません。移行は何よりもまず品質のプロジェクトです。

Start With the Picture

Here’s Steve Trucking’s landscape from Checkpoint 1, the weekend RouteDesk retires. RouteDesk is the desktop dispatch tool the coordinators used inside each distribution center (DC) to turn manifests into routes. It holds eight years of delivery history, about 5 million deliveries, and the quality varies by DC. At Checkpoint 1 we decided it retires, and we left one question open: what, if anything, comes into the org? That’s a migration decision, and this is the chapter for it. ⟲

クリックで拡大

One new arrow. It runs once, and then it disappears. ⟲

A migration is an arrow on the landscape like any other. Everything chapter 9 asked of an arrow applies: what moves, how much, by which key, who proves it arrived. The difference is that this arrow has an end. When it’s done, RouteDesk is switched off and the arrow comes off the drawing. That makes it easy to rush, because “we only do it once.” But the data it carries stays in Salesforce for years. ⟲

悪いデータを速く動かすことは成功ではない

レガシーシステムに顧客レコードが50万件あり、顧客レコードを50万件移行します。成功したのでしょうか？　そうかもしれません。でも4万件が重複で、7万5,000件は10年間動きがなく、何千件もが無効な州コードを持ち、使える識別子のないものがあり、もう存在しない親を指す子があり、レコードが作られた時期によって意味が変わる項目があったらどうでしょう？　レポートには相変わらずソース50万件、ターゲット50万件、100パーセントロード済みと書けますし、それでもプロジェクトは失敗であり得ます。完全性は重要ですが、完全性だけでは品質の証明になりません。

だからロードを設計する前に、ソースを理解したいのです。どんなデータがあり、それは何を意味するのか？　どれだけ古く、どれだけ信頼でき、実際に使われているのはどの項目で、どの値が有効で、どんなリレーションがあり、どの識別子を信頼できるのか？　移行を生き延びるべきものは何で、そうでないものは何か？　ここで前の章の内容が期日を迎えます。第4章では企業のシステム全体像を、第5章では品質は設計しなければならないことを、第6章では身元と権威を学びました。移行は、そのすべてを既存のデータの集まりに当てはめます。行を動かすだけではありません。過去のどの部分が未来のアーキテクチャの一部になるに値するかを決めることです。

移行するか、アーカイブするか、破棄するか。そしてその理由を知る

移行の一覧には、少なくとも3つの答えが必要です。**移行する、アーカイブする、またはポリシーに従って破棄する。**5年前のトランザクションの明細は、現役のデータモデルに置かずに、コンプライアンスのために保持する必要があるかもしれません。廃れた一時的なデータには保持の要件も価値もないかもしれません。履歴は検索できるアーカイブに属するかもしれません。第7章のライフサイクルの原則は「出口を設計する」で、移行はそれを当てはめる絶好の機会です。そこにあるからといって、すべてのレコードを持ち越さないことです。

So zoom in on RouteDesk and take it apart, one class of data at a time. ⟲

クリックで拡大

Every class of data gets a decision, a place and a reason. ⟲

The deliveries not yet made have to come in: manifests arrive one to two days ahead, so on cutover weekend RouteDesk holds about two days of work, roughly 6,400 deliveries, and the crews need them on Monday morning. The recent history comes in because of claims. A damage claim is a Case in Salesforce, and the agent working it needs the delivery behind it. So deliveries still inside the claim window come in too. Steve Trucking accepts claims for 60 days after a delivery, so that’s about 190,000 more Work Orders. Had the business said 30 days, it would be half that. The window is the business’s number, not ours. ⟲

The other 4.8 million deliveries go to Snowflake, where Checkpoint 1 already sends status history, kept by the partner key so a claim on an old delivery can still find it, and so leadership’s five-year reports still work. They don’t belong in the operational core: that would make Salesforce RouteDesk’s retirement home, and chapter 7 showed what Work Orders at volume cost. And the route plans and the coordinators’ drafts? Eight years of yesterday’s plans have no value once the deliveries are done. But I don’t decide that alone. ⟲

The opposite mistake is “we don’t need the old stuff.” Who decided? Legal, finance, operations, service, compliance? The data architect shouldn’t invent retention policy during a migration; we translate the business and regulatory requirement into architecture. Before excluding data, establish whether it must be kept, for how long, where, who needs access, and whether its relationships and source identifiers must survive. Eight years of Recipients’ names, addresses and phone numbers is exactly that kind of question: archiving them isn’t the same as keeping them forever. The goal isn’t to migrate less. It’s to know why every class of data is moving, or isn’t. ⟲

Test knowledge. Migrate what the new system needs to operate, not everything the old one held. Expect a scenario with years of legacy history: the answer is usually to migrate active and recent records and archive the rest outside Salesforce where it stays reachable, with the retention decision made by the business, not by the migration team. ⟲

Where the Preparation Happens

Before the steps, the place. All of this preparation happens outside Salesforce, in a working database of its own: Postgres, SQL Server, Oracle, MySQL, even SQLite for a small job, whatever the team knows. Not in Salesforce, and not in a spreadsheet that gets emailed around. I call it the preparation data store, or the preparation store for short. It sits in between: the source feeds it, and it feeds Salesforce. ⟲

クリックで拡大

The preparation data store sits in between. Every step in this module happens inside it. ⟲

The extract lands there raw. The standardizing, cleaning, enriching, deduping and validating all run there, as code. The quarantine is a table, the counts are queries, and the whole thing can be run again from the top. Some tools connect a database like this straight to Salesforce, copying data down and sending changes back; others export files for a data loader. There are many ways to load data. The principle doesn’t change: prepare it outside, then load the result. ⟲

And it holds more than the source. Pull down the relevant parts of the target org too. Why? Because dedupe has to compare against what’s already in Salesforce, and when the survivor of a merge is a record that’s already there, the new children need its key to link to it. You can’t decide the merge without both sides in front of you. For RouteDesk, the preparation store holds the RouteDesk extract and a copy of what Salesforce already has: the Retail Partner Accounts, the Products and Service Territories, the claim Cases with their delivery references, and the Work Orders the new integration has already created, because the partners don’t stop sending manifests for our cutover weekend. ⟲

Then you practice. Run the preparation, load a sandbox, reconcile, find the rule that was wrong, fix it, run it all again. By the time we reach production, the preparation has run many times, and it’s boring. That’s the goal. ⟲

私の順序：標準化、クレンジング、エンリッチ、重複排除、検証

When I’m preparing data for migration, I work in this order, and the order matters. All five steps happen in the preparation data store. ⟲

Standardize. Get equivalent values into one form. One source has CA, California and Calif.; another has US, USA and United States. A company comes in as Steve Plumbing, Steve's Plumbing and Steve's Plumbing LLC. Phone numbers arrive as 5555550142, (555) 555-0142 and +1 555 555 0142. Before we compare records or apply matching rules, we need to know which differences are formatting and which are meaningful. ⟲

Names are the classic trap. I had a system with first and last name in one field, and the Salesforce contact needs them apart. “Daniel Reyes” splits easily. Then you get “Mr. Daniel Reyes,” “Daniel Reyes PhD,” “Daniel Reyes III,” and names with two family names, such as Roberto González Suárez, where González isn’t a middle name: split that wrong and you’re in trouble. Build the patterns (two words, three words, a title, a suffix), run the splits, and have the customer validate the results. ⟲

**クレンジング。**間違っているもの、使えないもの、廃れたものを処理します。無効なコード、ありえない日付、誤字、仮の値、意味に合わないデータが入った項目。選択リストの値は意図してマッピングします。レガシーのリードの状況Coldは、ターゲットではClosedになるかもしれません。リストが長いときは（200個の値を見たことがあります）、変換表を作り、ソースの値ごとにビジネスにターゲットを埋めてもらいます。Salesforceは選択リストを厳しく検証するので、届く前にこれらを捕まえ、ソースの中身を入力規則に教えてもらうのを待たないことです。

RouteDesk’s “quality varies by DC” shows up right here. Each DC set up its own status codes over eight years, so the same outcome arrives in nine spellings. The transformation table maps every one of them to the Work Order’s status values in Salesforce: ⟲

DC	RouteDesk says	Work Order status
DC 1	DLV	Completed
DC 4	Delivered - OK	Completed
DC 7	DONE/INST	Completed (the install is on its line item)
DC 1	NH	Cannot Complete (nobody home)
DC 4	Refused	Cannot Complete
DC 7	CXL	Canceled

The left two columns come from profiling the extract; the right column comes from the business, not from us. Completed, Cannot Complete and Canceled are three of the standard Work Order status values (WorkOrder （新しいタブで開きます）, Object Reference, Winter ‘27, checked 2026-10-27). Notice the third row: one RouteDesk code carried two facts, the delivery and the install, and the target model keeps them apart. ⟲

Enrich. Sometimes missing information can be reliably added: a normalized address, a postal code from city and state, a county, a geolocation, a mapping from a legacy code to the new enterprise taxonomy, an enterprise identifier. Enrichment needs provenance. If we add or change information, I want to know where it came from and why I trust it. Some of RouteDesk’s older deliveries don’t name the Retail Partner at all, because each DC served one partner and everybody knew. The DC and the order number’s format tell us which partner it was. That’s enrichment from a rule we can show, not a guess. ⟲

**重複排除。**次に、現実世界の同じものを表すレコードを見つけます。なぜここから始めないのか？　汚れたデータの照合のほうが難しいからです。Steve's PlumbingとSTEVES PLUMBING LLCは、標準化したあとのほうがずっと比べやすくなります。まず入ってくるデータの中で重複を除き、次にすでにSalesforceにあるものと比べます。第6章のルールは今も当てはまります。**マージは破壊的で、つなぐことはそうではない。**あいまい一致のスコアがもっともらしく見えるからといって、レコードを一つに潰してはいけません。

Validate. Finally, test the transformed data against the target: required information present, reference values valid, relationships resolvable, keys unique where they should be, values fitting the model, authority rules preserved. Only then do I want to talk seriously about loading. And don’t expect the import tool to catch everything. Salesforce’s own Trailhead project on the NPSP importer makes the point: it catches invalid picklist values and missing required fields, but if a spreadsheet turned a postal code like 02134 into the number 2134, the importer loads the four digits (Perform an Import Dry Run （新しいタブで開きます）, Trailhead, checked 2026-10-27). That’s one more reason the preparation lives in a database with typed columns, not in a spreadsheet. ⟲

クリックで拡大

Five steps, in order. A record that fails one goes somewhere visible, with its reason. ⟲

Test knowledge. Data quality is fixed before the load, not after. Know the preparation steps (standardize, clean, enrich, deduplicate, validate) and why the order matters: you can’t match records reliably until their values are in one form. Picklist values are mapped with a transformation table the business signs off, because Salesforce rejects values a restricted picklist doesn’t have. ⟲

動かす前にクレンジングする

誘惑はこうです。「まず全部Salesforceに入れて、あとできれいにしよう」。私はそれを既定にするのは好きではありません。悪いデータは本番に入ったとたん、本番に参加します。ユーザーが目にし、自動化、レポート、統合、エージェントも目にし、重複は関連レコードを集め始め、クレンジングは難しくなります。現実的な範囲で、ターゲットに入る前にデータを良くしましょう。過去の不完全さをすべて直す必要はありません。それは費用対効果の判断です。でも「あとできれいにする」は移行の戦略ではありません。リリース日付きの技術的負債です。

And not every record deserves the same effort. An active customer with open orders, open cases, current contracts and billing relationships is different from one who bought something once nine years ago. Both may need to be kept. For the critical, active data I may require stricter validation, more enrichment, closer duplicate review and detailed reconciliation; for low-value history, preserving traceability may matter more than making every record perfect. Architecture is partly deciding where quality effort creates value. For RouteDesk, the 6,400 deliveries the crews will drive to on Monday get the strictest checks. The 4.8 million going to the archive need their keys and their dates right; nobody will fix eight years of typos in delivery notes. ⟲

ソースの身元を残し、キーでロードする

最もやりがちな間違いの一つが、Salesforceのレコードを出どころまでたどる能力を失うことです。レガシーの顧客CUST-847291が取引先001…になっても、それがCUST-847291から来たことは知っていたいのです。照合、トラブルシューティング、再ロード、監査、子レコードの照合、ロールバックの分析、そしてリリース後に届く問いのために。新しいSalesforceのIDはSalesforceの中で重要ですが、ソースの身元を消すわけではありません。これは第9章の外部IDの原則です。移行と統合は身元で出会います。

At Steve Trucking they meet in one field. Every Work Order already carries the partner’s key, Partner_Delivery_Key__c, an External ID marked unique, holding values like REDROCK-8472914-1 (chapter 9, module 2). RouteDesk kept the partner’s order number on each delivery, so the migration builds the same key and upserts on it, exactly as the integration does. That matters on cutover weekend: if Redrock resends a manifest for Tuesday after we’ve loaded Tuesday from RouteDesk, the integration finds the migrated Work Order and updates it instead of creating a second one. RouteDesk’s own delivery number comes along too, in a plain field, so anyone can trace a Work Order back to the record it came from. ⟲

So don’t rebuild relationships by name (“find the Account whose Name is Acme Distribution”). If the legacy contact carries Legacy_Account_ID = CUST-847291 and the Salesforce Account carries that identifier as an External ID, the relationship is rebuilt deterministically. The Bulk API does this in the load file itself: a column header such as WorkOrder.Partner_Delivery_Key__c says “find my parent by this indexed field,” and Salesforce looks up the parent’s ID for you (Relationship Fields in a Header Row （新しいタブで開きます）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-27). Keys turn “I think this child belongs here” into “I know which parent this came from,” and that matters more as the Number of Zeros grows. ⟲

Relationships also create sequence. If contacts reference accounts, the accounts must exist first; if line items reference orders and products, those come first. So migration isn’t one giant load. It’s reference data, parents, children, junctions, then dependent history, in an order the target data model dictates. That’s one more reason the data architect belongs in migration planning: the model tells us how the migration has to be assembled. Here’s RouteDesk’s open work, on Checkpoint 1’s model. ⟲

クリックで拡大

Wave 1: what the Work Orders will point to has to exist first. Most of it already does. ⟲

クリックで拡大

Wave 2: the Work Orders, upserted by the partner key. ⟲

クリックで拡大

Wave 3: the children, each finding its Work Order by the same key. ⟲

クリックで拡大

Wave 4: the claim Cases already in Salesforce get their link to the delivery. The model sets the order. ⟲

Test knowledge. Keep each legacy record’s key in an External ID field, load parents before children, and let each child find its parent by that key: an upsert on the External ID, and a relationship column in the load file (Parent.External_Id__c) instead of looking up Salesforce IDs. Reloads then update instead of duplicating, and every record traces back to its source. ⟲

マージしたレコードには子の戦略が要る

これは過小評価されがちな問題です。分析の結果、レガシーの顧客A、B、Cが同じ顧客だとわかり、ターゲットには取引先が1件できます。いいでしょう。でもAには12件のケース、Bには4件の注文、Cには3件の取引先責任者があります。子のマッピングを設計し直さずに親を概念上マージすれば、親は解決してもリレーションは壊れます。どの重複排除の判断にも、子の戦略が必要です。

RouteDesk has its own version. When a partner revised a manifest on the day, a coordinator sometimes keyed the delivery in again instead of editing it. Now RouteDesk has two deliveries with the same partner order number: one with the old window and two stops, one with the new window and the crew’s notes. Salesforce will have one Work Order, because the partner key is unique. Which window wins, and what happens to the stops and notes on the other one? ⟲

まず項目です。2件のレコードが一致したとき、どの値が勝つのか？　空白対値なら簡単です。衝突はそうはいきません。StevenかStephenか、Salesforceにあるメールかロードのメールか？　残すレコードを選んで項目ごとに決め、早い段階でサンプルのケースをビジネスに見せて、判断に彼らの指紋が残るようにしましょう。

Then the children. I see three options: add the children to the survivor, don’t load the merged record’s children, or load the merged record as inactive, linked to the survivor, with its children kept on it. ⟲

クリックで拡大

Three ways, none free. Notice the third one at RouteDesk: the inactive duplicate can’t reuse the partner key, because the survivor already holds it, so it needs a key of its own. ⟲

Whichever you choose, it happens in the preparation store, before anything loads. That’s where the survivor is picked, sometimes a record that’s already in Salesforce, pulled down with its key. That’s where each child gets the key of the parent it will point to. And that’s where the merged record either keeps its children, hands them over or is left out. Salesforce receives the result of the merge, not the job of doing it. ⟲

どう選ぶか？　データがどれだけ重要か、ロードしたものまでの追跡可能性が必要かによります。そして、そもそもマージする利点とリスクを比べましょう。小売の顧客リストで別々の2人の購買履歴を誤ってつなぐのは迷惑で済みますが、ある患者の薬を別の患者の記録に表示するのは深刻な違反です。誤った照合の代償が大きいほど、マージは慎重にすべきです。どう決めるにせよ、それぞれの子を元のソースまでたどれるでしょうか？　移行の重複排除は「取引先で重複の照合を実行する」ことではありません。リレーションのグラフ全体が重要なのです。

私自身、その逆の立場にいたことがあります。大学時代から買い物をしていた小売店が顧客データを移行していて、調べてみると、Steve Simpsonが6つほどのメールアドレスと住所で現れました。大学の住所、借りていた家、そのあとの住まい。マージすべきでしょうか？　世の中にはほかにもSteve Simpsonがいます。ビジネスは、私の古い履歴をつなぐことは、私を別のSteve Simpsonとマージしてしまうリスクに見合わないと判断しました。それがすべてのマージが答えるべき問いです。データをまとめる利点は何で、間違った人を選ぶリスクは何か？

Test knowledge. Deduplicate before the load, within the incoming data and against what’s already in Salesforce, with matching rules and a survivor chosen field by field. Expect the follow-up question: what happens to the merged record’s child records? Re-parent them to the survivor, leave them out (and archive them), or keep them on an inactive linked record. Each has a cost. ⟲

繰り返せる変換と、残しておく生のソース

レガシーの状況AはActiveに、IはInactiveに、SはSuspendedになります。そのマッピングはどこにあるのでしょう？　誰かの記憶の中ではなく、3つのファイルに少しずつ違う形でコピーされたExcelの数式でもなく、金曜の夜の手作業の手順でもありません。明日再ロードしたら同じ結果になるべきなので、マッピング、標準化とクレンジングのルール、変換、重複排除の判断、キーの生成はすべて再現できなければなりません。移行のプロセスはコードです。一部がプログラミング言語で書かれていなくても。

And don’t destroy the starting point. Keep the original extract in raw tables, exactly as it came out, and never change them. Each step writes its result to a new staged table: standardized, cleaned, deduplicated, load-ready. When something looks wrong, I want to know whether it was wrong in the source, changed by our transformation, changed by the load, or changed by Salesforce automation afterward, and with every table kept I can walk back through them and find out. Overwrite your only copy of the source while cleaning it and you lose the evidence. ⟲

I learned how much this pays off on a support migration. A company was moving its support desk from Zendesk into Salesforce, and Zendesk’s tickets were very similar to Salesforce Cases, but not exact. So I loaded every Zendesk export into a SQL database as raw tables, one per Zendesk structure: organizations, users, tickets, custom fields, comments, attachments. Then I built interim tables that got closer and closer to the Salesforce structure, with the field and picklist mappings kept as tables of their own. Then I loaded Salesforce from those tables and brought the Salesforce IDs back. In the end every row had three things: its original Zendesk key, the transformations that had been applied to it, which were never one way, and its Salesforce key. That’s what let me do partial loads and reloads whenever I needed to. ⟲

Here’s the same design for RouteDesk, one step at a time. ⟲

クリックで拡大

Extract: one raw table per RouteDesk structure, each row with its RouteDesk key. These tables never change. ⟲

クリックで拡大

Generate: new tables shaped for Salesforce, built from the raw ones with the mapping tables. The raw tables are still there. ⟲

クリックで拡大

Load: the Work Orders upserted by the partner key, then their children. ⟲

クリックで拡大

Keys back: each Salesforce ID is written to its row. Now every row knows where it came from, what was done to it and where it landed. ⟲

So no transformation is allowed to lose fidelity. If a step throws information away (truncates a note, drops a code it didn’t recognize, keeps one of two conflicting values without saying which), I can’t trace back through it, and I can’t repeat the run and get the same answer. Keep the raw tables, keep the staged tables, keep what each load sent and what came back. Then you can rerun the whole thing from the raw extract at any time, and you have the history of every load. This is migration’s version of lineage: preserve where the data came from and what you did to it. ⟲

Sometimes the Staging Is Inside Salesforce

The preparation store isn’t the only place to stage. In a few special cases, the last stop before the real objects is a plain custom object inside Salesforce: one flat row per source record, no automation, loaded fast. Then a batch process works through the rows and builds the real records. I’ve used it when Salesforce’s own logic had to create the records and was too slow to load through: a scheduling process that took a few seconds per appointment. Module 3 comes back to that case. ⟲

Salesforce uses the same pattern in its own products, and it’s worth learning from. The Nonprofit Success Pack loads a spreadsheet into its NPSP Data Import object first. A dry run checks for matches without creating anything. Then the importer creates the accounts, contacts and donations, and writes each new record’s ID back onto the row it came from (How the Import Process Works （新しいタブで開きます）, Salesforce Help, checked 2026-10-27). That’s a reference, not a rule: staging inside Salesforce is the special case, not the way to load everything. ⟲

For RouteDesk, a one-time move with heavy cleaning and merging, the preparation store outside Salesforce does the work, and the load sends the result. ⟲

悪いレコードにも行き場が要る

50万件のうち、497,800件が検証を通り、2,200件が通りません。黙って捨てますか？　いいえ。必須項目にゴミを押し込みますか？　いいえ。すべての過去のレコードが完璧になるまでプロジェクトを止めますか？　おそらく違います。私が欲しいのは、隔離と修正の道筋です。どのソースレコードが失敗したか、なぜか、どのルールが拒否したか、切り替えの前に直さなければならないか、誰がその判断に責任を持つか、延期できるか、を記録するものです。これで例外は、隠れたデータの損失ではなく、目に見えるアーキテクチャの仕事になります。

Before you call a record bad, look at the rule that rejected it. Sometimes the record is fine and the rule is wrong. Salesforce’s Well-Architected framework puts it plainly: “data architecture decisions determine the populations that become visible—and invisible,” and a required email address “excludes populations that don’t have reliable internet access or personal email addresses” (Fairness （新しいタブで開きます）, checked 2026-10-27). RouteDesk has thousands of deliveries where the Recipient gave only a phone number. If the new Work Order requires an email, those aren’t bad records. They’re real people the rule would make invisible. Fix the rule, not the person. ⟲

そしてロードの前に変換を証明しましょう。ソースのレコードは何件から始めたか、意図して除外したのは何件か、統合した重複は何件か、準備ができたのは何件か、隔離したのは何件か、解決できる親子のリレーションはいくつか、管理合計はいくらか？　ロードの前に数字が合わなければ、ロードを速くしても役に立ちません。モジュール4では件数、合計、抜き取り確認、集計レポートで移行を証明しますが、証明はここから始まります。

AIはクレンジングを助けられる。真実を作り出すことはできない

AIは移行で役に立ちます。マッピングの提案、疑わしい値の発見、重複候補のグループ化、異常の検出、変換のコードの生成、拒否されたレコードのパターンの説明。でもエンリッチのプロセスが「この会社はおそらくアリゾナにある」と判断したなら、「おそらく」では足りません。そして2件の顧客がマージするのに十分似ていると判断したなら、第6章を思い出してください。誤った照合は、照合の取りこぼしより大きな害をもたらし得ます。調査を速めるためにAIを使いましょう。権威ある企業のデータを、黙って作り出させてはいけません。

試験の先へ：AIが変えること。 AIは移行の間のプロファイリング、マッピング、異常の検出、候補の照合を劇的に加速できます。権威あるビジネスデータを作成、マージ、変更する判断の周りには、決定的なルール、出どころ、人によるレビューを置いておきましょう。

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

• ビジネス上の価値と保持の要件に従って、どのソースのデータを移行し、アーカイブし、除外するか。
• Where preparation happens (a preparation store outside Salesforce, a staging object inside it, or both), and which parts of the target org are pulled down to merge against. ⟲
• ターゲットに入る前に、データをどう標準化し、クレンジングし、エンリッチし、重複を除き、検証するか。
• 重要なターゲットのレコードをすべて追跡し照合できるように、どのソースの識別子とリネージを残すか。
• The load order the target data model dictates, and the keys each child uses to find its parent. ⟲
• 重複排除の判断が、リレーションのグラフ全体にわたって項目と子をどう扱うか。重要度、追跡可能性、誤ったマージのリスクで比べて。
• 本番のロードを始める前に、どの変換と例外処理のルールを繰り返せるようにしておかなければならないか。

移行をロードした行数で測らない

「50万件中50万件のレコードをロードしました」は、ローダーが動いたことを教えてくれます。私が知りたいのはこうです。正しいデータを動かしたか、良くすべきものを良くしたか、身元とリレーションを守ったか、重複を安全に統合したか？　除外したものを説明でき、変換を再現でき、Salesforceのレコードをソースまでたどれ、結果を証明できるか？　まずその仕事をしましょう。どれだけ速くロードできるかを気にするのは、そのあとです。

さらに学ぶ

• Salesforce, General Guidelines for Data Loads （新しいタブで開きます） and Relationship Fields in a Header Row （新しいタブで開きます）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
• Salesforce, WorkOrder （新しいタブで開きます）, Object Reference for the Salesforce Platform, Winter ‘27 (API version 68.0), checked 2026-11-01. ⟲
• Salesforce Help, How the Import Process Works （新しいタブで開きます） (the Nonprofit Success Pack’s staging object), checked 2026-11-01. ⟲
• Hands-on: the Trailhead trail Import Data With Nonprofit Success Pack (NPSP) （新しいタブで開きます） walks through the whole staging pattern in a practice org: a template, staging rows, a dry run, fixing the failed rows, then the import. It runs in a Trailhead Playground; Trailhead notes that as of December 2025, NPSP is no longer offered as a preconfigured package in production orgs. Checked 2026-10-27. ⟲
• Salesforce Architects, Well-Architected, Fairness （新しいタブで開きます）, checked 2026-11-01. ⟲
• In this course: Master Data and Identity (matching, survivorship, link vs merge), Data Quality and Governance, and Keys and Write Ownership (the partner key). ⟲
• Trailhead, Perform an Import Dry Run （新しいタブで開きます）, checked 2026-11-01. ⟲