> 継続的なプロセス改善 > インシデント管理 > Freshservice > データテンプレート

インシデント管理用データテンプレート

Freshservice

← 改善ガイドに戻る

インシデント管理の属性(19) インシデント管理のアクティビティ(14) データ抽出ガイド(3)

インシデント管理用データテンプレート

このテンプレートは、インシデント管理を効果的に分析できるよう、データの準備を支援します。収集する必要がある属性や追跡すべき重要なアクティビティを示し、ソースシステムから情報を抽出する方法も説明します。データ準備の際にお役立てください。

収集を推奨する属性
追跡すべき主なアクティビティ
データ抽出ガイド

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

テンプレートをダウンロード

インシデント管理の属性

インシデント管理プロセスを詳しく分析するために、イベントログに含めることを推奨するデータ項目です。

5 必須 7 推奨 7 任意

	名前	説明
	インシデントID IncidentId	各インシデントの記録を一意に識別するIDです。インシデントのライフサイクル全体を追跡するための主キーとして機能します。
説明インシデントIDは、インシデント管理の分析を支える基本項目です。ケースIDとして機能し、関連するすべてのアクティビティ、タイムスタンプ、属性の変更を1つの一連の流れに結び付けます。プロセスマイニングでは、イベントログの各記録がインシデントIDに関連付けられます。これにより、個々のインシデントについて、プロセスの開始から終了までの流れを再構成できます。サイクルタイムの算出、プロセスバリアントの分析、個別ケースに特有のボトルネックの特定にも欠かせません。一意のIDがなければ、インシデントを区別し、報告から解決までの経路を分析することはできません。重要な理由各インシデントを一意に識別し、作成から終了までのライフサイクルを最初から最後まで追跡・分析できます。入手先チケットの主識別子です。Freshservice Tickets APIでは、チケットオブジェクトの「id」フィールドから取得できます。例 INC-10234INC-10235INC-10236
	アクティビティ名 ActivityName	インシデントのライフサイクルにおいて、ある時点で発生した特定の業務アクティビティまたはイベントの名称です。
説明アクティビティ名は、インシデント管理プロセスにおける個々のステップやイベントを表します。たとえば、「インシデントをグループに割り当て」「ステータスを保留に変更」「インシデント解決」などです。これらのアクティビティは、時間の経過に伴うインシデントのデータ変更から導出されます。この属性は、検出されたプロセスマップのノードを定義するため、プロセスマイニングの基本となります。アクティビティの順序や頻度を分析すると、実際のインシデント解決プロセスを可視化し、よくある経路の特定、標準手順からの逸脱の検出、頻繁な再割り当てなどの手戻りの把握ができます。重要な理由プロセスマップの各ステップを定義し、インシデント解決の流れやボトルネック、逸脱を可視化して分析できます。入手先 Freshserviceに直接対応するフィールドはありません。ステータス、優先度、担当者やグループの割り当て、メモの追加など、チケットのプロパティ変更から導出します。例インシデントの報告インシデントをグループに割り当て解決メモを追加インシデントを解決済みにする
	イベントタイムスタンプ EventTimestamp	アクティビティまたはイベントが発生した正確な日時です。
説明イベントタイムスタンプ（開始時刻）は、アクティビティが発生した正確な時点を示します。作成から終了まで、インシデントのライフサイクルに含まれる各アクティビティにタイムスタンプが記録されます。この属性は、時間に基づくプロセスマイニング分析全般に欠かせません。イベントを時系列に並べ、アクティビティ間の所要時間やケース全体のサイクルタイムを算出し、待ち時間を分析するために使います。また、SLAパフォーマンス、引き継ぎの遅延、解決までの所要時間を追跡するダッシュボードの基礎となります。重要な理由イベントの時系列を把握できるため、所要時間やサイクルタイムの算出、プロセスパフォーマンスの理解に役立ちます。入手先 Freshserviceの「created_at」「updated_at」などのタイムスタンプフィールドや、チケットの会話履歴または監査ログ内のタイムスタンプから導出します。例 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	ソースシステム SourceSystem	データの抽出元となるシステムです。通常は「Freshservice」です。
説明この属性は、データの取得元を示します。この場合は常に「Freshservice」ですが、複数のシステムのデータを組み合わせてプロセス全体を把握する環境では重要なフィールドです。ソースシステム属性を含めることは、データガバナンスとトレーサビリティの観点から推奨される方法です。データの出所を明確にできるため、検証やデバッグに役立ちます。また、今後、他のサービス管理システムや業務システムをプロセスマイニングの対象に加える際にも役立ちます。重要な理由インシデント管理データの取得元を明確にし、データのトレーサビリティとガバナンスを確保します。入手先通常は、データ変換（ETL）処理でデータセットを識別するために追加する固定値です。例 FreshserviceFreshservice-EUFreshservice-PROD
	最終データ更新日時 LastDataUpdate	このプロセスのデータが最後に更新または抽出された日時を示すタイムスタンプです。
