複数アイテムを1申請に束ねる（オーダーガイド）

2026年6月22日 21:23

サービスカタログでは、利用者は普通「カタログアイテム（sc_cat_item）」を1つずつ申請します。でも「入社者の初期セットアップ」のように、ノートPC・モニタ・メールアカウント・VPN…を一気に頼みたいことがあります。これをまとめて申請させる仕組みが オーダーガイド（注文ガイド） です。

この記事では、ServiceNow のオーダーガイドが内部でどんなテーブル構造になっているのかを、PDI（Personal Developer Instance）の実機で確認しました。主役は2つです。オーダーガイドの本体が「特殊なカタログアイテム」であること（sc_cat_item を継承する）と、ガイドに含めるアイテムを最初の質問の答えで動的に出し分ける「ルール」テーブルです。

想定読者は、ServiceNow の Incident を触ったことがあり、サービスカタログの「カタログアイテム＝申請の1単位」までは分かっている管理者・開発者です。そのうえで、複数アイテムをまとめて申請させるオーダーガイドの構造を知りたい方に向けています。

この記事で分かること

オーダーガイド（sc_cat_item_guide）が、カタログアイテム（sc_cat_item）を継承する「特殊なアイテム」であること
ガイドに含めるアイテムは、別テーブル sc_cat_item_guide_items（label「Rule」）が「含めるアイテム＋出し分け条件」として持つこと
最初の画面（ニーズ記述）で答えたガイド変数の値に応じて、含まれるアイテムが動的に変わること。実機では laptop_type=developer のとき Developer Laptop が含まれる条件を確認しました
ガイド固有のフィールド（two_step / cascade / include_items など）の役割
OOTB のオーダーガイドは2件（New Hire / Request Developer Project Equipment）であること
実機で確認するときに見るべき一覧URL

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

オーダーガイドとは：1回の申請で複数アイテムを束ねる

オーダーガイドは、複数のカタログアイテムを1つの申請（Request）にまとめて頼むための仕組みです。利用者はまず「ニーズ記述」の画面でいくつかの質問に答え、その答えに応じて必要なアイテムが選び出され、まとめて申請されます。

次は実機の Service Portal で開いた「New Hire（入社者）」オーダーガイドの画面です。上部には Describe Needs（ニーズ記述）→ Choose Options（オプション選択）→ Summary（確認）という3ステップの導線があります。入社者に必要なメールアカウント・ノートPC・モニタなどが、1つの申請として束ねられています。この1画面が、sc_cat_item_guide とそのルールの見える側にあたります。

このガイド画面は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sp?id=sc_cat_item_guide&sys_id=<ガイドのsys_id>

全体像を図にすると次のとおりです。利用者の回答（ガイド変数）が、ルールの条件で評価され、含まれるアイテムが決まります。

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

オーダーガイド（sc_cat_item_guide）… 2件（New Hire / Request Developer Project Equipment）
ガイドのルール（sc_cat_item_guide_items）… 20件（2ガイドの合計。うち条件付き18件 / 条件なし2件）

OOTB でオーダーガイドは2件だけです。カタログアイテムが196件あるのと比べると、ガイドはごく少数の「まとめ申請」の入口として置かれている構成でした。

オーダーガイドは「特殊なカタログアイテム」（sc_cat_item を継承）

オーダーガイド（sc_cat_item_guide）は独立した別物ではなく、カタログアイテム（sc_cat_item）を継承する「特殊なアイテム」でした。name / category / sc_catalogs / picture / short_description といったアイテムの基本フィールドを、そのまま受け継ぎます。その上に、ガイド固有のフィールドを少しだけ足した構造です。

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

押さえどころは2つです。1つは、sc_cat_item_guide が sc_cat_item を継承していること。もう1つは、ガイドに含めるアイテムの実体が sc_cat_item_guide_items（label「Rule」）という別テーブルだということです。前者のおかげで、ガイドもカタログ画面に「申請ボタン」として並び、カテゴリやカタログに属せます。後者は Application File を継承する独立したテーブルで、guide（→sc_cat_item_guide）と item（→sc_cat_item）の参照を持つ「ルール行」です。ちなみに親の sc_cat_item 自体も Application File（sys_metadata）を継承しており、固有フィールドは76個ありました。

実際のガイド本体のフォームは次のとおりです。Name・Catalogs（Service Catalog）・Category・Two step・Cascade Variables といった項目が並びます。普通のカタログアイテムと同じ枠組みの上に、ガイド固有の設定が乗っていることが見て取れます。

ガイド本体の一覧は、次のURLから確認できます。

https://<YourInstance>/sc_cat_item_guide_list.do

ガイド固有のフィールド：two_step / cascade / include_items

オーダーガイドが sc_cat_item に足している固有フィールドは、7つ（sys_id 含む）だけでした。申請の束ね方を決める数個のスイッチが、ガイドの中身です。

主なものを言葉にすると次のとおりです。

