ServiceNowでカタログアイテムをゼロから作る手順：申請フォームが動くまで

2026年7月7日 08:50

「カタログアイテムを1つ追加してほしい」と頼まれても、変数・変数セット・UI Policy・承認フロー・通知・公開制御と手を付ける場所が多く、何から着手すればよいか迷います。この記事は「ソフトウェア利用申請」というアイテムを1つ、土台の作成から画面制御・承認フロー・履行タスク作成まで通しで組み立てた手順です。Zurich PDIで実際に発注し、要求（REQ）・要求アイテム（RITM）・承認・カタログタスク（SCTASK）が生成されるところまで確認しました。

カタログの仕組みを説明した記事は別に用意しています。この記事は仕組みの解説ではなく、手を動かして作るための手順です。作り終えたときに、自分のインスタンスで動くカタログアイテムが1つ残ります。

検証環境：Zurich PDI（Flow Designerは Workflow Studio に改称）/ OOTB / 2026-07-06 確認

結論：申請から履行タスクまでの流れと作る順番

作るものは、次の流れで動くカタログアイテムです。利用者が Employee Center から申請すると、要求（Request / REQ）と要求アイテム（Requested Item / RITM）が生成されます。RITM には上長の承認が回り、承認されればサービスデスク向けのカタログタスク（Catalog Task / SCTASK）が作られる、という流れです。払い出し作業が終わると RITM が完了し、却下のときはタスクを作らずに終わります。

作成する順番は、この流れをそのまま前から組み立てる形にしています。土台（カタログとアイテム）→ 入力フォーム（変数・変数セット）→ 画面制御 → 承認と履行（フロー）→ 通知 → 公開制御 → サーバ側の検証 → テスト → 移送、の順です。前の工程が後の工程の材料になるので、上から順に進めると迷いが減ります。

登場する主なテーブルと用語を先に一覧にします。

呼び方                      テーブル             役割
-----------------------------------------------------
カタログアイテム            sc_cat_item          申請できる品目の定義。今回の主役
変数（Variables）           item_option_new      申請フォームの入力項目の定義
変数セット（Variable Set）  item_option_new_set  入力項目の束を使い回す再利用単位
Catalog UI Policy           catalog_ui_policy    入力に応じた表示・必須・読み取りの制御
要求（Request / REQ）       sc_request           1回の申請のまとまり
要求アイテム（RITM）        sc_req_item          申請された品目ひとつ。承認・履行の主役
カタログタスク（SCTASK）    sc_task              品目を満たすための作業

1. 何から手を付ける？まず Update Set にまとめる

最初に、この作業でできる設定をひとまとめにする入れ物（Update Set）を用意します。ここに変更を貯めておくと、後で別環境へ移す作業や、作ったものの棚卸しが楽になります。

1) Update Set を新規作成する

実施者：カタログ管理者（開発担当）
画面：アプリケーションナビゲーターで System Update Sets > Local Update Sets を開く
入力
Name：CAT ソフトウェア利用申請（分かる名前）
Description：目的・担当・リリース予定を書ける範囲で
操作：「Submit」を押す
成功条件：一覧に作成した Update Set が並ぶ
注意点：1つのアイテムに関する設定は、なるべく同じ Update Set にまとめる

2) 作成した Update Set を現在の作業対象にする

画面：作成した Update Set のレコードを開く
操作：「Set as Current」（現在の Update Set にする）を押す
成功条件：現在の Update Set として表示される
注意点：ここを切り替え忘れると、以降の変更が別の Update Set に入ってしまう

この記事では、以降の設定がすべてこの Update Set に記録されるようにして進めています。移送の段取りは最後の章にまとめます。

2. どこに載せる？カタログとカテゴリを先に決める

アイテムを載せる棚を先に決めます。掲載先のカタログ（Service Catalog）と、その中の分類（カテゴリ）です。今回は OOTB にある Service Catalog と、その中の「Software」カテゴリをそのまま使います。新しく分類を増やしたいときはカテゴリを作りますが、まずは既存の棚に載せて動かすところから始めると安全です。