説明この属性は、ソースシステムからデータセット全体が最後に更新された日時を示します。個々のイベントではなくデータセット全体に適用されるメタデータですが、一貫性を保つためにイベント単位で含めることもよくあります。分析では、データの鮮度や、ダッシュボードと重要業績評価指標（KPI）が対象とする期間を把握するうえで重要な情報です。インサイトがどの時点までのデータに基づくかを確認でき、最新のインシデントが分析に含まれているかどうかを判断するのに役立ちます。重要な理由データの更新時点を示し、分析対象の期間を把握できるようにします。入手先データ抽出（ETL）処理で生成されるメタデータのタイムスタンプです。例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	インシデントのカテゴリ IncidentCategory	インシデントを分類するカテゴリです。「ハードウェア」「ソフトウェア」「ネットワーク」などがあります。
説明インシデントのカテゴリは、報告された問題の種類に基づいてインシデントを分類するために使います。階層的な分類により、適切なチームへの振り分けが可能になり、傾向分析にも役立ちます。この属性は、「インシデント分類の正確性」ダッシュボードで、最初の分類ミスによる再割り当てが解決時間の長期化につながっているかを分析するために使います。カテゴリ別にインシデントをまとめると、繰り返し発生する問題や、サポート業務の負荷が大きい領域を特定し、改善施策を検討できます。重要な理由インシデントの傾向を分析し、分類ミスが解決の遅延につながっているかを確認できます。入手先 Freshserviceの標準フィールドですが、カスタマイズも可能です。Tickets APIの「category」から取得でき、関連フィールドに「sub_category」と「item_category」があります。例ハードウェアソフトウェアネットワークの問題アカウントアクセス
	インシデントのステータス IncidentStatus	インシデントのライフサイクルにおける現在のステータスです。「Open」「Pending」「Resolved」「Closed」などがあります。
説明インシデントのステータスは、現在の状態を示します。ステータスの変更は、検出されたプロセスマップを構成する重要なイベントです。たとえば、「In Progress」から「Pending」への変更や、「Resolved」から「Closed」への変更があります。この属性は、インシデントの進行状況を把握するうえで基本となります。各ステータスの滞在時間を分析すると、ユーザーの回答を待つ「Pending」の状態が長引くなど、ボトルネックとなる段階を特定できます。また、サイクルタイムの算出に使う開始点と終了点を定義するうえでも重要です。重要な理由インシデントのライフサイクル全体の進行状況を追跡し、遅延が起きやすい段階を特定できます。入手先 Freshservice Tickets APIの「status」フィールドから取得できます。値は数値です。例オープン対応中保留中解決済み終了
	インシデントの優先度 IncidentPriority	インシデントの優先度です。応答と解決の緊急度を決定します。
説明インシデントの優先度は、対応に求められる速度や重点を決める重要なフィールドです。通常は「低」「中」「高」「緊急」などの段階で設定され、SLA目標にも反映されます。プロセスマイニングでは、優先度を使ってデータを絞り込み、分析できます。優先度の高いインシデントと低いインシデントの解決プロセスを比較し、重大な問題が効率よく処理されているかを確認できます。ダッシュボードでは、サイクルタイムやSLAの遵守状況などの指標を優先度別に表示し、サポート管理者が具体的な改善案を検討できるようにします。重要な理由重大なインシデントに焦点を当てた分析や、SLAパフォーマンスとリソース配分の評価に役立ちます。入手先 Freshservice Tickets APIの「priority」フィールドから取得できます。値は数値で、たとえば1は「低」、4は「緊急」を表します。例低中高緊急
	インシデントの重大度 IncidentSeverity	インシデントの重大度です。業務への影響を示します。
説明インシデントの重大度は、業務への影響を測るもので、「低」「中」「高」「重大」などに分類されます。優先度と関連しますが、重大度が影響の大きさを示すのに対し、優先度は緊急性を示します。重大度と影響度を組み合わせて、最終的な優先度を決めることもよくあります。重大度別の分析により、業務に大きな影響を及ぼすインシデントに組織がどのように対応しているかを把握できます。ダッシュボードで解決時間やSLAパフォーマンスを重大度別に表示し、ライフサイクル全体を通じて、影響の大きい問題に適切な注意とリソースが割り当てられているかを確認できます。重要な理由インシデントが業務に与える影響を測定し、被害の大きい問題の抑制に焦点を当てた分析ができます。入手先 Freshserviceの標準フィールドで、Tickets APIの「impact」から取得できます。値は数値です。例低中高
	担当グループ AssignedGroup	現在インシデントを担当しているサポートグループまたはチームです。
説明担当グループは、「レベル1サポート」「ネットワークチーム」「データベース管理者」など、インシデントを担当するチームを示します。この属性が変わると、異なる機能チームへのエスカレーションや引き継ぎが行われたことを表します。担当グループを分析すると、引き継ぎや移管に伴う遅延を把握できます。プロセスマイニングでグループ間のインシデントの流れを可視化し、よくあるエスカレーション経路を明らかにするとともに、各グループが対応を開始するまでの待ち時間を測定できます。これにより、組織内のボトルネックや、チーム間の連携を効率化する機会を特定できます。重要な理由担当チームを追跡できるため、引き継ぎやエスカレーション、チーム間の遅延を分析するうえで役立ちます。入手先 Freshservice Tickets APIの「group_id」フィールドから取得できます。このIDをGroups APIと結合すると、グループ名を取得できます。例サービスデスクネットワーク運用インフラサポート
	担当者 AssignedAgent	現在インシデントの解決を担当しているサポート担当者の名前またはIDです。
説明担当者は、ある時点でインシデントを担当するサービスデスクの従業員を示します。この属性が変わると、担当者間で引き継ぎが行われたことを表します。この属性はパフォーマンス分析に欠かせません。担当者ごとの業務量や平均解決時間、初回連絡での解決率を追跡するダッシュボードを作成できます。また、遅延や非効率の原因となることがある担当者間の引き継ぎの分析にも使えます。担当者の割り当てを追跡することで、管理者は研修の必要性を把握し、成果を上げているチームメンバーを評価できます。重要な理由担当者のパフォーマンスや業務量の分布、担当者間の引き継ぎが解決時間に与える影響を分析できます。入手先 Freshservice Tickets APIの「responder_id」フィールドから取得できます。このIDをAgents APIと結合すると、担当者名を取得できます。例 John DoeJane SmithSupportBot
	解決SLA目標時刻 ResolutionSlaTargetTime	SLAポリシーに基づき、インシデントの解決が求められる期限のタイムスタンプです。
