ナレッジ管理モジュールの運用手順書

ナレッジ記事を書いたのに公開されない、公開したつもりが誰にも見えない。ナレッジ管理の担当者が最初につまずくのはここです。ServiceNowは記事の公開段階をworkflow_stateという1項目で管理しますが、Publishボタンを押した先の挙動は所属するKnowledge Base側の設定で分かれます。この記事は、Australia PDIに実在する記事を1件ずつ開き、起票から改版・廃止までの手順として整理したものです。

この手順書に含む内容

• 起票からレビュー依頼・承認・公開までの作業手順

• 改版（Checkout）と廃止（Retire／Outdated）の操作手順

• 各段階で入力する項目と、実在記事による記入例

• Problem管理からKnown Error記事を起票する経路

• 差し戻し・放置を防ぐためのリカバリ表

押さえておくこと

• 作業は7つのSTEPで構成され、STEP3のPublishが分岐点になる

• 承認を挟むKnowledge Baseは5つのうち1つだけで、残り4つは即時公開になる

• 改版はCheckoutを押すと別レコードが生成される方式で、上書きにはならない

• 正式なRetire操作の実例はデモデータに0件で、実際に廃止済みとして残るのはOutdatedの7件だけ

1. 本手順書の目的

ナレッジ管理の担当者が、記事を1件起票してから公開・改版・廃止までを、迷わず同じ手順で進められるようにする。

記事の公開段階（workflow_state）はKB0005010のような実在記事のバージョン推移からも読み取れるとおり、記事1件が複数のレコードに分かれて版を重ねる構造です。手順が担当者ごとに違うと、どの版が最新か、誰が承認したかを追えなくなります。この手順書は、その追跡を可能にする粒度で作業を統一することを目的とします。

2. 適用範囲と前提条件

2-1. 適用範囲

本手順書は、ServiceNowのナレッジ管理モジュールを使う日常運用を対象とします。プラグイン導入・Knowledge Base自体の新規作成・多言語翻訳の設定は対象外とします。

2-2. 前提条件

項目内容対象バージョンAustralia対象テーブルkb_knowledge（記事本体、super_classなしの独立テーブル）必要なロールknowledge（執筆・編集・レビュー）／knowledge_admin（KB管理）記事作成・更新・削除の実際のACL要件snc_internal（内部ユーザー全員が対象。knowledge系ロールは不要）承認の有無Knowledge Base単位で決まる（IT KBのみ承認あり）

ACL上は記事の作成・更新・削除にknowledge系ロールを要求していません。実際の可否は所属KBのUser Criteriaとスクリプト側で判定される構成のため、権限の設計自体は本シリーズ第3巻「ロール」に譲り、本手順書では操作の手順に絞ります。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの条件と評価順の基本

3. 対象者と役割

役割担当する作業記事作成者起票・執筆・レビュー依頼・改版・（後継記事なしの場合の）廃止承認者IT Knowledge Baseに限り、レビュー依頼された記事のApprove／RejectKB管理者（knowledge_admin／knowledge_manager）Knowledge Base自体の設定管理、テンプレートの有効化判断

体制の詳細（誰が何人で担当するか、承認者の選定ルール）は本シリーズ第11巻「運用設計書」に譲ります。本手順書では、STEPごとに「誰が」「どの画面で」「何を」行うかだけを扱います。

4. 作業の全体像

記事の公開段階は7つのworkflow_stateで管理されています。

Australia PDIのkb_knowledgeは53件で、内訳はDraft4件・Outdated7件・Published42件でした。残る4状態（Review・Scheduled for publish・Pending retirement・Retired）はいずれも0件です。

0件の状態はグループ自体が一覧に現れません。担当者が一覧だけを見ていると、Review・Retiredのような状態が選択肢にあることさえ気づきにくい構成です。選択肢の定義そのものは7つとも有効です。

4-1. 承認の有無はKB単位で決まる

Knowledge Baseは5つあります。

5つのうちPublish flowがApproval（承認あり）に設定されているのはIT Knowledge Baseだけです。残る4つはInstant（即時公開）です。

所属するKBがApproval設定かInstant設定かによって、STEP3で同じPublishボタンを押した結果がまったく変わります。承認を前提に執筆していても、所属先がInstant設定のKBであればレビューを経ずに一発で公開される仕組みです。STEP3に進む前に、この違いを必ず確認します。

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

5. 記事を閲覧する手順

ここまでは記事を書く担当者側の操作です。記事を探す側の経路は、利用者向けとナレッジ担当者向けで画面が分かれています。

5-1. 利用者はKBポータルかEmployee Centerを開く

利用者は/kb（Knowledge Portal）または/esc（Employee Center）を開きます。どちらもService Portal上の画面で、上部の検索窓にキーワードを入力するか、Knowledge Base単位のタイルからカテゴリをたどって記事を探します。

