サービスカタログのトラブル事例と解決
「カタログアイテムを公開したのに利用者から見えないと言われる」「RITMは進んでいるのに親のRequestが残り続ける」。導入直後の相談はこの2つに集約されます。原因の多くは不具合ではなく、複数のテーブルにまたがる設定・状態の見落としです。Australia の PDI をデフォルト設定のまま開き、よくある症状から原因の場所を確かめました。
検証環境：Australia PDI / OOTB / 2026-09-01 確認
扱う症状
症状から原因へたどる順序
カタログアイテムの公開を決める複数の設定
state と stage という2つの状態フィールドの食い違い
この記事で扱う症状
カタログアイテムの公開は8つの関門を上から順に確認する
Close Parent if Required という仕組みは stage の変化だけを条件にしており、state を進めても親は閉じない
履行エンジンが未設定のカタログアイテムは、注文されても自動では何も起きない
症状から原因へたどる順序
サービスカタログの相談は、まず4段階に分けます。
この順序で確認すると、調べる場所が絞れます。
見えない・申請できない：カタログ・カテゴリ・アイテムの公開設定
申請後に進まない：履行エンジンの設定、承認の状態、state と stage の食い違い
画面によって挙動が違う：変数の表示、Service Portal限定の不具合
利用者に伝わらない：通知の生成と送信
「申請が来ない」という相談にいきなり通知設定から入ると、原因にたどり着きません。多くの場合、原因はそもそもカタログアイテムが見えていないことにあります。
カタログアイテムが見えない・申請できない
症状：カタログアイテムを1件作って公開したのに、Employee Center のどこにも出てきません。
原因：公開を決める設定はカタログ・カテゴリ・アイテムの3階層にあり、加えてロールとUser Criteriaという絞り込みが重なります。合わせて8つの関門です。
このPDIでは、sc_catalog は2件とも active でした。sc_category は47件中34件が active です。カテゴリより下の関門で止まっているケースが大半という計算になります。
カテゴリ自体のactiveとrolesに問題がなくても、配下にactive=trueのアイテムが1件もなければ同じ症状が出ます。Hardwareの子カテゴリであるTabletsで確認できます。Tabletsはactive=true・roles未設定で、設定だけを見れば公開されているカテゴリです。配下のsc_cat_itemはApple iPad 3とGoogle Nexus 7の2件で、どちらもactive=falseでした。
表示される文言は「You do not have permission to see this category」です。アイテムが非公開のときに出る「You are either not authorized or record is not valid.」とは異なります。この状態を作っている具体的な仕組み（ACLかBusiness Ruleか）は検証範囲外ですが、カテゴリの設定に異常が見当たらないときに次に確認すべきは、配下のactiveなアイテム数です。
active な sc_cat_item は152件でした。このうち category が未設定のものが23件、sc_catalogs（掲載先カタログ）が未設定のものが18件あります。掲載先を指定し忘れると、レコードは存在していても一覧にも検索にも出てきません。エラーも出ないため、作った本人が気づきにくい設定漏れです。
hide_sp という、Service Portal系の画面だけでアイテムを隠すフィールドもあります。3件が該当していました。active=true のままでも、hide_sp=true にすれば同じ効果が出ます。試しに該当アイテムを開くと、非公開のアイテムとまったく同じ文言が返ってきます。
原因はまったく別のフィールドなのに、利用者側の画面では区別が付きません。ここまでの6関門を抜けても、まだ2段階残っています。次は権限です。roles（active 152件中149件が何らかの値を持つ）と、User Criteria です。含める条件が256件、除外する条件が472件あり、合わせて728件が可視性を絞り込んでいます。ロール制限の検証はadminアカウントでは正しく行えません。管理者は多くの条件を素通りするため、対象ロールを持つ一般アカウントで最終確認します。
参考：Access Analyzer：「見えない」の理由を層で切り分ける … ロール判定を層ごとに追う道具
参考：誰も頼んでいないカタログを洗い出す手順：死蔵率98.6%の実測 … 公開はされていても使われていない項目の洗い出し方
解決：8つの関門を上から順に確認します。
カタログのactive
カテゴリのactive
カテゴリ配下にactiveなアイテムがあるか
アイテム自体のactive
category・sc_catalogsへの紐付け
hide_sp
roles
User Criteria
1つずつ潰せば、原因は必ずどこかで見つかります。途中で止まった段階が、そのまま相談の答えになります。
申請したのに何も起きない
症状：カタログアイテムを注文してRITMは作成されたのに、承認も履行タスクの生成も始まりません。
原因：履行を自動で進めるエンジンが、カタログアイテムごとに設定されていません。
このPDIの sc_cat_item 204件のうち、旧来の Workflow と後発の Flow Designer のどちらも未設定のものが85件（41.7%）あります（詳しい内訳は基本設定編で扱います）。RITMを実際に起動させる仕組みは、stage というフィールドが request_approved になった瞬間に動く2本のビジネスルールです。
条件式を読むと、両方とも current.stage=='request_approved' を見ています。current.cat_item.workflow と current.cat_item.flow_designer_flow のどちらも空なら、どちらのビジネスルールも発火しません。この状態のRITMを実際に確認すると、stage は初期値の waiting_for_approval のまま止まっていました。
エンジンが1件も設定されていないカタログアイテムは、注文が入っても承認以降が自動で1歩も進みません。担当者が手作業でタスクを作るしかない状態です。
参考：Catalog Task はどこから来るか（履行計画） … タスクが自動生成される仕組みの正しい形
解決：確認する順序は次のとおりです。
対象アイテムの cat_item.workflow 欄と cat_item.flow_designer_flow 欄を見る
両方とも空なら、そのアイテムはエンジンによる自動履行を持たない設計だと判断する
どちらかに値があれば、RITMの context 欄・flow_context 欄を見て、エンジンが実際に起動したかを確認する
起動していなければ、stage が既定値のまま止まっていないかを確認する
対処は単純です。新規カタログアイテムを作るときは、公開前に workflow か flow_designer_flow のどちらかを設定します。既存の未設定アイテムは、履行担当が手作業でタスクを作る運用にするか、Flow Designer側で標準の履行フローを割り当てるかを判断してください。棚卸しの優先順位も決めておくと効率が上がります。注文実績のあるアイテムから手を付け、注文されたことのないアイテムは後回しにします。効果を確認する機会が無いまま設定を追加しても、動作の検証ができません。
承認したのに次へ進まない
症状：承認は完了したはずなのに、RITMのstageが進みません。
原因：構えは2段です。RITM自体の承認と、履行タスク側の承認が別に走ります。1段目だけを見て「承認は終わった」と判断すると、まだ2段目が残っている場合があります。
解決：確認する順序は次のとおりです。
対象RITMの sysapproval_approver を見て、承認者全員の state が approved かを確認する
RITM自体の approval 項目（task継承の4値）を確認する
履行タスク側にも承認が必要な設計になっていないかを確認する
すべて approved でも進まない場合は、前の症状（履行エンジン未設定）に該当していないかを疑う
この2段構えの詳しい仕組みは別記事にまとめています。
参考：承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） … 2段構えの全体像
RITMは進むのにREQが閉じない
症状：RITMのstateをClosed Completeに変えたのに、親のRequestがいつまでもactiveのままです。
原因：親を閉じる処理は stage というWorkflow型のフィールドだけを条件にしています。state（担当者が手で進められる数値フィールド）を進めても、この処理は動きません。
Close Parent if Required というビジネスルールの条件式は current.stage.changes() && (current.stage=='complete' || ...) です。state の変化はまったく見ていません。
実際のデモデータでも、この食い違いが見つかりました。あるRITMは state がWork in Progressまで進んでいるのに、stage はまだ request_approved のままでした。前の症状で見た「エンジン未設定」のRITMも同じ構造です。stage の既定値から一度も動いていないため、いつまでも Close Parent if Required の条件を満たしません。
state と stage は、更新されるきっかけが別です。state は担当者が画面やスクリプトで直接書き換えられます。stage はエンジン（WorkflowかFlow Designer）が処理を進めたときだけ書き換わります。エンジンが動いていない、あるいは処理が途中で止まっているRITMは、担当者がどれだけstateを進めても、親のRequestには伝わりません。
解決：RITMを手作業でCloseするときは、state だけでなく stage も終了系の値に変えます。エンジンが動いているアイテムなら、通常はエンジン自身がstageを進めるため、この操作は不要です。
スクリプトで一括クローズする処理を作る場合も同じ注意が必要です。state の更新だけを書いたスクリプトは、見た目上は成功しても親のRequestを閉じません。stage の更新を必ずセットで含めるようにしてください。あわせて、stageの値が長期間変わっていないRequestを一覧で洗い出す運用を、履行担当のチェックリストに加えておくと安心です。件数がそれほど多くなければ、月次の棚卸しでも十分に対応できるはずです。
変数が表示されない
症状：RITMの画面には申請時の入力項目（変数）が表示されるのに、履行タスク（sc_task）の画面には出てきません。
原因：RITM画面と履行タスク画面は、変数の値を読みに行く関連テーブルが違います。表示先によって参照経路が分かれているため、片方だけに値が出るという状態が起こります。
解決：関連テーブルの違いを含めた切り分け手順は別記事にまとめています。まずは履行タスクのフォームに変数編集用の関連リストが表示されているかどうかを確認します。
参考：RITMには変数が出るのにsc_taskに出ない？ 表示を決める関連テーブルを実機で突き止める … 参照テーブルの違いを実機で特定
Portalでだけ動かない
症状：カタログアイテムのClient Scriptが、バックエンドの画面では動くのにService Portal（Employee Center含む）では動きません。
原因：catalog_script_client には ui_type という項目があり、どの画面種別で実行するかを個別に指定する仕様です。バックエンド用に作ったスクリプトは、Portal向けの指定が漏れていると動きません。
解決：対象スクリプトの ui_type を確認し、Service Portal（またはAll）を含めているかを見ます。バックエンドのAPIとPortal側のAPIは呼び出し方も異なるため、単純にコピーしただけでは動かないことがあります。
参考：カタログClient ScriptがService Portalでだけ動かない？ UI Typeを実機の3画面で切り分ける … 3画面での挙動差を実機で比較
利用者に通知が来ない
症状：RITMが承認されても完了しても、申請者にメールが届きません。
原因：工程は2段です。通知の仕組みは「生成」と「送信」という別の工程に分かれます。定義が動いていても、SMTP送信の設定が別に必要です。notify（既定 Do Not Notify）という項目を疑いたくなりますが、sc_request と sc_req_item の通知定義はどちらも notify の値を条件にしていません。
sc_req_item の通知は18件あります。ただし多くはカタログの履行通知ではありません。App Engine Studioのアプリ申請機能が同じテーブルを間借りしているため、履行と無関係な通知も同じ一覧に混じります（詳しくは連携編で扱います）。件数だけを見て「通知が多い」と判断すると、実際にカタログ履行で使われている定義を見落とします。
解決：確認する順序は次のとおりです。
sys_email を見て、メールが生成されているかを確認する
生成されていれば、通知定義自体は動いている
type が送信待ちのまま残っていれば、SMTP送信側の設定を疑う
生成されていなければ、通知定義が active かと条件式を確認する
対象の通知がカタログ履行向けかどうかを、event_name で見分ける
生成と送信を分けて確認すると、通知定義とメールサーバ設定のどちらが原因かを1手で判別できます。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときの経路確認
実機で気づいたこと
同じエラー文が複数の原因で出る
非公開のカタログアイテムを開いても、hide_sp で隠したアイテムを開いても、Employee Centerに表示される文言は同じ1行でした。原因はまったく別のフィールドです。
この設計は、利用者に内部の理由を見せないという意味では合理的です。一方で調査する側にとっては、画面のメッセージだけでは原因を絞り込めないという不便さになります。
画面は疑えません。相談を受けたら、メッセージだけで判断せず、対象アイテムのレコードを開いて active と hide_sp の両方を確認します。どちらか一方だけを見て終わらせないことが、切り分けを早くする最初の一歩です。
カテゴリの中身がゼロだと別のエラー文になる
カテゴリ自体は active でロールも空という設定でも、配下に active なカタログアイテムが1件も無いことがあります。このカテゴリを直接開くと、アイテム側の文言とは違う「You do not have permission to see this category.」という表示になります。
カテゴリの設定画面だけを見ると公開されているように見えるため、この文言はロール制限やUser Criteriaが原因だと誤解しやすい表示です。実際には8関門のうち3番目、配下のactiveなアイテム数がゼロという関門で止まっているだけの場合があります。
「カテゴリの設定は合っているのに開けない」と相談されたら、権限設定を疑う前に、そのカテゴリに属するactiveなアイテムが何件あるかを数えます。エラー文言がアイテム側と違う時点で、切り分ける先はロールではなくカテゴリの中身だと見当が付きます。
stateとstageは別々のきっかけで進む
RITMには進み具合を表すフィールドが2つあります。state は担当者が直接書き換えられる数値フィールドです。stage はエンジンの処理結果を反映するフィールドで、担当者が普段の画面で意識することは多くありません。
親のRequestを閉じる処理も、履行タスクを生成する処理も、多くはこの stage の変化を条件にしています。担当者が state だけを進めて満足していると、裏側の処理は何も動いていない場合があります。
RITMを手作業でクローズする運用を作るときは、state を変えるスクリプトやフローに stage の更新も必ず含めます。片方だけを更新する処理を作ると、あとで「進んでいるはずなのに親が閉じない」という同じ相談が繰り返されます。
有効なエンジンを持つアイテムでもstageが止まることがある
Flow Designerの flow_designer_flow が設定されているカタログアイテムでも、stage が古い値のまま残っているRITMが実機に存在しました。エンジンの設定があることと、エンジンが実際に最後まで走り切ったことは、別の話です。
途中でフローが中断した場合や、デモデータのように処理を経由せず直接投入された場合は、エンジンが設定されていても stage は進みません。
エンジンの設定有無だけをチェックリストに入れて安心せず、実際の stage の値も定期的に確認します。エンジンが「ある」ことと「動いた」ことは別の確認項目として扱います。
デモデータをそのまま参考資料に使うときにも、この点を意識しておいたほうがよさそうです。デモのRITMは実際の申請フローを経由せず、初期データとして直接投入されている場合があります。その結果、通常の運用では起こりにくい状態の組み合わせが混じることがあります。デモ環境で見た数値をそのまま実運用の目安にせず、実際の申請を1件通してから傾向を確かめるほうが確実です。
導入時の確認リスト
ここまでの内容を、相談を受けたときに確認する形にまとめました。
7つの症状のうち、単純な設定不足で説明できるものは3つです。残りはテーブルをまたいだ状態の食い違いが原因になっています。1つの画面や1つのフィールドだけを見て「異常なし」と判断しないことが、切り分けを早くする共通のコツです。
実務で順番に検討する箇所
導入直後の確認は、次の順序で進めます。
カタログアイテムの公開設定：8つの関門を上から確認し、まず「見えるか」を確定する
履行エンジン：新規アイテムの公開前に、workflowかflow_designer_flowのどちらかを必ず設定する
承認の2段構え：RITM単体の承認だけで完了と判断しない運用を周知する
state と stage の同期：手作業でクローズするスクリプトには、両方の更新を含める
変数・Portal限定の不具合：発生したら参照テーブルとui_typeをまず疑う
通知：生成と送信を分けて確認する運用をサポート窓口の手順に入れる
設定変更の移送：有効化したworkflow・flow_designer_flowの設定は更新セットで本番へ運ぶ
参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 検証環境の設定を本番へ運ぶ仕組み
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
RITM：Requested Item（sc_req_item）。1件のカタログアイテムの申請単位
stage：内部型がWorkflowの特殊フィールド。エンジンの実行結果がそのまま反映される
hide_sp：Service Portal系の画面だけでカタログアイテムを隠すフィールド。activeとは独立している
User Criteria：カタログアイテムやカテゴリの公開範囲を絞り込む条件部品
検証範囲とおことわり
検証環境：Australia PDI / OOTB / 2026-09-01 確認
件数と設定状況はすべてOOTBの実測です。本番環境やカスタマイズ済み環境、プラグイン構成が異なる環境では数値も挙動も変わります
各症状は定義・条件式・デモデータの実測から原因を整理したものです。実際に注文からクローズまで1件を通して動かす検証は行っていません
カタログの設定（active・hide_sp・roles・User Criteria等）は変更していません
Tabletsカテゴリを開いたときの権限エラー表示について、原因となる具体的なロジック（ACL・Business Ruleなど）は特定していません。観測した事実として記載しています
通知の実送信テストは行っていません。生成と送信の分離という仕組みの説明にとどめています
User Criteria 728件の個別の条件内容までは追っていません
Flow Designerのフロー内部（各アクションの中身）までは追っていません
付録：自分の環境で確認するときのURL
カタログアイテムの直接URL：/esc?id=sc_cat_item&sys_id=<アイテムのsys_id>
カテゴリの直接URL：/esc?id=sc_category&table=sc_cat_item&sys_id=<カテゴリのsys_id>
カテゴリ未設定のアイテム一覧：/sc_cat_item_list.do?sysparm_query=active=true^categoryISEMPTY
掲載先カタログ未設定のアイテム一覧：/sc_cat_item_list.do?sysparm_query=active=true^sc_catalogsISEMPTY
hide_spが有効なアイテム一覧：/sc_cat_item_list.do?sysparm_query=active=true^hide_sp=true
ロール制限があるアイテム一覧：/sc_cat_item_list.do?sysparm_query=active=true^rolesISNOTEMPTY
履行エンジンの設定：/sc_cat_item.do?sys_id=<アイテムのsys_id>（workflow・flow_designer_flow欄）
承認レコード：/sysapproval_approver_list.do?sysparm_query=sysapproval.sys_class_name=sc_req_item
クローズ処理のビジネスルール：/sys_script_list.do?sysparm_query=collection=sc_req_item^nameLIKEClose
通知定義：/sysevent_email_action_list.do?sysparm_query=collection=sc_req_item
引用した公式説明を実機で確認する方法
この記事で参照したビジネスルールの条件式は、ServiceNow が製品に同梱している設定そのものです。次のURLを自分のインスタンスで開くと、同じ内容を確認できます。
ビジネスルールの一覧（引用元）：/sys_script_list.do?sysparm_query=collection=sc_req_item^active=true
関連記事
承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） … 承認が進まないときの核心
カタログClient ScriptがService Portalでだけ動かない？ UI Typeを実機の3画面で切り分ける … 画面固有の不具合の切り分け
RITMには変数が出るのにsc_taskに出ない？ 表示を決める関連テーブルを実機で突き止める … 変数表示の参照テーブル