説明この属性には、インシデント解決の期限となる日時を記録します。期限はチケットに適用されるサービスレベル契約（SLA）ポリシーによって決まり、通常は優先度などの要素に応じて設定されます。この目標時刻は、「SLA遵守率」KPIの算出や「SLAパフォーマンス」ダッシュボードに欠かせません。実際の解決時刻と目標時刻を比較することで、インシデントが期限内に解決されたか、SLA未達となったかを判断できます。サービスレベルの遵守状況を測定するための基本情報です。重要な理由解決期限を示すため、SLAの遵守状況の算出や、期限超過のリスクがあるインシデントの特定に必要です。入手先 Freshservice Tickets APIの「fr_due_by」（初回応答）および「due_by」（解決）フィールドから取得できます。例 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	SLA未達かどうか IsSlaBreached	定められたSLA目標時刻までにインシデントが解決されなかった場合に真となる、計算上のフラグです。
説明この真偽値属性は、インシデントの解決時間がSLA目標を超えたかどうかを示す計算指標です。実際の解決時刻と「ResolutionSlaTargetTime」を比較して導出します。このフラグは、「SLA遵守率」KPIと「SLAパフォーマンス」ダッシュボードに直接使われます。各インシデントのSLAパフォーマンスを明確な二択で示すため、集計や傾向分析が容易になります。サービス上の取り決めを満たせなかったインシデントの件数や割合をすばやく把握できます。重要な理由各インシデントのSLA遵守状況を直接測定できるため、全体の遵守率の算出や問題領域の特定が容易になります。入手先データ変換時に、「Incident Resolved」のタイムスタンプと「ResolutionSlaTargetTime」フィールドを比較して算出するフィールドです。例 truefalse
	依頼者の部門 RequestersDepartment	インシデントを報告したユーザーが所属する部門です。
説明この属性は、依頼者が所属する「営業」「財務」「IT」などの業務部門を示します。通常、Freshservice内のユーザープロフィールから取得します。依頼者の部門別にインシデントを分析すると、特定の事業部門に問題が集中していないか、部門固有の問題がないかを把握できます。インシデントが業務に与える影響を理解するための背景情報となり、重要な部門に影響する問題の修正を優先する際にも役立ちます。重要な理由業務上の背景を踏まえて、インシデントの傾向や特定部門への影響を分析できます。入手先この情報はチケットの依頼者に関連付けられています。チケットの「requester_id」を使って「Requesters」APIエンドポイントから依頼者を取得し、「department_id」と部門名を参照できます。例営業マーケティング財務人事
	再オープンされたかどうか IsReopened	解決または終了後にインシデントが再オープンされた場合に真となる、計算上のフラグです。
説明この真偽値属性は、再オープンされたインシデントを特定する計算フラグです。インシデントが「Resolved」または「Closed」の状態になった後、ステータスがオープンまたは対応中に戻ると真になります。このフラグは、「インシデント再オープン率」KPIの算出や「繰り返し発生するインシデント」ダッシュボードに欠かせません。再オープン率が高い場合、最初の解決の品質、根本原因分析の不備、または早すぎる終了に問題がある可能性があります。該当ケースを分析することで、修正の品質と持続性を高められます。重要な理由解決プロセスの問題を特定し、最初の修正が有効でなく、手戻りにつながったインシデントを明らかにします。入手先イベントログのアクティビティの順序から導出する計算フィールドです。「Incident Reopened」のようなアクティビティが発生した場合、または同じインシデントIDで終了状態の後にオープン状態のアクティビティが続いた場合に真となります。例 truefalse
	回避策を提示 WorkaroundProvided	最終的な解決策を提示する前に、ユーザーに一時的な回避策を提供したかどうかを示すフラグです。
説明この真偽値属性は、恒久的な解決策を開発する間に、インシデントの影響を抑えるための一時的な修正や回避策を実施したかどうかを示します。チェックボックスや特定のステータスで記録されることがよくあります。プロセスマイニングでは、この属性を「回避策の有効性指標」ダッシュボードで利用できます。回避策の有無による解決時間を比較し、一時的な修正が業務への支障を抑え、ユーザーが感じる解決までの時間を短縮できているかを確認できます。重要な理由一時的な回避策がインシデントの影響を抑え、ユーザーが感じる解決までの時間を短縮する効果を測定できます。入手先通常はカスタムの真偽値フィールド（チェックボックス）です。Freshserviceの「Ticket Fields」設定で、フィールドの有無を確認してください。例 truefalse
	報告チャネル ReportingChannel	インシデントの報告に使われた方法またはチャネルです。「メール」「ポータル」「電話」などがあります。
説明報告チャネルは、報告元とも呼ばれ、インシデントがどのような経路でサポートシステムに登録されたかを示します。一般的なチャネルには、メール、セルフサービスポータル、電話、チャットがあります。この属性を分析すると、各報告チャネルの効率を評価できます。「報告チャネルの効率」ダッシュボードでは、チャネル別のインシデント件数と平均解決時間を比較し、効果的な方法やプロセスの改善が必要な方法を確認します。たとえば、ポータルから報告されたインシデントは、最初から情報が整理されているため、より早く解決できる場合があります。重要な理由効率の高い報告チャネルを特定し、インシデント受付プロセスの改善点を見つけるのに役立ちます。入手先 Freshservice Tickets APIの「source」フィールドから取得できます。値は数値です。例メールポータル電話チャット
	引き継ぎ回数 HandoffCount	インシデントが異なる担当者またはグループに移管された回数です。
