ダウンタイム通知メール文例5種｜クライアントへの第一報テンプレート

「第一報」を送らないと、クレームが倍になる

クライアントのサイトがダウンしたとき、最初にやるべきことは復旧作業と並行して「第一報を送ること」です。

多くの制作会社が「復旧してから一緒に報告しよう」と考えますが、これは逆効果です。クライアントはサイトが落ちていることに気づいているか、顧客からの問い合わせが既に届いている可能性があります。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）

株式会社△△

パターンD：復旧報告

復旧報告は、制作会社がもっとも省略しがちな連絡です。サイトが戻れば緊張が解けるためですが、省略は禁物です。クライアント側はまだ画面を更新しながら「本当に直ったのか」を確かめています。障害報告書を書き終えてからではなく、監視が復旧を確認した時点で送ってください。

件名: 【復旧完了】○○様サイト 復旧のご連絡（XX/XX XX:XX）

○○株式会社
○○様

お世話になっております。株式会社△△の◇◇です。

XX:XX に御社サイトの復旧を確認いたしました。
弊社監視システムにて正常稼働を確認しております。

【障害概要】
・ダウン検知: XX:XX
・復旧確認: XX:XX
・ダウンタイム: 約XX分
・原因: （一文で平易に。例「Webサーバーのメモリ不足」）

現在、詳細な調査を進めております。原因と再発防止策を
まとめた報告書を XX/XX XX:XX までにお送りいたします。

ご不便をおかけし、誠に申し訳ございませんでした。

担当: ◇◇（直通: 000-0000-0000）

株式会社△△

復旧時刻は「自分がサイトを開けた時刻」ではなく、監視履歴から正確に取得してください。

# 直近インシデントの復旧時刻とダウンタイムを確認
curl -s "https://miterl.com/api/v1/incidents?monitor_id=YOUR_MONITOR_ID" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[0] | {started_at, resolved_at, duration_seconds}'

パターンE：長期化・SLA影響が出る場合

復旧が長引き、稼働率の保証値に影響が出そうなときに使います。この局面では「良い報告ができるまで黙る」という判断をしがちですが、まさにそのタイミングでクライアントから電話が来ます。SLAへの影響を指摘される前に自分から触れることで、会話の主導権を保てます。

件名: 【障害継続・第3報】○○様サイト 現状と今後の対応について

○○株式会社
○○様

お世話になっております。株式会社△△の◇◇です。

御社サイトのダウンが約X時間継続しております。
現時点の状況を正確にご報告いたします。

【現状】
・稼働状況: （どこまで復旧し、どこが未復旧か）
・判明している原因: （分かっていること）
・未確定の点: （まだ分かっていないことを明示）
・実施中の対応: （いま動かしている作業）
・エスカレーション: （ホスティング事業者への問い合わせ番号、
  上位エンジニアの参画状況など）

【SLAへの影響】
本障害により、今月の稼働率保証のうち約X%を消費する見込みです。
正式な取り扱いは復旧後の報告書にてご相談させてください。

次回ご報告: XX:XX（60分以内）

担当: ◇◇（直通: 000-0000-0000）

株式会社△△

この文面の信頼性は「まだ分かっていないこと」を書いている点から生まれます。数時間の障害中に完全に掌握しているかのような報告はかえって不誠実に映り、未確定の論点を挙げるほうが誠実に伝わります。稼働率の計算方法は稼働率99.9%は何分のダウンタイムか、SLAから除外できる範囲はメンテナンスウィンドウの設計と告知のベストプラクティスで解説しています。

Slack・Chatworkへ同じ内容を流す場合

クライアントと共有チャンネルを運用している場合、メールと併用することが多くなります。チャンネル版はメールの貼り付けではなく、スマホのロック画面で読み切れる長さにします。

🔴 ○○様サイト ダウン検知 14:12
調査を開始しました。次報 14:45 までに。
担当: ◇◇（000-0000-0000）

🟢 ○○様サイト 復旧 14:38（ダウンタイム26分）
原因: Webサーバーのメモリ不足。詳細報告は明日12:00までに。

チャンネルに流す場合でも、記録として残すのはメールにしてください。数か月後の契約更新の場で参照するのはメールのスレッドです。検知と同時にチャンネルへ自動通知する設定はSlackとChatworkに監視アラートを飛ばす設定で解説しています。

第一報を送るタイミング

自動監視ツールを使っていれば、検知と同時にSlackやメールでアラートを受け取れます。アラートを受け取った時点でテンプレートをコピーして送信することで、15分以内の連絡が現実的になります。

