サービスカタログの概要

PCを1台用意してほしい。特定システムへのアクセス権が欲しい。こうした依頼は、内容も承認者もあらかじめ決まっています。ServiceNowのサービスカタログは、この「あらかじめ決まった依頼」を受け付け、承認を経て履行する仕組みです。カタログという商品棚から選んで注文する形を取り、止まった業務を戻すIncidentとは扱う対象が逆になります。Australia PDIをデフォルト設定のまま開き、テーブル・状態・カタログとの関係・裏で動く設定を確かめました。

この記事で分かること

• サービスカタログが担当する範囲と、Incidentとの役割の違い

• 申請1件がsc_request・sc_req_item・sc_taskという3テーブルにどう分かれるか

• 状態を表す3つの項目（request_state・state・stage）が指す中身の違い

• カタログ定義（sc_catalog・sc_category・sc_cat_item）と申請データ（sc_request・sc_req_item・sc_task）の2層関係

• OOTBで何件の設定がサービスカタログに紐づいて動いているか

先に押さえておくこと

• サービスカタログは、あらかじめ用意した選択肢から選んで申請する定型の依頼を扱う

• sc_request・sc_req_item・sc_taskはtaskを直接継承する兄弟テーブルで、入れ子ではない

• 状態を表す項目は3つあり、記録の粒度と語彙がそれぞれ異なる

サービスカタログの位置づけ

ServiceNowのITSMプロセスは、困りごとの性質で窓口を分けています。業務が止まっている場合はIncidentが担当し、原因の恒久対策が必要ならProblemへ引き継ぎます。あらかじめ用意された依頼は、この2つとは別枠でサービスカタログが受け持つ設計です。

申請する側が窓口に求めるものは決まっています。迷わず頼めること、承認が必要な依頼は止まること、そして進捗を後から追えることです。サービスカタログは、この3点を「あらかじめ並べた品目から選ぶ」という仕組みの上で実現します。

Incidentは自由記述で受け付け、担当者が内容を分類します。サービスカタログはその逆で、カタログという商品棚の中からアイテムを選ばせる形を取ります。入力の自由度を下げる代わりに、必要な項目を最初から埋めさせられる設計です。

この分担にも接点はあります。Incidentの対応中に正式な手続きが必要になれば、UI Actionから新しいRequestを起票できます。窓口は分かれていても、双方が独立して動いているわけではありません。

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

ServiceNowは製品の中にフィールドの説明文を同梱しています。sys_documentationのhintです。sc_request・sc_req_item・sc_taskを合わせると6件でした。

requested_for の公式説明を引用します。

（訳: 本人以外の代理として申請する場合の対象者）

これはsc_request.requested_forとsc_req_item.requested_forに共通する説明です。申請した人と、申請の対象になる人が違う場面を最初から想定した項目だと分かります。上司が部下の代わりに申請する運用は、標準機能の範囲です。

（訳: 希望する納品日）

sc_request.requested_dateの説明です。いつ欲しいかを申請者が指定できる項目だと公式が定義しています。

（訳: 利用者と共有される追記型の項目）

sc_task.commentsの説明です。履行担当者の追記が申請者にも見える前提で設計されています。作業側のやり取りをそのまま申請者への連絡に使える構造です。

引用元: /sys_documentation_list.do?sysparm_query=nameINsc_request,sc_req_item,sc_task^hintISNOTEMPTY

申請データの3テーブル構造

申請・承認・作業は、担当する人も完了するタイミングも異なります。申請者はフォームを送信すれば役目を終えますが、承認者は都度の判断が必要で、履行担当者は作業が終わるまで手を離せません。ServiceNowはこの3つの工程を1つのテーブルにまとめず、Request・RITM・Catalog Taskという別々のレコードに分けることで、それぞれの進み方を独立して追えるようにしています。

sys_db_objectを確認すると、sc_request・sc_req_item・sc_taskはいずれもtaskをsuper_classに持ちます。

