障害報告の第一報の書き方（テンプレート付き）：事実と推測を分ける

第一報は「分かっていること・影響・対応中のこと・次はいつ」を早く出す。

第一報は「早く・短く・正確に」

障害（サービスが止まる、遅くなる、誤った結果を返すなど、本来の動きができない状態）が起きたとき、最初に関係者へ送る報告を第一報と呼びます。第一報の目的は、原因を説明することではありません。関係者が状況を知り、自分の判断や行動（問い合わせ対応、作業の中断、上長への連絡など）を始められるようにすることです。

そのため、原因が分かるまで報告を待つのは逆効果になりがちです。利用者からの問い合わせや社内の別チームの気づきが先行すると、情報が錯綜し、確認の連絡が担当者に集中して調査が遅れます。分かっていることだけで構わないので早く出し、続報で情報を足していくのが基本です。Google の SRE（Site Reliability Engineering）の資料でも、障害対応では情報共有の役割を明確にし、定期的に状況を伝えることが重視されています。

第一報に入れる 4 つの要素

見落とされやすいのは次回報告の時刻です。「分かり次第ご連絡します」と書くと、受け手はいつまで待てばよいか分からず、何度も問い合わせることになります。進展がなくても「11:00 時点で原因は調査中です。次は 12:00 に報告します」と時刻どおりに出せば、受け手は安心して待てます。発生時刻と報告時刻は、タイムゾーンが混ざる組織では JST などと明記すると誤読を防げます。

よくある不足：件名と本文で分かることが少ない

「障害のご報告」という件名だけでは、どのサービスの話なのか、いま続いているのかが分かりません。件名に「第一報」「サービス名」「事象」「発生時刻」を入れると、通知の一覧を見ただけで状況がつかめます。本文でも、原因の説明に字数を使って影響範囲や次回報告が抜けている報告はよく見られます。受け手が最初に知りたいのは「自分に関係があるか」と「いつまた情報が来るか」です。

第一報のテンプレート

次のテンプレートは、社内向けの第一報を想定した穴埋め式のひな形です。【】の部分を埋め、分からない項目は空欄にせず「調査中」と書きます。

件名：【障害・第一報】【サービス名】【事象の一言】（【発生日時】〜）■ 状況（確認済みの事実）・発生時刻：【YYYY-MM-DD HH:MM】頃から（【検知の方法：監視アラート / 問い合わせ など】）・事象：【何が起きているか。例：注文確定時に 500 エラーになる】・現在の状態：【継続中 / 断続的 / 復旧済み】■ 影響範囲・対象：【全利用者 / 一部（条件）】・できないこと：【例：注文の確定】・できること：【例：閲覧、ログイン】・データへの影響：【なし（確認済み） / 調査中】■ 暫定対応・【実施中の対応。例：10:20 から直前のリリースを切り戻し中】・利用者へのお願い：【例：時間をおいて再度お試しください】■ 原因・調査中（【可能性として見ている点があれば「可能性」と明記】）■ 次回報告・【HH:MM】までに続報を出します（進展がなくても状況を報告します）■ 連絡先・対応責任者：【氏名】 / 問い合わせ先：【チャンネル名 など】

推測と事実を書き分ける

障害の初期は情報が少なく、「たぶんこれが原因だろう」という見立てを書きたくなります。しかし、推測を事実のように書くと、受け手はそれを前提に動きます。あとで原因が違うと分かれば、訂正の手間が増え、報告全体の信頼も下がります。確認したことと、まだ確認していないことは、言葉で区別します。

原因は DB の負荷です。データの消失はありません。まもなく復旧します。

DB の CPU 使用率が 10:03 から 95% を超えていることを確認しました。障害との関係は調査中です。注文テーブルの件数は発生前と一致しており、現時点でデータの消失は確認されていません。切り戻しの完了は 10:40 頃の見込みです。完了後に動作を確認して報告します。

「〜を確認しました」「〜は確認されていません」「〜の可能性があり調査中です」「〜の見込みです」のように、文末で確度を表すと読み手が誤解しにくくなります。復旧時刻の見込みを書く場合は、根拠（切り戻しにかかる時間など）がある範囲にとどめます。根拠のない「まもなく」は、外れたときに不信感を招きます。

顧客向けと社内向けの違い

同じ障害でも、読み手によって必要な情報は異なります。社内向けの報告は、調査や判断をする人のために、エラーの内容、関係するサーバーやリリース、実施中の作業などの技術的な情報を含めます。顧客向けの報告は、利用者が自分に関係があるか、何をすればよいかを判断できることが中心です。内部のサーバー名や担当者名、未確定の原因は書かず、専門用語は言い換えます。

第一報から続報、復旧報までの流れ

第一報は一連の報告の始まりにすぎません。障害対応では、状況が変わるたびに続報を出し、復旧したら復旧報を、落ち着いたら原因と再発防止策をまとめた報告（ポストモーテムなど）を出すのが一般的な流れです。続報では、前回からの変化を先頭に書くと、読み手は差分だけを追えます。

1. 検知：監視アラートや問い合わせで異常に気づき、影響を手早く確かめる
2. 第一報：事実・影響範囲・暫定対応・次回報告の時刻を出す
3. 続報：約束した時刻ごとに、前回からの変化と次回報告の時刻を出す
4. 復旧報：復旧した時刻、復旧を確認した方法、残っている影響（後続処理の遅れなど）を出す
5. 事後報告：原因、時系列、再発防止策をまとめる。個人の責任追及ではなく仕組みの改善に焦点を当てる

復旧報で「復旧しました」とだけ書くと、本当に直ったのか、データの整合は取れているのかが読み手には分かりません。「11:32 に切り戻しが完了し、11:40 に注文が正常に確定できることを確認しました。障害中に失敗した注文は自動では再送されないため、該当の利用者には個別に連絡します」のように、確認した方法と残る影響まで書くと、受け手は次の行動を決められます。

訂正の出し方

急いで出す第一報には、誤りが入ることがあります。気づいたら、すぐに訂正を出します。チャットのメッセージを編集して直すだけでは、すでに読んだ人は変更に気づきません。元の報告はそのまま残し（必要なら「訂正あり」と追記し）、新しいメッセージとして訂正を出します。

【訂正】10:15 の第一報で「影響は一部の利用者」と書きましたが、誤りでした。正しくは「全利用者の注文が不可」です。第一報をもとに問い合わせ対応をされた方は、回答内容の見直しをお願いします。その他の内容に変更はありません。次回報告は予定どおり 11:00 です。

訂正には、何が誤りだったか、正しくは何か、誤った情報に従って動いた人への影響と対処の 3 つを入れます。誤った手順やコマンドを共有していて、すでに実行した人がいるかもしれない場合は、冒頭に「実行しないでください」「実行した方は連絡してください」と書き、最も急ぐ情報を最初に読めるようにします。

第一報を送る前のチェックリスト

• 発生時刻、事象、現在の状態が書かれているか
• 影響範囲（誰が、何ができないか、何はできるか）が書かれているか
• データへの影響について、確認済みか調査中かが分かるか
• 実施中の暫定対応と、利用者に取ってほしい行動が書かれているか
• 次回報告の時刻が「分かり次第」ではなく時刻で書かれているか
• 推測を事実のように書いていないか（「可能性」「調査中」を付けているか）
• 顧客向けの文面に、内部のサーバー名や未確定の原因が入っていないか
• 宛先と送信先チャンネルは正しいか、連絡先が書かれているか

参考

• Google SRE Book: Managing Incidents
• Google SRE Workbook: Incident Response
• Google SRE Book: Postmortem Culture