# インシデント調査戦略 ## 定義 インシデント調査戦略（Incident Investigation Strategies）は、インシデント対応中にエンジニアが根本原因を特定するために用いる情報収集・分析の方法論を指す。[[Jonathan Sillito]] と [[Esdras Kutomi]] による 30 インシデントの定性分析（[[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]]）で同定された。大きく 2 種の戦略に分類される。 ### 体系的戦略（Systematic Strategy） 症状から根本原因まで段階的に調査する。2 つのアプローチを持つ: 1. **症状・挙動の連鎖をたどる**: 「なぜ」を繰り返す形でシステムの挙動の連鎖を追跡し、根本原因を発見する 2. **テクノロジースタックをたどる**: 問題を異なる層で再現しつつスタックを下り、問題が発生している層を特定する（「スタックを下っていく。問題を再現できる場所を見つけたらさらに下っていき、本当に問題が存在する場所を見つける」 \[1.14\]） ### 日和見的戦略（Opportunistic Strategy） 根本原因（または根本原因に近い別の症状）に概念的に直接ジャンプしようとする。2 つのアプローチを持つ: 1. **典型的な原因を確認する**: 過去の経験に基づいて典型的・よくある原因をチェックする。低コストで実施できる「ローハンギングフルーツ」的なアプローチ 2. **時間的相関のある異常を探す**: 調査対象の挙動と時間的に相関する異常を探す。詳細な因果連鎖は後から補完するか、確認せずに仮定することもある 日和見的戦略はインシデントタイムラインの概念を中心に組織化され、情報源間の相関付けにタイミングを活用する（「タイミングが非常に重要。それが情報源間の相関付けを可能にする」 \[1.3\]）。 ## 横断的知見 - **体系的と日和見的の組み合わせが現実の調査**: 実際のインシデント調査（フェーズ 1・15 件）では純粋に 1 戦略のみを用いたケースは少なく、多くは組み合わせていた。日和見的戦略が調査の出発点をより特定的にし、そこから体系的調査を継続するというパターンが多く見られた（Source: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]]） - **相関を発見しても因果理解が欠けると調査が失敗する**: incident 1.11 では相関する設定変更を発見したがその影響を理解できず、別チームが数時間後に再発見した。incident 2.2 では設定変更との「非常に良い時間的相関」を確認しながらメモリリークとの因果関係を理解できず、数時間にわたる無駄な調査が続いた。日和見的戦略の成功条件は「相関の顕在化＋因果の理解」の両方にある（Source: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]]） - **ダッシュボードの統合性が日和見的戦略の成否を分ける**: ダッシュボードに必要な情報が統合・可視化されている場合、対応者は迅速に根本原因を特定できる（例: incident 1.7）。情報が散在・未統合な場合、調査は認知的に困難になる。ログ検索・文書参照・インスタンス状態サンプリング・メモリダンプ収集などの手動操作が必要になる（Source: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]]） - **AIエージェントは「プレイブック確認・文脈収集・シグナル相関」の 3 ステップを担えるが、最終修正判断(Fix)には留保が付く**: Budichenko(SREcon26)が提示した調査フロー「アラート発火 → プレイブック確認 → 文脈収集 → シグナル相関 → 修正」(p.5-6)において、AIエージェントはプレイブック確認・文脈収集・相関の 3 ステップに有効であり、調査時間の短縮・MTTR の改善に貢献する。これは Sillito-Kutomi の分類では「日和見的戦略(典型的原因の確認 = プレイブック参照、時間的相関探索 = シグナル相関)」に最も適合する。一方 Fix はまだ人間主導であることが強調され、完全自律化には精度上の課題がある(同発表の RCA 精度 11.34% 参照)。ただし「プレイブック確認」「文脈収集」の自動化は日和見的戦略の「出発点をより特定的にする」効果と直接対応し、Sillito-Kutomi が観察した「日和見的→体系的の組み合わせ」パターンを AI が支援する可能性を示す。(Source: [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]] p.5-6) ## 未解決の問い - 現代の AIOps エージェント（[[根本原因分析]] のエージェント系ツール）はこの 2 分類のどちらに近い戦略を実装しているか。ReAct ループは日和見的→体系的の切り替えを明示的に設計しているか - AIOps ツールが提供するダッシュボードやアラート情報は、日和見的戦略における「時間的相関の顕在化」という要件を満たしているか - 体系的戦略はアーキテクチャが複雑なシステムではコストが増大する（観察 9）。マイクロサービス環境でのスタック追跡を自動化する手法（例: 分散トレーシング）は体系的戦略の実装といえるか - 日和見的戦略の「典型的原因の確認」は、インシデントの歴史的データベース（過去のポストモーテム）と LLM を組み合わせた RCA エージェントが最も自然に実装できる部分ではないか ## 関連 - [[根本原因分析]] — より広い RCA フレームワーク。本概念はその「調査」フェーズに特化 - [[インシデント管理]] — インシデント対応ライフサイクル全体 - [[オペラビリティ]] — 運用性の観点からの位置づけ ## 出典 - [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV-C