システム障害時の対応フロー：連絡体制と復旧手順の事前の決め方

システム障害への対応で差がつくのは、障害が起きた後の技術力よりも、起きる前に「誰が判断し、誰に連絡し、何を優先するか」を決めてあるかどうかです。障害の最中は、原因の調査、利用者への案内、社内への報告、復旧作業が同時に押し寄せます。役割と手順が決まっていないと、全員が同じ画面を見て原因を探し、顧客への案内は後回しになり、経営者は状況が分からないまま問い合わせへの対応に追われます。

この記事は、自社のWebサービスや業務システムを運営していて、障害時の対応を整えたい事業責任者・情報システム担当・開発チームのリーダーの方に向けたものです。障害対応の全体の流れを、検知・一次対応・影響の判断と連絡・復旧・事後対応と再発防止の五つの段階に分け、それぞれで事前に決めておくべき役割、連絡体制、手順、よくある失敗、チェックリストを説明します。

社内に専任の運用チームがない会社でも使えるよう、少人数で回す前提の決め方を中心に扱います。保守を外部の会社に委託している場合は、どこまでを保守会社が担い、どこからを自社が担うのかの線引きもあわせて確認してください。

システム障害対応フローの全体像

障害対応は、次の五つの段階に分けて考えると整理しやすくなります。

これらは順番に進むとは限らず、一次対応と顧客への連絡、原因の調査は並行して進みます。だからこそ、誰がどの作業を担うかを事前に分けておくことが重要です。障害を記録し、管理する仕組み全体はインシデント管理とも呼ばれます。

事前に決めておく役割と連絡体制

障害対応で最も重要な準備は、役割を決めておくことです。人数が少ない会社でも、役割として分けて考えることで、抜け漏れを防げます。

決めておくべき役割

役割の中で特に分けておきたいのが、対応責任者と技術対応です。原因を調べている人が、同時に顧客への案内や経営への報告まで判断しようとすると、どちらも遅れます。技術対応の人には調査と復旧に集中してもらい、判断と連絡は別の人が担う形にします。

連絡体制

• 連絡先の一覧：役割ごとの担当者と、その代わりの人の連絡先（電話番号、チャット、メール）を一覧にし、すぐに見られる場所に置きます。
• 連絡の手段：普段使っているチャットが使えない場合に備えて、電話など別の手段も決めておきます。
• 夜間・休日の扱い：夜間・休日に誰が通知を受け、誰に連絡を回すのかを決めます。すべての障害で夜中に人を起こす必要はないため、障害の重さに応じて決めます。
• 保守会社との連絡：保守を外部に委託している場合、障害の連絡先、受付時間、連絡してから対応が始まるまでの目安を確認しておきます。契約上の取り決めはシステム保守契約に含めるべき内容を参考にしてください。

保守会社に委託している場合の役割分担

保守を外部の会社に委託している場合は、五つの段階ごとに、自社と保守会社のどちらが担うかを表にしておきます。一般には、監視の通知の受信と技術的な調査・復旧は保守会社、障害の重さの最終判断、顧客への案内、社内への報告、事業上の判断は自社、という分け方が多くなります。ただし、監視の通知を保守会社が受けても、自社に連絡が来るまでの時間が決まっていなければ、顧客への案内は遅れます。「保守会社が異常に気づいたら何分以内に誰へ連絡するか」「自社が報告を受けたら誰が保守会社に連絡するか」という連絡の向きと時間を、双方の連絡先とあわせて明記しておきます。

また、障害の最中に保守会社が判断に迷う場面もあります。たとえば「一部の機能を止めれば他の機能は復旧できるが、止めてよいか」といった判断です。こうした事業に関わる判断を誰に確認すればよいか、その人に連絡がつかない場合は誰が代わりに判断するかも決めておくと、復旧の手が止まりません。

障害の重さの判断基準を決める

障害の重さによって、招集する人、連絡する相手、対応の速さが変わります。障害が起きてから議論するのではなく、判断の基準を事前に決めておきます。

判断に迷うときは、重いほうに区分するのが原則です。後から軽い区分に下げるのは簡単ですが、軽く見積もって対応が遅れると取り返しがつきません。また、情報漏えいの可能性がある場合は、技術的な影響の大きさにかかわらず最も重い区分として扱い、法令上の報告義務の有無などについて専門家や公的機関の最新の情報を確認します。

段階ごとの対応手順

ここからは、障害が起きたときの具体的な手順を段階ごとに示します。

1. 検知：異常に気づく

障害に気づくきっかけは、監視の通知、社内の利用者からの報告、顧客からの問い合わせのいずれかです。顧客からの問い合わせで初めて気づく状態は、検知が遅れていることを意味します。主要な機能が使えているかを外から定期的に確認する監視や、エラーの急増を知らせる通知を整えておきます。監視の設計についてはサービス監視とアラートの設計で詳しく説明しています。

社内や顧客からの報告を受ける窓口も一本化しておきます。報告が複数の担当者に個別に届くと、同じ障害の報告が別々に扱われ、全体像の把握が遅れます。

