ナレッジ管理モジュールの連携機能

2026年9月4日 12:44

インシデントをクローズしても、ナレッジ記事は自動で公開されません。Problemで回避策が決まっても、Known Error記事に何が書き込まれるのかは画面から分かりません。ナレッジ管理へは、どんな条件で、何が引き継がれるのでしょうか。Australia の PDI をデフォルト設定のまま開き、Incident・Problem・フィードバックとの接続経路を実機で確かめました。

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

確認する連携先

インシデントのクローズがナレッジの下書きを作る条件
問題管理からKnown Error記事を作るときに引き継がれる項目
kb_knowledgeを参照している実テーブルの内訳
フィードバックが作業として扱われる仕組み
サービスポータルでの表示経路とAI Searchとの関係

連携の全体像

Incidentのクローズはtask.knowledgeとBusiness Ruleが下書きを作る。作成先のKnowledge Baseは既定で記事0件の空箱になっている
Problemからは「Create Known Error article」が5項目を記事へコピーする。テーブルマップの実体を確認できた
kb_feedbackは既定で全件がkb_feedback_taskという作業レコードに変わる設計になっている

ナレッジへの接続は3種類の経路に分かれる

kb_knowledgeへの接続を、まず全体で見渡します。

経路は性質の違う3種類に分かれます。

クローズ・記事化のタイミングでBusiness Ruleが直接insertする：Incidentのクローズ時
UIアクションがテーブルマップ経由で項目をコピーする：ProblemからKnown Error記事を作るとき
参照フィールドで結びつくだけの経路：kb_feedback・Service Portal・AI Search

3番目は接続の実体はあっても、本環境では利用実績が伴っていない経路です。この記事の後半で確認します。

kb_knowledgeを参照する実テーブルはFlow内部変数を除いてから数える

sys_dictionaryでkb_knowledgeを参照するフィールドを検索すると92件が該当します。

内訳を見ると、65件はFlow Designerの内部変数テーブルでした。var__m_で始まる自動生成テーブルです。フローの入力欄がKnowledge型であるために作られます。この命名規則は問題管理・インシデント管理の連携記事でも確認した現象と同じです。

除外すると、実テーブルは27行・25種類になります。

25種類という数は、他モジュールと比べて際立って多い数です。Service Portal・Employee Center・Interaction・Now Assist・AI Search・CSM共有ドキュメント・カタログと、ほぼ全モジュールの土台になっています。kb_knowledgeがtaskを継承しない独立テーブルであることは既存記事で確認済みですが、参照される側としては逆にどのプロセスからも呼ばれる位置にいることが、この実測から分かります。

参考：Knowledge だけ task 系でない（kb_knowledge） … kb_knowledgeが独立テーブルである理由

インシデントをクローズすると条件付きでナレッジの下書きが作られる

Incidentのフォームには「Create Knowledge」に相当するボタンがありません。接続はtaskが持つ1個のチェックボックスと、Business Ruleが担っています。

If checked, will automatically create a Draft knowledge article upon closure

（訳: チェックすると、クローズ時にナレッジ記事の下書きを自動で作成する）

task.knowledgeの既定値はfalseです。担当者が明示的にチェックしたときだけ、Business Rule「Incident Create Knowledge」が動きます。

条件はincident_state.changesTo(Closed) && knowledge==trueに加えて、Best Practiceプラグインcom.snc.incident.knowledgeが無効であることです。このプラグインは実機でInactiveと確認済みなので、Australiaの既定構成ではBusiness Rule側が実際に動きます。

スクリプトの中身を見ると、kb_knowledgeへ直接GlideRecordでinsertしています。

var kb = new GlideRecord("kb_knowledge");
kb.source = current.sys_id;
kb.short_description = current.short_description;
kb.sys_domain = current.sys_domain;
kb.text = current.comments.getHTMLValue();
kb.workflow_state = 'draft';
kb.kb_knowledge_base = gs.getProperty("glide.knowman.task_kb", "dfc19531bf2021003f07e2c1ac0739ab");

