ServiceNow CSAの問題に Knowledge Base が出てきたとき、「ナレッジ記事を置く場所」と覚えるだけでは、Service Catalog・Record Producer・Virtual Agent と並べられた瞬間に迷います。試験で問われるのは用語の意味ではなく、利用者に ①読ませて自己解決させる のか、②申請させる のか、③レコードを作る のか、④会話で誘導する のか——という目的の切り分けです。この記事は、次の順で「迷わない判断軸」を作ります。
- 目的から機能を選ぶ判断早見表でいったん全体を掴む
- 取り違えると現場で何が起きるかを見る（FAQをCatalog Itemで作る事故）
- Knowledgeの4要素（Base / Article / Category / User Criteria）の役割を切り分ける
- PDIで確認する場所と、模試での読み方に落とす
先に結論です。読む＝Knowledge、申請＝Service Catalog、通常レコード作成＝Record Producer、会話で誘導＝Virtual Agent。そして Knowledge の中は、Knowledge Base＝記事を入れる箱／Knowledge Article＝1本の記事／Category＝探すための分類／User Criteria＝誰が読める・作れるかの条件、と捉えると整理できます。
関連練習：ServiceNow CSA セルフサービス・自動化特訓では、Knowledge・Service Catalog・Record Producer・Flow などの使い分けを問題形式で確認できます。
- そもそも Knowledge Base は「読んで解決する情報」の置き場
- これがないとどうなる：FAQをCatalog Itemで作ってしまう事故
- 判断早見表：目的から機能を選ぶ
- Knowledge Base・Article・Category・User Criteria の関係
- Service Catalog との違い：読むのか、申請するのか
- Category は権限ではなく「探しやすくする分類」
- User Criteria は「誰が読める・作れるか」を決める
- 公開・検索で見るべきポイント
- CSAで狙われやすい判断パターン
- Knowledge Base を活かす運用ベストプラクティス
- PDIで手を動かして確認する場所
- 模試で迷わないための読み方
- まとめ：Knowledge Base は「読む・探す・見せる範囲」で考える
- 公式ドキュメントで確認できること
そもそも Knowledge Base は「読んで解決する情報」の置き場
Knowledge Base は、利用者や担当者が参照する記事をまとめる単位です。公式Docsでも、Knowledge Management はナレッジベースで情報を共有し、セルフヘルプ・トラブルシューティング・作業解決の情報を利用者へ届けるアプリケーションとして説明されています。つまりCSAで見るべき軸は「読ませて自己解決させるための情報管理」。申請受付・会話分岐・レコード作成と混ぜると、選択肢で迷います。定義はここまでで十分です。大事なのは、次の境界の判断です。
利用者から見ると
検索して記事を読み、問い合わせや申請をしなくても自分で解決する入口。
管理者から見ると
記事の分類・公開状態・閲覧条件・投稿者/管理者を設計する対象。
試験問題として見ると
「自己解決」「記事」「カテゴリ」「検索」「閲覧条件」が出たら Knowledge 領域を疑う。
これがないとどうなる：FAQをCatalog Itemで作ってしまう事故
境界を判断できないと、現場では具体的にこういう失敗が起きます。「事故 → 放置 → 正しい設定 → 改善後」の流れで見ると、試験の選択肢が単語ではなくシーンとして判断できるようになります。
早見表の対応行：「読む＝Knowledge」。ありがちな誤答：「Record Producer で作る」——レコードは作れますが、目的は読ませて自己解決させることなので不適切です。問題文が「情報を読ませる」のか「依頼を処理に乗せる」のかを先に読むのがコツです。
判断早見表：目的から機能を選ぶ
ここまでの境界を1枚に圧縮したのが次の早見表です。左：利用者の目的から機能を選ぶ対応、右上：Knowledge の中の4要素（箱・分類・記事・閲覧条件）の入れ子、右下：「出ない・読めない」ときに見る場所、をまとめています。迷ったらまずここに戻ってください。
Knowledge Base・Article・Category・User Criteria の関係
| 要素 | 役割 | CSAでの見抜き方 |
|---|---|---|
| Knowledge Base | 記事をまとめる入れ物。読者・管理者・投稿者・公開範囲の単位になる。 | 「IT向け」「人事向け」など、記事群全体をどう分けるかが問われる。 |
| Knowledge Article | 利用者が読む1本の記事。手順・FAQ・トラブルシュート・解決策を記載。 | 「よくある質問を公開」「手順を読ませる」「検索で見つける」が出たら候補。 |
| Category | Knowledge Base 内で記事を探しやすくする分類。親子の階層を持てる。 | 「記事を分類」「カテゴリ階層」「探しやすくする」が出たら候補。 |
| User Criteria | 誰が読めるか、誰が作成・編集できるかを条件で制御する。 | 「特定部署だけに見せる」「外部には見せない」など公開範囲が問われる。 |
公式Docsでも、Knowledge Base には記事を整理するカテゴリ階層があり、User Criteria で Knowledge Base や記事へのアクセスを制御できると説明されています。試験では、この関係を「箱・記事・分類・閲覧条件」として切り分けられるかが問われます。
Service Catalog との違い：読むのか、申請するのか
Knowledge と Service Catalog は、どちらも利用者向けのセルフサービスに見えます。しかし目的が違います。冒頭の事故（FAQをCatalog Itemにした例）が、まさにこの境界の取り違えでした。
| 目的 | 使う機能 | 送信後・利用後に起きること |
|---|---|---|
| 利用者に手順やFAQを読ませたい | Knowledge Article | 記事を閲覧して自己解決する。申請レコードは作らない。 |
| PC貸与やアカウント発行を申請させたい | Catalog Item | Request / RITM / Catalog Task などの申請・履行の流れに乗る。 |
| 問い合わせ内容から Incident などを直接作りたい | Record Producer | 指定した通常テーブルにレコードを作る。 |
| 利用者と会話しながら次の操作へ誘導したい | Virtual Agent Topic | 会話の分岐で情報提示・申請誘導・担当者引き継ぎを行う。 |
問題文に「問い合わせを減らす」「同じ質問への回答を公開する」「利用者が検索して読む」とあれば Knowledge が自然です。一方、「申請を受け付ける」「承認する」「タスクで処理する」とあれば Catalog Item や Flow 側の話になります。
Category は権限ではなく「探しやすくする分類」
Category は、記事を分類して探しやすくするためのものです。公式Docsでも、Knowledge Base ごとにカテゴリ階層を作り、親子関係で整理できると説明されています。ここで注意したいのは、Category を「誰に見せるかの権限制御」と混同しないことです。これも放置すると事故になります。
ひっかけ：「人事カテゴリの記事は人事部だけに見せたい」と書かれていると、Category だけで制御できるように見えます。Category で“人事”に分けただけで安心すると、他部署からもその記事が読めてしまう——分類と公開範囲は別物だからです。
見るべき場所：「分類したいのか」「閲覧者を絞りたいのか」。分類は Category、閲覧者条件は User Criteria（Can Read） で考えます。実運用では両方をセットで設計しますが、CSAの判断では役割の違いを先に押さえます。
User Criteria は「誰が読める・作れるか」を決める
User Criteria は、Knowledge Base や Knowledge Article に対して、誰が読めるか・誰が作成編集できるかを制御します。公式Docsでは、ユーザー・グループ・ロール・会社・場所・部署などを条件に使えることが示されています。
その Knowledge Base や記事を読めるユーザー条件。利用者向けの公開範囲を決める軸で、試験で最も出やすい。
記事を作成・編集できるユーザー条件。投稿者・ナレッジ担当者側の運用に関係する。「読む」と「作る」を別々に設計できる点が要点。
条件を「すべて満たす」か「いずれか満たす」かで効き方が変わる。厳しくしすぎると、意図せず誰も一致せず非公開になることがある。
CSAでは「特定部署だけに見せたい」「外部ユーザーには非公開にしたい」「作成できる人をナレッジ担当に絞りたい」で User Criteria が候補になります。逆に、記事の分類名を変えたいだけなら Category、本文を整えたいだけなら Knowledge Article 側の話です。
公開・検索で見るべきポイント
Knowledge は「記事を作ったら終わり」ではありません。利用者が検索で見つけ、閲覧でき、内容が古くならないように管理する必要があります。公式Docsでも、検索結果は閲覧権限のある記事や質問を対象にし、Knowledge Base や Category で絞り込めると説明されています。
検索できるか
タイトル・本文・カテゴリ・言語・公開状態を確認。利用者の検索語に合う言葉で書かれているかも重要。
読めるか
Can Read や記事レベルの User Criteria、ポータル側の公開範囲を確認。
更新できるか
Can Contribute、Knowledge Manager、レビュー・承認の運用を確認。
問題文で「記事は存在するのに検索に出ない」「特定ユーザーだけ読めない」「公開前にレビューしたい」といった症状が出たら、記事本文ではなく、公開状態・User Criteria・Category・検索条件・ポータル入口を切り分けます（早見表の右下と対応）。
CSAで狙われやすい判断パターン
| 問題文の手がかり | 選ぶべき考え方 | 間違えやすい近接概念 |
|---|---|---|
| よくある質問を公開し、利用者が検索して読めるようにしたい | Knowledge Article を Knowledge Base に公開する | Catalog Item で申請受付にしてしまう |
| 記事を「ネットワーク」「アカウント」「端末」などに分けたい | Category で分類する | User Criteria で分類名を作ろうとする |
| 人事部の記事を人事部だけに見せたい | User Criteria で Can Read を制御する | Category だけで閲覧制御したつもりになる |
| 利用者の質問に会話で答え、必要なら申請へ誘導したい | Virtual Agent Topic を検討する | Knowledge Article だけで会話分岐を実現しようとする |
| 記事を公開前に確認し、担当者が内容を更新できるようにしたい | Knowledge 管理者・投稿者・公開プロセスを設計する | Service Catalog の承認フローと混同する |
Knowledge Base を活かす運用ベストプラクティス
試験の判断軸は、そのまま「事故を起こさない運用」につながります。次の5点は、CSAの選択肢としても運用設計としても通用する基本です。
「社内IT」「人事」「顧客向け」など対象読者でベースを分けると、公開範囲（User Criteria）と管理者を素直に設計できる。
階層を深くしすぎると利用者が辿れない。検索＋2〜3階層程度で「探しやすさ」を優先する。
Can Read は必要な利用者へ、Can Contribute はナレッジ担当へ。最初から全公開にせず、必要範囲から広げる。
公開プロセスと定期見直しで、古い手順が検索上位に残り続ける事故を防ぐ。
「パスワード再設定」など、実際に検索される語をタイトル・本文に入れる。正しい記事でも検索語と合わなければ読まれない。
PDIで手を動かして確認する場所
Personal Developer Instance で触るなら、次の順で見ると理解しやすくなります。CSA対策では細かな画面操作の暗記より、どこで何を決めるのかを確認してください。
- All > Knowledge > Administration > Knowledge Bases で Knowledge Base を開き、Can Read / Can Contribute を確認する
- Knowledge Categories の関連リストで、カテゴリが Knowledge Base ごとに管理されることを見る
- Knowledge Article を開き、Knowledge Base・Category・公開状態・本文を確認する
- User Criteria を開き、ユーザー・グループ・ロール・部署などの条件を確認する
- 利用者視点でポータルや検索画面を開き、見える記事と見えない記事の差を確認する
模試で迷わないための読み方
問い合わせ削減・FAQ・手順・トラブルシュート・自己解決が手がかり。
記事を探しやすくする・階層化する・カテゴリ別に整理する文脈。
部署・グループ・ロール・外部/内部などの公開範囲が手がかり。
Request・RITM・Catalog Task・承認・履行が出たら Catalog Item 側を疑う。
まとめ：Knowledge Base は「読む・探す・見せる範囲」で考える
- Knowledge Base は、自己解決のための記事をまとめる場所
- Knowledge Article は1本の記事、Category は記事の分類、User Criteria は閲覧・投稿条件
- Knowledge と Service Catalog の違いは「読む」か「申請する」か
- Category を権限制御と混同しない。公開範囲は User Criteria で考える
- 検索に出ない・読めない問題は、公開状態・User Criteria・Category・ポータル入口を切り分ける
Knowledge Base は、CSAのセルフサービス領域の中でも「単語暗記で解けそうに見えて、実は境界を問われる」テーマです。Service Catalog・Record Producer・Virtual Agent と並べられたら、まず問題文が「読む」「申請する」「会話する」「レコードを作る」のどれを求めているかに戻ると、落ち着いて判断できます。
次に解く：ServiceNow CSA セルフサービス・自動化特訓へ進む
関連理解として、ServiceNow CSAのセルフサービス対策もあわせて確認すると、Knowledge と Catalog の境界がさらに整理しやすくなります。
公式ドキュメントで確認できること
この記事は、ServiceNow公式ドキュメントの内容を、CSA学習者向けの判断軸として整理したものです。公開前に最新リリースの表記と画面名は必ず確認してください。
