ServiceNowのインジケータは履歴をどう持つ？ Data SnapshotsとCDCの除外リストを実機で読む

Performance Analytics で「先月と比べてどうか」を出したい。ところが過去のデータがどこに溜まるのかが分かりません。ServiceNow には Data Snapshots という仕組みがあり、集計元テーブルの変更を定期的に取り込んでインジケータのスコアを計算します。この仕組みには、集める対象を絞る2つのテーブルが付いていました。Australia の PDI を開いて、何が集められて何が捨てられるのかを追います。

「先月と比べてどうか」を出すために必要なもの

KPI を見るとき、いちばん知りたいのは変化です。今の件数より、先月からどう動いたか。

これを出すには過去の値が要ります。その時点の集計値が残っていなければ、後から再現するのは重いからです。監査ログを全部たどって当時の状態を組み立てる、という計算になります。

Data Snapshots は、この問題に「時点ごとの集計値を保存しておく」という答えを出した仕組みです。

既存の履歴の仕組みとの違い

ServiceNow には履歴を持つ仕組みが既にあります。混同しやすいので位置づけを整理します。

監査履歴（sys_audit）はレコード単位です。どのフィールドがいつ何から何に変わったかを1行ずつ記録します。

アクティビティ表示（sys_history_line）は表示単位。監査データを読みやすくまとめ直したものです。

Data Snapshots は集計単位でした。1レコードの変遷ではなく、集計した結果を時点ごとに保存します。「先週の月曜に未解決だったのは何件か」に答えられるのはこれだけです。

3つは目的が違うので、どれかがあれば足りるという関係ではありません。

公式が語る狙いは「制限の解除」

プラグイン com.snc.pa.mlb の説明に、この機能の目的が書かれていました。

automated と formula のインジケータで有効化でき、指定した集計元テーブルから定期的にスナップショットを取る。それを使って履歴に基づくスコアを計算する、という内容です。

そのあとが本題でした。Data Snapshots を有効にすると、インジケータが複数のブレークダウンとフィルタリングに対応し、それまで2階層までだったブレークダウンの制限が外れると書かれています。

現場では「カテゴリ別かつ拠点別かつ担当グループ別で見たい」という要望が出ます。これは3階層です。その制約を外すために履歴の持ち方を変えた、というのが公式の説明から読み取れる狙いになります。

結論：仕組みは入っているが、収集ジョブは止まっている

この機能の状態は、3つの数字で言い表せます。

ひとつ、Data Snapshots のプラグインは Zurich では無効で、Australia では有効になっていました。同じ OOTB でも状態が違います。

ふたつ、この仕組みには「集めないテーブルの一覧」が1,955件入っていて、その全部が sys_ で始まります。何を集めるかより先に、何を集めないかが決まっています。

みっつ、収集ジョブは3本ありますが、実機ではすべて無効でした。プラグインが有効でも、データは流れていません。

Zurich では無効だったプラグインが有効になっている

com.snc.pa.mlb というプラグインIDを持つ Data Snapshots が、この機能の本体です。

2つの PDI で状態を比べると、Zurich では inactive、Australia では active でした。プラグイン自体は前から存在していて、既定で有効になったのが変化点です。

プラグインの説明文には、ServiceNow 自身の言葉でこう書かれています。automated と formula の2種類のインジケータで有効化でき、指定した集計元テーブルから定期的にスナップショットを取る。そのスナップショットを使って、時系列の履歴に基づいたスコアを計算する。

説明文の後半に、もっと具体的な話があります。Data Snapshots を有効にすると、インジケータが複数のブレークダウンとフィルタリングに対応し、それまで2階層までだったブレークダウンの制限が外れるとあります。これが機能追加の狙いです。

分析の切り口を深くしたいという要望に対して、履歴の持ち方を変えることで応えた形になります。

収集ジョブは3本あって、実機では全部止まっている

sysauto_dm_cdc_collector に3件のレコードがあります。クラスは Scheduled Data Collection で、パッケージは Data Snapshots Model です。

Active 列を見ると、3件とも false です。

