システム障害のお知らせ文の書き方｜顧客向け連絡の構成と例文

システム障害のお知らせ文は、「一次連絡」「続報」「復旧報告」の3段階に分け、各段階で書く項目を決めておけば、慌てた状況でも短時間で書き上げられます。最初の連絡では原因を断定せず、わかっている事実と次の連絡時刻を伝えることが最優先です。

この記事では、顧客向けの障害連絡を担当する運用・カスタマーサポート担当者に向けて、各段階に入れる項目、そのまま使える例文、避けたい表現、社内承認の流れを整理します。例文は架空のサービス「クラウド勤怠管理サービス」を題材にしており、自社の状況に合わせて書き換えられるように、文面そのものを本文内で示します。

障害連絡の基本

障害連絡の基本は、顧客が「自分は何をすればよいか」と「次にいつ情報が届くか」を判断できる状態をつくることです。

目的

障害連絡の目的は、原因の説明よりも先に、顧客の業務への影響を最小限にすることにあります。顧客が知りたいのは、いま使えるのか、いつ戻るのか、自分側で対処すべきことはあるのかの3点です。原因の詳細や社内の事情は、この3点に答えたあとで十分です。

連絡を段階に分ける理由は、障害の状況が時間とともに変わるためです。発生直後は原因も復旧時刻もわからないのが普通なので、最初から完全な文面を目指すと発信が遅れます。「わかっていることだけを早く、わからないことは次回の連絡時刻とあわせて正直に」という姿勢が、結果として顧客の信頼を保ちます。障害の重大度に応じてどこまで連絡するかを決めたい場合は、システム障害のレベル（重大度）定義の考え方が参考になります。

書き手の役割

お知らせ文の書き手は、技術的な事実を顧客にわかる言葉へ翻訳する役割を担います。復旧作業をしている技術担当は、状況を正確に把握している一方で、顧客向けの言葉づかいまで手が回りません。そこで運用・サポート担当が、技術担当から事実を聞き取り、顧客目線の文面に整えます。

外部のコンサルタントやPMOが障害対応の支援に入る場合も、役割の線引きは同じです。業務委託の案件は準委任契約が中心で、案件の7〜8割程度とされています（ドメイン知識ベース「業務委託契約の形態」、出典はコンサルチョイス）。準委任は業務の遂行に対して報酬が支払われる形態のため、外部の支援者は文案の作成や整理を手伝えても、顧客に何を約束するかの最終判断は発注側の責任者が持つのが基本です。契約上の責任範囲に関わる個別の判断は、弁護士などの専門家に相談してください。

一次連絡

一次連絡は、障害を認識してから30分以内を目安に、事実だけを短く伝える連絡です。

入れる項目

一次連絡に入れる項目は、発生時刻、影響範囲、現在の状況、お客様への依頼事項、次回連絡の予定時刻の5つです。

発生時刻：障害に気づいた時刻ではなく、影響が出始めた時刻を書きます。不明なときは「午前9時ごろから」のように幅を持たせます。
影響範囲：どの機能が、どの顧客に影響しているかを書きます。全機能が止まっているのか、一部のみかで、顧客の動き方が変わります。
現在の状況：「原因を調査中です」で構いません。調査中であることを明示するだけでも、放置されていない安心感につながります。
お客様への依頼事項：再ログインを控える、データ入力を一時保留する、など顧客側で必要な行動を書きます。特にない場合は「現時点でお客様に必要な対応はありません」と明記します。
次回連絡の予定時刻：状況が変わっていなくても、その時刻には必ず連絡します。

編集部が実務経験者の話を聞く中では、5項目のうち最も抜けやすいのが「次回連絡の予定時刻」だという指摘が目立ちます。復旧の見通しが立たないときほど書きにくいのですが、「30分後に状況をお知らせします」だけでも、顧客は問い合わせを控えて待つ判断ができ、サポート窓口への集中も和らぎます。

例文

一次連絡の例文は、次のとおりです。件名で障害であることと対象サービスがわかるようにし、本文は5項目を順に並べます。

件名：【障害発生のお知らせ】クラウド勤怠管理サービスにアクセスしづらい状況について
平素より当サービスをご利用いただき、ありがとうございます。
本日10月8日午前9時10分ごろから、クラウド勤怠管理サービスにログインしづらい状況が発生しております。ご利用の皆さまにはご不便をおかけし、申し訳ございません。
影響範囲：ログインおよび打刻機能。勤怠データの閲覧は一部可能です。
現在の状況：原因を調査中です。
お客様へのお願い：お手数ですが、ログインを繰り返し試行することはお控えください。
次回のご連絡：午前10時までに、状況をあらためてお知らせします。
クラウド勤怠管理サービスサポート窓口

