ナレッジ管理モジュールのプロパティ

「検索結果の並び順を変えたい」「低評価の記事をタスク化したい」。こうした挙動をsysparm_query=nameLIKEknowledgeで探しても、目的のプロパティにはほとんど行き当たりません。ナレッジ管理のプロパティの大半はglide.knowmanという別の接頭辞を持つためです。Australia の PDI をデフォルト設定のまま開き、122件のプロパティが検索・表示・フィードバック・投稿をどう制御しているかを確かめました。

確かめること

• 「knowledge」で検索しても見つからないプロパティが、どれだけあるか

• 検索・表示・フィードバック・投稿を、それぞれ何件のプロパティが制御しているか

• User Criteriaが1件も無いKnowledge Baseが、実際にあるかどうか

• プロパティを変更する前に確認すべきこと

分かること

• ナレッジ管理関連のプロパティは122件あり、119件に公式説明が付いている

• 名前に「knowledge」を含むのは13件だけで、残り108件はglide.knowmanという別の接頭辞を持つ

• block_access_with_no_user_criteriaが既定でtrueのため、User Criteria未設定のKnowledge Baseはアクセス拒否の対象になり得る

「knowledge」で検索しても108件は見つからない

sys_propertiesをnameLIKEknowledgeで検索すると、13件しかヒットしません。

うち1件はglide.authenticate.multifactor.enforcement.acknowledgedという多要素認証の設定で、"acknowledge"の部分一致による誤検出です。実質12件しかありません。

一方、nameLIKEglide.knowmanで検索すると、様相が変わります。

108件がヒットします。knowmanはKnowledge Managementの内部での略称で、kb_knowledgeのようなテーブル名や画面の表記とは異なる文字列です。テーブル名からglide.knowledgeという接頭辞を類推して検索しても、ヒットは0件でした。

nameLIKEknowledge・nameLIKEkb.・nameLIKEglide.knowmanの3つを合算・重複除去すると、ナレッジ管理関連のプロパティは122件になります。命名規則を知らずに1系統だけを検索すると、実際の9割近くを見落とします。

公式の説明文はほとんどの項目に付いている

122件のうち119件（97.5%）にdescription（公式の説明文）が入っていました。空欄はcom.glide.script.fencing.cross_scope_access.knowledge_tables_filteredなど3件だけです。

• 参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方

プロパティの分類

122件を役割ごとに分けると、8つのまとまりになります。

最も件数が多いのは検索の29件です。次いで表示・レイアウトの20件、フィードバック・評価の18件と続きます。検索とフィードバックだけで122件の4割近くを占めており、ナレッジ管理のプロパティは「記事の中身」より「記事の見つけ方・評価のされ方」を調整する設定に厚みがあると分かります。

型で見ると、真偽値（boolean）が66件で半数以上を占めていました。

真偽値が多いのは、画面のどの要素を出す・出さないかを切り替える設定が中心だからです。この設計には利点があります。管理画面から1行のチェックを変えるだけで挙動が変わり、開発者を介さず現場で調整できます。反面、値を変えたときにどの画面へ影響するかは、descriptionを読まないと判断できません。文字列型（string）は34件で、複数の項目名やロール名をカンマ区切りで並べる形式が中心でした。この形式は入力ミスを検証しないため、値を書き換えたら該当画面を実際に開いて確認します。

検索に関連するプロパティ

検索の並び順・表示件数・多言語対応は、29件のプロパティで制御されています。

代表的な設定を見ます。glide.knowman.order.searchの既定値はrelevancy（関連度順）です。

（訳: ナレッジ検索結果の並び順）

引用元: /sys_properties_list.do?sysparm_query=name=glide.knowman.order.search

新着順に変えたい運用なら、この値をpublishedなどへ切り替えます。

もう1件、気になる設定がありました。glide.knowman.search.apply_aclsの既定値はfalseです。

（訳: 検索結果にACLを適用するかどうかを決める）

引用元: /sys_properties_list.do?sysparm_query=name=glide.knowman.search.apply_acls

