障害報告をAIでまとめる方法

障害対応が終わったあと、疲弊した状態で障害報告書を書くのは情報システム担当者の負担の大きい作業だ。対応ログは残っているが、時系列の整理・根本原因の整理・再発防止策の記述をゼロから文章にまとめると1〜2時間かかることも珍しくない。AIを使えば、対応メモや時系列ログを渡すだけで報告書の草稿が15分以内に出る。

結論

障害報告書のAI作成は「対応ログや振り返りメモをAIに渡し、報告書フォーマットへの変換を指示する」という一工程で完結する。AIは構造化と文章整形を担当し、時刻・IPアドレス・影響台数などの事実情報は人間が確認する役割分担が基本だ。障害対応直後の疲弊した状態でも報告書の品質を一定に保てる。

どのAIツールを使うか

**ChatGPT（GPT-4o）**はテキストの構造化と文章整形の精度が高く、長い対応ログをそのまま貼り付けて処理できる。障害報告書の草稿生成に最も使いやすい選択肢だ。

Claudeは長文の対応ログや複数のチャット履歴を一度に処理する場合に向く。複雑な障害で記録が多いケースでも、コンテキストを失わずに処理できる。

Notion AI・Confluence AIはドキュメント管理ツールに統合されているため、草稿をそのまま社内のナレッジベースに保存できる。ただし、指示の柔軟性は単体AIより限定的だ。

AIで障害報告書をまとめる手順

ステップ1：対応中のメモを残す

AIへの入力品質は元のメモの質に依存する。対応中に以下の情報を最低限メモしておくと、後工程の生成精度が上がる。

• 障害を最初に検知した時刻とその手段（監視アラート・ユーザー申告など）
• 影響が確認できたシステム・サービスと影響を受けたユーザー数の概算
• 対応のために実施した作業（時刻付き）
• 暫定対応・本対応のそれぞれの完了時刻
• 現時点で分かっている原因の仮説

対応後にメモを整備しようとすると記憶が薄れるため、対応しながら時刻付きで記録する習慣が生成精度を高める。

ステップ2：プロンプトを入力する

対応後のメモをAIに渡し、報告書フォーマットへの変換を指示する。以下はネットワーク障害の対応記録を報告書に変換するプロンプト例だ。

以下は社内ネットワーク障害の対応中に記録したメモです。障害報告書の形式に整形してください。

出力形式：
【障害タイトル】
【障害概要】（3〜5文で要約）
【発生日時】
【復旧完了日時】
【影響範囲】
  - 影響を受けたシステム・サービス：
  - 影響を受けたユーザー数・部署：
  - 業務への影響内容：
【発見経緯】
【対応経緯】（時系列で箇条書き。各行に時刻を付ける）
【原因】
  - 直接原因：
  - 根本原因：（不明な場合は「調査中」と記載）
【再発防止策】
  - 短期対応（1週間以内に実施）：
  - 中長期対応（1ヶ月以内に実施）：
【残課題・継続調査事項】

対応メモ：
（時系列のメモを貼り付ける）

ステップ3：出力を確認・修正する

AIが生成した草稿で必ず確認・修正する項目は以下だ。

1. 時刻の正確さ（発生・対応開始・復旧完了の各時刻）
2. IPアドレス・ホスト名・バージョン番号などの数値情報
3. 影響ユーザー数・対象システムの範囲
4. 原因分析の論理的な整合性（根本原因の記述が実際と合っているか）
5. 再発防止策が実行可能な具体的な内容になっているか

AIは構造を整えながら欠落している情報を推測で補完することがある。事実情報は元のログや監視ツールの記録と必ず照合する。

ステップ4：振り返り会議の記録も活用する

障害後の振り返り会議を行う場合、その文字起こしや会議メモをAIに渡して報告書を補完することもできる。

以下は障害発生後の振り返り会議の記録です。先ほど作成した障害報告書の「原因」「再発防止策」の項目を補強する内容を追記してください。

振り返り会議の記録：
（会議メモを貼り付ける）

補強する項目：
- 根本原因の分析：より詳しく記述する
- 再発防止策：会議で決定したアクションを追記する
- 残課題：会議で出た未解決事項を追記する

振り返り会議の発言から報告書を補強できるため、形式的な記録ではなく次のアクションに繋がる報告書に仕上がる。

