ServiceNowの標準ダッシュボードは移行できる？ ready_to_migrateの実測とメタデータの不一致

新しい Platform Analytics に移るとき、いま使っているダッシュボードがどうなるのかは気になるところです。Australia の PDI を開くと analytics_dashboard に28件あり、ready_to_migrate という移行フラグを持っていました。選択肢は4つ用意されています。ところが実機で使われている値は1つだけでした。移行元の pa_dashboards は0件です。

分析基盤を移すとき、最初に確認したいこと

「新しい Platform Analytics に移りましょう」と言われたとき、担当者が最初に思うのは「いま使っているダッシュボードはどうなるのか」です。

答えるには2つ確認する必要があります。移行の対象になっているのか。 そして移行が必要な状態なのか。

作り直しになるのか、そのまま持っていけるのか。ここが決まらないと工数が見積もれません。

新旧のダッシュボードは同居している

ServiceNow のダッシュボードは、世代の違うテーブルが並存しています。

従来の Performance Analytics のものが pa_dashboards。ホームページ由来のものが sys_dashboard。そして新しい Platform Analytics のものが analytics_dashboard です。

旧構造の中身はダッシュボードは1枚のレコードじゃない（pa_dashboards）で扱いました。片方が空になって置き換わるのではなく、同時に存在するのがこの領域の特徴です。

だから「移行するかどうか」を1件ずつ判断する必要が出てきます。その判断を記録するのが、この記事で見る移行フラグです。

移行フラグは何のための項目か

analytics_dashboard には ready_to_migrate という項目があります。そのダッシュボードが移行の準備できているかを記録する欄です。

有益性は、棚卸しの状態を製品側の項目で持てることにあります。Excel で管理表を作らなくても、レコードに書いておけば全員が同じものを見られます。

このテーブルは Application File を継承していました。アプリケーションの一部として扱われ、更新セットで運ばれる側です。移行の判断も一緒に運べることになります。

付随情報は analytics_dashboard_metadata という別テーブルに分かれていました。こちらは継承なしの基底テーブルで、その環境での作成者や更新日時を記録する入れ物です。定義と状態を分ける作りは、可視化の側でも同じでした。

結論：移行フラグは4値あるのに、実機では2値しか出ない

実測して分かったことを3点にまとめます。

移行フラグ ready_to_migrate の選択肢は Yes / No / Not Applicable / Already Migrated の4つ。実機では Not Applicable が20件、未設定が8件で、残る3つの値は1件も使われていません。

未設定の8件には共通点がありました。全部がアプリケーション固有スコープ由来で、Global のものは1件もありません。

そして本体28件に対しメタデータは29件。単純な1件ズレではなく、孤児が2件・メタデータ無しが1件という内訳でした。

28件のダッシュボードは全部が同じ状態

まず一覧を開きます。

active は28件とも true。certified は28件とも false。base_dashboard も28件とも空でした。

3つのフラグが揃って同じ値というのは、逆に言えばこれらが使われていないという意味になります。certified に true のものが1件もないので、認定という運用は行われていません。

description が空なのは14件。ちょうど半分です。名前だけで何のダッシュボードか判断することになります。

移行フラグは4値あるのに2値しか出てこない

本題の ready_to_migrate を見ます。

画面に出るのは2グループだけでした。未設定が8件、Not Applicable が20件です。

選択肢の定義を確認すると、4つ用意されていました。

Yes も No も Already Migrated も0件。移行の判断が行われた形跡が1件もありません。

Not Applicable が意味すること

20件に付いている Not Applicable は「移行の対象外」です。移行するかどうか以前に、そもそも関係ないという扱いになります。

これは自然でした。Analytics Usage Overview や MID Server のような、新しい仕組みで最初から作られたダッシュボードは、移行する元がありません。

Guided Tours – Operational Reporting や Gen AI Actions Dashboard も同じです。名前を見れば、比較的新しい機能に紐づくものだと分かります。

移行元が0件だった

