incident-response-textbook.md

SRE とインシデント管理の分野で蓄積されてきた 30 以上の文献を横断し、インシデント対応の理論、実践、研究を体系的に構成した。 検知から緩和までのライフサイクル、指揮体系、調査手法、人的要因、組織設計、AI 支援を包括する。

ポストモーテム(事後振り返り)については姉妹編の「ポストモーテムの教科書」を参照されたい。 インシデント管理(Incident Management)は、クラウドサービスにおけるサービス違反や性能劣化を検知、トリアージ、診断、緩和の 4 段で処理するライフサイクル全体を指す。 この 4 段は AIOps の能力分類(検知、箇所特定、RCA、緩和)がタスク能力を縦に切るのに対し、運用プロセスとしてライフサイクルを横断する視座を提供する。

Google SRE はさらに細粒度の 8 フェーズタイムラインを定義する。 Root Cause が本番に到達してから Detect、Escalate、Mitigate、Resolve、Retrospect、Action Items へ至る流れである [1]。 修正機会はこのタイムライン上で 3 方向に分類される。

方向	介入点
STOP
根本原因が本番に到達する前に止める
FASTER
検知から緩和までを高速化する
PREVENT and FIX CULTURE
復旧後に予防策と学習文化を醸成する

Li ら(2022)は AWS、Azure、Google Cloud の公開ポストモーテム 354 件を分析し、ライフサイクルを TTX(Time to X)指標で定量化した [2]。

指標	定義	平均値
TTD
障害発生から最初の検知まで	16.9 分
TTI
検知から根本原因特定まで	77.8 分
TTM
根本原因特定から緩和完了まで	304.2 分
TTR
障害発生から完全解決まで	572.8 分

TTR の 53% を緩和フェーズ(TTM)が占める。 障害発生から緩和まで平均 9 時間以上かかるという事実は、緩和フェーズの短縮が最大の改善ポイントであることを示す。 DevOps の理想目標(TTD 1 分、TTI 5 分、TTM 10 分)に対し、達成率は TTD 15.7%、TTI 14.0%、TTM 1.9% にとどまる。

インシデントの重大度は、直感的には「単一の数値(Sev1, Sev2)」で表現される。 しかしこの単純化にはいくつもの問題がある。

Sue Lueder(Google)は、重大度を法的リスク、ユーザー影響、財務、サービス種別の 4 次元に分解し、パースペクティブ別(財務、広報、品質)に重み付けスコアを算出する方式を提案した [3]。 Courtney Nash(Verica)は VOID データベース(1,856 件、610 組織)の分析から、持続時間と重大度は相関しないことを示した [4]。 「23 時間 11 分で顧客影響ゼロ」と「21 分で Critical 顧客影響」が共存する。 重大度は測定値ではなく、社交的な調整物(socially negotiated variable)であるというのが Nash と John Allspaw の結論である。

この問題に対し 3 つの異なる処方箋が提示されている。

意図的な過大分類(Eason, Facebook 2016): リスクがあれば Sev1 に倒し、後から格下げする [5]。結果ベースの評価(McCarthy, Afterpay 2023): 重大度判断の重心を「エンジニアの意図」から「ユーザーへの実害」に移す [6]。カナリアとしての重大度(Ruppe, Jeli 2024): 重大度を巡る摩擦そのものを組織課題の診断シグナルとして活用する [7]。

ICS(Incident Command System)は 1960〜70 年代のカリフォルニア山火事対応を起源とする指揮体系である。 2004 年に NIMS(National Incident Management System)として連邦義務化され、多機関連携の標準となった。

Google SRE Book(2016)はこの ICS をソフトウェアインシデント対応に適用し、4 役割を定義した [1]。 | 役割 | 責務 |

|---|---|
IC(Incident Commander) |

全体指令、調整、内部コミュニケーション | Ops Lead | 実際の修復 | Communications Lead | 外部ステークホルダーへの情報発信 | Planning Lead | 長期化した場合の計画策定 |

IC は技術問題を自ら解く役割ではない。 SRE Book は非管理型インシデントの最大の悪化要因を「善意に基づく独断行動(フリーランシング)」と特定し、この抑制こそが IC の中核機能だとする。 Gareth Eason(Facebook)はこの調停機能を「人間のミューテックス(human mutex)」と呼んだ [5]。 複数人が同時に問題解決を試みる際、まず 1 つの案を試し他は待たせるという並行制御の比喩である。

