RITMには変数が出るのにsc_taskに出ない？ 表示を決める関連テーブルを実機で突き止める

履行担当者がCatalog Taskを開く。なのに、利用者が何を申請したのかが画面に無い。RITMを開き直せば見えるのに、タスク側は空のままです。表示を決めているのはsc_item_variables_taskという関連テーブルの行になります。そしてOOTBのフローは、この行を1つも作りません。Australia PDIで行を足し、同じタスクに変数が現れるまで確かめました。

期待は「タスクにも自動で見える」。実際はタスク側だけ選択制

申請フォームを設計した担当者は、入力値が履行担当者にも自動で見えることを期待します。RITM側はこの期待どおりです。変数を定義すれば、設定なしで全部並びます。裏切られるのはタスク側です。sc_taskのVariable Editorは「関連付けた変数」だけを表示します。関連付けが無ければ、枠ごと出ません。

よくある誤解を3つ先に潰しておきます。第一に「ACLで隠れている」。権限より先に、後述の関連テーブルの行を見ます。第二に「値が消えた」。値は無事です。保存先はRITM側にあります。第三に「フォームにVariable Editorを足せば出る」。今回のタスクには枠の配置がありました。それでも行が無ければ、何も出ません。

仕組みを先に1枚で示します。

RITMは変数定義（item_option_new）を直接見に行きます。sc_taskは関連テーブル（sc_item_variables_task）を挟みます。行を作るのは、フローのCreate Catalog Taskアクションの変数選択欄です。図の赤が今回の症状で、緑が行を足した後の状態になります。この非対称を知らないと「RITMで見えるから設定は正しいはずだ」と考えてしまいます。それが原因から遠ざかる第一歩です。

前提：値の実体は1か所。タスクに出ないのは「参照の紐」の問題

カタログ申請1件は3テーブルに分かれます。リクエスト（sc_request）は買い物かご全体です。RITMがアイテム1つぶんの申請明細になります。タスクは履行チームへの作業指示です。分担の詳細は申請が3テーブルに分かれる記事に譲ります。

入力値の実体はsc_item_optionに入ります。回答1つが1行です。sc_item_option_mtomという関連テーブルが、それをRITMに結びつけます。今回のRITMでは、この関連が4行ありました。Adobe Acrobatにtrue、Adobe Photoshopにfalse、テキスト欄には入力した文字列がそのまま入っています。

だから「タスクに出ない」症状で、値は消えていません。参照の紐が張られていないだけです。値の無事を先に確かめれば、調査は表示側だけに絞れます。利用者に「もう一度入力してください」と頼む必要も無い、と最初に言い切れるのも利点です。タスクが生まれる仕組みはCatalog Taskはどこから来るかの記事が受け持ちます。

公式ナレッジの正本はKB0745282。同じ症状の記事も独立してある

Service Catalog機能の位置づけは、プラグイン（v_plugin）の公式説明にこうあります。

タスクへの変数表示の正本は、公式ナレッジのKB0745282です。「RITMには出るのにタスクに出ない」という今回そのままの症状にも、独立した公式ナレッジがあります（KB2469045）。世界中で繰り返し起きている定番の症状です。仕組みを1度押さえれば、迷いは消えます。

周辺の症状にも、それぞれ別のナレッジが分かれています。ロール起因で枠ごと見えない事例。変数の選びすぎで失敗する既知エラー。非アクティブの変数が出続ける逆方向の事例。この記事では本筋の「行の有無」だけを実測します。周辺は末尾の参考リンクに整理しました。

実測：同じ注文で、RITMには出てタスクには出ない

素材はStandard Laptopの注文1件です。RITM0010001と履行タスクSCTASK0010001が、OOTBフロー「Service Catalog item request」の標準経路で作られています。注文時はチェック2つとテキスト1つに値を入れました。

RITMには4変数が設定なしで並ぶ

Variablesセクションに全変数が出ています。表示のための追加設定はゼロです。チェックの状態もテキストも、申請時のまま並んでいます。承認者はこの画面で内容を判断できます。

同じ注文のタスクには1つも出ない

