ServiceNow Australiaで増えた340テーブル、中身があるのは何件？ 全件カウントで実測する

バージョンが上がるとテーブルが増えます。ただ「340個増えた」と言われても、どこから見ればいいのか分かりません。Zurich と Australia の2つの PDI を持っているので、新しく増えた291テーブルすべてにレコード数を数えました。結果は、中身があるのが104件。そのうち内部テーブルを除くと56件でした。

メジャーアップグレードで本当に知りたいこと

新しいバージョンの案内を見ると、機能の名前が並びます。ただ担当者が知りたいのはその手前です。

自分たちが使っている領域に手が入ったのか。入ったとして、すぐ試せる状態なのか。そして検証にどれだけ時間がかかるのか。

「340テーブル増えた」という数字は、この3つのどれにも答えません。数の大きさと影響の大きさは別だからです。

テーブルの増減で影響を測るという方法

機能の追加は、たいていテーブルの追加を伴います。設定を保存する場所、ログを残す場所、関係を持つ中間テーブル。

だから新しく増えたテーブルの一覧は、追加された機能のほぼ全量になります。リリースノートより網羅的です。しかも自分の環境で直接確認できるので、書いてある通りかどうかを疑う必要がありません。

必要なのは比較対象です。旧バージョンの環境が残っていれば、テーブル名の集合差を取るだけで一覧が出ます。全体の比較はZurichとAustraliaを並べて数えたら何が変わっていたかにまとめました。

名前から性格を読む3つの手がかり

増えたテーブルを1つずつ開くのは現実的ではありません。名前と定義から絞り込みます。

接頭辞が機能を表します。sys_ は基盤。sn_ はスコープ付きアプリ。pa_ は分析で、dp_ はデータプライバシー。自分たちが使っている領域の接頭辞だけを見れば足ります。

継承元がテーブルの性格を表します。Application File を継承していれば更新セットで運ばれる設定系、Log Entry ならログ、Scheduled Job なら定期実行。継承していなければ純粋な参照データです。

レコード数が状態を表します。0件なら箱だけ。値が入っていれば標準データが同梱されています。この記事はここを全件測りました。

結論：340テーブル増えて、読む価値があるのは56件

3段階で絞り込むと、こうなります。

340件のうち49件は内部のシャード実体でした。分割して保存するための実体テーブルで、中身を読む意味がありません。除くと291件です。

291件を数えると、レコードがあるのは104件、0件が187件。6割以上が空でした。

104件のうち48件は ts_ で始まる内部テーブルです。差し引くと、業務的に読める新テーブルは56件。340件のうち16%になります。

どうやって数えたか

docs/snapshots に取ってあった2つの環境のスナップショットから、Australia にだけあるテーブル名を340件抽出しました。

そこから2種類を除きます。末尾が4桁の数字になっているシャード実体が8件、ts_c_ で始まる内部シャードが41件。この49件は同じ役割のテーブルが番号で分かれているだけです。

残る291件に対して、1件ずつレコード数を数えました。逐次実行なので時間がかかります。2分では終わらなかったため、バックグラウンドで走らせました。

前提となるテーブル数の比較そのものはZurichとAustraliaを並べて数えたら何が変わっていたかにまとめています。この記事はその続きで、増えたテーブルの中身に踏み込んだものです。

6割以上が空だった

291件のうち、レコードが1件以上あるのは104件。残る187件は0件でした。予想より空が多い。

64%が空。新しいテーブルが増えても、そのほとんどには何も入っていません。箱だけ先に届いた状態だと言えます。

空でも意味がある

0件だからといって、無駄なテーブルではありません。使い始めたときに入る箱です。

たとえばログ系のテーブルは、機能を有効にして初めて行が増えます。設定を保存するテーブルも、設定しなければ空のままです。

空のテーブルは「これから使えるもののリスト」として読めます。名前を眺めるだけで、何ができるようになったかの手がかりになります。

内部テーブルを除く必要がある

