サービスカタログの連携機能
Requested Item（RITM）のフォームには、他モジュールを指す参照フィールドがほとんど出てきません。Incidentで「これは障害でなく申請だ」と分かったとき、何が引き継がれるのか。標準変更カタログの注文がRITMを作るとは限りません。App Engine Studioの通知がなぜsc_req_itemに混ざっているのか。Australia PDIをデフォルト設定のまま開き、Incident・Change・App Engine Studio・CMDB・承認基盤という5つの接続先を実機で確かめました。
検証環境：Australia PDI / OOTB / 2026-09-01 確認
確認する連携
インシデントから申請へ切り替える経路と、実際に引き継がれる値
カタログの中にあるRecord Producerが他テーブルへ直接書き込む理由
標準変更カタログはRITMを経由するのか
App Engine Studioの通知がRequestの一覧に混ざる理由
RITMからCMDB・資産管理へ配備される経路
承認・SLAという他モジュールと共用する基盤との関わり
連携の実態
sc_req_itemは2方向で共用されます。App Intakeが内側に同居する一方、Record Producer45件はsc_req_itemを1件も行き先にしません
インシデントのCreate Requestアクションは画面遷移のみで、値を引き継ぐ仕組みを持ちません
標準変更カタログの実体（std_change_record_producer）はchange_requestへ直接書き込み、RITMを作りません
Universal Requestはフィールド・ACLとも用意されていますが、関連プラグイン7件はすべてInactiveです
承認（sysapproval_approver）はPDI全体742件中2件だけがRequest関連で、taskを参照する汎用テーブルを借用しています
3つに分かれる連携の全体像
サービスカタログが他モジュールとつながる形は、方向で3つに分かれます。内側の連携はApp Intakeで、sc_req_itemの通常フローに同居する形です。外側の連携はRecord Producerで、カタログの中に置かれていながら別テーブルへ直接書き込みます。残る承認・SLA・システムプロパティは、Request固有ではない共通基盤を利用する連携です。
sc_requestとsc_req_itemを参照する実テーブルは、本シリーズ第2巻で数えたとおり合わせて11件で、incidentやchange_requestは含まれません。参照フィールドによる直接のつながりは無く、連携はすべて別の仕組みで実現されています。答えは連携ごとに違います。
この3分類は、本シリーズ第4巻「プロパティ」で確認した事実とも符合します。Request固有の挙動を切り替えるプロパティの名前空間（com.snc.request.*やsn_request.*）は0件で、代わりにカタログエンジン共通のglide.sc.*名前空間に間借りしていました。設定を変える手段さえ自前で持たず借り物である、という構造が、連携の作りにもそのまま表れています。
参考：サービスカタログの概要 … カタログ・RITM・履行タスクの基本構造
インシデントから「これは申請」に付け替えるCreate Requestアクション
Incidentのフォームには「Create Request」というUIアクションがあります。クリックを受け取る画面側アクションと、実処理を持つサーバ側アクションの2件がペアで登録されていました。ボタンが表示される条件は、インシデントがClosedでないことと、itilロールを持つことです。Incident Management専用ロールのプラグインが有効な場合は、sn_incident_writeロールでも表示されます。担当者を限定せず、通常業務でインシデントを触る人なら誰でも使える設計になっています。
サーバ側アクションの処理内容です。current.update()でインシデントを保存したあとcatalog_home.do?...&sysparm_parent_table=incident&sysparm_parent_sys_id=<sys_id>というURLを組み立て、action.setRedirectURL(url)で遷移するだけの処理でした。値を書き換える処理も、他レコードを作る処理も含まれません。
同じインシデントの「Create Change Request」と比べると違いがはっきりします。Change側はgs.getSession().putProperty('change_link', {table, sysid, field:'rfc'})でセッションプロパティに元のインシデント情報を保存し、遷移先の変更フォームがそれを読んでrfcへ書き戻す仕組みを持ちます。Requestの遷移には、この持ち回りの仕組みが丸ごとありません。単なる画面の切り替えです。
sysparm_parent_tableを実際に読むBusiness Ruleがあるかもsys_script全体を対象に検索しましたが、0件でした（UIページやウィジェットなどクライアント側での消費までは確認していません）。カタログホーム側でこのパラメータを使って何かを自動入力する処理があるかどうかは、少なくともサーバ側のスクリプトには存在しないという意味です。
画面はカタログホームへ遷移しますが、元のインシデントへの参照はレコードのどこにも残りません。sc_requestとsc_req_itemの固有フィールドにincidentを指す項目が1つも無いためです（第2巻既出）。申請の追跡を求められたら、URLパラメータをあてにせず作業メモへRITM番号を手動で転記する運用を案内します。誰が・いつ・どの申請へ切り替えたのかを残す責任は、システムではなく担当者の運用に委ねられています。
参考：Record Producer は RITM を作らない … 申請とRITMの関係の基礎
カタログの中にあるのに外へ書き込むRecord Producer
Service Catalogの中には、カタログアイテムでありながら別テーブルへ直接レコードを作るクラスがあります。Record Producer（sc_cat_item_producer）です。第5巻既出のとおり、204件のカタログアイテムのうちRecord Producer系は3クラス合計46件（sc_cat_item_producer30・sc_cat_item_composite_producer10・std_change_record_producer6）を占めます。
各Record Producerがどのテーブルへ書き込むかはtable_nameという項目が決めます。遷移先を決めるredirect_urlの公式ヒントを引用します。
Decides where to land after record creation. Works for Service Portal as well
（訳: レコード作成後にどこへ遷移するかを決める。Service Portalでも機能する）
注文の時点で対象テーブルにレコードが直接作られる、という意味です。table_name以外にも、Record Producerは独自のフィールドをいくつか持ちます。scriptが申請フォーム送信時にレコードを準備するスクリプト、post_insert_scriptが挿入後の追加処理、save_optionsが保存前後どちらで作るかの制御です。table_nameで指定した対象テーブルへ実際に値を書き込むのは、多くの場合このscriptフィールド自身です。カタログエンジンが自動でRITMを組み立てるのとは違い、Record Producerは開発者が書いたスクリプトが直接insertする、という作りの違いがあります。46件のtable_nameを集計しました。
46件のうち45件でtable_nameを直接確認できました（1件は権限の都合で未取得）。上位はchange_request8件・incident7件・std_change_proposal3件で、この45件にsc_req_itemは1件もありません。incident向けの7件には「Password Reset」「Report Outage」「Ask a Question」のような、一見すると自己解決型の申請フォームに見える項目も含まれます。名前だけを見ると申請の一種のようですが、実際には障害管理のインシデントとして起票される作りです。
Record Producerはカタログの管理画面ではsc_cat_itemの一種として扱われます。しかし実行結果は、申請データ（sc_request・sc_req_item・sc_task）のテーブルには一切残りません。見えない連携です。件数を見積もるときは、Record Producer系46件を先に除外します。これを含めたままカタログの注文数からRITM創出数を見積もると、実際より多く見積もることになります。
標準変更カタログの実行経路
Record Producerの行き先のうち8件はchange_requestでした。うち6件はstd_change_record_producerという専用クラスで、標準変更のテンプレートに対応します。
テンプレートがどのように審査・発行されてカタログアイテムになるかは、変更管理シリーズ第8巻「連携機能」で確認済みです。std_change_proposalが承認されるとstd_change_producer_versionとして発行され、継承チェーン（std_change_record_producer→sc_cat_item_producer→sc_cat_item）を通じてカタログアイテムになります。カテゴリ・価格つきの詳しい数値は同巻に譲り、本巻は注文されたあとの行き先だけを追いました。
本巻で追加確認したのは、この6件が実際に注文されたときの行き先です。6件すべてのtable_nameはchange_requestで、注文してもsc_req_itemにRITMは作られません。同じService Catalogの中に並んでいても、実行の通り道はまったく別です。標準変更カタログを「サービスカタログの申請の一種」として扱うと、承認後の履行がRITMに現れないことに戸惑います。実態はRecord Producerの仕組みそのもので、承認後は変更管理側のプロセスへそのまま合流します。
参考：変更管理モジュールの概要 … 標準変更そのものの位置づけ
App Engine StudioのApp Intakeがsc_req_itemに同居する実態
Record Producerが外へ出ていく一方で、逆に外から入ってくる連携がApp Engine StudioのApp Intakeです。
本シリーズ第6巻既出のとおり、sc_req_itemの通知（sysevent_email_action）18件のうち13件（72%）はevent_name=activate.life.cycle.migrationという共通のイベント名を持ちます。
件名は「Your app has been approved」「You have a new app request」で、アプリ開発の申請承認を扱う通知でした。画面で確認できた範囲では、宛先はいずれもApp Engine Adminsというグループです。カタログ本来の通知が申請者本人へ届くのに対し、App Intake系は管理者グループへ届く設計に見えます。残る5件がDelivery・Completed・Commentedといったカタログ本来の履行通知です。
Record Producerとは逆に、App Intakeは通常のカタログアイテムと同じ経路でRITMを作り、table_nameで逃げず既存のsc_req_itemに同居します。一覧で見るだけでは商品注文とアプリ開発申請を区別できません。通知やレポートはevent_nameでApp Intake分を分けます。同じsc_req_itemが、Record Producerのように外へ書き込みを逃がす側にもなります。App Intakeのように外から書き込みを受け入れる側にもなる、非対称な二面性です。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知定義そのものの仕組み
Universal Requestと他部門カタログへの拡張余地
task.universal_requestという項目が、taskを継承する全テーブルに存在します。sc_request・sc_req_itemにも継承され、REST APIで問い合わせると空文字ですが正常にキーが返り、ACLも1件（write・active）用意されています。参照するBusiness Ruleは合わせて0件でした。関連するv_pluginも確認しました。
本体（Universal Request）にも、6つの周辺プラグインがあります。1つはAdvanced Work Assignment連携、Virtual Agent向けNLUモデル、Virtual Agent会話テンプレートです。もう1つはPerformance Analytics、Predictive Intelligence（機械学習）、Reportingです。合わせて7件がすべてInactiveでした。名前を見る限り、チャットボットからの起票や機械学習による分類まで一式が用意された機能ですが、本体が眠っている以上どれも動きません。辞書上は正規のフィールドとして存在するのに参照する処理は一切なく、器だけが用意されて機能一式が丸ごと眠っている状態です。
Service Catalogのクラス構造自体は他業務への拡張を前提にしています。sc_cat_itemのサブクラスにはハードウェア・ソフトウェア資産向けのpc_hardware_cat_item・pc_software_cat_item（第5巻既出、54件）があり、同じ仕組みをIT資産管理へ転用済みです。本PDIにはHR Service Delivery・Facilities Service Managementのプラグインが無く、他部門カタログへの拡張は実機で確認できませんでした。
RITMからCMDB・資産管理へ配備する経路
RITMが承認されたあとCMDB（cmdb_ci）へつながる経路が2つあります。
1つ目はAssign from Stock（sc_req_item・before・order100）です。
configuration_itemが変更されると指定のcmdb_ciを取得し、install_statusを4（Pending Install）に、assigned_toを申請者に更新します。作業メモにも「Configuration item assigned from stock」と自動で記録される、在庫から既存CIを払い出す処理です。条件式にはglobal.AssetUtils.canUpdateCIStatus(current)という判定も含まれており、Hardware Asset Management（HAM）プラグインが有効な環境では、CIの状態更新をHAM側の専用処理に譲る作りになっています。標準の在庫払い出しと、HAMによる資産ライフサイクル管理が競合しないよう、条件式レベルで棲み分けています。
2つ目はCreate Inventory Item（sc_req_item・after・order100）です。stageがcompleteになり、カタログ変数create_itemがtrueのときだけcmdb_ci_computerを新規に1件作ります。資産タグ・シリアル番号・OSの値は注文時の変数（variable_pool）からそのまま複写される、新規CI作成の処理です。既存の在庫を払い出す1つ目とは対照的に、こちらは「注文のたびに新しい機器が1台増える」という前提のロジックです。
対象はどちらもcmdb_ciです。alm_asset（資産台帳）には直接書き込みません。alm_asset.request_lineという参照フィールドは辞書上に存在します（第2巻既出）が、実際に埋めるBusiness Ruleは本巻の検索範囲では見つかりませんでした。IT Asset Management側の専用ロジックと見られますが、内部までは確認していません。資産の調達記録とRITMをひもづけたい場合は、request_lineが空のままになっていないかを個別に確認します。
参考：資産(alm_asset)とCMDB(cmdb_ci)を分ける理由 … 2つのテーブルを分ける設計思想
参考：Catalog Task はどこから来るか（履行計画） … 変数からdelivery_planへつながる仕組み
承認とSLAという共用インフラとの関わり
承認はRequest専用ではない汎用テーブルsysapproval_approverを通じて動きます。source_tableの公式ヒントを引用します。
Table of that contains the document to be approved
（訳: 承認対象のドキュメントを含むテーブル）
引用元: /sys_documentation_list.do?sysparm_query=name=sysapproval_approver^element=source_table
sysapprovalフィールドはTask型への参照で、IncidentやChangeを含む全テーブルを指せる作りです。
本PDI全体では742件登録されていました。内訳をsource_tableでグループ化すると、change_requestが724件（全体の98%）を占めていました。残りはstd_change_proposalが4件、sc_requestとsc_req_itemが1件ずつ、値が空のものが11件です。sc_request・sc_req_item向けは合わせて2件、Requestは脇役でした。承認の仕組みを自分で持たず、共通基盤を間借りしていますが、その基盤自体が圧倒的にChangeの承認で占められているという事実も、あわせて分かります。
SLA（contract_sla）は第5巻既出のとおり3テーブルとも0件です。期限超過を検知して他モジュールへ自動でエスカレーションする経路はありません。滞留を検知したいときはstageの滞在時間を独自にレポート化するなど、Request側で別途用意します。
参考：承認は1人1レコード（sysapproval_approver） … このテーブルの基本構造
参考：承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） … Request内部の承認構造
連携を設計するときに決めること
ここまでを、連携を設計するときの判断基準としてまとめます。
Incidentからの付け替え：ボタンの遷移だけに頼らず、値を引き継ぐ運用を別途用意するか。追跡が必要なら作業メモへの手動転記をルール化する
標準変更カタログ：table_nameを確認し、RITMを経由しない前提で件数を数える。カタログの棚卸しと変更管理側の棚卸しを別々に行う
App Intake：event_nameでカタログ本来の通知と分離してから集計する。宛先グループも商品注文とは別枠で管理する
Universal Request：プラグインを有効化しない限り使えない前提で計画する。有効化する場合はawa/nlu/va等の周辺プラグインも合わせて確認する
CMDB・資産：既存CI更新か新規CI作成かを、カタログ変数の設計で決める。HAMプラグインの有無で優先される処理が変わる点も踏まえる
承認・SLA：汎用テーブルの制約と、期限監視が無い前提を他モジュールと共通で理解する。承認の大半はChange側という前提でボトルネックを探す
実機で気づいたこと
sc_req_itemは内側から間借りされ、外側へは一切出さない
共用のされ方が一方通行でした。App Intakeが内側に同居する一方、Record Producer45件の行き先にsc_req_itemは0件です。同じService Catalogに属していながら、Record Producerは履行の主導権をIncidentやChangeへ渡します。App Intakeは逆に、sc_req_itemへ主導権を預ける側に回っています。sc_req_itemの通知・ACLを設計するときは、内側へ入ってくる連携だけを想定すれば十分です。外へ抜けていく連携を心配して余計な制御を足す必要はありません。
Create Requestボタンは値を1つも引き継がない
catalog_home.doへの遷移だけで、Create Change Requestのようなセッションプロパティは使われていません。変更管理は起票後にrfcへ値を戻しますが、Requestに対になる項目はありません。ボタンの名前と挙動が対称に見えるため、最初は同じ仕組みを持っていると思い込みました。実際にスクリプトを開いて初めて、片方だけが持ち回りの仕組みを実装していると分かりました。申請の追跡を求められたら、担当者に作業メモへRITM番号を手動で転記してもらいます。
v_plugin.nameは一覧画面の絞り込みに使えない
v_pluginをnameLIKEuniversal_requestで絞り込むと、REST APIでは7件返るのに、ブラウザの一覧画面では「No records to display」と表示されました。v_plugin.nameの内部型がtranslated_textだったためです。翻訳テキスト型のフィールドは、REST APIの単純な文字列一致と、ブラウザの一覧画面が組み立てる条件式とで挙動が食い違う場合があると実機で確認できました。同じuniversal_requestという文字列でも、String型のidで検索し直すと一覧に正しく表示されました。プラグインやカタログ項目のように翻訳対応するテーブルを一覧で絞り込むときは、nameではなくidのようなString型のフィールドを使うほうが確実です。
辞書にあるのに動かない項目がある
task.universal_requestは辞書・ACLとも正規に存在しますが、参照するBusiness Ruleは0件でした。フィールドの有無と機能の稼働は一致しません。連携の有無を調べるときは、辞書だけでなく参照実績まで確認します。
用語
OOTB：Out of the Box。カスタマイズを行っていない製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNowが無償提供する個人検証用インスタンス
RITM：Requested Item。sc_req_itemに保存される申請品目1件
Record Producer：カタログの入口を使いながら注文内容を任意のテーブルへ直接書き込む仕組み
App Intake：App Engine Studioのアプリ開発申請機能。sc_req_itemを間借りする
検証範囲とおことわり
検証環境：Australia PDI / OOTB / 2026-09-01 確認
件数はOOTBの定義・設定の数です。本番環境やカスタマイズ済み環境では異なります
sysparm_parent_tableをUIページやウィジェットが参照しているかは未確認です
alm_asset.request_lineを実際に埋めるスクリプトの内部までは追っていません
Record Producer46件のうち1件は権限の都合でtable_nameを取得できませんでした
標準変更カタログ・Record Producerを実際に注文する操作は行っていません
付録：自分の環境で確認するときのURL
Incidentの申請系UIアクション：/sys_ui_action_list.do?sysparm_query=table=incident^nameLIKERequest^active=true
Record Producerの行き先：/sc_cat_item_producer_list.do?sysparm_query=ORDERBYtable_name
App Intake系の通知：/sysevent_email_action_list.do?sysparm_query=collection=sc_req_item^event_name=activate.life.cycle.migration
Universal Request関連プラグイン：/v_plugin_list.do?sysparm_query=idSTARTSWITHcom.snc.universal_request
承認の対象テーブル別内訳：/sysapproval_approver_list.do?sysparm_query=GROUPBYsource_table
引用した公式説明を実機で確認する方法
引用した説明文は、ServiceNowが製品に同梱しているフィールドのドキュメントです。次のURLを開くと同じ記述が見つかります。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINsc_cat_item_producer,sysapproval_approver^hintISNOTEMPTY
関連記事
Record Producer は RITM を作らない … カタログ入口とRITM作成の分岐点
資産(alm_asset)とCMDB(cmdb_ci)を分ける理由 … 配備連携の先にある設計思想
承認は1人1レコード（sysapproval_approver） … 承認テーブルの基本構造
