# TSG自動化 ## 定義 TSG自動化(Troubleshooting Guide automation)は、人間の運用者向けに書かれた**トラブルシューティングガイド(TSG)**——反復インシデントの診断・緩和手順を記した半構造のドキュメント——を、LLM エージェントが解釈・実行する取り組みを指す。[[インシデント管理]] のうち**反復インシデント(recurring incident)かつ既存 TSG が存在する**領域を対象とし、「何が根本原因か」を新規に探る [[根本原因分析]] とは問いが異なる——TSG に書かれた診断・緩和ステップを**信頼して実行できるか**という実行信頼性の問題として立つ([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]])。[[Microsoft]] 系の 3 本([[FLASH]]・[[StepFly]]・[[LLexus]])が、いずれも自社の本番 TSG(数万件規模、1 件あたり中央値 800 語超)を題材にこの問題に取り組む。 ## 横断的知見 - **「TSG 実行」対「ワークフロー生成」——FlowXpert が切り開く上流問題**: FLASH・LLexus・StepFly の 3 本は「既存 TSG を LLM エージェントで実行する」問題を扱う。[[FlowXpert]]([[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]], KDD 2025)はその**上流**——「TSG が存在しないドメインから運用ドキュメントを元にワークフロー自体を生成する」問題に取り組む。Huawei Cloud では OCE 7 人×7 時間かけてワークフローを手作成していたが、FlowXpert は 22.1 秒に短縮。TSG 自動化の研究空間は「実行」と「生成」の 2 軸に広がった——既存 TSG のある組織は実行自動化(FLASH 型)、ない組織は生成自動化(FlowXpert 型)が先決になる。(Source: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) - **TSGen は「生成」軸をさらに二分する——運用ドキュメントからの生成(FlowXpert)と、生インシデントデータからの生成(TSGen)**: [[TSGen]]([[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]], FSE Companion '26)は著者ら自身の言葉で「過去インシデントデータのマイニングから構造化 TSG をゼロから生成する初の試み」と位置づけられる。FlowXpert が既存の運用ドキュメント(SOP・ランブック等の人間が書いた文書)を出発点にワークフローを生成するのに対し、TSGen は文書化された手順が一切なくても**インシデントチケット・ログ・議論という生データ**だけから TSG を合成する——フィルタリング(ルールベース+LLM 意味ラベリング)→蒸留(TF-IDF+Ward 階層クラスタリングで medoid 抽出→統一フォーマット化)→DAG 化生成(one-shot + 単一パス制約の反復更新)という 3 段パイプラインで実現する。これにより TSG 自動化の「生成」軸は、(a) 運用ドキュメントを機械可読ワークフローへ変換する FlowXpert 型と、(b) 一次資料(過去インシデント)から TSG そのものを新規に合成する TSGen 型の 2 系統に分岐した。人間が書いた運用ドキュメントすら存在しない、あるいは陳腐化している組織には TSGen 型が唯一の選択肢になる。(Source: [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]], [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) - **TSGen の反復更新は「単一パス制約」で FLASH の status supervision と同じ方向の安全設計を、生成・更新の局面で具体化する**: [[FLASH]] がインシデント実行時に status に沿った段階実行でハルシネーションを抑えるのに対し、[[TSGen]] は TSG **更新**時に、1 更新サイクルあたり DAG への追加・変更を単一パスのみに制限するバリデータを導入する。これは「LLM の自由な書き込みをどう境界づけるか」という [[エージェント運用安全性]] の設計原理が、実行(FLASH)だけでなく生成・更新(TSGen)の局面にも一貫して現れることを示す。実験でも V0→V4 の反復更新でカバレッジが単調に改善し(42.3%→53.3%)、エラー累積やハルシネーションドリフトが生じないことが確認された。(Source: [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **人間作成 TSG の検索精度の低さが、TSG 自動化研究全体の存在意義を裏付ける**: TSGen のベースライン比較で、既存の人間作成 TSG は Retrieval Accuracy が 0.012 と際立って低く、モニタ間の弁別力をほぼ持たないことが定量的に示された(TSGen は 0.476〜0.482)。この結果は FLASH が TSG 品質調査(52 件)で Ambiguous Action 約 40%・そのまま自動化可能な Pass は約 8.5% と報告した「人間向け TSG は LLM 消費に適さない」という知見と独立に収束する——**生成側(TSGen)でも実行側(FLASH)でも、人間が書いた TSG の構造的な不十分さが自動化の出発点になっている**。(Source: [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **「LLM をワークフローのどの時点で働かせるか」で 3 設計が分岐する**: 3 本はともに Microsoft 発の TSG 自動化だが、LLM を呼ぶ時点が異なる。(1) [[FLASH]] は**インシデント時(オンライン)**に LLM を使い、複雑な TSG 命令を識別済みステータスに沿って分解する status supervision と、過去の失敗から LLM が生成する hindsight integration で多段実行の信頼性を高める。(2) [[LLexus]] は LLM を**計画フェーズ(オフライン)に前置**し、TSG を BPMN 風フローチャート(アクション/条件分岐/イベントノード)へコンパイルしておき、実行時は既存ツール(Powershell・Kusto)を**決定論的に**呼ぶだけにする。(3) [[StepFly]] は**両方**——オフラインで構造化実行 DAG と Query Preparation Plugins(QPP)を抽出し、オンラインは DAG ガイド付き scheduler-executor + memory で軽量に実行する。オンライン設計(FLASH)はインシデントごとの変動に柔軟だが LLM コストと非決定性を実行時に抱え、オフライン前置設計(LLexus・StepFly)は一回の前処理コストを払えば以後の実行を安く・速く・確実にできる。(Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]], [[@2024__OSR__LLexus - an AI agent system for incident management]]) - **3 本が独立に「TSG 品質こそが自動化の律速」へ収束する**: 最も強い横断知見は、TSG をそのまま LLM に渡しても動かないという共通の壁である。[[FLASH]] は実世界 TSG 品質調査(52 件)で Ambiguous Action が約 40%・そのまま自動化可能な Pass は約 8.5% にすぎないと定量化し、自動リファイニングツールを将来課題に挙げる。[[StepFly]] はワークフローの第 1 段まるごとを TSG 品質改善ツール [[TSG Mentor]](品質問題 CP/CF/DF/DI/PS を検知、F1 0.81)に充てる。[[LLexus]] は低品質 TSG が反復ラウンドを増やし計画コストを約 3 倍に膨らませると報告しつつ、TSG を source of truth として扱うことで自動化の副産物として TSG 品質も向上する正のフィードバックを観測する。「人間向けドキュメントを AI 向けに作り直す」ことが共通の主戦場で、これは [[インシデント管理]] の [[AlertGuardian]] の rule refinement(人間向けルールの AI 向け改善、受容率 32%)と同型の壁だ。(Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]], [[@2024__OSR__LLexus - an AI agent system for incident management]]) - **オフライン前処理は「インシデント件数でなく TSG 件数」にコストを移す経済構造を生む**: [[LLexus]] は計画フェーズを TSG 作成・更新時(1 件あたり一回払い $0.60〜$1.71)に前置するため、同じ TSG を何件のインシデントに使ってもオンラインの追加 LLM コストがゼロで、インシデント件数が増えるほどオンライン方式(FLASH 型)に対しコスト優位が拡大する。[[StepFly]] も DAG+QPP のオフライン抽出(QPP 抽出成功率 97.3%・DAG 抽出 F1 94.89%)で実行時の LLM 負荷を構造的に削減する。コストを「実行(インシデント)回数」から「TSG 本数」へ移すこの設計は、反復インシデントの「同じ手順を何度も使う」性質を経済的に突く。(Source: [[@2024__OSR__LLexus - an AI agent system for incident management]], [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) - **並列実行は StepFly 固有の軸で、SRE チームの協調診断を模す**: TSG を DAG として構造化すると独立ステップが見え、[[StepFly]] は約 46% の TSG が並列化の余地を持つと示し、並列化可能 TSG で実行時間を 32.9〜70.4% 削減する(プロトタイプで実インシデントの緩和時間中央値も約 34% 短縮)。FLASH/LLexus が逐次実行の信頼性・確実性を追うのに対し、StepFly は DAG が露わにする並列性で**遅延**も攻める。これは複数の調査線を同時に走らせる SRE の協調診断を模した構造で、[[ワークフロー自動化]] の依存グラフ駆動スケジューリングを LLM エージェントに適用した例といえる。(Source: [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) - **決定論的オンライン実行は [[エージェント運用安全性]] の「書き込み境界の確実性」と接続する**: [[LLexus]] が実行時を決定論的に保つ設計は、LLM の非決定性を制御面の近くから排除する——これは [[エージェント運用安全性]] が論じる「提案(LLM)と実行(決定論的ツール呼び出し)の分離」「書き込み境界の検証/確実性」と同じ向きの安全設計を、TSG 自動化の文脈で具体化したものと読める。FLASH の status supervision も、自由な ReAct でなくステータスにゲートされた段階実行で暴走を抑える点で同根。(Source: [[@2024__OSR__LLexus - an AI agent system for incident management]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **RCACopilot のインシデントハンドラは TSG 自動化の「先祖」かつ並走系統——「手順実行」と「RCA」を統合した最初の本番稼働 LLM システム**: [[RCACopilot]]([[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]])のインシデントハンドラは OCE がアラート種別ごとに有向グラフワークフロー(scope/query/mitigate の 3 種ノード)を構築する点で TSG/SOP と同型だが、出力は緩和ステップ実行でなく「根本原因カテゴリ予測 + 説明文生成」である。FLASH/LLexus/StepFly が「TSG 実行=既知の緩和手順を信頼して動かす」問題に閉じるのに対し、RCACopilot のハンドラは「診断情報収集ワークフロー + LLM 圧縮・予測」を統合し、TSG 自動化と LLM ベース RCA を**同じハンドラ抽象**で扱う。Microsoft 30 超チーム・4 年以上の本番実績は、LLexus/StepFly のオフライン前置設計が経済的に正しいことを別経路で裏付ける(ハンドラ構築コストを TSG 件数に押し付ける同じ原理)。TSG 自動化研究の射程は「既知緩和手順の信頼実行」だけでなく「ハンドラ抽象による診断+緩和の統合実行」を含むべきで、RCACopilot はその第三系統。(Source: [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]], [[@2024__OSR__LLexus - an AI agent system for incident management]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **SOP フローは「TSG 自動化の RCA 特化版」——Microsoft 系 3 本との接点と差異**: [[@2025__WWW__Flow-of-Action - SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis]] は SOP(標準操作手順)を知識ベースに埋め込み、SOP フロー(match_sop/generate_sop/generate_sop_code/run_sop)でエージェントの行動をソフト制約する。これは本 wiki の [[FLASH]] が TSG を status supervision で使い、[[LLexus]] が TSG を事前にフローチャートにコンパイルするパターンと同じ「人間が書いた手順書を LLM の行動制約に転換する」構造を持つ。ただし Flow-of-Action は TSG/SOP が**存在しない新種障害に対して generate_sop で SOP を LLM 自動生成**できる点が LLexus/FLASH と異なる——[[LLexus]] 自身が「TSG なしの新種には ReAct が必要」と認める限界を部分的に克服する試みだ。また Flow-of-Action の SOP コード変換(generate_sop_code)は [[StepFly]] の DAG 化に近く、どちらも「逐次テキスト実行の確率的誤りをコード/DAG による一括実行で回避する」設計を採る。差異は対象: Flow-of-Action は **RCA(未知の根本原因を探索)** に特化するのに対し、Microsoft 3 本は **反復インシデントの既知手順の実行** を主眼とする。(Source: [[@2025__WWW__Flow-of-Action - SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis]], [[@2024__OSR__LLexus - an AI agent system for incident management]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **OScope は「TSG 検索」を LLM 実行の前段問題として単独で扱い、症状記述の意味的不整合を専用モデルで解消する第 5 の設計軸を開く**: FLASH/LLexus/StepFly/Flow-of-Action がいずれも「(取得済みの)TSG/SOP をどう実行・検証するか」を主戦場とするのに対し、[[OScope]]([[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]], ICSE-SEIP '26)はその**手前**——「複数の OCE が異なる用語・表現スタイルで書いた症状記述から正しい TSG をどう検索するか」を独立した課題として切り出す。Knowledge Aligner という専用ファインチューニング済みモデルで症状記述を標準化してから検索する設計は、20 件の実証研究で AC@5 を 0.75(ベクトル検索単体)から 0.9(意味的整合+ベクトル検索)へ改善し、アブレーションでも Knowledge Aligner 除去時に AC@3 が 0.713→0.406 まで劣化する。TSG 自動化の研究空間は「検索(OScope)→実行(FLASH/LLexus/StepFly)→生成(FlowXpert)」の 3 段に整理できる——TSG が「存在するが見つからない」問題は「存在しない」問題(FlowXpert)とも「見つかったが実行できない」問題(FLASH 等)とも異なる、第 5 の設計軸である。(Source: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]]) - **チャンク単位の逐次 SOP 検証は StepFly の DAG 化と異なる「線形逐次+参照文脈」設計で、RAT を出典元とする独自系統**: [[OScope]] の Report Validator は初期診断報告 C={C₁,...,C_N} を DAG に構造化せず、線形チャンクとして先頭から逐次検証する——各ステップ Cᵢ の検証クエリに直前までの検証済み部分系列 C_{1:i-1} を含める設計で、これは Retrieval Augmented Thoughts(RAT, NeurIPS 2024 workshop)を出典とする。[[StepFly]] がオフラインで DAG+QPP を抽出し並列実行で高速化するのに対し、OScope は逐次実行(並列化なし)を選び、代わりに「直前の検証結果を次の検証の文脈に使う」ことで誤り伝播を防ぐ。アブレーションで Report Validator 除去時に AC@3 が 0.713→0.525 に劣化し、希少・複雑障害の診断が特に失敗しやすくなることが示された——TSG 自動化の「チャンク検証」という共通パターン(StepFly の DAG 検証・LLexus のフローチャート実行)に、RAT 系列という新しい実装系統が加わったことを意味する。(Source: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]]) - **OS レベル障害という新ドメインへの TSG/SOP 適用は、マイクロサービス/クラウドインシデント中心だった本概念の対象領域を拡張する**: FLASH・LLexus・StepFly・Flow-of-Action・RCACopilot はいずれもクラウドサービス/マイクロサービスのインシデント管理を対象とするのに対し、OScope は Linux/AliOS という OS レベルの障害診断に TSG(SOP)ベース設計を適用した最初の本 wiki 収録事例である。「メモリリーク」「CPU 負荷・ディスク I/O」のような OS カーネル/リソース管理層の障害は、マイクロサービスの「サービス間依存関係の異常伝播」とは異なる症状パターン(メトリクス・ログ・スタックトレースの 3 モダリティ)を持つが、SOP を CoT の外部制約として使う設計原理そのものはドメインを越えて転用可能であることを実証した。TSG 自動化がクラウドサービス固有の手法ではなく、より一般的な「人間の手順書を LLM の行動制約に転換する」パターンであることの追加証拠。(Source: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]]) ## 未解決の問い - FlowXpert が示す「生成 vs 実行」の分岐では、組織内に TSG が十分整備されるとどちらが主流になるか。FlowXpert で生成されたワークフローを FLASH/LLexus/StepFly で実行する、生成→実行パイプラインの統合は検討されているか。TSGen が生成する(TSG, DAG)ペアも FLASH/LLexus/StepFly の実行系にそのまま投入できる形式か、実証比較は未着手。(Source: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]], [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]]) - TSGen 型(生インシデントデータからの生成)と FlowXpert 型(運用ドキュメントからの生成)を同一組織・同一ドメインで直接比較した研究はまだない。運用ドキュメントが部分的に存在する組織では、両者をどう組み合わせるべきか(TSGen で骨格を生成し FlowXpert 型のワークフロー化で仕上げる、等)。(Source: [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]], [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) - TSGen の medoid ベースサンプリングは古いインシデントを選好するリスクを著者ら自身が認めている。直近イベントを優先する時間重み付けサンプリングは、StepFly の並列 DAG 抽出や OScope の意味的整合検索と組み合わせるとどのような効果を持つか。(Source: [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]]) - TSG 品質を自動で評価・改善する仕組みは、どの設計が一般化するか。FLASH の自動リファイニング(将来課題)・StepFly の [[TSG Mentor]](専用ツール)・LLexus の副産物的改善は同じ問いへの 3 つの解で、人間向け手順書を AI 向けに作り直す難しさは組織・ドメインを跨いで共通か。(Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) - オフライン前置(LLexus・StepFly)とオンライン柔軟性(FLASH)の境界はどこか。インシデントの変動が大きく TSG が頻繁に変わる(LLexus 調査では更新中央値 19 日)環境では、コンパイル済みプランの陳腐化と再コンパイルコストが前置の利点を相殺しうる。どの変動レベルでどちらが勝つか。 - 並列化の識別自体を自動化できるか。[[StepFly]] は DAG から並列性を取り出すが、TSG の並列化を意識した改訂は依然 SRE の手作業であり、LLM による自動並列化識別が次の課題。(Source: [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) - 3 本とも Microsoft 内部の TSG 形式・本番データに基づく。TSG のフォーマット多様性が大きい他組織で同じ手法が成立するか、産業横断の検証は未着手。 - TSG 自動化は「TSG が存在する反復インシデント」を前提にする。本番インシデントのうち使える TSG を持つ割合はどの程度か、TSG の無い新種インシデントには [[LLexus]] 自身が認めるとおり ReAct 型エージェントが必要——既知(TSG 自動化)と未知(探索型エージェント)の境界をどう設計し、どう切り替えるか。(Source: [[@2024__OSR__LLexus - an AI agent system for incident management]]) - RCACopilot のハンドラ抽象(scope/query/mitigate アクションノード + LLM カテゴリ予測)を Microsoft 内部の TSG ライブラリへ適用すると、FLASH/StepFly が抱えていた「TSG 形式の自由度が LLM 解釈を不安定にする」問題を解消できるか。ハンドラを構造化 DSL として標準化することで、TSG 品質改善コスト([[TSG Mentor]] が 5 種類の品質問題に費やすコスト)が削減される可能性は。(Source: [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]], [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) - OScope の Knowledge Aligner(症状記述の意味的整合による TSG 検索)を、FlowXpert の生成型ワークフローや FLASH/StepFly の実行型ワークフローと組み合わせるとどうなるか。「検索精度が低いまま実行だけ高度化しても効果は頭打ちになるはず」という仮説を、Knowledge Aligner を FLASH/StepFly の TSG 取得段に組み込んで検証する研究は未着手。(Source: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]]) - OScope のチャンク逐次検証(RAT 系列)と StepFly の DAG 並列検証は、同じ「初期草案を SOP/TSG で後段検証する」問題に対する 2 つの解だが、直接比較された例はない。逐次(誤り伝播に強いが低速)と並列(高速だが独立性の仮定が必要)のどちらが OS レベル障害・マイクロサービス障害それぞれで優位か、ドメイン横断の比較評価が必要。(Source: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]], [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) - OScope は症状記述の標準化に 157 件の障害事例全件を 3 名のシニア OCE が手動で書き換える初期コストを払っている。FLASH/StepFly の TSG 品質改善ツール([[TSG Mentor]] 等)と同様、この症状記述標準化を自動化・半自動化できるか。LLM 自身に標準化を担わせるセルフトレーニングループは有効か。 ## 関連 - ソース: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]] / [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]] / [[@2024__OSR__LLexus - an AI agent system for incident management]] / [[@2025__WWW__Flow-of-Action - SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis]] / [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]] / [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]] / [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]] - 概念: [[インシデント管理]] / [[根本原因分析]] / [[障害緩和]] / [[AIOps]] / [[エージェント運用安全性]] / [[ワークフロー自動化]] / [[マルチモーダル障害診断]] - エンティティ: [[FLASH]] / [[StepFly]] / [[TSG Mentor]] / [[LLexus]] / [[TaskWeaver]] / [[Semantic Kernel]] / [[Azure Durable Functions]] / [[Microsoft]] / [[OScope]] / [[Shenglin Zhang]] / [[Alibaba Group]] / [[TSGen]] / [[Yi Xiao]] / [[Chongqing University]] - 関連 MOC: [[LLM4SRE - MOC]] / [[SRE - MOC]] ## 出典 - [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]](§3.1 実証研究 Table 1、§4.2 Knowledge Aligner、§4.3 SOP-Guided Root Cause Analysis、§5.2-5.3 Table 3〜4 アブレーション) - [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]](§3 status supervision/hindsight、表2 +13.2%、表4+図9 TSG 品質 6 カテゴリ・Ambiguous Action 約 40%・Pass 約 8.5%) - [[@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% 削減、§7 緩和時間中央値 ~34% 削減) - [[@2024__OSR__LLexus - an AI agent system for incident management]](§1 TSG の 3 課題、§3 計画前置の設計原理、§4 マルチステップ計画生成、表1〜2・図10 コスト分析 $0.60〜$1.71) - [[@2025__WWW__Flow-of-Action - SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis]](§2.1 知識ベース設計、§2.2 SOP フローツール Table 1、§2.3 generate_sop/generate_sop_code の役割、Table 3 Flow-of-Action vs FLASH/LLexus 方式との設計対比) - [[@2026__FSE Companion__TSGen - Automated Troubleshooting Guide Generation]](§4 パイプライン全体・Algorithm 1 二層キャッシュフィルタリング・Algorithm 2 単一パス制約の反復更新、Table 4 ベースライン比較 Coverage 0.548・Retrieval Accuracy 約 3 倍、Table 5 アブレーション Filtering 除去で Coverage ↓49.3%・Structured Generation 除去で Retrieval Accuracy ↓91.2%、Figure 4 反復更新でのカバレッジ改善 42.3%→53.3%、§7.2 実運用受容率 38/53)