役割は説明文から読み取れます。First snapshot は集計元テーブルの現在の状態を最初に1回だけ取り込むもの。セットアップ時に一度動いて日次更新の下地を作る役です。Incremental daily snapshot は直近24時間の変更を集め、集計元のタイムゾーンに従って1日1回スコアを更新します。Incremental all changes snapshot は現時点までの全変更を集めて保存する役割でした。

実行間隔がばらついているのも特徴です。1時間ごとが2本、30分ごとが1本。日次の更新をするジョブが1時間おきに動くのは、24時間ぶんの変更を細かく拾っておき、スコア確定は1日1回にするという設計だと読めます。

作成日を見ると3本の来歴が違います。Incremental daily snapshot が2021年、First snapshot が2024年、Incremental all changes snapshot が2025年。段階的に足されてきた機能です。

何を集めないかが先に決まっている

この仕組みで面白いのは、対象の絞り込み方です。

除外リストは1,955件

pa_cdc_exclusions というテーブルに、除外するテーブル名が並んでいます。件数は1,955件。持っているフィールドは table だけで、テーブル名を1行ずつ挙げただけの単純な作りです。

1,955件の接頭辞を数えると、sys_ が1,955件でした。それ以外の接頭辞は1件もありません。 業務テーブルは1つも除外されていないことになります。

sys_db_object で sys_ から始まるテーブルを数えると2,090件でした。つまり除外リストは、プラットフォーム内部のテーブルをほぼ丸ごと対象外にしています。

理屈は通ります。インジケータで測りたいのはインシデントや変更やタスクの動きであって、更新セットの中身やUIポリシーの定義ではありません。内部テーブルを最初から外しておけば、集計元の候補が業務側に絞られます。

除外されていない157件を追う

2,090から1,955を引くと157件残ります。この157件が何なのかを確かめました。

内訳は、末尾が4桁の数字になっているシャード実体が139件、通常のテーブル名が18件でした。sys_activity0000 のように連番が付いたものは、大量データを分割して格納する実体テーブルです。

残る18件を並べると傾向が見えます。sys_flow_log / sys_history_line / sys_scheduler_job_history / sys_outbound_http_log / sys_notification_execution / sys_rollback_log / sys_export_set_log / sys_client_interaction / sys_kafka_unprocessed_messages。すべてログ・履歴・キュー系でした。

さらに調べると、sys_activity は親テーブル名が除外リストに入っているのに、この18件の親は入っていませんでした。同じシャード分割されるログ系なのに、扱いが揃っていません。

意図的な線引きなのか、列挙から漏れたのかは、この環境からは判断できません。ただ実務上の影響は小さいと考えています。除外リストに載っていなくても、そのテーブルを集計元に選ぶ理由がそもそも無いからです。

集められるフィールド型は25種類だけ

もうひとつの絞り込みが pa_cdc_supported_fields です。25件のレコードがあり、こちらも field というフィールドを1つ持つだけの単純な構造でした。

中身を分類するとこうなります。

日付と時刻の型が10種類と多いのが目立ちます。glide_date / glide_date_time / glide_time / glide_utc_time / calendar_date_time / integer_date / insert_timestamp / glide_duration / date / due_date。履歴を時系列で持つ仕組みなので、時間の表現を取りこぼさない作りにしたのだと読めます。

対応していない型のほうが圧倒的に多い

ServiceNow のフィールド型は sys_glide_object に定義されていて、この環境では160件ありました。詳しくはフィールドの「型」の正体（sys_glide_object）で扱っています。

対応25種類に対して、定義は160種類。差し引き135種類は対象外です。

落ちているものを見ると納得できます。script / css / conditions / condition_string / data_object / data_structure / encrypted / password2 / audio / catalog_preview。スクリプト本体や暗号化フィールドを時系列で持っても、集計には使えません。

一方で choice が対象外なのは意外でした。選択肢フィールドは集計の切り口としてよく使うものです。ただし choice_table は対象に入っているので、選択肢の扱いは別経路で拾われていると考えられます。選択肢の仕組みそのものは選択肢Choice（sys_choice）：ドロップダウンの中身を参照してください。

