タスク管理モジュールのテーブル・フィールド構成

Incident・Problem・Change Requestなど、ITSMのフォームに並ぶ項目の多くはtaskという1つのテーブルに定義があります。task自身は何項目を持ち、63のテーブルにどう配られているのでしょうか。とりわけ状態（state）は基底が6値しかないのに、子テーブルごとに値も個数もまったく違う体系に置き換わっています。Australia PDIを実機で開き、task固有71項目の内訳と、stateを子テーブルが上書きする仕組みを確認しました。

確認する項目

• task固有のフィールドが何項目あり、どう分類できるか

• 基底のstate 6値がどんな内容で、どのテーブルがそれを上書きしているか

• 辞書上書き（sys_dictionary_override）が全置換型・部分再利用型のどちらになっているか

• 継承と参照の違い（task_sla等はtaskの子ではない）

• 3階層になる継承の実例

この記事の要点

• task固有フィールドは71項目で、63の直接の子テーブルすべてが同じ項目を継承する

• stateは基底6値（-5 Pendingを含む）だが、37テーブルが辞書上書きで独自の値体系に置き換える。63の直接の子のうち上書きするのは19件だけ

• task自身のsys_dictionary_overrideは0件。上書きは常に子テーブル側に対して行われる

taskの継承構造（63の直接の子テーブル）

taskはsys_db_objectのsuper_classが空です。ITSMを含む全プロセスの最上位に位置し、これより上の親はありません。

taskを直接継承するテーブルは63件です。Incident・Problem・Change Requestにとどまらず、サービスカタログのRequestやCatalog Taskも含まれます。承認のGroup approval、Visual Task BoardのPrivate Taskも同じ63件です。性格の異なる業務テーブルが、同じtaskから項目を継承しています。

63件を分類すると、ITSMコアは3件にすぎません。カタログ系・承認や汎用チケット・GRC系・SAM系・Creator Studio系など、非同期の業務プロセス全体が同じtaskを継承します。もっとも多いのは単発の業務テーブル29件で、資産回収・ガイド設定・スキャンタスクのように、一見バラバラな機能がここに含まれます。

incidentはticketの子ではなく、ticket（汎用チケット）とincidentはどちらもtaskの直接の子で、きょうだいの関係です。「Incidentはticketの一種」という理解は、実機の継承構造とは食い違います。この誤解を持ったままticketのACLやビジネスルールを触ると、incident側には影響しない変更を「Incidentにも効くはず」と思い込む原因になります。

参考：taskテーブル：ITSM全プロセスの共通の親 … taskが担う役割全体の整理

基底のstate・priority・approval選択肢（上書き前の15値）

task自身が持つ選択肢は3項目で、いずれも63の子テーブルすべてが継承する基底の値です。子テーブル側が辞書上書きで置き換える前の姿にあたります。

stateは6値です。-5がPending、1がOpen、2がWork in Progressという並びでした。3がClosed Complete、4がClosed Incomplete、7がClosed Skippedと続きます。既定値は1（Open）です。

priorityは1から5までの5段階で、既定値は4（Low）です。approvalは既定値がnot requestedで、requested・approved・rejectedを合わせた4値を持ちます。state・priority・approvalの3項目、合計15値が、63の子テーブルが辞書上書きで置き換える前に共有する基底の姿です。

sys_dictionaryでtask自身のstate属性を確認すると、close_statesやdefault_work_stateは空でした。task自身は「どの状態を終了とみなすか」を決めず、その判断を子テーブル側に委ねる作りです。

63の子テーブルの一部は、Incidentのような専用の状態遷移を持ちません。その場合はこの基底6値がそのまま画面に出ます。ドロップダウンの選択肢がどこに格納されるかという仕組み自体は、既存記事にまとまっています。

参考：選択肢Choice（sys_choice）：ドロップダウンの中身 … ラベルと値の対応が置かれる場所

stateを辞書上書きしている37テーブル

taskを継承するテーブルのうち、sys_dictionary_overrideでstateを上書きしているものは37件でした。うち19件は直接の子テーブル自身、残り18件はplanned_taskやissueをさらに継承した2次以降の子テーブルです。上書きは値の入れ替えだけでなく、選択肢そのものを丸ごと置き換える形で行われます。

