システム障害の初動対応は？影響確認・担当への連絡・経過報告の手順

最初に、申告されたことと確認したことを分ける

利用者の言葉を、そのまま技術的な原因へ置き換えないことが出発点です。「保存したのに見えない」という申告は重要ですが、保存されていないことやデータ消失、サービス全体の停止が確認されたわけではありません。申告の内容、窓口が自分で確かめたこと、原因の仮説を別に残します。

この例で、届いているのは利用者からの申告

まず聞くのは、操作・現象・仕事への影響

• 何をしたか：どの業務システムの、どの画面で、どんな操作を行ったか。保存後に出た表示、一覧を開いた条件、同じ依頼を探した方法を必要な範囲で聞きます。
• いつ、どこで確認したか：現象を見た時点、使った環境と利用者の役割を確かめます。連絡を受けた時刻と、障害が始まった時刻を同一にしません。
• 何が進められないか：依頼の登録、担当者への引継ぎ、点検の日程決めなど、困っている仕事を聞きます。締めや予定へ影響するかも、業務責任者が判断できる形へまとめます。
• 既に何をしたか：再読込みや再登録など、利用者が行った操作を確認します。何度も保存し直すことを無条件に勧めず、重複や状態の変化が起きない方法を担当へ確かめます。

最初の段階ですべての欄を埋める必要はありません。影響が大きい疑いがある場合は、会社の手順で必要な責任者へ先に知らせ、不足する情報を並行して集めます。問い合わせの整理を理由に、連絡そのものを遅らせないでください。

窓口が見た事実は、申告と分けて記録する

原票の窓口はIT窓口（架空）です。IT窓口が同じ現象を観測した結果は、まだありません。確認できた操作、確認できた画面、確認できたサービスの状態はいずれも未確認です。

窓口が確認する場合は、会社が許可した環境と操作の範囲で、申告と同じ条件を確かめます。見つからなければ「一覧のこの条件で、対象を見つけられなかった」と残し、原因を確定しません。表示の違いだけでは、保存先の消失や全利用者への影響まで分かりません。

止まる仕事と影響範囲から、連絡先を決める

原因が未確定でも、止まりそうな仕事と、判断を頼む相手は整理できます。この例で影響が心配されるのは、新しい点検依頼を担当者が見つけられない可能性です。「見当たらない」という一つの申告を、全支店の停止や依頼の消失へ広げないでください。

人数・範囲・時刻を、分かった数に変えない

影響する支店、影響する利用者数、障害の開始時刻は未確認です。データが失われたか、原因も未確認です。連絡が来た支店が分かっても、それだけで影響範囲の全体を確定したとはしません。

どの仕事を、いつまでに進める必要があるかを業務側へ聞きます。同じ「一覧に出ない」でも、点検の手配が直ちに止まる場合と、別の確認方法で当面進められる場合では判断が違います。代わりの手段があるという思い込みも避け、必要な内容を扱え、後で元の記録へ戻せるかを責任者に確かめます。

この原票では実際に止まった仕事、期限への影響、代わりの手段が使えるか、優先度の判断は未確認です。判断する役割として業務責任者（架空）を置いていますが、その判断を終えた記録ではありません。

会社の基準で、責任者と連絡先へつなぐ

優先度は、影響する仕事、利用者・拠点、期限、拡大するおそれ、代替手段の有無を会社の基準へ照らして決めます。一般的な区分名や一律の分数を、そのまま自社の対応条件にはしません。判断に必要な情報が不足するなら、不足する点と懸念を添えて責任者へ相談します。

時間外や担当者が不在の場合の代わりの連絡先、保守会社の受付方法・対応範囲も確認します。連絡したこと、受領されたこと、担当が調査を始めたことは違います。応答時間や費用・作業範囲の読み方は、システム保守費用と対応範囲の比較で、対象の見積・契約に合わせて確かめます。

調査する人と案内する人へ、仕事を引き継ぐ

一人が原因調査も利用者への説明も抱える状態を、役割ごとに整理します。専任が少ない会社では同じ人が兼務して構いません。その場合も「今は誰が技術面を調べ、誰が仕事への影響を判断し、誰が次の案内を出すか」を明確にします。

この図は仕事を分けるための整理であり、三つの担当が引き受けた結果や、対応が順番どおり完了した記録ではありません。調査中でも、影響の確認と利用者への案内を並行します。

送っただけでなく、何を引き受けたかを確かめる

この例の役割は、技術面が保守担当（架空）、業務面が業務責任者（架空）、利用者への連絡が社内窓口（架空）です。一方、技術担当の引受けと業務担当の引受けは未確認です。メッセージを送ったことだけで引受け済みとは扱いません。