本文（text）の取得元がWork notesではなくCommentsである点が実務上の注意点です。作業メモに書いた社内向けの調査経過は下書きに反映されません。顧客向けに公開してよい文面を、クローズ前にComments欄へ整理しておく必要があります。

作成先のKnowledge Baseはプロパティglide.knowman.task_kbが決めます。値はdfc19531bf2021003f07e2c1ac0739abで、名前解決すると「Knowledge」というKnowledge Baseです。このKBは既存記事で確認済みのとおり、記事0件の空箱でした。既定のまま運用すると、下書きは他の担当者が普段開かないKBに溜まり続けます。IT向けのKBへ変更するか、下書きの棚卸しを定期的に行う運用が必要です。

参考：ナレッジの本棚と分類（kb_knowledge_base） … Knowledge Baseの分類全体

glide.knowman.で始まるプロパティは108件ありました。検索欄・AQIスコア・ポータル表示列数など、ナレッジ管理の挙動を外から変えられる設定が集中しています。今回の連携に直接関わるのはtask_kbとsubmission.workflowの2件だけですが、下書きの作成先や運用ルールを見直すときは、このプレフィクスで一覧してから絞り込むと関連設定を見落としにくくなります。

もう1つの経路がプロパティglide.knowman.submission.workflowです。trueにすると、kb_knowledgeへの直接insertではなくkb_submissionという候補記事テーブルへ登録され、承認フローを経由します。値はfalseで、kb_submissionの件数も0件でした。レビュー体制を敷きたい場合は、この設定を切り替える判断になります。

インシデント側にはもう1つ、ボタンによる経路があります。

「Report Knowledge Gap」です。表示条件はIncidentUtils().canCreateKnowledgeGap(current)で、下書きを作る経路とは別に「この件を解決するナレッジが足りない」と報告する導線になっています。同名のボタンが2件登録されていて、片方のaction_nameにはreport_nowledge_gap_incという綴りの誤りがありました。動作上の実害は無さそうですが、カスタマイズでこのボタンを条件変更するときは、対象が2件あることを見落とさないようにします。

参考：インシデント管理モジュールの連携機能 … インシデント側から見た経路の全体像

問題管理からKnown Error記事を作るとUIアクションが5項目をコピーする

Problem管理からナレッジへつながる経路の中心は、primary_known_error_articleです。参照先はkb_template_known_error_article（Known Error article）で、reference_qualはactive=trueに絞られています。

Problemのフォームにある「Create Known Error article」を押すと、記事作成フォームへリダイレクトされます。この仕組み自体は問題管理の連携編で確認済みですが、そのときに何がコピーされるのかは、テーブルマップの実体を見ないと分かりません。

対応するマップはcsm_table_mapに「Problem Known Error article」という名前で登録されています。マッピングスクリプト自体は既定の空テンプレートのままで、カスタムコードはありません。実際の項目対応は、子テーブルのcsm_field_mapにレコードとして持っています。

コピーされるのは5項目です。

workaroundがkb_workaroundへ、cause_notesがkb_causeへ、descriptionがkb_descriptionへとそれぞれ専用フィールドにコピーされます。担当者が回避策や原因をProblem側に書いていれば、ボタン1つでKnown Error記事の該当欄に反映されるということです。

比較としてIncident側のマップも確認しました。short_descriptionとsys_id→sourceは同じ単純コピーですが、記事本文（text）だけはsource_fieldが空欄で、代わりにITSMKnowledgeHelper().getIncFieldValuesForStdTemplate()というヘルパークラスを呼び出す設定でした。単純な項目コピーではなく、テンプレートに沿って本文を組み立てる処理です。同じテーブルマップの仕組みでも、Problem側は素直な項目対応、Incident側はヘルパー経由という違いがあります。

Known Error記事のsourceは問題側から書き戻す設計だが今は空欄のまま

