ナレッジ管理モジュールのロール

「knowledgeロールを付けたのに、この記事だけ投稿できない」という相談は、ロールを足すだけでは解決しません。ナレッジ管理ではACLのロール要件がかなりゆるく、実際の可否はUser Criteriaとスクリプトが握っているためです。Australia PDIをデフォルト設定のまま開き、8つのロールと、565件のACLがどう可否を決めているかを確かめました。

調べる順序

• ロールの一覧と、包含関係

• ACLが実際に何を判定材料にしているか

• 見えない・書けないときに、どこから確認するか

要点

• ナレッジ系ロールは8つあり、itilはそのうち1つも自動継承しない

• kb_knowledge本体のACLはcreate/delete/writeがsnc_internal、readはpublicで、ロール要件だけを見ると内部ユーザー全員が触れるように見える

• 実際の可否はUser Criteria10件とscript ACL183件（全体の32%）が握っており、ロールを足しても解決しないことがある

どの役割に、どのロールを付与するか

先に、実務の役割とロールの対応を1枚で示します。閲覧者には追加のロールを付けず、記事を書く担当者にはknowledge、KBの公開判断をする管理者にはknowledge_adminかknowledge_manager、システム全体を見る管理者にはadminを足す構成が基本形です。

knowledgeロールを持っていても、投稿できるKBはUser Criteriaが別途決めます。この対応がなぜ成り立つのかを、ロールの定義とACLの実測で確かめていきます。

ナレッジ管理に関わるロール

sys_user_roleをnameLIKEknowledgeで検索すると8件でした。kb_プレフィクスのロールは0件です。

8件すべてに公式説明（description）が付いています。役割ごとの守備範囲を整理します。

knowledgeの公式説明を引用します。

（訳: ナレッジ管理の記事を書き、編集し、レビューできる）

引用元: /sys_user_role_list.do?sysparm_query=name=knowledge

knowledge_managerの説明はもう一段具体的です。

（訳: Knowledge Baseを管理でき、新規のKnowledge Baseをknowledge_adminの承認向けに申請できる）

knowledge_adminが承認する側、knowledge_managerは申請する側という上下関係が、説明文からそのまま読み取れます。

knowledge_view_asの説明も実務的です。

（訳: 他のユーザーとして記事を検索・閲覧できる）

このロールを使うと、Impersonate Userで完全に切り替えなくても、指定したユーザー視点での検索結果を確認できます。「あのユーザーにこの記事が見えているか」を切り分けるとき、User Criteriaの設定を推測するより、knowledge_view_asを持つ担当者に実際の見え方を確認してもらうほうが早く決着します。ただしOOTBではこのロールを持つ担当者が0件でした。使う場合は先に誰かへ付与しておく必要があります。

• 参考：ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる … 誰にどのロールが付いているかはここで追える

ロールの包含関係

sys_user_role_containsでknowledge系ロールの包含を展開すると、次の階層が現れます。

knowledge_admin・knowledge_coach・knowledge_domain_expert・knowledge_managerと、knowledge_group_manager経由のknowledge_group_memberは、いずれも基礎ロールknowledgeを自動的に含みます。knowledge自身はcanvas_user（Canvas利用）とactsub_user（アクション購読）を含んでいます。

意外な1件がありました。Continuous Improvement Management（CIM）のsn_cim.improvement_coordinatorがknowledgeロールを自動継承しています。改善提案の担当者に、記事の執筆権限が最初から付いている設計です。

knowledge_view_asだけは含む・含まれるの関係を1件も持たない単独ロールでした。

itilはナレッジ系ロールを1つも含まない

itilロールの包含関係を直接確認すると、ナレッジ系ロールは1件もヒットしませんでした。

Problem管理のitilはsn_problem_writeを自動的に含み、書き込み権限が最初から付きます。ナレッジ管理はこの構図と異なります。itilを持つ担当者であっても、knowledge系ロールを個別に付与されない限り、記事の執筆・管理権限は持てません。

• 参考：ServiceNowで付けたロールが想定外の権限を含んでいた理由 sys_user_role_containsで包含を実機でたどる … itilが実際に何を含むかを再帰的に数えた記事

誰が実際にknowledgeロールを持っているか

sys_user_has_roleでknowledge系ロールの割り当てを数えると、8ロール中3ロールにしか誰も割り当てられていませんでした。

• knowledge：20件（直接付与6・継承14）

• knowledge_manager：5件

• knowledge_admin：2件

• 残る5ロール（coach／domain_expert／group_manager／group_member／view_as）：いずれも0件

グループへのロール付与（sys_group_has_role）も0件です。ナレッジの執筆・管理権限は、少人数の個人へ直接付与する運用になっています。

割り当てを持つ担当者が少ないという事実は、次の疑問につながります。残りの大多数の内部ユーザーは、ロールなしでどこまで記事に触れるのでしょうか。ここからACLの実測に入ります。

