はじめに
エンタープライズの運用をしていると、障害対応を実施した後、事後に実施する「障害報告書」の形式的な整理に時間や労力が掛かってしまって、本来行うべきポストモーテムの作成、改善への向けた取り組みに力を割けないということが、しばしば起こると感じていました。
そんな中、2025年10月にCloudWatch運用調査機能で、Incident Reportsを作成する機能が追加されました。
記事には以下のようなことが書かれています。（機械翻訳です）
この新機能を使用すると、重要な運用テレメトリ、サービス設定、調査結果を自動的にキャプチャして詳細なレポートを生成できます。レポートには、エグゼクティブサマリー、イベントのタイムライン、影響評価、実用的な推奨事項が含まれます。これらのレポートは、パターンをより適切に特定し、予防措置を実施し、構造化されたインシデント後分析を通じて運用体制を継続的に改善するのに役立ちます。
これは障害報告書に有用なドキュメントを生成してくれるのではないか？と期待して、検証してみました。
対象環境
別件でSQSを使ったデッドレターキュー（DLQ）の勉強をしていた環境がありましたので、そちらを題材にすることにしました。
流れとしては以下の作りになっています。
- ProducerのLambdaからSQSへデータを投入する
- ConsumerのLambdaがSQSを読み取り、処理をして、DynamoDBに書き込む
- SQSはReceiveCountがmaxReceiveCount(リトライ2回、合計3回の試行後)に達した時、DLQに移動する
- DLQのキュー蓄積量のメトリクスを監視して、一定量以上に蓄積するとCloudWatch Alarmが発報される
今回は運用作業ミスでConsumerのLambdaに付与しているIAMロールから、DynamoDBへアクセスするポリシーを誤って削除してしまったというシナリオで実施します（恐ろしい作業ミスです）。DLQの蓄積量が閾値を超過したことを契機として、運用調査機能を起動する仕組みで設定してみました。
CloudWatch 運用調査機能 設定
それでは、設定していきます。
毎度設定をする時に思うのですが、マネジメントコンソールにAIオペレーションと表示されるのは、初見で分かりづらくなっているのではと思います。AWSドキュメントでは、Investigationsというキーワードで表現されているので、表記を合わせた方が、わかりやすいのではと思います。
このAWSアカウント・リージョンで初めて運用調査機能を利用する形でしたので、このアカウント用に設定をクリックして初期設定を行います。
アクセス許可はデフォルトで自動作成されるIAMロールにして、調査グループを作成をクリックします。
調査グループができたら、調査を作成から、アラームから作成を選択します。
CloudWatchアラームの画面でアクションから編集をクリックします。
アクションの設定画面で、調査アクションの追加をクリックします。
DefaultInvestigationGroupを選択して、その後の設定を進めます。
CloudWatchアラームのアクションとして調査機能を設定できました。
運用調査機能の起動
ProducerのLambdaを実行すると、SQSにデータが投入され、ConsumerのLambdaが処理を実行し、DynamoDBに書き込みを実施します。
ConsumerのLambdaに付与されているDynamoDB書き込みの権限を削除します。
この状態でProducerのLambdaを実行し、SQSへレコードを追加していきます。
期待通り、Lambdaの実行が失敗しています。
SQSのVisibility Timeoutまで待ち、Lambdaがリトライ・失敗することで、DLQへメッセージが移動し、着実にカウント数がアップしていきます。
DLQの閾値超過を契機に運用調査機能が起動しました。
調査として使用するデータを淡々と承認していきます。
（移動時間中に通知を受けたので、Slackに届いた内容です）
しばらくすると、CloudWatchから提案をしてくれました。
ブラウザで機械翻訳を実施して、提案内容を確認します。
IAM権限の不足を的確に検出しています。この内容で良さそうですので、承認します。
以下はブラウザで翻訳表示した内容になります。
Agent queueの項目では、運用調査機能のエージェントが、自律的に実行した分析タスクのタスクリスト（実行済み、実行中、待機中のキュー）が表示されていて、どのように調査が行われたのかプロセスが確認できるようになっていました。このように可視化されているのは、エージェントがどう動いたのかを追う参考となりますので、ありがたい情報です。こういった情報は、以前は提供されていなかったと記憶しています。最近、AIのObservavilityに関する機能が充実してきている1つでしょうか。
続いて、いよいよIncident Reportを作成していきます。
右上のIncident Reportをクリックします。
レポート出力が始まり、少々待つと表示されます。
出力結果
出力は全て英語表示になるため、ブラウザで日本語変換して確認しました。(原文のママ読めるようになりたい。。)
まず、Report Assesmentの項目では、レポート作成において不足している数値についてコメントがまとめられています。今回の場合、影響を受ける顧客数や影響率など、この辺りをApplication Signalsなどを使ってSLO、バーンレートなどにより、ビジネス影響を可視化できていると、より充実したレポートが作成できるようになると考えます。
ビジネスへの影響データがなければ、レポートは商業的影響を評価したり、ビジネスの重要度に基づいて回復作業の優先順位を付けたりすることができず、経営陣の意思決定支援が制限されます。といった記載もあり、評価をする際の視点が、ビジネスへの影響を重視している点がよくわかります。
この視点でレポートが書かれるという点だけでも価値があると感じました。エンジニア視点だけではダメということに気付かされます。
続いて、実際のレポートです。先ほどのReport Assesmentで挙げられていた不足する情報が変数のような形で表示されます。
調査結果としてIAMロールの権限不足を挙げていましたが、そちらについても明記されています。ここまで自動でまとめてくれるというのは効率化にも寄与すると思います。
顧客影響などの観点でもまとめてくれています。アラーム発報により検知ができていることは良いことだと評価されています。
インシデント対応の観点でも評価されています。診断時間を半分に短縮するため、検討すべき点も挙げられています。事実に基づいて客観的に評価されていると感じます。
「なぜなぜ分析」のような深掘り、振り返りも行われています。
学んだ教訓も、まとめて記載されています。いや、綺麗にまとまり過ぎていて、個人的にちょっと引きました。。
エンジニアが振り返りをして、議論して、自ら考えて気づいて、ようやく学ぶ内容が、最初から綺麗にドキュメントとしてまとまって出てきてしまうので、これで自分ごとと捉えて、本当の教訓に繋がるのか、心配になります。
最後にアクションアイテムが記載されています。
優先度がつけられて、優先度高のものは30日、優先度中は60日、優先度定は90日といった期限が設定されています。各項目において、どういった対応を行うべきか、依存関係の有無まで列挙されています。
このレポートはPDFファイルとしてダウンロード、Markdon形式でコピーできるようになっています。全て英語で記載されているため、日本語にすることや追記修正を行うことを考えると、Markdown形式でコピーして、エージェントに日本語化させつつ、足りない要素を追記する形が現状では現実的な流れになると考えます。
控えめに言っても、素晴らしいレベルで作成されていると感じます。このまま全てを採用するわけには行かないですが、足りない観点を少し追記する程度で十分に使えます。これが僅か数分で出てきてしまうレベルにあることを脅威に感じると共に、これを活用しない手はないなと考えました。
（注意点）過去に作成した運用調査機能のIAMロール
今回の検証ですが、過去に運用調査機能を検証していたAWSアカウントでも試してみたところ、Incident Reportの作成が進みませんでした。しばらく待っても状況が変わらないため、画面をリロードしたところ、運用調査機能のIAMロールの権限が足りないということが表示されました。
今回、新規にデフォルト設定で自動作成したIAMロールと見比べてみたところ、AIOpsAssistantIncidentReportPolicyというIAMポリシーが不足していました。
画面に表示されて、追加したポリシーは以下になります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"aiops:PutFact",
"aiops:ListFacts",
"aiops:GetFact",
"aiops:GetFactVersions",
"aiops:UpdateReport",
"aiops:CreateReport",
"aiops:GetReport",
"aiops:GenerateReport",
"aiops:GetInvestigation",
"aiops:ListInvestigationEvents",
"aiops:GetInvestigationEvent"
],
"Resource": [
"arn:aws:aiops:ap-northeast-1:XXXXXXXXXXXX:investigation-group/*"
]
}
]
}
2025年10月のアップデート以前にCloudWatch運用調査機能を試されてIAMロール作成済みの方はご注意ください。
(その他)クロスリージョン推論
2025/11/3現在、CloudWatch 運用調査機能のクロスリージョン推論の実行リージョンは、東京リージョンを対象とした場合、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)となっていました。（以前と同様です）
先日、Amazon Bedrockでは、Anthropic Claude 4.5の日本国内クロスリージョン推論(Japan Cross Region Inference)が提供開始されましたが、運用調査機能はまだ先のようですね。
(その他)料金
気になる料金ですが、2025/11/3時点のドキュメントを読む限り、Incident Report生成自体は追加料金なしで利用できます。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Investigations-Incident-Reports.html
Incident report generation is included at no additional charge for all CloudWatch investigations users and integrates seamlessly with your investigation workflow.
以下が機械翻訳です。
インシデントレポートの生成は、すべての CloudWatch 調査ユーザーに追加料金なしで含まれており、調査ワークフローとシームレスに統合されます。
生成されるドキュメントは残念ながら英語ですが、お財布的には安心して試行できます。このレベルで追加料金なしというのは、ちょっと怖くなりますね。
なお、運用調査機能自体は１アカウント、月に150件までという制限があるのでご注意ください。（このレベルまで分析が必要な障害が月に150件も発生する方がつらいですが。。）
まとめ
今回の生成されるインシデントレポートは正直、私が期待していたレベルを大きく上回ってきました。企業によってビジネスで重視する視点は変わり、作成しなければならない障害報告書のフォーマット（重視されるポイント）も異なると思います。現時点では、Incident Reportはその全てをカバーできるわけではありませんが、インプットのベースとしては十分過ぎるレベルだと感じました。 早く日本語対応してくれることを願ってやみません。
ポストモーテムを出力するようなSaaS製品もありますが、AWS環境に閉じて、追加料金なしで実施できるという点が、かなりのアドバンテージになるのかと思います。一方でAWS環境の外で実施された障害対応（関係者へのエスカレーション実績など）については、Incident Reportではカバーできない範囲になります。足りない部分を補完しつつ、最終的にエンジニアが内容を把握して整理するその材料がかなり高い精度で生成されているというのが現状と認識しました。
この内容が、障害対応の効率化を考えていらっしゃるどなたかの参考になれば幸いです。