ServiceNowの「自分が作った分析資産」502件の正体は？ created_byがadminになる標準レコード

Analytics Center を開くと「自分が作ったもの」という一覧が出ます。Australia の PDI で対応するビューを数えたところ、502件ありました。誰も何も作っていない素の環境です。中身を追うと、標準で入っているレコードの作成者が admin になっているためでした。作成者だけを見て自作かどうかを判断できない、という話になります。

「自分が作ったもの」を数えたい場面

分析資産の棚卸しをするとき、まず知りたいのは自作と標準の切り分けです。

標準で入っているものは触らない。 自分たちで作ったものだけを見直したい。導入から時間が経つほど、この区別が必要になります。

素直に考えれば、作成者で絞れば済みそうに見えます。標準はシステムが作り、自作は人が作るはずだからです。この記事はその前提が成り立つかを確かめます。

Analytics Center という入口

新しい分析基盤には Analytics Center という画面があります。ダッシュボード・可視化・インジケータを1か所で探せる入口です。

3種類の資産はそれぞれ別のテーブルに入っています。バラバラに探すのは手間なので、まとめて見せるためのビューが用意されていました。

名前は sn_analytics_cen_v_pa_created_by_me_artifacts。長いですが、区切って読むと分かります。sn_analytics_cen が Analytics Center、v がビュー、そして pa_created_by_me_artifacts が「自分が作った分析資産」です。

ビューという仕組みの性格

ServiceNow のデータベースビューは、複数のテーブルを結合して1つの一覧として見せる仕組みです。実体としてレコードは持ちません。

だから件数は元テーブルと一致しないことがあります。結合の条件で絞られたり、逆に1件が複数行になったりします。

このビューは libraries と table_name という2つの列を持っていて、行ごとに元テーブルが分かるようになっていました。どこから来た行かを追えるので、突き合わせがしやすい作りです。

ビューを読むときは、必ず元テーブルの件数と並べる。差が出たら理由を探す。この順番で見ると誤読を避けられます。

結論：標準レコードがadmin名義なので「自分が作った」に502件出る

この数字の正体は、3段階で説明が付きます。

502件の内訳は、インジケータ355件、データ可視化121件、ダッシュボード26件でした。3種類の資産を1つのビューにまとめています。

実テーブルの件数と突き合わせると、常にビューのほうが少ない。差は作成者によるものでした。admin が作ったことになっている分だけが出てきます。

そして素の PDI では、標準で入っているレコードの大半が admin 名義です。誰も作っていないのに「自分が作った」に502件並びます。

ビューは3種類の資産を束ねている

sn_analytics_cen_v_pa_created_by_me_artifacts という長い名前のビューです。

libraries という列で3つに分かれていました。Indicators が355件、Data Visualizations が121件、Dashboards が26件。合計502件です。

同時に table_name という列も持っていて、こちらは pa_indicators、par_visualization、par_dashboard の3つ。ライブラリ名と実テーブル名が1対1で対応します。

交差はありません。Indicators はすべて pa_indicators から来ています。3種類の資産を、種類の名前と実テーブル名の両方で識別できる作りです。

description が111件で空

502件のうち、説明が空なのは111件でした。約2割です。

名前だけで内容を判断することになります。標準で入っているものは名前が具体的なので困りませんが、自分たちで作るときは説明を書いておく価値があります。

実テーブルと突き合わせると足りない

ビューの件数を、元のテーブルと比べました。

インジケータは実テーブルに409件あるのに、ビューには355件。54件足りません。

データ可視化は130件に対して121件で、9件足りない。ダッシュボードは28件に対して26件で、2件足りません。

合計すると567件のうち502件。65件がビューに出てきません。

差は作成者だった

何が違うのかを調べるため、pa_indicators の作成者を数えました。

admin が355件、maint が49件。この2つで404件です。残る5件は別のアカウントが2種類でした。

ビューに出る355件と、admin が作った355件が一致します。ビューは作成者で絞り込んでいると分かります。

