ナレッジの本棚と分類（kb_knowledge_base）

前回、ナレッジ記事そのもの（kb_knowledge）が task を継承しない独立したテーブルであることを確認しました。記事は単独で浮いているのではなく、必ず Knowledge Base（ナレッジベース＝本棚） に所属し、多くは Category（カテゴリ＝分類） で整理されています。では、その「本棚」や「分類」はどんなテーブルで、記事とどうつながっているのでしょうか。

この記事では、Knowledge Base（kb_knowledge_base）と Category（kb_category）を、概念図だけでなく実際のテーブル定義とレコードから読み解きます。前回触れた「公開が即時か承認かは Knowledge Base 側で決まる」という挙動が、どのフィールドで実現されているのかを確認します。カテゴリの階層がどう作られているのか、誰が記事を読めるかの制御がどこにあるのかも、PDI（Personal Developer Instance）の実機で確認します。

この記事は、ServiceNow の Incident は触ったことがあり、前回の kb_knowledge 記事を読んだ人を想定しています。あるいは、ナレッジの「箱」と「分類」の構造をこれから理解したい管理者・開発者も対象です。

この記事で分かること

• kb_knowledge_base と kb_category がどんなフィールドを持つか（実測の固有数）

• 記事（kb_knowledge）が Knowledge Base / Category にどう紐づくか（実測の件数）

• カテゴリの階層が parent_id + parent_table でどう作られているか

• 公開が即時か承認かを決める kb_publish_flow / kb_retire_flow

• 「誰が読めるか」を制御する User Criteria と Knowledge Base の関係

• 実機で確認するときに見るべき一覧URL

ナレッジの「本棚」と「分類」とは

ナレッジ記事は、図書館の本に似ています。1冊の本（記事）は、必ずどこかの 本棚（Knowledge Base） に置かれ、本棚の中では 分類（Category） の棚で整理されます。ServiceNow でも同じです。記事（kb_knowledge）は Knowledge Base（kb_knowledge_base）に所属し、Category（kb_category）で分類されます。

Knowledge Base は、単なる入れ物ではありません。公開・廃止のワークフロー、閲覧できる人の条件（User Criteria）、記事作成時の必須項目やテンプレートなど、「この本棚の記事はこう扱う」というルールを束ねる管理単位です。一方 Category は、本棚の中で記事をグループ分けし、階層（フォルダの入れ子）で整理するためのものです。

この記事の主役は2つです。前回主役だった記事（kb_knowledge）の「上」にある、Knowledge Base と Category のテーブルに焦点を当てます。

Knowledge Management モジュールの概要・用語・機能一覧は、公式ドキュメントにまとまっています。

• 参考: Knowledge Management（Zurich）

Knowledge Base（kb_knowledge_base）の基本構造

ナレッジベースの情報は、kb_knowledge_base という1つのテーブルに格納されます。テーブルの定義（sys_db_object）から基本情報を抜き出すと、次のようになります。

• テーブル名（Name）：kb_knowledge_base

• ラベル（Label）：Knowledge Base

• 継承元（Extends）：なし（空）

前回の kb_knowledge と同じく、kb_knowledge_base もどのテーブルからも継承しない独立したテーブルでした。今回確認した PDI（Zurich / OOTB）では、kb_knowledge / kb_knowledge_base / kb_category の3つを確認しました。いずれも super_class が空でした。これらは task 系とは別系統になります。

実際にフィールド（項目）を数えると、kb_knowledge_base は固有の 36 フィールド を持っていました。継承元が無いため、この 36 がすべて kb_knowledge_base 自身の定義です。役割で大きく分けると、次の4グループになります。

• 識別・基本：title / owner / description / active

• 公開・廃止：kb_publish_flow / kb_retire_flow / workflow / retire_workflow

• 記事ルール：mandatory_fields / template / article_validity / checklist

• 表示・機能：card_color / icon / enable_socialqa など

主要なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり英語で記載します。

注目したいのは kb_publish_flow（Publish flow）と kb_retire_flow（Retire flow） という2つの Reference フィールドです。参照先は sys_hub_flow＝Flow Designer のフローです。前回「公開が即時か承認かは Knowledge Base 側で決まる」と述べました。その判断は、この2つのフィールドにどの Flow が設定されているかで決まっていました。加えて、旧式の Workflow を指す workflow / retire_workflow（参照先は wf_workflow）も併存しています。

