incident-activity-summarization

インシデントアクティビティの要約

概要

このスキルは、ServiceNow ITSM のインシデントアクティビティストリームから簡潔な説明形式の要約を生成します。

• 作業メモ、追加コメント、ジャーナルエントリを一貫性のあるタイムラインに統合します
• 状態遷移をタイムスタンプ、所要時間、担当者とともに追跡します
• グループや個人をまたぐ割り当て変更をマッピングします
• 重要な意思決定のポイント、エスカレーションのきっかけ、解決の試みを強調します
• シフト交代やチームの引き継ぎにすぐ使える要約を生成します
• 重大インシデント向けに、管理者が把握しやすいエグゼクティブ向けの説明を作成します
• SLA を考慮した要約を作成し、違反や期限超過のリスクがあるタイムラインを明示します

使用する場面： 引き継ぎ時にエージェントがインシデントの履歴をすばやく把握する必要がある場合、マネージャーが対応中のインシデントの状況報告を必要とする場合、インシデント後のドキュメントを作成する場合、またはアクティビティを自動要約するゼロタッチのサービスデスク自動化を構築する場合に使用します。

前提条件

• ロール： itil、incident_manager、または admin
• プラグイン： com.glideapp.itil（ITSM）
• アクセス権： incident、sys_journal_field、sys_audit、task_sla への読み取りアクセス
• 知識： インシデントのライフサイクル状態、SLA の概念、割り当てグループの構造
• 関連スキル： 状態管理には itsm/incident-lifecycle、P1 プロセスには itsm/major-incident

手順

ステップ 1：インシデントレコードを取得する

コンテキストを把握するために、インシデントの基本情報を取得します。

MCP の方法：

Tool: SN-Get-Record
Parameters:
  table_name: incident
  sys_id: <incident_sys_id>
  fields: sys_id,number,short_description,description,state,priority,impact,urgency,category,subcategory,assigned_to,assignment_group,opened_at,opened_by,resolved_at,resolved_by,closed_at,closed_by,caller_id,cmdb_ci,contact_type,reopen_count,reassignment_count,escalation,sys_updated_on

REST の方法：

GET /api/now/table/incident/<incident_sys_id>
  ?sysparm_fields=sys_id,number,short_description,description,state,priority,impact,urgency,category,subcategory,assigned_to,assignment_group,opened_at,resolved_at,closed_at,caller_id,cmdb_ci,reopen_count,reassignment_count,escalation
  &sysparm_display_value=true

ステップ 2：作業メモとコメントを取得する

インシデントのすべてのジャーナルエントリ（作業メモと追加コメント）を取得します。

MCP の方法：

Tool: SN-Query-Table
Parameters:
  table_name: sys_journal_field
  query: element_id=<incident_sys_id>^elementIN(work_notes,comments)^ORDERBYsys_created_on
  fields: sys_id,element,value,sys_created_on,sys_created_by
  limit: 200

REST の方法：

GET /api/now/table/sys_journal_field
  ?sysparm_query=element_id=<incident_sys_id>^elementIN(work_notes,comments)^ORDERBYsys_created_on
  &sysparm_fields=sys_id,element,value,sys_created_on,sys_created_by
  &sysparm_limit=200

ステップ 3：状態変更の履歴を取得する

監査ログを使用して、すべての状態遷移をタイムスタンプとともに追跡します。

MCP の方法：

Tool: SN-Query-Table
Parameters:
  table_name: sys_audit
  query: documentkey=<incident_sys_id>^fieldname=state^ORDERBYsys_created_on
  fields: sys_id,oldvalue,newvalue,sys_created_on,user
  limit: 50

REST の方法：

GET /api/now/table/sys_audit
  ?sysparm_query=documentkey=<incident_sys_id>^fieldname=state^ORDERBYsys_created_on
  &sysparm_fields=sys_id,oldvalue,newvalue,sys_created_on,user
  &sysparm_display_value=true
  &sysparm_limit=50

ステップ 4：割り当て履歴を取得する

誰がどのくらいの期間インシデントに対応したかを追跡します。

MCP の方法：

Tool: SN-Query-Table
Parameters:
  table_name: sys_audit
  query: documentkey=<incident_sys_id>^fieldnameINassigned_to,assignment_group^ORDERBYsys_created_on
  fields: sys_id,fieldname,oldvalue,newvalue,sys_created_on,user
  limit: 50

ステップ 5：SLA の状態を取得する

インシデントに関連するすべての SLA レコードを確認します。

MCP の方法：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: task=<incident_sys_id>
  fields: sys_id,sla,stage,has_breached,planned_end_time,percentage,business_percentage,start_time,end_time,pause_duration,pause_time
  limit: 10

REST の方法：

GET /api/now/table/task_sla
  ?sysparm_query=task=<incident_sys_id>
  &sysparm_fields=sys_id,sla,stage,has_breached,planned_end_time,percentage,business_percentage,start_time,end_time
  &sysparm_display_value=true
  &sysparm_limit=10

