サービスカタログのテーブル・フィールド構成

申請の進み具合をレポートや条件式で拾おうとして、状態を表すフィールドがどれなのか迷うことがあります。サービスカタログは Request（sc_request）・Requested Item（sc_req_item）・Catalog Task（sc_task）という3つのテーブルで1件の申請を記録し、状態も request_state・state・stage という3つの仕組みが並んで動いています。Australia の PDI をデフォルト設定のまま開き、3テーブルの固有フィールドと状態の持ち方を確かめました。

確認する項目

• 3テーブルがどんな関係で、固有フィールドは何個ずつか

• 状態を表す3つの仕組みが、それぞれ何を管理しているか

• 辞書の上書きで priority と assigned_to がどう変わるか

• 変数（item_option_new）と回答値がなぜ別テーブルか

• 親子の間で状態がどう伝わるか

この記事の要点

• sc_request・sc_req_item・sc_task はいずれも task を直接継承する兄弟で、固有フィールドは9・16・5個としぼられている

• 状態は request_state（文字列7値）・state（数値6値）・stage（Workflow型）の3系統が並存し、stage は選択肢定義に無い値が実データに入る

• sys_dictionary_override で priority の既定値が空欄に、assigned_to の候補がロールで絞られている

3テーブルの継承構造

Request・Requested Item・Catalog Taskは、3階層のように見えて実際は横並びの構造です。3つとも task を直接継承しています。

sc_req_item と sc_request は、ともに task の子として横並びに存在します。継承関係ではなく、後述する参照フィールド（request や request_item）で親子のつながりが表現されます。

同じ画面には sc_cat_item・sc_catalog・sc_category も並びます。この3つは Application File という別系統を継承しており、更新セットで移送される設定オブジェクトです。カタログの変数定義（item_option_new）はさらに別で、Question を継承しています。1回の申請の裏側には、性格の異なる3つのテーブル群が同時に動いています。

3テーブルが分かれている理由は、番号の体系にも表れています。Requestの番号はREQ、RITMはRITM、TaskはSCTASKで始まります。この3種類の番号を見るだけで、今どの粒度のレコードを見ているかが分かる作りです。REQは注文全体の入れ物、RITMは品目1件ごとの履行状況、SCTASKは担当者が実施する作業そのものという役割分担です。申請番号で検索してもレコードが見つからないという相談を受けたら、まずRITM番号かSCTASK番号を尋ねます。REQ側は承認が終わると更新が止まることも珍しくなく、実際に動いているレコードはRITMかTaskであることがほとんどだからです。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … Incident・Problem・Changeも継承する共通の親

sc_requestとsc_req_itemの固有フィールド

sys_dictionary で3テーブルそれぞれの固有フィールドを数えると、sc_request が9個、sc_req_item が16個、sc_task が5個でした。impact・urgency・priority・state・assigned_to・assignment_group・short_description はどのテーブルの固有辞書にも無く、すべて task からの継承です。

固有フィールドの中身を見ると、テーブルごとの役割分担が見えてきます。

sc_request の9項目は、申請全体をまとめる情報です。requested_for（申請対象者）・request_state（進み具合）・price（合計金額）など、注文の入れ物としての性格が中心です。

sc_req_item の16項目は3テーブル中もっとも多く、cat_item（何を申請したか）・quantity（数量）・price／recurring_price（価格）・configuration_item（関連するCI）・flow_context／context（履行エンジンの実行コンテキスト）など、履行に必要な情報が集まっています。品目1件の「何を・いくつ・いくらで」がこのテーブルだけでほぼ分かる作りです。

flow_context と context が2つ並んでいるのは、履行を自動で進めるエンジンが新旧2つあるためです。context は旧Workflowエンジンの実行コンテキストを、flow_context は新しいFlow Designerの実行コンテキストをそれぞれ保持します。1件のRITMがどちらのエンジンで動いているかは、この2項目のどちらに値が入っているかで見分けがつく仕組みです。両エンジンの選ばれ方とビジネスルールの実行順は、本シリーズ第6巻「自動設定構成」で扱います。

• 参考：Catalog Task はどこから来るか（履行計画） … 履行タスクが生成される仕組み

sc_taskの固有フィールド

sc_task の固有フィールドは、次の5個です。

elementラベル型参照先calendar_stcResolve TimeIntegercat_itemItemReferenceCatalog ItemrequestRequestReferenceRequestrequest_itemRequest itemReferenceRequested Itemsc_catalogCatalogReferenceCatalog