説明引き継ぎ回数は、インシデントのライフサイクル中に発生した再割り当ての回数を示す計算指標です。「AssignedAgent」または「AssignedGroup」属性が変更されるたびに、回数が増えます。引き継ぎ回数が多い場合、プロセスの非効率、最初の振り分けの誤り、担当者の知識不足などが考えられます。この指標は、「インシデントの引き継ぎ回数」KPIや「引き継ぎと移管の遅延分析」ダッシュボードに直接役立ちます。過剰な移管によって遅延が生じているインシデントやプロセス経路を特定できます。重要な理由手戻りや再割り当ての回数を測定し、振り分けの誤りや知識不足による非効率を特定できます。入手先 1件のインシデントのライフサイクルを通じて、「AssignedAgent」または「AssignedGroup」フィールドの異なる値や変更の数を数えて算出する指標です。例 0125
	根本原因 RootCause	調査後に特定された、インシデントの背後にある原因または根本原因です。
説明根本原因属性には、インシデントにつながった根本的な問題を記録します。通常、サポート担当者が解決中または解決後に、根本原因分析（RCA）の一環として入力します。この属性は、「繰り返し発生するインシデントと根本原因」ダッシュボードや「根本原因分析の完了率」KPIに欠かせません。よくある根本原因を分析することで、事後対応的なインシデント修正から、問題の予防を重視する管理へと移行できます。恒久的な解決策を実施し、将来のインシデントや再発を減らせます。重要な理由繰り返し発生するインシデントの根本原因を特定して取り除き、問題の予防に役立てられます。入手先 Freshserviceの標準機能では対応が限られるため、カスタムフィールドとして設定されていることがよくあります。「Ticket Fields」の設定で、「Root Cause」または同様の名前のフィールドがあるか確認してください。例ソフトウェアのバグネットワーク設定エラーユーザートレーニングの問題ハードウェア障害

必須推奨任意

インシデント管理のアクティビティ

プロセスを正確に把握し、ボトルネックを特定するために、イベントログに記録すべき主なプロセスステップとマイルストーンです。

7 推奨 7 任意

	アクティビティ	説明
	インシデントの優先度を設定	インシデントの優先度が設定または更新されたときに発生します。優先度は、解決の緊急度とSLA目標を決定します。インシデント履歴の「優先度」フィールドの変更を監視して取得します。
重要な理由優先度の設定が誤っていたり遅れたりすると、SLA違反や非効率なリソース配分につながる可能性があります。このアクティビティを分析することで、重大なインシデントにすぐ対応できているかを確認できます。入手先「優先度」フィールドのすべての更新を記録したインシデントのアクティビティログから推定します。記録「優先度」フィールドの値が設定または変更された監査ログのタイムスタンプを使用します。イベントタイプ inferred
	インシデントの報告	Freshserviceで新しいインシデント記録が作成されたことを示します。インシデントのライフサイクルの開始点で、通常はエンドユーザーがポータルやメールから報告するか、サービスデスクの担当者が代理でチケットを作成したときに発生します。このイベントには作成時刻が明示的に記録されます。
重要な理由このアクティビティは、プロセス全体の主な開始イベントです。ここから解決までの時間を分析することは、全体のサイクルタイムとSLA遵守状況を測定するうえで基本となります。入手先インシデントテーブルの作成時刻から取得します。Freshserviceでは、新しいチケットごとにこの時刻が明示的に記録されます。記録メインのインシデント記録にある「作成日時」のタイムスタンプを使用します。イベントタイプ explicit
	インシデントをグループに割り当て	インシデントをサポートグループに最初に割り当てたことを示します。振り分けルールによる自動割り当て、または担当者による手動割り当ての場合があります。インシデントの監査ログで「グループ」フィールドに最初に値が設定された記録を追跡して取得します。
重要な理由割り当てを追跡すると、初回応答時間を測定し、振り分けプロセスのボトルネックを特定できます。インシデントが適切なチームにどれだけ効率よく振り分けられているかを分析するのに役立ちます。入手先インシデントのアクティビティログで「グループ」フィールドに値が設定または変更された最初の記録から推定します。記録インシデントの「グループ」フィールドに最初に値が設定されたタイムスタンプを特定します。イベントタイプ inferred
	インシデントを解決済みにする	担当者が修正を実施し、インシデントを解決済みと判断した時点を示します。インシデントのステータスが「解決済み」に変更されたときに記録されます。Freshserviceでは、SLAの計測を停止する重要な節目です。
重要な理由解決までの時間（TTR）を測定する重要な節目です。「解決済み」から「クローズ」までの期間を分析すると、ユーザー確認の遅れや自動クローズのルールを把握できます。入手先アクティビティログで「Status」フィールドが「Resolved」に更新された時点を特定して推定します。記録ステータスが「Resolved」に変更されたアクティビティログの記録から、タイムスタンプを取得します。イベントタイプ inferred
	インシデント終了	インシデントの記録を正式に終了したことを示します。通常は「Resolved」の状態が一定期間続いた後に自動で終了しますが、担当者が手動で終了することもできます。このイベントをもって、インシデントのライフサイクルが終了します。
重要な理由このアクティビティは、プロセスの明確な終点です。このイベントまでの合計時間は、ユーザーの確認待ち期間を含む、インシデントのライフサイクル全体の所要時間を表します。入手先アクティビティログで「Status」フィールドが「Closed」に更新された時点を特定して推定します。記録ステータスが「Closed」に変更されたアクティビティログの記録から、タイムスタンプを取得します。イベントタイプ inferred
	ステータスを対応中に変更	インシデントの調査と対応を正式に開始したことを示します。担当者がインシデントのステータスを「対応中」に変更したときに記録されます。チケットのアクティビティ履歴に記録される標準的なステータス変更です。
