インシデント管理モジュールの運用手順書
障害の連絡を受けてから記録を閉じるまで、担当者は何を入力し、どこで判断するのか。この記事は、そのまま自社の運用手順書として使える形で手順をまとめたものです。Australia の PDI で実際にインシデントを1件処理し、各段階で必要な入力と自動で記録される内容を確認したうえで作成しています。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
手順書に含む内容
起票からクローズまでの作業手順
各段階で入力する項目と記入例
状態を変えたときに自動で記録される内容
保留・エスカレーション・クローズの判断基準
差し戻しを防ぐ確認項目
手順書として押さえること
起票からクローズまでの作業は9段階で構成される
起票時に入力する影響度と緊急度が、優先度とSLAの期限を決める
解決とクローズでは解決コードと解決メモの入力が必須になる
クローズ後は編集できないため、確認は閉じる前に行う
1. 本手順書の目的
インシデント管理の担当者が、障害の連絡を受けてから記録を確定するまでの作業を、迷わず同じ品質で実施できるようにする。
記録の品質を保つことを目的に含める。インシデントの記録は、SLA の評価・傾向の分析・問題管理への引き継ぎに使用されるため、入力の粒度が揃っていることが前提となる。
2. 適用範囲と前提条件
2-1. 適用範囲
本手順書は、ServiceNow のインシデント管理モジュールを使用する日常運用を対象とする。重大インシデント（Major Incident）の宣言手順は対象外とする。
2-2. 前提条件
項目内容対象バージョンAustralia（patch3）対象テーブルincident / incident_task必要なロールitil（担当者）／sn_incident_read（参照のみ）割り当てルール無効。担当グループは手動で選択する無操作監視無効。滞留の検知は朝会で行う
割り当てルールが無効であるため、起票されたインシデントは自動で担当グループへ振り分けられない。この前提を踏まえ、4章の朝の確認作業を必ず実施する。
3. 対象者と役割
役割担当する作業一次受付（サービスデスク）受付・起票・分類・一次切り分け・担当グループへの割り当て・クローズ二次対応担当者調査・復旧・解決の申告チームリード割り当ての調整・エスカレーションの受付インシデントマネージャ重大案件の指揮・品質の確認
同一の担当者が Resolved と Closed の両方を行うと利用者への確認が省略されるため、Resolved は担当者、Closed は一次受付に分ける。
二次対応担当者は、調査と復旧の完了をもって Resolved とする。利用者への確認は一次受付が行い、確認が取れた時点で Closed とする。
4. 作業の全体像
起票からクローズまでは9段階で構成される。
PDI で1件を処理したところ、更新回数（sys_mod_count）は 0 から 8 まで増加した。1件を最後まで処理するには最低9回の保存が必要となる。実際の運用では調査の経過を複数回追記するため、回数はさらに増える。
処理を完了したレコードには、解決情報が記録される。
4-1. 起票時の入力が期限を決める
起票のとき、影響度（Impact）と緊急度（Urgency）を入力する。優先度は入力せず、この2項目から自動で決まる。
検証では影響度・緊急度をそれぞれ 2 - Medium とした。優先度マトリクスにより優先度は 3 - Moderate となり、対応するSLAが2件付与された。
SLA定義対象期限Priority 3 response (4 hours)応答4時間Priority 3 resolution (1 day)解決1日
起票時の2項目が、追うべき期限を決める。影響度と緊急度の判定を誤ると、優先度もSLAも実態と合わなくなる。判定基準は6章に記載する。
インシデント全体のSLA定義は13件あり、優先度ごとに応答と解決の2種類が用意されている。
なお優先度1のSLAのみスケジュールが未設定であり、24時間365日で計測される。優先度2以下は平日8時〜17時で計測される。夜間・休日に優先度1が発生した場合、時計は止まらない。
参考：task_sla：1タスク1本のSLA時計の読み方 … 計測側のテーブル
参考：SLAが土日を飛ばす理由：営業時間（cmn_schedule） … 計測が止まる仕組み
4-2. 状態を変えると自動で記録される内容
9回の更新に対し、監査履歴（sys_audit）には28行が記録された。
state と incident_state が両方5回記録されている。操作したのは state のみだが、ビジネスルールが incident_state へ同期するためである。
作業メモと利用者コメントは、本体ではなく sys_journal_field に保存される。
1件を処理すると、本体1行のほかに監査履歴28行・追記2行・SLA2行が作られる。入力した内容は複数のテーブルに分散して残るため、記録を訂正する場合は本体の修正だけでは完結しない。
5. 作業手順
STEP1（New）：【一次受付】利用者からの連絡を1件のインシデントとして起票する
操作：左メニューから Incident > Create New を開く。または一覧画面の右上「New」ボタンを押す。
入力する項目
欄記入例補足Caller（利用者）山田 太郎代理起票の場合も実際の利用者を選択するShort description共有フォルダにアクセスできない40文字以内。症状を1文で記述するDescription営業部のファイルサーバ（\\\\fs01\\sales）が開けない。10時ごろから。同部署の3名で再現。いつ・どこで・誰が・何回を記述するCategoryNetwork6種類から選択するSubcategoryDNSカテゴリに応じて候補が変わるImpact2 - Medium6-1 の基準で判定するUrgency2 - Medium6-2 の基準で判定するContact typePhone受付経路を選択する
確認する項目
Priority が自動で入力されていること（Impact 2 × Urgency 2 なら 3 - Moderate）
同じ症状の既存インシデントが存在しないこと（重複の場合は Duplicate でクローズする）
大規模障害の場合、親インシデントを作成して子として紐づけるかを判断する
実施してはならないこと
Caller に担当者自身を入力する。利用部門別の集計ができなくなるため
Short description に「至急」「重要」と記述する。優先度は Impact と Urgency で表現する
症状と原因の推測を混在させる。起票時点では症状のみを記述する
STEP2（New）：【一次受付】対応する担当グループへ割り当てる
操作：Assignment group に対応するグループを選択して保存する。
割り当て先の目安
カテゴリ割り当て先NetworkNetworkDatabaseDatabaseSoftware / InquiryService DeskHardwareHardware / Field Services
割り当てルールが無効であるため、この判断は担当者が行う。
確認する項目
対応可能なメンバーが在籍していること
時間外の場合、そのグループの対応時間内であること
STEP3（In Progress）：【担当者】自分に割り当てて着手する
操作：Assigned to に自分を入力し、State を In Progress に変更する。UIアクション「Assign to me」を押すと担当者のみが入力される。
自動で記録される内容
assigned_to：担当者
reassignment_count：担当が変わった回数（1増加）
state と incident_state：どちらも In Progress へ
確認する項目
SLA の応答期限に間に合っていること（優先度3なら4時間以内）
自分が対応可能な内容であること。困難な場合は STEP2 へ戻り、別グループへ割り当て直す
記入例：着手時の作業メモ
一次受付。利用者へ電話で状況を確認。
・発生時刻：10:00ごろ
・影響範囲：営業部3名（同一フロア）
・再現性：あり（3名とも同じ症状）
・直前の変更：不明
これから名前解決の確認を行う。この記事の有料部に含まれるもの
STEP4以降の作業手順と、判断基準・異常時の対応・確認項目を記載します。
STEP4〜STEP9：作業メモ・保留・利用者への連絡・解決・クローズの操作と記入例（画面つき）
第6章 判断基準：影響度と緊急度の判定、保留の可否、エスカレーションの起点
第7章 異常時の対応：差し戻しの原因と防止策
第8章 補足：1日の運用サイクル、引き継ぎの書式、クローズ前の確認項目
分量は本文の後半およそ4,500字です。記入例をそのまま自社の様式に置き換えれば、運用手順書として使えます。
💰 ここから先は有料エリア
