【AWS re:Invent 2025】CloudWatch Investigations の裏側を体験する

Amazon CloudWatch（以降、CloudWatch） Investigations は、障害発生時の一次調査（初動の切り分け）を AI が進め、 根拠とともに原因候補（RCA）や次のアクションを提示する CloudWatch のトラブルシューティング機能です。

その仕組みを深く理解するため、re:Invent のワークショップ 「Automate cloud operations with AI agents（COP403）」に参加し、 AI がどのようにインフラ調査を進めるのかを実際に体験しました。

本記事では、その体験をもとに、 CloudWatch Investigations が障害調査のどの部分を AI に委ね、 人間の役割をどのように再定義しているのかを整理します。

Investigations がもたらす運用の変化

CloudWatch Investigations は、DNS・VPC・セキュリティグループ・ログといった 複数の情報源を横断し、RCA（原因）と修復案までを提示します。

これまで「人間が調査し、AI が補助する」だったフローが、 「AI が調査し、人間が判断する」方向へ反転するのが Investigations の本質だと感じました。

その結果、運用者には次のようなメリットがあります。

• MTTR の短縮：初動調査の時間がほぼゼロになる
• 属人化の解消：誰が対応しても一定品質で切り分け可能になる
• 調査ログの自動化：報告書・証跡作成の手間が大きく減る

Investigations を理解するためのアプリ構成

この構成図はハンズオン資料から引用しました。ハンズオン用に AWS が用意した 調査対象アプリ（ExampleCorp） の全体像です。アプリやインフラは 最初から AWS が用意されていました。 実務でも頻出する「VPC が分かれていて、ネットワーク越しに DB へアクセスするアプリ」がモデルになっています。

サンプルとして用意されたWEBサービスの画面

アプリ内部には Support Tickets（問い合わせ管理機能） があります。ハンズオンでは、調査結果や対応内容が Support Tickets に自動で記録される実装になっていました。

今回発生させる障害シナリオはシンプルです。

Reporting Server（EC2）から RDS（データベース）への通信が、 Security Group の設定によって遮断されている状態です。

CloudWatch Investigations は、ネットワーク経路を辿りながら調査を行い、 通信断の原因を RCAとして提示します。

自然言語で質問すると、Investigations の内部が見えてくる

Investigations は、自由に何でも調べる AI ではありません。 あらかじめ定義された調査手段を必要に応じて呼び出す、 「使える道具が決まったエージェント」として設計されています。

ここからは、AI がツールをどう選び、どんな順序で根拠を積み上げるのかを、対話ログで確認します。AWSが用意したハンズオン用のLambdaのツールで、Investigations の動作をトレースする形で進めました。

実際にエージェントに自然言語で問いかけてみると、 CloudWatch Investigations の内部で起きていることと同じ流れで調査が進みます。

● 利用可能なツールを聞いてみる

調査範囲は「ツールとして許可された情報」に限定されます。

What tools do you have?
I have access to 4 troubleshooting tools:
- dns-resolve (Route 53)
- connectivity (VPC analysis & auto-fix)
- cloudwatch-monitoring (metrics / logs / alarms)
- current_time

● DNS 解決を依頼する（Reporting Server の特定）

AI は DNS → EC2 → VPC という依存関係をまとめて解決し、 人間が「どのサーバを調べるべきか」で迷う時間を潰してくれます。

You: Can you resolve reporting.examplecorp.com?
Hostname: reporting.examplecorp.com
Resolved IP: ***.***.***.***
Instance ID: i-*****************
VPC: vpc-*****************

● 到達性調査・ RCA

失敗地点（SG）まで特定し、原因候補を確定させています。

You: Can you check connectivity between reporting.examplecorp.com and database.examplecorp.com?
Connectivity FAILED
Issue: Security Group mismatch
DB SG does not allow inbound MySQL (3306) from ***.***.***.***

DNS 解決の後、そのまま疎通確認まで AI が自動で進めてもよさそうに見えますが、 この判断自体は Investigations の内部では すでに自動化可能なレベル にあります。 しかし、疎通確認は「探索」ではなく「介入」に当たるため 現時点では、誤操作や影響範囲を考慮し、責任境界を意識して実行の最終判断を人間に委ねているものと理解しました。

● 修復・検証

You: Yes, please fix and validate.
Added SG rule: allow TCP 3306 from ***.***.***.***/**
Connection Status: SUCCESS
Network path FOUND via VPC Reachability Analyzer

CloudWatch Investigations の画面上で見えるRCA、修復案の提示、再検証までのフローが、裏側ではこのようなテキストベースの推論として実行されています。

現場の運用はどう変わるのか

この仕組みを利用可能すると、運用現場には具体的に次の変化が起きます。

初動 30 分の削減
これまで手作業で行っていた「DNS → VPC → SG → Logs」の切り分けを、AI がまとめて実行します。

一部の熟練者に依存した体制からの脱却
ベテランだけが頭の中に持っていた調査手順が、AI のツールとして利用できます。

夜間オンコールの心理的負荷の軽減
目が覚めたときには、すでに AI が調査済みで、RCA 候補付きのアラートを確認するだけ、という状態を作れます。

証跡の自動化
AI が Support Ticket に調査結果と修復内容を書き込むため、「あとから報告書を書く仕事」が大きく減ります。

少人数で回せる運用体制
調査工程の標準化と自動化により、人数が少ないチームでも運用品質を維持しやすくなります。

まとめ

Investigations の価値は、これまで人間の頭の中にあった 「どこから調べるか」「次に何を見るか」という判断が、 AI エージェントの構成として明示的に切り出せる点にあります。 これまでナレッジ化されていなかった調査手法が形式化され、 運用は誰が対応しても同じ水準で回せる仕組みになります。

この記事は私が書きました

河野 桂子

記事一覧

ヨシ！