two_step（Two step） … オンにすると「ニーズ記述 → オプション選択」の2段構えになります。今回の PDI の2ガイドはいずれも false でした。
cascade（Cascade Variables） … オンにすると、ガイドの最初の画面で答えた変数の値を、含まれる各アイテムの同名変数へ自動で引き継ぎます。今回の2ガイドはいずれも false でした。
include_items（Show Include Toggle） … 各アイテムに「含める／含めない」のトグルを表示します（既定 true）。
order_to_cart（Order to cart） … 直接カートへ入れるか（既定 false）。

name や category、所属カタログ（sc_catalogs）といった項目はガイド固有ではなく、親の sc_cat_item から継承したものです。だからガイドも、普通のアイテムと同じようにカテゴリに分類してカタログ画面に並べられます。

ガイド固有フィールドの定義は、次のURLで確認できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sc_cat_item_guide^elementISNOTEMPTY

含めるアイテムは「ルール」で出し分ける（sc_cat_item_guide_items）

ガイドに含めるアイテムは sc_cat_item_guide_items（label「Rule」）が持っています。各行は「どのアイテムを、どんな条件のときに含めるか」を表していました。固有フィールドは11個（sys_id 含む）で、よく使うのは次の4つです。

guide（→ sc_cat_item_guide）… どのガイドのルールか
item（→ sc_cat_item）… 含めるカタログアイテム
condition（If this condition is true）… この出し分け条件（ガイドの変数を参照する）
order（At this position）… ガイド内での並び順

ルールが持つ残り7つのフィールド

先の4つ以外にも、sc_cat_item_guide_items は7つのフィールドを持っています。内訳は quantity（数量）・show_quantity（数量欄を表示するか）・requested_by（申請者）です。残りは requested_for（利用者）・ignore_mandatory_eval（必須チェックを無視するか）・use_sc_layout（カタログのレイアウトを使うか）・sys_id です。

ここで効いてくるのが、ガイド自身が持つ「変数」です。ガイドもアイテムなので、ニーズ記述の画面に出す質問を変数（item_option_new）として持てます。今回の New Hire ガイドは、自分の変数を7つ持っていました。

hiring_manager（採用マネージャ・参照）
hiring_group（配属グループ・参照）
remote（リモート勤務か・Yes/No）
corp_office（勤務オフィス・参照）
standard_package（標準パッケージで足りるか・Yes/No）
laptop_type（端末タイプ・選択ボックス）
mobile_device_type（モバイル端末タイプ・選択ボックス）

ルールの condition は、これらガイド変数の値を見て「含める／含めない」を決めます。次は実機の Rule フォーム（Developer Laptop (Mac)）です。「laptop_type is Developer かつ standard_package is Yes」のとき、このアイテムを含める という条件が、フィルタ条件として明示されています。

この「質問の答え → 含めるアイテム」の出し分けを図にすると次のとおりです。

New Hire ガイドの8つのルールと、その出し分け条件が次の表です。条件が空のルール（New Email Account / Corp VPN）は、回答に関係なく常に含まれます。

ルールの一覧は、次のURLで確認できます（ガイドで絞り込み）。

https://<YourInstance>/sc_cat_item_guide_items_list.do?sysparm_query=guide=<ガイドのsys_id>^ORDERBYorder

今回の PDI では、New Hire ガイドが8ルール、Request Developer Project Equipment が12ルールでした。合計20ルールのうち18ルールに出し分け条件が入り、残り2ルールは条件なし（常に含める）です。

ニーズ記述から一括申請までの流れ

ここまでのテーブルがどう連動するかを、利用者の操作の流れとして整理すると次のとおりです。

ニーズ記述：ガイドの変数（remote? device type? など）に回答する
ルール評価：sc_cat_item_guide_items の condition が回答を見て、含めるアイテムを決める
オプション選択：含まれたアイテムを確認し、include トグルで微調整する
一括申請：1つの Request として、含まれた複数アイテムをまとめて申請する

この記事で実機確認したのは、テーブル構造とルールの出し分け条件までです。ニーズ記述→オプション選択→チェックアウトの実描画と、各アイテムへの RITM 生成は検証範囲外とします。cascade=true / two_step=true の実フォーム挙動も同じく範囲外です（OOTB の2ガイドはいずれも cascade・two_step とも false でした）。

実機で気づいたこと

カタログの「種類」に注文ガイドという値はない

sc_cat_item.type の選択肢は 1=Item / 2=Task / 3=Bundle / 4=Template / 5=Package の5つです。「Order Guide」はここに含まれていません。実機で sys_dictionary を見ると、オーダーガイドは type の選択肢を増やす方法を取っていませんでした。その代わりに、sc_cat_item を継承した専用テーブル sc_cat_item_guide として実装されています。

ルールの条件はANDだけでなくORも使える

実機の Rule を見比べると、condition は AND 条件だけではありませんでした。Developer Laptop (Mac) は laptop_type is Developer かつ standard_package is Yes という AND 条件です。一方 Standard Laptop は standard_package is No または hiring_group is sales という OR 条件でした。1つのガイドの中でも、アイテムごとに条件の組み方を変えられる自由度があります。

ServiceNowにおけるオーダーガイドのポイント

