ServiceNowのService Catalogを触りはじめると、多くの人が同じ場所で手を止めます。「申請フォームを作りたいだけなのに、Catalog ItemとRecord Producerのどちらを使えばいいのか分からない」という壁です。画面上はどちらもポータルに並ぶ入力フォームで、ユーザーから見れば見分けがつきません。けれど、この2つは送信ボタンを押した後にまったく別の動きをします。試験でも実務でも、つまずきの正体は「フォームの見た目」ではなく「フォームの裏で動いているデータモデル」にあります。
この記事では、Catalog ItemとRecord Producerが内部でどのテーブルにレコードを作るのかを軸に、両者の違い・選び分け・実装でハマる箇所を整理します。CSA試験で問われる「役割の区別」と、CAD試験で問われる「実装時の設計判断」の両方に対応できるよう、暗記ではなく判断の道筋として説明します。
Service Catalogでつまずく理由は「画面の裏のデータモデル」
Service Catalogの学習でつまずく人の多くは、フォームの見た目から入ってしまいます。「項目を並べて、送信ボタンを付ければ申請フォームになる」という理解は半分正しく、半分危険です。なぜなら、ServiceNowではフォームに入力された値が「どのテーブルの、どのレコードになるか」が、Catalog ItemとRecord Producerで根本的に異なるからです。
たとえば同じ「PCの貸し出しフォーム」を作るにしても、Catalog Itemで作れば申請が承認・タスク処理の対象として記録され、Record Producerで作れば指定したテーブルに1件のレコードが直接できます。見た目が同じでも、後工程に渡るデータの形が違う。ここを意識せずに作ると、「フォームは送信できているのに、想定したレコードがどこにも見当たらない」という事態が起きます。
CSA試験がこの領域で確認したいのは、まさにこの「裏側の理解」です。フォームの作り方そのものより、「送信された後、システムの中で何が起きるか」を説明できるかが問われます。だから学習の出発点も、見た目ではなくデータモデルに置く必要があります。
申請を追うREQ・RITMと、履行処理が作るCatalog Task
Catalog Itemは「サービスや作業を依頼するための申請メニュー」です。PCの調達、アクセス権の付与、ソフトウェアの利用承認のように、誰かが何かを依頼し、承認や作業を経て完了する業務を標準化するために使います。
Catalog Itemの注文はREQとRITMで追跡します。実作業をCatalog Task（SCTASK）へ分ける場合は、関連付けたFlowのCreate Catalog Taskアクションなどで作成します。送信するだけでSCTASKが必ず生まれるわけではなく、承認の有無、生成条件、タスク数は履行処理の設計によります。次の表は3種類のレコードの役割を整理したものです。仕様の確認先：Create Catalog Task action、Create a flow with a Service Catalog trigger。
横にスクロールできます
| レコード | テーブル | 役割 |
|---|---|---|
| Request（REQ） | sc_request | 送信全体をまとめる親レコード。1回の送信に複数のRequested Itemをぶら下げられる |
| Requested Item（RITM） | sc_req_item | カタログ1品目ごとの申請。入力されたVariablesと履行ステータスを追跡する中心 |
| Catalog Task（SCTASK） | sc_task | 履行処理が作成する実作業の単位。作成条件や承認との順序は設定による |
流れを言葉にすると、ユーザーがCatalog Itemを送信するとまずRequest（親）ができ、その下に申請品目ごとのRITMができます。RITMが承認・履行の追跡単位になり、必要な実作業を履行処理でCatalog Task（SCTASK）として作成できます。1つのRITMから複数のCatalog Taskを作る構成もあります。たとえば「新入社員のPCセットアップ」というRITM1件に対して、「PCを準備する」「アカウントを作る」「席に設置する」という3つのSCTASKがぶら下がる、という形です。
この「REQ＝送信全体／RITM＝申請品目／SCTASK＝実作業」という役割分担を取り違えると、承認やSLA、通知をどのレコードに紐づけるべきかが分からなくなります。CSAの設問では、この3者のうち「どれが何の単位か」を問う形がよく出ます。RITMを承認・履行の主役レコードとして押さえておくのが軸になります。
直接生成の流れ：Record Producer → 指定テーブルへ1レコードを作る
Record Producerは「カタログ風のフォームから、特定のテーブルにレコードを1件直接作る入口」です。ここで大切なのは、Record Producerは単なる見た目の似たフォームではなく、Catalog ItemのようにRequest/RITM/Catalog Taskの連鎖を作らない、という点です。
Record Producerの動きは4ステップで整理できます。
- ポータルでユーザーがフォームに入力する
- Record Producerが送信を受け取る（カタログ側の入口として振る舞う）
- 入力されたVariablesの値が、対象テーブルのフィールドへマッピングされる
- 対象テーブルに標準レコードが1件、直接作られる
ここでできるレコードはRITMではありません。Record Producerに設定した「対象テーブル（Table name）」に対して、たとえばIncident、あるいは独自に作った業務テーブルのレコードが直接生成されます。「問い合わせフォームから送信したらインシデントが1件立つ」「ポータルの受付フォームから業務テーブルにレコードが入る」といった用途が典型です。
ServiceNowの公式ドキュメントでも、Record Producerは「Service Catalogの入口を通して、指定したテーブルにレコードを作成する仕組み」として説明されています。承認・履行の重い流れを挟まず、入力をそのまま1件のレコードに落とす——これがCatalog Itemとの決定的な違いです。
Record Producerの入力と生成されたIncidentをつなぐ
先に考えてみましょう：Record Producerから送信した内容は、RITMとIncidentのどちらで確認すればよいでしょうか。
今回はIncidentを生成する学習用Record Producerで確認します。Variableの保存先を指定した設定を見てから、入力した文章が新しいIncidentへ渡るところまで追います。
今回確認した結果：直接VariableのMap to fieldをONにし、FieldにShort description（short_description）を指定して送信すると、Incident INC0010015が作成されました。Short descriptionは入力した「PCが起動しない（PDI学習20260910）」と一致しています。今回はこの明示的な転記方法を確認しました。
確認環境：ServiceNow PDI／Core UI、学習用Record ProducerのTry It、生成先はIncident。確認日：2026-09-10。
判断のポイント：Record Producerは指定した対象テーブルのレコードを作る入口です。Catalog Itemの履行を追うREQ・RITMとは、送信後に確認する場所が異なります。
Variables と通常フィールドを混同しない
Catalog ItemとRecord Producerの両方でつまずきやすいのが、Variables（変数）と通常フィールドの扱いです。ここを混同すると、実装後に「入力したはずの値が消える」という典型的な失敗を踏みます。
Variablesは、カタログのフォーム上に置く入力項目です。重要なのは、Variablesは対象テーブルの通常フィールドそのものではない、という点です。
Catalog Itemの場合、Variablesに入力された値（requested_for、reason、categoryなど）はRITM（sc_req_item）に紐づくデータとして保持されます。RITMのフォーム上の通常フィールドとは別枠で、「この申請に対して入力された値」として記録されるイメージです。
Record Producerで対象フィールドへ値を設定する方法は複数あります。今回の写真では、直接追加したVariableのMap to fieldをONにし、FieldにShort description（short_description）を指定する方法を確認しました。このチェック項目だけが唯一の転記方法ではありません。
- 同名のVariableで対応させる：VariableのNameを対象フィールドの内部名と一致させ、フィールドに対応する型を使うと、そのフィールドへ値を設定できます。画面に表示するQuestionの文言だけを同じにする意味ではありません。
- Map to fieldとFieldで指定する：Record Producerに直接所属するVariableで転記先を選びます。今回の例ではVariable名と保存先フィールド名が異なります。
- Scriptで代入する：Record ProducerのScriptで、入力値を表す
producer.VARIABLE_NAMEから生成レコードのcurrent.FIELD_NAMEへ値を設定できます。 - Templateで固定値を設定する：入力値の転記とは別に、生成する全レコードへ共通の値を設定できます。
仕様の確認先：Populate record producer data and redirect users、Create a service catalog variable。
入力できたのに対象レコードが空欄だった場合は、採用した転記方法から確認します。同名対応ならNameと型、明示設定ならMap to fieldとField、Scriptなら参照しているVariable名と代入先を確認します。空欄という結果だけで、Map to fieldの設定漏れと決めつけないことが大切です。Variable名を変更すると、同名対応やその名前を参照するScriptにも影響します。
どちらを選ぶか：要件からの判断基準（比較表）
ここまでの内容を、要件から逆算して選べる形にまとめます。判断の起点は1つだけ——「送信された後、主役になるレコードはRITMか、対象テーブルのレコードか」です。この問いに答えられれば、ほとんどの設計の迷いは解けます。
参考までに、似た仕組みであるOrder Guideも並べて比較します。Order Guideは複数のCatalog Itemを束ねて一度の流れで申請させる仕組みで、選択肢として混同されやすいため、区別の軸として押さえておくと役立ちます。
横にスクロールできます
| 観点 | Catalog Item | Record Producer | Order Guide |
|---|---|---|---|
| 何ができる | REQ・RITMで申請を追跡し、必要なSCTASKは履行処理で作る | 指定テーブルに標準レコードを1件作る | 複数のCatalog Itemを束ねて申請させる |
| 送信後の主役レコード | RITM（sc_req_item） | 対象テーブルのレコード（例：Incident） | 束ねた各Catalog ItemのRITM |
| 承認・履行の流れ | 承認・タスク分解を前提にできる | 重い承認層を挟まず直接生成 | 各品目の流れをまとめて開始 |
| 向いている要件 | PC貸与・権限追加・ソフト利用承認 | 問い合わせからのインシデント起票・業務テーブルへの直接入力 | 入社セットなど複数品目の一括申請 |
| 主に問われる試験 | CSA（役割の区別）／CAD（実装） | CSA（役割の区別）／CAD（マッピング設計） | CSA（仕組みの区別） |
要件の言葉で言い換えると、こうなります。
- ユーザーが「サービスを依頼」し、承認や担当者の作業、申請単位の履歴が必要 → Catalog Item
- ユーザーの入力を「特定テーブルの1レコード」として直接残したい → Record Producer
- 複数の品目を条件に応じてまとめて申請させたい → Order Guide
「承認やタスクが要るか」「申請という単位で履歴を残したいか」を要件から拾えば、自然と選択肢は1つに絞られます。
Flow Designer・承認・通知との関係
Catalog ItemとRecord Producerを学ぶとき、Flow Designerとの関係を整理しておくと混乱が減ります。よくある誤解が、「どちらを使うか」と「Flow Designerを使うか」を同じ判断だと思ってしまうことですが、これは別々の関心事です。
Catalog ItemとRecord Producerは、あくまで「入口（intake）」です。ユーザーから入力を受け取り、レコードを作るところまでが役割です。一方、承認のルーティング、通知、Catalog Taskの作成、外部連携は、関連付けたFlowなどの履行処理で設計します。既存のWorkflowにもCatalog Taskを作るアクティビティがあるため、Flow Designerだけが唯一の生成経路とは限りません。仕様の確認先：Catalog Task workflow activity。
つまり、入口（Catalog Item / Record Producer）と、送信後の処理（Flow Designer）は、組み合わせて使うものであって、どちらかを選ぶ関係ではありません。Catalog Itemにフローを紐づけて承認とタスク生成を回すこともできますし、Record Producerでレコードを作った後にフローを起動して後続処理を走らせることもできます。Record Producerでフローを使うかは任意で、単純な直接生成だけならフローなしでも成立します。
通知や承認を「どのレコードに紐づけるか」も、ここで効いてきます。Catalog Itemなら承認・通知はRITMを単位に設計するのが自然で、Record Producerなら対象テーブルのレコードを起点に後続処理を考えます。入口の違いが、後続のフロー設計の起点を決める、という関係です。
実装でよくある失敗
ここでは、Catalog ItemとRecord Producerの実装・運用で実際に起きやすい失敗を挙げます。試験で問われる落とし穴とも重なります。
- Catalog Itemをフォームとしてしか作っていない：承認・タスク・通知を設計せず、ただの入力フォームとして置いてしまう。Catalog Itemの価値は後工程の流れにあるので、入口だけ作って満足すると業務が回らない。
- RITMとCatalog Taskの役割を取り違える：RITM（申請の単位）とCatalog Task（実作業の単位）を混同し、承認やSLAを誤ったレコードに紐づけてしまう。1つのRITMから複数のSCTASKが生まれる関係を押さえる。
- Record Producerの対象テーブルが曖昧：どのテーブルにレコードを作るのかを決めずに作り、想定と違うテーブルにレコードができる、あるいはどこにもできていないように見える。
- 値の転記方法を取り違える：対象フィールドが空なら、同名対応のNameと型、Map to fieldとField、Scriptの参照先を確認する。明示設定の有無だけでは原因を特定できない。
- Variable名の変更で転記が変わる：同名対応では対象フィールドの内部名との一致が変わり、FlowやScriptでは参照している名前と合わなくなる場合がある。Nameを変更する前に、どの仕組みがその名前を使っているか確認する。
これらはどれも「画面はそれらしく動いているのに、裏のデータや後続処理が想定どおりでない」という共通点があります。送信後に何が起きるかを最初に決めてから作ると、ほとんど防げます。
PDIでCatalog ItemとRecord Producerを両方作って挙動を比べる手順
理屈で覚えるより、Personal Developer Instance（PDI）で実際に両方を作って、送信後にできるレコードの違いを目で確認するのが最短です。次の手順で進めます。
1. Catalog Itemを1つ作る
- 左ナビゲーションで
Service Catalog > Catalog Definitions > Maintain Itemsを開く - New から新しいCatalog Itemを作り、名前と所属カタログ・カテゴリを設定する
- Variablesタブで入力項目を1〜2個（例：requested_for、short text）追加する
- 保存し、Try it（またはポータル）から実際に送信する
2. 送信後にできたレコードを確認する
sc_request（Request）とsc_req_item（RITM）を開き、送信1件に対して親REQと子RITMができていることを確認する- RITMを開き、入力したVariablesの値がRITM側に保持されていることを見る
3. 同じ入力項目でRecord Producerを1つ作る
Service Catalog > Catalog Definitions > Record Producersを開く（Catalog Itemとはメニューが別である点に注意）- New から作成し、Table name に対象テーブル（まずはIncidentで試すと分かりやすい）を指定する
- Variablesタブで、先ほどと同じような入力項目を追加する
- この演習では直接VariableのMap to fieldをONにし、FieldにShort description（short_description）を選ぶ。同名対応やScriptなど、別の転記方法との違いも確認する
- 保存し、ポータルから送信する
4. 生成されたレコードの違いを見比べる
- Record Producerの送信後、
sc_req_item（RITM）には何も増えていないことを確認する - 代わりに対象テーブル（Incidentテーブル）に、入力値が入った新規レコードが1件できていることを確認する
- 転記方法を変えて比較するときは、同名対応やScript、Templateも確認し、どの仕組みが値を設定しているかを切り分ける。Map to fieldをOFFにするだけで必ず空欄になるとは限らない
この「Catalog Itemは sc_req_item に、Record Producerは対象テーブルに」という差を実機で一度見ておくと、試験の選択肢が同じ見た目の説明文で並んでいても、中身で選べるようになります。
まとめ
Catalog ItemとRecord Producerは、ポータル上ではどちらも同じ入力フォームに見えます。けれど中身は別物で、Catalog ItemはREQ・RITMで申請を追跡し、必要なCatalog Taskを履行処理で作成します。Record Producerは指定したテーブルにレコードを直接作る入口です。VariablesはどちらでもRITMやフォーム上の通常フィールドとは別枠で扱われ、Record Producerでは同名対応、Map to field、Scriptなどから転記方法を選び、保存先と型を確認します。
選び分けの判断は「送信後の主役がRITMか、対象テーブルのレコードか」の一点に集約できます。承認・タスク・申請単位の履歴が要るならCatalog Item、入力を1レコードとして直接残したいならRecord Producer。入口（Catalog Item / Record Producer）と後続処理（Flow Designer）は別の判断だと分けて考えれば、設計の迷いは整理されます。CSAでは役割の区別が、CADではマッピングや命名変更の影響まで含めた実装判断が問われます。手を動かして両方の挙動を見比べておくことが、いちばん確実な理解への近道です。
学習を次に進めるなら、Service Catalog/セルフサービス領域のCSA模試・総合演習で、ここで整理した判断軸が身についているかを確認してみてください。
よくある質問
Q. Catalog ItemとRecord Producerは、ポータル上では区別がつかないのですか？
A. ユーザーから見た見た目はほぼ同じで、どちらもカタログに並ぶ入力フォームとして表示されます。区別は送信後にできるレコードで決まります。Catalog ItemはRITM（sc_req_item）を、Record Producerは対象テーブルのレコードを作ります。判断するときは「送信後に何ができるか」で見分けます。
Q. これはCAD試験の対策にもなりますか？
A. なります。CSAではCatalog ItemとRecord Producerの「役割の区別」が中心に問われますが、CADではVariablesと対象フィールドのマッピング設計、Variable名を変更したときの影響、対象テーブルの選定といった「実装時の判断」まで踏み込んで問われます。この記事のデータモデルの理解は、両方の土台になります。
Q. Record Producerでも承認や通知は付けられますか？
A. 付けられます。Record Producer自体は対象テーブルにレコードを作る入口ですが、生成されたレコードを起点にFlow Designerを起動すれば、承認・通知・後続タスクといった処理を回せます。フローを使うかは任意で、単純にレコードを直接作るだけならフローなしでも成立します。