情報システム固有の活用シーン

シーン1：重大障害のポストモーテム報告書

重大障害（全社に影響する長時間の停止など）では、経営層への報告を兼ねた詳細なポストモーテム報告書が必要になる。対応ログと振り返り会議の記録をまとめて渡し、詳細版の報告書を生成させる。

以下の資料をもとに、経営層向けの重大障害ポストモーテム報告書を作成してください。

対象：[システム名] 全社停止障害（[発生日]）

使用する資料：
1. 対応時の時系列メモ（添付）
2. 振り返り会議の議事録（添付）

出力形式：
【エグゼクティブサマリー】（5文以内。発生・影響・原因・対応・再発防止の概要）
【障害詳細】
  - 発生日時・復旧日時・総停止時間：
  - 影響範囲と業務への具体的な影響：
【根本原因分析】
  - 直接原因：
  - 根本原因：
  - 根本原因に至った背景：
【対応経緯と評価】
  - 時系列の対応内容：
  - 対応の課題点（次回への改善点）：
【再発防止策と実施スケジュール】
  - 対策内容：
  - 担当：[担当者/担当部門]
  - 期限：[日付]
【再発リスク評価】

条件：
- 技術的な詳細は別紙扱いにし、本文は経営層が理解できる表現にする
- 再発防止策には具体的な期限と担当を必ず記載する

経営層向けの要約と技術チーム向けの詳細を分けて書く構成は、AIへの指示で柔軟に制御できる。

シーン2：月次の障害傾向レポート

月次の障害対応記録をまとめてAIに渡し、傾向分析と報告用サマリーを生成させる。

以下は今月の障害対応記録（全件）の要約です。月次の障害傾向レポートを作成してください。

出力形式：
【今月の障害件数サマリー】
  - 総件数：
  - カテゴリ別内訳（ネットワーク / サーバ / アプリケーション / ユーザー端末）：
  - 重大度別内訳（業務停止 / 部分影響 / 軽微）：
【繰り返し発生している障害パターン】（3点以内）
【今月の改善点・評価】
【来月の重点課題】（2〜3点）

障害記録：
（月次の対応記録を貼り付ける）

このレポートを毎月生成して蓄積すると、季節性のある障害パターンや特定システムへの集中傾向が可視化される。

うまくいかない場合の対処

原因分析の部分が薄い：「根本原因の分析は、直接原因・根本原因・根本原因に至った背景の3層で記述してください」と構造を明示する。AIは表面的な原因で止まりがちなため、分析の深さを指示で制御する。

再発防止策が抽象的になる：「再発防止策は具体的な作業・担当・期限を含む形で記述してください」と追加指示する。「監視強化」のような抽象的な記述ではなく「XX監視ツールで〇〇のアラートを追加する（担当：[氏名]・期限：[日付]）」の粒度を求める。

時系列が入り組んで整理されない：元のメモを時刻順に並べてからAIに渡す。入力の時系列が混乱していると、出力も混乱する。手動で時刻順に並べた上でAIに整形させると精度が上がる。

報告書が長くなりすぎる：「エグゼクティブサマリーを5文以内にまとめ、詳細は各項目300字以内にしてください」と字数制限を明示する。

作業量の目安

障害規模	従来の報告書作成時間	AI活用後の所要時間
軽微（ユーザー1〜2名への影響）	20〜30分	5〜8分
中規模（部門単位の影響）	60〜90分	15〜20分
重大（全社影響）	2〜3時間	30〜45分

月5件の障害対応をこなす担当者なら、月4〜6時間の報告書作成時間が削減できる計算になる。

他の業務への応用

障害報告書の作成で使ったメモ→構造化のアプローチは、社内ヘルプ対応をAIで効率化する方法での対応記録作成にも応用できる。会議やヒアリングの内容を構造化する場合は情報システムの文字起こしをAIで整形する方法も参考になる。

導入の第一歩

直近の障害対応メモを1件用意して、上記の報告書生成プロンプトをそのまま試してみる。出力を実際に書いた（あるいは書こうとしていた）報告書と比較することで、自社のフォーマットに合わせたプロンプトの改良点が見えてくる。1件試せばどのくらいの精度で使えるかの感覚が掴める。