クライアント向け障害報告書の書き方とテンプレート｜Web制作会社の実務

障害報告書を出すのが怖い制作会社へ

障害が起きたとき、「どう報告するか」に頭を抱える制作会社は少なくありません。「正直に書いたらクレームになるのでは」「どこまで書けばいい？」という不安があると、報告書の作成が後回しになりがちです。

しかし、誠実な障害報告書こそが信頼を回復する最大の武器です。「隠さず、正確に、再発防止策とともに報告する」姿勢が、長期的な関係継続につながります。

この記事では、クライアントに提出する障害報告書の構成と、コピペで使えるテンプレートを紹介します。

障害報告書に含める6つの要素

良い障害報告書は、クライアントが「何が起きたのか・なぜ起きたのか・今後は大丈夫か」を読んで理解できるものです。以下の6項目をカバーしましょう。

1. 発生・復旧の日時とダウンタイム

数字で明示します。Miterlのインシデント履歴を使えば正確な時刻が取得できます。

# 対象モニターのインシデント履歴をAPI取得（モニターIDで絞り込み）
curl -s "https://miterl.com/api/v1/incidents?monitor_id=1" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '[.data[] | {原因: .cause, 発生時刻: .started_at,
    復旧時刻: .resolved_at, ダウン時間_秒: .duration_seconds}]'

2. 影響範囲

どのページやサービスが影響を受けたかを具体的に書きます。「サイト全体」ではなく「TOPページへのアクセス不能、問い合わせフォームは別サーバーのため影響なし」のように粒度を持って記述します。

3. 原因（技術的な内容をかみ砕いて）

「サーバーエラー」だけでは不十分です。「Webサーバーのメモリ使用量が上限に達し、新規リクエストを処理できなくなった」のように、技術者でないクライアントにも伝わる言葉で説明します。

4. 対応内容（時系列）

「何時に何をしたか」を時系列で記録します。「対応中でした」ではなく、具体的なアクションを列挙することが重要です。

5. 再発防止策

ここが最も重要です。「気をつけます」ではなく、「〇月〇日までにメモリ監視の閾値を設定する」のように具体的な内容と期日を示します。

6. 次回の報告予定

再発防止策の実施後に「確認報告」を行う旨を明記しておくと、クライアントの不安が和らぎます。

コピペで使えるテンプレート

以下のテンプレートをそのままコピーして使ってください。

件名: 【障害報告】○○様サイト 障害発生と対応のご報告

○○株式会社
○○様

平素よりお世話になっております。株式会社△△の◇◇です。
このたびは御社サイトに障害が発生し、ご迷惑をおかけいたしました。
改めて状況と対応内容をご報告いたします。

━━━━━━━━━━━━━━━━━━━━
障害概要
━━━━━━━━━━━━━━━━━━━━
・発生日時: 2026年X月X日 XX:XX
・復旧日時: 2026年X月X日 XX:XX
・ダウンタイム: 約X時間X分
・影響範囲: （例）サイト全ページへのアクセス不能

━━━━━━━━━━━━━━━━━━━━
原因
━━━━━━━━━━━━━━━━━━━━
（例）Webサーバーのメモリ使用量が上限に達したため、
新規リクエストの処理ができなくなりました。

━━━━━━━━━━━━━━━━━━━━
対応内容
━━━━━━━━━━━━━━━━━━━━
XX:XX 自動監視ツールにより障害を検知
XX:XX 御社への第一報をお送りいたしました
XX:XX サーバープロセスを再起動し、正常稼働を確認
XX:XX サイトの表示・動作確認を実施、復旧を確認

━━━━━━━━━━━━━━━━━━━━
再発防止策
━━━━━━━━━━━━━━━━━━━━
・メモリ使用量の監視閾値を設定し、80%超過で自動アラートを受け取る設定を追加（〇月〇日実施予定）
・月次でサーバーリソース使用状況のレポートを確認する運用フローを整備（〇月〇日~）

━━━━━━━━━━━━━━━━━━━━
今後について
━━━━━━━━━━━━━━━━━━━━
再発防止策の実施後、〇月〇日頃に確認報告をお送りいたします。
引き続きご迷惑をおかけしないよう努めてまいります。
何かご不明な点があれば、お気軽にご連絡ください。

株式会社△△
◇◇

報告書作成を効率化するツール活用

障害発生時はMiterlのダッシュボードで対応ログを確認しながら報告書を作成できます。稼働率データの取得もAPIで自動化しておくと、月次報告の負担を大きく削減できます。

報告書作成のよくある失敗パターン

報告書を書く際に避けたい失敗を整理します。

ツールで報告書作成を半自動化する

稼働率・ダウンタイムのデータはMiterl APIで取得し、テンプレートに直接貼り付けられます。手作業でのログ確認を省略できるため、復旧後1時間以内の報告送付も現実的です。

障害対応フロー全体の整備についてはインシデント対応フローの完全ガイドも参考にしてください。ステータスページと組み合わせれば、障害中の問い合わせを大幅に削減することもできます。クライアント向けステータスページの活用法もあわせてご覧ください。

まとめ

良い障害報告書は、「何が起きたか・なぜ起きたか・今後はどうするか」の3点を誠実に伝えるものです。このテンプレートを活用して、報告書の作成に迷う時間を「次の対策を考える時間」に使いましょう。

• ダウンタイムは分単位で明示する
• 原因は技術者でない人にも伝わる言葉で書く
• 再発防止策は「いつまでに何をするか」を具体的に書く
• 再発防止後に確認報告の予定を明記する

詳しい機能はドキュメントで確認できます。監視の導入から障害対応までの活用事例はユースケースページをご覧ください。