AIに障害対応を丸投げするな：SREがLLMを『有能な助手』としてRCAに組み込む現実的プロセスガイド

イントロダクション：深夜3時のPagerDutyと、AIへの期待と不安

深夜3時、枕元のスマートフォンがけたたましく鳴り響く。監視ツールからの容赦ない呼び出し音。

SRE（サイト信頼性エンジニアリング）やインフラ運用に携わる方であれば、一度は経験したことのある光景ではないでしょうか。重い瞼をこすりながらPCを開き、大量のアラートメールとログの海に飛び込むことになります。

近年、コンテナを管理する技術は大きな進化を遂げています。たとえば最新のKubernetes環境では、CPUやメモリが不足した際に、システムを再起動することなくリソースを動的に調整できる機能（In-place Podリソース更新）が導入されました。トラフィック分散の最適化なども進み、システム全体の回復力は着実に向上しています。

しかし、技術が進化しても、障害対応の複雑さが消え去るわけではありません。リソースの動的調整が追いつかない突発的なアクセスの集中、データベースの接続上限の枯渇、あるいはデプロイされたばかりのアプリケーションコードに潜む未知のバグなど、原因特定までの時間は依然として長く感じられます。「もっと早く、正確に原因を突き止められないか？」そう願うのは当然のことです。

システムが高度化し、複雑に絡み合うインフラ環境において、業界全体で大きな注目を集めているのが、「インシデント対応におけるLLM（大規模言語モデル）の活用」です。自然言語処理技術の飛躍的な進化により、膨大なログやシステムの健全性を示すデータ（メトリクス）から異常の兆候を迅速に読み解くアプローチが現実的になりつつあります。

「AIにログを読ませて、勝手に直してもらえばいいじゃないか」

経営層や技術に明るくない層からは、そんな楽観的な声も聞こえてきます。しかし、現場の感覚は違いますよね。「AIが誤った判断をして、システムを完全にダウンさせたらどうする？」「顧客の個人情報が含まれる機密ログを外部のAIに送信して大丈夫なのか？」

その懸念は、論理的に考えて完全に正しいものです。

結論から申し上げます。現時点での「AIによる完全自動復旧（NoOps）」は、時期尚早であり、システムに重大なリスクをもたらす可能性があります。理論上は可能に見えても、実証に基づいた安全な運用基盤がなければ、かえって危険を増大させます。推奨されるのは、AIをすべてを決定する「指揮官」にするのではなく、「極めて処理能力の高い、しかし時々うっかりミスをする新人アシスタント」としてチームに迎え入れるアプローチです。

本記事では、過度な期待を排除し、SREチームが現実的にLLMをRCA（根本原因分析）プロセスに組み込むための具体的な手法を解説します。AIの嘘（ハルシネーション）をどう防ぐか、機密情報をどう守るか、そしてAIと共に「平均復旧時間（MTTR）」をいかに短縮していくか。技術的な実装論だけでなく、明日から現場で使える実践的な運用の型をお伝えします。

なぜRCA（根本原因分析）にLLMが必要なのか：疲弊する現場への処方箋

そもそも、なぜ今、RCAにLLMが必要とされているのでしょうか。単なるトレンドだからというわけではありません。そこには現代のシステム構造が抱える根本的な課題が存在します。

複雑化するマイクロサービスと限界を迎える人力ログ解析

かつての単一構造（モノリシック）なシステムであれば、熟練のエンジニアが経験則から障害箇所を特定できました。「この挙動なら、あそこのサーバーのメモリ不足だろう」といった具合です。

しかし、複数の小さなサービスを連携させるマイクロサービスアーキテクチャや分散システムの普及により、状況は一変しました。一つのリクエストが数十、数百のサービスを通過し、それぞれが膨大なログを出力します。リクエストの経路を追跡するツール（分散トレーシング）などは進化しましたが、それでも「どのサービスのどの変更が、ドミノ倒しの最初の１枚だったのか」を特定するには、高度な専門知識と、何より膨大なテキストデータを読み解く時間が必要です。

ここで重要なのは、「ログは非構造化データ（自然言語に近いテキスト）である」という点です。従来の数値データの異常検知では、「CPU使用率が上がった」ことは分かっても、「なぜ上がったのか（例：特定の処理が順番待ちを引き起こしている）」という文脈までは理解できませんでした。

LLMのような高度な生成AIは、この「文脈理解」において圧倒的なパフォーマンスを発揮します。現在のAIモデルは急速な進化を遂げており、例えばOpenAIのAPI環境では、より高度な推論が可能な新しい標準モデルへと移行し、極めて長い文脈の理解や複雑なツール実行能力が飛躍的に向上しています。