sc_task は3テーブルの中でもっとも軽く、価格や数量は持ちません。担当者が実施する作業そのものの単位で、「誰が何をやるか」は task 継承の assigned_to／short_description が担い、sc_task 固有の5項目は参照関係の管理に絞られています。価格や数量の変更が必要になった場合も、担当者はsc_task側を編集する必要がなく、RITM側のprice・quantityを直せば足ります。

注目したいのは、request と request_item の両方を固有フィールドとして持っている点です。3テーブルの中で、親（Request）と直近の親（RITM）の両方を同時に参照できるのは sc_task だけです。sc_req_item は逆に request（親）しか持たず、祖先にあたるフィールドは持ちません。3階層ぶんの縦の関係を、末端の sc_task 側に集約して持たせる設計になっています。

状態を表す3つの仕組み

進み具合を表すフィールドは、request_state・state・stage という3系統に分かれます。それぞれ違う対象を管理しています。

request_state（Request全体の承認状態）

sc_request.request_state は文字列choiceで7値あります。requested（Pending Approval）から始まり、in_process（Approved）を経て closed_complete などの終了状態に至ります。

sc_request にはこの request_state 以外に状態を表す固有フィールドが無く、Request全体としては「承認されたかどうか」を軸にした値だけを持ちます。

state（RITM・Taskに共通する数値ステータス）

sc_req_item.state と sc_task.state は、どちらも task 基底の数値choiceをそのまま使います。辞書上の固有定義・上書きはありません。値は -5（Pending）・1（Open）・2（Work in Progress）・3（Closed Complete）・4（Closed Incomplete）・7（Closed Skipped）の6値です。品目単位・作業単位の状態を、Incident や Problem と同じ語彙で管理していることになります。

stage（選択肢定義の外にも値が入るフィールド）

stage の internal_type は通常のchoiceではなく「Workflow」という専用型です。choice定義は sc_request が7値（requested〜closed_complete）、sc_req_item が3値（waiting_for_approval／fulfillment／delivery）です。

ところが実データを GROUPBYstage で確認すると、choice定義に無い値が普通に混ざっていました。

7件のRITMが5種類のstage値に分かれ、Dept. Head Approval や Order Fulfillment のように、choice定義の3値のどれとも一致しない表示が3件を占めています。理由は、実行中のワークフロー（旧Workflowエンジン・新Flow Designerのどちらか）のアクティビティ名が、そのまま stage に反映される特殊なフィールドだからです。choice定義の値は、ワークフローが無い場合に表示される既定値にすぎません。

このため、stage を条件式やレポートの軸に使う場合は、choiceの一覧だけを見て網羅した気にならないほうがよくなります。実際に動いているワークフローのアクティビティ名を実データ側で確認し、GROUPBYstage のような集計で実在する値を洗い出してから条件を書きます。

• 参考：選択肢Choice（sys_choice）：ドロップダウンの中身 … choiceがレコードとして入る場所

辞書上書きによるpriorityとassigned_toの変更

task から継承した定義を、テーブルごとに変える仕組みが sys_dictionary_override です。sc_req_item と sc_task にそれぞれ2件、まったく同じ内容の上書きが登録されていました。

対象テーブルelement上書き内容sc_req_item / sc_taskassigned_to参照修飾子を roles=itil^ORroles=sn_request_write に上書きsc_req_item / sc_taskpriority既定値を空文字に上書き（基底 task.priority の4を打ち消す）

assigned_to は、担当者の候補が itil か sn_request_write のどちらかのロールを持つユーザーに絞られます。「担当者の欄で候補に出てこない」という相談を受けたときは、まずこのロールを持っているかを確認します。

priority は既定値そのものが空欄に上書きされています。Incident や Problem が持つ「Impact×Urgencyから優先度を自動計算する仕組み」（dl_definition）は、sc_request・sc_req_item・sc_task のいずれにも存在しません。優先度を空欄から始め、自動計算に頼らない設計を選んでいることが、既定値の上書きという1行から読み取れます。

• 参考：参照フィールドと参照修飾子：候補はどう絞られるか … 参照修飾子で候補を絞る仕組み

変数（item_option_new）と回答テーブルの分離

申請フォームに並ぶ入力項目の定義は item_option_new（変数）です。希望日・数量・理由などを、カタログ項目ごとに定義します。申請時に入力された回答値は、sc_req_item の通常フィールドではなく、sc_item_option や sc_item_option_mtom という別テーブルを経由してRITMと紐づく構造です。定義と回答が分かれているため、変数の中身を調べるときは両方を見る必要があります。

