gap-analysis

ナレッジギャップ分析

概要

このスキルでは、インシデントやケースのデータを既存のナレッジ記事と関連付け、ServiceNow のナレッジベースにあるギャップを体系的に特定する方法を説明します。ナレッジギャップがあると、解決までの時間が長くなり、エスカレーションが繰り返され、セルフサービスの利用が進まなくなります。

このスキルでは、次のことができます。

• 対応するナレッジ記事がない、件数の多いインシデントカテゴリを特定する
• 検索ログを分析し、結果がゼロまたは関連性の低いクエリを見つける
• 解決済みのインシデントとナレッジベースのカバー状況を関連付け、不足しているドキュメントを明らかにする
• 記事が不完全、または役に立たないことを示すフィードバックを調べる
• インシデント件数、ビジネスへの影響、解決の複雑さに基づいて記事の作成に優先順位を付ける
• データに基づくナレッジ作成バックログを作成する

使用するタイミング： 四半期ごとのナレッジレビュー時、特定カテゴリのインシデント件数の増加に気付いた後、セルフサービスによる問い合わせ削減率が低下したとき、または新しいサポート領域のオンボーディング時に使用します。

前提条件

• ロール： knowledge_manager、knowledge_admin、またはレポートへのアクセス権を持つ itil
• アクセス権： kb_knowledge、incident、sn_customerservice_case、kb_feedback、search_log、kb_use テーブルへの読み取りアクセス権
• プラグイン： com.glideapp.knowledge（Knowledge Management）が有効化されていること
• 推奨プラグイン： 検索ログ分析用の com.glide.search（Search Analytics）
• 知識： インシデント分類の体系とナレッジベースの構造を理解していること

手順

ステップ 1：件数の多いインシデントカテゴリを特定する

インシデントのサンプルを上限付きで取得し、ローカルでカテゴリとサブカテゴリ別に集計して、過去 90 日間に最も件数の多いトピックを特定します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^active=false^state=6
  fields: sys_id,category,subcategory
  limit: 1000
  instance: dev

返された行をローカルで (category, subcategory) ごとに数え、件数の 降順に並べ替え、上位 25 件を残します。取得上限は 1,000 件であるため、 全件を網羅する必要がある場合は、意図的にページネーションしてください。

REST API を使用する場合：

GET /api/now/stats/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^active=false^state=6&sysparm_group_by=category,subcategory&sysparm_count=true&sysparm_orderby=COUNT&sysparm_limit=25

ステップ 2：上位カテゴリのナレッジカバー状況を確認する

件数の多いカテゴリごとに、そのトピックを扱う公開済み記事を検索します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: kb_knowledge
  query: workflow_state=published^kb_category.label=Network^ORshort_descriptionLIKEnetwork
  fields: sys_id,number,short_description,kb_knowledge_base,kb_category,sys_view_count,rating,sys_updated_on
  limit: 20

REST API を使用する場合：

GET /api/now/table/kb_knowledge?sysparm_query=workflow_state=published^kb_category.label=Network^ORshort_descriptionLIKEnetwork&sysparm_fields=sys_id,number,short_description,kb_knowledge_base,kb_category,sys_view_count,rating,sys_updated_on&sysparm_limit=20

ステップ 3：KB 記事がないインシデントトピックを特定する

上位のインシデントカテゴリとナレッジベースのカバー状況を照合します。ステップ 2 で記事が 0 件だったカテゴリのインシデントをクエリします。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=6^category=network^subcategory=dns^resolved_byISNOTEMPTY
  fields: sys_id,number,short_description,close_notes,category,subcategory,resolved_by,resolution_code
  limit: 30

REST API を使用する場合：

GET /api/now/table/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=6^category=network^subcategory=dns^resolved_byISNOTEMPTY&sysparm_fields=sys_id,number,short_description,close_notes,category,subcategory,resolved_by,resolution_code&sysparm_limit=30

ステップ 4：検索ログを分析して検索に失敗したクエリを見つける

ナレッジポータルでユーザーが入力した検索語句のうち、結果が返されなかったもの、または結果がごく少なかったものを見つけます。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: search_log
  query: sys_created_on>=javascript:gs.daysAgoStart(30)^results_count=0^search_application=knowledge
  fields: sys_id,search_term,results_count,sys_created_on,user
  limit: 50

REST API を使用する場合：

GET /api/now/table/search_log?sysparm_query=sys_created_on>=javascript:gs.daysAgoStart(30)^results_count=0^search_application=knowledge&sysparm_fields=sys_id,search_term,results_count,sys_created_on,user&sysparm_limit=50

検索に失敗した語句のサンプルを上限付きで取得し、正規化した同一の 語句をローカルで数えて、満たされていないクエリのうち最も多いものを見つけます。