1) 掲載先のカテゴリを確認する

実施者：カタログ管理者
画面：Service Catalog > Catalog Definitions > Maintain Categories を開く
入力
一覧から「Software」を選ぶ（新規作成なら「New」で Title と対象カタログを入力）
操作：内容を確認したら開いたまま次へ（新規作成時は「Submit」）
成功条件：使うカテゴリが決まり、Active になっている
注意点：カテゴリ階層を深くしすぎると利用者が迷う。まず浅く作り、アイテムが増えてから分ける

カテゴリ名は利用者の言葉にします。どのソフトを使いたいかで探す人が多いので、技術用語よりも業務の言葉のほうが見つけてもらいやすくなります。

3. アイテムの土台を作る：名前だけ決めていったん保存する

主役のカタログアイテムを作ります。名前・掲載先・説明といった土台だけ先に決めて、いったん保存するのがコツです。保存すると、下部に変数や UI Policy を追加するための関連リストが揃い、以降の作業がやりやすくなります。

1) カタログアイテムを新規作成する

実施者：カタログ管理者
画面：Service Catalog > Catalog Definitions > Maintain Items を開き、「New」を押す
入力
Name：ソフトウェア利用申請
Short description：業務で使うソフトウェアの利用を申請します（1文で価値が伝わる説明）
Catalogs：Service Catalog
Category：Software
Active：オン
操作：「Submit」を押していったん保存する
成功条件：アイテムが保存され、フォーム下部に Variables や Catalog UI Policies などの関連リストが表示される
注意点：最初から作り込まず、まず保存する。関連リストが出てから中身を足していくほうが早い

作成直後の空のフォームは次のような画面です。ここに名前や説明を入れていきます。

入力して保存すると、次のようになります。Catalogs に Service Catalog、Category に Software が入り、Active にチェックが付いた状態です。

Name は利用者が一覧で見る名前です。技術的な正式名称より、申請したい人が分かる言葉を選びます。Short description は一覧やポータルで説明として出るので、何を申請するものかが1文で伝わるようにします。

4. 申請フォームの入力項目を決める：変数を6つ用意する

申請フォームに並ぶ入力項目が変数（Variables）です。集めたい情報ではなく、後で使う情報だけを用意するのがコツになります。承認の判定・履行タスクの内容・通知・レポート、そのどこかで使う項目に絞ると、フォームが短くなり入力の負担も減ります。

今回は次の6つを用意します。

1) 変数を1つずつ追加する

実施者：カタログ管理者
画面：作成したアイテムを開き、下部の Variables 関連リストで「New」を押す
入力
Type：入力形式（1行テキスト / 選択肢 / 日付 / Yes/No / 複数行など）
Question：利用者に見える質問文（例：利用開始日）
Name：内部名（例：start_date）
Order：表示順（10刻み）
Mandatory：必須にするものだけオン
操作：「Submit」を押し、必要な数だけ繰り返す
成功条件：Variables 関連リストに、Order 順で変数が並ぶ
注意点：Name は英小文字とアンダースコアで付ける。質問文は日本語でよいが、Name を日本語やスペースにすると後でフローやスクリプトから参照しづらい

追加していくと、変数の一覧はこのようになります。Order の順に並ぶので、10刻みにしておくと後から間に差し込めます。

選択肢（Select Box）の変数では、質問文とは別に選択肢そのものを用意します。今回の「利用したいソフトウェア」では、Microsoft 365・Adobe Acrobat・Zoom・Slack・その他、という選択肢を登録しています。

まずは必須の項目だけで作り、実際に入力してみてから任意の項目を足すと、利用者目線で無理のないフォームになります。選択肢は後から変えると運用に影響が出るので、文言と意味は最初に決めておくと安心です。

5. 入力項目を使い回すには？変数セットとMRVS

