# インシデントレポートを生成する
インシデントレポートは、インシデント調査に関するレポートを迅速かつ簡単に記述するのに役立ちます。このレポートを使用して、経営陣に詳細を提供したり、チームがインシデントから学び、今後同様の事象が発生しないようにアクションを実行したりすることができます。レポートの構造は、これらのタイプのレポートの業界標準に基づいており、長期保存のために他のリポジトリにコピーできます。
AWS マネジメントコンソール を使用して CloudWatch 調査で*調査グループ*リソースを作成すると、グループの IAM ロールが作成され、調査中にリソースへのアクセスが許可されます。CloudWatch 調査インシデントレポートを生成するには、調査グループに追加のアクセス許可を付与する必要があります。新しい `AIOpsAssistantIncidentReportPolicy` マネージドポリシーは必要なアクセス許可を提供し、2025 年 10 月 10 日より後に AWS マネジメントコンソール を使用して作成された調査グループに自動的に追加されます。詳細については、「[AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy)」を参照してください。
**注記**
CDK または SDK を使用している場合は、調査グループロールを明示的に追加し、ロールポリシーまたは同等のインラインアクセス許可をロールに指定する必要があります。アクセス許可の詳細については、「[CloudWatch 調査のセキュリティ](Investigations-Security.md)」を参照してください。
これらのレポートは、調査の検出結果、根本原因、タイムラインイベント、推奨される是正措置を構造化された形式でキャプチャし、利害関係者と簡単に共有して組織の学習に使用できます。
インシデントレポートの生成は、すべての CloudWatch 調査ユーザーに対して追加料金なしで含まれ、シームレスに調査ワークフローと統合されます。
**インシデントレポートの仕組み**
1. インシデントの調査を実行します。
1. 少なくとも 1 つの仮説を受け入れます。受け入れる各仮説がレポートで考慮されます。仮説が 100% 正確である必要はありません。
1. **[インシデントレポート]** を選択します。調査中、AI が調査のために収集されたデータと導出した事実を解析しました。事実は、レポートの生成の基礎となるインシデントに関する最小単位の情報です。事実の抽出には数分かかる場合があります。
1. 事実の抽出が完了したら、次の領域で利用可能な事実を確認できます。
1. **インシデントの概要** – 重大度、期間、運用上の仮説など、インシデントの概要。
1. **影響評価** – インシデントが顧客、サービス機能、および事業運営に与える影響に関連するメトリクスと分析。
1. **検出と対応** – インシデントがいつどのように検出されたか、およびインシデントにどのように対応したかに関連するメトリクスと分析。
1. **根本原因分析** – 調査仮説に基づく基となる原因の詳細な分析。
1. **緩和策と解決策** – 緩和の手順と解決のための対策に関連するメトリクスと分析、およびインシデントの緩和策と解決策の時間測定。
1. **学習と次のステップ** – チームが考慮すべき推奨アクションのリスト。調査の検出結果から自動的に生成されます。これらの推奨事項には、類似のインシデントに対する予防策や、モニタリングおよび対応プロセスの改善案が含まれる場合があります。
1. 事実を確認したら、**[レポートを生成]** を選択してインシデントの包括的な分析を作成します。選択した事実が主要なリファレンスポイントとして機能しますが、レポートは調査中に収集されたすべての利用可能な情報から抽出されます。このプロセスには数分かかることがあります。
1. レポートを生成したら、次のいずれかを実行できます。
+ 次のようにレポートをそのまま使用します。
+ 必要に応じてコピーして外部エディタで編集する
+ 後で参照できるように保存する
+ 次のようにさらにデータを追加してレポートを強化します。
+ **[事実を追加]** (推奨される方法) を選択して、インシデントチケットやカスタム説明文などの追加のテキストベースのコンテンツを入力します。AI はこのコンテンツを分析して既存の事実を補強したり、新しい事実を推測したりします。
+ 事実を直接編集する (控えめに使用) - 手動で編集した事実は、調査タイムラインと矛盾する可能性があります。これは、**[事実を追加]** が望ましい結果を達成しない場合の最後の手段としてのみ使用してください。
+ **[レポートを再生成]** を選択して、更新された情報を使用して新しいレポートを生成します。
**Topics**
+ [インシデントレポートの AI が導出した事実を理解する](Investigations-IncidentReports-ai-facts.md)
+ [インシデントレポートの用語](Investigations-IncidentReports-terms.md)
+ [調査からレポートを生成する](Investigations-IncidentReports-Generate.md)
+ [インシデントレポートでの 5 Why 分析の使用](incident-report-5whys.md)
# インシデントレポートの AI が導出した事実を理解する
AI が導出する事実は CloudWatch 調査インシデントレポートの基盤を形成し、AWS 環境の包括的な分析に基づいて AI システムが客観的に真または可能性が高いと見なす情報を表します。これらの事実は、機械学習パターン認識と体系的な検証方法を組み合わせた高度なプロセスを通じて明らかになり、本番環境に必要な運用上の厳密さを維持するインシデント分析のための堅牢なフレームワークを作成します。
AI が導出する事実がどのように開発されるかを理解することは、その信頼性を評価し、インシデント対応中に情報に基づいた意思決定を行うのに役立ちます。このプロセスは、人工知能が人間の専門知識を置き換えるのではなく補強するというハイブリッドアプローチを表し、生成されたインサイトは包括的で信頼できるものとなります。
## AI が導出する事実の開発プロセス
生のテレメトリデータから実用的な AI が導出する事実へのジャーニーは、CloudWatch 調査 AI が高度な機械学習アルゴリズムを使用して膨大な量の AWS テレメトリを分析するパターン観測から始まります。AI は、複数のディメンションにわたって CloudWatch メトリクス、ログ、トレースを同時に調査し、人間のオペレーターにとってすぐには明らかではない繰返しのパターンと関係を特定します。この分析には、インシデントが通常発生する時期と期間の特性を明らかにする時間的パターン、障害シナリオ中にさまざまな AWS サービスがどのように相互作用するかを示すサービス相関、インシデントに先行または付随するメトリクス異常、特定の障害モードを示すログイベントシーケンスが含まれます。
例えば、アプリケーションの応答時間が許容しきい値を超える約 15 分前に Amazon EC2 インスタンスの CPU 使用率が一貫して 90% を超えることを AI が環境内で観察しているとします。この時間的関係は、複数のインシデントにわたって観察されると、さらなる調査に値する重要なパターンになります。AI は単に相関関係に注意を向けるのではなく、関係の統計的有意性を測定し、パターンに影響を与える可能性のあるさまざまな混乱要因を考慮します。
これらの観測されたパターンから、AI は仮説の生成に移行し、発見した関係に対して可能な説明を策定します。このプロセスでは、複数の競合する仮説を作成し、サポートする証拠の強さに基づいて確率でランク付けします。AI は、応答時間の低下の前に CPU が急増していることを観察すると、コンピューティング容量不足によるリソースの枯渇、メモリリークが原因の CPU オーバーヘッドの増加、特定の入力パターンによってトリガーされる非効率的なアルゴリズムなど、いくつかの仮説を生成する可能性があります。各仮説は、観測データをどの程度適切に説明し、既知の AWS サービスの動作とどの程度整合しているかに基づいて、予備的な信頼レベルを受け取ります。
これらの仮説を人間が確認および検証して、AI が生成したインサイトが運用基準を満たしていることが保証された後に、インシデントレポートでの事実になります。このプロセスには、AI が導出したパターンを確立された AWS サービスの動作モデルと相関させ、インシデント対応に関する業界のベストプラクティスとの整合性をチェックし、類似の環境の過去のインシデントデータに対して検証することが含まれます。AI は、検出結果がさまざまな分析方法と期間にわたって再現可能性があることを実証し、運用上の意思決定の統計的有意性要件を満たし、AWS サービスの動作の経験的観察と一致し、インシデントの解決または防止のための実用的なインサイトを提供する必要があります。
このプロセスを通じて、AI はいくつかの固有の課題に直面します。AI が導出した事実を解釈する際にはこのことを理解しておくべきです。相関と因果の区別は基本的な課題として残っています。AI はネットワークトラフィックの急増とインシデントの発生の間に強い相関関係を特定することがありますが、直接の因果関係を確証するには追加の調査とドメインの専門知識が必要です。サードパーティーのサービスの依存関係や外部ネットワークプロバイダーの問題など、AWS テレメトリの範囲外に存在する隠れた変数は、AI 分析に取り込まれずにインシデントに影響を与える可能性があります。AI が導出した事実の品質は、基盤となる CloudWatch データの完全性と正確性によってまったく異なるため、信頼性の高いインサイトを得るには包括的なモニタリングカバレッジが不可欠です。
新しいインシデントパターンには別の課題があります。これらは AI トレーニングデータには存在せず、AI が不慣れな障害モードの解釈に苦労することがよくあるためです。この制限は人間の専門知識の重要性を強く示しています。AI が導出した事実を解釈し、それらをドメインの知識とコンテキストの理解で補完する必要があるからです。
## AI が導出した事実をインシデント対応に適用する
AI は、人間が手動で分析するのが現実的ではない大規模なデータセット全体のパターンを特定することが得意で、インシデントの診断と解決を大幅に加速できるインサイトを提供します。AI は、コンテキストを提供し、結論を検証し、テレメトリデータにキャプチャされない可能性のある要因を特定できる人間の専門知識と組み合わせると最も効果的です。
最も効果的なアプローチは、AI が導出した事実を、最終的な結論ではなく、調査のための高度な情報に基づいた出発点として扱うことです。AI が「データベース接続プールの枯渇がインシデントの 8 分前」などの事実を特定すると、データベースメトリクスとアプリケーションログのターゲットを絞った分析を通じて迅速に検証できる貴重な道しるべとなります。この事実によって調査する特定の時間枠と潜在的な根本原因がわかり、利用可能なすべてのテレメトリを手動で検索するよりも、問題を特定するのに必要な時間が大幅に短縮されます。
データ品質は、AI が導出した事実の信頼性において重要な役割を果たします。CloudWatch モニタリングのカバレッジが包括的であると、AI は分析のための完全で正確な情報にアクセスできます。AI は利用可能なデータでのみ機能するため、モニタリングにすき間があると不完全または誤解を招く事実につながる可能性があります。詳細なメトリクス収集、包括的なログ記録、分散トレースなど、徹底的なオブザーバビリティプラクティスを使用している組織は、インシデントレポートに正確で実用的な AI が導出した事実が含まれている可能性が高くなります。
# インシデントレポートの用語
CloudWatch 調査インシデントレポートでは、次の用語が使用されます。
AI が導出した事実
AWS サービス内の利用可能なデータ、テレメトリ、ログ、履歴パターンに基づいて、AI システムが客観的に真または可能性が高いと見なす個々の情報または観測。これらの事実はアルゴリズム分析と機械学習モデルによって導き出され、システムによって信頼できるものとして扱われますが、特に重要な意思決定コンテキストでは、人間による検証を受ける必要があります。AI が導出した事実には、人間のオペレーターにとってすぐには明らかではないシステム動作に関するイベント間の相関関係、異常検出、または推論が含まれる場合があります。
是正措置
AWS ベストプラクティスと影響を受けるリソースの特定のコンテキストに基づいて、インシデントの根本原因に対処し、再発を防ぐために CloudWatch 調査で推奨される具体的で実用的な手順。
事実のカテゴリ
レポート生成のためにデータを整理するために使用される、影響メトリクス、検出の詳細、緩和手順などのインシデント関連情報の構造化されたグループ化。
影響の評価
調査に追加された CloudWatch メトリクスやその他の AWS サービスのデータから導出された、システムパフォーマンス、ユーザーエクスペリエンス、ビジネスオペレーションに対するインシデントの影響の定量的および定性的評価。
インシデントレポートの生成
CloudWatch 調査の調査中に収集されたデータに基づいて、タイムライン、影響、根本原因、解決手順など、運用インシデントの包括的なドキュメントを作成する自動化されたプロセス。
調査フィード
CloudWatch 調査の調査内で受け入れられた観測値、仮説、およびユーザー追加メモの時系列表示。調査の進行状況と検出結果のプライマリレコードとして機能します。
教訓
組織全体のシステムの信頼性、運用効率、インシデント対応能力の向上を目的として、インシデント調査プロセスを通じて特定されたインサイトと改善の機会。自動的に生成されます。
レポート評価
生成されたインシデントレポートの自動評価。レポートの完全性と品質を向上させるために、データ欠落の可能性や追加情報が必要な領域を特定します。
根本原因分析
CloudWatch 調査の AI 主導の仮説と複数の AWS サービス間の相関を活用して、運用上の問題の基本的な理由を特定する体系的なプロセス。
提案タブ
システムテレメトリとログの分析に基づいて、潜在的な原因や関連する問題に関する AI 生成の観測と仮説を表示する CloudWatch 調査の機能。
タイムラインイベント
インシデント発生中の重要な事象の時系列シーケンス。CloudWatch ログ、メトリクス、その他の AWS サービスのデータから自動的に抽出され、インシデント進行状況の概要を明確にします。
# 調査からレポートを生成する
進行中の調査または完了した調査からインシデントレポートを生成できます。調査の早い段階で生成されたインシデントレポートには、根本原因や推奨されるアクションなどの重要な事実が含まれていない場合があります。調査がアクティブになると、利用可能な事実を編集して、調査を追加情報で補完できます。調査の終了後は、調査に事実を編集または追加することはできません。
**前提条件**
インシデントを生成する前に、次の要件が満たされていることを確認します。
+ 調査グループが必要な KMS キーを使用し、AWS サービスからデータを復号するための適切な IAM ポリシーがロールにアタッチされていることを確認します。AWS リソースがカスタマーマネージド KMS キーで暗号化されている場合は、IAM ポリシーステートメントを調査グループロールに追加して、CloudWatch 調査にこのデータの復号とアクセスに必要なアクセス許可を付与する必要があります。
+ 調査グループロールに次のアクセス許可が付与されている。
+ `aiops:GetInvestigation`
+ `aiops:ListInvestigationEvents`
+ `aiops:GetInvestigationEvent`
+ `aiops:PutFact`
+ `aiops:UpdateReport`
+ `aiops:CreateReport`
+ `aiops:GetReport`
+ `aiops:ListFacts`
+ `aiops:GetFact`
+ `aiops:GetFactVersions`
**注記**
これらのアクセス許可をインラインポリシーとして調査グループロールに追加することも、調査グループロールに追加のアクセス許可ポリシーをアタッチすることもできます。詳細については、「[インシデントレポート生成のアクセス許可](Investigations-Security.md#Investigations-Security-IAM-IRG)」を参照してください。
新しいマネージドポリシー `AIOpsAssistantIncidentReportPolicy` は必要なアクセス許可を提供し、2025 年 10 月 10 日より後に作成された調査グループに自動的に追加されます。詳細については、「[AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy)」を参照してください。
**インシデントレポートを生成するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. 左のナビゲーションペインで、**[AI Operations]**、**[Investigations]** を選択します。
1. 調査の名前を選択します。
1. 調査ページの **[フィード]** で、追加の関連する仮説を受け入れ、調査にメモを追加します。
**注記**
レポートの生成には、受け入れられた仮説が少なくとも 1 つある調査が必要です。
1. 調査ページの上部で、**[インシデントレポート]** を選択します。調査の関連する事実が収集され、同期されるまで待ちます。
1. **[インシデントレポート]** ページで、レポートの生成に使用されている事実を確認します。事実は右側のペインで確認できます。左矢印と右矢印を使用して [事実のカテゴリ] タブに移動するか、ペインを展開してすべてのカテゴリを表示します。
1. [事実] パネルで **[編集]** を選択して、そのカテゴリのデータを手動で追加または編集します。
1. [事実] パネルの **[詳細を表示]** を選択して、AI アシスタントが収集したサポートする証拠と事実の履歴を確認します。[事実の詳細] ウィンドウ内で **[編集]** を選択することもできます。
1. 外部イベントや酌量すべき状況など、調査にコンテキストを追加する場合は、**[事実を追加]** を選択します。
1. **[レポートを生成]** を選択します。
CloudWatch 調査は調査データを分析し、構造化レポートを生成します。このプロセスには時間がかかる場合があります。
1. プレビューペインで生成されたレポートを確認します。レポートには以下が含まれます。
+ 自動的に抽出されたタイムラインイベント
+ 受け入れられた仮説に基づく根本原因分析
+ 調査テレメトリから導出された影響評価
+ AWS ベストプラクティスに従って推奨される是正措置と教訓
1. レポートのコピーを別の場所に保持するには、レポートのテキストをコピーして目的の場所に貼り付けます。
1. **[レポート評価]** を選択して、レポート内のデータ欠落のリストを確認します。この情報を使用してレポート用の追加データを収集し、それに応じて事実を更新してレポートを再生成できます。
# インシデントレポートでの 5 Why 分析の使用
インシデントレポートを生成するとき、CloudWatch 調査は 5 Why 根本原因分析を実行して、運用上の問題の基になる原因を体系的に特定できます。この構造化されたアプローチによりインシデントレポートが強化されて、インサイトの深さが増し、修復ステップが実行可能になります。
この機能は、チャットで会話できるように Amazon Q を使用します。AWS マネジメントコンソール にサインインするユーザーは、次のアクセス許可を持っている必要があります。
```
{
"Sid" : "AmazonQAccess",
"Effect" : "Allow",
"Action" : [
"q:StartConversation",
"q:SendMessage",
"q:GetConversation",
"q:ListConversations",
"q:UpdateConversation",
"q:DeleteConversation",
"q:PassRequest"
],
"Resource" : "*"
}
```
これらのアクセス許可を直接追加することも、[AIOpsConsoleAdminPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsConsoleAdminPolicy.html) または [AIOpsOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsOperatorAccess.html) マネージドポリシーをユーザーまたはロールにアタッチすることもできます。
## 5 Why 分析とは
5 Why は、「なぜ」を繰り返し、インシデントの症状から基本的な原因にドリルダウンする根本原因分析手法です。各回答が次の質問のベースとなり、単なる表面レベルの症状ではなく、真の根本原因を明らかにする論理チェーンが作成されます。
インシデントレポートの生成中、CloudWatch 調査はこの方法を使用して調査の検出結果を分析し、直接的な技術上の障害を超えてプロセス、設定、または体系的な問題を特定する構造化された根本原因分析を提供します。
## インシデントレポートにとっての利点
インシデントレポートに 5 Why 分析を含めると、いくつかの利点があります。
+ **包括的な根本原因の特定** - 直接的な技術的原因を超えて、基盤となるプロセスやシステムの問題を特定します。
+ **実行可能な修復計画** - 一時的な修正ではなく、具体的でターゲットを絞ったアクションを提供して、再発を防止します。
+ **組織学習** - 将来のリファレンスとチームの知識共有のために、完全な因果連鎖をドキュメント化します。
+ **構造化分析** - アドホックな問題解決ではなく、調査を体系的に行います。
## インシデントレポートのシナリオ例
### データベース接続障害インシデント
**起点となるインシデント:** E コマースアプリケーションで 500 件のエラーが広範囲に発生
1. **Why 1:** ユーザーに 500 件のエラーが発生するのはなぜですか? アプリケーションがプライマリデータベースに接続できないからです。
1. **Why 2:** アプリケーションがデータベースに接続できないのはなぜですか? データベースインスタンスで使用可能な接続を使い果たしたからです。
1. **Why 3:** データベースが接続を使い果たしたのはなぜですか? バッチ処理ジョブが多くの接続をオープンして適切にクローズしなかったからです。
1. **Why 4:** バッチジョブが接続を適切にクローズしなかったのはなぜですか? ジョブのエラー処理に障害シナリオでの接続クリーンアップが含まれないからです。
1. **Why 5:** 適切なエラー処理が実装されなかったのはなぜですか? コードレビュープロセスにリソース管理パターンに特化したチェックが含まれないからです。
**根本原因:** リソース管理に対するコードレビュー基準が不十分
**推奨されるアクション:** コードレビューチェックリストの更新、接続プーリングモニタリングの実装、自動リソースリーク検出の追加
### パフォーマンス低下インシデント
**起点となるインシデント:** API 応答時間がトラフィックの急増時に 200 ミリ秒から 5000 ミリ秒に増加
1. **Why 1:** 応答時間が長くなったのはなぜですか? すべてのアプリケーションインスタンスで CPU 使用率が 100% に達したからです。
1. **Why 2:** 自動スケーリングがインスタンスを追加しなかったのはなぜですか? 自動スケーリングがトリガーされましたが、新しいインスタンスがヘルスチェックに失敗したからです。
1. **Why 3:** 新しいインスタンスがヘルスチェックに失敗したのはなぜですか? アプリケーションのスタートアッププロセスには 8 分かかり、これがヘルスチェックのタイムアウトより長いからです。
1. **Why 4:** スタートアップに時間がかかるのはなぜですか? アプリケーションは、スタートアップのたびに S3 から大きな設定ファイルをダウンロードするからです。
1. **Why 5:** このスタートアップの遅延が自動スケーリング設定で考慮されなかったのはなぜですか? パフォーマンステストが、コールドスタートではなく、事前にウォームアップされたインスタンスで行われたからです。
**根本原因:** パフォーマンステストの方法に本番環境での自動スケーリングシナリオが反映されていないこと
**推奨されるアクション:** コールドスタートテストを含める、アプリケーションのスタートアップを最適化する、ヘルスチェックのタイムアウトを調整する、設定キャッシュを実装する
### 分析の分岐を伴う複雑なインシデント
**起点となるインシデント:** OpenSearch Serverless の顧客に対して 11 時間にわたる 48.3% の可用性低下
**メイン分析チェーン:**
1. **Why 1:** 顧客へのサービスが低下したのはなぜですか? インジェスタースケーリングが正しくないため、サービスの可用性が 48.3% に低下したからです。
1. **Why 2:** インジェスタースケーリングが正しくなかったのはなぜですか? CortexOperator が AZ バランスの計算ミスにより、インジェスターを 223 から 174 に減らしたからです。
1. **Why 3:** CortexOperator が AZ バランスを誤って計算したのはなぜですか? バージョン 1.17 へのアップグレード後、コードが新しい Kubernetes ラベル形式に対応できなかったからです。
1. **Why 4 (分岐 A - テクニカル):** コードが新しいラベル形式に対応しなかったのはなぜですか? コードは「failure-domain.beta.kubernetes.io/zone」ラベルを想定していましたが、Kubernetes 1.17 が「topology.kubernetes.io/zone」に変更したからです。
1. **Why 5 (分岐 A):** 下位互換性が実装されなかったのはなぜですか? デプロイ計画中にレビューされたアップグレードノートにラベル形式の変更が記載されていなかったからです。
**分岐 B - プロセス分析:**
1. **なぜ 4 (分岐 B - プロセス):** これがテストで捕捉されなかったのはなぜですか? 統合テストで古いラベル形式の事前設定済みクラスターを使用したからです。
1. **5 (分岐 B):** テストにラベル形式の検証が含まれなかったのはなぜですか? テスト環境の設定が本番環境の Kubernetes バージョンのアップグレードシーケンスを反映していなかったからです。
**特定された根本原因:**
+ テクニカル: Kubernetes ラベル形式の変更に対する下位互換性がない
+ プロセス: テスト方法が、バージョンのアップグレードの影響を検証するようになっていない
**統合した修復計画:** ラベル形式検出ロジックを実装し、アップグレードテストの手順を強化し、自動互換性検証を追加し、バージョン変更の影響評価プロセスを確立する。
## ガイド付き 5 Why ワークフローの使用
CloudWatch 調査には、欠落している事実への対処やインシデントレポートの強化に役立つ、ガイド付き 5 Why 分析ワークフローが用意されています。この機能は、システムが根本原因分析に強化する余地があると判断すると、推奨されるワークフローとして表示されます。
### インタラクティブな分析エクスペリエンス
CloudWatch 調査の 5 Why 分析では、調査プロセスをガイドするインタラクティブなチャットベースのアプローチを使用します。会話によるこの方法は、質問間の論理フローを維持しながら、分析を包括的にするのに役立ちます。
**インタラクティブエクスペリエンスの主な機能:**
+ **事実に基づいた初期設定** - システムは、調査から関連する事実を事前に提示し、それを使用して明らかな回答は事前に記入し、事実に基づく提案か推論に基づく提案かを明確に示します。
+ **ガイド付き探索** - 「なぜ」の質問ごとに、システムは利用可能な事実に基づいて回答を提案し、特定の追加コンテキストをリクエストし、先に進む前に重要な側面を考慮するようにガイドします。
+ **分岐管理** - 複数の要因が寄与していると特定されると、システムは分岐オプションを明確に提示し、分岐間の関係を説明し、並列調査の優先順位付けを補助します。
+ **段階的検証** - 応答ごとに、システムはわかりやすく回答を再編成し、確認を求め、主要なインサイトを強調し、検出結果をより広範なコンテキストに接続します。
このアプローチにより、最も重要な因果関係に焦点を当てながら、すべての関連情報を確実に取得できます。
**ガイド付きワークフローへのアクセス:**
1. インシデントレポートの生成中に、右側のパネルの **[注意が必要な事実]** セクションを確認してください。
1. **[推奨ワークフロー]** で **[ガイド付き 5-Why 分析]** の提案を探します。
1. **[ガイドしてください]** を選択して、インタラクティブな 5 Why のプロセスを開始します。
1. ガイド付きプロンプトに従って、「なぜ」の質問ごとに体系的に作業し、症状から根本原因までの完全な因果関係の連鎖を構築します。
ガイド付きワークフローは、5 Why 方法論の各ステップを順に進めて、包括的な根本原因情報を把握するのに役立ちます。分析結果はインシデントレポートに自動的に組み込まれ、インシデント後のレビューと組織学習のための構造化されたドキュメントになります。
また、「このインシデントに対して 5 Why 分析を実行する」や「5 Why 方法論を使用すると根本原因は何になりますか?」などの質問をすることで、チャットインターフェイスから 5 Why 分析をリクエストすることもできます。
## 複数の原因がある複雑なインシデントの処理
一部のインシデントには、並列分析パスを必要とする複数のコントリビューターが含まれます。CloudWatch 調査は、分岐分析をサポートし、確実にすべての重要な原因を特定し、対処します。
**分岐分析が必要な場合:**
+ 複数の独立した障害が同時に発生した場合
+ さまざまなシステムコンポーネントが同一の顧客への影響に寄与した場合
+ 技術的障害とプロセス障害の両方が重要な役割を果たした場合
+ 連鎖的障害により複数の因果関係の連鎖が作成された場合
**分岐分析プロセス:**
1. **分岐の特定** - システムは複数の原因が収束または分岐するポイントを特定します。
1. **並列調査** - 各分岐は、完全な 5 Why 方法論を使用して分析されます。
1. **接続マッピング** - 分岐間の関係は、それらがどのように相互作用するかを示すために文書化されています。
1. **統合された解決策** - 特定されたすべての根本原因とその相互作用に対処する修復計画
この包括的なアプローチにより、複雑なインシデントを徹底的な分析し、寄与するすべての要因に最終的な修復計画で対処します。
## 効果的な 5 Why 分析のベストプラクティス
インシデントレポートで 5 Why 分析の有効性を最大化するには、運用経験から導き出された以下のベストプラクティスに従います。
### 質問策定のガイドライン
+ **顧客への影響から始める** - ビジネスへの影響に焦点を当てるために、顧客が直面している問題から各分析を開始します。
+ **技術的な深さを段階的に増やす** - 質問を進めるにつれて、ビジネスへの影響から技術的な詳細に移行します。
+ **論理的な継続性を維持する** - 各回答が論理的なギャップなしに次の質問に自然につながるようにします。
+ **サポートする証拠を含める** - 具体的なメトリクス、ログ、またはタイムラインイベントを参照して、各回答を検証します。
### 分析の検証
以下の基準を使用して 5 Why 分析を検証します。
+ **論理フロー** - 欠落したステップがなく、症状から根本原因への進行が明確
+ **技術的正確さ** - 用語が正確、システム動作の説明が正確、コンポーネント間の相互作用が妥当
+ **完全性** - 分析では、観察されたすべての症状について説明し、対処すれば再発を防ぐ根本的な原因に到達している
+ **アクション可能性** - 特定された根本原因は、具体的で実装可能な修復アクションにつながる
### 回避すべき一般的な落とし穴
+ **症状で停止する** - 最初の技術的障害で分析を終了しないでください。システム的またはプロセス的な原因に到達するまで続行します。
+ **非難に焦点を当てた分析** - 個人のアクションではなく、システムとプロセスの障害に焦点を当てます。
+ **単一パス思考** - 複数のコントリビューターを考慮し、必要に応じて分岐分析を使用します。
+ **証拠が不十分** - 各回答が調査の具体的なデータでサポートされていることを確認します。
### インシデントレポートセクションとの統合
5 Why 分析は、インシデントレポートの他のセクションと統合され、次のような包括的なドキュメントになります。
+ **タイムラインの相関** - 「なぜ」の質問ごとに特定のタイムラインイベントを参照し、因果関係の時間的コンテキストを提供できる
+ **メトリクスの検証** - 回答が説明されている技術的な動作を示すメトリクスとグラフでサポートされている
+ **影響評価の調整** - 最初の「なぜ」が影響評価セクションに記載されている顧客への影響メトリクスに直接結びつく
+ **教訓の基礎** - 5 Why 分析によって特定された根本原因は、教訓セクションと是正措置セクションへの直接の情報源になる
この統合により、インシデントレポート全体の一貫性が確保され、初期症状から根本原因、修復計画まで、完全で一貫した説明が利害関係者に提供されます。