インシデント管理モジュールの連携機能
インシデントのフォームを開いても、Problem を指定する項目が見当たりません。Change を紐づける欄もありません。ではインシデントと他プロセスは、どこでつながっているのでしょうか。Australia の PDI をデフォルト設定のまま開き、問題管理・変更管理・申請・ナレッジ・構成管理との接続経路を確かめました。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
確認する連携先
インシデントが他プロセスとつながる経路
参照フィールドを持たずに関連づける仕組み
UIアクションから他プロセスを起票する流れ
連携時に引き継がれる項目
連携の全体像
インシデントを参照する実テーブルは2つだけで、多くの連携は別の方法で実現している
task_rel_task という汎用テーブルが、9種類の型で任意のタスク同士をつなぐ
問題・変更・申請への接続は、参照フィールドではなくUIアクションによる起票が中心
インシデントから他プロセスへつながる経路
インシデントから他プロセスへの経路を整理します。
経路は3種類に分かれます。
参照フィールド：列に相手の sys_id を持つ。parent_incident と incident_task.incident
UIアクション：ボタンを押して相手のレコードを新規作成する
関連テーブル：task_rel_task に行を作り、型を付けてつなぐ
incident を参照している実テーブル
sys_dictionary で incident を参照しているフィールドを検索すると73件が該当します。
ただし内訳を見ると、71件は Flow Designer の内部変数テーブルでした。var__m_sys_hub_flow_input_* のような自動生成テーブルです。フローの入力欄が Incident 型であるために作られます。
実テーブルは2件だけでした。
incident.parent_incident：インシデント自身への参照（親子関係）
incident_task.incident：インシデントタスクからの参照
incident_task は、sys_id を除けば incident への参照1つだけを持つテーブルでした。作業を切り出すためだけの単純な構造です。
ただし incident_task は task を継承しています。固有の項目が1つでも、担当者・状態・優先度・作業メモといった71項目を親から受け継ぎます。1件の作業タスクとして必要なものは揃っている形です。
この設計により、作業タスクにも独自のACL・SLA・通知を設定できます。実際、incident_task 向けのACLがテーブル単位44件のうち約半数を占めていました。
つまり作業タスクにも独立した権限設計が必要ということです。本体のインシデントは itil があれば触れますが、作業タスクは assigned_to DYNAMIC の条件で担当者に絞られます。
複数チームで分担する運用を採るなら、この違いを踏まえて設計します。作業タスクを使えば担当範囲が自然に分かれる一方、担当者以外は内容を見られません。全員が経緯を追う必要があるなら、作業タスクではなく本体の作業メモに記録する方式を選びます。
問題管理との連携は problem.first_reported_by_task で持つ
インシデントのフォームには Problem を指定する項目がありません。Australia のデフォルト環境では、incident に problem_id が定義されていないためです。
つながりは問題側にありました。
問題側のフィールド参照先意味problem.first_reported_by_taskTaskこの問題が最初に報告されたタスク（インシデント）problem.rfcChange Requestこの問題を直すための変更problem.duplicate_ofProblem重複した問題problem.primary_known_error_articleKnown Error article既知の誤りの記事
first_reported_by_task が Task 型である点が重要です。参照先が Incident ではなく Task なので、Change や Catalog Task からも問題を起票できます。親テーブルを参照することで、どのプロセスからでも受けられる設計になっています。
この非対称な作りには理由があります。1つの問題は複数のインシデントから報告されますが、「最初に報告された1件」は必ず1つです。多対1の関係なので、問題側に列を1つ持てば足ります。
インシデント側に problem_id を持たせる作りだと、1件のインシデントが1つの問題にしか紐づけられません。実際には1つのインシデントが複数の問題に関係する場合もあります。列を持たないことで、この制約を避けている形です。
複数の問題に関係する例を挙げます。「メールが送れない」というインシデントの背後に、認証基盤の不具合とメールサーバの容量不足の2つがあった場合。どちらも原因であり、両方の問題に紐づけたい場面です。task_rel_task を使えば、2つの関係を型付きで記録できます。
この柔軟さは、調査のときに手間にもなります。関連を1か所で見られないためです。参照フィールドなら列を見れば済みますが、関連テーブルは検索が必要になります。
インシデントから変更管理を起票するときはUIアクションを使用する
変更管理側の参照フィールドを見ても、incident への参照はありませんでした。
change_request が持つのは requested_by（User）、chg_model（Change Model）、cab_delegate（User）といった、変更管理の内部で使う参照です。
インシデントから変更へは、UIアクションで渡します。
Create Change Request と Create Emergency Change の2つが用意されています。緊急変更を別のボタンにしているのは、承認経路が違うためです。障害対応中に通常の変更申請を出すと、CAB の承認を待つことになります。
この2つの使い分けが運用の分かれ目です。緊急変更は承認を省略または簡略化する代わりに、事後の報告が求められます。どの状況で緊急変更を使ってよいかの基準を、運用ルールに明記しておきます。
基準がないと、担当者が判断に迷って通常変更を選び、復旧が遅れる結果になります。逆に緊急変更を安易に使うと、変更管理の統制が効かなくなります。
参照フィールドを持たずにつなぐ task_rel_task の構造
参照フィールドを持たないまま関連づける仕組みが task_rel_task です。
構造は単純でした。
フィールド型役割parentReference → Task関係の親側childReference → Task関係の子側typeReference → Task Relationship Typeどんな関係か
親も子も Task 型です。Incident・Problem・Change・Catalog Task のどれとどれでもつなげます。列を追加せずに、あらゆる組み合わせを表現できる作りです。
task_rel_task で指定できる関係の型
task_rel_type に9種類の型が登録されていました。
型は「親から見た呼び方 :: 子から見た呼び方」の対で定義されています。Caused by :: Causes なら、親は「〜に起因する」、子は「〜を引き起こす」という関係です。
ITIL のプロセス間連携に対応する型が揃っています。
Caused by :: Causes：障害の連鎖を記録する
Solved by :: Solves：問題の対策がインシデントを解決した
Permanent correction for :: Permanently corrected by：変更が問題を恒久的に直した
Investigated by :: Investigates：問題がインシデントを調査対象にする
デモデータの138件はすべて Predecessor of :: Successor of（先行と後続）でした。他の8種類は定義があるだけで、実データがありません。型を使い分ける運用は、自社で設計することになります。
型が対で定義されている理由は、関係を両方向から読めるようにするためです。インシデントAの画面では「Bに起因する（Caused by）」と表示され、Bの画面では「Aを引き起こす（Causes）」と表示されます。1行のレコードが、見る側によって違う言葉で説明されます。
この仕組みがあるおかげで、逆向きの関連を別レコードとして作る必要がありません。task_rel_task に1行入れれば、両方の画面に適切な表現で現れます。
型の選び方には注意が要ります。Related to :: Related to は親子が同じ言葉で、方向を持ちません。迷ったときに選ばれやすい一方、後から集計しても意味が読み取れません。可能な限り、方向のある型を選びます。
申請の起票とインタラクションからの昇格
インシデントは他機能から作られる場合もあります。
Create Request の UIアクションで、インシデント対応の中から申請を起票できます。「この不具合を直すには機器の交換が必要」といった場面で使う導線です。交換の申請はサービスカタログの承認と履行に乗り、インシデント側は完了を待つ形になります。
インタラクション（電話やチャットの問い合わせ）からは、プロパティで制御されています。
プロパティ既定値意味com.snc.incident.create_from_interaction.savetrue保存済みの状態でインシデントを作る
下書きではなく保存済みで作られるため、起票の時点で番号が振られ、SLA の計測も始まります。問い合わせを受けた時刻から期限を数える運用に合った既定値です。
ビジネスルール側にも Close interaction from incident があり、インシデントを閉じたときに元のインタラクションも閉じます。双方向で連動する設計です。
参考：ServiceNowの問い合わせはいつチケットにする？ InteractionからIncidentへ上げる流れを実機で追う … 問い合わせからの昇格
Knowledge との連携について
ナレッジへの接続には、クローズ時の自動作成と、不足の報告という別々の入口があります。
1つ目は task.knowledge というチェックボックスです。公式説明を引用します。
If checked, will automatically create a Draft knowledge article upon closure
（訳: チェックすると、クローズ時にナレッジ記事の下書きを自動で作成する）
引用元: /sys_documentation_list.do?sysparm_query=name=task^element=knowledge
既定値は false でした。担当者が明示的にチェックしたときだけ、下書きが作られます。
2つ目は Report Knowledge Gap の UIアクションです。「この件を解決するナレッジが足りない」と報告する導線になります。
ビジネスルール Incident Create Knowledge と Check if Known error article required も、この流れを支える処理です。前者はクローズ時に下書きを作り、後者は既知の誤りとして記事が必要かを判定します。
参考：ServiceNow ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … ナレッジ側の仕組み
CMDB との紐づけに使う項目と関連リスト
インシデントは対象のCIを記録します。task.cmdb_ci が Configuration Item への参照です。
これに加えて、関連リストで複数のCIやサービスを持てます。
関連リストテーブル何を記録するか影響CItask_ci影響を受けた構成アイテム影響サービスtask_cmdb_ci_service影響を受けたサービスサービスオファリングtask_service_offering影響を受けたオファリング業務アプリケーションtask_cmdb_ci_business_app影響を受けた業務アプリ
自動で埋める設定もありますが、既定では無効でした。populate_service_offering と populate_business_application がどちらも false です。CMDB の完成度に依存するため、整備してから有効にします。
参考：ServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認 … CMDB 側の構造
問題管理へ引き継がれる項目とプロパティ
他プロセスへ渡すとき、何が引き継がれるかはプロパティで決まります。
問題を起票するときは description / short_description / cmdb_ci / impact などが引き継がれます。添付も copy_attachments = true で渡ります。
逆向きの連携もあります。communicate_prb_workaround_to_inc_worknotes が true のため、問題側で回避策が決まると、関連するインシデントの作業メモへ自動で流れます。担当者が問題側を見に行かなくても、手元に回避策が届きます。
インシデントから問題・変更へ進む判断の順序
ここまでの経路を、実際の対応の流れに置き換えます。
インシデントはまず暫定対応で業務を戻します。そのうえで判断が2つ入ります。
同じ障害が繰り返すか：はいなら Problem へ引き継ぐ
構成の変更が必要か：はいなら Change を起票する
どちらでもなければ、解決手順をナレッジに残してクローズします。
この分担を外すと運用が崩れます。Incident の中で根本原因を追い続けている間、業務は止まったまま。逆に Problem を作らず Incident だけを閉じ続ければ、同じ障害が何度も起票されます。
参照フィールドと task_rel_task をどう使い分けるか
同じ「つなぐ」でも、2つの方法には性質の違いがあります。
参照フィールド関連テーブル（task_rel_task）保存場所レコード自身の列別テーブルの行1件が持てる数1つだけ何件でも型の指定なし9種類から選ぶ検索のしやすさ条件式で直接使える結合が必要列の追加必要不要
parent_incident のように「必ず1つ」と決まっている関係は、参照フィールドが向きます。条件式で parent_incident=xxx と書けるため、レポートも作りやすくなります。
一方「何件でもつながる」「関係の種類が複数ある」場合は関連テーブルです。1件のインシデントが3つの問題に関係することもあります。列では表現できません。
Australia のデフォルトが問題管理との連携に参照フィールドを使っていないのは、この柔軟さを取ったためだと読み取れます。problem.first_reported_by_task は「最初に報告されたタスク」を1つだけ持ちますが、それ以外の関係は task_rel_task で持てます。
片方の操作が相手のレコードに及ぶ動作
連携には、片方の操作が相手に及ぶものがあります。
操作連動して起きること実装インシデントをクローズ作業タスクも閉じるプロパティ incident_task.closureインシデントをクローズ元のインタラクションも閉じるビジネスルール Close interaction from incidentインシデントをクローズナレッジの下書きを作るビジネスルール Incident Create Knowledge親にコメントを追記未解決の子すべてに転記プロパティ copy_comments_to_non_resolved_childInc問題で回避策を決定関連インシデントの作業メモへ転記プロパティ communicate_prb_workaround_to_inc_worknotesインシデントを保存関連する問題の件数を数え直すビジネスルール Update Problem Incident Count
実装場所がプロパティとビジネスルールに分かれています。「なぜか連動する」動きを追うときは、両方を確認します。プロパティだけを見ても、ビジネスルールだけを見ても、全体は分かりません。
親のコメントが子へ転記される仕組みは、大規模障害で効きます。親1件に状況を書けば、未解決の子の全件に同じ内容が届きます。解決済みの子には転記されないため、終わった件に古い情報が流れる心配はありません。
影響を受けたCIとサービスを記録する関連リスト
インシデントは対象を4つの関連リストで記録できます。
関連リストテーブル記録するもの影響CItask_ci影響を受けた構成アイテム影響サービスtask_cmdb_ci_service影響を受けたサービスサービスオファリングtask_service_offering影響を受けたオファリング業務アプリケーションtask_cmdb_ci_business_app影響を受けた業務アプリ
task.cmdb_ci の参照フィールドが1つのCIを指すのに対し、これらは複数を記録します。1つの障害が複数のサービスに影響する場合、関連リストで表します。
複製（Copy Incident）のときも、この4つが引き継ぎ対象でした。プロパティで「どの項目を複製するか」が個別に指定されています。
自動で埋める設定は既定で無効です。CMDB の関係が正しく登録されていない環境で有効にすると、誤った関連付けが大量に作られます。整備の状況を確認してから有効化します。
参考：サービスもCIになる（cmdb_ci_service） … 影響サービスの実体
連携の設計で決めること
ここまでの内容を、設計時の判断としてまとめました。
最初に決めるのは問題管理への引き継ぎ基準です。ここが曖昧だと、Problem が作られないまま同じインシデントが繰り返されます。件数か影響度か、あるいは両方かを数値で決めます。
関係の型は、使う数を絞ることを推奨します。9種類すべてを担当者に選ばせると、判断が分かれます。Caused by と Solved by の2つから始め、必要に応じて増やす進め方が現実的です。
参考：Comments/Work notes（sys_journal_field）は1追記1行 … 転記されたコメントが保存される場所です
つながっている相手を調べる確認場所
「このインシデントは何とつながっているのか」を調べるとき、確認する場所が分散しています。
レコード自身の列：parent_incident、cmdb_ci、business_service
関連リスト：incident_task、影響CI、影響サービス
関連テーブル：task_rel_task で parent または child に自分が入っている行
相手側の列：problem.first_reported_by_task に自分が入っている問題
UIアクションで作られたレコード：作成時に関連が記録されていない場合もある
5番目が落とし穴です。Create Change Request で変更を起票しても、インシデント側に「この変更を作った」という記録が残るとは限りません。相手のレコードに元のインシデントが記録されているかを確認します。
調査の順序としては、まず自分の列を見て、次に関連リスト、最後に task_rel_task を検索する流れになります。この順で見れば、直接の関係から間接の関係へと範囲が広がります。
task_rel_task で parent=<自分のsys_id> ^OR child=<自分のsys_id>この検索で、型付きでつながっている相手が一覧できます。
影響サービスの自動更新を有効にする条件
インシデント1件が止めているサービスを把握すると、優先度の判断が変わります。
task.cmdb_ci は1つのCIしか指せません。サーバ1台の障害でも、その上で動くサービスは複数あります。影響サービスの関連リスト（task_cmdb_ci_service）が、この広がりを記録します。
自動で埋める設定は2つありました。
プロパティ既定値何をするかcom.snc.incident.refresh_impacted.include_affected_cisfalse影響CIから影響サービスを割り出すcom.snc.incident.refresh_impacted.eventtrue更新をイベント経由で背景実行する
1つ目が false のため、影響CIを入れても影響サービスは自動で埋まりません。CMDB でCIとサービスの関係が正しく登録されていることが前提の機能だからです。
CMDB の整備が進んでいる環境では、この設定を有効にする価値があります。担当者が手作業でサービスを探す必要がなくなり、影響度の判定も正確になります。
2つ目が true なので、処理は背景で実行されます。画面はすぐ返りますが、関連リストが埋まるまでに時間差が出る点を運用担当に伝えておきます。
実機で気づいたこと
インシデント側に問題や変更を指す項目がない
Australia のデフォルト環境では、incident に problem_id と rfc が定義されていませんでした。REST でレコードを取得しても返りません。
項目を持たない理由は、関係の数にあると考えられます。1件のインシデントが複数の問題に関係する場合、列1つでは表現できません。問題側の first_reported_by_task が「最初に報告されたタスク」を1つだけ持ち、それ以外の関係は task_rel_task で持つ構成になっています。
他バージョン向けの手順書や設計書を参考にするときは、項目の有無を先に確認します。/sys_dictionary_list.do?sysparm_query=name=incident^elementISNOTEMPTY を開けば22項目が並ぶため、目視でも判断できる分量です。存在しない項目を前提にした設計を進めると、実装の段階で作り直しになります。
参照の件数を数えると実態の30倍以上になる
sys_dictionary で incident を参照するフィールドを検索すると73件が該当します。ところが71件は Flow Designer の内部変数テーブル（var__m_sys_hub_flow_input_* など）でした。フローの入力欄が Incident 型であるために自動生成されるものです。
実テーブルは2件だけです。影響範囲の調査でこの数字をそのまま使うと、30倍以上に見積もることになります。
参照関係を数えるときは var__m_ で始まるテーブルを除外します。この命名規則を知らないと、調査に不要な時間をかけることになる点に注意してください。CMDBやカタログなど、他のテーブルを調べるときも同じ確認が要ります。
関係の型が9種類あるのに1種類しか使われていない
task_rel_task には9種類の関係の型が定義されています。ところがデモデータの138件は、すべて Predecessor of :: Successor of（先行と後続）でした。
Caused by や Solved by といった ITIL のプロセス連携に対応する型は、定義があるだけで実データがありません。製品としては用意しているものの、使い方は利用者に委ねる方針だと読み取れます。
自社で導入するなら、使う型を絞ることを推奨します。9種類すべてを担当者に選ばせると、判断が分かれて集計できなくなります。Caused by と Solved by の2種類から始め、必要に応じて増やす進め方が現実的です。
連携を設計するときの検討順序
連携を設計するとき、次の順序で決めます。
問題管理への引き継ぎ基準：何件同じ障害が起きたら Problem を作るか
引き継ぎ項目：create_from_incident.attributes を自社の運用に合わせる
変更管理への経路：通常変更と緊急変更のどちらを使うかの判断基準
関係の型：9種類のうちどれを使うかを決める
作業タスクの使い方：incident_task で分担するか、担当者を追加するか
親子インシデント：大規模障害をどう束ねるか
ナレッジ化の基準：task.knowledge をいつチェックするか
CMDB との紐づけ：影響CI・影響サービスを自動で埋めるか
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
task_rel_task：任意のタスク同士を型付きで関連づける中間テーブル
RFC：Request for Change。変更要求のこと
CAB：Change Advisory Board。変更を審査する会議体
検証範囲とおことわり
検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認
件数はすべて OOTB の定義の数です。本番環境やカスタマイズ済み環境では異なります
実際にUIアクションを押して他プロセスのレコードを作る操作は行っていません
task_rel_task に関係を登録して挙動を確かめる検証は行っていません
problem_id / rfc の有無はバージョンとプラグイン構成で変わる可能性があります
関係の型9種類が画面上でどう選択されるかは確認していません
付録：自分の環境で確認するときのURL
incident を参照するフィールド：/sys_dictionary_list.do?sysparm_query=reference.name=incident^elementISNOTEMPTY
親子の項目：/sys_dictionary_list.do?sysparm_query=name=incident^elementINparent_incident,child_incidents
作業タスクの構造：/sys_dictionary_list.do?sysparm_query=name=incident_task^elementISNOTEMPTY
問題側の参照：/sys_dictionary_list.do?sysparm_query=name=problem^internal_type=reference^elementISNOTEMPTY
変更側の参照：/sys_dictionary_list.do?sysparm_query=name=change_request^internal_type=reference^elementISNOTEMPTY
関連テーブルの構造：/sys_dictionary_list.do?sysparm_query=name=task_rel_task^elementISNOTEMPTY
関係の型：/task_rel_type_list.do
実際の関連レコード：/task_rel_task_list.do
Create 系のUIアクション：/sys_ui_action_list.do?sysparm_query=table=incident^nameLIKECreate^active=true
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=task^element=knowledge
関連記事
ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … 引き継ぎ先のプロセス
ServiceNow 変更管理（Change）完全ガイド：Standard・Normal・Emergencyをどう使い分けるか … 変更の種類と承認経路
定義リレーション（sys_relationship）：参照列なしの関連リスト … 参照列を持たずにつなぐもう1つの仕組み