409件のインジケータ定義との関係

pa_indicators_definition に409件のレコードがあります。pa_indicators も同じ409件で、同じ実体を指していると見られます。

タイプ別に分けると Automated が303件、Formula が106件でした。プラグインの説明文にあった対象は「automated and formula indicators」なので、409件すべてが型としては Data Snapshots の対象になります。

他の項目の分布も見ておきます。頻度は Daily が407件で、Monthly はわずか2件。方向は Minimize が184件、None が158件、Maximize が67件。集計方法は Count が268件で最多、Sum が91件、Count Distinct が40件と続きます。単位は件数を表す # が273件、パーセントが60件、時間が29件、日が25件でした。

Minimize が Maximize の2.7倍あるのは、KPI の性格を表しています。インシデント件数、滞留時間、再オープン率。ITSM で測る指標の多くは、減らしたいものです。指標設計の考え方はServiceNowのPerformance Analyticsは何を測る？ 指標設計を5つのテーブルで決める手順にまとめています。

409件をそのまま使うのか、絞るのか

標準で409件のインジケータ定義が入っています。全部を有効にして回す運用は現実的ではありません。

頻度を見ると407件が Daily でした。仮に全件を日次で回すと、毎日409回ぶんの集計が走ります。デモ環境なら問題になりませんが、本番の件数で同じことをすると負荷が読めません。

実務では測る指標を先に決め、必要なものだけを動かす形になります。409件は「候補のカタログ」として見るのが正しい距離感でしょう。名前と条件を読めば、自分たちが測りたいものに近い定義が見つかります。

方向の分布も参考になります。Minimize が184件、None が158件。None が4割近くあるのは、良し悪しの向きを決めていない指標が多いという意味です。件数を数えるだけの指標には、増えたほうが良いとも悪いとも言えないものが含まれます。

ServiceNowが持っている「履歴」は1種類ではない

Data Snapshots を理解するとき、既にある履歴の仕組みと並べると位置づけがはっきりします。

監査履歴は sys_audit に入ります。どのレコードのどのフィールドが、いつ誰によって何から何に変わったかを1行ずつ記録するものです。詳しくはServiceNowの変更履歴はどこに残る？ sys_auditと監査対象フィールドを実機で確認で扱いました。

画面のアクティビティ表示に使われるのは sys_history_set と sys_history_line です。監査データを読みやすい形にまとめ直したもので、性格としてはキャッシュに近い作りでした。この構造は履歴セット（sys_history_set）はActivity表示のキャッシュに書いています。

Data Snapshots はこのどちらとも違います。1レコードの変遷を追うのではなく、集計した結果を時点ごとに保存する仕組みです。「先週の月曜日に未解決だったインシデントは何件だったか」を後から出せるのは、その時点の集計値が残っているからになります。

3つの違いを一言で言えば、sys_audit はレコード単位、sys_history_line は表示単位、Data Snapshots は集計単位です。目的が違うので、片方があれば片方が要らないという関係ではありません。

集計値を持つとなぜ有利なのか

過去の状態を後から計算しようとすると、監査ログを全部たどることになります。1件のインシデントの状態変化を追うだけならできますが、ある時点の全件の内訳を出すには全レコードの履歴を再生する必要があります。

現実的な件数ではこの計算が重くなります。最初から時点ごとの集計値を持っておけば、読み出すだけで済む。設計として素直です。

代わりに、後から切り口を足せないという弱点があります。集計してしまうと、集計に使わなかった軸では分解できません。ブレークダウンの階層数に制限があったのは、この事情によるものだと考えられます。

除外リストを更新セットで運ぶときの注意

pa_cdc_exclusions は普通のテーブルなので、行を足したり消したりできます。ここに手を入れる場面は多くないはずですが、触るなら気をつける点があります。

まず1,955件という規模です。この一覧はプラットフォーム側が持っている定義で、バージョンが上がれば内容も変わります。新しいテーブルが増えれば除外リストにも追加されるはずです。自分で行を足すと、次のアップグレードで差分が発生します。