3テーブルはtaskという共通の親を持つ兄弟です。sc_req_itemがsc_requestを継承しているわけではありません。担当者・状態・優先度といった共通項目は、親のtask側にまとめて定義されています。

親子の表現方法にも特徴があります。sc_taskは、親のRequestと直近の親のRITM、両方への参照フィールドを固有に持つテーブルです。加えてtask継承の汎用フィールドparentも、実際のカスケード処理で使われています。同じ親子関係を、request・request_item・parentという3つの経路で表現している点が特徴的です。RITM取消の処理はparentでsc_taskを検索し、RITM削除の処理はrequest_itemで検索するというように、OOB側のスクリプトも経路の使い方が処理ごとに違います。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … 親テーブル側の項目構成

カタログから履行タスクに届くまでの流れ

申請の入口はカタログの中に3種類あります。通常のカタログアイテム、RITMを作らないRecord Producer、複数アイテムをまとめるOrder Guideです。役割ごとに動きが異なるため、種類ごとに分けて確認します。

カタログアイテム

通常の入口です。利用者から見た操作は、カタログでアイテムを選び、フォームに入力して送信する1回だけです。裏側では、Requestと品目ごとのRequested Item（RITM）が同時に生成されます。承認はそのあとに動く仕組みです。REQ宛ての承認依頼は承認ルール（$1,000超で承認を必須にする等、有効4件）が作り、RITM宛ての承認依頼はRITM用のフローが作ります。2段階の承認を通過すると履行タスクが生成されます。承認の記録はsysapproval_approverという1つのテーブルへ集まる仕組みです。Changeなど他プロセスの承認も同じ場所に記録される共通の基盤で、カタログはその利用者の1つです。内訳は本シリーズ第8巻「連携機能」で扱います。実機の$1,100のノートPC注文1件でも、注文と同秒にREQとRITMが生まれ、承認2段階の通過後に履行タスクが生成されていました。

利用者側の画面で見ると、この入口は次のように動きます。Service Portalでカタログを開くと、パンくずが「Home ＞ Service Catalog ＞ Hardware」のように表示されます。ServiceNow自身がこの画面群を公式に「Service Catalog」と呼んでいる証拠です。

アイテムを開くと注文フォームが表示されます。数量・価格・納期がその場で分かり、Order Nowを押すと申請が生まれます。

承認で止まれば、履行タスクは1件も作られません。2段階のうち後段（部門長承認）まで通らないと履行は始まらないという点は、承認の運用を決めるときに押さえておく必要があります。

実物のレコードで見ても、流れは同じです。

申請した本人からは、同じRITMが管理画面の一覧ではなくService Portalの「My Request」画面に表示されます。

Stageに表示された「Order Fulfillment」は、後述する状態（stage）の実データ値の一例です。実行中のフローの工程名やワークフローのアクティビティ名がそのまま反映された値で、選択肢定義の既定値とは別物です。

sc_cat_item204件のうち、このクラス（通常のCatalog Item）は97件で最多です。カタログアイテムの作り方・変数の使い回し・2段階承認の内部構造は、それぞれ子記事で詳しく扱っています。

• 参考：承認は2段構え：1段目だけでは履行が始まらない … 承認の内部構造

Record Producer

RITMを作らない入口です。通常のカタログアイテムはsc_req_itemを経由しますが、Record Producerは経由しません。フォームの入力内容を、対象テーブル（Incident・Change・独自テーブルなど）へ直接1件書き込みます。標準変更カタログ（std_change_record_producer）のように、承認済みの変更をワンクリックで起票する場面で使われる入口です。

Record Producer系は3クラスに分かれます。sc_cat_item_producer30件・複合型のsc_cat_item_composite_producer10件があります。標準変更用のstd_change_record_producer6件を合わせると46件です。通常のカタログアイテム97件の半分近い規模があります。詳しい動きと通常アイテムとの違いは子記事で扱っています。

• 参考：Record Producer は RITM を作らない … 通常アイテムとの違い

Order Guide

