タスク管理モジュールの連携機能

Incidentで受け付けた依頼が、いつの間にか承認のワークフローや変更管理へ渡っています。フォーム上には相手のプロセスを指す項目が見当たらないのに、なぜつながるのでしょうか。taskは71項目の基底フィールドを提供するだけでなく、承認・SLA計測・影響CIの記録・親子関係という複数の経路を63の子テーブルへ共通に配っています。Australia のPDIを実機で開き、それぞれの経路がどのテーブルに・どれだけ使われているかを確認しました。

扱う連携

• 承認・SLA・CI・親子関係という経路が、それぞれどのテーブルに使われているか

• 同じ関係が複数の経路で二重に記録されている実例

• taskを継承した新しいテーブルを設計するとき、どの経路を使うかの判断材料

この記事で扱う内容

• sysapproval_approverが全プロセスの承認を1テーブルに集める仕組みと、sysapproval_groupという別経路

• task.parentという1項目が13テーブルの親子関係を横断的に表す仕組み

• task_ci・task_cmdb_ci_serviceの主な利用者が、Incidentではない実例

• Visual Task Board・作業時間・アクティビティ・添付が共通機構として引き継がれる範囲

• 3階層継承がPPM・GRCまで届く経路

task層がプロセス間をつなぐ経路を先に地図にする

taskは71項目のフィールドを子テーブルへ配る層であるとともに、承認・SLA・CI・親子関係という4つの経路を、参照テーブルまたは自己参照フィールドという形でtaskの外側に持っています。

経路ごとに保存場所と参照の向きが違います。整理すると次の表になります。

参照テーブル型（sysapproval_approver・task_sla・task_ci等）は、taskの外に別テーブルを作り、そこからtaskを指します。自己参照フィールド型（task.parent）は、task自身の列で完結します。どちらも子テーブル側は列を追加せずに済む点は共通です。実現方法が違うだけで、taskを共通の接続点にするという狙いは同じです。

承認はsysapproval_approverが全プロセスを1テーブルに集める

承認の記録は、Change・Catalog・改善提案といった複数プロセスにまたがります。理由は単純です。プロセスごとに承認テーブルを個別に持つと、承認の滞留状況を横断で追うレポートが作れません。

sysapproval_approverはこの問題を、taskへの汎用参照1つで解決しています。

sysapproval_approver.sysapprovalの公式説明を引用します。

（訳: 承認対象のドキュメントが入っているテーブル）

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

sysapproval列がtaskを参照するため、承認対象がChangeでもCatalog申請でも、同じsysapproval_approverに1行増えるだけです。本PDIには742件あります。内訳を見ると、偏りが大きいことが分かります。

change_requestが732件で全体の99%弱を占め、std_change_proposal・sc_request・sc_req_item・sn_cim_registerは合わせて7件です。参照先が解決できない孤立レコードも3件ありました。Changeの承認統計を出すとき、この孤立3件を分母に含めるかどうかで数値が変わります。集計前に除外条件を決めておきます。

参考：承認は1人1レコード（sysapproval_approver） … 1人1レコードになる構造そのものの解説

参考：承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか … 経路と滞留の追い方

グループ承認はsysapproval_groupという別の経路を使う

taskを直接継承する63テーブルの中に、sysapproval_groupという承認専用のテーブルがあります。個別承認者の記録であるsysapproval_approverとは別の経路です。

違いは明確です。sysapproval_groupはtask固有の71項目に加えて、approval_user・wait_for・reject_handling・admin_overrideという4項目を持ちます。複数人へまとめて承認を依頼し、全員の合意を待つか誰か1人の判断で進めるかをwait_forで切り替える構造です。

本PDIには127件あり、全件がtask.parentで特定のChangeを指していました（詳細は次のセクションで扱います）。sysapproval_approverの参照先（前セクション）にsysapproval_groupは現れないため、本PDIでは個別承認者の記録がsysapproval_group経由の入れ子にはならず、change_requestへ直接付く構成になっています。

承認を新しいtask継承テーブルに載せるときは、個別承認者を1人1行で記録するsysapproval_approver側に乗せるか、複数人をまとめて扱うsysapproval_groupを使うかの判断が要ります。1段階の可否判定だけで足りるなら、task.approvalの4値（未依頼・依頼中・承認・却下）だけで済ませる選択肢もあります。

参考：グループ承認：N人を1つに束ねる仕組み（sysapproval_group） … wait_forの動きを含めた詳細

SLA計測はtask_slaが同じ参照方式で一元化する