代表的な7テーブルの値を並べると、上書きの幅がわかります。

全置換型：incident・problem・change_request・dmn_demand

incidentは1・2・3・6・7・8の6値です。値も個数もtaskの基底とは別物です。problemは101から107番台で採番され、105だけが欠番のまま6値が使われます。change_requestは-5から4までの8値で、負の値を使ってAssess・Authorize・Scheduled・Implementというライフサイクルの段階を表します。dmn_demandはさらに独自で、9値のうち-4（Qualified）だけが負の並びです。

sys_dictionary_overrideのレコードを開くと、値の置き換えだけでなくclose_states・default_work_state・default_close_stateという3つの属性も一緒に上書きされています。problemならclose_states=107,default_work_state=102,default_close_state=107という指定です。

Problemの状態遷移とKnown Errorまでの流れは、既存記事に詳しくまとめています。

参考：Problem（problem）の読み方 … Problemの状態フィールドと項目の全体像

部分再利用型：std_change_proposal・sn_grc_indicator_task

std_change_proposal と sn_grc_indicator_task は、基底の値を一部残したまま上書きする部分再利用型です。std_change_proposalは1・2・3・4の4値で、1から3までは基底と同じ値をそのまま使い、7だった値を4に短縮しています。sn_grc_indicator_taskは1・2・3・7の4値で、値そのものは基底とほぼ同じですが、7のラベルだけをClosed SkippedからCancelledに変えています。

値を残してラベルだけ変える上書きと、値ごと入れ替える上書きの両方が実機に存在します。自社で新しいstate体系を作るとき、基底に近い値のままラベルだけを変える選択肢があることも覚えておくと設計が軽くなります。

上書きしない44テーブル

63の直接の子のうち、stateを上書きしているのは19件だけでした。残り44件は、asset_taskやgsw_taskのように基底の6値をそのまま使います。

task継承で新しい業務テーブルを作るときも、Open・Work in Progress・Closedの3段階で足りる業務なら、辞書上書きをせずに済みます。辞書オーバーライドという仕組みそのものの読み方は、既存記事を参照してください。

参考：辞書オーバーライド：継承フィールドを子だけ上書き … sys_dictionary_overrideの構造そのものの解説

辞書上書きを読み取って動く仕組み

上書きした属性は、書いただけでは動きません。状態が変わったときclose_states・default_work_state・default_close_stateを読み取り、activeフィールドの自動更新やクローズ処理を行うのはTaskStateUtilというサーバ側の共通処理です。個別テーブルごとに開く・閉じるの処理を書き直す必要がなく、辞書の値を変えるだけで挙動が変わります。

この分担には理由があります。37テーブルそれぞれに「状態が閉じたらactiveをfalseにする」処理を個別に書くと、同じロジックが37箇所に散らばる形です。1箇所の修正が全テーブルに反映されない不具合も起きやすくなります。値の意味づけを辞書側に集め、処理を1本の共通クラスにまとめれば、新しいテーブルを追加するときも辞書の3属性を設定するだけで済みます。

TaskStateUtilが実際にどう動くか、保存1回でどのBusiness Ruleが何件走るかは、本シリーズ第5巻「タスク管理モジュールの自動設定構成」で扱います。本巻で解剖したのは、その処理が読み込む辞書側の定義です。

task固有フィールドの内訳（71項目）

stateを含むtask固有のフィールドは71項目です。役割ごとに分けると、時刻・所要時間の記録が12項目と最多で、次に状態・優先度と他レコードとの関連がそれぞれ8項目でした。

mandatoryがtrueの項目は71項目中0件でした。必須の制御は辞書レベルでは行わず、子テーブル側のUIポリシー・データポリシー・ACLに委ねる設計です。辞書テーブルそのものの読み方は既存記事にまとまっています。

参考：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … 辞書テーブルの読み方

型で見る71項目

内訳を型で見ると、時刻系だけでもDate/Time・Duration・Timerの3種類が混在します。Date/Timeは時刻そのもの、Durationは2点間の長さ、Timerは積み上げた作業時間です。同じ「時間」でも測っている対象が違います。

