ナレッジ管理モジュールの基本設定

ナレッジベースを新しく1つ作るとき、決める項目は何でしょうか。公開に承認を挟むか、カテゴリをどう分けるか、誰が読めて誰が投稿できるか。ここを決めないまま使い始めると、後から公開経路も可視性も直しにくくなります。Australia の PDI をデフォルト設定のまま開き、5件あるナレッジベースの設定値と、そこに残る2種類の壊れた参照を確かめました。

導入時に決めること

• 公開・退役に承認を挟むか、フローをどう選ぶか

• カテゴリをKBの下に何階層で持つか

• 5種類ある記事テンプレートのどれを使うか

• 誰が読めて誰が投稿できるかをUser Criteriaでどう縛るか

• 有効期限とフィードバック項目をKB単位でどう開閉するか

設定を決める前に知っておくこと

• kb_version（Release version）は5件とも3。Flow Designer方式に揃っている

• 旧workflow欄は5件中4件が壊れた参照。今の設定画面には出てこない

• SLA・割り当て・エスカレーションは task を継承しないため構造的に存在しない

ナレッジベース5件はどこで設定するか

設定の単位は kb_knowledge_base というテーブルです。ここに5件のレコードがあり、記事が属するKBごとに公開フローもカテゴリもテンプレートも別々に持てます。

Release versionは5件とも3でした。ServiceNowにはKBごとにバージョン2方式とバージョン3方式が選べる仕組みがありますが、この環境では全KBがバージョン3、つまり後述するFlow Designer方式に揃っています。

Orderは公開画面での並び順を決める項目です。ITが100、Knowledgeが300で、他3件は未設定でした。並び順を制御したいKBだけ数値を入れる運用だと分かります。

公開・退役フローはKBごとに承認あり/なしを選べる

記事を公開するとき、誰かの承認を挟むかどうかは、所属するKB側の Publish flow / Retire flow という2項目が決めます。

ITだけ Publish flow が「Knowledge - Approval Publish」、Retire flow が「Knowledge - Approval Retire」でした。承認ありの経路です。残る4件（GRC＝Governance, Risk, and Compliance・KCS Knowledge Base・Knowledge・Known Error）は承認なしの即時公開です。Publish flow は「Knowledge - Instant Publish」、Retire flow は「Knowledge - Instant Retire」でした。

社内向けの手順メモと、対外的な説明にも使う公式手順で、公開前のチェックを同じ扱いにしていません。この差は設定を見て初めて分かります。

Flow Designerの9件がPublish/Retireの中身を担う

Publish flow / Retire flowの選択肢は sys_hub_flow というテーブルに入っています。「Knowledge - 」で始まるフローを数えると9件、全件がactiveかつpublished状態でした。

9件それぞれの役割は公式のdescriptionに書かれています。

Instant Publish の公式descriptionです。

（訳: 記事の作成と同時に即座に公開する）

Approval Publish の公式descriptionです。

（訳: 承認を伴う公開申請の提出を処理する）

引用元: /sys_hub_flow_list.do?sysparm_query=nameLIKEKnowledge^ORDERBYname

9件のうち Knowledge - Outdate Article だけは、退役ではなく新しい版が公開されたときに旧版を Outdated へ切り替える役目です。退役（Retire）と型落ち（Outdate）は別の状態遷移で、別のフローが担当しています。

• 参考：Flow Designerの中身は3テーブル（sys_hub_flow） … sys_hub_flowそのものの構造

承認を追加するにはPublish flowを差し替える

Instant Publish のKBに承認を追加したい場合、必要な作業はシンプルです。KBレコードの Publish flow / Retire flow を Approval 系のフローに差し替えるだけで、承認プロセスが有効になります。

ITで実際に動いている2つのApproval系フローを、他のKBのPublish flow / Retire flowにそのまま指定できます。承認者の割り当てはFlow側のロジックに任され、KB側では経路を選ぶだけです。

逆に、承認を外したいときは Instant 系に戻します。フローの差し替えだけで完結するため、運用ルールの変更に対して設定変更のコストは小さい部類です。

• 参考：ServiceNow 承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか … 承認が止まったときの追い方

旧ワークフロー欄は今の設定画面には出てこない