データ可視化でも同じでした。130件のうち admin が121件、maint が9件。ビューに出るのは121件です。

「自分が作った」の意味

ビューの名前に created_by_me と入っています。ログインしている利用者が作ったものを見せる、という意図でしょう。

素の PDI にログインしているのは admin です。そして標準で入っているレコードの多くが admin 名義で作られています。だから「自分が作ったもの」に502件並びます。

実際には誰も作っていません。製品を導入した時点で、そういう状態になっています。

maint 名義のレコードは何なのか

出てこない65件のうち、大半が maint 名義でした。インジケータ49件、データ可視化9件です。

maint は ServiceNow の保守用アカウントです。製品側のメンテナンス処理で作られたレコードに付きます。

つまり同じ標準レコードでも、入ってきた経路によって作成者が変わるということになります。admin 名義のものと maint 名義のものが混在しています。

経路の違いは追いきれない

なぜ一方が admin で他方が maint なのかは、この環境からは判断できません。

デモデータの投入スクリプトが admin で動き、プラグインのインストール処理が maint で動く。そういう分かれ方だと考えられますが、確認していないので推測にとどめます。

インジケータ409件の内訳そのものはServiceNowのPerformance Analyticsは何を測る？ 指標設計を5つのテーブルで決める手順で扱った領域と重なります。

par_dashboard と analytics_dashboard は同じもの

調べていて気づいた点があります。ビューが参照している par_dashboard は28件でした。

別の記事で調べた analytics_dashboard も28件です。同じ数なので、sys_id を突き合わせました。

28件すべて一致しました。 同じレコードを2つの名前で参照できる状態です。

可視化のほうは一致しない

同じことが可視化でも成り立つかを確かめました。par_visualization は130件、analytics_visualization は766件です。

こちらは大きく違います。名前が似ていても、同じ実体ではありません。

グラフ定義が新旧2系統に分かれている話はServiceNowのグラフ定義はどこに入る？で扱いました。par_ はさらに別の系統です。

名前が似ているテーブルを見つけたら、件数を並べて、必要なら sys_id で突き合わせる。この確認を省くと、同じものだと思い込んだまま調査を進めることになります。

可視化はワークスペース別に分かれている

par_visualization の130件を、スコープで分けました。

CMDB Workspace が41件で最多。ITSM Analytics が35件、Security Center が22件と続きます。

Global は14件だけでした。1割程度しかプラットフォーム側に置かれていません。

各ワークスペースが、自分の画面で使うグラフを自分のスコープに持っている構造です。ワークスペースを追加すると、その分だけ可視化も増えていきます。

可視化側でも同じ構図でした。admin が121件、maint が9件。ビューに出る121件と一致します。

分析資産が置かれるテーブルを一覧にする

調べる過程で、名前の似たテーブルがいくつも出てきました。整理しておきます。

インジケータは pa_indicators が409件。同じ409件を持つ pa_indicators_definition もあります。

可視化は par_visualization が130件、analytics_visualization が766件。さらに従来のレポートである sys_report が636件あります。

ダッシュボードは par_dashboard と analytics_dashboard がどちらも28件で同一。従来の sys_dashboard が16件、pa_dashboards は0件でした。

3つの世代が同居している

並べると世代が見えてきます。sys_report と sys_dashboard が従来の仕組み。pa_ が Performance Analytics の系統。analytics_ と par_ が新しい Platform Analytics です。

どれも実データを持っています。 片方が空になって置き換わるのではなく、同時に存在しています。

レポートの構造そのものはレポート（sys_report）：4つの軸で読み解くで扱いました。世代が違っても、測りたいことは変わりません。

話をする前に対象を決める

「グラフが何件ある」という話をするとき、どのテーブルを指しているかで答えが変わります。130なのか766なのか636なのか。

会話の食い違いはここで起きます。画面の名前ではなくテーブル名で確認すると、齟齬が減ります。

ビューという仕組みについて