移行という言葉が出るからには、移行元があるはずです。pa_dashboards を開きました。

0件でした。

この環境には移行すべき旧ダッシュボードが存在しません。だから Yes も Already Migrated も付きようがない。フラグが使われていない理由は、機能の停止ではなく対象の不在でした。

旧ダッシュボードの構造そのものはダッシュボードは1枚のレコードじゃない（pa_dashboards）で扱いました。この記事を書いた環境には3件ありましたが、こちらには入っていません。

未設定の8件は何が違うのか

残る8件が未設定なのはなぜか。作成者やスコープを並べると、はっきりした差がありました。

未設定の8件は、スコープが ITSM Analytics が5件、Security Center が2件、Incident Management for Service Operations Workspace が1件。Global は1件もありません。

一方 Not Applicable の20件は、13件が Global でした。残り7件も個別スコープですが、Global が主体です。

アプリケーションが持ち込んだものにはフラグが付かない

名前を見ると性格がはっきりします。未設定の8件は Incident Management / Request Management / Service Catalog / Interaction / IT Agent Dashboard / Password Reset Overview、そしてセキュリティ姿勢の2件でした。

どれも ITSM プロセスやセキュリティのアプリケーションが提供するダッシュボードです。プラットフォーム側で作られたものではありません。

フラグを埋める処理が、スコープ付きアプリケーションのレコードには及んでいない。そう読むのが自然に見えます。プラグインごとにレコードが持ち込まれる仕組みはプラグイン（v_plugin/sys_plugins）の有効・無効と依存で扱いました。

作成年にも差がある

未設定の8件は2023年が4件、2024年が4件。2022年も2025年もありません。

Not Applicable の20件は2022年から2025年まで散らばっています。追加された時期の幅が違います。

決定的な証拠ではないものの、別の経路で入ってきたレコードだという見方を補強する材料になります。

メタデータ29件との不一致を解く

もうひとつ調べたことがあります。analytics_dashboard_metadata の件数です。

本体が28件、メタデータが29件。1件多い状態です。

1件ズレではなかった

差が1なので「メタデータが1件余っている」と考えたくなります。実際に突き合わせると違いました。

本体に存在しないダッシュボードを指すメタデータが2件ありました。参照先の表示名が空で、レコードとして残っているだけです。作成日は2023年11月8日と2024年1月10日でした。

逆にメタデータを持たない本体が1件あります。Data Classification です。

27件が対応していて、そこに孤児2件とメタデータ無し1件が加わる。差し引きすると1件差になります。打ち消し合って1に見えていただけでした。

孤児が生まれた理由を考える

ダッシュボードを削除したとき、メタデータが残ったのだと考えられます。参照先が消えても、この行は消えていません。

削除時に連動して消す仕組みが無いか、あっても働かなかったか。どちらかは判断できません。

実務への影響は小さいでしょう。孤児のメタデータを読んでも参照先が無いだけで、動作を壊すものではありません。ただし件数を数えるときには効いてきます。

last_deactivated_on は全件空

メタデータには last_deactivated_on という列がありました。29件すべて空です。

無効化された記録が1件もありません。本体の active が28件とも true だったことと符合します。

この列が用意されているということは、ダッシュボードを無効化する運用が想定されているという意味になります。素の環境では使われていないだけです。

メタデータが持つ4つの日付列

analytics_dashboard_metadata は6つの列を持っていました。参照先の dashboard と、作成者・更新者、そして3つの日付です。

created_on が作成日、last_updated_on が最終更新日、last_deactivated_on が最後に無効化した日。この3つで、ダッシュボードの一生を追える設計になっています。

created_by は System Administrator が28件、maint が1件でした。人の手で作られたものは無く、全部が製品側から入っています。

作成年と更新年を並べると分かること

作成年は2022年3件、2023年10件、2024年14件、2025年2件でした。2024年に集中しています。

最終更新年も同じ傾向でした。2022年1件、2023年6件、2024年17件。2025年が4件で、2026年は1件です。