primary_known_error_articleを設定したProblemを検索すると5件でした。

5件はKnown Error記事3件（回避策の文例つき）に集約されています。この記事へ逆向きにたどるための仕組みが、Business Rule「Update Source Task of KE article」です。条件はprimary_known_error_articleISNOTEMPTY^primary_known_error_article.sourceISEMPTYで、記事のsourceが空のときだけ動きます。処理は2つです。記事のsourceへProblemのsys_idを書き込み、m2m_kb_taskという中間テーブルに記事とProblemの組を記録します。

ところが実機のKnown Error記事3件は、いずれもsourceが空欄のままでした。m2m_kb_taskも0件です。5件のProblemが記事を参照しているにもかかわらず、書き戻しの形跡がありません。デモデータがBusiness Ruleを経由しないロードで投入されたことが原因と考えられます。この2つの項目を「作られたはずの逆参照」として鵜呑みにすると、実際の紐付けを見落とします。自社の環境で確認するときは、Problem一覧からprimary_known_error_articleで辿るほうが確実です。

似た構造のBusiness Ruleが、Problem本体にもう1つあります。「Problem Create Knowledge」です。Incident Create Knowledgeとほぼ同じ処理ですが、本文の取得元はwork_notesで、条件はproblem_state.changesTo(4) && knowledge==trueでした。Madridステートモデルではproblem_stateが101〜107の値で同期し続けるため、整数値の4になる遷移は実質発生しません。Incident側と対になる自動下書き機能がProblemにも用意されているものの、現行の状態モデルの下では発火しない設計として残っているとみられます。

参考：Problem（problem）の読み方 … stateとproblem_state、2つの状態項目の背景

回避策の転記先はIncidentの作業メモとKnown Error記事の2つに分かれる

Problem管理には、回避策を関係先へ伝える別のボタン「Communicate Workaround」があります。このボタンはナレッジへは書き込みません。

Communicate Workaroundが発行するcommunicate.workaroundイベントの宛先はIncidentです。Script Actionがincident.addQuery('problem_id', ...)で対象を絞り込み、関連するIncidentのwork_notesへ回避策を転記します。

同じ「回避策を伝える」動作に見えても、行き先が違います。Communicate Workaroundは対応中の担当者へ即時共有するための経路、Create Known Error articleは記事として恒久的に残すための経路です。両方を使い分けることで、当面の対応と将来の参照資料の両方をカバーできます。

参考：インシデント管理モジュールの連携機能 … Workaroundがインシデントの作業メモへ転記される仕組み

サービスポータルへの表示経路はあるが利用ログは0件のまま

kb_knowledgeを参照するテーブルには、Service Portal向けの列が複数あります。sp_instance_link.kb_article、sp_rectangle_menu_item.kb_article、Employee Centerのsn_ex_sp_quick_link.knowledgeです。列としては存在しますが、いずれも該当行は0件でした。ウィジェットからの直接リンクやクイックリンクとして記事を固定表示する設定は、本環境では作られていません。

記事の閲覧経路そのものは、Knowledge Portal（/kb）を実際に開いて確認した既存記事があります。

参考：Knowledge Portal（/kb）の「45 Articles」はどこから来るか … 記事件数の表示元

利用実績を記録するkb_useも0件でした。記事が閲覧されたりタスクに添付されたりした実績を集計するテーブルです。Performance Analyticsコンテンツパック（com.snc.pa.knowledge_v2）もInactiveでした。このPDIには「記事は存在するが、使われた記録は無い」という状態がそのまま実測に出ています。導入直後の検証環境ではよくある状態ですが、本番導入後にレポートを作るときは、まずkb_useにデータが積み上がっているかを確認する価値があります。

AI Searchとの接続は、自動応答結果からの参照（sys_cs_auto_resolution_ai_search_result_line_item.kb_article）が実在することだけを確認しました。検索の仕組み自体は別カテゴリで詳しく扱っています。