/kbのトップにはKnowledge Baseが5つタイル表示され、タイルごとに公開済み記事の件数が添えられています。/esc?id=esc_knowledge_home（Employee Center）も、同じ記事データを別レイアウトで表示する入口です。

5-2. 担当者はプラットフォーム画面のナレッジホームから検索する

担当者はプラットフォーム側の画面からも探せます。左メニューのKnowledge > Homepageを開くと、KB・カテゴリ単位の集計を確認できる画面です。個別記事の検索はkb_knowledge_list.doの一覧でKnowledge base・Category・workflow_stateを絞り込みます。利用者向けの検索対象になるのは、4章で確認したworkflow_stateがPublishedの記事です。

5-3. インシデント入力中はContextual Searchの検索パネルから開ける

インシデントフォームには、Short descriptionへの入力をきっかけに関連記事を表示する検索パネルがあります。3文字以上の入力から約1秒後に検索が実行され、ナレッジ記事を含む候補が一覧に並ぶ仕組みです。記事を開くと、編集不可の閲覧専用ページで内容を確認できます。この経路はincidentテーブル向けのContextual Search設定（cxs_table_config）で有効化されており、フォームを離れずに関連記事を確認する用途に向いています。

5-4. ナレッジセンターは新しい閲覧・編集体験（概要）

ナレッジ管理のアプリメニューにはKnowledge Centerという項目も追加されています。従来のフォーム編集やKBポータルとは別に用意された、記事の作成・検索・品質チェックをまとめて行う新しい画面です。手順や設定の詳細は別記事で扱うため、本手順書では概要の紹介にとどめます。

6. 作業手順

STEP1（Draft）：【記事作成者】テンプレートを選び記事を起票する

操作：左メニューからKnowledge > Create Newを開くか、対象のKnowledge base一覧から「New」を押します。テンプレートを選ぶ画面が最初に表示されます。

確認する項目

• Active=trueのテンプレートはKnown Error articleの1件のみで、残る4件（How To・What Is・KCS Article・FAQ）はInactiveであること

• 記事型に応じた専用フィールド（Known Error articleならkb_cause・kb_description・kb_workaround）が必要かどうか

How To・What Is・KCS Article・FAQのテンプレートはOOTBのままでは無効です。有効化するかどうかはKB管理者が判断する事項のため、テンプレートを使わずに記事を起票する運用も選択肢に入ります。

実施してはならないこと

• Active=falseのテンプレートを選ぼうとして操作が進まないまま時間を使う。有効化はKB管理者へ依頼します

STEP2（Draft）：【記事作成者】本文を執筆し保存する

操作：Knowledge base・Category・Short description・Article bodyを入力して保存します。

入力する項目（記入例：KB0005014）

欄記入例補足Knowledge baseIT必須項目。後から変更すると承認フローの適用先も変わるCategoryApple選択したKnowledge baseに属するカテゴリから選ぶShort descriptionHow to Remove AirWatch MDM from Android or iOS Device必須項目。検索で見つかる言葉で書くArticle body手順本文記事型に応じた構成（Purpose／Overview／手順）で書く

kb_knowledgeの60個の固有フィールドのうち、必須（mandatory）はShort descriptionとKnowledge baseの2項目だけです。監査系フィールドを除く大半は任意入力です。STEP2ではこの2項目を入力すれば次に進めます。

確認する項目

• Versionが0.01のままDraftで保存できていること

• Valid toが空欄、またはデフォルトの2100-01-01のままになっていないか（廃止時の扱いはSTEP7で確認します）

STEP3（Draft→Review or Published）：【記事作成者】Publishを押して分岐させる

操作：フォーム右上の「Publish」を押します。入力項目はありません。

Publishを押した先の遷移は、STEP2で選んだKnowledge base（4-1で確認したPublish flow設定）で決まります。IT Knowledge Baseの記事はReviewへ進み、残り4KBの記事は直接Publishedへ進みます。

確認する項目

• 記事が所属するKnowledge baseのOwnerと、STEP2の入力内容に誤りがないこと

• 承認を前提とする記事であれば、所属KBがApproval設定（IT）であることを4-1で確認済みであること

実施してはならないこと

• 所属KBのPublish flow設定を確認せずにPublishを押す。Instant設定のKBでは、この操作の直後に外部へ公開されます

この記事の有料部に含まれるもの

• STEP4〜STEP7：承認・公開確認・改版（Checkout）・廃止の操作と、実在記事による記入例

• 判断基準：Problem管理からKnown Error記事を起票する1ステップの経路

• 異常時の対応：よくあるミスとリカバリ表

• 補足：STEPごとに動くUI Actionの条件と処理の一覧表

💰 ここから先は有料エリア