ナレッジ管理モジュールのトラブル事例と解決

「記事が検索に出てこない」「投稿しようとしてもKnowledge Baseの候補に出ない」「公開ボタンを押したのに承認が来ない」。ナレッジ管理の相談はこの3つがほとんどです。原因の多くは不具合ではなく、KB単位のUser Criteriaや状態管理の仕組みを知らずに操作していることにあります。ロールを足す・管理者に連絡するといった対応で解決することは稀で、まず見る場所を間違えているケースがほとんどです。Australia PDIをデフォルト設定のまま開き、6つの症状を実際に切り分けました。

症状の切り分け方針

• 「見えない」「投稿できない」はロールより先にKB単位のUser Criteriaを見る

• 「公開されない」は記事側ではなくKB側のPublish flow設定を見る

• 書き込みが要る再現（実際にRetireする等）は行わず、定義とAPIの実測から整理する

この記事で扱う症状

• KCS Knowledge Baseは実機で確認すると、読める・投稿できるユーザーの条件がどちらも0件だった

• Retireや型落ち（Outdated）になっても、activeフィールドはtrueのまま変わらない

• Flowの実行履歴（sys_flow_context）にkb_knowledge起点の記録は0件で、ログから承認状況を追えない場合がある

症状から原因への切り分け方

ナレッジ管理の相談は、まず6つに分けます。

この分け方さえ押さえれば、確認する場所に迷いません。

ロールから調べ始めると遠回りになります。kb_knowledge本体のACLロール欄は、本シリーズ第3巻「ロール」で確認したとおりsnc_internal・publicとかなり緩い設定です。実際の可否を握っているのはUser Criteriaとスクリプト側のACLで、ロール欄だけを見ても答えは出ません。

記事が見えない・検索に出ない

症状：特定のKnowledge Baseの記事が、検索しても一覧を開いても出てきません。

原因：そのKBのCan Read User Criteria（誰が読めるか）が空です。KCS Knowledge Base（demo data）で実際に確認すると、フォームにこう表示されていました。

（訳: このKnowledge Baseは、Can ContributeとCan Read両方のUser Criteriaが未設定のため、読み書きできるユーザーがいません）

理由は単純です。未設定の場合に、ServiceNow自身がこの警告を出す仕組みになっています。5件のKBを一括で確認すると、実際に空のまま運用されているKBがありました。

5件あるKBのうち、Can Readの登録があるのは3件だけでした。Governance, Risk, and ComplianceとKCS Knowledge Baseは1件も登録がありません。この2件は「記事が見えない」という相談を受けたら真っ先に疑う候補になります。

解決：対象KBのCan Read User Criteriaを開き、対象者が含まれる条件が1件でもあるかを確認します。0件なら、まずここへ条件を追加します。ロールを付け足しても、User Criteriaが空のままでは解決しません。

登録が1件以上あるのに見えない場合は、条件式（user_criteria.condition）の中身を疑います。条件式自体の判定ロジックは本記事では未確認のため、次の一歩は個別のUser Criteriaレコードを開いて対象者を具体的に絞り込むことです。層ごとに切り分けたい場合は、Access Analyzerという専用の調査ツールも使えます。

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

• 参考：Access Analyzer：「見えない」の理由を層で切り分ける … 層ごとに判定を追う道具

投稿できない・投稿先にKBが出ない

症状：新規記事を作ろうとしても、投稿先のKnowledge Base一覧に候補が出ません。

原因：見えない症状と同じ構造で、こちらはCan Contribute User Criteria（誰が投稿できるか）が空です。

Can Contributeの登録があるのは4件で、KCS Knowledge Baseだけが0件でした。さきほどのCan Readとあわせると、KCS Knowledge Baseは読む・書くの両方が未設定という状態です。フォームの警告バナーは、この2つの合わせ技を1文で説明していたことになります。

kb_knowledge本体のcreate ACLはsnc_internal（内部ユーザー全員）なので、ロール要件だけを見ると誰でも記事を作れそうに見えます。投稿先の候補にKBが出ない相談を、ACLの読み違いだと勘違いしないことが大切です。

解決：確認する順序は共通です。

1. KB単位のUser Criteriaを見る：対象KBのCan Read／Can Contributeに登録があるか

2. 記事単位の上書きを見る：個別記事のroles欄やworkflow_stateが条件に合っているか

3. 最後にロールを見る：knowledge系ロールの付与漏れがないか

この順序を逆にすると、ロールを次々に足す対応になりがちです。User Criteriaが空のKBでは、ロールをいくら足しても投稿先の候補には出てきません。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの基本的な読み方

公開されない・承認が来ない

症状：Publishボタンを押しても記事が公開されず、承認の連絡も来ません。

原因：所属KBのPublish flowが承認ありのフローに設定されています。5件のKBのうち、承認ありはITだけです。

ITのPublish flowは「Knowledge - Approval Publish」で承認者の対応待ちが挟まります。残る4件（GRC・KCS Knowledge Base・Knowledge・Known Error）は「Knowledge - Instant Publish」で、作成と同時に即時公開されます。