重要な理由この節目により、待ち時間と実際の作業時間を区別できます。インシデントが「対応中」の状態にとどまる時間を分析すると、解決に必要な作業を把握できます。入手先インシデントのアクティビティログで「ステータス」フィールドが「対応中」に更新された時点を特定して推定します。記録アクティビティログからステータスが「対応中」に変更された記録を抽出し、そのタイムスタンプを使用します。イベントタイプ inferred
	解決メモを追加	担当者が解決メモを追加し、インシデントの解決策を文書化したときに発生します。Freshserviceでは、ステータスを「解決済み」に変更する前に行う個別の操作です。この操作と内容は明示的に記録されます。
重要な理由解決策が特定されたことを示します。この時点から「インシデントを解決済みにする」までの時間は、社内レビューや文書化にかかる負荷を示す場合があります。入手先インシデントに解決メモが追加された時刻を、会話履歴の記録から取得します。記録インシデントの会話ログから「解決メモ」の記録時刻を特定します。イベントタイプ explicit
	SLA目標未達	インシデントの経過時間が、応答または解決に関して定められたSLA目標を超えたときに発生する、計算上のイベントです。FreshserviceではSLAの状態が内部で追跡されており、タイムスタンプとSLAポリシーを照合してこのイベントを導出できます。
重要な理由サービスレベルの取り決めへのコンプライアンスを直接測定します。SLAパフォーマンスダッシュボードや継続的な改善に役立てるには、未達がいつ、なぜ発生するのかを特定することが重要です。入手先解決または応答のタイムスタンプとSLA目標の期限を照合して算出します。Freshserviceでは、チケットに「SLA Violated」のフラグが付くことがよくあります。記録「Resolved at」のタイムスタンプと「Due by」のタイムスタンプを照合するか、「SLA Status」フィールドが「Violated」に変更された時点から導出します。イベントタイプ calculated
	インシデントを再割り当て	インシデントが別の担当者またはグループに移されたことを示します。解決プロセスで引き継ぎが発生したことを表します。最初の割り当て後に「担当者」または「グループ」フィールドが変更されたことを検出して推定します。
重要な理由再割り当てや引き継ぎが頻繁に発生する場合、プロセスの非効率、知識不足、初期の振り分けミスが考えられます。これらのイベントを分析することで、遅延の原因を特定し、削減できます。入手先最初の割り当て後に「担当者」または「グループ」フィールドが変更された記録を、インシデントのアクティビティログから追跡して推定します。記録チケットの監査履歴で「担当者」または「グループ」フィールドの変更を検出します。イベントタイプ inferred
	インシデント再オープン	「Resolved」とマークされたインシデントがオープン状態に戻ったときに発生します。通常は、ユーザーが解決内容に同意しない場合に起こります。「Resolved」から「Open」や「In Progress」などにステータスが変わったことから推定します。
重要な理由再オープン率が高い場合、解決の品質に問題があるか、修正が不完全である可能性があります。手戻りや担当者のパフォーマンスを分析するうえで重要な指標です。入手先アクティビティログで、「Resolved」からアクティブなステータスへの変更を検出して推定します。記録アクティビティログを絞り込み、「Status」が「Resolved」から「Open」または「In Progress」に変更された記録を確認します。イベントタイプ inferred
	ステータスを保留中に変更	通常はユーザーや第三者からの情報を待つ間など、解決プロセスが一時停止した時点を示します。「保留中」のいずれかの状態へのステータス変更から推定します。この状態に費やした時間は、SLAの計算から除外されることがよくあります。
重要な理由保留状態の時間を特定することは、外部への依存や遅延を把握するうえで重要です。担当者の作業時間と待ち時間を切り分けられます。入手先「ステータス」フィールドが「保留中」や「ユーザーの回答待ち」などに更新されたとき、インシデントのアクティビティログから推定します。記録アクティビティログから保留状態へのステータス変更を抽出し、該当するタイムスタンプを使用します。イベントタイプ inferred
	初回応答を送信	インシデントの報告後、担当者がユーザーに初めて連絡したことを示します。公開メモまたは直接の返信が該当します。Freshserviceでは、担当者からのすべての連絡がタイムスタンプとともに記録されます。
重要な理由初回応答のSLA達成は、顧客満足度を測る重要業績評価指標（KPI）です。このアクティビティを使って、新しいインシデントに担当者がどれだけ早く対応しているかを測定・分析できます。入手先インシデントの会話ログで、担当者が追加した最初の公開メモまたは返信のタイムスタンプを特定します。記録インシデントの会話履歴を確認し、担当者が記録した最も早い項目を抽出します。イベントタイプ explicit
	回避策を提示	インシデントの影響を抑えるため、一時的な解決策や回避策をユーザーに伝えたことを示します。取得には、専用のチェックボックス、特定のメモ種別、担当者のメモに対するキーワード分析など、システムの設定が必要になる場合があります。
重要な理由回避策が業務への影響を抑える効果や、最終的な解決時間との関係を分析できます。回避策の効果を測るダッシュボードにも役立ちます。入手先明示的なイベントとして記録されない可能性があります。「回避策」などのキーワードを含むメモにフラグを付けるか、カスタムの「回避策を提示」チェックボックスフィールドを使用し、その変更を記録して推定できます。記録カスタムフィールドの変更、または担当者のメモに対するキーワード分析から推定します。イベントタイプ inferred
	担当者をインシデントに割り当て	特定の担当者がインシデントを処理するために割り当てられた時点を示します。チケットの担当者が決まったことを表します。チケットのアクティビティ履歴には、割り当てられた担当者と時刻が記録されます。