複数のカタログアイテムを1回の申請にまとめる入口です。ガイド内で選んだ複数アイテムが、1件のRequestの下に複数のRITMとしてまとめて生成されます。新入社員向けの機材一式のように、複数の準備物が同時に必要な業務と相性が良い設計です。

sc_cat_item204件のうち、Order Guide（sc_cat_item_guide）は2件だけです。件数は少なくても、まとめ買いという固有の動きを持つため、通常のカタログアイテムとは別のクラスとして扱われています。詳しい内部構造は子記事で扱っています。

• 参考：複数アイテムを1申請に束ねる（オーダーガイド） … まとめ買いの仕組み

フィールド構成

sys_dictionaryを数えると、固有フィールドはsc_request9項目・sc_req_item16項目・sc_task5項目でした。

task継承の71項目と合わせると、3テーブルはそれぞれ80項目・87項目・76項目で構成されます。共通のtaskからimpact・urgency・priority・assigned_to・short_descriptionといった項目を受け取り、その上に少数の固有項目を足す作りです。

固有項目のうち、priorityの扱いには注意が必要です。sys_dictionary_overrideを見ると、sc_req_itemとsc_taskの両方でpriorityの既定値が空文字に上書きされていました。

taskが標準で持つ既定値「4」を、この2テーブルはあえて消しています。この事実は、後述するSLAと優先度の自動計算が0件という状態と符合します。サービスカタログは、影響度と緊急度から優先度を自動算出する設計を最初から持っていません。優先度を使う運用にするなら、品目ごとの個別ロジックか、申請時の入力項目として自前で用意する必要があります。

上書きの出どころにも特徴があります。sys_package名は「ITSM Roles - Request Management (do not activate, see plugin description)」でした。名前に「有効化するな」という注意書きを含みます。それでもこの上書き自体は、このPDIで実際に効いています。

状態（request_state・state・stage）

状態を表す項目は3つあり、値の語彙がそれぞれ異なります。sc_request固有のrequest_stateは文字列choiceで7値、sc_req_itemとsc_taskが共有するstateはtask基底の数値choiceで6値です。

3つ目のstageは事情が違います。internal_typeが「Workflow」という専用型で、sc_requestは7値・sc_req_itemは3値の既定choiceを持ちます。ところが実データを見ると、choice定義に無い値が普通に入っている点が特徴です。

「Dept. Head Approval」のような値は、選択肢のマスタには存在しません。stageは固定の選択肢ではなく、実行中のフローの工程名やワークフローのアクティビティ名がそのまま反映される特殊なフィールドです。choice定義の値は、フローもワークフローも動いていない場合の既定表示にすぎません。

この3系統を理解しておくと、集計やダッシュボードを作るときの選択を誤りません。申請単位の進捗を見たいならrequest_state、履行タスクの作業状況を見たいならstate、承認プロセスの現在地を見たいならstageというように、目的で使い分ける項目です。

カタログ定義と申請データの2層関係

申請データの3テーブル（sc_request・sc_req_item・sc_task）は業務データですが、カタログ側の3テーブルは性格が違います。sys_db_objectではsc_catalog・sc_category・sc_cat_itemのsuper_classが「Application File」でした。更新セットで移送する設定オブジェクトという扱いです。

規模を数えると、sc_catalog（カタログ本体）は2件、sc_category（カテゴリ）は47件（active34件）でした。sc_cat_item（カタログアイテム）は204件で、うちactiveは152件です。

カタログアイテムの入力項目はitem_option_new（変数）が担い、676件ありました。うち584件が、いずれかのカタログアイテムに直接紐づいています。カタログという商品棚と、その注文結果を記録する申請データ（Request・RITM・Catalog Task）は、参照関係で結ばれた別レイヤーです。sc_cat_item204件の内訳は、通常のカタログ項目97件・ハードウェア資産管理向け41件・Record Producer系46件・ソフトウェア資産管理向け13件などで構成されます。カタログという商品棚は、注文だけでなく資産管理の起点としても使われる作りです。カタログアイテムの中身の作り方は、本シリーズの子記事群で詳しく扱っています。

