サービスカタログのプロパティ

チェックアウトを1段階にしたい、変数の入力欄をもっと広くしたい。こうした申請フォームの挙動を変えたいとき、ビジネスルールを書く前に確認する場所があります。ServiceNowでは、この種の挙動の多くをシステムプロパティが外から制御しています。Australia PDIでsc.またはcatalogを含むプロパティを実機で洗い出すと、申請処理（Request）専用の名前空間は1件も無く、すべてカタログエンジン共通の名前空間に間借りしていることが分かりました。

この記事の範囲

• sc.／catalog系のプロパティがどう分類できるか

• Request専用の名前空間が存在しない理由

• チェックアウト・変数の表示幅・エンタイトルメントに関連する代表的な設定

• 名前が一致しただけで無関係なプロパティ

• プロパティを変更する前に確認すること

プロパティで変えられること

• チェックアウトを1段階にするか2段階にするか

• 変数（入力項目）の表示幅

• エンタイトルメントを無視して注文・閲覧できるロール

• ポータルごとに下書き保存を出すか出さないか

• カートに追加できないカタログ項目のクラス

プロパティで何が変えられるか

sc.またはcatalogを含むプロパティを開くと、コードを触らずに変えられる挙動が並んでいます。

該当件数は160件、うち150件に公式の説明文（description）が付いています。割合にすると94%です。

公式の説明文が付いている

説明が無い10件は、値そのものがJSON文字列や設定用のテンプレートで、名前を見れば用途が分かるものが中心でした。説明文があるプロパティは、値の意味を推測せずに読めます。値を変える前にまずdescriptionを確認する習慣が、意図しない挙動を防ぎます。

• 参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方

プロパティの分類

160件を役割ごとに分けると、6つのまとまりになります。

最も多いのは表示系（項目の幅や外観）の32件、次にカート・注文系の21件です。全体の約半分を占める79件は「その他」で、検索の挙動や変数の細部動作、Catalog Builderの設定などが混在しています。

型で分けると、真偽値（boolean）が69件で最多です。次いで文字列（string）が45件、選択肢（choicelist）が36件、整数（integer）が9件、色（color）が1件と続きます。

真偽値の多さは、機能の有効・無効をプロパティ1件で切り替える設計が中心であることを示しています。文字列型の多くはロール名や項目名をカンマ区切りで持つ形式で、コードに埋め込まず値として外に出す作りです。要件が変わったとき、スクリプトを触らずに調整できます。

プロパティの名前空間に関連する設計

Problem管理にはproblem.*という専用の名前空間があります。同じ考え方なら、申請処理（Request）にもcom.snc.request.*のような名前空間があってよいはずです。実機で確かめると、そうはなっていませんでした。

nameLIKEcom.snc.requestは0件、nameLIKEsn_requestも0件です。Request固有の挙動を切り替えるプロパティは存在しません。

代わりに、160件のうち136件がglide.sc.で始まり、4件がcss.sc.で始まります。残り20件はcom.glide(app).servicecatalog.など個別の接頭辞を持ちます。

sc_request・sc_req_item・sc_taskというテーブルは存在するのに、それを制御するプロパティの置き場所は無く、カタログエンジン全体で共有するglide.sc.名前空間に間借りしています。申請という業務は、Service Catalogエンジンの出力を格納する器という位置づけの表れです。「Request固有の設定を探しているのに見つからない」ときは、requestではなくsc.やcatalogで検索し直します。

カート・注文に関連するプロパティ

チェックアウトの手順やオーダーガイドの扱いを決めるプロパティが21件あります。代表的な8件を挙げます。

glide.sc.checkout.twostepの公式説明はこうです。

（訳: 2段階のカタログチェックアウトモデルを使う（既定false））

既定値はfalseで、カートに入れた項目はそのまま1回の操作で申請されます。true にすると、注文前に確認画面を挟む2段階の流れに変わります。高額な項目や承認前提の申請が多いカタログでは、この値をtrueにする調整が有効です。

紛らわしいのはglide.sc.sp.twostepという似た名前のプロパティです。既定値はtrueですが、こちらは別の挙動を指します。

（訳: チェックアウト処理で注文確認のポップアップを表示する）

