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試験がこの領域で確認したいのは、まさにこの「裏側の理解」です。フォームの作り方そのものより、「送信された後、システムの中で何が起きるか」を説明できるかが問われます。だから学習の出発点も、見た目ではなくデータモデルに置く必要があります。
申請の流れ：Catalog Item → Request(REQ) → RITM → Catalog Task(SCTASK)
Catalog Itemは「サービスや作業を依頼するための申請メニュー」です。PCの調達、アクセス権の付与、ソフトウェアの利用承認のように、誰かが何かを依頼し、承認や作業を経て完了する業務を標準化するために使います。
Catalog Itemを送信すると、内部では次の3階層のレコードが連鎖して作られます。これがCatalog Itemを理解するうえで最も重要な構造です。
横にスクロールできます
| レコード | テーブル | 役割 |
|---|---|---|
| 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との決定的な違いです。
Variables と通常フィールドを混同しない
Catalog ItemとRecord Producerの両方でつまずきやすいのが、Variables（変数）と通常フィールドの扱いです。ここを混同すると、実装後に「入力したはずの値が消える」という典型的な失敗を踏みます。
Variablesは、カタログのフォーム上に置く入力項目です。重要なのは、Variablesは対象テーブルの通常フィールドそのものではない、という点です。
Catalog Itemの場合、Variablesに入力された値（requested_for、reason、categoryなど）はRITM（sc_req_item）に紐づくデータとして保持されます。RITMのフォーム上の通常フィールドとは別枠で、「この申請に対して入力された値」として記録されるイメージです。
一方Record Producerの場合は、Variablesの値を対象テーブルのフィールドへ明示的にマッピングしてあげないと、対象レコードに値が入りません。フォーム上のVariablesと、対象テーブルのフィールドは、自動では一対一に結びつかないからです。Record Producerでは、この対応づけ（どのVariableをどのフィールドに入れるか）を設定しておく必要があります。
ここで起きる代表的な失敗が、「フォームは入力できて送信もできるのに、対象レコードを見ると肝心の値が空になっている」というものです。原因はほぼ、Variablesと対象フィールドのマッピングが抜けていること。CADでは、このマッピングの設計や、Variable名を後から変更したときの影響まで踏み込んで問われます。
どちらを選ぶか：要件からの判断基準（比較表）
ここまでの内容を、要件から逆算して選べる形にまとめます。判断の起点は1つだけ——「送信された後、主役になるレコードはRITMか、対象テーブルのレコードか」です。この問いに答えられれば、ほとんどの設計の迷いは解けます。
参考までに、似た仕組みであるOrder Guideも並べて比較します。Order Guideは複数のCatalog Itemを束ねて一度の流れで申請させる仕組みで、選択肢として混同されやすいため、区別の軸として押さえておくと役立ちます。
横にスクロールできます
| 観点 | Catalog Item | Record Producer | Order Guide |
|---|---|---|---|
| 何ができる | Request/RITM/Catalog Taskの連鎖を作る | 指定テーブルに標準レコードを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 Designerが担います。
つまり、入口（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の対象テーブルが曖昧：どのテーブルにレコードを作るのかを決めずに作り、想定と違うテーブルにレコードができる、あるいはどこにもできていないように見える。
- Variablesと対象フィールドのマッピング漏れ：Record Producerで入力は受け取れるのに、対象レコードの値が空になる。マッピング設定の抜けが原因。
- Variable名を後から変更してフローやスクリプトが壊れる：FlowやスクリプトがVariable名を参照しているのに、名前を変えてしまい参照が切れる。命名変更の影響範囲を確認せずに直すと事故になる。
これらはどれも「画面はそれらしく動いているのに、裏のデータや後続処理が想定どおりでない」という共通点があります。送信後に何が起きるかを最初に決めてから作ると、ほとんど防げます。
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タブで、先ほどと同じような入力項目を追加する
- 入力したVariablesを対象テーブルのフィールド（例：short_description）にマッピングする設定を行う
- 保存し、ポータルから送信する
4. 生成されたレコードの違いを見比べる
- Record Producerの送信後、
sc_req_item（RITM）には何も増えていないことを確認する - 代わりに対象テーブル（Incidentテーブル）に、入力値が入った新規レコードが1件できていることを確認する
- マッピングを意図的に外して再送信し、対象レコードの該当フィールドが空になることも見ておくと、マッピングの役割が体感できる
この「Catalog Itemは sc_req_item に、Record Producerは対象テーブルに」という差を実機で一度見ておくと、試験の選択肢が同じ見た目の説明文で並んでいても、中身で選べるようになります。
まとめ
Catalog ItemとRecord Producerは、ポータル上ではどちらも同じ入力フォームに見えます。けれど中身は別物で、Catalog Itemは Request → RITM → Catalog Task の連鎖を作り、Record Producerは指定したテーブルに1件のレコードを直接作ります。VariablesはどちらでもRITMやフォーム上の通常フィールドとは別枠で扱われ、Record Producerでは対象フィールドへのマッピングが必須になります。
選び分けの判断は「送信後の主役が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を起動すれば、承認・通知・後続タスクといった処理を回せます。フローを使うかは任意で、単純にレコードを直接作るだけならフローなしでも成立します。