作成と更新の分布が似ているのは、作った後にほとんど触っていないことを意味します。入れたきりのダッシュボードが多いという読み方ができます。

2026年に更新されたのは1件だけ。この環境が作られたのは2026年なので、その1件が何らかの理由で触られたことになります。

日付を棚卸しに使う

last_updated_on が古いものは、使われていない候補です。2022年や2023年で止まっているものは、少なくとも中身が変わっていません。

もっとも、更新していないことと使っていないことは別です。完成したまま毎日見られているダッシュボードもあります。判断材料の1つとして扱うのが妥当でしょう。

同じ考え方はスケジュールジョブでも使えます。定義があることと動いていることを区別する方法はServiceNowのスケジュールジョブは本当に動いている？で扱いました。

認定フラグが全件 false である意味

certified が28件とも false だったのも気になった点です。

このフラグは「このダッシュボードは信頼できる」という印だと考えられます。組織のなかで公式なものと、誰かが試しに作ったものを区別する用途でしょう。

素の環境で全部 false ということは、標準で入っているものすら認定扱いにしていないという意味になります。認定するかどうかは各社が決める、という立場です。

運用としては使いどころがあります。ダッシュボードが増えてきたとき、正式なものだけを絞り込む軸になります。名前の付け方で区別するより、フラグで持つほうが確実です。

base_dashboard も全件空だった

もうひとつ、base_dashboard という列があります。28件とも空でした。

名前からすると、他のダッシュボードを土台にして作った場合に、その元を指す列でしょう。複製して作ったものの系譜を追える仕組みだと考えられます。

標準で入っているものは、どれも独立して作られています。だから空のままです。自分たちで複製を作り始めると、ここに値が入るようになるはずです。

空のフラグが3つ揃っているのは、この環境がまだ何も運用していない状態だと示しています。

新旧のダッシュボードが同居する状態

この環境には、ダッシュボードに見えるテーブルが複数ありました。

analytics_dashboard が28件。sys_dashboard が16件。sys_portal_page が54件。そして pa_dashboards が0件です。

同じ「ダッシュボード」という言葉でも、指しているものが違います。どれを見るかで件数も内容も変わるので、話をする前に対象を決める必要があります。

どのテーブルを見るべきか

新しい Platform Analytics の画面を触っているなら analytics_dashboard です。この記事で扱ったのはこちらになります。

従来の画面を使っているなら sys_dashboard や pa_dashboards の側です。移行の話が出るのは、この2つの世界が併存しているためでした。

グラフ定義でも同じ構造がありました。新旧2系統が同時に実データを持っていて、どちらを見るべきかという問いが出ます。ServiceNowのグラフ定義はどこに入る？で766件と636件の併存を扱いました。

併存が続く前提で考える

移行フラグに Not Applicable が20件付いているのは、移行しないものが多数派だという意味です。

全部を新しい側に寄せる想定なら、こんな値は要りません。関係ないものが存在することを前提にしたフラグ設計になっています。

自分の環境でも同じでしょう。全部を一度に移す計画より、新しく作るものは新しい仕組みで、既存のものは必要になったら移す、という進め方のほうが現実的です。

指標の設計そのものをどう決めるかはServiceNowのPerformance Analyticsは何を測る？にまとめました。

28件に何が入っているのかを分類する

名前を眺めると、性格の違うものが混ざっていました。分けて考えると全体像がつかめます。

プロセスを測るもの

Incident Management、Request Management、Service Catalog、Interaction。ITSM の各プロセスに対応するダッシュボードです。

説明文には「Open and Closed の process metrics を見る」といった内容が書かれていました。件数や滞留を追う、いちばん想像しやすい種類です。

この4件はすべて ready_to_migrate が未設定でした。アプリケーション由来という共通点があります。

使われ方を測るもの

Analytics Usage Overview / Usage Overview / Legacy Usage Overview / ServiceNow Store Usage Overview / Inbound API Integration Usage。名前に Usage が付くものが5件ありました。