変数のセクションごと消えています。Description欄には汎用の履行手順が入っていました。在庫から払い出すか、無ければ発注する、という定型文です。個別の注文内容だけがありません。担当者に見えるのは「注文を履行せよ」という指示だけです。Acrobatは要るのか、Photoshopは要るのか、追記の要望はあるのか。判断材料が画面にありません。RITMを開けば見えます。ただし、その一手間を全タスクで踏む運用になります。リンクを辿らず思い込みで履行すれば、手戻りです。現場では「毎回電話で聞き返す」運用に化けがちな症状でもあります。

原因：関連テーブルは0行。フローも変数を選んでいない

このタスクでsc_item_variables_taskを検索すると0行でした。確認は一覧URLをタスクのsys_idで絞るだけです。列はtask（タスク参照）とvariable（変数参照）の2つしかありません。仕組みの中心にしては、拍子抜けするほど単純な関連テーブルです。

行が無い理由はフロー側です。タスクを作ったフローにはCreate Catalog Taskアクションが4つあります。設定済みの入力はShort DescriptionとFields欄（割り当てグループと説明文）だけでした。変数の選択欄は4つとも空です。アクションの入力値はsys_variable_valueに保存されるため、フローの編集画面を開かなくても確かめられます。

つまりOOTBの既定は「タスクに変数を見せない」です。不具合の類ではありません。選ばれていないから出ていない、が結論です。フロー自体は正常に働いています。タスクを作った後はWaitingで残り、完了を待っていました。壊れているものは1つも無く、問題は表示の設定だけです。

恒久対処：フローのCreate Catalog Taskアクションで変数を選ぶ

二度と起こさない方法から先に書きます。フローを開き、Create Catalog Taskアクションの変数選択欄で、見せたい変数を選んでください。選んだら公開し直して（Activate）完了です。フローは公開し直すまで前の版が動き続けます。保存だけで終えないよう注意してください。効くのは以後に作られるタスクからになります。すでにあるタスクには遡って効きません。

対象フローの探し方も1行です。アイテムのフォームでProcess Engineタブを開きます。Flow欄に入っているのが、そのアイテムのタスクを作っているフローです。旧Workflowで作られたアイテムなら、Catalog Taskアクティビティに同じ趣旨の指定があります（そちらは今回未検証です）。

本番への反映は更新セット経由になります。フローの変更も更新セットに乗ります。開発環境で選び直し、後述のテスト注文で確かめてから運んでください。

なおCreate Catalog Taskアクションが複数あるフローでは、経路ごとに選び直します。今回のOOTBフローにはこのアクションが4つありました。在庫からの払い出し、入庫待ち、利用者への配備という分岐ごとに、別のタスクを作る構成です。動いたのはそのうち1つでした。変数を見せたい経路すべてで選ぶ必要があります。

新しいアイテムを作るときは、設計手順に1行足してください。「タスクに見せる変数を選ぶ」。OOTBの既定が「選ばない」なので、この1行が無いと今回の症状が毎回発生します。アイテムを量産する時期ほど、抜けやすいチェックです。

選ぶときの注意：ラベルも一緒に。数は絞る

見出し用のラベル型変数にも行が必要です。今回のアイテムは変数4件のうち1件がラベル型でした。値を持たない飾りでも、選ばなければタスクから消えます。見出しだけ消えると、画面の意味が変わってしまいます。ラベルやコンテナは、中身の変数とセットで選んでください。

逆に、選びすぎにも注意が要ります。変数を選びすぎると追加に失敗する既知エラーがあります（KB1167695）。それに、履行担当者に全項目を見せる必要も無いはずです。本人の事情を書く欄などは外します。選ぶ行為が、そのまま情報の出し分けになります。迷ったら基準は1つです。履行の手順書に登場する項目だけを選びます。

リリース前の確認は、テスト注文1件で済む

この症状は、リリース前に必ず見つけられます。手順は3つです。開発環境でアイテムを1件注文します。承認を進めて、タスクを作らせるところまでが2手目です。3手目でそのタスクを開き、見せたい変数が出ているかを確かめます。出ていなければフローの選択漏れです。リリース判定のチェックリストに「タスクの変数表示を確認」と1行足せば、本番で発覚する事故はなくなります。