次に、除外リストは「集計元に選べない」という制約として働きます。誤って業務テーブルを追加すると、そのテーブルを使ったインジケータが作れなくなります。原因が除外リストにあると気づくまでに時間がかかる種類の障害です。

実務では、まず読むだけにしておくのが無難でしょう。集計元に選べないテーブルが出てきたときの調査先として覚えておけば十分です。

シャード実体139件から見えること

除外リストに載っていなかった157件のうち、139件が末尾4桁の連番テーブルでした。この存在自体が、ServiceNow の内部の作りを教えてくれます。

sys_activity0000 から sys_activity0015 まで16本。sys_amb_message0000 から 0006 まで7本。sys_client_interaction は8本に分かれています。同じ役割のテーブルを番号で分割して、書き込みを分散させる構造です。

分割されているのはどれも書き込み量が多いものでした。メッセージング、クライアント操作、ジョブ履歴、フローのログ。1本のテーブルに全部入れると肥大するので、最初から複数に割っておく設計になっています。

ログ系テーブルの溜まり方はシステムログ（syslog）の読み方と溜まり方でも触れました。運用が続くほど行数が増える種類のテーブルは、分割か削除の仕組みが要ります。

除外リストが親名だけを持つ理由

シャードの実体が除外リストに無いのは、親名だけ書けば足りるからだと考えられます。集計元テーブルを選ぶ画面に sys_activity0007 のような実体が並ぶことは、通常ありません。選択肢に出てくるのは親の名前です。

そう考えると、除外リストの1,955件は「選択肢に出てくる可能性がある内部テーブルの一覧」と読むのが正確でしょう。全テーブルを網羅するリストではありません。

ただし前に書いた18件の説明が付きません。sys_flow_log や sys_scheduler_job_history は親名なのに載っていない。ここは仕様として確認できていないので、そのまま事実として置いておきます。

この機能をひとことで言うと

Data Snapshots は、インジケータのスコアを「その時点の集計値」として保存する仕組みです。集計元テーブルの変更を定期的に拾い、時系列で積み上げます。

拾う対象は2つの条件で絞られます。ひとつは除外テーブルの一覧で、内部テーブル1,955件が対象外。もうひとつは対応フィールド型で、160種類のうち25種類だけが扱えます。

動かすのは3本の収集ジョブですが、実機では全部が無効でした。プラグインが有効になっただけの状態です。

得られるものは、ブレークダウンの階層制限が外れることによる分析の自由度でした。2階層までという制約で諦めていた切り口があるなら、検討する価値があります。

集計方法で見ると Count が268件で最多でした。件数を数えるだけの指標が3分の2を占めます。合計や平均より、まず数を追う設計です。

用語

Data Snapshots：集計元テーブルの状態を定期的に取り込み、履歴としてためる仕組み。プラグインID は com.snc.pa.mlb。

CDC：Change Data Capture の略。変更された分だけを拾って取り込む方式を指す。この機能ではテーブル名が pa_cdc_ で始まる。

集計元テーブル：インジケータのスコアを計算する元になるテーブル。プラグイン説明文では fact table と表記されている。

ブレークダウン：インジケータを切り口ごとに分解する軸。優先度別、担当グループ別といった見方を作る。

インジケータ：測定する指標の定義。Automated は条件に当てはまる件数を数える型、Formula は他のインジケータを組み合わせて計算する型。

実機を見て気づいたこと

除外リストが「全部 sys_」で揃っているのは珍しい

1,955件を接頭辞で数えたとき、例外が1件も無かったのは予想外でした。この種の一覧は運用のなかで例外が混ざりがちです。業務テーブルを名指しで外したくなる場面もありそうなものですが、そうなっていません。

判断基準を「内部テーブルかどうか」の一点に絞ったから、これだけ綺麗に揃ったのだと考えています。基準が単純だと、後から誰が触っても崩れにくくなります。

プラグインが有効でも、ジョブは止まったまま

有効化されたと聞くと動き出した気がしますが、実機のジョブは3本とも false でした。プラグインの有効化は「使える状態になった」であって「使っている」ではありません。

