ツール比較・レビュー

Copilotで障害報告書を作る手順

Copilotで障害報告書を作る手順

この記事の要点

Microsoft Copilotを使えば障害報告書のたたき台を数分で作成できる。5W1H整理から根本原因分析・再発防止策まで、プロンプト例と手順を解説。

結論

Copilotを使うと、障害発生後の報告書作成を30分以内で始められる。インシデント収束直後の混乱した状況でも、断片的なメモや時系列ログをCopilotに渡すだけで、報告書として整った文書のたたき台が出てくる。根本原因分析や再発防止策の検討も、Copilotとの対話で素早く進められる。


前提:必要なプランとアクセス方法

スタンドアロン版(copilot.microsoft.com) Microsoftアカウントで無料利用可能。ブラウザから開いてチャット形式でやり取りする。

Copilot for Microsoft 365(M365統合版) WordやTeamsのCopilotを使うと、Teamsの会話ログをそのまま参照して報告書を生成したり、Wordドキュメントに出力を直接挿入したりできる。利用にはM365有料プランが必要。詳細は管理者または公式サイトで確認すること。

機密情報の取り扱いについては、入力前に社内のAI利用ポリシーを確認すること。


手順1:インシデントの情報を箇条書きで整理する

報告書を作る前に、手元にある情報を箇条書きに落とす。記憶が新鮮なうちにメモを取ることが重要で、後から思い出す手間をなくす。

最低限、以下の情報を揃えると出力の精度が上がる。

  • 障害が発生した日時
  • 影響を受けたシステム・サービス
  • 影響範囲(ユーザー数・売上・業務への影響)
  • 最初に異常を検知した方法と時刻
  • 対応した担当者・部署
  • 実施した対処内容(時系列で)
  • 復旧した時刻
  • 暫定対処か恒久対処か

このメモをプロンプトにそのまま使う。


手順2:タイムラインを整理する

断片的なメモや複数人のやり取りがある場合、まずタイムライン整理を依頼する。

以下の情報をもとに、インシデントの時系列タイムラインを整理してください。
時刻・出来事・対応者の3列の表で出力してください。

- 14:23 監視ツールがAPIエラー増加を検知(エラー率5%→40%)
- 14:25 アラートがSlackに通知。インフラ担当Aが確認開始
- 14:30 インフラ担当AがDB接続数の異常を発見。チームに共有
- 14:35 DBエンジニアBが参戦。スロークエリの存在を確認
- 14:50 問題のクエリをキルし、一時的にエラー率が低下
- 15:05 再度エラー率上昇。接続プールの枯渇と判断
- 15:20 接続プール上限を一時的に拡張して応急処置
- 15:35 エラー率0%に回復。サービス正常化を確認
- 16:00 インシデント収束宣言

この出力が正確かどうかを確認し、抜けがあれば追加する。


手順3:報告書のたたき台を生成する

タイムラインが整ったら、報告書全体を生成する。

以下の情報をもとに、社内向けの障害報告書を作成してください。

【障害名】本番APIサービスの大規模エラー
【発生日時】2026年6月3日 14:23
【復旧日時】2026年6月3日 15:35
【影響範囲】外部向けAPIサービス全体。推定で約1,200ユーザーが影響を受けた
【影響時間】72分
【原因(暫定)】DBの接続プール枯渇によるAPIエラーの連鎖
【対処内容】問題クエリの強制終了→接続プール上限の一時拡張→サービス正常化

以下の構成で作成してください。
1. 概要(発生から復旧までのサマリー)
2. 影響の詳細
3. インシデントタイムライン(表形式)
4. 原因分析(直接原因・根本原因)
5. 実施した対処
6. 再発防止策(短期・中長期)
7. 今後のアクションと担当・期限(表形式)

読者は経営陣と関連部署のマネージャーを想定し、技術的な詳細は脚注または注釈として添えてください。

手順4:根本原因分析を深める

最初の出力の原因分析が浅い場合、5Whyを使って深掘りする。

先ほどの障害の直接原因「DBの接続プール枯渇」について、5Whyで根本原因を分析してください。

各Whyに対して、想定される複数の回答を示したうえで最も可能性の高い仮説を選んでください。
分析結果は以下の形式で出力してください。