同じ入力項目を複数のアイテムで使うなら、変数セット（Variable Set）にまとめて使い回します。「部署」「費用負担部門」のように、どの申請でも聞く項目は、セットにしておけば各アイテムで作り直す必要がありません。変数セットには画面制御（UI Policy / Client Script）も一緒に持たせられるので、共通の入力と共通の挙動をまとめて管理できます。

1) 変数セット（Single Row）を作る

実施者：カタログ管理者
画面：Service Catalog > Catalog Variables > Variable Sets を開き、「New」を押す（Single Row を選ぶ）
入力
Title：共通：申請者情報
Internal name：applicant_common
Description：複数アイテムで共通して使う入力（部署・費用負担部門など）
操作：「Submit」で保存し、続けてセット内に変数を追加する
成功条件：変数セットが作られ、中に変数を追加できる
注意点：セット内の変数にも Order がある。アイテム側の Order と二重で整理する

作成した変数セットです。種別（Type）が Single Row（1行）になっています。

セットの中に、共通で聞く変数を追加します。ここでは「部署」「費用負担部門」を入れています。作り方は第4章の変数と同じで、違いは所属先が変数セットになる点です。

2) アイテムに変数セットを追加する

画面：アイテムを開き、下部の Variable Sets 関連リストで「Edit」を押す
入力
候補から追加したい変数セットを選び、選択済みへ移す
操作：「Save」で保存する
成功条件：アイテムの申請フォームに、変数セットの項目が表示される
注意点：表示順が崩れたら、変数セット側とアイテム側の Order を見直す

3) MRVS（複数行変数セット）を作る（必要な場合）

1回の申請で「複数のソフトを行として追加したい」ような場合は、複数行変数セット（MRVS）を使います。便利な一方で、後工程（フロー・通知・抽出）での扱いがやや難しくなります。採用するなら、行数の上限や抽出方法を先に決めてから進めるほうが安全です。

画面：Variable Sets で「New」を押し、種別に Multi Row を選ぶ
入力
Title：追加ソフトウェア（複数行）
列として使う変数（ソフトウェア名・用途など）を追加
操作：「Submit」で保存し、アイテムに追加する
成功条件：フォームで行の追加・削除ができる
注意点：Try it で、行追加・必須チェック・表示や非表示の挙動を確認する

種別が Multi Row の変数セットです。

変数セットの詳しい考え方（Single Row と Multi Row の違い、共通化の設計）は別記事にまとめています。参照先は変数セットの解説記事です。

6. 入力に応じて項目を出し分けるには？ UI PolicyとClient Script

入力内容に応じて、項目を表示・必須・読み取りにするのが画面制御です。まず Catalog UI Policy で作り、それで届かないところだけ Catalog Client Script で補う、という順で考えると保守が楽になります。制御手段の使い分けは次の表のとおりです。

今回は「個人端末にもインストールしますか？」で「はい」を選んだときだけ、「個人端末の台数」を表示して必須にします。

1) Catalog UI Policy を作る

実施者：カタログ管理者
画面：アイテムを開き、下部の Catalog UI Policies 関連リストで「New」を押す
入力
Short description：個人端末＝はいのとき台数を表示・必須
Applies to：アイテム
Active：オン
Catalog conditions：個人端末にもインストールしますか？がはい（true）
操作：「Submit」で保存する
成功条件：UI Policy が保存され、Catalog UI Policy Actions を追加できる
注意点：Reverse if false を有効にしておくと、「いいえ」に戻したとき自動で非表示・任意に戻る

2) UI Policy Action で対象項目の動作を決める

画面：保存した UI Policy の Catalog UI Policy Actions で「New」を押す
入力
対象の変数：個人端末の台数
Visible：true
Mandatory：true
操作：「Submit」で保存する
成功条件：条件を満たしたときだけ、対象の変数が表示・必須になる
注意点：クライアント側の必須は入力補助。重要な制限はサーバ側でも担保する前提で考える

3) Catalog Client Script を書く（必要最小で）

UI Policy で届かない補助が必要なときだけ、Client Script を足します。重い処理や過剰なサーバ呼び出しは避け、最小限にとどめます。

