インシデント管理モジュールの概要

「共有フォルダが開けない」と社内から連絡が来ます。担当者はまず何を記録すればよいのでしょうか。ServiceNow のインシデント管理は、この連絡を1件のレコードにして、誰が対応し、いつ業務が元に戻ったかを追跡できるようにするための仕組みです。原因の究明より、止まった業務を早く戻すことを優先します。Australia の PDI をデフォルト設定のまま開き、テーブル・状態・ロール・裏で動く設定を確かめました。

この記事で分かること

• インシデント管理が Problem・Change・Request とどう役割を分けているか

• Incident の1件がどのテーブルに、どんな項目で保存されるか

• 状態が6つある理由と、On Hold で保留理由を選ぶ意味

• デフォルトで何本の設定が incident に紐づいて動いているか

• 権限を分ける9つのロールの守備範囲

先に押さえておくこと

• インシデント管理は「原因を突き止める」より「サービスを早く戻す」ための記録である

• Incident は task を親に持つ1テーブルで、固有22項目と継承71項目の計93項目で構成される

• デフォルトでも ACL 151件・ビジネスルール38件・通知23件が incident に紐づいて動いている

インシデント管理の位置づけ

インシデント管理の目的は、止まった業務を早く戻すことにあります。原因の究明は Problem が引き受けます。恒久対策としての変更は Change の担当です。あらかじめ用意された依頼への対応は Request が受け持ちます。目的が違うため、4つは別のテーブルに分かれています。

灰色のノードがシステムの外から来る連絡です。同じ連絡でも、業務が止まっているなら Incident、事前に用意された依頼なら Request に分かれます。Incident はまず暫定対応で業務を戻します。同じ障害が繰り返すなら Problem へ引き継ぐ流れです。

この分担を外すと運用が崩れます。Incident の中で根本原因を追い続けている間、業務は止まったまま。逆に Problem を作らず Incident だけを閉じ続ければ、同じ障害が何度も起票されます。

Incident テーブルの継承構造

Incident は task テーブルを継承しています。実機の sys_db_object で確認できます。

super_class が Task です。スコープは Global。つまり Incident・Problem・Change・Catalog Task は、すべて同じ task を親に持つ兄弟にあたります。担当者・状態・優先度・説明といった共通の項目は、親の task 側で定義されています。

この構造は運用設計に効きます。「全プロセス横断で自分に割り当てられた作業を見たい」という要望は、task テーブルを1つ見れば満たせるためです。Incident と Change を別々に検索する必要はありません。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … 親テーブル側の項目構成

公式のフィールド説明（sys_documentation）

ServiceNow は製品の中にフィールドの説明文を同梱しています。sys_documentation の hint です。incident と task で35件（incident 15件・task 20件）に説明がありました。

主要なものを引用します。

（訳: インシデントまたは問題を解決すべき順序。影響度と緊急度にもとづく）

これは task.priority の説明です。優先度は影響度（impact）と緊急度（urgency）から導かれる順序だと公式が定義しています。2つの値の組み合わせで決まる項目です。

task.impact の説明も同じ考え方に立ちます。

（訳: 影響を受けたサービスの、業務上の重要度を測るもの）

影響度は止まったサービスが業務にとってどれだけ重要かを測る指標です。この定義を運用ルールに書いておくと、優先度の付け方が担当者ごとに揃います。

もう1つ、運用に直結する説明があります。

（訳: チェックすると、クローズ時にナレッジ記事の下書きを自動で作成する）

task.knowledge の説明です。ナレッジ化はクローズ時のチェックボックス1つで始まります。ナレッジ運用を回すなら、この項目をフォームに出しておくのが前提になります。

引用元: /sys_documentation_list.do?sysparm_query=nameINincident,task^hintISNOTEMPTY

フィールド構成

sys_dictionary を数えると、incident 固有が22項目、親の task から継承するものが71項目でした。合計93項目です。

固有22項目のうち、運用で意味を持つものを挙げます。

• caller_id：連絡してきた利用者。User への参照

• category / subcategory：分類。集計とルーティングの基礎になる

• hold_reason：保留理由。On Hold のときに何を待っているかを表す