ステップ 6：アクティビティタイムラインを作成する

すべてのデータソースを統合し、時系列に沿ったタイムラインを作成します。

=== INCIDENT ACTIVITY TIMELINE ===
Incident: INC0067890 - Production database connection pool exhaustion
Priority: P1 - Critical | State: Resolved
Duration: 4 hours 23 minutes (Opened to Resolved)

[2025-12-10 02:15] OPENED by Monitoring System (auto-created)
  - Source: Event Management alert
  - Description: Connection pool on prod-db-01 exceeded 95% threshold
  - Auto-assigned to: Database Administration (DBA Team)

[2025-12-10 02:17] WORK NOTE by System
  - "Related alert: CPU utilization on prod-db-01 at 92%"
  - "3 dependent services affected: Order Processing, User Auth, Reporting"

[2025-12-10 02:25] STATE: New -> In Progress
  - Assigned to: Mike Chen (DBA Team)
  - Work note: "Investigating connection pool metrics. Current active
    connections: 485/500. Identifying top consumers."

[2025-12-10 02:42] WORK NOTE by Mike Chen
  - "Root cause identified: Reporting batch job spawning excessive connections.
    Job ID: RPT-NIGHTLY-2025121001. Normally runs 50 connections, currently
    holding 280 connections due to long-running query."

[2025-12-10 02:55] ESCALATION triggered (P1 > 30 min without resolution)
  - Notification sent to: DBA Manager (Sarah Kim)

[2025-12-10 03:10] WORK NOTE by Mike Chen
  - "Killed the runaway reporting query (PID 45678). Connection pool
    dropping. Currently at 310/500. Waiting for connections to release."

[2025-12-10 03:15] COMMENT by Sarah Kim (Manager)
  - "Monitoring the situation. Is there a risk of recurrence tonight?"

[2025-12-10 03:20] WORK NOTE by Mike Chen
  - "Disabled the nightly reporting job to prevent recurrence. Will
    coordinate with Reporting team to fix the query before re-enabling.
    Connection pool now at 180/500 - within normal range."

[2025-12-10 03:45] WORK NOTE by Mike Chen
  - "All dependent services confirmed operational. Order Processing,
    User Auth, and Reporting dashboard all responding normally."

[2025-12-10 04:00] ASSIGNMENT changed: Mike Chen -> Lisa Park (for monitoring)
  - Shift handoff: Mike Chen end of on-call rotation

[2025-12-10 06:38] STATE: In Progress -> Resolved
  - Resolved by: Lisa Park
  - Resolution: "Runaway reporting query killed, connection pool restored.
    Nightly job disabled pending query optimization. Change CHG0012345
    created for permanent fix."

ステップ 7：説明形式の要約を生成する

タイムラインを読みやすい説明文にまとめます。

=== NARRATIVE SUMMARY ===
Incident INC0067890 was a P1 critical issue involving production database
connection pool exhaustion on prod-db-01. The incident was auto-created
by Event Management at 02:15 on December 10, 2025, when the connection
pool exceeded the 95% threshold.

DBA team member Mike Chen began investigation at 02:25 and identified
the root cause within 17 minutes: a nightly reporting batch job had
spawned 280 connections (normally 50) due to a long-running query. Three
dependent services were impacted: Order Processing, User Auth, and
Reporting.

The runaway query was terminated at 03:10, and the connection pool
returned to normal levels (180/500) by 03:20. The nightly reporting job
was disabled as a preventive measure. All dependent services were
confirmed operational by 03:45.

The incident was handed off to Lisa Park at 04:00 during shift rotation
and formally resolved at 06:38. Total resolution time was 4 hours 23
minutes. A change request (CHG0012345) was created for the permanent
fix (query optimization).

KEY METRICS:
- Time to Acknowledge: 10 minutes
- Time to Root Cause: 27 minutes
- Time to Mitigate: 55 minutes
- Time to Resolve: 4 hours 23 minutes
- Reassignment Count: 1 (shift handoff)
- SLA Status: Response SLA met, Resolution SLA met

ステップ 8：引き継ぎ用の要約を生成する

シフト交代に適した簡潔な要約を作成します。

=== SHIFT HANDOFF SUMMARY ===
Incident: INC0067890 - DB Connection Pool Exhaustion (P1)

CURRENT STATE: Resolved (monitoring)
WHAT HAPPENED: Reporting batch job consumed 280 DB connections (limit 500),
  causing service degradation for 3 dependent apps.
WHAT WAS DONE: Killed runaway query, disabled nightly job, pool recovered.
WHAT REMAINS: Monitor for recurrence. Reporting job stays disabled until
  CHG0012345 (query optimization) is implemented.
RISK: Low - root cause addressed. If pool spikes again, kill reporting
  connections first (see work note at 02:42 for query identification steps).
CONTACTS: Mike Chen (original responder), Sarah Kim (manager, notified).

ステップ 9：エグゼクティブサマリーを生成する

管理者が把握しやすい概要を作成します。

