ナレッジ管理モジュールの概要
同じ質問に何度も答えていませんか。ServiceNowのナレッジ管理は、一度解決した内容を記事として残し、次に同じ問題が起きたときに検索で見つけられるようにする仕組みです。IncidentやProblemとは別の独立したテーブルで動き、Problemの恒久対策（Known Error）ともつながります。Australia の PDI をデフォルト設定のまま開き、テーブル・状態・ロール・公開の流れを確かめました。
検証環境：Australia PDI / OOTB / 2026-09-01 確認
この記事で分かること
ナレッジ管理が Incident・Problem とどう役割を分け、Known Error Article でどうつながるか
kb_knowledge_base（本棚）→ kb_category（分類）→ kb_knowledge（記事・5つの記事型）という3層の構成
記事が Draft から Published を経て Retired に至るまでの流れと、承認の分岐
ポータル・関連検索・ワークスペースなど、記事にたどり着く複数の経路
誰が記事を読めるかを決める User Criteria の全体像
先に押さえておくこと
ナレッジ管理は、一度解決した内容を検索で再利用できる形に変えるための仕組みである
kb_knowledge は task を継承しない独立ベーステーブルで、自身が5つの記事型サブクラスの親になっている
デフォルトで ACL 565件・ビジネスルール47件・Flow Designer フロー9件が kb_knowledge 周りで動いている
ナレッジ管理の位置づけ
障害を1件解決しても、同じ質問が翌週また来ることがあります。欲しいのは、対応した内容を検索1つで再利用できる場所です。ServiceNowではこの役割をナレッジ管理が担います。
Incident は止まった業務を早く戻すための記録です。Problem は繰り返す障害の恒久対策を調べるための記録です。ナレッジ管理はこの2つと目的が異なります。誰かが一度調べた答えを、次に同じ問題に当たった担当者が自分で検索して使えるようにすることが役目です。
Problem が繰り返す障害の原因と回避策を突き止めると、その内容は Known Error Article としてナレッジ側に記録されます。Known Error Article は Problem 管理の一部ではなく、ナレッジ管理が用意する5つの記事型の1つです。障害対応で得た知見が検索で見つかる資産に変わる接続点が、ここにあります。
参考：ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Known Error に至るまでのProblem側の流れ
kb_knowledge テーブルの継承構造
Incident や Problem は task テーブルを継承する兄弟同士でした。ナレッジ管理はこの構造に乗りません。
sys_db_object で kb_knowledge を確認すると、Extends table 欄が空欄でした。
super_class が空欄ということは、SLA・エスカレーション・割り当てルールといった task 系の仕組みに、そもそも構造として乗らないことを意味します。ナレッジ記事に期限を切って督促する、という発想自体がテーブル構造の外側にあります。
参考：taskテーブル：ITSM全プロセスの共通の親 … IncidentやProblemが継承する側のテーブル
逆に kb_knowledge は自分自身が親になっています。5つの記事型テーブルが kb_knowledge を継承していました。
新規作成時にどの型を選ぶかで、初期のフィールド構成が変わります。5つの型を1つずつ確認します。
FAQ
質問と回答をワンセットで記録する型です。単発の問い合わせ対応を、そのまま記事に変換するときに向いています。
追加項目は kb_question（質問）・kb_answer（回答）の2つで、いずれもHTML型です。本文（text）とは別にこの2項目が並び、質問と回答を分けて入力する画面になります。
デモデータでの記事数は0件です。IT・KCS Knowledge Base のどちらにも、この型で書かれた記事は見当たりません。
How To
手順を示す型です。操作ガイドや設定手順の記事に使います。
追加項目は kb_introduction（導入文）・kb_instructions（手順本体）の2つです。「導入 → 手順」という2段構成を、テーブル構造の側から用意しています。
デモデータでは6件がこの型で作られており、5つの型の中で最も使われています。Known Error Articleの3件を上回る数です。
KCS Article
KCS（Knowledge-Centered Service）の解決記録として使う型です。サポート現場で「症状 → 原因 → 解決」を記録する運用に対応します。
追加項目は4つ、kb_issue（症状）・kb_environment（環境）・kb_cause（原因）・kb_resolution（解決策）です。KCSの記録手順がテーブル構造にそのまま反映されています。
デモデータでは0件でした。KCS Knowledge Base自体には記事が8件ありますが、いずれもこのKCS Article型では書かれていません。
Known Error Article
Problem管理の恒久対策を記録する型です。Problem側の primary_known_error_article フィールドが参照する先で、Problem⇔Knowledge連携の接続点になります。
追加項目は3つ、kb_cause（原因）・kb_description（説明）・kb_workaround（回避策）です。Problem管理が持つ cause_notes（原因）・workaround（回避策）と役割が対応しています。Problem 管理から作られる記事は、この3項目に直接書き込まれます。
デモデータは3件で、いずれもKnown Error Knowledge Base（記事3件）に属します。フィールドと参照構造の詳細は、本シリーズ第2巻「テーブル・フィールド構成」で扱います。
What Is
用語や概念を説明する型です。「〜とは」の記事に対応します。
追加項目は kb_introduction（導入文）・kb_explanation（説明本文）の2つです。導入文の項目名は How To と共通ですが、本体側は kb_instructions ではなく kb_explanation になります。手順を書く型と説明を書く型で、導入のあとに続く項目名を変えている設計です。
デモデータは2件です。
公式のフィールド説明（sys_documentation）
ServiceNow は製品の中にフィールドの説明文を同梱しています。sys_documentation の hint です。kb_knowledge には31件の説明がありました。
公開範囲を左右する説明を引用します。
Roles allowed to view or search for article - if empty, all users can see
（訳: 記事の閲覧・検索を許可するロール。空の場合は全ユーザーが閲覧できる）
roles フィールドの説明です。空欄が「誰も見られない」ではなく「誰でも見られる」を意味するという定義を公式が明示しています。制限をかけるつもりで roles を空にしたままにすると、意図と逆の公開状態になります。
もう1つ、公開状態そのものの説明です。
Knowledge base workflow state
（訳: ナレッジベースのワークフロー状態）
workflow_state の説明です。task 系の state とは異なり、workflow という専用の型で管理されています。
引用元: /sys_documentation_list.do?sysparm_query=name=kb_knowledge^hintISNOTEMPTY
フィールド構成
sys_dictionary で数えると、kb_knowledge 固有のフィールドは60件でした。
必須（mandatory）は2項目だけです。short_description（記事のタイトル）と kb_knowledge_base（所属先）です。この2つを埋めれば記事は保存できます。
60件のうち9件は sys_created_by や sys_domain といった監査系フィールドでした。Incident や Problem では task 側が吸収するため、モジュール固有の辞書には現れません。kb_knowledge は継承元を持たないため、このテーブル自身の辞書に9件が直接並びます。task を継承しない構造が、フィールド一覧にもそのまま表れています。
運用で意味を持つ固有フィールドを挙げます。
kb_knowledge_base：所属先。ワークフローと閲覧条件の土台を決める
workflow_state：公開状態。draft/review/scheduled_publish/published/pending_retirement/retired/outdated の7値
can_read_user_criteria / cannot_read_user_criteria：記事単位で閲覧条件を上書きする2項目
version：kb_version テーブルへの参照。改訂のたびに版が積み上がる
base_version：コピー元の記事への自己参照。version とは指す対象が違う
valid_to：有効期限。この日付を過ぎると検索結果にも一覧にも出ない
60項目の全一覧と画面設計は、本シリーズ第2巻「ナレッジ管理モジュールのテーブル・フィールド構成」で扱います。
ワークフロー状態（workflow_state）
sys_choice で workflow_state の選択肢を確認すると7件でした。すべて有効です。
デモデータの内訳を見ると、53件の記事のうち使われている値は draft（4件）・outdated（7件）・published（42件）の3値だけでした。
review・scheduled_publish・pending_retirement・retired は0件です。承認待ちや退役予定のレコードが実機に存在しないのは、デモデータが完成品の状態で投入されているためです。承認フローの動きを確認するには、記事を実際に1件作成してPublishを押すところまで動かす必要があります。この操作は本シリーズ第9巻「ナレッジ管理モジュールの運用手順書」で扱います。
ナレッジを構成する体系
記事は kb_knowledge_base（本棚）・kb_category（分類）・kb_knowledge（記事）という3層の中に置かれ、層ごとに決まることが違います。
一番上の kb_knowledge_base が、承認方式（kb_publish_flow）とKB単位の可視性（kb_uc_can_read_mtom）を決めます。実機には5件登録されていました。
ナレッジベースOwner記事数ITBernard Laboy42KCS Knowledge Base (demo data)Arya Stark (KCS role)8Known ErrorProblem Manager3Governance, Risk, and ComplianceSystem Administrator0KnowledgeSystem Administrator0
記事が実際に入っているのは3件だけでした。残り2件は記事0件の空箱です。kb_managers（管理グループ）はどのナレッジベースも未設定で、管理権限は個人の owner フィールドだけに委ねられています。
真ん中の kb_category は、記事を探すための分類だけを持つ層です。parent_id と parent_table という2項目で親を指す作りで、KB直下のトップレベル18件とカテゴリ配下のネスト23件を同じ1つのテーブルで表現します（合計41件）。可視性を持つのはKBと記事だけで、kb_category は分類専用です。
一番下の kb_knowledge（53件）が本文と5つの記事型を持つ実体です。
参考：ナレッジの本棚と分類（kb_knowledge_base） … 本棚と分類の階層をさらに詳しく扱う
参考：記事の評価はどこに溜まるか（kb_feedback） … 評価・フィードバックの置き場
ナレッジベースの作成手順とカテゴリ設計は本シリーズ第5巻「ナレッジ管理モジュールの基本設定」、可視性の判定順序は本シリーズ第3巻「ナレッジ管理モジュールのロール」で扱います。
ナレッジが使われる経路
記事にたどり着く経路は複数あります。実機の設定を確認すると、少なくとも4つの入口がありました。
1つめはポータル閲覧です。専用の Knowledge Portal（/kb）と既定ポータルの Employee Center（/esc）の両方に記事ページがあります。kb関連の sp_page は13件、部品（Widget）は54件でした。
参考：既定ポータル Employee Center（/esc）はカタログを持たない：導線はタクソノミーが作る … ポータル側の構成を詳しく扱う
2つめはフォーム入力中の関連検索です。cxs_table_config には incident・problem など14件が有効（related_search_active=true）でした。似た記事を横に出す「Incident Deflection」という設定も確認できます。
参考：Contextual Search：入力中に「似た答え」を出して重複起票を防ぐ … 入力中に記事を提示する仕組みを詳しく扱う
3つめはバーチャルエージェントやカタログからの検索、4つめはエージェントワークスペースのナレッジパネルです。
読んだ記事をタスクに紐づける記録（m2m_kb_task・task_rel_kb）や閲覧記録（kb_use）も用意されています。稼働の実態は「実機で気づいたこと」で扱う内容です。検索の中身は既存記事群「検索の仕組み（AI Search）」、インシデントから記事を新規作成する経路は本シリーズ第8巻「ナレッジ管理モジュールの連携機能」に委ねます。
kb_knowledge に紐づく OOTB 設定
ナレッジ管理は、1つのテーブルとその周りで動く設定の集まりで構成されます。kb_knowledge / kb_knowledge_base に紐づく設定を数えました。
Incidentの同種の集計（ACL 151件・ビジネスルール38件）と比べると、ACLが565件と際立って多くなっています。kb_ / knowledge を名前に含むACLを合算・重複除去した数です。
この差の理由はACL側の条件式とスクリプト（advanced ACL）の使い方にあります。ACL全体の32%にあたる183件がスクリプトで判定条件を書いていました。Incidentでは9%です。ロールを見るだけでは誰が何をできるか分からない設計になっています。詳しい内訳は本シリーズ第3巻「ナレッジ管理モジュールのロール」で扱います。
ビジネスルール
保存ボタンを1回押すと、サーバ側で複数の処理が順に実行されます。この置き場がビジネスルール（sys_script）です。kb_knowledge には47件、kb_knowledge_base には13件ありました。
中心はバージョニングと状態遷移の確定処理です。状態がどう移り変わるかは、次の「記事が作成されてから廃棄されるまでの流れ」で扱います。1つだけ先に挙げると「Update Stage State」というルールがあります。対象KBが Flow Designer 方式なら、判定した直後に処理を終える設計です。旧 Workflow Editor 方式向けに残る後方互換ロジックだとコード上に明記されていました。
各ルールの条件とスクリプトの中身は、本シリーズ第6巻「ナレッジ管理モジュールの自動設定構成」で扱います。
記事が作成されてから廃棄されるまでの流れ
記事は Draft（作成）から Published（公開）を経て、最終的に Retired（廃棄）へ進みます。承認を挟むかどうかは記事側でなく、所属KBの kb_publish_flow / kb_retire_flow が決めます。
新規保存した記事はまず Draft になります。KB Version3方式では、workflow_state を強制的に draft へ戻すビジネスルールがあります。
実機でナレッジ向けに有効なフローは9件、すべて active かつ published でした。
承認ありの Knowledge - Approval Publish を使うのは、5件のうち IT だけでした。承認者は KB の owner か、記事ごとの ownership_group（sys_user_group参照）から決まる設計です。残り4件は Knowledge - Instant Publish で、承認なしにそのまま Published へ進みます。
Published になった記事の可視範囲は、KB単位の User Criteria と記事単位の can_read_user_criteria が決めます。改訂は Checkout で新しい Draft を複製し、再び Publish すると古い版は Knowledge - Outdate Article フローで Outdated（旧版）へ移ります。
廃棄も Publish と同じ構造で分岐します。IT は Knowledge - Approval Retire、残り4件は Knowledge - Instant Retire です。
旧方式の Workflow Editor（wf_workflow）側の定義は0件でした。詳しい経緯は次の「実機で気づいたこと」で扱います。
Draftから1件をPublish・Retireまで動かす手順は本シリーズ第9巻「ナレッジ管理モジュールの運用手順書」で扱います。フロー自体とKB設定の変更手順は本シリーズ第5巻「ナレッジ管理モジュールの基本設定」で扱います。
通知
記事の公開・却下・期限切れといった変化に反応するメール通知は sysevent_email_action に4件ありました。
内訳は次の4件です。
KM: Article approved for publish（公開承認時）
KM: Article Expiry Warning（有効期限が近づいたとき）
KM: Article rejected for publish（公開却下時）
Knowledge article email（記事の共有）
いずれも event_name が kb.* または knowledge.* 系で、送信条件（condition）は空欄でした。宛先の絞り込みはイベントを発行する側、つまり承認フロー側に委ねられています。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届くまでの経路を順に追う
UI アクション（ボタン）
フォーム上の Publish や Retire といったボタンは sys_ui_action にレコードとして定義されています。有効なものは24件でした。
Publish 系だけで3系統に分かれます。Workspace 版・Workspace Classic 版・従来の Classic/Legacy 版です。Retire も後継記事の有無で3系統に分かれます。いずれのボタンも直接ロジックを持たず、KnowledgeUIAction・KBKnowledge・KBCommon という共通の Script Include が持つ判定メソッドを呼び出す構成でした。ボタンの表示条件を直したいときは、UI Action本体ではなく Script Include 側を確認します。
Search for Duplicates というボタンもあります。workflow_state が draft か review のときだけ表示され、knowledge か itil のロールを持ち、かつ機械学習による重複検知が無効なときに動く設計でした。標準の重複検知機能が入っていない環境向けの、手動チェックの入口です。
システムプロパティ
コードを書き換えずに挙動を変えられる設定値はシステムプロパティに集まっています。ナレッジ関連は15件でした（"acknowledge"との偶発一致1件を除いた数です）。
運用に直結する例を1つ挙げます。problem.knowledgebase.known_error_article という項目には、Known Error 用のナレッジベースの sys_id が入っています。実機ではこの値が、記事3件が入っている「Known Error」ナレッジベースの sys_id と完全に一致しました。Problem 管理から Known Error 記事を作る先が、このプロパティ1つで一元管理されている構造です。
もう1つ、glide.sp.honour.kb.search.order という項目があります。検索結果の並び順を、閲覧回数（sys_view_count）ベースにするかどうかを切り替える設定でした。
命名規則は kb_knowledge系・kb.系・taxonomy.knowledge.系・problem.knowledgebase.系の4系統に分かれています。nameLIKEknowledge で検索するだけでは Problem 側のプロパティを取りこぼします。
参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方
各プロパティの既定値と変更の勘所は、本シリーズ第4巻「ナレッジ管理モジュールのプロパティ」で扱います。
ロールと権限
kb_ プレフィクスのロールは存在せず、knowledge 系が8件でした。
itil ロールは knowledge 系ロールを一切自動継承しません。Incident 管理の itil が sn_problem_write を自動継承するのとは対照的です。ナレッジ記事の執筆・管理権限は、knowledge 系ロールを個別に付与しないと得られません。
ACL側で見ると、kb_knowledge 本体の作成・更新・削除に必要なのは snc_internal（内部ユーザー全員）で、読み取りは public（未ログインでも可）でした。knowledge 系ロールはACL上、レポート閲覧の権限としてしか直接紐付いていません。ロールの表だけを見ると誰でも書けるように見えますが、実際の可否は次の節で扱う User Criteria とスクリプトACLが最終判定しています。
参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … 権限が効かないときはここを見る
各ロールの守備範囲とACLの内訳は、本シリーズ第3巻「ナレッジ管理モジュールのロール」で扱います。
誰が読めるか（User Criteria の概観）
ナレッジベース単位の可視性は User Criteria という条件レコードで管理します。実機で kb_uc_can_read_mtom（誰が読めるか）を確認すると5件でした。
Knowledge ナレッジベースには「Any user for KB」が1件紐づいていました。ITには3件（Problem AnalyzersとProblem Solvingのメンバー・ACME North America全社員・ACME Corporation全社員）が紐づいています。Known Errorには専用のUser Criteriaが1件ありました。いずれか1つでも条件を満たせば読める仕組みです。
これはナレッジベース単位の制御です。記事1件ごとに上書きできる項目も別に用意されています。kb_knowledge が持つ can_read_user_criteria / cannot_read_user_criteria という2項目です。ナレッジベースは読めるはずなのに特定の記事だけ見えない、という調査はこの2項目から始めます。二重構造の詳しい判定順序とACLとの関係は、本シリーズ第3巻「ナレッジ管理モジュールのロール」で扱います。
kb_knowledge を参照しているテーブル
sys_dictionary で kb_knowledge を参照するフィールドを検索すると92件が該当します。
内訳を見ると、65件は Flow Designer の内部変数テーブルでした。var__m_sys_hub_flow_input_ のような自動生成テーブルです。フローの入力欄が Knowledge 型であるために生成されます。
実質的に kb_knowledge を参照するテーブルは25件でした。Incidentが2件だったのと比べると際立って多い数です。代表的な連携先を挙げます。
Service Portal（sp_instance_link）
Interaction（interaction_related_record）
Virtual AgentやCSMの共有ドキュメント（sn_irm_shared_cmn_document_version）
Now Assist（sys_pd_process_definition.now_assist_kb）
AI Searchの自動応答（sys_cs_auto_resolution_ai_search_result_line_item）
ほぼ全モジュールの土台になっていることが実測から分かります。
参考：Knowledge Portal（/kb）の「45 Articles」はどこから来るか … ポータル画面での記事数表示
ナレッジ記事が製品全体でどう連携するかは、本シリーズ第8巻「ナレッジ管理モジュールの連携機能」で扱います。
実機で気づいたこと
IT以外4件のナレッジベースが、存在しない旧ワークフローを指している
ナレッジベース5件のうち、IT・KCS Knowledge Base・Knowledge・Known Errorの4件を確認しました。この4件は旧方式のworkflow / retire_workflowフィールドに値を持っています。この値は wf_workflow テーブルを指す sys_id です。ところがその sys_id で wf_workflow を検索すると、該当レコードは1件も見つかりません。
原因は移行の順序にあると考えられます。公開・退役の仕組みは Flow Designer（sys_hub_flow）へ完全に移行済みで、旧 Workflow Editor 側のレコード自体はすでに削除されています。参照する側のフィールドだけが値を残し、参照先を失った状態です。データポリシー側でも、旧 Workflow を必須化する設定はすでに無効化されていました。
実務では、この2つのフィールドをスクリプトや連携で読みに行かないことがポイントです。空でも壊れていても実害はありませんが、workflow フィールドの値が入っていることをもって「旧方式で運用中」と判断すると誤ります。公開・退役の実態を確認するときは、kb_publish_flow / kb_retire_flow の2項目だけを見ます。
workflow_state は7値あるのに、実機では3値しか動いていない
draft・outdated・published の3値で53件全部が埋まっていました。review・scheduled_publish・pending_retirement・retired は0件です。
デモデータが「執筆完了・公開済み・退役済み予定なし」という完成品の状態で投入されているためだと考えられます。承認待ちや退役予定のレコードは、業務が動いている環境でこそ生まれる一時的な状態です。
自社の運用でこの7値がどう分布するかは、実機データだけでは判断できません。テスト記事を1件作り、Reviewから Publishedまで実際に動かして確認します。この操作は本シリーズ第9巻「ナレッジ管理モジュールの運用手順書」で扱います。
参照テーブルの実数は92件のうち25件だけ
sys_dictionaryで reference=kb_knowledge を検索すると92件がヒットします。この数をそのまま「92のテーブルと連携している」と読むと誤ります。
65件はvar__m_で始まるFlow Designerの内部変数テーブルで、フローの入力欄がKnowledge型であるために自動生成されたものでした。実際に連携先として意味を持つテーブルは25件です。
影響範囲を調べるときは、var__m_で始まるテーブルを除外してから数えます。この命名規則さえ知っていれば、確認作業は一度のクエリで済みます。
記事を使った証跡を残す仕組みは、実機ではまだ空だった
m2m_kb_task・task_rel_kb（この記事で解決したという記録）と kb_use（閲覧ログ）は、いずれも0件でした。kb_feedback だけは19件です。
テーブルとフィールドは製品側に用意済みです。稼働しない理由は、記事を使った側が明示的に記録する操作をして初めてデータが増える仕組みだからだと考えられます。効果測定では、この3テーブルへの蓄積の有無を最初に確認します。
実務で順番に検討する箇所
ナレッジ管理を新しく設計するとき、確認する順序を決めておくと迷いません。
ナレッジベースの区分：承認が要る記事と要らない記事を分け、kb_publish_flow を使い分ける
記事型の選定：障害対応チームは Known Error article、手順書は How To のように、書き手に合わせて標準の型を決める
可視性の設計：kb_uc_can_read_mtom でナレッジベース単位の閲覧範囲を決め、個別記事の上書きは例外運用にとどめる
ロールの付与：itil を持つ担当者にも knowledge 系ロールを個別に付与する
プロパティの確認：problem.knowledgebase.known_error_article のような連携用プロパティが、自社のKnown Error用ナレッジベースを指しているか確認する
AI Searchとの接続：公開しただけでは検索に出ない。索引への取り込みタイミングを別途確認する
利用実績の可視化：m2m_kb_task・kb_use への蓄積を確認し、効果測定に使えるか判断する
参考：ServiceNowのAI Searchで検索ソースとインデックスの数が合わないのはなぜ？ … 公開後の検索側の仕組み
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
KCS：Knowledge-Centered Service。サポート業務の中でナレッジを作成・改善し続ける手法
AQI：Article Quality Index。記事の品質を採点する仕組み
ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則
検証範囲とおことわり
検証環境：Australia PDI（OOTB）/ 2026-09-01 確認
件数はすべてOOTBの設定・定義の数です。本番環境やカスタマイズ済み環境では異なります
各ビジネスルール・UIアクションの処理内容は代表的なものだけを確認しました
ACL 565件の内訳、User Criteriaの詳しい判定ロジックは、このシリーズの後続記事で扱います
業務レコードの分布（どのナレッジベースに何件あるか）はデモデータ固有のため、判断の主軸にしていません
AI Searchとの接続は既存記事群に委譲し、本記事では扱っていません
利用経路の実測は sp_page / cxs_table_config 等の設定定義によるもので、アクセスログの計測ではありません
Approval Publishの承認者判定（owner / ownership_group）はフロー内部までは追っていません
付録：自分の環境で確認するときのURL
テーブル定義：/sys_db_object_list.do?sysparm_query=name=kb_knowledge
5つの記事型：/sys_db_object_list.do?sysparm_query=super_class.name=kb_knowledge
フィールド定義：/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^elementISNOTEMPTY
ワークフロー状態の選択肢：/sys_choice_list.do?sysparm_query=name=kb_knowledge^element=workflow_state^ORDERBYsequence
ナレッジベース一覧：/kb_knowledge_base_list.do
ビジネスルール：/sys_script_list.do?sysparm_query=collection=kb_knowledge
公開・退役フロー：/sys_hub_flow_list.do?sysparm_query=nameLIKEknowledge
通知：/sysevent_email_action_list.do?sysparm_query=collection=kb_knowledge
UIアクション：/sys_ui_action_list.do?sysparm_query=table=kb_knowledge
システムプロパティ：/sys_properties_list.do?sysparm_query=nameLIKEknowledge^ORnameLIKEkb.
ロール：/sys_user_role_list.do?sysparm_query=nameLIKEknowledge
誰が読めるか：/kb_uc_can_read_mtom_list.do
参照しているテーブル：/sys_dictionary_list.do?sysparm_query=reference=kb_knowledge^elementISNOTEMPTY
カテゴリの階層：/kb_category_list.do?sysparm_query=parent_table=kb_knowledge_base
関連検索の対象テーブル：/cxs_table_config_list.do?sysparm_query=related_search_active=true
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=kb_knowledge^hintISNOTEMPTY
関連記事
Knowledge だけ task 系でない（kb_knowledge） … フィールド単位の詳しい構成
taskテーブル：ITSM全プロセスの共通の親 … Incident・Problemが継承する側のテーブル
ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Known Errorを作る側の流れ