検索結果の絞り込みは、この記事の後半で扱うUser Criteriaが主に担っています。この値を切り替えたときに検索結果の件数や中身がどう変わるかは、実際にログインして確認していません。有効化を検討する場合は、検証環境で件数の変化を先に確かめます。

glide.knowman.search.facet_depth（既定300）は、絞り込みフィルタを作る際に考慮する件数です。記事数が多い環境では、この値を増やすとフィルタの選択肢が充実する一方、処理する対象が増えます。

検索結果に何を表示するかも、個別のプロパティで1項目ずつ切り替えられる形式です。glide.knowman.search.show_view_count（閲覧数）・glide.knowman.search.show_author（著者）・glide.knowman.search.show_last_modified（更新日時）は既定でtrue、glide.knowman.search.show_published（公開日）とglide.knowman.search.show_article_number（記事番号）は既定でfalseでした。検索結果一覧を簡潔にしたい場合、表示中の項目のうちどれを削るかをこの単位で決められます。

glide.knowman.search_character_limit（既定3文字）は、検索が実行される最小文字数です。1〜2文字での検索を許可すると、短い単語がヒットしやすくなる一方、意図しない広い範囲がヒットしやすくなります。社内の主要な検索語が短い略語中心の環境では、値を下げる判断があります。

• 参考：ServiceNow AI Searchはどう組み立てられている？ … 検索エンジン側の構成要素との関係

フィードバック・評価に関連するプロパティ

星評価・Yes/No評価・記事へのフラグは、18件のプロパティで制御されています。

glide.knowman.show_rating_options・glide.knowman.show_yn_rating・glide.knowman.show_star_ratingは、いずれも既定でtrueです。星評価とYes/No評価の両方が同時に表示される既定構成になっています。

評価をタスク化する条件は、3件のプロパティに分かれていました。

（訳: 記事にフラグが付いたとき、対応タスクとなるフィードバックを作成する）

引用元: /sys_properties_list.do?sysparm_query=name=glide.knowman.feedback.enable_actionable_feedback_for_flag

for_flag（フラグ時）は既定でtrueですが、for_helpful（役に立たなかった評価時）はfalse、for_rating（低評価時のしきい値）は空欄で無効です。記事の品質改善サイクルを回す運用にするなら、for_ratingに数値を入れて低評価も拾う判断があります。

glide.knowman.max_comments_per_user_dailyは空欄が既定で、1人が1日に投稿できるフィードバック数に制限がありません。荒らし対策として上限を設ける場合は、この値に数値を入れます。

タスク化されたフィードバックはkb_feedback_taskというテーブルに記録され、対応担当者が確認・返信します。for_flagだけを既定で有効にしている設計には理由があります。内容の誤りや古さの指摘（フラグ）を、単なる低評価より優先度の高いシグナルとして扱う狙いです。低評価そのものにも対応したい場合は、for_ratingにしきい値を設定してから、実際にタスクが作られる件数を確認します。件数が多すぎるようであれば、しきい値を段階的に絞り込みます。

• 参考：記事の評価はどこに溜まるか（kb_feedback） … 評価データの保存先テーブル

投稿・承認に関連するプロパティ

記事の投稿ワークフローと、KB新規作成の承認は10件のプロパティで制御されています。

glide.knowman.submission.workflowは既定でfalseです。

（訳: 投稿ワークフローを使用する）

引用元: /sys_properties_list.do?sysparm_query=name=glide.knowman.submission.workflow

投稿ワークフローを使わない既定構成では、記事の作成から公開までを1人の担当者が完結できます。複数人でレビューしてから公開したい運用にするなら、この値を有効にします。

新規Knowledge Base自体の申請は、glide.approval_engine.kb_knowledge_base_requestが制御します。既定値はoff（承認なし）です。

（訳: kb_knowledge_base_requestテーブルに使用する承認エンジン）

引用元: /sys_properties_list.do?sysparm_query=name=glide.approval_engine.kb_knowledge_base_request