引継ぎでは、現象と確認条件、困る仕事、未確認の範囲、既にしたこと、次にしてほしいことを短くまとめます。受け手に、担当する範囲と次に返す結果を確認してください。調査担当へ送った受付番号があっても、業務責任者の判断や利用者への案内まで引き受けられたとは限りません。

次に技術担当が確認する対象も、利用者への次の更新時点も、この原票では未確認です。担当名だけを置いて終えず、次の作業と返す相手を決めます。担当交代では、残る影響と未完了の作業、次の案内を受け手へ渡し、引き受けた人を関係者へ知らせます。関係者全員の返信を待つ仕組みにする必要はありません。

図で見る問い：利用者の「見えない」という申告を、誰がどんな確認へつなぎ、何を利用者へ返すのでしょうか。次の図では、申告、窓口の確認、担当の引受け、次の案内を分けて見てください。

この解説図を原寸で見る

図の読み方：申告の紙が届いたことと、窓口が現象を見たことは違います。担当へ渡した連絡と、担当が引き受けた仕事も分けます。まだ確かめていない枝は、次に確認する人と材料へつなぎ、復旧済みの印へ変えないでください。

第一報と経過報告を、利用者の行動につなげる

第一報は、原因や復旧時刻を言い当てるための連絡ではありません。利用者が今の状況を理解し、何をすればよいか判断できることを目指します。誰にどの仕事の影響を伝えるかを決め、必要な権限・共有範囲で案内します。

申告だけの段階では、申告として伝える

確認が進んだら、何を・いつ・どの条件で確かめたかを反映します。「全社で利用できません」といった表現は、その範囲を確かめた場合に限ります。原因が未確認なら未確認と記し、推測を確定事項として案内しないでください。

利用者の行動は、対象の仕事に合わせて書く

この架空文例の行動案は「重複登録を避け、窓口の案内を確認する（この架空文例の条件。実会社へ無条件適用しない）」です。登録済みか不明な依頼を再入力することで重複するおそれを考えた文例ですが、実会社へそのまま適用する指示ではありません。業務責任者・技術担当と、待つ対象、続けてよい操作、問い合わせ先を確かめてから案内します。

「復旧までお待ちください」だけでは、別の仕事を続けてよいか、手元の情報をどう扱うか分かりません。影響のある機能、対象の利用者、今してよいこと・確認を待つこと、追加情報の連絡先を、読み手の仕事で説明してください。機微な画面や顧客情報を無制限に集める案内にはしません。

次の更新と、復旧予定を別にする

次の連絡は「次に状況を知らせる時点」で、使える状態へ戻る約束とは違います。会社の体制と影響に合わせて更新の時点・担当・経路を決めます。普遍的な更新間隔は定めていません。復旧見込みの根拠がない場合は推測の時刻を置かず、見込みを確認する担当と次の案内を示します。

• 調査継続中の文例：「前回の案内から、影響範囲と保存の状態を引き続き確認しています。原因と復旧見込みは未確定です。対象の方への操作案内に変更があるかを確認し、決めた時点に次の状況をお知らせします」。実際に確かめていない進展は書き足しません。
• 状況が変わった場合の文例：「今回確認できた範囲は〈具体的な仕事・対象〉です。前回から変わったのは〈確認できた内容〉です。対象の方は〈確認済みの行動案内〉をご確認ください」。山括弧は、その会社で得た事実へ置き換えるための説明です。

この原票では第一報は実際に送信していません。利用者が読んだ結果も未確認です。案内を作成したこと、配信したこと、届いたこと、読まれたこと、必要な行動ができたことを一つの完了にまとめません。

再現しない・連絡できないときの返し方を変える

回答が変われば、次に確かめる内容と案内を変えます。下の表は、今後その条件になった場合の進め方です。現在、現象の再現や担当の引受け、代替経路、修復が確認された結果ではありません。

表は横に動かせます。左の状況名を残しながら、右端の「次に確かめる担当」まで読み、同じ行の返し方と対応させてください。

いつものメールやチャットが使えない

障害の案内を、障害のある仕組みだけに頼ると届かない場合があります。会社が決めた代替経路とその管理者を確認します。電話、別の連絡先、掲示先などは候補になり得ますが、この原票の代替の連絡経路は未確認です。使えること、必要な人へ届くこと、情報を安全に扱えることを確かめず、導入済み・送達済みとしません。

連絡先一覧が同じ障害のあるサービスにしか置かれていない場合も考えます。利用者が別の手段を持っているか、時間外に届くか、個人の端末や番号を使ってよいかは会社の条件で確認してください。特定サービスやSMSを、必ず届く万能な方法として勧めるものではありません。

原因や契約の扱いを、その場で決められない