• close_code：解決コード。どう決着したかを10種類から選ぶ

• resolved_at / resolved_by：いつ誰が解決したか

• reopen_count / reopened_time / reopened_by：再オープンの記録

• parent_incident / child_incidents：親子関係。大規模障害を1件に束ねる

• business_stc / calendar_stc：解決までの所要時間。営業時間ベースと実時間ベースの2種類

再オープンの項目が3つある点に注目してください。ServiceNow は「Resolved にしたあと差し戻される」ことを前提に設計されています。再オープン率は、初回解決の質を測る指標としてそのまま使えます。

解決時間が2種類ある理由も同じ発想です。calendar_stc は実時間、business_stc は営業時間ベース。金曜夜の障害を月曜朝に直した場合、実時間は60時間を超えますが、営業時間なら数時間で収まります。どちらで評価するかを先に決めておく必要があります。

93項目の全一覧と、どの項目を画面に出すかの判断は、本シリーズ第2巻「インシデント管理モジュールのテーブル・フィールド構成」で扱います。

状態（State）

sys_choice で state の選択肢を確認すると6件でした。すべて有効です。

value は 1・2・3 と続いたあと、4と5を飛ばして 6・7・8 になります。空いた番号は、独自の状態を後から差し込むための余地です。

各状態の意味を整理します。

運用上の要点は Resolved と Closed の違いです。Resolved は「担当者が直したと申告した」状態にすぎません。利用者の確認を経て、初めて Closed になります。ここを1段階に統合した設計では、直っていないのに完了扱いの件が出ます。

On Hold には保留理由が4種類あります。

• Awaiting Caller：利用者からの返答待ち

• Awaiting Problem：問題管理の結論待ち

• Awaiting Vendor：ベンダーの回答待ち

• Awaiting Change：変更の実施待ち

何を待っているかを記録に残す設計です。滞留の原因が自分たちの外にあるのか内にあるのかを、あとから集計できます。

解決コード（Resolution code）

close_code の選択肢は10種類ありました。どう決着したかを表します。

• Solution provided：こちらで解決策を提示した

• Resolved by caller：利用者側で解決した

• Resolved by change：変更を実施して解決した

• Resolved by problem：問題管理の恒久対策で解決した

• Resolved by request：申請プロセスで解決した

• Known error：既知の誤りとして扱った

• Duplicate：他のインシデントと重複していた

• User error：利用者の操作誤りだった

• No resolution provided：解決策を出せないまま終えた

Resolved by change / problem / request の3つは、他プロセスへ引き継いだ結果として閉じたことを示します。この3つの比率を見れば、インシデント管理だけで完結していない領域が分かります。

状態・優先度・カテゴリを自社に合わせて決める手順は、本シリーズ第5巻「インシデント管理モジュールの基本設定」で扱います。

incident に紐づく OOTB 設定

インシデント管理は、1つのテーブルとその周りで動く設定の集まりで構成されます。incident に紐づく設定を数えると、有効なものが282件ありました。

この表で注目すべきは最後の2行です。割り当てルール3つと無操作監視6つは、定義があるのに全件が無効でした。担当者の自動割り当てと放置の検知は、導入時に自分で有効化する前提になっています。

つまり導入直後は、起票されたインシデントが誰にも割り当てられないまま残り得ます。運用を始める前に、この2つを有効化するか、朝の確認作業で拾う手順を決めておきます。

• 参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 有効化する前に読んでおく

ビジネスルール

保存ボタンを1回押すと、サーバ側では複数の処理が順に実行されます。この処理の置き場がビジネスルール（sys_script）です。

動くタイミングは4種類に分かれます。フォームを画面に出す前（display）、データベースへ書き込む前（before）、書き込んだ後（after）、そして背景での非同期実行（async）。値の補正は before、他レコードの更新は after が受け持ちます。

実際の動きを1つ挙げます。担当者が Resolve を押すと mark_resolved というルールが動き、resolved_by に操作者、resolved_at に現在時刻を入れ、起票からの経過を実時間と営業時間の両方で計算して保存します。担当者が操作するのは状態だけで、解決の記録は自動で揃う仕組みです。

