ナレッジ管理モジュールのテーブル・フィールド構成

ナレッジ記事のフォームに並ぶ項目は、どこで定義されているのでしょうか。Incident や Problem は task テーブルを継承するため、項目の定義が2つのテーブルに分かれます。kb_knowledge はこの構造を持ちません。task を継承せず、記事に必要な項目を自分自身で持つ独立したテーブルです。ただし記事の型（FAQ・How To・Known Errorなど）によって持てる項目が変わる、もう1段の構造があります。Australia の PDI をデフォルト設定のまま開き、60項目の内訳・型・既定値・必須の決まり方と、記事型ごとの違いを確かめました。

確認する項目

• kb_knowledge の項目が、task 系とどう違う構造で定義されているか

• 60項目がどの型で構成されているか

• 既定値が入っている項目と、その決まり方

• 必須項目を実際に決めている仕組み

• 5つの記事型サブクラスが、どんな追加項目を持つか

この記事の要点

• kb_knowledge は task を継承せず、逆に5つの記事型サブクラスの親になっている

• 既定値は60項目中20項目に入っており、うち5項目はJavaScript式で決まる

• 必須はUIポリシーではなく、辞書（sys_dictionary）の mandatory 自体で2項目が決まっている

kb_knowledgeはどんな構造を持つテーブルか

Incident（incident）・Problem（problem）・Change（change_request）は、どれも task を継承する「task 系」です。kb_knowledge はこの系譜に入りません。

kb_knowledge の Extends table 欄は空欄です。task を継承しないだけでなく、他のどのテーブルも継承しない独立ベーステーブルとして定義されています。その代わりに、kb_knowledge 自身が5つの記事型のスーパークラスになっています。

• kb_template_faq（FAQ）

• kb_template_how_to（How To）

• kb_template_kcs_article（KCS Article）

• kb_template_known_error_article（Known Error article）

• kb_template_what_is（What Is）

Incident や Problem の継承がテーブルの縦の関係（task から機能を受け継ぐ）だとすると、kb_knowledge の継承は逆方向です。基本の記事テーブルがまずあり、記事の型ごとに追加項目を持つサブクラスがぶら下がる構造になっています。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … kb_knowledgeが加わらない側の系譜

フィールドの総数と内訳

sys_dictionary で kb_knowledge を絞り込むと、固有フィールドは60件でした。

継承元を持たないため、この60件がすべて kb_knowledge 自身の定義です。役割で分けると次のようになります。

本文・基本（16項目）

• number / short_description / text / wiki：記事番号・タイトル・本文（HTML）・本文（Wiki形式）

• article_type / editor_type：本文の種別と編集エディタの種類

• display_number / article_id：表示用番号・元記事の識別子

• meta / meta_description：検索用の補助テキスト

• category / topic / taxonomy_topic：分類・トピック・タクソノミー

• image：記事一覧に表示する画像

• generated_with_now_assist：Now Assist（生成AI機能）で作られた記事かの記録

分類・所属（3項目）

• kb_knowledge_base：所属する Knowledge Base

• kb_category：Knowledge Base 配下の分類

• ownership_group：所有グループ

公開管理（13項目）

• workflow_state：公開ステータス

• author / revised_by：作成者・改訂者

• published / retired / valid_to / scheduled_publish_date：公開日・廃止日・有効期限・公開予約日時

• version / base_version / latest：バージョン参照・元バージョン・最新版フラグ

• replacement_article：廃止後の差し替え先記事

• latest_aqi / summary：最新の品質評価・要約

評価・利用（5項目）

• sys_view_count / use_count / helpful_count / rating / flagged

閲覧制御（4項目）

• roles / can_read_user_criteria / cannot_read_user_criteria / view_as_allowed

表示・操作制御（5項目）

• active / direct / disable_commenting / disable_suggesting / display_attachments

連携（5項目）

• cmdb_ci：関連する構成アイテム

• source：記事の起点になった task（Incident の解決記録などから作った場合）

• instrumentation_metadata / sn_grc_source / sn_grc_target_table：計測用メタデータとGRC連携用の項目

