レコードの全項目をXMLで確認する方法（Show XML）

フォームに表示されている項目と、レコードに実際に格納されている値は、常に一致するとは限りません。ある項目がフォームに配置されていなければ、値が入っていても画面には出ません。参照フィールドは、選んだレコードの表示名だけが画面に出て、実際に格納されているのは参照先の sys_id です。この2つのずれに気づかないまま画面だけを見て原因を探すと、時間がかかります。

ServiceNow には、レコードの中身をそのまま確認する機能が最初から入っています。それが Show XML です。フォームのヘッダを右クリックして選ぶだけで、そのレコードの全項目が XML として表示されます。フォームのレイアウトは関係ありません。

この記事では、PDI（Personal Developer Instance / Zurich / OOTB）で Show XML を実際に開き、何が見えて何が見えないかを確認します。あわせて、右クリックが使えない環境向けの URL 方式、一覧を対象にした確認方法、つまずきやすい点も扱います。

想定読者は、フォームの見た目だけでレコードの中身を判断していて、格納されている値そのものを確認したことがない人です。

この記事で分かること

• Show XML でレコード全体の格納値を確認する方法

• フォームのレイアウトに載っていない項目が見える理由

• 参照フィールドが sys_id として見える理由

• ジャーナルフィールドや添付ファイルが XML に出ない理由

• URL から同じ内容を取得する方法、一覧をまとめて確認する方法

• Show XML を使える人を広げる、または制限する方法

Show XML とは何か

Show XML は、フォームのヘッダを右クリックしたときに出るコンテキストメニューの1項目です。操作自体は単純です。この右クリックメニューの並びは sys_ui_context_menu というテーブルで定義されています。メニューをカスタマイズする方法は、公式ドキュメントのCustomize list context menusにまとまっています。

Show XML が返す中身は、選んでいるレコードが持つ列とその値です。列の並び順や名前は、そのテーブルの sys_dictionary 定義に従います。フォームの見出しや選択肢のラベルは介在しません。出てくるのは、テーブル設計そのものを映した値です。

sys_dictionary が決めるタグと値

XML のタグ名は、テーブルの列名（sys_dictionary の element）と一致します。列の型や参照先テーブルも、同じ sys_dictionary の設定で決まる仕組みです。1つのフィールドにつき sys_dictionary のレコードが1件対応し、詳しい見方はDictionary entry formのドキュメントに記載があります。

つまり、Show XML の1行1行は「このテーブルにこういう列が定義されている」という事実の裏返しです。フォーム側の表示設定を追いかけるより、sys_dictionary の定義を追いかけるほうが、XML に出る項目の正体をつかみやすくなります。

フォームの表示とレコードの格納値は違う

フォームは、テーブルが持つ列のうち、フォームデザイナーで配置した項目だけを並べた画面です。配置していない項目は、値が入っていても画面には出ません。列は存在するのに、見た目には現れないということです。

参照フィールドも同じ理由でずれます。画面に出るのは参照先レコードの表示名で、実際に格納されているのは参照先の sys_id です。表示名は毎回引き直して見せているだけで、レコード自体が持っているのは sys_id のほうです。参照フィールドの仕様はReference field typeで解説されています。

参照フィールドの表示名とsys_idのずれ

インシデントで言えば、担当者を表す assigned_to や担当グループを表す assignment_group は参照フィールドです。問い合わせ元を表す caller_id、構成アイテムを表す cmdb_ci も参照フィールドにあたります。フォームには人名や機器名が並びますが、レコードの中身は32文字の sys_id が入っているだけです。

参照先が削除された場合

参照先が削除された場合はさらに分かりにくくなります。表示名を引けなくなるため画面は空欄に見えますが、項目自体の値（古い sys_id）が消去されていなければ、レコードには依然としてその値が残っています。見た目は空、中身は空でない、という状態です。

フォームに項目を出さないこと自体は、設計として自然です。画面に全項目を並べると読みにくくなるため、業務でよく使う項目だけを選んで配置します。問題になるのは、配置されなかった項目に値が入っていることを忘れて、画面だけを見て「この項目は空だ」と判断してしまう場面です。テーブルとフォームと列の関係はTables and dataの概要ページにまとまっています。

Show XML は、こうしたレイアウトや表示変換をすべて外し、レコードが持つ値をそのまま返します。

