システム障害が発生したら何をする？初動・記録・報告の進め方

障害に気づいたら、原因が分からなくても第一報を送る

システムの異常に気づいたら、原因を調べ終わるのを待たずに、決められた連絡先へ知らせましょう。 この最初の連絡を「第一報」といいます。

自分だけで原因を調べていると、担当者が異常を知るのが遅れ、その間も業務への影響が続くことがあります。早めに知らせることで、チームで状況の確認や対応を始められます。

最初は「注文一覧が開かず、出荷作業が止まっているとの連絡があります。原因はまだ分かりません」のように、分かっていることを伝えれば大丈夫です。記録をきれいにまとめてから連絡する必要もありません。

「障害かどうか、まだ判断できない」という段階でも、そのまま伝えて相談しましょう。

最小限の状況を押さえ、第一報を送る

第一報は、異常に気づいたことを知らせる最初の連絡です。調査結果をまとめた完成版の報告書ではないため、分からない項目は「未確認」として伝えます。

まず障害対応手順や連絡網に従い、運用担当者や当番の担当者へ連絡します。連絡先が分からないときは、直属の上司や作業を依頼した人へ「業務に影響する異常があり、緊急の連絡先を確認したい」と知らせてください。

緊急連絡で指定されている電話などの手段があれば、それを使います。チャットへ投稿しただけで対応が始まったと思わず、受け取った返事を確認しましょう。応答がなければ、連絡網の次の担当者や上司へつなぎます。待つ時間や順番は職場のルールに従います。

業務への影響を、分かる範囲で伝える

注文一覧が開けない場合は、「画面が使えない」だけでなく、「出荷する注文を確認できない」と伝えると、対応する人が仕事への影響を把握しやすくなります。

確認には、今見えている画面、届いた問い合わせ、すでに利用している人からの情報を使います。影響を調べるために、他の人へ注文登録や送信を何度も試してもらう必要はありません。

「自分の画面で確認した」「出荷担当者1名から同じ症状の連絡を受けた」「全社員が使えない」は、それぞれ違う情報です。未確認の範囲まで広げて書かず、原因や復旧予定も推測で断定しません。

第一報の例文とテンプレート

たとえば、次のように送れます。

【障害の可能性・第一報】10月10日14:05に、本番の受注管理システムで注文一覧が開かず、「情報を取得できません」と表示されることを確認しました。出荷担当の佐藤さんからも同じ症状と、注文を確認できず出荷作業が止まっているとの連絡があります。影響の全体範囲と原因は未確認です。追加の再操作はしていません。対応の確認をお願いします。

本番とは、実際の利用者が仕事で使っている環境のことです。練習・テスト用のシステムと取り違えないよう、分かる場合は環境も添えます。

コピーして使う場合は、次の型に置き換えてください。空欄を調べ尽くすために、連絡を遅らせる必要はありません。

【障害の可能性・第一報】
発見した日時（日付・時刻・日本時間など）：
対象のシステム・画面・環境：
自分で確認した症状：
他者からの報告・業務への影響（誰からの情報か）：
実施した対応・保留している操作：
未確認のこと（発生時刻・影響範囲・原因など）：
お願いしたい確認・対応：

もっと急ぐ場面なら、「受注管理の注文一覧が開かず、出荷作業が止まっているとの連絡が来ています。詳細確認中です。対応をお願いします」と先に知らせ、残りを追記します。

起きたことと対応を時系列で記録する

第一報を送ったら、チーム指定の障害記録や共有メモへ、分かったことを追記します。連絡しながら短くメモしても構いません。電話で話した内容も、後から時刻と要点を残してください。

記録は文章をきれいに整えるより、別の人が「何を確認し、どこまで対応したか」を追えることを優先します。

発見時刻と発生時刻を分ける

14:05に異常を見つけたとしても、障害が14:05に始まったとは限りません。次のように分けます。

• 発見時刻：異常に気づいた時刻。この例では自分が画面で確認した14:05。
• 発生時刻：異常が始まった時刻。調べていなければ「不明」。

「13:50には使えていた」という連絡があっても、14:00から障害が起きたと決めつけません。誰から得た情報か、何の機能が使えていたかを残し、開始時刻の確認は担当者へつなぎます。

時系列のメモは、次のように書けます。すべて架空の10月10日・日本時間の例です。報告を受けた時刻と、報告された出来事の時刻が違う場合は、両方を残します。

時刻	確認した人・情報源	起きたこと・対応・結果
14:05	自分	本番の注文一覧で「情報を取得できません」と表示。発生時刻は不明
14:06	佐藤さんからのチャット	同じ画面が開かず、注文を確認できないため出荷作業が止まっているとの連絡
14:07	自分	当番の田中さんへ電話で第一報
14:08	田中さんからの返答	対応を開始するとの返答を受けた
14:10	田中さんの指示	自分は利用者からの連絡を記録する担当になった。復旧操作は田中さん側で実施
14:20	田中さんからの共有	原因を調査中。復旧見込みは未定。次回共有は14:30

自分が操作した場合は、対象、指示者または適用した手順、操作内容、結果も残します。「再起動した」だけでなく、何をいつ再起動し、その後どうなったかが分かる形にしてください。

自分の確認・他者の報告・推測・未確認を分ける

「システム全体が止まったようです」だけでは、確認した範囲や根拠が分かりません。次のように分けましょう。

区分	記録例
自分で確認した事実	注文一覧にエラーメッセージが表示された
他者からの報告	佐藤さんから、出荷作業が止まっているとの連絡があった
推測	注文一覧が使えないため、他部署の出荷準備にも影響しているかもしれない。部署への確認は未実施
未確認事項	他部署への影響、データが失われていないか、異常が始まった時刻