全フィールドは、次のURLで一覧できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=kb_knowledge_base^elementISNOTEMPTY

PDIに入っていた4つのKnowledge Base

PDI（Zurich / OOTB）には、Knowledge Base が 4件（すべて active）登録されていました。一覧で見ると、それぞれ所有者と公開・廃止 Flow が異なります。

中身を整理すると次のとおりです。

公開が即時か承認かはKBごとに違う

4つの Knowledge Base のうち「IT」だけが Approval（承認付き）の公開・廃止フローを使っています。残り3つ（KCS / Known Error / Knowledge）は Instant（即時）です。同じ Publish 操作でも、記事がどの Knowledge Base に入っているかで、即時公開になるか承認必須になるかが変わります。これがフィールドレベルで確認できました。

実際に「IT」Knowledge Base のフォームを開くと、Publish flow に Knowledge - Approval Publish が設定されています。Retire flow には Knowledge - Approval Retire が設定されています。

このフォームには、記事の関連リスト（Knowledge 42件）も並んでいます。Can Read（閲覧許可）、Can Contribute（投稿許可）、Knowledge Categories（8件）も同じ画面にあります。Knowledge Base が、記事・カテゴリ・閲覧制御の起点になっていることが、この1画面から読み取れます。

公開・廃止フローの分岐を図にすると、次のようになります。

今回確認した PDI（Zurich / OOTB）では、Knowledge の公開・廃止は Flow Designer 側のフローとして用意されていました。Instant / Approval の Publish・Retire です。どれを使うかは Knowledge Base の kb_publish_flow / kb_retire_flow で指定されます。実環境では、Knowledge Base 側で Flow と旧 Workflow のどちらが有効かが異なる場合があります。両方を合わせて確認してください。

各 Knowledge Base の設定は、次のURLの一覧から確認できます。

https://<YourInstance>/kb_knowledge_base_list.do

Knowledge Base 作成時に設定する所有者・管理者・公開ワークフロー・User Criteria などは、公式ドキュメントで説明されています。

• 参考: Create a knowledge base（Zurich）

Category（kb_category）の階層はどう作られているか

Category の情報は、kb_category という1つのテーブルに格納されます。テーブル定義は次のとおりです。

• テーブル名（Name）：kb_category

• ラベル（Label）：Knowledge Category

• 継承元（Extends）：なし（空）

kb_category は固有の 14 フィールド と、kb_knowledge_base（36）に比べてかなり小ぶりです。注目すべきは、階層を作るための仕組みが Reference 1本ではない点です。

kb_category は、親を parent_id（親レコードの sys_id）と parent_table（親レコードのテーブル名）の組で持ちます。これは「多態（polymorphic）な親」と呼べる作りです。親が Knowledge Base（kb_knowledge_base）なら最上位カテゴリ、親が Category（kb_category）なら入れ子のサブカテゴリになります。同じ1つのテーブルで「KB直下」も「カテゴリの入れ子」も表現できるわけです。

実機のカテゴリ一覧を見ると、Parent ID 列に「Knowledge Base: ...」と「Knowledge Category: ...」が混在しているのが分かります。これが多態的な親の正体です。

カテゴリ親の内訳（最上位／入れ子）

PDI（Zurich / OOTB）には Category が 34件（すべて active）あり、親の内訳は次のとおりでした。

• 親が Knowledge Base（最上位カテゴリ）… 11件

• 親が Category（入れ子サブカテゴリ）… 23件

• 合計 11 + 23 = 34件

さらに、full_category（Full Category）というフィールドに、ルートからのフルパスが入っています。たとえば Email / Outlook / Outlook 2010 のように、3階層の入れ子も表現されていました。カテゴリのフォームを開くと、親（Email → Outlook）と full_category を確認できます。

カテゴリの一覧は、次のURLで確認できます（フルパス順）。

https://<YourInstance>/kb_category_list.do?sysparm_query=ORDERBYfull_category

カテゴリを Knowledge Base や別のカテゴリの下に作って階層化する手順は、公式ドキュメントに説明があります。

• 参考: Define a knowledge article category（Zurich）

記事はどう紐づくか（所属と分類）

記事（kb_knowledge）から見ると、Knowledge Base への所属と Category への分類は別のフィールドです。

