インポートのログと行の一生：結果とエラーはどこに残るか
インポート・連携シリーズの7本目です。ここまで、取り込みの入口から変換までを見てきました。では、取り込みを実行したあと、「うまくいったか」「どこで失敗したか」はどこに残るのか。今回は、取り込みの結果とエラーがどこに記録されるかを実機で読み解きます。
先に正直に書いておくと、今回の PDI では実際の取り込みが走っていません（前回まで触れたとおり、生データ行は0件でした）。ですので、扱えるのは「結果がどう記録される仕組みか」という構造まで。実際のエラー行の中身は検証範囲外とします。ただ、その仕組み自体は、フィールドと状態の一覧としてしっかり読めます。
取り込みと連携の全体像は ServiceNowのデータ連携 全体地図 にまとめています。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・フィールド・状態はすべて REST と実画面で確認しました（確認日 2026-07-13）。本番環境では設定が異なります。
結果は2か所に残る
取り込みの結果は、大きく2か所に記録されます。
import_log（運用ログ）… 「いつ、何が起きたか」を時系列で残す
sys_import_set_row（生データ行）… 1行ごとに「その行がどうなったか」を残す
前者は取り込み全体のできごとを俯瞰する記録、後者は1行1行の顛末を細かく残す記録です。全体を眺めたいなら import_log、特定のデータがどうなったか追いたいなら生データ行、と使い分けます。
この2つが分かれているのには理由があります。取り込みは、1回の実行で何千、何万という行を扱います。その全部を1つのログにだらだら書くと、読めたものではありません。そこで、全体の要約や重要なできごとは import_log にまとめ、1行ごとの細かい顛末はその行自身（sys_import_set_row）に持たせる、と役割を分けています。ログは「木を見る前に森を見る」ため、行は「特定の木を詳しく見る」ため。調べたい粒度に応じて、どちらを開くかを選べる作りになっています。この分担を知っておくと、ログを闇雲に全部読まずに済みます。まず森（ログ）で当たりをつけ、怪しい木（行）だけを詳しく見る。この順で効率よく調べられます。
import_log：運用ログ
まず import_log です。実測で117件ありました。
列は Created（日時）、Level、Message、Source。①の記事でも触れたとおり、この環境の Message は「Cleaning import sets > 7 days old」など、7日を超えた古いインポートセットの自動削除の記録ばかりでした。Source 列も、すべて「Cleanup」になっています。実際の取り込みが走っていないので、取り込みそのもののログは残っていません。ですが、フィールドの作りは読めます。ちなみに Source 列は「このログがどの処理から出たか」を示すので、取り込みを実行すれば、ここに取り込み由来のログが Cleanup 以外の値で並ぶことになります。
import_log のテーブル定義には、関連レコードへのリンク項目があります。Import set（どの取り込みか）、Import set row（どの行か）、Run history（どの実行か）です。だから本来は、取り込みを実行すると、この import_log に「何件処理した」「この行でこういうエラーが出た」といった記録が、対象へのリンク付きで残ります。ログから、問題の起きた取り込みや行へ、直接たどれる作りです。
Level（重要度）の列があるのも大事な点です。Information（情報）だけでなく、Warning（警告）や Error（エラー）といったレベルで記録されるので、「エラーだけを絞り込んで見る」ことができる。大量の取り込みを回していると、ログも膨大になります。そのとき Level で Error だけを抽出できれば、問題のある取り込みにすぐたどり着ける。今回の環境はクリーンアップの Information しか無いので絞り込む意味はありませんが、実運用では、この Level が調査の起点になります。運用ログは「全部読む」ものというより、「レベルで絞って必要なところだけ読む」ものです。
行の一生：sys_import_set_row の State
もう1つの記録場所が、生データ行そのものです。前回まで見てきた sys_import_set_row（ステージングの1行）は、ただのデータではなく、「その行がどうなったか」の状態も持っています。
その状態の一覧が、これです。
1行が取りうる状態（sys_import_state）は10種類ありました。取り込みの流れに沿って読むと、こうなります。
Pending … まだ処理されていない（取り込んだだけ）
Inserted … 新規レコードとして作られた（coalesce が一致しなかった）
Updated … 既存レコードが更新された（coalesce が一致した）
Skipped / Ignored … 取り込まれなかった（ignore=true など）
Error … 変換に失敗した
つまり、取り込んだ行は最初 Pending で、変換されると Inserted / Updated / Skipped / Ignored / Error のどれかに落ち着きます。ここまでの記事で見てきた仕組みが、この状態にそのまま表れています。coalesce が一致すれば Updated、しなければ Inserted。前回の変換スクリプトで ignore = true を立てれば Ignored。マッピングでこけたら Error。行の状態を見れば、その行がどの経路をたどったかが分かります。
図にすると、行の一生はこう枝分かれします。Pending で待機し、変換を通ると、結果に応じて4つの終着点のどれかへ。この枝分かれの分岐点こそ、coalesce（一致で Updated / 不一致で Inserted）や、変換スクリプトの ignore（Ignored）、変換の成否（Error）でした。前回までに1つずつ見てきた仕組みが、この状態遷移の分岐として1枚に集約されている、と捉えると、シリーズ全体がつながって見えてきます。
行が持つ結果の情報
状態のほかに、生データ行は結果に関する情報を持っています。テーブル定義で確認しました。
State（sys_import_state）… 上で見た10状態
Error（sys_row_error）… エラーが起きたときの内容
Target record / Target table（sys_target_sys_id / sys_target_table）… その行から作られた本番レコードへのリンク
Transform Map … 適用された変換マップ
この Target record が便利です。「取り込んだこの行が、本番のどのレコードになったか」を、リンクで直接たどれます。逆に、Error に何か入っていれば、その行は変換で失敗した、ということです。1行ごとに、State（どうなったか）・Error（なぜ失敗したか）・Target（何を作ったか）がそろって残る。だから、取り込み後の検証は、この生データ行を見るのが基本になります。
もう1つ、Transform Map の項目も見逃せません。これは「その行に、どの変換マップが適用されたか」を示すもの。1つのステージングに複数の変換マップがぶら下がっている場合（②で触れました）、行がどのマップで処理されたかが、ここで分かります。複数のマップが絡む取り込みで「思ったのと違うテーブルに入った」というときは、この Transform Map を見れば、どのマップが動いたのかを特定できる。State・Error・Target・Transform Map。この4つがそろえば、1行の顛末は、ほぼ完全に再現できます。取り込みが「ブラックボックス」にならず、1行ずつ追える。この透明性が、外部データを扱う機能に求められる信頼性の土台になっています。
Inserted と Updated を見れば coalesce が分かる
行の状態は、これまでの記事の答え合わせにも使えます。とくに Inserted と Updated の2つです。
取り込みを実行したあと、行の State を見ます。Inserted ばかりなら「coalesce が効いていない（または初回で全部が新規）」。Updated が多いなら「既存レコードと突合できている」と読めます。もし毎回 Inserted ばかりで、本番にデータが増え続けているなら、③で見た coalesce の付け忘れを疑うべきです。逆に Updated が並んでいれば、突合キーが正しく効いている証拠です。つまり、行の状態は、coalesce の設定が意図どおり動いているかを事後に確かめる、いちばん確実な手がかりになります。設定を見るだけでは「たぶん大丈夫」までしか言えませんが、実行後の状態を見れば「確かに Updated になっている」と断言できます。取り込みを設計したら、テスト実行して、この State で答え合わせをする。これが確実な進め方です。
この環境で行が0件な理由
念のため、生データ行の一覧も見ておきます。
予想どおり、レコードはありませんでした。「No records to display」と表示されます。理由は2つ考えられます。1つは、この PDI で実際の取り込みが実行されていないこと。もう1つは、前回触れた「7日を超えた古いインポートセットの自動削除」で、過去の行が消えていることです。生データ行は一時的なもので、いつまでも残るわけではありません。だから、取り込み直後にしか、この行は見られません。取り込みの検証は、実行してから7日以内に行います。今回はこの一覧が空なので、実際のエラー行の中身は検証範囲外とし、状態とフィールドの構造まで確認するにとどめます。
Target record で本番へたどる
生データ行が持つ Target record は、実務でとくに役立つ項目です。これは「この取り込み行が、本番のどのレコードになったか」を指すリンクです。
たとえば、CSV で取り込んだ100人のユーザーのうち、特定の1人が正しく入ったかを確かめたいとします。その人の生データ行を開き、Target record のリンクをたどれば、実際に作られた（または更新された）sys_user のレコードに一足でたどり着けます。「取り込んだデータ」と「できあがった本番レコード」が、リンクで直結しているわけです。これで、取り込みの検証は一手で済みます。もしこのリンクが無ければ、名前やメールで本番テーブルを検索して探すことになりますが、Target record があれば、その手間が要りません。逆方向にも意味があり、本番レコードから「どの取り込みで作られたか」を追える場合もあります。取り込みと本番が双方向でつながっていることが、後々の監査やトラブル調査で効いてきます。データの出所をたどれる、というのは、地味ですが信頼性の高いシステムの条件です。
トラブルのときの追い方
構造が分かると、トラブル時の追い方も見えてきます。取り込みで「入ったはずのデータが無い」となったら、順番はこうです。
まず生データ行（sys_import_set_row）を開き、その行の State を見ます。Error なら変換で失敗、Skipped / Ignored なら意図的に飛ばされた、Pending ならまだ処理されていない、と原因の方向が分かります。Error なら Error 欄に理由が入っているので、それを読む。Inserted / Updated なのに本番に見当たらないなら、Target record のリンクをたどって、作られたレコードを確認します。全体の流れを俯瞰したいときは import_log を見る。この「行の State から入る」切り分けが、取り込みトラブルの定石です。状態という1つの列が、原因究明の入口になっています。
よくある相談を、この地図に当てはめてみます。「取り込んだのに反映されない」という声のうち、実際に多いのは Ignored や Skipped、つまり「意図せず飛ばされていた」ケースです。前回の変換スクリプトで ignore=true が立っていた、あるいは coalesce 条件に合わず作成条件から外れていた、といった理由です。State を見れば、これらは Error とは別物だと一目で分かります。「失敗」ではなく「あえて飛ばされた」なら、直すべきは取り込みの仕組みではなく、飛ばす条件のほうです。逆に State が Error なら、Error 欄に理由が入っています。必須項目が空・参照先が見つからない、といった内容を読んで、データか変換マップを直します。State という1列が、「どこを直すか」まで教えてくれる。だから、取り込みトラブルは、まず State を確認する。この習慣が、遠回りを防ぎます。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
運用ログ … import_log_list.do
生データ行 … sys_import_set_row_list.do
行の State 一覧 … sys_choice_list.do?sysparm_query=name=sys_import_set_row^element=sys_import_state
まとめ
取り込みの結果は、import_log（全体の運用ログ）と sys_import_set_row（1行ごとの顛末）の2か所に残る仕組みでした。行は Pending から始まり、Inserted / Updated / Skipped / Ignored / Error のどれかに落ち着きます。1行ごとに、State・Error・Target がそろって残るので、取り込み後の検証や原因究明は、この行から入るのが基本です。
今回の PDI は実行データが0件だったので、扱えたのは構造まで。ですが、この状態とフィールドの地図を持っておけば、実際に取り込みを走らせたとき、どこを見ればよいかで迷いません。
ここまでの7本で、取り込みの一巡が見えてきました。データソースで取り込み、ステージングに受け、変換マップで移す。coalesce で重複を防ぎ、スクリプトで整え、スケジュールで自動化する。そして今回、その結果を State とログで確認しました。取り込みは、単発の操作というより、こうした部品の連なりでできています。そして、その連なりの最後に「結果を確かめる」場所がちゃんと用意されている。作りっぱなしにせず、1行ごとの顛末まで追える。この確認の仕組みがあるからこそ、外部データの取り込みを安心して自動化に載せられます。地味な機能ですが、取り込みの信頼性はこの確認の仕組みが支えています。
次回からは、取り込みの隣にある「連携」の領域へ進みます。まずは、ノーコードで外部システムとつなぐ IntegrationHub を見ていきます。
その他、実機で確認した記録
用語
import_log … 取り込みの運用ログ。全体のできごとを時系列で残す
sys_import_set_row … ステージングの1行。結果（State / Error / Target）も持つ
sys_import_state … 行の状態（Pending / Inserted / Updated / Skipped / Ignored / Error ほか）
Target record … その行から作られた本番レコードへのリンク
Error（sys_row_error） … 行の変換が失敗したときの内容
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/import_log_list.do（運用ログ117件）
/sys_import_set_row_list.do（生データ行・状態とエラー）
/sys_choice_list.do?sysparm_query=name=sys_import_set_row^element=sys_import_state（行の状態10種）
実測の要点（再掲）
結果の記録は2か所: import_log（117・この環境はクリーンアップ記録のみ）と sys_import_set_row（0件）
行の状態は10種: Pending / Inserted / Updated / Skipped / Ignored / Error / Ignore / Test / Processed / Transform
行は State / Error / Target record / Target table / Transform Map を持つ
coalesce 一致=Updated、不一致=Inserted、ignore=true=Ignored、と前回までの仕組みが状態に表れる
検証範囲とおことわり
この記事の件数・状態一覧・フィールドは、PDI（Zurich / OOTB）の実測です。
実インポートが0件のため、実際のエラー行の内容や Inserted / Updated 等の実データは未確認（検証範囲外）です。構造（フィールド・状態）のみ確認しています。
生データ行は7日超で自動削除されるため、取り込み直後にしか確認できません。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
