coalesce：重複を防ぐ小さなチェックボックス
インポート・連携シリーズの3本目です。前回、変換マップの下に「フィールドマップ」がぶら下がっていることを見ました。そのフィールドマップに1つ、小さなチェックボックスがあります。名前は coalesce（コアレス）。地味な見た目ですが、これが「取り込みでデータが重複するか、しないか」を決める、とても重要なスイッチです。
たとえば毎朝ユーザー一覧の CSV を取り込むとします。coalesce の設定を間違えると、同じ人が毎朝1件ずつ増えて、1週間で7人に化けます。この事故を防ぐのが coalesce です。今回は、この1つのチェックボックスを、実機の User と Location の対比で読み解きます。
このシリーズのまとめ：取り込みと連携の全体像は ServiceNowのデータ連携 全体地図 にまとめています。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。設定値・件数はすべて REST と実画面で確認しました（確認日 2026-07-13）。本番環境では設定が異なります。
coalesce とは：一致すれば更新、なければ新規
言葉の意味から。coalesce は「合体させる」という意味の英語です。ServiceNow のインポートでは、「取り込む行を、既存のどのレコードと同じものとみなすか」を決めるキーを指します。
動きはこうです。変換のとき、ServiceNow は coalesce に指定した項目の値で、ターゲットテーブルを検索します。
同じ値のレコードがあれば → その既存レコードを更新（update）する
同じ値のレコードがなければ → 新しいレコードを作成（insert）する
この「あれば更新、なければ新規」という判断の基準が coalesce です。公式ドキュメントでも、coalesce は「一意性を定義して重複を防ぐ」ものと説明されています。メールアドレスやユーザー名のような、人を一意に識別できる項目に付けるのが定石です。
言い換えると、coalesce は「このデータの世界で、何が同じものを指すのか」を ServiceNow に教える設定です。人間なら「メールアドレスが同じなら同じ人だよね」と自然に分かりますが、システムはそれを知りません。だから、突合の基準を明示的に指定してあげる必要があります。その指定が coalesce です。ここを正しく設定できるかどうかは、「取り込むデータの主キーは何か」を理解できているかにかかっています。データ設計の知識が、そのまま取り込みの品質に直結する、という点で、coalesce は地味ながら奥の深い設定です。
図にすると単純です。取り込む行のキーを見て、既存にあれば上書き、なければ追加。この分岐が、取り込むたびに1行ずつ行われます。100行の CSV なら、100回この判定が回る、というイメージです。図の右下にあるとおり、coalesce が1つも無いマップは、この分岐そのものが無く、常に追加（insert）だけになります。
毎朝のCSVで考える
もう少し具体的に、なぜ coalesce が重要かを見ます。人事システムから、毎朝ユーザー一覧の CSV が届くとします。その CSV を、毎朝 sys_user に取り込む運用です。
coalesce を email に設定していれば、こうなります。1日目、100人ぶんが新規作成される。2日目、同じ100人の CSV が届く。email をキーに突合すると、100人とも「既存にいる」ので、新規作成ではなく更新になります。電話番号や部署が変わっていれば、その差分だけが反映される。人は増えません。これが coalesce の効いた状態です。
もし coalesce を付け忘れていたら、悲惨です。2日目、突合するキーが無いので、100人がまた新規作成される。sys_user には同じ人が200件。3日目には300件。1週間で700件に膨れ上がります。実際にこの手の重複事故は、coalesce の付け忘れが原因のことが多いのです。だから「更新したいデータには必ず coalesce」を、取り込み設計の最初に確認する習慣が大切になります。
フィールドマップの中のチェックボックス
coalesce は、フィールドマップ（sys_transform_entry）の1レコードにあるチェックボックスです。User マップの email フィールドマップを開くと、こうなっています。
Source field が Email、Target field が Email。つまり「imp_user の email を sys_user の email に移す」対応づけです。その右下に Coalesce のチェックが入っています。これが「email を突合キーにする」という指定です。
同じ画面に、関連する設定が2つあります。
Coalesce empty fields … キーの値が空の行も突合対象にするか（既定 false）
Coalesce case sensitive … 大文字小文字を区別するか（既定 false）
Coalesce empty fields が false（既定）だと、キーが空の行は突合の対象から外れます。これは安全側の設定です。もし空同士を突合させてしまうと、「キーが空のレコード」がすべて同じ1件に上書きされる、という事故が起きかねません。空の値は「一致」とみなさない、という既定は、その事故を避けるための配慮です。
Coalesce case sensitive が false なので、Taro@example.com と taro@example.com は同じ人とみなされます。メールアドレスは大文字小文字を区別しないのが普通なので、この既定は理にかなっている。逆に、区別したいコード値をキーにするなら、ここを true にします。
単一キー：User は email 1つ
User マップのフィールドマップを一覧で見ると、突合キーの付き方がよく分かります。
7件のフィールドマップのうち、Coalesce 列が true になっているのは email だけでした。残りの department、first_name、last_name、location、phone、user_id はすべて false です。つまり User マップは、「email が同じなら同一人物」という単純明快なルールで突合します。
これは分かりやすい設計です。会社の中でメールアドレスは1人1つ、重複しません。だから email さえ一致すれば、同じ人だと断定できます。毎朝ユーザー CSV を取り込んでも、email をキーに既存を更新するので、人が増殖しません。単一キーで足りる典型例です。
ここで1つ、実務的な注意も添えておきます。単一キーは楽ですが、そのキーが本当に一意で、かつ必ず入っていることが前提です。もし email が空のユーザーが混じっていたら、突合できずに新規作成されるか、Coalesce empty fields の設定しだいで空同士が突合してしまう恐れもあります。だから単一キーを使うときは、そのキー項目が「空でなく、重複もしない」ことを、取り込み元のデータで確かめておくのが安全です。キーの信頼性が、そのまま突合の信頼性になります。User マップが email を選んでいるのは、社内ユーザーなら email がほぼ確実に一意で埋まっている、という前提があるからです。
複合キー：Location は5項目を組み合わせる
一方、Location マップ（imp_location → cmn_location）は事情が違いました。coalesce=true の項目を絞り込むと、こうなります。
画面上部の絞り込みは「Map = Location > Coalesce = true」。その結果が「1 to 5 of 5」で、city / name / state / street / zip の5項目すべてに coalesce=true が付いていました。これが「複合キー」です。この5つがすべて一致したときだけ、同じ拠点とみなします。どれか1つでも値が違えば、別の拠点として扱われます。
なぜ複合なのか。拠点（Location）には、email のような「1つで一意になる項目」がないからです。同じ名前の拠点は各地にあります（「東京支社」が複数あるなど）。名前だけでは同一とは言えない。そこで、名前・市・州・番地・郵便番号をすべて突き合わせて、初めて「同じ拠点」と判断します。1つの項目で一意にできないものは、複数を組み合わせてキーにする。User の単一キーと Location の複合キーを並べると、「何を一意の基準にするか」がデータの性質で変わることがよく分かります。
単一と複合、どちらを選ぶか
User と Location を並べると、選び方の基準が見えてきます。
分かれ目は「1つの項目で一意になるか」です。メールアドレスや社員番号、シリアル番号のように、それ自体で重複しない項目があるなら、単一キーで十分です。突合も速く、設計もシンプルになります。一方、拠点名や商品名のように、単体では同名がありうる項目しかないなら、複数を組み合わせて複合キーにします。
複合キーで注意したいのは、「1つでも値が違えば別物とみなされる」点です。Location なら、name と city と state と street が同じでも、zip が1文字違えば別の拠点として新規作成されます。だから複合キーを使うときは、取り込むデータの表記が揃っていることが前提になります。郵便番号にハイフンが入ったり抜けたりするだけで、重複が生まれてしまう。単一キーは楽ですが使える場面が限られ、複合キーは厳密ですがデータの品質に敏感、というトレードオフがあります。取り込み元のデータがどれだけ整っているかを見て、単一か複合かを決めるのが実践的です。
coalesce が無いとどうなるか
では、coalesce をどの項目にも付けなかったら、どうなるか。答えは「毎回、新規作成される」です。
突合するキーが無いので、ServiceNow は既存レコードを探しようがありません。だから取り込むたびに、全行がまるごと insert される。同じ CSV を2回取り込めば、データは2倍になります。これはプロパティにも表れていて、glide.import_set_insert_serialized_when_no_coalesce という設定が、「coalesce が無いときの挿入挙動」を扱っていました。
このプロパティの存在自体が、「coalesce の有無で挙動が分岐する」ことの裏付けです。coalesce を付けたマップは突合して update / insert を選び、付けないマップはひたすら insert する。同じインポート機能でも、この1つのチェックボックスで、まったく違うデータの育ち方になります。
裏を返せば、「重複させたくないなら、必ず coalesce を1つは付ける」が鉄則です。ログの取り込みのように「毎回新規で追記したい」ケースなら、あえて coalesce を付けない、という選択もあります。付けるか付けないかは、「そのデータは更新したいのか、追記したいのか」で決まります。
突合キーの全体像
各変換マップが、それぞれ「何を同一とみなすか」を独自に定義しています。coalesce=true のフィールドマップを横断で見ると、その多様さが分かります。
User … email（メールアドレス）
Computer … serial_number（シリアル番号）
Location … name/city/state/street/zip（5項目複合）
Notification … uuid → correlation_id（外部の一意ID）
LDAP … u_samaccountname（アカウント名）
対象データの「一意になるもの」が、そのまま突合キーに選ばれています。コンピュータならシリアル番号、ユーザーならメール、外部連携なら相手システムの一意ID。coalesce を見れば、「この取り込みは何を基準に重複を判断しているか」が一目で読めます。逆に、新しく取り込みを設計するときは、まず「このデータで一意になるのは何か」を考えることが、coalesce 設計の出発点になります。
とくに外部連携で覚えておきたいのが、Notification マップの uuid → correlation_id という組み合わせです。外部システムから届くデータには、その相手側での一意ID（uuid）が付いていることが多い。それを ServiceNow 側の correlation_id（相関ID）という項目に入れ、coalesce キーにします。こうすると、「相手システムのこのレコードは、ServiceNow のこのレコードと同じもの」という対応が保てます。同じ外部イベントが2回届いても、correlation_id が同じなら更新になり、重複しません。連携では、この「相手の一意IDを correlation_id に持たせて突合する」パターンが定番です。coalesce は、単なる重複防止を超えて、外部システムとの「同一性の橋渡し」まで担っている、というわけです。
性能：突合キーには索引を
coalesce には、性能の側面もあります。突合のたびに、キーの項目でターゲットテーブルを検索するからです。何万件も取り込むと、この検索が積み重なって遅くなります。
そこで、前回も触れた変換マップの Related Links「Index Coalesce Fields」で、coalesce 項目に索引を張ります。索引があれば検索が速くなり、大量取り込みの時間が縮みます。coalesce を設定したら索引も張る、というのがセットの作法です。複合キーの Location なら、5項目の組み合わせに索引が効きます。突合キーは「正しさ（重複防止）」だけでなく「速さ（索引）」の両面で設計する、と覚えておくと実務で役立ちます。
数万件、数十万件を扱う初期移行では、この差が体感できるほど出ます。索引が無いと、1件取り込むたびにテーブル全体を走査して突合相手を探すので、件数が増えるほど1件あたりが遅くなります。索引があれば、その走査が一瞬で済む。取り込みが「だんだん遅くなる」と感じたら、まず coalesce 項目に索引が張られているかを疑う、というのが定番の切り分けです。重複を防ぐ設計と、速く取り込む設計は、どちらも同じ coalesce 項目の上に乗っている、と捉えておくと見通しが良くなります。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
フィールドマップ一覧 … sys_transform_entry_list.do（Coalesce 列で絞り込める）
フィールドマップ1件 … sys_transform_entry.do?sys_id=...
変換マップ … sys_transform_map_list.do
まとめ
coalesce は、フィールドマップの小さなチェックボックスでありながら、「取り込みでデータが重複するか」を左右する要でした。一致すれば更新、なければ新規。User は email の単一キー、Location は5項目の複合キー。データの性質で、何を一意の基準にするかが変わります。そして、coalesce が無ければ毎回新規作成、重複します。
「重複させたくないなら coalesce を付け、索引も張る」。この1点を押さえるだけで、取り込みの事故はぐっと減ります。逆に「毎回新しく追記したい」なら、あえて coalesce を付けない。この判断を、取り込みを作る前に一度立ち止まって考えるだけで、後の運用がずっと楽になります。小さなチェックボックスですが、データが重複するか整合するかを決める要所だ、という意識を持っておくと、取り込みまわりのトラブルは大きく減らせます。
次回は、取り込み口であるデータソースの種類（File / JDBC / LDAP / OIDC）を、実機で詳しく見ていきます。同じインポートでも、どこから取るかで設定が変わる部分です。
その他、実機で確認した記録
用語
coalesce（コアレス） … 取り込む行を既存レコードに突合するキー。一致で更新、不一致で新規
単一キー … 1項目で一意（例: User の email）
複合キー … 複数項目の一致で一意（例: Location の5項目）
Coalesce case sensitive … 突合で大文字小文字を区別するか（既定 false）
フィールドマップ（sys_transform_entry） … 列と項目の対応。coalesce はここのチェックボックス
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sys_transform_entry_list.do?sysparm_query=coalesce=true（突合キーの一覧）
/sys_transform_entry.do?sys_id=...（1フィールドマップの coalesce 設定）
/sys_transform_map_list.do（変換マップ）
実測の要点（再掲）
User マップ: coalesce=true は email のみ（単一キー）
Location マップ: coalesce=true は name/city/state/street/zip の5項目（複合キー）
Computer=serial_number, Notification=correlation_id 等、マップごとに突合キーが違う
coalesce が無いと毎回 insert（重複）
検証範囲とおことわり
この記事の coalesce 設定値・件数・複合/単一の別は、PDI（Zurich / OOTB）の実測です。
実際に取り込んで update / insert が起きる様子は、sys_import_set が0件のため未確認（検証範囲外）です。
email / Location のフィールドマップは「High Risk」の標準レコードで、実機では原則書き換えません。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