• kb_knowledge_base（Reference → kb_knowledge_base）… 記事が所属する本棚

• kb_category（Reference → kb_category）… 記事の分類

KB・カテゴリと記事の紐づき件数

PDI の記事 56件 で実際に紐づきを数えると、次のようになりました。

• Knowledge Base が設定されている記事：56 / 56（すべての記事が必ずどれかのKBに所属）

• Category が設定されている記事：50 / 56（6件はカテゴリ未設定）

つまり、記事は必ず Knowledge Base に属する一方、Category は任意です。本棚は必須に近い運用だが、分類は付けても付けなくてもよい、という関係が読み取れます。Knowledge Base ごとの記事数は、KCS 8件・IT 42件・Known Error 3件・Knowledge 3件で、合計 56件と一致しました。

記事・KB・カテゴリ・公開Flow・閲覧制御の関係を1枚の図にします。

記事から所属KB・分類カテゴリへの参照は、次のURLで一覧できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^elementINkb_knowledge_base,kb_category

「誰が読めるか」はどこで決まるか（User Criteria）

ナレッジ特有の閲覧制御として、ロールや ACL に加えて User Criteria（ユーザー条件） があります。User Criteria は、ロール・部署・グループ・拠点・会社などの条件で「読める／投稿できる人」を絞る仕組みです。

この閲覧制御は Knowledge Base 単位で結びついています。PDI（Zurich / OOTB）で確認すると、Knowledge Base と User Criteria を多対多で結ぶテーブルにレコードがありました。

• kb_uc_can_read_mtom（Can Read の紐づけ）… 5件

• kb_uc_cannot_read_mtom（Cannot Read の紐づけ）… 1件

先ほどの IT Knowledge Base のフォームにも「Can Read」「Can Contribute」という関連リストがありました。カテゴリ単体ではなく、カテゴリが属する Knowledge Base 側の Can Read で、そのカテゴリの記事を読めるかが決まります。これは公式ドキュメントやコミュニティの説明とも整合します。誰が記事を読めるかを調べるときは、記事やカテゴリだけでなく、まず所属 Knowledge Base の User Criteria を見るのが近道です。

Knowledge Base の閲覧・投稿アクセスを User Criteria で制御する考え方は、公式ドキュメントで説明されています。

• 参考: Understanding access to the Knowledge knowledge base（Zurich）

kb_knowledge_base / kb_category の周辺機能

これらのテーブルの動きも、フィールド定義だけでは決まりません。保存時のサーバ処理、画面の制御、権限などが組み合わさります。今回確認した PDI（Zurich / OOTB・active 中心・2026-06-21 確認）の件数は次のとおりです。

kb_knowledge_base のほうが Business Rules（11）・Client Scripts（16）・UI Policies（7）・ACL などが多いです。ACLだけでもテーブルACL・フィールドACLを合わせると、kb_knowledge_base 側に34件（10+24）、kb_category 側に14件（5+9）ありました。閲覧・更新権限は、ここまで細かく制御されています。Knowledge Base が公開・権限・記事ルールの起点として多くの処理を抱えていることが分かります。kb_category は小ぶり（Business Rules 4 など）で、主に階層・分類の整理に徹している印象でした。「どこを見れば確認できるか」を押さえておけば十分です。

自分のインスタンスでは、次のURLで各一覧を開けます（先頭の <YourInstance> は置き換えてください）。

KB Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=kb_knowledge_base^active=true
KB Client Scripts : https://<YourInstance>/sys_script_client_list.do?sysparm_query=table=kb_knowledge_base^active=true
KB UI Policies    : https://<YourInstance>/sys_ui_policy_list.do?sysparm_query=table=kb_knowledge_base^active=true
KB ACL            : https://<YourInstance>/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHkb_knowledge_base
Cat Business Rules: https://<YourInstance>/sys_script_list.do?sysparm_query=collection=kb_category^active=true
Cat ACL           : https://<YourInstance>/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHkb_category

ServiceNowにおける Knowledge Base / Category のポイント

• Knowledge Base（kb_knowledge_base）も Category（kb_category）も task を継承しない独立テーブルで、固有フィールドはそれぞれ 36・14 でした。