監査・ドメイン分離（9項目）

sys_class_name / sys_created_by / sys_created_on / sys_updated_by / sys_updated_on / sys_mod_count / sys_id / sys_domain / sys_domain_path

これらは他のテーブルなら継承元（task など）が吸収する監査系フィールドです。kb_knowledge は継承元を持たないため、9項目がこのテーブル自身の辞書として直接定義されています。task を継承する Incident・Problem の辞書には、このような監査系フィールドは現れません。

• 参考：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … 辞書テーブルの読み方

型の分布

60項目を型で分けると、Reference が最多の13項目でした。

Incident は Integer 型が17項目と多く、これは state・priority のような選択肢を数値で保存しているためでした。kb_knowledge は傾向が異なります。Integer は4項目にとどまり、代わりに Boolean が9項目と目立ちます。active / flagged / direct / disable_commenting / disable_suggesting / display_attachments / latest / view_as_allowed / generated_with_now_assist は、いずれも記事1件ごとのオン・オフを切り替える設定です。

この違いは、テーブルの性格を表しています。Incident は状態遷移を数値の段階（New→In Progress→Resolved）で管理します。kb_knowledge は記事1件ごとの表示・操作の可否を、個別のスイッチで管理する設計です。承認や進行の管理は workflow_state（Workflow型、1項目）に集約され、それ以外の制御は多数の Boolean が分担しています。

String も12項目あります。short_description（タイトル）や category / topic（分類の補助的な文字列）が含まれ、選択肢のように見える article_type も文字列で保存されています。

• 参考：選択肢Choice（sys_choice）：ドロップダウンの中身 … ラベルと値の対応が置かれる場所

参照フィールドのつながり先

Reference 型の13項目が、どのテーブルを指しているかを確認します。

Reference 型13項目の参照先を整理すると、次のとおりです。

• author / revised_by → sys_user

• kb_knowledge_base → kb_knowledge_base

• kb_category → kb_category

• cmdb_ci → cmdb_ci

• source → task

• version / base_version / replacement_article → kb_knowledge・kb_version

• ownership_group → sys_user_group

• latest_aqi → kb_article_checklist_summary

• summary → kb_knowledge_summary

• taxonomy_topic → topic

source（Source task）が task への参照を持つ点に注意してください。これは「記事の起点になったタスク」を指す1項目にすぎず、kb_knowledge が task を継承していることを意味しません。継承（super_class）は空欄のままです。参照と継承は別の仕組みという点は、テーブル設計を読むときの基本になります。

replacement_article は kb_knowledge 自身への自己参照です。記事を廃止するとき、差し替え先の記事をこの項目で示します。古い記事にたどり着いた場合でも、差し替え先へ誘導できる仕組みです。

• 参考：参照フィールドと参照修飾子：候補はどう絞られるか … 参照先の候補が絞られる場所

• 参考：ナレッジの本棚と分類（kb_knowledge_base） … kb_knowledge_base・kb_category の詳しい構造

既定値が設定されているフィールド

60項目のうち、既定値が設定されているのは20項目でした。

固定値の既定は15項目で、active / latest / view_as_allowed は true、direct / disable_commenting / disable_suggesting / display_attachments は false という組み合わせです。記事は作成した時点で「有効・最新版・他ユーザーとして閲覧可」を初期状態に持ち、コメントや添付表示は無効から始まります。workflow_state の既定は draft で、新規記事は必ず下書きから始まる設計です。

残り5項目はJavaScript式です。

• number = 採番関数

• author = ログインユーザーを取得する関数

• kb_knowledge_base = 既定のKBを取得する関数

• sys_class_name = 現在のテーブル名を取得する関数

• valid_to = 所属KBの設定から有効期限を計算する関数

valid_to の式は、所属する Knowledge Base の設定を参照して有効期限を自動計算します。KB側の設定次第で記事ごとの有効期限が変わるため、単純な固定日数ではありません。KBの運用ルールを変えると、既存記事の有効期限計算にも影響が及ぶ設計です。

必須項目を決めている仕組み

