ServiceNowで『状態に何日いたか』はどこに残る？ Metric Definitionを実機で確認

2026年6月21日 22:28

インシデントの対応時間を集計しようとしても、状態ごとに何日とどまっていたかがどこに保存されているのか分からないという相談を受けることがあります。ServiceNowはフィールドの値が変わるたびの経過時間を、metric_definition（何を測るか）とmetric_instance（測った結果）という2つのテーブルに自動記録しています。State滞留時間がどんな形で残るのか、Zurich PDIで実機を確認しました。

検証環境：Zurich PDI / OOTB / 2026-08-09 確認

結論：状態滞留時間は2テーブルとエンジンの連鎖で記録される

先に全体像です。

ServiceNowは、フィールドの値が変わるたびの経過時間をメトリクス（Metrics）という仕組みで自動記録します。「何を測るか」を決めるのがmetric_definition（測定定義）、「測った結果」を1件ずつ残すのがmetric_instance（測定結果）です。今回のPDIでは定義12件・結果179件でした。
State滞留時間のように値ごとの滞留時間を測る定義はtype=field_value_duration（8件）、scriptで算出する定義はtype=calculation（4件）です。calculationはtrue/falseの判定にも使えます。
metric_instanceは手作業では作られません。task系レコードの保存をきっかけに、Business Rule「metrics events」→ Event → Script Action → Script Includeという連鎖で自動生成されます。

metric_definitionは1件で複数のmetric_instanceを生みます。「Incident State Duration」という定義は1件ですが、結果は対象インシデントのState変化の数だけ増えます。だから定義12件に対して、結果は179件まで積み上がりました。

うち159件（incident 76・problem 67・change_request 16）は、現在activeな12定義のいずれかに紐づく結果です。残り20件は、Agile系のrm_release_scrum・rm_sprint・rm_storyというテーブルを指すレコードでした。この20件の正体は後述の「実機で気づいたこと」で扱います。

なお、テーブルの素性を見ると役割の違いがそのまま現れています。metric_definitionはLabelが「Metric Definition」で、sys_metadata（Application File）を継承するメタデータ系のテーブルでした。metric_instanceはLabelが「Metric」で継承元を持たないデータ系のテーブルです。定義は設定、結果はトランザクションデータという位置づけになります。

メトリクスとは何か

メトリクス（Metrics）とは、ServiceNowがレコードのフィールド変化を追跡し、「ある値だった時間」や「ある条件を満たしたか」を自動で記録する仕組みです。代表的な使い道は、State（状態）ごとの滞留時間や、作成から解決までの所要時間を残すことです。これらは後からレポート・分析の材料になります。

公式のMetric definition（Zurich）に、測定定義で追跡できる対象とtypeの考え方が説明されています。

何を測るかはmetric_definitionが決める

metric_definitionは「測定の設計図」です。今回のPDI（Zurich / OOTB）で確認した固有フィールドは11件で、測定の対象と方式を決める項目が中心でした。

押さえどころは3つです。

tableとfield … どのテーブルのどのフィールドを見るか。OOTBではincident / change_request / problem / kb_feedback_taskの各フィールドが対象になっていました。
type … 測り方。field_value_durationとcalculationの2種類だけです。
script … typeがcalculationのときに使う、結果を算出するロジック。

今回のPDIの12件は、対象テーブル別にincident 7件・change_request 2件・problem 2件・kb_feedback_task 1件でした。

定義の一覧は、次のURLで確認できます（先頭の<YourInstance>は自分のインスタンスに置き換えてください）。

https://<YourInstance>/metric_definition_list.do

なぜtypeは2種類だけなのか（field_value_durationとcalculation）

metric_definitionのtype（測り方）は、sys_choice上も2種類しかありません。

field_value_duration（Field value duration） … 指定フィールドがある値だった間の滞留時間を測ります。Stateのように値が遷移するフィールドに使うと、「Newに何時間」「In Progressに何時間」のように、値ごとに1件ずつmetric_instanceが作られます。代表例はIncident State Duration（incident_state）。
calculation（Script calculation） … scriptフィールドのロジックで結果を算出します。経過時間だけでなく、true/falseの判定にも使えます。代表例はFirst Call Resolution（一次解決だったか）やCreate to Resolve Duration（作成から解決までの合計時間）。

今回のPDIの12定義の内訳はfield_value_durationが8件・calculationが4件でした。滞留時間そのものを測りたいならfield_value_duration、条件判定や独自集計をしたいならcalculation、という使い分けになります。

12定義の対象（table / field / type）は次のとおりです。

State滞留時間はmetric_instanceにどう記録されるか

metric_instanceは「測定の結果ログ」です。今回のPDI（Zurich / OOTB）で確認した固有フィールドは17件でした。

フィールドの組み合わせを読み解く

読み解くときは次の組み合わせを押さえます。

definition（→metric_definition） … どの定義による結果か。
id（document_id） … 測定対象のレコード（例 Incident: INC0009002）。
field_value / value … 測定中だったフィールドの値（State値など）。
start / end / duration … その値に入った時刻（start）・抜けた時刻（end）・差分（duration）。
calculation_complete … 計測が確定したか。false=滞留中／true=確定。