また、Anthropicのモデル環境においても、最新のClaudeモデルでは膨大なテキスト量（コンテキストウィンドウ）への対応や、タスクの複雑度に応じて思考の深さを自動調整する機能が搭載されています。情報量の上限に近い状態でも自動で要約を生成する機能なども活用できるため、膨大なログデータを途切れることなく解析可能です。

これらの進化により、散らばったエラーログをつなぎ合わせ、「サービスAのタイムアウトは、実はサービスBのデータベース更新失敗に起因している可能性が高い」といった高度な推論を行う能力が劇的に高まっています。旧モデルでは処理しきれなかった大規模なログ解析も、最新モデルへの移行によって、疲弊した人間が深夜に行うよりもはるかに高速かつ網羅的に実行できる環境が整っています。

「平均復旧時間（MTTR）」短縮への壁

SREチームの重要指標の一つにMTTR（Mean Time To Recovery：平均復旧時間）があります。インシデント対応のプロセスは、大きく以下の4段階に分けられます。

1. 検知（Detect）: アラートが鳴る
2. 特定（Identify）: 何が起きているか把握する
3. 診断（Diagnose）: なぜ起きたか（根本原因）を突き止める
4. 修復（Resolve）: 修正を適用する

この中で、最も時間がかかり、かつ個人のスキルに依存しやすいのが「診断（Diagnose）」のフェーズです。LLMはこのフェーズにおいて、膨大なログと過去の障害報告書などのナレッジベースを瞬時に照らし合わせ、有力な原因候補をリストアップすることで、初動を劇的に加速させます。最新モデルの強力な文脈理解力を活用すれば、診断にかかる時間を大幅に圧縮し、MTTRの短縮という高い壁を乗り越える有力な手段となります。

LLMが得意なこと・不得意なことの境界線

ただし、ここで期待値を正しく設定する必要があります。生成AIの特性を踏まえると、LLMは決して万能ではありません。システム運用に組み込む際は、その特性を正確に把握することが重要です。

• 得意なこと:

  • 大量のテキストデータの要約と構造化
  • 既知のエラーパターンとの高速な照合
  • ログメッセージからの自然言語による状況説明
  • クエリやコードの構文エラーの指摘
  • タスクの複雑度に応じた推論

• 不得意なこと（リスクがあること）:

  • 未知の事象に対する正確な因果関係の特定（推測によるハルシネーションの可能性）
  • 最新のシステム変更状況のリアルタイム把握（前提情報として与えなければ認識できない）
  • 「責任を取ること」および最終的な意思決定

AIはあくまで「有能な提案者」であり、「決定者」にしてはいけません。この境界線を理解せずに自動化を推し進めると、誤った分析に振り回され、かえってMTTRが悪化する「二次災害」を招くことになります。常に人間が最終判断を下すプロセス（Human-in-the-Loop）を設計に組み込むことが、安全で効果的な運用の鍵となります。

「完全自動化」は目指さない：Human-in-the-Loop（人間参加型）運用フローの設計

多くのベンダーが「自律型AI運用」を謳っていますが、実務の現場で推奨されるのは、いきなり完全自動化を目指すのではなく、Human-in-the-Loop（人間参加型）のワークフロー設計です。

AIによる「仮説生成」と人間による「検証」の分担

理想的なフローは、AIが「下書き」を作り、人間が「承認」するプロセスです。具体的には以下のような流れになります。

1. インシデント発生: 監視ツール（Datadog, Prometheus等）がアラートを発火。
2. AIによる自動調査（トリアージ）:
   • 通知を受け取ったAIエージェントが、関連する期間のログ、メトリクス、直近のデプロイ履歴を収集。
   • それらを解析し、「何が起きているか（要約）」と「考えられる原因（仮説リスト）」を生成。
   • さらに、過去の類似インシデントの解決策（Runbook）を検索して提示。
3. チャットツールへの通知: 解析結果を専用チャンネルに投稿。
4. 人間による判断（Human-in-the-Loop）:
   • SRE担当者はAIの提示した仮説を確認。「データベースのロックが怪しい」というAIの指摘に基づき、詳細なメトリクスを確認しに行く。
   • AIの仮説が正しければ、提示された復旧手順を実行。
   • 間違っていれば、フィードバックを与えて再調査させるか、手動調査に切り替える。

