インシデント管理モジュールのテーブル・フィールド構成
インシデントのフォームに並ぶ項目は、どこで定義されているのでしょうか。Incident は task テーブルを継承しているため、項目の定義は2つのテーブルに分かれています。自社の項目を足すとき、既定値を変えるとき、必須にするときに、どちらを触るかで結果が変わります。Australia の PDI をデフォルト設定のまま開き、93項目の内訳・型・既定値・必須の決まり方を確かめました。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
確認する項目
Incident の項目が incident と task のどちらで定義されているか
93項目がどの型で構成されているか
既定値が入っている項目と、その決まり方
必須項目を実際に決めている仕組み
時間を測る項目が5つある理由
この記事の要点
フィールドは「incident 固有」「task 継承」に加え、task の定義を incident 用に変える「上書き」の3層でできている
既定値は25項目に入っており、うち5項目は JavaScript 式で決まる
sys_dictionary の mandatory は0件で、必須はUIポリシー・データポリシー・ACLが決めている
テーブルの継承構造
Incident は task テーブルを継承しています。項目の定義もこの構造に沿って2つに分かれます。
sys_db_object で両方のテーブルを並べると、継承関係が確認できます。
この構造が意味するのは、項目を足す場所が2つあるということです。Incident だけで使う項目なら incident に、Change や Problem でも使う項目なら task に足します。task に足すと ITSM の全プロセスに影響します。
参考：taskテーブル：ITSM全プロセスの共通の親 … 親テーブル側の役割
フィールドの総数と内訳
sys_dictionary を数えると、incident 固有が22項目、task から継承するものが71項目でした。
フォームを開いたときに扱える項目は、この2つを合わせた93項目です。実際のフォームには、そのうち一部だけが表示されています。
name=incident の検索に task の71項目が出てこないのは、継承が「定義の複製」ではないからです。task 側の辞書定義がそのまま使われる仕組みで、incident 側に別レコードは作られません。継承分を確認するときは name=task で開き直します。
参考：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … 辞書テーブルの読み方
型の分布
93項目を型で分けると、Reference が最多の20項目でした。
Integer が17項目ある点に注目してください。state・priority・impact・urgency・severity・notify・hold_reason といった選択肢が Integer で保存されているためです。画面には「New」「In Progress」と表示されますが、データベースには 1・2 が入ります。
この違いは条件式を書くときに効きます。ビジネスルールやレポートの条件で指定するのは、ラベルではなく数値のほう。state=2 と書けば In Progress を指します。一方で category や close_code は String 型で、category=inquiry のように文字列で保存されます。同じ選択肢でも型が分かれている点に注意してください。
数値で持つ利点は並び替えにあります。優先度を「1が最も高い」順で並べるとき、Integer ならそのままソートできる形です。文字列だと表示順を別途 sequence で管理することになります。実機の sys_choice には sequence 列があり、String 型の選択肢はこの値で並びます。
List 型の5項目は、複数のユーザーやグループを1つの欄に持たせるためのものです。
watch_list：このインシデントの更新通知を受け取るユーザー
work_notes_list：作業メモが追記されたときに通知を受け取るユーザー
additional_assignee_list：主担当以外の担当者
group_list：関係するグループ
skills：対応に必要なスキル
通知先を2種類に分けている点が実務的です。全更新を追いたい人は watch_list、社内の調査経過だけ追いたい人は work_notes_list に入れます。
時間に関する型も3種類あります。Date/Time は時刻そのもの、Duration は2点間の長さ、Timer は積み上げた作業時間です。同じ「時間」でも、測っている対象が違います。
参考：選択肢Choice（sys_choice）：ドロップダウンの中身 … ラベルと値の対応が置かれる場所
参照フィールドのつながり先
Reference 型の20項目が、どのテーブルを指しているかを整理します。
incident 固有の参照は4項目のみです。caller_id・resolved_by・reopened_by（すべて User）と parent_incident（Incident 自身）。残り16項目は task 側にあります。
User への参照は全部で6つあります。
caller_id：連絡してきた利用者（incident 固有）
assigned_to：作業する担当者
opened_by：レコードを作った人
closed_by：クローズした人
resolved_by：解決した人（incident 固有）
reopened_by：再オープンした人（incident 固有）
利用者・担当者・操作者を別々に持つ設計です。誰かの代理で起票した場合、caller_id と opened_by が食い違います。
参考：参照フィールドと参照修飾子：候補はどう絞られるか … 参照先の候補はここで絞られる
参考：ServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認 … cmdb_ci の参照先
既定値が設定されているフィールド
93項目のうち、既定値が設定されているのは25項目でした。
既定値の組み合わせに整合が取れています。impact の既定は 3（Low）、urgency の既定も 3（Low）。この組み合わせを優先度マトリクスに当てると 4 - Low になります。priority の既定値 4 と一致します。
made_sla の既定が true である点も設計の意図が読み取れます。SLA違反していない状態から始まり、期限を過ぎたときに false へ変わります。
knowledge の既定は false です。クローズ時のナレッジ記事の自動作成は、担当者が明示的に選ぶ形になっています。
JavaScript 式で決まる既定値
25項目のうち5項目は、固定値ではなく JavaScript 式が入っています。
number = javascript:getNextObjNumberPadded();
caller_id = javascript:incidentGetCaller();
opened_at = javascript:gs.nowDateTime()
opened_by = javascript:gs.getUserID()
sys_class_name = javascript:current.getTableName();
INC番号の採番、起票者の判定、起票時刻の記録が、この5行で決まります。caller_id の incidentGetCaller() は、ログイン中のユーザーを利用者として初期設定する関数です。ヘルプデスクが代理で起票する運用では、この初期値を毎回変えることになります。
参考：レコード採番（sys_number）：INC番号の決まり方 … 番号の桁とプレフィクスが決まる場所
必須項目を決めている仕組み
sys_dictionary の mandatory が true の項目は、93項目のうち0件でした。辞書の側では必須にしていません。
実際に必須になる項目は、別の3つの仕組みで決まります。
仕組みテーブルincident 向けの件数効く範囲UIポリシーsys_ui_policy15画面上のみデータポリシーsys_data_policy21画面・API・インポートすべてACL（write）sys_security_acl79書き込みそのものを止める
データポリシーは1件だけ有効でした。Make close info mandatory when resolved or closed という名前で、Resolved または Closed のときに解決情報を必須にします。
この違いは重要です。UIポリシーは画面でしか効きません。REST API やインポートセットから流し込むと、UIポリシーの必須は素通りします。データポリシーはどちらの経路でも効きます。
参考：APIやインポートにも効く必須制御（Data Policy） … 画面外からの投入はここで止まる
参考：ServiceNowで項目が画面に出ないのはなぜ？ ビュー・UI Policy・ACLを順番に切り分ける … 表示されない原因はここから切り分ける
公式のフィールド説明（sys_documentation）
ServiceNow は製品の中にフィールドの説明文を同梱しています。incident と task で35件に説明がありました。
項目の意図が読み取れるものを引用します。
Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency
（訳: インシデントまたは問題を解決すべき順序。影響度と緊急度にもとづく）
task.priority の説明です。優先度は影響度と緊急度から導かれる順序だと定義されています。
Combined output of Additional comments and Work notes
（訳: Additional comments と Work notes を合わせた出力）
task.comments_and_work_notes の説明です。利用者向けコメントと社内向け作業メモを1つにまとめて表示する項目だと分かります。
引用元: /sys_documentation_list.do?sysparm_query=nameINincident,task^hintISNOTEMPTY
参考：Comments/Work notes（sys_journal_field）は1追記1行 … 追記が保存される場所
task から継承するフィールドの内訳
task から受け継ぐ71項目を役割ごとに分けると、Incident が何を記録するために設計されているかが見えます。
時間の記録が12項目と最も多くなっています。起票・作業開始・作業終了・クローズ・期限・SLA期限を別々に持つためです。次に多いのが状態と優先度の8項目。
担当の割り当てに5項目ある点も特徴です。assigned_to（主担当）と assignment_group（グループ）に加えて、additional_assignee_list（追加担当者）、group_list（関係グループ）、skills（必要スキル）を持ちます。1件を複数人で追う運用に対応する構造になっています。
承認の5項目（approval / approval_history / approval_set / upon_approval / upon_reject）は、task を継承する Change Request のために用意されたものです。Incident では使われないまま残ります。
task の定義を incident 用に上書きしている項目
継承には第3の層があります。task の定義を受け継ぎつつ、incident でだけ挙動を変える上書き（sys_dictionary_override）です。実測では8件が登録されていました。
中身が具体的です。2つ取り上げます。
assigned_to：担当者の候補がロールで絞られている
参照修飾子が roles=itil^ORroles=sn_incident_write に上書きされています。担当者の欄で検索したとき、候補に出るのは itil か sn_incident_write を持つユーザーだけ。「あの人が担当者に選べない」という相談の答えは、多くの場合ここにあります。ロールを付ければ候補に現れます。
state：どの状態を「終了」とみなすかの定義
属性に close_states=7;8 / default_work_state=2 / default_close_state=7 が入っています。Closed（7）と Canceled（8）を終了状態として扱う定義が、辞書の上書きとして書かれている形です。ACL の incident_state NOT IN 7,8 という条件や、SLA の停止判定は、この定義と足並みを揃えています。独自の状態を「終了扱い」で追加するなら、この属性も更新の対象になります。
上書きの仕組みは、自社のカスタマイズでも使えます。task の項目を incident でだけ変えたいとき、task の辞書を直接変更すると Problem・Change・Catalog Task のすべてに波及してしまう。sys_dictionary_override に incident 用の行を足せば、task の定義には触れずに済みます。
調べる順序は3段階になります。
name=incident で開き、固有項目かを確認する
無ければ name=task で開く。継承なら、直接変更は全プロセスに波及すると意識する
incident だけ変えたい場合は sys_dictionary_override に incident 用の行があるか確認し、無ければ追加する
追記が保存されるフィールド
利用者とのやり取りと社内の調査メモは、別々の項目に保存されます。
comments（Additional comments）は利用者に見えます。work_notes（Work notes）は担当者だけが見る項目。この2つを取り違えると、社内の切り分けメモが利用者に届きます。
型はどちらも Journal Input です。フォームでは入力欄に見えますが、保存先は sys_journal_field という別テーブルになります。1回の追記が1行のレコードとして積まれる構造です。incident テーブルの列には、追記の本文が入りません。
comments_and_work_notes は Journal List 型で、両方を時系列にまとめて表示します。障害の経緯を最初から追うときに使います。
参考：Comments/Work notes（sys_journal_field）は1追記1行 … 追記が積まれるテーブルの構造
incident 固有のフィールド
incident だけが持つ22項目を、役割ごとに整理します。
利用者と分類
caller_id：連絡してきた利用者（User への参照）
category / subcategory：分類。ルーティングと集計の基礎になる
business_impact：業務への影響の記述
severity：重大度
解決の記録
close_code：解決コード。10種類から選ぶ
cause：推定原因
resolved_at / resolved_by：いつ誰が解決したか
保留と再オープン
hold_reason：保留理由。On Hold のときに何を待っているかを表す
reopen_count / reopened_time / reopened_by：再オープンの記録
親子関係
parent_incident / child_incidents：大規模障害を1件に束ねる
時間の計測
calendar_stc / business_stc：解決までの所要時間（実時間・営業時間）
その他
state / incident_state：状態。2つあるが同じ選択肢を持つ
notify：通知手段
origin_table / origin_id：どこから生成されたか
sys_id：レコードの識別子
Australia のデフォルト環境では、problem_id・rfc・caused_by は22項目に含まれていませんでした。問題管理・変更管理とのつなぎ方は本シリーズ第8巻「インシデント管理モジュールの連携機能」で扱います。
Incident では使われないまま残る項目
task を継承すると、Incident で使う予定のない項目も一緒に付いてきます。
承認の5項目
approval / approval_history / approval_set / upon_approval / upon_reject は、Change Request の承認フローのために用意されたものです。Incident の標準運用では承認を挟まないため、既定値のまま残ります。approval の既定値は not requested、upon_approval は proceed、upon_reject は cancel です。
実行計画の2項目
delivery_plan / delivery_task は Execution Plan（履行計画）への参照です。サービスカタログの申請が履行タスクへ展開されるときに使われます。Incident では空のままです。
ワークフローの2項目
wf_activity は Workflow Activity への参照、variables は Variables 型です。カタログアイテムの入力値やワークフローの現在地を保持します。
これらを画面に出さない設定が、UIポリシーとフォームレイアウトで行われています。項目が存在することと、画面に出ることは別です。自社で列を追加するとき、まず既存の未使用項目で足りないかを確認すると、テーブルが太りません。
監査とドメイン分離のフィールド
残る7項目は、業務データではなくプラットフォーム側の記録です。
監査の5項目
sys_created_by / sys_created_on：作成者と作成日時
sys_updated_by / sys_updated_on：最終更新者と更新日時
sys_mod_count：更新回数
sys_mod_count は更新のたびに増えます。1件のインシデントが何回触られたかが分かるため、手戻りの多い案件を洗い出す指標になる項目です。なお項目ごとの変更履歴は sys_audit という別テーブルに積まれます。
ドメイン分離の2項目
sys_domain：所属ドメイン（既定 global）
sys_domain_path：ドメインの階層パス（既定 /）
複数の会社や部門でインスタンスを分けて使うときに効きます。1社で使う環境では global のまま変わりません。
参考：ServiceNowの変更履歴はどこに残る？ sys_auditと監査対象フィールドを実機で確認 … 項目単位の履歴が残る場所
時間を測るフィールド
Incident は時間を5つの異なる項目で測ります。
実時間と営業時間を分ける理由は、評価の公平さにあります。金曜の夜に起きた障害を月曜の朝に解決した場合、実時間は60時間を超えます。営業時間で測れば数時間です。24時間対応の窓口と平日日中の窓口を同じ指標で比べると、後者が不利になります。
time_worked は Timer 型で、担当者が実際に手を動かした時間を測ります。滞留時間と作業時間を分けて把握できます。
実機で気づいたこと
辞書の必須指定を一切使っていない
93項目の mandatory を確認すると、すべて false でした。必須はUIポリシー15件とデータポリシー1件が決めています。
辞書で必須にすると、条件を付けられません。「Resolved のときだけ必須」という制御ができなくなります。ServiceNow が辞書レベルの必須を避けているのは、この柔軟さを保つためだと読み取れます。
自社で必須項目を追加するときも同じ判断をします。画面だけで足りるならUIポリシー、API経由の投入も止めるならデータポリシー。辞書の mandatory を直接 true にすると、後から条件を付けられなくなる点に注意してください。
状態を表す項目が2つあり、どちらも同じ選択肢を持つ
state と incident_state は、どちらも6つの同じ選択肢（New / In Progress / On Hold / Resolved / Closed / Canceled）を持ちます。
過去のバージョンとの互換のために両方が残っていると考えられます。実際、2件のビジネスルールが order 0 と 1,000,000 で相互に同期する構成になっており、値が食い違わないよう作られています。
レポートや条件式では state に統一します。incident_state を条件に使った定義が混ざると、片方だけ更新されたときに集計がずれる原因になります。自社でビジネスルールを追加する場合も、両方を更新する前提で書いてください。
close_code と close_notes は別の層にある
フォームの解決情報タブでは並んで見える2項目ですが、辞書上の層が違いました。close_code は incident 固有、close_notes は task 継承です。
ペアに見える項目が別の層に属している結果、close_notes は Problem や Change の解決メモとしても同じ定義が使われています。両方を incident 固有だと思い込んでいると、task を継承する他プロセスで close_notes が使われていることに気づけません。
解決情報まわりをカスタマイズするときは、2項目の追加先が違うことを前提に影響範囲を見ます。
辞書のラベルとフォームの表示名は一致しない
close_code と close_notes の辞書上のラベルは「Close code」「Close notes」です。ところが実際のフォームでは「Resolution code」「Resolution notes」と表示されます。
辞書の column_label は、その項目が最初に定義されたときのラベルです。フォーム側で表示名を変える仕組みが別にあるため、辞書を読むだけでは画面の文言まで分かりません。
利用者向けの手順書を書くときは、辞書ではなく実際のフォームの表示名で記述します。辞書のラベルで書くと、読者が画面上で項目を見つけられません。
利用者の欄に担当者の名前が入りやすい
caller_id の既定値は javascript:incidentGetCaller(); で、ログイン中のユーザーを初期設定します。ヘルプデスクが代理で起票すると、担当者自身の名前が入ります。
セルフサービスポータルからの起票を想定した既定値です。利用者が自分で起票する場合は正しく動きます。
代理起票が多い運用では、caller_id を必須かつ空で始める設定に変えます。方法は既定値を外すか、UIポリシーで初期化するかの2つ。集計の母数が担当者名で埋まると、利用部門別の分析ができなくなります。
使われないまま残る項目が9つある
93項目のうち、承認5項目（approval / approval_history / approval_set / upon_approval / upon_reject）、実行計画2項目、ワークフロー2項目は、Incident の標準運用では使いません。
task を継承したことで付いてくるものです。Change Request の承認フローやカタログの履行計画で使われる項目が、そのまま現れています。
自社の項目を足す前に、これらで代替できないかを確認します。たとえば correlation_id は外部システムの識別子として使える項目。u_ 付きの列を増やすより、既存の意味に沿った項目を使うほうが後の移行とレポートが楽になります。
実務で順番に検討する箇所
自社向けに項目を設計するとき、確認する順序を決めておくと迷いません。
追加先の判断：Incident だけで使うか、Change や Problem でも使うか。後者なら task に足す
型の選択：選択肢は Integer と String のどちらで持つか。既存項目に合わせる
既定値：固定値で足りるか、JavaScript 式が要るか
必須の実現方法：画面だけならUIポリシー、API経由も止めるならデータポリシー
参照先の絞り込み：Reference 型を足すなら参照修飾子も同時に決める
時間の測り方：実時間で評価するか営業時間で評価するかを先に決める
通知先の設計：watch_list と work_notes_list のどちらに誰を入れるかを決める
未使用項目の棚卸し：承認5項目・実行計画2項目を画面に出すかどうかを決める
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
辞書（Dictionary）：sys_dictionary。テーブルの各項目の型・長さ・既定値を定義する場所
参照修飾子：Reference 型の候補を絞り込む条件
データポリシー：画面・API・インポートのすべてに効く必須／読み取り専用の制御
検証範囲とおことわり
検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認
件数はすべて OOTB の定義の数です。本番環境やカスタマイズ済み環境では異なります
UIポリシー15件・データポリシー1件の条件式の中身は、本シリーズ第6巻「インシデント管理モジュールの自動設定構成」で扱います
ACL 79件（write）の内訳は、本シリーズ第3巻「インシデント管理モジュールのロール」で扱います
選択肢の値の決め方は、本シリーズ第5巻「インシデント管理モジュールの基本設定」で扱います
problem_id / rfc の有無はバージョンとプラグイン構成で変わる可能性があります
付録：自分の環境で確認するときのURL
incident の項目定義：/sys_dictionary_list.do?sysparm_query=name=incident^elementISNOTEMPTY
task の項目定義：/sys_dictionary_list.do?sysparm_query=name=task^elementISNOTEMPTY
参照型だけを見る：/sys_dictionary_list.do?sysparm_query=nameINincident,task^internal_type=reference^elementISNOTEMPTY
既定値が入っている項目：/sys_dictionary_list.do?sysparm_query=nameINincident,task^default_valueISNOTEMPTY^elementISNOTEMPTY
型ごとの件数：/sys_dictionary_list.do?sysparm_query=nameINincident,task^elementISNOTEMPTY^GROUPBYinternal_type
継承関係：/sys_db_object_list.do?sysparm_query=nameINincident,task
上書きの定義：/sys_dictionary_override_list.do?sysparm_query=name=incident
UIポリシー：/sys_ui_policy_list.do?sysparm_query=table=incident
データポリシー：/sys_data_policy2_list.do?sysparm_query=model_table=incident
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINincident,task^hintISNOTEMPTY
関連記事
taskテーブル：ITSM全プロセスの共通の親 … 71項目を提供している親テーブル
ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … 辞書テーブルそのものの読み方
ServiceNowの変更履歴はどこに残る？ sys_auditと監査対象フィールドを実機で確認 … どの項目の変更が履歴に残るか