下は、table=incidentのmetric_instanceを一覧したものです。Create to Resolve Durationの行には「2696 Days 15 Hours 56 Minutes」のような実際の経過時間が入ります。table=incidentの結果は今回76件でした。

State滞留時間は、このfield_value_duration型のmetric_instanceとして記録されます。「State値ごとに1レコード」という単位です。Stateが変わるたびに、前の値のレコードにendとdurationが入って確定します（calculation_complete=true）。新しい値のレコードはstartだけ持って始まります。

実例：1件のインシデントがStateを渡り歩く

定義をIncident State Duration一本に絞ると、1件のインシデントがStateを渡り歩く様子がそのまま並びます。あるインシデント（INC0010020）は、In Progressに42秒→On Holdに1分→In Progressに1分と細かく状態が動いたあと、Resolvedに7日と23分とどまっていました。直近のClosedの行だけはendが空でcalculation_complete=falseのままです。「いまのState」のレコードだけが、まだ確定していません。

結果の一覧は、次のURLで確認できます。

https://<YourInstance>/metric_instance_list.do?sysparm_query=table=incident

公式のMetric instance（Zurich）に、metric_instanceがdurationをstartとendから算出することなど、結果レコードの考え方が説明されています。

誰がmetric_instanceを作るのか（測定エンジンの正体）

metric_instanceは、フォームから人が手で作るものではありません。task系レコードの保存を起点に、Business Rule → イベント → Scriptという連鎖で自動生成されます。

図の色は5種類の意味に固定しています。濃紺は起点、橙はトリガーとなる分岐点です。紫は非同期のイベント層、水色は参照先（コード実行）、緑は結果の書き込みを表します。

測定エンジンの3ステップ

今回のPDI（Zurich / OOTB）で確認した流れは次のとおりです。

Business Rule「metrics events」（対象テーブル＝task / when=after）… task系レコードの保存後に走ります。変更されたフィールドを集めて、対象の定義があればイベントmetric.updateを発火します。
Event「metric.update」 … 「このレコードのメトリクスを更新する必要がある」という非同期イベント。
Script Action「Metric Update」（event=metric.update）… イベントを受けます。Script Include MetricInstanceを呼び出し、定義に従ってmetric_instanceを作成・更新します。

task側に紐づくからincident/problem/change_requestが対象になる

ここで効いてくるのが、Business Ruleがtaskテーブルに紐づいているという事実です。incident / problem / change_requestはいずれもtaskを継承するため、これらのレコードを保存すると自動的に「metrics events」が走ります。OOTBの測定対象がtask系に偏っているのは、エンジンの起点がtaskのBusiness Ruleだからです。

テーブル自身の設定だけでは測定ロジックは見えない

metric_instanceテーブル自身に紐づくBusiness Ruleは、「表示値を整える」もの1件だけです。測定の本体ロジックはtask側の「metrics events」とScript Include側にあり、周辺のBusiness Rule・ACL件数を数えても測定ロジックの姿は見えてきません。

新しく独自の測定を追加したいときも、この連鎖を踏まえて設計します。ポイントは、metric_definitionにレコードを1件追加するだけでよいことです。既存の「metrics events」がそのテーブルの変更を拾い、あとはScript Include側が自動でmetric_instanceを作ります。

「いつ変わったか」と「どれだけ長くいたか」の違い（sys_auditとの役割分担）

似た響きの仕組みにsys_auditがあります。値の変更を1回ごとに記録する監査ログで、Stateがいつ・誰によって・どの値からどの値に変わったかを追うテーブルです。詳しい保存の仕組みはServiceNowの変更履歴はどこに残る？ sys_auditと監査対象フィールドを実機で確認で扱っています。

metric_instanceが記録するのはその先です。その値に何秒・何日とどまっていたかという滞留時間そのものを、State値ごとに集計して持ちます。Stateが変わった瞬間の記録が欲しいときはsys_audit、Stateごとの滞留時間の合計が欲しいときはmetric_instance、という役割分担になります。

実機で気づいたこと

同じ環境を7週間後に数え直すと、定義は12件のままで結果だけが122件から179件に増えていました。カスタマイズは加えていません。PDIのデモデータは日々の運用を模してincidentやproblemが動き続けているため、metric_instanceも黙って増え続けます。数値は確認した時点のスナップショットとして読むほうが安全です。

12件の定義のうち2件は、今回metric_instanceが0件でした。1つはResolved by Known Error（incident・calculation）です。もう1つはKnowledge Feedback Task State Duration（kb_feedback_task・field_value_duration）です。定義はactive=trueのまま存在するのに、対応する結果が1件も生まれていません。定義があること自体は測定が動いている証拠にならず、instance側の件数まで見て初めて計測が生きているかどうかが分かります。