履行を自動で動かす仕組み

履行のきっかけとなる自動処理には、新旧2つの仕組みが併存します。旧来のWorkflowエンジンと、後発のFlow Designerです。どちらが動くかはカタログアイテムごとの設定で決まり、判断の仕方と設定方法は本シリーズ第6巻「自動設定構成」で扱います。

• 参考：レガシーWorkflow（wf_workflow）とFlowの違い … 2つのエンジンの見比べ方

申請データに紐づくOOTB設定

申請データの3テーブル（sc_request・sc_req_item・sc_task）は、その周りで動く設定の集まりで構成されます。紐づく設定を数えると、ACL106件・Business Rule43件・UI Action17件・通知31件でした。

カタログ側4テーブルを合わせるとACLは116件です。業務3テーブルの106件と合算した総合計は222件になります。このうちスクリプト条件（advanced ACL）を持つのは28件で、割合は約13%にとどまります。大半はロール割当が中心の設計です。

通知31件のうち、sc_req_item側の18件を見ると、13件（72%）が「App Intake Request…」という名前で、App Engine Studioのアプリ申請承認向けでした。カタログ本来の履行通知は5件にとどまります。

sc_req_itemは、Service Catalogの履行とApp Engine Studioのアプリ開発申請という2つの業務を兼務しているテーブルです。通知の一覧だけを見て「申請まわりの通知は多くて複雑」と判断すると、実際には別業務の通知を数えていることになります。

もう1つ、Incidentとの対比で目立つ数字があります。SLA定義（contract_sla）は3テーブルとも0件でした。

Incident管理には対顧客・社内グループ間・ベンダー契約という3種類のSLAが13件用意されているのに対し、サービスカタログはOOBのSLA監視対象を持ちません。期限を管理したい場合は、自社でSLA定義を作る必要があります。

ロールと権限

誰が何を操作できるかは、ロールとACLの2段で決まります。カタログ系ロールは12件、リクエスト管理系ロールは4件で、合わせて16件でした。

標準のitilロールはsn_request_write（→sn_request_readも含む）を自動的に継承します。担当者がitilロールを持っていれば、申請の承認や履行は追加設定なしで行えます。一方でカタログの基本ロールcatalogは、itilには含まれません。カタログを閲覧・利用する範囲を広げたい場合は、別途ロールを付与する必要があります。

用途を1つに絞ったロールもあります。sn_request_approver_readは、承認レコードを持つ人だけに読み取りを許可するロールです。sn_request_comments_writeは、Additional commentsだけへの書き込みを許可します。外部委託先に利用者向けの連絡だけを任せたい場面で使える組み合わせです。

各ロールの守備範囲とACLの内訳は、本シリーズ第3巻「ロール」で扱います。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … 権限が効かないときはここを見る

実機で気づいたこと

親子関係を3つの経路で表現している

sc_taskは、親のRequestを指すrequest、直近の親のRITMを指すrequest_item、task継承の汎用フィールドparentという3つの経路で親を参照できます。

RITM取消のBusiness Ruleはparentでsc_taskを検索して一括更新し、RITM削除のBusiness Ruleはrequest_itemで検索して物理削除します。同じ「RITMに紐づくタスクを探す」処理なのに、使う経路が処理ごとに違います。

自社でsc_taskを検索するスクリプトを書くときは、この3経路のどれを条件にしているかを最初に確認します。OOB側の実装が経路を統一していない以上、独自スクリプトが片方の経路だけを前提にすると、もう片方で作られたレコードを取りこぼします。

stageの値が選択肢マスタに無い

stageはinternal_type「Workflow」という専用型で、choiceのマスタは既定の値しか持ちません。実際のRITMを見ると「Dept. Head Approval」のような、マスタに登録の無い値が普通に入っています。

この仕組みは、実行中のフローやワークフローの工程名が、そのままstageへ反映されることを意味します。固定の選択肢を表示するための項目ではなく、進行状況を動的に映すための項目だと考えられます。

