ServiceNow CSAのセルフサービス対策｜Catalog・Record Producer・Knowledgeの使い分けガイド

ServiceNow CSAのセルフサービスでは、Knowledge・Service Catalog・Catalog Item・Record Producer・Request / RITM といった機能が次々に出てきます。どれも「利用者が自分で進める」ための仕組みですが、「どれを何に使い分け、送信したあと何が作られるのか、試験でどう判断するのか」が掴みにくい——そう感じている方は多いはずです。

この記事は、CSAで問われるセルフサービスを、①各機能が何のためにあるか → ②取り違えると現場で何が起きるか → ③やりたいことから選ぶ早見表の順で理解するための記事です。用語の暗記ではなく、模試で迷わない判断軸を持ち帰ることをゴールにします。

▶ この分野の模擬試験を無料・登録不要で解く
CMDB・データ移行など分野別に分けた、AI生成のCSA模試です

そもそもセルフサービスは「読む・申請する・作る・処理する」

セルフサービスは、「利用者に何をさせたいか」で整理すると迷いません。

• 読む（自己解決）：Knowledge で記事を読ませ、問い合わせを減らす
• 申請する：Service Catalog の Catalog Item で標準サービスを申請（→ Request / RITM が作られる）
• 作る：Record Producer でカタログ画面から通常テーブルのレコード（Incident等）を直接作る
• 処理する：送信後の承認・タスク作成を Flow / Approval で自動化する

CSAで繰り返し問われる本質は、「読ませるのか申請させるのか」「申請（Request/RITM）か通常レコードか」を見分けられるかです。次の事故を見ると、入口と生成物の取り違えが痛いことが分かります。

これがないとどうなる ——「Incidentを作らせたいのに、申請として処理された話」

ある管理者が、社内から「PCが起動しない」といった不具合報告をセルフサービス化しようと考え、カタログにそれっぽい入力画面をCatalog Itemで作りました。すると報告のたびにRequest → RITM → Catalog Taskが生成され、承認フローまで回り、肝心の「Incidentとして対応する」流れに乗りませんでした。本来はRecord Producerで、入力からIncidentを直接作るべきでした。

これは入口と生成物を取り違えると起きることの典型です。同じ「カタログのような入力画面」でも、Catalog Itemは申請（Request/RITM）を作り、Record Producerは通常テーブルのレコードを直接作ります。「何を作りたいのか」を意識しないと、処理の流れがまるごとズレます。

だからCSAは「入口と生成物」を問う ——鍵は「読む/申請/通常レコード」

こうした取り違えを避けられるかを確認するため、CSAの試験範囲にはKnowledge・Service Catalog・Catalog Item・Record Producer が含まれています。問われるのは操作の暗記ではなく、「利用者に読ませるのか申請させるのか」「申請を作るのか通常レコードを作るのか」を正しく判断できるかです。

この先は、(1)迷ったとき立ち返る判断早見表、(2)主要な機能を「事故 → 放置するとどうなる → どう使い分けるか → 改善後」で、の順に、模試で迷わない判断軸を作っていきます。

セルフサービス 判断早見表（迷ったらここに戻る）

セルフサービスの問題は、やりたいこと（問題文）と使う機能を結べれば解けます。次の早見表が、この記事全体の地図です。各機能は後の章で事故付きで深掘りします。

ここからは、主要な機能を「実際に起きがちな事故」から見ていきます。事故の形を知っていると、選択肢の言い換えに惑わされなくなります。

Knowledge と Catalog：読ませるのか、申請させるのか

現場で起きる事故：「よくある質問」を減らしたくて、FAQ的な内容をCatalog Item（申請アイテム）として作ってしまった。利用者は「申請」した扱いになり、Request/RITMが溜まる一方で、知りたい情報は読めなかった。

放置するとどうなる：読ませるべき情報を申請にしてしまうと、不要な申請レコードが増え、自己解決も進みません。逆に申請すべきものを記事にすると、依頼が処理に乗りません。

CSAでこう使う：情報を読ませて自己解決させるならKnowledge、標準化されたサービスを依頼させるならService Catalog（Catalog Item）を使います。どちらの入口もService Portalからアクセスさせます。

改善後：「読む」と「申請する」が分かれ、自己解決が進み、申請も正しく処理に乗ります。

早見表の該当行：「情報を読ませて自己解決」→ Knowledge。「標準サービスを申請」→ Catalog Item。

Catalog Item と Record Producer：申請（Request/RITM）か通常レコードか

現場で起きる事故：冒頭で紹介した「Incidentを作らせたいのにCatalog Itemにして申請として処理された」事故がこれです。生成物を意識せず入力画面を作ってしまいました。

