記事の評価はどこに溜まるか（kb_feedback）
ServiceNow のナレッジ記事には、星評価や「役に立った／立たなかった」、コメント、内容への問題報告（フラグ）がつきます。記事フォームに表示される平均評価や Helpful の数字は、どこから来ているのでしょうか。実は記事テーブル（kb_knowledge）が自分で持っているのではなく、kb_feedback という別テーブルに1件ずつたまった評価を、保存時に集計して記事側へ書き戻しています。
この記事では、評価やコメントを記録する kb_feedback と、閲覧・利用ログを記録する kb_use を、PDI の実機で確認します。どんなフィールドを持つか、フラグの理由はどう選ぶか、19 件の実フィードバックがどの記事についているか、そして評価が記事の rating や helpful_count にどう反映されるかを、実レコードと Business Rule の一覧で追います。
ServiceNow の Incident は触ったことがあり、ナレッジの記事テーブル（kb_knowledge）の構造は把握したが、評価や利用記録がどのデータで動いているかをこれから確認したい管理者・開発者を想定しています。
この記事で分かること
記事評価が kb_knowledge ではなく kb_feedback に1件ずつ記録されること
フィードバックの4種類（useful / rating / flagged / comments）とフラグ理由の選択肢
kb_feedback の評価が Business Rule で記事の rating・helpful_count・flagged へ集計される流れ
閲覧・利用ログを記録する kb_use のフィールドと、OOTB では空であること
実機で評価・利用記録を確認するときに見る一覧URL
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、リリース・アップグレード経路・導入済みプラグイン・Knowledge Base の設定によって、フィールドや挙動が異なる場合があります。
ナレッジのフィードバックと利用記録とは
ナレッジ記事は、書いて公開したら終わりではなく、読まれて評価されて改善されます。ServiceNow はその「評価」と「利用」を、記事本体とは別のテーブルに記録します。評価・コメント・問題報告は kb_feedback（Knowledge Feedback）、誰がいつ記事を閲覧・利用したかは kb_use（Knowledge Use） です。
記事1件に対してフィードバックは何件もつくので、kb_feedback の1行は「1人の1回の評価」を表します。kb_use も同様に、1行が「1回の閲覧・利用」を表します。記事側（kb_knowledge）は、これらを集計した結果（平均評価、Helpful の数、閲覧回数）だけを持ちます。集計のもとになる生データが、この2つのテーブルに残ります。
kb_feedback と kb_use は、記事テーブル kb_knowledge と同じく、task を継承しない独立したテーブルです。今回確認した PDI では、どちらも super_class（継承元）が空でした。記事の周辺データを保持する記録テーブルとして、それぞれ独立して定義されています。
公式の Provide feedback on knowledge articles（Zurich） には、利用者が記事をフラグ・評価・Helpful 判定できること、フィードバックとフィードバックタスクの関係の説明があります。
フィードバックの4つの形（kb_feedback）
利用者が記事に返せるフィードバックは、おおまかに4つの形をとります。役に立ったかの2択（useful）、点数（rating）、問題の報告（flagged ＋ reason）、自由なコメント（comments）です。どれも kb_feedback の1レコードに記録されます。
PDI Zurich の OOTB では、kb_feedback は固有の 26 フィールドを持っていました。継承がないため、この 26 がすべて kb_feedback 自身の定義です。記録の中心になるフィールドは次のとおりです。
article（Article）は評価対象の記事への参照（Reference → kb_knowledge）です。これによって、1つの記事に複数のフィードバックがぶら下がります。useful は Yes / No の2択、rating は数値の点数、flagged は内容に問題ありの旗、comments は自由記述です。
フラグや「役に立たなかった（useful=No）」を選んだとき、その理由を選ぶのが reason です。OOTB では4種類が用意されていました。
Value Label（理由）
--------------------
1 The article is incomplete（記事が不完全）
2 The article contains incorrect information（内容が不正確）
3 The article is unclear（分かりにくい）
4 Other（その他）rating には選択肢（choice）の定義がなく、数値をそのまま保持します。範囲外の値は Business Rule「Abort ratings insert when out of bounds」が保存時に弾く作りになっていました。星評価の上限・下限は、選択肢ではなくこのルールで守られます。
選択肢の定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/sys_choice_list.do?sysparm_query=name=kb_feedback^element=reason^inactive=false^ORDERBYsequence実機のフィードバック19件を見る
PDI のデモデータには、kb_feedback が 19 件入っていました。一覧を開くと、どの記事にどんなコメントがついているかが並びます。
下部のページャに「1 to 10 of 19」と出ており、件数は REST API で数えた 19 件と一致します。フィードバックがついていた記事は KB0000005 / KB0000006 / KB0000008 / KB0000009 / KB0000028 / KB0005010 の6記事で、Excel の使い方や VPN 設定、フィッシング解説などの記事にコメントがついていました。
一覧の下に「Number of rows removed from this list by Security constraints」と表示される場合があります。これは ACL（アクセス制御）によって、ログインユーザーに見えないフィードバックが一覧から除かれているという意味です。フィードバックの中には自分宛・特定ロール向けのものがあり、誰でも全件見えるわけではありません。
内訳を REST で数えると、flagged=true（問題報告あり）が3件、useful=Yes（役に立った）が4件、useful=No が1件、rating（点数）が入っているものが5件でした。フラグ理由は Other（reason=4）が1件で、定型理由（不完全・不正確・分かりにくい）を選んだものは今回のデモデータにはありませんでした。
なお、フラグだけをかけた一覧をユーザー権限で開くと、ACL で絞られて1件だけ表示されることがあります。REST（管理者相当の読み取り）で数えた3件と、画面に出る件数が食い違うのは、この閲覧制御によるものです。
評価が記事に反映される流れ
kb_feedback に1件ずつたまった評価は、そのままでは記事フォームに出ません。記事側（kb_knowledge）の rating（平均評価）・helpful_count（役に立った数）・flagged（問題ありの旗）へ書き戻す処理が、kb_feedback の Business Rule として動きます。
PDI Zurich の OOTB では、kb_feedback に active な Business Rule が 12 件ありました。一覧を見ると、集計や記事への反映を担うルールが並びます。
役割が分かりやすいものを挙げると、Calculate Article Rating は rating を集計して記事の平均評価へ、Populate Helpful Count は useful=Yes を数えて helpful_count へ、Set Flagged Status は flagged を記事側へ反映します。Calculate Rating on Delete はフィードバックを消したときに平均を計算し直します。Abort ratings insert when out of bounds は範囲外の点数を弾きます。
もう1つ重要なのが Knowledge Feedback Task Creation です。記事にフラグが立つと、このルールがフィードバックタスク（kb_feedback_task）を起票します。フラグは「問題があると報告された」という事実だけでなく、誰かが対応すべき作業として残ります。フィードバックタスクは kb_feedback とは別のテーブルで、評価そのものとは分けて管理されます。
公式の Configure feedback task properties（Zurich） には、星評価がいくつ以下でタスクを作るか（しきい値）など、フィードバックタスクを生成する条件を設定できることの説明があります。
active な Business Rule は、次のURLで確認できます。
https://<YourInstance>/sys_script_list.do?sysparm_query=collection=kb_feedback^active=true閲覧・利用を記録する kb_use
kb_use（Knowledge Use）は、記事が「読まれた」「使われた」ことを記録するテーブルです。kb_feedback が利用者の評価を残すのに対し、kb_use は記事へのアクセスそのものを残します。
主なフィールドは次のとおりです。固有 16 フィールドのうち、利用状況を表すのは viewed（閲覧したか）・used（インシデント等で実際に利用したか）・times_viewed（閲覧回数）です。
article（Reference → kb_knowledge）で対象の記事を指し、user で利用者を記録します。viewed は記事を開いたか、used は解決の場でその記事を実際に役立てたかを区別します。これらを記事ごとに集計したものが、記事側の sys_view_count（閲覧数）や use_count（利用数）になります。
今回確認した PDI では、kb_use は0件でした。OOTB のデモデータには評価（kb_feedback）は入っていましたが、閲覧・利用のログはまだ蓄積されていません。
kb_use の行は、ユーザーがポータルやプラットフォームで記事を開いたり、インシデント解決で記事を利用したときに増えます。実際にログが増える挙動は、今回のデータでは観測できなかったため検証範囲外とします。
公式の Article quality index for knowledge management（Zurich） には、閲覧数・評価・鮮度などから記事の品質指標を出す考え方の説明があります。kb_use と kb_feedback の集計が、記事の品質・人気を測る材料になります。
利用記録の一覧は、次のURLで確認できます。
https://<YourInstance>/kb_use_list.dokb_feedback / kb_use の周辺設定
2つのテーブルの動きは、フィールド定義だけでは決まりません。評価の集計、フラグからのタスク起票、コメントの無害化などは Business Rule が担い、権限は ACL が制御します。件数で全体像を押さえておきます。
kb_feedback は Business Rule が 12 件と多めで、これは評価の集計（rating / helpful_count / flagged）やタスク起票を保存時に処理するためです。一方 kb_use は Business Rule が2件と少なく、閲覧・利用回数のカウントと記事サマリへの反映が中心でした。どちらも Client Script や UI Policy は0件で、フォーム上のブラウザ側制御はほとんど持ちません。データを受けてサーバ側で集計する記録テーブル、という性格が件数にも表れています。
自分のインスタンスでは、次のURLで各一覧を開けます（先頭の <YourInstance> は置き換えてください）。
Feedback Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=kb_feedback^active=true
Use Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=kb_use^active=true
Feedback Dictionary : https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=kb_feedback^elementISNOTEMPTY
Use Dictionary : https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=kb_use^elementISNOTEMPTY実際のフィールド定義は、たとえば kb_feedback の辞書一覧をこのように確認できます。
ServiceNow におけるフィードバック・利用記録のポイント
記事の評価は記事テーブルではなく kb_feedback に1件ずつ記録 されます。useful（Yes/No）・rating（数値）・flagged（問題報告）・comments（自由記述）の4つの形をとり、フラグや低評価の理由は reason の4択（不完全 / 不正確 / 分かりにくい / その他）から選びます。
kb_feedback の評価は、保存時に Business Rule が集計して kb_knowledge へ書き戻し ます。Calculate Article Rating が平均評価、Populate Helpful Count が helpful_count、Set Flagged Status が flagged を反映します。記事フォームの数字の出どころはこの集計です。
フラグが立つと Knowledge Feedback Task Creation がフィードバックタスクを起票し、評価の記録と対応の作業が分かれて残ります。
kb_use は記事の閲覧（viewed）・利用（used）・閲覧回数（times_viewed）を記録し、sys_view_count / use_count の集計につながります。今回の PDI では0件で、実利用が発生していないため未蓄積でした。
一覧では ACL によって見えないフィードバックが除かれることがあります。REST で数えた全件数と画面の表示件数が食い違うのは、この閲覧制御によるものです。
評価・利用記録を調べるときは、kb_feedback と kb_use を単体で見るだけでなく、どの Business Rule が記事側の集計値を更新しているかをあわせて見ると、画面の数字とデータがつながって理解できます。
実機で気づいたこと
kb_feedback は19件あったのに対し、kb_use はOOTBのPDIで0件でした。同じ記事の周辺データを持つ隣同士のテーブルなのに、片方だけデモが入っている構成は意外でした。よく考えると、kb_feedback は管理画面で見せるサンプルとして作り込みやすい一方、kb_use は誰かがポータルで記事を開いたりインシデント解決で使ったりという操作の副産物なので、シナリオに組み込まない限り増えません。利用ログ系のテーブルが0件でも、それだけでは壊れているとは判断できないと分かりました。
flagged=true の件数を REST で数えると3件でしたが、ログインユーザーの権限で一覧を開くと1件しか表示されず、「Security constraints により行が除外されました」という注記が出ました。管理者相当で集計した件数と、実際にユーザーが見る一覧の件数がずれることがあるとは、実機を触るまで意識していませんでした。フィードバックの棚卸しをするときは、どの権限で数えたかをセットで書かないと、後で数字が合わなくなります。
kb_feedback には Business Rule が12件ある一方、Client Script と UI Policy はどちらも0件でした。フォーム上の見た目を操作するのではなく、保存された評価をサーバ側で集計して記事へ書き戻すだけの、一方通行の作りに見えます。フラグが立ったときも kb_feedback 自体を「対応中」のような状態には変えず、別テーブルの kb_feedback_task を新規に起票していました。評価という記録と対応という作業を、最初からテーブルレベルで分けている設計だと感じました。
次に読むなら
記事の置き場所・承認・閲覧範囲まで一望できるナレッジ管理完全ガイドも参考になります。記事テーブルそのものの構造（継承なし・workflow_state・公開設定）は、別記事「Knowledge だけ task 系でない（kb_knowledge）」で確認しています。フィードバックから起票されるフィードバックタスク（kb_feedback_task）の構造や、Knowledge Base 単位の品質・人気のレポートは、それぞれ別のテーマとして確認する予定です。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
ACL：Access Control（テーブル・項目レベルの権限）
フィードバックタスク：フラグや低評価から起票される対応用のタスク（kb_feedback_task）
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
Feedback 一覧 : kb_feedback_list.do
Use 一覧 : kb_use_list.do
Feedback フィールド : sys_dictionary_list.do?sysparm_query=name=kb_feedback^elementISNOTEMPTY
Use フィールド : sys_dictionary_list.do?sysparm_query=name=kb_use^elementISNOTEMPTY
reason の選択肢 : sys_choice_list.do?sysparm_query=name=kb_feedback^element=reason^inactive=false^ORDERBYsequence
Feedback Business Rule : sys_script_list.do?sysparm_query=collection=kb_feedback^active=trueテーブルの基本
kb_feedback ／ Label：Knowledge Feedback ／ Extends：なし（継承なし） ／ 固有フィールド 26
kb_use ／ Label：Knowledge Use ／ Extends：なし（継承なし） ／ 固有フィールド 16
どちらも task 系ではない。記事（kb_knowledge）の周辺データを保持する記録テーブル
kb_feedback の reason の値（Value → Label）
1 … The article is incomplete（記事が不完全）
2 … The article contains incorrect information（内容が不正確）
3 … The article is unclear（分かりにくい）
4 … Other（その他）
kb_feedback の useful の値
yes … Yes
no … No
rating は choice 定義なし（数値。範囲外は Business Rule で弾く）
レコード件数（OOTB・2026-06-22 確認）
kb_feedback … 19（flagged=true: 3 ／ useful=yes: 4 ／ useful=no: 1 ／ rating あり: 5 ／ reason=Other: 1）
kb_use … 0（viewed=true: 0 ／ used=true: 0。OOTB では未蓄積＝検証範囲外）
フィードバックがある記事（distinct）… KB0000005, KB0000006, KB0000008, KB0000009, KB0000028, KB0005010 の6記事
周辺設定の件数（OOTB・active 中心）
kb_feedback … Business Rules 12 ／ Client Scripts 0 ／ UI Policies 0 ／ UI Actions 3 ／ Notifications 0 ／ ACL（テーブル 9 ＋ 名前一致 45）／ Dictionary 26 ／ Choices 6
kb_use … Business Rules 2 ／ Client Scripts 0 ／ UI Policies 0 ／ UI Actions 0 ／ ACL（名前一致 7）／ Dictionary 16
kb_feedback の active な Business Rule（検索用）
Abort ratings insert when out of bounds, Calculate Article Rating, Calculate Rating on Delete, Populate Helpful Count, Set Flagged Status, Knowledge Feedback Task Creation, Set Resolved Checkbox, Set SessionID and User for Flag, Create Activity, Update Article Summary, Sanitise Malicious Comments, Update attachments on new kb feedback
kb_feedback / kb_use の主なフィールド（検索用）
kb_feedback: article, article_summary, useful, rating, flagged, reason, comments, work_notes, resolved, user, session_id, view_id, query, search_id, parent_comment, live_message, parent_feedback, root_feedback
kb_use: article, article_summary, user, viewed, used, times_viewed, session_id, search_id
関連テーブル（検索用）
kb_knowledge（Knowledge Article）, kb_knowledge_summary（Article Summary）, kb_feedback_task（Feedback Task）, sys_user（User）, ts_query_kb（Search）
検証範囲とおことわり
確認した範囲：kb_feedback / kb_use の継承関係（＝どちらも継承なし）、フィールド数と型、reason / useful の選択肢、kb_feedback の件数（19）と内訳、kb_use の件数（0）、kb_feedback の active な Business Rule 名、周辺設定の件数と物理テーブル名、kb_feedback.article / kb_use.article による kb_knowledge への参照。すべて PDI（Zurich / 2026-06-22 確認）の OOTB で取得しています。
確認していない範囲（断定しません）：各 Business Rule の内部スクリプトの詳しい挙動、平均評価（rating）の計算式、フィードバックタスク（kb_feedback_task）の構造、kb_use が実利用で増える挙動（OOTB では0件のため未観測）、live_message（Comments / 会話機能）連携の内部、検索（Zing / AI Search）からのフィードバック経路。これらは別記事で扱います。
今回は PDI の OOTB（初期設定）を前提に、評価・利用記録のデータ構造を確認しました。実環境では、既存のカスタマイズや実際の利用実績によって、件数や設定の数・内容が変わります。
