Transform Mapのcoalesceは何を保証する 一意性 重複 更新の境界線を公式仕様で整理

coalesceを一言で説明すると何か

Transform Mapのcoalesceは、インポート時に「この行は既存レコードの更新なのか、それとも新規作成なのか」を決めるための照合キーです。
Transform MapのフィールドマップでCoalesceを有効にすると、変換時にターゲットテーブルの既存レコードを検索し、値が一致するレコードが見つかれば更新、見つからなければ新規作成という分岐になります。

ここで大事なのは、coalesceは魔法の重複排除機能ではなく、あくまで「照合の条件」を与える仕組みだという点です。
設計が雑だと、意図せず上書き更新が起きたり、逆に重複が増えたりします。CSA学習でも実務でも、Import Setsの理解が浅いとここで一度つまずきやすいです。

---

coalesceが保証すること しないこと

まず結論からいきます。coalesceが保証するのは、だいたい次の2つです。

• 一致条件に合う既存レコードが見つかった場合は更新する
• 見つからなければ新規作成する

一方で、誤解されやすい「保証しないこと」もあります。

coalesceは一意性そのものを保証しない

「coalesceを付けたから、ターゲット側で重複が起きない」と思いがちですが、そこまでの保証はありません。
公式ドキュメントでも、coalesceに選ぶターゲットフィールドは一意になる値を持つものに限る、という注意があります。

なぜなら、ターゲット側に同じ値のレコードが複数存在してしまうと、coalesceはそれらを完全に排除できません。さらに重要な仕様として、複数一致した場合は最初に見つかった1件だけが更新されると明記されています。

これ、実務だと地味に怖いです。
例えば「社員番号が同じユーザーが2件いる」状態で、社員番号coalesceのインポートを回すと、どちらか片方だけが更新され続け、もう片方は放置されます。見た目上は更新が成功しているので、事故に気づくのが遅れます。

coalesceは更新の対象選定であり 更新内容の制御ではない

coalesceは「どのレコードに当てるか」を決めるだけで、更新の中身を安全にするわけではありません。
「このフィールドは上書きしない」「空なら更新しない」などの制御は、フィールドマップの設定、スクリプト、onBeforeなど別の仕組みで設計します。

---

単一 複数 条件付き 空欄一致 大文字小文字の違い

coalesceは設定のバリエーションがあり、ここを言葉で整理できると試験対策としても実務の事故防止としても効きます。

単一フィールドcoalesce

最も基本です。
例として、ユーザー取り込みでemailをcoalesceにするようなケース。ターゲットに同じemailがあれば更新、なければ新規作成です。

ポイントは「照合キーとして本当に適切か」。
emailが空欄のデータが混ざる運用なら、空欄同士が一致して更新対象になってしまう可能性が出ます（後述）。

複数フィールドcoalesce

複数にすると「どれか一致」ではなく、すべて一致したときだけ更新になります。公式でも「すべてのcoalesceフィールドの値が一致する必要がある」とされています。

ここは初学者が勘違いしやすいところで、
「AかBが一致したら更新したい」みたいなOR条件は、複数coalesceではできません。やるなら条件付きcoalesce寄りの設計になります。

条件付きcoalesce

スクリプトで「どの既存レコードに当てるか」を決める方式です。
典型はsys_idのフィールドマップにスクリプトを書き、一致したターゲットレコードのsys_idを返すことで更新対象にする、という考え方です。

条件付きcoalesceの良さは、複数フィールドのOR条件のような、現場の曖昧さを吸収できるところです。例えば「emailがあればemail、なければuser_nameで照合」みたいな設計も組めます（ただし事故る余地も増えるので、運用前提と監査ログは必須）。

空欄一致のcoalesce

設定名の通り、「空欄も一致として扱う」オプションです。
デフォルトでは、coalesceは値一致を前提に照合しますが、このオプションを有効にすると、ターゲットもソースも空欄なら一致とみなされます。公式の例として、User transform mapでemailが空欄の場合でも、空欄のターゲットにcoalesceするケースが説明されています。

これが必要な場合もありますが、必要性が薄いのにオンにすると「空欄ユーザーが空欄ユーザーを上書きする」ような事故が起きやすくなります。
判断基準はシンプルで、「そのフィールドは空欄のまま運用されるのが正常か」。正常なら検討、正常でないならデータ品質を先に直した方が安全です。

大文字小文字の扱い

coalesceはデフォルトでは大文字小文字を区別しない照合で、必要なら「case sensitive」を有効にして区別する、と公式で整理されています。

