System Export Sets は標準で0件（sys_export_set）

2026年7月26日 16:55

ServiceNow へデータを取り込む仕組みは、標準でたくさん用意されています。データソースがあり、変換マップがあり、スケジュールインポートがある。その逆に、データを外へ出す役割を持つのが System Export Sets です。

ところが実機の件数は0件でした。関係する4テーブルが、どれも空のままです。取り込む側にはデータソースが最初から入っているのに、出す側は自分で1件目を作るところから始まります。PDI（Zurich / OOTB）でテーブルの構造を読み、実際にエクスポート定義とエクスポートセットを作って、どこまで動くかを確かめました。

この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-26）。本番環境では設定が異なります。

4つのテーブルで「何を・どこへ・どう・いつ」を決める

役割がきれいに4つに分かれています。

何を出すか … sys_export_definition（対象テーブル・列・条件）
どこへ出すか … sys_export_target（MID Server とファイルパス）
どう出すか … sys_export_set（形式・ファイル名・上限行数）
いつ出すか … scheduled_data_export（スケジュールと差分）

そして実測の件数は、4つとも 0件でした。インポート側にはデータソースが最初から入っているのと対照的です。

この差は機能の性格から来ています。取り込むデータは「ユーザー一覧をLDAPから」のように定番がありますが、出すデータは組織ごとに違う。だから標準では用意されていません。

実際に作ってみる

空のままでは形が見えないので、この記事のために2件のレコードを作りました。

まず エクスポート定義（sys_export_definition）です。

設定した値は4つだけでした。

Name … Demo: Active Incidents
Table … incident
Filter … active=true
Fields … number, short_description, priority, state, assignment_group

対象テーブルと、出す列と、出す行の条件。これで「何を出すか」が決まります。view というフィールドもあり、列を1つずつ選ぶ代わりにビューを指定することもできます。

列の指定は2通りある

field_list に列を並べる方法のほかに、view（→sys_ui_view）を指定する方法もあります。

ビューを使うと、画面で見えている列がそのまま出ます。運用担当が「この画面の内容をそのままExcelで欲しい」と言うとき、ビューを指定するほうが早い。列を追加したいときも、ビューを直せばエクスポート定義は触らずに済みます。

いっぽう field_list に直接書けば、画面とは無関係に列を選べます。外部システムへ渡すデータのように、画面表示とは別の並びが要るときはこちらです。

人が見るならビュー、機械が読むなら field_list。 受け手で選び分けると迷いません。

条件はフィルタ形式で持つ

filter は conditions 型で、画面ではフィルタの条件ビルダーとして表示されます。デモでは active=true の1条件だけにしましたが、複数条件も組めます。

ここで気をつけたいのは、日付の条件です。「昨日ぶん」を出したいとき、固定の日付を書くと翌日から間違ったデータが出ます。javascript:gs.daysAgo(1) のような動的な式を使うか、後述の差分エクスポートに任せます。

エクスポートセットが形式を決める

次に エクスポートセット（sys_export_set）を作ります。

フォームの冒頭に、機能の説明がそのまま書かれていました。

Use Export Sets to periodically send data from ServiceNow instance to external systems.

「定期的に外部システムへ送る」ためのもの、という位置づけです。続けて、指定するのは2つだと明示されています。What data to export（Export Definition）と Where to export the data to（Export Target）。

作成したデモの設定はこうです。Format は CSV、File name は active_incidents、Maximum rows は1,000、Append timestamp はオン。

列見出しと列の値を別々に選ぶ

このフォームでは、Column headers と Column values を別々に選びます。

Column headers は「Use field name（列名）」か「Use field label（項目ラベル）」の2択。前者なら short_description、後者なら「Short description」が見出しになります。

Column values は3択でした。「Use raw value（生の値）」「Use display value（表示値）」「Use both（両方）」。優先度なら、生の値は 1、表示値は 1 - Critical です。

受け取る相手で選び方が変わります。人が Excel で開くなら、ラベル見出しと表示値。別のシステムが機械的に読むなら、列名と生の値。両方が必要な場面のために Use both も用意されています。

Append timestamp と Maximum rows

Append timestamp をオンにすると、ファイル名の末尾に日時が付きます。フォームの案内にも「automatically append the current date and time to the name of the exported file」とありました。

毎日同じファイル名で出すと、前の日のファイルを上書きします。日時を付けておけば履歴が残る。定期実行では、まず付けておくのが無難です。

Maximum rows は上限です。案内によれば、既定値は選んだ Format ごとの全体上限になります。CSV と Excel では扱える行数が違うので、形式に応じた上限が効く仕組みです。

「どこへ出すか」でつまずく

エクスポートセットのタブは2つでした。What to export と \* Where to export to。後者にはアスタリスクが付いており、必須項目です。

ここで手が止まりました。出力先（sys_export_target）の method フィールドを調べると、選択肢が1つしかありません。

File on MID Server。

MID Server は、ServiceNow と社内ネットワークをつなぐ中継サーバです。エクスポートセットの出力先は、この MID Server 上のファイルパスに限られます。

