LLMを使ったインシデント対応支援

障害対応の一次対応者が最初に費やす時間の多くは、原因調査そのものより「大量のログ・メトリクス・過去チケットをかき集めて状況を把握する」作業に消えます。LLMをこの初動に組み込む「インシデントコパイロット」は、事後のポストモーテムとは別物で、対応が進行中の数分〜数十分に、要約・仮説生成・過去事例検索を肩代わりすることを狙います。本稿はその内部動作と、避けられない限界を原理から扱います。

なぜ生ログをそのままLLMに渡せないか

大規模障害では、数万行のログと数百系列のメトリクス、数千spanのトレースが同時に発生します。LLMの入力窓（コンテキストウィンドウ）はトークン数に上限があり、しかも長い入力ほど途中の情報を見落とす傾向（lost in the middle）が知られています。生データを丸ごと詰め込む方式は、コスト・レイテンシ・精度のすべてで破綻します。

そこで実務的な構成は、観測基盤から関連する断片だけを事前に絞り込み、要約済みの短い文脈をLLMに渡す検索拡張生成（RAG: Retrieval-Augmented Generation）です。

1. 抽出：直近の異常時刻帯を中心に、該当サービス・該当traceのログ行やspanだけを取得する。
2. 圧縮：定型的なログ行（ヘルスチェック成功など）を除去し、エラー・警告・状態変化のみを残す。
3. 埋め込み検索：現在の症状（エラー文言・スタックトレース・影響範囲）をベクトル化し、過去インシデントの記録から意味的に近いものを検索する。
4. プロンプト構築：圧縮ログ＋類似インシデント要約＋現在のアラート内容を1つのプロンプトにまとめ、LLMに仮説とドラフト対応手順を生成させる。

類似インシデント検索の仕組みと限界

過去インシデントとの類似検索は、テキストを高次元ベクトルに変換する埋め込みモデルを使い、コサイン類似度などでの意味的な近さで一致度を測ります。キーワード一致（全文検索）と違い、「connection refused」と「upstream unreachable」のように表現が違っても意味が近い事例を引き当てられるのが利点です。

ただしこの類似度は症状の言語的な近さを測っているだけで、根本原因が同じであることを保証しません。同じ「タイムアウト」という症状でも、原因が接続プール枯渇のこともあれば下流サービスの過負荷のこともあります。逆に、文言がまったく異なる過去事例（例えばDNS TTL切れとコネクションリーク）が、実は同じ「クライアント側の再接続ロジック不備」という共通原因を持つ場合、埋め込みが表層的な語彙差を拾いすぎると類似候補から漏れることもあります。

仮説生成とドラフト作成が担う役割

LLMが生成するのは主に次の3種類です。

• 状況要約：バラバラなログ・メトリクスの変化点を、時系列に沿った自然文で圧縮する。人間が数百行を読む代わりに数行で把握できる。
• 仮説の列挙：類似インシデントと現在のシグナルから「考えられる原因」を複数提示する。可能性の順位付けは統計的な尤もらしさではなく、学習データ中の頻出パターンの反映に過ぎない点に注意が必要。
• 対応手順のドラフト：過去のランブックや対応履歴を参照し、「まず何を確認し、何を実行するか」の叩き台を生成する。

これらはいずれも初動の叩き台であり、最終形ではありません。特に対応手順のドラフトは、実運用のインフラ構成が過去事例と微妙に異なる場合、有害な手順（対象を誤ったロールバックやスケールダウン）を提案しうる点が実行前提の設計と決定的に違います。

ハルシネーションと人間の最終判断

LLM支援を導入する際に避けて通れないのが、ハルシネーション（存在しない事実をもっともらしく生成する現象） です。障害対応の文脈では次のような形で現れます。

• 実在しないログ行やメトリクス値を「引用」として提示する。
• 存在しないAPIエンドポイントやコマンドオプションを対応手順に含める。
• 類似インシデントの根本原因を、実際のポストモーテム記録と異なる内容で要約する。

これはモデルの学習不足ではなく、次のトークンを尤もらしく予測する生成の仕組みそのものに起因するため、プロンプト設計や検索精度の改善で低減はできても原理的に排除できません。したがって設計上の前提は次の2点になります。

1. 出力を実行系に直結させない：生成された手順やコマンドを自動実行するのではなく、人間が内容を検証してから実行する経路のみを許可する。
2. 根拠を検証可能にする：要約や仮説には、参照した元ログ・元チケットへのリンクを必ず併記させ、人間が一次情報に戻って裏取りできるようにする。

まとめ

• LLM支援の核はRAGによる文脈選別。生ログを直接渡さず、抽出・圧縮・埋め込み検索で絞った断片のみをプロンプトに載せることでコンテキスト長とlost in the middleの問題を回避する。
• 類似インシデント検索は意味的な近さを測るのみで、根本原因の同一性や時系列因果は保証しない。検索結果は仮説の候補として扱う。
• 状況要約・仮説列挙・手順ドラフトはいずれも初動の叩き台であり、ハルシネーションのリスクを踏まえて実行系には直結させず、根拠リンク付きで人間が検証・判断する設計が前提になる。
• 事後のポストモーテムやインシデント指揮系統と組み合わせることで、対応中の初動短縮と事後の学習資産化の両輪が揃う。