ミス・障害の報告書をAIと作る：経緯・原因・再発防止を混ぜない書き方

3つを分ける理由と、AIに任せる範囲

混ざる原因は、性質の違う内容を同じ段落に書いてしまうことです。

• 経緯、書くもの：何時に何が起きたか、根拠：ログ、チャット、チケット等の記録、AIに任せる範囲：並べ替えと整形。補完はさせない
• 原因、書くもの：なぜ起きたか、根拠：調査結果。未確認なら「推定」と明記、AIに任せる範囲：候補の洗い出しまで。確定は人
• 再発防止、書くもの：次に起きにくくする変更、根拠：原因との対応、AIに任せる範囲：案出し。実行可否は人

AIは記録にない事実を知りません。「記録にない時刻や担当者は書かない」と明示します。原因が確定したかどうかを決めるのは、調査した人と責任者です。

入力前に、渡す情報を置き換える

報告書の元データには、顧客名、社員名、社内システム名、ログ中のIDなどが入っています。AIに貼る前に、「担当A」「顧客X」「システムP」のような役割名や記号へ置き換えます。氏名が見えない状態で原因を考えると、人ではなく手順や仕組みに目が向きやすくなる、という副次的な利点もあります。

ここで、「学習に使われない」ことと「秘密が守られる」ことは別です。

• AnthropicのClaudeのサポート記事は、Free・Pro・Maxなど個人向け製品が対象です。モデル改善を許可した場合、データはユーザーIDから切り離され、アクセスは学習に関わる少数の担当者に限られるとあります。シークレット(incognito)チャットは、モデル改善をオンにしていても改善に使われないとされています。一方で、機密性の高いビジネス文書の共有は避けるよう案内しています。また、安全性分類器にフラグされた会話は、引き続き内部の信頼・安全性モデルの改善に使われる場合があるとの注記もあります。
• Microsoftの職場・学校アカウント向けCopilot Chatのデータ保護の記事では、プロンプトと応答は基盤モデルの学習に使われないと説明されています。ただしプロンプトや応答は記録され、IT管理者が検索・監査ツールで確認できます。Bing検索は別のデータ取扱いになるとも書かれています。

確認したのは上記のプラン・アカウント種別の説明だけです。お使いのサービスや契約の条件は、社内ルールと各社の最新の案内で確認してください。社内で利用が認められたツールに、置き換え後のデータだけを渡すのが無難です。

手順：4回に分けてAIに依頼する

【】の部分を差し替えて使います。これも説明用のひな形で、特定のAIでの動作を検証したものではありません。

手順1：記録から時系列だけを作る

あなたは障害報告書の編集補助です。
以下の記録だけを使い、時系列の表(時刻/出来事/根拠となる記録)を作ってください。
ルール:
- 記録にない時刻、人物、原因は書かない。不明な箇所は「不明」と書く
- 「なぜ」「〜のせいで」「怠った」など、原因や評価の表現は使わない
- 人は役割名のまま扱う(担当A、確認者Bなど)
- 記録同士で食い違う点は、最後に「食い違い」として列挙する

【ここにログ・チャット・チケットの抜粋を貼る】

出てきた表は、元の記録と一行ずつ突き合わせます。時刻の誤りや、勝手な補完がないかを見ます。

手順2：原因は「候補」として出させる

次の時系列(確認済み)を材料に、原因の候補を3〜5件挙げてください。
ルール:
- 各候補に「裏づけとなる事実」「まだ確認できていない点」「確認方法」を付ける
- 手順・ツール・情報共有・設定・体制など、仕組みの側から考える
- 個人の注意不足、意識、能力を原因にしない
- 断定せず「〜の可能性がある」と書く

【手順1で確認した時系列を貼る】

確認方法を実施して裏づけが取れた候補だけを、人が「原因」欄に移します。取れていないものは「推定」として別に残します。

手順3：再発防止策を種類別に出させる