Alice Goldfuss(New Relic, 2016)は、最深刻の Sev1 でのみ解放される追加役割を定義した [8]。

**EC(Emergency Commander)**: IC と法務、マーケティング等の間のリエゾン。** LL(Logistics Lead)**: シフト管理、食事手配、帰宅指示などのロジスティクス。

ICS 導入前後で、同種の大規模インシデントの対応時間が 3 日から 3 時間に短縮された。 この数値は IC プログラムの ROI を示す、公開されている最古の実績報告である。

IC の育成方針は 10 年間で進化した。

Goldfuss(2016)は「全員を訓練し、快適な者が任意で立候補する」アプローチを採った [8]。 Vanessa Huerta Granda(2026)は「Deliberate IC Team(意図的専任チーム)」を最良実践として推奨する [9]。 両者は「IC は技術役割でない」という核心で完全に一致する。 IC の人材選定にあたり、役職は指標にならない。

アンチパターン	理由
最強エンジニアを IC にする	最強のエンジニアを技術問題から引き離すことになる
オンコール担当者をそのまま IC にする	オンコール適性と IC 適性は別物である
最上位者を IC にする	役職が IC の適性を保証しない

IC のコアコンピテンシーは 3 つである。 コミュニケーション(技術と非技術の両方の語り口)、社会技術的リーダーシップ(技術の外の問題を識別する力)、認知負荷管理(複数の作業ストリームを切り替えながら全体状況を維持する力)。 Thai Wood(SREcon23 Americas)は、ICS の正式な役割体系ではなく「対応に必須の core needs」として 3 つの帽子を提示した [10]。

Organizer(IC 相当): 全体の調整。** Connector**(CL 相当): 情報の橋渡し。** Expert**(TL 相当): 技術的な問題解決。 重大度や命令系統を意図的に排除し、チーム単体で今日からでも始められる規模に縮小している。 成熟度の低い組織でも着手可能な入り口として位置づけられる。

Brent Chapman(Slack)は、同時多発インシデントが増えるにつれ単一の IC では解決しない「インシデント間のリソース競合」に直面し、公共安全 ICS から Area Command を輸入した [11]。 Area Command は、他のインシデントを俯瞰して優先順位付けと仲裁を行うメタ統制層である。

IC の設計論は「IC をどう選び育てるか」に組織的関心を集中させる。 しかし対応者の大半は IC ではなく「フォロワー」である。

Laura Maguire(Jeli, SREcon23 Americas)は、この関心の非対称性を問題視し、**フォロワーシップ(Followship)**を提唱した [12]。 フォロワーシップとは、共通の目標のために協働する経験豊富な対応者たちの「適応的コレオグラフィ(adaptive choreography)」である。

複雑適応系ではあらゆる人のメンタルモデルは部分的にしかなり得ない [13]。 非定型の事象に対処するには多様な視点の統合が必要だが、他者と協働すること自体が追加の認知負荷(Cost of Coordination, CoC)を生む。 対応者はこの負荷に DELEGATE(委任)、DELAY(後回し)、DIMINISH(優先度低下)、DROP(切り捨て)という 4 戦略で対処する。 Anticipating: 他者の作業を先読みする。** Initiating**: 作業を自発的に始める。** Signalling intent**: 意図を表明して協調を助ける。** Proactively providing information**: 能動的に情報と前提を共有する。** Relaxing goals and constraints**: 互恵性を示すために自分の制約を緩める。** Synchronizing**: 活動を同期させる。** Preparing themselves to be useful**: 役立つための準備をする。** Looking in and listening in**: 状況を観察し傾聴する。

IC 中心主義とフォロワーシップは対立ではなく補完である。 IC の設計論がリーダー役割の内部を最適化するのに対し、フォロワーシップはそれ以外の全員の働きを底上げするフォースマルチプライヤーとなる。

Jonathan Sillito と Esdras Kutomi は 30 インシデントの定性分析から、調査を 2 種の戦略に分類した [14]。

体系的戦略(Systematic Strategy)は、症状から根本原因まで段階的に調査する。 2 つのアプローチがある。 「なぜ」を繰り返してシステムの挙動の連鎖をたどる方法と、テクノロジースタックを層ごとに下って問題の存在する層を特定する方法である。