item_option_new は676件登録されており、うち584件がいずれかのカタログ項目に直接紐づいています。残り92件は変数セットなど、単体の項目に直付けされていない定義です。1つのカタログ項目に平均しても数個の変数が紐づく計算で、フォーム1画面の裏側には想像より多くの定義レコードが動いています。

この構造は、sc_cat_item（カタログ項目本体）が業務データの sc_request／sc_req_item／sc_task とは別系統である点とも重なります。sc_cat_item は Application File を継承する設定オブジェクトで、更新セットで移送されます。カタログ項目・変数の定義は「設定」、Request・RITM・Taskとその回答は「業務データ」という区分けです。設定側を直しても業務データは変わらず、逆も同様です。

カタログ項目の可視性も、業務データ側とは別の仕組みで管理されています。テーブルへの権限を決めるsys_security_aclとは別に、sc_cat_item_user_criteria_mtom（見せる条件）・sc_cat_item_user_criteria_no_mtom（隠す条件）というUser Criteriaの専用レコードが控える構造です。「公開したはずのカタログ項目が特定の利用者に見えない」という調査では、ACLだけでなくこのUser Criteria側も確認対象になります。

• 参考：同じ入力項目を9アイテムで使い回す中間表（io_set_item） … 変数を複数アイテムで共有する仕組み

• 参考：誰も頼んでいないカタログを洗い出す手順 … Application File系であるsc_cat_itemを対象にした棚卸し

• 参考：サービスカタログのトラブル事例と解決 … User Criteriaを含む可視性の切り分け手順

カタログアイテムを取り巻く関連機能の全体像

ここまでで、カタログ項目本体（sc_cat_item）と変数（item_option_new）の関係を見てきました。実際にはカタログ項目1件の裏側で、もっと多くのテーブルが連動しています。関係を1枚の図にまとめます。

変数セット（変数の再利用機構）

変数は個々のカタログ項目に直付けするだけでなく、複数のアイテムで使い回すための入れ物を持ちます。この入れ物がitem_option_new_set（変数セット、22件）です。カタログ項目への配布はio_set_item（割当49件）が仲介する構造です。item_option_new676件のうち、変数セット経由の配布は76件（11%）にとどまり、残り600件（89%）はカタログ項目へ直接紐づく。

22件の変数セットは、複数アイテムへの配布状況で性格が分かれます。代表例はit_to_it（9アイテムで共有）とstandard_employee_questions（5アイテムで共有）で、複数アイテムへ実際に配布されている再利用型です。もう一方は、名前が空欄で_stepが付く構造専用のセットで、カタログ項目デザイナーやRecord Producerのフォームが内部で使う土台にあたります。「変数セット＝複数アイテムでの再利用」という理解だけでは、22件のうち実際に再利用されている件数を過大に見積もります。

画面制御・可視性・履行の起点は別巻で扱う

図の残り4系統は、いずれも別巻で詳しく扱います。ここではsc_cat_itemとの接続関係だけを押さえます。

• catalog_ui_policy（103件）・catalog_script_client（141件）: 変数の表示・必須を制御する仕組み。動きの詳細は自動設定構成編で扱う

• User Criteria（728件）: カタログ項目の可視性を判定する、ACLとは別レイヤーの機構。詳細はロール編で扱う

• workflow・flow_designer_flow: カタログ項目ごとの履行エンジンの設定。分布は基本設定編、起動の仕組みは自動設定構成編で扱う

• delivery_plan（15件、配下のタスク定義53件）: 履行タスクの生成計画。204件中70件（34%）に設定されている。生成の仕組みは自動設定構成編で扱う

子クラス8種（申請の入口）

sc_cat_itemは8つの子クラスに分かれます。標準の通常カタログ項目が97件で最多です。次に多いのはRecord Producer系（sc_cat_item_producer・sc_cat_item_composite_producer・std_change_record_producer）で、合計46件にのぼります。残りは資産管理連携（pc_hardware_cat_item41件・pc_software_cat_item13件）、Order Guide2件、コンテンツ項目4件、ウィザード型1件です。クラスごとの役割は概要編、フォームの入口としての使い分けは基本設定編で扱います。

親子カスケードによる状態の伝播

Request・RITM・Taskの状態は、保存時に動くビジネスルールによって、上位から下位へ、下位から上位へと双方向に伝播する仕組みです。

