# StepFly: Agentic Troubleshooting Guide Automation for Incident Diagnosis Navigation: [[インシデント管理]] | [[AIOps]] | [[agentic SRE]] | [[根本原因分析]] > [!abstract] 概要 > 大規模ITシステムにおける効果的なインシデント管理はトラブルシューティングガイド(TSG)に依存しているが、その手動実行は遅くミスを招きやすい。インシデント管理タスクの自動化にはLLMが有望なことが最近の研究で示されているが、既存のLLMベースの解決策はいくつかの重要な課題、すなわちTSG品質問題の管理・複雑な制御フローの解釈・データ集約的クエリの処理・実行並列性の活用に対する専門的なサポートが欠けている。我々はまず92本の実世界TSGに対する包括的な実証研究を実施し、その知見に導かれてStepFlyを提案する。StepFlyはトラブルシューティングガイド自動化のための新規のエンドツーエンドなエージェント型フレームワークである。本アプローチは3段のワークフローを特徴とする。第1段は包括的なガイドラインとツールTSG Mentorを提供し、SRE(Site Reliability Engineer)がTSG品質を改善するのを支援する。第2段はLLMを用いてオフラインで前処理を行い、非構造化TSGから構造化された実行有向非巡回グラフ(DAG)を抽出し、専用のQuery Preparation Plugin(QPP)を作成する。第3段はDAG誘導型scheduler-executorフレームワークとメモリシステムを用いてオンラインで実行し、正しいワークフローを保証しつつ独立ステップの並列実行をサポートする。実世界TSGとインシデントの実証評価により、StepFlyはGPT-4.1で約94%の成功率を達成し、より少ない時間・トークン消費でベースラインを上回ることを示す。さらに並列化可能なTSGに対して実行時間を32.9%から70.4%削減するという顕著な成果を達成する。コードとサンプルデータはhttps://github.com/microsoft/StepFlyで公開されている。 ## 論文情報 - arXiv ID: arXiv:2510.10074 - バージョン: v2 (cs.AI, 2026-04-21改訂)、v1 (2025-10) - 掲載誌: Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE136 (2026年7月) - DOI: https://doi.org/10.1145/3808143 - コード: https://github.com/microsoft/StepFly - 著者: - [[Jiayi Mao]](Tsinghua University, China) - [[Liqun Li]](Microsoft, China) - [[Yanjie Gao]](Microsoft Research, China; Renmin University of China, China) - [[Zegang Peng]](Tsinghua University, China) - [[Shilin He]](Microsoft, China) - [[Chaoyun Zhang]](Microsoft, China) - [[Si Qin]](Microsoft, China) - [[Samia Khalid]](Microsoft, USA) - [[Qingwei Lin]](Microsoft, China) - [[Saravan Rajmohan]](Microsoft, USA) - [[Sitaram Lanka]](Microsoft, USA) - [[Dongmei Zhang]](Microsoft, China) ## 概要 StepFlyはMicrosoft・Tsinghua Universityの共同研究であり、LLMを活用してTSGの実行を自動化するエージェント型フレームワークである。92本の実世界TSGに対する実証研究から得た知見を出発点として設計されており、3段構成(品質改善・オフライン前処理・オンライン実行)で従来手法の欠点を体系的に克服する。プロトタイプは本番環境で70チーム以上・170以上のモニタから毎週数百回起動されており、インシデント緩和時間の中央値を約34%削減した(§7)。 ## 問題設定 大規模クラウドサービスではSREがTSGを参照しながらインシデントを手動で診断・緩和する。この手動実行には4つの根本的課題がある。 1. **TSG品質問題**: TSGはSREが作成するスパースなメモであり、暗黙知が省略されがちで、LLMエージェントにとっても人間にとっても実行困難な箇所が多い。92本のTSGを4名(研究者2名+SRE2名)がラベリングした結果、明確性・精度(CP)37.4%、データベース指示(DI)27.2%、データフロー(DF)20.4%、制御フロー(CF)5.1%、構造(PS)9.9%の問題が分布していた(図4)。Cohen's κ = 0.78(十分な一致)。 2. **複雑な制御フロー**: TSGは条件分岐・早期終了を含む複雑な制御フローを持ち、LLMが正しい実行パスを辿ることが困難である(知見1)。92本中5〜15ステップが最多で、最大30ステップに達するものもある(図3b)。 3. **データ集約的クエリ**: Kusto Query Language(KQL)クエリテンプレートがTSGの平均35.85%を占め(1TSGあたり平均4.4クエリ、平均26.6行)、LLMによるオンザフライ生成は命令逸脱・構造省略・構文エラーの3種類の誤りを招く(知見3)。 4. **並列性の未活用**: TSGの約46%が並列化の可能性を持つ(独立パス40.5%・複数データソース28.6%・複数分析種別26.2%・ループ4.8%)にもかかわらず、従来は逐次実行されていた(図2、知見2)。 ## 提案手法 StepFlyは3段構成のエンドツーエンドフレームワークである(図5)。 ### 段1: TSG品質改善(オフライン) **品質改善ガイドライン**: 各ステップのテンプレート(タイトル・手順・次ステップへの条件付き遷移)と既出問題のチェックリストを整備し、SREがTSGを作成・改訂する際の規範とする。LLMエージェントだけでなく人間の読者にも有益な形式を保持することが設計上の要件である。 **TSG Mentor ツール**: TSGを入力として受け取り、表1の5カテゴリ(CP/CF/DF/DI/PS)に従って問題を自動検知し、インライン注釈と改善提案を付与して再フォーマット済みTSGを出力するLLMベースのツール。品質ガイドライン・問題事例・サンプルTSGを含む特化プロンプトを使用し、ベクトル距離に基づいて3本のTSGをフューショット例として動的に選択する。92本に対するleave-one-out評価で再現率0.78・適合率0.85・F1スコア0.81を達成した(§4.1)。 ### 段2: オフライン前処理 **実行DAG抽出**: TSGを有向非巡回グラフ $G = (V, E)$ に変換する。各ノード $v \in V$ はTSGステップに対応し、各辺 $e \in E$ はステップ間の遷移を表す。条件付き辺と無条件辺を区別し、JSON形式で出力する。15本のTSGに対して3回の独立実験を実施した結果、全体F1スコア約94.89%・ノードレベル99%超・辺レベル約93.47%・条件レベル正確度約91.78%を達成した(表2)。 **Query Preparation Plugin(QPP)抽出**: TSGに含まれるクエリテンプレートを解析し、プレースホルダをパラメータとして受け取るプラグインとして自動生成する。これにより実行時にLLMがクエリを生成する必要がなくなる。15本のTSGに含まれる86クエリテンプレートを対象とした3回の実験(計258回の抽出)で成功率97.3%を達成。失敗はエスケープ文字の誤りのみ(§5.3)。 ### 段3: オンライン実行 **Scheduler**: イベント駆動型設計でDAGのノード状態(未知・有効・無効)を管理し、実行可能なステップをExecutorに割り当てる。ステップ完了イベントに応じて後続辺・ノードの状態を更新する。再試行機構を持ち、失敗ノードは後続辺をすべて無効化して下流実行を防止する(§4.4.1)。 **Executor**: 個々のTSGステップを実行するエージェント。各Executorはインシデントレポート・TSGドキュメント・プラグイン・現在ステップのDAGノード/辺・実行履歴を初期コンテキストとして受け取る。ReAct[43]スタイルの反復的な思考-行動サイクルとCoT推論[38]でサブタスクを完了し、辺の状態を更新する(§4.4.2)。 **メモリシステム**: キーバリュー型アーキテクチャ(MongoDB実装)でプラグイン間のデータ受け渡しを管理する。データリトリーバルプラグインがデータをメモリに格納し、コードインタープリタがキーで参照することで、大きなデータペイロードをテキストとして会話履歴に流す必要がなくなる(§4.4.4)。 **並列化実行**: SchedulerがDAGの独立ステップを複数のExecutorに割り当てることで並列実行を実現する。ただし、既存TSGは依存関係を明示しないため、SREが数行の文言修正でTSGを並列化対応に改訂する必要がある(§4.5)。 ## 新規性 - TSG品質の実証的分類(5カテゴリ・92本)とTSG Mentorによる自動品質改善支援 - Nissist(知識グラフ)やLLexus(自己完結型実行ワークフロー)と異なる**軽量補助的DAG**設計—オリジナル文書の補足メタデータとして保持し、維持管理と検証を容易化 - QPP抽出によるオンザフライクエリ生成の廃止—クエリエラーを大幅削減 - スケジューラ・エグゼキュータ分離によるホモジニアスマルチエージェント並列化 ## 実験設定 - **データセット**: 92本の実世界TSGから選抜した15本と、Microsoftの大規模本番システムからサンプリングした実インシデント80件(3〜28ステップ、平均9ステップ)(§5.1) - **ベースライン**: ReAct(ReAct+CoT、単一エージェント)、TaskWeaver(二重エージェント、コードファースト) - **評価モデル**: GPT-4.1、GPT-4.1-mini、GPT-4o、Grok-3 - **評価指標**: 成功率(実行経路と診断結論の双方が正解と一致)・実行レイテンシ・総トークン消費量 - **並列化評価**: 7本の並列化可能TSGに対し2〜5のExecutor数で3回ずつ実験(§5.5) ## 実験結果 **TSG実行成功率**(表3): GPT-4.1でStepFlyが94.38%±0.88、ReActが71.25%、TaskWeaverが80.0%。GPT-4o比では最大約20%上回る。QPPを除いたStepFly-wo-QPPでも両ベースラインを上回り、QPPの効果はGPT-4.1-mini(10.63%向上)で特に顕著。 **時間・トークン消費量**(図10、GPT-4.1): StepFlyの中央値実行時間はReActの88%、TaskWeaverの38%。トークン消費量の中央値はReActの約71%、TaskWeaverの約61%。TaskWeaverの時間オーバーヘッドは双方向の多重通信に起因し、ReActのトークン外れ値はメモリシステム不在による大容量テキスト展開に起因する。 **並列化効果**(図11): 7本中最大はTSG6が70.6%削減(243.36秒→71.57秒)、TSG3が70.4%削減(207.93秒→61.59秒)、最小はTSG7で32.9%削減。5 Executorでの平均削減率は51.31%。 **ケーススタディ**(§5.6): TSG6(11ステップ)で、QPPにより9クエリ(計127行KQL)のオンザフライ生成を回避し、返却データ50KB超のコンテキスト表現を2KB未満(96%削減)に圧縮。メモリシステムにより394行のDataFrameを3行サンプル+スキーマ記述(200トークン未満)で表現。 ## 考察 - **実用性**: プロトタイプは170モニタ・70チーム以上からトリガされ、インシデント緩和時間の中央値を約34%削減(§7)。 - **安全性**: 現実装は診断操作(読み取り専用)に特化し、緩和アクションはSREの確認後に実施。全アクションをインシデント管理システムに構造化ログとして記録(§7)。 - **並列化とトークン消費のトレードオフ**: 並列化は実行時間を削減するが、早期終了条件次第でトークン消費が増加する場合もある(§7)。LLMによる並列化機会の自動識別は今後の課題。 ## 強み / 弱点・課題 **強み**: - 実証研究に基づいた設計(92本のTSG分析) - 3段フレームワークの各段が独立した課題に対応する明快な設計 - 本番デプロイ実績と定量的な効果の実証 - コードと合成インシデントデータの公開 **弱点・課題**: - 評価はMicrosoft内の特定サービスドメインのTSGに限定され、外部妥当性に制約あり(§6) - 並列化TSGへの改訂はSREの手動作業を要し、LLMによる自動化は今後の課題 - LLMの非決定性(温度固定で対処済みだが根本的な課題として残る) - TSG新規作成・保守・並列化改訂の自動化は今後の研究課題