SLAの残り時間を表示するtask_slaも、super_classが空でtaskの子テーブルではなく、taskを参照する参照テーブル型の経路です。1タスクに複数のSLAが並走する構造や、SLA定義（contract_sla）が個々のプロセス側で持たれる仕組みは、既刊の2件で扱っています。本記事では新しい実測を行わず、接続点であることだけを確認します。

参考：task_sla：1タスク1本のSLA時計の読み方 … 計測側のテーブル構造

参考：SLA Definition（contract_sla）とは：時計を生むルール … 時計を生む条件設定

影響CI・サービスはtask_ci／task_cmdb_ci_serviceに集まる

障害や変更が影響するCIを記録するtask_ciも、参照テーブル型です。Incidentの「影響CI」関連リストとして使われる場面を思い浮かべる担当者が多いはずですが、本PDIで内訳を見ると想定と違う結果になりました。

task_ciは1,013件あり、内訳はcert_follow_on_task 944件・change_request 66件・problem 2件です。Incidentは1件もありません。

cert_follow_on_taskの正体を辞書で確認すると、理由が分かります。

（訳: 監査で見つかった不一致から生成されるタスク）

（訳: 監査結果に記載された不一致を修正するために更新すべき構成アイテム）

引用元: /sys_documentation_list.do?sysparm_query=name=cert_follow_on_task

cert_follow_on_taskはCMDBデータ認証（cert_audit）が生成する是正タスクで、そのcmdb_ciは「直すべきCI」を指します。task_ciの主な利用者は、Incidentの影響範囲記録ではなく、CMDB認証の是正対象という別の用途でした。影響範囲の調査でtask_ciをそのまま集計すると、CMDB認証タスクが数値の大半を占め、実際のインシデント対応での利用実態を見誤ります。集計するときはsys_class_nameで絞り込みます。

task_cmdb_ci_service（影響サービス）は4件のみで、全件がincidentでした。CIと違い、サービス単位の関連付けは今のところIncidentだけが使っている状態です。

参考：CMDBデータ認証（cert_audit）：あるべき状態から外れたCIに、タスクを配る … cert_follow_on_taskを生む側の仕組み

親子関係はtask.parentという1項目がプロセスを横断する

task固有の71項目には、task自身を参照する自己参照フィールドが3つあります。役割は様々です。そのうちparentが、13テーブルの実際の親子関係を担っています。

本PDIでparentを持つレコードは1,472件です。

pm_project_task（1,231件）とsysapproval_group（127件、前セクション参照）が大半を占めます。続くのはsn_cim_task（74件）・issue（10件）・dmn_decision（6件）です。issueのparentを実際に開くと、8件がProject（PRJ）を、2件がDemand（DMND）を指していました。1つの汎用フィールドが、プロジェクトの子課題も需要の子課題も同じ形で表現しています。

incidentは0件でした。Incident同士の親子関係には、parentではなく専用のparent_incidentが使われています。

taskを継承した新しいテーブルで親子関係を作るときは、専用の参照フィールドを新設するか、parentを再利用するかを決めます。関係の種類が1つだけで、レポートをparent条件で素直に書きたいなら再利用が近道です。関係の種類を複数持たせたい、あるいは既存のparent利用と用途が混ざると困る場合は、専用フィールドを検討します。

Problem⇄Changeの関係は2つの独立した経路で二重に記録されている

parentの内訳を1件ずつ確認していく過程で、見落としやすい重複に気づきました。change_requestのparentがproblemを指す例が2件あります。

このChangeとProblemの組を、Problem側から見るとどうなるでしょうか。Problemにはrfcという専用の参照フィールドがあり、同じ組がここにも記録されていました。

2つの画面は同じChange・Problemの組を指しています。片方はProblem専用のrfc列、もう片方はtask共通の自己参照parent列です。

同じ関係が独立した2つの列に記録される形は、片方だけを更新すればもう片方とずれる余地を残します。関係を集計するツールを自作するときに見落としやすいのは、rfcとparentのどちらか一方だけを条件にする書き方です。両方を確認する運用にするか、正本を1列に決めて他方は使わない運用にするか、テーブル設計の段階で選ぶ判断が実務的です。

Visual Task Boardは既存タスクをカード化するもう1つの経路

Visual Task Boardも、taskを土台にした連携経路の1つです。vtb_taskという専用のカードテーブルを使う方式と、vtb_boardのtable列に既存のtask系テーブル名を指定して、そのテーブルをそのままカード化する方式の2種類があります。