sys_dictionary の mandatory が true の項目は、60項目のうち2件でした。short_description と kb_knowledge_base です。

Incident のシリーズでは、辞書レベルの mandatory は0件で、必須はすべてUIポリシー・データポリシー・ACLが決めていました。kb_knowledge はこの点が異なります。辞書自体が2項目を直接必須にしています。

Data Policy は kb_knowledge に1件あり、kb_knowledge_base を必須にする内容でした。辞書側ですでに mandatory=true になっている項目を、Data Policy で重ねて必須化しています。辞書の必須はフォームと保存処理に効きますが、インポートセットの経路によっては素通りするケースがあるため、Data Policy で二重に固定していると読み取れます。

UI Policy は6件ありますが、mandatory を制御するアクションは0件でした。6件はいずれも項目の表示・非表示を切り替えるだけで、必須の可否には関与しません。

条件を付けたい必須制御（「Resolved のときだけ必須」のような分岐）を作るなら、辞書の mandatory ではなくUIポリシーかデータポリシーを使います。kb_knowledge の short_description / kb_knowledge_base のように、記事の状態にかかわらず常に必須で構わない項目だけを、辞書レベルで固定していると考えられます。

• 参考：APIやインポートにも効く必須制御（Data Policy） … 画面外からの投入はここで止まる

公式のフィールド説明（sys_documentation）

ServiceNow は製品の中にフィールドの説明文を同梱しています。kb_knowledge には31件の説明がありました。

閲覧制御の設計が読み取れる引用を紹介します。

（訳: 記事の閲覧・検索を許可するロール。空の場合、すべてのユーザーが閲覧できる）

roles の説明です。ロールを1件も設定しなければ、閲覧制御は行われません。閲覧を絞りたい記事には明示的にロールを入れる必要があるという、既定が「公開寄り」の設計だと分かります。

（訳: この日付を過ぎると、記事はKnowledge Baseに表示されず、検索結果にも返らなくなる）

valid_to の説明です。前章のJavaScript式で計算される有効期限が、検索結果からの除外にも直結することが公式に明記されています。

引用元: /sys_documentation_list.do?sysparm_query=name=kb_knowledge^hintISNOTEMPTY

記事型サブクラスとKnown Error Articleの接続

kb_knowledge のサブクラスは、記事の型ごとに追加項目とデモデータの入り方が異なります。sys_dictionary を各サブクラスで確認すると、5つとも固有の追加項目を持っていました。型ごとに1つずつ確認します。

FAQ

追加項目は kb_question（質問）・kb_answer（回答）の2つで、いずれもHTML型です。本文（text）とは別にこの2項目が並び、質問と回答を分けて入力する画面になります。

デモ記事数は0件でした。

How To

追加項目は kb_introduction（導入文）・kb_instructions（手順本体）の2つです。「導入 → 手順」という2段構成をテーブル構造の側から用意している作りです。

デモ記事数は6件でした。5つの型の中では最も使われており、Known Error articleの3件を上回ります。

KCS Article

追加項目は4つ、kb_issue（症状）・kb_environment（環境）・kb_cause（原因）・kb_resolution（解決策）です。KCS（Knowledge-Centered Service）が定める「症状 → 環境 → 原因 → 解決」という記録の型が、そのままテーブル構造に落とし込まれています。

デモ記事数は0件でした。

Known Error article

追加項目は3つ、kb_cause（原因）・kb_description（説明）・kb_workaround（回避策）です。

この3項目は、Problem 管理の cause_notes / workaround と役割が対応しています。この対応は、Problem テーブルの primary_known_error_article という参照項目にもとづく意図的な設計です。参照先は kb_knowledge 全体ではなく、kb_template_known_error_article というこのサブクラスに限定されています。

Problem 側にはさらに problem.knowledgebase.known_error_article というプロパティがあり、Known Error 記事を作成する先のKBを、このプロパティで一元的に指定しています。原因調査の結果を Known Error article に変換する導線が、フィールド定義とプロパティの両方で構造化されている形です。Problem 管理から Known Error article を作る仕組みの詳細は、本シリーズのProblem管理編で扱います。

