ENGINEER エンジニア 2026.11.07

障害対応の記録の残し方｜原因と再発防止を分ける

システムが復旧した直後は、次の問い合わせや通常業務に押され、記録が後回しになりやすい。しかし数日たつと、誰が何を見て判断…

text: HYPE編集部

システムが復旧した直後は、次の問い合わせや通常業務に押され、記録が後回しになりやすい。しかし数日たつと、誰が何を見て判断したかを正確に再現するのは難しくなる。障害報告では起きた事実、まだ検証中の原因、再発防止に必要な作業を混ぜないことが重要だ。筆者は顧客への説明に使える記録と、開発チームが改善に使う記録を区別して整理する。

障害の記録は、推測を混ぜないのが鉄則です。時刻と事実だけを並べると、後から検証できる記録になります。

Table of Contents

時系列は推測を入れずに記録する

検知した時刻、最初のアラート、利用者からの連絡、担当者が見たログ、対処の着手、復旧確認を別の行として残す。アクセス障害なら「画面が開かない」と「APIが失敗した」を混同しない。時計のずれやログ収集の遅延がある場合は、その事実も注記する。

アラート発火を「発生時刻」と書かない。最初に異常を観測した時点と、利用者に不具合が始まった時点は一致しないことがある。後者を特定できなければ不明と置き、監視の欠落自体を改善課題へ回す。

影響は、エラー件数ではなく相手の業務で書くこと。「予約ができない」と書くと、被害の大きさが伝わります。

影響範囲を顧客の業務で書く

エラー件数だけでは依頼主に被害が伝わらない。予約操作が完了できないのか、閲覧だけが遅いのか、決済結果の確認ができないのかを分ける。分母となる全リクエスト数が不明なら、影響率を推測してはいけない。

影響説明では技術指標のグラフを貼るだけでなく、ユーザーが完了できなかった操作を明示する。決済失敗があったなら再試行案内の必要性も論点になる。顧客対応を担当する部署が使える表現まで落とす。

顧客向けの影響説明と社内技術記録を分けて運用する体制づくりには、保守支援の役割分担も検討材料になる。公開や納品の環境を整えるなら、レンタルサーバーエックスサーバーのようなレンタルサーバーも候補になります。

事実と仮説を異なる欄に置く

ログで確認した事象には証拠の保存場所を添え、原因と思われる事柄には未検証の印をつける。デプロイ直後の発生であっても、変更が原因と確定したわけではない。複数の要因を検討し、反証できる観測値を探す。

仮説欄には検証方法を並記する。「リリース起因の可能性」の横に、変更前後の比較や対象外環境のログ確認を書く。検証に失敗した候補も消さずに残せば、あとから同じ調査を繰り返さずに済む。

暫定復旧と恒久対策を別管理する

再起動、ロールバック、キャッシュ消去などはその場の復旧策であり、必ずしも再発防止ではない。復旧後に実施する監視の修正、テストの追加、構成変更について、担当者と期日を個別に決める。

復旧宣言と原因解明を一つの承認にまとめない。サイトが閲覧可能になった時点で顧客向け案内を出し、残る調査は別の担当と期限で管理する。運用復帰後も監視の観測期間を定めておく。

復旧手順と改善チケットの結び付けを自動化できるか、既存の課題管理ツールの機能を確認したい。記録とあわせて会計まわりも整えるなら、クラウド会計ソフト freee会計のようなクラウド会計もあります。

復旧と信頼性向上を分けて考える枠組みは、Google Cloud Architecture Centerの信頼性の柱でも示されています。

原因分析は、人ではなく仕組みを見る場です。誰がではなく、なぜ防げなかったかを追うと改善につながります。

原因分析で人ではなく仕組みを見る

「確認不足だった」で終えると、次も同じ条件で障害が生じる。なぜ確認できなかったのか、手順書に欠落があったのか、権限・時間・通知の設計に無理があったのかを追う。個人を責める文面は改善提案を萎縮させる。

個人の注意不足という結論には改善の設計がない。レビューを通過した理由、テストに欠けた観点、異常通知を見落としやすい配置など、再現する構造を探す。責任追及と業務改善を分けることが率直な情報共有につながる。