説明文にはoffのほか、Approval Rulesエンジンを使う空欄設定と、Process Guidesエンジンを使うprocess_guide設定が選べると書かれています。KBの新設を誰でも申請できる状態のままにするか、承認者を挟むかは、この1件で切り替えられます。

記事の取り込み（Import）にも上限があります。glide.knowman.import.max_document_sizeは既定30MBで、glide.knowman.import.uncompressed_max_document_size（docx展開後の上限）は既定100MBでした。マニュアルPDFや画像を多く含む文書を一括取り込みする運用では、上限に達していないかを事前に確認します。

glide.knowman.ownership_group.enabledも既定でfalseですが、説明文に運用上の注意が書かれていました。

（訳: ナレッジ記事にオーナーシップグループを有効にする。注記: このプロパティを有効化したあとは、無効化を推奨しない）

引用元: /sys_properties_list.do?sysparm_query=name=glide.knowman.ownership_group.enabled

一度有効にすると元に戻さない前提の設定です。組織変更の予定がある場合は、有効化する前に運用側と合意しておきます。

バージョニングに関連するプロパティ

記事の版数管理は3件のプロパティで制御されています。

プロパティ既定値何を決めるかglide.knowman.versioning.enabledtrue版数管理そのものを使うかglide.knowman.versioning.enable_minor_editsfalse公開済み記事を新版を作らずに軽微修正できるかglide.knowman.versioning.minor_edit_fieldsvalid_to軽微修正の対象にできる項目

enable_minor_editsは既定でfalseのため、公開済み記事を直すと基本的に新しい版が作られます。誤字修正のたびに版が増える運用が負担なら、enable_minor_editsを有効にし、対象項目をminor_edit_fieldsに追加する選択があります。既定で軽微修正の対象になっているのはvalid_to（有効期限）1項目だけで、本文（text・wiki）は含まれていません。本文の細かな修正まで版を増やさずに済ませたい場合は、この一覧に本文の項目を加えるかどうかを検討します。ただし版の履歴が粗くなる副作用も伴うため、変更履歴を厳密に残したい記事群では既定のままにする判断もあります。

アクセス制御に関連するプロパティ

誰が記事を読め、誰が投稿できるかの判定に関わるプロパティは7件です。

もっとも影響が大きいのはglide.knowman.block_access_with_no_user_criteriaで、既定はtrueです。

（訳: Can ReadまたはCan ContributeのUser Criteriaリストが指定されていないKnowledge Baseへのアクセスを拒否する）

引用元: /sys_properties_list.do?sysparm_query=name=glide.knowman.block_access_with_no_user_criteria

Can Read・Can Contributeどちらか一方でも未指定のKBは、この既定値のもとで拒否対象になります。実際にKB5件がこの条件をどう満たしているかを確かめました。

Can Read側の中間テーブル（kb_uc_can_read_mtom）に登場するのはKnowledge・IT・Known Errorの3KBだけです。Governance, Risk, and ComplianceとKCS Knowledge Base (demo data)は現れません。Can Contribute側にはGRCが1件だけ加わりますが、値は空欄でした。KCS Knowledge Baseは両方の中間テーブルに1件も現れず、記事8件を抱えるKBとして条件に最も近い状態でした。

実際に別ユーザーでログインしてアクセス可否を確認する検証は行っていません。この事実は「プロパティの既定値」と「中間テーブルの実測」を突き合わせた結果であり、断定はできません。ただし、KBを新設したらkb_uc_can_read_mtom・kb_uc_can_contribute_mtomの両方に最低1件ずつ登録する運用にしておくと、この既定値による意図しないアクセス拒否を避けられます。

• 参考：Employee Centerの出し分け設定（User Criteria） … User Criteriaの基本的な使われ方

Service PortalとKnowledge Centerに関連するプロパティ

ポータル側の設定は9件あります。

