Import Setでデータが反映されない時の確認順 まず見るべき場所が全部わかる

Import Setはどこで止まりやすいのか

Import Setで「取り込みはしたはずなのに、ターゲットに反映されない」という場面は、慣れていないとかなり混乱します。理由はシンプルで、Import Setは1つの操作に見えて、実際は データの取り込み と 変換 の二段階に分かれているからです。

大まかには次の流れです。

• データソースを定義して、外部データをステージングテーブルへロードする
• Transform mapで、ステージングの各行をターゲットテーブルへ変換する
• 実行結果は、Import Setの実行履歴やログに残るので、そこから原因を詰める

この「どの段階で止まっているか」を切り分けられると、解決が一気に早くなります。ServiceNow公式でも、Import Setはデータソース・変換・実行履歴という観点で整理されています。

この記事では、実務で迷いがちな順番に沿って、確認する場所と見方をまとめます。CSA学習の観点でも、暗記というより「なぜそこを見るのか」が理解できるように書きます。

---

データがステージングに入っているか

「反映されない」と聞くとTransform Mapを疑いがちですが、最初にやるべきは そもそもステージングに行が入っているか の確認です。ここが空だと、その先は何を直しても反映されません。

データソースの設定をざっくり疑うポイント

データソースは「どこからデータを取ってくるか」を定義するレコードです。ファイル、JDBC、LDAPなど、タイプにより入力項目が変わります。ここでありがちなズレは次の通りです。

• 読み込んでいるファイルが古い、別ファイルになっている
• 文字コードや区切り文字の想定違いで、列がうまく分割されていない
• ヘッダ行の扱いがズレて、列名が意図しない形で入っている

この段階の違和感は、ステージングテーブル側の列名を見ればだいたい気づけます。Import Setの列は、入力データから自動生成される前提で、手で列を足すのは推奨されません。必要な列があるなら、入力データ側に列を追加してロードで自動生成させる、というのが公式の考え方です。

ステージングテーブルの行数と中身を見る

確認のコツは「件数」だけで終わらせないことです。

• 行数は増えているか
• 代表的な数行を開いて、期待した値が入っているか
• nullだらけ、列名が崩れている、型が怪しい、といった違和感がないか

公式にも、Import Setの用語として「Import Set tableはステージングであり、変換時にターゲットへコピーされる」と説明されています。つまり、ステージングの時点で値が正しくないなら、その後の変換で正しくなる可能性は低いです。

---

変換が走っているか Transform Mapの見直し順

ステージングに行が入っているのに反映されない場合、次は「変換が実行されているか」「変換のルールが意図通りか」を見ます。

Transform mapが紐づいているか

Import Setでターゲットに入れるには、基本的にTransform mapが必要です。公式でも「本番テーブルへのインポートにはTransform mapが必要」という整理になっています。

ここでの落とし穴は、次のような状態です。

• Transform mapが存在するが、別のステージングテーブル向けになっている
• 期待しているTransform mapではなく、別のmapが動いている
• 同じソースとターゲットの組み合わせで複数のmapが有効になっていて、結果が読みづらい

フィールドマッピングで起きやすいズレ

Transform mapの中心はフィールドマップです。よくある“反映されない”は、実は「マップされていない」だけだった、というパターンです。

• ステージング側の列名が想定と違い、マップが無効になっている
• automap任せで、重要な列だけ漏れている
• 参照フィールドの扱いで、表示値を入れたつもりがマッチしていない

Coalesceの考え方がズレると 更新されない もしくは増え続ける

「更新したいのに新規が増える」「更新されるはずが更新されない」は、Coalesceの理解が分かれ目になります。

Coalesceは、変換時に「同じキーのレコードがあるなら更新する」という仕組みです。公式の定義でも、Coalesceを選ぶとターゲット側に同じ値のレコードがあるかチェックして、あれば更新する、という説明です。

実務での確認順はこんな感じです。

• Coalesceに使っているフィールドが、本当に一意になっているか
• 入力データ側にそのキーが必ず入っているか（空だと更新条件にならない）
• 複数フィールドでCoalesceしている場合、すべて一致が前提になっていないか
• 条件付きCoalesceのスクリプトを書いているなら、意図通りの検索になっているか

条件付きCoalesceでは、dot-walkを使った照合例や、OR条件でどちらか一致でも良い、という考え方も公式に載っています。実務で「メールかユーザー名のどちらかで一致させたい」など、ありがちな要件に効きます。

変換スクリプトが原因で無言でスキップしていることもある

onBeforeなどで「この行は無視する」と判断していると、件数的には処理されているのに結果が出ないことがあります。こういう時に効くのが、変換イベントスクリプトでログを出す考え方です。

公式の変換イベントスクリプトでは、log.info() log.warn() log.error() のように、現在のインポート実行のログに出せることが説明されています。無言でスキップしているのか、条件分岐で弾いているのかを“見える化”しやすいです。

