同じ入力項目を9アイテムで使い回す中間表（io_set_item）

前回までの記事で確認したのは3点です。1つ目は、Service Catalog の申請が3階層に分かれること。Request（sc_request）→ Requested Item（sc_req_item）→ Catalog Task（sc_task）の順に流れます。2つ目は、Record Producer（sc_cat_item_producer）がカタログアイテムの一種であること。そして変数は「定義（item_option_new）」と「回答値（sc_item_option）」に分かれていました。

今回はその一段上、カタログアイテム（sc_cat_item）自身の周辺構造です。同じ入力項目を複数のアイテムで使い回す仕組みが変数セット（item_option_new_set）ですが、アイテムと変数セットが直接つながっているわけではありません。間に io_set_item という中間表（多対多テーブル）が入ります。アイテムをカタログ画面に並べるためのカテゴリ（sc_category）も同じ形です。この結びつき方を PDI の実機で確認しました。

想定読者は、ServiceNow の Incident を触ったことがあり、Service Catalog の3階層と変数の保存構造まで分かっている管理者・開発者です。カタログアイテムの「並べ方（カタログ・カテゴリ）」と「入力項目の使い回し（変数セット）」をこれから整理したい段階を想定しています。

この記事で分かること

• カタログアイテム（sc_cat_item）と変数セット（item_option_new_set）が、Application File（sys_metadata）を継承する「構成定義」であること

• カテゴリ（sc_category）とカタログ（sc_catalog）も、同じ「構成定義」であること

• アイテムと変数セットの紐づきが、専用の多対多テーブル io_set_item（Catalog Variable Set）で表現されること

• 1つの変数セットを複数アイテムで使い回せること（実機で it_to_it が9アイテムに紐づくのを確認）

• 変数セットには Single Row（単一行）と Multi Row（複数行）の2種類があること

• アイテムとカテゴリの紐づきにも多対多テーブル sc_cat_item_category があり、カテゴリは parent で階層化されること

• 実機で確認するときに見るべき一覧URL

カタログアイテムを取り巻く4つの構成要素

利用者がカタログ画面で目にする「申請ボタン」の1つ1つがカタログアイテム（sc_cat_item）です。そのアイテムは、どのカタログ（sc_catalog）の、どのカテゴリ（sc_category）に並ぶかで分類され、フォームの入力項目を変数として持ちます。複数のアイテムで共通して使う入力項目の束が変数セット（item_option_new_set）です。

4要素それぞれの件数

今回確認した PDI（Zurich / OOTB）では、これらは次の件数でした。

• カタログ（sc_catalog）… 2件（Service Catalog / Technical Catalog）

• カテゴリ（sc_category）… 45件（うち active 32件）

• カタログアイテム（sc_cat_item）… 196件（うち active 146件）

• 変数セット（item_option_new_set）… 20件

利用者から見た入口はこうです。次は Service Portal（sc_home）のカタログトップ画面で、検索窓と「Browse by Categories（カテゴリで探す）」が並びます。この画面の裏側で sc_catalog / sc_category / sc_cat_item が動いています。

カタログトップは、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sp?id=sc_home

6テーブルはすべて「構成定義（sys_metadata）」

今回扱う6テーブルは、申請データ（トランザクション）ではなく、すべて Application File（sys_metadata）を継承する「構成定義」でした。カタログの“設計図”側のテーブル群です。

今回確認した PDI（Zurich / OOTB）の継承関係と件数を表にまとめます。

表の下2つ、io_set_item（Catalog Variable Set）と sc_cat_item_category（Catalog Item Category）は毛色が違います。両端の参照と並び順だけを持つ多対多（M2M）の橋渡しテーブルです。前者はアイテムと変数セットを、後者はアイテムとカテゴリを結びます。固有フィールドはごく少なく、io_set_item は4、sc_cat_item_category は3しかありません。対照的に本体側の sc_cat_item は76、item_option_new_set は14、sc_category は19と、こちらは項目数が多めです。

6テーブルの定義は、次のURLから一覧できます。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameINsc_cat_item,item_option_new_set,io_set_item,sc_cat_item_category,sc_category,sc_catalog

変数セットは「入力項目の束を使い回す」ための仕組み

変数セット（item_option_new_set）は、複数のアイテムで共通して使う入力項目をひとまとめにして使い回す“再利用単位”です。概要は公式の Service catalog variable sets（Zurich） にまとまっています。

たとえば「申請者の部署・電話番号・上長」といった、どのアイテムでも聞きたい項目を毎回作り直すのは大変です。これを1つの変数セットにまとめておけば、複数のアイテムが同じ束を参照できます。

その「同じ束を複数アイテムから参照する」紐づきを実際に持つのが、多対多テーブル io_set_item です。今回の PDI では、変数セット it_to_it（Single Row）が 9件のアイテムに紐づいていました。

この画面では、it_to_it という1つの変数セットを9アイテムが共有しています（右上の「1 to 9 of 9」）。内訳は VM Provisioning / Provision a Database / Server Tuning / Endpoint Security。続けて Consulting Request / Whitelist IP / Firewall Rule Change / Big Data Analysis / Table Index です。変数セット common_comments（Single Row）も同じ形です。Password Reset / Report Performance Problem / Report Outage の3アイテムに紐づいていました。

