Incident運用設計①：状態(State)を読む

2026年6月25日 00:20

【2026-09-01 追記】インシデント管理を11本で体系化したシリーズを公開しました。状態モデルを含む導入時の設定はインシデント管理モジュールの基本設定、シリーズの全体像はインシデント管理モジュールの概要からどうぞ。本記事は Zurich 時点の状態(State)深掘りとしてそのまま残します。

ServiceNowのIncidentを触ると、最初に意識するのが State（状態） です。
New から始まって、最後は Closed になる。だいたいの人はそう理解しています。

ただ、現場で迷うのはそこから先です。

On Hold って、いつ・誰が・どういう理由で使うのか
Resolved と Closed は何が違うのか
状態を変える前に、本当は何を確認しておくべきなのか

この記事は、その手前にある 「標準ではどうなっているか」 を、PDI（Personal Developer Instance）で実際に開いて確認したメモです。
公式ドキュメントを書き写すのではなく、OOTB（初期状態）の挙動を観察して、運用で使える言葉に翻訳することを目的にしています。

この記事はServiceNow PDI（Zurichリリース）で確認した個人検証メモです。
本番環境では、利用中のアプリケーション、ロール設計、既存カスタマイズ、運用ルールによって動作や見え方が変わる可能性があります。

公式の Life cycle of an Incident（Zurich）に、OOTBの状態遷移モデル（New〜Closedの流れと各状態の定義）が図付きで解説されています。

OOTBの状態は「6つ」だった

今回見ているのはここです。左のApplication Navigatorから Incident を開いた、標準のインシデント一覧です。

まず、Incidentの State にどんな選択肢があるのかをPDIで確認しました。

OOTBで有効な状態は、次の6つです。

状態                   内部値
-----------------------------
New（新規）            1
In Progress（対応中）  2
On Hold（保留）        3
Resolved（解決済み）   6
Closed（クローズ）     7
Canceled（取消）       8

これは「思い込み」ではなく、PDIの選択肢定義（State の Choices）を直接見て確認した内容です。

そして、この6状態の標準的な流れを図にすると、こうなります。

ここで面白いのが、内部値が「1,2,3,6,7,8」と飛んでいることです。4と5がありません。

これは標準の状態が、過去に整理された名残りです。
昔は「Awaiting（待ち）」系の状態が独立して並んでいたものが、今は On Hold + 理由 という形にまとめられています（理由のほうは後で出てきます）。

ここから分かる事実は、実務で押さえておきたい点です。

状態は「New / In Progress」といったラベルではなく、裏では数字（1,2,3…）で判定されている。

つまり業務ルールやレポートの条件は、表示名ではなく内部値で書かれます。
この感覚を持っておくと、後で「なぜ条件式が state=6 みたいな書き方なのか」が腑に落ちます。

新規作成時は必ず「New」から始まる

PDIでフィールド定義（Dictionary）を見ると、状態の初期値は 1（New） に設定されていました。

当たり前に見えますが、これは「Incidentは必ずNewから始まる」という標準の前提を、設定として明示しているということです。
ここを起点に、In Progress → （必要なら On Hold）→ Resolved → Closed と進んでいきます。

ちなみに Type は Integer（整数） でした。さきほどの「状態は数字で判定される」という話が、ここでも裏取りできます。

On Hold には「理由」がセットで用意されている

On Hold（保留）は、現場で一番扱いが割れる状態です。
PDIで確認すると、On Hold には専用の 理由（On hold reason） が標準で用意されていました。

On Hold の理由
--------------
Awaiting Caller（依頼者待ち）
Awaiting Problem（Problem待ち）
Awaiting Vendor（ベンダー待ち）
Awaiting Change（Change待ち）

これは設計として綺麗だな、と思った点です。

状態をむやみに増やさず、「止まっている」という事実は On Hold ひとつで表し、
「なぜ止まっているか」は理由フィールドという別の軸で持たせている。

逆に言うと、On Hold を理由なしで使うと、この設計の意図が死にます。
「とりあえず保留」が並ぶと、後から「これは何待ちだったのか」が誰にも分からなくなります。

実際のフォームでもこの通りで、State を On Hold にすると On hold reason が現れます。下はデモデータの INC0000002（Awaiting Vendor＝ベンダー待ち）です。

公式の Incident Management（Zurich）に、On Hold を含む各状態の目的と、製品全体の概要が説明されています。

Closeには「分類(Close code)」が最初から付いている

クローズ時の Close code（クローズコード）も、OOTBで10種類が用意されていました。

Duplicate / Known error / No resolution provided / Resolved by caller /
Resolved by change / Resolved by problem / Resolved by request /
Solution provided / Workaround provided / User error

注目したいのは、Resolved by problem / change / request が最初から入っていることです。
ServiceNowは「Incidentは単独で閉じるとは限らない。Problem・Change・Requestに引き継がれて解決することがある」という前提を、選択肢のレベルで持っています。

ここでは「そういう語彙が標準である」までにとどめ、
どのClose codeをいつ選ぶかという判断は、後半の実践編で早見表にまとめます。

実際のIncidentは、どの状態に溜まっていたか

最後に、このPDIのデモデータが実際にどの状態で止まっているかを数えてみました（全68件）。

状態         件数
-----------------
Closed       30
In Progress  20
New          11
On Hold      7

PDIのリストを State でグループ化すると、この分布がそのまま見えます。

参考までに、同じ数字を図にするとこうなります。

ここでひとつ観察があります。
Resolved が 0 件でした。Resolved を経由せずに Closed になっているレコードがある、ということです。

これは「Resolvedを必ず通さないとClosedにできない」わけではない、という標準の柔らかさを示唆します。
ただし、デモデータの作られ方によるものかもしれないので、遷移ルールの結論にはしません（ここは別記事で、UI PolicyやBusiness Ruleを実際に開いて確かめます）。

ここまでのまとめ（無料部分）

PDIで確認できた標準の事実は、次の通りです。

OOTBの状態は 6つ（New / In Progress / On Hold / Resolved / Closed / Canceled）、内部値は飛び番
新規は必ず New（1） から
On Hold には理由フィールドがセットで用意されている
Close code は10種類、Problem/Change/Request連携を前提にした語彙
デモデータ上は Resolvedを経由しないClosed も存在した

ここまでが「標準ではどうなっているか」です。

ここから先、現場で実際に効いてくるのは「状態を変える前に何を確認するか」です。

状態ごとの遷移チェックリスト（New→In Progress→…→Closed で、各段階の確認事項）
On Hold の4理由を、現場でどう使い分けるか（判断フロー）
Close code 10種類の選び分け早見表
Reopen（再オープン）が起きたときの扱い
Problem / Change への切り出し基準

これらは、自分のチームの一次対応〜クローズの手順にそのまま落とせる形で、この続きにまとめました。

ServiceNowのインシデント1件は何テーブルに書かれる？周辺13テーブルを実機で数える — State（状態）はincidentテーブル1件が抱える多数のフィールドの1つです。周辺13テーブルとの関係を俯瞰できます。