state・priority・impact・urgencyはInteger型です。画面には「Open」「Critical」と表示されますが、データベースには1や2の数値が入ります。ビジネスルールや条件式で指定するのは、ラベルではなく数値のほうです。state=1と書けばOpenを指します。子テーブルが値を丸ごと入れ替えても型がInteger型のまま変わらないのは、この仕組みがあるためです。対してapprovalはString型で、条件式ではapproval='approved'のように文字列で指定します。同じ選択肢系の項目でも、型は項目ごとに違います。

承認の5項目（approval / approval_history / approval_set / upon_approval / upon_reject）はChange Requestの承認フローのために用意されていますが、Incidentのように承認を使わないテーブルでは既定値のまま残ります。approvalの既定値はnot requested、upon_approvalはproceedです。承認を使わないテーブルでも、この5項目は画面のどこかに存在し続けます。フォームレイアウトから外さない限り、空欄のまま表示され続ける点に注意が必要です。

参照フィールドが指す先

71項目のうち、参照型（Reference）は16項目です。指す先を集計すると、sys_userが3項目、task自身への自己参照が3項目でした。

参照先件数フィールドsys_user（人）3assigned_to / opened_by / closed_bytask自身（自己参照）3parent / rejection_goto / universal_requestCI・サービス系3cmdb_ci / business_service / service_offering組織・契約系3company / location / contractカタログ履行系2delivery_plan / delivery_taskassignment_group1sys_user_groupwf_activity1wf_activity

parentが特に汎用的です。Change TaskがどのChangeの子かも、Catalog TaskがどのRequestの子かも、この1項目で表現します。子テーブルごとに専用の親参照フィールドを作らずに済む設計です。CIの参照先であるcmdb_ci自体は102クラスに分かれる大きな階層で、詳しい継承構造は既存記事で扱っています。

参考：ServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認 … cmdb_ciの参照先の継承構造

追記・監査・ドメイン分離の項目

71項目には、参照や時刻以外の実務的な項目も残っています。

追記を保存する項目は5つです。comments（Additional comments）は利用者に見えます。work_notes（Work notes）は担当者だけが見る項目です。comments_and_work_notesは両方を時系列にまとめます。通知先も2種類に分かれます。watch_listは全更新を追いたい人向けです。work_notes_listは社内の調査経過だけを追いたい人向けです。

監査の5項目（sys_created_by / sys_created_on / sys_updated_by / sys_updated_on / sys_mod_count）は、プラットフォーム側の記録です（業務データではありません）。sys_mod_countは更新のたびに増えます。手戻りの多い案件を洗い出す指標として使える項目です。

テーブル単位のAudit設定

sys_dictionaryには、フィールド単位の行だけでなくテーブルそのものを表す行があります。この行にはAuditという列があり、テーブル全体の変更をsys_auditに記録するかどうかを決めます。上で見たフィールド単位のaudit列（追記・監査の5項目とは別の項目）とは異なる階層の設定です。

task自身のテーブル単位の行を確認すると、Auditはfalseでした。フィールド単位のauditも、task固有71項目のうちaudit=trueは0件です。監査対象にする指定は、taskの側には一切ありません。

63の直接の子テーブル全件を同じ方法で確認すると、45件がtrue、18件がfalseです。true側にはincident・problem・change_request・ticket・sc_request・sysapproval_group・vtb_taskが並びます。ITSMコアやカタログ・承認・VTB系は、ほぼここに入ります。false側は資産の回収タスクやCMDBの再計算タスクのような、内部の補助的な処理が中心でした。

監査を有効にするかどうかも、taskは決めず子テーブル側に委ねています。SLAや割り当てルールの0件とも重なる設計です。

ドメイン分離の2項目（sys_domain / sys_domain_path）は、複数の会社や部門でインスタンスを分ける運用で効きます。既定値はどちらもglobalと/です。1社で使う環境ではほぼ変わりません。

残るcontact_typeとreassignment_countは、それぞれ問い合わせ経路の記録と、担当グループを変更した回数の記録です。reassignment_countはassignment_groupが変わるたびに、Business Ruleが1ずつ加算します。63の子テーブルすべてで同じルールが動くため、テーブルごとに集計ロジックを書き直す必要がありません。

公式のフィールド説明（sys_documentation 20件）

taskには公式の説明文（hint）が20件登録されています。

