ServiceNow CSAのデータ移行・連携対策｜Import Set・Transform Map・REST・MIDの判断ガイド

ServiceNow CSAのデータ移行・連携では、Import Set・Transform Map・Coalesce・REST API・MID Server といった機能が次々に出てきます。外部データを取り込んだり外部システムと連携したりする仕組みですが、「どれがどの役割で、取り込みのどこに効き、試験でどう判断するのか」が掴みにくい——そう感じている方は多いはずです。

この記事は、CSAで問われるデータ移行・連携を、①各機能が取り込みのどこで効くか → ②取り違えると現場で何が起きるか → ③やりたいことから選ぶ早見表の順で理解するための記事です。用語の暗記ではなく、模試で迷わない判断軸を持ち帰ることをゴールにします。

▶ この分野の模擬試験を無料・登録不要で解く
CMDB・データ移行など、分野別に整理した独自CSA模試です

そもそもデータ移行・連携は「取込→変換→照合→反映」と「通信経路」

外部データの取り込みは1本の流れで、外部連携は「どの経路で通信するか」で整理すると迷いません。

• 取込：Data Source で取得元を定義し、Import Set（一時テーブル）に取り込む
• 変換：Transform Map で取込列を対象テーブルのフィールドへ対応付ける
• 照合：Coalesce で既存レコードと突合し、更新か新規作成かを判断する
• 通信経路：REST API で外部とHTTP通信、社内ネットワーク内なら MID Server を中継に使う

CSAで繰り返し問われる本質は、「取り込みのどこで効く機能か」「外部通信は直接かMID経由か」「構成移送（Update Set）と混同していないか」です。次の事故を見ると、照合（Coalesce）の取り違えが地味に怖いことが分かります。

これがないとどうなる ——「毎月の取り込みで、重複レコードが増え続けた話」

ある担当者が、取引先データのCSVを毎月Import Setで取り込んでいました。ところがCoalesce（既存照合キー）を設定していなかったため、毎回すべて新規作成され、同じ取引先が何件も重複。半年後にはレコードが膨れ上がり、レポートも分析も信用できなくなりました。

これは照合を意識しないと起きることの典型です。Coalesceは「既存レコードと突合して、更新か新規作成かを決める」キーです。これがないと、取り込みは毎回「新規作成」になり、重複が積み上がります。取り込みは「どのキーで既存と照合するか」を決めて初めて安全になります。

だからCSAは「取込の流れと経路」を問う ——鍵は「どこで効く機能か」

こうした事故を避けられるかを確認するため、CSAの試験範囲にはImport Set・Transform Map・Coalesce・REST・MID Server が含まれています。問われるのは操作の暗記ではなく、「取り込みのどの段階の機能か」「外部通信は直接かMID経由か」「構成移送と混同していないか」を正しく判断できるかです。

この先は、(1)迷ったとき立ち返る判断早見表、(2)主要な機能を「事故 → 放置するとどうなる → どう使うか → 改善後」で、の順に、模試で迷わない判断軸を作っていきます。

データ移行・連携 判断早見表（迷ったらここに戻る）

データ移行・連携の問題は、やりたいこと（問題文）と使う機能を結べれば解けます。次の早見表が、この記事全体の地図です。各機能は後の章で事故付きで深掘りします。

ここからは、主要な機能を「実際に起きがちな事故」から見ていきます。事故の形を知っていると、選択肢の言い換えに惑わされなくなります。

取込の流れ：Data Source → Import Set → Transform Map

現場で起きる事故：CSVをいきなり対象テーブルへ流し込もうとして、列の対応や型が合わずエラー多発。どこで何を変換するのかが整理できていなかった。

放置するとどうなる：取り込みの流れ（取得元→一時テーブル→変換→反映）を理解していないと、エラーの原因切り分けができず、毎回手探りになります。

CSAでこう使う：取得元はData Sourceで扱い、データを一度Import Set Table（取込用の一時テーブル）へロードします。次にTransform Mapで列を対応付け、変換を実行して対象テーブルへ反映します。Load Dataでファイルを選んだ画面やロード成功だけでは、対象テーブルへの反映・Coalesceによる更新まで成功した証拠にはなりません。変換履歴と対象レコードを分けて確認します。仕様の確認先：Import sets key concepts。

これは処理の役割の区別です。すべての入口で手動操作が2回必要という意味ではありません。たとえばImport Set APIは、ステージングへの入力に続いて関連するTransform Mapで変換する方式に対応しています。仕様の確認先：Import Set API。

改善後：「どこで取得し、どこで変換し、どこへ反映するか」が明確になり、エラーも切り分けやすくなります。

早見表の該当行：「外部データを一時取込」→ Import Set。「列を対象フィールドへ対応」→ Transform Map。

Coalesce：重複を生まない照合キー

現場で起きる事故：冒頭で紹介した「Coalesce未設定で重複が増え続けた」事故がこれです。既存照合を考えずに毎回新規作成していました。

放置するとどうなる：照合キーがないと、取り込むたびに既存レコードと突合されず、すべて新規作成されて重複が膨らみます。台数・件数・分析が信用できなくなります。

CSAでこう使う：Field MapのCoalesceには、対象レコードを一意に識別できる項目を指定します。ファイルをロードした時ではなく、Import Setの行を変換する時に対象テーブルを照合し、通常は一致すれば更新、一致しなければ新規作成します。複数項目をCoalesceにすると、すべての項目の値が一致して初めて同じレコードと判定します。仕様の確認先：Updating records using coalesce、Create a field map。