Miterlでは、監視がダウンを検知した瞬間にメール・Slack・Chatworkへアラートを送信します。深夜でも自動で気づける体制が、第一報の速度を大きく左右します。

第一報のよくある失敗パターン

第一報から最終報告への流れ

第一報は「発生の通知」にすぎません。復旧後は詳細な障害報告書（最終報告）を送付します。

第一報（検知から15分以内）
  ↓
進捗連絡（長期化する場合、30〜60分ごと）
  ↓
復旧連絡（復旧直後）
  ↓
障害報告書（復旧から24時間以内）

障害報告書には、原因・対応時系列・再発防止策を詳細に記載します。テンプレートはクライアント向け障害報告書の書き方とテンプレートをご覧ください。

障害対応フロー全体についてはインシデント対応フローの完全ガイドで解説しています。

Miterlで第一報の速度を上げる

自動監視なしでは、ダウンの検知自体が遅れます。クライアントから「サイトが見られない」と連絡が来て初めて気づく状況では、第一報は常に遅くなります。

Miterlを使うと以下が可能です。

• 1分間隔での監視: ダウンを最短1分で検知
• 即時アラート: 検知と同時にメール・Slack・Chatworkへ通知
• APIでの時刻取得: 第一報に使う検知時刻をAPIから正確に取得

保守契約に監視を組み込む方法については保守契約に監視を組み込む料金設計ガイドをご覧ください。

Miterl を無料で試す

よくある質問

サイトダウン後、どのくらいで第一報を送るべきですか？

営業時間内であれば検知から15分以内が目安です。ただしこの水準は自動監視が前提で、人が気づいてから動く運用では検知の遅れだけで15分を使い切ります。深夜に発生して既に復旧している場合は、翌営業日の始業後1時間以内に送ります。

原因が分からない段階でも連絡すべきですか？

送るべきです。第一報の役割は原因の説明ではなく「把握しており対応中である」ことを伝えることです。原因不明の状況を想定したのが上記のパターンAです。原因が判明するまで待つと、その間クライアントは「まだ気づいていない」と受け取ります。

クライアントが気づいていない短時間のダウンでも復旧報告は必要ですか？

必要です。2分程度のダウンでも自分から報告すれば「監視が効いている」という信頼につながりますが、後日の報告書で初めて知らされると「隠していたのでは」と受け取られます。パターンDの形式なら1分で送れます。

第一報で謝罪は入れるべきですか？

入れますが、冒頭には置きません。まず現在実施している対応を伝え、そのうえで簡潔に謝罪します。謝罪から始まって対応内容が書かれていないメールは受け身に映り、クライアントが次にどう動けばよいか分かりません。これは失敗パターン表にある最も多い誤りです。

原因がホスティング事業者側にある場合はどう書きますか？

事業者名と問い合わせ番号は明記しますが、責任転嫁の材料には使いません。クライアントが契約しているのはホスティング事業者ではなく自社です。パターンEの「エスカレーション」欄は、ベンダーを動かしつつ結果責任は自社が持つ姿勢を示すために設けています。

障害中の連絡は何回まで送ってよいですか？

障害が続いている間は30〜60分ごと、かつ前回の連絡で約束した時刻には必ず送ります。約束した連絡時刻を守らないことは、障害そのものより信頼を損ないます。「進展なし、次報XX:XX」という内容であっても、沈黙よりはるかに良い対応です。

まとめ

クライアントへの第一報は、「原因がわかってから」では遅すぎます。検知から15分以内に「把握して対応中」の一報を送ることで、クレームリスクを大きく下げられます。

• 第一報は短文でよい。速度が最優先
• 「現在の状況」「次の連絡タイミング」「連絡先」の3点を必ず含める
• 原因不明でも「調査中」と明示することで不安を和らげられる
• 原因不明ならパターンA、判明後はパターンB、深夜検知はパターンC、復旧時はパターンD、SLA影響が出る長期化ではパターンEを使い分ける
• 復旧報告（パターンD）を省略しない。もっとも省略されがちだが、対応を締めくくる連絡である
• 復旧後は詳細な障害報告書を24時間以内に送付する

詳しい監視設定や通知の設定方法はドキュメントをご覧ください。制作会社の監視活用事例についてはユースケースページもあわせて参考にしてください。

クライアントへの通知メールのテンプレートが整ったら、「誰にいつ通知するか」というエスカレーションの設計も固めておきましょう。軽微な障害をすべて担当者に転送すると対応疲れが起きますが、重大障害を見逃すと信頼を損ないます。アラートの深刻度別に担当者・上長・クライアントへの連絡タイミングを整理した「監視アラートのエスカレーション設計ガイド」で通知ポリシー全体を設計してください。