日和見的戦略(Opportunistic Strategy)は、根本原因に概念的に直接ジャンプしようとする。 過去の経験に基づく典型的な原因の確認と、時間的に相関する異常の探索がある。

実際のインシデント調査では純粋に 1 戦略のみを用いるケースは少なく、日和見的戦略が出発点をより特定的にし、そこから体系的調査を継続するパターンが多い。

相関の発見だけでは不十分で、因果の理解が伴わなければ調査は失敗する。 設定変更との「良い時間的相関」を発見しながらメモリリークとの因果関係を理解できず、数時間の無駄が生じた事例が報告されている(incident 2.2) [14]。

Jack Kingsman(Atlassian, SREcon26 Americas)は、インシデント対応を認識論的に分析するフレームワークを提案した [15]。 Google SRE Book の Incident Loop を基盤に、4 つの認識ツールを追加した構成をとる。

フェーズ	目標
Phase 0: 検知
インシデントの存在を確認し宣言する
Phase 1: 生存
被害の拡大を止める(「ボートを浮かせる」)
Phase 2: 検査
システムの現状を観測して証拠を集める
Phase 3: 診断
証拠から根本原因の仮説を立てる
Phase 4: テスト
仮説を検証し、確認後に修正する

証拠を出所の直接性(Direct / Indirect)と変化状況(Changing / Stable)の 2 軸で分類し、収集の優先度をつける。 Direct-Changing: 最高信頼度。今起きていることを直接示す。** Direct-Stable**: 長期的根本原因を示す可能性が高い。** Indirect-Changing**: 変化の徴候として有用だが解釈を要する。** Indirect-Stable**: 最低信頼度。補足情報としてのみ使う。

線形探索(Linear Search): ユーザー側の末端から順に「正常か異常か」を判定しながら根本へ進む。** 2 分探索**(Binary Search): 確認するコンポーネントを毎回半分に絞る。変化誘導(Induced-Change): 意図的に変化(再現テスト、無効化、負荷変更)を加えて反応を観察する。証拠が乏しいときに能動的に証拠を生成する戦略である。 Testable: 何らかのテストで真偽を確認できる形式である。** Relevant**: 現在の証拠と結びついている。** Specific**: どのコンポーネント、条件、状態を指しているかが明確である。

「十分もっともらしい」と感じた段階で探索を止めてはならない。 早期停止(stopping early)は最大の誤りとされる。

インシデント対応はチームスポーツである。 技術的な調査と並行して、参加者間の相互理解を維持する作業が常に進行している。

Common Grounding(共通基盤構築)は、相互理解とメンタルモデルをコミュニケーション、テスト、更新、調整、修復によって維持するプロセスである [16]。 「Common Grounding」は修復活動の副次的活動ではなく、修復と並行して常に進行するメイン活動の一つである。

割り込み、疲労、注意分散は Common Ground を直ちに脅かす。 さらに危険なのは、一方が協働から離脱しても他方が共同作業の存続を信じ続ける場合である。 崩壊に気づくのは離脱した側ではなく残された側であり、しかも遅れて気づく [17]。

Laura Maguire は Common Ground の知識を team(チームのスキル、知識)、others(誰が誰を頼るか)、technical system(システムの動作)、organization(目標、制約)の 4 象限に整理した [12]。

**引き継ぎ**(Handover)は Common Ground が明示的に受け渡される数少ない局面である [17]。

Chad Todd(CrowdStrike)の調査から、確信度を下げる要因として部門間の不整合、引き継ぎ後の不在、高負荷下での準備不足が特定された。 確信度を上げる要因は、口頭と記述の併用、詳細な記述、確認応答(Acknowledgement)の徹底である。

障害緩和(remediation / mitigation)は、診断結果を入力に適切な復旧アクションを実行してシステムを健全な状態へ戻す、インシデントライフサイクルの最終段である。

Li ら(2022)は 354 件から 9 種類の緩和手段を同定した [2]。

- リプレースメント(32%)が最多、自己回復(7.6%)が最少。

• ロールバックが TTM 中央値 91 分で最速、フィックスが 220 分で最遅。
• 根本原因と緩和手段には強い相関がある。設定ミスにはロールバックが集中し、ハードウェア障害にはフィックスが多い。

