スケジュールインポート：取り込みを毎晩自動で走らせる
インポート・連携シリーズの5本目です。ここまで、取り込みの「口」と「移し方」を見てきました。データソースを用意し、変換マップで移し、coalesce で重複を防ぐ。ただし、そこまでは基本的に「人が実行ボタンを押す」前提でした。
現実の運用では、毎晩決まった時刻に、人事システムのユーザー一覧を自動で取り込みたい、という要望がよくあります。それを担うのが スケジュールインポート（scheduled_import_set）です。データソースの取り込みを、時刻を決めて自動で走らせる仕組みです。今回は、この自動化の設定を実機で読み解きます。
取り込みと連携の全体像は ServiceNowのデータ連携 全体地図 にまとめました。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・設定値はすべて REST と実画面で確認しました（確認日 2026-07-13）。本番環境では設定が異なります。
スケジュールインポートとは
一言でいえば、「どのデータソースを、いつ、自動で取り込むか」を定義するレコードです。手で取り込む場合は、データソースを開いて「Load All Records」を押します。スケジュールインポートは、その実行を時刻で予約するものだ、と捉えると分かりやすいです。
たとえば「毎晩1時に、Active Directory のユーザーを取り込む」と設定すれば、あとは ServiceNow が自動で実行してくれます。人が毎晩ボタンを押す必要はありません。ユーザー情報のように、日々変わり続けるデータを最新に保つには、この自動化が欠かせません。
なぜ自動化がそこまで大切なのか。理由は、手動の取り込みは「忘れる」「担当者が休む」「時間がずれる」といった人の都合に左右されるからです。ユーザーの入退社を反映する取り込みが1日抜ければ、退職者がまだシステムを使える、入社者がまだ登録されていない、といった不整合が生まれます。決まった時刻に機械が淡々と回す。この確実さこそが、スケジュールインポートの価値です。地味な機能ですが、データを「生きた状態」に保つ土台を支えています。手で1回取り込むところまでは誰でもできますが、それを毎日確実に続けるには、この自動化が要る、というわけです。
実機には2件、どちらもサンプル
まず一覧を見ます。実測でスケジュールインポートは2件でした。
「Example LDAP User Import」と「Example LDAP Group Import」。どちらも LDAP（ディレクトリ）連携のサンプルで、Run は Daily（毎日）です。ただし、2件とも Active は false（無効）でした。OOTB では、設定の見本として置いてあるだけで、実際には動いていません。自社で使うときは、これを参考に、自分のデータソース向けのスケジュールを作る、という流れになります。
サンプルが LDAP のユーザーとグループなのは、示唆的です。前回のデータソースの回でも触れたとおり、ユーザー情報の取り込みは、企業システムでもっとも頻繁な取り込みの1つです。人の入退社や異動は毎日のように起きるので、ユーザーを日次で取り込む需要が高い。だから ServiceNow は、スケジュールインポートのサンプルとして、あえてユーザーとグループの日次取り込みを用意しています。「まずはこれを真似して、自社の認証基盤に向けたスケジュールを作ってください」という、実質的な雛形になっているわけです。2件しかないのは寂しく見えますが、いちばん使われるパターンを的確に押さえたサンプル、と読むこともできます。
レコードの設定項目
1件を開いてみます。「Example LDAP User Import」です。
設定はシンプルです。中心にあるのは Data source（Example LDAP Users）。これが「どのデータソースを走らせるか」の指定です。前回まで見てきたデータソースを、ここで指名します。右側の Run は実行タイミングで、この例では Daily（毎日）になっていました。この2つ、「何を」と「いつ」が、スケジュールインポートの核です。
その周りに、細かい制御項目が並びます。
Active … このスケジュールを有効にするか（サンプルは false）
Run as … どのユーザーの権限で実行するか
Concurrent Import … 並行取り込みを許すか。オフなら、前の取り込みが終わるまで次を待つ。重い取り込みが重なって負荷が跳ねるのを防ぐ設定です
Execute pre-import script / post-import script … 取り込み前後にスクリプトを走らせるか
Conditional … 条件を満たしたときだけ実行するか
Run as（実行ユーザー）も見落とせません。スケジュールは人が見ていない夜間に走るので、「誰の権限で実行するか」をここで決めます。取り込み先のテーブルに書き込める権限を持つユーザーを指定しないと、権限不足で失敗します。自動処理だからこそ、実行者の権限を明示しておくのが大事です。
そして画面上部に「Execute Now」というボタンがあります。これは「スケジュールを待たずに、今すぐ1回実行する」ボタンです。設定を作ったあと、動作を確かめるのに使います。
テーブル定義を見ると、これらの設定が scheduled_import_set の列として並んでいます。data_source、run_type、run_time など。ほかに run_dayofweek、active、Concurrent Import もあります。設定画面のチェックボックスやプルダウンは、この列の値を持っているだけです。ここでも「GUIの裏は素直なテーブル」という ServiceNow の一貫した作りが確認できます。
手動と自動を行き来する
スケジュールインポートを理解するうえで押さえておきたいのは、手動実行と自動実行が地続きだという点です。
前回まで見たデータソースには、「Load All Records」という手動実行の操作がありました。人がボタンを押すと、その場で取り込みが走ります。スケジュールインポートの「Execute Now」も、やっていることは同じで、指定したデータソースの取り込みを今すぐ走らせます。違いは、スケジュールインポートには「時刻で自動発火する」機能が加わっている点だけです。
だから運用は、こう進めるのが自然です。まず手動（Load All Records や Execute Now）で取り込みを試し、変換マップや coalesce が期待通りに動くことを確かめる。うまくいったら、Active をオンにして、Run で時刻を決める。すると、翌日からは自動で回り始めます。手動で固めてから自動に載せる、という流れがそのまま使えます。いきなり自動で回して失敗すると原因が分かりにくいので、この「手動で確認 → 自動化」の順序は、実務で守りたい定石です。Execute Now は、その確認のための心強いボタンだと言えます。
Run：実行タイミングの決め方
いちばん大事な Run（実行タイミング）を、もう少し見ます。この項目はプルダウンで、いくつかの頻度から選べます。
Daily を選べば、何時に走らせるかの時刻を指定します。Weekly なら曜日と時刻。取り込みたいデータの更新頻度に合わせて選びます。ユーザー情報のように毎日変わるものは Daily、月次で締める集計なら Monthly、という具合です。実測したレコードのフィールドにも、run_type（daily）や run_time、run_dayofweek といった項目があり、この「いつ走らせるか」を細かく持っていました。
選択肢の中で少し性格が違うのが Once と On Demand です。Once は「1回だけ、指定日時に実行して終わり」。初回の一括移行を予約したいときなどに使えます。On Demand は「自動では発火せず、呼ばれたときだけ実行」。ほかのスクリプトやフローから「このタイミングで取り込んで」と呼び出す、といった連携で使う選択肢です。Daily / Weekly / Monthly が「定期的に自動で回す」ためのものだとすれば、Once と On Demand は「一度きり」「他から呼ぶ」ための特殊な選択肢だ、と整理できます。取り込みをどう回したいかで、この Run の選び方が決まります。
スケジュールジョブ基盤の上に乗る
スケジュールインポートは、単独で時計を持っているわけではありません。ServiceNow のスケジュールジョブ（Scheduled Job）という共通の基盤の上に乗っています。
スケジュールジョブの一覧（sysauto）を見ると、いろいろな「定期的に走るもの」が並んでいます。レポートの定期送信、データのクリーンアップ、各種の定期処理などです。スケジュールインポートも、その仲間の1つです。前回の記事で触れた「7日を超えた古いインポートセットの自動削除」も、この基盤で動いていました。つまり ServiceNow には「決まった時刻に何かを走らせる」共通の仕組みがあり、取り込みの自動化も、その仕組みを借りて実現されている、というわけです。共通基盤に乗っているので、実行のログや失敗時の扱いも、他のスケジュールジョブと同じやり方で追えます。
この「共通基盤に乗る」という作りは、ServiceNow のあちこちで見られます。定期的に何かを走らせたい機能はたくさんありますが、それぞれが独自にタイマーを持つのは無駄です。だから「スケジュールジョブ」という土台を1つ用意し、各機能はそこに相乗りします。スケジュールインポートも、レポートの定期送信も、裏で使っている時計は同じです。この設計のおかげで、「決まった時刻に走るもの」はすべて sysauto の一覧で見渡せます。もし「昨夜の取り込みが走ったか」を確認したいなら、この共通基盤のログを見れば分かる、というわけです。個々の機能を別々に調べなくても、1か所で定期処理の全体を把握できるのは、運用者にとって大きな助けになります。
データソースとの関係
スケジュールインポートと、これまで見てきた部品の関係を確認します。
スケジュールインポートは、データソースの「実行」を予約するものです。データソースが「どこから取るか」を定義し、変換マップが「どう移すか」を定義する。スケジュールインポートは、その取り込みを「いつ走らせるか」を足します。3つが揃って、はじめて「毎晩、外部データを自動で取り込んで、本番テーブルを最新に保つ」という運用が回ります。
スケジュールインポートはデータソースを指名するだけで、取り込みや変換の中身には踏み込みません。だから、データソースや変換マップを先に作り込んでおけば、あとはスケジュールで「いつ走らせるか」を足すだけで自動化が完成します。役割がきれいに分かれているので、手動でうまくいった取り込みを、そのまま自動化に載せられます。
この役割分離は、変更にも強いという利点があります。たとえば、取り込む時刻を夜1時から3時にずらしたいとします。そのとき直すのは、スケジュールインポートの Run の時刻だけです。データソースや変換マップには一切触れません。逆に、取り込み元のファイル形式が変わったら、直すのはデータソースだけで、スケジュールはそのまま。「いつ」「どこから」「どう移すか」が別々のレコードに分かれているので、変えたいところだけをピンポイントで直せます。1つの巨大な設定にすべてを詰め込んでいたら、こうはいきません。小さな部品に分けて、それぞれを組み合わせます。この設計思想が、取り込みまわりを通して一貫しています。
pre/post スクリプトと Conditional
もう少し踏み込んだ制御も用意されています。Execute pre-import script / post-import script は、取り込みの前後に処理を挟むためのものです。たとえば「取り込み前に、古いデータをいったん退避する」「取り込み後に、通知を送る」といった前後処理を、ここで書けます。
Conditional は、条件付き実行です。オンにすると、決めた条件を満たしたときだけ取り込みを走らせます。「前回から一定時間が経っていたら」「特定のフラグが立っていたら」といった判断を挟めます。毎回無条件に走らせるのではなく、必要なときだけ動かしたい、という細かな運用に対応するための設定です。基本は「データソースを、決まった時刻に走らせる」だけですが、こうした前後処理や条件で、実運用に合わせた調整ができるようになっています。
pre / post スクリプトの使いどころを、もう少し具体的に挙げます。pre-import（取り込み前）では、たとえば「取り込む前に、対象テーブルの一時的な無効化を解除する」「前回のステージングを掃除する」といった下準備を書ける。post-import（取り込み後）では、「取り込みが終わったら、担当者にメールで結果を知らせる」「取り込んだ件数を別の記録テーブルに残す」といった後片付けや通知を書けます。取り込み本体は変換マップに任せ、その前後の段取りだけをここで補う、という役割分担です。多くの場合、これらは空のままで問題ありません。ですが、業務の都合で「取り込みの前後にどうしても挟みたい処理」が出てきたときに、この2つの窓口があると助かります。スケジュールインポートは、素の状態では単純ですが、必要に応じて前後に手を入れられる余地を残している、というわけです。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
スケジュールインポート一覧 … scheduled_import_set_list.do
スケジュールインポート1件 … scheduled_import_set.do?sys_id=...
スケジュールジョブ全体 … sysauto_list.do
データソース … sys_data_source_list.do
まとめ
スケジュールインポートは、データソースの取り込みを「決まった時刻に自動で走らせる」仕組みでした。中心は Data source（何を）と Run（いつ）の2つ。実機では LDAP のサンプルが2件、どちらも無効の状態で置かれていました。そして、この自動化は ServiceNow のスケジュールジョブ基盤の上に乗っています。
データソース（口）・変換マップ（移し方）・スケジュール（いつ）。この3つが揃うと、外部データを毎晩自動で取り込み、本番を最新に保つ運用ができあがります。手動で確かめた取り込みを、そのままスケジュールに載せられるのが、役割分離のありがたいところです。
実機で自動化を組むときの手順も、これで見えてきます。まずデータソースを作り、Load All Records で手動取り込みを試す。変換マップと coalesce を調整して、意図どおりの結果になることを確かめる。固まったら、スケジュールインポートを1件作ります。そのデータソースを指名して、Run で時刻を決め、Active をオンにします。動作確認は Execute Now で。この順で進めれば、自動化まで迷わずたどり着けます。取り込みは、部品を1つずつ組み上げていく作業です。今回のスケジュールは、その最後のピース、「いつ回すか」を決める部品でした。
次回は、取り込みの途中に割り込む変換スクリプト（onBefore / onAfter など）を、実機で詳しく見ていきます。
その他、実機で確認した記録
用語
スケジュールインポート（scheduled_import_set） … データソースの取り込みを時刻指定で自動実行する定義
Data source … 走らせる対象のデータソース
Run … 実行タイミング（Daily / Weekly / Monthly / Periodically / Once / On Demand）
Execute Now … スケジュールを待たず今すぐ1回実行するボタン
スケジュールジョブ（sysauto） … 定期処理の共通基盤。スケジュールインポートもこの上に乗る
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/scheduled_import_set_list.do（スケジュールインポート2件）
/scheduled_import_set.do?sys_id=...（1件の設定・Data source と Run）
/sysauto_list.do（スケジュールジョブ全体）
実測の要点（再掲）
scheduled_import_set 2件（Example LDAP User / Group Import）、どちらも Run=Daily・active=false
中心フィールド: Data source（何を）/ Run（いつ）/ Active
Execute Now・pre/post-import script・Conditional で細かく制御
スケジュールジョブ（sysauto）基盤の上に乗る
検証範囲とおことわり
この記事の件数・フィールド・run 設定は、PDI（Zurich / OOTB）の実測です。
2件とも active=false で、実際にスケジュール発火して取り込む様子は未確認（検証範囲外）です（sys_import_set も0件）。
サンプルレコードは「High Risk」の標準レコードで、実機では原則書き換えません。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