参考：ServiceNowの検索は2階層：エンジン（Zing / AI Search）と、その上に乗る機能 … 検索エンジンと上位機能の全体像

kb_feedbackは既定で全件がkb_feedback_taskという作業に変わる

記事への評価・コメントはkb_feedbackに溜まります。デモデータは19件で、article（評価対象の記事）・comments・flagged（要対応フラグ）・useful・rating・reason（4種類の定型理由）といった項目を持ちます。フィールドの内訳は既存記事で確認済みです。この記事では、そこから先の「作業化」までを追います。

参考：記事の評価はどこに溜まるか（kb_feedback） … kb_feedbackの項目内訳

19件のうち、flagged=trueは1件でした。「Excelのどのバージョンに対応する記事か追記してほしい」というコメントです。

このflagged=trueが、作業を分担するkb_feedback_taskへ変わる設計になっています。Business Rule「Knowledge Feedback Task Creation」が、フィードバック保存のたびにKBFeedbackTask().createFeedbackTask()を呼び出します。生成されるタスクのfeedback_task_typeは、flaggedがtrueなら2（Internal feedback）、falseなら1（User feedback）です。

呼び出し可否を判定するcanCreateFeedbackTask()は、プロパティglide.knowman.feedback.enable_explicit_feedbackが既定のfalseである限り常にtrueを返します。つまり本環境の設定では、記事への評価・コメントは種類を問わず全件がタスク化される作りです。

ところが実機のkb_feedback_taskは0件でした。flagged=trueの実例が存在するにもかかわらず、対応するタスクが1件も生成されていません。Known Error記事のsource同様、デモデータがBusiness Rule経由でないロードで投入されたことによる差とみられます。自社のPDIで同じ設計を確かめたいときは、実際にフィードバックを1件投稿し、kb_feedback_taskが生成されるところまで見届けるのが確実です。

解決から評価までの一連の流れを一枚で見る

ここまでの経路を、実際の対応の流れに置き換えます。

Incident側とProblem側で経路は分かれますが、記事がdraftとして作られたあとの流れは共通です。knowledgeロールを持つ担当者がレビューし、Publishへ進めます。公開後はService PortalやEmployee Centerで閲覧され、評価が付けばkb_feedback_taskとして作業に回ります。この一連の流れのうち、本環境で実データが確認できたのは記事の作成と評価の投稿までで、公開後の閲覧・利用実績（kb_use）は0件のままでした。

連携の設計で決めること

ここまでの内容を、設計時の判断としてまとめました。

最初に決めるのは、インシデントクローズ時の下書き作成先です。既定のプロパティのままでは、記事0件の空箱KBに下書きが溜まり続けます。業務で実際に使うKBへ変更するか、定期的に棚卸しする担当を決めます。

次に、Known Error記事のsourceバックリンクを運用でどう扱うかです。本環境のように0件のまま放置されている可能性を踏まえ、Problem一覧からprimary_known_error_articleで辿る手順をチェックリストに残しておきます。

フィードバックのタスク化は、既定のままなら全件が対象です。担当者へ自動で割り当てたい場合は、プロパティenable_explicit_feedbackを有効にして絞り込みの余地を作ります。

実機で気づいたこと

インシデントのナレッジ下書きは作業メモではなく顧客向けコメントから作られる

Business Rule「Incident Create Knowledge」のスクリプトを読むと、kb.text = current.comments.getHTMLValue()とあります。Work notesではなくCommentsです。

社内向けの調査経過を作業メモに書く運用をしている現場では、この違いに気づきにくいと考えられます。作業メモをどれだけ丁寧に書いても、下書きの本文には反映されません。

実務では、クローズ前に「顧客に見せてよい要約」をCommentsへ書く手順を、チェックリストに明記しておくのがポイントです。担当者が作業メモしか書いていない場合、下書きの本文はほぼ空欄になります。

Known Error記事の逆参照は、設計はあっても実データには反映されていない