glide.sc.checkout.twostepは画面遷移そのものを2段階にする設定、glide.sc.sp.twostepはService Portalでの確認ポップアップの有無を決める設定です。両方とも名前に「twostep」を含みますが、対象とする画面も挙動も別です。

オーダーガイドについては、glide.sc.sog.inactive_order_guideが失敗記録の作成を制御します。

（訳: スクリプト形式のオーダーガイドを処理する際、オーダーガイドが無効な場合に失敗記録を作成する）

既定はtrueで、無効化されたオーダーガイドが呼ばれたときにsc_script_order_guide_failureへ記録が残ります。原因調査の起点になる設定です。

• 参考：複数アイテムを1申請に束ねる（オーダーガイド） … オーダーガイドの仕組みそのもの

変数の表示幅に関連するプロパティ

カタログ項目の入力欄（変数）は、型ごとに表示幅がプロパティで決まっています。

glide.sc.reference_width（参照型）とglide.sc.select_box_width（選択ボックス）は既定50%、glide.sc.date_width（日付）とglide.sc.date_time_width（日時）は既定25%と狭く、glide.sc.multi_line_text_width（複数行テキスト）やglide.sc.html_widthは既定100%で画面の横幅いっぱいに広がります。短い入力欄は横並びに、長い入力欄は単独で1行を使う設計です。

入力項目が多いカタログ項目で画面が縦に伸びすぎるときは、この値を見直します。参照型を50%から100%に広げれば、選択候補の表示名が長い項目でも省略されずに見えます。

近い役割の設定として、glide.sc.item.cannot_show_priceとglide.sc.item.cannot_add_to_requestもあります。前者は一覧で価格を表示しないカタログ項目のクラス、後者は既存の申請に追加できないカタログ項目のクラスを指定します。

（訳: 一覧で価格を表示しないカタログ項目のクラス名一覧）

既定値にはsc_cat_item_guide（オーダーガイド）やsc_cat_item_producer（Record Producer）が含まれます。これらは単体の商品ではなく、申請フォームそのものやガイドの入り口なので、価格表示の対象から外れています。

• 参考：注文フォームの制御は通常フォームと別テーブル（catalog_ui_policy） … 変数ごとの表示制御を担うもう1つの仕組み

エンタイトルメント・可視性に関連するプロパティ

誰がどのカテゴリを見られるか、誰が制限を無視して注文できるかを決めるプロパティが6件あります。

glide.sc.entitlement.overrideの公式説明を引用します。

（訳: カタログ内の通常のエンタイトルメントチェックを無視できるロールの一覧（カンマ区切り）。「itil」を指定すると、itilロールはエンタイトルメントで保護された項目も含めどれでも注文できるようになる）

既定値はadminです。障害対応でサービスデスクが緊急代理注文をする運用にするなら、itilをこの値に加える選択肢があります。ただしエンタイトルメントによる制限そのものを無効化する強い設定なので、追加は慎重に判断します。

glide.sc.category.canview.overrideも同じ考え方で、カテゴリの閲覧範囲を無視できるロールを指定します。

（訳: エンタイトルメントを無視してサービスカタログ内のどのカテゴリでも閲覧できるようにするロールの一覧（カンマ区切り））

既定値はadmin,catalog_adminです。カタログ管理者は、公開設定に関わらずすべてのカテゴリを見渡せる状態になっています。

残り4件のうちglide.sc.use_user_criteriaは既定trueで、カタログ項目・カテゴリの可視性判定にUser Criteriaを使うかどうかを決めます。対になるglide.sc.user_criteria_migrationは既定falseで、Entitlementから移行する期間だけ両方の関連リストを併用表示する互換設定です。移行が済んだ環境ではfalseのままにします。glide.sc.restrict.quantity.changesは既定trueで、承認が下りた申請アイテムの数量変更をcatalog_admin以外に禁止します。glide.sc.approval.hoverは既定trueで、承認待ちの承認者名がステージ表示のマウスオーバーに出る設定です。

• 参考：Employee Centerのコンテンツはどう出し分けられる？ User Criteria … 可視性制御のもう1つの経路

• 参考：サービスカタログのトラブル事例と解決 … 可視性が絡むトラブルの切り分け

ポータル・モバイルに関連するプロパティ