assigned_to・activity_due・knowledge・sys_domainの4件を引用します。

（訳: このタスクの作業に主として責任を持つ人）

assigned_toの説明です。

（訳: Inactivity Monitorがこのタスクの更新を期待する日付）

activity_dueの説明です。放置されたタスクを検知する仕組みが、taskレベルの項目として最初から用意されているとわかります。

（訳: チェックすると、クローズ時に下書きのナレッジ記事を自動作成する）

knowledgeの説明です。

（訳: このタスクが属するドメイン）

sys_domainの説明です。

引用元: /sys_documentation_list.do?sysparm_query=name=task^hintISNOTEMPTY

残り16項目の要約は次の通りです。

継承ではなく参照でつながる周辺テーブル

taskを参照する実テーブルは98件です。うちtask_で始まる21件のテーブルのうち13件はsuper_classが空で、taskの子ではなく参照でつながる関連テーブルでした。

task_slaはtaskとcontract_slaの両方を参照する橋渡しテーブルで、1件のtaskに複数のtask_slaが並走します。詳しい時計の読み方は既存記事を参照してください。作業時間明細のtask_time_workedも同じ構造で、継承ではなく参照でつながります。

参考：task_sla：1タスク1本のSLA時計の読み方 … SLA時計の読み方

参考：SLA Definition（contract_sla）とは：時計を生むルール … SLA定義の読み方

参考：作業時間明細（task_time_worked）は継承でなく参照 … 参照でつながる周辺テーブルの実例

3階層になる継承の実例（planned_taskというハブ）

63の直接の子のうちplanned_taskは、2階層（task→子）で完結せず、さらに14のテーブルに継承される中間クラスです。中間クラスは自分の固有フィールドを追加してから、末端の具象テーブルに渡します。planned_taskの子はtaskの71項目に加えて、planned_task自身が追加した項目も引き継ぐことになります。

14テーブルのうち、デモデータに記録があるのは8テーブルだけでした。合計は1,461件です（pm_project_task1,231+pm_project67+pm_program7+dmn_decision6+sn_cim_task74+sn_cim_register32+sn_vdr_risk_asmt_assessment36+sn_grc_issue8）。incident73+problem24+change_request106+change_task10=213件と比べ、約7倍の規模です。本PDIのデモデータでは、Incident対応よりもプロジェクト・需要管理系のレコードのほうが多いという結果でした。件数は環境によって変わるため、自社の実態は別途確認してください。

issueも同様に3階層です。sn_vdr_risk_asmt_issueはtaskではなくissueを継承しています。新しい業務テーブルを設計するとき、taskを直接継承するか、planned_taskやissueのような中間クラスを継承するかで、引き継ぐ項目の量が変わります。

中間クラスを選ぶ判断基準は単純です。プロジェクトや案件のように「予定日・進捗・成果物」といった項目を複数の子テーブルで共有したいなら、planned_taskのような中間クラスを継承します。そうした共通項目が不要で、taskの71項目だけで足りるなら、直接継承で十分です。中間クラスを増やしすぎると、どの項目がどの階層で定義されているかが追いにくくなる点は留意してください。

実機で気づいたこと

stateフィールドだけ公式ヒントが無い

task固有71項目のうち、20項目にsys_documentationのhintが登録されています。priorityやimpactには説明がある一方、stateには1件もありませんでした。

stateはtask系テーブルでもっとも重要な項目です。それでも公式の説明文が無いのは、値の意味が子テーブルごとに変わるためだと考えられます。task自身の6値と、incidentの6値、problemの6値はまったく別物で、共通の説明文を書けません。

自社でstateの意味を確認するときは、hintではなくsys_choiceの選択肢一覧とsys_dictionary_overrideの属性を直接見ます。説明文が無い項目こそ、実機で確認する価値があります。

task自身にも246件の生レコードが残っている

taskは抽象クラスで、実際のレコードは必ずincidentやproblemのような具象テーブルとして作られると考えていました。デモデータをsys_class_nameでグループ化すると、全3,402件が30種類の具象テーブルに分かれます。その内訳を数えると、taskという基底クラスそのままのレコードが246件残っていました。