プロパティ既定値何を決めるかsn_km_portal.glide.knowman.serviceportal.portal_urlkbナレッジ用ポータルのURL接尾辞sn_km_portal.glide.knowman.serviceportal.enable_redirectfalse旧ページへのアクセスをService Portal UIへ転送するかsn_km_center.glide.knowman.enabletrueKnowledge Center（新UI）を全体で有効にするかsn_km_center.glide.knowman.ece.enabletrue高機能エディタ（Enhanced Content Editor）を使うかsn_km_center.glide.knowman.redirect.enabletrueKnowledge Centerへ自動転送するか

sn_km_center.glide.knowman.enableが既定でtrueのため、この環境ではClassic UIより新しいKnowledge Centerの体験が標準で有効になっています。URLの接尾辞（既定kb）を変えると、既存のブックマークやリンクに影響するため、変更は事前告知を伴います。

（訳: ナレッジ管理のService Portalが配置されているポータルのURL接尾辞。既定は「kb」）

引用元: /sys_properties_list.do?sysparm_query=name=sn_km_portal.glide.knowman.serviceportal.portal_url

複数のポータルを運用し、ナレッジ用ポータルを別のURLに割り当てたい場合は、まずポータルレコード自体を作成してから、この値をそのポータルのURL接尾辞に合わせます。値を先に変えてもポータルが存在しなければ、リンク切れになります。

• 参考：Service Portalを構成する7テーブル … ポータル側の基本構造

• 参考：Knowledge Portal（/kb）の「45 Articles」はどこから来るか … ポータル画面に出る件数表示の出どころ

その他の機能が使うプロパティ

残る26件は、Problem連携・タクソノミー・AQI（記事品質評価）・購読機能など、個別の周辺機能が使うプロパティです。

プロパティ既定値何のためのものかproblem.knowledgebase.known_error_articleKBのsys_idProblem管理からKnown Error記事を作成する先のKBを指定するglide.knowman.aqi_pass_score70AQI（記事品質評価）の合格点glide.knowman.enable_km_subscriptiontrue記事の更新をユーザーが購読できるようにするかglide.knowman.enable_article_expiry_notificationfalse有効期限が近い記事の通知を毎月送るかcom.glide.cs.portal_url_mapping.portal.kb_knowledgesp非推奨。後継設定へ移行済みcom.glide.cs.portal_url_mapping._default.kb_knowledgeURLテンプレート非推奨。後継設定へ移行済み

最後の2件は、説明文にDEPRECATED（非推奨）と明記されたまま、レコードとしては削除されずに残っています。値も設定されたままです。棚卸しでは、非推奨の注記があるプロパティを見つけても、レコードの存在だけで「使われている」と判断しないようにします。

glide.knowman.aqi_pass_score（既定70点）は、AQIレビューの合格ラインです。

（訳: AQIレビューの合格点）

引用元: /sys_properties_list.do?sysparm_query=name=glide.knowman.aqi_pass_score

AQIは記事の品質を人手または自動で採点する仕組みで、この値を下回った記事は改善が必要と判定されます。基準を厳しくするほど改善対象は増えるため、レビュー担当の体制と合わせて数値を決めます。

Problem連携のproblem.knowledgebase.known_error_articleは、Problemレコードから「Known Error」記事を作成するときの作成先KBを、値にsys_idで指定します。空欄のままだと作成先が定まらないため、Problem管理からのナレッジ化を運用に組み込む前に、値が自社のKnowledge Baseを指しているかを確認します。

• 参考：ナレッジ管理（Knowledge）完全ガイド … Known Error連携を含む全体の地図

プロパティを変更する前の確認事項

122件のうち、実際に触る機会が多いものを整理しました。

変更前に確認する点は3つです。

1. 説明文を読む：119件に公式説明があります。値の意味を推測で決めません

2. 接頭辞を絞りすぎない：glide.knowmanのように、テーブル名から類推できない接頭辞があります

3. User Criteriaとの組み合わせ：アクセス制御系のプロパティは、User Criteriaの登録状況とあわせて確認します

実機で気づいたこと

プロパティ名の推測が接頭辞のところで外れた

テーブル名kb_knowledgeから、プロパティの接頭辞もglide.knowledgeだろうと想定して検索し、0件という結果に行き当たりました。実際の接頭辞はglide.knowmanです。