今回の注文実験そのものが、この確認手順の実演になっています。OOTBのままではタスクに何も出ない。それをリリース前に知っているかどうかの差です。

実証：行を足したら、同じタスクに変数が現れた

仕組みの証明として、変数4件を関連テーブルに直接関連付けました。フローもフォームも変えていません。足したのはデータ行だけです。もし表示がフローの再実行やフォーム設定に依存するなら、これでは出ないはずです。出れば「行の有無がすべて」の証明になります。

同じタスクを開き直します。Variablesセクションが現れました。値もRITMと同じです。チェックの状態もテキストも、申請時のまま表示されています。

反映は開き直すだけでした。キャッシュ操作は不要です。フローで変数を選んだときに起きることを、データ側から再現した形になります。この直接編集は、すでに作られたタスクへの応急対応にも使えます。ただし常用はせず、恒久対処はフロー側で行ってください。

行の作り方も添えておきます。sc_item_variables_taskの一覧を開き、Newで行を作ります。入力はtask（対象タスク）とvariable（見せたい変数）の2つだけです。1件あたり数十秒で済みます。対応中の案件が数件なら、この方法で当日中にしのげます。件数が多いなら、フロー修正後の作り直しを検討してください。

この操作は可逆です。行を消せば、元の「出ない」状態に戻ります。検証では撮影のために一度消して戻す往復も行いました。挙動は行の増減にそのまま追随します。

前後の比較を1枚にまとめます。

切り分けは3手で終わる

調査手順に直します。第一の手は、管理者でタスクを開くことです。変数が出るかを見ます。ここまで1分です。第二の手は、sc_item_variables_taskをそのタスクで絞ることです。0行なら「出ないのが正常」で、原因はタスクを作った側にあります。ここまで3分で着きます。第三の手は、フローのアクション入力の確認です。変数の選択が無ければ、そこが直す場所になります。

どの手も一覧を開くだけです。設定変更を伴いません。本番環境でもそのまま実行できます。原因の候補を1枚にまとめます。

管理者なら見えるのに担当者には見えない。その結果になったときだけ、ロール側（KB0814952）へ進みます。行の有無が先、権限が後です。この順番なら行き止まりがありません。逆順で始めると、存在しない権限問題を延々と探すことになります。

RITM側にも出ないなら、変数と画面の設定を疑う

症状が「RITMにも出ない」なら、関連テーブルは無関係です。候補は3つあります。変数のactiveが外れている場合。Variable Editorのフォーマッタがフォームから外されている場合。表示条件（catalog_ui_policyなど）で隠されている場合です。見る場所はそれぞれ、item_option_newのactive列、RITMフォームのレイアウト設定、そのアイテムのUI Policy一覧になります。逆に、非アクティブの変数がタスク側に出続ける事例も公式ナレッジにあります（KB0864422）。RITM側の各候補は今回未検証のため、入口の区別だけを書き残します。

覚え方は1行です。RITMに出るのにタスクに出ないなら関連テーブル。RITMにも出ないなら変数と画面の設定。症状の出る場所が、開くべきテーブルをそのまま教えてくれます。

実機を見て気づいたこと

sc_item_variables_taskには、フィールドの公式説明（hint）も継承元（super_class）もありません。ナビゲーターのメニューにも出てきません。テーブル名を直打ちする以外に辿り着けない、知る人ぞ知る置き場です。名前さえ覚えておけば、一覧を開くだけで切り分けの半分が終わります。

タスクのフォーム側にも導線がありません。関連リストに並ぶのはAffected CIsや承認だけでした。フォームをいくら眺めても、この関連テーブルへは辿り着けません。「画面から追えない仕組みが表示を握っている」。この症状が長引く理由は、たぶんここにあります。

RITMは無条件で全変数を表示します。タスクは選んだものだけです。この非対称は、情報の見せ過ぎを防ぐ設計だと読めます。履行担当者に全項目は要らない、という思想です。ただし既定が「ゼロ」なので、知らない環境では確実につまずきます。