• 参考：ユーザー（sys_user）は1行＝1人 … 割り当て先となるユーザーテーブル

kb_knowledge本体のACLはロール要件だけを見るとゆるい

kb_knowledge本体のテーブル単位ACLは12件でした。

ロール（role欄）とスクリプトの有無、admin_overridesをまとめます。

role欄だけを追うと、create・delete・writeはsnc_internal（内部ユーザー全員が持つ基礎ロール）、readはpublic（未ログインでも可）です。ロール名から想像すると、内部ユーザーなら誰でも記事を作成・更新・削除でき、閲覧はログインすら不要に見えます。

ここで止まると誤読します。12件中10件にはrole欄と同時にスクリプトが付いているためです。role要件を満たしても、スクリプトの判定を通らなければ実行できません。

例外はquery_rangeの1件で、roleもscriptも付いていませんでした。query_rangeは一覧の絞り込みや参照フィールドの候補表示で使われる操作です。記事本体の閲覧可否とは別枠で、常に許可される設計だと分かります。この1件だけ「ロールもスクリプトも見なくてよい」という判断になります。

ロールはACLのrole欄ではなくスクリプトの中に隠れている

kb_knowledgeのread ACLの1つを開くと、次のスクリプトが書かれていました。

gs.hasRole("knowledge") || gs.hasRole(current.roles) || current.roles == "public" || current.roles == "";

読み下すと「knowledgeロールを持つ」または「記事のroles欄に指定されたロールを持つ」または「記事のroles欄がpublicか空」なら読める、です。current.rolesは記事1件ごとに閲覧ロールを指定できる項目（kb_knowledge.roles）で、公式説明は次のとおりです。

（訳: 記事の閲覧・検索を許可するロール。空の場合、すべてのユーザーが閲覧できる）

引用元: /sys_documentation_list.do?sysparm_query=name=kb_knowledge^element=roles

knowledgeロールの実際の力は、ACLの role欄ではなくスクリプトの中のgs.hasRole("knowledge")に潜っています。同じ書き方はkb_article_checklist_summaryなど複数のACLで見つかり、knowledge_adminも同様にスクリプト内で判定されています。ACLのrole欄だけを一覧しても、knowledge系ロールの本当の効き方は分かりません。

このread ACLにはkb_knowledge_base.kb_version=2（旧UI限定）という条件も付いています。KB Version3（Flow Designerへ移行した新UI）では、KBScopedKnowledgeSNCという別のScript Includeが判定を引き継ぎます。同じ「読める・読めない」の判定が、KBのバージョンによって別のコードで動いている構成です。

ACL565件のうち32%がスクリプトで判定している

nameLIKEkb_とnameLIKEknowledgeで拾える有効ACLを合算・重複除去すると565件でした。うちスクリプトを持つものは183件、全体の32%です。

operation件数write137read116query_range96create87delete78report_view27list_edit10conditional_table_query_range9execute4save_as_template1

同じ切り口で調べたProblem管理はスクリプトの比率が9%（13/146件）でした。ナレッジ管理はProblem管理の3倍以上、条件分岐をスクリプトに寄せています。

kb_feedback_task（フィードバック対応タスク）のcreate ACLは、単純なロールチェックだけでした。

gs.hasRole("itil", "sn_incident_write");

同じテーブルのread ACLは、1つのスクリプトに4段階の分岐を持っています。

1. 担当者または起票者なら許可

2. 記事へのコントリビュート権（SNC.KnowledgeHelper().canContribute()）があれば許可

3. 親タスクを読めれば許可

4. デマンド由来のタスクかつadminなら許可

単純なロールチェックのACLと、複数条件を跨ぐACLが同じテーブルに混在しています。1件目を直しても解決しないときは、同じoperationにもう1件別のACLが無いかを確認します。

kb_knowledge_baseのACLにも、kb_knowledge本体と同じ構図があります。KBKnowledgeBase().canCreate()（グローバルスコープ向け）とKBScopedKnowledgeSNC().canCreateKnowledgeBase()（スコープ済みアプリ向け）という2本のスクリプトが、create・read・write・deleteそれぞれに並んでいました。テーブル単位ACLのrole欄を見ると、この2本とは別にreport_viewがknowledge_manager／knowledge_adminに、もう1件sn_hr_sp.esc_adminにも紐付いています。report_viewはKBの利用状況レポートを見る操作で、記事の読み書きとは別枠の権限です。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの基本的な読み方

誰が読めて誰が投稿できるかはUser Criteriaが決める

ACLのrole欄がゆるい代わりに、KB単位の可視性・投稿可否はuser_criteriaという別の仕組みに委ねられています。ナレッジではこの中間テーブルが4つに分かれています。