放置するとどうなる：申請と通常レコードを取り違えると、Incidentにしたいものが申請フローに乗ったり、逆に申請として管理すべきものが通常レコードになったりして、処理が破綻します。

CSAでこう使う：標準サービスの申請ならCatalog Item（→ Request / RITM が作られ、承認やCatalog Taskで処理）、Incidentなど通常テーブルのレコードを直接作らせるならRecord Producerを使います。「何のレコードを作るか」で選びます。

改善後：作りたいレコード（申請か通常か）に合った入口になり、処理が正しく流れます。

早見表の該当行：「標準サービスを申請」→ Catalog Item（→Request/RITM）。「通常レコードを直接作る」→ Record Producer。

Order Guide・Variable・Variable Set：複数申請と入力項目

現場で起きる事故：入社時の「PC・アカウント・席・備品」をそれぞれ別々に申請させていて、利用者も担当者も漏れが多かった。各申請で同じ入力（部署・連絡先）を毎回作り直してもいた。

放置するとどうなる：関連する複数申請をバラバラに扱うと漏れが出ます。共通の入力項目を毎回作り直すのは保守が大変です。

CSAでこう使う：複数のCatalog Itemをまとめて順番に出させるならOrder Guide、申請時の入力項目はVariable、複数アイテムで共通の入力群を再利用するならVariable Setを使います。誰に見せるかはUser Criteriaで制御します。

改善後：関連申請がまとまり漏れが減り、共通項目の再利用で保守も楽になります。

早見表の該当行：「複数の申請をまとめて出させる」→ Order Guide。「共通の入力項目を再利用」→ Variable Set。

送信後の処理：Request → RITM → Catalog Task と承認

現場で起きる事故：申請は受け付けられるが、その後だれが承認し、どのタスクで処理するかが決まっておらず、申請が放置された。

放置するとどうなる：送信後の処理を設計しないと、申請は溜まるだけで完了しません。承認や担当作業が宙に浮きます。

CSAでこう使う：Catalog Item申請ではRequestが作られ、その中に1つ以上のRITM（Requested Item）、各RITMの処理担当作業としてCatalog Taskが作られます。承認やタスク作成の流れはFlow / Approvalで自動化します。

改善後：申請が承認→処理→完了まで流れ、放置がなくなります。

早見表の該当行：「申請後に承認・タスクを自動化」→ Flow / Approval。1 Requestに複数RITM、処理作業＝Catalog Task。

「読む/申請/通常レコード」を取り違える罠

セルフサービスの判断問題は、入口と生成物を取り違えないかが問われます。具体シナリオに翻訳して違いを見ます。

「最も適切なのは？」と問われたら、「読ませるか申請させるか」「申請（Request/RITM）か通常レコードか」の軸で選びます。これが迷わないための判断軸です。

セルフサービスの運用ベストプラクティス

利用者が自分で進められる仕組みを正しく作るために、現場で押さえておきたい運用のベストプラクティスは次の5つです。

1. 「読む」と「申請する」を分ける。情報提供はKnowledge、依頼はCatalog Itemにします。
2. 生成物で入口を選ぶ。申請（Request/RITM）はCatalog Item、通常レコードはRecord Producerです。
3. 関連申請はまとめる。複数申請はOrder Guide、共通入力はVariable Setで再利用します。
4. 送信後の処理を設計する。承認・Catalog Task・Flowで完了まで流します。
5. 公開範囲を制御する。User Criteriaで「誰に見せる・使わせるか」を決めます。

PDIで手を動かして確認する場所

Personal Developer Instance（PDI）で実際の画面を触ると、早見表が記憶に定着します。

• Knowledge / Knowledge Base / Category：記事の公開と分類を見る
• Service Catalog / Catalog Item / Variable / Variable Set：申請アイテムと入力項目を作る
• Record Producer：通常テーブル（Incident等）への直接作成を確認する
• Request / RITM / Catalog Task / Approval / Flow：送信後の生成物と処理を追う
• User Criteria / Service Portal：公開範囲と利用者入口を確認する

まとめ：入口と生成物で選べると、判断問題に強くなる

• セルフサービスは「読む・申請する・作る・処理する」で考える
• 読む＝Knowledge、申請＝Catalog Item、通常レコード作成＝Record Producer
• Catalog Item申請は Request → RITM → Catalog Task と流れる
• 複数申請＝Order Guide、共通入力＝Variable Set、公開範囲＝User Criteria
• 送信後の承認・タスクはFlow / Approvalで完了まで設計する

セルフサービスは、CSAでも「入口と生成物の取り違え」を突く判断問題が多いテーマです。事故の形と早見表が頭に入ったら、実際の問題で手を動かして判断軸を固めましょう。