Catalog Task はどこから来るか（履行計画）

Service Catalog で品目を申請すると、Requested Item（RITM）の下に作業用の Catalog Task（SCTASK）ができます。この「作業がどこからどんな順番で出てくるか」を決めているのが履行計画（Execution Plan）です。PDI（Zurich / OOTB）の Parcel Delivery Plan を見ると、Prepare parcel → Post parcel → Confirm receipt の3つのタスク雛形が order 100 / 200 / 300 で並んでいました。申請後はこの雛形をもとに sc_task が作られます。

この記事は、Request / RITM / Catalog Task の3階層は知っているが、Catalog Task が「誰がいつ作っているのか」をテーブルで確かめたい管理者・開発者に向けています。履行計画の本体（sc_cat_item_delivery_plan）、計画上のタスク雛形（sc_cat_item_delivery_task）、生成される実レコード（sc_task）の3つを、PDI 実測で順に確認します。

この記事で分かること

• 品目に1つ割り当てる履行計画（Execution Plan）の正体が sc_cat_item_delivery_plan テーブルだということ

• 計画上のタスク雛形（sc_cat_item_delivery_task）が order と所要時間と履行グループを持つこと

• 雛形（設定テーブル）と生成される sc_task（作業テーブル）で継承元が違うこと

• 履行計画が sc_task 以外（change_task）も生成先にできること

• PDI Zurich OOTB の active な計画3件と、その中身

• 実機で確認するときに開く一覧URL

履行計画（Execution Plan）とは

履行計画は、品目を申請されたときに「どんな作業を、どの順番で、どのグループに出すか」をあらかじめ決めておく段取りの雛形です。ServiceNow の画面では Execution Plan、テーブル名は sc_cat_item_delivery_plan、内部では delivery plan とも呼ばれます。

品目（Catalog Item）側には delivery_plan という参照フィールドがあり、ラベルは「Execution Plan」です。1つの品目に履行計画を1つ割り当てておくと、その品目が申請されたときに、計画に従って作業タスクが生成されます。PDI Zurich の OOTB では sc_cat_item が196件あり、そのうち64件に delivery_plan が設定されていました。残り132件は delivery_plan が空で、Flow Designer など履行計画以外の手段で作業を生成していると考えられます（推測）。品目ごとにどちらの手段を使っているかは、この delivery_plan が空かどうかで見分けがつきます。

公式の Service catalog execution plans（Zurich） に、履行計画が品目の納品・履行をどう定義するかが説明されています。

履行計画は雛形・Catalog Task は実レコード

履行計画まわりは3つのテーブルでできています。役割が紛らわしいので、まず立ち位置を分けます。

• Execution Plan（sc_cat_item_delivery_plan）… 履行計画の本体。合計所要時間や生成先テーブルを持ちます。

• Plan Task（sc_cat_item_delivery_task）… 計画上のタスク雛形。1つの計画に複数ぶら下がり、実行順（order）と所要時間（delivery_time）と履行グループ（group）を持ちます。

• Catalog Task（sc_task）… 申請後に実際に作られる作業レコード。番号は SCTASK で、担当者が処理する単位です。

役割を表にすると次のとおりです。

この3つで紛らわしいのは、Plan Task（雛形）と Catalog Task（実レコード）が別テーブルだという点です。設定として並べる雛形が sc_cat_item_delivery_task、申請のたびに作られる実物が sc_task です。

公式の Execution plan tasks（Zurich） に、計画に紐づくタスク雛形（実行順・所要時間・グループ・条件）の定義方法が説明されています。

雛形と実レコードで継承元が違う

3テーブルの継承元を調べると、雛形と実レコードできれいに分かれていました。今回確認した PDI（Zurich / OOTB）では、Execution Plan と Plan Task は Application File を継承し、sc_task だけが Task を継承していました。

なぜこう分かれるかというと、履行計画と計画タスクは「設定（メタデータ）」だからです。Application File 系のテーブルは更新セットで移送される設定であり、開発環境で作った計画を本番へ運べます。一方 sc_task は申請ごとに増える運用データなので、番号・State・優先度・担当を持つ Task を継承しています。

固有フィールド数は、Execution Plan が12、Plan Task が14、sc_task が6でした（sc_task はこれに task 継承の70が加わります）。

テーブルの定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sc_cat_item_delivery_task^elementISNOTEMPTY

履行計画フォームの中身（Parcel Delivery Plan）

履行計画のフォームを開くと、計画本体の設定と、その下にぶら下がる Plan Task の一覧が見えます。PDI Zurich OOTB の Parcel Delivery Plan を例にとります。

計画本体は Total delivery time に「4 Days」、Task table に「Catalog Task [sc_task]」を持っていました。Task table は生成先テーブルの指定で、ここが sc_task なら申請後に Catalog Task が作られます。

配下の Execution Plan Tasks には Prepare parcel（order 100）、Post parcel（order 200）、Confirm receipt（order 300）の3件が並び、それぞれ Delivery time（4 Hours / 1 Day / 3 Days）を持っていました。order が実行順で、小さい番号から処理されます。