本番インシデントの緩和は「正しく直す」より「速く止める」に傾く。 GenAI クラウドサービスの分析では、コード修正は根本原因のコードバグ 21.5% に対し 7.6% にとどまる [18]。 CI/CD の所要時間を考慮すると、ロールバックやアドホック修正が優先されるためである。

また自己回復が 19.7% を占める点も注目に値する。 「何もしないのが最適」なケースが約 2 割存在するが、既存のエージェント評価はこの判別能力を測っていない。

深刻度に応じた多段エスカレーションへの収束が、SRE とハードウェア故障管理の双方で独立に観察される。 可逆で軽量な早期措置を先に置き、不可逆で重い措置は深刻度が確証されるまで遅らせるという順序設計が共通する [19] [20]。

変更起因インシデント(Change-Induced Incidents, CII)は、変更を行わなければ起きなかった障害として通常インシデントと区別される。

2 つの独立した実証研究が、ほぼ同一の統計を報告している [2] [21]。 コード変更が約 55% で最多、構成変更が約 25% で第 2 位、最多緩和策はロールバック(約 50%)である。 クラウド障害ライフサイクルの 354 件分析でも、58.8% が変更中に発生し、そのうち 84.7% が内部原因(設定ミス、コード変更)であった [2]。 変更プロセス中が最もリスクの高い時間帯であるという構造は、独立したデータセットで一致する。

変更起因インシデントの 50.6% ではユーザーがモニタより先に異常を検知した [21]。 自動検知の網からすり落ちるインシデントの過半が変更操作中に発生しているという事実は、デプロイパイプラインへの検知強化が最優先であることを示す。

この主張は 3 人の実践者が独立に到達した収束点である。

- Lund(SREcon19 APAC): 「Human Error は analytical dead end」 [22]
- Eckhardt(SREcon19 Asia/Pacific): 「ヒューマンエラーは調査を終わらせる場所でなく、始める場所」 [23]
- Gallego(SREcon18 Americas): 「人はその時点の情報において最善と信じる行動をとる」(ローカル合理性) [24]

人間をエラーの原因として特定した瞬間に分析は止まり、「なぜその文脈でその判断が合理的に見えたか」という問いが省かれる。

Matt Davis(SREcon23 Americas)は「人間のオブザーバビリティ」を技術的メトリクスとは独立した観測対象として位置づけた [25]。 コンダクター質問が疲労、食事、時刻、心理的安全を問うのはその実践形態である。

Davis は「インシデント対応の即興能力(Adaptive Capacity)は練習の外に存在しない」と主張し、Practice of Practice Gamelan という練習フレームワークを提案した。 認識論的な提案にとどまった Lund、Eckhardt とは異なり、Davis は組織的な訓練設計への橋渡しを行った点で新しい。

Eddie Redick(SREcon26 Americas)は "Commanding the Chaos" として、AI エージェントが自律的に動く環境下での SRE の人間側スキルセットを 3 軸で定義した [26]。

Psychological Composure: プレッシャー下での冷静。** Systems Thinking**: 全体最適視点。** Automation at Scale**: スケールする自動化設計。

「アーキテクチャの水準には上がれない。システム思考の水準に落ちる」。 この主張は、アーキテクチャの複雑性が増すほど人間の全体俯瞰能力の相対的価値が上がるという意味である。

Beth Adele Long(SREcon26 Americas)は、オンコール業務に伴う 2 種類のストレスを区別した [27]。 慢性ストレス(ページャーを持ち続ける負荷)と急性ストレス(インシデント対応中の超警戒状態)である。 自律神経系(ANS)は本来、自己修正機能を持つ。 しかし合理的思考(Ordinary Mind)による抑制がかかると自己修正が働かなくなる。 解法は身体知性に根ざした 4 つの実践ツール(ボディスキャン、呼吸法、自発的な動き、退屈)である。

Jaime Woo(SREcon18 Americas)は Shopify の 40 名を対象に調査し、42.5% がインシデント後に強いストレスを報告した [28]。 80% が組織的サポートをほぼ受けていないとも報告している。

医師の二次被害者研究(Waterman et al. 2007)では、医療ミス後に将来のミスへの不安増大(61%)、自信の喪失(44%)、睡眠困難(42%)が報告されているが、82% がピアサポートとカウンセリングを有効と感じた [29]。 Mosewich ら(2013)のセルフコンパッション介入研究(n=60)は、反芻思考と自己批判を有意に低下させた [30]。 この能力は先天的ではなく、意図的に訓練できる。

