タスク管理モジュールの概要
Incident・Problem・Change・Requested Item の画面を並べると、番号・状態・担当者・優先度といった項目がどれも同じ配置で並びます。この作りはどこで決まっているのでしょうか。ServiceNow ではこれらのテーブルすべてが task という1つの基底テーブルを継承しています。Australia の PDI を OOTB のまま開き、task が実際にどこまでを共通化し、どこから先を各テーブルに委ねているかを確認しました。
検証環境：Australia PDI / OOTB / 2026-09-01 確認
この記事で分かること
task が ITSM 全プロセスに共通する最上位のテーブルで、他に継承元を持たないこと
task を直接継承するテーブルが63件あり、Incident・Problem・Change 以外にも広がっていること
task 自身が定義する項目・ACL・ビジネスルールの範囲と、子テーブルに委ねている範囲
task 自体にも生のレコードが存在し、完全な抽象テーブルではないこと
task_sla のような周辺テーブルが継承ではなく参照でつながっていること
先に押さえておくこと
task は super_class を持たない ITSM テーブル階層の最上位で、63のテーブルが直接継承する
task 自身の直接ACLはわずか4件で、読み書きの実際の権限は子テーブル側が個別に持つ
task は抽象テーブルに見えて、基底クラスのままの生レコードが246件存在する
task の位置づけ
ServiceNow を使い始めると、Incident・Problem・Change・Requested Item のフォームがよく似ていることに気づきます。番号の採番規則、状態の遷移、担当者の指定方法、優先度の付け方。プロセスが違うのに操作感が揃っているのは、共通の設計を土台にしているためです。
多くの担当者が最初に期待するのは、この共通部分がどこか1か所にまとまっていることです。プロセスごとに番号の採番ロジックや優先度の選択肢を個別に作り直していては、保守のたびに複数箇所を直すことになります。
ServiceNow はこの共通部分を task というテーブルに集約しています。task は特定のプロセスを表すテーブルではなく、「誰かが対応すべき1件の仕事」という抽象を表す型です。Incident・Problem・Change を含む多数のテーブルがこれを継承し、共通の骨格の上に具体的なプロセスを組み立てます。
task という土台が見えると、プロセス横断で「自分に割り当てられた仕事」を検索したり、複数プロセスに共通するレポートを作ったりする設計がしやすくなります。個別のプロセスがどんな仕組みで動くかは、Incident・Problem・Change それぞれのシリーズが担当します。この記事のテーマは、共通の土台であるtaskが何を提供し、何を子テーブルに委ねているかです。
公式ドキュメントが説明するtaskの役割
ServiceNow は製品の中にフィールドの説明文を同梱しています。sys_documentation の hint です。task 自身のフィールドには20件の説明がありました。
priority・impact・クローズ時の挙動という3件の説明を引用します。
Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency
（訳: インシデントまたは問題を解決すべき順序。影響度と緊急度にもとづく）
これは task.priority の説明です。task はあらゆるプロセスに共通する項目ですが、公式の説明文自体は Incident と Problem だけを名指ししています。
もう1件、影響度の定義を見ます。
Measure of the business criticality of the affected service
（訳: 影響を受けたサービスの、業務上の重要度を測るもの）
影響度は止まったサービスが業務にとってどれだけ重要かを測る指標です。プロセスを問わず共通に使える定義です。
クローズ時の挙動に関わる説明も1件あります。
If checked, will automatically create a Draft knowledge article upon closure
（訳: チェックすると、クローズ時にナレッジ記事の下書きを自動で作成する）
task.knowledge の説明です。ナレッジ化のトリガーは task 側で定義され、Incident・Problem・Change のどのクローズでも同じ挙動になります。
引用元: /sys_documentation_list.do?sysparm_query=name=task^hintISNOTEMPTY
task はsuper_classを持たない最上位テーブル
sys_db_object で task のテーブル定義を確認します。
Extends table（super_class）の欄は空です。task はこれより上位のテーブルを持たない、ITSM テーブル階層の最上位です。スコープは global で、プラットフォームの標準機能として提供されます。
テーブル定義には is_extendable（拡張可能）という項目もあります。task はこの値が true です。super_class の空欄は継承元を持たないことを示します。is_extendable=true は、他のテーブルから継承される側として開かれていることを示します。採番定義（sys_number）でも task は独自のカテゴリを持ち、プレフィックスは TASK です。後述する生レコード（TASK0020921）の番号も、この採番体系にもとづきます。
task を継承する側のテーブル定義を開くと、この欄には必ず「Task」と表示されます。次の節で、その継承がどこまで広がっているかを見ます。
継承の意味を示す実例
task が最上位のテーブルであることを確認しました。ここからは「継承する」という言葉が実際に何を意味するのか、3つの実例で確認します。
実レコードで見る継承
incidentのINC0000060（メール接続不可の記録）を、taskの一覧で絞り込みます。
Number・Priority・Assigned to・Short descriptionの列は、incident.list（Incidentの一覧）で見るのと同じ値です。sys_idも同一で、この1件はtaskの一覧からもincidentの一覧からも同じレコードとして参照できます。
Stateの表示は「Closed」でした。task自身のstate選択肢では値7のラベルは「Closed Skipped」ですが、この行はincidentが辞書上書きしたラベルで表示されています。継承したフィールドの値は、実体テーブル側の設定に従って解釈されます。
stateの上書きに見る継承
taskはstateという項目の枠を子テーブルに配り、値の中身は子テーブル側の判断に委ねます。taskの基底stateは6値（-5のPendingを含む）ですが、incidentはこれを辞書上書きし、独自の6値に置き換えます。継承の実態は同じ列を共有することにあり、値の体系は子テーブルが決め直します（内訳は次の節と本シリーズ第2巻で扱います）。
新規テーブルに継承で付いてくるもの
taskを継承してテーブルを1つ新規作成すると、numberの自動採番・担当管理・状態遷移・作業履歴が、追加の実装なしでそのまま使えます。状態遷移はTaskStateUtil、作業履歴はcomments/work_notesという共通項目が担う構造です。具体的な内訳は、次節以降と本シリーズ第9巻「タスク管理モジュールの開発設計書」で扱います。
継承設計を採る理由
taskへ処理を集約する設計には、実機の構造から読み取れる理由が複数あります。
共通項目の一元定義：number・state・priority・assigned_toなど基本語彙をtask側1か所で定義し、63テーブルが共有する
共通機能の一括提供：承認（sysapproval_approver）・SLA（task_sla）・関連CI（task_ci）・Visual Task Board・アクティビティ（comments/work_notes）を、taskを参照する仕組みだけで63テーブルに配れる
横断レポート：taskの一覧やGROUPBYで、プロセスを問わず誰が何件抱えているかを横断集計できる
汎用ロジック：TaskStateUtilが子テーブルの辞書属性を読んで状態遷移を処理するため、閉じる・再開くの実装を63テーブルごとに書かずに済む
いずれも、フィールドや機能を個別実装させず、共通部分は1か所・固有部分だけ子テーブルという役割分担を徹底する設計だと読み取れます。
継承のメリットとデメリット
ここまでの実例を、メリットとデメリットの対比として整理します。
メリットは、共通部分の実装コストと運用の一貫性に効きます。デメリットは、63テーブルが1つのtaskを共有する構造そのものが生む結果です。task層に手を入れる変更は影響範囲の確認が必須で、症状の切り分け方は本シリーズ第6巻「タスク管理モジュールのトラブル事例と解決」で扱います。
task を直接継承する子テーブル
sys_db_object を super_class=task で絞ると、直接継承する子テーブルが63件ありました。
63件を分野で分けると、次の9分類になります。
全体の広がりを図にすると次のようになります。
63件は役割の重さに差があり、主な顔ぶれを4つの塊で見ていきます。
ITSMのコアプロセス
incident・problem・change_request・change_taskの4テーブルが、ITSM運用の中心です。incidentは障害の暫定対応、problemは恒久原因の記録、change_requestは変更の申請と承認、change_taskはその変更内の個々の作業を担当します。付随するincident_task・problem_taskも同じ系列の直接の子です。
4テーブルとも、taskの基底state・priorityを辞書上書きし、自分専用の値体系に置き換えています（値の中身は次節）。デモデータの件数はincident73＋problem24＋change_request106＋change_task10＝213件でした。個別の状態遷移・承認経路・自動化の詳細は、各プロセスのシリーズが担当します。
参考：インシデント管理モジュールの概要 … Incidentの役割と全体像
参考：問題管理モジュールの概要 … Problemの役割と全体像
参考：変更管理モジュールの概要 … Change Requestの種別と承認経路
申請と依頼
sc_request（申請そのもの）・sc_req_item（申請内の品目）・sc_task（品目に紐づく履行作業）は、いずれもtaskを直接継承する同格のきょうだいです。申請から履行までは、1階層の親子関係ではなく3つの独立したtask継承テーブルの組み合わせで表現されます。
ticket（汎用チケット）も同じ階層でtaskを直接継承しています。「incidentはticketの子」という見え方をすることがありますが、実機ではticketとincidentはどちらもtaskの直接の子で、親子関係にはありません。IT部門を横断する汎用の起票先として、incidentとは別の用途に使われます。
3テーブルの構造とライフサイクルは、リクエスト管理シリーズが扱います。
計画系（planned_task ファミリー）
planned_task は直接の子でありながら、それ自体がさらに下の階層へ継承が伸びる中間ハブです。sys_db_object で planned_task と pm_project_task を並べて見ると、この2階層が実機でも確認できます。
planned_task の super_class は Task、pm_project_task の super_class は Planned task です。「task を継承するテーブル」と一括りにすると、直接の子と、間接的に2段階挟んで継承するテーブルが混在していることを見落とします。3階層をたどると、planned_task の直接の子は14クラスあり、レコードの合計は1,461件です。前節のコアITSM合計213件と比べると約7倍にあたります。PPM（プロジェクト・プログラム・需要）・CIM（変更影響管理）・GRC・VDR（ベンダーリスク評価）といった非ITSM系のプロセスが、この中間ハブを経由してtaskの資産を使っています。
各クラスの内訳と件数は、本シリーズ第2巻「タスク管理モジュールのテーブル・フィールド構成」で扱います。
そのほかのファミリー
上の3ファミリーに含まれない残りは3分野です。資産・CMDB管理タスク（asset_task等）とソフトウェア資産管理（SAM、samp_sw_eol_task等）が含まれます。GRC/リスク/セキュリティ（sn_grc_indicator_task等）も同様です。ほかに承認とタスクボード（sysapproval_group・vtb_task）とナレッジ/アイデア/課題（kb_feedback_task等）があります。開発/連携基盤（Creator Studio・Deployment Pipeline等）と、change_phase/release_phase/release_taskなどのリリース関連も対象です。いずれも各分野の非同期処理をtaskの上に実装している点は共通です。内訳の件数は上の分類表（画像）で確認できます。
実務でtaskの広がりを把握するときは、直接の63件だけでなく、planned_task経由の2階層先まで含めて考える必要があります。個別テーブルの固有フィールドと、task 側の項目をどう上書きしているかは、本シリーズ第2巻「タスク管理モジュールのテーブル・フィールド構成」で扱います。
task 自身のフィールド構成
sys_dictionary で task 自身のフィールド定義を数えると71件でした。
number・state・priority・assigned_to・short_description・work_notes など、ITSM の基本語彙はここで定義されています。71件のうち mandatory=true（辞書レベルでの必須指定）は0件でした。必須にするかどうかの判断は、UIポリシーやデータポリシーといった子テーブル側の設定に委ねられています。
自己参照するフィールドが3件あります。parent・rejection_goto・universal_request はいずれも task 自身を参照先に持ちます。parent は「Change Task の親 Change」のような子テーブル間の親子関係を、個別に参照フィールドを作らずに表現する仕組みです。
sys_dictionary_override（task向け）は0件でした。上書きは常に子テーブル側の辞書に対して行われ、task 自身の辞書には上書きが存在しません。項目の追加や型の変更が必要になったら、子テーブル側で対応する設計です。
各項目の一覧と、画面にどう出すかの判断は、本シリーズ第2巻で扱います。
状態・優先度・承認の基底の選択肢
sys_choice で task の state を確認すると6件でした。
Pending（-5）
Open（1）
Work in Progress（2）
Closed Complete（3）
Closed Incomplete（4）
Closed Skipped（7）
初期値は Open（1）です。負の値である Pending（-5）が基底に存在する点は見落とされやすいところです。
priority は5段階（1-Critical〜5-Planning）、approval は4値（not requested/requested/approved/rejected）。これも全プロセス共通の基底値です。
Incident はこの6値を辞書上書きでまるごと自分専用の値体系に置き換えます。1・2・3・6・7・8という独自の番号体系がそれです。Problem も101〜107という別の番号体系を持ちます。task 自身の6値がそのまま使われる場面は、専用の状態モデルを持たない一部の子テーブルに限られます。
状態をどこまで自社向けに追加してよいかの判断基準は、本シリーズ第2巻「タスク管理モジュールのテーブル・フィールド構成」で扱います。
task 直接の共通設定の範囲
task に紐づく設定を種類ごとに数えると、次のようになりました。
図にすると、task 層で完結している設定と、値をゼロのまま子テーブルへ渡している設定が分かれます。
task 直接のACLは4件です。
内訳は report_view（レポート閲覧）が3件、delete（削除）が1件で、read・write・createの直接ACLは1件もありません。基本的な読み書き権限は、子テーブル（incident・problem等）が個別に定義する設計です。フィールドレベルのACLは30件あり、itil と task_editor という2つの独立したロールのどちらかで書き込みが許可されています。誰がどこまで編集できるかの詳細は、本シリーズ第3巻「タスク管理モジュールのロール」で扱います。
参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの読み方の基礎
参考：インシデント管理モジュールのロール … itilロールが実際にどこまで及ぶか
ビジネスルールは有効33件です。
状態を閉じる・再開する処理は、個別テーブルごとの実装ではなく TaskStateUtil というスクリプトが、子テーブルの辞書属性（close_states 等）を読んで汎用的に処理します。この設計の詳細は、本シリーズ第5巻「タスク管理モジュールの自動設定構成」で扱います。
参考：インシデント管理モジュールの自動設定構成 … 子テーブル側でTaskStateUtilの入力がどう設定されているか
一方、SLA定義・割り当てルール・エスカレーションルール・Data Lookupは、task 直接ではいずれも0件です。task が提供するのはフィールドと汎用ロジックという構造で、期限や担当割り当ての具体的な値はすべて子テーブル側が個別に持ちます。プロパティは91件あり、SLA・CI同期・GRC設定など、テーマ別に子テーブルへ向けた挙動を切り替える値が並びます。
参考：task_sla：1タスク1本のSLA時計の読み方 … 期限を測る仕組みは子テーブル側の関連テーブルが持つ
参考：SLA Definition（contract_sla）とは … 期限のルール定義そのものの読み方
参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方
task を参照しているテーブル（継承ではなく参照）
sys_dictionary で task を参照しているフィールドを検索すると289件が該当します。ユニークなテーブル名で数えると277テーブルです。ただし内訳を見ると、179テーブルは Flow Designer の内部変数テーブルでした。フローの入出力欄が Task 型であるために自動生成されるものです。これを除くと、実際に task を参照している実テーブルは98件です。
task_ で始まるテーブルは21件ありますが、そのうち13件は super_class が空でした。
task_sla・task_ci・task_time_worked はいずれも、task を参照フィールドとして持つ独立したテーブルです（「taskを継承した子テーブル」ではありません）。作業時間の明細（task_time_worked）を継承でなく参照として扱う理由は、既存記事で扱っています。
参考：作業時間明細（task_time_worked）は継承でなく参照 … task_* 系テーブルの位置づけ
残り7件（task_action_workflow 等）は super_class が Application File で、更新セットで移送される設定マスタです。
参照関係を数えるときは、Flow Designer の内部変数テーブル（var__m_ で始まる名前）を除外する必要があります。承認（sysapproval）やVisual Task Boardとの具体的なつなぎ方は、本シリーズ第7巻「タスク管理モジュールの連携機能」で扱います。
参考：インシデント管理モジュールの連携機能 … 個別プロセス側での承認・VTBとの接続例
task 自身に残る生レコード
task を継承する63テーブルを見ていると、task 自身は具体的な業務データを持たない抽象的な型に見えます。実機のデータを数えると、そうではありませんでした。
デモデータの task 総件数は3,402件で、30種類の sys_class_name に分かれます。
このうち、どの子テーブルにも分類されない生の task レコードが246件存在します。「taskは抽象クラスで、実際のレコードは常にIncidentのような具象テーブルとして作られる」という一般的な想定とは異なる実測結果です。実際の1件がどうなっているかは、次の「実機で気づいたこと」で見ます。
実機で気づいたこと
生レコードにも実例がある
246件の生レコードのうち1件を開くと、次のようになっていました。
短い説明は「Quantity threshold breached: Santa Monica Warehouse」。在庫のしきい値超過を知らせる通知でした。プラットフォームや周辺アプリケーションが内部的に生成する汎用タスクが、具象テーブルを持たないまま task のレコードとして残ります。
task_list.do を対象にした集計や連携を組むときは、この生レコードも母数に含まれます。sys_class_name で絞り込まずに「taskの件数」を数えると、こうした汎用通知まで一緒に数えてしまいます。
task.priorityの公式説明はIncidentとProblemしか名指ししていない
task.priority の公式ヒントには、Incident と Problem だけが名指しされていました。原文は「Sequence in which an Incident or Problem needs to be resolved」です。task を継承する63テーブルの大半（Change Task・Catalog Task・PPM系など）は、この説明の対象外です。
PPMやGRCの担当者がフォーム上でPriorityにマウスを重ねても、Incident・Problemの話しか出てきません。非ITSM系のプロセスでtaskを土台に新しいテーブルを作るときは、公式ヒントをそのまま流用せず、自分たちの業務に即した説明文を用意したほうが混乱を防げます。
参照テーブルの件数は実態より多く見える罠を実際に踏んだ
reference=task で検索を打つと289件がヒットします。件数だけを見て「taskはこれほど広く連携している」と早合点しかけましたが、実際に1件ずつ開くと9割以上が var__m_sys_hub_flow_input_* のようなFlow Designerの内部変数テーブルでした。
影響範囲を調べるときにこの数字をそのまま使うと、実態の3倍近くに見積もることになります。var__m_ で始まるテーブルを除外するクエリを最初から組んでおけば、この罠は避けられます。
task_editorロールはitilの陰に隠れている
フィールドレベルACLの書き込み権限は、itil と task_editor の2つのロールに割り当てられていました。
task_editor（Can edit protected task fields）は、project_user（PPM）や data_manager_admin（CMDBデータ管理）など、itilを持たない5つの非ITSMロールに内包されています。itilという名前がITSM専用に見えるため、非ITSM側のモジュールは自分たちのロールにtask_editorを組み込むことで、taskの保護フィールドを編集できるようにしていました。
PPM・GRC側の担当者から「保護されたtaskフィールドが編集できない」と相談されたら、モジュール固有ロールがtask_editorを含むかを確認します（判断基準はitilの有無ではありません）。
実務で順番に検討する箇所
taskを土台に新しい業務テーブルを検討するとき、確認する順序を決めておくと迷いません。
既存63テーブルの重複確認：資産管理・PPM・GRCの既存task継承テーブルで代替できないか、新しいテーブルを作る前に確認する
辞書上書きの範囲：state・priorityをどこまで独自化するかを、子テーブル設計の最初の段階で決める
ACLの追加方針：task直接のACLは4件のみ。read/write/createは子テーブル側で個別に設計する前提で進める
itil / task_editorの使い分け：ITSM系にはitilを、非ITSM系には自モジュール固有ロールにtask_editorを内包させる
BR・UIポリシーの重複回避：TaskStateUtilが処理する状態遷移を、子テーブル側で再実装しない
参照テーブルの命名：task_ という接頭辞は継承と紛らわしい。新規に参照テーブルを作る際はsuper_classを明示的に確認する
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
super_class：テーブル継承における親テーブルの参照。空なら継承元を持たない最上位を意味する
ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則
検証範囲とおことわり
検証環境：Australia PDI / OOTB / 2026-09-01 確認
件数はすべてOOTBの設定・定義の数です。本番環境やカスタマイズ済み環境では異なります
各ビジネスルール・UIアクションの処理内容の詳細までは追っていません
63テーブルの9分類はこの記事のための独自区分で、ServiceNow公式の分類ではありません
業務レコードの分布（どのsys_class_nameに何件あるか）はデモデータ固有のため、参考情報として扱っています
承認（sysapproval）・Visual Task Boardとの連携の詳細はこの記事の範囲外です
付録：自分の環境で確認するときのURL
テーブル定義：/sys_db_object_list.do?sysparm_query=name=task
直接継承する子テーブル：/sys_db_object_list.do?sysparm_query=super_class.name=task^ORDERBYname
フィールド定義：/sys_dictionary_list.do?sysparm_query=name=task^elementISNOTEMPTY
状態の選択肢：/sys_choice_list.do?sysparm_query=name=task^element=state^language=en
ビジネスルール：/sys_script_list.do?sysparm_query=collection=task
ACL（テーブルレベル）：/sys_security_acl_list.do?sysparm_query=name=task
ロール：/sys_user_role_list.do?sysparm_query=nameINtask_editor,itil
taskで始まる周辺テーブル：/sys_db_object_list.do?sysparm_query=nameSTARTSWITHtask_^ORDERBYname
taskをグループ集計で見る：/task_list.do?sysparm_query=GROUPBYsys_class_name
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=task^hintISNOTEMPTY
ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameINtask_editor,itil
関連記事
taskテーブル：ITSM全プロセスの共通の親 … Zurich時点の旧調査。継承数・件数の初出記事
インシデント管理モジュールの概要 … taskを継承する個別プロセスの実例
作業時間明細（task_time_worked）は継承でなく参照 … task_*系テーブルの位置づけ
