# 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]]) - **「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]]) - **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]]) ## 未解決の問い - FlowXpert が示す「生成 vs 実行」の分岐では、組織内に TSG が十分整備されるとどちらが主流になるか。FlowXpert で生成されたワークフローを FLASH/LLexus/StepFly で実行する、生成→実行パイプラインの統合は検討されているか。(Source: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) - 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]]) ## 関連 - ソース: [[@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]] - 概念: [[インシデント管理]] / [[根本原因分析]] / [[障害緩和]] / [[AIOps]] / [[エージェント運用安全性]] / [[ワークフロー自動化]] - エンティティ: [[FLASH]] / [[StepFly]] / [[TSG Mentor]] / [[LLexus]] / [[TaskWeaver]] / [[Semantic Kernel]] / [[Azure Durable Functions]] / [[Microsoft]] - 関連 MOC: [[LLM4SRE - MOC]] / [[SRE - MOC]] ## 出典 - [[@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 方式との設計対比)