vtb_task（Private Task）がtask固有71項目に追加する独自フィールドは、担当者を指すowner（参照型）のたった1項目です。ボードの定義を持つのはvtb_boardという別テーブルで、taskの子ではなくtable列に任意のtask系テーブル名を指定する汎用の構成テーブルです。

本PDIではvtb_taskが0件、vtb_boardが1件で、そのtable列にはvtb_taskではなくupgrade_history_taskが入っていました。名前は「Australia Patch 3」で、レーンにstate、スイムレーンにpriorityを使い、特定のメジャーアップグレード実行に絞り込むfilterが設定されています。プラットフォーム自身が、メジャーアップグレードの進捗をこの仕組みで1枚のボードに追いかけている実例です。vtb_taskはVTBが使える対象の1つにすぎず、vtb_boardが指せる先はtaskの子テーブルであれば何でもよいという、汎用の作りが実例からも読み取れます。

作業時間・アクティビティ・添付も共通機構として引き継がれる

承認・SLA・CIほど目立ちませんが、作業の記録に関わる3つの機構もtask層から配られています。

作業時間はtask_time_workedが担います。taskの子ではなく参照テーブルで、1件のタスクに複数の作業時間明細が積み上がる構造です。本PDIには8件ありました。詳しい構造は既刊記事に委譲します。

アクティビティは、taskのcomments_and_work_notesフィールドが担います。comments（顧客と共有される追記）とwork_notes（内部向けの作業メモ）を1つの表示にまとめた journal_list 型のフィールドで、71項目の1つです。63の子テーブルすべてが、この1つのフィールド定義をそのまま使う形でアクティビティの表示形式を揃えています。

添付にも共通処理があります。Copy Attachment - new TaskというBusiness Ruleは、before_display・条件current.isNewRecord()で動きます。Interaction（電話やチャットの問い合わせ記録）からの添付ファイルを、新しく作られたtask系レコードへInteractionRelationshipUtil().copyAttachments()でコピーする処理です。問い合わせの最中に受け取った画像やログが、そこから起票したIncidentやCatalog Taskへそのまま引き継がれる仕組みです。

参考：作業時間明細（task_time_worked）は継承でなく参照 … 作業時間側の構造

3階層継承の先にあるPPM・GRCへも同じ経路が伸びる

taskを直接継承するテーブルの中には、planned_taskという中間クラスがあります。ここから先はさらにもう1段継承が伸び、14クラス・合計1,461件がぶら下がっています。

最大はpm_project_taskの1,231件で、次に多いのがsn_cim_task 74件・pm_project 67件です。残りはsn_vdr_risk_asmt_assessment 36件・sn_cim_register 32件・pm_program 7件です。sn_grc_issue 8件・dmn_decision 6件と続き、他の6クラスは0件でした。ここまで見てきた承認・CI・親子関係の経路は、この2階層下のテーブルにも同じ形で届きます。sn_cim_task（74件）のparentがsn_cim_registerを指す構成（前セクション参照）は、その具体例です。

taskを継承する新しいテーブルをPPMやGRCの配下に作る場合、planned_taskを経由するかどうかで、継承する項目の量が変わります。planned_task固有の項目が必要かどうかを先に確認します。

参考：PPMは他モジュールとどうつながる？ プロジェクトを起点にした連携 … PPM側から見た連携の実例

連携の設計で決めること

ここまでの経路を、新しいtask継承テーブルを設計するときの判断としてまとめました。基準は単純です。

承認は、複数人の順次承認が必要ならsysapproval_approverの汎用フローに、1段階の可否判定だけならtask.approvalの4値に乗せます。SLAの要否は、期限に業務上の意味があるかどうかが判断基準です。CIとの関連は、構成アイテムに紐づく業務かどうかで判断します。親子関係は、関係の種類が1つならparentの再利用、複数併存させたいなら専用フィールドの新設です。VTBは、既存タスクを可視化したいだけならvtb_boardへの登録、専用の非公式タスクが欲しいならvtb_taskです。

実機で気づいたこと

同じProblem-Change関係が2つの独立したフィールドに記録されている

parentの内訳を確認する過程で、change_requestのparentがproblemを指す組を見つけました。同じ組をproblem.rfc側から見ても、同じChangeが記録されています。sys_id単位で突き合わせても矛盾なく一致していました。

1つの関係が2つの独立した列に記録される設計は、更新のタイミングがずれると片方だけが古い値のまま残る余地を作ります。関係の集計や監査を自作するときは、rfcとparentの両方を確認するか、正本をどちらか1列に決めて運用します。