重要な理由担当者の業務負荷やパフォーマンス、グループへの割り当て後に個人が対応を開始するまでの時間を分析できます。担当者のパフォーマンスを示すダッシュボードに欠かせない情報です。入手先インシデントのアクティビティログまたは監査履歴で「担当者」フィールドの変更を追跡します。記録「担当者」フィールドが変更されたタイムスタンプを特定します。イベントタイプ inferred

推奨任意

データ抽出ガイド

Freshserviceからデータを取得する方法

ステップ

Freshserviceの分析にアクセス：レポートへのアクセスと作成が許可されたアカウントでFreshserviceにログインします。メインメニューから分析モジュールを開きます。
新しいレポートを作成：新しいレポートボタンをクリックします。「インシデント管理イベントログ」など、内容が分かる名前を付けます。データソースの選択を求められたら、インシデント管理モジュールを選択します。
レポートウィジェットを選択：レポートエディターで新しいウィジェットを追加し、種類としてテーブルを選択します。これがイベントログデータの基礎になります。
主要なデータ列を追加：右側のデータソースパネルから必要なフィールドをドラッグし、テーブルの列設定に追加します。まず、インシデントID、作成日時、エージェント、グループ、優先度、重大度、ステータス、カテゴリを追加します。
アクティビティデータを追加：個々のイベントを記録するには、チケットのアクティビティデータを結合するか、レポートに含める必要があります。ウィジェットにアクティビティデータソースを追加します。このデータソースから、実行日時（イベントのタイムスタンプ）と、発生した変更を示すアクティビティの説明などのフィールドを追加します。
計算列「ActivityName」を作成：ここが最も重要な手順です。新しい計算列または数式フィールドを作成します。ネストしたIF文またはCASE関数を使い、生のアクティビティデータを必要なActivityNameの値に変換します。14種類のアクティビティそれぞれの詳細なロジックについては、クエリのセクションを参照してください。
「EventTimestamp」を設定：EventTimestamp用の計算列をもう1つ作成します。「インシデント報告」アクティビティには作成日時を、それ以外のイベントにはアクティビティの実行日時を設定するロジックにします。
レポートのフィルターを設定：データを絞り込むため、レポートフィルターを設定します。最低限、「作成日時」フィールドに日付範囲フィルターを設定してください。過去3～6か月の範囲を推奨します。また、「チケット種別」が「インシデント」のチケットだけを含めるフィルターも追加します。
レポートを実行して調整：レポートを実行し、データのプレビューを生成します。ActivityName列とEventTimestamp列に正しい値が設定されていることを確認します。必要に応じて数式やフィルターを調整してください。
レポートを保存してエクスポート：出力内容を確認したら、レポートを保存します。エクスポートを選択し、形式としてCSVを指定します。
エクスポートをスケジュール（任意）：継続的に分析する場合は、レポートの実行とエクスポートを自動化できます。スケジュール（毎日または毎週など）を設定し、CSVをメールまたは別の保存先に送信します。
アップロード用にデータを準備：エクスポートしたCSVファイルを開きます。列見出しをProcessMindで必要なスキーマに合わせて、IncidentId、ActivityName、EventTimestamp、AssignedAgent、AssignedGroupなどに変更します。固定列SourceSystem（値は「Freshservice」）とLastDataUpdate（現在のタイムスタンプ）を追加します。これでファイルをアップロードできます。

設定

分析モジュール：この方法でデータを抽出するには、Freshserviceの分析モジュールへのアクセスが必要です。このモジュールは上位プラン（Pro、Enterpriseなど）で利用できます。
必要な権限：ユーザーアカウントには、分析モジュールでレポートを作成、編集、実行できるロールが必要です。
日付範囲：データ量を調整するため、インシデントの作成日に日付範囲フィルターを設定してください。過去3～6か月を対象にすると、過去の状況を把握しながら処理性能も保ちやすくなります。
レポートフィルター：プロセス分析にサービスリクエストや他の種類のチケットが含まれないよう、「チケット種別」が「インシデント」の条件を必ず設定してください。
計算フィールド：各イベントのActivityNameとEventTimestampを求めるため、計算フィールド（数式）を多く使用します。Freshserviceの数式エディターの操作に慣れていると便利です。
データ量：この方法では、インシデントごとに複数の行（アクティビティごとに1行）が生成されます。大規模なFreshservice環境では、CSVファイルが非常に大きくなり、レポートの生成やエクスポートに時間がかかる場合があります。

クエリの例 config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

ステップ