画面：アイテムの Catalog Client Scripts 関連リストで「New」を押す
入力
Type：onLoad / onChange / onSubmit のいずれか
Variable name：onChange の場合は対象変数
Script：最小限の処理
操作：「Submit」で保存する
成功条件：狙った場面でだけスクリプトが動く
注意点：クライアントスクリプトはブラウザ側で改変され得る。権限や上限など重要なチェックはサーバ側で再確認する

画面挙動の仕組み（Catalog UI Policy と Catalog Client Script の関係、適用範囲の考え方）は別記事で扱っています。詳細はフォーム挙動の解説記事を参照してください。

7. 承認と履行をつなぐ：Workflow Studioでフローを組む

申請後の「上長の承認 → 承認後にサービスデスクへタスク作成」を、Workflow Studio（Flow Designer）で組みます。Zurich では Flow Designer が Workflow Studio という名前になっていますが、作り方の考え方は同じです。トリガー（いつ動くか）と、アクション（何をするか）を並べていきます。

1) フローを新規作成する

実施者：フロー作成担当
画面：Process Automation > Workflow Studio（またはナビゲーターで Flow Designer）を開き、「New」から「Flow」を選ぶ
入力
Flow name：ソフトウェア利用申請承認と払い出し
Application：Global
Description：目的を1文で
操作：「Build flow」を押す
成功条件：フローの編集画面が開く
注意点：名前はアイテム名＋用途にしておくと、後で探しやすい

2) トリガーに Service Catalog を設定する

画面：TRIGGER の「Add a trigger」を押す
入力
Trigger：Service Catalog
操作：「Done」を押す
成功条件：トリガーが Service Catalog になり、右側の Data に Requested Item Record が出る
注意点：どのアイテムで動かすかは、後の手順（11章の紐付け）でアイテム側の設定と結び付ける

3) 承認アクション（Ask For Approval）を追加する

画面：ACTIONS の「Add an Action, Flow Logic, or Subflow」→「Action」→「Ask For Approval」を選ぶ
入力
Record：トリガーの Requested Item（sc_req_item）
Rules：Approve When Anyone approves
承認者：Requested for（申請者）→ Manager（上長）
操作：「Done」を押す
成功条件：承認アクションが保存され、出力に Approval State が出る
注意点：承認者を個人で固定すると、異動で承認が回らなくなる。項目を参照して決めると保守が楽

4) 「承認された場合」の分岐でタスク作成を追加する

画面：「Add an Action, Flow Logic, or Subflow」→「Flow Logic」→「If」を選ぶ
入力
条件：1-Ask For Approval の Approval State が Approved
操作：「Done」を押し、その If の中（then）で「Action」→「Create Catalog Task」を追加する
入力（タスク）
Requested Item：トリガーの Requested Item
Short description：ソフトウェアの払い出し作業（アカウント作成・インストール）
Fields：Assignment group＝Service Desk
Wait：オン
操作：タスク側も「Done」を押す
成功条件：承認されたときだけタスクが作られる
注意点：If で承認を確認してからタスクを作る。これがないと、却下されてもタスクが作られてしまう

5) フローを有効化する

画面：フロー編集画面の右上「Activate」を押し、確認ダイアログでもう一度「Activate」
成功条件：ステータスが Active（Published）になる
注意点：有効化しただけでは、まだアイテムと結び付いていない。11章でアイテムに紐付ける

組み上がったフローは、トリガー（Service Catalog）→ 承認 →「承認された場合」→ タスク作成、という並びになります。

8. 誰に・いつメールが飛ぶ？通知の考え方

申請から履行までの節目で、関係者にメールが飛びます。多くは OOTB の通知でまかなえます。後で実際に発注してみると、次の5通が生成されました。申請者への受付連絡、上長への承認依頼、承認結果、そしてサービスデスクへのタスク割当です。

このうち受付のお知らせは、練習として自分で1本足したものです。通知を1つ追加する手順は次のとおりです。

1) 通知（Notification）を追加する

