インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説【2026年版】

インシデント管理（Incident Management）とは、ITサービスの予期しない停止や品質低下（インシデント）が起きたとき、可能なかぎり早くサービスを復旧させ、業務への影響を最小に抑えるための一連のプロセスです。ITILではこれを「暫定的でよいので、まず正常な状態に戻す」対応と位置づけます。この記事では、インシデント管理の定義と障害対応・問題管理との違い、ITIL準拠の検知から終結までのフロー、そして監視アラート連携・重大度（SEV）分類・オンコール・Runbook・MTTR計測といった実装面までを、IT運用と受託開発の目線で整理しました。最後に、自社で仕組み化するか外部の保守運用に委ねるかの判断軸も示します。

まとめ｜インシデント管理の目的とITIL準拠フローの実装勘所

インシデント管理は「原因を突き止めること」ではなく「まずサービスを戻すこと」を目的にした運用プロセスです。根本原因の除去は問題管理という別プロセスが担い、両者を分けて回すことで、復旧の速さと再発防止の両立が狙えます。設計の第一歩は、何をインシデントとして起票し、誰がどの基準で優先度を判断するかを先に決めることにあります。

実装の結論は3点あります。第一に、監視アラートとチケット管理を連携させ、インシデントの検知・記録を自動化しておくと初動が速くなります。第二の勘所は、重大度（SEV）とエスカレーション経路を事前に決め、オンコール体制で「誰が拾うか」を曖昧にしない体制づくりです。第三に、復旧後はポストモーテムで学びを残し、Runbookとして仕組みに戻すことで、次の同種インシデントのMTTR（平均修復時間）が縮みます。復旧速度の測り方は主に別記事で扱うため、ここでは管理プロセス側の実装に集中します。

インシデント管理とは何か、障害対応・問題管理との違いを整理する

言葉の切り分けから始めます。インシデント・障害・問題・サービス要求は現場で混同されやすく、起票の基準がぶれると管理そのものが破綻します。まず定義をそろえ、そのうえで管理プロセスの目的を確認しましょう。

インシデントと障害・問題・サービス要求の違いを実装目線で整理

ITILでのインシデントは「サービスの計画外の中断、または品質の低下」を指します。ユーザーが「メールが送れない」と申告すれば、それがインシデントです。一方の障害（障害＝故障）は、その中断を引き起こしているハードやソフトの不具合そのものを指すことが多く、インシデントの原因側に位置します。問題（Problem）は複数のインシデントの背後にある根本原因を意味し、サービス要求（Request）はパスワード再発行のような通常運用の依頼です。下表のように起票のカテゴリを分けておくと、対応チームと計測の粒度がそろいます。

この区分が曖昧だと、パスワード再発行までインシデントとして数えてしまい、指標が意味を失います。起票フォームの選択肢に区分を持たせ、入口で仕分ける設計にしておきましょう。

インシデント管理の目的＝暫定復旧と、問題管理の根本原因除去の違い

インシデント管理の目的は、影響を受けているユーザーを一刻も早く元の状態に戻すことです。極端に言えば、原因が分からなくても回避策（ワークアラウンド）でサービスが戻れば、その時点で目的は達成されます。対して問題管理は、なぜ壊れたのかを時間をかけて突き止め、恒久対策で二度と起こさないことを目指します。この2つは求める速さも成果物も異なるため、同じ担当が同じ場で兼ねると、目の前の復旧を優先して根本対策が後回しになりがちです。復旧の速さと再発防止は、プロセスとして分けて回すのが定石になります。

ITIL準拠のインシデント管理プロセスを検知から終結まで追う

ITILのインシデント管理は、いくつかの決まった工程を順にたどります。工程を固定しておくと、担当者が替わっても対応の品質がぶれにくくなるのが利点です。ここでは初動・調査・終結の3段階に分けて流れを追います。

インシデントの検知・記録・分類および優先度づけまでの初動フロー

最初の工程は検知と記録です。検知の入口は、ユーザーからの問い合わせと、監視ツールのアラートの2系統に大きく分かれます。検知したら、いつ・何が・どの範囲で起きているかをチケットに記録するのが第一歩です。次に分類（カテゴリ付け）を行い、担当チームへ振り分けられる状態にします。そして優先度を、影響範囲（Impact）と緊急度（Urgency）の掛け合わせで決めます。全社に及ぶ停止なら最優先、一部ユーザーの軽微な不便なら低め、という判断を表で基準化しておくと、担当者の主観に左右されません。