Why1: なぜ接続プールが枯渇したのか?
→ 回答と仮説
Why2: なぜ(Why1の原因)が起きたのか?
→ ...(以下繰り返し)

最後に根本原因の仮説を1文でまとめてください。

この出力をエンジニアに確認してもらい、技術的な事実と照合する。CopilotはAIであり実際のシステム構成を知らないため、出力はあくまで仮説として扱うこと。


手順5:再発防止策を具体化する

根本原因が確定したら、再発防止策を具体化する。

根本原因「スロークエリの定期的なモニタリング体制がなく、問題のあるクエリがリリース後に長期間放置されていた」に対して、再発防止策を以下の軸で整理してください。

【短期(1週間以内)】今すぐ実施できる応急処置・設定変更
【中期(1ヶ月以内)】仕組み・ツールの整備
【長期(3ヶ月以内)】プロセス・文化の改善

各施策に「担当部署の案」「難易度(高・中・低)」「期待効果」を加えた表形式で出力してください。

手順6:M365統合版でTeamsの会話から報告書を作る

Copilot for Microsoft 365のTeams統合版を使っている場合、インシデント対応中のTeamsチャネルの会話履歴からCopilotに直接サマリーを生成させることができる。

Teamsのチャネルを開き、チャネル上部の「Copilot」ボタンから「このチャネルの会話をサマリーしてください」と指示する。インシデント対応スレッドを選択して「この会話をもとに障害報告書の素案を作成してください」と続けると、対話の内容から自動で文書の骨格を生成してくれる。

スタンドアロン版では、Teamsの会話をテキストとしてエクスポートしてからプロンプトに貼り付ける方法を使う。


うまくいかない場合のポイント

原因分析が「調査中」や「確認が必要」ばかりになる場合 Copilotに渡す情報が少ないほど出力が曖昧になる。監視ツールのエラーログ・DBのスロークエリ結果・直前のデプロイ情報など、手元にある技術情報をより多く貼り付けてから依頼すると精度が上がる。

再発防止策が抽象的な場合 「『モニタリングの強化』ではなく、具体的なツール名(例:Datadog、CloudWatch)や閾値の設定方法まで含めてください」と具体性の指定を追加する。

経営層向けのサマリーと技術詳細が混在する場合 「エグゼクティブサマリー(300字以内)と技術詳細セクションを分けて構成してください」と構造を明示すると、読者層に合わせた分離ができる。

英語での報告書が必要な場合 最後に「この報告書を英語に翻訳してください。技術用語は一般的な英語表現を使い、略語は初出時に定義してください」と依頼する。


作業時間の目安

フェーズ所要時間の目安
インシデント情報の箇条書き整理10〜15分
タイムライン生成・確認5〜10分
報告書たたき台の生成2〜3分
根本原因・再発防止策の深掘り15〜20分
担当者確認・最終調整20〜30分

インシデント収束から1〜2時間以内に報告書の初稿が完成する。


関連記事

よくある質問

障害報告書をCopilotで作るとき、インシデント情報をそのまま入力していいですか?

機密性の高いシステム情報や個人情報を含む場合は、社内のAI利用ポリシーに従ってください。Copilot for Microsoft 365はM365テナント内で動作し入力データが外部学習に使われない設計ですが、スタンドアロン版(無料)はデータ保護の扱いが異なります。機密情報は仮名や抽象化した情報に置き換えてから入力することを推奨します。

根本原因分析(RCA)もCopilotに任せられますか?

Copilotは5Whyやフィッシュボーン分析などのフレームワークに沿って根本原因を洗い出す補助ができます。ただし実際の根本原因の特定には現場の技術的知見が必要で、Copilotの出力はあくまで分析の補助としてください。

障害報告書のフォーマットは会社によって違いますが、どう対応しますか?

プロンプトに既存フォーマットの項目名を列挙するか、既存文書をテキストで貼り付けて「このフォーマットに合わせて作成してください」と指示すれば、社内フォーマットに沿った出力を得られます。

障害発生直後の時系列ログを整理するのにも使えますか?

使えます。チャットログ・監視ツールのアラート履歴・担当者メモなどの断片的な記録をCopilotに渡して「時系列順に整理してください」と依頼することで、インシデントタイムラインを素早く構築できます。