次の原因に対して、再発防止策を出してください。
ルール:
- 「防止(起きにくくする)」「検知(早く気づく)」「復旧(影響を小さくする)」に分ける
- 「注意する」「徹底する」「周知する」だけの対策は、具体的な仕組みに言い換える
- 各対策が、どの原因に対応するかを明記する。推定の原因への対策には「推定に基づく」と付ける
- 担当は役割名で、期限は空欄にする

【確認済みの原因と、推定の原因を分けて貼る】

手順4：表現のチェックを別の依頼でかける

次の報告書案から、個人への非難、推測の断定、原因と対策の混在を探してください。
該当箇所を引用し、直し案を付けてください。直し案でも、記録にない事実は足さないでください。

【報告書案を貼る】

AIの指摘は参考にとどめ、最終判断は人が行います。

報告書の骨組み

説明用の例を入れた骨組みです。実在の事案ではありません。

■ 件名:月次請求データの取込誤りについて(説明用の例)
■ 概要(3行以内):何が、いつ、誰(部門)に、どの程度影響したか
   例:顧客Xを含む12件の請求額が、更新前の顧客マスタで計算された。

■ 1. 経緯(事実のみ・時系列)
   | 時刻 | 出来事 | 根拠 |
   | 10:05 | 担当Aが取込を実行 | 実行ログ |
   | 10:40 | 確認者Bが差異に気づき連絡 | チャット記録 |

■ 2. 影響範囲(確認済みの範囲/未確認の範囲を分ける)

■ 3. 原因
   3-1 確認済み:取込対象ファイルが更新前のものだった(ファイル日時で確認)
   3-2 推定:取込前にファイルの更新日時を照合する手順が明文化されていなかった可能性
       (確認方法:手順書の版管理を確認、関係者への聞き取り)

■ 4. 再発防止
   | 対応する原因 | 種類 | 対策 | 担当(役割) | 期限 |
   | 3-2(推定) | 防止 | 取込画面で更新日時を表示し、照合を必須項目にする | 運用リーダー | |

■ 5. 未解決事項・今後の確認

ポイントは、原因欄を「確認済み」と「推定」に割ることです。AIが出した候補が混ざっても、読み手が事実と推測を見分けられます。

原因欄が個人批判になっていないかの確認項目

報告書を出す前に、次の項目を上から順に確認します。

1. 原因欄に氏名、または「担当者が」「〜さんが」を主語にした文がない
2. 「怠った」「不注意」「認識が甘い」「意識が低い」といった評価語がない
3. 人の行動を書く場合は、その行動が起きうる仕組み(手順・画面・権限・負荷)も併記している
4. 「なぜ、その確認が機能しなかったのか」を一段掘っている
5. 再発防止が「注意喚起」「周知」「教育」だけで終わっていない
6. 確認していない内容が、断定の文末(〜である)で書かれていない
7. 経緯欄に「ため」「ので」など因果を示す語が入り込んでいない
8. 担当や関係者の記載が、役割名または社内ルールに沿った表記になっている

書き換えの例(説明用):

• 修正前:「担当Aが古いファイルを使い、確認を怠った」
• 修正後(経緯):「10:05に、更新前のファイルで取込が実行された(実行ログ)」
• 修正後(原因・推定):「取込前にファイルの更新日時を照合する手順が明文化されておらず、確認が個人の判断に委ねられていた可能性がある。手順書の版管理と聞き取りで確認する」

個人の行為を隠すのではなく、行為は経緯に事実として書き、原因は「それを防げなかった仕組み」として書く、という分け方です。人事上の対応や責任の所在は、この報告書とは別に組織のルールで決めるのが一般的です。報告書に混ぜないほうが、関係者も事実を話しやすくなります。

提出前には、次の点を人が確認します。

• 経緯の各行が、元の記録で確認できる
• 原因の「確認済み」が、調査で裏づけられている
• 再発防止の担当と期限を、実際に決めた人が入れている
• 外部に出す場合は、社内の取扱いルールに合わせて固有名詞を戻している

AIの出力は下書きで、確認の責任は報告書を出す人にあります。