そしてこの PDI には、MID Server（ecc_agent）が0件でした。つまり出力先を作れません。デモのエクスポートセットは Export target が空のままです。

これは機能の限界ではなく、設計上の割り切りです。ServiceNow はクラウド上にあるので、社内のファイルサーバへ直接書き込めません。MID Server を経由することで、社内側にファイルを置きます。

エクスポートセットを使うには MID Server が要る。 これが最初の前提条件でした。

画面からのエクスポートとは別物

この仕組みを使わなくても、一覧から右クリックで CSV に落とせます。そのとおりで、両者は別の機能です。

一覧の列ヘッダを右クリックすると Export のメニューが出て、CSV / Excel / XML / JSON を選べます。これはその場で1回だけ出す機能で、ブラウザにダウンロードされます。

エクスポートセットは違います。定期的に、指定した場所へ出す仕組みです。人が操作せずに、毎朝6時に前日ぶんのインシデントを社内サーバへ置く。そういう使い方をします。

用途が違うので、比べる必要はありません。1回きりなら画面から、繰り返すならエクスポートセット。この切り分けで足ります。

出力形式が同じ5種類（CSV / Excel 2種 / XML / JSON）である点も共通しています。違うのは、誰が起動して、どこへ届くかだけです。画面からのエクスポートは操作した人のブラウザへ、エクスポートセットは MID Server 上のフォルダへ。

もうひとつの違いは、条件の持ち方です。画面からのエクスポートは、そのとき画面に適用されているフィルタがそのまま効きます。エクスポートセットは、定義に書いた条件が毎回効きます。前者は操作者しだいで結果が変わり、後者は誰が実行しても同じ結果になる。定期的に同じものを出したいなら、条件を定義に固定できる後者が向いています。

いつ出すかを決める

Scheduled Data Export（scheduled_data_export）が実行のタイミングを持ちます。

フィールドを見ると、単なるスケジュール以上のことができる作りでした。

enable_delta_export と delta_on_or_after は差分エクスポートの設定です。前回の実行以降に作られた行や更新された行だけを出せます。毎回全件を出すと、受け取る側で重複を処理する手間が増える。差分にしておけば、増えたぶんだけが届きます。

pre_script と post_script は、実行の前後に走らせるスクリプトです。それぞれ有効/無効のチェックが別にあります。「出す前に一時テーブルを作る」「出した後に通知を送る」といった処理を挟めます。

parent と order もあります。複数のエクスポートを親子でまとめ、順番に走らせる仕組みです。関連するファイルを決まった順で出したいときに使います。

インポート側と比べる

取り込む側と出す側を並べると、非対称なところがはっきりします。

インポートには中間の置き場があります。取り込んだデータをいったんインポートセット表に置き、変換マップで本番テーブルへ移す。この2段構えのおかげで、取り込みの失敗が本番を汚しません。

エクスポートには中間がありません。定義した条件でテーブルを読み、そのままファイルにします。列の対応づけ（変換マップ相当）も無く、列と値の形式を選ぶだけです。

理由は単純で、出す側には「間違ったデータが入る」という危険が無いからです。読むだけなので、失敗しても元のデータは変わりません。だから仕組みが軽い。

差分の扱いも対照的でした。インポートは coalesce で重複を防ぎ、エクスポートは delta で差分だけ出す。どちらも「同じものを二度扱わない」ための工夫ですが、向きが逆です。

どんな場面で使うか

標準で0件ということは、必要になったときに自分で作る機能です。実際に要るのは、こういう場面です。

他システムへの定期連携。資産台帳を会計システムへ、ユーザー一覧を勤怠システムへ。相手がAPIを持たず、ファイルの受け渡ししかできない場合に使います。API連携が組めるなら、そちらのほうが確実です。

監査資料の提出。「四半期ごとに、期間内の変更要求を一覧で提出せよ」という要件は珍しくありません。人が毎回画面から落とすより、決まった条件で自動的に出したほうが漏れません。

分析基盤への流し込み。BIツールやデータ基盤へ、日次でデータを渡す。差分エクスポートを使えば、増えたぶんだけを送れます。

逆に向かないのは、その場で1回だけの抽出です。画面のエクスポートで足ります。設定を作る手間のほうが大きくなります。

実行履歴を見る

エクスポートセットのフォームには、関連リストとして Export Histories がありました。実体は sys_export_set_run で、実測は0件です。

実行のたびに1行が残る作りなので、定期実行を始めたらここが最初の確認先になります。「昨日のファイルが来ていない」と言われたとき、履歴を見れば実行されたのか失敗したのかが分かります。

差分エクスポートを使う場合、この履歴の重要度が上がります。実行が飛んだ回があると、その期間のデータが次回に持ち越されるのか、そのまま抜けるのかで結果が変わるからです。どちらになるかは今回未確認なので、運用に乗せる前に失敗時の挙動を確かめておきます。

実務で気をつけるところ

MID Server の準備を先に確認する