利用者が自分で解決を報告した場合の処理も用意されています。Caller Close は、利用者本人が状態を Resolved に変えたとき、解決コードへ「Resolved by caller」を自動で入れる処理。ポータルには解決コードの入力欄がないため、この補完がないと集計に空欄が混ざります。

もう1つ、全ルールの最初と最後には状態の同期が挟まっています。state と incident_state という2つの状態項目を、order 0 と order 1,000,000 の2件が相互に写し合う構成です。独自のルールを足して片方だけを更新しても、最後に同期で上書きされます。

各ルールの条件と処理の中身は、本シリーズ第6巻「インシデント管理モジュールの自動設定構成」で扱います。

通知

インシデントの状態が変わると、条件に合う通知がメールを送ります。定義の置き場は sysevent_email_action です。

通知は2段階で動きます。まずビジネスルール incident events が、作成・更新・コメント追記を区別してイベントを発行する。次に、そのイベントを購読する通知が条件を評価し、合致したものだけがメールを組み立てる。この2段構成のため、「通知が届かない」という相談では、通知定義の条件だけでなくイベントが発行されているかも確認します。

宛先はすべてレコードの項目から決まります。担当者へは assigned_to、利用者へは caller_id、関係者へは watch_list。特定のユーザーを固定で指定した通知は1件もありません。担当者が変われば通知先も変わり、組織変更があっても定義の修正は不要という作りです。

条件の細かさも実物から読み取れます。「Incident assigned to my group」は、担当者が空のまま担当グループが変わったときだけグループ全員へ送ります。担当者が決まっていれば、その人だけに届く設計です。

導入時にそのまま使うと、担当者に不要なメールが届く原因になります。1件ずつ宛先と条件を確認し、自社の運用に合わないものは条件を調整します。

• 参考：メール通知が飛ぶまでの4段階（Notification） … 届かないときはこの経路を順に追う

SLA 定義

contract_sla で incident 向けの定義は13件が有効でした。

種別が3つに分かれている点が重要です。

• SLA：利用者に約束する期限。Priority 1 response (15 minutes) のように優先度ごとに用意されている

• OLA：社内グループ間の期限。Database group resolution (P1 only)、Network group resolution の2つ

• Underpinning contract：外部ベンダーとの契約。SAN 001 contract resolution (3.5 hour) の1つ

利用者への約束が1時間でも、途中に入るベンダー契約が3.5時間なら守れません。3種類を分けて持つのは、この整合を検証するためです。

13件のうち2つは ATF（自動テスト）用の定義でした。実運用の想定は11件になります。

• 参考：task_sla：1タスク1つのSLA時計の読み方 … 計測側のテーブルを扱っています

• 参考：SLAが土日を飛ばす理由：営業時間（cmn_schedule） … 期限は営業時間で止まる

UI アクション（ボタン）

フォーム上の Resolve や Close といったボタンは、sys_ui_action にレコードとして定義されています。ボタン1つが1レコードで、表示する条件と押したときの処理を持ちます。

Resolve を例にすると、押した瞬間に画面側で incident_state と state の両方へ Resolved を設定し、resolved_by にログイン中のユーザーを入れてから保存します。ボタンは「状態を変えて保存する」操作の入口で、解決日時の記録や所要時間の計算はビジネスルールが引き受けます。

Create で始まるボタンは、他のテーブルへレコードを作ります。Create Change Request は変更を、Create Request は申請を、Create Incident Task は作業タスクを起票する入口です。インシデントから他プロセスへの接続は、参照フィールドではなくこのボタン群が担っています。緊急変更だけ Create Emergency Change として別のボタンになっているのは、承認経路が通常の変更と違うからです。

表示条件はスクリプトで判定されるものが多く、「ボタンが表示されない」という相談は condition 欄から切り分けます。同じ名前のボタンがフォーム用と一覧用で別レコードになっている点にも注意してください。1つを直しても、別の場所のボタンは変わりません。

• 参考：ServiceNowのResolveボタンはどこで動く？ UI Actionの表示条件とClient/Server処理 … 表示条件と処理の中身

システムプロパティ