もう一つ意外だったのが、先述の20件のrm_release_scrum・rm_sprint・rm_story向けmetric_instanceです。definitionが指す先をたどると、現在のmetric_definitionテーブルにはそのsys_idのレコードが存在しませんでした。Agile Scrum用の測定定義がどこかの時点で削除され、それが生成したmetric_instanceだけが参照先を失ったまま残っている状態です。metric_instanceは定義が消えても自動では片付かず、孤立したレコードとして残り続けることが実機から分かりました。

実務では何に使える？

対応時間を集計するとき

対応時間を集計したいときは、まずmetric_instanceをtableやdefinitionで絞り込みます。あるインシデントがどのStateに何日いたかを知りたいときは、definition.name=Incident State Duration^id=<対象レコード>のようなクエリで一覧を絞れば、フォームのActivityタブを目で追うより早く合計が出せます。

独自の測定を追加するとき

独自の集計を増やしたいときは、metric_definitionを1件追加するだけで既存の測定エンジンに乗ります。値ごとの滞留時間を測りたいならtype=field_value_durationでtableとfieldを指定する形です。条件判定や合計時間のような計算をしたいならtype=calculationでscriptにロジックを書きます。対象テーブルがtaskを継承していれば、Business Rule「metrics events」が変更を拾ってくれます。測定エンジン側に手を入れる必要はありません。

結果が増えないときに確認すること

新しく作った定義の結果が増えないときは、対象テーブルがtaskを継承しているか、fieldが実際に変化しているかを確認します。今回の「実機で気づいたこと」のとおり、定義がactiveでも結果が0件のままということは普通に起こります。

さらに詳しく知りたい人へ

ServiceNowのBusiness Ruleはいつ動く？ before/after/asyncの違いを実機の件数で確認 — metric_instanceを生成している「metrics events」もBusiness Ruleの1つです。when=after・非同期イベントの仕組みを先に押さえたい人向け
ServiceNowの変更履歴はどこに残る？ sys_auditと監査対象フィールドを実機で確認 — 「いつ変わったか」を記録するsys_audit側を掘り下げます
SLA Definition（contract_sla）とは：時計を生むルール — 経過時間を扱う似た仕組みとして、SLAの時計がどう生まれるかを確認します

まとめ

State滞留時間は、metric_definition（何を測るか）とmetric_instance（測った結果）という2つのテーブルに分かれて記録されます。typeがfield_value_durationの定義は値ごとに1レコードを作り、start・end・durationで滞留時間を持ちます。この結果はフォームから人が作るものではなく、task側のBusiness Rule「metrics events」を起点にした連鎖で自動生成される仕組みです。

対応時間を集計するときは、まずmetric_instanceをtableとdefinitionで絞り込みます。新しい測定を増やしたいときは、metric_definitionに1件追加すれば既存のエンジンがそのまま動きます。

用語

PDI … Personal Developer Instance（無料の検証用インスタンス）
OOTB … Out of the Box（初期設定のまま）
メトリクス（Metrics） … フィールド変化を追跡し経過情報を記録する仕組み
metric_definition（測定定義） … 何を・どのテーブルの・どのフィールドで測るかのマスタ
metric_instance（測定結果） … 定義に従って作られる1件ごとの結果レコード
field_value_duration … フィールドがある値だった間の滞留時間を測るtype
calculation … Scriptで結果を算出するtype

実機で確認するときに開いたURL

定義一覧           : metric_definition_list.do
結果一覧（incident）: metric_instance_list.do?sysparm_query=table=incident
State滞留結果       : metric_instance_list.do?sysparm_query=definition.name=Incident State Duration
typeの選択肢        : sys_choice_list.do?sysparm_query=name=metric_definition^element=type
測定エンジンBR      : sys_script_list.do?sysparm_query=name=metrics events
instance固有項目    : sys_dictionary_list.do?sysparm_query=name=metric_instance^elementISNOTEMPTY

参考リンク

検証環境と未検証範囲

確認した範囲（PDI／Zurich／2026-08-09確認のOOTBで取得。初回確認は2026-06-20）:

metric_definition / metric_instanceの継承と固有フィールド数（11 / 17）
type選択肢（2種、内訳field_value_duration 8・calculation 4）
定義12件のtable/field/type
結果179件とtable内訳、および0件だった定義2件
実レコードのstart/end/duration/calculation_completeの挙動
測定エンジンの連鎖（Business Rule「metrics events」→ Event「metric.update」→ Script Action「Metric Update」→ Script Include「MetricInstance」）
周辺設定件数、および定義が削除された後もmetric_instanceが孤立して残る挙動

確認していない範囲（断定しません）:

Script Include MetricInstanceの内部実装の詳細
各calculation定義のscriptの中身
business_durationの算出スケジュール
incident_metricビュー（incident × metric_definition × metric_instanceを結合したOOTBのdatabase view）の内訳
Performance Analytics（indicator）との連携
timeline機能の描画

件数は確認時点の値です。PDIは日々のデモデータでレコードが増減するため、本番環境やカスタマイズ済みの環境はもちろん、同じPDIでも時間が経つと数値は変わります。