---

Transform HistoryとImport Logの読み方

ここまでで「怪しい場所」は絞れますが、最後はログと履歴で確定させます。感覚で直すより、履歴が示す事実に沿って直す ほうが早いです。

Import Set Runsで そもそも完了しているかを見る

Importの実行結果は、Import Set側の履歴で確認できます。公式のImport run detailsでは、実行のStateとして Complete、Complete with errors、Running などが整理され、Inserted/Updated/Ignored/Skipped/Errors のような内訳も確認できるとされています。

ここが最初の分岐点です。

• CompleteでInsertedもUpdatedも0：変換自体は完了したが、実質的に反映がない
• Complete with errors：原因がログや行エラーに残っている可能性が高い
• Runningのまま：大量データやスクリプトで詰まっているか、並列実行の監視が必要

Import Set Rowsで 行ごとの状態を見る

「全体では成功っぽいけど反映されていない」は、行単位で見ると一発で分かることが多いです。

• 特定の行だけエラーになっている
• ターゲットレコードが空で、更新対象が見つかっていない
• エラー詳細に、参照解決失敗や必須項目不足が出ている

公式でも、Import Set Rowsのタブで行の状態やエラー詳細を確認できることが説明されています。

Transform HistoryとImport Logで 何が起きたかを追跡する

Import Logは、インポートの内部処理について“やや冗長に”情報を残すログとして説明されています。そして「より詳細に見るならTransform Historyへ」という導線も公式に明記されています。

ここで見たいのは、次の3点です。

• 変換が走ったかどうか
• どのTransform mapが使われたか
• 何が原因でエラー、無視、スキップになったか

特に、処理件数の内訳（Ignored/Skipped/Errors）を見ながら、「これは仕様で無視されたのか」「内部問題でスキップされたのか」を分けて考えると、打ち手が変わります。

---

詰まりどころを減らす設計へ

最後に、反映トラブルを減らすための“設計と運用”の話です。ここはCSAの学習にも効きます。なぜなら、機能名を覚えるより「こういう時はどのテーブルと履歴を見る」という筋道が身につくからです。

Coalesceは 一意性とインデックスが鍵になる

Coalesceは便利ですが、キーが一意でないと更新事故や重複が起きます。さらに、性能面でもCoalesceフィールドの扱いが重要で、公式のベストプラクティスでは「可能なら一意で既にインデックスされているフィールドでCoalesceする」考え方が示されています。

現場的には、次を意識するとトラブルが減ります。

• “業務キー”が一意かを、取り込み前に関係者と握る
• Coalesce対象の入力が空になり得るなら、空の時の挙動を決める
• 参照解決が絡むなら、先に参照先マスタを入れる順序にする

Import Set APIを使う場合は 返却結果を味方にする

RESTで流し込んでいる場合、「成功しました」だけで終わらせないのがコツです。Import Set APIは、変換が同期で動き、どのTransform mapで、どのターゲットに、inserted/updatedになったかをレスポンスに含められる形で説明されています。取り込み側のログ設計をするときに、この情報はかなり使えます。

ログが薄いなら 変換スクリプトのログ設計をする

「原因が分からない」を減らすには、ログを出す場所を決めるのが早いです。変換イベントスクリプトでは、import_set、source、targetなどのコンテキストと、logオブジェクトが使えることが説明されています。要点は、どの条件で無視したのか をメッセージに残すことです。

体系的に学ぶなら Udemyを併用すると理解が早い

Import Setは、画面操作だけ覚えると必ずどこかで詰まります。おすすめは、次の順序で理解することです。

• データソース → ステージング → 変換 → 履歴とログ、という流れを一度手で追う
• Coalesceや参照更新のような“挙動が変わるポイント”だけ深掘る
• ログとTransform Historyから原因を言語化する練習をする

この手の「一連の流れを通しで触る」学び方は、UdemyのServiceNow講座のように、手順と画面をセットで追える教材と相性が良いです。ひとつの例として、CSA学習者向けに“Import SetとTransform mapの基本から、ログの見方まで”を扱う講座を選んで併用すると、理解が安定しやすいと思います。

---

まとめ

Import Setでデータが反映されない時は、いきなりTransform mapをいじるより、段階で切り分ける ほうが早く、安全です。

• まず、ステージングに行が入っているか。列名や値が崩れていないか
• 次に、Transform mapが正しく紐づき、フィールドマップとCoalesceが意図通りか
• そして、Import Set Runsや行単位の状態、Transform HistoryとImport Logで事実を確認する
• 再発防止として、Coalesceのキー設計、ログ設計、取り込み手段に応じた監視を整える

この順番が身につくと、「反映されない」が起きても焦らなくなります。CSA対策としても、暗記ではなく“仕組みと確認の筋道”として整理できるので、理解が一段深くなります。