この例文では、原因について「調査中」とだけ書き、推測を含めていません。「サーバーの不具合と思われます」のような推測は、あとで違っていたときに訂正の連絡が必要になるため、一次連絡では避けます。

続報

続報は、状況が変わったとき、または約束した時刻が来たときに、変化の有無を含めて伝える連絡です。

更新の頻度

続報の頻度は、一次連絡で約束した時刻を最優先に決めます。目安として、影響が大きい障害では30分から1時間ごと、影響が限定的な障害では2〜3時間ごとに設定するケースが多く見られますが、これは運用ごとに決める性質のもので、自社の重大度区分に合わせて定めておくと迷いません。

重要なのは、進展がなくても連絡することです。「新しい情報はありませんが、引き続き調査しています」という続報は一見すると無内容ですが、顧客から見ると「見られている」ことの証明になります。逆に、約束した時刻を過ぎても連絡がないと、状況の悪化を疑われます。時刻を守れそうにないときは、その時刻の前に「次回の連絡を30分延期します」と伝えます。

例文

続報の例文は、前回からの変化を冒頭に置き、現在の見通しと次回連絡の時刻で締めます。

件名：【続報】クラウド勤怠管理サービスのログイン障害について（午前10時時点）
午前9時10分ごろから発生しているログイン障害について、続報をお知らせします。
これまでにわかったこと：特定のデータベースへの接続に問題が生じていることを確認しました。
現在の対応：接続の切り替え作業を進めています。
復旧の見通し：確定できておりません。見通しが立ち次第、お知らせします。
お客様へのお願い：引き続き、ログインの繰り返し試行はお控えください。
次回のご連絡：午前11時までにお知らせします。

続報では、確認できた事実と、まだ確認できていないことを分けて書きます。「復旧の見通し：確定できておりません」と書くのは頼りなく見えますが、見通しの立たないまま「まもなく復旧します」と書いて外れるほうが、顧客の信頼を大きく損ないます。

復旧報告

復旧報告は、サービスが利用できる状態に戻ったことと、原因・影響・再発防止の方針を伝える連絡です。

原因と対策の書き方

復旧報告では、原因は「何が起きたか」を顧客が理解できる粒度で書き、対策は「何をいつまでにするか」まで書きます。

原因の書き方は、技術用語を最小限にして、顧客の業務に引きつけて説明するのが基本です。たとえば「データベースのコネクションプールが枯渇した」ではなく「同時に処理できるアクセス数の上限に達し、ログインの処理が滞りました」と書きます。対策は、すでに実施した応急処置と、これから実施する恒久対策を分けます。恒久対策には実施時期を添えます。時期が未定なら「時期が決まり次第お知らせします」と書き、約束できないことは約束しません。原因を深掘りする際の観点は、システム障害の原因ランキングと対策で整理しています。

障害に個人データの漏えいなどが絡む場合は、顧客向けのお知らせとは別に、行政機関への報告が必要になることがあります。個人情報保護委員会は、個人データの漏えい等が発生した場合の報告期限として、速報は発覚日から3〜5日以内、確報は発覚日から30日以内（不正な目的が疑われる場合は60日以内）と案内しています（個人情報保護委員会「漏えい等の対応とお役立ち資料」、2026-10-08参照）。該当するかどうかの判断は個別の事情によるため、法務担当や弁護士などの専門家に確認してください。

例文

復旧報告の例文は、復旧した事実を最初に書き、そのあとで経緯と対策を続けます。

件名：【復旧のお知らせ】クラウド勤怠管理サービスのログイン障害について
10月8日午前9時10分ごろから発生していたログイン障害は、午前11時40分に復旧しました。長時間にわたりご不便をおかけしましたことを、お詫び申し上げます。
影響：障害の間、ログインおよび打刻機能をご利用いただけない状態でした。この間の打刻漏れは、管理画面の「打刻修正」から補正いただけます。
原因：同時に処理できるアクセス数の上限に達し、ログインの処理が滞ったためです。
実施済みの対応：接続の切り替えにより、処理能力を回復させました。
今後の対策：アクセス数の監視を強化し、上限に近づいた時点で自動的に通知される仕組みを導入します。実施時期は決まり次第お知らせします。
ご不明な点がございましたら、サポート窓口までご連絡ください。

