統合とデータの移動
ほかに 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)
Data Architectコース第9章の学習ガイドです。まず4つのモジュールを読んでください。このページでは、何が身についたかを確認できます。
この学習ガイドについて。 このガイドは、このコース自体の内容と、Salesforceが公開している試験ガイドの出題目標の一覧だけをもとに作られています。実際の試験問題をもとにしたことは一度もなく、試験に何が出るかを知っているとも主張しません。すでに受験した方は、どうか試験の問題を私に送らないでください。認定資格の契約で共有が禁じられていますし、そもそも答えを暗記するのはアーキテクトになる方法として間違っています。
試験ガイドは統合ツールの設定は出題しないとしており、この章はデータアーキテクトのための試食であって、Integration Architectコースではありません。試験が気にするのは、統合があなたのデータに何をするかです。キー、書き込みの権限、量と完全性、そして組織の間を動くデータ。プラットフォームの数字は変わるので、頼る前に最新の値を確認してください。
進めながらチェックしていきましょう。各項目には、それを教えている箇所へのリンクがあります。
矢印の前に（LDV-1とSDM-2を支える）
- I zoom out to the landscape, then zoom in on one arrow and ask its data questions: initiator, direction, freshness, volume and shape, key, write authority, and who proves it arrived. (Zoom In on One Arrow) ⟲
- 誰が起動するかとデータがどちらへ流れるかを分け、往復の全体が見えるのはクライアントだけだと知っている。（誰が始めるかは、データがどちらへ動くかではない）
- I treat freshness as a requirement, not a default, and match the timing to the mechanism: a synchronous call when the caller waits, platform events for fire and forget, Change Data Capture to keep another system in step, the Bulk API for large scheduled loads. (How Current Does It Need to Be?) ⟲
- I know a database stores; a process calls: polling needs a process, often middleware, and polling for nothing is waste. Change Data Capture has a daily delivery allocation, counted per subscriber. (Asking Every Minute) ⟲
- I know Salesforce’s guidance for pulling changes on a schedule:
getUpdated()andgetDeleted()for intervals over 5 minutes; more often than that, let Salesforce send the change. (Asking Every Minute) ⟲ - I know the three traffic shapes, singles, sets and bulk; that more than 2,000 records is a good candidate for Bulk API 2.0, fewer for bulkified synchronous calls such as Composite; and to send only the fields that changed. (The Number of Zeros Applies to Integrations Too) ⟲
- I know integration volume becomes data volume: ownership, automation, sharing and storage. (Integration Volume Becomes Data Volume) ⟲
キーと書き込みの権限（SDM-2、SDM-4、MDM-2を支える）
- I carry an external system’s key in an External ID field marked Unique, one-to-one, and upsert on it: no match creates, one match updates, more than one fails. (One Record, One Key) ⟲
- When one customer has several external records, I add records, not fields (a hierarchy, peers or a child object), never a key field per ERP. (When the Customer Is in Two ERPs, chapter 6: One Customer, Two ERPs) ⟲
- I know one key field with the source in the value is still one key per record, and a new partner is a new value, not a new field. (Steve Trucking: One Field, the Source in the Value) ⟲
- 安定したキーが再試行を安全にする（冪等性の始まり）ことを知っている。（キーが再試行を安全にする）
- I know a key isn’t authority, and enforce write authority in the org: record types, read-only fields for users, and an integration user with only the access its contract needs. (A Key Isn’t Authority) ⟲
- I know two-way movement still has one owner per field, and how unclear authority causes loops. (Two-Way Movement, One Owner per Field) ⟲
- あるSalesforceの組織のレコードIDは、別の組織では企業のキーではないことを知っている：2つの組織は2つのシステム。（キーにもライフサイクルがある）
Proof of delivery (supports MIG-1 and MIG-2) ⟲
- I know the client owns the conversation, and whoever knows what should arrive proves that it did; the server keeps its own promises and reports what it received. (Who Proves It Arrived?) ⟲
- I know “no errors” isn’t completeness: reconcile counts and, where it matters, control totals. (“No Errors” Isn’t Completeness) ⟲
- I design for restart and safe retries, and log every call: request ID, endpoint, response code and duration. (Know Where You Are, and Restart Gracefully, Log Every Call, Retries Are Normal; Make Them Safe) ⟲
- I know platform events and Change Data Capture events stay on the bus for 72 hours, subscribers resume by Replay ID, duplicates can happen, and proof needs my own return receipt. (The Return Receipt) ⟲
- I know the soft landing for partial failure, and I send the increment, not the universe. (Partial Failure, and the Soft Landing, Send the Increment, Not the Universe) ⟲
- I know the four shapes: request and reply, fire and forget, batch and events, and where each recovers. (Four Shapes of Integration) ⟲
- I know outbound messaging is supported but gets no further investment, and since Spring ‘26 sends no session ID. (Outbound Messaging: Know It, Don’t Start There) ⟲
統合のデータ契約（SDM-4を支える）
- I can write an integration data contract for an arrow, eleven lines: initiator, direction, freshness, volume and shape, key, write authority, pattern, mechanism, proof of delivery, sensitivity and travel, and change. (An Arrow Needs More Than a Label) ⟲
- I go requirement, then pattern, then mechanism. (Requirements, Then Pattern, Then Mechanism) ⟲
- I know when to give another team a custom Apex REST endpoint instead of the standard APIs (one stable interface, my own logging and orchestration) and what it costs (code to maintain; API and Apex limits still apply). (A Contract Between Teams) ⟲
- I count every place the data rests on its way, logs and retry queues included, when it has to stay in a country. (Make Each Line Specific) ⟲
- For multiple orgs, I start with a contract per movement, and sometimes the contract says don’t move it (chapter 14). (Multiple Orgs, and “Don’t Move It”) ⟲
Where the rest lives. This chapter is about moving data. Not moving it (Salesforce Connect, mashups, data brought in on demand, zero copy: exam objective LDV-3) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). Loading and extracting at volume is chapter 10, Migration and Synchronization. ⟲
試験の先へ
Section titled “試験の先へ ”試験は床であって天井ではありません。ここに挙げるのは、問題で問われるかどうかにかかわらず、アーキテクトに必要なこの章の習慣です。
- Zoom out, then zoom in. Start with the landscape; then take one arrow at a time. ⟲
- **やってくるトラフィックを理解する。**統合を設計するのが別の人でも。
- 移動を理解してから、仕組みを選ぶ。
- A database stores; a process calls. Someone has to own the process. ⟲
- **データの移動はただではない。**どのコピーも、管理すべき場所がもう一つ増えることだ。
- Add records, not fields. ⟲
- **レコードを知る。所有者を知る。**それから統合に書き込ませる。
- Whoever knows what should arrive proves that it did. ⟲
- **人知れず失敗し得るなら、それは完成していない。**止まった統合はデータ品質の問題だ。
- 権限は「できる」を語り、アーキテクチャは「すべき」を語る。
- Decide the interface between teams in the first weeks: the standard API or a wrapper you own. ⟲
- 契約はテクノロジーより長生きする。
- **エージェントの操作はどれも統合として扱う。**キー、権威、冪等性、可観測性とともに。
覚えておきたい用語
Section titled “覚えておきたい用語 ”| 用語 | ひとことで |
|---|---|
| 起動側 | 会話を始めるシステム（クライアント） |
| データの方向 | 誰が始めたかにかかわらず、ビジネスデータが動く向き |
| Freshness | How current the data must be |
| Polling | Asking on a schedule whether anything changed |
| 1件ずつ、まとまり、一括 | 一度に1件、小さなグループ、または一つのジョブでの大量 |
| 外部ID | Salesforceのレコードに保存され、照合に使われる、別のシステムのキー |
| アップサート | 一致するレコードがあれば更新し、なければ作成する |
| 冪等性 | 意図しない余分な効果なしに操作を繰り返せること |
| ウォーターマーク／チェックポイント | 統合が安全にどこまで進んだかの記録 |
| 照合 | 予定したものと届いたものを比べること |
| Proof of delivery | Evidence, held by the side that knows what should arrive, that it did |
| Return receipt | An acknowledgment sent back to say a message was received and processed |
| Request and reply | The client sends and waits for the answer |
| Fire and forget | The client sends without waiting for the outcome |
| プラットフォームイベント | 購読者のためにSalesforceのイベントバスに発行されるメッセージ |
| 変更データキャプチャ | レコードが変わったときにSalesforceが発行するイベント |
| Replay ID | 購読者がイベントの読み取りを再開するのに使う位置 |
| Custom Apex REST | Your own REST endpoint in Salesforce, written in Apex, in front of your objects |
| 統合のデータ契約 | 統合がデータに何をしてよいかの短い記録 |
理解度チェック
Section titled “理解度チェック ”コースと同じスタイルの短いシナリオです。開く前に自分の答えを決めましょう。
1. SalesforceがERPを呼び出して顧客の与信状況を取得します。データはどちらへ流れ、誰が起動していますか？
起動しているのはSalesforceで、データはERP → Salesforceへ流れます。起動側と方向は別の問いで、往復の全体が見えるのは起動側（クライアント）です。誰が始めるかは、データがどちらへ動くかではないを読み直しましょう。
2. チームが、GPSの測位ごとにSalesforceのレコードを作ることを提案しています。1日20万件です。まず何を尋ねますか？
なぜ年7,300万件の測位をトランザクションのモデルに入れるのか？ それは統合の判断である前に、データアーキテクチャの判断です。組織に必要なのは最新の位置だけかもしれません。統合の量はデータの量になるを読み直しましょう。
3. A warehouse team says, "Snowflake will just poll Salesforce every minute." What's missing?
⟲A database stores; a process calls. Something has to run the polling (usually an integration layer), with its own credentials, schedule and failures, and 1,440 calls a day mostly find nothing. Ask how current the data must be, then consider letting Salesforce send the changes (Change Data Capture), and count the events. Reread Asking Every Minute.
4. An external system needs Salesforce's changes about every hour, including deletions. What does Salesforce's own guidance suggest?
⟲For intervals over 5 minutes, the SOAP API’s getUpdated() and getDeleted() return what changed and what was deleted in a window, instead of a full extract. More often than that, let Salesforce send the change. Reread Asking Every Minute.
5. The ERP retries a "create customer" call after a timeout and Salesforce ends up with two accounts. How should it have been designed?
⟲Upsert on the ERP’s customer number in an External ID field marked unique, so a retry matches the existing record instead of inserting a duplicate. Reread Keys Make Retries Safe.
6. The customer exists in two ERPs, and someone proposes `NA_ERP_ID__c` and `EMEA_ERP_ID__c` on the Account. Your view?
⟲That’s a key field per ERP: an anti-pattern. It hides repeating structure in fields and turns every new ERP into a schema change. Add records, not fields: child accounts, peer accounts, or a child object per ERP record, each with one key. Reread When the Customer Is in Two ERPs.
7. The integration log shows zero errors, but finance totals don't match. What happened, and who should have caught it?
⟲Zero errors isn’t completeness: maybe fewer records were sent than intended, or values changed in transit. The side that knows what should have arrived proves it did: it reconciles counts and control totals against what it meant to send. Reread Who Proves It Arrived?.
8. A subscriber to platform events was down for a day. Can it catch up?
⟲Yes, within the 72-hour retention: it resumes from its last Replay ID. It must also handle duplicates, because the same event can arrive twice. Reread The Return Receipt.
9. The requirement says "we need a REST integration for credit holds." What's wrong with that?
⟲REST is a mechanism, not a requirement. The requirement is something like “agents see a credit hold within five minutes of the ERP change.” Start there, choose the pattern, then the mechanism, and write the contract. Reread Requirements, Then Pattern, Then Mechanism.
10. A partner's middleware team will send orders that touch four objects, and your data model changes every release. Standard API or custom Apex REST?
⟲It depends on the team. If they know Salesforce deeply and can change quickly, the standard APIs work. If not, a custom Apex REST endpoint gives them one stable interface, lets Salesforce orchestrate the four writes and log every call, and absorbs your changes inside. The cost is code you maintain, inside Salesforce’s API and Apex limits. Decide in the first weeks. Reread A Contract Between Teams.
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce 認定 Platform Data アーキテクト受験ガイド （新しいタブで開きます）, Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes （新しいタブで開きます）, Winter ‘27 (last updated September 18, 2026), checked 2026-11-01: the guide behind the exam’s Large Data Volumes section. Its integration rules are in module 1; its mashups are in chapter 14. ⟲
- 各モジュールの「さらに学ぶ」には、そのデータの裏づけとなるSalesforceのドキュメントが、確認した日付とともに載っています。