はじめに
異常の通知を受けて画面を開くと、必要な情報が集まっている。原因の候補と、その判断理由、対応方法まで並んでいる。
人が内容を確認して承認すると、手順を実行し、本当に直ったかまで確かめてくれる。そんな障害対応ができたら助かる。ということで、Codexを使用して作ってみました。
作ったのは、障害対応を支援する「AI SRE Agent」。自宅のMinecraftサーバーを題材に、実際に障害を再現して試しました。
検証環境
今回の検証は、以下の環境で実施しました。ローカルLLMを使用しているため、特にCPU・メモリ・GPU構成は参考情報として記載しています。
| 項目 | 内容 |
|---|---|
| ホストOS | Ubuntu |
| CPU | XXX |
| メモリ | XX GB |
| GPU | XXX |
| ストレージ | XXX GB |
| コンテナ実行環境 | Docker / Docker Compose |
| Minecraft | Bedrock Server |
| ローカルLLM実行環境 | Ollama |
| 使用LLM | Qwen XXX |
| 量子化方式 | XXX |
| 監視・可視化 | Prometheus / Alertmanager / Grafana |
| ログ | Loki |
| 外形監視 | AWS上のmc-monitor |
| Agent API / UI | FastAPI / Jinja2 |
作った仕組み
全体の流れは、次のとおりです。
異常を検知 → 情報収集 → AIが原因と対応を提案 → 人が承認 → 手順を実行 →復旧確認
AIが担当するのは、集まった情報から原因を考え、対応方法を提案すること。情報収集や手順の実行、復旧確認はプログラムが担当します。人は、提案の根拠と操作の影響を確認し、実行してよいか判断します。
自宅の中だけでなく、AWSに置いた監視用コンピューターからも接続を確認しています。「家の中では使えるのに、外からは使えない」という違いを見分けるためです。
なお、Prometeusを使用した監視基盤の構築については以下記事で照会しています。
https://qiita.com/KanshiKun/items/1176246d27e52be652eb
同じ「つながらない」でも、対応は違う
主に二つの障害を再現し、最終的に次の対応を確認できました。
サーバーを停止させる
監視が異常を検知し、サーバーの状態や動作記録を収集。その情報をもとに、AIが停止状況を整理して、再起動手順を提案しました。
人が承認すると、登録済みの手順で再起動し、監視による復旧確認まで進められました。
外からの接続だけを遮断する
今度はサーバーを動かしたまま、ルーターのMinecraft用の通信設定を一時的に無効にしました。
監視で「自宅の中からはつながるが、外からはつながらない」ことを確認。その情報をもとに、AIが状況を整理し、接続経路の確認手順を提案しました。
人の承認後に確認手順を実行し、ルーター設定は私が元に戻しました。その後、監視側で再び接続できることを確認しています。
ルーターの設定変更まで自動化したわけではありません。それでも、「つながらないから、とりあえず再起動」ではなく、状況に応じた対応につなげられました。
操作の流れを紹介するデモはこちらです。
https://x.com/kanshi_sre/status/2096222566570705044
※デモは説明用の架空の障害情報を使い、操作の流れを再現しています。実際の障害試験の録画ではありません。
なぜローカルLLM（Qwen）を使ったのか
今回、AI診断にはローカルLLMのQwenを使用しています。
狙いは主に二つです。
1つ目は、ログや監視情報を外部サービスへ送らずに済むことです。
障害調査では、ログやホスト名、構成情報など、外部へ出したくない情報を扱うことがあります。ローカルで推論を完結させることで、こうした情報を外部へ送信する機会を減らし、情報管理上のリスク低減を狙っています。
2つ目は、継続利用時のコストを抑えやすいことです。
障害調査では、複数のメトリクスやログを何度もAIへ渡す可能性があります。ローカルLLMであれば、API利用量に応じた従量課金を気にせず、繰り返し検証しやすくなります。
もちろん、ローカルLLMにも性能や運用負荷などの課題はあります。
それでも今回は、「障害対応に使う情報をできるだけローカルに閉じつつ、継続的に使える構成にしたい」 という考えからQwenを選びました。
任せるために、止める仕組みも必要だった
AIの提案が正しいとは限りません。そこで、自由に命令を作って実行させるのではなく、操作を事前に登録した手順に限定しました。
人が承認すれば、必ず実行するわけでもありません。
例えば再起動は、最近の観測結果に異常の根拠があることが条件です。承認後でも、実行直前に正常へ戻っていれば中止します。
AIの提案、人による確認、プログラムによる条件のチェック。
一つの判断だけに頼らず、任せられる範囲を決めています。
「一から調べる」から、「提案を確認する」へ
今回、一番手応えがあったのは、原因候補を答えてくれたことだけではありません。必要な情報と判断理由、次に行うことが、そろって提示されることです。
「何から調べよう？」ではなく、「この根拠と提案で進めてよいか？」から始められる。
まだ限定した自宅環境での検証です。それでも、調査を任せ、提案を任せ、条件を決めた操作を任せる。その範囲を少しずつ広げていけば、人は影響の判断や例外への対応に、より集中できるかもしれません。
「異常が起きています」という通知から、「ここまで調べました。次はこうしませんか？」という提案へ。
そんな障害対応が、少し現実に近づいた気がします。
以下、参考情報
技術構成
| 役割 | 使用技術 |
|---|---|
| 監視・通知・可視化 | Prometheus / Alertmanager / Grafana |
| ログの収集・検索 | Loki |
| 内部・外部からの接続確認 | mc-monitor（自宅／AWS） |
| AI診断 | Ollama / Qwen |
| Agent API・操作画面 | FastAPI / Jinja2 |
| 確認・復旧手順 | YAMLで登録したRunbookと固定helper |
実行制御
AIが提案するRunbook（確認・復旧手順）は、許可されたものに限定しています。実行対象、コマンド、復旧条件はAIに決めさせず、LLM出力をeval、shell=True、bash -cへ渡す経路もありません。
実行前には、承認した手順との一致、観測情報の鮮度、対象の状態を確認します。同じ対象への重複操作は排他制御で防ぎ、診断・承認・実行・復旧確認は追記型の履歴へ保存します。
ルーターの認証情報や設定変更権限は、Agentに与えていません。