コードを書き換えずに挙動を変えられる設定値は、システムプロパティ（sys_properties）に集まっています。管理画面から値を1行変えるだけで、複製・連携・クローズの動きが変わります。

例として複製の設定を見ます。Copy Incident を押したとき何を引き継ぐかは、com.snc.incident.copy.attributes に項目名のリストとして書かれています。既定は assignment_group / category / cmdb_ci / impact など18項目。この値を編集すれば、スクリプトに触れずに複製の範囲を変えられます。状態・担当者・作業メモはリストに含まれておらず、複製された件は新しい1件として始まります。

運用に効く設定を1つ挙げると、communicate_prb_workaround_to_inc_worknotes（既定 true）。問題管理で回避策が決まると、関連インシデントの作業メモへ自動で転記されます。担当者が問題側を見に行かなくても、回避策が手元に届く仕組みです。

連携の設定は受け取る側のモジュールに置かれる点も覚えておくと、探し物が速くなります。インシデントから問題を作るときの引き継ぎ項目は、com.snc.problem で始まる問題管理側のプロパティが決めています。nameLIKEincident の検索だけでは見つかりません。

各プロパティの既定値と変更の勘所は、本シリーズ第4巻「インシデント管理モジュールのプロパティ」で扱います。

• 参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方

ロールと権限

誰が何を操作できるかは、ロールとACLの2段で決まります。ロールは「その人が誰か」を、ACL（sys_security_acl）は「どのレコードのどの項目に何ができるか」を判定します。

ロールには階層があります。sn_incident_admin を頂点に、incident_manager → itil → sn_incident_write → sn_incident_read と包含される4段の構成です。上位を1つ付ければ下位は継承されます。担当者の標準は itil ですが、このロールは問題管理や変更管理への書き込みも含むため、インシデントだけに絞るなら sn_incident_write を選びます。

sn_incident_comments_write のような用途を1つに絞ったロールもあります。Additional comments だけに書き込めるロールで、外部委託先に利用者向けの連絡だけを任せる場面で使えます。

ACL 側の判定材料は、ロールよりも条件式が中心です。

有効な151件のうちロールが指定されているのは12件だけで、残りは「どの状態のレコードか」「担当者は誰か」を条件式で見ています。クローズ済みのインシデントが編集できないのは、26件のACLが Closed と Canceled を除外する条件を持っているからです。ロールを足しても解決しません。権限の相談を受けたら、ロールの前にまずレコードの状態を確認します。

各ロールの守備範囲と ACL の内訳は、本シリーズ第3巻「インシデント管理モジュールのロール」で扱います。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … 権限が効かないときはここを見る

incident を参照しているテーブル

sys_dictionary で incident を参照しているフィールドを検索すると73件が該当します。

ただし内訳を見ると、71件は Flow Designer の内部変数テーブルでした。var__m_sys_hub_flow_input_* のような自動生成テーブルです。フローの入力欄が Incident 型であるために生成されます。

実テーブルは2件だけでした。

• incident.parent_incident：インシデント自身への参照（親子関係）

• incident_task.incident：インシデントタスクからの参照

「73テーブルが連携している」と読むと誤ります。参照関係を数えるときは var__m_ で始まるテーブルを除外する必要があります。

問題管理・変更管理・リクエストとの具体的なつなぎ方は、本シリーズ第8巻「インシデント管理モジュールの連携機能」で扱います。

実機で気づいたこと

担当を自動で決める仕組みが最初から止まっている

割り当てルール（sysrule_assignment）はすべて無効でした。無操作監視（sysrule_escalate）も同じく無効です。

無効な理由は、グループ構成が環境ごとに異なるためだと読み取れます。カテゴリと担当グループの対応は、どの組織でも同じにはなりません。ServiceNow は定義だけを用意し、有効化の判断を利用者に委ねています。

この2つが止まっているため、デフォルトの状態では「誰にも割り当てられず、誰にも気づかれないインシデント」が発生し得ます。導入時のチェックリストに、有効化を明示的に入れます。順序としては、割り当てルールを先に有効化し、それでも滞留する件を拾うために無操作監視を有効にします。

状態の番号が4と5を飛ばしている

state の value は 1・2・3 のあと 6・7・8 と続きます。保留理由も 1・3・4・5 で、2 が空いています。