2. 一次対応：状況を把握し、体制を立ち上げる

1. 事実を確認する：何が使えないのか、いつからか、どの利用者に起きているのかを確認します。報告をそのまま受け取るのではなく、実際に画面や監視の情報を見て確かめます。
2. 重さを判断する：事前に決めた基準で区分を判断します。
3. 責任者に連絡する：区分に応じて、対応責任者と技術担当を招集します。
4. 対応の場を作る：チャットの専用の場所や通話など、関係者が情報を共有する場を一つに決めます。
5. 記録を始める：気づいた時刻、確認した事実、判断、作業を時系列で記録し始めます。

3. 影響の判断と連絡：伝えるべき人に伝える

技術担当が原因を調べている間に、連絡担当は影響の範囲を確認し、顧客と社内に案内します。原因が分からない段階でも、「どの機能が使えないか」「調査中であること」「次にいつ状況を知らせるか」は伝えられます。

• 顧客への案内：お知らせのページ、メール、サービス内の表示など、どの手段で案内するかを決めておきます。案内の文面のひな形を用意しておくと、障害の最中に一から考える必要がなくなります。
• 更新の頻度を約束する：「次の案内は一時間後」のように、次の更新の時期を伝えます。進展がなくても、約束の時刻に「調査を継続中」と伝えることで、問い合わせの増加を抑えられます。
• 社内への報告：営業、サポート、経営者など、顧客から問い合わせを受ける可能性のある部署に、同じ内容を共有します。部署ごとに違う説明をしないことが大切です。

4. 復旧：使える状態に戻す

復旧では、原因を完全に突き止めることよりも、まずサービスを使える状態に戻すことを優先します。

1. 直前の変更を確認する：障害の多くは、公開作業や設定の変更、外部サービスの変更の直後に起きます。直前に何が変わったかを最初に確認します。
2. 戻せるなら戻す：直前の公開が原因と考えられる場合は、前の状態に戻すことを検討します。戻す手順と判断の基準を事前に決めておくと、迷わずに実行できます。
3. 暫定対応で影響を止める：原因の機能を一時的に止める、外部連携を切り離す、処理能力を増やすなど、影響を止めるための対応を行います。
4. 復旧を確認する：主要な機能が実際に使えることを、技術担当以外の人も確かめます。
5. 復旧を案内する：顧客と社内に復旧を知らせます。データの不整合など、利用者に確認してほしいことがあればあわせて伝えます。
6. 恒久対応を計画する：暫定対応で済ませた部分について、根本的な修正の計画を立てます。

前の状態に戻す考え方はロールバックの解説も参考になります。復旧の手順は、障害が起きる前に手順書として残しておくことが重要です。手順書の作り方は運用手順書（Runbook）の作り方で説明しています。

5. 事後対応と再発防止：同じ障害を繰り返さない

復旧したら終わりではありません。障害の記録をもとに振り返りを行い、再発防止策を決めます。

• 時系列を整理する：いつ起き、いつ気づき、いつ誰が何を判断し、いつ復旧したかを整理します。
• 原因を掘り下げる：直接の原因だけでなく、なぜそれが起きたのか、なぜ早く気づけなかったのか、なぜ復旧に時間がかかったのかを掘り下げます。
• 再発防止策を決める：技術的な修正、監視の追加、手順の見直し、テストの追加など、具体的な対策を決め、担当者と期限を割り当てます。
• 報告書をまとめる：社内向け、必要に応じて顧客向けに報告をまとめます。

振り返りでは、個人の責任を追及するのではなく、仕組みの問題として原因を探ることが大切です。責める場になると、次からは情報が隠され、障害の原因が見えにくくなります。この振り返りの考え方はポストモーテム（障害振り返り）と呼ばれます。

具体例：休日の決済障害に対応した場面

ここでは架空の一般例として、少人数で会員制のオンライン講座を運営している会社を想定します。

ある土曜日の朝、サポート担当のもとに「申し込みの決済ができない」という問い合わせが数件届きました。この会社では、事前に障害対応の手順を決めていたため、サポート担当はまず自分で申し込み画面を試し、決済の画面でエラーが出ることを確認しました。決済ができない状態は「重大」の区分に当たるため、手順どおりに対応責任者である事業責任者に電話で連絡し、保守を委託している開発会社の休日の連絡先にも連絡しました。

事業責任者は、チャットに障害対応の専用の場所を作り、記録を始めるよう指示しました。技術対応は開発会社の担当者が担い、事業責任者は連絡に専念しました。原因はまだ分かっていませんでしたが、三十分以内にサービスのお知らせ欄に「決済ができない状態が発生しており調査中であること」「次の案内は一時間後に行うこと」を掲載しました。

開発会社の担当者は、直前の変更を確認したところ、前日の夕方に決済サービスとの連携で使う設定を更新していたことが分かりました。設定を前の状態に戻すと決済が通るようになり、サポート担当が実際に申し込みを試して復旧を確かめました。事業責任者はお知らせ欄を更新し、障害の時間帯に申し込めなかった利用者向けに、再度の申し込みの方法を案内しました。