実施者：通知の設計担当
画面：System Notification > Email > Notifications を開き、「New」を押す（テーブルは sysevent_email_action）
入力
Table：Requested Item（sc_req_item）
送信条件：レコード作成時
条件：このカタログアイテムのとき
宛先：要求の Requested for（申請者）
Subject と本文
操作：「Submit」で保存する
成功条件：発注したときに、その条件で通知が送られる
注意点：宛先（申請者・上長・担当グループ）を先に決める。作りすぎると受け取る側が疲れるので、本当に必要な通知に絞る

節目ごとに、誰へ何が飛ぶかを整理すると次のようになります。

どこまで自分で足すかは運用しだいです。まず OOTB の通知で足りるかを確認し、足りない連絡だけを追加すると、通知が増えすぎずに済みます。

9. 誰に見せる？ User Criteriaで公開範囲を決める

誰にこのアイテムを見せるかを決めるのが公開制御です。部署・拠点・役割・グループなどの条件を User Criteria として作り、カテゴリやアイテムに適用します。後から権限を直すのは影響が大きいので、公開範囲は早めに設計しておきます。

1) User Criteria を作る

実施者：公開範囲の設計担当
画面：Service Catalog > Catalog Definition > User Criteria を開き、「New」を押す
入力
Name：社員（ITILロール）など、意図が分かる名前
条件：Role / Group / Department / Location（今回は Role に itil を指定）
Description：後から見て意図が分かる説明
操作：「Submit」で保存する
成功条件：条件を持った User Criteria が作られる
注意点：名前と説明を丁寧に付けておくと、後から見返したときに運用が安定する

2) アイテムに User Criteria を適用する

画面：アイテムを開き、下部の Available for（見せる相手）関連リストで対象の User Criteria を追加する
操作：「Save」で保存する（除外したい相手は Not available for に追加）
成功条件：指定した条件の利用者にだけアイテムが見える
注意点：カテゴリに付けた制御が、アイテムに自動で効かないことがある。重要なアイテムは、カテゴリに加えてアイテムにも直接適用する

アイテムのフォーム下部には、変数セット・Client Script・Available for などの関連リストが並びます。ここで公開範囲や共通項目を確認できます。

3) 見える／見えないをデバッグする

「見えない」が起きたら、次を順に確認します。

カテゴリとアイテムの両方に User Criteria を適用したか
Available for と Not available for が意図どおりか
条件に使ったロールや部署の値がユーザー側に入っているか

原因がデータ側（ロール不足・部署の値違い）にあることも多いので、ユーザーレコードも合わせて確認します。外部向けの公開は、ロールやポータルの設定など別のレイヤーが関わるため、内部向けとは分けて設計します。

10. 標準機能で足りないところだけスクリプトを足す

標準機能で届かないところだけ、スクリプトを足します。順番としては、まず UI Policy、次に Flow、最後にスクリプトです。クライアント側は入力補助、サーバ側は検証・権限・永続化、と役割を分けて考えます。

1) Business Rule でサーバ側の最終チェックを置く

画面の必須やクライアントのチェックに頼らず、保存時にサーバ側で守りたいルールがあるときに使います。

実施者：スクリプト担当
画面：System Definition > Business Rules を開き、「New」を押す
入力
Table：守りたいレコード（例：Requested Item / sc_req_item）
When：Before / After / Async と条件
Script：最小限の検証
操作：「Submit」で保存する
成功条件：保存時に、狙ったチェックが効く
注意点：重要な入力チェック（範囲・上限・権限）はここに置く。クライアント側だけに頼らない

2) GlideAjax で画面からサーバの値を問い合わせる

入力値に応じてサーバ側のデータを参照したいときに使います。サーバ側の処理は Script Include に置き、Client callable（クライアントから呼べる）にするのが基本です。返してよい情報だけを返し、権限チェックも入れます。

画面：System Definition > Script Includes を開き、「New」を押す
入力
Name：CatalogAjaxHelper
Client callable：オン
Script：必要最小の処理
操作：「Submit」で保存する
成功条件：クライアントの Client Script から GlideAjax で呼び出せる
注意点：Client callable はセキュリティ境界になる。大量データや権限のない情報を返さない