改善の確認：再取込では変換履歴のInserted・Updated・Errorと対象レコードを確認します。Coalesceは既存重複をまとめて削除する機能ではありません。対象テーブルに同じキーが複数ある場合、最初に一致したレコードだけが更新されるため、キーの一意性も確認します。

早見表の該当行：「既存と照合し重複防止」→ Coalesce。未設定だと毎回新規作成で重複が増える。

同じ照合キーを取り込んだときの件数と値を確認する

先に考えてみましょう：同じ外部IDの行をもう一度取り込むと、対象レコードは増えるのでしょうか。それとも値だけが変わるのでしょうか。

同じExternal IDを再利用し、部門だけを変えたデータを取り込みます。Field Mapの設定→初回の変換→対象データ→2回目の変換→最終データの順に追うと、InsertsとUpdatesの違いがつながります。

PDIで確認したレコードの変化

External ID	初回の部門	2回目の部門	結果
E100	Sales	IT	同じsys_idを更新
E200	General Affairs	General Affairs	既存値を維持
E300	存在しない	HR	新規作成

今回確認した結果：初回は2行とも新規作成。2回目はE100を更新し、E300を新規作成して、対象一覧は2件から3件になりました。E100のsys_idは前後で同一、E200のsys_idと部門も変わっていません。更新と新規追加の両方を変換履歴と対象データで確認した結果です。

確認環境：ServiceNow PDI／Core UI、学習専用Import Set Tableと対象テーブル、External IDでCoalesce。確認日：2026-09-10。

判断のポイント：一致判定に使うキーを決めるのがCoalesceです。設定しただけで終わらず、同じキーの再取込で既存行がどう扱われたかを履歴と最終データで確認します。

エラー対応：Import Log と Transform History で切り分ける

現場で起きる事故：取り込みが「失敗した」とだけ分かり、何件・どの行・なぜ失敗したのかが分からず、原因究明に時間がかかった。

放置するとどうなる：失敗の中身を確認できないと、同じエラーを繰り返し、取り込みが安定しません。

CSAでこう使う：取り込み結果はImport LogやTransform History、そしてエラーになった行を確認して原因を切り分けます。列対応・型・必須・Coalesceなど、どこで失敗したかを特定します。

改善後：失敗行と原因が分かり、修正して安定した取り込みにできます。

早見表の該当行：「取り込みエラーの原因を見る」→ Import Log / Transform History / 失敗行。

連携経路：REST API と MID Server を使い分ける

現場で起きる事故：社内ネットワーク内のシステムへServiceNowクラウドから直接つなごうとして、到達できず連携が動かなかった。

放置するとどうなる：通信経路を考えないと、クラウドから届かない社内システムには連携できず、原因も分かりにくくなります。

CSAでこう使う：外部とHTTPでやり取りするならREST API、ServiceNowクラウドから直接届かない社内ネットワーク内システムへはMID Serverを中継に使います。外部サービス連携を自動化で扱いやすくするIntegrationHub / SpokeはFlowから呼び出します。API連携では認証・権限・エンドポイント・データ形式を確認します。

改善後：到達経路に合った方式を選べ、社内システムとも安全に連携できます。

早見表の該当行：「外部とHTTPでやり取り」→ REST API。「社内NW内システムと通信」→ MID Server。

「取込と構成移送・直接通信とMID」を取り違える罠

データ移行・連携の判断問題は、似た機能の役割や経路を取り違えないかが問われます。具体シナリオに翻訳して違いを見ます。

「最も適切なのは？」と問われたら、「取込か構成移送か」「直接通信かMID経由か」「列対応か値加工か」の軸で選びます。これが迷わないための判断軸です。

データ移行・連携の運用ベストプラクティス

外部データの取り込みと連携を安全に回すために、現場で押さえておきたい運用のベストプラクティスは次の5つです。

1. 取込と構成移送を分ける。データはImport Set、設定はUpdate Setと使い分けます。
2. 更新と新規追加の目的を先に決める。既存データを更新する取込では一意なCoalesceキーを設計します。毎回別レコードとして追加する用途では、Coalesceを使わない選択もあります。
3. 失敗はログで切り分ける。Import Log・Transform History・失敗行で原因を特定します。
4. 通信経路を見極める。外部直結はREST、社内NW内はMID Serverを中継にします。
5. 連携の前提を確認する。認証・権限・エンドポイント・データ形式を最初に押さえます。

PDIで手を動かして確認する場所

Personal Developer Instance（PDI）で実際の画面を触ると、早見表が記憶に定着します。

• Data Source / Import Set Table / Transform Map：取込→変換の流れを作る
• Coalesce（Transform Map内）：照合キーの有無で更新/新規がどう変わるか試す
• Import Log / Transform History：失敗行と原因の確認方法を見る
• REST Message / MID Server / IntegrationHub・Spoke：連携経路の違いを確認する

まとめ：取込の流れと経路で選べると、判断問題に強くなる

• データ移行・連携は「取込→変換→照合→反映」と「通信経路」で考える
• 取込＝Import Set、変換＝Transform Map、照合＝Coalesce、取得元＝Data Source
• Coalesce未設定だと毎回新規作成で重複が増える
• 外部直結＝REST API、社内NW内＝MID Server経由
• データ取込（Import Set）と構成移送（Update Set）は別物

データ移行・連携は、CSAでも「取込の役割と通信経路の取り違え」を突く判断問題が多いテーマです。事故の形と早見表が頭に入ったら、実際の問題で手を動かして判断軸を固めましょう。