はじめに
近日、AIの急速な進歩によってAIエージェントを使ってトイルを解消できる道が開けてきています。以前のAIではインフラを熟知した人の所謂エスパー力といわれる知見を覚えさせることが困難なため、Google検索と同じようにナレッジ検索レベル止まりでした。しかし、さらに性能をあげ、一例で言えば実際にコマンドを実行した結果を参考にするといった方法で、今調べているのがどんなシステムなのかという点もカバーできるようになりました。様々なサービスにてAIエージェントを活用し運用作業のトイルを解消するためのサービスがリリースされるようになりました。
今回は障害対応を模したテストケースでの動作を比較することでAIエージェントの現在地とその可能性を確認したいと思います。
テストケース
色々検証していて分かったのですが最近の操作ログや、アラート情報をかき集めたものを重要参考情報として扱い、調査結果に大きな影響を与えてしまう事がわかりました。
①できるだけクラウド要因と無関係のエラーを発生させる
②できるだけ他のアラートを拾ってない状態にする
この条件を満たせるように、まっさらでアラートが一切発生していない環境のWeb＋DBの単純な2層構造のwordpress環境をAWS上に用意してみました。
※ただし、この環境は過去に同様の構成を作っては壊しているので検証結果に影響してしまっています
発生事象としてはメモリ不足やディスク枯渇など様々な要因で行き着く現象として、DBのプロセス停止を起因としてDatadogの外形監視をアラートとして通知させ、それを解析させました。CloudWatchを使わなかったのは後述にもありますが、AWSへのサービス依存度で結果が変わるからという理由です。
DB高負荷やセキュリティグループで遮断してみるなど、他の障害ケースもあるのですが、記事がとても長くなってしまうのと、障害を入れ込むオペレーション自体がノイズになってうまくいかなかったのでプロセス停止だけを今回検証結果としました。余談ですが、そもそもクラウドだとマネージドサービスになるのでプロセス停止という条件がほぼ起きえない事が結果、ソリューションによってはノイズの少ない検証結果になったかと推測します。
①AWS DevOps Agent
まずはお手並み拝見的に、リリース時にSREの仕事が無くなる？話題となったAWSのDevOps Agentで調査させてみます。調査時間は10分程度でした。
調査が完了しました。WordPressサイトのデータベース接続エラーの根本原因が特定されています。
## 問題の概要
2つの重大な根本原因が見つかりました:
### 根本原因 #1: RDSデータベースが2週間前に削除済み
- XXXXに、RDSインスタンス「XXXXXX」が削除されました
- 最終スナップショットなし、自動バックアップも削除されたため、データ復旧が不可能な状態です
### 根本原因 #2: Terraformによるインフラ再構築時にデータベース層が未構築
- XXXXにTerraformでインフラを再構築
- Legacy EC2インスタンス2台を終了し、新しいWordPress EC2を起動
- 問題: 新インスタンスは削除済みのRDSデータベースへの接続設定で起動したため、接続不可能
## 影響を受けているリソース
現在稼働中だが機能していない:
- EC2インスタンス: `XXXX`
- パブリックIP: `XXXX`
- 状態: 起動中だがデータベース接続不可
削除済み:
- RDSインスタンス: `XXXX`
- RDS Proxy: `XXXX`
## 緊急対応が必要な項目
現在、WordPressサイトが完全に利用不可能な状態です。以下の対応が必要です:
1. RDSインスタンスの再構築 (最優先)
- 新しいMySQL 8.0インスタンスを作成
- EC2からの接続を許可するセキュリティグループ設定
2. WordPress設定の更新
- EC2インスタンスに接続してwp-config.phpを新しいRDSエンドポイントに更新
3. Terraform構成の修正
- RDS/RDS Proxyリソース定義を追加
- インフラ変更の検証プロセス強化
調査の詳細なタイムラインや推奨対応策の全体については、上記のレポートをご確認ください。復旧作業について、何かサポートが必要でしょうか?見ての通りですが、DevOps Agentはクラウド上の他の操作や状態変化で関連しそうなものをごっそり拾ってきて、それを元に推測してしまいます。今回のように構成要素がAWSへの依存度が低い場合はノイズとして引っ張られてしまっています。逆を言えば、監視もCloudWatchを使ってるケースなど、AWSへの依存度が高いシステムについては少なくともクラウド周りを包括的にチェックできるので、サーバーの中を調査している裏で基盤側の異常を最近の変更差分込みで調査させる、という使い方で強力なお供になる事が考えられます。
| 調査タイプ | AWS基盤上の包括的なチェックを実施 |
|---|---|
| 使い所 | 使用しているリソースの大半がAWS上で稼働している場合 |
②Datadog Bits AI
次に監視ツールからはどのように見えてくるのか検証すべくDatadogのAI調査で調査させてみます。調査時間は9分弱で、今回調査時間としては一番短かったです。
Root Cause Analysis
New server slow downloads
The WordPress web server at XXXX (freshly provisioned ~35 minutes before testing began) exhibits intermittent ~1 second download delays on every other synthetic test request, caused by a web server or network configuration issue on the newly provisioned EC2 instance. The server was deployed as a replacement for the previous server at XXXX which became completely unreachable (60s TCP connect timeouts), and the new instance's web server configuration introduces periodic download throttling on the 68KB response body, likely due to TCP congestion window settings, output buffering misconfiguration, or rate limiting on the freshly provisioned instance that hasn't been fully tuned.※要約：新規デプロイされたWordPressサーバーにおける断続的なダウンロード遅延は、TCP設定、出力バッファリング、またはレート制限などのサーバー・ネットワーク構成の不備が原因と推測されます。
Datadogも過去のインシデントをひっくるめた調査結果にしていますので、前にあった検証環境をリプレイスしたものとして扱ってしまって、調査結果があらぬ方向になってしまいました。ただ、DevOps Agentは調査中どんな推測をしているのかはあまりはっきり見えてこないのですが、Datadogの場合は以下のような考察をパイプラインとして可視化しながら進めてくれるので人が考えている状況を覗けるような形で調査状況を確認できます。こちらもクラウドへの依存度が高い状況であればもっと精度が高かったかと思います。クラウド固有のものに非依存なので、特にマルチクラウド環境であれば最も性能が出ると思われます。
| 調査タイプ | 過去のアラートとの比較をしたうえで、バックエンドで障害対応ナレッジを参照しているので、それを元にした対応へのアドバイスをあわせて生成 |
|---|---|
| 使い所 | Datadogにて定常時から監視している場合、または、マルチクラウド構成の場合 |
③OSS(OpenSRE)
OSSでも同様のAIエージェントツールが出てきています。今回の検証を実施しようと思い立った一因となりました。
| ツール名 | 特徴 |
|---|---|
| OpenSRE | AI SREエージェントを構築するための基盤。60以上のツールと連携し、独自のワークフローを定義可能 |
| IncidentFox | チームごとに特化したエージェントを作成。階層的リトリーバル（RAPTOR）を用いた知識管理が強み |
| k8sgpt | Kubernetes診断に特化し、K8sクラスターの構成ミスをスキャンし、自然言語で解説することに特化 |
| HolmesGPT | Prometheusのアラート調査を自動化し、根本原因分析（RCA）を行うエージェント |
| Keep | 100以上のソースからアラートを集約し、AIでノイズ削減と相関分析を行う |
今回はこの中から登場からたった三か月程度で6kスター(2026年6月現在)を達成していて最も勢いがあるOpenSREを検証しました。調査時間は14分程度でした。
● INVESTIGATE 14:04 local ctrl+o tool details esc to cancel
The WordPress web server is returning an HTTP 500 Internal Server Error because it is unable to connect to its backend
MariaDB database
Findings
· WordPress Synthetics test is failing with HTTP 500 Internal Server Error.
· The operator (yasutaka.kato) modified the monitor URL and recreated all production monitors via Terraform in an
attempt to fix or update the environment, but the 500 error persists.
· The underlying EC2 instances for the web and database servers are online and healthy.
· The Datadog Agent is failing to execute the MySQL health check (`mysql.can_connect`), resulting in a 'No Data'
state.
*Non-Validated Claims (Inferred):*
· Whether the MariaDB service crashed independently or if the database instance/credentials were unintentionally
wiped during the recent Terraform configuration applied by the operator.
· Whether Datadog log collection is disabled in production (as no application logs were found for `env:production`).
*Provenance:*
· Datadog: site=datadoghq.com
Recommended Actions
· SSH into the production database instance (`role:db, env:production`) and check the status of the MariaDB service
(`systemctl status mariadb`).
· Restart the MariaDB service if it is inactive or hung.
· If the database instance was rebuilt via Terraform, verify that the database volume was correctly mounted and that
the WordPress user credentials still exist.
· Check network/security group rules to ensure port 3306 is open from the web server (`XXXX`) to the DB
server.
· Verify the Datadog Agent configuration (`conf.d/mysql.d/conf.yaml`) on the DB server to restore the
`mysql.can_connect` monitoring metric.
Cited Evidence
— Queries: get hermes logs, Datadog, Datadog Logs, Datadog Events, get sre guidance※要約：WordPressがMariaDBへの接続失敗により500エラーを返しており、原因究明のためDBの稼働状態やTerraformによる変更影響、ネットワークおよび監視設定の確認が推奨されています。
Claude Codeのようにターミナルから調査のトリガーとするアラート情報が含まれたJSONファイルを指定する事で調査が開始されます。Datadog等の監視ツールと連携する事ができるので、トリガーを指定するだけで、監視基盤上のアラートを調査した結果を出せる仕組みになっています。トリガーを人が指定するので調査開始時に人が介在しなければならないようなのですが、この仕組みのおかげで上記の通りの他のアラートからノイズを拾う事が軽減できるようで調査結果は根本原因に辿り着いています！人間の調査へサポート的に使う用途になりそうですが効果ありそうですね。
| 調査タイプ | 監視基盤から必要な情報を収集し、情報を集約したうえで発生条件を特定する |
|---|---|
| 使い所 | 有人監視のサポート役として。ログをトリガーで動くので、コンピュートリソースが多いほど効果が高い可能性がある |
④Claude Code
最後に皆様ご存知のClaude Codeです。ネタバレしてしまいますがClaude Codeを触り始めた時にコード生成とかより個人的に一番驚いたのは障害対応スキルの高さでした。調査時間は11分程度でした。
❯ syntheric.jsonにdatadogのエラーログが出力されています。解析してください
⏺ syntheric.json ファイルを探します。
Searched for 1 pattern, read 1 file (ctrl+o to expand)
⏺ 解析結果を整理します。
---
障害概要
┌────────────────┬────────────────────────────────────────────┐
│ 項目 │ 内容 │
├────────────────┼────────────────────────────────────────────┤
│ 監視テスト名 │ [WordPress] Webサーバー 外形監視 │
├────────────────┼────────────────────────────────────────────┤
│ 対象URL │ http://XXXX/ │
├────────────────┼────────────────────────────────────────────┤
│ HTTPステータス │ 500（期待値: 200） │
├────────────────┼────────────────────────────────────────────┤
│ エラー内容 │ "Error establishing a database connection" │
├────────────────┼────────────────────────────────────────────┤
│ 検知時刻 │ 2026-06-04 01:18:08 UTC │
├────────────────┼────────────────────────────────────────────┤
│ 監視拠点 │ Tokyo (AWS ap-northeast-1) │
└────────────────┴────────────────────────────────────────────┘
根本原因
WordPress が データベースに接続できない状態です。
考えられる原因：
1. DB インスタンスがダウンしている
2. MySQL サービスが停止している
3. DB とのネットワーク疎通不可（セキュリティグループ等）
4. DB 認証情報の不一致触った事がある人はご存知と思いますが、Claude Codeはあたかも人間が実施していることを肩代わりしつつ、LLMのナレッジを使って段階的にオペレーションを伴って調査をするのでエラー＆トライでガンガンと調査を進めていきます。こちらも根本原因を特定しましたし、復旧作業まで提案してきました！
障害が起きたら人間が駆けつけるまで自動的に発動させたClaude Codeに頑張らせてみるなんて良いかもしれないですね
⏺ 根本原因が特定されました。
ログに明確に記録されています：
Jun 04 01:17:31 ... sudo[30430]: ec2-user : USER=root ; COMMAND=/usr/bin/systemctl stop mariadb
MariaDB は ec2-user によって手動で意図的に停止されました。 クラッシュや障害ではなく、意図的な操作です（fault-injection-testing.md ファイルも存在しており、障害注入テストの一環と考えられます）。
MariaDB を再起動して復旧しますか？
| 調査タイプ | オペレーションをしながらLLMでナレッジで調査を進める |
|---|---|
| 使い所 | バイブコーディング的にAIに操作までも許可して良い環境 |
検証結果のまとめ
予想外に優劣が出ているように見えますがテストケースにあるように、良い結果を出しているものについては、有利になる仕組みなりが備わっています。よって、正確なソリューションの選定基準にはならないのですが、今どれだけ動くものなのか、また、それぞれがどんな動きをするものなので使い所はどこなのかを知るにはまとめられているかと思います。
まとめ
| ツール | 根本原因到達 | 調査時間 | 使い所 |
|---|---|---|---|
| AWS DevOps Agent | △（ノイズに引っ張られた） | 約10分 | AWS依存度が高い構成で、クラウド側の変更差分や基盤状態を包括チェックしたいときに強い |
| Datadog Bits AI | △（過去インシデント前提で推測が逸れた） | 約9分 | Datadogで定常監視している場合に強い。マルチクラウドなど特定のクラウド固有に寄らない環境にも強みがある（ただし履歴のノイズには注意） |
| OSS（OpenSRE） | ○（ほぼ到達） | 約14分 | アラート/ログなどトリガー入力を人が選べる前提で、ノイズを抑えつつ調査を自動化したい場合 |
| Claude Code | ◎（完全に到達） | 約11分 | ターミナル操作＋LLMナレッジで“エラー&トライ”しながら調査を前に進められる。AIによる直接の操作を許可できる環境向け |
SREの特定タスクにAIが利用できる事が確認できたかと思います。ただし、AIに代替えされていくのか？は個人的に疑問です。なぜならSREはそもそも障害対応”だけ”をするものではないからです。SLI/SLOの実装、トイルの解消、ポストモーテムなど組織横断的に改善を担うジョブです。例え、今回ご紹介した障害調査以外にも他のSRE機能がAI化していったとしても、SREは対象が対人や組織となるため全ては代替えとならず、人と人の対人インタフェースとしての役割は残るのかな、なんて思います。また半年ぐらいに同じ検証してみたいです。