インシデント管理プロセス：受付からクローズまでの手順・役割・対応時間の目安

要点： インシデント管理プロセスは、サービスの障害を受付からクローズまで決まった順序で進める仕組みです。検知と記録、分類、優先度付け、調査、解決、クローズの順に進めます。目的は、通常のサービスをできるだけ早く回復し、業務への影響を抑えることです。各ステップに担当者、次へ進む条件、時間の目安を決め、次の担当者が利用者に聞き直さなくて済むよう、チケットに十分な記録を残します。

中小企業で、日々のインシデント対応の流れを作る、または整理したい情シス担当者やサービスデスクのリーダー向けの内容です。読み終えると、手順を文書にし、役割を決め、時間の目安を設定し、チケットのひな形を使えるようになります。重大インシデント（まれに起きる大規模障害）は別のプロセスで扱うため、重大インシデント管理をご覧ください。この記事は通常のライフサイクルを扱います。

インシデントとは

ウィキペディアのインシデント管理の概要（2026年10月28日確認）によると、ITIL 2011はインシデントを、ITサービスの計画外の中断、サービス品質の低下、またはまだサービスに影響していない構成アイテムの障害と定義しています。同じ記事は、このプロセスの目的を、通常のサービス運用をできるだけ早く回復し、業務への影響を最小限にすることと説明しています。

ITIL 4は2019年2月に公開され、指針を「プロセス」ではなく「プラクティス」として整理しているため、ITIL 4ではインシデント管理プラクティスと呼ばれることがあります。以下の手順はサービスデスクで一般的な進め方であり、ITILへの準拠を主張するものではありません（2026年10月28日確認）。

ここから二つのことがわかります。

1. まずサービスを回復する。 根本原因の特定は別のプロセス（問題管理）です。インシデントは回避策でクローズできます。
2. 依頼はインシデントではない。 新入社員のPCやアクセス権の申請は、サービスリクエストとして別の流れで扱います。境界線はサービスリクエストとインシデントの違いで説明しています。

6つのステップ

手順の数え方は資料によって違い、検知・記録・分類のまとめ方により5段階、6段階、7段階などになります。実際の順序は同じです。チームが覚えやすい区切りを使ってください。

ステップ1：検知と記録

目的： すべてのインシデントを、番号付きのチケットにする。

1. すべての窓口からの連絡を受け付けます。ポータル、メール、電話、チャット、監視からの自動アラート。
2. 最初の連絡の時点でチケットを作ります。直す前に起票します。
3. 誰が、どのサービスで、何が起きているか（正確なエラー文言またはスクリーンショット）、いつからか、連絡先を記録します。
4. 重複や既知の問題でないか確認します。障害がすでに起票されていれば、新しいチケットを紐づけます。

担当： サービスデスク（L1）。時間の目安の例： 連絡から数分以内に記録。

ステップ2：分類

目的： 正しい区分に入れ、適切な担当へ届ける。

1. 短く固定された一覧からカテゴリーとサブカテゴリーを選びます。例：メール、ネットワーク、端末、アプリケーション、アカウント、セキュリティ。
2. 構成アイテムを管理している場合は、影響を受けるサービスと構成アイテム（機器やシステム）を紐づけます。
3. セキュリティインシデントの疑いがあればこの時点で印を付け、すぐにセキュリティ対応の経路へ送ります。

担当： サービスデスク。カテゴリーの一覧は短くします。長いと、入力が雑になります。

ステップ3：優先度付け

目的： どのくらい急ぐかを決める。

1. 影響度（何人、どの範囲の業務に影響するか）と緊急度（業務がどれだけ早い復旧を必要とするか）を設定します。
2. 影響度と緊急度のマトリクスから優先度を決めます。重大度と優先度は別のものです。各レベルと応答目標の対応はP1〜P4の優先度レベルで説明しています。
3. 状況が変わったら、サービスデスクが優先度を変更でき、理由を記録します。

担当： サービスデスク。最上位の優先度ではインシデントマネージャーも加わります。時間の目安： 最初の応答目標の計測が始まる前に、優先度を決めておきます。

ステップ4：調査と切り分け

目的： 修正方法または回避策を見つける。

1. L1での初期調査。 ナレッジベースと手順書を使い、チケットにまだない情報を質問します。既知の対処法なら実行します。
2. エスカレーション： L1の範囲を超える、時間の目安を過ぎる、またはリスク（データ消失、セキュリティ、広範囲の影響）がある場合。誰が何をするかはL1・L2・L3の区分で決め、連絡先はエスカレーションマトリクスのひな形をご覧ください。
3. エスカレーションのたびに引き継ぎメモを書く。 何に影響があるか、何を試したか、次に何が必要か。
4. 優先度ごとに決めた間隔で利用者に状況を伝える。 進展がなくても伝え、次の連絡時刻を知らせます。
5. ベンダー： 原因が製品の不具合に見える場合はベンダーにケースを起票し、ケース番号をチケットに記録します。

担当： 最初はL1、その後L2、L3、または対応チーム。時間の目安の例： 優先度ごとのエスカレーション時刻になっても進展がなければ、上位へ。

ステップ5：解決と復旧

目的： 利用者側でサービスが使える状態に戻る。

1. 修正または回避策を実施します。標準の範囲を超える変更は変更管理に、緊急の変更は緊急の経路に従います。
2. システムが正常に見えるだけでなく、利用者に実際に使えることを確認します。
3. 解決内容を記録します。何をしたか、なぜ効いたか、回避策か恒久対処か。
4. 原因が不明、あるいは回避策にとどまる場合は、後日原因を調べるために問題レコードを起票します。
5. チケットを「解決済み」にし、利用者へ連絡します。