sn_analytics_cen_v_... という名前には _v_ が入っています。ビューであることを示す命名でしょう。

ServiceNow のデータベースビューは、複数のテーブルを結合して1つの一覧として見せる仕組みです。実体としてレコードは持ちません。元テーブルを参照するだけになります。

ビューを読むときの注意

ビューの件数は、条件次第で元テーブルより増えることも減ることもあります。今回は減る方向でした。

結合の仕方によっては、1件が複数行になる場合もあります。件数だけを見て「何件ある」と判断すると誤ります。

ビューを見つけたら、必ず元テーブルの件数と突き合わせる。 差が出たら理由を探す。この順序で読むと間違えません。

元テーブルが分かる作りだった

このビューは table_name という列を持っていて、行ごとに元テーブルが分かるようになっていました。

親切な設計です。列を1つ足すだけで、どこから来た行かを追えます。ビューを読む側にとって、これがあるとないとでは調査の手間が変わります。

自分でビューを作るときにも真似できる考え方でしょう。

admin 名義であることの副作用

作成者が admin に揃っているのは、他の場面にも影響します。

監査で追えない

誰がいつ作ったかを追いたいとき、標準レコードと自作レコードが同じ作成者になります。区別する手がかりが1つ減ります。

変更履歴そのものは別に残ります。何がいつ変わったかはServiceNowの変更履歴はどこに残る？ sys_auditと監査対象フィールドを実機で確認で扱った仕組みで追えました。作成者だけに頼らない方法があります。

更新セットとの関係

自分たちで作ったものは更新セットに乗ります。標準で入っているものは乗りません。

この違いは作成者より確実です。何を移送するかを決めるとき、更新セットの中身を見るほうが正確でしょう。

権限との関係

admin 名義であることと、誰が見られるかは別の話です。可視性はロールやスコープで決まります。

権限の層をどう追うかはServiceNowで権限はどこで決まる？ ユーザーからACL・ドメインまで7つの層を実機でたどる完全ガイドにまとめました。作成者は権限には効きません。

素の環境を基準として持っておく

今回のような調査は、素の環境の数字を知っていると速く進みます。

インジケータ409件、可視化130件と766件、ダッシュボード28件。これが何もしていない状態の数字です。

自分の環境で数えて、この数より多ければ追加されたものがあります。少なければプラグインが入っていない可能性があります。

基準を取るタイミング

導入直後に数えておくのが理想です。後から「どこまでが標準か」を判断するのは難しくなります。

プラグインを入れるたびに数字は動きます。何を入れたかの記録と、そのときの件数を残しておくと、後の調査が楽になります。プラグインの依存関係はプラグイン（v_plugin/sys_plugins）の有効・無効と依存で扱いました。

差分を見る習慣

バージョンが上がったときも同じです。前後で数えれば、何が増えたかが分かります。

この記事の調査も、Zurich と Australia の2つの環境を持っていたから成り立ちました。比較対象があると、気づけることが増えます。

502件のなかから目的のものを探す

ビューを実際に使う場面を考えます。502件から目的の資産を見つける方法です。

種類で絞る

まず libraries で絞ります。インジケータを探しているなら355件、ダッシュボードなら26件まで減ります。

ダッシュボードは26件しかないので、この時点で一覧できます。名前を眺めれば目的のものが見つかるでしょう。

名前で探す

インジケータの355件は多すぎます。name で検索するのが現実的です。

標準のインジケータは名前が具体的でした。「Number of open incidents」のような形で、何を測るかが読み取れます。測りたいものの英単語で引くと当たります。

説明が空の111件に注意する

description が空のものが111件ありました。名前だけで判断することになります。

自分たちで作るときは、ここを埋めておくと後で助かります。半年後の自分が同じものを探すとき、名前だけでは思い出せません。

種類ごとの件数を頭に入れる

355 / 121 / 26 という配分は、資産の性格を表しています。

いちばん下にインジケータがあり、それを使う可視化があり、可視化を並べたダッシュボードがある。下に行くほど数が多いのは自然な形です。