レコードがある104件のうち、48件が ts_ で始まっていました。ts_v4_16_9 のような名前で、数千件のレコードを持つものもあります。

内部の処理で使われるものです。中身を読んでも業務的な意味は取れないので、除外して考えます。名前に版数らしき数字が入っているのも、利用者向けではない証拠と見ています。

残る56件が、この記事で言う「読める新テーブル」です。

機能ごとに温度差がある

接頭辞で分けると、機能ごとの差がはっきり出ました。

analytics_ は4件中4件。chg_ は3件中3件。どちらもデータが入っていて、入れたら即使える状態でした。

一方 qc_（クエリキャッシュ）は4件中0件。cmdb_ も3件中0件でした。定義だけ入って、まだ使われていません。テーブルを開いても、見出しの行だけが表示されます。

母数が大きいのは sys_ と sn_

新しく増えた291件のうち、sys_ が76件、sn_ が58件で、この2つが半分近くを占めます。

ところがデータがあるのは sys_ で11件、sn_ で13件だけ。率にすると14%と22%です。

sys_ はプラットフォーム基盤、sn_ はスコープ付きアプリの領域です。基盤に箱だけ増やして、中身は環境ごとに入るという構造が見えます。

pa_ が8%しかないのは意外だった

pa_ は Performance Analytics の接頭辞。34件も増えているのに、データがあるのは3件だけでした。

promin_（プロセスマイニング）も7件中1件です。分析まわりは箱が先に増えて、中身は後から入る形になっています。

dp_ が53%と高い

逆に高かったのが dp_（データプライバシー）です。15件中8件にデータがあります。

個人情報の検出パターンが32件、匿名化の技法が9件。標準で使える状態のものが最初から入っています。

新機能のなかでも、すぐ試せるものとそうでないものがある。この差が率に出ました。

中身があっても件数は少ない

56件の合計レコード数は5,551件でした。1テーブルあたり平均100件ほどです。

ただし平均は当てになりません。分布を見ると偏りが大きいためです。

1,000件以上が1件。100〜999件が6件。10〜99件が12件。そして1〜9件が37件でした。3分の2が1桁です。定義データをいくつか置いてあるだけ、という状態のテーブルが大半を占めていることになります。

1件しかないテーブルが7つある

レコードが1件だけのテーブルが7件ありました。設定のひな形が1つ入っているだけです。テーマの派生、画面部品の派生、問い合わせのヘルプ要請設定。名前を見ると、いずれも「1つ作ってみせた」形をしています。

見本として1件置いてあるパターンでしょう。自分で作るときの参考になります。

上位はどれも調べる価値がある

件数の多いものを並べると、この環境で何が動いているかが見えます。

1位は変更収集の除外リストで1,955件。2位と3位は標準グラフの定義とメタデータで766件ずつ。

言語定義が519件、分析資産のビューが502件、指標の定義が409件と続きます。

上位6件で全体の8割を占めます。残り50件は100件未満です。

率が高かった4つの機能を個別に見る

データあり率の高い順に、何が入っているかを確認しました。

dp_（データプライバシー）は8/15

個人情報を検出して隠す仕組みです。検出パターンが32件、匿名化の技法が9件、技法のパラメータが18件。

標準で使える状態のものが揃っています。プラグインを有効にすれば、すぐ試せる作りです。

中身はServiceNowでAIに個人情報を渡さない設定はどこにある？で詳しく追いました。32パターンが何を検出するかが分かります。

sttrm_（状態遷移テンプレート）は4/7

変更申請のテンプレートに関わるテーブル群です。ひな形が7件、フィールドの制御が9件。

こちらも標準のテンプレートが入っていて、中身を読めます。ServiceNowの変更申請テンプレートには切り戻し手順まで入っている？で扱いました。

analytics_（新しい分析基盤）は4/4

4件すべてにデータがあります。標準グラフの定義が766件、ダッシュボードが28件。

ただし件数が多いことと使われていることは別でした。グラフの新旧2系統が併存している話はServiceNowのグラフ定義はどこに入る？にまとめています。