• 公開が即時か承認かは、Knowledge Base の kb_publish_flow / kb_retire_flow（→ sys_hub_flow）で決まります。 今回の PDI では 4KB 中 IT だけが Approval、残り3つが Instant でした。承認を入れたいなら記事側ではなく Knowledge Base 側に設定します。

• Category の階層は parent_id + parent_table の多態的な親で作られます。親が Knowledge Base なら最上位（11件）、親が Category なら入れ子（23件）。full_category にフルパスが入ります。

• 記事は 必ず Knowledge Base に所属（56/56）し、Category は任意（50/56） という関係でした。

• 「誰が読めるか」は Knowledge Base 単位の User Criteria（Can Read / Cannot Read）で制御され、カテゴリの閲覧可否も所属KBに従います。

Knowledge Base と Category を調べるときは、記事単体ではなく次をセットで確認します。

• 所属KB → 公開Flow / User Criteria

• カテゴリ → parent_id / parent_table

これにより、画面上の操作と裏側のデータ構造がつながって理解できます。

実機を見て気づいたこと

• KBごとの直下カテゴリ数を見ると、KCS 3・IT 8・Known Error 0・Knowledge 0でした。ITやKCSのようによく使われるKnowledge Baseほどカテゴリで整理されており、Known ErrorとKnowledgeはカテゴリを作らずフラットに記事を並べる運用になっているようです。同じテーブル構造でも、KBごとに整理の作り込み具合がかなり違うことが件数から見えました。

• kb_knowledge_base にも kb_category にも、Notifications（sysevent_email_action）は0件でした。記事を公開・更新してもOOTBでは誰にもメール通知が飛ばない作りだと分かります。更新をチームに知らせたい場合は、自分でBusiness RuleやFlowを組む必要がありそうです。

次に読むなら

次に確認するなら、次のテーマです。

• kb_publish_flow / kb_retire_flow が指す Flow Designer のフロー（Instant / Approval Publish の中身）

• User Criteria（user_criteria）テーブルそのものの構造

特に「承認の有無は Knowledge Base 側で決まる」という仕組みの中身、そして User Criteria の評価順は、ナレッジ運用を設計するうえで役立ちます。これらは別記事で取り上げる予定です。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• Knowledge Base：記事を束ねる管理単位（本棚）。公開Flow・閲覧制御・記事ルールの起点

• Category：Knowledge Base 内で記事を分類・階層化する単位（フォルダ）

• User Criteria：ロール・部署・グループ等で閲覧／投稿対象を絞る条件

• polymorphic parent：parent_id + parent_table の組で、異なるテーブルのレコードを親に取れる作り

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

KBテーブル定義     : sys_db_object_list.do?sysparm_query=name=kb_knowledge_base
Catテーブル定義    : sys_db_object_list.do?sysparm_query=name=kb_category
KBフィールド一覧   : sys_dictionary_list.do?sysparm_query=name=kb_knowledge_base^elementISNOTEMPTY
Catフィールド一覧  : sys_dictionary_list.do?sysparm_query=name=kb_category^elementISNOTEMPTY
Knowledge Base 一覧: kb_knowledge_base_list.do
Category 一覧      : kb_category_list.do?sysparm_query=ORDERBYfull_category

関連記事

• ServiceNow ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか — 本棚（Knowledge Base）とカテゴリが、記事の置き場所・承認・閲覧制御全体のどこに位置するかを地図として確認できます。

検証範囲とおことわり

• 確認した範囲：kb_knowledge_base / kb_category の継承（＝なし）、固有フィールド数（36 / 14）と主要な型

• レコード件数（KB 4 / Category 34 / 記事 56）、KBごとの記事数・公開Flow・直下カテゴリ数

• カテゴリ親の多態内訳（最上位 11・入れ子 23）、記事の KB/カテゴリ紐づき（56/56・50/56）

• 周辺設定件数、User Criteria 多対多の件数。すべて PDI（Zurich / 2026-06-21 確認）の OOTB・active 中心で取得しています

• 確認していない範囲（断定しません）：各 Flow（Instant / Approval Publish・Retire）の内部ステップ、User Criteria の評価順

• Service Portal での表示（card_color / icon 等）の描画、検索（Zing / AI Search）の内部

• kb_quality_checklist / data_policy の詳細挙動

• 環境によっては Knowledge Base 側で Flow / 旧 Workflow のどちらが有効かが異なる場合があり、その差分も確認対象になります