優先度は復旧の順番と投入する人数を決める土台です。基準を明文化し、チケットの必須項目にしておくと、繁忙時でも仕分けが破綻しません。

エスカレーションと初期診断・調査から暫定対応での早期復旧まで

優先度が決まったら、一次対応チームが初期診断に入ります。既知の事象なら手順書に沿って回避策を当て、その場で暫定復旧を狙います。一次で手に負えない場合は上位へエスカレーションする段取りです。エスカレーションには2種類あり、より詳しい技術者へ渡す機能的エスカレーションと、管理者へ状況を上げる階層的エスカレーションを使い分けます。ここで大切なのは、原因究明に深入りしすぎないことです。インシデント管理の役目はあくまで復旧なので、再起動・切り離し・切り戻しといった回避策でサービスが戻るなら、原因の特定は問題管理に引き継ぎます。

解決・終結（クローズ）と問題管理・変更管理への確実な引き継ぎ

サービスが戻ったら、ユーザーに復旧を確認してもらい、チケットをクローズします。ここで対応内容・回避策・所要時間を記録として残す作業が、後の分析の材料です。根本原因が未解明のまま暫定復旧した場合は、問題管理へ「既知のエラー」として登録し、恒久対策の検討につなぎます。構成変更を伴う恒久対策は、変更管理のプロセスへ回すのが定石です。終結時の記録が薄いと、同じインシデントが再発したときにゼロから調べ直すことになり、対応時間が膨らみます。クローズは事務作業ではなく、次の初動を速くするための投資だと捉えましょう。

インシデント管理を実装する監視連携・チケット・オンコール設計

プロセスを紙の手順で終わらせず、ツールに落とし込むのが実装の勘所です。ここでは検知の自動化、重大度とオンコール、そして学びを残すRunbookの3点を具体化します。

監視アラートとチケット管理を連携するインシデント起票の自動化

初動を速くする最短の一手は、監視アラートからチケットを自動起票する連携です。CPU・メモリ・応答時間・エラー率などの監視でしきい値を超えたら、ITSMツールにインシデントを自動生成し、担当チームへ通知が飛ぶように組みます。人の申告を待たずに検知できれば、気づくまでの時間（MTTD）が縮み、復旧全体も前倒しになるのが利点です。アラートの検知・相関・ノイズ削減をAIで支える発展形についてはAIOpsとは？IT運用×AIの仕組みと主要機能で扱っています。ただし自動起票は、しきい値が甘いとアラート疲れを招くため、鳴らす条件は「対応が必要なものだけ」に絞る設計が前提です。

重大度（SEV）レベルの分類とオンコール体制のエスカレーション

優先度（P1〜P4）とは別に、障害の深刻さを表す重大度（SEV：Severity）を定義しておくと、呼び出しの基準が明確になります。SEV1は全面停止で全員招集、SEV2は主要機能の障害でオンコール担当が対応、といった具合に段階を決めます。オンコールは、時間帯ごとに一次受け担当を輪番で割り当てる仕組みで、深夜のSEV1でも「誰が拾うか」で迷わないための備えです。エスカレーション先と連絡手段（電話・チャット・呼び出しツール）を重大度ごとに紐づけておけば、通知が届かず放置される事故を防げます。呼ばれる側の負荷を平準化する輪番設計も、体制を続けるうえで見落とせません。

Runbookとポストモーテムで再発防止とMTTR短縮につなげる

同じインシデントを二度目から速く倒すには、対応をRunbook（手順書）として残します。「この症状ならまずこれを確認し、次にこう切り離す」という判断の道筋を書いておけば、経験の浅い担当でも一次対応をこなせるのが利点です。重大なインシデントの後には、犯人探しをしないポストモーテム（振り返り）を開き、時系列・影響・対応・改善案を記録します。この学びをRunbookや監視の改善に戻すループが、次の同種インシデントのMTTR（平均修復時間）を短縮する打ち手になります。MTTRの計測設計は別記事で詳しく整理しますが、管理プロセス側では「記録を残し、仕組みへ戻す」文化づくりが土台です。稼働率という上位の目標との関係は可用性とは？稼働率の計算と高可用性の設計と合わせて捉えると位置づけが掴めます。

インシデント管理を内製で仕組み化するか外部保守運用に委ねる判断