オーダーガイド（sc_cat_item_guide）は、独立した別物ではなく カタログアイテム（sc_cat_item）を継承する「特殊なアイテム」 です。name / category / 所属カタログなどはアイテムから継承します。固有フィールドは7つ（two_step / cascade / include_items / order_to_cart / script / validator / sys_id）だけでした。
ガイドに含めるアイテムの実体は、別テーブル sc_cat_item_guide_items（label「Rule」）です。各行が guide・item の参照と、出し分け condition、並び順 order を持ちます。
ルールの condition は、ガイド自身の変数（item_option_new）の値を参照して「含める／含めない」を決めます。New Hire ガイドで実機確認した条件は laptop_type=developer かつ standard_package=Yes でした。これを満たすとき Developer Laptop (Mac) が含まれます。
今回の PDI（Zurich / OOTB）では、オーダーガイドは2件、ルールは20件（条件付き18 / 条件なし2）でした。

オーダーガイドを調べる起点は、位置関係の把握です。ガイド本体（sc_cat_item_guide＝特殊なアイテム）と、含めるアイテムのルール（sc_cat_item_guide_items）は別テーブルになっています。そのうえで、ルールの condition がどのガイド変数を見ているかをセットで追うと早く進みます。

次に読むなら

次に確認したいのは3つです。cascade=true を有効にしたときに、ガイド変数が各アイテムの同名変数へどう引き継がれるか。two_step=true のときのニーズ記述→オプション選択の実フォーム挙動。そして一括申請で生成される Request（sc_request）と各 Requested Item（sc_req_item）の関係です。いずれも本記事で触れた「ガイド固有フィールド」「ルールの出し分け」の先にあたるので、別記事で扱う予定です。

用語

本記事で使った用語をまとめます。

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
オーダーガイド（Order Guide／注文ガイド）：sc_cat_item_guide。複数アイテムを1申請に束ねる仕組み
カタログアイテム（Catalog Item）：sc_cat_item。利用者がカタログから申請する1単位
ルール（Rule）：sc_cat_item_guide_items。ガイドに含めるアイテムと出し分け条件
ガイド変数：ガイド本体が持つ item_option_new（ニーズ記述で答える質問）
cascade（カスケード）：ガイド変数の値を各アイテムの同名変数へ引き継ぐ設定
two step（2ステップ）：ニーズ記述→オプション選択の2段構成にする設定

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

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

ガイド一覧        : sc_cat_item_guide_list.do
ガイド本体（フォーム）: sc_cat_item_guide.do?sys_id=<ガイドのsys_id>
ガイドのルール一覧  : sc_cat_item_guide_items_list.do?sysparm_query=guide=<ガイドのsys_id>^ORDERBYorder
ポータルのガイド画面 : sp?id=sc_cat_item_guide&sys_id=<ガイドのsys_id>
ガイド固有フィールド : sys_dictionary_list.do?sysparm_query=name=sc_cat_item_guide^elementISNOTEMPTY
ルール固有フィールド : sys_dictionary_list.do?sysparm_query=name=sc_cat_item_guide_items^elementISNOTEMPTY

参考資料

公式ドキュメント（Zurich）

Order guides … オーダーガイドの概要。複数アイテムを生成する1つのサービスカタログ要求を送信する仕組みとして説明されています。
Create an order guide … オーダーガイドの作成手順。ガイドの作成とルール（含めるアイテム）の追加の流れが説明されています。
Cascade an order guide variable … カスケード変数の概念。初期画面で入力した値を、注文した各アイテムの同名変数へ引き継ぐ仕組みとして説明されています。
SC Order Guide widget … Service Portal でオーダーガイドを表示する SC Order Guide ウィジェットの説明です。

参考にした日本語の解説（一般情報）

【ServiceNow】注文ガイドの基本（TechHarmony） … 注文ガイドの基本動作とニーズ記述画面の解説。
【ServiceNow】注文ガイドの実行順序（TechHarmony） … Order Guide Sequential Fulfillment による処理順序制御の解説。

ServiceNow サービスカタログ完全ガイド：申請フォーム1つが履行タスクに届くまで — 複数アイテムを束ねるオーダーガイドも、申請から履行までの流れの中では「特殊なカタログアイテム」の1つです。全体像はこちらで確認できます。

検証範囲とおことわり

確認した範囲：sc_cat_item_guide / sc_cat_item / sc_cat_item_guide_items の継承関係。sc_cat_item_guide と sc_cat_item_guide_items の固有フィールド数と、主要フィールド・参照先。sc_cat_item.type の選択肢。オーダーガイド2件・ルール20件（条件付き18 / 条件なし2）の件数。New Hire ガイドの自変数7件とルール8件の出し分け条件。Request Developer Project Equipment のルール12件。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲：cascade=true / two_step=true の実フォーム挙動（OOTB の2件はいずれも false）。ニーズ記述→オプション選択→チェックアウトの実描画と、各アイテムへの Request（sc_request）／ Requested Item（sc_req_item）生成。validator / script フィールドの実行。condition（variable_conditions）の評価がサーバ側かクライアント側かの内部実装。Order Guide Sequential Fulfillment プラグインの挙動。これらは別記事で扱います。

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