出力先が MID Server の1択である以上、MID Server が無いとこの機能は始まりません。設計の初期に、使える MID Server があるか、そこに書き込み先のフォルダを用意できるかを確認しておきます。

ファイル名の重複を避ける

Append timestamp をオフのまま日次で回すと、毎日上書きされます。受け取る側が取りに来る前に次のファイルが来ると、1日ぶんが消える。日時を付けるか、後処理スクリプトで移動させるかを決めておきましょう。

列の形式は受け取る側に合わせる

Column headers と Column values の組み合わせは4通りあります。受け取るのが人か機械かで選び方が変わるので、先に相手と決めておくのが確実です。後から変えると、相手側の取り込み処理も直すことになります。

出す前に「出してよいデータか」を確かめる

エクスポートは、権限の壁を越えやすい操作です。画面では見られない列でも、エクスポート定義に書けば出てしまう可能性があります。個人情報や評価に関わる列が混ざっていないか、定義を作った時点で確認します。

出力先が MID Server 上のフォルダである点も同じです。そのフォルダに誰がアクセスできるかは ServiceNow の外側の話になります。中で厳しく権限を管理していても、出したファイルが誰でも読める場所にあれば意味がありません。

出す列と、置く場所。 この2つをセットで決めるのが、エクスポート設計の勘どころです。

上限行数を超えたときの挙動を確かめる

Maximum rows は上限であって、警告ではありません。条件に合う行が上限を超えたとき、超えたぶんは出ないと読めます。実際の挙動は今回未確認です。

日次で1,000行に収まる想定でも、障害が起きた日に急増することがあります。「昨日のファイルの行数が上限ちょうどだった」なら、取りこぼしを疑います。上限は余裕を持って設定しておきましょう。

差分の起点を理解しておく

enable_delta_export をオンにすると、前回実行以降のぶんだけが出ます。実行が失敗した回があると、その期間のデータが抜けることになります。差分を使うなら、実行履歴（Export Histories）を見る運用もセットで必要です。

どこから触るか

/sys_export_definition_list.do … 何を出すかの定義
/sys_export_set_list.do … エクスポートセット
/sys_export_target_list.do … 出力先（MID Server）
/scheduled_data_export_list.do … スケジュール
/sys_export_set_run_list.do … 実行履歴
/ecc_agent_list.do … MID Server の一覧

エクスポートセットのフォームには、関連リストとして Scheduled Data Exports と Export Histories が並びます。1つのセットを複数のスケジュールから使える作りです。

まとめ

System Export Sets は、データを定期的に外へ出すための仕組みでした。

4つのテーブルが「何を・どこへ・どう・いつ」を分担します。標準では4つとも0件で、すべて自分で作ります。実際に定義とセットを作ってみると、対象テーブルと条件、そして出力形式を決めるだけで形になりました。

ただし出力先は MID Server の1択です。この PDI には MID Server が無く、実行までは到達できませんでした。使い始める前に、MID Server の有無を確認しておくのが最初の一歩になります。

画面からの1回きりのエクスポートとは、目的が違います。繰り返す必要が出てきたときに、この仕組みを思い出せば足ります。

用語

Export Definition（sys_export_definition） … 何を出すか。テーブル・列・条件
Export Target（sys_export_target） … どこへ出すか。MID Server とファイルパス
Export Set（sys_export_set） … どう出すか。形式・ファイル名・上限行数・列の形式
Scheduled Data Export（scheduled_data_export） … いつ出すか。差分と前後スクリプト
Append timestamp … ファイル名の末尾に日時を付ける設定
差分エクスポート（delta） … 前回実行以降に増減したぶんだけを出す

自分の環境で確認するときのURL

/sys_export_definition.do?sys_id=...（作成したエクスポート定義）
/sys_export_set.do?sys_id=...（作成したエクスポートセット）
/sys_export_target_list.do（出力先・0件）
/scheduled_data_export_list.do（スケジュール・0件）
/ecc_agent_list.do（MID Server・0件）

実測の要点（再掲）

sys_export_set / sys_export_definition / sys_export_target / scheduled_data_export はすべて 0件
sys_export_target.method の選択肢は File on MID Server の1つだけ
ecc_agent（MID Server）も0件のため、出力先を作れない
Format は CSV / Excel(.xlsx) / Excel(.xls) / XML / JSON の5種類
Column headers は2択、Column values は3択（生の値・表示値・両方）
scheduled_data_export は差分エクスポートと前後スクリプト、親子の実行順を持つ

ServiceNowのデータはどこに溜まっていつ消える？添付・履歴・ログ・アーカイブを実機で確認 — エクスポートで外へ出す前提として、ServiceNow内部にデータがどう溜まりいつ消えるのかを確認できる

検証範囲とおことわり

件数・項目・選択肢は PDI（Zurich / OOTB）の実測です。本番環境の設定とは異なります。
エクスポートは実行していません。MID Server が無く、出力先を作れないためです。
この記事のために、エクスポート定義とエクスポートセットを各1件作成しました。デモ用のレコードです。
差分エクスポート・前後スクリプト・親子の実行順は、フィールドの存在を確認しただけで未検証です。