> [!abstract] 概要(Abstract の日本語訳) > 最新のトラブルシューティングガイド(TSG)を維持することはクラウドシステムの信頼性にとって重要だが、手動でのメンテナンスはしばしば非効率や文書の陳腐化を招く。 > 本論文は、大規模言語モデル(LLM)を用いて過去のインシデントレポートから高品質かつ構造化された TSG を生成する自動パイプライン TSGen を提案する。 > 我々のアプローチは 3 段階から成る: (1) インシデントデータを診断上関連のあるカテゴリにフィルタリング・分類する、(2) 多様性と汎化性を確保するためにコアインシデントを蒸留する、(3) 蒸留された知識を根本原因と解決策を構造的に捉える有向非巡回グラフ(DAG)に整理する。 > 実世界のインシデント議論を活用することで、TSGen はライブのトラブルシューティングに合わせた動的かつ再利用可能なガイドを生成する。 > Microsoft の実世界インシデントに対する実験は、TSGen がベースラインと比較して 54.8% のインシデントカバレッジと約 3 倍高い検索精度を達成することを示す。 > さらに、このシステムは反復更新をサポートし、動的なクラウド環境に合わせてガイドを進化させることができる。 > 人手評価では、on-call エンジニアが、生成された TSG を人間が作成したものより有意に高く評価することが示された。 ## 論文情報 - タイトル: TSGen: Automated Troubleshooting Guide Generation - 著者・所属: [[Yi Xiao]]・[[Hongyu Zhang]]([[Chongqing University]])、[[Daniel Genkin]]・[[Chaoyun Zhang]]・[[Rujia Wang]]・[[Chetan Bansal]]・[[Bhala Ranganathan]]・[[Saravan Rajmohan]]・[[Minghua Ma]](corresponding author、[[Microsoft]]) - 媒体: 34th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, Companion Volume(**FSE Companion '26**)、2026年7月5〜9日、モントリオール、カナダ。ACM, 12 pages。 - DOI: [10.1145/3803437.3805239](https://doi.org/10.1145/3803437.3805239) - ライセンス: CC BY 4.0(This work is licensed under a Creative Commons Attribution 4.0 International License) ## 概要 クラウドサービスの障害対応で使われる Troubleshooting Guide(TSG)は、書かれていれば時間短縮に大きく効くが、手作業でのメンテナンスコストが高く欠落・陳腐化しやすい。TSGen は、過去のインシデントレポート(チケット・ログ・議論)を LLM でフィルタリング・蒸留・構造化することで、TSG をゼロから自動生成し、新規インシデントの到着に応じて反復的に更新する 3 段パイプラインである。Microsoft の実運用データでの評価により、既存の LLM ベースライン・人間作成 TSG のいずれよりも高いカバレッジ・検索精度・人手評価スコアを達成することを示した。 ## 問題設定 - **入力**: 特定のモニタまたは on-call チームに紐づく過去のインシデントレポート集合(メタデータ・要約・ログ/議論の時系列)。 - **出力**: 構造化された TSG(記述・症状・診断ステップ・緩和アクションを含む文書)と、それに対応する有向非巡回グラフ(DAG、ノード=判断/アクション、エッジ=逐次・条件分岐・エスカレーション・緩和の関係)。 - **前提**: 対象モニタ/チームには TSG が存在しない、または既存 TSG を新規インシデントで継続的に更新したいというシナリオの双方をカバーする。TSG は原則としてモニタ単位に 1 つ対応する(モニタとインシデント管理の関係については [[インシデント管理]] を参照)。 - **必要なデータ**: Microsoft のインシデント管理システムに 5 年以上蓄積された、約 80 サービス・約 5 万モニタにまたがる本番インシデントログ。 ## 提案手法 ### アーキテクチャ TSGen は「Filtering → Sampling → Distillation → Generation(One-shot + Iterative Updating)」の 4 ブロックからなるパイプラインである(Figure 3)。モニタ単位のスコープで過去インシデントを収集・解析し、二段フィルタリングでノイズを除去した後、階層クラスタリングで代表インシデントを抽出、蒸留により統一フォーマットへ正規化し、LLM に一度で TSG と DAG のペアを生成させる。以後は新規インシデントごとに反復更新する。 **Figure 3: TSGen の全体アーキテクチャ** ![[_attachments/2026_Unknown_TSGen_Automated_Troubleshooting_Guide_Generation/fig03-tsgen-architecture.png]] (Figure 3. 生データの「Collection & Parsing」から、Filtering(Rule-based → LLM-based)、Sampling(Hierarchizing & Sampling)、Distillation(統一フォーマットの Distilled Incident)を経て、One-shot Generation と Iterative Updating の両方で TSG を生成・更新する流れを図示。Source: Adapted from Figure 3.) ### アルゴリズム/手法の詳細 **1) Incident Data Processing(§4.1)** 各インシデントから ①メタデータ(タイトル・重大度・状態・タイムスタンプ・オーナー)、②要約(任意、しばしばログと重複するため補助扱い)、③ログ(時系列の議論。診断・仮説・緩和策・最終解決を含む)の 3 要素を抽出する。 - **Rule-based filtering**: 重大度が設定閾値以上、かつ人間が書いたログを 1 件以上含む記録のみを残し、自動緩和されたアラートの大半を除去する。 - **LLM-based filtering**: ルールベースを通過してもログ内には症状記述・トラブルシューティング手順・根本原因・緩和アクションと、無関係な雑談が混在するため、LLM で各ログ行に意味役割ラベル(symptom / root cause / troubleshooting step / mitigation / enrichment / other irrelevant)を付与し、無関係カテゴリを除外する。全ログへの LLM 問い合わせはコストが高いため、二層キャッシュ戦略を導入する: (1) 現在のモニタのセッション内でクラスタレベルラベルを再利用するローカルキャッシュ、(2) 全モニタ横断でラベル済みクラスタ中心を蓄積し新規モニタへの知識転移を可能にする永続キャッシュ。ログのクラスタリング Cluster(D) は TF-IDF 埋め込み + DBSCAN(デフォルトパラメータ)で行う(Algorithm 1)。 **2) Core Incidents Distillation(§4.2)** - **Incidents Sampling**: 各インシデントのメタデータ・要約・ログを連結して TF-IDF ベクトル化し、Ward 階層クラスタリングでデンドログラムを作成、ユーザー指定の k クラスタ(実装ではデフォルト k=12)にカットする。各クラスタから medoid(他メンバーへの平均コサイン距離が最小のインシデント)を代表として抽出し、多様性を保ちながら重複インシデントを除去する。候補プールが k 件以下ならそのまま全件使用する。 - **Information Distillation**: サンプリングされたインシデントを、LLM プロンプトで固定 3 セクションのテンプレート(Incident Title / Basic Information / Workflow)へ書き換え、症状・診断・根本原因の手がかり・チーム移管・緩和のみを時系列順に再構成する。 **3) TSG Generation(§4.3)** - **One-shot Generation**: すでにクリーンで代表性の高い蒸留済みインシデントを LLM に直接投入し、トラブルシューティングアクションの decision tree と TSG を構築させる。各分岐は特定のインシデント症状/パターンに紐づけられる。生成された TSG から DAG(ノード=判断的アクション/分岐点、エッジ=逐次・条件・エスカレーション・緩和関係)を抽出し、(TSG, DAG) ペアを初期知識ベースとする。 - **Iterative Updating**(Algorithm 2): 新規インシデントごとに (1) 同じフィルタリング・蒸留パイプラインを通し、LLM が現行 TSG/DAG と比較して未知パターンかどうかを判定する Pattern Analysis、(2) 提案された DAG 変更ごとにグルーピングし、最も情報量の多いインシデント(最も豊富な議論を持つもの)を代表として選ぶ Representative Selection(重複更新を防ぎ TSG を簡潔に保つ)、(3) バリデータが各更新サイクルで単一パスのみの追加・変更に制約する TSG Update with Validation の 3 フェーズで構成される。この「1 サイクルにつき単一パス制約」がハルシネーションと構造破壊を抑える中心的な安全機構である。 ### 実装上の工夫 - 二層キャッシュ(ローカル + 永続)による LLM 呼び出し削減。アブレーションでは生成時間を約 11.5 倍短縮、トークン消費を 95% 削減。 - medoid ベースの代表抽出により、少数の高情報密度インシデントで LLM のコンテキストウィンドウ制約に収める設計。 - DAG の「単一パス制約」による反復更新時のハルシネーション・構造逸脱の抑制。 ## 新規性 - 著者らの認識では、**過去インシデントデータのマイニングから構造化 TSG をゼロから自動生成する最初の試み**である。先行研究([[FLASH]]・[[LLexus]]・[[StepFly]] 等)は「既存 TSG をどう実行するか」を扱うのに対し、TSGen は「TSG が存在しない/古い状態からどう生成するか」という一段上流の問題を扱う。 - AIOps 領域の既存研究(クラウドインシデントからの知識グラフマイニング、インシデントエンティティのニューラル抽出、LLM ベース RCA 等)は、抽出された知識が孤立したエンティティ・関係・要約にとどまるのに対し、TSGen はそれらを**実務者が直接追従できる一貫したエンドツーエンドの運用文書**にまとめる点で異なる。 - コード要約・コミットメッセージ生成など既存の自動ドキュメント生成研究が短文・単目的の出力を対象とするのに対し、TSGen は**マルチステップの手続き文書**を対象とする。 ## 実験設定 - **データセット**: Microsoft の本番インシデント管理システムから収集した直近1年分のデータ。約 20,000 件以上のインシデント、約 30 モニタ。各モニタのデータをチロノジカルに Train(最古 60%)/Validation(次の 20%)/Test(直近 20%)に分割し、Test は学習時に未見であることを保証。各モニタには人間作成の既存 TSG が groundtruth として存在。 - **比較対象(baseline)**: - **LLM-Based Summarization (GPT-4o)**: GPT-4o に直接インシデントログを要約させて TSG 化する、タスク特化の適応が最小のベースライン。 - **Agent-Based Composition (ReAct)**: ReAct ベースの自律エージェントに反復的に計画・DB 問い合わせ・パターン識別・ガイド構築を行わせる、ドメイン特化プロンプトを与えた competitive な設定。 - **Rule-Based TSG Generation**: インシデントをクラスタリングして各クラスタから代表を選び、キーワードベース抽出で定型テンプレートを埋める、人間の手作業のヒューリスティックを模したベースライン。 - **Human-crafted TSG**: 既存の人間作成 TSG を pseudo-baseline として併記(最適でない可能性を認識した上での参照値)。 - **評価指標**: - **Matching Rate Evaluation**: LLM が TSG から抽出したステップ集合 T={s1,...,sk} と、インシデントの実効的議論 D={d1,...,dm} を突き合わせ、Coverage = (full_matches×1 + partial_matches×0.5) / total_steps(式(3))、および Order Consistency(マッチしたステップ順序と TSG 記載順序の一致度)を算出。 - **RAG-based Retrieval Evaluation**: 生成された全ガイドを Sentence-BERT でベクトル DB 化し、Title+初回議論(早期トリアージを模擬)/Title+全議論(事後解析を模擬)の 2 クエリで Retrieval Accuracy(Top-1 正解率)・Hit@3・MRR を評価。 - **Human Evaluation**: on-call エンジニアが正確性・網羅性・論理的一貫性・明瞭さの観点で 1〜5 のスコアを付与。 - **Practical Deployment Metrics**: Acceptance Rate(レビュー後にエンジニアリングチームが正式採用・公開した TSG の割合)。 ## 実験結果 ### 定量評価(RQ1: TSGen 生成性能) **Table 4: ベースライン・既存 TSG との比較** | 手法 | Coverage | Consistency | Retrieval Acc.† | Hit@3† | MRR† | Retrieval Acc.‡ | Hit@3‡ | MRR‡ | |---|---|---|---|---|---|---|---|---| | Rule-based | 0.354 | 0.922 | 0.178 | 0.359 | 0.403 | 0.173 | 0.362 | 0.400 | | GPT-4o | 0.417 | 0.926 | 0.173 | 0.752 | 0.472 | 0.170 | 0.747 | 0.470 | | ReAct | 0.455 | 0.939 | 0.162 | 0.833 | 0.471 | 0.164 | 0.830 | 0.471 | | Human-crafted TSG | 0.235 | 0.933 | 0.012 | 0.081 | 0.231 | 0.012 | 0.081 | 0.231 | | **TSGen** | **0.548** | **0.941** | **0.476** | **0.978** | **0.708** | **0.482** | **0.981** | **0.711** | († Retrieval input = title + first discussion、‡ Retrieval input = title + all discussions) TSGen は全指標でベースラインと既存人間作成 TSG を上回り、平均インシデントカバレッジ 54.8%、ベースライン比約 3 倍の検索精度を達成した。特に人間作成 TSG は Retrieval Accuracy が 0.012 と極端に低く、モニタ間の弁別力が乏しいことを示唆する。 ### アブレーション(RQ2: コンポーネント寄与) **Table 5: アブレーション結果** | 設定 | Coverage | Retrieval Accuracy† | MRR† | |---|---|---|---| | TSGen | 0.548 | 0.354 | 0.619 | | w/o Filtering | 0.278 (↓49.3%) | 0.262 (↓25.6%) | 0.531 (↓14.2%) | | w/o Distillation | 0.523 (↓4.6%) | 0.351 (↓0.9%) | 0.594 (↓4.0%) | | w/o Generation(structured) | 0.491 (↓10.4%) | 0.031 (↓91.2%) | 0.339 (↓45.2%) | - **Filtering の除去**が Coverage を最大 49.3% 低下させる最大の寄与要因。ルールベースフィルタのみでは意味解析ができず、LLM ベースの意味ラベリングが必要であることを示す。キャッシュ除去では生成時間 11.5 倍増・トークン消費 95% 増となり、キャッシュが実運用スケールに不可欠であることを裏付ける。 - **Distillation の除去**は全指標を悪化させるが Filtering ほどではない(Coverage ↓4.6%)。蒸留がフォーマットの意味的整合を高め LLM の抽出精度を上げることを示す。 - **Structured Generation の除去**(decision tree/DAG による明示的構造化をやめ自由形式生成に変更)は Retrieval Accuracy を 91.2% という最大幅で悪化させる。構造化生成が症状・根本原因・是正アクションの関係を明示的にモデル化することの重要性を最も強く示す結果。 - **Iterative Updating**: 検証セットを 4 分割し、one-shot 生成(V0)から順次更新した V1〜V4 で Coverage を追跡。42.3%(V0)→53.3%(V4)へと相対 26% 改善。V1(47.8%)→V2(47.6%)で軽微な低下が見られるが(特定検証サブセットのノイズに起因と考察)、全体としては単調な改善傾向であり、複数回の反復更新でエラー累積やハルシネーションドリフトが生じないことを確認した。 **Figure 4: 反復更新によるカバレッジ改善** ![[_attachments/2026_Unknown_TSGen_Automated_Troubleshooting_Guide_Generation/fig04-coverage-iterative-updates.png]] (Figure 4. V0(one-shot)から V4(全更新後)にかけて Coverage が 42.3%→53.3% へと段階的に改善する棒グラフ。V1・V2 間の軽微な逆転を含みつつ全体として上昇傾向。Source: Adapted from Figure 4.) ### 人手評価(RQ3) **Figure 5: 人手評価スコアの分布** ![[_attachments/2026_Unknown_TSGen_Automated_Troubleshooting_Guide_Generation/fig05-human-rating-distribution.png]] (Figure 5. TSGen(平均 ≈4.3)・Human-crafted TSG(平均 ≈3.3)・ReAct(平均が明確に低く分布も 1〜4 に偏る)の 3 手法についての 1〜5 評点分布のバイオリンプロット。ReAct は OCE から「一部のステップが誤解を招く、あるいは完全に捏造されている」と指摘され、より深刻なハルシネーション問題を示した。Source: Adapted from Figure 5.) TSGen は 3 手法中最も高い評価(平均 ≈4.3)を獲得し、既存 TSG(平均 ≈3.3)を有意に上回った。ReAct は幻覚的なステップが目立ち評価が大きく劣った。 ### 実運用インパクト(§7.1〜7.2) - **コスト**: 平均生成時間 146.88 秒/回、入力 78,115 トークン・出力 8,149 トークン。GPT-4o 価格(入力 $2.50/1M トークン、出力 $10.00/1M トークン)換算で 1 TSG あたり約 $0.28(918 件のインシデントバックログを処理して 1 TSG を生成するコスト)。 - **展開**: Microsoft 内で LLM ホスティングを担うサービスランタイムチームに TSGen をデプロイ。生成された 53 件の TSG のうち **38 件がレビューを経て採用**された(受容率 約 71.7%)。 - **チームからのインパクト声明**: 「TSGen は out-of-memory 状態・ロールアウトの停止・設定ミス・5xx エラー多発・容量問題など多様な障害モードをカバーし、約 80% の成功率でエンドツーエンドのトラブルシューティングガイドを自動導出できる」との定性的フィードバックが得られた。 - **§7.3 Extensibility: TSG as Agent Skills**: 構造化された TSG の Symptom/Root Cause セクションはエージェントの意味的インデックス(Skill Description)、Mitigation セクションの抽出済みクエリ/スクリプト/CLI コマンドは実行可能ペイロード(Skill Execution)として、Microsoft Copilot のような LLM ブレインの GUI エージェントが扱う Agent Skill 形式(JSON/YAML)へ変換できる可能性を論じている。 ## 考察 - Filtering の寄与が最大である点は、生のインシデントログをそのまま LLM に渡すことの限界を示す。ノイズ除去(意味的ラベリング)が構造化生成の前提条件であるという知見は、「良い生成には良い入力整形が必要」という一般的教訓とも一致する。 - 人間作成 TSG の Retrieval Accuracy が極端に低い(0.012)という結果は、既存 TSG がモニタ固有の識別可能な情報を欠いていることを示唆し、TSGen が「実際のインシデントとの意味的な結びつき」を明示的に生成する設計の妥当性を裏付ける。 - 単一パス制約による反復更新の安定性(V0→V4 でのハルシネーションドリフト非発生)は、後続研究([[FLASH]]・[[StepFly]] 等)が指摘する TSG 実行時の信頼性課題と対をなす、TSG *生成*・*更新* 時点での信頼性設計として位置づけられる。 ## 強み / 弱点・課題 **Strengths** - 過去インシデントデータからの TSG ゼロ生成という、既存研究(TSG 実行・検索寄り)が扱ってこなかった上流課題に初めて取り組んだ。 - フィルタリング・蒸留・構造化生成の各コンポーネントの寄与をアブレーションで定量化しており、設計判断の根拠が明確。 - 実運用デプロイと定量的コスト分析($0.28/TSG)を含み、産業応用としての実現可能性を具体的に示している。 **Weaknesses / Limitations(論文が §7.4 Threats to Validity で明記)** - **外部妥当性**: 評価は単一の大規模クラウドプロバイダ(Microsoft)のインシデントデータに限定されており、他組織や小規模オンプレミス環境での障害パターン・ログフォーマットの違いによる一般化可能性は未検証(TSG 構造・LLM 能力に関する主要な知見は一般化しやすいと著者は主張)。 - **内部妥当性**: 生成品質は基盤 LLM(GPT-4 系)の能力に強く依存し、ハルシネーションや誤った指示のリスクを内在的に抱える。DAG ベースの検証と構造制約はこのリスクを大きく緩和するが、高圧下のライブインシデントでの逸脱に関する定量分析は今後の課題。 - **構成概念妥当性**: 自動評価指標(ステップマッチング・検索精度)はガイド品質のプロキシに過ぎず、LLM ベース評価に大きく依存する。人手評価はこれを部分的に緩和するが、時間的制約の強いライブインシデント対応での実世界効果の評価は依然として課題。 - **データモダリティ・時間的動態**: TSGen は現状テキストのみに依拠し、メトリクス・トレース等のマルチモーダル信号の統合は将来課題。medoid ベースのサンプリングは古いインシデントを選んでしまうリスクがあり、直近イベントを優先する時間重み付けの導入が今後の重要なステップとして挙げられている。 - **著者自身が明記する Future Work**: TSG 自動化フレームワーク(TSG 実行系)との統合によるインシデント検知→TSG 生成→エージェント実行のエンドツーエンドワークフロー、ログ・メトリクス・診断画像などのマルチモーダル入力の統合。