MTTR は 3 つの観点から批判されている。

統計的問題(Davidovič, Google SRE): インシデント件数が少なく標準偏差が大きい場合、MTTR の変化のほぼすべてが統計的ノイズである [31]。VOID の実データ(1,856 件、610 組織)では持続時間分布は一貫して右歪みを示し、この理論的予測を裏付ける。逆インセンティブ(Luck, de Vesine, Datadog): MTTR を下げる最も簡単な方法は「同じインシデントを繰り返して素早く修正する」こと [32]。深い根本原因の修正は MTTR を上昇させる。** DORA での廃止**: DORA の最新版では MTTR が「bad rollout を remediate する時間」に置き換えられた。

インシデント件数も MTTR も機能しない場合、何を測るべきか。 Luck と de Vesine(Datadog, SREcon25 Americas)は、インシデント管理プロセスの「目標ごと」に指標を当てる方式を提案した [32]。

目標	測定例
オンコール持続可能性	深夜ページ数、シフト長、フェアネス知覚サーベイ
インシデントが真剣に扱われる	ステートマシン完走率、自発的ポストモーテム率
インシデント対応の質	役割使用率、感情分析(自信、準備感)
事後学習と改善	アクションアイテム速度、繰り返しインシデント率

顧客信頼性はこのリストに含まれない。 それは SLO で直接測定すべき別の問題である。

Narimichi Takamura(Topotal)は、Google SRE の「信頼性のマインドセット」をベースに、3 フェーズ×9 プロセスを 4 段階で評価するマトリクスを提案した [33]。

レベル	状態
Absent
属人的対応が常態化
Reactive
重大障害の方針は定まるが環境改善は行われない
Proactive
組織全体で対応し、事前リスク低減を実施
Strategic
フィードバックループで対応負荷を継続的に最小化

3 フェーズは Pre-Incident(Detection、Workflow、Training)、Response(Empowerment、Systematization、Collaboration)、Post-Incident(Learning、Analytics、Follow-up)で構成される。 IC の導入は Proactive 以降で効果を発揮する。 「さまざまな前提が整って初めて効果を発揮する、企業によっては単なるオーバーヘッドになりうるベストプラクティス」である(Takamura)。

ChatOps は、チャットプラットフォームを運用操作の主要インターフェイスとする実践パターンである。 Al Tobey(Netflix, SREcon16)の Scorebot は典型実装であり、以下の機能パターンを確立した [34]。

bookmarking: タイムスタンプとメモの記録。タイムライン構築の起点。** presence**: 実際にキーボードの前にいるかを追跡する。** after-hours**: 夜間の問い合わせに自動応答し、緊急時はページを促す。** archive**: 絵文字リアクションで発言にタグ付けし、インシデントレポートの自動生成を目指す。

「ボットに機能を詰め込みすぎない」ことが設計原則である。 ロジックは独立したデーモンとして動かし、ボットはそれらへの薄いインターフェイスにとどめる。 Slack が落ちても本質ロジックは別で動く。

潜在インシデントの 30〜60% が正式なトラッキングを通過しない。 Andreas Deuschl(Dynatrace, SREcon25 EMEA)はこれを**アンインシデント(Un-Incident)**と名づけた [35]。

類型	定義
No-CI
顧客影響があるが既存分類に当てはまらない
NOF
外部要因に起因し自組織の責任外と判断される
Near Miss
幸運または予防的行動でエスカレーションを免れた
Fear Miss
不安による不必要なエスカレーション

「インシデントか否か」という問いを「何を学べるか」に転換することが中心テーゼである。 対処の骨格は Gray Zone Playbook として示される。 マインドセット(宣言を阻まない、宣言に感謝する、事実ベースのトリアージ)、ストラクチャー(オブザーバビリティへの信頼構築、SLO による微細劣化の早期検出)、プロセス(簡単にトリガーできる事後分析への接続)の 3 層で構成される。

「同じインシデントを二度経験することは不可能」という根本的制約を緩和する手段が、インシデントシミュレーションである。

David D. Woods と Hollnagel(2006)が定義した手法で、4 つの特性を持つ [36]。 シミュレーションシナリオ、十分な忠実度、専門性を引き出す設計、唯一解がないことである。