Service Portal・Employee Center・NOW Mobileそれぞれの表示や下書き保存を制御するプロパティが14件あります。代表的な8件を挙げます。

下書き保存の有効・無効は、ポータルごとに別々のプロパティで持っています。

（訳: spポータルで下書き保存を有効にする）

glide.sc.enable.save_as_draft.portal.sp・.esc・.mespの3件はいずれも既定trueで、Service Portal・Employee Center・モバイル向けポータルの3種類それぞれに下書き保存機能が有効です。入力途中で離脱しても、あとから再開できる状態が既定になっています。

NOW Mobile側には見た目に関する設定もあります。

（訳: NOW Mobileのカタログ申請画面におけるボタンの基調色）

glide.sc.mobile.primary_colorの既定値は#1f8476という緑系の色です。自社ブランドの色に申請画面のボタンを合わせたいとき、ここを書き換えます。

• 参考：カタログClient ScriptがService Portalでだけ動かない？ … ポータルごとに挙動が変わる別の実例

• 参考：既定ポータル Employee Center（/esc）はカタログを持たない … ポータル構成の前提知識

申請の一連の流れとプロパティの対応

ここまで見た設定を、利用者が実際にたどる画面の順番に並べ直します。

カタログを検索すると、glide.sc.search.rowcount（既定30）の件数までヒットが返ります。

（訳: 全体検索でサービスカタログから返される一致件数）

アイテム詳細では、価格を隠すクラスの指定（glide.sc.item.cannot_show_price）が効き、変数の入力では表示幅（glide.sc.reference_widthなど）が画面を決めます。カートに入れる段階ではglide.sc.allow.quantityが数量変更の可否を決めます。

（訳: カート内の数量選択を使えるロールの一覧（カンマ区切り）。空欄は全ユーザー）

既定は空欄で、全利用者が数量を変更できます。特定の商品だけ数量固定にしたい場合は、カタログ項目側の設定と組み合わせます。

チェックアウトを終えたあとの注文状況画面には、glide.sc.checkout.task.displayが関わります。

（訳: 注文状況ページ（注文成功後に表示される画面）に、申請に関連するタスクを表示する）

既定はtrueで、申請後の画面に履行タスクの進み具合が出ます。検索からチェックアウト後の確認まで、画面が変わるたびに別のプロパティが挙動を決めている構造です。

プロパティを変更する前の確認事項

160件のうち、実際に触る機会が多いものを整理しました。

1. 説明文を読む：150件に公式説明があります。値の意味を推測で決めません

2. 似た名前のプロパティを区別する：checkout.twostepとsp.twostepのように、名前が似ていても対象画面が違う組み合わせがあります

3. 値に並ぶロール名・項目名の実在：カンマ区切りのリスト型は、存在しないロール名を書いても素通りします

4. 変更の記録：プロパティの変更は更新セットに入ります。移送の対象になるかを確認します

プロパティは画面から1行変えるだけで挙動が変わります。手軽な反面、変更の理由が残りません。誰がなぜ変えたかを別途記録する運用を決めておくと、後任の担当者が困りません。

• 参考：サービスカタログの運用手順書 … 変更後の申請1件を通しで確認する手順

名前が一致しただけの無関係なプロパティ

nameLIKEsc.という検索条件には、Service Catalogと関係ないプロパティも紛れ込みます。160件のうち8件がこれに当たります。

代表はsn_vsc.*で始まる4件です。

vscはVulnerability Response・Security Centerの略ですが、文字列の中にsc.が偶然含まれるため、nameLIKEsc.の条件に一致します。残り4件は、CMDB Discoveryが収集するデータベーススキーマの一覧（DBカタログ）の表示設定や、Data Catalog（データガバナンス機能）の設定です。どちらもService Catalogとは別の機能です。

nameLIKEは部分一致なので、意図しない語まで拾います。プロパティを検索するときは、ヒット件数が想定より多い場合、内容を1件ずつ確認してから集計に含めます。

実機で気づいたこと

変数の表示幅プロパティには文章の説明が無い

glide.sc.reference_widthやglide.sc.date_time_widthなど、表示幅を扱うプロパティのdescriptionを確認すると、「Reference」「Date/Time」のような変数タイプ名だけが入っており、文章の解説はありませんでした。

