インポートの3段構造：データソース→ステージング→ターゲット
CSV や外部DBのデータを ServiceNow に取り込むとき、データは3つの段を通ります。この3段さえ掴めば、インポート機能の全体像は一気に見通せます。この記事は、その骨格を実機のテーブルから読み解く、インポート・連携シリーズの1本目です。
3段とは、データソース（取り込み口）→ ステージング（生データの置き場）→ ターゲット（本来のテーブル）。間を橋渡しするのが「変換マップ」です。順番に、実機で確かめていきます。
このシリーズのまとめ：取り込みと連携の全体像は ServiceNowのデータ連携 全体地図 にまとめています。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・状態はすべて REST で取得しました（確認日 2026-07-13）。本番環境やカスタマイズ済み環境では設定が異なります。
なぜ3段に分けるのか
いきなり外部データを本番テーブル（sys_user など）に流し込まないのには理由があります。外部の CSV は、列名がバラバラだったり、余計な空白が入っていたり、重複があったりする。それをそのまま本番に入れると、データが壊れてしまいます。
そこで ServiceNow は、間にステージング（一時置き場）を挟みます。まず外部データをステージングにそっくり受け取り、そこで中身を確認してから、変換マップのルールに沿って本番テーブルへ移す。この2段構えにすることで、「取り込み」と「変換」を分けて扱えるようになります。取り込みで失敗しても本番は汚れず、変換のルールだけを何度でも調整できる。公式ドキュメントでも、インポートセットは「ステージングテーブル＋変換ロジック」と説明されています。
この分離は、実務で効いてくる場面が多いのです。たとえば、取り込んだ結果が思ったのと違ったとき。もし直接本番に入れていたら、間違ったデータを1件ずつ手で直すことになります。ステージングを挟んでいれば、本番はそのまま、変換マップの対応づけだけを直して、もう一度変換を流せばよい。取り込み元のデータには手を触れず、「移し方」だけをやり直せるわけです。もう1つ、同じステージングを使い回せる利点もあります。毎朝同じ形式の CSV が届くなら、データソースとステージングは固定のまま、中身だけ入れ替えて変換を繰り返せます。1回きりの移行にも、毎日の定期取り込みにも、同じ3段が使えるのはこの構造のおかげです。
① データソース：取り込み口
最初の段は「どこから、どんな形式で取り込むか」を決めるデータソース（sys_data_source）です。実測で17件ありました。
一覧は Name / Type / Format / Updated の列でできています。「Example CSV Test Users on Path（File / CSV）」「Example CSV FTP test（File / CSV）」「Example JDBC MySQL Glide.sys_user（JDBC / MySQL）」「ADFS Example（OIDC）」といったサンプルが並び、Type と Format の組み合わせで取り込み方が一目で分かります。種類（type）の内訳はこうでした。
File が8件でいちばん多く、外部IdP連携用の OIDC が5件、データベース直結の JDBC が2件、ディレクトリ連携の LDAP が2件。File の中でも、取得方法（file_retrieval_method）は Attachment（手で添付）、FTP、FTPS、HTTP、SCP とバリエーションがあります。形式（format）も CSV、タブ区切り CSV、Excel、そして JDBC 側は MySQL や Oracle のドライバ指定まで。OOTB のサンプルだけで、代表的な取り込みパターンがひととおり揃っています。
取り込めるファイルの拡張子は無制限ではありません。プロパティ glide.import.file.extension_whitelist を実測すると csv,xls,xlsx,json,xml,zip,txt に限定されていました。想定外の形式を弾く、地味だが大事な安全弁です。実行ファイルや未知の形式を誤って取り込ませない、という発想です。
データソースで押さえておきたいのは、この1レコードが「取り込み方の設計図」だということです。同じ CSV でも、FTP から取るのか、手で添付するのか、HTTP で取りに行くのかは、このレコードのフィールド1つで切り替わります。取り込み元のシステムが変わっても、データソースを1件用意すれば、後段のステージングと変換マップはそのまま使い回せます。取り込み口と変換ルールが分離しているからこその柔軟さです。
② ステージング：imp_* の生データ置き場
2つめの段がステージングテーブルです。名前は imp_ で始まり、すべて sys_import_set_row というテーブルを継承しています。OOTB では imp_user、imp_location、imp_computer、imp_notification などが用意されていました。
上は imp_user の項目定義です。user_id、email、first_name、last_name…と、取り込み元 CSV の列に対応した項目が並びます。ここに入るのは加工前の生データです。まだ sys_user ではありません。あくまで「一時的に受け取っただけ」の状態です。
生データ1行は sys_import_set_row の1レコードになります。この行は、ただのデータではなく、取り込みの状態も記録します。主なフィールドはこうです。
sys_import_state … その行が「未処理／取込済／エラー」のどれか
sys_row_error … 行でエラーが起きたときの内容
sys_target_table / sys_target_sys_id … 変換で作られた本番レコードへのリンク
つまり1行ごとに「どうなったか」が残ります。あとで「あのデータはちゃんと入ったか」を追えるのは、この仕組みのおかげです。
ステージングテーブルが全部 imp_ で始まり、sys_import_set_row を継承しているのには意味があります。継承しているおかげで、どの imp_* テーブルにも、先ほどの状態フィールド（sys_import_state や sys_row_error）が最初から備わっています。取り込み先が imp_user でも imp_location でも、行の状態を同じやり方で追える。共通の親を持たせることで、取り込みの管理を一元化しているわけです。新しい取り込み用のステージングを作るときも、この親を継承すれば、状態管理の仕組みはただで手に入ります。これは ServiceNow のテーブル設計でよく見る「共通の親テーブルに仕組みを持たせ、子が引き継ぐ」パターンそのものです。
③ 変換マップ：ステージングとターゲットの橋渡し
3段を貫くいちばん重要な部品が変換マップ（sys_transform_map）です。「ステージングのどの列を、本番テーブルのどの項目に入れるか」を決めます。実測で14件、すべて active でした。
この一覧が3段構造をそのまま表しています。Source table（ステージング）と Target table（本番）の列を見てください。
User: imp_user → sys_user
Location: imp_location → cmn_location
Computer: imp_computer → cmdb_ci_computer
Notification: imp_notification → incident
LDAP / OIDC 各種: ldap_import・oidc_*_import → sys_user
たとえば User マップは、imp_user に受け取った生データを sys_user（ユーザー本番テーブル）へ移します。Notification マップは、外部の通知データを incident（インシデント）に変換します。左から右へ、ステージングからターゲットへ。この矢印が、インポートの本体です。
一覧の「Run business rules」列に注目してください。実測では14件すべて true でした。これは、変換で本番テーブルにレコードを作るとき、そのテーブルに設定された業務ルール（Business Rule）も一緒に走るという意味です。たとえば sys_user に新規ユーザーができれば、それに紐づく通知やデフォルト値の設定も発火します。単なるデータコピーではなく、「正規の入口からレコードを作る」動きになっている、というのが大事な点です。もし業務ルールを走らせたくない大量投入なら、この列を false にする、という判断もできます。
「Order（順序）」列は全件100でした。1つのステージングに複数の変換マップをぶら下げることもでき、その場合はこの順序で実行されます。1つのデータソースから、複数の本番テーブルへ枝分かれさせる、といった構成もこの仕組みで表現できます。取り込みは1本道に見えて、後段は柔軟に分岐できるわけです。
具体例：ユーザーCSVを取り込む流れ
3段を、1つの具体例で通してみます。「社員100人分のユーザー情報が入った CSV を、sys_user に取り込みたい」という場面です。
まず、データソースに CSV を設定します。形式は CSV、取得方法は Attachment（ファイルを手で添付）。ここで「取り込み口」が決まります。次に、その CSV を読み込むと、1行1レコードで imp_user（ステージング）に着地します。この時点では、まだ sys_user には1件も入っていません。CSV の中身が、そっくりそのまま imp_user に並んでいるだけです。
ここが確認のポイントです。imp_user を開けば、取り込んだ生データを目で見られます。「メールアドレスが空の行はないか」「部署名の表記は揃っているか」を、本番を汚さずにチェックできる。問題がなければ、User 変換マップを実行します。マップは imp_user の各列を sys_user の項目に対応づけ、100件を sys_user へ移す。もし途中でエラーが出た行は、本番には入らず、ステージング行にエラーが記録されて残ります。
この「一度受け止めてから、確認して、変換する」という流れが、インポートの基本動作です。CSV でも Excel でも、外部DBでも、通る道は同じ3段です。取り込み元が変わっても、ステージングと変換マップの考え方は変わりません。だから最初にこの3段を押さえておくと、どんな取り込みにも応用が利きます。
生データ行はどこにあるのか
ここまでの登場人物を、実行時のレコードで結びます。実際に取り込みを走らせると、sys_import_set（実行1回ぶん）と、その下に sys_import_set_row（生データ行）ができます。
今回の PDI では、この2つがどちらも0件でした。理由は次の「クリーンアップ」で触れますが、実インポートが走っていない、あるいは古い履歴が消えているためです。ですのでこの記事で扱えるのは、器（テーブル・マップ・データソースの定義）まで。実際の取り込み結果（行の状態遷移やエラーの実例）は検証範囲外とします。定義がすべて OOTB で揃っているので、構造を読むには十分でした。
なお sys_import_set（実行1回ぶん）には、state（実行状態）や mode、対象テーブルといったフィールドがあります。取り込みを実行するたびに1件できて、その下に生データ行がぶら下がる親子構造です。0件なのは「まだ誰も取り込みを実行していない、または7日で消えた」というだけで、テーブル自体はいつでも受け入れ可能な状態でした。
ログと自動クリーンアップ
インポートの運用ログは import_log に残ります（名前が紛らわしいのですが、sys_import_log というテーブルは存在しません）。実測で117件ありました。
一覧は Created（日時）、Level、Message、Source の列でできています。Level はすべて Information、Source は「Cleanup」。Message を見ると、「Cleaning import sets > 7 days old」と「Cleaning the sys_execution_context and sys_import_set_execution tables」の2種類が、毎日決まった時刻に並んでいました。これは、7日を超えた古いインポートセットを ServiceNow が自動で削除している記録です。先ほど sys_import_set が0件だったのは、これが理由でした。ステージングは一時置き場なので、放っておくとデータが溜まり続けます。それを定期的に片付ける仕組みが、標準で動いているわけです。逆に言えば、取り込み直後の生データを確認したいなら、7日以内に見ておく必要があります。
この自動クリーンアップは、運用上けっこう重要です。ステージングのデータは、変換が終われば本番テーブルに移っているので、原則もう不要になります。とはいえ何万件ものインポートを繰り返すと、ステージングと生データ行がどんどん膨らみます。放置すればストレージを圧迫し、パフォーマンスにも響く。そこで7日という区切りで古いものを消し、インスタンスを軽く保っているわけです。ログにこの掃除の記録が残っているということは、裏で定期ジョブが淡々と動いている証拠でもあります。トラブル時に「昨日取り込んだはずのデータが見当たらない」となったら、まずこのクリーンアップのタイミングを疑う、という勘所も覚えておくと役に立ちます。
3段を1枚で
最後に、ここまでの流れを図にします。
外部データが、データソースの設定に従って取り込まれ、imp_* ステージングに生データとして着地する。変換マップが、その生データを本番テーブルの形に整えて移す。移した先の行へのリンクは、ステージング行に残る。この一本道さえ頭にあれば、あとの回で見る「変換マップの中身」「coalesce」「データソースの種類」も、どの段の話かがすぐ分かります。
この3段は、覚え方も単純です。入口（データソース）・仮置き（ステージング）・本番（ターゲット）、そして仮置きから本番への運び方（変換マップ）。この4語だけで、インポートの登場人物はほぼ出そろいます。トラブルが起きたときも、この地図の上で「どの段でつまずいたか」を切り分ければ、原因にたどり着きやすい。取り込めていないなら入口かステージング、変換で落ちるなら変換マップ、というふうに、段ごとに見る場所が決まっているからです。次回以降は、この地図の各所を1つずつ拡大していきます。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
データソース … sys_data_source_list.do
変換マップ … sys_transform_map_list.do
インポートセット（実行単位）… sys_import_set_list.do
生データ行 … sys_import_set_row_list.do
ステージング例 … imp_user_list.do
ログ … import_log_list.do
まとめ
インポートは、**データソース → ステージング（imp_*）→ 変換マップ → ターゲット**の3段構造でした。間に一時置き場を挟むことで、取り込みと変換を分けて安全に扱えます。今回の PDI では実行データこそ0件でしたが、変換マップ14・データソース17という器はすべて OOTB で揃っており、構造は余さず読めました。
このシリーズでは、この3段の各所を1本ずつ掘り下げていく予定です。次回は3段の要である変換マップの中身（どの列をどう対応づけ、どんなオプションがあるか）を、1レコード開いて詳しく見ていきます。そのあと、重複を防ぐ coalesce、データソースの種類、スケジュール実行、変換スクリプトと続き、後半では外部システムとつなぐ REST 連携まで扱う。今回の3段の地図が、そのすべての土台になります。
補足として、この3段を通さない取り込み方も ServiceNow にはあります。管理者が画面から Excel を貼り付ける「Easy Import」や、他インスタンスとつなぐ仕組みなどです。ただしそれらも、内部では結局ステージングと変換マップを使っています。見た目の入口が変わっても、データが通る道は同じ3段。だから、まずこの基本形を押さえることが、どの取り込み方を選ぶときにも効いてきます。細かな UI の違いに惑わされず、「いま自分は3段のどこを触っているのか」を意識できると、迷いが減ります。
その他、実機で確認した記録
用語
インポートセット … 外部データを取り込む仕組み。ステージング＋変換ロジック
データソース（sys_data_source） … どこから・どんな形式で取り込むかの定義
**ステージングテーブル（imp_*）** … 加工前の生データを一時的に受け取る場所
変換マップ（sys_transform_map） … ステージングの列を本番テーブルへ対応づけるルール
ターゲット … 変換後の本番テーブル（sys_user, incident など）
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sys_data_source_list.do（データソース17件）
/sys_transform_map_list.do（変換マップ14件・source→target）
/sys_import_set_row_list.do（生データ行）
/import_log_list.do（運用ログ・7日クリーンアップ）
実測の要点（再掲）
3段: データソース17 → ステージング imp_*（sys_import_set_row 継承）→ 変換マップ14 → ターゲット
データソース type: File 8 / OIDC 5 / JDBC 2 / LDAP 2
取込可能拡張子: csv,xls,xlsx,json,xml,zip,txt（extension_whitelist）
sys_import_set / sys_import_set_row は0件（7日超で自動クリーン）
検証範囲とおことわり
この記事の件数・状態・テーブル継承・フィールド・プロパティ値は、PDI（Zurich / OOTB）の REST 実測です。
sys_import_set / sys_import_set_row は0件のため、実際の取り込み・変換の実行結果（行の状態遷移・エラーの実例）は未確認（検証範囲外）です。
データソースの実接続（FTP / JDBC 先など）は当然この環境では未接続です。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