レポートやダッシュボードでstageを条件に使う場合、choiceのマスタだけを見て網羅した気にならないようにします。実データに何が入るかは、稼働しているフロー・ワークフローの構成次第で変わります。

専用のプロパティ名前空間が無い

com.snc.request.*やsn_request.*というプロパティ名を検索すると、どちらも0件でした。申請処理（Request）固有の挙動を切り替える設定は、専用の名前空間を持っていません。

代わりにglide.sc.*というカタログ共通の名前空間に間借りする形で実装されています。承認のしきい値やエンタイトルメントの制御も、この名前空間の中に含まれます。

自社の運用で申請まわりの挙動を変えたいときは、nameLIKErequestで検索しても見つかりません。nameLIKEsc.やカタログ関連の名前空間まで含めて探す必要があります。各プロパティの個別の値は、本シリーズ第4巻「プロパティ」で扱います。

• 参考：システムプロパティ（sys_properties）は設定値の置き場 … 名前空間の探し方

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

サービスカタログを新しく設計するとき、確認する順序を決めておくと迷いません。

1. カタログの品目構成：sc_cat_item204件のうち、自社で公開する範囲とカテゴリ分けを決める

2. 承認の設計：金額しきい値による承認と、部門長承認の2段階をどう組み合わせるかを決める

3. 履行エンジンの選択：新規アイテムにWorkflowとFlow Designerのどちらを使うかを決める

4. 優先度の扱い：既定値が空欄のため、優先度を使う運用にするなら入力方法を別途用意する

5. SLAの要否：OOBのSLA監視は無いため、期限管理が必要なら自社でcontract_slaを作る

6. ロールの棚卸し：カタログ閲覧とリクエスト管理の書き込みは別軸のため、両方の付与範囲を確認する

7. 通知の取捨：31件のうち何件が自社の履行フローに関係するかを1件ずつ見て、無関係な通知は条件で絞る

用語

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

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

• RITM：Requested Item。sc_req_itemに保存される、申請された品目1件

• ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則

• Application File：更新セットで移送される設定オブジェクトの総称。sc_cat_item・sc_catalog・sc_categoryが該当する

検証範囲とおことわり

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

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

• 各Business Rule・通知の処理内容までは追っていません

• ACL222件の内訳、ロールごとの守備範囲は、このシリーズの後続記事で扱います

• 業務レコードの分布（どの状態に何件あるか）はデモデータ固有のため扱っていません

• カタログアイテム204件の内訳（クラス別・active別）は、今回確認した範囲の数字です

• 履行エンジンの選び方、承認しきい値の設定方法は本シリーズ第5・6巻で扱います

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

• テーブル定義：/sys_db_object_list.do?sysparm_query=nameINsc_request,sc_req_item,sc_task

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

• 辞書上書き：/sys_dictionary_override_list.do?sysparm_query=nameINsc_req_item,sc_task

• request_stateの選択肢：/sys_choice_list.do?sysparm_query=name=sc_request^element=request_state^language=en

• Business Rule：/sys_script_list.do?sysparm_query=collectionINsc_request,sc_req_item,sc_task

• 通知：/sysevent_email_action_list.do?sysparm_query=collectionINsc_request,sc_req_item,sc_task

• SLA定義：/contract_sla_list.do?sysparm_query=collectionINsc_request,sc_req_item,sc_task

• ロール：/sys_user_role_list.do?sysparm_query=nameLIKEcatalog^ORnameLIKEsn_request

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

• カタログアイテム：/sc_cat_item_list.do?sysparm_query=active=true

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

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

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

関連記事

• taskテーブル：ITSM全プロセスの共通の親 … 申請データ3テーブルの親を先に知ると、フィールド構成がつかみやすくなる

• インシデント管理モジュールの概要 … 定型と非定型、扱う対象が逆の関係にあるシリーズ

• 承認は1人1レコード（sysapproval_approver） … サービスカタログの承認が記録される共通基盤