Record Producer は RITM を作らない

2026年6月21日 11:44

前回の記事では、Service Catalog の申請が3階層に分かれることを確認しました。Request（sc_request）→ Requested Item（sc_req_item）→ Catalog Task（sc_task）の3つです。アイテムの定義は sc_cat_item にあり、変数は「定義（item_option_new）」と「回答値（sc_item_option など）」に分かれます。

その続きとして扱うのが Record Producer（sc_cat_item_producer） です。カタログ画面から RITM を作らずに、incident や change_request のような指定した作成先テーブルにレコードを作る入口です。この記事では Record Producer と、申請フォームの入力項目を支える変数（Variable）の保存構造を、実機を起点に確認します。

この記事は、ServiceNow の Incident は触ったことがあり、前回の Service Catalog の3階層は理解している人向けです。そのうえで Record Producer と変数の関係を整理したい段階を想定しています。変数まわりでは item_option_new / sc_item_option / item_option_new_set などを扱います。管理者・開発者が実機で確認するときに見るべき箇所は4つあります。Record Producer と通常のカタログアイテムの違い、table_name による作成先指定、変数を構成する4つの要素、変数の型（type）です。4つの要素とは、定義・回答値・RITM との紐づけ・変数セットを指します。

この記事で分かること

Record Producer（sc_cat_item_producer）が sc_cat_item（カタログアイテム）を継承する「アイテムの一種」であること
通常のカタログアイテムが RITM を作るのに対し、Record Producer は table_name で指定した作成先テーブルにレコードを作ること。公式説明では incident などの task ベースのレコード作成が中心の用途とされていること
変数が「定義」「回答値」「回答値と RITM の紐づけ」「変数セット」の4つの観点に分かれること。テーブルは item_option_new / sc_item_option / sc_item_option_mtom / item_option_new_set です
変数の入力項目を決める項目（name / question_text / type / mandatory）が親テーブル question 側にあること
変数の型（type）にどんな種類があるか（実機で確認した31種）
実機で確認するときに見るべき一覧URL

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、テーブル構成・フィールド・選択肢の内容が異なる場合があります。

Record Producer と変数とは

Record Producer（レコードプロデューサー）は、サービスカタログと同じ「メニューから選んでフォームに入力する」見た目をしています。ただし申請（RITM）ではなく、指定した作成先テーブルにレコードを直接作る 入口です。今回の PDI で確認した例には「Create Incident」や「Password Reset」があります。利用者はカタログ画面で入力するだけですが、裏では incident テーブルにレコードが作られます。

Record Producer は、何でも自由に任意のテーブルへ作れる仕組みではありません。ServiceNow の公式ドキュメント Record Producer では、主に incident などの task ベースのレコードを作成する用途として説明されています。作成先はスコープや create access（作成権限）の条件に従います。この記事では、今回の PDI で確認できた table_name の分布を「実機で見えた作成先」として扱います。推奨用途や制約そのものは、公式ドキュメントで確認してください。

変数（Variable）とは、カタログアイテムや Record Producer のフォームに表示する入力項目（希望日・理由・対象ユーザー・数量など）のことです。前回の記事で触れたとおり、変数は「フォームに出す項目の定義」と「実際に入力された値」が別のテーブルに分かれて保存されます。この記事では、その分かれ方を実テーブルで確認します。

Record Producer はカタログアイテムの一種

Record Producer は、カタログアイテムの仲間でした。まず継承関係から確認します。

今回確認した PDI（Zurich / OOTB）で、sc_cat_item_producer（Record Producer）の継承元を見ました。親は sc_cat_item（Catalog Item＝カタログアイテム） でした。つまり Record Producer は、通常のカタログアイテムと同じ「アイテム」の一種です。アイテムとしての共通項目（name / short_description / sc_catalog / category など）は、親の sc_cat_item から受け継いでいます。

一方、変数定義の item_option_new（Variable）は question（Question）を継承していました。変数の中心になる「質問」としての項目は、item_option_new 固有ではなく親の question 側にあります。name / question_text / type / mandatory / reference がそれにあたります。item_option_new 自体の固有フィールドは31で、cat_item や variable_set など「どのアイテム・どのセットに属するか」を表すものが中心です。

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

https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameINsc_cat_item_producer,sc_cat_item,item_option_new

通常のカタログアイテムとの違い（table_name で作成先を決める）

両者は見た目が似ていても、「申請後に何ができるか」が違います。カタログ画面のフォームはほぼ同じですが、出口が分かれます。なお、作成先テーブルを指定して入口を作る手順は公式ドキュメントの Create record producers from tables で説明されています。

