サービスカタログの基本設定

カタログアイテムを新しく登録しても、そのままでは承認や履行タスクへ何も進まないことがあります。ServiceNowには申請を自動で動かす仕組みが標準で2つ用意されていますが、どちらの設定も入れないまま公開できてしまうためです。Australia の PDI をデフォルト設定のまま開き、カタログ構造・履行エンジンの設定状況・変数の入力制御・通知・SLAの初期状態を確かめました。

この巻で棚卸しする設定

• カタログ・カテゴリ・カタログアイテムの構成

• 履行エンジン（Workflow / Flow Designer）の設定状況

• 変数の入力制御とRecord Producer・Order Guide

• 通知の初期設定

• SLA・優先度の初期状態

導入前に知っておくこと

• カタログはTechnical CatalogとService Catalogの2つ、カテゴリは47件（active 34件）、カタログアイテムは204件（active 152件）で構成される

• 履行エンジンはWorkflowとFlow Designerが並存し、どちらも未設定のアイテムが85件（41.7%）ある

• 変数側の入力制御はcatalog_ui_policyとcatalog_script_clientに集中し、Request本体のUIポリシー・データポリシーは0件

• 通知は31件のうち11件がApp Engine Studioのアプリ申請（App Intake）と共用されている

カタログ構造の全体像

サービスカタログの構造は3階層です。カタログがカテゴリを持ち、カテゴリがカタログアイテムを持ちます。

テーブル件数activesc_catalog（カタログ本体）22sc_category（カテゴリ）4734sc_cat_item（カタログアイテム）204152

カタログ本体は2つだけでした。Technical CatalogとService Catalogです。両方ともactiveでした。マルチカタログの仕組みそのものは用意されていますが、実際に使われているのは最小限だと分かります。複数事業部で画面を分けたい場合は、カタログを増やすところから設計に入ります。

カテゴリは47件のうち34件がactiveでした。残り13件は無効のまま残っています。棚卸しをするなら、この13件を削除するか、使う予定があるのかをまず判断します。

sc_cat_item のクラス分布

カタログアイテムは単一の型で統一されておらず、204件を sys_class_name で分けると9種類のクラスに分かれました。

通常の Catalog Item（97件）が半数近くを占めます。Hardware Asset Management連携（41件）とSoftware Asset Management連携（13件）を合わせた54件は、資産管理向けの専用クラスです。Record Producer系も、通常アイテムとは別クラスとして数えられています。内訳はRecord Producer 30件・Composite Record Producer 10件・Standard Change Template 6つで、合計46件です。残る2クラスは件数がごく少なく、Content Item（案内・リンク等）が4つ、Wizard Launcher（ウィザード型項目）が1つでした。

カタログアイテムは「サービスを注文する画面」に加えて、ハードウェア・ソフトウェアのライフサイクル起票や、標準変更の申請という役割も同じテーブルの上で兼ねています。新規アイテムを作るときに最初に決めるのは、どのクラスで作るかです。通常のCatalog Itemで作るべきものをRecord Producerで作ると、変数の扱いや画面遷移が変わってしまいます。

履行エンジンの設定分布

カタログアイテムが注文されたあと、承認やタスク生成を自動で動かす仕組みが履行エンジンです。ServiceNowにはこのエンジンが旧来のWorkflowと後発のFlow Designerの2つあり、カタログアイテムごとにどちらを使うかを個別に設定します。組み合わせは4パターンに分かれます。

Flow Designerのみ

後発の履行エンジンだけを設定した組み合わせです。sc_req_itemのafter Business Rule「Start FlowDesigner Flow」（order -1,000）が起動します。このBusiness Ruleがsn_flow_trigger.FlowTriggerAPI.fireCatalogTriggerを呼び、Flow Designer側のフローを起動します。204件のうち59件がこの設定で、新規のカタログアイテムに推奨される組み合わせです。起動経路の詳細は次の節で扱います。

Workflowのみ

旧来の履行エンジンだけを設定した組み合わせです。before Business Rule「Start Workflow」（order 10,000）が起動し、Workflow()でwf_workflowを開始します。204件のうち55件がこの設定です。

両方設定

移行の途中と見られる組み合わせで、204件のうち5件です。

Business Rule側では「Start FlowDesigner Flow」が先に評価され、「Start Workflow」はそのあとに実行される順序で登録されています。両方が設定されたアイテムでも、実際に動くのはFlow Designer側です。新規のカタログアイテムはFlow Designerだけを設定する方針にすると、この重複を避けられます。

どちらも未設定