この空きは偶然ではなく、独自の値を差し込むための余地として残されていると考えられます。連番で埋めてしまうと、後から状態を追加するときに末尾へ足すことになり、画面の並び順を sequence で個別に調整する手間が生じます。

自社で「調査中」といった状態を追加する場合、4 か 5 を使います。ただし影響が及ぶ先は、ACLの条件式・ビジネスルール・SLAの計測条件・レポートのすべて。26件のACLが incident_state NOT IN 7,8 を条件に持つため、新しい状態を終了扱いにするならこの条件も直します。

参照の件数が実態の30倍以上に見える

sys_dictionary で incident を参照するフィールドを検索すると73件が該当します。ところが71件は Flow Designer の内部変数テーブル（var__m_*）でした。フローの入力欄が Incident 型であるために自動生成されるものです。

実テーブルは2件だけです。影響範囲の調査でこの数字をそのまま使うと、30倍以上に見積もることになります。

参照関係を数えるときは var__m_ で始まるテーブルを除外します。この命名規則さえ知っていれば、調査は2件の確認で済みます。

実務で順番に検討する箇所

インシデント管理を新しく設計するとき、確認する順序を決めておくと迷いません。

1. カテゴリ体系：category と subcategory を自社の分類に合わせる。集計とルーティングの基礎になる

2. 優先度の決め方：impact と urgency の組み合わせから priority を導く表を決める。公式説明どおりの考え方に合わせる

3. 割り当てルール：既定では全件無効。誰にどう振るかを決めて有効化する

4. Resolved と Closed の運用：誰が Closed にするか、何日で自動クローズするかを決める

5. 通知23件の取捨：未設定のままでは不要な通知も飛ぶ。宛先と条件を1つずつ見る

6. SLA の3種類：対顧客・社内グループ間・ベンダー契約の期限が矛盾しないかを検証する

7. プラグインの要否：重大インシデント管理や高度な作業割り当ては既定で無効。必要なら有効化を計画に入れる

用語

• OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態

• PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス

• ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則

• OLA：Operational Level Agreement。社内グループ間で交わす期限の取り決め

• ATF：Automated Test Framework。ServiceNow に同梱されている自動テストの仕組み

検証範囲とおことわり

• 検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認

• 件数はすべて OOTB の設定・定義の数です。本番環境やカスタマイズ済み環境では異なります

• 各ビジネスルール・通知の処理内容までは追っていません

• ACL 151件の内訳、実際の起票からクローズまでの操作は、このシリーズの後続記事で扱います

• 業務レコードの分布（どの状態に何件あるか）はデモデータ固有のため扱っていません

• problem_id / rfc の有無はバージョンとプラグイン構成で変わる可能性があります

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

• テーブル定義：/sys_db_object_list.do?sysparm_query=name=incident

• フィールド定義：/sys_dictionary_list.do?sysparm_query=name=incident^elementISNOTEMPTY

• 状態の選択肢：/sys_choice_list.do?sysparm_query=name=incident^element=state^language=en

• ビジネスルール：/sys_script_list.do?sysparm_query=collection=incident

• 通知：/sysevent_email_action_list.do?sysparm_query=collection=incident

• SLA定義：/contract_sla_list.do?sysparm_query=collection=incident

• UIアクション：/sys_ui_action_list.do?sysparm_query=table=incident

• システムプロパティ：/sys_properties_list.do?sysparm_query=nameLIKEincident

• ロール：/sys_user_role_list.do?sysparm_query=nameLIKEincident^ORnameLIKEitil

• ACL：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHincident

引用した公式説明を実機で確認する方法

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINincident,task^hintISNOTEMPTY

• プラグインの状態（引用元）：/v_plugin_list.do?sysparm_query=idLIKEincident

関連記事

• taskテーブル：ITSM全プロセスの共通の親 … Incident の親テーブルを先に知ると、93項目の内訳がつかみやすくなる

• ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … 原因究明を引き継ぐ側

• ServiceNow 変更管理（Change）完全ガイド：Standard・Normal・Emergencyをどう使い分けるか … 恒久対策を実施する側