ServiceNowの標準グラフ766件、実際に使われているのは何件？ used_in_dashboardで棚卸しする
グラフを新しく作ろうとして一覧を開いたら、標準のものが数百件並んでいた。この中に使えるものがあるのか、それとも全部が飾りなのか。判断する材料が欲しいところです。ServiceNowには可視化のメタデータを持つテーブルがあり、そこに「ダッシュボードで使われているか」を示すフラグがありました。数えると766件のうち158件、約2割だけが実際に使われています。
検証環境：Australia PDI / OOTB / 2026-08-10 確認
標準グラフを前にして最初に思うこと
ダッシュボードを作ろうとして標準のグラフ一覧を開くと、数百件が並びます。そこで手が止まります。
知りたいのは2つです。この中に使えるものがあるのか。 そしてどれが実績のあるものなのか。全部を1つずつ開いて確かめるのは現実的ではありません。
判断の材料になるのが「実際に使われているかどうか」です。誰かがダッシュボードに載せたものなら、少なくとも実用に耐えた実績があります。
使用状況はどこに記録されるのか
ServiceNow はグラフの定義と、その付随情報を別のテーブルに分けていました。
定義そのものが analytics_visualization。付随情報が analytics_visualization_metadata です。作成者、更新日時、そして使用状況がこちらに入ります。
継承元を見ると性格が分かります。メタデータ側は基底テーブルでした。更新セットで運ぶ種類のものではありません。その環境での状態を記録するための入れ物です。
公式は「使用状況を見るための機能」と書いている
この仕組みを入れているのは PAR Analytics Center というプラグインでした。公式の説明はこうです。
PAR Analytics Center allows admin users to see dashboard and data visualization usages details.
管理者がダッシュボードとデータ可視化の利用状況の詳細を見られるようにするもの、と書かれています。グラフを作る側の機能ではありません。作ったものがどう使われているかを見る機能だと公式が明言しています。
棚卸しに使うのは、この説明どおりの用途ということになります。
中間テーブルではなくフラグで持つ
ダッシュボードとグラフは多対多の関係になります。1つのグラフが複数のダッシュボードに載ることも、その逆もあります。
ServiceNow でこうした関係を持つときは、中間テーブルを使うのが一般的です。ユーザーとロール、カタログアイテムとカテゴリ。どれも専用のテーブルがあります。
ところがここでは違いました。used_in_dashboard という真偽値ひとつで表現されています。この設計だと「どのダッシュボードに載っているか」は追えません。載っているかどうかだけが分かります。
割り切った作りですが、棚卸しの用途には十分です。探しているのは「使われているか」であって「どこで使われているか」ではないからです。
結論：5件に1件しか使われていない
先に数字です。
図の色は意味を持たせています。紺が起点で、青が対応するテーブル。緑は使われているもの、橙は使われていないものです。灰色はこの環境で実績のない部分を示します。
766件のうち、ダッシュボードに載っているのは158件。載っていないものが608件あります。割合にすると約2割です。
未設定のものはありません。766件すべてに真偽どちらかの値が入っていました。つまりこれは「まだ判定していない」状態ではなく、判定した結果として608件が未使用ということです。
フラグはメタデータ側にある
この情報がどこにあるかを説明します。
グラフの定義そのものはanalytics_visualizationに入っています。それとは別にanalytics_visualization_metadataというテーブルがあり、こちらも766件。1対1で対応しています。
使用状況を持っているのは、メタデータ側のほうでした。
項目は15個ありました。可視化本体への参照と、使用状況のフラグ。作成者と作成日時、更新者と更新日時。そして無効化された日時です。
中間テーブルは存在しなかった
調べる前は、ダッシュボードと可視化を結ぶ中間テーブルがあると考えていました。analytics_dashboard_visualizationのような名前で。
探しましたが、ありませんでした。analytics_dashboard_tabも存在しません。
代わりにあったのが、このused_in_dashboardという真偽値です。どのダッシュボードに載っているかは分からないが、どこかに載っているかどうかは分かる、という持ち方になっています。
使われている158件を見る
絞り込むと158件が出ます。この数を28件のダッシュボードで割ると、1つあたり約5.6件という計算です。
実際には偏りがあるでしょう。10件以上を載せたダッシュボードもあれば、2〜3件で済ませているものもあるはずです。ただ平均で5〜6件というのは、感覚と大きく違いません。1画面に詰め込みすぎない構成です。
もうひとつ言えるのは、158件が28件のダッシュボードに分散しているという点です。1つの可視化が複数のダッシュボードで使い回されている可能性もあります。フラグは真偽値なので、何回使われているかまでは分かりません。
同じグラフを別の切り口のダッシュボードに載せる、という使い方は自然です。たとえばインシデントの件数推移は、運用チーム向けの画面にも経営向けの画面にも置きたくなります。そう考えると、実際に画面へ配置されている回数は158件より多いはずです。
フラグで分かるのは「使われているかどうか」だけで、「どれだけ使われているか」は別の話になります。棚卸しの目的が「使っていないものを見つける」ことなら真偽値で足りますが、「よく使われているものを知りたい」なら別の手段が要ります。
使われていない608件をどう見るか
問題はこちらです。8割が未使用という数字を、どう受け止めるか。
「無駄」ではなく「在庫」と考える
まず、これを無駄だと決めつけないほうがよさそうです。
標準で用意されている可視化は、あらゆる業種・規模の顧客を想定しています。製造業が使うもの、金融が使うもの、大企業向け、中小企業向け。すべてを1つのダッシュボードに載せることはできません。
使われていない608件は、必要になったときに取り出せる在庫と考えるのが実態に近いでしょう。自分の組織に合うものを、この中から選んで載せる。そういう使い方が想定されています。
探す価値がある理由
608件が眠っているということは、自分が作ろうとしているグラフが、すでにこの中にある可能性が高いということでもあります。
ゼロから作る場合、手順が4段階あります。データソースを選び、集計軸を決め、条件を書き、表示形式を選ぶ。既存のものを流用すれば、条件を少し変えるだけで済みます。
作る前に608件を検索する。この一手間で、かなりの作業が省けるはずです。維持の手間も違います。自作したものは自分で面倒を見ることになりますが、標準のものはリリースごとに製品側が更新してくれます。
誰が作ったものかも記録されている
メタデータには作成者の記録もありました。
大半はSystem Administratorです。631件。標準データを投入するときに使われる既定のユーザーなので、これが多いのは自然でしょう。
maintが15件あります。これはServiceNow側の保守用アカウントです。製品側から後で追加されたもの、と読めます。
1件だけ人間が作っている
目を引いたのがJoe Employeeという1件です。デモ用のユーザー名です。
766件のうち1件だけ、デモユーザーの名前で作られたものがある。おそらくデモデータを準備する過程で、誰かが手動で作った痕跡でしょう。断定はできませんが、他の765件とは違う経路で作られたことは確かです。
きれいに揃った中に1件だけ違うものがあると、そこに経緯がある。 前にも同じような発見がありました。グラフ形式の値にVertical barが199件ある中、1件だけvertical_barという表記ゆれがあった件です。詳しくはグラフ定義はどこに入る？に書きました。
作成者が空欄の117件
もうひとつ気になるのが、created_byが空の117件です。
作成者が記録されていないということは、通常の作成経路を通っていない可能性があります。インストール時に一括投入されたもの、あるいは古い版から引き継がれたもの。どちらかだろうと考えていますが、確かめる方法が見つかりませんでした。
無効化の実績は0件
last_deactivated_onという項目があります。いつ無効化されたかを記録する欄です。
全766件で空でした。一度も無効化されていないということです。
この項目が用意されているということは、可視化を無効化する操作があるはずです。削除ではなく無効化という形で残す。使わなくなったものを消さずに寝かせておく仕組みだと読めます。
ただし標準では誰も使っていません。運用が始まってから埋まっていく側の項目です。
608件から目的のものを探す手順
在庫として使うなら、探し方を決めておく必要があります。608件を順に見るのは現実的ではありません。
手順1：業務名で絞る
まず対象の業務で絞ります。インシデント関連ならIncident、変更ならChange、カタログならCatalog。標準の名前は英語なので、日本語で検索しても出てきません。ここでつまずく人は多いはずです。
実際に絞ってみました。
Incident を含むもので90件です。他の業務名でも試しました。
766件が1割前後まで減ります。ここから先は形式で絞る段階です。
手順2：形式で絞る
次に表示形式で絞ります。数字を1つ大きく出したいのか、推移を見たいのか、明細を並べたいのか。
前の記事で数えたところ、縦棒が199件、単一数値が132件、一覧が108件でした。この3つで全体の6割弱を占めます。目的が決まっていれば、候補はさらに減ります。
手順3：中身を確認する
残った候補を1つずつ開いて、集計軸と条件を確認します。名前が近くても、集計している内容が違うことがあります。
画面から探す操作はAnalytics Centerの操作方法にまとめました。テーブルを直接見るより、こちらのほうが早い場面もあります。
見つからなかったときだけ作る
3段階を通しても見つからなければ、そこで初めて新規に作ります。この順序を守ると、重複を減らせます。
手順はData Visualizationsでグラフをゼロから作る手順にあります。
自作したものが増えたときの棚卸し
運用を続けると、自作の可視化が増えていきます。そのときused_in_dashboardが効いてきます。
定期的に数えるだけでいい
難しい調査は要りません。used_in_dashboard=falseで絞って件数を見る。それだけです。
標準の608件は最初からあるので、そこからの増分が自作の未使用分になります。増え方が急なら、作りすぎのサインです。
消すかどうかは慎重に
未使用だからといって、すぐに削除するのは危険です。理由が3つあります。
季節性があるものが含まれている可能性があります。四半期末だけ使う、年度末だけ使うといった可視化は、普段は未使用に見えます。
作りかけのものもあるでしょう。ダッシュボードに載せる前段階で止まっているだけかもしれません。
削除の影響が読みにくいという問題もあります。どこからも参照されていないように見えて、スクリプトやレポートから呼ばれている可能性は残ります。
last_deactivated_onという項目が用意されているのは、この事情を反映していそうです。削除ではなく無効化。使わなくなったものを消さずに寝かせる仕組みが最初から想定されています。
数字を測ることそのものが価値になる
今回やったのは、フラグを2種類に分けて数えただけです。技術的には難しくありません。
それでも意味があるのは、この数字を知っている人が少ないからです。766件という総数は一覧を開けば分かりますが、そのうち何件が使われているかは、メタデータ側のテーブルを知らないと調べられません。
同じ構図は他の機能でもあります。指標を定義したのに測定が始まっていない、という話はPerformance Analyticsは何を測る？で扱いました。定義の件数と、実際に動いている件数は別々に数える必要があります。
標準ダッシュボードにどんなものがあるかは標準ダッシュボード全体像にまとめてあります。今回の158件が、そのどれに載っているかを追う手がかりになります。
作ったグラフを配布する方法はPowerPoint出力・共有・定期送信で扱いました。棚卸しで見つけた既存の可視化を、そのまま報告資料に回せます。
実機を見て気づいたこと
いちばん意外だったのは、中間テーブルではなくフラグで表現されていたことです。
ServiceNowでは、多対多の関係を中間テーブルで持つのが一般的です。ユーザーとロール、カタログアイテムとカテゴリ。どれも専用のテーブルがあります。
ところがダッシュボードと可視化は、そうなっていませんでした。真偽値ひとつです。この設計だと「どのダッシュボードに載っているか」は追えません。追える必要がないという判断なのか、別の場所に情報があるのか。今回は特定できていません。
もうひとつは、作成者の欄が2種類あることでした。created_byとsys_created_byが別々にあります。前者は業務的な作成者、後者はシステムが記録する作成者、という使い分けでしょう。
sys_created_byを数えると、766件すべてがsystemでした。1種類しかありません。システム側の記録では区別が付かないので、業務的な作成者を別に持つ必要があったと読めます。
普通のテーブルならsys_created_byだけで足ります。わざわざ別に持っているということは、システム上の作成者と、業務上の作成者が食い違う場面があるということです。たとえば管理者が代理で作成する場合や、インポートで一括投入する場合が考えられます。ここは推測です。
そして、8割が未使用という数字そのものにも考えさせられました。最初は多すぎると感じましたが、標準機能として考えると妥当なのかもしれません。全員に必要なものだけを入れると、誰にとっても物足りない製品になります。使わないものが8割あるくらいが、選択肢としては健全という見方もできます。
標準機能の「使われ方」を測るという発想
今回の調査は、機能そのものではなくその機能がどれだけ使われているかを測るものでした。この視点は他にも応用できます。
ServiceNowには、標準で大量の定義が入っています。通知が403件、UI Actionが数千件、Business Ruleが5,000件超。どれも「入っている」ことは一覧を見れば分かります。
しかし「実際に動いているか」は別です。通知については、定義403件に対して送信実績があるのは37件でした。今回の可視化も、766件に対して使用中は158件。どちらも2割前後という点が興味深いところです。
2割という数字の意味
偶然の一致かもしれません。ただ、標準機能の設計としては筋が通っています。
あらゆる顧客に対応するため、選択肢は幅広く用意する。その中から各組織が2割程度を選んで使う。残りは使われないが、必要な人には必要。選択肢としての在庫という考え方です。
この前提に立つと、「標準機能が多すぎて分からない」という感想は的外れではないものの、対処法が見えてきます。全部を理解しようとせず、自分に必要な2割を見つける方法を身につければよい、ということです。
測り方は共通している
やることは毎回同じです。定義の総数を数え、実績を示すフィールドを探し、突き合わせる。
今回はused_in_dashboardというフラグがありました。通知のときは送信ログと突き合わせました。フィールドが無い場合は、関連テーブルの件数を見ることになります。
「定義の数」と「使われている数」を別々に数える。この習慣があると、標準機能の全体像を掴むのが早くなります。
実務では何に使えるか
この情報は、3つの場面で役に立ちます。
作る前に探す
新しくグラフを作る前に、used_in_dashboard=falseの608件を検索します。似たものがあれば、それを複製して条件だけ変えれば済みます。
検索するときは名前で絞るのが早いでしょう。「Incident」「Change」といった業務名、あるいは「by」で始まる集計軸。標準の名前は英語なので、日本語で探しても出てきません。
棚卸しの基準にする
自分の組織で運用を始めると、可視化は増え続けます。標準の766件に、自作のものが積み上がっていきます。
そのときused_in_dashboardが判断材料になります。作ったのにどこにも載っていないものが溜まっていないか。定期的に数えると、無駄な増殖に気づけます。
同じ考え方は、カタログアイテムでも使えます。作ったのに誰も注文しないアイテムをどう見つけるか、という話はカタログアイテムが見えない・申請できないでも触れました。定義があることと、使われていることは別という観点は共通しています。
ダッシュボードを設計するときの目安にする
28件のダッシュボードに158件の可視化。1つあたり5〜6件です。
自分でダッシュボードを作るとき、この数が目安になります。10件を超えると1画面に収まらず、スクロールが必要でしょう。見る人が一度に把握できる情報量にも限りがあります。
標準がこの粒度で作られているということは、5〜6件で1つの目的を表現するという設計思想があるのでしょう。詰め込みたくなったときに思い出すと役に立ちます。
この機能はZurichには無かった
analytics_visualization_metadataは、Zurichには存在しないテーブルです。Australiaで新しく加わりました。
ということは、Zurichの環境では「どの可視化が使われているか」を簡単には調べられなかったことになります。従来のsys_report側に同様の仕組みがあるかは確認していません。
新旧の全体像はZurichとAustraliaを並べて数えたらにまとめました。グラフ定義そのものが新旧2系統に分かれている話も、そちらで扱っています。
メタデータを分けている理由を考える
定義本体とメタデータが別テーブルになっている構造は、少し珍しい作りです。766件に対して766件。1対1なら1つのテーブルにまとめてもよさそうに見えます。
分けている理由をいくつか想像しました。いずれも推測です。
更新の頻度が違う。 可視化の定義そのものは、作ったあとあまり変わりません。一方で使用状況は、ダッシュボードを編集するたびに変わり得ます。更新頻度の違うものを分けるのは、データベース設計の定石です。
権限を分けたい。 可視化を編集できる人と、使用状況を見たい人は別かもしれません。テーブルが分かれていれば、アクセス制御も別々に設定できます。
後から足した。 元々は定義だけがあり、あとから使用状況を追跡する必要が出てきた。既存のテーブルに列を足すより、別テーブルにするほうが影響が小さい場合があります。
どれが正しいかは分かりません。ただ、分かれていること自体に意味があるとは言えそうです。設計者が意図して分けています。
ダッシュボード側は1件多い
もうひとつ引っかかる点があります。ダッシュボード側は本体が28件、メタデータが29件で、1件多いのです。
可視化側は766件で完全に一致しているのに、ダッシュボード側だけ揃っていません。削除されたダッシュボードのメタデータが残っているのか、本体を持たないメタデータがあるのか。
1対1で対応するはずのものが1件ずれているという状態は、たいてい何かの経緯を示しています。今回は理由まで追えていません。
この記事で確かめたこと
整理します。
analytics_visualization_metadataは766件で、可視化本体と1対1で対応していました。そのうちused_in_dashboardが真のものは158件、偽のものは608件。未設定はゼロで、全件が判定済みです。
ダッシュボードと可視化を結ぶ中間テーブルは存在しませんでした。analytics_dashboard_visualizationもanalytics_dashboard_tabも無く、真偽値ひとつで表現されています。この設計だと「どこに載っているか」までは追えません。
作成者はSystem Administratorが631件で大半を占め、maintが15件、systemが2件。空欄が117件あり、Joe Employeeというデモユーザー名が1件だけ混ざっていました。
last_deactivated_onは全件が空です。無効化の仕組みはあるものの、標準では一度も使われていません。
確かめられなかったことも5つあります。158件の具体的な行き先。フラグの更新タイミング。608件を消した場合の影響。空欄117件の由来。そして旧sys_report側に同じ仕組みがあるかどうか。次に触るときはここから見ます。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
メタデータ：定義そのものではなく、定義に付随する情報
中間テーブル：多対多の関係を保持するための専用テーブル
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/analytics_visualization_metadata_list.do … メタデータの一覧
/analytics_visualization_metadata_list.do?sysparm_query=used_in_dashboard%3Dtrue … 使われているもの
/analytics_visualization_metadata_list.do?sysparm_query=used_in_dashboard%3Dfalse … 使われていないもの
/analytics_visualization_metadata_list.do?sysparm_query=GROUPBYused_in_dashboard … 件数の内訳
/analytics_dashboard_list.do … ダッシュボードの一覧
引用した公式説明を自分で開く
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINanalytics_visualization_metadata^hintISNOTEMPTY
プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=descriptionISNOTEMPTY
関連記事
ServiceNowのグラフ定義はどこに入る？ analytics_visualizationとsys_reportの併存を実機で確かめる — 可視化そのものの構造はこちらで扱っています。
ZurichとAustraliaを並べて数えたら何が変わっていたか — このテーブルが増えた経緯が分かります。
ServiceNow レポート・ダッシュボード完全ガイド — レポート機能の全体像から読む場合の入口です。
検証環境と未検証範囲
確認した範囲：Australia PDI（OOTB）におけるanalytics_visualization_metadata766件のused_in_dashboard集計、created_byの分布、フィールド構成15個、last_deactivated_onの件数、およびanalytics_dashboard_visualization・analytics_dashboard_tabが存在しないことの確認。すべてREST APIと画面の読み取りのみで、レコードの作成や更新は行っていません。
確認していない範囲（断定しません）：158件が具体的にどのダッシュボードに載っているか、used_in_dashboardがいつ誰によって更新されるか、608件を削除した場合の影響、created_byが空欄の117件がどう作られたか、旧sys_report側に同様の仕組みがあるか。これらは別途の検証が必要です。
比較対象のZurich環境は別々に作成されたインスタンスです。同一環境をアップグレードした結果ではありません。