逆方向も成り立ちます。1つのアイテムが複数の変数セットを並べることもでき、Record Producer Builder というアイテムは io_set_item を10件持っていました。io_set_item は「1セット→多アイテム」「1アイテム→多セット」の両方向を表し、order フィールドでアイテム内の並び順を制御します。io_set_item 全体のレコード数は46件でした。

変数セット（item_option_new_set）の主な固有フィールドは次のとおりです。

変数セットの一覧と、それを変更したい場合の入口は、次のURLで確認できます。

https://<YourInstance>/item_option_new_set_list.do

変数セットには Single Row と Multi Row がある

変数セットの種別（type）は、PDI（Zurich / OOTB）では次の2種でした。

• Single Row（one_to_one） … 通常の変数の束。1つのアイテムにつき1組の入力欄として表示します。今回の PDI では20件中15件がこちらでした。

• Multi Row（one_to_many） … 複数行（表形式）の入力を許す変数セット。1件のアイテムに対して、同じ項目の組を何行も入力できます。今回の PDI では5件でした。

Multi Row は、「ノートPCを5台、それぞれ機種と用途を指定して一括発注する」のように、同じ入力の組を行数分くり返したいケースに向きます。この記事では type の値（Single Row / Multi Row）と件数の分布までを確認し、Multi Row の行追加フォームの実描画挙動は検証範囲外とします。

変数セットの種別の分布と、再利用の実例は次の表のとおりです。

カテゴリとカタログ：アイテムの並べ方

アイテムを「どこに並べるか」は、カタログ（sc_catalog）とカテゴリ（sc_category）で決まります。カテゴリは parent で階層化され、sc_catalog でどのカタログに属するかを持ちます。カテゴリの概念は、公式の Service Catalog categories（Zurich） を参照してください。

実機で確認したカテゴリ階層の例は次のとおりです。

• Hardware（parent なし＝トップ）→ Laptops / Printers / Cables and Adapters

• Software（トップ）→ Application and Account Access

• Office（トップ）→ Services

• Standard Changes（トップ）→ Template Management

アイテム側は、category フィールド（主カテゴリ1つ・sc_cat_item 側の参照）を持ちます。たとえば「Access」は Software カテゴリ、「Cisco jabber softphone」は Office カテゴリ、というように1つの主カテゴリに属します。

これに加えて、アイテムを複数のカテゴリ（や複数カタログ）に出すための多対多テーブルが sc_cat_item_category（Catalog Item Category）です。今回の PDI では441件あり、アイテムとカテゴリの紐づきを多対多で表現していました。主カテゴリ（sc_cat_item.category）と多対多（sc_cat_item_category）の2系統があるため、1つのアイテムを複数の場所に出せます。

2つの多対多テーブルの件数を比べる

io_set_item（アイテム⇔変数セット）は46件、sc_cat_item_category（アイテム⇔カテゴリ）は441件でした。約10倍の差です。カテゴリへの割り当てはほぼ全アイテムに関わる一方、変数セットの共有は一部のアイテムだけが使う機能だと、この差から読み取れます。

カテゴリの一覧URLは次のとおりです。

https://<YourInstance>/sc_category_list.do?sysparm_query=active=true^ORDERBYparent

これらの構造を1画面に集約するのがカタログアイテム本体です。次は実際のカタログアイテム（VM Provisioning）のフォーム。Name・Catalogs（Technical Catalog）・Category（Services）・Item Details などが並びます。1つのアイテムが、どのカタログ・どのカテゴリに属し、どんな説明と入力項目を持つかを、ここで設定します。

カタログアイテムの作成・編集手順は、公式の Create or edit a catalog item（Zurich） にまとまっています。

sc_cat_item.type：アイテムにも5つの種別がある

sc_cat_item 自体にも type という区分があり、選択肢は 1=Item（通常のアイテム）／2=Task／3=Bundle（複数アイテムのまとめ）／4=Template／5=Package の5種類でした。ここまで見てきた VM Provisioning のような単体アイテムは type=Item です。複数アイテムをまとめる Bundle や Package が同じテーブルに同居している点は、フォームを一目見ただけでは気づきにくい構造でした。

カタログアイテム本体は、次のURLの一覧から確認できます。

https://<YourInstance>/sc_cat_item_list.do

いま新しく設定するなら：部署・電話番号を変数セットで共通化する

複数の申請アイテムで「申請者の部署」「電話番号」を毎回聞きたい場合、各アイテムに同じ変数を作り直すのではなく、変数セットに1度だけ作って共有します。

手順は次の3つです。

1. item_option_new_set で新しい変数セット（例：requester_contact）を作り、type を Single Row にする。この束に「部署」「電話番号」の変数（item_option_new）を入れる。

2. 共通化したいアイテムを開く。上の VM Provisioning と同じ Catalog Item 画面で、Variable Sets 関連リストから requester_contact を追加する。この操作が、内部的には io_set_item に1行（sc_cat_item と variable_set の組）を作ります。