Show XML の開き方

手順は単純です。対象のレコードをフォームで開き、画面上部のヘッダ（灰色の帯）を右クリックします。出てきたメニューから Show XML を選ぶと、そのレコードの内容が XML のテキストとして表示されます。

フォームからの操作手順

右クリックできるのは、ヘッダの灰色の帯の部分です。フォーム本体や個々の項目を右クリックしても、このメニューは出ません。管理者ロールで開いていれば、初期設定のままメニューに Show XML が並びます。

出力されるXMLの構造

出力される XML は、タグ名がテーブルの列名（element）と一致し、その中に格納値がそのまま入っている形です。フォームでの見出しや選択肢の表示ラベルは出てきません。出るのは列名と値だけです。

表示はプレーンテキストなので、ブラウザの検索機能（Ctrl+F など）でタグ名を検索すれば、目当ての項目にすぐたどり着けます。項目数が多いレコードでも、目視で1行ずつ探す必要はありません。

XMLに出るもの・出ないもの

Show XML に何が出て何が出ないかを整理すると、実務で迷わずに済みます。ここでは4つに分けて説明します。

フォームのレイアウトに載っていない項目

フォームのレイアウトに関係なく、テーブルが持つ列はすべて XML に並びます。業務でほとんど見ない管理用の列や、過去のカスタマイズで残った列も含まれます。フォームに出す・出さないの判断は表示側の設計であって、列そのものの有無とは別問題です。

参照フィールドはsys_idで出る

参照フィールドが格納するのは、参照先テーブルの sys_id です。PDI で sys_dictionary を element=sys_id で絞ると6,008件でした。全テーブルは6,317件なので、ほとんどのテーブルが sys_id を持つ設計だと分かります。参照フィールドの値がこの sys_id であることを踏まえると、Show XML に表示名ではなく sys_id が出るのは当然の挙動です。

ジャーナルフィールドはタグだけで中身が空

work_notes や comments のようなジャーナルフィールドは、実機で確認するとタグ自体は出力されますが、中身は常に空でした。ジャーナルフィールドへの入力履歴は、レコード本体の列にはなく、sys_journal_field という別テーブルに1件ずつ蓄積される仕組みだからです。フィールドの種類ごとの扱いはExploring field administrationのページでも触れられています。PDI 全体では、ジャーナル系（journal・journal_input・journal_list）の列定義が39件ありました。

言い換えると、Show XML が返すのは「レコード自身の行が持つ値」に限られます。関連テーブルに蓄積される履歴までは含まれません。

添付ファイルは別テーブルなので出ない

添付ファイルも同じ理由で XML に出ません。添付は sys_attachment というテーブルが管理していて、table_name と table_sys_id で元のレコードを指す形で紐付いています。つまり、リンクの向きはレコード側から添付側ではなく、添付側からレコード側です。レコード自身の XML を見ても、添付があるかどうかは分かりません。実機で添付済みのインシデントを Show XML と同じ方式で開いても、sys_attachment への言及は出力に一切ありませんでした。

同じレコードでも見え方は複数ある

同じテーブルでも、フォームは1つとは限りません。PDI で incident のフォーム定義を数えると8件ありました。役割やアプリケーションごとに、別のフォームが割り当てられています。ビュー定義も707件あり、ビューを切り替えるとフォームに出る項目や並びも変わる仕組みです。ビューによって見え方が変わる詳しい話は別の記事で扱っています。

フォーム定義とビュー定義

フォームが8種類あるということは、同じレコードでも8通りの見え方があるということです。Show XML はそのどれでもありません。フォームやビューを経由せず、レコードに格納されている値そのものを返します。結果は変わりません。どのフォームから開いても、同じ内容が出てきます。

見え方が複数あること自体は問題ではありません。困るのは、自分が見ているフォームを基準だと思い込んで、他の人が別のフォームで見ている内容や、実際の格納値とのずれに気づかない場面です。Show XML を基準に確認する習慣があれば、フォームの違いに振り回されずに済みます。

URLからも同じことができる（?XMLパラメータ）

右クリックが使えない場面でも、URL に直接パラメータを付ければ同じ内容を取得できます。一覧の URL の末尾にパラメータを足すだけで、画面を経由せず結果が返る仕組みです。URL パラメータでのエクスポート方法はExport directly from a URLに説明があります。以下はすべて実機で200応答を確認済みです。