逆に言えば、ダッシュボードを1つ作るために、複数の可視化と多数のインジケータが要ります。作る手順を考えるときの目安になります。

ワークスペースごとに資産が増える構造

par_visualization のスコープ分布は、この製品の作り方を表していました。

CMDB Workspace が41件、ITSM Analytics が35件、Security Center が22件。それぞれのアプリケーションが、自分の画面で使うグラフを自分で持っています。

Global が14件しかない意味

プラットフォーム側に置かれているのは14件だけでした。全体の1割程度です。

共通の部品としてまとめず、使う場所の近くに置く。そういう方針だと読めます。

利点は分かりやすさです。CMDB Workspace の画面で見えるグラフは、CMDB Workspace のスコープにある。探す場所が決まっています。

欠点は重複でしょう。似たグラフが複数のスコープに散らばる可能性があります。実際に重複しているかは確認していません。

ワークスペースの位置づけ

そもそもワークスペースが従来のフォームと何が違うのかは、別の論点になります。ServiceNowのワークスペースは従来のフォームと何が違う？で切り分けを扱いました。

画面基盤が変わると、その画面が使う資産も一緒に付いてきます。可視化がスコープ別に分かれているのは、その現れです。

導入判断の材料になる

新しいワークスペースを入れるとき、何が増えるかを事前に見積もれます。

CMDB Workspace の41件が目安です。同規模のものを足せば、可視化が数十件増えると考えられます。

管理対象が増えることを、費用や工数の話とは別に把握しておく価値があります。棚卸しの対象が増えるためです。

調べた手順をそのまま残しておく

この記事でやったことは3ステップでした。同じ手順が他のビューにも使えます。

1. ビューの分布を取る

GROUPBY で種類ごとにまとめます。今回は libraries で3グループに分かれました。

同時に table_name のような、元テーブルを示す列があるかを見ます。あれば次のステップが楽になります。

2. 元テーブルの件数を数える

種類ごとに、元テーブルのレコード数を数えます。ビューの件数と並べて差を出します。

差が0なら、ビューは単に見せ方を変えているだけです。差があれば、何かの条件で絞っています。

3. 差の原因になりそうな列で分ける

作成者、有効フラグ、スコープ。単純な列から順に GROUPBY して、差の件数と一致するものを探します。

今回は作成者で一発でした。355という数が、ビューの件数とぴったり合います。

一致するものが見つかったら、他の種類でも同じ規則が成り立つかを確かめます。3種類とも作成者で説明できたので、推定の確度が上がりました。

1種類だけで結論を出さない。 複数で成り立って初めて、規則として扱えます。

インジケータを単位で分けた画面です。件数を表す記号が最多で、パーセントや時間が続きます。何を測る指標が多いかの目安になります。

用語

Analytics Center：分析資産をまとめて扱う画面。ダッシュボード・可視化・インジケータを1か所で探せる。

ビュー：複数のテーブルを1つに束ねて見せる仕組み。ここでは3種類の資産を束ねている。

インジケータ：測定する指標の定義。pa_indicators に入る。

par_ 系：可視化とダッシュボードを持つテーブル群。analytics_ 系とは別。

maint：ServiceNow の保守用アカウント。製品側の処理で作られたレコードの作成者になる。

スコープ：アプリケーションの区切り。Global はプラットフォーム全体を指す。

実機を見て気づいたこと

「自分が作った」を信用できない

502件という数を見たとき、何かの間違いだと思いました。誰も何も作っていない環境です。

作成者を追うと理屈は通っていました。admin 名義のレコードが標準で入っていて、admin でログインしているから「自分が作った」に出てくる。仕組みとしては正しく動いています。

それでも実務では困ります。 自分たちで作ったものを探したいのに、標準のものが502件混ざるからです。作成者だけでは絞り込めません。

絞るならスコープや作成日を併用することになります。Global で、かつ導入日以降に作られたもの。この2つを重ねると、自作のものが見えてきます。