テーブル件数代表内容kb_uc_can_read_mtom5Knowledge KB×「KBの全ユーザー」／IT KB×「Problem AnalyzersグループとProblem Solvingグループのメンバー」ほかkb_uc_can_contribute_mtom4Knowledge KB×「knowledgeロールを持つユーザー」／Known Error KB×「itilロールを持つユーザー」ほかkb_uc_cannot_read_mtom1Knowledge KB×「ゲストユーザー」kb_uc_cannot_contribute_mtom0（レコードなし）

kb_knowledge_base・kb_category自体は可視性を示すフィールドを持ちません。個別の記事（kb_knowledge）だけがcan_read_user_criteria／cannot_read_user_criteriaを持ち、KB単位の設定を記事1件だけ上書きできます。KB単位の既定値と、記事単位の例外という二重構造です。

この中間テーブル自体を書き換える権限も、script ACLで絞られています。4テーブルともnew KnowledgeAccess().managerRights(current.kb_knowledge_base);という同じ判定が使われており、そのKnowledge Baseの管理権限を持つ人だけが、誰が読めるか・書けるかの割り当てを変更できます。棚卸しの権限が、記事を書く権限とは別に閉じている設計です。

Known Error KBのkb_uc_can_contribute_mtomには「itilロールを持つユーザー」という条件が入っていました。itilロールはknowledge系ロールを1つも自動継承しません。それでもitil担当者がKnown Error KBへ投稿できるのは、ロールの包含関係ではなくUser Criteriaで個別に許可されているためです。ロールの継承だけを調べても、この経路は見つかりません。

AQI（記事品質評価）の採点結果を持つkb_article_checklist_summary・kb_article_checklist_answerにもscript ACLがあり、レビュアー本人かknowledge_adminだけが編集・削除できる作りでした。knowledge_coach・knowledge_domain_expertはAQI採点のための専用ロールですが、実際の割り当ては0件でした。仕組みは用意されていても、まだ稼働させていない機能だと分かります。

Knowledge Base本体（kb_knowledge_base）にはkb_managersというグループ管理用の項目がありますが、5件のKBすべてで未設定でした。管理権限は個人1名のownerフィールドだけに依存しています。owner担当者が異動・退職すると、そのKBを管理できる人が一時的にいなくなる構成です。グループをkb_managersへ設定しておけば、個人に依存しない引き継ぎができます。

• 参考：ServiceNowのEmployee Centerでコンテンツはどう出し分けられる？ トピックへの紐付けとUser Criteriaを実機で確認 … User Criteriaの基本的な使われ方

「うちのナレッジが見えない・編集できない」ときの調べる順序

ここまでの実測を踏まえると、ロールから調べ始めるのは非効率です。ACLのrole要件はsnc_internal・publicとゆるく、そこを見ても答えに辿り着きません。

1. User Criteriaを見る：そのKBのkb_uc_can_read_mtom／kb_uc_can_contribute_mtomに対象者が含まれているか

2. ACLのscriptを見る：記事のroles欄やworkflow_stateの条件に阻まれていないか

3. 最後にロールを見る：knowledge系ロールの付与有無

「見えないならknowledgeロールを足す」という対応から入ると、User Criteriaで除外されている場合に解決しません。反対に「投稿できないからknowledge_adminまで付ける」という過剰な対応も、User Criteriaの範囲を直せば不要な場合があります。

• 参考：Access Analyzer：「見えない」の理由を層で切り分ける … 判定の層を順に確認する道具

実機で気づいたこと

ロールの役割欄とスクリプトが同じ操作に2重に付く

kb_knowledgeのcreate・read・writeには、それぞれKBKnowledge系とKBScopedKnowledgeSNC系の2本のスクリプトが並んでいました。おそらく、Classic UI経由のアクセスとスコープ済みアプリ（Service Portal・CSM等）経由のアクセスを、別のScript Includeで判定しているためです。

権限の調査で「1つのACLを直しても直らない」ときは、同じoperationにもう1件別のACLが存在していないかを疑います。kb_knowledge・kb_knowledge_baseとも、create/read/writeはほぼ確実に2件セットです。

knowledgeロールの効き方はACLの一覧画面からは見えない

sys_security_acl_role（ACLとロールの対応表）だけを見ると、knowledge系ロールはreport_view（レポート閲覧）にしか直接紐付いていません。ところがACLのscriptを1件ずつ開くと、gs.hasRole("knowledge")やgs.hasRole("knowledge_admin")が複数のACLの中で使われていました。

ロールとACLの対応を調べるとき、sys_security_acl_roleの一覧だけで「このロールはここにしか効かない」と判断すると読み違えます。scriptを持つACLは、中身まで開かないとロールとの関係が分かりません。

8ロール中5つは誰にも割り当てられていない

