2026年のインシデント管理: LLM が当然化した世界
- 年まで、インシデント管理 SaaS は「オンコールローテーション」「エスカレーション」「ステータスページ」「postmortem テンプレート」の四機能をいかに洗練するかが競争軸だった。2026年の現在、これらは全てコモディティ化し、差別化要因は LLM 支援機能に移った。タイムラインを自動生成するか、影響範囲を自動推定するか、postmortem の下書きをどこまで書けるか、action item の進捗をどう追跡するか——この四点で各社は激しく競っている。
本稿では PagerDuty、Incident.io、Rootly、FireHydrant の四製品を 2026年 Q1 時点の実運用観点で比較し、LLM 支援がもたらす MTTR（Mean Time To Resolution）削減の定量効果を整理する。
PagerDuty: 既存機能の深化と AIOps 強化
PagerDuty はインシデント管理 SaaS の草分けで、2026年現在も市場シェア首位を維持する。強みはオンコール管理の成熟度で、複雑なローテーション、休暇連動、follow-the-sun 体制、エスカレーションポリシーの柔軟性は他社を抑えて最強である。加えて AIOps 機能が 2025年に大幅強化され、アラート相関ルールを LLM が自動提案し、ノイズアラートのグルーピングが従来比で大幅に減った。
LLM 支援 postmortem としては PagerDuty Advance（2025年 GA）が提供され、Slack の会話ログと Change Events（デプロイ履歴）を統合して postmortem 下書きを自動生成する。ただし Incident.io や Rootly と比較すると、インシデントプロセス全体のオーケストレーション機能は弱く、「通知とオンコールは強いが、インシデント中の進行管理は他ツールに劣る」という評価が定着している。
Incident.io: Slack-native な完結体験
Incident.io は 2021年創業の英国発 SaaS で、2025年に急速にシェアを伸ばした。思想は明確——「インシデント対応は Slack で完結する」。`/incident` スラッシュコマンドで起票、専用チャンネルを自動生成、ロール（incident commander、communications lead、scribe）を Slack UI で割当、ステータス更新も Slack で完結する。
LLM 支援は AI Scribe 機能が特筆される。インシデントチャンネルの会話を常時要約し、「現在の状況」「直近の判断」「未解決の論点」を Slack 上に pin 表示する。対応が長引くほど状況整理が追いつかなくなる問題を、LLM が常に解決する。終息後は会話ログ全体から postmortem の「何が起きたか」「いつ何を試したか」「有効だった対処」を時系列で生成し、人間はレビューと追記だけで公開できる。
弱点はオンコール管理で、PagerDuty ほど複雑なローテーションは組めない。そのため大企業では「オンコールは PagerDuty、対応プロセスは Incident.io」の併用パターンが定着している。
Rootly: Slack + GitHub + Jira の統合ワークフロー
Rootly は 2020年創業の米国発 SaaS で、Incident.io と思想が近いが、開発者ワークフローとの統合に重点を置く。特徴は Runbook の宣言的定義で、Git で管理された YAML ワークフローが「インシデントの重要度が SEV1 に上がったら、特定チャンネルに通知、Zoom Bridge 自動作成、ステータスページ更新、特定 Jira プロジェクトにチケット作成」といった一連を自動化する。
LLM 支援機能 Rootly AI は 2025年後半に大幅拡張され、(1) 類似過去インシデントの自動検索（ベクトル検索）、(2) 影響範囲の自動推定（関連サービス・依存関係からの逆引き）、(3) postmortem 下書き生成、(4) action item の自動追跡（Jira 連携で完了状況を Rootly 側に反映）の四本柱となった。特に類似インシデント検索は有用で、「過去に同様のアラートが出た際はどう対処したか」を平均数秒で提示する。
FireHydrant: コンプライアンス重視の設計
FireHydrant は米国発 SaaS で、コンプライアンス・監査の要件が強い業界（金融、医療、政府系）で採用が進む。差別化は「エビデンス保全」で、インシデント発生時の全アーティファクト（Slack ログ、PagerDuty アラート、デプロイ差分、ダッシュボード画像）を暗号化・改ざん防止で保存する。SOC 2、ISO 27001、HIPAA の監査で「この期間のインシデント対応記録を提示せよ」という要求に対し、ワンクリックでエビデンスパッケージを出力できる。
LLM 支援も postmortem 生成を提供するが、医療・金融向け設定では「LLM が生成した文章は必ず人間が承認するまで外部共有不可」というワークフロー強制が可能。プライバシー境界を守りたい組織にとって重要な特徴である。
タイムライン自動生成の実装詳細
LLM 支援機能の中核がタイムライン自動生成だ。従来、インシデント終息後に scribe（記録係）が Slack ログを遡り「10:23 アラート発報、10:25 on-call engineer acknowledge、10:31 dashboards 確認で DB CPU 100%」といったタイムラインを手作業で書き起こしていた。大型インシデントでは数時間かかる作業である。
- 年の LLM タイムライン生成は、会話ログに加えて (1) ChatOps コマンドの実行ログ、(2) デプロイイベント、(3) アラート発報履歴、(4) ダッシュボード閲覧履歴、(5) ランブック実行履歴を統合する。LLM に投入する際は「全トークンを詰め込む」のではなく、イベント単位で構造化し、時刻順に整形した JSON を context として与え、「SRE として、次の情報から incident timeline を時系列で作成せよ。各項目に時刻、担当者、判断内容、根拠を含めよ」と指示する。
- 年時点で Claude Opus 4.7 と GPT-5.1 が同タスクで人手に匹敵する品質を出す。ただし「判断の根拠」を推測で埋める傾向があり、人間による校正は必須。自動生成の価値は「ゼロからの時間短縮」で、従来 3 時間かかっていた作業が 30 分に短縮される——10 倍効率化のインパクトが大きい。
Blameless Postmortem と action item 追跡
Postmortem の品質は文化と運用で決まる。核心は blameless——個人の過失を追及せず、システムの欠陥を特定する姿勢だ。LLM 支援はこの文化形成にも寄与する。生成される下書きは感情を含まない中立的文体で、「誰が間違えた」ではなく「どのプロセスが missing control だった」という記述に自然に収斂する。人間 scribe が書くより blameless 度が高いという面白い副次効果がある。
Action item 追跡は SRE プラクティスの弱点だった。postmortem で 10 個の action item を挙げても、半年後に完了しているのは 3 個、というのは珍しくない。2026年の各 SaaS は Jira/Linear/Asana 連携で action item の完了率を自動追跡し、四半期ごとに「未完了 action item 一覧」「同一原因での再発件数」を経営にレポートする。Rootly と FireHydrant はこの機能が特に強く、未完了率が可視化されるだけで完了率が体感的に大きく向上する。
MTTR 削減の定量効果
複数の公開事例（各社導入事例、DORA レポート 2025、Gartner 2026年 Q1 レポート）を総合すると、LLM 支援インシデント管理導入による MTTR 削減は概ね 20〜40% のレンジに入る。内訳は (1) 初動の状況把握が速い（AI Scribe の常時要約）、(2) 類似過去インシデントの参照が速い（ベクトル検索）、(3) postmortem 作成が速い（タイムライン自動生成）の三要素が主要因子だ。
ただし注意点として、MTTR の削減は「LLM 支援そのもの」より「インシデント管理プロセスの標準化」による寄与が大きい。LLM 支援ツールを導入すると、必然的にロール定義、重要度基準、ランブック、postmortem テンプレートが整備される。この副次的効果の方が数値に表れやすい。
KGA IT では、クライアントのインシデント管理診断で「ツール導入前にプロセス成熟度を 3 段階上げる」ことを優先する。ツールは加速装置であって、土台がなければ効かない——この順序を守ったクライアントは、6 ヶ月で MTTR を半減させた実績がある。