Hamed Silatani(Uptime Labs, SREcon24 EMEA)は 20 名を対象にステージドワールド実験を行い、2 つの行動パターンを同定した [37]。

Solo Artist: 全負担を一人で抱え、ストレスが高い。** Band Member**: 早期にチームメンバーを巻き込み、ワークロードと思考力を分散する。

解決時間は参加者の経験や能力レベルと相関しなかった。 むしろ重大度の議論に費やした時間や、チームの巻き込み方が有意な行動差として浮上した。 技術的スキルより組織的な行動が成否を分けるという洞察は、訓練設計に含めるべき要素を示唆する。

カテゴリ	内容
Diagnostic
信号を吸収し推論を行う
Therapeutic
問題を修正しようとする介入
Recruiting
専門性と権限を持つ人を巻き込む
Status/Reporting
記録の作成とステークホルダーへの報告

治療的行動(Therapeutic)は即座に診断情報に変わるという特性を持つ。 失敗したロールバックは「その変更が原因ではなかった」という新たな診断シグナルを生み出す。

Ryota Yoshikawa(Topotal)は SAE の自動運転 L0〜L5 を IR(インシデントレスポンス)に対応させたフレームワークを提唱した [38]。

IR レベル	AI の役割
IR0
なし
IR1
通知と記録補助
IR2
判断支援と提案
IR3
実行と監視責任も AI
IR4
完全実行(特定領域)
IR5
あらゆる状況で AI

2025 年時点で IR0〜IR2 は実現済みとされ、MCP(Model Context Protocol)とコーディングエージェントの進展により IR2〜IR3 の実現可能性が出てきたとされる。 IR3 到達には「AI に任せられる安全な操作の定義」が必要である。

TSG(Troubleshooting Guide)を LLM エージェントで実行する問題は、Microsoft の 3 本の論文で設計空間として立ち上がった。

FLASH: インシデント時にオンラインで TSG を実行する [39]。** StepFly**: オフラインで DAG を抽出し、並列スケジューラで実行する [40]。** LLexus**: 計画フェーズを前置し、実行時は決定論的に走らせる [41]。 3 本に共通する最大の発見は、TSG 品質が自動化の律速であることである。 FLASH の曖昧アクション(Ambiguous Action)が TSG の約 40% を占め、LLexus では低品質 TSG で計画コストが約 3 倍に膨らむ。

Google SRE AI はこの律速を、プレイブックの保守自体をエージェンティックループに組み込むことで解こうとしている [42]。 エージェントが利用実態を監視し、改善を提案し、インシデントから新規プレイブックを生成する。

Google SRE AI は ICS の 4 役割に 4 種のエージェントを補助層として被せる設計を採る [42]。 コミュニケーション面の監視と集約、SRE 間ハンドオフ文書生成、ポストモーテム下書き作成、内外コミュニケーション管理である。 いずれも人間 IC を置き換えない補助層であり、「フリーランシング」の抑制を agentic 補助層でも貫いている。

本教科書の各部から浮かび上がる未解決の研究課題を整理する。

指揮と組織

• Wood の「3 つの帽子」(最小導入)と Huerta Granda の「Deliberate IC Team」(専任チーム)は、どの成熟度で接続すべきか。

• フォロワーシップの 8 行動は、経験の浅い対応者にどう訓練できるか。

• MTTI(Mean Time To Innocence)を定量化した研究は存在するか。 調査と診断

• AIOps エージェントは体系的戦略と日和見的戦略のどちらを実装しているか。ReAct ループは両者の切り替えを設計しているか。

• インシデント認識論の「良いテストの 6 基準」は、緊急度が高い場面でどれを優先するか。

緩和

• 緩和エージェントは「何もしないのが最適」というケースを判別できるか。
• 反復リフレクションの精度向上は逓減する。適応的なプロービングとリフレクションの最適配分は設計できるか。

人間

• Human Factors アプローチのコスト(個別インタビュー、デブリーフィング)と効果のトレードオフ。
• セルフコンパッション介入は SRE チームの文化に組み込めるか。

測定

• 繰り返しインシデントの検出は現在手動に依存しており、LLM は不得意とされる。どのような定式化で自動化できるか。
• SLO とインシデント指標の「橋渡し」をどう設計するか。

AI

• IR3 に必要な「安全な操作の定義」はどう検証するか。
• RCA 精度(14%)が低いまま IR3 は実現できるか。
• LLM 生成の緩和スクリプトの「症状消し」への最適化をどう防ぐか。

