# LLexus: an AI agent system for incident management > [!abstract] 概要 > クラウドで複数の分散コンポーネントを稼働させることは、エンジニアリングチームにとって著しい課題である。エンジニアは性能劣化やサービス停止のインシデントに対応する際、トラブルシューティングガイド(TSG)を頼りにすることが多い。しかし、TSG の有効性は、その長大さ・部族知識(tribal knowledge)への暗黙の依存・コンテンツ品質のばらつきによってしばしば損なわれている。本稿では、TSG の実行を自動化するエージェントベースの AI システム LLexus を紹介する。LLexus は大規模言語モデル(LLM)エージェントを用いて、計画フェーズ中に TSG を精緻で実行可能なプランへ変換する。それらのプランはインシデント発生時に実行される。LLexus の主要コンポーネントはインタラクティブなプランナとエグゼキュータである。プランナはエンジニアが TSG をフローチャートとして表現された詳細プランへ洗練するのを支援し、タスクと判断点を明確化する。エグゼキュータはそのプランを自律的に実行し、機器交換のような物理的アクションを要するタスクにのみ人間の補助を必要とする。一連のユースケースを通じて、LLexus の実現可能性と初期的な有効性を実証し、インシデント管理プロセスを合理化する可能性を示す。主な知見として、LLexus が TSG の可読性を改善できること、また計画フェーズでの LLM 利用が LLM 関連コストと実行時の潜在的な誤りの影響を低減することが挙げられる。 --- ## 論文情報 | 項目 | 内容 | |---|---| | DOI | 10.1145/3689051.3689056 | | 媒体 | ACM SIGOPS Operating Systems Review(OSR)2024年8月 | | 著者 | Pedro Las-Casas, Alok Gautam Kumbhare, Rodrigo Fonseca, Sharad Agarwal | | 所属 | Microsoft | --- ## 概要 LLexus は、クラウドサービス運用における[[インシデント管理]]の自動化を目的とした AI エージェントシステムである。従来のアプローチではインシデント発生時に LLM に TSG を読ませて対応させるが、LLexus はこれを2フェーズに分離する。**計画フェーズ(オフライン)** で LLM エージェントが人間の助けを借りながら TSG を実行可能なプランへ変換し、**実行フェーズ(オンライン)** ではそのプランを決定論的に実行する。この設計により LLM のコストとハルシネーションの影響を最小化しつつ、障害緩和(MTTM)の短縮を狙う。 --- ## 問題設定 ### TSG の現状と限界 大規模クラウドシステムには数百のコンポーネントが存在し、on-call エンジニアはトラブルシューティングガイド(TSG)に頼って障害に対応する。Microsoft では 6 万人超のエンジニアが 5 万件超の TSG を利用し、一部の TSG は数百件のインシデントで使われている(§1)。 著者らが対象チームの 54 件の TSG を分析したところ、3 つの構造的問題が確認された(§2.1、図1〜3)。 1. **長大さ**: 中央値 815 ワード、最大 5,500 ワード超。Flesch-Kincaid Grade Level で最大 20 年の教育水準を要するものもある(図2)。 2. **部族知識(tribal knowledge)への依存**: TSG は自然言語で書かれており、その組織・サービスを知る人間が暗黙知として補完することを前提にしている。 3. **品質のばらつき**: 54 件中、不完全な情報・壊れたリンク・誤り・欠落情報などの問題が多数確認された。TSG の更新頻度は中央値 19 日に 1 回、最大で 60 回超の変更履歴を持つものもある(図3)。 ### 素朴な LLM アプローチが失敗する理由 インシデント時に LLM へ TSG を渡して直接実行させる単純アプローチは 3 つの理由で機能しない(§1)。 - **品質の壁**: TSG の曖昧さ・前提知識の欠落が LLM にとっても障壁になる。 - **ハルシネーション**: LLM の非決定的出力をチームが本番で信頼するのは困難。 - **コスト**: インシデント件数に比例して LLM コストが増大する。 --- ## 提案手法 ### LLexus のアーキテクチャ概観 図4 に示すとおり、LLexus は 2 つの主コンポーネントからなる。 | コンポーネント | 動作タイミング | 役割 | |---|---|---| | **プランエクストラクタ(プランナ)** | オフライン(TSG 作成・更新時) | TSG → 実行可能プランへ変換 | | **プランエグゼキュータ(エグゼキュータ)** | オンライン(インシデント発生時) | プランを決定論的に実行 | プランはさらに **プランコンパイラ** と **プランバリデータ** によって完全性・実行可能性が検証される(§3)。 ### 主要設計選択(§3) - **プランは TSG 作成・更新時に生成**する(インシデント発生時ではない)。1 TSG あたり 1 回の計画コストで、以後は何件のインシデントにも決定論的実行を適用できる。 - **プランは反復的に生成**される。LLM エージェントがまず高レベルのスキーマを生成し、続いて各ステップの詳細を埋める。これによりハルシネーションを局所化する。 - **エンジニアが計画を審査**する。プラン生成と同時に TSG の問題点を可視化し、TSG の品質改善も促す。 - **TSG が唯一の真実の源(source of truth)**。プランに問題があれば、プランでなく TSG を修正して再計画する。 - **既存の特定ツールに依存**する。汎用 SSH ではなく、チームが保有する Powershell スクリプト・Kusto クエリ等の確定的ツールを使うことで、コストとハルシネーションのリスクを低減する。 ### プランの表現 プランは BPMN [9] にインスパイアされたフローチャートとして表現される(§3.1.1)。有向グラフで、ノードはステップ、実線エッジは実行フロー、破線エッジはデータフローを表す。ステップの種類は 3 つである。 - **アクションステップ**: ツールを実行する。次ステップは必ず 1 つ(四角ノード)。 - **条件ステップ**: 判断を行い、評価式に基づいて 2 つ以上の経路に分岐する(菱形ノード)。 - **イベントステップ**: 外部アクション待ちのステップか、タイマーによる待機(円形ノード)。 ### ツールの種類(§3.1.2) プランナはステップごとに使用ツールを決定する。ツールは 2 種類に分類される。 - **スクリプトツール**: 言語モデル不要の従来型プログラム(Powershell・Python・Kusto クエリ等)。データ取得系と操作実行系の 2 種がある。 - **セマンティックツール**: LLM の理解・生成能力に依存するツール。ログ中の例外の解釈・クエリ結果からのパラメータ導出等、曖昧さや文脈理解を要するタスクに使う。 ### プランコンパイラ(§3.1.3) プランコンパイラは生成されたプランが完全かつ実行可能かを検証する。チェック内容の例を示す。(i) アクションステップに実行ツールが定義されているか。(ii) すべてのステップが到達可能か。(iii) 条件ノードの評価式が有効か。(iv) 各ステップの入力がそれ以前のステップ・インシデント・定値から取得可能か。この検証はプランだけでなく TSG の品質改善フィードバックとしても機能する。 ### エグゼキュータ(§3.2) エグゼキュータはインシデント到着のたびに起動し、プランを取得・実行する。決定論的プランに沿って盲目的に(blindly)各ステップを実行するため、推論コストを最小化する。セマンティックツールが必要なステップのみ LLM を呼び出す。また、外部イベント待ちや手動介入を要する場合に備え、**Azure Durable Functions** [17] によるステートフルな実行・一時停止・再開に対応する(§5)。 ### 4 コンポーネントによるマルチステップ計画生成(§4) プランナ内部は図6 のとおり 4 コンポーネントで構成され、各コンポーネントの後に検証ループが走る。 1. **ツール選択(Tool Selection)**: TSG と利用可能ツール全体を入力に、chain-of-thought プロンプトで関連ツールを選定する。JSON で出力し、検証後に次コンポーネントへ渡す。 2. **プランスキーマ抽出(Plan Schema Extractor)**: ノードと関係からなる高レベルのプランスキーマを生成する。各ステップの種類・後継ステップ・条件式を定義するが、ツールの詳細はこの段階では未定。 3. **ステップ詳細抽出(Step Details Extractor)**: 各ステップに対して使用ツール・入力元(前ステップ・インシデント・定値)・出力を特定する。入力源の追跡が重要で、実行時の決定論性を担保する。 4. **検証(Validation)**: Reflexion [28] の自己省察と修正のアプローチを応用した汎用検証コンポーネント。応答・目標・追加文脈を入力とし、他の 3 コンポーネント全てから呼び出される。 使用 LLM は **GPT-4-Turbo**（Azure OpenAI API 経由）。フレームワークは **Semantic Kernel** [20]。計画生成の非同期化には **Azure Functions** と **Azure CosmosDB**・**Azure Queue** を使用する(§5)。 --- ## 新規性 1. **オフライン計画・オンライン決定論的実行の分離**: 先行研究([23]の ReAct エージェント等)はインシデント発生時に毎回 LLM で推論するが、LLexus はコストとハルシネーションを計画フェーズに前置することで実行時の LLM 依存を最小化する。 2. **TSG を source of truth として扱い品質改善フィードバックループを形成**: 単なる TSG 実行器でなく、TSG そのものの品質を人間との協調ループで向上させる仕組みを内包する。 3. **コパイロット(Copilot)[2][30] との対比**: 先行研究のコパイロット方式はインシデント対応中にエンジニアの都度承認を要するが、LLexus は計画承認を事前に行い実行時の人手介入を不要にする。 --- ## 評価 ### 3 件のケーススタディ(§6) 評価はまだ初期段階であり、MTTM 削減の包括的な定量評価は長期的目標として残る(§6 冒頭)。現段階では 3 件のケーススタディで実現可能性を示す。 **ケーススタディ1: Azure Service Fabric アップグレード失敗(表1)** 公開 TSG [22] を入力とした計画生成。TSG が明示的にコマンドを示していないステップ 1・4 に対し、GPT-4 が Azure Service Fabric と Powershell の知識を用いてコマンドを補完した。計画は 1 パス・人手介入なしで生成できた(TSG の品質が高かったため)。各コンポーネントのコストは表1 のとおりで、合計 $0.60。 | コンポーネント | 平均入力トークン | 平均完了トークン | 実行回数 | コスト | |---|---|---|---|---| | ツール選択 | 1,184 | 166 | 1 | $0.02 | | プランスキーマ | 2,273 | 390 | 2 | $0.07 | | ステップ詳細 | 3,705 | 435 | 5 | $0.25 | | 検証 | 1,520 | 568 | 8 | $0.26 | | **合計** | — | — | — | **$0.60** | **ケーススタディ2: Azure Service Fabric バックアップ停止(表2)** 同じく公開 TSG を対象。条件分岐とイベントステップを含む複雑なプランで、初期計画では「問題なし」のパスが欠落していた。エンジニアが TSG を更新した後、欠落ノードが追加され最終プランが完成した(図8)。同じ最終 TSG で 10 回計画生成し、いずれも同じ構造のプランが得られた(記述が若干異なるが構造は一致)。合計コスト $1.71。 **ケーススタディ3: 社内サービスのネットワークリンク異常挙動(図9)** 品質の低い社内 TSG。初期計画は不完全で 12 ステップのみ(メンテナンス確認のみ、核心的な調査パスを欠落)。複数ラウンドの反復改善を経て各ステップが明確化され、最終プランは 21 ステップ(図9b)となった。 ### コスト分析(§6.4) LLexus のオフライン計画コストは 2 件の平均で約 $1.15。これをインシデント 1 件ごとに支払う完全オンライン方式(1 件あたり LLM コスト + $0.50 のセマンティック処理)と比較すると、図10 のとおり **少数件のインシデントでコストが逆転**する。インシデント件数が増えるほど LLexus の優位性は拡大する。 --- ## 考察 ### 知見(§6.5) 1. **TSG の品質が計画品質に直結する**: 明確に書かれた TSG は 1 パスで完全なプランを生成できるが、曖昧な TSG は多くの反復を要する。 2. **反復改善プロセスの有効性**: LLexus のフィードバックによってエンジニアが TSG の欠陥を早期に発見し、継続的改善が促される。 3. **多様なシナリオへの適応性**: 線形プランから条件分岐・イベント待ちを含む複雑なプランまで対応できる。 ### 未解決と将来課題(§8) - 計画実行のさらなる汎用化(オンプレ・クラウド・多段認証への対応)が必要。 - 小型言語モデル(SLM)の適用可能性の検討。 - 機械生成インシデントが現在の主対象。人間生成インシデントへの拡張には、インシデントと TSG を対応づける学習的アプローチが必要。 - 将来的には、閾値超えの前の「予兆段階」での予防的緩和への応用も視野に入る。 --- ## 強み / 弱点・課題 ### 強み - **コストと信頼性のトレードオフを設計レベルで制御**: LLM を計画フェーズに前置することで、インシデント対応の決定論性とコスト効率を両立する。 - **TSG の品質改善という副次的価値**: 実行自動化だけでなく、人間エンジニアにとっての TSG 品質も向上させる。 - **既存ツールとの親和性**: スクリプトツールへの依存により、無制限アクセスを回避しつつ本番環境への適用が可能。 ### 弱点・課題 - **MTTM 削減の定量評価が未達成**: 実際の改善幅を示す包括的評価は今後の課題として残る。 - **既知の問題にのみ適用可能**: 未知のインシデントには決定論的プランが存在しないため、[23] のような ReAct ベースのアプローチが依然として必要。 - **TSG 品質に強く依存**: 品質の低い TSG は多くの反復を要し、計画コストが増大する(ケーススタディ2 で $1.71)。 - **機械生成インシデント中心**: 人間が報告する独自のインシデントへの対応は未解決。