通常のカタログアイテム（sc_cat_item）は、申請されると Requested Item（sc_req_item / RITM）を作ります。そこから Request（REQ）や Catalog Task（SCTASK）へと履行が展開します。これに対して Record Producer は、固有フィールドの table_name（必須）で指定したテーブルに、レコードを1件直接作ります。

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

観点                  通常のカタログアイテム（sc_cat_item）  Record Producer（sc_cat_item_producer）
----------------------------------------------------------------------------------------------------
テーブル継承          Application File を継承                sc_cat_item を継承（アイテムの一種）
申請時に作るレコード  Requested Item（sc_req_item / RITM）   table_name で指定した作成先テーブルに1件
作成先の指定          履行 Flow / Workflow 側                table_name フィールド（必須）で直接指定
代表的な作成先        RITM → REQ / SCTASK へ展開             incident / change_request / std_change_proposal など
件数（このPDI）       196                                    39
用途のイメージ        物品・サービスの「申請」               フォーム入力から「レコード作成」（例：Create Incident）

Record Producer の作成先は RITM に限りません。今回の PDI では Record Producer が39件ありました。作成先テーブル（table_name）の内訳は、change_request 10件・incident 6件・std_change_proposal 3件です。incident や change_request のような task 系に加え、task 系以外に見えるテーブルも対象になっていました。今回の PDI では、「Create Incident」「Report Outage」「Password Reset」の table_name が incident でした。「Delegate roles to group member」は change_request です。対比として、通常のカタログアイテム（sc_cat_item）は196件ありました。

ただし、Record Producer の公式説明では task ベースのレコード作成が中心の用途として説明されています。ここで示した table_name の分布は「この PDI で確認できた作成先」であって、Record Producer で何を作るべきかという推奨用途や制約を示すものではありません。task 系以外の table_name がどういう経緯で設定されているかは、本記事では確認していません。

Record Producer の固有フィールドは次のとおりです。

Field                    Label                    Type / 参照先       説明
--------------------------------------------------------------------------
table_name               Table name               table_name（必須）  申請から作成するレコードの“作成先テーブル”
script                   Script                   script_plain        レコード作成時に動かす処理（変数値の反映など）
post_insert_script       Post insert script       script_plain        レコード作成後に動かす処理
redirect_url             Redirect to              string              作成後に遷移する画面
save_options             Save options             string              変数の回答値を保存する挙動の設定
allow_edit / can_cancel  Allow edit / Can cancel  True/False          編集・キャンセルの可否
view                     View                     string              表示するフォームビュー

table_name のほか、レコード作成時の処理を書く script / save_script / post_insert_script があります。作成後の遷移先を決める redirect_url などもあります。これらの内部スクリプトは、利用者が入力した変数の値を作成先レコードへどう反映するかに関わります。ただし、その挙動は本記事では確認していません。公式ドキュメントには、Record Producer の script が作成を中断した場合の説明があります。その場合、Item Produced Record（sc_item_produced_record） にはレコードが生成されません。実際に作成されたレコードを追跡する場合は、Item Produced Record（sc_item_produced_record）も確認対象になります。本記事では table_name で作成先を決めるという構造に絞り、値の反映や produced record の追跡は範囲外とします。

Record Producer の一覧は、次のURLで確認できます。

https://<YourInstance>/sc_cat_item_producer_list.do

変数を構成する4つの要素（定義・回答値・RITM との紐づけ・変数セット）

変数は、1つのテーブルで完結しません。今回確認した PDI（Zurich / OOTB）では、変数は「定義」「回答値」「回答値と RITM の紐づけ」「変数セット」に役割が分かれていました。「定義 → 回答値」という単純な前後関係ではありません。変数セットは回答値の後段ではなく、複数の定義を束ねる側です。紐づけは回答値と申請（RITM）をつなぐ側です。それぞれ役割の異なる4つの要素として読むのが正確です。

変数“定義”（item_option_new） … フォームに出す入力項目の定義です。「希望日」「理由」「対象ユーザー」といった項目を、type（型）や mandatory（必須かどうか）とともに定義します。cat_item（→sc_cat_item）でどのアイテムに属するか、variable_set（→item_option_new_set）でどの変数セットに属するかを持ちます。今回の PDI では614件ありました（アイテム×変数の数だけ定義が増えます）。
変数セット（item_option_new_set） … 複数の変数定義を束ねて再利用できるまとまりです。回答値の後段ではなく、定義をグループ化して複数アイテムで使い回すための「再利用単位」です。今回の PDI では20件ありました。
回答値（sc_item_option） … 申請時に実際に入力された“値”です。item_option_new（→定義）でどの変数の回答かを参照し、value に入力値そのものを保存します。
回答値↔RITM の紐づけ（sc_item_option_mtom） … 回答値（sc_item_option）と RITM（sc_req_item）を結ぶ多対多テーブルです。request_item（→sc_req_item）と sc_item_option（→回答値）を持ちます。