用語	定義
ICS	Incident Command System。山火事対応に起源を持つ指揮体系
IC	Incident Commander。全体指令と調整の最高責任者
TTX	Time to X。障害ライフサイクルの各フェーズの所要時間指標群
TTD	Time to Detect。障害発生から検知まで
TTI	Time to Identify。検知から根本原因特定まで
TTM	Time to Mitigate。根本原因特定から緩和完了まで
TTR	Time to Resolve。障害発生から完全解決まで
CII	Change-Induced Incidents。変更起因インシデント
TSG	Troubleshooting Guide。トラブルシューティングガイド
Common Grounding	相互理解とメンタルモデルを維持するプロセス
Followship	フォロワー全体の適応的コレオグラフィ
Area Command	同時多発インシデントの優先順位付けと仲裁を行うメタ統制層
IR Levels	SAE 自動運転レベルに対応させたインシデントレスポンス AI 自律度分類
MCP	Model Context Protocol。AI エージェントのツール接続標準
アンインシデント	正式なトラッキングに至らなかった潜在インシデント

[1] Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy. "Managing Incidents." Site Reliability Engineering, Chapter 14, O'Reilly, 2016. Link

[2] Xiaoyun Li, Chao Chen, Zhiming Chen, Zhenyu Zhong, Jing Luo, Yanjie Jiang, Zhenyong Zhang. "Going through the Life Cycle of Faults in Clouds: Guidelines on Fault Handling." Proc. 33rd IEEE International Symposium on Software Reliability Engineering (ISSRE), IEEE, 2022. Link

[3] Sue Lueder. "What Brought Us Down? Outage Trend Analysis at Google." SREcon15, USENIX, 2015. Link

[4] Courtney Nash. "Tales from the VOID: The Scary Truth About Incident Metrics." SREcon22 Americas, USENIX, 2022. Link

[5] Gareth Eason. "Incident Response @ FB: Facebook's SEV Process." SREcon16, USENIX, 2016. Link

[6] Niall McCarthy. "The Incident Is The Way: Using Your Incidents to Win Reliability Investment." SREcon23 EMEA, USENIX, 2023. Link

[7] Emily Ruppe. "What Is Incident Severity, but a Lie Agreed Upon?" SREcon24 Americas, USENIX, 2024. Link

[8] Alice Goldfuss. "nrrd 911 ic me: The Incident Commander Role." SREcon16, USENIX, 2016. Link

[9] Vanessa Huerta Granda. "So You Want a New Incident Commander." SREcon26 Americas, USENIX, 2026. Link

[10] Thai Wood. "If I Can Do It on an Ambulance: Scalable Incident Response Using ICS." SREcon23 Americas, USENIX, 2023. Link

[11] Brent Chapman. "Evolution of Incident Management at Slack." SREcon21, USENIX, 2021. Link

[12] Laura Maguire. "An Organizational Response to Incidents." SREcon23 Americas, USENIX, 2023. Link

