# インシデント管理 ## 定義 インシデント管理（Incident Management）は、クラウドサービスにおけるサービス違反や性能劣化を**検知→トリアージ→診断→緩和**の 4 段で処理するライフサイクル全体を指す。[[AIOps]] の 4-level taxonomy（検知/箇所特定/RCA/緩和）がタスク能力として各段を縦に切るのに対し、インシデント管理はライフサイクルを横断する運用プロセスとしての視座を提供する。[[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] は [[Microsoft]] の GenAI クラウドサービス（Azure OpenAI 等）の本番インシデント 4 年分を分析し、GenAI 固有のインシデント特性——監視の未成熟（38.3% が人手検知）、症状と根本原因の多対多マッピング、緩和戦略の多様化（アドホック修正 22.4% 対 非 GenAI 54.7%）——を定量化した。 ## 横断的知見 - **AIOps エージェント評価が想定するインシデント像と本番インシデントの乖離**: [[AIOpsLab]] や [[SREGym]] は障害注入（[[ChaosMesh]] / eBPF）によるインシデントを評価対象にするが、本番インシデントの根本原因分布は設定問題 24.5%・外部利用 14.1%・運用操作ミス 12.7% を含み、障害注入で再現しにくい種別が過半を占める。学術ベンチマークが Infrastructure Issue（27.2%）やコードバグ（21.5%）を対象にしても、本番インシデントの半分以上はカバーできない可能性がある。(Source: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **インシデントタイムライン(Slack スレッド)が「専門家アノテーションの一次源」として AI 評価に直接使われ始めた**: [[ARFBench]]([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]])は、[[Datadog]] エンジニアの Slack インシデントタイムライン(障害検知から緩和までの議論スレッド)を、専門家の推論(問う質問・調べる証拠・導く結論)のリアルタイム記録とみなし、時系列質問応答([[時系列質問応答]])ベンチマークの正解ラベルの一次証拠に転用する。これは [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が OCE の事後インシデント報告を分析対象にしたのと同じく、**人間の運用記録を AI 研究の一次データに昇格させる**流れ。ARFBench は ICSE 研究と同じインシデント対応の段階構造(報告→診断→トリアージ→緩和→復旧→RCA→postmortem)を引きつつ、その中で TSQA がトリアージ・緩和・RCA に効くと位置づける(Appendix A.2)。(Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **アラートライフサイクル全体最適化という処理単位の出現**: 既存のインシデント管理スレッドが単発の検知/診断/緩和や [[LogPilot]]([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]])の**単発アラート診断**を扱うのに対し、[[AlertGuardian]]([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])は denoise→summary→rule refinement を**一気通貫のライフサイクル**として扱う初の experience paper で、本番([[Tencent]] と読める Company-X)で MTTR 156→21 分(7.4 倍)・日次アラート 30 万→1.5 万を達成する。同じ ASE2025 の LogPilot と並べると「単発アラート診断 対 ライフサイクル全体最適化」という対比軸が立つ——両者は同じ大規模オンラインサービスの本番アラートを対象にしながら、処理の切り出し単位(単発の 1 アラート 対 アラート群のライフサイクル)が異なる。(Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **rule refinement という上流介入(下流の抑制でなく上流のルール品質でアラート疲弊を断つ)**: [[LogPilot]] の単発アラート診断や ICSE 研究の事後分析を含め、多くのインシデント管理研究は「鳴ったアラートをどう捌くか」(下流)に集中する。これに対し [[AlertGuardian]] は**アラートルール自体を改善する**フィードバックループ(オーケストレータなし 4 エージェント Detect/RAG/Rule/Review + 反復、停止条件=構文・重要アラート保持・ノイズ比 5%、30 反復上限)を持ち、human-in-the-loop で 1,174 提案→375 受容(32%)という上流介入を行う。アラート疲弊を下流の抑制でなく上流のルール品質で断つ設計は、検知/診断の精度向上に閉じてきたインシデント管理研究に「ルール生成・改善」という新しい介入点を示す。(Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **インシデント対応ループを「証拠 → 仮説 → 緩和 → 変更記録」の翻訳の連鎖として捉え、各継ぎ目にエージェントを置く**: 本 wiki は ICSE 研究で本番インシデントのライフサイクル(検知→トリアージ→診断→緩和→学習)を、ARFBench で Slack タイムラインを一次データ化する流れを記録してきた。[[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] は同じライフサイクルを detect/triage/diagnose/mitigate/learn と置きつつ、エージェントの価値は段そのものでなく**段と段の継ぎ目**——チケット文 → テレメトリクエリ、テレメトリ結果 → 仮説、仮説 → 緩和、緩和 → 変更記録という人間が時間を費やす翻訳——にあると整理する(§VI-C)。タスク taxonomy(表IV)も incident triage & routing・evidence acquisition・RCA・remediation planning・change safety & rollout control を、各々の入力・ツール面・運用上の成功基準で定義する。本 wiki がライフサイクルの「段」を縦に切ってきたのに対し、サーベイは「継ぎ目の翻訳」を agentic 化の主戦場として横に切る視座を加える。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **LLexus が示す「計画フェーズ前置」と「FLASH/NissIST との設計原理の収束と分岐」**: [[LLexus]]([[@2024__OSR__LLexus - an AI agent system for incident management]])は、Microsoft の SaaS 製品向けに TSG の実行を自動化する AI エージェントシステムである。FLASH や NissIST(An et al. [2])が「インシデント時に LLM を使う」のに対し、LLexus は LLM の使用を**インシデント時でなく計画フェーズ(TSG 作成・更新時)に前置**し、実行時は決定論的プランをそのまま走らせる。これにより、インシデント件数が増えるほどコスト優位性が拡大し(少数インシデントでオンライン方式とコストが逆転)、実行時のハルシネーションリスクが最小化される。一方で FLASH と同様、**TSG の品質が自動化の律速**という共通の壁にぶつかる——品質の低い TSG は多くの反復ラウンドを要し、計画コストが 3 倍近く増大する。LLexus 独自の重要な知見は「TSG を source of truth として扱うことで、自動化の副産物として TSG の品質も向上する」という正のフィードバックループが成立する点である。(Source: [[@2024__OSR__LLexus - an AI agent system for incident management]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **TSG 駆動のワークフロー自動化という反復インシデント固有の診断パターン**: [[FLASH]]([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]])は、反復インシデントが TSG(Troubleshooting Guide)という構造化ドキュメントを持つ固有性に着目し、「TSG を与えれば LLM エージェントが診断を自動実行できるか」という問いを設定する。既存の RCA 研究が「何が根本原因か」の同定に集中するのに対し、FLASH は「TSG に書かれた診断ステップをエージェントが信頼実行できるか」という実行信頼性問題として問いを立て直す。5 シナリオ・250 件の評価で TaskWeaver 比 +13.2% を達成したが、CAPA のような外部ツール依存シナリオでは精度が 50% 程度にとどまり、TSG の品質(Ambiguous Action が全 TSG の約 40%)が自動化可否の主要律速となることを定量化した。これは本 wiki の他のインシデント管理ソース(AlertGuardian・LogPilot)が「アラートのライフサイクル」を単位にするのと異なり、FLASH は**反復インシデントという特定パターンのインシデント種別**を単位として診断ワークフローを閉じる。(Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **「軽量 MAS+自己進化」という新しいトレードオフ軸が MAS 型 IM に出現**: 既存 MAS 型 IM([[D-Bot|@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]]・Flow-of-Action)は GPT-4 等の closed-source LLM と静的 SOP/知識ベースに依存し、再学習なしの経験蓄積機構を持たない。[[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] の OpsAgent は 14B の軽量オープンモデルを推論コアとし、PPO 強化学習(内部パラメータ更新)と反省ベース知識蒸留(外部 RAG 蓄積)の二重自己進化で継続的能力成長を可能にする。[[OpenRCA]] ベンチマークで SOTA(RCA-Agent w/Claude 3.5 Sonnet)比 Correct +46.63%、[[Lenovo]] 本番 53 日・10,492 件で 84.09% 精度・解決時間 2.5 時間→126 秒を達成した。「大型 closed-source モデルで高精度」対「小型 open-source モデル+自己進化で高汎化・低コスト」というトレードオフは、本番展開可能な MAS 型 IM の新しい設計軸となる。(Source: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]], [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]]) - **異種テレメトリの統一テキスト化が MAS 協調の前提条件**: OpsAgent の training-free データプロセッサ(メトリクス: 3σ 検知+CNN 形状分類、ログ: keyword+TF-IDF、トレース: 95 パーセンタイル高レイテンシスパン+3 ホップ呼び出しパス)は、異種オブザーバビリティデータを全エージェントが共通利用できるテキスト記述に変換する。アブレーション研究でプロセッサ除去時の Correct 率は 16.54%→2.26% と激減し、LLM が生の数値入力を苦手とすることを定量的に裏付ける。これは [[マルチモーダル障害診断]] で DL モデルが生テレメトリを直接処理するのとは対照的な「テキスト変換によるモダリティ統一」アプローチで、cross-system 汎化と解釈可能性を同時に実現する。(Source: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] §3.2, Table 2) - **FlowXpert が示す「ワークフロー生成」——TSG 実行(Microsoft 3 本)の上流問題**: [[FlowXpert]]([[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]], KDD 2025)は、[[FLASH]]/[[LLexus]]/[[StepFly]] が前提とする「既存 TSG の存在」を仮定せず、**運用ドキュメントから TSG を生成する**問題に取り組む。Huawei Cloud では 189 種のインシデントに対してワークフローを手作成していた(7 人×7 時間/1 件)が、FlowXpert は 22.1 秒に短縮し 10 週間本番展開で承認率約 80% を達成した。ワークフロー生成 → 実行の 2 段パイプライン(FlowXpert が生成し FLASH/LLexus 型が実行)は論文未検討だが、次の自然な発展として立つ。また FlowXpert は「Scorer の AI フィードバック品質」を DPO で改善する共進化アーキテクチャを持ち、Microsoft 3 本が「TSG 品質が自動化の律速」と指摘したのと並行して「AI フィードバック品質が RL の律速」という別のボトルネックを同時に解決しようとする。(Source: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) - **TSG 自動化という反復インシデント固有のサブ問題が、Microsoft 3 本で設計空間として立ち上がった**: [[FLASH]](オンライン status supervision)・[[StepFly]]([[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]、オフライン DAG+QPP 抽出 + 並列 scheduler-executor)・[[LLexus]](計画前置 + 決定論的実行)は、いずれも「既存 TSG を LLM エージェントで実行する」という同じ問いを、LLM を働かせる時点(インシデント時/計画時/両方)で別々に解く。3 本に共通する最強の発見は **TSG 品質が自動化の律速**であること——FLASH の Pass 約 8.5%、StepFly の専用ツール [[TSG Mentor]]、LLexus の低品質 TSG で計画コスト約 3 倍が独立に同じ壁を指す。この反復インシデント固有のサブ問題は [[TSG自動化]] に切り出して横断集約する。(Source: [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2024__OSR__LLexus - an AI agent system for incident management]]) - **SRE Book の ICS に基づくインシデント管理は、マルチエージェント SRE の役割設計の直接の前駆である**: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] は非管理型インシデントの最大の悪化要因を「善意に基づく独断行動（フリーランシング）」と特定し、ICS（インシデントコマンドシステム）に基づくインシデントコマンダー・オペレーション・コミュニケーション・プランニングの 4 役を処方する。この役割分離は [[Stratus]] の 4 エージェント構成（Commander/Investigator/Executor/Undo）や [[OpsAgent]] の MAS 設計と構造的に対応する。Ch13（[[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]]）はテスト誘発型障害と訓練なし障害の対比で人間の判断力の価値を浮かび上がらせ、Ch15（[[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]]）はブレームレスポストモーテム文化を「人でなくシステムの欠陥に焦点」という原則で定着させる。Ch33（[[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]]）は航空（CHIRP）・医療・製造業（CAPA）から非難なき振り返りが業界横断で有効であることを確認し、Ch16（[[@2016__OReilly__SRE Book - Chapter 16 Tracking Outages]]）の Outalator はパッシブ集約とタグベースメタデータでアウテージ追跡を自動化する。LLM エージェントが自動生成する RCA レポートの「非難なき説明」要件は、このブレームレス文化の自動化版として読める。(Source: [[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]], [[@2016__OReilly__SRE Book - Chapter 16 Tracking Outages]], [[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]]) - **オペレータエラーの支配性は 20 年超にわたって構造的に持続しており、現代の AIOps エージェント評価の障害モデルにも影を落とす**: Gray (1986) が Tandem システムでオペレータエラーを最大の障害原因（42%）として同定し、[[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] が 17 年後のインターネットサービスで同じ傾向（Online 33%、Content 36%）を再確認した。設定エラーがオペレータエラーの 50% 以上を占める点も両時代で共通する。一方、2026 年の ICSE 研究は GenAI クラウドサービスの本番インシデントで設定問題 24.5%・運用操作ミス 12.7% を報告しており、「人間起因の障害が全体の 3〜4 割を占める」というパターンは技術世代とアーキテクチャを超えて持続している。この構造的持続性は、障害注入ベースの AIOps ベンチマークが人間起因障害を再現しにくいという前述の乖離問題の根底にある。(Source: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **workflow artefacts(runbook・チケット・postmortem)は「知識ベース」かつ「攻撃面」という二面性を持つ**: 本 wiki の ARFBench スレッドは Slack タイムラインや OCE の事後報告を AI 評価の一次データに昇格させる流れを肯定的に記録した。[[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] は同じ artefacts を「知識ベースであると同時に攻撃面」として両義的に扱い、untrusted な成果物(自由形式チャット・外部文書・ユーザー影響下のログ文字列)は独立チェックなしに特権行動を駆動してはならない、と規律づける(§II-D、§VI-E)。さらに runbook は古び・postmortem は機微情報を省き・チケットは曖昧/敵対的なテキストを含みうる系統的バイアス源だとし、authoritative / advisory / untrusted の信頼階層(表I)で扱うことを求める。インシデント記録を AI の燃料にする流れと、それを攻撃面として警戒する流れは、信頼階層と独立検証の規律で初めて両立する([[エージェント運用安全性]] に詳述)。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]) ## 未解決の問い - OpsAgent の自己進化(PPO+反省)は、訓練データ分布と乖離した新種インシデント(未知の障害種別・未監視コンポーネント)でどれだけ汎化するか。53 日本番で「初出パターンが後から解決できるようになった」観測はあるが、汎化の上限と失敗条件は未解析。([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]]) - OpsAgent の training-free プロセッサの閾値(3σ・95 パーセンタイル・TF-IDF 80 パーセンタイル)はシステムごとに調整が必要か。OPENRCA の 3 環境(Telecom/Bank/Market)では共通閾値で機能したが、異なるアーキテクチャ・監視密度を持つシステムへの移植時に人手チューニングが生じないか。([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]]) - 反省ベース知識ベースは誤診断の反省でなく成功診断だけを蓄積する設計だが、稀で重要な障害パターン(複雑インシデント)は成功例が少なく知識ベースに過小収録される。定型インシデント 97% 対 複雑 54% の差は知識ベースの偏りを反映しているか。([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]]) - 反復インシデントの TSG 品質を自動的に評価・改善する仕組みはどう設計すべきか。FLASH が提案する TSG 自動リファイニングツール(将来課題として記載)は、AlertGuardian の rule refinement エージェントと同型の問いを持つが、「診断ステップの文書」対「アラートルール」という対象の違いがある——前者は人間向け手順書、後者は機械実行可能ルールで、AI 向け再構成の難しさは質的に異なるか。([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - ステータス監視(status supervision)による命令分解は TSG 以外の知識ベース(runbook・KB 記事・postmortem)に適用できるか。反復インシデントに限定せず、非反復インシデントの診断にも有効か。命令分解のステータス設計はドメインごとに人手で定義する必要があるか、それとも自動抽出できるか。([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - GenAI クラウドサービスの監視未成熟（38.3% 人手検知・偽陽性 11.0%）は成熟とともに収束するか、それとも GenAI 固有の症状（無効推論・応答品質劣化）は本質的に自動検知が困難か。 - 症状と根本原因の多対多マッピング（図 7）は、LLM エージェントの hypothesis-driven RCA（[[Bits AI SRE]]・[[Stratus]]）でどこまで解けるか。人手 OCE の事後報告で得られた分類体系を、エージェントの推論空間にどう埋め込むか。 - 自己回復（19.7%）は「障害が自然に解消する」パターンだが、[[AIOpsLab]] や [[SREGym]] のベンチマークは自己回復シナリオを含んでいるか。含まないなら、エージェント評価は 2 割近い「介入不要」ケースの判別能力を測っていない。 - GenAI インシデントの TTM が 1.83 倍長い構造的原因は、監視の未成熟・症状の複雑さ・緩和の多様化のどれが支配的か。TTM 短縮は検知精度の改善・診断の自動化・緩和の自動化のどこに最も効くか。 - 本研究は Microsoft 単社のデータに基づく。他の GenAI プロバイダー（AWS Bedrock・Google Cloud・Anthropic Claude 等）のインシデント特性が質的にどう異なるか、産業横断的な比較研究は未着手。 - [[FLASH]]([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]])の実世界 TSG 品質調査(52 件)は、Ambiguous Action(約 40%)・Unavailable Tools(約 20%)が主要な自動化阻害要因であり、「Pass」(そのまま自動化可能)は約 8.5% にすぎないことを示す。この知見は「TSG さえあれば自動化できる」という楽観的仮定への反証であり、AlertGuardian の rule refinement(1,174 提案→375 受容=32%)と並べると「既存の人間向けドキュメント/ルールをそのまま AI に渡しても機能しない」という共通の壁が浮かぶ——ドキュメント品質と AI 向け再構成は別問題として扱う必要がある。(Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - [[ARFBench]] はインシデント対応の問い(時系列の異常推論)をシングルターンの多肢選択 QA に切り出すが、実際のインシデント管理は検知→トリアージ→診断→緩和のマルチターン・非線形プロセス([[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] の自己回復 19.7% も含む)。シングルターン TSQA の能力は、エージェントがライフサイクル全体を進める能力にどこまで転移するか。緩和戦略の推奨やインシデントパターンへの紐づけといった自由形式の問いを含む評価は未着手。([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]) - [[AlertGuardian]] の上流介入(rule refinement)では Temporal Analysis 系のルール提案の受容率が極端に低い(7.5〜14.0%)。なぜ時間的分析に基づくルール改善は人間に受容されにくいのか——時間窓・閾値の妥当性が運用文脈に強く依存し自動提案が外しやすいのか、それとも提案の説明可能性が不足するのか。上流のルール改善が効きにくいルール種別は何で、ライフサイクル全体最適化のうちどの段が人間の信頼を得にくいかは未解明。([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) ## 関連 - ソース: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] / [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] / [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] / [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] / [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]] / [[@2024__OSR__LLexus - an AI agent system for incident management]] / [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]] / [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]] / [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] - 概念: [[AIOps]]（4-level taxonomy）/ [[根本原因分析]]（RCA、ライフサイクル第 3 段）/ [[障害緩和]]（ライフサイクル第 4 段）/ [[TSG自動化]] / [[時系列質問応答]] / [[SRE Benchmark]] / [[エージェント運用安全性]] / [[NetOps]] - エンティティ: [[Microsoft]] / [[AIOpsLab]] / [[SREGym]] / [[Bits AI SRE]] / [[ARFBench]] / [[Datadog]] / [[AlertGuardian]] / [[LogPilot]] / [[Tencent]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[LLM4SRE - MOC]] / [[SRE - MOC]] ## 出典 - [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]（§I–VIII、Table I、Figure 7–9） - [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]（Appendix A.2 インシデント対応ワークフローと TSQA の位置づけ） - [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]（§V-A 本番実績 MTTR 156→21 分・日次 30 万→1.5 万、表 III/IV、§IV-C rule refinement の 4 エージェントと 1,174 提案→375 受容） - [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]]（§II-C AIOps ライフサイクル detect/triage/diagnose/mitigate/learn、§VI-C 段の継ぎ目の翻訳、§II-D/§VI-E workflow artefacts の信頼階層と攻撃面、表IV タスク taxonomy、表I operational artefacts as data types） - [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]（表2 5 手法精度比較・平均 73.9% 対 60.7%(TaskWeaver)、表3 人手評価 TTM 5.3 分・総合 4.3/5、表4+図9 TSG 品質問題 6 カテゴリ・Pass 約 8.5%、§4.3 ヒントサイト統合効果 +6%〜+7.5%） - [[@2024__OSR__LLexus - an AI agent system for incident management]]（§1 問題設定・TSG の 3 課題、§3 設計原理・プランコンパイラ、§4 マルチステップ計画生成、表1〜2 コスト分析、図10 オンライン方式との費用対効果比較） - [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]（§3 92 TSG 実証研究・並列性 ~46%、§4 TSG Mentor F1 0.81、§5 DAG 抽出 F1 94.89%・QPP 97.3%・GPT-4.1 約 94%・実行時間 32.9〜70.4% 削減） - [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]（3 大規模インターネットサービスの障害原因分析、オペレータエラー支配性、設定ミスが最大カテゴリ、TTR の 75% がオペレータ起因）