204件のうち85件（41.7%）が該当し、4パターンの中で最多です。

承認やタスク生成のロジックを何も設定しなければ、アイテムは公開できても履行の自動化は一切動きません。新規にカタログアイテムを作る担当者にとって、この85件は重要な事実です。棚卸しをするなら、この85件が意図的に手動運用のままなのか、設定を入れ忘れているだけなのかを1件ずつ確認します。

• 参考：レガシーWorkflow（wf_workflow）とFlowの違い … 2つのエンジンの実装差

履行を起動するFlow

Flow Designerが動く経路も見ておきます。sc_req_item のBusiness Ruleがどちらのエンジンで動いているかは、レコード画面のボタンで判別できます。

「Flow Context」ボタンはカタログアイテムに flow_designer_flow が入っているときだけ表示され、「Show Workflow」ボタンは workflow が入っているときだけ表示されます。担当者はレコードを開いた瞬間、ボタンの出方だけでどちらのエンジンが設定されているかを判断できます。

起動される側のFlowも数えました。Flow Designer本体（sys_hub_flow）でカタログ関連の名前を持つものは9つ、うち公開されて有効なものは7つです。

ただし、注文のたびに直接呼び出されるトリガーを持つのは「Service Catalog item request」の2つだけでした。残りは、この2つから呼び出されるサブフローだと見られます。カタログアイテムに flow_designer_flow を設定するときに指す先は、この起点のFlowです。呼び出し関係を追うと、注文1件が承認までどう流れるかがつかめます。

同じ名前空間には「Service Catalog Request」と「Service Catalog Request Price Approval」という2つのFlowもありました。命名からは、金額のしきい値によって承認経路を分けるサブフローだと読み取れます。直接のトリガーを持たないため、起点のFlowから内部でどう呼ばれているかまでは今回の調査範囲では追っていません。

• 参考：Flow Designerの中身は3テーブル（sys_hub_flow） … トリガーとサブフローの構造

• 参考：承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） … 承認とタスク生成の内部構造

変数側の入力制御

sc_request ／ sc_req_item ／ sc_task の3テーブル本体には、フォーム制御の仕組みが実質存在しません。サーバ側のUIポリシー（sys_ui_policy）とデータポリシー（sys_data_policy2）は、3テーブルとも0件でした。

制御の主戦場は、カタログアイテムの変数（item_option_new、676件）に紐づく別系統の仕組みです。Catalog UI Policyが103件（active 101件）、Catalog Client Scriptが141件あります。

Catalog UI Policyには、どの画面に効かせるかを決める3つの項目があります。公式ヒントにこう書かれていました。

（訳: このUIポリシーが、カタログ項目の注文時に適用されることを示す）

applies_req_item はRequested Item（RITM）のタスク上、applies_sc_task はCatalog Task上に適用範囲を分けます。3つのチェックボックスの組み合わせで、同じ入力制御ルールを注文画面・RITM・Catalog Taskのどこまで効かせるかを決める仕組みです。

「申請フォームの入力項目がなぜこう動くのか分からない」というときに見る手順は、次のとおりです。カタログアイテムに紐づく変数を確認し、そこに紐づくCatalog UI Policy・Catalog Client Scriptの設定を見ます。制御の実体は sc_req_item 本体には無く、変数側に集まっています。

catalog_script_client（141件）はUIポリシーより細かい制御を担います。フィールドの値が変わったタイミングで、選択肢を絞り込んだり別の変数を自動入力したりするロジックが、この141件に収まっています。

• 参考：注文フォームの制御は通常フォームと別テーブル（catalog_ui_policy） … この仕組みの詳しい構造

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

申請の入口ごとの内訳

sc_cat_itemのクラス分布で見たRecord Producer系（46件）と、複数アイテムを束ねるOrder Guide（2件）を、履行エンジンの設定と合わせて確認します。

Record Producer

通常のカタログアイテムが sc_req_item を経由するのに対し、Record Producerはフォームの入力内容を任意のテーブル（Incident・Change・独自テーブルなど）へ直接書き込みます。「申請の結果をRITMで管理したいか、別の業務テーブルへ直接起票したいか」が、通常アイテムとRecord Producerを選ぶ最初の判断基準です。204件のうち46件がRecord Producer系のクラスです。

• 参考：Record Producer は RITM を作らない … Record Producerの動き方

Order Guide

複数のカタログアイテムを1回の申請にまとめる仕組みです。New Hireのように複数の準備物が同時に必要な業務と相性が良い設計です。

