メインコンテンツへスキップ

テーブルの情報をエクスポートする方法(XML / CSV / Excel / PDF)


    ServiceNow の一覧やレコードを、画面の外に取り出したいことがあります。他のシステムに渡す、Excel で集計する、監査のために証跡を残す。理由は様々でも、やることは同じです。テーブルのデータをファイルにして持ち出します。

    ServiceNow には、この持ち出しの方法がいくつも用意されています。URL の末尾に文字を足すだけの方法もあれば、画面のメニューから選ぶ方法もあります。どちらも操作自体は単純ですが、初めて触ると形式の選び方や隠れた項目の扱いで迷いがちです。

    エクスポートと一口に言っても、入口は URL・画面のメニュー・定期実行の仕組みと複数あります。どれも同じテーブルのデータを取り出す機能ですが、向いている場面はそれぞれ違います。件数の上限や権限による見え方の違いも、あらかじめ知っておきたいところです。

    想定読者は、一覧の画面は普段から使っているが、そこからデータを外部に取り出す方法はまだ試したことがない人です。

    この記事の内容は ServiceNow の PDI(Personal Developer Instance)Zurich リリースの OOTB(初期設定)で確認しています。実環境では権限やカスタマイズにより結果が変わります。エクスポート機能の位置づけそのものは、公式ドキュメントの記載と突き合わせています。

    この記事のURLは、実際に打てる形で書いています。差し替える箇所は次の2つです。

    • <YourInstance> … 自分のインスタンス名。ブラウザのアドレスバーに出ているものに置き換えます

    • incident … 対象のテーブル名。sys_user や change_request など、調べたいテーブルに置き換えます

    条件や件数を指定する部分も、そのまま書き換えて使えます。

    この記事で分かること

    • URL の末尾に形式を書くだけでエクスポートできること

    • 画面のメニューからエクスポートする2つの入口

    • 既定では隠れている項目まで含める方法

    • 件数や条件を絞ってエクスポートする方法

    • 件数の上限がどのプロパティで決まり、どう調べるか

    • 形式ごとの向き不向きと、それぞれの注意点

    • Export Set という別の仕組みとの違い、その3つの構成要素

    • 棚卸し・監査提出・システム連携での使い分け

    • 参照フィールドや権限まわりでつまずきやすい点

    URLの末尾に形式を書いて出す

    一覧の URL には、末尾に形式を書き足すだけでエクスポートできる仕組みがあります。公式ドキュメントでは「Export directly from a URL(URLから直接エクスポートする)」として説明されている機能です。


    画像


    画像
    https://<YourInstance>.service-now.com/incident_list.do?XML
    https://<YourInstance>.service-now.com/incident_list.do?CSV
    https://<YourInstance>.service-now.com/incident_list.do?XLS
    https://<YourInstance>.service-now.com/incident_list.do?PDF

    実機で incident_list.do?XML にレコード2件を指定して叩くと、28,119バイトの XML が返ってきました。仕組みは単純です。タグの中に、一覧に出ている項目がそのまま並びます。

    CSV・XLS・PDF は画面が切り替わらず、そのままファイルのダウンロードが始まります。ブラウザ側はダウンロードとして扱うので、開いた先に別の画面が表示されるわけではありません。Excel で開いて集計したいときは XLS、そのまま印刷や共有に使いたいときは PDF、という使い分けになります。

    レコード1件だけを出す

    レコード1件だけを対象にするときは、一覧ではなくフォームの URL に同じ形式を足します。公式ドキュメントでは、この操作を「Export data from a record」として、一覧のエクスポートとは別のページで解説しています。

    https://<YourInstance>.service-now.com/incident.do?sys_id=対象のsys_id&XML

    一覧の URL とフォームの URL は見た目が似ていますが、末尾に _list が付くかどうかで対象が変わります。取り違えると、1件だけ欲しいのに一覧全体が返ってきたり、その逆が起きたりするので、URL を組み立てるときはここを最初に確認すると迷いません。

    JSONで受け取る

    画面表示用の形式とは別に、JSON で受け取る方法もあります。


    画像
    https://<YourInstance>.service-now.com/incident.do?JSONv2&sysparm_action=getRecords

    実機で叩くと、2,537バイトの JSON が返ってきました。差は歴然です。同じ2件のデータでも、XML の28,119バイトに比べるとかなり小さく収まっています。スクリプトや外部システムから機械的に読み込みたいときは、JSON のほうが軽くて扱いやすい形式です。

    なお、画面のメニューには JSON を選ぶ項目はありません。JSON で受け取りたいときは、この記事にある URL を直接使う必要があります。

    画面から操作して出す

    URL を直接叩かなくても、画面の操作だけでエクスポートできます。入口は2つあります。


    画像

    1つは、一覧の列ヘッダを右クリックする方法です。開いたメニューの中に Export の項目があり、そこから形式を選びます。もう1つは、一覧の左上にある三本線のメニューを開く方法です。こちらにも同じ Export の項目があります。

    どちらの入口でも、選べる形式は Excel・CSV・PDF・XML の4つです。操作はどちらも同じです。URL に文字を足すのと同じ結果が、メニューの操作からも得られます。

    この右クリックメニューの定義は sys_ui_context_menu というテーブルに入っています。PDI で確認したところ、86件の定義がありました。Export 以外の操作も、この同じテーブルにまとまっています。

    フォームから1件を出す

    レコードを1件だけエクスポートしたいときは、一覧ではなくフォーム側で操作します。フォームのヘッダ部分を右クリックすれば、同じく Export のメニューが現れる作りです。URL を覚えていなくても、右クリックか三本線メニューさえ見つければ迷わずたどり着けます。パラメータのつづりを間違える心配もありません。まずは画面の操作から試して、URL は繰り返し使う場面で覚えていく、という順番でも困りません。

    URL版とメニュー版はつながっている

    ここまで、URL に直接文字を足す方法と、画面のメニューから選ぶ方法を別々に紹介しました。この2つは、まったく独立した機能ではありません。

    公式ドキュメントの「Export data from a list」と「Export directly from a URL」は、どちらも同じ「Exporting data」という章にまとまっています。メニューの Export をクリックしたときも、内部的には一覧の URL に形式のパラメータが付いたリクエストが飛び、同じエクスポートの処理に行き着く仕組みです。つまり、右クリックメニューは URL エクスポートの入口を画面上に用意したもの、と捉えられます。

    この構造を知っておくと、応用が利きます。メニューでは選べない JSONv2 や sysparm_default_export_fields=all のような細かいパラメータも、URL を直接書けば足せます。逆に、URL の組み立てに慣れていないうちは、メニューから形式だけ選んで様子を見る、という進め方でも構いません。入口が2つあるだけで、たどり着く先は同じです。

    隠れた列も出す

    エクスポートには、既定の制約が1つあります。画面に表示されている列だけが対象になり、sys_id のような普段は隠れている項目は含まれません。


    画像

    これを変えるには、パラメータを足します。

    https://<YourInstance>.service-now.com/incident_list.do?XML&sysparm_default_export_fields=all

    実機で叩いたところ、出力は15,065バイトになり、中に sys_id が含まれることを確認しました。他のシステムとデータを突き合わせたいときや、参照先の内部値まで確認したいときに、このパラメータが要ります。ServiceNow のデベロッパーブログでも、このパラメータについて「テーブルの全フィールド(sys_id を含む)をエクスポート対象にする」ものだと説明されています。

    ただし、このパラメータで増えるのはあくまで「テーブル自身の隠れた項目」です。参照フィールド(Assignment group など)が指す先のレコードの sys_id まで一括で取りたい場合は、別の手当てが要ります。この点は後の「つまずきやすい点」でもう一度扱います。

    条件と件数を絞る

    エクスポートするデータの範囲は、パラメータで調整できます。

    件数を絞るには sysparm_record_count を使います。

    https://<YourInstance>.service-now.com/incident_list.do?CSV&sysparm_record_count=100

    条件を絞るには sysparm_query を使います。複数条件をつなぐときは ^ を使い、AND として扱われます。

    https://<YourInstance>.service-now.com/incident_list.do?XML&sysparm_query=active=true^priority=1

    条件の演算子には他にも種類がありますが、その一覧は別記事にまとめています。ここでは、一覧の絞り込みに使う sysparm_query が、エクスポートの対象を絞るときにもそのまま使える、とだけ押さえておけば足ります。公式の「Data export reference」も、このクエリパラメータ群を整理した参照ページです。

    大量の件数をそのままエクスポートすると、応答に時間がかかります。件数を区切るか、条件で対象を絞ってから実行すると、待ち時間を減らせます。

    件数の上限をどう確認するか

    一度に出せる件数には、上限があります。公式ドキュメントにも「Export limits」という専用のページがあり、大きすぎるエクスポートは分割することが推奨されています。上限は glide.ui.export.limit のような命名のシステムプロパティで制御される仕組みですが、この値はインスタンスやバージョンによって違うため、断定はできません。

    答えは環境次第です。今回の PDI で sys_properties を export を含む名前で検索したところ、15件がヒットしました。ただし、上限の値そのものを持つプロパティは見当たらず、いずれもフォーマット変換やアクセス制御など個別の挙動を切り替えるものです。件数の上限を表すプロパティ名で直接検索しても、レコードとしては見つかりませんでした。ServiceNow のシステムプロパティは、既定値のまま使われている間はレコード化されず、管理者が値を変更した時点で初めて sys_properties に現れるものが少なくありません。上限プロパティもこの類に当たると考えられます。

    自分の環境で件数の上限を確かめたいときは、sys_properties を export や limit といったキーワードで検索し、見つからなければ「未設定=既定値が有効」と捉えるのが実務的な進め方です。上限に達しそうな大きなテーブルをエクスポートするときは、sysparm_record_count で件数を区切るか、sysparm_query で日付や状態を絞り、何回かに分けて取得する方法が安全です。公式ドキュメントの「Break up a large export」も、同じ考え方を勧めています。

    形式ごとの向き不向き

    5つの形式は、それぞれ得意な場面が違います。選び方に迷うのも当然です。実機で確認できたプロパティの挙動を交えて、形式ごとに見ていきます。

    CSVは加工向き、文字コードに注意

    CSV は、Excel や他のツールへ読み込んで加工することを前提にした形式です。行数が多いデータでも軽く扱え、他システムへの受け渡しにもよく使われます。

    注意したいのは文字コードです。テキストとしてそのまま開くツールによっては、想定と違う文字コードで解釈され、文字化けすることがあります。開き方に迷ったら、テキストエディタで文字コードを指定して開き直すと解決することが多いです。

    もう1つ、セキュリティ面の挙動も確認できました。glide.export.escape_formulas というプロパティが true になっており、これは「+ - = @ で始まる文字列値を、CSV・XLS・XLSX のエクスポート時にエスケープする」ものだと説明されています。セルの中身が数式として実行されてしまう事故を防ぐ仕組みで、既定で有効になっていました。

    Excelは行数に上限がある

    Excel(XLS / XLSX)は、そのまま集計や共有に使いたいときに向いています。書式が保たれるので、受け取った側もすぐに開いて使えます。

    一方で、Excel 形式には行数の上限があります。古い XLS 形式は仕様上の上限が低く、大量データには向きません。PDI では glide.export.excel.force_xlsx というプロパティが false になっており、?XLS で叩いたときに、より新しい XLSX 形式へ強制的に切り替えるかどうかを、このプロパティで制御していることが分かりました。

    もう1つ気づいたのが、glide.basicauth.required.excel というプロパティです。実機では true になっており、「Excel 形式への着信リクエストに認証を必須にする」ものだと説明されています。ブラウザで通常のセッションを開いていても、Excel 向けのリクエストだけ別途認証を求められることがあるのは、このプロパティが関係していると考えられます。

    PDFは見た目重視でレイアウトが崩れやすい

    PDF は、画面に見えている状態をそのまま資料として渡したいときに向いています。印刷して配る、会議で見せる、といった用途に合います。

    反面、列の数が多い一覧を PDF にすると、紙面の幅に収まらず、レイアウトが崩れることがあります。加工して再利用する用途には向いていません。あくまで「見た目を渡す」ための形式と考えるのが実務的です。

    PDI では com.snc.pdf.exports.enabled が true、glide.pdf_export_from_form_list.show_report_attrs も true になっていました。後者は「一覧やフォームを PDF にエクスポートしたとき、タイトル・実行日時・検索条件などの見出しをレポートの先頭に付ける」ものです。誰が、いつ、どんな条件で出したファイルかが PDF自体に残るため、証跡としての使い勝手はこの設定に支えられています。

    XMLは再インポートを見据えた形式

    XML は、全項目を機械的に処理したいときや、他システムへ連携したいときに向いています。もう1つの用途が再インポートです。エクスポートした XML をそのまま Import Set の取り込み元に使う、という流れが組めるように作られています。公式ドキュメントにも「Export data to XML」という専用のページがあり、この形式が単なる表示用ではなく、往復(エクスポートしてまた取り込む)を前提にしていることがうかがえます。

    タグの分だけファイルサイズは大きくなりがちですが、構造がはっきりしている分、プログラムからは扱いやすい形式です。


    画像

    迷ったときの目安は、行き先で決めることです。人が Excel で開くなら XLS、印刷して配るなら PDF、プログラムが読むか再インポートするなら XML、という具合です。

    Export Setという別の仕組み

    ここまでの方法は、いずれも今すぐこの画面から出すエクスポートでした。ServiceNow には、これとは別に、定期的にデータを外部へ送り出す Export Set という仕組みもあります。


    画像

    Export Set は sys_export_set というテーブルで管理されます。PDI で確認したところ、既定で1件だけ登録されていました。今回扱った URL 経由のエクスポートとは別の機能で、対象のテーブルや出力先、実行のタイミングをあらかじめ定義しておく仕組みです。

    3つの構成要素

    Export Set は、大きく3つのレコードの組み合わせでできています。ServiceNow コミュニティの解説記事によると、構成要素は次のとおりです。

    • Export Definition(何を) … 対象のテーブル・フィールド・絞り込み条件を定義する

    • Export Target(どこへ) … 出力先のパス、および経由する MID Server を定義する

    • Scheduled Export(いつ) … 上の2つを結び付け、実行のタイミングを定義する。フル出力か差分出力かも、ここで選ぶ

    この3つを分けて持つ設計なので、「対象は変えずに出力先だけ差し替える」「スケジュールだけ見直す」といった変更が、それぞれ独立してできます。今すぐ出す URL エクスポートが1回限りの操作なのに対し、Export Set はこの3点セットを一度組めば、あとは決まった手順で繰り返し動く点が違います。

    差分エクスポート

    Scheduled Export には、前回の実行以降に作成・更新されたレコードだけを対象にする、差分エクスポートの選択肢もあります。毎回全件を出し直すと出力先の負荷が大きくなるため、日次や週次で回すような運用では、差分だけを送る設定が実務でよく使われます。

    目の前の一覧を今出したいなら URL やメニューからのエクスポート、決まった条件で定期的に出し続けたいなら Export Set、という向き先の違いがあります。Export Set 自体の詳しい作成手順は、別記事で扱います。

    実務での使い分け

    形式や入口の違いを踏まえると、実務でどう使い分けるかが見えてきます。

    棚卸しでは、対象テーブルの全件を、隠れた列も含めて定期的に出す使い方が向いています。sysparm_default_export_fields=all を付けた CSV や XML で sys_id まで含めて出しておけば、前回との突き合わせや、他台帳との照合がしやすくなります。

    監査提出では、見た目をそのまま渡せる PDF か、条件を明示した CSV が使われます。sysparm_query で絞った条件をそのまま記録に残しておくと、「いつ、どの条件で出したファイルか」を後から説明しやすくなります。レポートの見出しに条件が残る PDF は、この用途に適した形式です。

    他システムへの受け渡しでは、機械的に読み込みやすい XML か JSON が中心になります。1回限りの連携なら URL エクスポート、定期的に繋ぎ続けるなら Export Set、という選び方になります。

    つまずきやすい点

    参照フィールドが表示値になりsys_idが出ない

    一覧に出ている参照フィールド(Assignment group など)は、既定では表示値(名前)でエクスポートされます。sysparm_default_export_fields=all を付けても増えるのは、そのテーブル自身の隠れた項目です。参照先のレコードそのものの sys_id まで欲しい場合は、ドット・ウォーク(assignment_group.sys_id のような指定)で列を追加するなど、別の手当てが要ります。この挙動の詳しい検証は、今回の範囲外です。

    大量件数で時間がかかる

    件数が多いテーブルをそのままエクスポートすると、応答に時間がかかり、途中でタイムアウトすることもあります。「件数の上限をどう確認するか」で触れたとおり、sysparm_record_count で区切るか、sysparm_query で条件を絞ってから実行すると安定します。急ぎでなければ、時間帯を分けて何回かに分けて取る方法も有効です。

    権限で列が欠ける

    答えは権限です。エクスポートは、実行するユーザーの権限をそのまま反映します。PDI で確認したところ、glide.export.query.enforce_field_acl というプロパティが true になっていました。対象は Table API・SOAP の getRecords、そして CSV / XML / EXCEL(XLS) / XLSX / JSONv2 の各ファイルエクスポートです。これらのクエリ条件に対して、フィールドACLを強制する仕組みです。つまり、あるフィールドの参照権限を持たないユーザーの場合、そのフィールドはエクスポート結果に含まれません。管理者が出したファイルと、権限が限られたユーザーが出した「同じはずの一覧」のファイルとで、列の数が食い違うことがあります。ファイルを見比べて列が足りないときは、まずこの権限差を疑うと、早く原因にたどり着けます。

    よくある質問

    CSVで開いたら文字化けします。原因は何ですか

    多くの場合、開いたツールが文字コードを正しく判定できていないことが原因です。テキストエディタで文字コードを指定して開き直すか、Excel側の取り込み設定で文字コードを明示すると解決することが多いです。

    sys_idを含めてエクスポートするにはどうすればいいですか

    URLに sysparm_default_export_fields=all を付けます。テーブル自身の sys_id はこれで出ますが、参照フィールドの参照先の sys_id までは含まれない点に注意してください。

    何件までエクスポートできますか

    上限はインスタンスやプロパティ設定によって変わるため、この記事では断定していません。sys_properties を export や limit で検索して確認し、見つからなければ既定値が使われていると考え、大きなテーブルは sysparm_record_count や sysparm_query で区切って出すのが安全です。

    Export SetとURLエクスポートはどちらを使えばいいですか

    今すぐこの一覧を出したいだけなら URL エクスポートで足ります。決まったテーブルを、決まった条件・出力先で、定期的に出し続けたいなら Export Set を組むほうが手間が少なくなります。

    エクスポートに権限は必要ですか

    対象テーブル・フィールドへの読み取り権限が前提です。権限が足りないフィールドは、エクスポート結果から欠けます。Excel向けのリクエストでは、別途認証が求められる設定になっていることもあります。

    用語

    • URLエクスポート … 一覧・フォームの URL 末尾に形式を付けて出す方法

    • sysparm_default_export_fields=all … 隠れた項目(sys_id など)も含めて出すパラメータ

    • sysparm_record_count … エクスポートする件数を絞るパラメータ

    • sysparm_query … エクスポートする条件を絞るパラメータ(一覧の絞り込みと同じ書式)

    • Export Set(sys_export_set) … 定期的に外部へデータを送り出す仕組み。Export Definition・Export Target・Scheduled Export の3点で構成される

    • sys_ui_context_menu … 右クリックメニューの定義が入るテーブル

    • glide.export.escape_formulas … CSV/XLS/XLSXの数式記号を自動エスケープするプロパティ

    • glide.export.query.enforce_field_acl … エクスポート時にフィールドACLを強制するプロパティ

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

    • 一覧のエクスポート … /incident_list.do?XML(CSV / XLS / PDF も同様)

    • フォーム1件のエクスポート … /incident.do?sys_id=...&XML

    • JSONでの取得 … /incident.do?JSONv2&sysparm_action=getRecords

    • 隠れた項目を含める … /incident_list.do?XML&sysparm_default_export_fields=all

    • 件数・条件を絞る … /incident_list.do?CSV&sysparm_record_count=100

    • 右クリックメニューの定義 … sys_ui_context_menu_list.do

    • Export Set の一覧 … sys_export_set_list.do

    • エクスポート関連プロパティ … sys_properties_list.do?sysparm_query=nameLIKEexport

    検証範囲とおことわり

    • バイト数・件数は、この記事に書いた条件でPDIを実機で叩いた結果です

    • sysparm_query の演算子の一覧は、この記事では扱っていません

    • 件数の上限を表すシステムプロパティは、この PDI の sys_properties にレコードとして存在せず、具体的な値は確認できていません。実環境で確認してください

    • 参照フィールドの参照先 sys_id をドット・ウォークで取得する具体的な手順は、この記事では検証していません

    • Export Set の作成・スケジュール設定・実際の配信結果は、この記事では扱っていません

    • 権限が足りない場合にどのフィールドが欠けるかの具体例は、今回は個々に確認していません

    • CSV・XLS・PDF のファイル内部の詳細なレイアウトは、ダウンロードが始まることまでを確認し、内容の詳細な検証はしていません

    参考リンク

    まとめ


    画像

    エクスポートは、URL に文字を足すだけで動く手軽な機能です。まずは形式を1つ試し、隠れた列や件数の絞り込みを覚え、上限に近づいたら分割する。この順番で慣れていくと、迷いにくくなります。

    形式選びに迷ったら、行き先で決めます。人が開くなら Excel、印刷するなら PDF、機械が読むか再インポートするなら XML か JSON です。決まった条件で出し続けたいときだけ、Export Set という別の仕組みに切り替える。この住み分けさえ押さえておけば、日々のエクスポートで困る場面はぐっと減ります。

     
     
    ServiceNowのPDI(Personal Developer Instance)を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