task_ciの主な利用者はIncidentではなくCMDB認証の是正タスク

task_ci（影響CI）の内訳を最初に見たとき、Incidentが上位に来ると想定していました。実際は944件がcert_follow_on_task、66件がchange_request、Incidentは0件でした。

cert_follow_on_taskはCMDBデータ認証が生成する是正タスクで、cmdb_ciは「直すべきCI」を意味します。障害対応の影響CIとは別の目的で、同じtask_ciが使われているという実態です。影響範囲を調査するときは、sys_class_nameで対象を絞り込んでから件数を読みます。

基底クラス経由の集計とテーブル直接集計で件数が食い違う場合がある

planned_task系14クラスの件数を確認する作業で、taskテーブル経由にsys_class_name=sn_grc_issueを指定すると0件が返りました。ところがsn_grc_issueテーブルを直接集計すると8件が返ります。

基底クラス経由のクエリだけで「0件」と判断すると、GRCのようなスコープアプリのデータを見落とします。件数がゼロに見えて疑わしいときは、対象テーブルを直接集計して裏取りします。

連携を調べるときに確認する場所

新しいtask継承テーブルを既存プロセスとつなぐとき、確認する場所は経路ごとに分かれています。

1. 承認が要るか：sysapproval_approverに乗せるかtask.approvalだけで済ませるかを最初に決める

2. SLAを計測するか：業務上の期限があるなら、そのテーブル用のcontract_slaを新規作成する

3. CIとの関連を持たせるか：構成アイテムに紐づく業務ならtask_ci等の関連リストを有効化する

4. 親子関係をどう表すか：関係が1種類ならparentを再利用し、複数種類なら専用フィールドを検討する

5. VTBに載せるか：既存タスクの可視化ならvtb_boardへの登録で足りる

この順で確認すると、taskが用意している経路をひととおり検討してから、専用フィールドの新設に進めます。専用フィールドは、既存の経路で表現できないことを確認したあとの選択肢です。

用語

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

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

• cert_audit：CMDBデータ認証機能が持つ、監査結果を記録するテーブル

• task_editor：「保護されたtaskフィールドを編集できる」という単一機能のロール（本記事では未使用、詳細は既刊のロール巻）

• wait_for：sysapproval_groupが持つ項目。複数人の承認を全員待つか1人で進めるかを切り替える

検証範囲とおことわり

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

• 件数はすべてOOTBの定義とデモデータに基づきます。本番環境やカスタマイズ済み環境では異なります

• task_slaとVisual Task Boardの詳細な項目・実測値は、既刊各巻で確定した数値を引用しています。本記事での再測定は行っていません

• sysapproval_approverの個々のレコードがどの承認エンジン（Workflow / Flow Designer）から生成されたかは追跡していません

• task_rel_task（Task Relationship）による任意タスク間の関連づけも、taskを土台にした経路の1つですが、詳細はインシデント管理シリーズの連携巻に委譲し、本記事では扱いません

• Visual Task Boardを実際に操作してカードを追加する検証は行っていません

• 新しいtask継承テーブルを実際に作成し、承認・SLA・CIの各連携を設定して動作確認する検証は行っていません

• 気づき3で触れたGRCスコープのACL・ドメインの挙動について、原因の特定までは行っていません

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

• sysapproval_approverの参照フィールド：/sys_dictionary_list.do?sysparm_query=name=sysapproval_approver^element=sysapproval

• 承認先の内訳：/sysapproval_approver_list.do?sysparm_query=GROUPBYsysapproval.sys_class_name

• task.parentのフィールド定義：/sys_dictionary_list.do?sysparm_query=name=task^element=parent

• incident.parent_incidentのフィールド定義：/sys_dictionary_list.do?sysparm_query=name=incident^element=parent_incident

• task_ciの参照先内訳：/task_ci_list.do?sysparm_query=GROUPBYtask.sys_class_name

• task_cmdb_ci_serviceのフィールド定義：/sys_dictionary_list.do?sysparm_query=name=task_cmdb_ci_service^elementISNOTEMPTY

• Visual Task Boardの定義：/vtb_board_list.do

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

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

• sysapproval_approverの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=sysapproval_approver^hintISNOTEMPTY

• cert_follow_on_taskの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=cert_follow_on_task

関連記事

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

• 承認は1人1レコード（sysapproval_approver） … 承認経路そのものの解説

• CMDBデータ認証（cert_audit）：あるべき状態から外れたCIに、タスクを配る … task_ciの主な利用者を生む側の仕組み