たとえば外部システムが Takeshi@example.com と takeshi@example.com を別物として扱う設計なら、区別が必要かもしれません。
ただ、多くの現場ではメールは大小を区別しない前提の方が運用が安定します。ここも「正しさ」より「一貫性」を選ぶ場面が多いです。

---

実務での設計例とありがちな事故パターン

ここからは、仕組みを「どう使い分けるか」の話です。CSAの学習でも、単語暗記よりこういう整理の方が後で伸びます。

設計例 ユーザー同期はemail coalesceが筋が良い

ユーザーの一意キーとしてemailを採用できる運用なら、単一coalesceでシンプルに組めます。
ただし、メール変更があり得る組織だと、メールをキーにすると「過去レコードに当たらず新規ができる」ことがあるので注意です。その場合は、社員番号など変更されにくいキーの方が向きます。

設計例 CMDBは単一キーに寄せすぎない

構成管理の世界は、外部ソースが増えるほど「キーが揺れる」ことが多いです。
シリアル番号が入らない機器、ホスト名が変更されるサーバ、命名規約が揺れるネットワーク機器など。こういうときに複数coalesceで厳密一致に寄せると、更新されず新規が増える方向に働きます。

そこで、条件付きcoalesceで「この条件ならこのキーを優先」みたいなルールを用意したり、そもそもImport Setsではなく別の識別ロジックを検討するなど、設計の引き出しが必要になります。
ここは試験でも「どの機能を使うか」より「なぜその設計にするか」を説明できると強いです。

事故パターン coalesceに一意でないフィールドを選ぶ

公式の注意がまさにこれで、複数一致すると最初の1件だけ更新されます。
「部署名」「所在地名」「カテゴリ」みたいな、同値があり得るフィールドをcoalesceに選ぶのは危険です。

事故パターン 空欄一致を気軽にオンにする

空欄も一致として扱うのは、使いどころが限られます。
データ品質が荒い状態でオンにすると、空欄を含む行が既存の空欄レコードに当たり続け、意図しない上書きが起きます。

事故パターン OR条件を複数coalesceで表現しようとする

複数coalesceは「全部一致」です。
ORをやりたいなら、条件付きcoalesceのスクリプトで照合の優先順位を明文化する方が、結果として保守しやすいです。

---

トラブルシュートと性能 監査目線のチェックポイント

coalesce周りの不具合は、見た目が「更新されたっぽい」「取り込めたっぽい」になりやすいので、チェックの筋道を持っておくのが大事です。

まず確認すること

• フィールドマップで、どのターゲットフィールドにCoalesceが付いているか
• 複数coalesceなら、全フィールドが期待どおりに値を持っているか
• 条件付きcoalesceなら、スクリプトが返している値は何か（sys_idを返しているか）
• 空欄一致やcase sensitiveを有効にしていないか

特に条件付きcoalesceは、返す値がズレると「更新されない」「別レコードに当たる」が起きます。スクリプトの意図をコメントで残しておくと、半年後の自分が助かります。

更新だけしたい 追加はしたくない場合

現場だと「マスタ更新だけしたい。新規は入れたくない」って要求がよく来ます。
この場合、公式ドキュメントにある例として、onBeforeで action == 'insert' のとき ignore = true; にして新規をスキップする方法が紹介されています。

この手の制御は、coalesce単体では実現できないので、「coalesceは照合」「更新可否は別で制御」と頭の中で切り分けておくと混乱が減ります。

性能面の注意

coalesceは変換時にターゲットを検索します。つまり、件数が多いテーブルで重いキーを使うと、取り込みが遅くなります。
実務では、coalesceに使うフィールドが検索に耐えるか、インデックス設計や運用頻度を含めて判断します。取り込みを定期実行するほど、ここは効いてきます。

---

まとめ

Transform Mapのcoalesceは、インポート時に「更新か新規作成か」を決めるための照合キーです。見つかれば更新、見つからなければ新規作成という分岐を作れます。
ただし、coalesceは一意性そのものを自動で保証するものではなく、ターゲット側のデータが重複していれば、最初に見つかった1件だけが更新されるという仕様も押さえておく必要があります。

単一coalesce、複数coalesce、条件付きcoalesce、空欄一致、大小文字の扱いは、それぞれ更新条件が変わります。暗記ではなく、「どの条件で既存に当たるのか」を言葉で説明できる状態にしておくと、CSA学習でも実務の設計でも迷いが減ります。

体系的に理解したい場合は、Import SetsとTransform Mapを一通りハンズオンで触れる教材があると早いです。Udemyにも、Import SetsやTransform Mapの設計を流れで学べる講座がいくつかあるので、手を動かしながら「更新と新規作成の境界線」を体感しておくと、知識が定着しやすくなります。