chg_（変更管理）は3/3

変更テンプレート、子レコードのテンプレート、テンプレートの指標。3件とも少ない件数ですが、全部に中身があります。

3件で合計9件のレコードです。見本が置いてある状態で、実運用では自分たちで足すことになります。

接頭辞で絞ると、その機能が持つテーブルが一覧できます。名前を眺めるだけで役割の見当が付く。全部の中身を開かなくても、何を入れる箱なのかは判別できます。

0件の187件をどう扱うか

空のテーブルが6割を占めます。ここをどう読むかで、調査の効率が変わります。

名前から役割を推測する

テーブル名には規則があります。接頭辞で機能が分かり、その後ろで役割が分かります。

_config や _configuration で終わるものは設定の置き場。_log はログ。_m2m は中間テーブル。名前だけで見当が付きます。

空でも名前は情報を持っています。 全部の中身を確認しなくても、機能の輪郭はつかめます。

有効化すると埋まるものを見分ける

0件のテーブルには2種類あります。設定すれば埋まるものと、動かせば埋まるものです。

設定系は自分で行を作ります。ログ系は機能が動けば自動で増えます。どちらかは名前から判断できる場合が多いと感じました。

数え直すことに意味がある

半年後に同じ調査をすれば、どこが埋まったかが分かります。

空だったテーブルに行が入っていれば、そこで何かが始まったということです。誰かが設定したか、機能が動き始めたか。変化の起点を見つけられます。

テーブルの定義そのものを読む方法はServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読むにまとめました。列の構成まで確認したいときに使えます。

数える前に決めておくこと

同じ調査を自分の環境でやるなら、先に決めることがあります。

何を除外するか

今回はシャード実体と ts_c_* を除きました。この判断で、340件が291件になっています。

除外の基準を決めておかないと、数字が動きます。除外した数と理由を必ず記録しておく必要があります。この記事でも、340 / 291 / 104 / 56 の4つの数字を全部書いているのはそのためです。

どのタイミングで数えるか

導入直後、プラグインを入れた直後、半年後。数えるタイミングで結果が変わります。

比較したいなら、条件を揃える必要があります。今回は素の PDI どうしなので、デモデータの差はありますが設定の差はありません。

数える範囲

全テーブルを数えると時間がかかります。新しく増えたものに絞れば291件で済みました。

差分を先に取ってから数える。この順番だと現実的な時間で終わります。

数字を並べて見えること

340 / 291 / 104 / 56。この4つが調査の全部です。

340から291は、内部構造を除いた数。291から104は、使われているかどうか。104から56は、読む価値があるかどうか。

3段階で絞り込むと、最後に残るのは6分の1でした。メジャーアップグレードの影響を測るとき、この比率は覚えておく価値があります。

大きな数字に引っ張られない

340という数字だけを見ると、大きな変化に思えます。実際に確認すべきは56件でした。

リリースの規模を語るときは、増えたテーブル数ではなく、使えるようになった機能の数を数えるほうが実態に近いでしょう。

権限まわりのように層が多い仕組みでも、同じことが言えます。ServiceNowで権限はどこで決まる？で7つの層を追いましたが、実際に触るのはそのうち2つか3つです。

次に何を調べるか決まる

56件のリストがあれば、次の調査対象が決まります。件数の多いものから順に見ていけばよい。

上位6件で全体の8割。そこを押さえれば大半をカバーできます。残り50件は必要になったときに見ます。

全部を調べる必要はありません。 数えた結果そのものが優先順位になりました。順番に迷わなくなったのが、この調査でいちばん助かった点です。

前のバージョンとの比較で分かること

2つの環境を持っていると、こうした調査ができます。片方だけでは「増えた」が分かりません。

差分を取るのが先

まずテーブル名の一覧を両方から取ります。集合の差を取れば、増えたものと消えたものが出ます。

今回は新規340件、消失204件でした。消えたほうも同じように数える価値がありますが、消えた環境ではもう数えられません。古いほうが生きているうちに取っておく必要があります。