[13] David D. Woods. "STELLA: Report from the SNAFUcatchers Workshop on Coping with Complexity." 2017. [Link](https://snafucatchers.github.io/)

[14] Jonathan Sillito, Esdras Kutomi. "Failures and Fixes: A Study of Software System Incident Response." arXiv:2004.13434, 2020. [Link](https://arxiv.org/abs/2004.13434)

[15] Jack Kingsman. "Epistemology of Incident Management." SREcon26 Americas, USENIX, 2026. Link

[16] Gary Klein, Paul J. Feltovich, Jeffrey M. Bradshaw, David D. Woods. "Common Ground and Coordination in Joint Activity." Organizational Simulation, Wiley, 2005.

[17] Chad Todd. "Handover Communications in Software Operations: Findings from the Field." SREcon23 Americas, USENIX, 2023. Link

[18] Zhiqiang Xie et al. "An Empirical Study of Production Incidents in Generative AI Cloud Services." Proc. 48th International Conference on Software Engineering (ICSE), IEEE/ACM, 2026. Link

[19] Aditya Deshmukh et al. "Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems." Proc. International Conference for High Performance Computing, Networking, Storage and Analysis (SC), ACM, 2025. Link

[20] Shenghao Lin et al. "Guard: Scalable Straggler Detection and Node Health Management for Large-Scale Training." Proc. MLSys, 2026.

[21] Supriyo Ghosh et al. "An Empirical Study of Change-Induced Incidents in Cloud Services." Proc. IEEE/ACM International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), IEEE, 2023. Link

[22] Tanner Lund. "A Tale of Two Postmortems: A Human Factors View." SREcon19 Asia/Pacific, USENIX, 2019. Link

[23] Courtney Eckhardt. "Retrospectives for Humans (a crash course)." SREcon19 Asia/Pacific, USENIX, 2019. Link

[24] Will Gallego. "Architecting a Technical Post Mortem." SREcon18 Americas, USENIX, 2018. Link

[25] Matt Davis. "Human Observability of Incident Response." SREcon23 Americas, USENIX, 2023. Link

[26] Eddie Redick. "Human Factors in the Age of AI Ops: Re-Engineering Trust Between Humans and Machines." SREcon26 Americas, USENIX, 2026. Link

[27] Beth Adele Long. "The Critical Resource Is You: Practical Destressing for On-Call Engineers." SREcon26 Americas, USENIX, 2026. Link

[28] Jaime Woo. "Your System Has Recovered from an Incident, but Have Your Developers?" SREcon18 Americas, USENIX, 2018. Link

[29] Albert W. Wu, Susan Folkman, Sara J. McPhee, Bernard Lo. "Do House Officers Learn from Their Mistakes?" JAMA, 265(16):2089–2094, 1991. / Roni C. D. Waterman et al. "The Emotional Impact of Medical Errors on Practicing Physicians in the United States and Canada." The Joint Commission Journal on Quality and Patient Safety, 33(8):467–476, 2007.

[30] Amber D. Mosewich, Peter R. E. Crocker, Kent C. Kowalski, Anita DeLongis. "Applying Self-Compassion in Sport: An Intervention with Women Athletes." Journal of Sport & Exercise Psychology, 35(5):514–524, 2013.

[31] Stepan Davidovič. "Incident Metrics in SRE: Critically Evaluating MTTR and Friends." O'Reilly / Google SRE, 2021. Link

[32] Jamie Luck, Laura de Vesine. "Incident Management Metrics that Matter." SREcon25 Americas, USENIX, 2025. Link

[33] Narimichi Takamura. "組織的なインシデント対応を目指して." SRE NEXT 2024, 2024. Link [34] Al Tobey. "Incident Management and ChatOps @ Netflix feat. Scorebot." SREcon16, USENIX, 2016. Link

[35] Andreas Deuschl. "The Un-Incident." SREcon25 EMEA, USENIX, 2025. Link [36] David D. Woods, Erik Hollnagel. Joint Cognitive Systems: Patterns in Cognitive Systems Engineering. CRC Press, 2006.

[37] Hamed Silatani. "Incident Groundhog Day." SREcon24 EMEA, USENIX, 2024. Link

[38] Ryota Yoshikawa. "Rethinking Incident Response: Context-Aware AI in Practice." SRE NEXT 2025, 2025. Link

[39] Rohan Bavishi, Jiaqi Guo, Lezhi Ma, Shuai Lu, Qinan Yu, Ze Shi Li, Michael R. Lyu, Qi Zhang, Saravan Rajmohan, et al. "FLASH: Workflow Automation Agent for Diagnosing and Resolving Incidents." arXiv:2410.21028, 2024. Link

[40] Rohan Bavishi, Shuai Lu, Jiaqi Guo, Ze Shi Li, Saravan Rajmohan, Qi Zhang. "StepFly: An LLM-Driven Framework for Automated Troubleshooting Workflow." arXiv:2510.10074, 2025. Link

[41] Rohan Bavishi, Shuai Lu, Jiaqi Guo, Ze Shi Li, Saravan Rajmohan, Qi Zhang. "LLexus: An AI Agent System for Incident Management." ACM SIGOPS Operating Systems Review, 58(1), 2024. Link

[42] Stevan Malesevic, Christopher Heiser. "AI in SRE: Where and How Google Is Deploying Agentic AI to Improve Operations." Google Cloud Blog, 2026. Link

source & further reading

gist.github.com — original article Visualizing MNIST Training with Deep Neural Networks Find what your prompt is missing: the blindspot pass, the debrief, and the permanent fix, made specific Give Claude Eyes — watch any video frame-by-frame, 100% local (buildwith.conrad)