一覧をXMLで取得する

一覧をXMLで返します。

incident_list.do?XML&sysparm_record_count=2

sysparm_record_count で件数を指定します。実測で28,119バイトの応答でした。XML形式でのエクスポート全般はExport data to XMLにまとまっています。

非表示列を含めて取得する

画面に出ていない非表示列も含めて返します。

incident_list.do?XML&sysparm_default_export_fields=all

一覧の既定の出力は、画面に表示している列に合わせて絞られます。このパラメータを足すと、非表示の列も含めて全項目が出ます。実測で15,065バイトの応答でした。

JSON形式で取得する

XMLではなくJSON形式で欲しいときは、こちらです。

incident.do?JSONv2&sysparm_action=getRecords

他システムとの連携で JSON を使う場合に向いています。実測で2,537バイトの応答でした。パラメータの詳細はJSONv2 web serviceのドキュメントにあります。継続的に外部システムと連携する用途では、Table APIを使う設計のほうが一般的です。JSONv2 は簡易な確認や検証には十分ですが、認証方式やレート制限の考え方が REST API と異なります。使い道は明確です。エクスポート形式の細かい違い（CSV / XLS / PDF など）は、別の記事にまとめています。

一覧に対する?XMLで複数レコードをまとめて見る

Show XML は右クリックした1レコードだけが対象です。複数のレコードをまとめて突き合わせたいときは、一覧側の ?XML を使います。incident_list.do?XML に絞り込み条件を付けて開くと、条件に合うレコードの数だけ <incident> タグが並んだ1つの XML が返ります。

たとえば、同じ問い合わせ元から起票されたインシデントをまとめて見たい場合や、似た症状のレコードを横に並べて項目値を比較したい場合に向いています。1レコードずつ Show XML を開いて見比べるより、まとめて1回で取得したほうが早く終わります。

件数が多いクエリで実行すると応答も大きくなるため、絞り込み条件を工夫して対象を限定するのが実務的です。範囲を絞る考え方は前章の sysparm_record_count や sysparm_query と同じです。一覧の条件指定そのものは別の記事で詳しく扱っています。

実務での使い分け

Show XML と一覧の ?XML は、目的によって使い分けます。

フォームで見えない値を確認する

画面では空なのに処理が動く場合、表示と格納値がずれていないかを Show XML で確認できます。フォームに出ていない列に値が入っていて、それをスクリプトが参照しているケースはよくあります。典型例です。

参照先レコードを特定する

参照フィールドの表示名から実体を追えないとき、Show XML で sys_id を確認すれば、参照先のレコードを一意に特定できます。sys_id の調べ方はほかにも複数あり、用途別の一覧は別の記事にまとめています。

更新前後の差分を確認する

設定変更やデータ移行の前後で、レコードの値がどう変わったかを比較したい場面があります。変更前と変更後、それぞれの Show XML をテキストとして保存しておくと、差分ツールでそのまま突き合わせられる形です。フォームのスクリーンショットを見比べるより、確実に差分を追えます。

サポート問い合わせに情報を添付する

他システムへ渡すデータの実体を送信前に確認したいときや、サポート窓口へレコードの状態を伝えたいときにも Show XML が役立ちます。XML はプレーンテキストなので、画面のスクリーンショットより情報量が多く、コピーしてそのまま貼り付けられます。手間も少なくて済む方法です。

つまずきやすい点

Show XML と ?XML を使うときに、実務でつまずきやすい点を3つ挙げます。

大量レコードで重くなる

一覧の ?XML で sysparm_record_count を大きくすると、応答が重くなります。件数を絞らずに全件を取ろうとすると、ブラウザの表示が止まったように見えることがあります。対策は簡単です。必要な範囲に条件を絞ってから実行すれば防げます。

ブラウザが整形表示しない場合

ブラウザや拡張機能の設定によっては、XML がプレーンテキストとして表示されず、ダウンロードとして扱われることがあります。対処は簡単です。その場合はダウンロードしたファイルをテキストエディタで開けば、内容自体は変わらず確認できます。

権限で一部が出ない場合

見落としがちです。フィールド単位のアクセス制御（ACL）が設定されている環境では、読み取り権限がない項目が空で返ることがあります。Show XML に出ていない項目を見つけたときは、そのテーブルの設計だけでなく、ACL の設定も合わせて確認すると原因の切り分けが早くなります。