このフローの肝は、「AIが勝手にシステム設定を変更しない」という点です。あくまで情報の整理と仮説の提示に徹させることで、心理的な安心感とシステムの安全性を担保します。

インシデント発生からRCAレポート作成までの標準タイムライン

事後対応（ポストモーテム）でもAIは活躍します。障害対応が終わった後、チャットツール上のやり取りやシステムログをAIに読み込ませることで、RCAレポート（障害報告書）のドラフトを自動生成させることができます。

「発生時刻」「検知時刻」「復旧時刻」「根本原因」「対応内容」「再発防止策」。これらをゼロから書くのは非常に労力がかかります。AIが8割の完成度でドラフトを作ってくれれば、人間は残りの2割（ニュアンスの修正や、組織的な再発防止策の策定）に集中できます。

SLA（サービスレベル合意）にAI解析時間をどう組み込むか

AI導入にあたっては、SLAやSLO（サービスレベル目標）の考え方も少し調整が必要です。AIによる解析には多少の時間（数十秒〜数分）がかかります。しかし、人間がログを検索し始めるまでの「リードタイム」を考えれば、トータルでは短縮されるはずです。

運用ルールとして、「AIの解析結果が出るまでは、人間は状況把握（ユーザー影響の確認など）に専念する」といった役割分担を明確にしておくことが、混乱を防ぐ鍵となります。

AIの「知ったかぶり」を防ぐ：ハルシネーション対策と信頼性担保の運用

生成AI最大の敵、それがハルシネーション（幻覚）です。もっともらしい顔をして、存在しないエラーコードや、嘘の原因をでっち上げることがあります。RCAにおいてこれは致命的です。

RAG（検索拡張生成）を用いた社内ナレッジ参照の仕組み

LLM単体（学習済みモデル）の知識だけで回答させると、ハルシネーションのリスクが高まります。そこで必須となる技術がRAG（Retrieval-Augmented Generation：検索拡張生成）です。

これは、AIに回答させる前に、まず社内のドキュメント（過去の障害報告書、システム仕様書、手順書など）を検索させ、その検索結果を「参考資料」としてAIに与え、回答を生成させる手法です。

「一般論としてのデータベースエラー」ではなく、「自社の過去の事例に基づいたエラーの傾向」を答えさせることで、回答の精度と具体性が格段に向上します。ベクトルデータベースを用いて社内ナレッジを検索可能にしておく準備が、AI活用の前提条件となります。

「根拠となるログ行」を必ず提示させるプロンプト設計

運用上の工夫として、プロンプト（AIへの指示）で「回答の根拠を明示すること」を強制します。

例えば、以下のようなプロンプトです。

「あなたはシニアSREエンジニアです。提供されたログを分析し、根本原因を推測してください。
重要：推測を行う際は、必ずその根拠となったログの具体的な行（タイムスタンプ含む）を引用してください。根拠となるログが存在しない場合は、『情報不足により特定できません』と回答し、無理に推測しないでください。」

このように「分からない」と言う勇気を持たせる設計が重要です。AIが出した答えにログの引用がなければ、担当者はその分析を疑うことができます。この「検証可能性（Verifiability）」こそが、信頼の担保になります。

回答の信頼度スコアリングと閾値設定

高度な運用では、AIの回答に「信頼度スコア（Confidence Score）」を付与させることも可能です（モデルによってはAPIで取得可能、あるいはプロンプトで自己評価させる）。

「この分析の自信度は80%です」と「30%です」では、受け取る側の対応が変わります。信頼度が低い場合は、アラート通知に「※AIによる分析は信頼度が低いため、手動調査を推奨」といった注釈を自動付与する仕組みを作れば、現場の混乱を最小限に抑えられます。

機密情報を守るためのデータサニタイズとセキュリティ運用

「ログをAIに読ませる」と言った瞬間、セキュリティ担当者は顔をしかめるでしょう。ログにはIPアドレス、ユーザーID、場合によってはメールアドレスなどの個人識別情報（PII）が含まれている可能性があるからです。

ログに含まれるPII（個人識別情報）の自動マスキング

基本原則として、「生のログ（Raw Log）をそのままパブリックなLLMに投げてはいけません」。

AIに渡す前に、前処理の仕組みを通す必要があります。正規表現や専用のマスキングツールを用いて、以下のような変換を行います。

• 192.168.1.1 → <IP_ADDRESS>
• user@example.com → <EMAIL>
• user_id=12345 → user_id=<USER_ID>