Order Guideは「Request Developer Project Equipment」と「New Hire」の2件で、どちらもactiveです。2件しかないという件数自体は、この機能を使うかどうかの判断がまだ限定的にしかされていないことを示しています。新しく業務プロセスを棚卸しするときは、複数アイテムをまとめて申請させたい場面がないかをOrder Guideの候補として洗い出します。

• 参考：複数アイテムを1申請に束ねる（オーダーガイド） … Order Guideの内部構造

通知の初期設定

メール通知（sysevent_email_action）は3テーブル合計31件でした。

内訳を見ると、sc_req_item の18件のうち11件は "App Intake Request..." という名前で、カタログの履行通知とは異なる由来を持ちます。App Engine Studioのアプリ開発申請が、同じ sc_req_item テーブルを申請の記録先として間借りしているためです。同じテーブルの共用です。カタログ本来の履行通知（Delivery・Completed・Commentedなど）は7つにとどまります。

導入時は、App Intake系の11件を除いた20件（sc_request 9つ・sc_req_item 7つ・sc_task 4つ）が、実際のサービスカタログ運用に関わる通知です。31件全体ではなく、この20件を対象に通知を見直します。

• 参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときの切り分け方

SLA・優先度の初期状態

期限（contract_sla）と優先度の自動計算（dl_definition）は、sc_request ／ sc_req_item ／ sc_task のいずれも0件でした。priority の既定値も、辞書上書きによって空欄に上書きされています。

仕組みIncident・ProblemRequest（3テーブル共通）SLA定義（contract_sla）定義あり0件優先度自動計算（dl_definition）Impact×Urgencyで算出0件priority の既定値4（初期値のまま）空欄に上書き

Requestは影響度・緊急度から優先度を自動算出する仕組みを持たず、SLAによる期限監視の対象にもなっていません。この事実の詳しい根拠は本シリーズ第1巻「概要」と第2巻「テーブル・フィールド構成」で扱っています。履行の遅延を検知する仕組みがOOTBには無いという点が、基本設定を棚卸しするときの前提です。滞留を監視したい場合は、sc_req_item.stage の滞在時間を独自にレポート化するなど、代わりの仕組みを自分で用意します。

設定変更を本番へ移す方法

ここまで見た設定のうち、どれが更新セット（Update Set）で運べるかはテーブルの性格で分かれます。

テーブルsuper_class更新セットで運べるかsc_catalog / sc_category / sc_cat_itemApplication File運べるitem_option_new（変数）/ catalog_ui_policyApplication File系運べるsc_request / sc_req_item / sc_taskTask運べない（業務データのため）

カタログ・カテゴリ・カタログアイテム・変数・UIポリシーは「Application File」という性質を持ち、更新セットに記録されて別環境へ運べます。一方で sc_request や sc_req_item は申請1件ごとの業務データであり、Incidentのレコードと同じように更新セットの対象にはなりません。検証環境で作ったテスト用の申請データは、本番へは運ばれないという前提で作業します。

• 参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 移送の仕組み

実機で気づいたこと

履行エンジンが無くても公開できてしまう

sc_cat_item の state フィールドはpublished・draft・publishing・in_review・reviewedの5値を持つ選択肢です。実際の204件を見ると、published は6件だけで、残り198件は空欄でした。ほとんど使われていません。

state を運用していないアイテムでも active=true にすれば注文画面に表示されます。公開ワークフローの値と、実際に見えるかどうかを決める active フラグが別々に機能しているためです。

履行エンジンが未設定の85件と同じ構図で、「設定していないから止まる」わけではなく「設定していなくても動いてしまう」点に注意が要ります。新規アイテムを棚卸しするときは、active と state と履行エンジンの3つを別々に確認します。

どのエンジンが動くかはボタンの出方で判別できる

sc_req_item のUI Actionを見ると、「Flow Context」と「Show Workflow」という、名前も条件も紐づくエンジンが違う2つのボタンが用意されています。

条件式を見ると、cat_item.flow_designer_flow が入っていれば前者が、cat_item.workflow が入っていれば後者が表示される作りでした。担当者向けの操作ボタンが、そのまま設定状態を可視化する役割を兼ねています。

トラブル対応でどちらのエンジンが動いているか調べるとき、カタログアイテムのレコードを開かなくても、RITMの画面に出ているボタンだけで一次判断ができます。ACLの許可条件は Flow Context 側に flow_operator ロールの制約があるため、ロールを持たない担当者には両方とも見えない場合がある点も合わせて確認します。

通知の6割がカタログ以外の用途で登録されている