作る側の目線も1つ添えます。開発中はRITMで動作を確かめがちです。RITMでは常に全部見えるため、選択漏れに気づけません。レビューではRITMではなくタスクを開く癖を付けると、この症状は出荷前に止まります。

値の保存側（sc_item_option）を見ると、ラベル型にも空の値の行が作られていました。飾りに見える部品も、データ上は他の変数と同格です。見た目で軽く扱うと、選択から漏れます。

この一覧は「値は無事か」の即答にも使えます。タスクに出ない相談を受けたら、まずここを開きます。行があれば、値は保存済みです。あとは表示側だけを直せば済みます。

用語

• RITM（sc_req_item） … 申請明細。入力値はここに紐づく

• Catalog Task（sc_task） … 履行用タスク。変数は関連付けた分だけ表示される

• Variable Editor … 変数を表示するフォームの枠。フォーマッタとして配置される

• sc_item_variables_task … タスクと変数の関連テーブル。行の有無が表示を決める

• sc_item_option / sc_item_option_mtom … 入力値の実体と、RITMへの関連付け

• item_option_new … 変数の定義そのもの

• Create Catalog Task … フローでタスクを作るアクション。変数の選択欄を持つ

• Activate（公開） … フローの変更を実行版に反映する操作。保存だけでは反映されない

• stage … RITMの進行段階の表示。承認待ちや履行中がここで分かる

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

• /sc_item_variables_task_list.do?sysparm_query=task=<タスクのsys_id> … タスクに関連付いた変数の行

• /sc_item_option_mtom_list.do?sysparm_query=request_item=<RITMのsys_id> … 入力値が保存されていることの確認

• /sc_task.do?sys_id=<タスクのsys_id> … タスクの変数表示の確認

• /sc_req_item.do?sys_id=<RITMのsys_id> … RITM側との比較

• /item_option_new_list.do?sysparm_query=cat_item=<アイテムのsys_id> … 変数定義の一覧

• /sys_variable_value_list.do?sysparm_query=document_key=<アクションのsys_id> … フローのアクション入力値

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNowが製品に同梱しているプラグインのドキュメントです。

• Service Catalogプラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=id=com.glideapp.servicecatalog

参考リンク

本筋の2本から読んでください。

• KB0745282: How variables appear on Catalog Task Form in Variable editor? — タスクへの変数表示の正本（本筋）

• KB2469045: Catalog Variables Visible on RITM Form but Not on SC Task Form — この記事と同じ症状の公式ナレッジ（本筋）

周辺の症状は次の3本です。

• KB0814952: The Variable Editor is not showing on sc_task records for users with certain roles — ロール起因で枠ごと見えない事例

• KB1167695: Flow Designer 'Create Catalog Task' action fails adding variables if too many are selected — 変数の選びすぎで失敗する既知エラー

• KB0864422: Inactive variables are displaying in the task variable editor — 非アクティブ変数が出続ける逆方向の事例

検証範囲とおことわり

挙動はAustralia PDI（OOTB）で2026-08-29に確認したものです。RITM0010001とSCTASK0010001は検証用に注文したデータレコードになります。sc_item_variables_taskへ追加した4行も、実験の成果としてそのまま残しました。フロー・フォームレイアウト・アイテム定義などの設定は変更していません。

今回の検証範囲に含めていないものを挙げます。旧Workflow（Catalog Taskアクティビティ）経由のタスク、ロール起因でVariable Editorが見えないケース、変数側のvisible系設定の3つです。関連テーブルの直接編集は、仕組みの確認と応急対応に限ります。恒久対処はフロー側の変数選択で行ってください。

関連記事

• ServiceNowの申請1件はなぜ3テーブルに分かれる？ sc_request / sc_req_item / sc_taskを実機で追う — RITMとタスクの役割分担を先に押さえたい人向け

• Catalog Task はどこから来るか（履行計画） — タスクが生まれる仕組み側を追う前提知識

• 承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） — タスクが作られるまでの承認の流れを追う実務編