https://<YourInstance>/sc_cat_item_delivery_plan_list.do?sysparm_query=active=true^ORDERBYname

計画タスク（Plan Task）が持つフィールド

Plan Task は、生成される sc_task の中身を前もって決めるためのフィールドを持っています。実行順・所要時間・履行グループが中心です。

PDI Zurich OOTB の Plan Task は53件あり、そのうち44件で group（履行グループ）が設定され、assigned_to（個人）は0件でした。OOTB は個人ではなくグループに作業を振り分ける作りになっています。なぜグループ中心かというと、申請を受けた時点では誰が空いているか決まらないため、いったんグループのキューに入れて担当者が引き取る運用に向くからです。

生成後の sc_task に引き継がれるフィールド

Plan Task には instructions（作業手順）・work_notes（作業メモ）・short_description（概要）のように、生成される sc_task へそのまま転記されるフィールドもあります。sla という参照フィールドも持っており、計画タスクの段階で SLA 契約をあらかじめ割り当てておける作りです。申請前に決めておける情報は、Plan Task 側にまとめて持たせておく設計だと分かります。

order の進み方を Parcel Delivery Plan で図にすると、次のとおりです。

condition / condition_script を持つ Plan Task もあり（OOTB では2件）、条件に合うときだけタスクを作る制御ができます。ただし生成時の内部ロジックは検証範囲外です。

生成された Catalog Task は RITM に紐づく

履行計画はあくまで雛形です。申請が入ると、計画に従って sc_task が作られ、申請された品目（RITM）に紐づきます。PDI Zurich OOTB には Catalog Task が1件（TASK0000001）あり、これを開くと親 RITM が見えました。

このフォームでは Request item が RITM0000001、State が Open、Short description が「Order from vendor or move from in-stock inventory」でした。sc_task の固有フィールドは6つで、うち参照は request_item（→sc_req_item）、request（→sc_request）、cat_item（→sc_cat_item）、sc_catalog の4つです。生成された作業がどの申請・どの品目のものかを、この参照でたどれます。

つまり履行計画（雛形）→ Plan Task（計画上の各作業）→ sc_task（実際の作業、RITM に紐づく）という流れで、申請が具体的な作業へ落ちていきます。

https://<YourInstance>/sc_task_list.do

品目から履行計画への入口

履行計画は品目に割り当てて初めて使われます。品目（sc_cat_item）の delivery_plan フィールド（ラベル「Execution Plan」）が、その入口です。

PDI Zurich OOTB の「Packaging and Shipping」品目を REST で確認すると、delivery_plan（Execution Plan）に Parcel Delivery Plan が設定されていました。品目フォームでは履行手段の指定は Process Engine タブにあります。この品目が申請されると、Parcel Delivery Plan の3つの Plan Task をもとに作業が生成される、という対応です。

履行計画は sc_task だけを生成先にするとは限りません。今回確認した active な計画3件のうち、Office Move は Task table が change_task でした。つまり履行計画は Catalog Task 以外の作業テーブルにもタスクを出せます。3件の内訳は、DEFAULT（合計2日・生成先 sc_task・Plan Task 2件）、Office Move（合計3日・生成先 change_task・Plan Task 5件）、Parcel Delivery Plan（合計4日・生成先 sc_task・Plan Task 3件）でした。Office Move が change_task を選んでいるのは、オフィス移転のような物理的な作業がすでに Change 管理のプロセスに組み込まれているからだと考えられます（推測）。

公式の Catalog Task（Zurich・ワークフローアクティビティ） に、ワークフロー側から Catalog Task を作る場合の設定が説明されています。履行計画とワークフロー（Flow）は、どちらも作業タスクを生む手段として併存します。

履行計画まわりの周辺設定

履行計画の動きは、計画とタスク雛形のフィールドだけでは終わりません。生成された sc_task 側に Business Rule や Notification がぶら下がっています。

範囲としては、計画・雛形側（設定テーブル）は Business Rule や Notification がほぼ無く、生成後の sc_task 側に Business Rule（13件）・Notification（4件）・UI Action（4件）が集まっていました。

設定の種類（物理テーブル）              紐づくテーブル             件数        ざっくりの役割
---------------------------------------------------------------------------------------------
Business Rules（sys_script）            sc_cat_item_delivery_plan  0           計画本体の保存時処理
Business Rules（sys_script）            sc_cat_item_delivery_task  1           計画タスクの保存時処理
Business Rules（sys_script）            sc_task                    13          生成後の作業の保存時処理
Notifications（sysevent_email_action）  sc_task                    4           作業に関するメール通知
UI Actions（sys_ui_action）             sc_task                    4           作業フォームのボタン
Access Controls（sys_security_acl）     3テーブル合計              12＋16＋22  各テーブルの権限