必要な初動と利用者への案内を進めつつ、契約上の調査・修正の範囲は担当窓口へ確認します。この例の費用や契約の判断は未確認です。納品後の不具合と合意仕様・開発契約・保守契約の整理は、納品後の不具合と契約先への確認で扱います。

不正利用や情報漏えいなどが疑われる場合は、会社のセキュリティ責任者と専用の手順へつなぎます。本稿は一般的な業務システムの障害申告を扱い、法令上の報告期限や適合を認定していません。すべてを一律に停止する指示や、実顧客への通知を勝手に行う手順は示していません。

修復の連絡から、仕事の再開と窓口の終了を確かめる

技術担当からの「直った」という返答を、業務側が仕事を再開できた結果へつなぎ直します。何を修復し、どの範囲を確認したかを聞き、対象の利用者が必要な依頼を見つけ、担当へ引き継げるかを業務責任者と確かめます。

修復・業務再開・原因確定を別々に残す

この原票では技術的な修復の完了も、業務を再開できた結果も未確認です。根本原因の確定、恒久的な再発防止の完了も未確認です。「一覧が開いた」だけで、対象の依頼と引継ぎが正しいことや、再発を防げることまで確定しません。

1. 技術担当の返答を読む。対象の機能、変更・回避した範囲、確認できたこと、残る制約を聞きます。原因の仮説や暫定対応なら、その状態のまま残します。
2. 影響した仕事を確かめる。会社が許可した方法で、問題になった依頼と利用者の役割を対応させて確認します。操作が通ることと、必要な記録を相手が扱えることを分けます。
3. 残る依頼や影響を引き継ぐ。対応中に別の方法で受け付けたものがあるなら、存在と内容を確認してから処理先を決めます。この例には、その受付の存在や照合結果は設定していません。
4. 再開案内を実結果へ合わせる。利用できる範囲、残る制限、利用者が確かめる内容と窓口を示します。対象外の支店や機能まで復旧したと広げません。

予定した復旧テストを、元の依頼や注文の記録と業務の確認へ結ぶ方法は、業務の仕事まで確かめる復旧テストで扱っています。本稿は初動の受付と連絡が中心で、実際の復旧方式や修復コマンドを決めるものではありません。

窓口を終える条件と、後に残す仕事を決める

障害の窓口対応を終了した結果は未確認です。業務への影響と利用者への案内を確認したうえで、残る問い合わせ、原因調査、暫定対応の解消、再発防止を誰が引き継ぐかを明確にします。窓口を閉じたことだけで、根本原因や恒久対応も完了したとは扱いません。

次に備えて、連絡先と記録の置き場を整える

次の障害で同じ窓口が抱え込まないよう、実際に使う連絡先・引継ぎ先・案内の置き場を整えます。立派な一覧を作ること自体を目的にせず、利用者の申告を受けたとき、必要な担当へつながり、次の状況を返せるかを確かめます。

• 役割と代わりの人：技術調査、業務判断、利用者への連絡を誰が担うか。兼務する場合の引継ぎ先、不在や時間外の扱いを決めます。
• 連絡の経路：通常の窓口と、それが使えない場合の経路を確認します。必要な人が見られる場所に、共有範囲を守って置きます。
• 更新する記録：申告、確認時点と条件、影響、担当、未確認、次の作業と案内を同じ件へ結びます。関係者が別々の古い説明を見続けないようにします。
• 練習と見直し：会社が許可した想定例で連絡・引継ぎを試し、途切れる所を直します。実障害を作ったり、本番を無断で止めたりする必要はありません。

Google SREの資料も、利用者に見える症状、役割の分担、影響と案内、共有する状態記録、明確な引継ぎを扱っています。専任の人数や製品、Googleの体制をそのまま採用する必要があるという意味ではありません。自社の規模と業務、保守の契約に合わせて使います。

本例には全社共通で使える障害の重さの基準は設定していません。また、実システムは変更していません。実顧客への通知は行っていませんし、実際の担当者の引受けは得ていません。実際の復旧を達成した記録でもありません。説明例で学ぶことと、会社の実手順を実施して得た結果を分けてください。

まとめ：同じ申告を、次の担当と案内までつなぐ

障害らしい連絡を受けたら、操作と現象、確認した時点、影響する仕事を同じ申告へまとめます。利用者からの申告と窓口の観測、原因の仮説と確認事実を分け、不足する情報を補いながら必要な責任者へ知らせます。

技術調査、業務判断、利用者への案内は役割を分けて並行します。送信で終えず、担当の引受けと次の作業を確かめ、第一報と更新に利用者の行動を示してください。修復の返答後は仕事の再開と残る影響を確認し、原因調査・再発防止を引き継いで窓口を終えます。