デモ記事数は3件でした。

What Is

追加項目は kb_introduction（導入文）・kb_explanation（説明本文）の2つです。導入文の項目名は How To と共通ですが、本体側は kb_instructions ではなく kb_explanation になります。手順を書く型と説明を書く型で、導入のあとに続く項目名を変えている設計です。

デモ記事数は2件でした。

taskを継承しないことの帰結

kb_knowledge の60項目に assigned_to（担当者）や priority（優先度）はありません。Incident や Problem が task から受け継ぐ作業管理系の項目は、kb_knowledge には最初から存在しない設計です。

SLA・エスカレーション・割り当てルールの仕組みも同様です。contract_sla / sysrule_escalate / sysrule_assignment を kb_knowledge 向けに検索すると、いずれも0件でした。task を継承していないため、これらの仕組みにそもそも接続する先がありません。

ナレッジ管理の運用は、作業管理とも接点を持っています。周辺には task を継承する2つの専用テーブルがあります。

• kb_feedback_task：記事へのフィードバックに対応するためのタスク

• kb_submission：記事投稿の申請

この2つは super_class が task です。担当者・優先度・SLAといった作業管理の仕組みは、記事本体（kb_knowledge）ではなく、この2つの周辺テーブル側に委ねられています。記事そのものは公開状態（workflow_state）だけを持ち、フィードバック対応や投稿審査という「作業」が発生する場面だけを、別のtask系テーブルに切り出す設計です。

itil ロールの扱いにも同じ設計思想が表れています。Problem 管理では itil ロールが sn_problem_write を自動的に含みますが、knowledge 系ロールは itil から一切自動継承されません。ナレッジ記事の執筆・管理権限は、knowledge 系ロールを個別に付与しない限り持てません。

• 参考：記事の評価はどこに溜まるか（kb_feedback） … kb_feedbackとkb_feedback_taskの詳しい構造

kb_versionは記事より多い、改版の積み上げ

記事に関連するテーブルの件数を並べると、kb_version（版履歴）が記事本体の件数を上回っていました。

指標件数kb_knowledge（記事）53件kb_version（版履歴）70件kb_category（分類）41件kb_feedback（評価・コメント）19件kb_use（利用実績）0件

記事53件に対して版履歴が70件ということは、一部の記事が複数回改版され、履歴が積み上がっていることを意味します。1記事あたり平均で1.3件強の版が記録されている計算です。

workflow_state の内訳を見ると、記事53件は draft 4件・outdated 7件・published 42件の3値だけで構成されていました。

workflow_state には7つの選択肢が用意されていますが、デモデータで実際に使われているのは3値だけでした。

• 全7選択肢：Draft / Review / Scheduled for publish / Published / Pending retirement / Retired / Outdated

• 0件だった4値：review / scheduled_publish / pending_retirement / retired

承認待ちや廃止申請中の状態は、実機データからは確認できません。承認フローや廃止フローの中身を確認したい場合は、実際に記事を1件動かして状態遷移を追う必要があります。

• 参考：Knowledge Portal（/kb）の「45 Articles」はどこから来るか … 画面に表示される件数との対応。デモデータは更新され得るため、記事数は都度実機で確認します

実機で気づいたこと

Now Assistで生成した記事を追跡する項目がある

固有フィールドの一覧に generated_with_now_assist（Boolean）という項目がありました。

Now Assist（生成AI機能）で作られた記事かどうかを、この1項目だけで記録する設計です。AI生成コンテンツの品質やレビュー状況を後から追跡できるようにする狙いだと考えられます。自社でNow Assistの記事生成を使う場合、この項目を条件にレポートやレビューのフィルタを作れます。

フィールドレベルのACLはkb_knowledgeに集中する

kb_knowledge に関連するACLをテーブル単位とフィールド単位に分けると、フィールド単位のACLは122件のうち43件が kb_knowledge 自身に付いています。60項目の固有フィールドに対して、平均で1項目あたり0.7件のACLが個別に設定されている計算です。

