SaaS障害告知の書き方｜ステータスページ・更新間隔・復旧後報告の設計
SaaSやWebサービスに障害が起きると、運用チームは復旧作業に集中し、顧客向けのお知らせは後回しになりがちです。しかし利用者が知りたいのは、内部で何が壊れたかだけではありません。自分が影響を受けているのか、待つべきか、別の手段へ切り替えるべきか、いつ次の情報が出るのかを判断できることが重要です。
障害告知は「原因」より先に「影響・代替策・次回更新時刻」を出します。 原因が未確定でも、確認できた症状、影響する機能や利用者、発生または検知時刻、現在の対応、回避策、次回更新予定は伝えられます。初報から復旧まで同じステータスページへ時系列で追記し、技術対応と顧客コミュニケーションの担当を分けると、情報の遅れと矛盾を減らせます。
本記事のポイント
- SaaSの障害初報は原因確定を待たず、影響範囲、利用者が取れる代替策、次回更新時刻を先に伝えます。
- 更新間隔に万能な正解はなく、影響の大きさに合わせて頻度を決め、変化がなくても約束した時刻に状況を更新します。
- 復旧報告はサービスが動いた事実だけで閉じず、影響期間、確認方法、残る制約、事後報告の予定まで残します。
この記事で扱うテーマ
関連キーワード
- SaaS 障害 告知 書き方
- ステータスページ 運用
- システム障害 お知らせ 更新間隔
- 障害 復旧報告 テンプレート
- サービス障害 初報 文例
- インシデント コミュニケーション
このページで答える質問
- SaaSの障害告知には何を書きますか？
- ステータスページはどのくらいの間隔で更新しますか？
- 原因未確定の段階ではどう説明しますか？
- 復旧後の報告には何を残しますか？
この記事の直接回答
SaaSの障害告知には、影響範囲、利用者が見ている症状、発生・検知時刻、対応状況、利用可能な代替策、次回更新時刻を書きます。原因や復旧見込みが分からない段階では推測せず、「何を確認できていて、何を調査中か」を分けます。復旧後は、影響期間、復旧確認方法、残る制約、事後報告の予定を残します。
SaaS障害告知に入れる6項目
初報は長い説明文にする必要はありません。利用者が次の行動を決めるために必要な情報を、確認できた事実だけで短く並べます。根本原因の説明は後から更新できますが、影響範囲や次回更新時刻がない告知は、問い合わせの集中や誤った回避行動を招きます。
| 項目 | 書く内容 | 避けたい書き方 |
|---|---|---|
| 影響範囲 | 影響する機能、地域、契約プラン、利用者の条件 | 「一部で障害」の一文だけで済ませる |
| 症状 | ログイン不可、処理遅延、保存失敗など利用者が確認できる現象 | 内部のエラーコードだけを書く |
| 時刻 | 発生時刻が不明なら検知時刻と調査対象期間 | タイムゾーンを示さない、後から時刻を書き換える |
| 対応状況 | 調査中、原因特定、修正適用、監視中など現在地 | 根拠のない復旧見込みを断定する |
| 代替策 | 安全に使える別機能、再試行条件、避けるべき操作 | 検証していない回避策を案内する |
| 次回更新 | 次に更新する具体的な日時または間隔 | 「進展があり次第」とだけ書く |
Atlassian Statuspageの公式ガイドでも、インシデント作成時に現在の状況を短いメッセージで説明し、影響するコンポーネントを指定する構造になっています。これは単なるツール仕様ではなく、利用者に「自分が影響対象か」を判断してもらうための基本設計です。
障害を検知した時点で影響範囲が分からない場合は、「全利用者に影響」と広げて断定するのではなく、確認済みの範囲と調査中の範囲を分けます。たとえば「管理画面へのログイン失敗を確認しています。APIとデータ保存への影響は調査中です」と書けば、事実と未確認事項が混ざりません。
初報・継続更新・監視・復旧の4段階で書き分ける
ステータスページは、障害が起きたことを一度知らせる掲示板ではありません。同じインシデントの中で、調査中、原因特定、監視中、復旧済みという状態変化を時系列で残します。Atlassian Statuspageでは、状態をInvestigating、Identified、Monitoring、Resolvedの4段階で扱っています。日本語では自社の言葉に置き換えて構いませんが、状態の意味は社内で固定します。
| 段階 | 利用者へ伝えること | 社内で確認すること |
|---|---|---|
| 初報・調査中 | 確認済みの症状、影響範囲、代替策、次回更新 | 担当、指揮系統、影響調査、ログ保全 |
| 原因特定・対応中 | 特定できた範囲、実施中の対処、見込みの確度 | 変更内容、ロールバック、追加影響 |
| 監視中 | 修正済みの内容、利用者側の確認方法、残る制約 | エラー率、遅延、キュー、再発の有無 |
| 復旧済み | 影響期間、現在の状態、必要な再操作、事後報告予定 | 復旧条件の充足、データ整合性、問い合わせ残件 |
更新間隔には、すべての障害へ適用できる法的・技術的な万能値はありません。Atlassianのサポート資料は「30分ごと、または状況に合う間隔」を一例として挙げ、顧客が利用できない状態が続く場合は1時間を超えて更新を空けず、次回更新予定を示すことを勧めています。実務では次のように、影響と変化の速さで運用目標を決めます。
- 広範囲で主要機能が使えない：まず30分を目安にし、状況が安定するまで短い更新を続ける。
- 一部機能に限定され回避策がある：30分から60分を目安にし、次回時刻を毎回明記する。
- 修正後の監視中：監視項目と終了条件を示し、変化がなくても約束した時刻に更新する。
重要なのは、更新のたびに新事実が増えることではありません。「影響範囲に変化はありません」「修正を検証中です」「次回は17時30分に更新します」という報告でも、利用者は対応が継続していると判断できます。逆に更新予定を過ぎると、障害そのものに加えて説明責任への不信が生まれます。
原因未確定でも出せる初報と、断定してはいけない情報
初報を遅らせる最大の理由は、「原因が分からないと何も書けない」という思い込みです。しかし初報の目的は根本原因分析ではなく、利用者が影響を判断して安全に行動できるようにすることです。原因、復旧見込み、データ影響が未確定なら、未確定であることを明示し、確認できている事実と分けます。
初報の文例：「本日16時05分ごろから、管理画面へログインしにくい事象を確認しています。影響する利用者の範囲と原因を調査中です。API経由の処理は現時点で継続しています。復旧までログインの再試行を繰り返さず、次回の更新を16時30分にご確認ください。」
変化がないときの更新例：「影響範囲に変化はなく、管理画面の認証処理を継続して確認しています。原因と復旧見込みはまだ確定していません。次回は17時00分に更新します。」
監視へ移るときの例：「16時48分に修正を適用し、新規ログインの成功率が通常水準へ戻ったことを確認しています。現在は再発と処理遅延を監視中です。ログインできない場合はブラウザを再読み込みせず、17時30分の更新をお待ちください。」
| 未確定事項 | 安全な書き方 | 避ける断定 |
|---|---|---|
| 原因 | 確認済みの症状と調査対象を示す | 証拠のない外部ベンダー原因を公表する |
| 復旧時刻 | 見込みの確度と次回更新時刻を示す | 希望的な時刻を確約する |
| データ影響 | 確認中の範囲と保全措置を示す | 調査前に「漏えいはない」と言い切る |
| 再操作 | 検証済みの操作だけ案内する | 連続再試行や二重送信を促す |
セキュリティ侵害や個人データへの影響が疑われる場合は、通常の可用性障害と同じ文面で断定しません。法務、セキュリティ、個人情報保護の担当を早い段階で加え、通知義務や調査保全と矛盾しない説明にします。NIST SP 800-61 Rev.3は、インシデント対応を検知・対応・復旧だけの技術作業ではなく、組織全体のサイバーリスク管理へ組み込む考え方を示しています。過去事例から点検項目を整理する場合は、主要セキュリティインシデントの事例と教訓も参考になります。
ステータスページと各チャネルの役割を分ける
障害告知をメール、アプリ内表示、サポート返信、SNSへ出す場合も、正本は一つにします。チャネルごとに別の長文を作ると、時刻や影響範囲がずれやすくなります。ステータスページへ時系列を集約し、他のチャネルは対象者へ知らせて正本へ誘導する役割に分けると管理しやすくなります。
| チャネル | 主な役割 | 運用上の注意 |
|---|---|---|
| ステータスページ | 時系列、影響コンポーネント、現在状態の正本 | 本体サービスと同時に停止しない配信経路を持つ |
| メール・通知 | 影響する契約者や管理者へ能動的に知らせる | 更新ごとに通知する対象を絞り、過通知を避ける |
| アプリ内表示 | 影響機能を使う直前に回避策を示す | ログイン不能時には届かない前提を持つ |
| サポート | 個別状況を確認し、共通回答と例外を分ける | ステータスページと同じ時刻・表現を使う |
| SNS | 広範な認知と正本への誘導 | 断片的な説明だけで完結させない |
Google SREのインシデント対応では、指揮を執るIncident Commander、復旧作業を担うOperations Lead、定期更新と問い合わせを担うCommunications Leadを分けています。小規模な組織でも、技術担当が復旧作業と顧客文面を同時に抱えないことが重要です。少なくとも「技術判断」「発信文の作成」「承認」の役割を決めます。
事前準備は次の6ステップで進めます。
- 対象を分ける：主要機能、地域、プラン、連携先をコンポーネントとして定義する。
- 重大度を決める：告知を開始する条件、通知対象、更新間隔の初期値を決める。
- 役割を決める：技術対応、コミュニケーション、承認、問い合わせ対応の担当を置く。
- 文面を用意する：初報、継続更新、監視、復旧、事後報告の雛形を作る。
- 経路を試す：本体停止中でもステータスページ、通知、社内連絡が使えるか確認する。
- 訓練する：原因不明、外部依存、データ影響疑いなど複数の想定で更新を練習する。
監視と通知の経路自体が止まらない設計は、問い合わせフォームの通知漏れを防ぐ監視設計と共通します。また、外部AIサービスの障害で代替モデルへ切り替える場合は、AIモデル障害時の切替と利用者案内の考え方も参考になります。
復旧判定と事後報告に残す内容
エラーが一度消えただけで「復旧済み」にすると、再発時に説明が二転三転します。修正を適用した段階は監視中とし、主要な利用経路、処理待ちのキュー、データ整合性、外部連携、サポート問い合わせを確認してから復旧済みに移します。利用者側で再ログインや再送が必要なら、その操作と二重処理の防止策も案内します。
- 主要機能の成功率と応答時間が通常水準へ戻った。
- 滞留していた処理が解消し、二重実行や欠損がない。
- 複数の地域、プラン、端末、連携経路で確認できた。
- 監視期間中に同じ症状が再発していない。
- 利用者に必要な再操作と残る制約を説明できる。
復旧告知では「復旧しました」だけで閉じず、影響が始まった時刻、復旧確認時刻、影響した機能、必要な再操作、データへの影響、事後報告の予定を書きます。原因分析に時間がかかる場合は、事後報告を出す予定日を伝え、確定していない原因を復旧告知へ混ぜません。
Atlassianはポストモーテムを、影響、緩和・復旧のために取った行動、根本原因、再発防止のフォローアップを記録する文書として整理しています。顧客向けの事後報告は内部版をそのまま公開する必要はありません。個人情報、攻撃に悪用される詳細、契約上の機密を除きながら、利用者が「何が起き、どう直し、何を変えるか」を確認できる内容にします。
| 事後報告の項目 | 顧客向けに残す内容 |
|---|---|
| 概要 | 影響期間、影響機能、利用者が経験した症状 |
| 時系列 | 検知、初報、対応、監視、復旧の主要時刻 |
| 原因 | 確認できた直接原因と背景。未確定なら調査継続を明記 |
| 対応 | 影響を抑え、復旧するために実施したこと |
| 再発防止 | 具体的な改善策と、完了を確認できる状態 |
| 残る影響 | 再操作、データ確認、問い合わせが必要な条件 |
責任ある説明は、障害の原因となった個人や外部ベンダーを責めることではありません。利用者への影響を自社サービスの問題として受け止め、確認できた事実、対応、改善を一貫して示します。より広い危機対応の体制は危機管理広報の基本設計でも整理しています。
公開資料
- Google SRE Workbook: Incident Response：指揮、技術対応、コミュニケーションを分け、定期更新を行う役割設計を確認できます。
- Atlassian Statuspage: Incident communication tips：早期・継続・明確・一貫した障害コミュニケーションの原則を確認できます。
- Atlassian Statuspage: Create an incident：調査中、原因特定、監視中、復旧済みの状態と影響コンポーネントの扱いを確認できます。
- Atlassian: Incident communication best practices：顧客向けの更新間隔、次回更新時刻、事前テンプレートの考え方を確認できます。
- Atlassian: Incident postmortems：影響、対応、原因、再発防止を残す事後報告の構成を確認できます。
- NIST SP 800-61 Rev.3：インシデント対応を組織のサイバーリスク管理へ統合する現行勧告です。
よくある質問
SaaSの障害告知には何を書きますか？
影響する機能や利用者、確認できた症状、発生または検知時刻、現在の対応、検証済みの代替策、次回更新時刻を書きます。原因と復旧見込みは、確度が低い段階で断定しません。
ステータスページはどのくらいの間隔で更新しますか？
すべての障害に共通する間隔はありません。主要機能が広く使えない場合は30分を初期目安とし、影響が限定的で回避策がある場合は30分から60分を目安にします。どの間隔でも次回更新時刻を示し、変化がなくても約束した時刻に更新します。
原因未確定の段階ではどう説明しますか？
確認済みの症状と影響範囲、調査中の範囲を分けて書きます。「原因は調査中です」だけで終わらず、利用者が取れる行動と次回更新時刻を伝えます。外部ベンダー原因やデータ漏えいの有無は、証拠がそろう前に断定しません。
ステータスページとメールは両方必要ですか？
役割が異なります。ステータスページは時系列と現在状態の正本、メールやアプリ内通知は影響する利用者へ能動的に知らせる手段です。複数チャネルを使う場合も、詳しい内容は一つの正本へ集約します。
いつ「復旧済み」と判断しますか？
修正適用後に主要機能の成功率、処理待ち、データ整合性、外部連携を確認し、一定の監視期間で再発がないと確認してから復旧済みにします。利用者側の再操作が必要なら、その案内も復旧条件に含めます。
復旧後の報告には何を残しますか？
影響期間、影響した機能と利用者、主要な時系列、確認できた原因、復旧のために行ったこと、残る影響、再発防止策を残します。原因が未確定なら、事後報告の予定日と調査継続を明記します。
まとめ
SaaSの障害告知は、原因説明の完成を待つ文書ではありません。利用者が影響を判断し、誤った再操作を避け、次の情報を待てるようにする運用です。初報では影響、症状、時刻、対応、代替策、次回更新を示し、その後も同じ時系列で状態を更新します。
技術復旧と顧客コミュニケーションを分担し、ステータスページを正本として各チャネルを揃えます。復旧後は影響期間と残る制約を明示し、事後報告で対応と改善策を残してください。平常時に状態定義、役割、テンプレート、通知経路を試しておくことが、障害時の速さと信頼を両立させます。
