はじめに

異常の通知を受けて画面を開くと、必要な情報が集まっている。原因の候補と、その判断理由、対応方法まで並んでいる。

人が内容を確認して承認すると、手順を実行し、本当に直ったかまで確かめてくれる。そんな障害対応ができたら助かる。ということで、Codexを使用して作ってみました。

作ったのは、障害対応を支援する「AI SRE Agent」。自宅のMinecraftサーバーを題材に、実際に障害を再現して試しました。

検証環境

今回の検証は、以下の環境で実施しました。ローカルLLMを使用しているため、特にCPU・メモリ・GPU構成は参考情報として記載しています。

項目	内容
ホストOS	Ubuntu 24.04.2 LTS
CPU	AMD Ryzen 7 7800X3D（8コア / 16スレッド）
メモリ	32 GB（OS認識約30 GiB）
GPU	NVIDIA GeForce RTX 4070 Ti SUPER（VRAM 16 GB）
ストレージ	WD Blue SN5000 2 TB NVMe SSD
コンテナ実行環境	Docker 28.3.3 / Docker Compose v2.39.1
Minecraft	Bedrock Server
ローカルLLM実行環境	Ollama
使用LLM	Qwen3.8 27B（27.3B、32Kコンテキスト設定）
量子化方式	GGUF Q4_K_M
監視・可視化	Prometheus / Alertmanager / Grafana
ログ	Loki
外形監視	AWS EC2上のmc-monitor
Agent API / UI	FastAPI / Jinja2

使用モデルのOllama上のタグは
qwen3.8-27b-q4km-32k:latest、
モデルサイズは約18 GBです。

作った仕組み

全体の流れは、次のとおりです。

異常を検知 → 情報収集 → 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に与えていません。