![[アップデート] Amazon CloudWatchのインシデントレポートにて、Amazon Q経由でなぜなぜ分析を実施してレポートに追記できるようになったので、AWS Lambda関数のエラーを分析してみた #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3cSNU2biOZjSIpzhzUgtBJ/eeb74bd4d0c8f041ce027f3258cd249f/reinvent2025_devio_try_w1200h630__1_.png?w=3840&fm=webp)
[アップデート] Amazon CloudWatchのインシデントレポートにて、Amazon Q経由でなぜなぜ分析を実施してレポートに追記できるようになったので、AWS Lambda関数のエラーを分析してみた #AWSreInvent
Amazon CloudWatchがインシデントレポート機能をサポートしました
おのやんです。記事執筆時点で、アメリカではAWS re:Invent2025期間の初日を迎えています。
そんな中、Amazon CloudWatch（以下、CloudWatch）のインシデントレポート機能にて、Amazon QのAIチャットのワークフローでなぜなぜ分析を実施し、この分析結果をレポートに自動で追記できるようになりました。引用元のページでは、Five Whys analysis（なぜなぜ分析）が可能になった、と記述があります。
こちらは、もともと一般提供されていたCloudWatch調査のインシデントレポート機能にアップデートが入った形になります。
ということで、今回はこちらを使って、実際になぜなぜ分析をやってみたいと思います。
下準備
今回はこちらの機能を試すべく、実際に筆者が検証用AWS環境で使っているAWS利用料金Slack通知用AWS Lambda（以下、Lambda）で意図的に例外を発生させ、こちらをもとにインシデントレポートを作成します。
実際に使っているコードはこちらの記事を参考にしてください。
今回はこちらの記事に掲載されているコードをベースに作成した関数にて、lambda_handler関数の最後に、例外を発生させるこちらの記述を追加してLambda関数を実行し、エラーを出してもらいます。
...
raise ValueError("error!")
...
CloudWatch調査を作成
上記の下準備が終わりましたら、さっそくCloudWatchのマネジメントコンソールにてインシデントレポートを作成してきましょう。
CloudWatchインシデントレポートを作成するには、まずCloudWatch調査を作成する必要がありますので、これから作成していきます。Lambda関数の「モニタリング」セクションから、Lambda関数のCloudWatchロググループにアクセスします。
ここから、「Investigate with Al」という表示がありますので、こちらをクリックして画面遷移します。
CloudWatch調査が作成されていない状態ですと、CloudWatchのAIオペレーションのコンソールに遷移します。ここから、CloudWatch調査を作成していきます。
まずは調査グループの作成です。今回は「保持」の項目を7日にし、残りはデフォルトで作成していきます。
次に、実際の調査を作成していきます、前述のとおり、今回はCloudWatchログから調査していきます。
AWS料金通知用関数のCloudWatchロググループを選択して、クエリを実行し、新しい調査を開始します。
調査のタイトルは「investigate-notify-aws-billing」で入力しておきます。今回は時間を自動入力できなかったようなので、手動で入力します。記事執筆時点で UTCのみ でしたので注意してください。
CloudWatch調査が作成されました。今回のCloudWatchログを読み取って、エラーの原因を解説してくれています。
この画面の下にスクロールすると、Hypotheses（以下、仮説） という項目があります。CloudWatch調査は、AWS環境をスキャンして関連がありそうな項目を調査し、その内容に基づいて仮説を生成します。インシデントレポートを生成するには、この仮説を承諾する必要がありますので、この仮説セクションをクリックします。
The root cause is a ValueError exception in the AWS Lambda Function notify-aws-billing at line 33 of lambda_function.py.とあります。いいですね、きちんと原因を特定できています。こちらの仮説の承諾ボタンを押します。
インシデントレポート作成
ここまで終わりましたらCloudWatch調査に戻って、インシデントレポートのボタンをクリックします。
インシデントレポートは数分で出力されます。非常に細かく内容がまとめられていて、障害が発生したAWSサービスとその用途、障害内容、顧客への影響など、AWS環境から読み取れること・推測できることが詳細にまとめられています。
なぜなぜ分析開始
それでは、こちらのインシデントレポートに対してなぜなぜ分析を実施したいと思います。なぜなぜ分析は、「なぜ」を5回繰り替えすことで、ミスや障害の根本の原因を深ぼっていくアプローチですね。
インシデントレポート画面の右側のサイドメニューには「Guided 5-Whys Analysis」という項目があり、ここの「Guide Me」をクリックすると「Start the 5 why workflow」というメッセージがAmazon Qに送信される、という流れです。
それでは、実際になぜなぜ分析をやってみましょう。「Guide Me」をクリックして、「Start the 5 why workflow」というメッセージをAmazon Qに送信します。
すみません、ここ検証中に1個目と2個目の「なぜ」に事前に回答していたのですが、Amazon Qのチャットを消去して初めから実施しようとしても回答を保持していました。前回のなぜなぜ分析の回答が保存されているようですね。
ここで、日本語でのやりとりを希望します。ここから3個目の「なぜ」に入っていきます。
3個目の「なぜ」に回答します。
4個目の「なぜ」を入力します。個人の検証用AWSアカウントでなぜなぜ分析をしているのですが、チャットの中で本番環境であることが前提になっていたり、組織のポリシーなどに言及していたり、なぜなぜ分析で根本原因を防ぐ内容になるよう調整されていますね。
5個目のなぜを入力します。ここで5つの「なぜ」が、新しいFactsとして保存されて、レポートを更新できるようになります。
New facts available. Regenerate report with the latest updates.：新しいFactsが利用可能です。最新のアップデートを行いレポートをRegenerateしてください、とあります。Regenerateをクリックします。
数分待機し、インシデントレポートのRegenerateが完了すると、レポートに5 Whysの項目が追加されました。
まとめ
5つの「なぜ」の入力が完了した段階で、自動でインシデントレポートを更新して追記できるようになったのは非常に面白いですね。それぞれの「なぜ」の回答結果も保存されますので、また一から回答のし直し、とはならない部分も評価できますね。
引き続き、AWS re:Invent 2025の情報をまとめていきたいと思います。では！