kb_knowledge_base には Publish flow / Retire flow のほかに、旧方式の workflow / retire_workflow という2項目が残っています。ところが今の設定画面（Knowledge Base レコード）を開いても、この2項目は表示されません。

sys_id で直接引くと、この2項目には値が入っています。ところがその値が指す wf_workflow レコードは、5件中4件（IT・KCS Knowledge Base・Knowledge・Known Error）で見つかりません。GRCだけ両方とも空欄で、参照そのものを持ちません。

5件中4件が壊れた参照を持つ

承認ありのITも同様です。公開フローはFlow Designerへ移行済みでも、旧workflow欄の値はレコードに残ったままです。

読みに行かなければ実害はありません。ただし何かのスクリプトや連携が古い workflow フィールドを参照していた場合、値が入っているのに実体が無いという状態にぶつかります。設定を移行するときは、Publish flow / Retire flowの2項目だけを見る運用に切り替えます。

• 参考：レガシーWorkflow（wf_workflow）とFlowの違い … 旧方式そのものの仕組み

もう1つ、別系統の壊れた参照もあります。KB個別の Data policy 欄（sys_data_policy2 への参照）が、GRCとKCS Knowledge Baseの2件で同じように実体を失っていました。こちらは公開フローとは無関係の、追加の必須項目チェックを差し込むための欄です。

• 参考：APIやインポートにも効く必須制御（Data Policy） … Data Policyそのものの仕組み

カテゴリはKBの下にもう1段ある

カテゴリ（kb_category）は41件でした。KBに直接ぶら下がるトップレベルが18件、さらにその下に置かれる下位カテゴリが23件です。

kb_category は専用の「所属KB」欄を持ちません。代わりに parent_table / parent_id という汎用の参照ペアで、上位がKBなのかカテゴリなのかを区別しています。

KBごとのトップレベル件数は偏っています。

ITが8件で最多、GRCが7件で続きます。KCS Knowledge Baseは3件、Knowledge と Known Error はどちらも0件でした。

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

記事テンプレートは5件のうちKnown Errorだけ有効

記事の型（FAQ・How To・KCS Article・Known Error article・What Is）は kb_knowledge のサブクラスとして実装されています。Administration配下の「Article Templates」には、その5型に1:1で対応するテンプレートレコードが5件あります。役割の詳しい違いは本シリーズ第1巻「概要」で扱う内容です。

引用元: /kb_article_template_list.do

型ごとにテンプレートの有効状態を確認します。

FAQ

テンプレートは Inactive です。質問と回答を記録する型で、有効化しない限り新規作成時の選択肢には出ません。

How To

テンプレートは Inactive です。デモデータでは6件がこの型で作られており、5型の中で最も使われています。テンプレートを有効化しなくても、既存記事のコピーや直接入力でこの型の記事は作れることになります。

KCS Article

テンプレートは Inactive です。KCS（Knowledge-Centered Service）の解決記録に使う型です。

Known Error Article

テンプレートは5件のうち唯一の Active です。Problem管理の恒久対策（既知のエラー）を記事化するための専用型で、原因（kb_cause）・説明（kb_description）・回避策（kb_workaround）という3項目を追加で持ちます。

problem.knowledgebase.known_error_article というプロパティが、Problem管理からKnown Error記事を作成するときの作成先KBを直接指定しています。テンプレートが唯一有効という事実は、この連携が現に使われる経路として整備されていることを裏づけています。

• 参考：ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Known Error登録までの流れ

What Is

テンプレートは Inactive です。用語・概念を説明する型です。

他の4型を使う場合は、Article Templatesレコードを個別に有効化する作業が要ります。

誰が読めて誰が投稿できるかはUser Criteriaで決める

KB単位の可視性は、ACLではなく user_criteria を使った専用の中間テーブルで管理されています。「誰が読めるか」を持つのが kb_uc_can_read_mtom です。

5件のうち、GRCとKCS Knowledge Baseは1件も登録がありません。「誰が投稿できるか」（kb_uc_can_contribute_mtom）でも、KCS Knowledge Baseだけ0件でした。

Can Read / Can Contributeが空のとき、実際に閲覧・投稿できるかどうかはACLとスクリプト側の判定に委ねられます。この判定の詳しい仕組みは、本シリーズ第3巻「ナレッジ管理モジュールのロール」で扱っています。

