> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/data-migrator/data-migrator-ja/tenpurto/yi-xing/rekdomappingunomi.md).

# レコードマッピングの仕組み

## ![](https://1278659608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvaxzColPOlNbsq4imqpd%2Fuploads%2FcfMTqg4Brbm9baWutclZ%2FSummary2-Small-Icon.svg?alt=media\&token=d1cf162d-c02d-4184-988e-7f7350e450fc) 概要

Data Migrator はレコード マッピングを使用して、複数回の移行実行にわたってレコードの正確性を維持します。オブジェクトでレコード マッピングを有効にすると、Data Migrator はソース組織とターゲット組織の間で個々のレコードを対応付けるため、その後の移行では新しいレコードのみが追加され、既存のレコードは更新されます。テンプレート内では、各オブジェクトごとにレコード マッピングを個別に制御します。Data Migrator では、ソース組織とターゲット組織の間でレコードをマッピングするために 2 つの方法を提供しています: **自動** と **手動**。以下のセクションでは、各方法の仕組みを説明し、レコード マッピングの成功例と失敗例を示すサンプル シナリオを紹介します。

* [#automatic-record-mapping](#automatic-record-mapping "mention")
* [#manual-record-mapping](#manual-record-mapping "mention")
* [#record-mapping-scenarios](#record-mapping-scenarios "mention")

{% hint style="info" %}

#### レコード マッピングの有効化

デフォルトでは、テンプレート内のすべてのオブジェクトでレコード マッピングは無効です。レコード マッピングを有効にしない場合、移行時にソースのすべてのレコードが常にターゲット組織に挿入されます。これは、同じレコードが両方の場所に存在する場合、重複を引き起こす可能性があります。

オブジェクトのレコード マッピングは、［設定］タブから有効にします。次の記事では、オブジェクトのレコード マッピングを有効にする方法を説明しています。

* [オブジェクトレコードマッピングの設定](/data-migrator/data-migrator-ja/tenpurto/tenpurtodezain/obujekutorekdomappinguno.md)
  {% endhint %}

## 自動レコード マッピング

自動レコード マッピングは、ソース レコードとターゲット レコードを関連付けるために内部マッピング テーブルを使用する、状態を保持するマッピング ベースの戦略です。これは、リアルタイムのターゲット データではなく、過去のデプロイで作成された履歴マッピングに依存します。ソースからターゲットへのマッピングが一度存在すると、その関係は固定されるため、自動で移行済みのレコードに関してはあいまいさがありません。

自動は、次のような場合の繰り返し移行向けに設計されています:

* 使用している移行ツールが Data Migrator のみである
* 初回移行時にターゲット組織が空である
* 実行をまたいだ長期的な一貫性が必要である

自動は次のことを保証します:

* 同じソース レコードは常に同じマッピング済みターゲット レコードを更新する
* ビジネス フィールドの変更はレコード照合に影響しない
* マッピングが存在すれば、レコード更新は決定的である

ただし、自動はリアルタイムのターゲット データを評価しません。

### 自動の仕組み

自動は、決定論的なマッピング駆動プロセスに従います。下の図は全体の流れを示しています。

<figure><img src="https://1278659608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvaxzColPOlNbsq4imqpd%2Fuploads%2FHQ3R5paTJEYcCDt5ZNZi%2FFlosum%20Data%20Migrator%20VEID%20Flow.png?alt=media&amp;token=e9ff49d1-056a-490d-940a-b979f06cfd64" alt=""><figcaption></figcaption></figure>

{% stepper %}
{% step %}

#### ソース レコードを読み取る

移行実行中、各ソース レコードは個別に処理されます。
{% endstep %}

{% step %}

#### データベースでマッピングを検索する

システムは、ソース レコードの ID に対するマッピングがすでに存在するかどうかを確認します。
{% endstep %}

{% step %}

#### マッピング結果を評価する

<table><thead><tr><th width="180.33331298828125">マッピングが見つかった</th><th>操作</th></tr></thead><tbody><tr><td>いいえ</td><td>ターゲット組織に新しいレコードを挿入します。</td></tr><tr><td>はい</td><td>既存のマッピング済みターゲット レコードを更新します。</td></tr></tbody></table>
{% endstep %}

{% step %}

#### マッピングを保存する

マッピングが存在しない場合、システムはレコードをターゲット組織に挿入し、新しいマッピングを作成します。その後の移行では、このレコードは再度挿入されるのではなく更新されます。この処理は実行ごとに繰り返されるため、新しく追加されたソース レコードはデータベースで追跡されます。
{% endstep %}
{% endstepper %}

### 制限事項

{% hint style="warning" %}

#### 自動レコードマッピングの重要な制約

* 自動では、すでにターゲット組織に存在するレコードをマッピングできません。
* 別のツールまたは手動プロセスがターゲット組織内でレコードを作成または変更した場合、自動マッピングが古くなり、重複レコードが発生する可能性があります。
* 自動は、Data Migrator を通じて移行されたレコードのみを追跡できます。
  {% endhint %}

#### 古くなったマッピング

自動の信頼性は、そのデータベースの信頼性に依存します。ターゲット組織でレコードが手動または別のツールによって作成されると、マッピングは古くなります。以下の例では、これがどのように重複レコードにつながるかを示しています。

**例:**

1. ユーザーが、すべての Contact レコードを空の組織へ移行します。
   1. すべての Contact レコードがソースからターゲット組織へコピーされます。
   2. 各レコードに対して自動マッピングが作成されます。
2. ユーザーが次の Contact レコードを手動で作成します **Charlie** と **Alice** ソース組織とターゲット組織の両方で。
3. ユーザーが、ソース組織からターゲット組織へすべての Contact レコードの別の移行を実行します。
   1. **Charlie** と **Alice** 以前に移行されていないため、自動マッピングがありません。
   2. 次の新しいレコードが **Charlie** と **Alice** ターゲット組織で作成されます。
   3. ターゲット組織には次のレコードの重複が存在します **Charlie** と **Alice**: 1 つは手動作成によるもの、もう 1 つは移行によるものです。

## 手動レコード マッピング

手動レコード マッピングでは、1 つ以上のレコード フィールドを組み合わせて、ソース レコードとターゲット レコードを結び付ける複合 ID を作成します。標準の Salesforce 外部 ID とは異なり、複合 ID には任意のフィールドを使用できます。手動がターゲット組織を検索して一致するレコードをちょうど 1 件見つけると、新しいレコードを挿入する代わりにそのレコードを更新します。

これは、すでに自動レコード マッピングでマップされていないレコードを含むターゲット組織、または他のツールによって作成されたターゲット組織内のレコードへ移行するために設計されています。手動レコード マッピングのフィールドは慎重に選択してください。選択したフィールドのいずれかの値が変わると、マッピングは以前に移行したレコードと一致しなくなります。

### 手動の仕組み

手動レコード マッピングでレコードを移行する前に、対象オブジェクトでレコード マッピングに使用する 1 つ以上のフィールドを選択する必要があります。選択したフィールドは組み合わされ、固有かつ安定したキーを作成します。つまり、よく更新されるレコード フィールドが変更されてもキーは変わらず、組織内の各レコードに対して一意になります。手動キーには 1 つ以上のフィールドを選択できます。選択するフィールドが多いほど、キーが一意になる可能性は高くなります。ただし、フィールドを増やすと、キーが不安定になる可能性も高まります。

手動レコード マッピングでは、処理が生成されたキーと一致するものをターゲット組織で検索します。下の図と説明は、その仕組みを示しています。

<figure><img src="https://1278659608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvaxzColPOlNbsq4imqpd%2Fuploads%2FSS7vNmCOIbsfbeAEDUTo%2FFlosum%20Data%20Migrator%20CEID%20Flow.png?alt=media&amp;token=2b82cea9-8699-4038-a8ad-e88ed6380754" alt=""><figcaption></figcaption></figure>

{% stepper %}
{% step %}

### ソース レコードを読み取る

移行実行中、各ソース レコードは個別に処理されます。
{% endstep %}

{% step %}

### キーを生成する

A **キー** は、手動マッピング用に選択されたレコードのフィールドから生成されます。
{% endstep %}

{% step %}

### ターゲット組織をクエリする

ターゲット組織で次の項目に対する SOQL クエリを実行します: **キー**.
{% endstep %}

{% step %}

### クエリ結果を評価する

<table><thead><tr><th width="219.6666259765625">一致したレコード数</th><th>操作</th></tr></thead><tbody><tr><td>0</td><td>ターゲット組織に新しいレコードを挿入します。</td></tr><tr><td>1</td><td>一致した既存のターゲット レコードを更新します。</td></tr><tr><td>2 件以上</td><td>エラー - レコードはスキップされます。複数のレコードが次と一致するため <strong>キー</strong>、このレコードの手動キーは一意ではなく、レコードを移行できません。</td></tr></tbody></table>
{% endstep %}
{% endstepper %}

### 制限事項

{% hint style="warning" %}

#### 手動レコードマッピングの重要な制約

各レコードに一意のIDを作成する、安定したフィールドの組み合わせを選択することが重要です。

* **安定**：キーとして選択したフィールドのいずれかの値が変更されると、手動マッピングは以前に移行されたレコードと一致しなくなり、新しいレコードが挿入されて重複が発生します。
* **一意**：ソース組織で2つ以上のレコードが同じキーを共有している場合、キーが一意ではないため、移行はそれらをターゲットレコードに正しくマッピングできません。
  {% endhint %}

#### 不適切な手動フィールド

手動レコード マッピングは、手動マッピングに選択したフィールドが、安定していて一意なキーを作成する場合にのみ信頼できます。以下は、適切でないフィールド選択の例です。

次の例では Contact オブジェクトを使用します。

<table><thead><tr><th width="220">キーに選択されたフィールド</th><th>これらのフィールドが不適切な理由</th></tr></thead><tbody><tr><td><code>名前</code> と <code>市区町村</code></td><td>たとえ <code>名前</code> と組み合わせると、 <code>市区町村</code> 連絡先の市区町村は変更される可能性があるため、キーが不安定になります。</td></tr><tr><td><code>役職</code> と <code>部門</code></td><td>この組み合わせは一意ではありません。複数の連絡先が同じ役職と部門を共有できるためです。</td></tr><tr><td><code>名前</code> と <code>誕生日</code></td><td>この組み合わせは一意で安定しているように見えますが、 <code>誕生日</code> 最初は空欄で後から入力されることが多いため、キーが不安定になります。</td></tr></tbody></table>

## レコード マッピングのシナリオ

{% hint style="success" %}

#### テンプレート設計

オブジェクト: **Contact**

* フィールド: **名前**
* フィールド: **メール**
* フィールド: **市区町村**
  {% endhint %}

下の表では、相違点を太字で示しながら、ソースとターゲットのレコードを示しています。

**ソース組織の Contact レコード**

<table><thead><tr><th width="200.3333740234375">ID</th><th>名前</th><th width="210">メール</th><th>市区町村</th></tr></thead><tbody><tr><td>001D000000kL4p1</td><td>Alice</td><td>alice@company.com</td><td><strong>ベルリン</strong></td></tr><tr><td>001D000000kL4p2</td><td>Bob</td><td><strong>bobNew@company.com</strong></td><td>ロンドン</td></tr><tr><td>001D000000kL4p3</td><td>Charlie</td><td>charlie@company.com</td><td>パリ</td></tr><tr><td>001D000000kL4p4</td><td><strong>Dave</strong></td><td><strong>dave@company.com</strong></td><td><strong>シアトル</strong></td></tr></tbody></table>

**ターゲット組織の Contact レコード**

<table><thead><tr><th width="200.33331298828125">ID</th><th>名前</th><th width="210">メール</th><th>市区町村</th></tr></thead><tbody><tr><td>002D000000kL5p1</td><td>Alice</td><td>alice@company.com</td><td>ニューヨーク</td></tr><tr><td>002D000000kL5p2</td><td>Bob</td><td>bob@company.com</td><td>ロンドン</td></tr><tr><td>002D000000kL5p3</td><td>Charlie</td><td>charlie@company.com</td><td>パリ</td></tr></tbody></table>

### 自動レコード マッピングを使用したデータ移行

#### 成功シナリオ

このシナリオでは、以前の移行でソース組織とターゲット組織の間にすでに自動マッピングが作成されています。下の表はそのマッピングを示しています。

| ソース名    | ソース ID          | ターゲット ID        |
| ------- | --------------- | --------------- |
| Alice   | 001D000000kL4p1 | 002D000000kL5p1 |
| Bob     | 001D000000kL4p2 | 002D000000kL5p2 |
| Charlie | 001D000000kL4p3 | 002D000000kL5p3 |

移行が実行されると、自動レコード マッピングは既存のマッピングから各ソース レコードの ID を検索します。保存済みのマッピングがあるレコードはターゲット組織で更新され、マッピングがないレコードは新規レコードとして挿入されます。下の図と表は、この処理とターゲット組織での結果の操作を示しています。

<figure><img src="https://1278659608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvaxzColPOlNbsq4imqpd%2Fuploads%2FaIMfSu7i6GDBlAQuOiXT%2F3_VEID%20Record%20Mapping%20Example.png?alt=media&amp;token=0db00575-fe39-412d-972b-ad5857d23307" alt=""><figcaption></figcaption></figure>

<table><thead><tr><th width="179.66668701171875">ID</th><th>名前</th><th width="210">メール</th><th>市区町村</th><th>操作</th></tr></thead><tbody><tr><td>002D000000kL5p1</td><td>Alice</td><td>alice@company.com</td><td><strong>ベルリン</strong></td><td>更新</td></tr><tr><td>002D000000kL5p2</td><td>Bob</td><td><strong>bobNew@company.com</strong></td><td>ロンドン</td><td>更新</td></tr><tr><td>002D000000kL5p3</td><td>Charlie</td><td>charlie@company.com</td><td>パリ</td><td>更新</td></tr><tr><td>002D000000kL5p4</td><td><strong>Dave</strong></td><td><strong>dave@company.com</strong></td><td><strong>シアトル</strong></td><td>挿入</td></tr></tbody></table>

その後、新しく挿入されたレコードに対して新しい自動マッピングが追加されます:

| ソース名 | ソース ID          | ターゲット ID        |
| ---- | --------------- | --------------- |
| Dave | 001D000000kL4p4 | 002D000000kL5p4 |

#### 失敗シナリオ

このシナリオでは、以前の移行でソース組織とターゲット組織の間にすでに自動マッピングが作成されていました。ただし、その時点でマップされていたレコードは 2 件のみでした。下の表はそのマッピングを示しています。

| ソース名  | ソース ID          | ターゲット ID        |
| ----- | --------------- | --------------- |
| Alice | 001D000000kL4p1 | 002D000000kL5p1 |
| Bob   | 001D000000kL4p2 | 002D000000kL5p2 |

次の移行の前に、外部ツールが Charlie のレコードをソース組織とターゲット組織の両方に追加します。移行が実行されると、自動は既存のマッピングで各ソース レコードの ID を検索し、すでにマッピングがあるターゲット レコードを更新し、マッピングがないものには新しいレコードを挿入します。

下の図と表は、この処理とターゲット組織での結果の操作を示しています。Charlie の自動マッピングが存在しないため、移行では重複レコードが挿入され、追加で挿入された行に示されています。

<figure><img src="https://1278659608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvaxzColPOlNbsq4imqpd%2Fuploads%2FyGETlsSHDtegUt29M7Lp%2F4_VEID%20Record%20Mapping%20Example%20-%20Failed.png?alt=media&amp;token=b651fbc8-e7d2-4747-be3c-0b9670ce2624" alt=""><figcaption></figcaption></figure>

<table><thead><tr><th width="180.33331298828125">ID</th><th>名前</th><th width="209.666748046875">メール</th><th>市区町村</th><th>操作</th></tr></thead><tbody><tr><td>002D000000kL5p1</td><td>Alice</td><td>alice@company.com</td><td><strong>ベルリン</strong></td><td>更新</td></tr><tr><td>002D000000kL5p2</td><td>Bob</td><td><strong>bobNew@company.com</strong></td><td>ロンドン</td><td>更新</td></tr><tr><td>002D000000kL5p3</td><td>Charlie</td><td>charlie@company.com</td><td>パリ</td><td></td></tr><tr><td><mark style="color:$danger;"><strong>002D000000kL5p4</strong></mark></td><td><mark style="color:$danger;"><strong>Charlie</strong></mark></td><td><mark style="color:$danger;"><strong>charlie@company.com</strong></mark></td><td><mark style="color:$danger;"><strong>パリ</strong></mark></td><td><mark style="color:$danger;"><strong>挿入</strong></mark></td></tr><tr><td>002D000000kL5p5</td><td><strong>Dave</strong></td><td><strong>dave@company.com</strong></td><td><strong>シアトル</strong></td><td>挿入</td></tr></tbody></table>

新しく挿入されたレコードに対して 2 つの新しい自動マッピングが追加されます:

| ソース名    | ソース ID          | ターゲット ID        |
| ------- | --------------- | --------------- |
| Charlie | 001D000000kL4p3 | 002D000000kL5p4 |
| Dave    | 001D000000kL4p4 | 002D000000kL5p5 |

{% hint style="warning" %}
移行は失敗しました。外部ツールが Charlie をソース組織とターゲット組織の両方に、自動マッピングを作成せずに追加したためです。Charlie のマッピングがないため、自動は既存のレコードを更新する代わりにターゲット組織に新しいレコードを挿入し、その結果、重複が発生しました。
{% endhint %}

### 手動レコード マッピングを使用したデータ移行

#### 成功シナリオ

手動フィールド キー: `名前`

このシナリオでは、手動レコード マッピングは構成済みのキーを使用してレコードを照合します。 `名前` を手動キーとして、システムは各ソース レコードのキーを生成し、一致するものをターゲット組織に問い合わせます。ちょうど 1 件一致したレコードは更新され、一致しなかったレコードは挿入されます。下の図と表は、手動レコード マッピングの処理とターゲット組織での結果の操作を示しています。

<figure><img src="https://1278659608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvaxzColPOlNbsq4imqpd%2Fuploads%2FeN0MzVUkDxLyb4oaEEok%2F1_CEID%20Record%20Mapping%20Example.png?alt=media&amp;token=6a6b92f2-6cde-457c-90cf-bca80edd8701" alt=""><figcaption></figcaption></figure>

<table><thead><tr><th width="180.3333740234375">ID</th><th>名前</th><th width="209.6666259765625">メール</th><th>市区町村</th><th>操作</th></tr></thead><tbody><tr><td>002D000000kL5p1</td><td>Alice</td><td>alice@company.com</td><td><strong>ベルリン</strong></td><td>更新</td></tr><tr><td>002D000000kL5p2</td><td>Bob</td><td><strong>bobNew@company.com</strong></td><td>ロンドン</td><td>更新</td></tr><tr><td>002D000000kL5p3</td><td>Charlie</td><td>charlie@company.com</td><td>パリ</td><td>更新</td></tr><tr><td>002D000000kL5p4</td><td><strong>Dave</strong></td><td><strong>dave@company.com</strong></td><td><strong>シアトル</strong></td><td>挿入</td></tr></tbody></table>

#### 失敗シナリオ

手動フィールド キー: `名前` + `メール`

このシナリオでは、手動レコード マッピングは `名前` + `メール` を構成済みのキーとして使用します。各ソース レコードについて、システムはこのキーを生成し、一致するものをターゲット組織に問い合わせます。Bob のソース レコードではキー フィールドの 1 つに新しい値があるため、ターゲット組織内の彼のレコードとは一致しなくなっています。

ちょうど 1 件一致したレコードは更新され、一致しなかったレコードは挿入されます。下の図と説明は、手動レコード マッピングの処理とターゲット組織での結果の操作を示しています。Bob のソース キーが既存のターゲット レコードと一致しなくなったため、移行では重複が挿入され、追加で挿入された行に示されています。

<figure><img src="https://1278659608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvaxzColPOlNbsq4imqpd%2Fuploads%2FOSRDO54tfxS7GfSUJKvq%2F2_CEID%20Record%20Mapping%20Example%20-%20Failed.png?alt=media&amp;token=f1fdb64e-0820-4337-94c4-cdea43f3633b" alt=""><figcaption></figcaption></figure>

<table><thead><tr><th width="180.33331298828125">ID</th><th>名前</th><th width="210.3333740234375">メール</th><th>市区町村</th><th>操作</th></tr></thead><tbody><tr><td>002D000000kL5p1</td><td>Alice</td><td>alice@company.com</td><td><strong>ベルリン</strong></td><td>更新</td></tr><tr><td>002D000000kL5p2</td><td>Bob</td><td>bob@company.com</td><td>ロンドン</td><td></td></tr><tr><td>002D000000kL5p3</td><td>Charlie</td><td>charlie@company.com</td><td>パリ</td><td>更新</td></tr><tr><td><mark style="color:$danger;"><strong>002D000000kL5p4</strong></mark></td><td><mark style="color:$danger;"><strong>Bob</strong></mark></td><td><mark style="color:$danger;"><strong>bobNew@company.com</strong></mark></td><td><mark style="color:$danger;"><strong>ロンドン</strong></mark></td><td><mark style="color:$danger;"><strong>挿入</strong></mark></td></tr><tr><td>002D000000kL5p5</td><td><strong>Dave</strong></td><td><strong>dave@company.com</strong></td><td><strong>シアトル</strong></td><td>挿入</td></tr></tbody></table>

{% hint style="warning" %}
移行は失敗しました。Bob の `メール` 値が、ターゲット レコードが作成された後にソース組織で変更されたためです。 `メール` は手動キーの一部であるため、ソース レコードから生成された新しいキー (`Bob` + `bobNew@company.com`) は、既存のターゲット レコードのキー (`Bob` + `bob@company.com`) と一致しなくなりました。一致が見つからなかったため、手動は既存のレコードを更新する代わりにターゲット組織に新しいレコードを挿入し、その結果、重複が発生しました。
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.flosum.com/data-migrator/data-migrator-ja/tenpurto/yi-xing/rekdomappingunomi.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.