テーブル構成の継承関係と固有フィールド数

継承関係で見ると、sc_item_option と sc_item_option_mtom は独立したベーステーブルで、他のテーブルを継承していません。固有フィールドはそれぞれ12・8です。item_option_new_set は sc_cat_item_producer と同じく Application File（sys_metadata）を継承しており、固有フィールドは14でした。item_option_new の固有フィールド31、sc_cat_item_producer の固有フィールド10は、それぞれ前の節で触れたとおりです。

各層のテーブルを表にすると次のとおりです。

観点                      テーブル             label               役割                                            主なフィールド                                                                                    件数
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
定義                      item_option_new      Variable            申請フォームに出す入力項目の“定義”              name / question_text / type / mandatory（←question親） / cat_item（→sc_cat_item） / variable_set  614
変数セット（再利用単位）  item_option_new_set  Variable Set        変数定義を束ねて再利用（回答値の後段ではない）  internal_name / title / type / order                                                              20
回答値                    sc_item_option       Options             申請時に入力された“値”                          item_option_new（→定義） / value                                                                  0
回答値↔RITM の紐づけ      sc_item_option_mtom  Variable Ownership  回答値と RITM を結ぶ多対多                      request_item（→sc_req_item） / sc_item_option（→回答値）                                          0

注意したいのは、回答値（sc_item_option）と紐づけ（sc_item_option_mtom）は、今回の PDI ではどちらも0件だったことです。これはこのデモ PDI に実際の申請データがほとんど無いためで、テーブル構造そのものは存在します。前回の記事で触れた「変数の定義と回答値を分けて見る」というのは、この item_option_new（定義）と sc_item_option（値）の分離を指します。今回の PDI では回答値が0件のため、実データでは追えていません。テーブル構造としては、RITM 経由の申請の回答値は RITM の通常フィールドに直接入りません。sc_item_option に保存され、sc_item_option_mtom を介して RITM と紐づく形です。なお Record Producer で入力された値が作成先レコードへどう反映されるかは、これらとは別の話です。Record Producer の script 側が関わる部分で、本記事では確認していません。

変数定義の一覧は、次のURLで確認できます。

https://<YourInstance>/item_option_new_list.do

変数の型（type）

変数の見た目は型（type）で決まります。テキスト入力なのか、選択肢なのか、参照なのかという違いです。前述のとおり type は item_option_new 固有ではなく、親の question 側に定義されています。なお、各型の意味は公式ドキュメントの Types of service catalog variables にまとまっています。

今回確認した PDI（Zurich / OOTB）では、type の選択肢は31種ありました。役割で大まかに分けると、次のように整理できます。

テキスト入力系 … Single Line Text（1行）、Multi Line Text（複数行）、Wide Single Line Text、Masked（伏せ字）、Email、URL
選択系 … Select Box、Multiple Choice、CheckBox、Yes / No、Numeric Scale
参照系 … Reference（他テーブルを参照）、List Collector（複数選択）、Lookup Select Box、Requested For
日付・その他 … Date、Date/Time、Duration、IP Address、Attachment
入力ではないレイアウト用 … Container Start / Split / End、Label、Break、HTML、Rich Text Label、UI Page、Custom / Custom with Label

type には実際の入力項目だけでなく、フォームの見た目を整えるためのレイアウト用（Container や Label、Break）も含まれています。変数を調べるときは、入力値を持つ型と、レイアウト用の型を区別して見る必要があります。型ごとのフォーム描画の挙動までは本記事では踏み込みません。

型の選択肢は、次のURLで一覧できます（変数の型は question テーブルに定義されています）。

https://<YourInstance>/sys_choice_list.do?sysparm_query=name=question^element=type^inactive=false^ORDERBYsequence

実機で気づいたこと

item_option_new の中心項目は question 側にあった

変数（item_option_new）の name・type・mandatory といった中心項目は、item_option_new 自体ではなく継承元の question テーブル側にありました。定義用のテーブルなので質問文や型もここに並ぶと想像していましたが、実際にあったのは cat_item や variable_set のような「所属」を表す項目が中心でした。

変数セットは回答値の後工程ではなかった

変数セット（item_option_new_set）の位置づけも、実機で確認するまでは誤解していました。「定義→回答値」の一本道の途中に挟まる印象を持っていましたが、実際は回答値の後工程ではなく複数の定義を束ねて使い回す横の仕組みでした。

task系以外の作成先にも気づいた