• 参考：Employee Centerでコンテンツはどう出し分けられる？ トピックへの紐付けとUser Criteriaを実機で確認 … User Criteriaを使う別の画面での例

バージョンはメジャー版ごとに新しいレコードが作られる

版数管理（kb_version）の仕組みは、記事番号（number）ではなく kb_knowledge のレコード単位で動きます。記事「KB0005010」を例に見ると、この違いがよく分かります。

同じ番号KB0005010に対応する kb_knowledge レコードは、実は3件ありました。version=1.0（workflow_state=Outdated）、version=2.0（Outdated）、version=3.0（Published・latest=true）です。2.0のレコードは base_version 欄で1.0を、3.0のレコードは2.0を指しています。

整数部が変わるメジャー版（1.0→2.0→3.0）が上がるたびに、新しい kb_knowledge レコードが作られます。旧レコードは「Knowledge - Outdate Article」フローによって workflow_state が Outdated に切り替わります。小数点以下のマイナー編集は、同じレコードに kb_version として履歴が積み上がるだけです。

52件のレコードのうち、履歴が1版だけなのは46件でした。残る6件（3版が3件・5版が3件）だけが実際に改版されています。ほとんどの記事は公開後に手を入れられていない、という実態です。

有効期限はKB側の日数設定が空欄で実質無期限

記事の valid_to（有効期限）は、KB側の article_validity（日数設定）から自動計算されます。

article_validity は5件のKBすべてで空欄でした。日数の指定が無い場合の計算結果を実データで確認すると、valid_toは2035年や2100年といった数十年先の日付になっていました。実務上、期限切れは発生しない設定です。

期限管理を運用したい場合は、KBごとに article_validity へ具体的な日数を入れます。空欄のままでは、記事が古くなっても自動では見直しの対象になりません。

フィードバック4項目はKB単位のチェックボックスで開閉する

星評価・コメント・役に立った評価・記事へのフラグ付けは、それぞれ独立したチェックボックスでON/OFFできます。

評価・コメント・役立った・フラグの4項目とも、5件すべてでチェックが外れていました。フィードバックの入り口は既定で全開です。

一方、社会的Q&A（Enable social questions and answers）はKBごとに割れています。GRC・IT・KCS Knowledge Baseは有効、Knowledge と Known Error は無効でした。基本の評価4項目とQ&A機能は別の設定として扱われています。

品質チェック（AQIチェックリスト）を持つのはKCS Knowledge Baseだけで、「Default AQI Survey」が割り当てられていました。KCS方式の記事作成プロセスに合わせた設定です。

• 参考：記事の評価はどこに溜まるか（kb_feedback） … 評価データの保存先テーブル

SLA・割り当て・エスカレーションは構造的に存在しない

インシデントや変更で使うSLA定義・割り当てルール・無操作監視は、いずれも kb_knowledge に対して0件でした。

contract_sla sysrule_assignment sysrule_escalate の3テーブルを collection=kb_knowledge / table=kb_knowledge で検索しても、該当は1件もありません。設定を忘れているのではなく、そもそも仕組みに乗らない構造です。

kb_knowledge は task を継承しません。SLA・割り当てルール・エスカレーションはいずれも task 系のテーブルを前提にした仕組みで、継承していないテーブルには適用できません。

記事の対応期限を管理したい場合は、別の作り込みが要ります。kb_feedback_task（フィードバックへの対応タスク）や kb_submission（投稿申請）は task を継承しているため、こちら側でSLAや割り当てルールを組む余地があります。

• 参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 割り当てルールそのものの仕組み

• 参考：task_sla：1タスク1本のSLA時計の読み方 … SLAが動くテーブル側の仕組み

実機で気づいたこと

KCS Knowledge Baseだけ不備が重なっている

ここまでの設定を1件ずつ見ていくと、KCS Knowledge Baseにだけ複数の欠けが重なっていることに気づきます。Can Read User Criteriaが0件、Can Contribute User Criteriaも0件、Data policyは壊れた参照、旧workflow欄も壊れた参照です。

他の4件は、多くても壊れた参照が1〜2種類にとどまります。KCS Knowledge Base（demo data）という名前のとおりデモ用に用意された環境で、本番導入の手本にはできません。自社でKBを新設するときは、この4項目を1つずつ埋める前提でチェックリストを作ります。