sys_user_has_roleを数えると、実際に割り当てられているのはknowledge・knowledge_manager・knowledge_adminの3ロールだけでした。knowledge_coach・knowledge_domain_expert・knowledge_group_manager・knowledge_group_member・knowledge_view_asは0件です。

デモ環境の特性もありますが、AQI（記事品質評価）やグループ管理、他ユーザーとしての閲覧といった機能は、標準搭載されていても実際には使われていない可能性を示しています。自社で導入するときは、この5ロールが自社の運用に必要かどうかを最初に判断します。不要なら、権限設計から外して構いません。

itilがKnown Errorに投稿できるのはロールではなくUser Criteria経由

itilはknowledge系ロールを1件も含みません。それでもKnown Error KBのkb_uc_can_contribute_mtomには「itilロールを持つユーザー」という条件が個別に登録されていました。

ロールの包含関係を調べる調査だけでは、この経路にたどり着けません。「itilを持つ担当者がKnown Errorへ投稿できている、なぜだろう」という疑問が出たら、ロールの上位下位ではなくUser Criteriaを先に確認します。Problem管理からKnown Error記事を自動生成する連携（problem.knowledgebase.known_error_article）を実装した設計者が、投稿元になるitil担当者へ執筆権を渡す手段として、あえてこの経路を選んだと考えられます。

自社で同じ設計を真似るときも、この順序が参考になります。特定の既存ロールにナレッジの投稿権だけを追加したいなら、対象KBのUser Criteriaへその条件を1行足すだけで済みます。ロールの包含関係はそのままにでき、影響範囲を他のモジュールへ広げずに済む設計です。

実務で順番に検討する箇所

権限を設計するとき、確認する順序を決めておくと迷いません。次の表は、ここまでの実測から導いた8つの決定項目です。role欄が緩いテーブルほど、User Criteriaと記事単位のroles欄で絞り込む前提で設計します。

1. 執筆権限の範囲：knowledgeを全社員に配るか、部門ごとに絞るか

2. KB単位の閲覧範囲：kb_uc_can_read_mtomの対象を部署・全社・特定グループのどれにするか

3. KB単位の投稿範囲：kb_uc_can_contribute_mtomをロール条件にするか組織条件にするか

4. 記事単位の上書き：kb_knowledgeのroles欄・can_read_user_criteriaで個別記事だけ絞るか

5. KB管理者の人選：knowledge_admin（全KB）とknowledge_manager（申請・管理）のどちらを配るか

6. kb_managersグループの利用：個人のowner1名運用か、グループ管理に変えるか

7. Known Error連携の作成先：problem.knowledgebase.known_error_articleの向き先KBを固定するか

8. 調査の入口：「見えない」報告への確認順序を、User Criteria→ACL→ロールに統一するか

用語

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

• ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則

• snc_internal：ServiceNowにログインできるユーザー全員が持つ基本ロール

• script ACL（advanced ACL）：条件式ではなくJavaScriptで可否を判定するACL

• admin_overrides：adminロールが条件を無視して通れるかどうかの設定

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

検証範囲とおことわり

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

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

• KBKnowledge／KBScopedKnowledgeSNC／KnowledgeAccess各Script Includeの全文までは追っていません

• user_criteriaテーブル自体の判定ロジック（conditionスクリプト）は確認していません

• 実際に別ユーザーでログインして拒否を再現する検証は行っていません

• kb_feedback_taskなど周辺テーブルのACLは代表例のみを扱っています。全件の精読は今後の巻に持ち越します

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

• ナレッジ関連のロール：/sys_user_role_list.do?sysparm_query=nameLIKEknowledge

• ロールの包含関係：/sys_user_role_contains_list.do?sysparm_query=role.nameLIKEknowledge

• itilがナレッジを含まないことの確認：/sys_user_role_contains_list.do?sysparm_query=role.name=itil^contains.nameLIKEknowledge

• kb_knowledge本体のACL：/sys_security_acl_list.do?sysparm_query=name=kb_knowledge^active=true

• ACLとロールの対応：/sys_security_acl_role_list.do?sysparm_query=sys_security_acl.name=kb_knowledge^sys_security_acl.active=true

• User Criteria（誰が読めるか）：/kb_uc_can_read_mtom_list.do

• User Criteria（誰が投稿できるか）：/kb_uc_can_contribute_mtom_list.do

• 誰がロールを持っているか：/sys_user_has_role_list.do?sysparm_query=role.name=knowledge

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

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

• ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameLIKEknowledge

• rolesフィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=kb_knowledge^element=roles

関連記事

• ナレッジの本棚と分類（kb_knowledge_base） … kb_knowledge_base・kb_categoryの詳しい構造

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

• ServiceNowでadminを配らずに開発させるには？ Delegated Developmentで権限を絞る … admin以外に権限を絞る別の設計パターン