サーバ側（Script Include）とクライアント側（Catalog Client Script）は、次の形で対にします。

// サーバ側（Script Include / Client callable）
var CatalogAjaxHelper = Class.create();
CatalogAjaxHelper.prototype = Object.extendsObject(AbstractAjaxProcessor, {
  getSomething: function() {
    var input = this.getParameter('sysparm_input') + '';
    // 返してよい情報だけを返す（権限チェックも入れる）
    return input;
  },
  type: 'CatalogAjaxHelper'
});

// クライアント側（Catalog Client Script / onChange）
function onChange(control, oldValue, newValue, isLoading) {
  if (isLoading || !newValue) return;
  var ga = new GlideAjax('CatalogAjaxHelper');
  ga.addParam('sysparm_name', 'getSomething');
  ga.addParam('sysparm_input', newValue);
  ga.getXMLAnswer(function(answer) {
    // answer を使ってフォームを更新（例：g_form.setValue(...)）
  });
}

どの手段を選ぶかは、6章の使い分けの表に戻って考えると整理しやすくなります。ロジックは Script Include に集約し、Flow やクライアントから呼べる形にしておくと、後の保守が楽になります。

11. 実際に発注して、承認とタスクが動くか確認する

作ったら、利用者の画面で見えるか、注文したときに承認とタスクが動くかを確認します。管理者で見えても、一般の利用者ロールで見えるとは限りません。利用者目線での表示確認と、実際の発注まで行います。

1) アイテムにフローを紐付ける

実施者：カタログ管理者
画面：アイテムを開き、Process Engine（またはフローを指定する欄）で、作ったフローを選ぶ
操作：「Update」で保存する
成功条件：アイテムのフロー欄に「ソフトウェア利用申請承認と払い出し」が入る
注意点：ここが空だと、発注しても承認やタスクが動かない。フローが Active になっていることも合わせて確認する

2) 利用者の画面で表示を確認する（Try it）

画面：Employee Center（またはサービスポータル）でカタログを開き、Software カテゴリから「ソフトウェア利用申請」を開く。アイテムフォーム上部の「Try It」からも確認できる
確認
作った変数がフォームに並ぶ
「個人端末にもインストールしますか？」で「はい」にすると「個人端末の台数」が表示される
必須の項目が意図どおりになっている
注意点：公開範囲を制御している場合は、対象ユーザーでも表示を確認する

利用者から見た申請フォームは次のようになります。選択肢・日付・台数・理由が並び、条件を満たすと追加の項目が現れます。

3) 試しに発注して、生成物を確認する

画面：申請フォームで各項目を入力し、「Order Now」（今すぐ注文）を押す
入力例
利用したいソフトウェア：Microsoft 365
利用開始日：日付
必要台数：2
個人端末にもインストール：はい
個人端末の台数：1
申請理由：用途
成功条件：要求（REQ）と要求アイテム（RITM）が生成され、RITM に入力した変数の値が保持される
注意点：誰の申請かによって承認者が変わる。上長が設定されていないユーザーだと、承認が想定どおりに回らないことがある

発注すると、RITM が作られ、入力した変数の値がそのまま保持されます。

このとき、データは次の関係になっています。要求の下に要求アイテムがあり、要求アイテムが変数の回答値・承認・タスクを持ちます。

4) 承認とタスクが動くことを確認する

画面：RITM の承認（Approvers）や、承認レコードの一覧を開く
成功条件：申請者の上長あてに承認が1件生成され、承認待ちになっている
注意点：承認前の段階では、まだタスクは作られない（「承認された場合」の分岐が効いているため）

生成された承認レコードです。承認者は申請者の上長になっています。

承認すると、フローが続きを実行し、サービスデスクあてのカタログタスク（SCTASK）が作られます。

一連のメールも生成されます。申請者への受付連絡、上長への承認依頼、承認結果、サービスデスクへのタスク割当が並びます。