見るべきは1点だけです。承認が来ない相談を受けたら、まず所属KBがITかどうかを確認します。IT以外のKBなら、そもそも承認という工程が存在しません。承認の連絡先や条件はFlow側のロジックに委ねられているため、承認者に割り当てられていないケースも考えられます。

Flowの実行履歴からも状況を追いたくなりますが、ここには注意が必要です。実行コンテキストを保持するsys_flow_contextをsource_table=kb_knowledgeで検索すると、本インスタンスでは0件でした。デモの記事53件（公開済み42件を含む）はFlowを経由せず直接投入されたと見られ、実行履歴からは追えません。

承認タスクを記録するsysapproval_approverも同じ条件で確認しましたが、こちらも0件でした。承認が来ないのではなく、そもそも承認タスクが1件も発行されていない状態と一致します。

解決：自分の環境で1件Publishしてから、その記事に対応するsys_flow_contextとsysapproval_approverを確認します。履歴が積み上がるのはFlowを経由した操作だけです。今回はPDIへの書き込みを伴うため、この確認自体は検証範囲外としています。

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

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

編集すると別レコードになって戸惑う

症状：公開済みの記事をCheckoutして編集すると、元の記事とは別のレコードができたように見えて戸惑います。

原因：Checkoutは仕様として新しいkb_knowledgeレコードを作ります。本シリーズ第6巻「自動設定構成」で確認したとおり、UI Actionの中身はnew KBVersioning().checkout(current)の1行で、戻り値の新レコードへ画面が遷移します。

KB0005010という記事番号で確認すると、同じarticle_idを持つkb_knowledgeレコードが3件ありました。

仕組みは単純です。記事番号（number）は同じでも、レコード（sys_id）はバージョンごとに別です。旧版はbase_versionで直前のレコードを指し、新版が公開されると自動で型落ち（outdated）に切り替わります。3件のうち、latest=trueが付くのは最新の1件だけです。

解決：「編集したら記事が増えた」ように見えますが、実際は版管理の仕組みが動いた結果です。同じ記事の履歴を追うときは、記事番号ではなくarticle_idのつながりを見ます。作業中の版が見当たらないときは、まずCheckout中でないかを確認します。latest=trueが付いたレコードが、常に最新版です。

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

Retireしたのに一覧や検索に残って見える

症状：記事をRetireしたはずなのに、一覧やレポートでは「有効な記事」として残っているように見えます。

原因：activeフィールドは、Retireや型落ちの処理では変更されません。kb_knowledgeに定義されたBusiness Rule 47件を全件確認しましたが、current.activeを操作する処理は1件もありませんでした。

実際に型落ち（outdated）になった記事7件を確認すると、全件がactive=trueのままでした。

Valid to（有効期限）も2100-01-01のままです。KB側の有効期限日数（Article Validity）が5件とも空欄のため、既定の計算では遠い未来の日付になります。valid_toの公式説明はこうです。

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

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

つまりactiveでもvalid_toでもなく、workflow_stateだけが「今この記事を出してよいか」の判定材料です。デモデータにはRetire済み（workflow_state=retired）の記事が1件も無く、実際にRetireボタンを押した直後の一覧表示までは今回確認していません。書き込みを伴う再現のため検証範囲外としましたが、型落ちと同じBusiness Rule群が処理する以上、Retireでも同じ結果になると見られます。

解決：見る項目は1つです。「有効かどうか」をactiveチェックボックスで判断しないでください。workflow_stateがpublishedかどうかで確認します。カスタムのレポートや連携スクリプトでactive=trueだけを条件にしていると、型落ち・Retire済みの記事まで拾ってしまいます。

KB設定画面のworkflow欄が壊れて見える

症状：正体は移行の残骸です。Knowledge Baseの設定をAPIで調べていると、workflow欄に値が入っているのにレコードが開けないことに気づきます。

原因：本シリーズ第5巻「基本設定」で確認したとおり、旧方式のworkflow／retire_workflow欄は5件中4件で参照先のwf_workflowレコードが存在しません。Flow Designerへ移行した際の残骸で、現在の設定画面（KBレコード）自体にはこの2項目が表示されないため、通常の操作では気づきません。連携スクリプトやレポートでこの2項目を直接参照していると、突然エラーになります。

解決：公開・退役の経路を確認するときは、旧workflow欄を無視し、Publish flow／Retire flowの2項目だけを見ます。詳しい構造は第5巻に譲ります。

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

実機で気づいたこと

KCS Knowledge Baseは製品側が空欄に気づいて警告する

きっかけは1行の警告文でした。KCS Knowledge Baseのフォームを開いた瞬間に、ServiceNow自身が「読み書きできるユーザーがいません」という警告バナーを出していました。他の巻で確認したACLやUser Criteriaの構造は、記事を1件ずつ開かないと見えないことが多いのですが、この警告はKBのフォームを開くだけで気づけます。