閲覧制御を項目単位まで作り込む前提の設計だと分かります。自社で新しい項目を追加するとき、テーブル全体のACLだけでなく、その項目固有のACLが必要かどうかも検討対象になります。

workflow_stateの内部値はラベルと文字数が変わる

Scheduled for publish の内部値は scheduled_publish、Pending retirement の内部値は pending_retirement です。画面のラベルをそのまま内部値だと思って workflow_state=Scheduled for publish のような条件式を書くと、一致しません。

スクリプトやレポートの条件式では、選択肢一覧（sys_choice）で内部値を確認してから使う必要があります。ラベルと内部値がアンダースコア区切りで短縮されている点は、他のワークフロー型フィールドを調べるときにも当てはまる可能性があります。

実務で順番に検討する箇所

自社向けにナレッジのフィールドを設計するとき、確認する順序を決めておくと迷いません。

1. 追加先の判断：全記事型で使うなら kb_knowledge に、特定の記事型だけで使うならそのサブクラスに足す

2. 型の選択：オン・オフの制御は Boolean、状態遷移は Workflow 型の workflow_state に集約する

3. 既定値：固定値で足りるか、所属KBを参照するJavaScript式が要るか

4. 必須の実現方法：常に必須なら辞書の mandatory、条件付きならUIポリシーかデータポリシー

5. 参照先の絞り込み：Reference 型を足すなら参照修飾子も同時に決める

6. 作業管理の要否：担当者・優先度・期限が要る業務は、記事本体ではなく kb_feedback_task のような別テーブルに切り出す

7. 版管理の設計：改版のたびに履歴を残したいか、kb_version の仕組みで足りるかを確認する

8. 閲覧制御の粒度：テーブル単位で足りるか、項目単位のACLまで必要かを検討する

用語

• OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態

• PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス

• 辞書（Dictionary）：sys_dictionary。テーブルの各項目の型・長さ・既定値を定義する場所

• サブクラス：あるテーブルを継承し、追加項目を持つテーブル。kb_knowledge では記事型ごとに用意される

• データポリシー：画面・API・インポートのすべてに効く必須／読み取り専用の制御

検証範囲とおことわり

• 検証環境：Australia PDI / OOTB / 2026-09-01 確認

• 件数はすべて OOTB の定義の数です。本番環境やカスタマイズ済み環境では異なります

• UIポリシー6件・データポリシー1件の条件式の中身は、本シリーズ第6巻「ナレッジ管理モジュールの自動設定構成」で扱います

• ACL・User Criteriaによる実際の閲覧可否の判定は、本シリーズ第3巻「ナレッジ管理モジュールのロール」で扱います

• Known Error article の作成フロー・承認フローの中身は、本シリーズ第7巻「ナレッジ管理モジュールのトラブル事例と解決」および連携機能編で扱います

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

• kb_knowledge の項目定義：/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^elementISNOTEMPTY

• 参照型だけを見る：/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^internal_type=reference^elementISNOTEMPTY

• 既定値が入っている項目：/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^default_valueISNOTEMPTY^elementISNOTEMPTY

• 必須項目：/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^mandatory=true

• 型ごとの件数：/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^elementISNOTEMPTY^GROUPBYinternal_type

• 継承関係：/sys_db_object_list.do?sysparm_query=nameINkb_knowledge,kb_template_faq,kb_template_how_to,kb_template_kcs_article,kb_template_known_error_article,kb_template_what_is

• Known Error article固有フィールド：/sys_dictionary_list.do?sysparm_query=name=kb_template_known_error_article^elementISNOTEMPTY

• workflow_state の選択肢：/sys_choice_list.do?sysparm_query=name=kb_knowledge^element=workflow_state^ORDERBYsequence

引用した公式説明を実機で確認する方法

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=kb_knowledge^hintISNOTEMPTY

関連記事

• ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … Knowledge Base・Category・公開範囲を含む全体の地図

• ナレッジの本棚と分類（kb_knowledge_base） … kb_knowledge_base・kb_categoryの詳しい構造

• 記事の評価はどこに溜まるか（kb_feedback） … kb_feedback・kb_feedback_taskの詳しい構造