2種類の壊れた参照は原因が別

旧workflow欄とData policy欄は、どちらも「値はあるのに参照先が無い」という同じ症状です。ただし対象KBの組み合わせは一致しません。旧workflow欄はIT・KCS・Knowledge・Known Errorの4件、Data policy欄はGRCとKCSの2件で、重なるのはKCS Knowledge Baseだけです。

一括の移行漏れではなく、別々のタイミングで別々の理由から生まれた残骸だと考えられます。原因がKBごとに異なるため、設定の点検では項目ごとに個別で参照先の実在を確認する必要があります。

メジャー版が上がるとレコードごと切り替わる

KB0005010を調べるまで、版数管理は同じレコードの中で完結すると考えていました。実際には整数部が変わるたびに kb_knowledge の行そのものが新しくなり、旧行はOutdatedとして残ります。

一覧画面でKB0005010を開いたとき、表示されるのは最新（version=3.0・latest=true）の行です。過去のsys_idを直接開かない限り、旧版が3件に分かれて存在することには気づきません。改版履歴を調査するときは、number ではなく base_version のつながりを辿る必要があります。

設定変更を本番へ運ぶ方法

ここまでの設定は、すべて更新セット（Update Set）に記録されます。

変更するもの更新セットに入るかkb_knowledge_baseのPublish flow / Retire flow入るkb_categoryの追加・親子関係入るkb_article_templateの有効化入るUser Criteria（kb_uc_*_mtom）入るフィードバック4項目のチェックボックス入る

検証環境で調整したKB設定は、更新セットにまとめて本番へ運べます。本番で直接触った設定は次の移送で上書きされるため、検証環境で変更してから移す順序を崩さないようにします。

• 参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 移送の仕組み

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

新しくKBを作るとき、次の順序で設定すると手戻りが減ります。

1. 公開・退役フロー：承認を挟むかを最初に決め、Publish flow / Retire flowを選ぶ

2. 旧workflow欄：読みに行かない前提で無視する。値が入っていても実体は保証されない

3. カテゴリ：トップレベルとその下位をどこまで作るか決める

4. 記事テンプレート：Known Error以外を使うなら個別に有効化する

5. User Criteria：Can Read / Can Contributeを空にせず、最低1件は登録する

6. 有効期限：期限管理をするなら article_validity に日数を入れる

7. フィードバック4項目：不要な機能があればKBごとにOFFへ切り替える

8. SLA相当の管理：必要なら kb_feedback_task 側で別途設計する

用語

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

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

• kb_knowledge_base：ナレッジベース1件を表すテーブル。公開フロー・カテゴリ・テンプレートの設定単位

• kb_version：記事のマイナー改版履歴を記録するテーブル

• base_version：メジャー版の新レコードが、直前のレコードを指すための参照項目

検証範囲とおことわり

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

• 設定値はすべてOOTBの状態です。本番環境やカスタマイズ済み環境では異なります

• Publish flow / Retire flowを実際に差し替えて挙動が変わることは確認していません

• User Criteriaが空のときの実際の可否判定は、本シリーズ第3巻・第4巻に委ねています

• kb_versionとkb_knowledgeの関係は、KB0005010を含む代表例の実測にもとづく整理です。全52件の突き合わせは行っていません

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

• ナレッジベース一覧：/kb_knowledge_base_list.do

• Flow Designerのフロー：/sys_hub_flow_list.do?sysparm_query=nameLIKEKnowledge^ORDERBYname

• カテゴリ：/kb_category_list.do?sysparm_query=ORDERBYparent_table^ORDERBY2label

• 記事テンプレート：/kb_article_template_list.do

• Can Read User Criteria：/kb_uc_can_read_mtom_list.do

• Can Contribute User Criteria：/kb_uc_can_contribute_mtom_list.do

• valid_toの辞書定義：/sys_dictionary_list.do?sysparm_query=name=kb_knowledge^element=valid_to

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

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

• Flow Designerの公式説明（引用元）：/sys_hub_flow_list.do?sysparm_query=nameLIKEKnowledge^ORDERBYname

関連記事

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

• レガシーWorkflow（wf_workflow）とFlowの違い … 旧方式そのものの仕組み

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