sc_req_item の通知18件のうち11件が "App Intake Request..." という名前で、event_name はいずれも activate.life.cycle.migration でした。

App Engine Studioというアプリ開発支援機能が、独自の申請テーブルを新設するのではなく、既存の sc_req_item を「申請」の汎用テーブルとして再利用しているためです。ServiceNowのプラットフォーム機能同士が同じテーブルを共有する例のひとつです。

通知の棚卸しをするときは、テーブル名だけで一覧を眺めると数が多く見えます。event_name や通知名でApp Intake系を除外してから、カタログ運用に関わる通知だけを対象にします。

ニッチなクラスにも役割がある

204件のうち、Content Item（4つ）とWizard Launcher（1つ）は合わせても5つしかありません。一覧をざっと見ただけでは見落としやすい規模です。

Content Itemは注文を発生させず、案内や外部リンクを表示するためのクラスです。Wizard Launcherは複数ステップの入力画面をひとつのアイテムとしてまとめます。どちらも「注文する」以外の目的でカタログの中に置かれています。

カタログの棚卸しで204件を数えるとき、この2クラスを通常アイテムと同じ基準で評価すると数字がずれます。承認や履行の有無を問う前に、そもそも注文を伴うクラスかどうかを先に見分けます。

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

基本設定を決めるとき、次の順序で進めると手戻りが減ります。

1. カタログ構造：カタログ・カテゴリの数を自社の組織に合わせる。無効なカテゴリ13件を削除するか、再利用するかを決める

2. 履行エンジン：新規アイテムはFlow Designerだけを設定する方針にする。未設定の85件が手動運用の想定なのか、設定漏れなのかを1件ずつ判断する

3. 承認Flow：起点となる「Service Catalog item request」の承認条件を確認し、サブフロー側の分岐条件も合わせて把握する

4. 変数の入力制御：Catalog UI PolicyとCatalog Client Scriptの適用範囲（catalog / req_item / sc_task）を確認する

5. Record Producer・Order Guide：業務プロセスに合わせて追加候補を洗い出す。RITM経由か直接起票かをアイテムごとに決める

6. 通知：App Intake系を除いた実際の運用通知を対象にする。宛先とタイミングが自社の運用に合っているかを見る

7. SLA・優先度：期限監視の仕組みが無い前提で、必要な件は独自に設計する

用語

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

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

• Workflow：旧来の履行エンジン。wf_workflow テーブルで定義される

• Flow Designer：後発の履行エンジン。sys_hub_flow テーブルで定義される

• Application File：更新セットで移送される設定オブジェクトの分類。業務データとは区別される

検証範囲とおことわり

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

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

• Business Ruleの実行順序・order番号・スクリプトの中身は、本シリーズ第6巻「自動設定構成」で扱います

• 個々のプロパティの値と説明文は、本シリーズ第4巻「プロパティ」で扱います

• ロールごとのACL内訳は、本シリーズ第3巻「ロール」で扱います

• カタログ別（Technical Catalog / Service Catalog）のカタログアイテム分布は、集計値の信頼性が確認できなかったため本文には使用していません

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

• カタログ本体：/sc_catalog_list.do

• カテゴリ：/sc_category_list.do?sysparm_query=active=true

• カタログアイテムのクラス分布：/sc_cat_item_list.do?sysparm_query=GROUPBYsys_class_name

• 履行エンジン未設定：/sc_cat_item_list.do?sysparm_query=workflowISEMPTY^flow_designer_flowISEMPTY

• 履行エンジン両方設定：/sc_cat_item_list.do?sysparm_query=workflowISNOTEMPTY^flow_designer_flowISNOTEMPTY

• UI Action（履行エンジン可視化）：/sys_ui_action_list.do?sysparm_query=table=sc_req_item^active=true

• カタログ関連Flow：/sys_hub_flow_list.do?sysparm_query=nameLIKECatalog

• Catalog UI Policy：/catalog_ui_policy_list.do?sysparm_query=active=true

• Order Guide：/sc_cat_item_list.do?sysparm_query=sys_class_name=sc_cat_item_guide

• 通知：/sysevent_email_action_list.do?sysparm_query=collection=sc_req_item

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

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

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

関連記事

• 注文フォームの制御は通常フォームと別テーブル（catalog_ui_policy） … 変数側の入力制御の詳しい仕組み

• レガシーWorkflow（wf_workflow）とFlowの違い … 2つの履行エンジンの実装差

• 誰も頼んでいないカタログを洗い出す手順：死蔵率98.6%の実測 … 公開しても使われないアイテムの見つけ方