incident や change_request が中心という説明どおりの例が多く見つかりました。ただ、task 系以外を作成先にした例もありました。たとえば「Register a Business Application」という Record Producer があります。作成先（table_name）は business_app_request で、一見畑違いのテーブルでした。task 系が中心という公式の説明を裏付けつつも、実際の設定はそれより広い範囲で使われていると気づかされました。

ServiceNowにおけるRecord Producerと変数のポイント

Record Producer（sc_cat_item_producer）は sc_cat_item（カタログアイテム）を継承する「アイテムの一種」 です。アイテムの共通項目は sc_cat_item から継承し、固有フィールドは10でした。
通常のカタログアイテムが RITM（sc_req_item）を作るのに対し、Record Producer は table_name（必須）で指定した作成先テーブルにレコードを作ります。今回の PDI で確認した作成先は change_request（10）・incident（6）・std_change_proposal（3）などです。task 系以外に見えるテーブルも含まれていました。ただし公式説明では task ベースのレコード作成が中心の用途とされており、この分布は「PDI で見えた作成先」であって推奨用途を示すものではありません。
変数は4つの要素に分かれます。定義（item_option_new）・変数セット（item_option_new_set）・回答値（sc_item_option）の3つです。そこに回答値と RITM の紐づけ（sc_item_option_mtom）が加わります。変数セットは回答値の後段ではなく定義を束ねる再利用単位です。今回の PDI では定義614件・変数セット20件で、回答値と紐づけは0件（デモのため申請実績ほぼ無し）でした。
変数の中心になる項目は item_option_new 固有ではなく、親の question 側 にあります。name / question_text / type / mandatory / reference が該当します。item_option_new 固有（31）は cat_item / variable_set など“所属”を表すものが中心です。
変数の型（type）は今回31種で、テキスト入力・選択・参照・日付のほか、Container / Label などのレイアウト用も含みます。

Record Producer と変数を調べるときは、2つの点を起点にすると整理しやすくなります。「Record Producer はアイテム（sc_cat_item）の一種で、table_name が作成先」「変数は定義と回答値が別テーブル」の2点です。そのうえで、上の sc_cat_item / question、横の sc_item_option / item_option_new_set をセットで確認します。

次に読むなら

次に確認するなら、Record Producer の script / save_script が変数の回答値を作成先レコードにどう反映するかです。回答値（sc_item_option）の実データがどう保存されるかも気になります。Variable Set（item_option_new_set）を複数アイテムで再利用する設計も残っています。特に「申請フォームの入力制御（Catalog UI Policy / Catalog Client Script）はどこにあるか」は、カタログ設計を理解するうえで押さえておきたい点です。これらは本記事の「変数を構成する4つの要素」「Record Producer の固有フィールド」で触れた仕組みの先にあたり、別記事で扱う予定です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Record Producer：sc_cat_item_producer。カタログの見た目で、指定した作成先テーブルにレコードを作る入口（公式説明では task ベースのレコード作成が中心の用途）
変数（Variable）：item_option_new。フォームの入力項目の“定義”（回答値は sc_item_option など別テーブル）
変数セット（Variable Set）：item_option_new_set。変数定義を束ねて再利用するまとまり
RITM：Requested Item（sc_req_item）。申請されたアイテムひとつ

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

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

テーブル定義       : sys_db_object_list.do?sysparm_query=nameINsc_cat_item_producer,sc_cat_item,item_option_new
Record Producer一覧 : sc_cat_item_producer_list.do
変数定義一覧        : item_option_new_list.do
変数セット一覧      : item_option_new_set_list.do
変数の型(choices)   : sys_choice_list.do?sysparm_query=name=question^element=type^inactive=false^ORDERBYsequence
RP 固有フィールド   : sys_dictionary_list.do?sysparm_query=name=sc_cat_item_producer^elementISNOTEMPTY

ServiceNow サービスカタログ完全ガイド：申請フォーム1つが履行タスクに届くまで — Record Producer の変数入力が、申請から履行タスクに渡っていくまでの起点であることをこちらでまとめています。

検証範囲とおことわり

確認した範囲：sc_cat_item_producer / sc_cat_item / item_option_new / sc_item_option / sc_item_option_mtom / item_option_new_set の継承関係、固有フィールド数と主要フィールド・参照先、変数 type の選択肢（question.type 31種）、各テーブルの件数、Record Producer の作成先テーブル（table_name）の分布。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲：Record Producer の script / save_script / post_insert_script の内部挙動、回答値（sc_item_option）の実データ保存例（このPDIでは0件）、Variable Set の適用・再利用ロジック、各 type のフォーム描画挙動、Catalog UI Policy / Catalog Client Script の動作、履行 Flow の詳細。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、テーブルの構造を確認しました。実環境では、既存のカスタマイズによってフィールドや設定の数・内容が変わります。