例外系も一度は試しておきます。未入力での送信、却下したときの動き、承認者が不在のときの扱いなどです。性能面では、変数を増やしすぎるとタスク作成が失敗する場合が知られています。変数を必要最小に絞る、タスクを担当単位で分ける、説明文に全変数を詰め込まない、の3点が効きます。

実機で気づいたこと

発注してみると、想定と違う点がいくつかありました。

まず、RITM（要求アイテム）にはStageとStateという似た名前の項目が別々にあり、最初は同じ意味だろうと思っていました。実際に生成されたRITMを見ると、承認まで進んだ時点でStageは「Request Approved」、Stateはまだ「Open」のままでした。Stageは申請者向けの大まかな進捗表示、Stateは内部のライフサイクル管理という役割分担になっていて、片方だけを見て終わったと判断すると誤ります。

次に、承認とタスク作成の順序です。フローを組むとき、最初はAsk For Approvalの直後にCreate Catalog Taskを並べれば動くだろうと考えていました。実際に却下のケースも想定して組み直すと、Ifで承認結果を確認する分岐を自分で挟まない限り、フローは承認結果に関係なくタスクを作ってしまいます。承認された場合だけタスクを作るという制御は、自動では付いてこない設計でした。

最後に、通知の内訳です。発注から履行までに実際に発生したメールは5通でしたが、そのうち自分で作った通知は最初のお知らせ1本だけで、残り4通（申請受付・承認依頼・承認結果・タスク割当）はOOTBの通知だけでまかなえていました。通知を作り込む前に、まずOOTBのままどこまで飛ぶかを試すほうが手数は少なく済みそうです。

12. 他の環境へ持っていく：Update Setの移送で気をつけること

作ったものを別の環境（検証・本番）へ移すときは、1章で用意した Update Set を使います。移送で壊れないための段取りを確認します。

1) Update Set の中身を確認する

実施者：リリース担当
画面：System Update Sets > Local Update Sets で対象の Update Set を開く
確認
Customer Updates に、画面まわりの設定（アイテム・変数・変数セット・UI Policy・Client Script）がそろっているか
Customer Updates に、処理まわりの設定（Flow・通知・Script Include・Business Rule）がそろっているか
注意点：ユーザーやグループなど環境ごとに違うデータは、移送先で別途用意する前提で考える

2) 移送先でプレビューしてから適用する

操作：移送先で Update Set を取り込み、Preview でコンフリクトや不足を確認してから Commit する
成功条件：意図した設定が移送先に反映される
注意点：公開はいつ・誰が確認するか、どこまで戻せるかを決めてから切り替える

公開前の最終チェックとして、次を見ておくと設定漏れを防げます。

カテゴリに載っているか
重要なアイテムはカテゴリとアイテムの両方に公開制御が付いているか
必須は最小か
UI Policy と Client Script の Order が規約どおりか
フローが有効で発注できるか
タスクに必要な情報が入るか
例外時の通知先が決まっているか

よくあるミスとリカバリ

作成中につまずきやすいところと、その戻し方をまとめます。

次に読むなら

この記事は「作る手順」に絞りました。テーブルの構造や入力項目のまとめ方、画面挙動の仕組みは、次の解説記事に分けています。

ServiceNow サービスカタログ完全ガイド：申請フォーム1つが履行タスクに届くまで — この記事の12ステップが、申請から履行までの全体像のどこに当たるかを一望できます。
カタログアイテムと変数セット：アイテム・カテゴリ・カタログと「変数の束」の関係
カタログのフォーム挙動：Catalog UI Policy と Catalog Client Script

技術メモ：型・承認・紐付けの詳細

変数の型は、変数そのもの（item_option_new）ではなく親の question テーブルに定義されている。今回は Select Box・Date・Single Line Text・Yes/No・Multi Line Text を使用した
変数セットには Single Row（one_to_one）と Multi Row（one_to_many）がある。共通の入力に加えて、画面制御もセット側に持たせられる
Catalog UI Policy は Applies to でアイテムか変数セットのどちらに効かせるかを選ぶ。動作（表示 / 必須 / 読み取り）は Catalog UI Policy Action 側に保持される
承認は sysapproval_approver に生成され、承認者は Requested for → Manager で解決された
アイテムとフローの紐付けは、アイテム側のフロー欄（flow_designer_flow）に、作成した Workflow Studio のフローを設定する形で行った