Business Rule「Update Source Task of KE article」は、Problemのprimary_known_error_articleが指す記事のsourceへ、Problem自身のsys_idを書き戻す設計です。あわせてm2m_kb_taskにも記録します。

実機で確認すると、5件のProblemが記事を参照しているにもかかわらず、対象の記事3件はsourceが空欄、m2m_kb_taskも0件でした。デモデータの投入方法がBusiness Ruleを経由しないルートだったためと考えられます。

自社のPDIで同じ調査をするときは、sourceやm2m_kb_taskが空だからといって「関連するProblemが無い」と判断しないほうが安全です。Problem側のprimary_known_error_articleから辿る経路のほうが、現時点では確実です。

同じ設計のBusiness RuleがProblemにもあるが、発火しない条件のまま残っている

Incidentの「Incident Create Knowledge」と対になる「Problem Create Knowledge」がProblem管理にも存在します。条件はproblem_state.changesTo(4)です。

Madridステートモデルの下では、problem_stateが101〜107の範囲でstateと同期し続けます。整数値の4になる遷移は実質発生しません。

同じ発想の自動化がモジュールごとに用意されていても、片方は状態モデルの都合で動かなくなっている場合があります。他モジュールから移植した設計を流用するときは、条件式が現行の状態値と噛み合っているかを個別に確認します。

用語

OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
Known Error article：原因は特定できたが恒久対策がまだ無い状態を記録する、ナレッジ記事のサブクラス
テーブルマップ：あるテーブルのレコードから別テーブルの新規作成フォームへ、値を引き継いで遷移させる仕組み
Best Practiceプラグイン：標準機能に追加の自動化を載せるオプションのプラグイン。無効化すると土台のBusiness Ruleが代わりに動く

検証範囲とおことわり

検証環境：Australia PDI（patch3）/ OOTB / 2026-09-01 確認
件数はすべてOOTBの定義・デモデータの数です。本番環境やカスタマイズ済み環境では異なります
「Create Knowledge」「Create Known Error article」「Report Knowledge Gap」「Communicate Workaround」の各ボタンを実際に押す操作は行っていません。スクリプト・テーブルマップの中身の確認にとどめています
kb_feedbackへの新規投稿、kb_feedback_taskの自動生成を実際に発生させる検証は行っていません
problem_stateが整数値4になる遷移が本当に発生しないかは、状態モデルのカスタマイズ次第で変わる可能性があります
サービスポータル・Employee Centerでの表示については、参照フィールドの件数確認にとどめ、画面上の見え方までは確認していません

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

kb_knowledgeを参照するフィールド：/sys_dictionary_list.do?sysparm_query=reference=kb_knowledge^elementISNOTEMPTY^ORDERBYname
Incident側の自動下書き作成BR：/sys_script.do?sys_id=245748ecc61122aa016c02dffbff7464
ナレッジ関連プロパティ：/sys_properties_list.do?sysparm_query=nameLIKEknowman
Report Knowledge Gapボタン：/sys_ui_action_list.do?sysparm_query=table=incident^active=true^nameLIKEknowledge
テーブルマップの一覧：/csm_table_map_list.do?sysparm_query=source_tableINproblem,incident
Problem→Known Error記事のフィールドマッピング：/csm_field_map_list.do?sysparm_query=table_map=bc77a3d0870023000e3dd61e36cb0b93
primary_known_error_articleが設定済みのProblem：/problem_list.do?sysparm_query=primary_known_error_articleISNOTEMPTY
Known Error記事の一覧：/kb_template_known_error_article_list.do
flagged=trueのフィードバック：/kb_feedback_list.do?sysparm_query=flagged=true
フィードバックの作業タスク：/kb_feedback_task_list.do

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

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

フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=task^element=knowledge
プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEknowman^descriptionISNOTEMPTY

ServiceNow ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … ナレッジ側の受け入れ全体の仕組み
ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Problem側からKnown Errorに至る全体の流れ
インシデント管理モジュールの連携機能 … インシデント側から見た他プロセスとの接続経路