測る対象が業務の結果ではありません。システム自体がどう使われているかを見る種類で、管理者向けの視点になります。

Legacy Usage Overview の説明には「Interface の利用状況を見る」とありました。古い画面がまだ使われているかを確認する用途でしょう。移行を考えるときに役立つ種類です。

資産や基盤を見るもの

Asset Overview / My Assets / Application Services Dashboard / MID Server / Workflow Operations Dashboard の5件です。

MID Server の説明には「different metrics のスナップショット」とありました。連携基盤の状態を見るためのものです。

新しい機能に紐づくもの

Gen AI Actions Dashboard、Guided Tours – Operational Reporting、Instance Scan Results Next Experience Dashboard、Data Classification。

比較的新しい機能に対応するダッシュボードです。機能が追加されるたびに、それを測る画面も一緒に入ってくると分かります。

28件のうち4分の1近くが、ここ数年で足された機能のものでした。標準ダッシュボードは固定の集合ではありません。機能が増えるたびに一緒に増えていくものだという見方ができます。

自分の環境で同じ調査をするには

この記事でやったことは、レコードを読んで突き合わせただけです。同じ手順が自分の環境でも使えます。

手順1：分布を見る

まず GROUPBY でまとめます。ready_to_migrate、sys_scope、active あたりを軸にすると傾向が出ます。

グループが2つしか出ないなら、選択肢の定義と突き合わせます。使われていない値があるかを確認する作業です。

手順2：選択肢の定義を確認する

フィールドが取りうる値は、選択肢の定義側にあります。実際の分布と並べると、使われていない値が見えます。

ここで差が出たら、それ自体が調べる価値のある事実です。設計として想定されているのに、環境では発生していない状態を意味します。

手順3：2つのテーブルを突き合わせる

本体とメタデータのように対になるテーブルがあるなら、両方向から突き合わせます。

片方にあって他方に無いものを、両側から数える。これをやらないと、打ち消し合った差を見逃します。今回はこれで内訳が出ました。

この調べ方が効く場面

今回のように「定義はあるが使われていない」を見つける手順は、他の機能にも応用できます。

新機能の実態を測るとき

リリースノートに書かれた機能が、自分の環境で実際に動いているかは別の話です。テーブルを開いてレコードを数えれば、すぐ判断できます。

0件なら定義だけ。値が偏っていれば、想定された使い方の一部しか発生していない。今回の ready_to_migrate がその例でした。

移行の計画を立てるとき

新旧が併存する機能では、両方の件数を並べるのが出発点になります。旧側が0件なら移行作業は発生しません。

ダッシュボードの作り方そのものを知りたい場合はData Visualizationsでグラフをゼロから作る手順から追うとよいでしょう。作る手順を知っていると、移行で何が失われるかの見当が付きます。

標準機能の設計意図を読むとき

使われていない列やフラグは、製品が何を想定しているかを教えてくれます。

certified があるということは、認定という運用が想定されているという意味です。base_dashboard は複製して育てる使い方を、last_deactivated_on は無効化して残す運用を、それぞれ前提にしています。

どれも素の環境では空でした。空欄の並びから、製品側が用意した運用の型が読み取れます。

用語

analytics_dashboard：新しい Platform Analytics のダッシュボード定義。この環境では28件。

ready_to_migrate：旧ダッシュボードからの移行状態を表すフラグ。Yes / No / Not Applicable / Already Migrated の4値。

pa_dashboards：従来の Performance Analytics のダッシュボード。この環境では0件。

メタデータ：作成者・更新者・日時を持つ付随レコード。analytics_dashboard_metadata に入る。

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

孤児レコード：参照先が存在しなくなった行。ここではメタデータ2件が該当する。

実機を見て気づいたこと

「件数が1違う」を1件ズレだと決めつけない

28と29を見たとき、真っ先に「1件余分」と考えました。突き合わせたら、+2と−1が同時に起きていました。

数の差だけを見て原因を推測すると、こういう構造は見えません。両方向から突き合わせる必要があります。本体にあってメタデータに無いもの、メタデータにあって本体に無いもの。両方を数えて初めて内訳が出ます。