権限と制約

Show XML は既定では管理者だけが使えます。理由は単純で、レコードの生の値を誰でも見られると困る場面があるからです。他のロールにも開放したい場合は、右クリックメニューの定義である sys_ui_context_menu の条件を調整します。PDI ではこの定義が86件ありました。Show XML はこの中の1つです。メニュー項目の条件式はAction script for list context menusのリファレンスに沿って書きます。

もう一つの制約は UI です。右クリックメニューは Classic UI（UI16）の機能で、Next Experience やワークスペースの画面では出ません。右クリックが使えない環境では、前の章で挙げた URL 方式を使うと同じ内容を確認できます。

権限の調整と UI の制約は別の話です。権限を開放しても、Next Experience やワークスペースで作業している人には、そもそも右クリックメニュー自体が現れません。誰にどちらの案内をするかは、対象者が普段どの UI で作業しているかで決まります。ロールごとにリストの操作をどこまで許すかはControl which roles can personalize listsにもまとまっています。

よくある質問

Show XML は誰でも使えますか

既定では管理者ロールだけです。他のロールに開放するには、sys_ui_context_menu の条件を編集し、対象ロールを持つユーザーにメニュー自体を見せる必要があります。編集を誤ると想定外のロールにまで見えてしまうため、条件式は絞り込んで書きます。

Show XML の画面で値を直接編集できますか

編集はできません。Show XML は表示専用で、値を書き換える手段は提供していません。値を変更したい場合は、通常のフォームやスクリプト、Table API などの更新用インターフェースを使います。

一覧の?XMLとShow XMLはどちらを使えばよいですか

対象が1件なら Show XML、複数件をまとめて突き合わせたいなら一覧の ?XML が向いています。1件ずつ内容を細かく確認したい場面と、傾向や差分をまとめて見たい場面とで使い分けます。

XMLに出てきたsys_idから元のレコードを開くには

対象テーブルの URL に sys_id パラメータを付けて開けば、そのレコードのフォームに直接アクセスできます。テーブル名さえ分かれば、一覧から検索する手間を省けます。

Next Experienceやワークスペースでも同じ確認ができますか

右クリックメニュー自体が出ないため、Show XML と同じ操作はできません。同じ内容を確認したい場合は、URL に ?XML を付ける方式に切り替えます。ワークスペース側に相当する代替機能があるかどうかは、この記事では確認していません。

検証範囲外のこと

• sys_ui_context_menu の86件それぞれの条件式は、件数の確認にとどめ、個別には見ていません

• Next Experience やワークスペースに、Show XML に相当する代替機能があるかどうかは確認していません

• JSONv2 の認証方式や、大量レコードを取得したときの挙動は確認していません

• 項目数が多いテーブルで Show XML を開いたときの表示速度は計測していません

• ジャーナルフィールドや添付ファイルが出ない挙動は incident テーブルで確認したもので、他のテーブルでの挙動は個別に確認していません

• フィールドレベル ACL による非表示の挙動は、一般的な仕組みとしての説明にとどめ、個別の設定パターンごとの検証はしていません

用語の整理

• sys_dictionary: テーブルの列（フィールド）の定義を持つテーブル。列名・型・参照先などを管理する

• sys_id: レコードを一意に識別する32文字の値。参照フィールドが格納するのもこの値

• ジャーナルフィールド: work_notes や comments のように、入力履歴を積み重ねる型のフィールド。実データは sys_journal_field に別レコードとして残る

• sys_ui_context_menu: フォームや一覧の右クリックメニューの項目を定義するテーブル。Show XML もここで定義されている

• sys_ui_view: フォームやリストのビュー定義を持つテーブル。同じレコードでも見え方を切り替えられる

• JSONv2: XML と同じ考え方で、JSON 形式のレスポンスを返す簡易な Web サービス

まとめ

フォームは見え方の1つにすぎません。基準はレコードの値そのものです。同じレコードでもフォームやビューが変われば見た目は変わりますが、Show XML が返すのは、それらとは無関係にレコードが持っている値そのものです。ジャーナルフィールドや添付ファイルのように、そもそもレコード自身の列ではない情報は、Show XML を開いても出てきません。出るもの・出ないものの境界を知っておくと、画面だけでは判断できない場面で迷わずに済みます。