この「サニタイズ（無害化）」処理を行うことで、文脈（エラーのパターン）は維持しつつ、機密情報だけを隠蔽できます。LLMが解析に必要なのは「特定ユーザーのID」ではなく、「どのようなエラーが起きているか」という構造だからです。

オープンモデルとプライベートモデルの使い分け基準

企業によっては、外部のAPIへのデータ送信自体がセキュリティポリシー違反となる場合があります。その場合の選択肢は主に2つです。

1. エンタープライズ契約の利用: クラウドプロバイダーが提供する、データが学習に使われず、セキュリティ境界内で処理される法人向け契約を利用する。
2. ローカルLLMの活用: オープンソースのモデルなどを自社の仮想プライベートネットワーク内で稼働させ、データが社外に出ない環境を構築する。

RCAのような高度な推論には高性能なモデルの能力が望ましいため、現実的には「1. エンタープライズ契約」を選択しつつ、前述のマスキングを徹底するのがバランスの良い解決策となります。

LLMに入力してよいデータ・いけないデータの分類ガイドライン

システム的に防ぐだけでなく、運用ルールとしてのガイドライン策定も不可欠です。

• Level 1（入力OK）: システムエラーログ、メトリクス数値、公式ドキュメント
• Level 2（マスキング必須）: アプリケーションログ（ユーザー入力が含まれる可能性があるもの）
• Level 3（入力禁止）: データベースのダンプデータ、顧客リスト、認証キー・パスワード

この基準を明確にし、チーム内で共有することが、事故を防ぐ第一歩です。

チームで育てるAI：フィードバックループと継続的な精度向上

AIシステムを導入して終わりにしてはいけません。導入直後のAIは、いわば「配属されたばかりの新人」です。チームの文脈も、システム特有の癖も知りません。日々の運用を通じて育てていく必要があります。

ポストモーテムレビューでの「AI分析評価」セクションの導入

インシデント振り返り（ポストモーテム）のミーティングに、新しい確認項目を追加してください。

「今回の障害対応で、AIの分析は役に立ったか？」

• AIの指摘は正しかったか？
• 提示された解決策は適切だったか？
• どの情報が足りなくてAIは間違えたのか？

この議論を行い、その結果をフィードバックデータとして蓄積します。もしAIが間違えたなら、正しい解決策を「正解データ」としてRAGのナレッジベースに追加します。これを繰り返すことで、AIは自社のシステム特有のトラブルに強い「ベテラン」へと成長していきます。

誤解析パターンの蓄積とプロンプト改善サイクル

AIが頻繁に間違えるパターンがあれば、それはプロンプトを改善するチャンスです。

例えば、「タイムアウトエラーが出るとすぐに『ネットワーク障害』と断定してしまう」という癖が見つかったら、プロンプトに「タイムアウト時は、まずアプリケーション側の処理遅延を疑い、CPU使用率を確認してからネットワーク要因を検討せよ」といった指示（思考の連鎖：Chain of Thought）を追加します。

この「プロンプトエンジニアリングの運用」こそが、これからのシステム運用に求められる新しいスキルセットになるでしょう。

運用メンバーへのAIリテラシー教育とオンボーディング

最後に、最も重要なのは「人」です。AIを恐れず、過信せず、道具として使いこなすマインドセットをチームに醸成することが求められます。

「AIは私たちの仕事を奪うものではなく、私たちが本来やるべき『信頼性向上のためのエンジニアリング』に時間を割くためのパートナーである」

この共通認識を持つことで、AI導入は単なるツール導入を超え、チームの文化を変革するきっかけになります。

まとめ：AIは「魔法の杖」ではないが、最強の「バディ」になり得る

LLMを活用したRCAの自動化は、システム運用の業務を劇的に変えるポテンシャルを持っています。しかし、それは「魔法の杖」ではありません。論理的な期待値設定、Human-in-the-Loopのワークフロー、地道なハルシネーション対策、そして厳格なセキュリティ運用があって初めて機能するものです。

1. 完全自動化を急がない: まずは「調査アシスタント」から始める。
2. 証拠を出させる: ログの引用がない推論は信用しない。
3. データを守る: マスキングなしにログを投げない。
4. 育てる: 失敗をナレッジに変え、AIを教育する。

このステップを踏めば、AIはチームにとって、24時間365日文句も言わずにログを読み続けてくれる、何よりも頼もしい「バディ」になるはずです。

まずは小さな一歩から始めましょう。特定のサービス、特定のアラート種類に絞ってPoC（概念実証）を行うことをお勧めします。実際に自社のログをAIがどう解析するか、実証データに基づいてその効果を確かめてみてください。