設定が sc_task 側に寄るのは、利用者への通知や担当者の操作が「実際の作業レコード」に対して起きるからです。雛形である計画・Plan Task は設定として静的なので、保存時ロジックや通知が少なくて済みます。一方 Access Control だけは計画12件・計画タスク16件・sc_task22件と、3テーブルのどこにも一定数設定されていました。閲覧・更新の権限は雛形テーブルにもきちんと及んでいる一方、Business Rule や Notification のような動的な処理だけが生成後の sc_task 側に集中する、という対比が見えます。

履行計画と Catalog Task のポイント

• 品目に1つ割り当てる履行計画の本体は Execution Plan（sc_cat_item_delivery_plan） で、合計所要時間と生成先テーブル（task_table）を持ちます。

• 計画上のタスク雛形は Plan Task（sc_cat_item_delivery_task） で、実行順（order）・所要時間（delivery_time）・履行グループ（group）を持ちます。OOTB はグループ割り当て中心で、個人割り当ては未設定でした。

• 雛形（Execution Plan / Plan Task）は Application File 継承の設定、生成される Catalog Task（sc_task）は Task 継承の作業で、継承元が分かれています。

• 履行計画は sc_task 以外（change_task など）も生成先にできます。今回の active 3件のうち Office Move は change_task でした。

• 生成された sc_task は request_item で RITM に紐づき、申請から作業までを参照でたどれます。

履行計画を調べるときは、品目の delivery_plan から計画を開き、計画フォーム下の Execution Plan Tasks（雛形）と、実際に生成された sc_task（RITM 配下）をセットで見ることで、「申請がどう作業になるか」が一本につながります。

実機を見て気づいたこと

• 履行計画は全部で15件登録されていましたが、active なのは3件だけでした。最初は登録されている履行計画はどれも使われているものだと思っていましたが、残り12件は無効化された定義で、実際の申請に出てくるのはごく一部でした。履行計画がうまく効かないと感じたら、まず active かどうかを疑うとよさそうです。

• Plan Task には条件で作業を絞る condition / condition_script だけでなく、生成ロジックそのものをカスタマイズできる generation_script というフィールドもあります。OOTB のどこかで使われているだろうと思って確認したところ、53件の Plan Task のうち generation_script を使っているものは1件もありませんでした。標準機能は condition 止まりで完結する設計のようです。カスタマイズの必要が生じたときに初めて使う、拡張用の逃げ道として用意されているフィールドだと理解しました。

次に読むなら

履行計画は、品目の履行手段の1つです。同じ役割を Flow Designer のワークフローが担うこともあり、新規の品目では Flow を使う設計も増えています。次に確認したいのは3点です。品目側で履行計画とワークフローのどちらが選ばれているか（Catalog Item の process engine の指定）。Plan Task の condition / generation_script が生成時にどう効くか。change_task を生成する計画がどう動くか。これらは本記事の「品目から履行計画への入口」で触れた delivery_plan と task_table の先にあたり、別記事で扱う予定です。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• Execution Plan（履行計画）：sc_cat_item_delivery_plan。品目の作業の段取り雛形

• Plan Task（計画タスク）：sc_cat_item_delivery_task。計画上の各作業の雛形

• Catalog Task（SCTASK）：sc_task。申請後に生成される実際の作業レコード

• task_table：履行計画が作業を生成する先のテーブル（sc_task / change_task など）

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

先頭に自分のインスタンスを付けると、同じ画面が開けます。

履行計画(active)   : sc_cat_item_delivery_plan_list.do?sysparm_query=active=true^ORDERBYname
計画タスク一覧     : sc_cat_item_delivery_task_list.do?sysparm_query=ORDERBYdelivery_plan^ORDERBYorder
計画タスク定義     : sys_dictionary_list.do?sysparm_query=name=sc_cat_item_delivery_task^elementISNOTEMPTY
Catalog Task一覧   : sc_task_list.do
品目(計画設定あり) : sc_cat_item_list.do?sysparm_query=delivery_planISNOTEMPTY

関連記事

• ServiceNow サービスカタログ完全ガイド：申請フォーム1つが履行タスクに届くまで — 申請フォームから履行タスクが生まれるまでの全体像はこちら。Execution Plan と Plan Task がその流れのどこに位置づくかが分かります。

検証範囲とおことわり

• 確認した範囲：3テーブルの継承元、固有フィールド数と型、Execution Plan の構成（task_table / total_delivery_time / order / delivery_time / group）、active な計画3件とその Plan Task、sc_cat_item.delivery_plan 参照、生成済み sc_task と RITM の紐づき、各テーブルの周辺設定件数。すべて PDI（Zurich / 2026-06-22 確認）の OOTB で取得しています。

• 確認していない範囲（断定しません）：申請から sc_task が生成される実行時の内部ロジック（どのトリガで何件作られるか）、condition / condition_script / generation_script の挙動、change_task を生成する計画の動作詳細、sc_task の State 遷移の具体値、履行計画と Flow Designer ワークフローの使い分け（品目の process engine 指定）。これらは別記事で扱います。