事前準備：Python 3.6以降と、requestsおよびpandasライブラリがインストールされていることを確認します。pip install requests pandasを実行してインストールできます。
APIキーを取得：管理者としてFreshserviceにログインします。右上のプロフィール画像をクリックしてプロフィール設定を開きます。「APIキー」セクションに移動し、個人用APIキーをコピーします。このキーはパスワードと同様に取り扱ってください。
スクリプトを準備：提供されたPythonコードを、ローカルマシン上のextract_freshservice_incidents.pyという名前のファイルに保存します。
パラメーターを設定：テキストエディターでスクリプトファイルを開きます。FRESHSERVICE_DOMAIN（例：「yourcompany.freshservice.com」）、API_KEY（コピーしたキー）、START_DATE_STR（抽出期間の開始日。「YYYY-MM-DD」形式）のプレースホルダー値を更新します。
スクリプトの処理を確認：スクリプトはまず、指定した開始日以降に作成されたすべてのインシデントチケットを取得します。APIから返された結果の各ページを順に処理し、チケットごとにAPIを再度呼び出して、詳細なアクティビティ履歴を取得します。
イベントログを作成：スクリプトはチケットの基本データとアクティビティログを処理し、必要な14種類の業務アクティビティのレコードを作成します。たとえば、「インシデント報告」はチケットの作成日から作成し、「対応中へのステータス変更」はアクティビティログの特定の記録から導き出します。
複雑なイベントを導出：「SLA目標超過」などのイベントも導出します。チケットの解決SLAに違反したかを確認し、違反している場合は、期限日時をイベントのタイムスタンプとして記録します。
スクリプトを実行：ターミナルまたはコマンドプロンプトを開き、スクリプトを保存したディレクトリに移動して、python extract_freshservice_incidents.pyを実行します。
実行状況を確認：処理したチケット数など、進捗状況がコンソールに表示されます。チケット数やAPIのレート制限によっては、完了まで時間がかかる場合があります。
出力を確認：スクリプトが完了すると、同じディレクトリにfreshservice_incident_event_log.csvというCSVファイルが作成されます。このファイルにはイベントログ全体が含まれます。
アップロードの準備：表計算ソフトでCSVファイルを開き、列（IncidentId、ActivityName、EventTimestampなど）に想定どおりの値が入っていることを確認します。これでProcessMindなどのプロセスマイニングツールにアップロードできます。

設定

FRESHSERVICE_DOMAIN：会社固有のFreshservice URL（例：mycompany.freshservice.com）です。スクリプトで必須のパラメーターです。
API_KEY：すべてのインシデントデータを読み取る権限を持つユーザーの個人用APIキーです。必須のパラメーターです。
START_DATE_STR：データ抽出の開始日です。「YYYY-MM-DD」形式で指定します。分析に役立つデータを得るため、最初は過去3～6か月分を抽出することを推奨します。
PAGE_SIZE：Freshservice APIで許可されている最大値の100に設定し、API呼び出し回数を抑えて処理性能を高めます。通常、この値は変更しないでください。
APIのレート制限：スクリプトには、各チケットの処理後にtime.sleep(1)を実行する基本的な待機処理が含まれています。FreshserviceのAPIレート制限を守るためのものです。大量のデータを扱う環境では、エラーを避けるために待機時間の調整が必要になる場合があります。
必要な権限：使用するAPIキーは、異なるサービスデスクグループにまたがる必要なチケットフィールドとアクティビティログすべてにアクセスできるよう、「SD Agent」ロール以上の権限を持つユーザーアカウント（専用のサービスアカウントなど）に属している必要があります。

クエリの例 python

import requests
import pandas as pd
import time
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

if __name__ == class="hl-string">"__main__":
    main()

ステップ

Freshserviceのプランと管理者権限で、Workflow Automatorのルール、Webhookアクション、インシデントへのアクセス、チケットのアクティビティ履歴へのアクセスが許可されていることを確認します。受信側のチームと、送信先エンドポイント、認証方式、TLS要件、データ保持ポリシーを確認してください。
Workflow Automatorを設定する前に、イベントの仕様を定義します。Webhookの送信1回につき、IncidentId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdate、AssignedAgent、AssignedGroup、IncidentPriority、IncidentSeverity、IncidentStatus、IncidentCategory、ResolutionSlaTargetTimeを含むJSONオブジェクトを1つ送信します。受信側では、元のWebhookペイロードと送信日時を保持するよう設定してください。
インシデント作成用のWorkflow Automatorルールを作成します。インシデント作成時に実行するよう設定し、「インシデント報告」アクティビティを送信するWebhookアクションを追加します。EventTimestampにはインシデントの作成日時を、ActivityNameにはIncident Reportedを設定します。
担当者、優先度、ステータス、連絡、メモ、SLA、クローズの変更に対する更新ルールを作成します。Freshserviceアカウントで利用できるインシデントフィールドとアクティビティ履歴を使って条件を設定します。該当するアクティビティが発生するたびに、各ルールから個別のWebhookイベントを送信してください。最終状態のインシデント情報だけをもとに、ProcessMindがアクティビティを推測することを前提にしないでください。
アクティビティの対応関係を明示的に設定します。Groupフィールドに初期値が設定されたときはIncident Assigned to Group、Agentフィールドに初期値が設定されたときはAgent Assigned to Incidentを送信します。Priorityが設定または変更されたときはIncident Prioritizedを送信します。条件を満たす最初の公開返信またはメモが記録されたときはFirst Response Sentを送信します。初回割り当て後にAgentまたはGroupが変更されたときはIncident Reassignedを送信します。該当するステータス変更時にはStatus Changed to In ProgressまたはStatus Changed to Pendingを送信します。設定済みの回避策を示す項目がある場合に限りWorkaround Providedを送信します。解決メモが追加されたときはResolution Note Added、ステータスがResolvedに変わったときはIncident Resolvedを送信します。設定したSLA違反条件を満たしたときはSLA Target Breachedを送信します。ステータスがResolvedからオープン状態に変わったときはIncident Reopened、Closedに変わったときはIncident Closedを送信します。
Webhookリクエストの本文をJSON形式に設定し、インシデントID、アクティビティ名、イベント時刻、ソースシステム、最終データ更新日時、および推奨されるコンテキスト属性を含めます。Freshserviceアカウントで利用できるWebhook変数を使用してください。必須の変数がWebhookエディターで利用できない場合は、承認されたFreshserviceインターフェースを呼び出して受信側サービスで値を設定するか、値を推測せず空欄にしてください。
エンドポイントで冪等性と配信処理を設定します。Freshserviceが安定したイベントIDを提供する場合は、それを使用します。提供されない場合は、IncidentId、ActivityName、EventTimestamp、送信元の配信IDから重複排除キーを作成します。ペイロードを確実に受け付けた後にのみ、成功を示すHTTPレスポンスを返してください。
テスト用のインシデントを使って各ルールを検証します。インシデントを作成し、グループとエージェントを割り当て、優先度とステータスを変更します。条件を満たす返信を送信し、設定に応じて回避策と解決メモを追加した後、解決、再オープン、クローズします。SLA違反については、テスト用のポリシーまたはキューを使って別途検証します。想定した各アクティビティが個別のWebhookペイロードとして届くことを確認してください。
Webhookペイロードを永続性のあるステージング領域に保存し、タイムスタンプを単一のタイムゾーンに統一して、各ペイロードをイベントログの1行に変換します。明示的に送信されたWebhookアクティビティごとに1行を保持してください。LastDataUpdateには、業務イベントの時刻ではなく、抽出または取り込みの更新時刻を設定します。
ステージングしたイベントログを検証し、完全に同一の重複配信のみを削除します。優先度の変更やステータス遷移が複数回発生した場合など、正当な繰り返しアクティビティは残してください。すべての行にIncidentId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdateが含まれていることを確認します。
正規化したイベントログをCSVまたはProcessMindが対応する別の形式でエクスポートします。列名にはIncidentId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdate、AssignedAgent、AssignedGroup、IncidentPriority、IncidentSeverity、IncidentStatus、IncidentCategory、ResolutionSlaTargetTimeをそのまま使用します。ファイルをアップロードするか、準備したイベントソースをProcessMindに接続し、IncidentIdをケース識別子、ActivityNameをアクティビティフィールドとして割り当てます。

