架空企業「みらい業務サービス」の例。すべて教材用の演習データ上の話であり、実在の障害ではない。
演習の実行記録は evidence/sample-c/run_log.md。
時系列の時刻は教材のために架空に引き延ばしている。実際の演習では全手順を同じ分内に連続実行した（実行記録の時刻参照）。
「事実」と記した行は、演習で該当する操作を実行し記録が残っていることを指す。
1. 概要
| 項目 | 内容 |
|---|
| 障害ID | INC-2026-001（架空） |
| 発生日時 | 2026-09-18 22:22 頃（掃除スクリプト v1.1 の実行時刻） |
| 検知日時 | 同日 22:25（架空） |
| 検知のきっかけ | 承認者から「承認した依頼の履歴が空になっている」と申告（架空） |
| 影響を受けた業務・利用者 | 承認済み依頼3件（REQ-C01, C02, C04）の履歴が消失。依頼者・承認者が経緯を確認できない |
| 対応責任者 | 運用管理者（架空） |
| 現在の状態 | 復元済み（自動照合一致）・再開保留（業務確認が未実施） |
2. 時系列
| 時刻 | 出来事・行動 | 実施者 | 事実か推測か |
|---|
| 22:22 | 掃除スクリプト v1.1 を実行 | 運用管理者 | 事実（実行記録あり） |
| 22:25 | 承認者から履歴が見えない旨の申告 | 承認者 | 事実（架空の申告） |
| 22:26 | 初報：「承認記録の表示に不具合。調査中。承認操作は控えてほしい」を全利用者に送信 | 運用管理者 | 事実（架空の連絡） |
| 22:26 | 掃除スクリプトの実行を停止。以後の実行を禁止 | 運用管理者 | 事実 |
| 22:27 | 壊れた状態のファイルを別名で保全（freeze） | 運用管理者 | 事実 |
| 22:28 | v1.1 の削除条件に日付条件が抜けていることを確認 | 運用管理者 | 事実（コードを読んで確認） |
| 22:29 | スクリプトを既知版 v1.0（削除処理なし）に戻して実行。履歴は戻らないことを確認 | 運用管理者 | 事実 |
| 22:30 | 世代 gen-001 のバックアップを別の場所へ復元し、基準時点と全行照合（終了コード0） | 運用管理者 | 事実 |
| 22:35 | 途中経過：復元完了と、再操作が必要な2件を個別連絡。再開は業務確認後と周知 | 運用管理者 | 事実（架空の連絡） |
3. 影響の把握
| 確認項目 | 結果 |
|---|
| 影響を受けたデータの範囲 | 履歴 6件が削除（承認済み3件分の提出・承認履歴）。依頼データ自体は6件とも残存 |
| 影響を受けていないと確認できた範囲 | 下書き・提出済み・差戻しの依頼とその履歴 |
| 利用者から見た症状 | 承認済み依頼を開いても「誰がいつ承認したか」が表示されない |
4. 追加被害の防止
| 行動 | 実施時刻 | 実施者 | 解除の条件 |
|---|
| 掃除スクリプトの実行停止 | 22:26 | 運用管理者 | 修正版の検証完了と責任者承認 |
| 承認・差戻し操作の一時停止（架空） | 22:26 | 運用管理者 | 復旧確認表の完了 |
5. 状態の保全
| 保全したもの | 保存場所 | 指紋や件数 | 実施者 |
|---|
| 障害時のデータベースファイル | work/incident/practice_broken_<時刻>.db | 依頼6件／履歴3件。sha256は実行記録参照 | 運用管理者 |
| バックアップの控え（manifest） | work/backup/manifest.json | 依頼5件／履歴7件 | （バックアップ時に作成済み） |
6. 原因
| 項目 | 内容 |
|---|
| 直接の原因 | v1.1 の履歴削除の条件に日付条件がなく、承認済み依頼の履歴を全部削除した |
| 背景の原因 | 削除を伴うスクリプトを、演習データでの事前確認なしに実行した（架空の設定） |
| 確認方法 | v1.1 のSQLを読み、削除件数（6件）が承認済み依頼の履歴数と一致することを確認 |
7. 復旧の方法と結果
| 項目 | 内容 |
|---|
| コードの切戻し | 行った。v1.1 → v1.0（既知版、削除処理なし）。ただし消えたデータは戻らない（実行記録で確認） |
| データの復元 | 行った。復元元 世代 gen-001（work/backup/gen-001/）、復元先 work/restore/gen-001/practice_restored.db（別の場所）。基準時点 22:22 のバックアップ。復元前に復元元の指紋、復元後に復元先の指紋を照合 |
| 復旧確認表の結果 | 自動照合（指紋・可読性・件数・内容・関係）はすべて一致、終了コード0。バックアップ後の変更2件（REQ-C06 の提出、REQ-C02 の承認）は復元に含まれない。業務確認は未実施のため判定は「再開保留」 → 別紙参照 |
8. 関係者への連絡
| 時刻 | 相手 | 種類 | 内容 | 手段 |
|---|
| 22:26 | 承認者・依頼者全員（架空） | 初報 | 不具合の発生、調査中、承認操作の一時停止 | 社内チャット（架空） |
| 22:35 | 田中（REQ-C06 依頼者）、鈴木（REQ-C02 承認者） | 途中経過 | 復元完了、再提出・再承認が必要 | 社内チャット（架空） |
| 22:36 | 承認者・依頼者全員（架空） | 途中経過 | 復元完了、業務確認が済むまで承認操作は停止中 | 社内チャット（架空） |
| （未定） | 全員 | 再開連絡 | 業務確認の完了後に送る | — |
9. 再発防止
| 対策 | 担当 | 期限 | 状態 |
|---|
| 削除を伴うスクリプトは演習データで件数を確認してから実行する手順を追加 | 運用管理者 | 未定 | 未着手 |
| 削除を伴う処理を実行できる権限を限定する | 運用管理者・設計担当 | 未定 | 未着手 |
| 履歴テーブルは削除ではなく保管（アーカイブ）に変える案の検討 | 設計担当 | 未定 | 未着手 |
| バックアップの取得頻度と、復元演習の定期実施を決める | 運用管理者 | 未定 | 未着手 |
AI時代のシステム開発の基礎