用語

PDI：Personal Developer Instance。無料で使える検証用インスタンス
OOTB：Out of the Box。初期設定のまま、追加開発をしていない状態
カタログアイテム（sc_cat_item）：カタログに並ぶ「申請できる品目」の定義
変数（Variables / item_option_new）：申請フォームの入力項目の定義
変数セット（Variable Set / item_option_new_set）：入力項目の束を使い回す再利用単位
Catalog UI Policy（catalog_ui_policy）：入力に応じた表示・必須・読み取りの制御
要求（Request / REQ / sc_request）：1回の申請のまとまり
要求アイテム（Requested Item / RITM / sc_req_item）：申請された品目ひとつ。承認・履行の主役
カタログタスク（Catalog Task / SCTASK / sc_task）：品目を満たすための作業
User Criteria（user_criteria）：誰に見せるかを決める公開条件
Workflow Studio（Flow Designer）：トリガーとアクションで自動化を組むツール。Zurich で名称が変わった

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

自分の環境で確認する際は、<YourInstance> を自分のインスタンス名に置き換えてください。

# カタログアイテムの一覧（Maintain Items）
https://<YourInstance>/sc_cat_item_list.do

# あるアイテムの変数（Variables）
https://<YourInstance>/item_option_new_list.do?sysparm_query=cat_itemISNOTEMPTY^ORDERBYorder

# 変数セット（Variable Sets）
https://<YourInstance>/item_option_new_set_list.do

# Catalog UI Policy / Catalog Client Script
https://<YourInstance>/catalog_ui_policy_list.do
https://<YourInstance>/catalog_script_client_list.do

# 公開制御（User Criteria）
https://<YourInstance>/user_criteria_list.do

# 通知（Notifications）
https://<YourInstance>/sysevent_email_action_list.do

# 発注後の要求アイテムと承認・タスク
https://<YourInstance>/sc_req_item_list.do
https://<YourInstance>/sysapproval_approver_list.do
https://<YourInstance>/sc_task_list.do

参考リンク

公式ドキュメントの中でも、この記事の作業に直結するものをまとめました。

検証に使う PDI は ServiceNow 開発者サイトから無料で取得できます。

検証範囲とおことわり

確認した範囲は次のとおりです。

カタログアイテム・変数・選択肢・変数セット（Single Row / Multi Row）・Catalog UI Policy・Catalog Client Script の作成
Workflow Studio（Flow Designer）での、Service Catalog トリガー・上長承認・「承認された場合」の分岐・カタログタスク作成
通知を1本追加し、発注時に OOTB の通知と合わせてメールが生成されること
User Criteria の作成とアイテムへの適用、Script Include・Business Rule の作成
実際に発注し、要求・要求アイテム・変数の値・承認・タスクが生成され、承認するとタスクが作られること

確認していない範囲（この記事では扱っていません。断定しません）。

MRVS の抽出やフロー連携での詳しい扱い、GlideAjax の実データを使った動作
外部ユーザー向けの公開（外部ロール・ポータル公開・閲覧範囲）の詳細設計
SLA、複数段階の承認、履行計画（Execution Plan）による履行
Catalog Builder（新しい作成画面）での同等の操作

ここに書いた画面名・フィールド・挙動は、今回確認した PDI（Zurich / OOTB）で見えた範囲のものです。リリースやカスタマイズによって異なる場合があります。作成後は、自分の環境で実際に発注し、承認・タスク・通知が想定どおりに動くかを確認してから公開してください。

このシリーズの記事一覧

ServiceNow の機能を1テーマずつ実機で確かめた記事を、分類ごとにまとめています。読みたいテーマから辿れます。

→ ServiceNow 観察日記 - 目次 -