=== EXECUTIVE SUMMARY ===
INC0067890 | P1 Critical | RESOLVED

A production database capacity issue caused temporary degradation to three
business services (Order Processing, User Authentication, Reporting) for
approximately 90 minutes on December 10. The issue was caused by a
misconfigured batch reporting job and was resolved without data loss or
customer impact. A permanent fix is scheduled via change request CHG0012345.

Impact: 3 internal services, no customer-facing impact
Duration: 90 minutes (service degradation), 4h23m (total incident lifecycle)
Root Cause: Software defect in reporting batch job
Prevention: Change request filed for query optimization

ステップ 10：要約をインシデントに追加する

生成した要約を作業メモとして保存します。

MCP の方法：

Tool: SN-Add-Work-Notes
Parameters:
  table_name: incident
  sys_id: <incident_sys_id>
  work_notes: "[AI-Generated Activity Summary]\n\n<narrative summary>"

ツールの使用方法

ツール	目的	使用する場面
SN-Get-Record	インシデントレコードの詳細を取得する	初期コンテキストの収集
SN-Query-Table	ジャーナルエントリ、監査証跡、SLA レコードを取得する	アクティビティデータの取得
SN-Natural-Language-Search	説明をもとに関連インシデントを見つける	インシデント間のパターン分析
SN-Add-Work-Notes	生成した要約をインシデントに追加する	ドキュメント作成と引き継ぎ

ベストプラクティス

1. すべてのデータソースを時系列順に統合する -- 作業メモ、状態変更、担当者の割り当てを1つのタイムラインにまとめます
2. 作業メモとコメントを区別する -- 作業メモは内部向けで、コメントは顧客に表示されます
3. 各状態の継続時間を算出する -- インシデントが各状態にどれくらい留まったかを示します
4. 根本原因を明確に強調する -- 最も重要な調査結果を目立たせます
5. 未完了の作業を含める -- 引き継ぎの要約には、未対応のアクションを含める必要があります
6. SLA 違反を目立つように示す -- 違反は、あらゆる要約の先頭で確認できるようにします
7. ビジネス向けの言葉を使う -- エグゼクティブサマリーでは、専門用語を避けます
8. 再割り当てのパターンを記録する -- 再割り当てが過剰な場合は、ルーティングに問題があることを示します
9. 関連レコードを含める -- 変更リクエスト、問題レコード、関連インシデントへのリンクを含めます
10. すべてのエントリーにタイムスタンプを付ける -- 監査のため、すべてのアクティビティに明確なタイムスタンプを付ける必要があります

トラブルシューティング

問題	原因	解決方法
ジャーナルエントリーが見つからない	保持ポリシーにより古いエントリーが削除された	sys_journal_field の保持設定を確認します。データはアーカイブにある場合があります
監査レコードが不完全	すべてのフィールドで監査が有効になっていない	sys_dictionary の監査設定を確認します
状態変更が追跡されない	状態フィールドが監査対象になっていない	ディクショナリで state フィールドの監査を有効にします
SLA レコードが見つからない	この優先度／カテゴリに対する SLA 定義がない	contract_sla の SLA 定義を確認します
割り当て履歴に抜けがある	割り当て変更が監査されていない	assigned_to と assignment_group の監査を有効にします
タイムラインの順序が正しくない	クエリのタイムゾーンが一致していない	UTC を一貫して使用し、表示時に変換します

例

例 1：シフト引き継ぎの要約

入力：「次のシフト担当者向けに、INC0067890 のすべてのアクティビティを要約してください」

**手順：**インシデントを取得し、すべてのジャーナルエントリーと状態変更を取得します。直近4時間のアクティビティを特定し、現在の状態、保留中のアクション、リスク評価を含む簡潔な引き継ぎの要約を作成します。

例 2：重大インシデントのエグゼクティブレポート

入力：「CTO 向けに、P1 インシデント INC0067890 のエグゼクティブサマリーを作成してください」

**手順：**インシデントとすべてのアクティビティを取得し、主要な指標（検知までの時間、対応までの時間、解決までの時間）を算出して、ビジネスへの影響を評価します。技術的な詳細を含まないエグゼクティブ向けの説明を作成し、再発防止策を含めます。

例 3：デイリースタンドアップ向けの一括アクティビティ要約

入力：「過去24時間のすべての P1 および P2 インシデントを要約してください」

**手順：**過去24時間に起票または更新された優先度1または2のインシデントを検索します。それぞれについて簡潔な（3～5行の）要約を作成し、現在の状態と担当者を含めます。合計インシデント数、解決済み件数、未解決件数などの指標を集計します。

関連スキル

• itsm/incident-lifecycle - インシデントの状態管理とライフサイクル
• itsm/major-incident - 重大インシデント管理プロセス
• itsm/incident-triage - インシデントの分類とルーティング
• reporting/sla-analysis - SLA パフォーマンス分析
• itsm/quick-reference - ITSM のフィールドと状態のリファレンス