Tool: SN-Query-Table
Parameters:
  table_name: search_log
  query: sys_created_on>=javascript:gs.daysAgoStart(30)^results_count=0^search_application=knowledge
  fields: sys_id,search_term
  limit: 1000
  instance: dev

ステップ 5：既存の記事に対する否定的なフィードバックを確認する

ユーザーが役に立たないと評価した記事を見つけます。これらの記事は、トピックのカバーが不十分であることを示している可能性があります。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: kb_feedback
  query: sys_created_on>=javascript:gs.daysAgoStart(90)^rating=not_helpful^ORrating=1
  fields: sys_id,article,article.number,article.short_description,rating,comments,sys_created_on
  limit: 30

REST API を使用する場合：

GET /api/now/table/kb_feedback?sysparm_query=sys_created_on>=javascript:gs.daysAgoStart(90)^rating=not_helpful^ORrating=1&sysparm_fields=sys_id,article,article.number,article.short_description,rating,comments,sys_created_on&sysparm_limit=30

ステップ 6：KB 記事を添付せずに解決したインシデントを調べる

ナレッジ記事がリンクされていない解決済みインシデントを見つけます。これらは、場当たり的に解決され、文書化されていないことを示しています。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=6^close_notes!=^kb_knowledgeISEMPTY
  fields: sys_id,number,short_description,close_notes,category,subcategory,assignment_group,resolved_by
  limit: 40

REST API を使用する場合：

GET /api/now/table/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=6^close_notes!=^kb_knowledgeISEMPTY&sysparm_fields=sys_id,number,short_description,close_notes,category,subcategory,assignment_group,resolved_by&sysparm_limit=40

ステップ 7：CSM ケースを分析してサービス固有のギャップを特定する

Customer Service Management が有効な場合は、ナレッジでカバーされていないケースのトピックを確認します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_customerservice_case
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=3^knowledge=false
  fields: sys_id,product,category
  limit: 1000
  instance: dev

ローカルで (product, category) ごとに行数を数え、上位 20 件を残します。 日付範囲全体を明示的にページネーションしない限り、結果は上限付きのサンプルとして扱ってください。

REST API を使用する場合：

GET /api/now/stats/sn_customerservice_case?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=3^knowledge=false&sysparm_group_by=product,category&sysparm_count=true&sysparm_limit=20

ステップ 8：優先順位を付けたギャップレポートを作成する

調査結果を優先順位付きのリストにまとめます。インシデント数、ビジネスへの影響、解決の複雑さに基づいて、各ギャップにスコアを付けます。

ギャップのスコアリングマトリクス：

要因	重み	スコア範囲
インシデント数（90 日間）	40%	件数に基づく 1～5
インシデントの平均優先度	25%	1～5（P1=5、P5=1）
検索失敗の頻度	20%	件数に基づく 1～5
否定的なフィードバックの件数	15%	件数に基づく 1～5

ステップ 9：ナレッジギャップのレコードを作成する

特定したギャップを、ナレッジ作成者向けのタスクとして記録します。

MCP の使用：

Tool: SN-Create-Record
Parameters:
  table_name: kb_submission
  data:
    short_description: "Knowledge Gap: DNS Configuration Troubleshooting"
    description: "Gap Analysis identified 47 resolved incidents in 90 days for DNS configuration issues with no matching KB article. Top search terms: 'dns settings', 'dns not resolving', 'configure dns'. Priority score: 4.2/5."
    kb_knowledge_base: [target_kb_sys_id]
    category: Network
    assignment_group: Knowledge Authors

REST API の使用：

POST /api/now/table/kb_submission
Content-Type: application/json

{
  "short_description": "Knowledge Gap: DNS Configuration Troubleshooting",
  "description": "Gap Analysis identified 47 resolved incidents...",
  "kb_knowledge_base": "[target_kb_sys_id]",
  "category": "Network",
  "assignment_group": "[group_sys_id]"
}

ツールの使用方法

MCP ツールのリファレンス

ツール	使用する場面
SN-Query-Table	インシデント、記事、フィードバック、検索ログを照会し、ローカルで集計するために範囲を限定したフィールドを取得します
SN-Natural-Language-Search	トピックの網羅状況を自然言語で検索します
SN-Create-Record	ギャップに関するナレッジ提出レコードを作成します
SN-Add-Work-Notes	既存のレコードに分析結果を記録します

REST API のリファレンス

エンドポイント	メソッド	目的
/api/now/table/incident	GET	解決済みインシデントを照会します
/api/now/stats/incident	GET	インシデントデータを集計します
/api/now/table/kb_knowledge	GET	既存の記事の網羅状況を確認します
/api/now/table/search_log	GET	失敗した検索クエリを分析します
/api/now/table/kb_feedback	GET	記事への否定的なフィードバックを確認します
/api/now/table/kb_submission	POST	ナレッジギャップのレコードを作成します

