ナレッジ管理モジュールの自動設定構成
記事を1件Publishすると、公開日時が入りバージョン番号が進みます。旧版は退役し、承認が必要なKBなら申請フローが挟まります。担当者はボタンを1回押しただけです。裏側で動いているBusiness Rule・Client Script・UI Policy・Flow Designer・通知の役割分担を、Australia の PDI で実機確認しました。
検証環境：Australia PDI / OOTB / 2026-09-01 確認
押さえておくこと
Business Ruleは kb_knowledge に47件。中心はバージョニングと状態変化への追随
公開・退役の実処理はFlow Designerの9フローが担い、承認あり/なしはKB側の設定（第5巻）が決める
Checkout・Publish・Retireの主要なUI Actionは、すべてScript Includeの1メソッド呼び出しに集約されている
クライアント側は入力補助、UIポリシーは表示切り替え、データポリシーは画面外の経路まで必須化を効かせる
通知は有効4件のみで、宛先制御は通知定義側でなくイベント発行元に委ねられている
ビジネスルールが動くタイミング
kb_knowledge に定義されたBusiness Ruleは47件、すべてactiveです。非アクティブは0件でした。
内訳はbefore18件・after20件・display7件・async2件です。役割はタイミングごとに分かれます。displayはフォーム表示前の準備、beforeは値の補正と保存の中断です。afterは他レコードの更新と通知の起点作り、asyncは記事最適化スキャンの裏実行を担います。
orderの実態には偏りがあります。47件中39件（83%）が同じorder=100に集まっていました。個別の実行順を細かく制御する必要が薄く、「beforeかafterか」という大枠の分類だけで足りる処理が大半を占めています。order=1,000以降を使うのはバージョニング関連の3件（後述）だけでした。
主要なビジネスルールの処理内容
47件のうち、いつ動いて何をするかが分かりやすい12件を order 順に見ます。
3件だけ中身を詳しく見ます。
Set article in draft state on insert（before）
条件は KBKnowledgeBase().isKBVersion3()。KB Version3（Flow Designer方式）への新規登録時だけ、workflow_stateをdraftへ強制します。テンプレートや投稿経路の違いで最初からdraft以外の値が入ろうとしても、ここで揃えられます。
Update Stage State（after）
このルールは名前だけ見ると重要そうですが、中身はisFlowDesigner(current.kb_knowledge_base)が真なら即returnします。判定条件は「kb_publish_flowかkb_retire_flowに値がある」で、本インスタンスは5KB全件がこれに該当します。つまりこのルールは実質的に何もしません。旧Workflow Editor時代のステージ管理ロジックが後方互換のためだけに残っている状態です。
Change workflow when KB changes（after）
条件は「review中の記事がKBを変更し、承認がキャンセルされた時」。処理はUI Actionが呼ぶのと同じKnowledgeUIAction().publish(current)をBusiness Ruleの側から直接呼び出します。ボタンを押していないのに公開処理が走る唯一のケースです。KBを変更する運用がある場合、review中の記事は公開まで進む可能性があると理解しておきます。
公開・退役を担うFlow Designerのフロー群
記事の公開・退役という実処理を担うのはFlow Designerです。「Knowledge - 」で始まるフローを数えると9件、全件がactiveかつpublished状態でした。旧wf_workflowはknowledge関連が0件です（KBごとの旧workflow欄が壊れた参照になっている経緯は第5巻「基本設定」に詳述済みのため、本巻では触れません）。
9件を同列に数えると多く見えます。実際にPublish/Retireのライフサイクルへ関わるのは5件だけです。内訳は承認あり・即時それぞれの公開と退役が2件ずつ、型落ち処理のOutdate Articleが1件です。残り4件は別用途でした。
Knowledge - Approval Ownership Group：サービスカタログのKB所有グループ申請項目に付随するフロー
Request new Knowledge Base / Send Email for Knowledge Base Request：新規KB申請とその通知メール
Knowledge Article：Playbook等でエージェントに記事を提示するサブフロー
Approval Publishの公式説明です。
This flow will handle the submission of publishing an article with approvals.
（訳: 承認を伴う公開申請の提出を処理する）
Instant Publishの公式説明です。
Instantaneously publishes articles upon creation.
（訳: 記事の作成と同時に即座に公開する）
引用元: /sys_hub_flow_list.do?sysparm_query=nameLIKEKnowledge^ORDERBYname
sys_hub_trigger_instance（flow.nameLIKEKnowledge -）は0件で、これら5フローはレコードトリガーを持ちません。次章のUI ActionがScript Include経由で呼び出す構造だと分かります。内部でどのAPIを介して呼んでいるかまでは本調査では確認していません。
参考：Flow Designerの中身は3テーブル（sys_hub_flow） … sys_hub_flowそのものの構造
参考：レガシーWorkflow（wf_workflow）とFlowの違い … 旧方式との違い
クライアントスクリプトとUIポリシーの役割分担
ブラウザ側で動くクライアントスクリプトは19件登録されていますが、有効なのは18件（onChange 8件／onLoad 10件）でした。無効なのはonLoadのSet KB Data1件だけです。
Validate Scheduled publish date（onChange）は予約公開日時が現在から24時間未満だとエラーを出し送信を止めます。同名のサーバ側Business Ruleと役割が重なりますが、こちらは保存前に画面上でエラー表示するための担当です。二重にチェックすることで、ネットワーク遅延などでクライアント側の判定をすり抜けてもサーバ側で確実に止まる構成になっています。
UIポリシーは6件あり、全件がactiveかつon_load=trueです。
対応するUI Policy Actionも合計6件です。ただし内訳に偏りがあります。「Change visiblity on text and wiki when Article type is Wiki」だけがtext（非表示）とwiki（表示）の2件を持ちます。他4件のUI Policyはそれぞれ1件ずつでした。差し引くと1件だけ、実行する動作を持たないUI Policyがありました（order=10,000、詳しくは後述）。
参考：Client ScriptとUI Policyの違い（フォーム挙動） … 2つの使い分け
データポリシーが必須化する項目
画面を問わず効く必須制御は「Enforce Knowledge Base Field」の1件だけです。
対象はkb_knowledge_base項目です。ところがこの項目はsys_dictionary側で既にmandatory=trueが設定されています。Data Policyが必須化している内容は、辞書レベルの必須設定とまったく同じでした。
インシデント管理のclose_code/close_notesのように、辞書はmandatory=falseのままでData Policy側だけが必須化しているケースとは事情が異なります。ここでのデータポリシーは新しい制約を追加しているのではなく、API・インポートセット経由の投入でも辞書の必須設定が確実に効くようにする、いわば二重の保険という位置づけです。
参考：APIやインポートにも効く必須制御（Data Policy） … Data Policyそのものの仕組み
UIアクションPublish・Retire・Checkoutの処理内容
フォーム上のボタンは24件あり、全件が有効です。
3つのスクリプトの中身を見ます。
Checkout
条件はKBVersioning().canCheckout(current)。処理はこの1行が核心です。
var newRecord = new KBVersioning().checkout(current);戻り値newRecordへaction.setRedirectURL()しています。押すと新しいkb_knowledgeレコードが作られ、そちらへ画面が遷移することがスクリプトから直接確認できました。すでに他の人がチェックアウト中の場合はnewRecordが空になります。「You cannot checkout this article as it is already checked out.」というエラーで止まります。
Publish（Workspace / Workspace Classic / Legacy）
3種類ある公開ボタンは、表示条件（Workspaceで出すか、重複記事チェックを挟むか）が違うだけで、最終的に呼ぶ処理は同じ1行でした。
new global.KnowledgeUIAction().publish(current);ボタンの見た目が3つに分かれていても、実装は1つのScript Includeメソッドに集約されています。改修が必要なときはUI Action本体ではなくKnowledgeUIAction側を見ます。
Retire（後継記事あり／なし）
後継記事を指定できるかどうかで条件が分かれ、後継記事ありはretireKnowledgeWithReplacementByIds()、なしはretireKnowledgeById()（実体は共通のretireKnowledgeRecord()経由）を呼びます。後継記事の指定はダイアログで一度確認を挟む作りでした。
Make this Current・Recall・Republish
Checkoutと同じくnewRecordを返して新しいレコードへ遷移するのはMake this CurrentとRepublishです。Recallだけは新しいレコードを作らず、既存レコードを「draftへ戻す」だけの処理でした。チェックアウトを取り消す操作は新規作成を伴わないという違いがあります。
参考：ServiceNowのResolveボタンはどこで動く？ UI Actionの表示条件とClient/Server処理 … UI Actionの基本パターン
1回の公開操作で処理が動く順序
ここまでの層が、Publishボタンを1回押したときにどう重なるかを整理します。
Publishボタンをクリック：Workspace/Classicいずれかの画面から
条件判定：KBKnowledge().canPublish(current)
KnowledgeUIAction().publish(current)を呼び出す：UI Actionが共通処理へ委譲
KBのPublish flowへ分岐：ITは承認あり（Approval Publish）、他4KBは即時（Instant Publish）
beforeビジネスルール：公開日時の設定・予約日時の検証・後継記事参照のクリア
workflow_state=publishedでデータベースへ書き込み
afterビジネスルール：メジャーバージョンの採番・latestフラグの付け替え・アクティビティ作成
通知イベント発行：「KM: Article approved for publish」
承認ありのITだけは、手順4と5の間に承認者の対応待ちが挟まります。それ以外の4KBは手順1から8まで一続きで進みます。障害調査でつまずきやすいのは手順4です。「公開できない」という相談を受けたら、まずそのKBのPublish flowが承認系か即時系かを確認します。
Checkoutが新しいレコードを作る版数管理の仕組み
版数管理の実体はレコードの複製です。
公開中の記事をCheckoutすると、base_versionに元の記事を指す新しいkb_knowledgeレコードがdraftとして作られます。編集して再度Publishすると、Versioning : Increment Versionがpublishedへの遷移だけをメジャー版として扱い、それ以外の遷移はマイナー版として扱います。
if (newState === prevState) return;
if (IGNORE_STATES[newState] || IGNORE_STATES[prevState]) return;
else if (MAJOR_VERSION_STATES[newState]) v.incrementMajorVersion(current);
else v.incrementMinorVersion(current);新しい版が公開されると、Versioning : Retire all versionsが同じarticle_idを持つ他のレコードを検索し、一括でretiredにします。あわせてVersioning : Update latest flagが、outdatedでない最新レコードにlatest=trueを付け直します。「1つの記事番号」に対して実は複数のkb_knowledgeレコードが存在し、article_idという共通の索引でつながっているという構造です。この連鎖は本シリーズ第5巻でKB0005010という実例（1.0→2.0→3.0の3レコード）として確認した内容と一致します。
通知の送信条件
collection=kb_knowledgeの通知は4件、全件有効でした。
通知event_name送信条件KM: Article approved for publishknowledge.approval.approved承認を経て公開が承認された時KM: Article rejected for publishknowledge.approval.rejected承認が却下された時KM: Article Expiry Warningkb.article.expiry.warning有効期限（valid_to）が近づいた時Knowledge article emailsn_ex_sp.knowledge.send_emailEmployee Center等から記事を共有した時
4件ともconditionとrecipient_fieldsが空欄でした。宛先やタイミングの絞り込みは、イベントを発行する側（Flowや共有機能）に委ねられています。インシデント管理で見つかった「event_nameに別テーブル向けの名前が混入している」ような不整合は、ナレッジ管理では見つかりませんでした。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときの追い方
無効になっている定義
有効な定義だけを見ていると、止まっている設定を見落とします。
種別有効無効ビジネスルール470クライアントスクリプト181UIポリシー60UIアクション240通知40
自動設定のほとんどが有効のまま運用されている環境です。唯一の無効定義は、onLoadのクライアントスクリプト「Set KB Data」でした。有効化する前に中身を読み、自社の運用に合うかを確認します。
実機で気づいたこと
ほぼ全てのビジネスルールが同じorder=100に集まっている
47件のBusiness Ruleのうち39件（83%）がorder=100でした。order=1,000以降を使うのはバージョニング関連の3件だけです。
インシデント管理では0〜1,000,000まで幅広くorderを使い分けている一方、ナレッジ管理はほとんどが同じ値に集まっています。処理の中身が「他のルールとの実行順を厳密に制御する必要がない」ものばかりだからだと考えられます。
自社で独自のBusiness Ruleを追加するときは、既存の大半と同じ100を避け、意図的にずらした値（300や700など）を選びます。39件と同じorderに置くと、同時実行時の順序が保証されず、意図しない前後関係が生まれる可能性があります。
画面には現れるが動作を持たないUIポリシーがある
「Hide Article Type, Text and Wiki Fields for Knowledge Child tables」というUI Policyがあります。order=10,000ですが、UI Policy Actionは0件でした。定義は一覧に表示されるため、設定を見ただけでは「何かを制御している」ように見えます。
名前から推測すると、Knowledge子テーブル向けにarticle_type・text・wikiの3項目を隠す意図で作られたと考えられますが、実行部分が空のため現在は何も起きません。実装が途中で止まった残骸か、他の仕組み（サブクラス側のビュー定義など）に役目を譲った後の削除漏れのどちらかでしょう。
自社の環境で同種のUI Policyを見つけたら、UI Policy Actionの件数を必ず確認します。件数が0であれば、削除しても画面上の挙動は変わりません。
同じ接頭辞のFlowに公開・退役と無関係な用途が混ざっている
「Knowledge - 」という名前だけで9件のフローを数えると、公開・退役の仕組みが9段階もあるように見えます。実際には5件（Approval/Instant Publish・Retire・Outdate Article）が記事のライフサイクルを担います。残る4件はKB所有グループの申請・新規KB申請・そのメール送信・Playbook表示という別用途でした。
命名規則が「Knowledge - 」という接頭辞だけでまとめられているため、名前検索だけでは公開・退役の全体像を過大に見積もってしまいます。フローの棚卸しをするときは、名前ではなくtype（flow/subflow）と実際の呼び出し元まで確認する必要があります。
実務で順番に検討する箇所
独自の自動化を追加するとき、次の順序で確認すると手戻りが減ります。
既存47件の把握：orderが100に集中している実態を踏まえ、追加分は明示的にずらす
before / after の選択：値の補正はbefore、他レコード更新や通知起点はafterに置く
Flowとの境界：KB単位の経路選定（承認あり/なし）は設定側の役割、処理の追加はこの層の役割
クライアント/サーバの選択：見た目だけならUIポリシー、API経由も止めるならデータポリシー
通知の見直し：宛先制御をFlow側に委ねる設計を踏襲するか、条件付きに変えるか決める
無効な定義の扱い：復活させるか削除するかを個別に判断する
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
article_id：同じ記事の複数バージョン（kb_knowledgeレコード）を束ねる共通の索引値
base_version：Checkout等で新しいレコードが作られたとき、直前のレコードを指す参照項目
latest：同じarticle_idの中で最新のレコードだけがtrueになるフラグ
検証範囲とおことわり
検証環境：Australia PDI / OOTB / 2026-09-01 確認
件数・条件式はすべてOOTBの定義です。本番環境やカスタマイズ済み環境では異なります
KnowledgeUIAction・KBVersioning等のScript Include内部の全実装までは追っていません。UI Actionから呼び出す先頭の1〜2行を確認したにとどまります
Flow Designerの各フロー内部（アクションの並び）は確認していません。公式description・種別（flow/subflow）・呼び出し元の関係のみを実測しています
実際にPublishボタンを押して処理順序を観測する検証は行っていません。ビジネスルールのwhen/orderとスクリプト条件式から順序を整理したものです
KBごとのPublish flow/Retire flow設定や旧workflow欄の壊れた参照は、本シリーズ第5巻「基本設定」の実測に委ねています
付録：自分の環境で確認するときのURL
ビジネスルールのタイミング別：/sys_script_list.do?sysparm_query=collection=kb_knowledge^active=true^GROUPBYwhen
ビジネスルールをorder順に：/sys_script_list.do?sysparm_query=collection=kb_knowledge^active=true^ORDERBYorder
クライアントスクリプト：/sys_script_client_list.do?sysparm_query=table=kb_knowledge^GROUPBYtype
UIポリシー：/sys_ui_policy_list.do?sysparm_query=table=kb_knowledge
データポリシー：/sys_data_policy2_list.do?sysparm_query=model_table=kb_knowledge
UIアクション：/sys_ui_action_list.do?sysparm_query=table=kb_knowledge^active=true
Flow Designerのフロー：/sys_hub_flow_list.do?sysparm_query=nameLIKEKnowledge^ORDERBYname
通知：/sysevent_email_action_list.do?sysparm_query=collection=kb_knowledge^active=true
引用した公式説明を実機で確認する方法
この記事で引用したフローの説明文は、ServiceNowが製品に同梱しているFlow Designerのdescriptionです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
Flow Designerの公式説明（引用元）：/sys_hub_flow_list.do?sysparm_query=nameLIKEKnowledge^ORDERBYname
関連記事
ServiceNowのBusiness Ruleはいつ動く？ before/after/asyncの違いを実機の件数で確認 … タイミングの基礎
Flow Designerの中身は3テーブル（sys_hub_flow） … sys_hub_flowそのものの構造
ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … シリーズ全体の構成を扱う親記事
参考：APIやインポートにも効く必須制御（Data Policy） / レガシーWorkflow（wf_workflow）とFlowの違い / ServiceNowのResolveボタンはどこで動く？