消えたテーブルの扱い

204件が消えたと言っても、機能が廃止されたとは限りません。プラグインが既定で無効になっただけの場合もあります。

実際、オンコール当番や権限委任の機能は、プラグインが無効になっていました。テーブルが読めなくなっただけで、有効にすれば戻ります。

消えた＝廃止と決めつけない。 プラグインの状態を必ず合わせて見ます。

数字を記録に残す

今回の調査結果はファイルに保存しました。次のバージョンで同じことをやるとき、比較対象になります。

数字だけでも残しておけば、後から傾向が見えます。3世代ぶん溜まれば、どの機能が育っているかが分かるはずです。

分析まわりの指標がどう設計されるかはServiceNowのPerformance Analyticsは何を測る？にまとめました。自分の環境の変化を測るときも、考え方は同じです。

上位6件が何を表しているか

合計5,551件のうち、上位6件で8割を占めます。この6件を並べると、Australia で何に力が入ったかが読めます。

分析まわりが3件

766件のグラフ定義、766件のメタデータ、409件の指標定義。上位6件のうち3件が分析関連でした。

数だけ見れば、分析基盤への追加がいちばん大きい。ただし pa_ のデータあり率は8%でした。件数は多いが、テーブルの種類としては使われていないという、ねじれた状態です。

既存のダッシュボードがどう構成されているかはダッシュボードは1枚のレコードじゃない（pa_dashboards）で扱いました。新旧の対応を考えるときの前提になります。

除外リストが1位

いちばん多いのが1,955件の除外リストです。変更収集の対象から外すテーブルを並べたもので、全部が sys_ で始まります。

設定データではなく、製品が持っている固定のリストでした。環境ごとに変わるものではありません。

件数が多いから重要とは限らない例です。1,955件あっても、読むべきは「全部 sys_ である」という1点でした。

言語定義が519件

core_language の519件は、言語と地域の組み合わせです。こちらも製品が持つ参照データになります。

実際に使える言語は1件でした。カタログの件数と、使える件数は別物です。

上位に業務データが1件も無い

6件を眺めて気づくのは、業務レコードが1つも無いことです。全部が定義データか参照データでした。

新しいテーブルが増えるとき、まず入るのは定義です。業務データはその後、使い始めてから増えます。

素の環境を数える意味はここにあります。定義だけの状態を先に把握しておけば、後から増えた分が自分たちのデータだと分かります。

この調査に使ったもの

特別なツールは使っていません。REST API でテーブル定義とレコード数を取っただけです。

使ったのは2つのAPI

テーブル一覧は sys_db_object から取れます。レコード数は集計のクエリで1件ずつ数えました。

どちらも読み取りだけです。設定を変えずに調べられるのが、この方法の利点になります。本番環境でも同じことができます。

時間がかかる点だけ注意

291件を順に数えると数分かかりました。1件あたり1秒前後です。

まとめて取る方法もありそうですが、素直に順番に回すほうが確実でした。途中で止まっても、どこまで数えたかが分かります。

結果をファイルに残す

数えた結果はテキストファイルに保存しました。件数とテーブル名を並べただけです。

次に調べるときの出発点になります。同じ環境で数え直せば差分が出ますし、別の環境で取れば比較できます。

データあり率57%だった状態遷移テンプレートです。7件のひな形が読める状態で入っていました。

用語

シャード実体：大量データを分割して保存するための実体テーブル。末尾に連番が付く。

接頭辞：テーブル名の頭に付く区分。sys_ は基盤、sn_ はスコープ付きアプリ、pa_ は分析。

スコープ：アプリケーションの区切り。sn_ で始まるものは特定のアプリに属する。

データあり率：その接頭辞のテーブルのうち、レコードが1件以上あるものの割合。

実機を見て気づいたこと

「増えた数」は判断材料にならない

340テーブル増えたと聞くと、大きな変化に思えます。実際に読む価値があるのは56件でした。

6分の1。数字の大きさと、実務への影響は比例しません。

