ServiceNowのインシデント1件は何テーブルに書かれる？ 周辺13テーブルを実機で数える
インシデント1件を消したいとき、incidentテーブルの1行を消すだけでは終わりません。ServiceNowでは1件のインシデントを保存するたびに、変更履歴・作業メモ・SLA・添付ファイルといった周辺のテーブルにも同時に行が増えます。Zurich PDIで71件のインシデントを起点に、実際に関わっているテーブルを実機で数えたら13個でした。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：1件のインシデントは13テーブルに分かれて記録される
先に全体像です。
インシデント本体（incident）は71件。フォームを1件保存するたびに、変更履歴・作業メモ・SLA・添付など周辺のテーブルにも行が増え、関わるテーブルを数えるとincident自身を含めて13個でした。
sys_auditやsys_journal_fieldのような周辺テーブルはインシデント専用ではありません。ChangeやProblem、カタログの申請とも共有していて、テーブル全体の件数をそのままインシデント分の件数と思うと、実際より二桁近く多く見積もることになります。
Stateは6種類定義されていますが、実機で埋まっていたのはNew・In Progress・On Hold・Closedの4種類だけでした。Resolvedは0件、Closedが32件です。
incidentから伸びる矢印は、taskという親テーブルへの継承と、4つのグループへの枝分かれを表しています。同じ枠の中に全体件数とincident分の件数を並べているのは、後半で説明する「共有テーブル」の性質を先に見せておきたかったからです。数字が2つ並んでいるテーブルほど、他のプロセスとの共有度が高いと読んでください。
Stateは6種類あるのに、実機で埋まっていたのは4種類だけ
incidentの一覧をStateでグループ化すると、実際に使われている値が一目で分かります。
New 11件、In Progress 21件、On Hold 7件、Closed 32件で合計71件です。選択肢としてはResolvedとCanceledも定義されていますが、この画面には行そのものが出てきません。0件のグループはグループ化一覧に表示されない仕組みなので、選択肢は存在していても実データでは見えなくなります。
もっとも目を引くのはResolvedが0件でClosedが32件という組み合わせです。ITILの教科書的な流れでは、対応が終わったインシデントはまずResolvedに遷移し、利用者の確認期間を経てClosedになります。この環境ではその中間ステップが1件も残っていません。Resolvedを経由する運用が有効化されていないのか、そもそもデモデータがClosedの状態で最初から投入されているのか、この画面だけでは判別できません。理由は一つではなさそうです。Stateの遷移条件そのものは公式のLife cycle of an Incidentに定義があり、条件の設計次第でResolvedを飛ばす運用も組めます。
フォーム1枚の裏側にある13テーブル
Stateの分布を見たあと、実際のフォームも開いてみました。
画面に並ぶのはNumber・Caller・Category・State・Priorityといった十数個の項目だけです。ここからCallerを入力してSubmitを押すと、incidentに1行できるだけでなく、担当割り当てや通知の条件次第で周辺テーブルにも行が増え始めます。数えた13テーブルの一覧が下の表です。
incidentはtaskというテーブルを継承しています。この親子関係は、公式ドキュメントのTable adminのページでテーブル拡張として説明されている構造です。Incident・Problem・Change・Requested Itemは、見た目も操作感もまるで違う業務レコードです。それでも内部では、同じ親テーブルの子として扱われています。フォームの見た目だけを追っていると、この共通性には気づきにくいところです。表の残り11テーブルは、この継承関係の外側でincidentと紐づく記録です。次の章から、件数が大きい順に見ていきます。
変更履歴はsys_auditに1行ずつ残る
incidentのどの項目が、いつ、何から何に変わったかを記録しているのがsys_auditです。
sys_auditはテーブル全体で56,723件ありました。1行が「1件のレコードの1項目が1回変わった」ことを表すので、フィールドを1つ変更するたびに1行増える計算です。公式のUnderstanding the Sys Audit tableでも、監査ログはフィールド単位の変更を記録する仕組みだと説明されています。
画面を開いて驚いたのは、上位に並ぶ行のOld valueとNew valueがそろって「DELETED」になっていたことです。これは値の変更ではありません。レコードそのものが削除された痕跡です。同じ秒台に何行も並んでいたので、個別の編集というより、デモデータを入れ替える際にまとめて削除された記録だと考えられます。実際の障害対応で発生する変更履歴とは性質が違うので、監査ログを障害調査に使うときは、こうした一括操作の痕跡を実データと混同しないよう注意が要ります。
作業メモとコメントはsys_journal_fieldに1件1行
work_notesとcomments（Customer visible）はsys_journal_fieldという別テーブルに保存されます。
sys_journal_fieldもテーブル全体で1,399件でした。中身を見ると、VPN接続エラーやメールサーバの死活確認など、実際の障害対応を思わせる具体的なやり取りが並んでいます。1回の書き込みが1行になる作りなので、やり取りが長引くインシデントほど行数が増えます。公式のJournal field typeでも、Taskテーブル系で使われる特殊なフィールド型だと説明されている仕様です。
全体件数とincident限定件数を比べると桁が変わる
sys_auditとsys_journal_fieldの件数を見て、最初は「1件のインシデントに対してずいぶん多い」と感じました。実際にtablename=incident（sys_journal_fieldはname=incident）で絞り込むと、数字はまったく違って見えます。
sys_auditは56,723件のうちincident分が618件で1.1%、sys_journal_fieldは1,399件のうち26件で1.9%でした。残りはProblemやChange、カタログタスクなど、taskを継承する他のプロセスが積み上げた行です。件数の大きさに驚くよりも先に、そのテーブルが誰と共有されているテーブルなのかを確認したほうが読み間違えません。
task_slaだけは事情が違いました。全体でも21件、incident限定でも21件で比率は100%です。この環境ではSLAの時計が動いているタスクが、たまたま全部インシデントだったことになります。偶然か、必然かは分かりません。
SLAの時計が付いているのは71件中21件
task_slaは1つのタスクに対して複数のSLA定義がひも付く仕組みです。
71件のインシデントに対してSLAの行は21件しかありません。理由は一つに絞れません。優先度に応じたSLA定義が条件不一致で紐付かなかった可能性と、そもそもSLA定義自体が適用対象外だった可能性の両方が考えられます。原因の切り分けまではこの画面だけでは分からず、SLA定義側の条件を1つずつ確認する作業が別途必要です。
一覧のBusiness elapsed percentageの列も見ておく価値があります。中には1万%を超える行があり、Priority 1 resolution（1時間）のSLAに対して実際の経過時間が22日を超えているケースもありました。SLAは達成・未達だけでなく、どれだけ超過しているかまで1行で読み取れます。公式のMonitoring Service Level Agreement (SLA)にも、経過率の見方がまとまっています。
taskテーブル3,935件のうちincidentは71件
taskはIncidentだけでなく、ITSM全体の共通の親です。sys_class_nameでグループ化すると、内訳がはっきりします。
3,935件の内訳を表にまとめました。
いちばん多いのはFollow On Task（cert_follow_on_task）の2,806件で、全体の71%を占めます。汎用のTask（678件）やIncident（71件）よりずっと多い数字です。正直なところ、意外でした。Follow On TaskはCertification（適合性の証明・棚卸し）機能が生成するフォローアップ用のタスクで、障害対応とは別の運用領域に属します。taskテーブルを覗くときは、この母数の大きさを前提に見る必要があります。
添付ファイルはsys_attachmentに、incident分は11件
添付ファイルのメタ情報はsys_attachmentというテーブルに集まります。ファイルの中身そのものは含まれません。並ぶのはファイル名・種類・サイズ・作成日時です。中身は別テーブルの管轄です。
table_name=incidentで絞ると11件でした。作成日時を見ると2015年から2026年まで幅があり、デモデータとして投入された古い添付と、比較的新しい添付が混在しています。添付ファイルの扱いは公式のAttachmentsにまとまっています。
画面には出さなかった残りのテーブル
ここまでスクリーンショットで見た7テーブルのほかに、incidentと関わるテーブルがまだ6つあります。
cmdb_ci（2,786件）はConfiguration itemの参照先で、影響範囲を特定するための構成アイテムです。件数の大きさは環境全体のCI登録数を反映しており、incidentからの参照は1件につき最大1件にとどまります。sys_email（1,144件）は通知メールの送受信記録、sysapproval_approver（771件）は承認が必要なプロセスで生成される承認者レコードです。CMDBの構成はCMDB tables descriptions、承認の基本はClassic approvalsに解説があります。
sys_user_grmember（193件）はAssignment groupに誰が所属しているかを表し、割り当て候補を決める材料になります。sys_history_line（30件）はActivity表示を組み立てる履歴行、task_time_worked（8件）は手作業で記録した作業時間、incident_task（1件）は1件のインシデントから切り出された子タスクです。件数が少ないテーブルほど、この環境での利用頻度が低い機能だと読めます。
実機で気づいたこと
Resolvedを経由せずClosedになる運用
Stateの分布を見て最初に引っかかったのは、Resolvedが1件もないという結果でした。件数だけを見ると設定ミスのようにも見えますが、closeを直接押せる権限やUI Actionの構成次第では、Resolvedを飛ばす運用も普通にありえます。デモデータの初期状態がClosedで投入されている可能性も否定できません。障害の起票から解決までを1件通しで操作した記事は別に用意しているので、今回は実測の結果だけを記録しておきます。
「全体件数」は他テーブルの分も含んでいた
sys_auditが56,723件と聞いて、最初は「インシデント1件あたり800行近い変更履歴が付く」と読みました。読み違えでした。tablename=incidentで絞ると618件しかなく、実際は1件あたり9行ほどです。大きな数字はインシデント固有の重さではなく、taskを継承する全プロセス分の合計でした。件数を見たら、まずそのテーブルが何と共有されているかを確認する習慣がついた発見です。
監査ログの先頭が「DELETED」ばかりだった
sys_auditを新しい順に開くと、上位の行がすべて「レコード削除」の痕跡でした。同じ秒に何行も並ぶ様子から、個別の編集作業ではなく一括処理の跡だと判断しています。監査ログを障害調査で使うときは、こうしたデータ整備の痕跡を実際の対応履歴と取り違えないよう、日時とUserの列をあわせて確認したほうが安全です。
Follow On Taskが7割を占めていた
taskテーブルの内訳を見るまで、大半はIncident・Problem・Changeのようなよく使うレコードで埋まっていると思い込んでいました。実際にはCertification機能のFollow On Taskが2,806件で7割を占め、Incidentは全体の2%に届きません。taskを「ITSMの共通の親」と呼ぶ記事は多いものの、実機で内訳を数えるとITSM以外の用途がここまで大きな割合を占めるとは想定していませんでした。
実務では何に使えるか：障害調査でどこから見るか
複数のテーブルにまたがる構造を知っておくと、障害調査で開く画面の順番を組み立てやすくなります。近道はありません。順番を決めておくだけで、調査にかかる時間は変わります。自分なら次の順で見ます。
まずインシデントフォームのActivityで大まかな流れをつかみます。ここはsys_auditとsys_journal_fieldという2つの別テーブルの中身を、時系列に沿って1つの表示へ合成した画面です。
SLA違反が疑われる場合はtask_slaを単独で開き、Business elapsed percentageの列で超過の度合いを確認します。
添付ファイルの数が多いインシデントではsys_attachmentを直接開き、ファイルサイズと作成日時から不審な後追い添付がないかを見ます。
承認待ちで止まっているように見えるときはsysapproval_approverを確認し、誰の承認で止まっているかを特定します。
sys_auditやsys_journal_fieldをリストで直接開くときは、tablename=incidentのような絞り込みを先にかけることが欠かせません。絞り込まずに開くと、Follow On TaskやChange Requestの行がノイズとして大量に混ざります。この一手間だけで、読む行数を数百分の一に減らせます。
さらに詳しく知りたい人へ
Incident（incident）をテーブルで読む — incident本体のフィールド構造を詳しく見る前提知識
taskテーブル：ITSM全プロセスの共通の親 — Follow On Taskを含む16種類の内訳をさらに詳しく扱う記事
Incidentの「誰が何を変えたか」はどこに残るか（sys_audit） — 監査ログの構造と読み方の詳細編
よくある質問
Q1. sys_auditの全体件数とincident限定件数の差はなぜこんなに大きいのですか
sys_auditはincident専用のテーブルではありません。taskを継承する全プロセス（Problem・Change・カタログのタスクなど）が共有しています。全体56,723件のうち、incidentに紐づくのは618件だけでした。テーブル名だけで用途を判断せず、tablenameで絞り込んだ件数を見る必要があります。
Q2. Resolvedが0件というのは異常な設定ですか
この環境の実データがたまたまそうなっていた、という以上のことは今回の確認だけでは言えません。Resolvedを経由せずClosedにする運用は、UI Actionの構成やBusiness Ruleの条件次第で普通に成立します。異常かどうかを判断するには、そのUI Actionの表示条件と、Closeボタンを押せる権限を別途確認する必要があります。
Q3. task_slaが21件しかないのはSLA定義に問題があるということですか
件数の少なさだけでは断定できません。SLA定義側の条件（対象カテゴリ・優先度・営業時間の設定など）に71件の一部が一致しなかった可能性と、そもそも一部のインシデントにSLAを適用しない運用だった可能性の両方が考えられます。切り分けにはSLA定義のConditionタブを1件ずつ確認する作業が要ります。
Q4. Follow On Taskとは何ですか、Incidentと関係ありますか
Follow On Task（cert_follow_on_task）はCertification機能が生成するフォローアップ用のタスクで、Incident対応とは別の運用領域に属します。taskテーブルを継承している点は同じですが、業務上の目的は異なります。今回の環境ではtask全体の71%をこの種別が占めていました。
Q5. incident_taskが1件しかないのはなぜですか
incident_taskは1件のインシデントを複数の担当者・チームに分割したいときに使う子タスクのテーブルです。今回のPDIでは、そもそも1件のインシデントを分割する運用があまり使われていなかったために、1件しか記録が残っていなかったと考えられます。使用頻度の差です。運用によって発生頻度が大きく変わる機能です。
まとめ
incidentは1件のレコードに見えて、実際には13テーブルにまたがって記録されています。件数の大きいテーブルほどincident専用ではありません。taskを継承する他のプロセスと共有されている点が、実機で数えて初めて分かった構造でした。sys_auditは56,723件のうちincident分は618件、sys_journal_fieldは1,399件のうち26件、sys_attachmentは2,999件のうち11件でした。taskテーブル3,935件の内訳ではFollow On Taskが71%を占め、Incidentは71件にとどまります。
障害調査でこれらのテーブルを開くときは、全体件数に惑わされず、tablename=incidentのような絞り込みを先にかける習慣が実務では効いてきます。件数の桁を見て驚く前に、そのテーブルが誰と共有されているかを確かめる。今回の実測から得られた一番の教訓です。
用語
incident … インシデント本体。taskを継承する
task … Incident/Problem/Change/カタログタスクなどが継承する共通の親テーブル
sys_audit … フィールド単位の変更履歴。1項目の1回の変更が1行
sys_journal_field … work_notes・commentsの追記を1件1行で記録するテーブル
task_sla … 1つのタスクに紐づくSLAの時計。定義ごとに1行
sys_attachment … 添付ファイルのメタ情報（本体データではなくファイル名・サイズなど）
cert_follow_on_task … Certification機能が生成するフォローアップ用タスク
実機で調べるときに開いたURL
/incident_list.do?sysparm_query=GROUPBYstate … Stateごとの件数
/sys_audit_list.do?sysparm_query=tablename=incident … incident分の変更履歴
/sys_journal_field_list.do?sysparm_query=name=incident … incident分の作業メモ・コメント
/task_sla_list.do … SLAの時計一覧
/task_list.do?sysparm_query=GROUPBYsys_class_name … taskの種別別内訳
/sys_attachment_list.do?sysparm_query=table_name=incident … incident分の添付ファイル
参考リンク
検証環境と未検証範囲
件数・画面はZurich PDI（OOTB）で確認したものです。一覧画面に表示される件数をそのまま数えており、推定やサンプリングではありません。本番環境やカスタマイズ済みの環境では数値が異なります。
Resolvedが0件になっている理由（UI Actionの条件・Business Ruleの設定・デモデータの初期状態のいずれか）までは切り分けていません。SLA定義がインシデントの残り50件に紐付かなかった条件面の原因は、今回は確認できていない部分です。監査ログの「DELETED」行がどの操作で発生したものかも、操作ログまでは追っていません。1件のインシデントを新規作成してからクローズするまでの実操作は別記事の範囲です。