Requestが取消状態になると「Cancel Flows Upon Cancellation」というビジネスルールが動きます。sys_flow_context を source_table=sc_request で検索し、実行中のFlow Designerのコンテキストを能動的にキャンセルする処理です。RITM側で stage が Request Cancelled になったときは、「Close Tasks Due to Cancellations」が動きます。このビジネスルールは sc_task を parentフィールドで検索し、状態をまとめてClosed Incompleteに更新します。

同じ「RITMに紐づくTaskを探す」処理でも、削除系のビジネスルールは request_item フィールドを条件に使い、キャンセル系は parent フィールドを使っています。sc_task が親を指す経路を request・request_item・parent の3つ持っていることの裏返しで、ServiceNow標準のスクリプト自体がどの経路を使うか統一されていません。自社でTaskを検索するスクリプトを書くときは、この3経路のどれで書かれた既存コードなのかを先に確認したほうが安全です。

承認そのものは、この3テーブルには含まれません。承認者ごとの記録は sysapproval_approver という別テーブルに1人1レコードで積まれ、Request側の approval フィールド（task 継承）が全体の集計結果を持つ形です。カスケードを追うときは、Request・RITM・Taskの3テーブルに加えて、承認の記録がどこにあるかも合わせて押さえます。

• 参考：承認は1人1レコード（sysapproval_approver） … 承認者ごとの記録の持ち方

公式ヒントに見るフィールドの意図

ServiceNowは製品にフィールドの説明文を同梱しています。sc_request・sc_req_item・sc_task を合わせると、説明があるのは6件だけでした。同じ手法で確認したProblem管理（problem12件＋problem_task2件）と比べると、半分以下の情報量です。

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

sc_request.requested_for と sc_req_item.requested_for の説明です。代理申請を前提としたフィールドだと公式に明記されています。

（訳: 希望する納品日）

sc_request.requested_date の説明です。SLAの期限とは別に、利用者が希望する日付だけを持つ項目という位置づけです。

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

実機で気づいたこと

sc_taskだけが親と直近の親の両方を固有フィールドに持つ

sc_task の固有フィールドを見ると、request（Requestへの参照）と request_item（RITMへの参照）が両方とも並んでいます。sc_req_item は request しか持たず、祖先を直接参照する固有フィールドはありません。

3階層の縦の関係を、実行の末端にあたる sc_task 側に集約して持たせる設計です。Taskのレコード1件から、RITMを経由せずにRequestへ直接たどり着けます。RITMの状態が壊れていても、TaskからRequestへの経路は影響を受けません。

自社でTaskからRequest情報を取得するスクリプトを書くときは、request_item.request と遠回りせず、sc_task.request を直接参照するほうが、経由テーブルの状態に依存しない書き方になります。

priorityの既定値が空欄に上書きされている理由

sys_dictionary_override を確認すると、sc_req_item・sc_task の priority は既定値が空文字に上書きされていました。基底の task.priority は既定値4を持つため、通常なら空欄で始まりません。

このパッケージの名前には「do not activate, see plugin description」という注意書きが含まれていますが、上書き自体は本PDIで有効になっています。Incident・Problemが持つ「Impact×Urgencyから優先度を自動計算する」仕組み（dl_definition）は、Request系の3テーブルにいずれも存在しません。優先度は自動計算に頼らず、カタログ項目ごとの個別ロジックか担当者の手動設定に委ねる設計だと読み取れます。

自社でRequest系のレコードにSLAや優先度ベースのエスカレーションを組むときは、既定値が空欄であることを前提に、カタログ項目側かビジネスルール側で優先度を明示的に設定する処理を用意します。

stageの値は選択肢定義を全部読んでも足りない

stage のchoice定義を読むだけでは、実データに現れる値を網羅できません。今回の7件のRITMでも、choice定義の3値と一致したのは1件（Fulfillment）だけで、残り6件は Request Approved・Dept. Head Approval・Order Fulfillment・Request Approval という、定義には無い表示でした。

internal_type が「Workflow」という専用型になっているのが理由です。実行中のフローの工程名やワークフローの活動名がそのまま stage に書き込まれるため、カタログ項目ごとに設定されたフロー・ワークフローの数だけ、stage の実データ値は増えます。

ダッシュボードやレポートで stage を軸に集計するときは、choice定義だけを条件に入れると取りこぼしが発生します。GROUPBYstage で実在する値を先に洗い出してから、条件式やフィルタの候補を決めます。

