ServiceNowのService Catalogは「フォームを作って公開すれば終わり」ではなく、変数設計・UI挙動・提出後の処理・利用チャネル差・運用が噛み合って初めて“使われる申請”になります。ZurichではCatalog Builderの強化などで作りやすくなった一方、作り手が増えるほど「似た項目の乱立」「どこで動くスクリプトか分からない」「提出後に変数が消えたように見える」といった事故も起きやすくなります。
この記事はCSA学習者の方が、暗記ではなく仕組みとして理解できるように、Catalog Item実装で混乱しやすいポイントを実務目線で整理します。公式ドキュメントに沿って、Zurichで特に意識したい点も織り込みます。
申請が使われない理由は実装の前提ズレにある
Catalog Itemの実装で一番つらいのは「公開したのに使われない」「使われたけど情報が足りない」「担当者が毎回ヒアリングし直す」という状態です。原因はたいてい、フォームの見た目より前の段階にあります。
- 申請の入口が複数チャネルにまたがるのに、どこで動く設定か整理していない
- 変数が増えすぎて入力負担が高い でも裏側の処理は軽い
- 参照項目の候補が多すぎて選べない、逆に絞りすぎて選べない
- 提出後の処理で必要な情報がタスクに渡らず、結果的に手作業になる
ZurichではCatalog Builder側で複雑なCatalog Itemを作りやすくする方向のアップデートがあり、作り始めのハードルは下がっています。だからこそ、作れることと、運用できることを分けて考えるのが大事です。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
設計で9割決まる 何をCatalog Itemにして何を分離するか
Catalog Itemに寄せすぎない
Catalog Itemは申請を集約できる反面、何でも詰め込むと破綻します。次の判断が実装前に必要です。
- 本当に「申請」なのか、単に「データ登録フォーム」なのか
- 依頼の種類が増えたとき、項目が増えるのか、Itemが増えるのか
- 入力の複雑さを「質問の分岐」で吸収するのか、「別Item」で分けるのか
この判断が曖昧だと、後から変数が膨れ上がり、Catalog Client ScriptやCatalog UI Policyで無理やり制御することになります。制御が増えるほど、次に触る人が理解できなくなります。
Zurichの前提 Next Experienceでの見せ方も設計に入れる
ZurichではNext Experience系でのカタログ体験を強化する流れがあり、UI Builderに「Catalog browse component」を使ってカタログの閲覧体験を組み込みやすくなっています。
つまり、実装者は「Service Portalだけ見ればOK」ではなく、今後どの体験で見せるかも意識した設計が必要です。
変数設計の注意点 変数セット 命名 参照選択肢
変数セットは便利だが 命名ルールがないと事故る
変数セットは複数のCatalog ItemやOrder Guideで再利用でき、修正も一括反映できるのが強みです。
ただし、再利用が進むほど「名前が似ているセット」「どれを使うべきか分からないセット」が増えます。
公式ドキュメントでも、変数セットの作成時にいくつかの制約が示されています。たとえば、同一Item内の内部名の衝突や、変数名と変数セット名の衝突などは、後からスクリプトやポリシーで参照するときに混乱の元になります。
おすすめのルール例（実務で効きます）
- 変数セットの内部名は用途接頭辞を付ける（例：
vs_hr_、vs_it_） - 変数の内部名は意味が変わらない単語に固定（表示ラベルは変更可）
- 「似た質問」は変数を増やすのではなく、選択肢や参照元の設計を見直す
ポイントは、見た目ではなく内部名の安定です。スクリプトや条件式は内部名に依存しがちなので、ここが揺れると実装が壊れます。
参照項目は Reference Qualifierを最初から設計する
Referenceフィールドは便利ですが、候補が多すぎるとユーザーが選べません。逆に絞りすぎると「必要な人が出ない」になります。
このバランスを取るのがReference Qualifierです。参照候補を絞り込む考え方自体は、ServiceNow全体でよく出てくる前提知識です。
ありがちな落とし穴
- “全ユーザー”が出てくる参照で、探すだけで疲れる
- 非アクティブまで混ざり、選択ミスが起きる
- 条件が複雑になりすぎて、どこで絞っているか分からなくなる
ZurichのService Catalogリリースノートでも、Catalog Builderで「動的・高度なReference Qualifier」や「scripted default value」などを扱う文脈が出てきます。作れる自由度が上がるほど、条件の責務（どこで絞るか）を決めないと保守不能になります。
ソート順は体験に直結する
参照候補が出る順番は地味ですが、入力ミスや入力時間に直結します。Zurichではlookup系の並び順を制御するための属性が追加されています。
「なぜこの順で出るのか」を説明できる状態にしておくと、利用者からの不満が減ります。
UI挙動の注意点 Catalog Client ScriptとCatalog UI Policy チャネル差分
Catalog Client Scriptの基本 UI Typeを雑にしない
Catalog Client ScriptはCatalog Itemまたは変数セットに適用でき、UI Typeを指定できます。
ここで混乱しやすいのが「どの画面で動くのか」です。特にService Portalを使っている環境では、UI Typeを適切にしないと動いていないように見えることがあります。
Service Portalでは、Catalog Client Scriptを使う場合、UI TypeをMobile/Service PortalまたはAllにする、といった整理が公式にも示されています。
「開発環境のデスクトップでは動いたのに、ポータルでは動かない」はこの手の設定ミスが多いです。
実装メモ
- まず「どの体験で入力させるか」を決める
- 次に、その体験に合わせてUI Typeを合わせる
- 最後に、スクリプトは最小限にして、条件は変数設計で吸収する
Catalog UI Policyは スクリプトより先に使う
Catalog UI Policyは、フォーム上の表示・必須・読み取り専用などを制御します。一般のUI Policyと同じく、スクリプトなしでも多くの要件を満たせます。
まずは「スクリプトを書かずにできること」を押さえると、保守性が大きく上がります。
さらに、（Zurichに限らず）UI PolicyにはRun scriptsの考え方があり、条件成立/不成立でonChange相当の処理を動かすこともできます。
ただし、ここにロジックを詰め込み始めると、Catalog Client Scriptと責務が被ってカオスになります。
おすすめの棲み分け
- 表示/必須/Read-onlyなどのUI制御 → Catalog UI Policy中心
- 値の自動設定や参照絞り込みの補助 → まず設計、次に必要最小限のClient Script
- 複雑な分岐や外部参照 → なるべく提出後の処理（Flow等）に寄せる
Catalog Builderで作りやすくなったぶん ルールがないと乱立する
ZurichのService Catalogでは、Catalog Builderで複雑なCatalog Itemを作成しやすくする機能が強調されています。Client Scriptの作成/編集、Reference Qualifierの設定などができるため、現場では「作れる人」が増えます。
だからこそ、チーム内で次のような最低限のルールが必要です。
- 変数セットは原則再利用、ただし用途が違うなら新規
- スクリプトは共通化できるなら変数セット側へ寄せる
- “とりあえずscript”を禁止し、目的と代替案をコメントに残す
提出後の処理設計 Flowとタスク 変数の受け渡し セキュリティ
提出後に何が作られるかを理解しておく
Catalog Itemは「提出」すると裏側でレコードが生成され、承認やタスクが作られて処理が進みます。この流れを理解していないと、実装の判断がブレます。
たとえば「入力項目を増やしてでも正確な分類をさせたい」のか、「提出後に担当が判断すればよい」のかは、タスク設計とセットで決める話です。
変数はタスクやチケットに勝手には載らない
ここが初学者が一番ハマりやすい点です。Catalogの変数は“変数として”保存されますが、タスク側のフィールドに自動で転記されるとは限りません。
結果として、提出後に作られたタスクだけ見ている人が「情報がない」と感じます。
実務では次のどちらかを選びます。
- タスク/チケットに必要な要点だけを転記する（短く、検索できる形に）
- 変数は変数のまま参照する運用にする（一覧性より正確性）
どちらが正しいではなく、運用の観点で選ぶのがポイントです。
ここが曖昧だと、現場で「結局電話で聞く」が復活します。
セキュリティと見せ方はセット
Catalog Itemは利用者が広いほど、意図しない情報の露出リスクも上がります。
特に参照項目（ユーザー、CI、契約、部門など）は、参照先のACLや参照絞り込みが噛み合っていないと「見えてはいけない候補」が出てしまいます。
CSAの学習でも、ACLや参照の仕組みは前提として扱われやすい領域です。Catalog実装で実感すると理解が一気に進みます。
「なぜ候補が出ないのか」「なぜこの人だけ見えるのか」を説明できるようになると、実務でも強いです。
学習として体系化したい場合は Udemyを一例にする
ここまでの内容は、断片的に覚えるより「Service Catalogの全体像」と「UI制御の基本」と「提出後処理」を繋げて理解したほうが伸びます。
体系的に学べる教材の一例として、UdemyのServiceNow講座（Service CatalogやFlow Designerを扱うもの）を1本決めて、手を動かしながら用語を一本線にするやり方は相性が良いです。公式ドキュメントで概念を確認しつつ、動画で画面操作を追えるので、初学者でも迷子になりにくいです。
運用とテスト Zurichで増えた作成自由度に耐えるルール化
ドラフトの扱い 変更時の事故を減らす
Zurichのリリースノートには、保存されたドラフトの削除挙動を制御するプロパティが記載されています。
運用上の観点では、次のような事故を想定しておくと安全です。
- 作成途中のドラフトが残って、別の人が古い状態で編集してしまう
- 変更管理のタイミングで、どれが最新版か分からなくなる
現場のルールとしては「公開前はドラフト管理」「公開後は変更申請とセットで編集」「編集者を限定」など、シンプルに縛るのが効きます。
実装チェックリスト 公開前に最低限ここを見る
フォームの確認
- 変数名（内部名）がルール通りで、衝突していない
- 参照項目が過不足なく絞れている
- 入力が長くなる箇所は説明文や選択肢で支援できている
UI挙動の確認
- Catalog Client ScriptのUI Typeが利用チャネルに合っている
- UI制御はまずCatalog UI Policyで実現できている
- PortalとNext Experienceで挙動差が出る部分はメモが残っている
提出後の確認
- タスク側に必要な情報が届く設計になっている（転記 or 参照運用）
- 承認や担当割り当ての条件が“変数に依存しすぎていない”
- ACLや参照候補の露出が問題ない
作る人が増える前提で 仕組みを残す
ZurichではCatalog Builderの強化で「作成者の裾野」が広がります。
この状況で品質を守るには、属人化ではなく、次の2つが効きます。
- “テンプレItem”を用意して、変数命名・UI Policyの基本形を固定
- “設計メモ”を必須にして、責務（どこで制御するか）を文章で残す
実務的には、これだけで保守コストがかなり下がります。
ZurichのCatalog Itemは 作れるからこそ設計と運用で差が出る
ZurichのService Catalogは、Catalog Builderの強化などで複雑なCatalog Itemを作りやすくなっています。
一方で、自由度が上がるほど「変数の乱立」「スクリプトの責務重複」「チャネル差分の見落とし」「提出後に情報が届かない」といった、実装後の混乱も増えがちです。
大事なのは、暗記ではなく次の因果を理解することです。
- 変数設計が安定すると、UI制御と提出後処理がシンプルになる
- UI Typeやポータル対応を整理すると、「動かない」が減る
- 参照絞り込みと並び順は、入力体験とミス率に直結する
- 作成者が増える前提で、命名・テンプレ・メモを仕組みにする
このあたりをチェックリスト化して回せるようになると、Catalog Itemは「増やすほど地獄」ではなく「増やしても運用できる資産」に変わります。学習としても、Service CatalogはUI制御・ACL・Flowなどの理解が繋がりやすいので、CSAの基礎固めにも役立ちます。
必要なら、あなたのブログ既存記事（たとえばUI PolicyとClient Script、Flow、ACLあたり）との内部リンク設計も含めて、同一テーマ重複を避けながら“シリーズ化”できる形に組み替え案も出します。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