復旧報告の最後には、顧客側に残る作業（打刻の補正など）を必ず入れます。復旧しても顧客の手元に後始末が残るなら、その手順まで書いて初めて障害対応が完了します。

避けたい表現

障害連絡で避けたい表現は、責任の所在をぼかす言い回しと、確認できていない情報を事実のように書く言い回しの2種類です。

責任の曖昧な表現

責任の曖昧な表現とは、主語を消して、誰が何をしたのかをわからなくする言い回しです。「システムに不具合が発生してしまいました」「障害が起きた模様です」のように、自社の問題であるにもかかわらず他人事に聞こえる書き方は、顧客に不誠実な印象を与えます。

避けたい書き方	置き換えの例
障害が起きた模様です	当サービスで障害が発生しています
一部のお客様にご迷惑をおかけしたかもしれません	ログイン機能をご利用のお客様に影響が出ています
外部要因により止まっています	利用しているクラウド基盤で障害が発生し、当サービスに影響が出ています

3つ目の例のように、外部の事業者の障害が原因の場合でも、顧客にとってのサービス提供者は自社です。外部要因であることは事実として伝えて構いませんが、それを自社の責任を和らげる材料として使わないことが大切です。賠償や補償の有無に踏み込む場合は、文面を出す前に法務担当や弁護士に確認してください。

不確かな情報

不確かな情報とは、確認が取れていない原因・復旧時刻・影響範囲を、確定した事実のように書くことです。一次連絡の段階では「サイバー攻撃の可能性があります」「午後には復旧する見込みです」のような推測を書きたくなりますが、違っていたときの訂正は、最初に書かなかった場合よりずっと大きな信頼低下を招きます。

確認できていないことは、「現時点では確認できておりません」「原因は調査中です」と書きます。復旧時刻は、根拠のある見通しが立つまで書かず、代わりに次回連絡の時刻を約束します。数値を書くときは、「約3,000件に影響」のような具体値より、確認済みの範囲を示す「ログイン機能をご利用の全てのお客様」のほうが、あとで食い違いが起きにくくなります。

社内承認の流れ

社内承認の流れは、事実確認と責任者の承認を最短の手順で通し、連絡の遅れと誤りの両方を防ぐ仕組みです。

確認の順序

確認の順序は、起案、技術担当による事実確認、責任者の承認、配信の4段階が基本です。

起案：運用・サポート担当が、技術担当から聞いた事実をもとに文面を書きます。入力は技術担当からの状況メモ、出力は配信前の文案です。
事実確認：技術担当が、発生時刻・影響範囲・原因の記述が実態と合っているかを確認します。入力は文案、出力は修正済みの文案です。
承認：障害対応の責任者が、顧客への約束（次回連絡の時刻、対策の実施時期）に問題がないかを確認して承認します。補償や契約に触れる場合は、ここで法務担当にも確認します。
配信：メール、サービス内のお知らせ、公式サイトなど、定めた経路で配信し、配信した時刻を記録します。

このうち承認を得るのに時間がかかりすぎると、一次連絡が遅れます。重大度に応じて、軽微な続報は運用責任者の承認のみで配信できるようにしておくなど、権限の線引きを平時に決めておくことが現実的です。

テンプレートの準備

テンプレートの準備とは、障害が起きる前に、自社の一次連絡・続報・復旧報告の雛形を社内で用意しておくことです。この記事の例文を土台に、サービス名、連絡経路、署名、問い合わせ先を自社のものに置き換えて、社内の共有場所に保管します。

準備しておくと効果が大きいのは、次の3点です。

3段階それぞれの文面の雛形と、空欄に入れる項目の一覧
配信経路ごとの担当者と、承認者の連絡先
重大度ごとの続報頻度と、承認の権限の線引き

雛形は作って終わりではなく、訓練や実際の障害のたびに見直します。実際の障害対応のあとで「この項目は不要だった」「この一文が足りなかった」と振り返る場を設けると、雛形が実務に合った形に育っていきます。障害対応全体の枠組みを学びたい方は、ITILのプロセス一覧でインシデント管理の位置づけを確認しておくと、連絡の位置づけが理解しやすくなります。

出典・参考情報

個人情報保護委員会「漏えい等の対応とお役立ち資料」（2026-10-08参照）

本記事の例文は、説明のために作成した架空のものです。本記事は2026年10月時点の情報に基づいています。契約・補償・法令対応の個別判断は、弁護士などの専門家にご相談ください。最終更新日：2026年10月8日。