インシデント管理モジュールの基本設定
インシデント管理を導入するとき、最初に決めるのは選択肢の中身です。状態をいくつ持つか、優先度をどう決めるか、カテゴリを自社の分類に合わせるか。ここを決めないまま運用を始めると、後から集計ができません。Australia の PDI をデフォルト設定のまま開き、選択肢の定義・優先度の導き方・SLA・割り当てルールがどう用意されているかを確かめました。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
導入時に決めること
選択肢を持つ項目と、その型の違い
優先度が影響度と緊急度からどう決まるか
判定基準を自分で決める必要がある理由
カテゴリとサブカテゴリの依存関係
SLA定義が3種類に分かれている理由
既定で無効になっている設定
設定を決める前に知っておくこと
選択肢は状態6・優先度5・影響度3・緊急度3・カテゴリ6・サブカテゴリ19で構成される
優先度は影響度×緊急度の9通りから自動で決まり、5 - Planning だけは手動選択になる
割り当てルール3つと無操作監視6つは定義があるものの、すべて無効
選択肢の全体像
インシデントで選択肢を持つ項目は11個ありました。
保存される型が2種類に分かれます。Integer で持つのは state・priority・impact・urgency・severity・hold_reason・notify の7項目。String で持つのは category・subcategory・close_code・contact_type の4項目です。
同じ「選択肢」でも型が違うため、条件式の書き方が変わります。priority=1 と category=hardware のように、数値と文字列を使い分けます。
参考：選択肢Choice（sys_choice）：ドロップダウンの中身 … 選択肢はここに保存される
優先度は影響度と緊急度から自動で決まる
優先度を担当者が直接選ぶ設計ではありません。影響度（Impact）と緊急度（Urgency）の組み合わせから導かれます。
task.priority の公式説明がこの考え方を明示しています。
Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency
（訳: インシデントまたは問題を解決すべき順序。影響度と緊急度にもとづく）
引用元: /sys_documentation_list.do?sysparm_query=name=task^element=priority
実際の対応表は dl_u_priority というテーブルに9行で入っていました。
読み取れる設計方針は次のとおりです。
1 - Critical になるのは High × High の1通りだけ。最優先は厳しく絞られる
4 - Low は3通り。低い影響度と緊急度の組み合わせが広く受け止められる
影響度と緊急度は対称に扱われる。High × Medium と Medium × High はどちらも 2 - High
優先度の 5 - Planning の扱い
優先度の選択肢は5つあります。ところがマトリクスから出てくるのは 1 から 4 までの4つだけでした。
5 - Planning は、影響度と緊急度のどの組み合わせからも導かれません。手動で選ぶときだけ使える値です。
この値は task テーブル由来で、Change Request のように計画的な作業で使われます。インシデントで 5 - Planning が入っている件があれば、マトリクスを経由せず誰かが手で設定したことになります。
自社でマトリクスを調整するとき、5 - Planning を使うかどうかを先に決めます。使わないなら選択肢から外しておくと、誤選択を防げます。
影響度と緊急度の判定基準は自分で決める
影響度と緊急度は3段階しかありません。何をもって High とするかは、製品側では決まっていません。
公式説明が示すのは考え方だけです。
Measure of the business criticality of the affected service
（訳: 影響を受けたサービスの、業務上の重要度を測るもの）
影響度は「止まったサービスがどれだけ重要か」を測ります。人数ではありません。1人しか使わないサービスでも、それが月次決算の要なら影響度は High です。
緊急度は「どれだけ早く対応が必要か」を測ります。同じサービスの停止でも、業務時間内と深夜では緊急度が変わります。
運用ルールに書くべきは、この2つの判定基準です。
影響度 High の例：全社が使う基幹システムの停止、法令対応に関わるサービスの停止
影響度 Medium の例：一部門の業務システムの停止、代替手段がある機能の不具合
影響度 Low の例：個人の環境の不具合、業務に直接の支障がない事象
緊急度 High の例：業務時間内で回避策がない、締め日など時間の制約がある
緊急度 Medium の例：業務時間内だが回避策がある
緊急度 Low の例：業務時間外、または急がない依頼
基準を文章で残さないと、担当者ごとに判定がぶれます。マトリクスの精度は、この基準の明確さで決まります。
severity と priority の違い
優先度（priority）とは別に、重大度（severity）という項目があります。どちらも3段階または5段階の数値です。
項目選択肢既定値決まり方priority5段階（1 Critical 〜 5 Planning）4影響度×緊急度から自動severity3段階（1 High / 2 Medium / 3 Low）3手動
severity は incident 固有の項目で、マトリクスの対象外です。既定値は 3（Low）のまま変わりません。
OOTB では severity を使う仕組みが特に用意されていません。運用で使うなら、何を表す値かを自社で定義します。使わないならフォームから外しておくと、入力の迷いが減ります。
カテゴリとサブカテゴリは親子関係になっている
カテゴリは6種類でした。
サブカテゴリは19種類あり、それぞれが親カテゴリに紐づいています。
紐づけは dependent_value という列で行われます。カテゴリを選ぶと、その値を持つサブカテゴリだけが表示される仕組みです。
分布に偏りがあります。Hardware が6つと最多で、Software は2つだけ。実運用ではソフトウェア関連の問い合わせが多いため、この配分のまま使うと分類が粗くなります。
Password Reset にはサブカテゴリが1つもありません。しかも sequence が 100 と、他の5つ（1〜5）から大きく離れています。後から追加されたカテゴリだと分かります。パスワードリセット機能が別途プラグインとして提供されているためです。
状態（State）と保留理由
状態（state）は6つで、value は 1・2・3 のあと 4 と 5 を飛ばして 6・7・8 になります。空いた番号は独自の状態を差し込むための余地です。
保留理由（hold_reason）は4つでした。
valueラベル何を待っているか1Awaiting Caller利用者からの返答3Awaiting Problem問題管理の結論4Awaiting Vendorベンダーの回答5Awaiting Change変更の実施
こちらも value が 2 を飛ばしています。待ち先を4種類に分けることで、滞留の原因が社内か社外かを集計できます。
4種類の内訳を見ると、社外要因が2つ（Awaiting Caller、Awaiting Vendor）、社内要因が2つ（Awaiting Problem、Awaiting Change）です。均等に分けられています。
On Hold の件数だけを見ても改善点は見えません。理由別に分けて初めて、「ベンダー待ちが長い」「利用者からの返答が来ない」といった具体的な課題が浮かびます。保留理由を必須にする設定を入れておくと、この集計が確実になります。
解決コード（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つは、他プロセスへ引き継いだ結果として閉じたことを示します。この比率を見れば、インシデント管理だけで完結していない領域が分かります。
No resolution provided と Known error の扱いには注意が要ります。前者は解決策を出せないまま閉じた記録、後者は既知の不具合として受け止めた記録です。どちらも「直っていない」状態でクローズされるため、件数が増えているなら問題管理側の滞留を疑います。
10種類すべてを使う必要はありません。運用で判断が分かれる値は外し、使うものだけを残すほうが集計が安定します。
参考：ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Known Error の扱い
受付経路（Contact type）
contact_type は問い合わせがどこから来たかを記録します。7種類のうち、1つが無効でした。
valueラベル状態chatChat有効emailEmail有効phonePhone有効self-serviceSelf-service有効virtual_agentVirtual Agent有効walk-inWalk-in有効monitoringMonitoring無効
Monitoring（監視からの自動起票）だけが inactive です。監視ツールとの連携を組んでいない環境では選ばせない、という既定になっています。
監視連携を導入するときは、この選択肢を有効へ戻す作業が要ります。自動起票の経路を作っても、受付経路として記録できなければ、後から「監視由来の件数」を集計できません。
あわせて Virtual Agent と Chat の扱いも決めます。チャットボットからの起票をどちらで記録するかを揃えておかないと、経路別の集計が二重になります。
通知手段（Notify）
notify は、この利用者にどう連絡するかを記録します。3種類でした。
valueラベル既定1Do Not Notify●2Send Email3Telephone
既定値は 1（Do Not Notify）です。名前から「通知を止める設定」に見えますが、実測では違いました。
OOTB の通知定義は、この項目を条件にしていません。起票・コメント追記・解決・クローズの通知は、notify の値に関わらず生成されます。検証用に REST で作成したインシデントでも、担当者宛の通知が4件生成されていました。
notify は「利用者がどの連絡手段を希望しているか」を記録する項目として扱います。この値で通知を出し分けたい場合は、通知定義の条件に自分で追加します。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときはここから追う
SLA定義の3種別
期限の定義は13件が有効でした。
種別が3つに分かれている点が重要です。
SLA：利用者に約束する期限。優先度ごとに応答と解決の2種類が用意される
OLA：社内グループ間の期限。Database group と Network group の2件
Underpinning contract：外部ベンダーとの契約。SAN 001 の1件
優先度1から4まで、応答と解決の期限が対になっています。Priority 1 は応答15分・解決1時間、Priority 4 は応答8時間・解決2日。優先度の設計とSLAの設計が連動しています。
優先度マトリクスを変えるとSLAの負荷も変わります。影響度の判定基準を緩めて Critical が増えれば、15分以内の応答を求められる件数が増えます。2つは必ずセットで検討します。
13件のうち2件は ATF（自動テスト）用の定義でした。実運用の想定は11件になります。
参考：task_sla：1タスク1本のSLA時計の読み方 … 計測側のテーブル
参考：SLAが土日を飛ばす理由：営業時間（cmn_schedule） … 期限は営業時間で止まる
割り当てルールは定義があるものの全件無効
担当を自動で決めるルールが3つ用意されていました。
ルール名状態Networking無効Database or Software無効Service Desk無効
3つとも active=false です。名前から、カテゴリに応じて担当グループを振り分ける想定だと分かります。Networking カテゴリなら Network グループへ、といった具合です。
デフォルトで無効なのは、グループ構成が環境ごとに違うためです。有効にする前に、自社のグループとカテゴリの対応を決めます。
参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 有効化する前に読んでおく
無操作監視も全件無効
放置されたインシデントを検知する仕組みも6つ用意されており、こちらも全件が無効でした。
割り当てルールと無操作監視が両方止まっているため、デフォルトの状態では「誰にも割り当てられず、誰にも気づかれないインシデント」が発生し得ます。
導入時に有効化を計画へ入れます。順序としては、まずグループとカテゴリの対応を決めて割り当てルールを有効にし、それでも滞留する件を拾うために無操作監視を有効にします。
状態を増やすときに使う番号
状態の value は 1・2・3 のあと 6・7・8 と続きます。4 と 5 が空いています。
保留理由も同じで、1・3・4・5 と並び、2 が空いています。この空きは偶然ではありません。独自の値を差し込むための余地として残されています。
自社で「調査中」「エスカレーション中」といった状態を足す場合、4 か 5 を使います。9 以降に足すと、画面での並び順を sequence で個別に調整する手間が増えます。
ただし状態を増やす判断は慎重に行います。影響が及ぶ先は、ACLの条件式・ビジネスルール・SLAの計測条件・レポートのすべて。26件のACLが incident_state NOT IN 7,8 という条件を持っているため、新しい状態を「終了扱い」にするならこの条件も直します。
参考：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … 選択肢の定義元となる辞書です
設定変更を本番へ移す方法
ここまでの設定は、すべて更新セット（Update Set）に記録されます。
変更するもの更新セットに入るか選択肢（sys_choice）入る優先度マトリクス（dl_u_priority）入るSLA定義（contract_sla）入る割り当てルール（sysrule_assignment）入るシステムプロパティ（sys_properties）入る
検証環境で調整した設定は、更新セットにまとめて本番へ運べます。逆に言えば、本番で直接触った設定は次の移送で上書きされる危険があります。
設定を変えるときの手順を決めておきます。検証環境で変更し、更新セットに入っていることを確認してから本番へ移す。この順序を守らないと、環境間で設定が食い違います。
参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 移送の仕組み
実機で気づいたこと
優先度の選択肢が1つ余っている
優先度の選択肢は5つありますが、優先度マトリクス（dl_u_priority）から導かれるのは 1 から 4 までの4つだけでした。5 - Planning は、影響度と緊急度のどの組み合わせからも出てきません。
この値は task テーブル由来で、Change Request のように計画的な作業で使われます。インシデントでも選択肢としては残っている状態です。
マトリクスを使う運用なら、5 - Planning を選択肢から外します。残す場合は、どういうときに手動で選ぶかを運用ルールに書きます。選べるのに使い道が決まっていない値は、担当者の判断を迷わせます。
監視からの起票を経路として記録できない
contact_type の7種類のうち、monitoring だけが inactive=true でした。他の6種類（Chat / Email / Phone / Self-service / Virtual Agent / Walk-in）はすべて有効です。
監視ツールとの連携を組んでいない環境では選ばせない、という既定だと読み取れます。使わない選択肢を隠しておく配慮です。
監視連携を導入するときは、この選択肢を有効へ戻します。自動起票のスクリプト側で contact_type=monitoring を設定しても、選択肢が無効だと画面の表示が空欄になるためです。経路別の集計を取るなら、連携の実装より先にこの設定を直してください。
後から追加されたカテゴリにサブカテゴリがない
カテゴリ6種類のうち、Password Reset だけ sequence が 100 でした。他の5種類は 1 から 5 です。サブカテゴリも1つも紐づいていません。
パスワードリセット機能が別途プラグインとして提供されているため、後から追加されたカテゴリだと分かります。
パスワードリセットを分類として使うなら、サブカテゴリを自分で足します。使わないなら選択肢から外すほうが親切です。空のまま残すと、担当者がサブカテゴリの入力欄で迷います。
サブカテゴリの分布が実態と合わない
19件のサブカテゴリのうち、Hardware に6件、Network に5件が紐づく一方、Software は2件（Email / Operating System）だけでした。
デモ環境の構成をそのまま反映したものと考えられます。標準の分類体系が、どの組織にも合うわけではありません。
実運用ではソフトウェア関連の問い合わせが多くなります。この配分のまま使うと、Software カテゴリの案件が2つのサブカテゴリに集中し、傾向の分析ができません。導入時に自社の問い合わせ実績を見て、分類を組み直します。
実務で順番に検討する箇所
基本設定を決めるとき、次の順序で進めると手戻りが減ります。
カテゴリ体系：自社の分類に合わせる。サブカテゴリの偏り（Hardware 6・Software 2）を見直す
影響度と緊急度の判定基準：何をもって High とするかを文章で定義する
優先度マトリクス：9通りの対応を自社の基準に合わせる。5 - Planning を使うか決める
SLA：優先度ごとの応答・解決期限を決める。OLA と Underpinning contract の整合も取る
割り当てルール：カテゴリとグループの対応を決めて有効化する
無操作監視：滞留を検知する条件を決めて有効化する
受付経路：Monitoring を使うかどうかを決める
解決コード：10種類のうち使わないものを外す
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
dependent_value：選択肢を親の値に紐づける列。カテゴリとサブカテゴリの関係に使われる
OLA：Operational Level Agreement。社内グループ間で交わす期限の取り決め
Underpinning contract：外部ベンダーとの契約にもとづく期限
検証範囲とおことわり
検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認
件数と既定値はすべて OOTB の状態です。本番環境やカスタマイズ済み環境では異なります
優先度マトリクスを実際に書き換えて挙動が変わることは確認していません
SLA が実際に計測を開始・停止する条件式までは追っていません
割り当てルールを有効化したときの動作は確認していません
各設定を読んでいるスクリプトの実装は、本シリーズ第6巻「インシデント管理モジュールの自動設定構成」で扱います
付録：自分の環境で確認するときのURL
状態の選択肢：/sys_choice_list.do?sysparm_query=name=incident^element=state^language=en
カテゴリ：/sys_choice_list.do?sysparm_query=name=incident^element=category^language=en
サブカテゴリ：/sys_choice_list.do?sysparm_query=name=incident^element=subcategory^language=en
影響度・緊急度・優先度：/sys_choice_list.do?sysparm_query=name=task^elementINimpact,urgency,priority^language=en
優先度マトリクス：/dl_u_priority_list.do
解決コード：/sys_choice_list.do?sysparm_query=name=incident^element=close_code^language=en
SLA定義：/contract_sla_list.do?sysparm_query=collection=incident
割り当てルール：/sysrule_assignment_list.do?sysparm_query=table=incident
無操作監視：/sysrule_escalate_list.do?sysparm_query=table=incident
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINincident,task^hintISNOTEMPTY
関連記事
選択肢Choice（sys_choice）：ドロップダウンの中身 … 選択肢そのものの仕組みです
自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 担当を自動で決める方法です
task_sla：1タスク1本のSLA時計の読み方 … 期限の計測側