ServiceNowの内部コード名と、ユーザーに見える画面上の名称が一致しない例は他のモジュールにもあります。プロパティを棚卸しするときは、テーブル名からの類推だけに頼らず、descriptionに含まれるキーワードからも検索する習慣が有効です。今回はnameLIKEfeedbackのように機能語で検索したところ、接頭辞に関係なく該当プロパティを見つけられました。

KCS Knowledge BaseだけUser Criteriaが1件も無い

5件あるKnowledge Baseのうち、Can Read・Can Contributeどちらの中間テーブルにも1件も登録がありませんでした。該当するのはKCS Knowledge Base (demo data)だけです。他の4KBは、少なくとも一方には登録があります。

デモ環境の特性である可能性はありますが、block_access_with_no_user_criteriaが既定でtrueである以上、この状態のままではアクセス判定に影響し得ます。自社でKBを新設する手順には、User Criteriaの登録を必須のチェック項目として組み込むのが安全です。

非推奨のプロパティが値を保持したまま残っている

com.glide.cs.portal_url_mapping.*の2件は、説明文で明確に非推奨と告知されているにもかかわらず、値を保持したレコードとして存在し続けていました。

非推奨のアナウンスと、実際のレコード削除は別のタイミングで行われることが分かります。棚卸しスクリプトを書く際は、descriptionにDEPRECATEDを含むプロパティを別枠で抽出し、後継の設定へ移行済みかを個別に確認します。

プロパティ調整の検討順序

プロパティを調整するとき、確認する順序を決めておくと迷いません。

1. 接頭辞を決め打ちしない：glide.knowmanなど、テーブル名と一致しない接頭辞を疑う

2. 説明文を読む：119件に公式説明がある。値を変える前に意図を確認する

3. 検索結果の並び順・件数：order.search・search.rowcountを自社の運用に合わせる

4. フィードバックのタスク化条件：enable_actionable_feedback_for_ratingを有効にするか決める

5. 投稿ワークフローの要否：submission.workflowをレビュー体制に合わせて決める

6. User Criteriaの登録状況：block_access_with_no_user_criteriaの対象になっていないかを全KBで確認する

7. オーナーシップグループ：ownership_group.enabledは有効化後の無効化が非推奨である点を踏まえて判断する

8. 非推奨プロパティの扱い：DEPRECATEDの注記があるものは後継設定への移行を確認する

用語

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

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

• AQI：Article Quality Index。記事の品質を採点する仕組み

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

• Knowledge Center：ナレッジ管理の新しい執筆・管理体験（従来のClassic UIの後継）

検証範囲とおことわり

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

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

• プロパティの値を実際に変更して挙動が変わることは確認していません

• KCS Knowledge Baseのアクセス可否について、別ユーザーでログインして拒否を再現する検証は行っていません

• AQI・購読機能・Knowledge Centerなど周辺機能の詳細な動作は、本シリーズの後続の巻で扱います

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

• ナレッジ関連プロパティ全体：/sys_properties_list.do?sysparm_query=nameLIKEknowledge^ORnameLIKEglide.knowman^ORnameLIKEkb.

• knowmanプレフィクスのみ：/sys_properties_list.do?sysparm_query=nameLIKEglide.knowman

• 検索に関連するもの：/sys_properties_list.do?sysparm_query=nameLIKEglide.knowman.search

• フィードバックに関連するもの：/sys_properties_list.do?sysparm_query=nameLIKEfeedback

• アクセス制御の中心プロパティ：/sys_properties_list.do?sysparm_query=name=glide.knowman.block_access_with_no_user_criteria

• 誰がKBに投稿できるか：/kb_uc_can_contribute_mtom_list.do

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

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

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEglide.knowman^descriptionISNOTEMPTY

関連記事

• ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … Knowledge Base・Category・公開範囲を含む全体の地図

• システムプロパティ（sys_properties）は設定値の置き場 … プロパティそのものの扱い方

• インシデント管理モジュールのプロパティ … 同じ切り口で調べた別モジュール