障害の振り返りの進め方は、Google SRE Workbookでも、個人を責めないポストモーテム文化として整理されています。

記録の公開範囲を選ぶ

社内の詳細版には技術ログと検証過程を残し、顧客向けには影響と対応、未解決事項を中心に説明する。個人情報、認証情報、攻撃に利用されうる設定は報告書に貼り付けず、アクセスを制限した証跡へ参照をつける。

顧客には不具合の規模と対応予定が必要で、内部の認証情報は不要である。詳細ログの共有が必要なときは閲覧期限と受取人を限定する。報告書をメール添付で転送し続ける運用も見直したい。

インシデント分析の基礎を学び直す場合は、実際の障害記録を題材に演習できる講座が適している。体系立てて学びたい場合は、Webスキルを学ぶオンラインスクールデイトラのようなオンラインスクールも選択肢になります。

記録に利用者の情報が含まれる場合は、IPAの情報セキュリティの案内もあわせて確認しておくと安心です。

再発防止策に完了条件を持たせる

「監視を強化する」という抽象語だけでは終了を判定できない。失敗を模擬した試験で通知が届くこと、担当者が手順を実行できることなど確認方法を記録する。未完了の対策を完了扱いにしない。

対策欄の「対応済み」を増やしても効果を測れない。想定した失敗を起こす検証で通知が発信され、誰が受信し、何分後に初動したかなど確認する対象を決める。テスト未実施なら閉じずに状態を残す。

報告書を次の見積もりに生かす

障害対応で実際に発生した調査、再検証、顧客連絡の工数を次回の保守範囲と照らす。発注側は連絡基準を見直せるし、制作者は保守契約で何を含むか説明しやすくなる。単なる反省文よりも運用判断に使える記録を残す。

保守費の議論は感覚ではなく記録した作業の種類から始める。夜間連絡の回数、調査時に必要だった権限、復旧後の検証範囲を示せば、通常運用と別料金の境界について合意形成しやすい。

判断に使う比較表

確認する場面	実際に見ておく材料
時系列は推測を入れずに記録する	検知した時刻、最初のアラート、利用者からの連絡、担当者が見たログ、対処の着手、復旧確認を別の行として残す
事実と仮説を異なる欄に置く	ログで確認した事象には証拠の保存場所を添え、原因と思われる事柄には未検証の印をつける
原因分析で人ではなく仕組みを見る	「確認不足だった」で終えると、次も同じ条件で障害が生じる
再発防止策に完了条件を持たせる	「監視を強化する」という抽象語だけでは終了を判定できない

案件での使い方

記録の運用例として、問い合わせフォームが突然送信できなくなった制作案件を考える。受付担当が最初に気づいた時間と、監視でエラーを捉えた時間は分けて記す。再現した環境、フォームの入力条件、送信先の処理結果も残す。技術者が確認できたのは送信処理の失敗までなのに、原因欄へ「外部メール障害」と書くのは早い。メール連携を外した試験や通信記録から仮説を確かめ、判断の根拠を添える。

顧客向け報告書では、実際に問い合わせを受け付けられなかった期間と、代替の連絡先を案内した期間を示す。フォームを再公開した時点を復旧とし、その後の監視ルールの修正やテストケースの追加は別項目で追跡する。改善期限が過ぎても未完了なら、次回確認日を更新する。復旧したから対策も終わったと読まれない書き分けが大切だ。

原因分析の会議は反省の言葉を増やす場ではない。変更前の手順でどの異常を検出できたはずか、レビュー担当に必要な資料が届いていたか、繁忙期に通知が埋もれなかったかを検討する。再発防止の成果物を、担当者の注意喚起ではなく、監視設定や自動テストなど確認可能な変更として示すことで、費用を伴う改修にも説明がつく。

記録は障害対応後だけでなく、発生中から最小限の項目を入力する運用がよい。対応中に長文の報告書を書く必要はないが、調査したログの位置と実施したコマンドは残しておく。顧客への連絡に使った時刻も控えれば、技術的な復旧と説明上の復旧の差を後から確認できる。

障害記録は、顧客との信頼を守る報告書であると同時に、保守契約を設計するための実績資料になる。原因の推測を急いで確定させず、復旧と改善の完了を別々に報告したい。