これは Data Snapshots に限った話ではありません。定期実行の仕組みは定義と実行が分かれているので、定義があることと動いていることは別です。定期実行（sysauto_script）：定義と実行キューの2層で扱った構造と同じ考え方になります。

新機能を評価するときは、プラグインの状態とジョブの状態を別々に見る必要があります。

対応フィールド型に日付が10種類も入っている

25種類のうち10種類が日付・時刻でした。全体の4割です。

最初はもっと数値型が多いと思っていました。集計というと合計や平均を思い浮かべるからです。実際には「いつ変わったか」を持てないと履歴のスナップショットが成立しないので、時間の表現を厚くするほうが理にかなっています。

この配分を見てから、Data Snapshots が「集計の機能」ではなく時系列を持つための機能だと理解できました。

実務では何に使えるか

有効化する前に見る3つの場所

自分の環境で Data Snapshots を使うか判断するとき、順番に見る場所があります。

まずプラグインの状態です。バージョンによって既定が違うので、com.snc.pa.mlb が有効かどうかを先に確かめます。Zurich と Australia で違っていたように、環境ごとに前提が変わります。

次に収集ジョブです。3本の Active を見て、実際にデータが流れているかを確認します。止まっているなら、そこから先の話は成り立ちません。

最後に測りたい指標の型です。Automated か Formula なら対象になります。使いたいフィールドの型が25種類に入っているかも、あわせて見ておきます。

除外リストは自分の環境でも確認できる

pa_cdc_exclusions はただのリストなので、リストビューを開けば中身が読めます。集計元にしたいテーブルが除外されていないかを検索すれば、それだけで判断が付きます。

カスタムテーブルを集計元にしたい場合、この確認は特に有効です。u_ で始まる独自テーブルは除外リストに載っていないので、対象にできます。

ブレークダウンの制限が外れる意味

従来はブレークダウンが2階層までという制約がありました。優先度別、そのなかで担当グループ別、までは作れても、さらに細かい軸を足せません。

現場でよくあるのは「この3つを掛け合わせて見たい」という要望です。カテゴリ別かつ拠点別かつ担当グループ別、といった見方は3階層になります。この制約が外れるなら、レポートで作っていた分析をインジケータ側に寄せられる場面が出てきます。

既存のレポートとダッシュボードの関係はダッシュボードは1枚のレコードじゃない（pa_dashboards）で扱いました。グラフ定義が新旧2系統に分かれている話はServiceNowのグラフ定義はどこに入る？にあります。

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

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

• 収集ジョブ：/sysauto_dm_cdc_collector_list.do

• 対応フィールド型：/pa_cdc_supported_fields_list.do?sysparm_query=ORDERBYfield

• 除外テーブル：/pa_cdc_exclusions_list.do?sysparm_query=ORDERBYtable

• インジケータ定義をタイプ別に見る：/pa_indicators_definition_list.do?sysparm_query=GROUPBYtype

• フィールド型の一覧：/sys_glide_object_list.do

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINpa_cdc_supported_fields,sysauto_dm_cdc_collector^hintISNOTEMPTY

• プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=descriptionISNOTEMPTY

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-10 に確認しました。件数はこの環境の実測値です。

確認していないことを挙げておきます。Data Snapshots は有効化していません。収集ジョブは3本とも無効のままにしてあり、設定変更を加えずに読み取りだけで調べました。スナップショットが実際にどのテーブルへ書き込まれるかは追えていません。

本番環境での既定値や件数も確認していません。プラグインの有効・無効はインスタンスの契約内容や導入経緯で変わります。

除外リストからログ系18件が漏れている理由も、仕様として確認できていません。観察できた事実と、そこからの解釈を分けて書きました。

関連記事

• フィールドの「型」の正体（sys_glide_object） — 対応25種類の母数になる160種類の話

• ServiceNowのPerformance Analyticsは何を測る？ 指標設計を5つのテーブルで決める手順 — インジケータをどう設計するか

• ServiceNow標準ダッシュボード全体像：どんなダッシュボードがあるか — 測った結果をどこに出すか