グラフ定義を調べたときにも同じ形の差を見つけていました。あのときは説明できないまま残しましたが、同じ方法で調べれば内訳が出るはずです。

選択肢が4つあっても使われるとは限らない

ready_to_migrate は4値を持ちながら、実機では1値しか出ませんでした。

選択肢の定義は「取りうる値」であって「使われている値」ではありません。設計書に4つの状態を書いても、環境によっては1つしか現れない。

標準機能を調べるとき、選択肢の一覧と実際の分布を両方見る習慣が要ります。片方だけだと実態を読み違えます。

フラグが空なのは機能の境界を示している

未設定の8件が全部アプリケーション由来だったのは、調べてみるまで予想していませんでした。

最初は「たまたま埋まっていない」と思っていました。スコープで分けたら、Global が0件という明確な線が出ます。偶然でこうはなりません。

空欄が揃っている場所には理由がある。どこで処理が止まっているかを教えてくれる情報として読めます。

実務では何に使えるか

移行を検討する前に見る2つの数

自分の環境で移行を考えるなら、確認する順番があります。

まず pa_dashboards の件数です。ここが0なら、移行という作業自体が発生しません。新しい仕組みで作り直すだけになります。

次に analytics_dashboard の ready_to_migrate を見ます。Yes が付いているものがあれば、移行対象として認識されているという意味です。

この2つで、自分の環境がどの段階にいるかが分かります。ダッシュボードを新規に作る手順はダッシュボードをゼロから作る手順：グラフを1画面にまとめるにまとめました。

標準ダッシュボードの棚卸しに使う

28件のうち、実際に使われているものは限られるはずです。description が空の14件は、名前だけで判断することになります。

メタデータの last_updated_on を見れば、いつ最後に触られたかが分かります。2022年から更新されていないものは、使われていない可能性が高い。

この考え方は他の資産でも同じです。標準で入っているものを全部使う必要はありません。何が入っているかの全体像はServiceNow標準ダッシュボード全体像：どんなダッシュボードがあるかで扱いました。

スコープを見ると出どころが分かる

ダッシュボードが増えていくと、どれが標準でどれが独自か分からなくなります。

sys_scope を見れば、どのアプリケーションが持ち込んだかが判別できます。Global なら基盤側、それ以外ならアプリケーション由来です。

この見分け方は、アップグレードで上書きされるかどうかの判断にも効きます。自分たちで作ったものは Global に置かれることが多いので、名前だけでなくスコープと作成者を合わせて見ます。

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

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

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

• 移行フラグ別にまとめる：/analytics_dashboard_list.do?sysparm_query=GROUPBYready_to_migrate

• メタデータ一覧：/analytics_dashboard_metadata_list.do?sysparm_query=ORDERBYdashboard

• 旧ダッシュボード：/pa_dashboards_list.do

• スコープ別にまとめる：/analytics_dashboard_list.do?sysparm_query=GROUPBYsys_scope

検証範囲とおことわり

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

確認していないことがあります。ダッシュボードを開いて中身の表示を見ていません。移行の機能を実行していないので、ready_to_migrate を書き換えたときに何が起きるかは分かりません。

孤児になっているメタデータ2件が、もともと何を指していたかも追えていません。参照先の sys_id は残っていますが、対応するレコードが存在しないので中身は分かりません。

pa_dashboards が0件である理由も特定していません。Zurich の PDI には3件ありました。環境の作られ方の違いだと考えられますが、確認していないので断定しません。

本番環境ではダッシュボードの件数も分布も変わります。この記事の数字は素の PDI の状態です。

関連記事

• ダッシュボードは1枚のレコードじゃない（pa_dashboards） — 移行元にあたる旧構造

• ServiceNowのグラフ定義はどこに入る？ — 新旧2系統が併存する話

• ServiceNow標準ダッシュボード全体像：どんなダッシュボードがあるか — 何が入っているかの一覧