レポート（sys_report）：4つの軸で読み解く
ServiceNow の画面で見る棒グラフや円グラフ、件数の一覧は、どれも「レポート」という同じ仕組みから作られています。見た目はバラバラでも、その定義は sys_report（Report） という1つのテーブルに、1レポート＝1レコードとして保存されています。
レポートの定義は、実際の sys_report テーブルを起点に「どのテーブルを（table）」「どの切り口で分けて（field）」「どう集計し（aggregate）」「どう見せるか（type）」の4つの軸で読み解けます。PDI（Zurich）の OOTB で確認した実測値（レポート総数・type 分布・対象テーブル分布）を添えて、この4軸を1つずつ確かめます。
想定する読者は、ServiceNow の Incident や Change は触ったことがあるが、レポート（Report）がどんなデータ構造でできているかをこれから理解したい管理者・開発者です。実機で確認するときは、sys_report の継承、主要フィールド、type の種類、aggregate の集計関数、周辺テーブルの順に見ると把握しやすくなります。
この記事で分かること
レポートの定義が sys_report（1レポート＝1レコード）に保存されること
sys_report が業務データではなく「メタデータ（設定）」のテーブルであること
レポートは table（対象）・field（切り口）・aggregate（集計）・type（可視化）で決まること
type にどんな種類があり、今回の PDI でどう分布していたか（bar 180 / list 104 …）
aggregate（COUNT / AVG / SUM …）の7種類
実機で確認するときに見るべき一覧URL
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、レポート定義・フィールド・件数の内容が異なる場合があります。
レポート（Report）とは
ServiceNow のレポートは、既存のテーブルにあるデータを集計・整理し、棒グラフ・円グラフ・一覧・トレンドなどの形で可視化します。「優先度ごとの未解決インシデント件数」「カテゴリ別の件数」といった図表は、すべてこのレポートとして作られます。
公式ドキュメントでの位置づけ
レポート・ダッシュボード・データビジュアライゼーションの全体像は、公式の Reporting（Zurich・Platform Analytics の入口） にまとまっています。棒・円・時系列・ヒートマップ・ピボットなど、どんな種類の可視化があるかもここで一覧できます。
その定義を格納する中心テーブルが sys_report（画面上のラベルは Report）です。グラフの種類や対象テーブル、集計の切り口といった設定が、1つのレポートにつき1レコードとしてここに保存されます。今回確認した PDI（Zurich / OOTB）では、sys_report に 648 件のレポート定義がありました。
sys_report が持つのは「データそのもの」ではなく「データの見せ方の設計図」です。 インシデントの実データは incident テーブルにあり、sys_report はそれを「どう集計してどう描くか」だけを持ちます。だから1つのテーブルに対して、棒グラフ・円グラフ・一覧など何種類ものレポートを作れます。
sys_report はメタデータ（設定）のテーブル
sys_report のまわりの継承関係を見ると、これまで見てきた incident（task 系）や cmdb_ci（CMDB 系）とは性格が違うことが分かります。
今回確認した PDI（Zurich / OOTB）では、sys_report は sys_metadata（Application File）を継承していました。incident や cmdb_ci が「業務データ」を入れるテーブルなのに対し、sys_report は「設定そのもの（メタデータ）」を入れるテーブルです。
この違いは移送の仕方に現れます。Application File を継承するレコードは Update Set に乗せて別インスタンスへ運べるので、レポート定義も「アプリ部品」として扱えます。開発インスタンスで作ったレポートを、そのまま本番へ持っていけます。なお、sys_report 自体の固有フィールドは 146 ありました。
固有フィールドを実際に見る
sys_dictionary で name=sys_report ／ element が空でない条件に絞り込むと、実際にこの146件を一覧で確認できます。フィールド1つ1つが Type や Reference といった詳細設定を持っているので、カスタムのレポート項目を追加したいときもここから探せます。
テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_reportレポートを決める4つの軸（table / field / aggregate / type）
sys_report の1レコードは、いくつかのフィールドの組み合わせで「1つのグラフ」を表します。なかでも中心になるのが、対象・切り口・集計・可視化の4つです。
table（対象テーブル） … どのテーブルのデータを集計するか。例：incident。
field（切り口） … どの列で分けて集計するか。例：priority、state、category。
aggregate（集計関数） … どう数えるか。例：COUNT（件数）、AVG（平均）。
filter（絞り込み条件） … 集計対象を絞るエンコードクエリ。例：active=true。
type（可視化の種類） … どう見せるか。例：bar（棒）、pie（円）、list（一覧）。
たとえば「優先度ごとの未解決インシデント件数を棒グラフで」というレポートは、table=incident、field=priority、aggregate=COUNT、filter=active=true、type=bar という組み合わせになります。この4つと filter を読めば、そのレポートが何を表しているかが分かります。
自分で新規に作る場合の手順
自分で新規にレポートを作る手順は、公式の Create a report（Zurich・自分でレポートを作る） にまとまっています。テーブル選択・type・group by・集計といった、レポート作成の入口にあたる手順が説明されています。
実際のレポート定義フォームを見ると、この対応がそのまま並んでいます。
これは「Opened Incidents this month by Priority」というレポートの定義です。Table が Incident [incident]、Field Name が priority、Type が Bar、Filter が「Opened on This month」になっており、まさに table / field / type / filter の組み合わせで1つのグラフが定義されていることが分かります。User が GLOBAL なのは、特定個人ではなく全員で共有するレポートだからです。
主なフィールドは次のとおりです。ラベルは画面上の表示名で、実機どおり英語で記載します。
表には出てこない補助フィールド
主要5フィールドのほかにも、chart_size（グラフの表示サイズ）／description（説明文）／aggregation_source（集計元の指定）／bar_unstack（積み上げ棒グラフの解除フラグ）／interval（時系列レポートの粒度）といった補助フィールドがあります。基本の4〜5フィールドだけでも十分にレポートは作れますが、細かい見た目や時系列の粒度を調整したいときはこのあたりも合わせて使います。
実機で同じものを見るときは、レポート一覧（sys_report.LIST）から1件開くと、このフォームを確認できます。
https://<YourInstance>/sys_report_list.do?sysparm_query=user=GLOBAL^ORDERBYtable
レポートを実行するとどう見えるか
定義（設計図）を実行すると、実データを集計したグラフが描かれます。先ほどの table / field / aggregate / type の組み合わせが、そのまま1枚の図になります。
これは「Open Incidents by Category」を実行した画面です。左側の Report Designer に Group by（切り口）= Category、Aggregation（集計）= Count、Table: Incident [incident]、絞り込み Active = true が並び、右側にカテゴリ別の件数が棒グラフとして出ています。
定義フォームの field / aggregate / table は、実行画面では Group by / Aggregation / Table としてそのまま可視化の軸になります。 レポート定義を読むことが、そのまま「このグラフが何を集計しているか」を読むことになります。なお Zurich では、こうしたレポートは新しいビジュアライゼーション（Platform Analytics）の画面で開かれます。
type（可視化の種類）の広がり
type は、同じ集計を「どう見せるか」を決めます。今回の PDI では、choices に多くの種類が登録されていました。大きくは一覧系・棒系・円系・時系列系・単一スコア・ピボット/地図系に分けられます。
実際に PDI の 648 件がどの type だったかを数えると、次のような分布でした。
今回確認した PDI（Zurich / OOTB）では、棒グラフ（bar）が 180 件で最多でした。次いで一覧（list）104 件、単一スコア（single_score）103 件、折れ線（line）60、円グラフ（pie）50、ヒートマップ（heatmap）25、トレンド（trend）23 と続きます。
list型の作り方は公式手順にある
一覧（list）型は基本の type の一つで、公式の Create a basic list report（Zurich・一覧レポート） に作り方がまとまっています。最も基本的な list 型レポートを、ゼロから作る手順を追った内容です。
type の choices には、実際の選択肢のほかに --- Time series charts --- のような「グループ見出し」も混ざります。これはドロップダウンを種類ごとに区切るための見出しで、選択肢ではありません。実際の type 値と混同しないようにします。
type の choices は、次のURLで一覧できます。
https://<YourInstance>/sys_choice_list.do?sysparm_query=name=sys_report^element=type^inactive=false^ORDERBYsequence
aggregate（集計関数）の種類
棒グラフや円グラフのように「分けて数える」レポートでは、aggregate がどう集計するかを決めます。今回の PDI では7種類の集計関数が選べました。
最も基本的なのは COUNT（件数を数える）で、今回の PDI では 445 件のレポートが COUNT を使っていました。金額や時間など数値フィールドを扱うときは AVG（平均）や SUM（合計）、MAX / MIN（最大・最小）を使います。COUNT(DISTINCT) は重複を除いた件数、STDDEV は標準偏差です。
aggregate は field とセットで意味を持ちます。「priority で分けて（field）件数を数える（COUNT）」のように、切り口と集計関数を組み合わせて初めて1つの集計になります。list（一覧）型のように集計しないレポートでは、aggregate は使われません。
レポートに関わる周辺テーブル
レポートの動きも、sys_report 1テーブルだけでは決まりません。色・共有先・データソース・ドリルダウンなど、複数の sys_report* テーブルが組み合わさります。
今回確認した PDI（Zurich / OOTB・2026-06-20 確認）では、レポート本体のまわりに次のようなテーブルがありました。
テーブル（物理名） 件数 ざっくりの役割
------------------------------------------------------------------------
sys_report（Report） 648 レポート定義の本体
sys_report_color（Color Definition） 545 グラフ系列の色定義
sys_report_users_groups（Report Users and Groups） 128 共有先のユーザー / グループ
sys_report_source（Report Source） 47 レポートのデータソース定義
sys_report_drill（Report Drilldown） 14 グラフから詳細へ辿るドリルダウン定義ここで数えているのは sys_report 系の主なテーブルだけです。実際にはダッシュボード（pa_dashboards など）や Performance Analytics の indicator、sys_report_map（地図表示用）など、レポートと連携する仕組みは他にもあります。レポート単体ではなく、共有・色・ドリルダウンといった周辺設定とセットで見ると、実運用での挙動が読み取りやすくなります。
対象テーブルの偏り
対象テーブル別に集計すると、incident が72件・change_request が71件と突出して多くなっていました。次いで problem28件・sc_req_item16件・cmdb_ci9件・task と kb_knowledge が各8件・sys_user が2件と続きます。ITSM の中心テーブルにレポート定義が集中していることが分かります。インシデント管理と変更管理という、運用担当者が日常的に見る領域に標準のレポート定義が手厚く用意されている形です。逆に kb_knowledge や sys_user のようにレポートが少ないテーブルは、日常的にグラフで追う対象になりにくい、という見方もできます。
今回の PDI では、648 件中 586 件が user=GLOBAL（全員共有）でした。レポートは個人専用にも全員共有にもでき、共有範囲は user / roles / sys_report_users_groups で決まります。roles で閲覧に必要なロールを追加指定することもできますが、今回は GLOBAL レポートのうち何件が roles を併用しているかまでは確認していません（検証範囲外）。
ServiceNow におけるレポート（sys_report）の要点
レポートの定義は sys_report（1レポート＝1レコード）に保存されます。今回の PDI では 648 件ありました。
sys_report は sys_metadata（Application File）を継承するメタデータのテーブルで、業務データではなく「設定そのもの」です。Update Set でアプリ部品として移送できます。
1つのレポートは table（対象）・field（切り口）・aggregate（集計）・filter（絞り込み）・type（可視化）の組み合わせで決まります。この5つを読めば、そのグラフが何を表すかが分かります。
type は多種類あり、今回の PDI では bar 180 / list 104 / single_score 103 が上位でした。choices にはグループ見出しも混ざります。
aggregate は COUNT / AVG / SUM / COUNT(DISTINCT) / MAX / MIN / STDDEV の7種で、今回の PDI では 445 件が COUNT を使っていました。
色・共有・データソース・ドリルダウンは sys_report_color / sys_report_users_groups / sys_report_source / sys_report_drill など別テーブルが担います。
レポートを調べるときは、対象テーブル（table）・切り口（field）・集計（aggregate）・可視化（type）を順に読むと、画面のグラフがそのまま定義として理解できます。
実機で気づいたこと
type の choices は本文で確認した19種類がありましたが、実際に一定数使われているのは bar・list・single_score など上位14種で、648件中634件（約98%）を占めていました。残り14件は funnel（じょうご型）・calendar（カレンダー）・box（箱ひげ図）・angular_gauge（Speedometer）・solid_gauge（Dial）などの少数派 type に分散しています。19種類の入口が用意されていても、実際に選ばれる type は一部に偏る、という実機の様子が見えました。
is_published（公開フラグ）が true のレポートは、648件中9件にとどまりました。もう少し多いだろうと予想していましたが、ほとんどの sys_report はこのフラグを立てずに使われていることになります。個別に開いて閲覧されるか、ダッシュボードへ部品として組み込まれる使われ方が主流だと考えられます。
集計の切り口を持つフィールドは field だけだと思っていましたが、sys_report には group_by という別フィールドも用意されていました。今回確認した棒グラフや円グラフのような単純集計のレポートでは中身が空で、マルチレベルのピボット系レポートで使うフィールドでした。同じ「切り口」でも、レポートの型によって使うフィールドが変わる作りだと分かりました。
aggregate の choices を確認していて、COUNT(DISTINCT という値に閉じ括弧がないことに気づきました。ラベルは「Count Distinct」ときれいな表記なのに対し、値（value）側は COUNT(DISTINCT のまま閉じられていません。表示には影響しませんが、スクリプトで aggregate の値を直接扱うときは、この値をそのまま使う必要があります。
次に読むなら
次に読むなら、レポートを並べて表示するダッシュボード（Dashboards）、レポートの一覧表示で使う List 型レポート、集計の切り口を段階的に下げていくドリルダウン（sys_report_drill）です。単発のレポートを複数並べてダッシュボードに広げる流れは、実運用で可視化を設計するときの次の一歩になります。いずれも本記事の4つの軸と周辺テーブルの先にあたり、別記事で扱う予定です。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
sys_report：レポート定義を格納するテーブル（ラベルは Report）
メタデータ：業務データではなく「設定そのもの」を表すデータ（sys_metadata 配下）
aggregate：集計関数（COUNT / AVG / SUM など）
type：レポートの可視化の種類（bar / pie / list / trend など）
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
テーブル定義 : sys_db_object_list.do?sysparm_query=name=sys_report
レポート一覧（共有） : sys_report_list.do?sysparm_query=user=GLOBAL^ORDERBYtable
フィールド一覧 : sys_dictionary_list.do?sysparm_query=name=sys_report^elementISNOTEMPTY
type の選択肢 : sys_choice_list.do?sysparm_query=name=sys_report^element=type^inactive=false^ORDERBYsequence
aggregate の選択肢 : sys_choice_list.do?sysparm_query=name=sys_report^element=aggregate^inactive=false^ORDERBYsequence関連記事
ServiceNow レポート・ダッシュボード完全ガイド：Data VisualizationsとPerformance Analyticsの使い分け — sys_reportの4軸を押さえたら、ダッシュボードやPAとどう組み合わせるかはこちらのガイドで確認できます
検証範囲とおことわり
確認した範囲：sys_report のクラス階層（→ sys_metadata / Application File）、固有フィールド数（146）、type の choices と分布（bar 180 ほか）、aggregate の choices（7種）、主要フィールドと意味、レコード総数（648）・GLOBAL（586）・COUNT（445）・公開（9）、対象 table 分布、周辺 sys_report* テーブルと件数。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲（断定しません）：各 type の描画内部仕様、Report Designer / Platform Analytics の新 UI の詳細挙動、sys_report_source の生成ロジック、ドリルダウンの実行時挙動、ACL によるレポート閲覧制御の詳細、Performance Analytics（indicator）との連携、ダッシュボード（pa_dashboards 等）との関係。これらは別記事で扱います。
今回は PDI の OOTB（初期設定）を前提に、レポート定義テーブルの構造を確認しました。実環境では、既存のカスタマイズや作成済みレポートによって、件数・type 分布・対象テーブルが変わります。