3. 並び順を変えたいときは io_set_item の order を調整する。

この設定の結果として、it_to_it が9アイテムで共有されていたのと同じ状態を自分で作れます。変数を直したいときも、変数セット1か所を直せば紐づく全アイテムに反映されます。

ServiceNowにおけるカタログアイテムと変数セットのポイント

• カタログアイテム（sc_cat_item）や変数セット（item_option_new_set）は「構成定義」です。カテゴリ（sc_category）・カタログ（sc_catalog）も含めて、いずれも Application File（sys_metadata）を継承します。申請データそのものではありません。

• アイテムと変数セットの紐づきは、多対多テーブル io_set_item（Catalog Variable Set）が担います。1つの変数セットを複数アイテムで使い回すことができ、今回の PDI では it_to_it が9アイテム、common_comments が3アイテムに紐づいていました。逆に1アイテムに複数セットを並べることもでき、order で順序を制御します。

• 変数セットには Single Row（one_to_one・今回15件）と Multi Row（one_to_many・今回5件）の2種類があります。Multi Row は表形式で複数行の入力を許す種別です。

• アイテムとカテゴリの紐づきにも多対多テーブル sc_cat_item_category（今回441件）があり、アイテム側の主カテゴリ（sc_cat_item.category）と併存します。カテゴリは parent で階層化され、sc_catalog で所属カタログを持ちます。

カタログ構造を調べるときは、「アイテム（sc_cat_item）を中心に、上にカタログ・カテゴリ、横に変数セット」という位置関係を起点にします。紐づきの実体である io_set_item と sc_cat_item_category という2つの多対多テーブルを、セットで見ると早いです。

実機を見て気づいたこと

• it_to_it は「1つのセットを9アイテムが使う」形でしたが、Record Producer Builder は逆に「1つのアイテムが10個のセットを持つ」形でした。同じ io_set_item という多対多テーブルが、こんなに違う使われ方を両方とも体現しているとは、実機を見るまで気づきませんでした。

• 変数セット20件のうち Multi Row はわずか5件（25%）でした。表形式の入力は便利そうに見えても、実際に使われているのは一部のケースに限られるようです。

次に読むなら

次は、変数セットの中に入る変数定義（item_option_new で variable_set を指定したもの）が、アイテム個別の変数とフォーム上でどう並ぶかを扱う予定です。Multi Row 変数セットの行追加がフォームでどう描画されるか、カテゴリの公開対象（roles / entitlement）がポータル表示にどう効くかも、別記事で確認します。いずれも本記事の「変数セットの type」「sc_cat_item_category の多対多」の先にある話です。

用語

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

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

• カタログアイテム（Catalog Item）：sc_cat_item。利用者がカタログから申請する1単位

• 変数セット（Variable Set）：item_option_new_set。複数アイテムで使い回す変数の束

• io_set_item（Catalog Variable Set）：アイテムと変数セットを結ぶ多対多テーブル

• sc_cat_item_category（Catalog Item Category）：アイテムとカテゴリを結ぶ多対多テーブル

• カテゴリ（Category）：sc_category。アイテムの分類（parent で階層）

• カタログ（Catalog）：sc_catalog。カテゴリ・アイテムを束ねる入口

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

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

テーブル定義      : sys_db_object_list.do?sysparm_query=nameINsc_cat_item,item_option_new_set,io_set_item,sc_cat_item_category,sc_category,sc_catalog
カタログトップ    : sp?id=sc_home
カタログアイテム一覧 : sc_cat_item_list.do
変数セット一覧    : item_option_new_set_list.do
アイテム⇔変数セット : io_set_item_list.do
カテゴリ一覧      : sc_category_list.do?sysparm_query=active=true^ORDERBYparent
変数セット固有     : sys_dictionary_list.do?sysparm_query=name=item_option_new_set^elementISNOTEMPTY

関連記事

• ServiceNow サービスカタログ完全ガイド：申請フォーム1つが履行タスクに届くまで — 変数セットで束ねた入力項目が、申請フォームから履行タスクに届くまでの流れ全体はこちらで確認できます。

検証範囲とおことわり

• 確認した範囲は次の6テーブルです。sc_cat_item / item_option_new_set / io_set_item / sc_cat_item_category / sc_category / sc_catalog。継承関係、固有フィールド数と主要フィールド・参照先を見ました。sc_cat_item.type と item_option_new_set.type の選択肢、各テーブルの件数（全体／active）も確認しています。変数セットの再利用件数（io_set_item 経由・it_to_it 9件 / common_comments 3件）と、カタログ2件・カテゴリ階層の実例も取りました。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。

• 確認していない範囲は次のとおりです。変数セット内の変数定義（item_option_new.variable_set 経由）の中身と、Multi Row（one_to_many）変数セットの実際のフォーム描画・行追加挙動。sc_cat_item_category の多対多がポータル表示でどう効くか、カテゴリの公開対象（roles / entitlement）制御、価格・履行 Flow の実行。これらは別記事で扱います。