150件のうち大半は文章の説明文を持ちますが、表示幅系だけは値が自明だからか、型名を短く入れるだけで済ませています。おそらく変数タイプごとに機械的に生成されたプロパティ群だからと考えられます。

値の意味が分かりにくいプロパティに当たったら、名前だけでなくdescriptionの中身が文章なのかラベルなのかも確認します。ラベルだけの場合は、値そのもの（数値や選択肢）から挙動を読み取ります。

似た名前の2つのtwostepが別々の画面を制御する

glide.sc.checkout.twostepとglide.sc.sp.twostepは、どちらも「twostep」という語を含みますが、前者はチェックアウト全体を2段階の画面遷移にするかどうか、後者はService Portalでの確認ポップアップの有無を決めます。既定値も前者がfalse、後者がtrueと食い違っています。

同じキーワードが複数の機能単位で再利用されているため、片方だけを変えて「2段階になった」と誤解する余地があります。チェックアウトの挙動を調整するときは、twostepで検索して出てきたプロパティ全部のdescriptionを読んでから着手します。

検索条件の部分一致が無関係な設定を8件連れてくる

nameLIKEsc.で検索すると、Vulnerability ResponseやCMDB Discoveryなど、Service Catalogと無関係なプロパティが混ざります。件数を数える作業では、この8件を除いてから合計を出す必要がありました。

原因はsc.という短い文字列が、他の機能の名前（vscなど）にも部分一致することです。プロパティの棚卸しをするとき、検索語が短いほど誤ヒットの確率は上がります。件数を報告する前に、ヒットした一覧を目視で確認する工程を省けません。

プロパティを調整するときの検討順序

プロパティを調整するとき、確認する順序を決めておくと迷いません。

1. 説明文を読む：150件に公式説明がある。値を変える前に意図を確認する

2. チェックアウトの段階：checkout.twostepとsp.twostepを、対象画面を区別しながら決める

3. 変数の表示幅：入力項目の型ごとに_width系プロパティを見直す

4. エンタイトルメントの上書き範囲：entitlement.overrideにどのロールを含めるかを決める

5. ポータルごとの下書き保存：3種のポータルで有効・無効を揃えるか個別にするか決める

6. 検索条件の誤ヒット：sc.で検索した結果から無関係なプロパティを除く

用語

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

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

• システムプロパティ：sys_properties。インスタンス全体の設定値を保持するテーブル

• 変数：カタログ項目の入力欄。item_option_newに定義が格納される

• オーダーガイド：複数のカタログ項目を1回の申請にまとめる仕組み

検証範囲とおことわり

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

• 件数と既定値はすべてOOTBの状態です。本番環境やカスタマイズ済み環境では異なります

• プロパティを実際に変更して挙動が変わることは確認していません

• 「その他」に分類した79件の個別の役割までは確認していません

• 各プロパティを読んでいるビジネスルールの実装は、本シリーズ第6巻「サービスカタログの自動設定構成」で扱います

• フォーム側のUIポリシー・クライアントスクリプトの個別設定は、本シリーズ第5巻「サービスカタログの基本設定」で扱います

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

• sc.／catalog系のプロパティ一覧：/sys_properties_list.do?sysparm_query=nameLIKEsc.^ORnameLIKEcatalog

• 説明が入っているものだけ：/sys_properties_list.do?sysparm_query=nameLIKEsc.^ORnameLIKEcatalog^descriptionISNOTEMPTY

• Request専用の名前空間が無いことの確認：/sys_properties_list.do?sysparm_query=nameLIKEsn_request^ORnameLIKEcom.snc.request

• 型ごとの件数：/sys_properties_list.do?sysparm_query=nameLIKEsc.^ORnameLIKEcatalog^GROUPBYtype

• 表示幅系のプロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.sc.^nameLIKE_width

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

この記事で引用した説明文は、ServiceNowが製品に同梱しているプロパティの説明です。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEsc.^ORnameLIKEcatalog^descriptionISNOTEMPTY

関連記事

• システムプロパティ（sys_properties）は設定値の置き場 … プロパティそのものの扱い方

• 複数アイテムを1申請に束ねる（オーダーガイド） … オーダーガイドの仕組みそのもの

• 誰も頼んでいないカタログを洗い出す手順 … カタログ項目の運用実務編