ベストプラクティス

• 定期的に実施する： 新たなトピックに先手を打つため、ギャップ分析を毎月または四半期ごとに実施します
• 複数のシグナルを使う： インシデントデータ、検索ログ、フィードバックを組み合わせて全体像を把握します。単一の情報源だけでは全体像は分かりません
• 解決済みインシデントに焦点を当てる： クローズノートに解決内容が記録されている、クローズ済みまたは解決済みのインシデントのみを分析します
• SME と連携する： 記事の作成を検証し、優先順位を付けられる分野の専門家とギャップの調査結果を共有します
• デフレクションへの影響を追跡する： 特定したギャップを埋める前後で、インシデントのデフレクション率を測定します
• セルフサービスを考慮する： 社内向けのみのドキュメントよりも、エンドユーザーのセルフサービスを可能にするギャップを優先します
• ノイズを除外する： 1 回限りのインシデントを除外し、5 件以上発生している反復パターンに焦点を当てます

トラブルシューティング

「検索ログテーブルが空、またはアクセスできない」

原因： 検索分析プラグインが有効化されていないか、検索ログが有効になっていません
解決策： com.glide.search が有効であり、プロパティ glide.ts.search.log が true に設定されていることを確認します

「インシデントカテゴリと KB カテゴリが一致しない」

原因： インシデントの分類とナレッジの分類で異なる分類体系が使われています
解決策： 正確に相互参照できるよう、インシデントのカテゴリ／サブカテゴリと KB カテゴリラベルの対応表を作成します

「KB へのリンクがないインシデントが多すぎる」

原因： ナレッジ中心型サービス（KCS）のプラクティスが徹底されておらず、エージェントが記事にリンクしていません
解決策： KCS の使用が求められる担当グループで絞り込み、記事は存在するものの添付されていないカテゴリに焦点を当てます

「集計クエリがタイムアウトする」

原因： 日付範囲が広く、インシデントテーブルが大きすぎます
解決策： 日付範囲を 30 日間に絞るか、特定の担当グループまたはカテゴリで絞り込みます

例

例 1：ネットワークの DNS ギャップの発見

分析：

• 90 日間に「DNS」サブカテゴリで解決済みインシデントが 47 件
• 「dns settings」と「dns not resolving」でナレッジ検索に失敗した件数が 23 件
• DNS 設定に該当する公開済み KB 記事は 0 件
• インシデントの平均優先度：P3

ギャップスコア： 4.2/5（件数が多く、検索失敗が頻繁）

推奨事項： よくある設定エラー、解決手順、エスカレーション経路を網羅した、包括的な DNS トラブルシューティング記事を作成します。ネットワーク運用のナレッジ作成者に割り当てます。

例 2：新入社員のオンボーディングに関するギャップ

分析：

• 90 日間で「アカウント設定」カテゴリのインシデントが 112 件
• 「新入社員のアクセス権」「初日のセットアップ」「オンボーディングチェックリスト」の検索が 45 件失敗
• 既存のナレッジベース記事が 2 件見つかりましたが、どちらも「役に立たない」と評価されています（否定的なフィードバックが 8 件）
• 既存の記事は 18 か月前のもので、廃止されたツールを参照しています

ギャップスコア： 4.8/5（件数が非常に多く、既存のコンテンツが古くなっています）

推奨事項： 古くなった記事を廃止し、新しい包括的なオンボーディングガイドを作成します。すべてのプロビジョニング手順を網羅するため、人事部門と IT 部門で連携してください。新入社員の生産性への影響を考慮し、優先度を高くします。

例 3：CSM の製品返品に関するギャップ

分析：

• 「製品返品」に関するカスタマーサービス案件が 38 件あり、ナレッジフラグは付いていません
• 「返品ポリシー」「返品ラベル」「返金状況」のポータル検索が 15 件失敗
• 外部顧客向けナレッジベースに公開済みの記事がありません

ギャップスコア： 3.9/5（件数は中程度ですが、顧客への影響があります）

推奨事項： 返品の適格条件、手順、ラベルの生成、返金の所要時間を網羅した顧客向け記事を作成します。セルフサービスによる問い合わせ削減のため、外部ナレッジベースに公開してください。

関連スキル

• knowledge/duplicate-detection - ギャップ分析の前に重複記事を整理します
• knowledge/content-recommendation - インシデントに関連する既存の記事を提示します
• knowledge/article-generation - 解決済みのインシデントから記事を生成し、ギャップを埋めます
• knowledge/gap-grouping - 特定したギャップをトピック別に分類し、優先順位を付けます