障害対応の手順シート

1. 埋めておく連絡先と役割

最初に決めるのは人です。障害に気づいた人が誰に連絡するのか、止めるかどうかを判断する人は誰か、利用者への説明は誰が書くのかを、名前と連絡手段まで含めて記入します。開発会社の連絡先は、日中と夜間・休日で異なることが多いため、両方を確認してください。保守契約で対応できる時間帯がどう定められているかも、このシートに書き写しておきます。夜間は翌営業日の対応となる契約であれば、その前提で社内の段取りを組む必要があります。

• 第一報の受け先（社内の誰に、どの手段で）
• 開発会社の窓口（日中／夜間・休日、それぞれの連絡手段と対応時間）
• 停止・告知・返金などを判断する人（不在時の代理も決める）
• 利用者への告知を書く人と、告知を出す場所（サイト上、メール、SNSなど）
• サーバーや外部サービスの管理画面にログインできる人

2. 障害の程度を分ける

すべての不具合に同じ対応をしていると、現場が疲弊し、本当に重い事象への反応が鈍ります。事業への影響の大きさで段階を分け、それぞれについて誰をどの時間帯に呼ぶかを決めておきます。判断に迷ったときは重いほうに寄せる、というルールも書いておくと、最初に気づいた人が悩まずに動けます。以下は一般的な分け方の例です。自社のサービスの性質に合わせて言葉を書き換えてお使いください。

3. 最初の15分にやること

初動で大事なのは、原因を突き止めることではなく、状況を正しく把握して関係者に伝えることです。原因の調査は開発側が行います。発注側が行うのは、事実の確認と記録、そして決められた相手への連絡です。ここで推測を事実として伝えてしまうと、後の説明が混乱し、訂正の手間が増えます。分かっていることと分かっていないことを分けて伝えるだけで、その後のやり取りが落ち着きます。

• 自分でも実際にアクセスし、症状を確認する（画面を撮って残す）
• いつから、どの範囲で、誰に影響しているかを確認する
• 決められた連絡先に第一報を入れる（分かっていることだけを伝える）
• 時刻つきで記録を取り始める（後の振り返りと説明に使います）
• 直前に何か変更がなかったかを確認する（公開作業、設定変更、外部サービスの障害）

4. 利用者への告知を判断する

告知は早いほど信頼を損ないません。原因が分かっていなくても、「現在ご利用しづらい状態が発生しており、確認しています」という事実だけで出すことができます。原因の説明や復旧の見込みは、分かった段階で追記すれば足ります。復旧見込みを確度の低いうちに出すと、それを過ぎたときにかえって不信を招くため、慎重に扱ってください。告知の文面は、落ち着いて書ける平時のうちに下書きを用意しておくと、当日の負担が大きく下がります。

• 告知を出す基準（どの段階から出すか）を決めてあるか
• 出す場所（サイト上の掲示、メール、SNS）と、その操作を誰ができるか
• 第一報の下書きを用意してあるか
• 復旧の見込み時刻は、確度が低いうちは書かないと決めているか
• 問い合わせが増えたときの、受け付け方と返答の雛形

5. 復旧の判断を誰が下すか

復旧の進め方には、原因の特定を待つ、直前の変更を元に戻す、修正して出し直す、といった選択肢があります。それぞれ復旧までの時間と利用者への影響が違うため、技術的な選択であると同時に事業の判断でもあります。開発側から選択肢とそれぞれの影響を提示してもらい、事業側が選ぶ形にしておくと、後から経緯を説明できます。判断が必要な場面と、開発側の裁量で進めてよい範囲を、平時に決めておいてください。

• 直前の変更を元に戻す選択肢があるか。戻す判断は誰がするか
• 一時的にサービスを止めて、案内ページを出す選択肢はあるか
• データが影響を受けた場合、バックアップから戻す判断は誰がするか
• 復旧したと判断する基準は何か（誰がどの操作で確認するか）

6. 個人情報が関わる可能性があるとき

情報が外部に見えた可能性がある場合は、システムの復旧と並行して、別の対応が必要になります。まず、何がどの範囲で見えた可能性があるかを調べるための記録を保全し、消さないよう開発側に伝えることが最初の要点です。復旧を急ぐあまり記録が失われると、後から範囲を特定できなくなります。法令上の報告義務や利用者への通知の要否は事案によって判断が異なるため、早い段階で専門家に相談してください。

• 調査に使う記録（アクセスの履歴など）を保全し、消さないよう開発側に伝えたか
• 影響を受けた可能性のある情報の種類と件数を把握したか
• 相談先（弁護士など）の連絡先を、あらかじめ控えてあるか
• 外部への説明は、事実が確認できた範囲に限ると決めてあるか

7. 復旧後に必ず行うこと

復旧した直後は誰もが疲れていますが、記録が新しいうちに振り返るほど、得られるものが多くなります。目的は、原因を作った人を特定することではなく、同じことが起きても被害が小さくなる仕組みを作ることです。責任を追及する場にはしないと先に宣言しておくと、事実が出てきやすくなります。開発会社にも同席してもらい、双方の記録を突き合わせる形にすると、抜けの少ない時系列が作れます。

• 時系列の記録を整理する（発生・検知・第一報・復旧の各時刻）
• 検知が遅れた場合、なぜ気づけなかったかを確認する
• 同じことが起きたときに被害を小さくする手だてを一つ決め、担当と期限をつける
• 利用者への最終的な報告が必要か判断する
• このシートの記載を、今回の経験を踏まえて更新する

8. 平時に整えておくこと

障害対応の質は、起きたときの頑張りではなく、平時にどこまで準備してあるかで決まります。特に差が出るのは、止まったことに自分たちで気づけるかどうかです。利用者からの問い合わせで初めて気づく状態が続いているなら、そこが最初に手を入れる場所になります。監視の仕組みは大がかりなものでなくとも、止まったら通知が飛ぶ程度の設定から始められます。開発会社に相談してみてください。

• サービスが止まったときに自動で通知が飛ぶ仕組みがあるか。どこに飛ぶか
• バックアップからの復元を、実際に試したことがあるか
• 各種サービスの契約更新・証明書の期限を、誰かが管理しているか
• 重要なアカウントに、担当者1人しかアクセスできない状態になっていないか
• このシートを、関係者がすぐ取り出せる場所に置いてあるか

9. ご注意

本資料は一般的な情報を整理したものであり、特定の事案についての法的な助言ではありません。個人情報の漏えいが疑われる場合の報告義務や利用者への通知の要否、保守契約における責任や損害の負担の範囲については、事案ごとに判断が異なります。実際の対応にあたっては、弁護士など専門家、および所管の窓口にご確認ください。