ここまでの実装をすべて自社で抱えるべきか、外部に任せるべきかは、運用の規模と体制で判断が分かれます。受託開発と保守運用の現場で見てきた採用条件と、見送るべき場面を条件付きで言い切ります。

自社で仕組み化すべき条件と、外部の保守運用へ委ねるべき場面とは

自社で仕組み化すべきなのは、次の条件がそろう場合です。24時間の自社サービスを持ち、インシデントの頻度が週に複数回あり、オンコールを回せる人数（最低でも4〜5名）を確保できるなら、内製の投資は回収できます。ドメイン知識が復旧速度に直結するプロダクトも、内製が向きます。逆に、夜間・休日の障害が月に数回程度で、専任の運用要員を置けない規模なら、外部の保守運用に一次対応を委ねるほうが現実的です。中途半端に内製し、担当1名に依存して属人化させるのは、その人が倒れた瞬間に復旧体制が崩れる最も危うい選択になります。問い合わせ窓口としての一次受けを整理したい場合は、役割の異なるヘルプデスクとは？仕事内容とサービスデスクとの違いも参照すると、窓口業務とインシデント管理の切り分けが整理できます。

受託開発・保守運用でインシデント対応の体制を仕組みに落とす手順

外部に委ねる場合でも、丸投げでは機能しません。委託の成否は、復旧の目標時間（許容MTTR）とエスカレーション経路を契約に明記できるかで決まります。私たちが受託開発から保守運用まで一貫して手がける際は、監視の設計・アラートの自動起票・Runbookの整備・オンコールの取り決めまでを一つの仕組みとして構築し、開発したチームがそのまま運用を担うことで、障害時の原因特定が速まる体制です。開発と運用を分断せず、コードとインフラの両方を理解した体制でインシデント対応を回したい場合は、保守運用・内製化支援で、監視から復旧・再発防止までの仕組み化を支援しています。内製化を見据えた伴走も含め、自社に体制を残す形での引き継ぎが可能です。

よくある質問

インシデント管理と問題管理は何が違いますか？

目的が違います。インシデント管理はサービスを早く元に戻す「暫定復旧」が目的で、原因が未解明でも回避策で戻れば役目を果たします。問題管理は根本原因を突き止めて「再発防止」する恒久対策が目的です。速さを求めるインシデント管理と、確実さを求める問題管理は、プロセスとして分けて回すのが基本になります。

インシデント管理でMTTRはどう使いますか？

MTTR（平均修復時間）は、インシデントが起きてから復旧するまでの平均時間で、対応プロセスの速さを測る代表指標です。検知・対応・復旧の内訳を分けて計測し、どの工程が長いかを可視化すると改善点が見えます。数値だけを追うと恒久対策が後回しになりやすいため、再発防止の指標と併せて読むのが要点です。

インシデントの優先度はどう決めればよいですか？

影響範囲（Impact）と緊急度（Urgency）の掛け合わせで決めます。全社に及ぶ停止は最優先、一部ユーザーの軽微な不便は低め、というように基準を表で明文化し、チケットの必須項目にしておきましょう。担当者の主観に頼らず、入口で優先度が決まる仕組みにすると、繁忙時でも仕分けが破綻しません。

インシデント管理表は何を記録すべきですか？

発生日時・検知経路・影響範囲・優先度・対応者・実施した回避策・復旧日時・根本原因の有無を残します。特に「対応の時系列」と「暫定か恒久か」を記録しておくと、後の分析とMTTRの内訳把握に役立ちます。終結時の記録が薄いと再発時にゼロから調べ直すことになるため、クローズ時の記入を必須にしておきましょう。

小規模なチームでも仕組みは必要ですか？

必要です。規模が小さいほど属人化しやすく、担当者の不在で復旧が止まるリスクが高まります。高価なツールを入れずとも、起票の基準・優先度の表・簡単なRunbookを用意するだけで、対応のばらつきは大きく減ります。まずは記録を残す習慣と、誰が一次対応するかの取り決めから始めるとよいでしょう。

関連記事

• MTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説（復旧速度の計測指標）
• AIOpsとは？IT運用×AIの仕組みと主要機能・MLOpsとの違いを実装目線で解説（検知と対応の自動化）
• 可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説（稼働率とMTTRの上位設計）
• ヘルプデスクとは？仕事内容と種類、サービスデスクとの違い・属人化を防ぐ仕組み化を解説（問い合わせ窓口の役割）