65件の差が作成者で説明できた

567件と502件の差を見たとき、条件が複雑だと予想していました。有効フラグか、公開設定か、何かの権限か。

実際は作成者ひとつでした。admin 以外が作ったものが除かれるだけです。3種類とも同じ規則で説明が付きます。

差の原因を探すとき、まず単純な列から当たるのが効率的でした。作成者、有効フラグ、スコープ。この3つで説明が付く場合が多いと感じます。

名前が似たテーブルは件数から確かめる

par_dashboard と analytics_dashboard が同一で、par_visualization と analytics_visualization が別物。これは予想が外れました。

接頭辞が揃っているので、同じ規則で対応していると思い込んでいました。片方だけ一致するのは、成り立ちが違うからでしょう。

件数を並べるだけで、同一かどうかの見当が付きます。28と28なら同一を疑い、130と766なら別物を疑う。sys_id の突き合わせに進む前に、件数で当たりを付ける手順が使えます。

実務では何に使えるか

自作の資産を数える

導入後に自分たちで作った分析資産がどれだけあるかを知りたい場面があります。

ビューをそのまま使うと502件出てくるので、役に立ちません。実テーブル側で条件を付けます。

作成日が導入日より後、かつスコープが Global。この2つで絞ると、追加されたものが浮かびます。作成者は使えません。

棚卸しの前に母数を確認する

分析資産の棚卸しをするとき、母数をどこから取るかで結論が変わります。

インジケータなら409件。ビューの355件を母数にすると、54件を見落とします。

可視化はさらに厄介です。par_visualization の130件と analytics_visualization の766件、どちらを母数にするかで話が変わります。何を数えているのかを先に決める必要があります。

グラフ定義が新旧2系統に分かれている話でも、母数の取り方が結論を左右しました。どのテーブルを数えるかを先に決めておくと、後で説明が食い違いません。

ワークスペースを増やす影響を見積もる

par_visualization がスコープ別に分かれているので、ワークスペースを追加すると可視化も増えます。

CMDB Workspace だけで41件です。似た規模のワークスペースを1つ足せば、同じくらい増えると見込めます。

管理する対象が増えることを、導入前に把握しておく材料になります。ダッシュボードの作り方そのものはダッシュボードをゼロから作る手順：グラフを1画面にまとめるにまとめました。

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

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

• 資産ビューを種類別にまとめる：/sn_analytics_cen_v_pa_created_by_me_artifacts_list.do?sysparm_query=GROUPBYlibraries

• インジケータを作成者別にまとめる：/pa_indicators_list.do?sysparm_query=GROUPBYsys_created_by

• 可視化をスコープ別にまとめる：/par_visualization_list.do?sysparm_query=GROUPBYsys_scope

• ダッシュボード一覧：/par_dashboard_list.do?sysparm_query=ORDERBYname

• 新しい系統の可視化：/analytics_visualization_list.do

検証範囲とおことわり

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

確認していないことがあります。Analytics Center の画面を開いて、このビューがどう見えるかは見ていません。自分で資産を作ってもいないので、追加したときにビューがどう変わるかも未確認です。

ビューの定義そのものも読んでいません。作成者で絞っているという説明は、件数の一致から導いた推定です。別の条件が同じ結果を生んでいる可能性は残ります。

par_visualization と analytics_visualization の関係も調べていません。件数が違うことを確認しただけです。

作成者の一覧には、ServiceNow 社内のものと見られるアカウントが2種類・計5件含まれていました。個人が特定できる情報なので、この記事にも画面にも載せていません。件数の内訳としてのみ触れています。

本番環境では資産の件数も作成者も変わります。この記事の数字は素の PDI の状態です。

関連記事

• ServiceNowのグラフ定義はどこに入る？ — 可視化が複数系統に分かれている話

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

• ダッシュボードをゼロから作る手順：グラフを1画面にまとめる — 資産を自分で作る側