どの経路で作られたレコードかは本記事の範囲外ですが、taskは、具象子テーブルを持たないまま直接インスタンス化されうる作りです（完全な抽象基底ではありません）。自社でtask系のデータを集計するとき、sys_class_name=taskのレコードを見落とすと、件数が合わない原因になります。

63の直接の子のうち44件は状態モデルを変えていない

stateを辞書上書きしているテーブルにばかり目が向きますが、63の直接の子のうち44件は上書きをせず、基底の6値をそのまま使います。

task継承で新しい業務テーブルを作るときも、Open・Work in Progress・Closedの3段階で足りる業務なら、辞書上書きをせずに済みます。上書きが必要になるのは、独自の承認段階やライフサイクルを表現したいときだけです。

実務で順番に検討する箇所

自社向けにtask継承のテーブルを設計するとき、確認する順序を決めておくと迷いません。63テーブルの実例を見ると、迷いやすい判断はおおむね7つに集約されます。

1. 継承の起点：新しい業務テーブルはtaskを直接継承するか、planned_taskのような中間クラスを継承するか

2. 状態モデル：基底の6値で足りるか、辞書上書きで独自の値体系にするか

3. 上書きの範囲：値だけでなくclose_states・default_work_state・default_close_stateも一緒に決める

4. 参照フィールドの再利用：parentのような汎用項目で足りないか、専用の参照フィールドが本当に必要か

5. 必須の実現方法：子テーブル側のUIポリシー・データポリシーで決める（辞書のmandatoryは使わない）

6. 周辺テーブルの選択：task_slaのような多対一の関連を自作するか、既存の仕組みに乗るか

7. 項目の追加先：Change・Problem等でも使う項目ならtask側、そのテーブルだけで使うなら子テーブル側に追加する

7つの判断のうち、もっとも影響が大きいのは1番目です。継承の起点を間違えると、あとから中間クラスを差し込むのは大がかりな変更になります。設計の初期段階でどこまで項目を共有するかを決めておくと、後戻りが減ります。

用語

• OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態

• PDI：Personal Developer Instance。ServiceNowが無償で提供する個人検証用インスタンス

• 辞書（Dictionary）：sys_dictionary。テーブルの各項目の型・長さ・既定値を定義する場所

• 辞書上書き（Dictionary Override）：sys_dictionary_override。継承した項目の設定を、子テーブルだけで変更する仕組み

• 中間クラス：planned_taskやissueのように、taskと末端の具象テーブルの間に挟まる継承のハブ

検証範囲とおことわり

• 検証環境：Australia PDI / OOTB / 2026-09-01 確認

• 件数はすべてOOTBの定義の数です。本番環境やカスタマイズ済み環境では異なります

• stateを上書きする37テーブルの一覧は本記事の実測に基づきます。プラグイン構成やバージョンにより変わる可能性があります

• TaskStateUtilの処理詳細・Business Ruleの実行順序は本シリーズ第5巻「タスク管理モジュールの自動設定構成」で扱います

• ACL件数は本シリーズ第3巻「タスク管理モジュールのロール」、UIポリシー・UIアクションの件数は第5巻「タスク管理モジュールの自動設定構成」で扱います

• デモデータの分布（1,461件等）は本PDI固有の値です。自社環境の実態は別途確認してください

付録：自分の環境で確認するときのURL

• task固有の項目定義：/sys_dictionary_list.do?sysparm_query=name=task^elementISNOTEMPTY

• taskを直接継承する子テーブル：/sys_db_object_list.do?sysparm_query=super_class=<taskのsys_id>

• stateの選択肢：/sys_choice_list.do?sysparm_query=name=task^element=state

• stateの辞書上書き一覧：/sys_dictionary_override_list.do?sysparm_query=element=state

• 参照型だけを見る：/sys_dictionary_list.do?sysparm_query=name=task^internal_type=reference^elementISNOTEMPTY

引用した公式説明を実機で確認する方法

この記事で引用した説明文は、ServiceNowが製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=task^hintISNOTEMPTY

関連記事

• taskテーブル：ITSM全プロセスの共通の親 … taskが担う役割全体の整理

• 辞書オーバーライド：継承フィールドを子だけ上書き … 辞書上書きの仕組みそのものの読み方

• 作業時間明細（task_time_worked）は継承でなく参照 … 周辺テーブルの実例