設定

トリガーの範囲：インシデントの作成と各更新条件に対して、Workflow Automatorのルールを個別に設定します。受信側で厳密にアクティビティを対応付けない場合、広範な更新ルールを1つだけ設定すると、イベントが重複したり、内容が曖昧になったりする可能性があります。
Webhookペイロード：すべてのペイロードに必須属性を含めます。イベント発生時に取得できる場合は、推奨属性も含めてください。監査や再処理に備えて、生のペイロードを保持します。
アクティビティの意味：グループとエージェントの初回割り当ては、その後の変更と区別する必要があります。初回割り当て後の変更はIncident Reassignedとして記録し、初回設定はそれぞれの初回割り当てアクティビティとして記録します。
ステータスの処理：Freshserviceアカウントで設定されているステータス値を正確に対応付けます。独自の保留中またはオープンのステータスを使用している場合は、それぞれに明示的な対応関係を設定してください。
初回応答：公開返信、公開メモ、または別の連絡種別のどれを対象とするか定義します。定義を一貫して適用し、条件を満たす最初の連絡に限ってイベントを送信してください。
回避策の検出：専用フィールド、チェックボックス、メモの種類、または承認済みのキーワードルールを設定します。こうした設定がない場合、Workaround Providedを確実に特定できません。
SLA違反：SLA違反を検出する明示的なトリガーを設定するか、現在時刻とResolutionSlaTargetTimeを比較する別の定期処理を設定します。最終状態のインシデント情報だけでは、違反時刻を再構成できません。
日付範囲：初期検証では、過去3～6か月程度のインシデントを対象にします。リアルタイム運用では、分析対象期間の開始前にデータ取り込みを始め、再処理に備えてWebhookの履歴を保持してください。
フィルター：承認済みの会社、ワークスペース、部門、サービス、カテゴリ、日付のフィルターのみを適用します。アカウント設定で確認できないFreshserviceのフィールド名やフィルター構文を前提にしないでください。
処理性能：Webhookを非同期で処理し、受信リクエストをキューに入れ、後続の書き込みをまとめて実行します。IncidentIdとEventTimestampにはインデックスを設定してください。Webhookの受信中に同期的なデータ補完を行わないでください。
信頼性：再試行、デッドレター処理、監視、重複抑止を設定します。配信に失敗した記録を残し、問題を修正した後に再処理してください。
前提条件：管理者アクセス、Workflow Automatorの利用環境、Webhook権限、HTTPSエンドポイント、認証設定、必要なFreshserviceプランの機能、ProcessMindに対応したデータ受け入れまたはアップロード手順が必要です。
セキュリティ：HTTPSを使用し、可能な場合は受信アクセスを制限します。認証情報を定期的に更新し、機密情報を含むフィールドを最小限に抑えてください。ペイロードにインシデントの説明やメモを含める場合は、適切に保護します。

クエリの例 config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

始める準備はできましたか？

このテンプレートを使ってデータを適切に設定し、インシデント管理ワークフローに関するインサイトを見つけてください。解決時間の短縮に向けて、今日から取り組みを始めましょう。

改善ガイドに戻る

テンプレートをダウンロード

SLA違反を防ぐ：今日からインシデント管理を改善

MTTRを35％短縮し、コストのかかるSLA違反を防いでいる企業に続きましょう。

無料トライアルを開始しましょう。

14日間無料でお試しいただけます。クレジットカードは不要です。

インシデント管理用データテンプレート

インシデント管理用データテンプレート

インシデント管理の属性

インシデント管理のアクティビティ

データ抽出ガイド

Freshservice分析モジュールからCSVにデータをエクスポート

ステップ

設定

クエリの例 config

Freshservice REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

クエリの例 python

Workflow AutomatorのWebhookによるリアルタイムデータ送信

ステップ

設定

クエリの例 config

始める準備はできましたか？

SLA違反を防ぐ：今日からインシデント管理を改善