担当： 対応した人。時間の目安： その優先度の解決目標。

ステップ6：クローズ

目的： きれいで検索しやすい記録を残す。

1. 利用者に確認する。 または、一定期間返信がなければ自動クローズします。目安は数営業日で、自社で決めて利用者に伝えます。
2. 記録を点検する。 カテゴリーが正しい、解決内容が書かれている、作業時間が記録されている、関連レコードが紐づいている。
3. このチケットで得た知見があればナレッジベースを更新する。
4. クローズする。 クローズ後は、新しいチケット、または取り決めた期間内のフォローアップで再開します。

担当： サービスデスク。毎月、クローズ済みチケットを抜き取って品質を確認するチームも多くあります。

役割

小さなチームでは役割を兼任します。大事なのは、各役割に責任者がいることです。

1. 依頼者（利用者）： インシデントを報告し、質問に答え、修復を確認する。
2. サービスデスク担当（L1）： 記録、分類、優先度付け、既知の対処、利用者への連絡。
3. 対応担当（L2、L3、専門チーム）： L1を超える調査と修復。
4. インシデントマネージャー（またはサービスデスクのリーダー）： キューと時間の目安を見守り、滞留した、または優先度の高いチケットを引き取り、エスカレーションを進める。重大インシデントでのこの役割は別の解説にあります。
5. 問題管理者： 原因の調査が必要なときに引き継ぐ。
6. 変更管理者または承認者： 変更が必要な修復を承認する。
7. サービスオーナーとベンダー： 担当するサービスや製品について判断と支援を行う。

対応時間の目安の例

以下は例示の目標であり、標準ではありません。実際の値はSLAで決まります。Brocentが公開している応答目標はSLAのページにあります。

1. P1（緊急）の例： 数分以内に応答し、頻繁に利用者へ連絡し、進展がなければ直ちにエスカレーションして、回復まで対応を続ける。
2. P2（高）： 1時間以内に応答し、決めた短い時間で解決しなければエスカレーションする。
3. P3（中）： 営業日内に応答し、数日以内に解決する。
4. P4（低）： 1〜2日以内に応答し、より長い期間のなかで余力に応じて解決する。

計測する時間は3つ定義します。応答までの時間、エスカレーションまでの時間、解決までの時間。解決のタイマーを止めるのは、利用者の返信待ちなど、定義した理由がある場合に限ります。

チケットのひな形

よいチケットには次の項目があります。お使いのツールにコピーしてください。

概要:          1行、症状 + サービス
依頼者:        氏名、連絡先、場所
影響範囲:      何人、どのサービス/機器
症状:          利用者の言葉、正確なエラー、画面
発生時刻:      日時、直前の変更
カテゴリー:    カテゴリー / サブカテゴリー
影響度/緊急度: それぞれ 高/中/低 -> 優先度
実施した対応:  手順、結果、担当、時刻
エスカレーション先: チーム/担当、理由、時刻
次回連絡:      日時
解決内容:      何で直ったか、回避策か恒久対処か
問題レコード:  有/無、ID

よくある失敗

1. 直してから記録する。 起票されない即時対応は、レポートにもナレッジベースにも残りません。
2. 声の大きさで優先度を決め、連絡もしない。 影響度と緊急度のルールを使い、予定どおりに連絡します。利用者は遅れより、連絡がないことに腹を立てます。
3. 確認なしでクローズする。 再オープンと不満の原因になります。
4. 引き継ぎメモがない。 利用者がレベルごとに同じ質問に答えることになります。
5. 回避策を最終対応と見なす。 原因が不明なら問題レコードを起票します。
6. 依頼とインシデントを混ぜる。 件数とSLAの数字が歪みます。

プロセスが機能しているかの確認方法

1. クローズ済みのチケットを無作為に5件選ぶ。それぞれに、誰が、何が、いつ、実施した手順、解決内容、時刻が残っている。
2. エスカレーション時刻を過ぎたまま、メモのないオープンチケットがない。
3. 利用者が、決めた予定どおりに連絡を受けている。
4. 月次の数字が妥当である。カテゴリー別の件数、優先度別の応答・解決時間、再オープン率。指標の定義はMTTR・MTBF・MTTAを参照してください。
5. 繰り返し起きるインシデントが、問題レコードとナレッジ記事につながっている。

よくある質問

インシデント管理プロセスとは何ですか？

ITの障害を受付からクローズまで導き、サービスを素早く回復して業務への影響を抑えるための一連の手順です。記録、分類、優先度付け、調査、解決、クローズの順に進みます。

インシデント管理の手順にはどんなものがありますか？

検知と記録、分類、優先度付け、調査と切り分け、解決と復旧、クローズです。フレームワークによって手順の分割や統合が異なるため、資料によって5段階、6段階、7段階の説明があります。

5ステップのインシデント管理プロセスとは何ですか？

よくある5段階の区切りは、特定と記録、分類と優先度付け、調査と切り分け、解決と復旧、クローズです。6ステップと順序は同じで、そのうち二つをまとめたものです。

インシデント管理の6つのステップとは何ですか？

記録、分類、優先度付け、調査、解決、クローズです。出典によって区切りは違うため、チームが一貫して運用できる版を選んでください。

次のステップ

優先度ごとに公開している応答目標は、SLAのページでご確認ください。

2026年10月28日に確認した情報源：ウィキペディア「Incident management」（en.wikipedia.org/wiki/Incident_management）。ITIL 2011の定義が引用されています。