ダウンタイム通知メールの書き方——クライアントへの第一報テンプレート
「第一報」を送らないと、クレームが倍になる
クライアントのサイトがダウンしたとき、最初にやるべきことは復旧作業と並行して「第一報を送ること」です。
多くの制作会社が「復旧してから一緒に報告しよう」と考えますが、これは逆効果です。クライアントはサイトが落ちていることに気づいているか、顧客からの問い合わせが既に届いている可能性があります。30分の沈黙は「対応していない」と受け取られ、クレームのリスクが高まります。
第一報の目的は「状況の共有」であり、「解決策の提示」ではありません。 「把握しており、対応中である」を伝えるだけで十分です。
この記事では、障害発生直後に送る第一報メールの書き方と、コピペで使えるテンプレートを紹介します。障害報告書（最終報告）のテンプレートはクライアント向け障害報告書の書き方とテンプレートを参照してください。
第一報メールの5つの要素
第一報は短くて構いません。長文を書く時間があれば、その時間を復旧作業に充てるべきです。ただし、以下の5要素は必ず含めてください。
1. 件名：すぐに重要性が伝わる形式
件名は「何が起きているか」を一目でわかるようにします。
【障害発生・対応中】○○様サイト ダウン検知のご連絡
「緊急」「重要」などの感情的な言葉より、「対応中」という状態を示す言葉の方が安心感を与えます。
2. 検知日時
「いつから対応しているか」が伝わることで、クライアントは「気づいた時点で動いていた」と理解できます。自動監視ツールがあれば、検知から第一報送付までの時間を短くできます。
# 検知時刻はMiterlのAPI から取得可能
curl -s "https://miterl.com/api/v1/incidents?monitor_id=YOUR_MONITOR_ID" \
-H "Authorization: Bearer YOUR_API_KEY" | \
jq '.data[0] | {started_at: .started_at, cause: .cause}'
3. 現在の状況（一文で）
「対応中」「原因調査中」など、現時点の状態を一文で伝えます。原因が特定できていなくても、「調査中」であることを明示します。
4. 次の連絡タイミング
「30分後に進捗をご連絡します」のように、次の報告タイミングを伝えることで、クライアントの不安を和らげます。
5. 連絡先
担当者の直通連絡先を記載します。クライアントが疑問を持ったときにすぐ連絡できる体制を示すことが重要です。
コピペで使える第一報テンプレート
パターンA：原因不明の段階（最も使う場面）
件名: 【障害発生・対応中】○○様サイト ダウン検知のご連絡
○○株式会社
○○様
お世話になっております。株式会社△△の◇◇です。
本日 XX:XX 頃、御社サイト（https://example.com）のダウンを
弊社監視システムにて検知いたしました。
現在、原因の調査と復旧作業を進めております。
詳細が判明次第、改めてご連絡いたします。
次回ご報告: XX:XX 頃（約30分後）を予定しております。
お急ぎの場合は下記へご連絡ください。
担当: ◇◇（直通: 000-0000-0000）
引き続き対応を進めてまいります。
株式会社△△
パターンB：原因が判明している場合
件名: 【障害発生・復旧作業中】○○様サイト 障害発生のご連絡
○○株式会社
○○様
お世話になっております。株式会社△△の◇◇です。
本日 XX:XX 頃、御社サイト（https://example.com）のダウンを
弊社監視システムにて検知いたしました。
【現在の状況】
・発生時刻: XX:XX
・原因: （例）サーバーのメモリ使用量が上限に達し、
新規リクエストの処理ができない状態です
・対応状況: 復旧作業を実施中です
次回ご報告: XX:XX 頃（約XX分後）を予定しております。
復旧が完了した時点でも、速やかにご連絡いたします。
担当: ◇◇（直通: 000-0000-0000）
株式会社△△
パターンC：深夜・早朝に検知された場合
件名: 【深夜障害発生】○○様サイト ダウン検知のご連絡（XX/XX XX:XX）
○○株式会社
○○様
お世話になっております。株式会社△△の◇◇です。
昨夜（本日）XX:XX 頃、御社サイトにダウンが発生していたことを
弊社監視システムのログで確認いたしました。
【確認状況】
・ダウン検知: XX:XX
・復旧確認: XX:XX（ダウンタイム: 約XX分）
・現在の状態: 正常稼働中
本日 XX:XX 以降に改めて詳細をご報告いたします。
詳細報告書（原因・対応内容・再発防止策）は
本日中にお送りいたします。
担当: ◇◇（直通: 000-0000-0000）
株式会社△△
第一報を送るタイミング
| 状況 | 目安 |
|---|---|
| 営業時間内にダウンを検知 | 検知から15分以内 |
| 深夜・早朝にダウンを検知 | 翌朝の始業後1時間以内 |
| 復旧が長引いている場合 | 30〜60分ごとに進捗連絡 |
自動監視ツールを使っていれば、検知と同時にSlackやメールでアラートを受け取れます。アラートを受け取った時点でテンプレートをコピーして送信することで、15分以内の連絡が現実的になります。
Miterlでは、監視がダウンを検知した瞬間にメール・Slack・Chatworkへアラートを送信します。深夜でも自動で気づける体制が、第一報の速度を大きく左右します。
第一報のよくある失敗パターン
| 失敗パターン | 問題点 | 改善策 |
|---|---|---|
| 第一報を送らず復旧報告だけ送る | クライアントが「何も連絡がなかった」と感じる | 復旧前に必ず第一報を送る |
| 原因不明なのに謝罪だけする | 「何をしているかわからない」と不安が増す | 現状と次のアクションを伝える |
| 「確認します」だけで次の連絡時間を明示しない | クライアントが不安で頻繁に連絡してくる | 「XX分後に連絡」を必ず入れる |
| 長文の第一報を書こうとして遅れる | 遅れるほどクレームリスクが高まる | 短文でよい、速度を優先する |
第一報から最終報告への流れ
第一報は「発生の通知」にすぎません。復旧後は詳細な障害報告書（最終報告）を送付します。
第一報（検知から15分以内）
↓
進捗連絡（長期化する場合、30〜60分ごと）
↓
復旧連絡（復旧直後）
↓
障害報告書（復旧から24時間以内）
障害報告書には、原因・対応時系列・再発防止策を詳細に記載します。テンプレートはクライアント向け障害報告書の書き方とテンプレートをご覧ください。
障害対応フロー全体についてはインシデント対応フローの完全ガイドで解説しています。
Miterlで第一報の速度を上げる
自動監視なしでは、ダウンの検知自体が遅れます。クライアントから「サイトが見られない」と連絡が来て初めて気づく状況では、第一報は常に遅くなります。
Miterlを使うと以下が可能です。
- 1分間隔での監視: ダウンを最短1分で検知
- 即時アラート: 検知と同時にメール・Slack・Chatworkへ通知
- APIでの時刻取得: 第一報に使う検知時刻をAPIから正確に取得
保守契約に監視を組み込む方法については保守契約に監視を組み込む料金設計ガイドをご覧ください。
まとめ
クライアントへの第一報は、「原因がわかってから」では遅すぎます。検知から15分以内に「把握して対応中」の一報を送ることで、クレームリスクを大きく下げられます。
- 第一報は短文でよい。速度が最優先
- 「現在の状況」「次の連絡タイミング」「連絡先」の3点を必ず含める
- 原因不明でも「調査中」と明示することで不安を和らげられる
- 復旧後は詳細な障害報告書を24時間以内に送付する
詳しい監視設定や通知の設定方法はドキュメントをご覧ください。制作会社の監視活用事例についてはユースケースページもあわせて参考にしてください。