管理画面だけでなく、Service Portalの利用者向け画面でも同じ食い違いが起きます。本シリーズ第1巻「概要」でMy Request画面を確認したときも、RITM0010001（Standard Laptop）のstageに Order Fulfillment という、choice定義に無い値が表示されていました。実データの根拠はどちらの画面でも同じで、RITM0010001ではフロー「Service Catalog item request」の工程名です。

フォーム制御はsc_req_item側になく、カタログ側に集中している

sc_request・sc_req_item・sc_taskのsys_ui_policy・sys_script_client・sys_data_policy2を数えると、3テーブルともゼロでした。

フォーム制御は、カタログ項目の変数（item_option_new）に紐づくcatalog_ui_policy（103件）とcatalog_script_client（141件）に集中しています。合計244件が、標準の仕組みではなくカタログ専用の別テーブルで動く構成です。

申請フォームの表示や必須の挙動を調べるときは、sys_ui_policyやsys_script_clientをsc_req_item条件で検索しても手掛かりが見つかりません。catalog_ui_policy・catalog_script_client側を確認します。動きの詳細は本シリーズ第6巻「自動設定構成」で扱います。

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

自社向けにRequest系のカスタマイズを検討するとき、確認する順序を決めておくと迷いません。

1. 追加先の判断：Request全体で使うか、品目単位か、作業単位か。3テーブルの固有フィールドが薄いぶん、多くはtask継承フィールドで足りるかを先に確認する

2. 状態の選び方：進み具合を条件にするなら、request_state（Request全体の承認状態）・state（品目/作業の数値状態）・stage（ワークフローの実行位置）のどれを見るべきかを先に決める

3. stageを使うときの注意：choice定義だけでなく、GROUPBYstage で実データの値を洗い出してから条件を書く

4. 担当者の絞り込み：assigned_to の候補ロールが itil／sn_request_write に上書きされている前提で、候補に出ないユーザーへの対応を決める

5. 優先度の扱い：既定値が空欄である前提で、自動計算に頼らずどこで優先度を設定するかを決める

6. Task検索の経路選定：sc_task から親を探すとき、request／request_item／parent のどれを使うかを既存コードと揃える

7. 変数の調査範囲：定義（item_option_new）と回答（sc_item_option系）を分けて確認する

用語

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

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

• RITM：Requested Item（sc_req_item）。申請された品目1件

• Application File：更新セットで移送される設定オブジェクトの継承元。sc_cat_item／sc_catalog／sc_category が該当

• 辞書上書き（sys_dictionary_override）：継承元テーブルの定義を、特定のテーブルだけで変える仕組み

検証範囲とおことわり

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

• 件数はすべてOOTBの定義の数、またはこのPDIのデモデータの実測値です。本番環境やカスタマイズ済み環境では異なります

• request_state・stageの遷移条件や承認フローの内部ロジックは、本シリーズ第5巻「基本設定」・第6巻「自動設定構成」で扱います

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

• プロパティによる挙動変更は、本シリーズ第4巻「プロパティ」で扱います

• カタログ変数の回答値の保存構造の詳細は、同じ入力項目を9アイテムで使い回す中間表（io_set_item）で扱っています

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

• sc_requestの項目定義：/sys_dictionary_list.do?sysparm_query=name=sc_request^elementISNOTEMPTY

• sc_req_itemの項目定義：/sys_dictionary_list.do?sysparm_query=name=sc_req_item^elementISNOTEMPTY

• sc_taskの項目定義：/sys_dictionary_list.do?sysparm_query=name=sc_task^elementISNOTEMPTY

• テーブルの継承関係：/sys_db_object_list.do?sysparm_query=nameINsc_request,sc_req_item,sc_task,sc_cat_item,sc_catalog,sc_category,item_option_new

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

• stageの実データ集計：/sc_req_item_list.do?sysparm_query=GROUPBYstage

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

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

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

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

参考リンク

• Introduction to catalog items（Zurich） … Catalog Itemの定義・変数・Order Guideとの関係

• Service catalog variable sets（Zurich） … 変数セット（item_option_new_set）の公式説明

• Service catalog execution plans（Zurich） … delivery_planが担う履行計画の仕組み

• Classic approvals（Zurich） … sysapproval_approverによる承認の仕組み

関連記事

• taskテーブル：ITSM全プロセスの共通の親 … 3テーブルが共通で継承する親テーブルの役割

• サービスカタログの概要 … 全体像。今回の3テーブルが申請から履行までの流れのどこに当たるか

• 承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） … 実務編。request_stateとstageが承認でどう動くかを実際の申請で確かめる