ServiceNowでカタログ申請を扱い始めると、REQ・RITM・SCTASKという3種類の番号に立て続けに出会います。申請者から「REQの進捗を教えて」と言われ、作業者は「SCTASKしか見ていない」と言い、レポートを作ろうとすると今度はRITMの件数が合わない——3つの番号が同じ1回の申請から生まれた別々のレコードだと分かっていないと、この時点で会話が噛み合わなくなります。
この記事は、Request Managementの3層構造をデータ構造（どのテーブルか）→ 連動の流れ（どう生まれ、どう繋がるか）→ 状態と承認（どう進み、どう閉じるか）→ 現場で迷う典型パターンの順に整理し、最後にCIS-ITSM試験でこの領域がどう問われるかまで進む判断ガイドです。読み終えると「誰が・どの番号を・いつ見るべきか」を即答できるようになります。
要点まとめ
- REQ（sc_request）＝注文全体の入れ物、RITM（sc_req_item）＝品目1つぶんの依頼、SCTASK（sc_task）＝品目を実現する作業指示。1回の申請が3層に分かれて記録されます。
- 申請者と承認者が見るのはREQ/RITM、作業担当者が動かすのはSCTASK。申請内容（Variables）はRITMに保存されます。
- 完了は下から上へ繰り上がります。作業タスクが済むとRITMが完了へ進み、全RITMが閉じるとREQが閉じる——この向きを覚えると状態の疑問の大半が解けます。
Request Management領域の理解をCIS-ITSM無料模試で確認する
この記事で扱う「どのテーブルか」「誰がどれを操作するか」は、模試のRequest系ドリルの頻出判断です。
3つの番号は「1回の注文」を3層に分けたもの
まず全体像を1枚で押さえます。イメージは通販です。カートで注文を確定すると「注文番号」が1つ発行され、注文の中の商品ごとに「明細」があり、倉庫では商品ごとに「ピッキング指示」が動く——ServiceNowのRequest Managementはこの構造をそのままテーブルにしています。
横にスクロールできます
| 番号 | テーブル | 何を表すか | 主に見る人 |
|---|---|---|---|
| REQ | sc_request |
注文全体の入れ物。「誰がいつ申請したか」を束ねる | 申請者（自分の申請一覧）・承認者 |
| RITM | sc_req_item |
品目1つぶんの依頼。申請内容（Variables）と進捗Stageを持つ | 申請者・フルフィルメント管理者 |
| SCTASK | sc_task |
品目を実現するための作業単位。担当グループに割り当てられる | 作業担当者 |
なぜ3層も要るのか。答えは数の関係にあります。1回の注文には複数の品目が入り得るし（PC1台とモニター2台）、1つの品目を実現するには複数の作業が要り得ます（在庫確認→キッティング→配送）。「注文：品目＝1対多」「品目：作業＝1対多」という現実を、REQ→RITM→SCTASKの親子関係で表現しているわけです。3つともtaskテーブルを拡張したテーブルなので、番号は違っても「タスクの仲間」として共通の仕組み（担当・状態・SLA）に乗っています。
注文から完了まで：レコードが生まれる順番
データの流れを時系列で追うと、3層の役割分担がはっきりします。
- 申請者がService CatalogでCatalog Itemに入力して注文（Order）する
- その瞬間にREQ（sc_request）が1件生成され、注文に含まれる品目ごとにRITM（sc_req_item）がぶら下がる
- 各RITMのフルフィルメント（Flow DesignerのフローやWorkflow）が動き出し、承認やSCTASK（sc_task）の生成を品目ごとに進める
- 作業者がSCTASKを完了させていくと、RITMが完了へ進み、最終的にREQが閉じる
ここで大事なのは、SCTASKは「注文したから自動で決まった数できる」ような固定物ではないことです。何個のタスクをどの順で作るかは、そのCatalog Itemに紐づくフローの設計次第。品目によってはタスクを1つも作らず自動処理だけで完了するものもあります。「RITMは必ずあるが、SCTASKの数と形は設計依存」と覚えておくと、環境ごとの違いに驚かなくなります。
申請内容（Variables）はRITMに載る
実務で最初に効く知識がこれです。「申請フォームで入力した内容はどこで見られるか」——答えはRITMです。Catalog Itemのフォームで入力した値（希望機種、利用開始日、理由など）はVariablesとしてRITMに紐づき、RITMのフォーム上に表示されます。REQを開いても品目ごとの入力値は見えません。問い合わせ対応で申請内容を確認したいのにsc_requestばかり探して見つからない、というのは定番の空振りです。
番号の対応関係を画面で辿る
3層の繋がりは、フォームの関連リストでそのまま辿れます。REQのフォームにはRequested Items関連リストがあり、その注文に含まれるRITMが並びます。RITMのフォームには申請内容のVariablesと、Catalog Tasks関連リスト（配下のSCTASK）が見えます。逆方向も同じで、SCTASKからは親のRITMへ、RITMからは親のREQへ、参照フィールドを1クリックするだけで戻れます。「迷ったら親子の関連リストを辿る」——これがRequest Management画面操作の基本動作です。
状態・承認・完了：進み方には「向き」がある
承認は品目（RITM）単位が基本形
標準的なカタログ設計では、承認はRITM単位で動きます。フローが承認依頼を上長やアイテム所有者に送り、承認されたらSCTASKの生成へ進む形です。品目ごとに承認者が違う（PCは情シス、ソフトウェアライセンスは部門長）ケースを自然に表現できるのがRITM承認の利点です。設計によってはREQ側でまとめて承認する構成も作れますが、「どの層で承認しているかは環境の設計を確認する」が正しい姿勢です。
完了は下から上へ繰り上がる
状態の進み方には明確な向きがあります。SCTASKが全て完了すると、そのRITMのフローが次の段階へ進んで完了状態になり、注文内の全RITMが閉じるとREQが閉じる——下から上への繰り上がりです。逆に、REQを直接閉じて回るような運用は、配下に生きた作業が残ったまま外箱だけ閉じることになるので原則やりません。「閉じる操作は一番下の層で行い、上は自動で追従させる」と覚えてください。
申請者に見せる進捗はRITMのStage
申請者が「今どこまで進んでいるか」を見る場所は、RITMのStage（段階）です。承認待ち→履行中→配送待ち→完了のような段階表示で、ポータルの申請一覧にもこのStageが出ます。作業者向けの細かい状態（SCTASKのState）と、申請者向けの大づかみな進捗（RITMのStage）は別物——この使い分けを知っていると、「ユーザーには完了と見えているのに作業タスクが残っている」ような見え方の差も説明できます。
IncidentやCatalog Item定義との境界線
Request Managementの理解は、隣の概念との境界を引くと安定します。ここはデータ構造の観点だけ短く押さえ、詳細は各記事に譲ります。
- Incidentとの境界：「壊れた・動かない」を直すのがIncident（
incidentテーブル）、「欲しい・してほしい」を叶えるのがRequest（sc_request系）。どちらのテーブルに落ちるかで、その後のプロセスもSLAも変わります。4プロセス全体での位置づけはCIS-ITSM 4プロセスの連携記事で扱っています。 - Catalog Item（定義）との境界：Catalog Itemは「注文できる品目の定義」、RITMは「その定義から生まれた実行結果」です。定義側（Variables設計やRecord Producerとの違い）はCatalog ItemとRecord Producerの比較記事が守備範囲なので、本記事では実行側だけを扱いました。なおRecord Producer経由の申請はREQ/RITMを作らず対象テーブルへ直接1レコードを作る——ここが両者の分水嶺です。
現場で迷う典型パターン
3層構造の理解が曖昧なまま運用に入ると、決まった場所でつまずきます。よくある4つを、原因と処方で並べます。
横にスクロールできます
| 症状 | 原因 | 処方 |
|---|---|---|
| 申請者にRITM番号を伝えたのに、作業チームが「見つからない」と言う | 作業者の作業一覧はSCTASK基準で動いている | 作業への問い合わせはRITM配下のSCTASK番号で。逆に進捗の問い合わせはRITMで受ける |
| 申請時の入力値が見つからない | sc_request側を探している | VariablesはRITM。sc_req_itemを開く |
| SCTASKを全部閉じたのにRITMが完了しない | 繰り上がりはフローの設計で動く。カスタムフローで完了処理が組まれていないことがある | RITMのフロー実行状況を確認。標準の形では作業完了後にフローが完了段階へ進める |
| 「申請件数」のレポートが感覚と合わない | REQ（注文単位）で数えている | 品目ベースの実態を測るならRITM（sc_req_item）で数える。1REQに複数RITMがぶら下がる |
4つに共通するのは、「どの層の話をしているか」を最初に確定させれば防げるということです。番号のプレフィックス（REQ/RITM/SCTASK）はそのための道標で、試験でも実務でもこの識別が判断の起点になります。
PDIで3層を自分の手で作って確認する
この構造は、読むより1回作るほうが早く身につきます。PDI（開発者インスタンス）なら5分で3層を再現できます。
- Service Catalogを開き、標準で用意されているCatalog Itemを1つ注文する（内容は何でもよい）
- 発行されたREQ番号を控え、
sc_requestの一覧から開く → Requested Items関連リストにRITMが生まれていることを確認する - RITMを開き、申請時に入力したVariablesがどこに表示されるか、Catalog Tasks関連リストにSCTASKがあるか（フローの設計によっては承認待ちで止まっている）を見る
- 3つの番号をメモに並べ、「注文→品目→作業」の親子を自分の言葉で説明してみる
承認で止まっている場合は、管理者として承認レコードを承認すると、フローが次の段階へ進んでSCTASKが生成される様子まで観察できます。状態が下から上へ繰り上がる動きも、このミニ演習の中で一通り体験できます。
CIS-ITSM試験ではこう問われる
CIS-ITSM試験でのRequest Managementは、用語の暗記ではなく層の識別として出題されます。「申請内容を確認するために開くべきレコードは」「作業担当者に割り当てられるのは」「全ての品目が完了したとき何が起きるか」——本記事の早見表（テーブル名と役割）と繰り上がりの向きが、そのまま判断軸になります。
当サイトのCIS-ITSM模試（全677問）には、Request Management・SLA系のドリルとシナリオ特訓を収録しています。解き終えると分野別の正答率と推定得点が出るので、この領域の理解が数字で確認できます。間違えた問題は解説つきで復習できます。
CIS-ITSM無料模試でRequest領域の理解度を測る
学習順や他プロセスとのつながりはCIS-ITSM対策ハブからどうぞ。
まとめ
- REQ（sc_request）＝注文、RITM（sc_req_item）＝品目、SCTASK（sc_task）＝作業。1対多が2段重なった親子構造です。
- 申請内容（Variables）と進捗StageはRITMに、作業の割り当てはSCTASKに載ります。
- 承認は品目（RITM）単位が基本形。完了はSCTASK→RITM→REQへ下から繰り上がる。
- 迷ったら「どの層の話か」を番号プレフィックスで確定させてから動く——実務も試験もこれが起点です。
よくある質問
問い合わせにはREQとRITMのどちらの番号を使えばよいですか？
品目の進捗や内容に関する話ならRITMが適切です。REQは注文全体の入れ物なので、複数品目を含む場合に「どの品目の話か」が特定できません。作業チームへの確認なら、さらに一段下のSCTASK番号まで特定すると、担当者が自分の作業一覧から直接見つけられます。
申請フォームで入力した内容はどこに保存されますか？
RITM（sc_req_item）にVariablesとして紐づき、RITMのフォームで確認できます。REQ（sc_request）側には品目ごとの入力値は表示されないため、申請内容の確認はまずRITMを開くのが正解です。
SCTASKを全て完了したのにRITMが閉じません。なぜですか？
完了の繰り上がりはRITMに紐づくフロー（またはワークフロー）が制御しています。標準的な形では作業タスクの完了後にフローが完了段階へ進めますが、カスタムフローでは繰り上がり処理が組まれていない、あるいは承認や別のタスクを待っていることがあります。RITMのフロー実行状況を確認するのが切り分けの第一歩です。
関連記事・公式確認先
- ServiceNow CIS-ITSM 4プロセスの違いと連携（Incident・Problem・Change・Request）
- Catalog ItemとRecord Producerの違いをデータモデルで理解する
- CIS-ITSM対策ハブ（学習順・模試の使い方）
受験条件・試験範囲・製品仕様は変わる可能性があります。最終確認は必ず公式で行ってください。
