ServiceNowのKnowledge Managementは、単に記事を1つのテーブルへ保存するだけの機能ではありません。Knowledge Baseが運営単位、Categoryが分類構造、Knowledge Articleが本文を持つコンテンツです。さらに、公開ワークフロー、User Criteria、Ownership Group、バージョン管理が組み合わさります。
この記事ではPDIに検証用Knowledge Base、カテゴリ、Draft記事を順番に作り、保存前後の画面とDBレコードを比較しました。公開は行わず、確認後にKnowledge BaseとカテゴリをActiveオフにしています。試験対策だけでなく、実装時に「どの入力がどのテーブルへ保存されるか」を追えるように整理します。
PDI検証レコード
- Knowledge Base：Codex PDI Evidence Knowledge Base（
kb_knowledge_base） - Category：PDI検証 / value=
pdi_evidence（kb_category） - Article：KB0010002 / PDIで確認するKnowledgeの保存先（
kb_knowledge） - Article version：version 0.01（
kb_version）
検証日：2026年7月19日。検証記事はDraftのまま、KBとカテゴリは検証後に無効化済みです。画面はPDIの構成に基づくため、利用中リリースやプラグインによりナビゲーション・項目は異なります。
Knowledge Base・Category・Articleの違い
| 要素 | 役割 | 主な保存先 | 設計時の判断 |
|---|---|---|---|
| Knowledge Base | 記事群の運営・アクセス・公開プロセスの単位 | kb_knowledge_base |
誰が管理し、誰が読めて、誰が投稿できるか |
| Category | 1つのKB内で記事を探しやすくする階層 | kb_category |
利用者の検索語と業務分類に沿うか |
| Knowledge Article | 手順、FAQ、障害対処などの本文 | kb_knowledge |
1記事1目的、所有者、レビュー期限、公開状態 |
| Version | 記事の改版履歴 | kb_version |
公開済み記事を直接上書きせず改版できるか |
PDI検証1：Knowledge Baseを作る
AllメニューからKnowledge > Administration > Knowledge Basesを開き、Newを選びます。検証ではTitle、Owner、Descriptionを入力しました。実運用では、この段階でKnowledge Manager、投稿者、読者、公開ワークフロー、記事のライフサイクルを決めてから作る方が安全です。
- Titleには対象読者と用途が分かる名前を入力します。
- OwnerまたはManagersに、コンテンツ品質の責任者を設定します。
- Descriptionへ対象範囲と除外範囲を記載します。
- Can Read / Cannot Read / Can ContributeなどのUser Criteriaを設計します。
- 公開・廃止ワークフローを確認してから有効化します。
Submit後、Knowledge Bases一覧に同名レコードが現れました。TitleやOwnerはKnowledge Baseレコードに保存されます。記事本文がこのレコードへ直接格納されるわけではなく、記事側がKnowledge Baseを参照します。
PDI検証2：カテゴリをKBへ結び付ける
カテゴリは単なる文字列ではありません。Knowledge Category [kb_category] の独立レコードで、Parent IDを通じてKnowledge Baseまたは上位カテゴリに結び付きます。今回のトップレベルカテゴリでは、Parent IDに作成済みKnowledge Baseを選びました。
- 対象Knowledge Baseを開き、Knowledge Categories関連リストからNewを選びます。
- Labelに利用者へ見せる名称、Valueにスクリプト等で使う安定した値を入力します。
- Parent IDが意図したKnowledge Baseを参照していることを確認します。
- 階層を深くし過ぎず、利用者が2～3回の選択で目的記事へ到達できる粒度にします。
保存後の一覧では、Parent IDに「Knowledge Base: Codex PDI Evidence Knowledge Base」と表示されました。つまり、Labelだけでなく「どのKBのカテゴリか」という参照関係がDBへ保存されています。
PDI検証3：Draft記事を作り、KBとCategoryを参照させる
次にKnowledge Articleを作成しました。Knowledge Baseを先に選ぶと、そのKBで利用可能なCategoryを選べます。ServiceNow公式手順でも、Categoryの前にKnowledge Baseを選択する流れが示されています。
今回入力したShort descriptionは「PDIで確認するKnowledgeの保存先」、本文は検証目的を明記した1段落です。公開済み情報と誤認されないよう「公開はしません」と書き、WorkflowはDraft、versionは0.01のままにしました。
保存後、Knowledge [kb_knowledge] にKB0010002が現れ、Knowledge Base列とCategory列に作成済みレコードが表示されました。同時にバージョン管理が有効な環境ではkb_versionにもversionレコードが作られます。記事番号、本文、公開状態、KB参照、カテゴリ参照、バージョンはそれぞれ意味が違うため、1画面だけでなく関連レコードを追うことが重要です。
入力からDBまでの流れ
- Knowledge Baseを保存すると
kb_knowledge_baseに運営単位ができる - Categoryを保存すると
kb_categoryに分類ができ、Parent IDでKBへつながる - Articleを保存すると
kb_knowledgeに本文と参照が保存される - Versioningが有効なら
kb_versionに改版情報が残る - Publish操作はKBのWorkflowに従い、即時公開または承認後公開へ進む
この構造が分かると、「カテゴリを変更したのに検索結果が想定と違う」「別KBの記事が投稿者に見えない」「Draftなのに読者へ出ない」といった問題を、UIだけでなくDB参照・User Criteria・Workflowに分けて調査できます。
Knowledge Managementのベストプラクティス
1. KBは部署名だけで分けない
部署が違うから別KB、という分け方だけでは、読者、機密性、承認責任、公開ライフサイクルの差を表せません。「対象読者」「情報所有者」「公開ワークフロー」「保持期間」が同じかで分割を判断します。同じならカテゴリ分けで十分な場合があります。
2. User CriteriaとRoleを混同しない
Knowledge BaseのCan Read / Cannot ReadやCan ContributeではUser Criteriaが重要です。RoleはUser Criteriaの条件に利用できますが、KBアクセス設計をRole名だけで説明しないようにします。部署、グループ、会社、場所など、実際の読者条件をレビューします。
3. 1記事1目的にする
「メール設定とVPNと端末交換」を1記事へ詰め込むと検索意図がぶれ、更新責任も不明になります。利用者が実行したい1タスクまたは解決したい1問題に絞り、タイトルには利用者が検索する語を使います。前提条件、手順、期待結果、失敗時の確認先を分けます。
4. Draft、Review、Publish、Retireを設計する
作成者本人が即時公開する運用は速い反面、誤情報が残りやすくなります。高リスク手順ではApproval Publish、Ownership Group、定期レビュー、Valid toを組み合わせます。古い記事を放置せず、更新またはRetireへ進める責任者を決めます。
5. Categoryを組織図にし過ぎない
読者は組織名ではなく「パスワードを再設定したい」「VPNにつながらない」と検索します。カテゴリは検索を補助する導線であり、記事タイトル・本文・メタデータの品質を代替しません。アクセス解析、検索失敗語、フィードバックから分類を見直します。
6. 公開前に重複と機密情報を確認する
公式機能にはSimilar ArticlesやSearch for Duplicatesなどがあります。既存記事との差分を確認し、個人情報、認証情報、社内URL、顧客固有情報を本文や添付へ入れない運用を作ります。ゲスト公開があり得るKBでは、匿名ユーザーからの見え方も確認します。
トラブルシューティング
- Categoryを選べない
- Knowledge Baseを先に選んだか、CategoryのParent IDとActive、投稿者のKBアクセスを確認します。
- 保存した記事が検索で出ない
- WorkflowがDraftのまま、Publish未完了、User Criteriaで読めない、Active/Valid to、索引更新などを確認します。
- 投稿者によって作成画面が違う
- Role、Can Contribute、Article Template、プラグイン、UI世代、対象KBの設定を確認します。
- 同じ記事番号に複数版が見える
- 記事バージョン機能では改版レコードが作成されます。公開中版とDraft改版を区別します。
CSA理解確認問題
問題：Knowledge Articleを特定Knowledge Baseの分類へ登録したい場合、正しい関係はどれですか。
- ArticleはRoleレコードへ本文を保存し、RoleがCategoryを生成する
- Categoryは独立レコードとしてKBへ結び付き、ArticleがKBとCategoryを参照する
- Knowledge BaseとCategoryは同じ
kb_knowledgeレコードの表示名にすぎない - Articleは公開後にだけKnowledge Baseを選択できる
解答と解説
正解：B。Knowledge Base、Category、Articleは別の責任を持つレコードです。記事作成ではKBを先に選び、そのKBに属するCategoryを選択します。
まとめ
PDIで実際に作成すると、Knowledge Base、Category、Article、Versionが別テーブルで管理され、参照でつながることが確認できます。高品質なKnowledge運用には、記事本文だけでなく、誰が読めるか、誰が責任を持つか、どのWorkflowで公開・廃止するか、いつ見直すかまで必要です。
CSA学習ガイド ／ ACLとRoleの違い ／ CSA練習問題