トラブル調査の最初の1手として、対象KBのフォームを開いて警告バナーが出ていないかを見る価値があります。バナーが出ていれば、User Criteriaの調査に進む前に原因を特定できます。

activeを触るBusiness Ruleが1件も無い

結果は0件でした。kb_knowledgeの有効なBusiness Rule 47件を1件ずつ確認しましたが、activeフィールドを書き換える処理は見つかりませんでした。ナレッジ管理では、記事の「有効・無効」をactiveで管理する設計にはなっていないと分かります。

Incident管理やProblem管理のように、無効化＝activeをfalseにする設計に慣れていると、ここで感覚がずれます。ナレッジ管理の状態管理は、workflow_stateという1本の項目に集約される設計です。activeは辞書の既定値trueのまま基本的に動かない項目だと理解しておくと、レポートや連携の設計で余計な条件を書かずに済みます。

実行履歴が無いことも、それ自体が手がかりになる

承認フローの動きを追おうとしてsys_flow_contextを調べたところ、kb_knowledge起点の記録が0件でした。他のテーブル（sysauto_script等）では実行履歴が普通に残っていたため、この0件はテーブルの不具合ではありません。

デモデータは実際の操作を経由せず、直接投入されたと考えられます。本番の記事を1件でもPublishすれば、その瞬間から履歴が積み上がっていきます。ログが無い状態は、調査の手がかりが尽きたことを意味しません。まだ誰も操作していない証拠と捉えると、調査の見立てが変わります。

記事単位の上書きは、用意されていても使われていない

結果は0件です。kb_knowledgeは記事ごとにroles欄を持ち、KB単位のUser Criteriaを個別に上書きできます。53件の記事を確認しましたが、この欄を使っている記事はありませんでした。

仕組みはあっても、実際には誰も触っていません。デモ環境固有の事情かもしれませんが、自社で導入するときも「まずKB単位で統一し、記事単位の例外は本当に必要な1件だけに絞る」という運用のほうが管理しやすいはずです。例外が増えるほど、後から見えない原因を探す調査が長引きます。

実務で順番に確認する箇所

「見えない」「投稿できない」「公開されない」の相談を受けたときに、確認する順序をまとめました。

1. KB単位のUser Criteria：Can Read・Can Contributeに対象者が含まれるか

2. 記事単位の上書き：rolesやworkflow_stateが条件に合っているか

3. ロールの付与：knowledge系ロールが個別に付いているか

4. 所属KBのPublish flow：Approval系かInstant系か

5. article_idのつながり：同じ記事の別バージョンが他にないか

6. workflow_stateの値：activeやvalid_toではなくここで判定する

7. 旧workflow欄は無視：Publish flow／Retire flowの2項目だけを見る

この順序で確認すれば、ロールから調べ始めて遠回りする事態を避けられます。検証環境でUser CriteriaやPublish flowを直したら、更新セットに記録されていることを確認してから本番へ運びます。

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

用語

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

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

• User Criteria：user_criteriaテーブルを使った、KB単位・記事単位の可視性制御の仕組み

• article_id：同じ記事の複数バージョン（kb_knowledgeレコード）を束ねる共通の索引値

• sys_flow_context：Flow Designerのフローが実行されるたびに記録される実行コンテキスト

検証範囲とおことわり

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

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

• 実際にRetireボタンを押した直後の一覧・検索表示は確認していません。型落ち（outdated）の実測から類推しています

• Publish flowを承認ありに差し替えたときの承認者への通知経路は確認していません

• KB単位のUser Criteriaを追加・削除したときの反映タイミングは確認していません

• User Criteriaが空のKBでもACLやスクリプトの条件次第で閲覧できる余地があり、その全パターンは本シリーズ第3巻「ロール」に委ねています

• sys_flow_context・sysapproval_approverの0件は本インスタンスの実測であり、別のPDIやデモデータの投入時期が違う環境では件数が異なる可能性があります

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

• Can Read User Criteria：/kb_uc_can_read_mtom_list.do?sysparm_query=GROUPBYkb_knowledge_base

• Can Contribute User Criteria：/kb_uc_can_contribute_mtom_list.do?sysparm_query=GROUPBYkb_knowledge_base

• ナレッジベースの設定：/kb_knowledge_base_list.do

• Flowの実行履歴：/sys_flow_context_list.do?sysparm_query=source_table=kb_knowledge

• 記事の版のつながり：/kb_knowledge_list.do?sysparm_query=article_id=<article_idの値>

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

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

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

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

関連記事

• ロールを付けたのに見えない理由：ACL（sys_security_acl） … 権限で止まる原因の基本

• Employee Centerでコンテンツはどう出し分けられる？ トピックへの紐付けとUser Criteriaを実機で確認 … User Criteriaの基本的な使われ方

• レガシーWorkflow（wf_workflow）とFlowの違い … 旧workflow欄の正体

• 参考：ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … シリーズ全体の親記事