# 異常時の初動手順ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「「提出したのに履歴が残らない」申告から、初動手順をたどる」（12-02）の本文で実際にまとめた内容をまとめたもの。空欄版は `12-02-incident-response_template.md`。

## 1. 異常時の初動手順

| 入口 | 症状（申告） | 確認する記録と事実 | 仮説と切り分け | 原因 | 影響範囲の判定 | 対応区分 | 暫定対応 | 恒久対応／残課題 | 初動の担当 | 連絡先 |
|---|---|---|---|---|---|---|---|---|---|---|
| 利用者の申告（依頼者役・佐藤）＋失敗ログ | 提出時に「履歴の記録に失敗しました」と表示。一覧では提出済み | 状態ファイル：提出済み／履歴ファイル：0件／失敗ログ：1件（TypeError） | A 通信失敗→消える、B 拒否→消える、C 部分失敗→残る | 履歴の書き込み失敗（08-04の部分失敗。状態と履歴が別々に書かれる作りに起因） | 同じ症状の依頼が他に0件、失敗ログ1件→REQ-0003に限る | 即時対応 | 失敗ログの増加を監視、REQ-0003の扱い（履歴を補う／状態を戻す）は運用管理者が決める、依頼者へ連絡、総務課長へ報告、版が変わっていないため切戻しは行わない | 候補：状態変更と履歴追加を全部成功か全部取り消しにする（記事B）。題材アプリへの適用は未決 | 運用担当（架空） | 総務課長（架空）、依頼者本人 |

## 2. 完了条件の確認

- [x] ログ・通知・申告の3入口がある
- [x] 影響範囲の判定基準がある
- [x] 対応区分と判断者が書かれている
- [x] 症状が再現できる失敗（08-04の部分失敗）と一致している
- [x] 仮説を切り分け、原因を失敗ログで裏付けた
- [x] 切戻しの要否を版の記録から判断した
- [ ] 不整合データの扱い（履歴を補う／状態を戻す）— 未決

## 3. 次工程へ渡すもの

- [x] 異常時の初動手順（第1節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い