推測を書く場合は、根拠も添えます。無理に原因候補を考えて欄を埋めなくても構いません。後から誤りと分かった情報は、訂正した時刻と内容が分かるよう追記します。

画面やログ（システムで起きた出来事の記録）は、第一報を遅らせない範囲で、職場で許可された場所に保存します。元の記録を削除・書き換えず、誰が閲覧できる場所かも確かめてください。顧客名やパスワードなどを、広く見えるチャットや外部のAIへそのまま貼らないようにします。

役割を確認し、続報と引き継ぎを行う

担当者が対応を始めたら、自分は何を担当するかを確認します。複数の人が別々に設定を変えると、変更同士が影響したり、どの対応で状態が変わったか分からなくなったりします。

担当する作業と連絡先をそろえる

最低限、対応をまとめる人、自分の担当、情報を集める場所を確認しましょう。小さなチームでは、1人が複数の役割を担当する場合もあります。

私は利用者から届いた連絡を、この障害記録にまとめればよいですか。追加で分かったことは田中さんへ伝えます。

「もう一度押せば直るかも」と、登録ボタンを何度も押すのは避けましょう。同じ注文が二重に登録されることがあります。再起動や設定変更も、ほかの人の作業に影響することがあるため、担当者と手順を確認してから行います。

迷ったときは、次の操作をいったん待って相談しましょう。動いている処理を、無理に止めるという意味ではありません。

ただし、緊急時に自分が行ってよい作業が職場で決まっている場合は、その手順に沿って対応し、担当者にも知らせます。

顧客への案内も、職場で決められた担当者と内容をそろえます。問い合わせを受けたときは、承認された案内の範囲で伝え、不明な復旧時刻を約束しないようにします。

変化がない場合も、決めた時刻に続報を出す

続報では、今の影響、新しく分かったこと、対応中の内容、未確認事項、次の共有予定を伝えます。状況が悪化したときは、予定時刻を待たずに知らせます。

14:20時点で原因が分からない場合も、次のように報告できます。

【続報・14:20】注文一覧が開けない件は、担当者が原因を調査中です。佐藤さんからは出荷作業を再開できていないとの連絡があります。他部署への影響は未確認です。復旧見込みは未定で、次回は14:30に状況を共有します。影響の変化が分かった場合は、その時点で連絡します。

次回報告の時刻と、復旧予定の時刻は別です。 「14:30に報告します」は「14:30に直ります」という意味ではありません。この例の10分間隔は共通ルールではありません。報告の間隔は職場の手順や担当者と確認します。

交代時は、残る作業まで渡す

勤務交代などで引き継ぐ場合は、記録の場所だけでなく、現在の影響、対応済みのこと、未確認事項、次にすること、次回報告時刻を伝えます。

「他部署への影響は未確認です。次の担当は鈴木さんで、14:30の続報をお願いします」のように、誰が何を引き受けるかをそろえましょう。引き継ぐ相手の了承を確認し、必要な関係者にも担当変更を知らせます。

復旧したように見えても、確認結果を残す

注文一覧が1回開けても、利用者の業務がすべて戻ったとは限りません。担当者が決めた方法で、影響した機能と業務を確認します。

この例なら、注文一覧が表示されるかに加えて、出荷担当者が必要な注文を確認し、作業を再開できたかを確かめます。ほかの機能やデータへの影響も、必要な範囲を担当者が判断します。

動作確認で実際の注文を登録・削除すると、業務のデータに影響します。自分の判断では試さず、担当者が決めた確認用データと手順に従ってください。

報告には「いつ、誰が、どの範囲を確認できたか」を残します。

【確認結果・14:45】担当者の対応後、14:40に自分の画面で注文一覧の表示を確認しました。14:43に佐藤さんから、必要な注文を確認でき、出荷作業を再開したとの連絡がありました。他部署の確認状況は未確認です。この結果を復旧判断の担当者へ共有しました。

復旧の宣言や対応終了は、職場の基準と担当者の判断に従います。使える状態に戻っても、原因の調査や再発を防ぐ対応が残ることがあります。残作業は担当者と確認予定を決め、記録を引き継ぎます。

よくある疑問

自分の操作がきっかけかもしれない場合は？

行った操作、対象、時刻、表示された結果を早く伝えます。「自分が壊した」と原因まで断定する必要はありませんが、直前に行った変更を隠すと調査が遅れます。記録を消したり、報告せずに戻したりせず、手順に沿って対応してください。

一度だけ起きて、その後は使える場合は？

業務への影響があった場合や、障害か判断できない場合は、その状況も含めて連絡します。「14:05に開けなかったが、14:12の確認では表示できた。原因は不明」のように、時刻と確認範囲を示します。再発を確かめるために、影響のある操作を繰り返す必要はありません。

不審なログインや情報流出の疑いがある場合は、通常の障害連絡に加え、職場のセキュリティ窓口・専用手順へつなぎます。

まとめ

システム障害が疑われるときは、原因が分からなくても、分かっている症状と業務への影響を知らせます。連絡後は、確認した事実と未確認事項を分け、対応や結果を時刻とともに残しましょう。

今まさに異常が起きているなら、第一報の型を使い、分かっている範囲で指定の連絡先へ伝えてください。平常時に読んでいる方は、まず障害時の連絡先、応答がないときの次の連絡先、記録の保存場所を確認しておくと、最初の行動に迷いにくくなります。

関連記事

• エラーログの読み方｜初心者が最初に確認するポイント：記録を確認する担当になり、ログのどこを見ればよいか知りたい方へ。
• 不具合報告の書き方｜初心者向けの例文・テンプレート：第一報の後、発生条件や操作手順を詳しく整理したい方へ。
• 運用・保守とは？IT初心者向けに意味や違いをわかりやすく解説：障害対応を含む、運用・保守の仕事全体を知りたい方へ。