リリースノートで機能の数を見るときも同じでしょう。数えるべきは、自分の環境で実際に動くものの数です。

率を見ると機能の成熟度が分かる

analytics_ が100%で qc_ が0%。この差は偶然ではないと考えています。

すぐ使える状態で出荷されている機能と、枠だけ用意された機能がある。データあり率は、その機能がどこまで作り込まれているかの目安になります。

新機能を評価するとき、テーブルの数より率を見るほうが判断しやすいと感じました。

全件数えるのは思ったより現実的だった

291件のカウントは、逐次実行で数分かかりました。手作業では無理ですが、機械なら回せます。

一度数えておくと、次の調査が速くなります。「あのテーブルは何件だったか」を毎回調べ直さずに済みます。

調べる前に全体を数えるという順番が、今回は効きました。素材の多いテーブルから手を付けられます。

実務では何に使えるか

アップグレード前の影響調査

新しいバージョンで何が増えるかを調べるとき、この方法が使えます。

まずテーブル名の一覧を取り、接頭辞で分類します。自分たちが使っている機能の接頭辞に増減があるかを見ます。

pa_ が34件増えていれば、分析まわりに手が入ったと分かります。使っていない機能なら、影響は小さいと判断できます。

プラグインの有効・無効と合わせて見ると精度が上がります。プラグイン（v_plugin/sys_plugins）の有効・無効と依存で扱った方法と組み合わせます。

検証する機能に優先順位を付ける

新機能を全部試す時間はありません。データあり率で順番を決められます。

率が高いものは、標準で試せる状態です。すぐ画面を開いて確認できます。

率が0%のものは、設定から始める必要があります。時間がかかるので後回しにできます。

空のテーブルを「これから」として記録する

0件だった187件は、今後使われる可能性があります。名前を控えておくと、次に数えたときに変化が分かります。

同じ環境で半年後に数え直せば、どの機能が使われ始めたかが見えます。空だったものが埋まっていれば、そこで何かが起きたということです。

個別の機能は別記事で追う

この記事は全体像です。個々のテーブルについては、件数の多いものから順に調べています。

たとえば1位の除外リストは、変更収集の仕組みそのものに関わります。標準グラフの766件は、使われているものと使われていないものに分かれます。

数えた結果を出発点にして、気になるものを掘る。そういう使い方ができる一覧になりました。

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

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

• テーブル定義を接頭辞で絞る：/sys_db_object_list.do?sysparm_query=nameSTARTSWITHdp_

• 個人情報の検出パターン：/dp_data_pattern_list.do

• クエリキャッシュの設定：/qc_configured_query_list.do

• 標準グラフをタイプ別に見る：/analytics_visualization_list.do?sysparm_query=GROUPBYtype

• テーブル一覧を作成日順に見る：/sys_db_object_list.do?sysparm_query=ORDERBYDESCsys_created_on

検証範囲とおことわり

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

確認していないことがあります。291件すべての中身を読んだわけではありません。件数を数えただけで、意味を調べたのは10件ほどです。

0件のテーブルが「今後使われる」のか「この環境で使わないだけ」かも判断していません。どちらの可能性もあります。

ts_ で始まるテーブルの用途も追っていません。内部のシャードと判断して除外しました。この判断が正しいかは確認していません。

2つのテーブルは count では件数が返るのに、行を取ると0行でした。スコープ付きテーブルの読み取り制限だと考えられますが、確認していません。件数は集計に含めています。

本番環境では件数も分布も変わります。この記事の数字は素の PDI の状態です。

なお、この比較は「アップグレードの差分」ではありません。別々に作られた2つの PDI を並べたものです。デモデータの差が混ざっている可能性があります。

関連記事

• ZurichとAustraliaを並べて数えたら何が変わっていたか — テーブル・プラグイン・既定値の全体比較

• プラグイン（v_plugin/sys_plugins）の有効・無効と依存 — 機能が入っているかを確認する方法

• システムログ（syslog）の読み方と溜まり方 — 空のテーブルが埋まる仕組み