翌週の振り返りでは、設定の更新が金曜の夕方に行われ、更新後の決済の確認手順がなかったことが問題として挙がりました。再発防止策として、決済に関わる変更は週の前半に行うこと、変更後に決済の動作確認を必ず行うこと、決済の成功件数が急に減ったときに通知が届く監視を追加することを決め、それぞれに担当者と期限を割り当てました。

障害対応でよくある失敗と避け方

全員が原因の調査に集まる：役割が決まっていないと、全員が原因を探し、顧客への案内や記録が抜けます。対応責任者と技術担当、連絡担当を分けます。

原因が分かるまで顧客に知らせない：原因が分からないうちは案内しにくいものですが、案内が遅れるほど問い合わせが増え、信頼も損なわれます。分かっている事実と次の案内の時期だけでも先に伝えます。

連絡先が古い：担当者の異動や退職で、連絡先の一覧が古くなっていることがあります。定期的に見直し、実際に連絡がつくかを確かめます。

戻す手順がない：公開した変更を前の状態に戻す手順が決まっていないと、復旧に時間がかかります。公開の手順とあわせて、戻す手順も整えておきます。

振り返りが責任追及になる：誰のせいかを問う場になると、次から情報が出てこなくなります。仕組みの問題として原因を掘り下げ、再発防止策に集中します。

再発防止策が実行されない：振り返りで対策を決めても、担当者と期限がなければ実行されません。対策を作業として登録し、完了を確認します。

一度も練習しない：手順書があっても、一度も使ったことがなければ、障害の最中に読み解く余裕はありません。年に一度程度、模擬の障害で手順をたどる訓練を行うと、手順の不備や古くなった情報に気づけます。

障害対応フローの準備チェックリスト

• 障害対応の五つの段階ごとに、担当する役割が決まっている
• 役割ごとの担当者と代わりの人の連絡先が一覧になっている
• 普段の連絡手段が使えない場合の手段が決まっている
• 夜間・休日の通知の受け手と連絡の回し方が決まっている
• 保守会社の障害時の連絡先と受付時間を把握している
• 障害の重さの判断基準と、区分ごとの対応が決まっている
• 主要な機能の監視と、異常時の通知が設定されている
• 社内・顧客からの報告を受ける窓口が一本化されている
• 顧客への案内の手段と文面のひな形がある
• 直前の変更を確認し、前の状態に戻す手順がある
• 復旧の手順書が、作業する人の手元にある
• 振り返りの形式、期限、再発防止策の管理方法が決まっている
• 模擬の障害で手順をたどる訓練の時期が決まっている

よくある質問

Q. 少人数の会社でも、ここまでの体制が必要ですか？

役割の数だけ人を用意する必要はありません。一人が複数の役割を兼ねても構いませんが、「誰がどの役割を担うか」は決めておきます。少なくとも、原因を調べる人と、顧客に連絡する人は分けておくと、対応が大きく変わります。

Q. 障害の報告書は顧客に出すべきですか？

障害の重さや、顧客との契約の内容によります。企業向けのサービスで、契約に障害時の報告が定められている場合や、顧客の業務に大きな影響が出た場合は、原因と再発防止策をまとめて報告するのが望ましいです。報告の範囲や表現については、契約の内容を確認してください。

Q. 外部の保守会社に任せていれば、自社は何もしなくてよいですか？

技術的な調査と復旧は保守会社が担えても、障害の重さの判断、顧客への案内、社内への報告、事業上の判断は自社にしかできません。保守会社との役割分担を事前に決め、自社が担う部分の手順も整えておく必要があります。

Q. 障害対応の手順はどのくらいの頻度で見直すべきですか？

障害が起きて振り返りを行ったとき、システムの構成や体制が変わったとき、担当者が入れ替わったときに見直します。障害が起きていない場合でも、一年に一度は連絡先と手順を確認し、模擬の訓練で使えるかを確かめるのが目安です。

Otsumuに相談できること

システムの構成が把握できていて、開発担当者や保守会社と連絡が取れる体制がある場合は、この記事の表とチェックリストを使って役割と手順を書き出すだけで、自社で十分に障害対応フローを整えられます。最初は簡単な一覧と連絡先から始め、障害の振り返りのたびに手順を足していけば構いません。

一方で、システムの構成や監視の状態を社内で誰も把握していない、保守会社との役割分担が曖昧で障害時に誰が動くのか分からない、障害が繰り返し起きているが原因が特定できない、といった状況では、技術的な観点から現状を確認し、監視や手順を整える外部の力を借りたほうが確実です。

Otsumuは自らも事業を手がける立場から、事業への影響を起点に障害の重さの基準と対応の体制を整理し、監視の設計、手順書の整備、保守の引き受け、振り返りにもとづく改善までを一気通貫で支援しています。既存システムの保守や障害対応の体制づくりは保守・運用でご相談いただけます。範囲に応じて個別にお見積もりします。

最近起きた障害の経緯や、今の保守契約の内容をお持ちいただければ、どこから整えるべきかを一緒に整理できます。まずは30分の無料相談をご利用ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01