インシデント管理モジュールのトラブル事例と解決
「担当者が自動で割り当てられない」「クローズしたインシデントを直せない」「利用者に通知が届かない」。導入直後によく出るこの3つは、どれも不具合ではありません。デフォルトの設定がそうなっているだけです。Australia の PDI をデフォルト設定のまま開き、よくある症状の原因がどこにあるかを確かめました。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
扱う症状
症状から原因へたどる順序
デフォルトで無効になっている設定
プラグインが無効なために使えない機能
この記事で扱う症状
割り当てルール3つと無操作監視6つは、デフォルトですべて無効
クローズ済みを編集できないのは、ACL 26件が状態を条件にしているため
症状は「保存できるか」「画面に出るか」「後続が動くか」の3つに分けて切り分ける
症状から原因へたどる順序
インシデントの相談は、まず3つに分けます。
この分け方で、確認する場所が絞れます。
保存できない：ACL の条件、データポリシーの必須
画面に出ない：UIポリシー、クライアントスクリプト、UIアクションの condition
後続が動かない：割り当てルール、無操作監視、通知の設定
順序を間違えると時間を失います。「担当が付かない」という相談にロールの調査から入ると、原因にたどり着きません。原因は割り当てルールが無効になっていることであり、権限とは無関係だからです。
担当者が自動で割り当てられない
症状：インシデントを起票しても、担当者（Assigned to）と担当グループが空のままです。
原因：割り当てルールが3つ用意されていますが、すべて無効でした。
ルール名状態Networking無効Database or Software無効Service Desk無効
名前から、カテゴリに応じてグループを振り分ける想定だと分かります。デフォルトで無効なのは、グループ構成が環境ごとに違うためです。
解決：自社のカテゴリとグループの対応を決めてから有効にします。3つのルールをそのまま使うか、自社用に作り直すかを先に判断します。
参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 有効化する前に読んでおく
放置されたインシデントに誰も気づかない
症状：数日間更新されていないインシデントがあっても、誰にも通知が来ません。
原因：無操作監視（Inactivity Monitor）が6つ用意されていますが、こちらも全件が無効でした。
割り当てルールと無操作監視が両方止まっているため、デフォルトの状態では「誰にも割り当てられず、誰にも気づかれないインシデント」が発生し得ます。
解決：割り当てルールを先に有効化し、それでも滞留する件を拾うために無操作監視を有効にします。順序を逆にすると、担当が付いていない件で大量の警告が出ます。
デフォルトで無効になっているものの一覧
無効な設定は他にもあります。まとめて把握しておくと、導入時の確認が楽になります。
無効の理由は種別で違います。割り当てルールと無操作監視は「環境に依存するため」。クライアントスクリプトの6件のうち3件は「学習用のサンプルだから」。残りは記録が残っていません。
クローズ済みのインシデントが編集できない
症状：Closed のインシデントを開いても、項目が編集できません。admin でも同じです。
原因：ACL 151件のうち26件が incident_state NOT IN 7,8 という条件を持っています。7 は Closed、8 は Canceled です。
ロールを足しても解決しません。条件が状態を見ているためです。
解決：Reopen の UIアクションで状態を戻してから編集します。運用として「クローズ後は編集しない」を徹底する方針もあります。記録の信頼性を保つ設計として、この制限は意図的なものです。
さらに incident_state=7（Closed のときだけ書ける）という ACL が1件あり、admin_overrides が false になっています。admin でも条件を満たさなければ通りません。
参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACL の判定順序
解決しようとすると入力を求められる
症状：状態を Resolved にして保存しようとすると、解決コードと解決メモの入力を求められます。
原因：データポリシーが1件有効になっています。
Make close info mandatory when resolved or closed という名前で、reverse_if_false が true です。Resolved または Closed のときに解決情報を必須にし、条件から外れたら必須を解除します。
解決：これは仕様どおりの動作です。解決の記録を残すために必要な制御なので、外さないことを推奨します。
データポリシーは画面だけでなく REST API やインポートにも効きます。外部システムからインシデントを一括でクローズする処理を作るときは、この必須項目も渡します。渡さないとエラーで止まります。
参考：APIやインポートにも効く必須制御（Data Policy） … 画面外からの投入はここで止まる
利用者に通知メールが届かない
症状：インシデントを起票しても、利用者に連絡メールが届きません。
原因：PDI では SMTP 送信が無効になっており、通知は生成されても送信されずに Outbox へ溜まります。実測では、検証用インシデント1件から通知が4件生成され、すべて send-ready のまま残っていました。
notify 項目（既定 Do Not Notify）を疑いたくなりますが、OOTB の通知定義はこの項目を条件にしていません。起票・コメント追記・解決・クローズの通知は、notify の値に関わらず生成されます。
無効な通知も1件ありました。こちらが原因の場合もあります。
解決：確認する順序は次のとおりです。
メールの生成ログを見る（sys_email）。生成されていれば定義は動いている
type を見る。send-ready のまま溜まっていれば送信設定（SMTP）の問題
生成されていなければ、通知定義が有効かを見る
通知定義の条件式を見る
イベントが発行されているかを見る（sysevent）
生成と送信を分けて切り分けると、通知定義とメールサーバ設定のどちらが原因かを最初の1手で判別できます。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときはここから追う
重大インシデントの画面が見つからない
症状：重大インシデント（Major Incident）を宣言する操作が見当たりません。
原因：プラグインが無効でした。
com.snc.incident.mim（Incident Management - Major Incident Management）が Inactive です。重大インシデントの宣言、専用のダッシュボード、関係者への一斉連絡といった機能が使えません。
解決：重大インシデント運用を設計するなら、プラグインの有効化を計画に入れます。有効化すると項目と画面が追加されるため、既存のフォームレイアウトへの影響も確認が要ります。
プラグインの有効化は本番環境に直接影響します。検証環境で先に入れて、追加される項目とテーブルを確認してから本番へ進めます。一度有効にすると、無効化しても項目定義は残る点にも注意してください。
major_incident_state のような項目を前提にした記事や設計書を見かけたら、まず自分の環境でプラグインの状態を確認します。項目がなければ、その手順はそのまま使えません。
他にも4つのプラグインが無効でした。作業の自動割り振り（AWA）、ナレッジ中心のサポート（KCS）、予測分析、統合リクエストとの連携です。「この機能が使えない」の答えが、プラグインの状態にある場合があります。
監視ツールからの起票を経路として記録できない
症状：受付経路（Contact type）に Monitoring が出てきません。
原因：contact_type の選択肢7つのうち、monitoring だけが inactive=true でした。
解決：監視連携を導入するときに、この選択肢を有効へ戻します。自動起票のスクリプト側で値を設定しても、選択肢が無効だと画面の表示が空欄になります。
経路別の集計を取るなら、この設定は先に直します。後から有効にしても、それ以前のレコードには値が入りません。
受付経路の設計では、Chat と Virtual Agent の使い分けも決めておきます。チャットボットからの起票をどちらで記録するか揃えないと、経路別の集計が二重になります。
7種類のうち実際に使うものだけを残す判断もあります。Walk-in（窓口に来訪）を使わない組織なら、選択肢から外しておくほうが入力が速くなります。
状態を更新したのに元に戻る
症状：独自のビジネスルールで state を更新したのに、保存後の値が元に戻っています。
原因：Copy Incident State to State というビジネスルールが order 1,000,000 で最後に実行され、incident_state の値で state を上書きするためです。
インシデントには状態を表す項目が2つあります。state（task から継承）と incident_state（incident 固有）です。この2つを揃えるルールが、order 0 と order 1,000,000 の両端に配置されています。
解決：状態を変える処理では、state と incident_state の両方を更新します。片方だけを書き換えると同期ルールに戻されます。
問題管理との紐づけ項目が見つからない
症状：インシデントのフォームに Problem を指定する項目がありません。
原因：Australia のデフォルト環境では、incident に problem_id と rfc が定義されていませんでした。REST でレコードを取得しても返りません。
解決：問題との連携は problem.first_reported_by_task（Problem 側が起票元のタスクを持つ）で追います。変更との連携は UIアクション「Create Change Request」から起票します。
他バージョン向けの記事や手順書を参考にするときは、自分の環境で項目の有無を先に確かめる手順を挟みます。項目名だけが独り歩きすると、存在しない項目を前提にした設計になります。
確認は REST でも画面でも可能です。画面なら /sys_dictionary_list.do?sysparm_query=name=incident^elementISNOTEMPTY を開いて一覧を見ます。22項目しかないため、目視でも十分に確認できます。
なお com.snc.incident.copy.attributes というプロパティの既定値には problem_id と rfc が含まれていました。存在しない項目名がプロパティに残っている状態です。値は検証されないため、指定が無視されるだけで済みます。ただし「複製で引き継がれるはず」と誤解したまま設計を進めると、後で食い違います。
ボタンが表示されない
症状：Resolve ボタンが出ない、Create Change Request が見当たらない、といった相談です。
原因：UIアクションの condition が満たされていません。
UIアクションは26件定義され、23件が有効です。無効な3件が原因の場合もあります。
解決：確認する順序は次のとおりです。
そのUIアクションが有効かを見る
condition の条件式を読む
表示場所（フォーム・一覧・関連リスト）の設定を見る
ACL で操作が許可されているかを見る
同じ名前のアクションが複数ある点にも注意が要ります。表示場所ごとに別のレコードとして定義されているため、1つを直しても別の場所のボタンは変わりません。
無効になっているクライアントスクリプトも確認します。
実機で気づいたこと
デフォルトでは3つのことが同時に起きない
起票しても担当者が付かず、通知も飛ばず、放置しても警告が出ません。割り当てルール3つ、無操作監視6つ、notify の既定値がすべて「動かない」側に設定されているためです。
環境ごとに構成が違うものを、製品側で決め打ちできないという事情があります。グループの構成も、通知を送るかどうかも、組織によって変わります。
導入時のチェックリストに、この3つを明示的に入れます。「動くはずなのに動かない」ではなく「最初から動かない設定になっている」と理解しておくと、原因調査の時間を使わずに済みます。
無効な設定が7つの種別に散らばっている
割り当てルール・無操作監視・クライアントスクリプト・UIアクション・通知・SLA・ACL のそれぞれに、無効なレコードがありました。テーブルが分かれているため、1画面では確認できません。
無効の理由も種別によって異なります。環境依存のもの、学習用のサンプル、記録が残っていないもの。「使わないから無効」なのか「不具合があって止めた」のかは、説明欄がなければ判断できません。
導入時に active=false のレコードを種別ごとに数え、一覧にします。件数を記録しておけば、後から「誰かが無効にしたのか、最初から無効だったのか」を判断できます。自社で無効にするときは、理由を説明欄に残す習慣をつけてください。
参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 有効化した設定を本番へ運ぶ
admin での確認では一般ユーザーの挙動が分からない
ACL 151件のうち45件は admin_overrides が false でした。query_range と conditional_table_query_range の31件はすべて false です。
取得範囲の制限は admin でも外れない構成になっています。一方、残る106件は admin なら条件を無視して通ります。
権限に関わる確認は Impersonate User で対象のロールに切り替えて行ってください。admin で通ったからといって、担当者でも通るとは限りません。検証計画には「各ロールでの確認」を項目として入れます。
一覧に出てこないレコードがある
症状：レコードは存在するのに、一覧やレポートに出てきません。read の ACL は通っているように見えます。
原因：ACL の操作には query_range と conditional_table_query_range があり、合わせて31件が有効です。これらは「読めるかどうか」ではなく「検索結果に含めるかどうか」を判定します。
31件はすべて admin_overrides が false でした。admin でも取得範囲の制限は外れません。
解決：一覧に出ない件は、read ではなく query 系の ACL を確認します。あわせて見るのがビジネスルールの incident query（query タイミングで動く1件）。こちらは検索条件そのものを書き換えます。
調査の順序を決めておくと速く終わります。まずレコードが存在するかを admin で確認。次に query ACL、最後に query ビジネスルールを見ます。3層のどこで消えているかが分かれば、対処は絞られます。
ドメイン分離を使っている環境では、ACL より前にドメインで絞り込まれます。3つの層（ドメイン → query ACL → query ビジネスルール）を順に確認します。
参考：Access Analyzer：「見えない」の理由を層で切り分ける … 層ごとに判定を追う道具
SLA の時計が想定と違う
症状：優先度1のインシデントなのに、SLA の残り時間が想定より長く表示されます。
原因：SLA定義は13件ありますが、うち2件は ATF（自動テスト）用です。実運用の想定は11件になります。また種別が3つに分かれており、対顧客の SLA・社内グループ間の OLA・ベンダー契約の Underpinning contract が同時に動きます。
期限の計算は営業時間（スケジュール）に依存します。24時間365日で計算するか、平日9時から18時で計算するかで、残り時間の表示が大きく変わります。
解決：確認する順序は次のとおりです。
どの SLA定義が適用されているかを task_sla で見る
その定義のスケジュール（営業時間）を確認する
開始・一時停止・停止の条件を確認する
ATF 用の定義が誤って適用されていないかを見る
優先度マトリクスを変えると SLA の負荷も変わります。影響度の判定基準を緩めて Critical が増えれば、15分以内の応答を求められる件数が増えます。2つはセットで検討します。
参考：task_sla：1タスク1本のSLA時計の読み方 … 計測側のテーブル
導入時の確認リスト
ここまでの内容を、導入時に確認する形にまとめました。
10項目のうち6項目が「デフォルトでは動かない設定」です。動かないことを前提に、必要なものだけを有効化していくのが導入の進め方になります。
すべてを有効にする必要はありません。無操作監視を使わない運用も成り立ちます。判断の記録を残しておくと、後任者が「なぜ無効なのか」を調べ直さずに済みます。
実務で順番に検討する箇所
導入直後の確認は、次の順序で進めます。
割り当てルール：カテゴリとグループの対応を決めて有効化する
無操作監視：滞留を検知する条件を決めて有効化する
notify の既定値：利用者への自動連絡を使うかどうかを決める
通知23件の取捨：宛先と条件を1つずつ確認する
プラグイン：重大インシデント管理などが必要かを判断する
受付経路：Monitoring を使うなら選択肢を有効に戻す
クローズ後の編集：Reopen の運用ルールを決める
無効なレコードの棚卸し：種別ごとに件数を記録する
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
無操作監視（Inactivity Monitor）：一定時間更新のないレコードを検知する仕組み
admin_overrides：admin ロールが ACL の条件を無視して通れるかどうかの設定
Impersonate User：管理者が別のユーザーとして画面を確認する機能
検証範囲とおことわり
検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認
件数と有効・無効の状態はすべて OOTB のものです。本番環境やカスタマイズ済み環境では異なります
各症状を実際に再現し、対処して直ることまでは確認していません。定義から原因を整理しています
割り当てルールや無操作監視を有効化したときの動作は確認していません
プラグインを有効化したときに追加される項目・画面は確認していません
スクリプト付き ACL 13件の中身までは追っていません
付録：自分の環境で確認するときのURL
割り当てルール：/sysrule_assignment_list.do?sysparm_query=table=incident
無操作監視：/sysrule_escalate_list.do?sysparm_query=table=incident
データポリシー：/sys_data_policy2_list.do?sysparm_query=model_table=incident
書き込みのACL：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHincident^operation=write^active=true
UIアクション（Resolve）：/sys_ui_action_list.do?sysparm_query=table=incident^name=Resolve
プラグインの状態：/v_plugin_list.do?sysparm_query=idLIKEincident
無効な通知：/sysevent_email_action_list.do?sysparm_query=collection=incident^active=false
無効なクライアントスクリプト：/sys_script_client_list.do?sysparm_query=table=incident^active=false
引用した公式説明を実機で確認する方法
この記事で参照したプラグインの説明は、ServiceNow が製品に同梱しているものです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=idLIKEincident
関連記事
ロールを付けたのに見えない理由：ACL（sys_security_acl） … 権限で止まる原因はここを見る
自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 担当を自動で決める方法です
メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときの経路確認です
