Transform Mapは便利だが事故も起きやすい
ServiceNowのImport SetとTransform Mapは、CSV取込や外部連携の入口として定番です。便利な一方で、「重複レコードが大量に増えた」「意図せず別の人のレコードが更新された」「本番でBusiness Ruleが連鎖して通知が飛びまくった」みたいな事故も、だいたいここから始まります。
Zurichでも考え方の芯は同じです。大事なのは、画面上の設定を“なんとなく”で埋めないこと。Transformは内部的に順番通りに処理され、スクリプトも決まったタイミングで動きます。つまり、安全なTransformは、運用を含めた設計で決まるということです。実際、Transform Mapのスクリプト実行順序は公式KBでも整理されています。
この記事は、CSAを目指す学習者が「暗記」ではなく「仕組み」で理解できるように、実務で混乱しやすいポイントを“設計判断”としてまとめます。Udemyなどの講座で体系的に学ぶ際の補助線にもなるはずです。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
安全設計の全体像 まず決めるべき前提
Transform Mapを作る前に、最低限ここを決めると事故が減ります。
何を正とするかを決める
例として「社員マスタを取り込んでsys_userを更新する」ケースを考えます。
- 外部が正：社員番号やメールが外部のマスタで確定していて、ServiceNowは追従する
- ServiceNowが正：ServiceNow側での運用変更を優先し、外部は参考情報
この前提が曖昧だと、Coalesceのキー選びも、空値の扱いもブレます。
InsertとUpdateの境界を言語化する
Transform Mapは、Coalesceなどの一致条件で「更新するか、新規作成するか」を分けます。ここが曖昧だと、重複か誤更新が起きます。Transformの処理では、まずCoalesce評価でターゲットレコードを探す流れが明確に示されています。
変換は同期か非同期かを決める
特にAPIや外部連携では重要です。同期のImport Setは「行が入ったらすぐTransform」になりやすい一方、非同期にすると“ためてから実行”ができ、運用が安定します。Zurichの公式ドキュメントでも、Synchronousは挿入後すぐ変換し、既定で深夜にProcessedへ変更されることが説明されています。
Coalesceで事故を防ぐ ユニーク性と性能の両立
Coalesceは、Transform Map安全設計の中心です。結論から言うと、人間が見て分かりやすい値より、システム的に一意なキーを優先します。
悪い例と良い例
- 悪い例：氏名、部署名、CI名など「被り得る」ものをCoalesceにする
- 良い例：社員番号、外部ID、メールアドレスなど「一意で変わりにくい」ものをCoalesceにする
もちろんメールも変更されることがあります。だからこそ「外部IDがあるなら外部ID」「ないならメール＋追加ルール」など、最初に方針を決めます。
Coalesce対象はインデックスを意識する
大量データの取り込みで遅くなる典型がここです。Coalesceで突合するフィールドが無駄にフルスキャンになると、遅いだけでなく、タイムアウトや途中失敗が増えます。SupportのKBでも、Coalesceフィールドとインデックスに関する考慮点が扱われています。
迷ったら外部IDを作る
外部側に一意キーがない場合、連携設計として「一意キーを持たせる」ほうが、長期的に安いです。Transformで頑張って“それっぽい一致”を作ると、運用年数が増えるほど壊れます。
変換スクリプトの安全な使い方 onStart onBefore onAfter onComplete
Transform Mapのスクリプトは強力ですが、強力だから危険です。安全に使うコツは、何をどのタイミングでやるかを固定すること。
まず実行順序を押さえる
ざっくりの流れは次の通りです。
- onStartが走る
- Coalesceの評価でターゲットを決める
- onBeforeが走る
- フィールドマッピングが適用される
- onAfterが走る
- 最後にonCompleteが走る
この順序は公式KBで整理されています。
使える変数を理解する
変換スクリプトでは、sourceやtargetなどの変数が使えます。公式ドキュメントに、代表的な変数と意味がまとまっています。
onBeforeは検証と除外の置き場所
行単位で「このデータは入れていいか」を判断するならonBeforeが基本です。理由はシンプルで、onBeforeは変換前に止められるからです。
公式KBでも、onBeforeでignoreをtrueにして行をスキップできること、そして注意点が示されています。
onAfterは後処理 ただしignoreでも動く
混乱ポイントとして、ignoreした行でもonAfterが動くケースがあります。これは公式KBにも明記されています。
なので、設計としてはこう割り切るのが安全です。
- 行を止めたい、除外したい：onBeforeで判断
- 変換後に整形したい：onAfter
- 件数集計や終了処理：onComplete
onStartとonCompleteは全体制御に使う
onStartは初期化、onCompleteはまとめ処理に向きます。変換イベントスクリプトで使えるlogやignore、errorなども、公式ドキュメントに整理されています。
ここでの“安全設計”のポイントは、onCompleteで重い処理をやりすぎないことです。Transformは基本的に「データを正しく入れる」ための入口。後続の整備はFlowやScheduled Jobなど、影響範囲を切れる仕組みに逃がすのが安定します。
Run business rulesと必須項目の扱い 本番影響を読める設計にする
Transform Mapの事故で多いのが「本番影響を読めていなかった」パターンです。代表がこの2つです。
Run business rulesを有効にするか
Run business rulesを有効にすると、ターゲットテーブルのBusiness Ruleが通常どおり動き得ます。これが良い場合もありますが、通知や更新連鎖、関連テーブル更新が発生して“想定より大きい変更”になりがちです。
SupportのKBでは、Transform Map側でRun Business rulesをオフにできることが案内されています。
判断基準の一例はこんな感じです。
- オフに寄せる：データ移行、初期ロード、大量更新、検証が未成熟
- オンを検討：Business Ruleに「必ず通したい正規化処理」があり、影響範囲も把握できている
CSA学習の観点でも、ここは「機能としてそういうチェックがある」ではなく、なぜ危ないのかが腹落ちすると強いです。
Enforce mandatory fieldsは品質ゲートになる
Transformでは、テーブルの必須項目を必ずしも満たさなくても処理が進むことがあります。そこでTransform Map側のEnforce mandatory fieldsが効いてきます。
開発者向け公式教材で、Enforce mandatory fieldsの意味が説明されています。
設計としては、こう考えるのが安全です。
- 外部データの品質がまだ不安：Enforceを有効にして、足りない行を弾く
- どうしても欠けるが後から埋める運用：Enforceは無効、ただし“欠けたままでも事故らない”設計が必要
弾いた行は「捨てた」ではなく「改善すべき入力が見えた」なので、運用にログとレビューを組み込みます。
テストと運用設計 失敗から復旧できる仕組みを先に作る
安全なTransformは、スクリプトの巧さより検証と復旧の設計で決まります。
小さなデータで段階テストする
いきなり本番サイズを入れない。まずは10行、次に100行、最後に全量。これだけで事故率が激減します。
Transformの実行自体は、Run Transformから実施する手順が公式ドキュメントにあります。
ログを必ず残す
変換イベントスクリプトではlogが使えます。何が起きたかを追えるように、onStartやonCompleteで件数や例外を記録するだけでも、運用がかなり楽になります。
同期と非同期を使い分ける
外部から行が入った瞬間に変換して良いのか、溜めてから手動や定期で変換したいのか。Import SetのModeは挙動に直結します。Zurichの公式ドキュメントにも、Synchronousの挙動が明記されています。
運用としてよく効くのは、
- 日中はLoadingに溜める
- 夜間にまとめてTransformする
- 失敗が出たら翌朝レビューする
みたいな“人間の監視ができるタイミング”に寄せることです。
Udemyで学ぶならここを意識すると伸びる
UdemyのServiceNow講座は、操作手順を通して全体像を掴むのに向いています。見るときは「どの設定が、どの事故を防ぐためなのか」をメモしながら進めると、暗記ではなく理解になります。
- Import SetのModeやRun Transformの流れ
- Coalesceの考え方と設計
- onBeforeとonAfterの役割分担
- Run business rulesや必須項目の影響
この辺りを“手を動かして再現”できる教材を一つ持っておくと、学習も実務も楽になります。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
ZurichでTransform Mapを安全に使うコツは、最新機能の追いかけよりも「設計の型」を持つことです。Transformは、onStartから始まりCoalesceで更新か新規かを判断し、onBeforeとマッピングを経てonAfter、最後にonCompleteで締まるという順序で動きます。だからこそ、行の除外はonBefore、後処理はonAfter、全体制御はonStartとonCompleteといった役割分担を固定すると、事故が減ります。
さらに、Coalesceは一意で変わりにくいキーを選び、性能も見てインデックスを意識することが重要です。Run business rulesやEnforce mandatory fieldsも、正しさと本番影響のトレードオフとして判断し、ログと段階テストで“失敗しても戻れる運用”を先に作ると安定します。
Transform Mapは、理解すればするほど怖さが減っていきます。Udemyなどで体系的に学びながら、今回の設計基準をチェックリストとして持っておくと、CSA学習にも実務にも効いてきます。
