「メールが開かない」「共有ファイルにアクセスできない」「受付システムが動かない」。クラウドサービスが突然止まると、情シスには問い合わせが集中します。公式の復旧案内を待っている間にも、受付や支払いの期限は近づいてきます。
まずは影響範囲を確認して社内へ知らせ、止められない業務から代替運用へ切り替えましょう。原因調査と業務の継続を並行して進めることが大切です。
この記事では、ひとり情シスや少人数のIT担当者に向けて、最初の30分の対応、業務別の代替手段、復旧後の確認までを整理します。時間配分は実務上の目安です。既存の社内手順がある場合は、それに沿って担当者と判断者を確認してください。
クラウド基盤の停止が、その上で動くサービスの利用に影響することもあります。個別の事例は、IDCFクラウドの障害と利用サービスへの影響の記事で整理しています。
クラウド障害が起きたら、最初の30分で行うこと
この30分で目指すのは、原因の特定を終えることではありません。何が止まり、どの仕事をどう続けるかを関係者が共有できる状態を作ります。電話対応に追われると記録が後回しになるため、最初から1つの記録先を決めておくと、その後の説明も楽になります。
| 時間の目安 | 行うこと | 残す・決める内容 |
|---|---|---|
| 0〜5分 | 発生状況を確認 | 発生時刻、サービス名、エラー、使えない機能 |
| 5〜10分 | 影響範囲と公式情報を確認 | 対象者・拠点・業務、公式発表の有無 |
| 10〜15分 | 社内へ第一報 | 確認済みの影響、当面の対応、次回更新時刻 |
| 15〜30分 | 優先業務の代替運用を決定 | 継続・停止する業務、担当者、記録先 |
この時間配分は本記事の提案であり、IPAの時間基準ではありません。受付が止まっているなど、影響がすでに大きい場合は、全体の調査を終える前に該当部門へ連絡します。
0〜5分：エラーと発生時刻を残す
利用者に、何を操作したときに、どの画面で止まったかを確認します。「使えない」だけでは、ログインの問題か、保存の問題か分かりません。
- 気付いた時刻と、最後に正常利用できた時刻
- 対象サービスと操作内容（ログイン・閲覧・保存・送信など）
- エラーメッセージや画面の記録
- 影響が出ている利用者・拠点と、まだ確認できていない範囲
画面を共有する場合は、顧客情報や認証情報が写っていないか確認します。原因は「調査中」とし、観測した事実と推測を分けて記録してください。
5〜10分：「自分だけ」「社内全体」「サービス側」を切り分ける
別の利用者や端末でも同じ症状か、ほかのWebサービスは利用できるか、サービスの公式障害情報や管理画面に案内があるかを確認します。
1人だけなら端末・アカウントの問題、社内から一斉に接続できないなら回線や認証基盤の問題なども候補になります。ただし、これだけで原因を確定はできません。公式案内がまだ出ていなくても、サービス側の障害が否定されたわけではありません。
契約先のサポートへ問い合わせる際は、発生時刻、操作、エラー、影響範囲をまとめて伝えます。SNSの投稿は参考情報にとどめ、社内へ伝える障害原因や復旧見込みは、公式情報と自社で確認した事実を基にします。
10〜15分：復旧予定が分からなくても第一報を出す
原因が判明するまで連絡を待つと、各部門が同じ操作を繰り返したり、それぞれ別の方法で仕事を進めたりします。確認済みの影響と当面の対応を先に知らせましょう。
復旧見込みが分からなければ「未定」と明記します。そのうえで「次の案内は10時30分」のように更新時刻を決めます。新情報がなくても、その時刻に確認状況を伝えることで、問い合わせを整理できます。
15〜30分：止められない業務から代替運用を決める
各部門に「今日中に必要な仕事」「その期限」「止まると困る相手」を確認します。情シスは使える手段を整理し、業務の継続・停止や切替の承認は、部門責任者や上司と決めます。
ひとり情シスであっても、受付の仮記録や取引先への連絡まで1人で抱える必要はありません。技術確認、社内周知、業務判断、仮記録の担当を分けると、対応が進みやすくなります。
どこまで仕事が止まるか、業務と機能で確認する
ログインできても、一部の機能だけ止まることがある
ログインできたから正常とは限りません。ファイルの閲覧はできても保存できない、受付画面は開いても通知メールが届かない、といった状態もあります。実際の業務で必要な機能を分けて確認しましょう。
| 確認する機能 | 確認したいこと |
|---|---|
| ログイン・認証 | 新規ログインと既存セッションの両方に問題がないか |
| 閲覧・検索 | 必要なデータが表示されるか、更新時刻はいつか |
| 登録・保存 | 処理結果を確認できるか、入力内容が残っているか |
| 送信・通知 | 送信待ち・エラーがないか、相手に到達しているか |
| 外部連携 | 勤怠から給与など、後続の処理が止まっていないか |
共通の認証や連携先にも目を向ける
複数のサービスが使えないときは、共通の認証、回線、クラウド基盤、API連携への依存も確認します。サービスの名前が違っていても、同じ仕組みに依存している場合があります。
予備の連絡アプリも同じ認証が必要なら、切り替えてもログインできないかもしれません。代替手段は、実際に利用できることを確かめてから案内します。
業務別：クラウドが使えない間の代替手段
代替運用では、担当者・記録先・連番や識別番号・復旧後の反映担当を決めます。「各自でメモしておいて」だけでは、後から集める際に抜けや重複が生じやすくなります。
| 止まった業務 | 代替運用の例 | 切替前の確認 |
|---|---|---|
| メール・社内チャット | 電話、事前に決めた予備の連絡手段 | 連絡先を取り出せるか、相手も利用できるか |
| ファイル共有 | 承認済みの保存先、取得済みのローカル資料 | 版・更新日時・閲覧権限、ローカルの実体があるか |
| 勤怠・申請 | 紙や指定のExcelで一時記録 | 記録者・承認者・後日の入力担当 |
| 予約・受付・顧客管理 | 仮受付票、受付番号付きの一覧 | 既存予約を確認できるか、重複受付を防げるか |
| 会計・請求 | 証憑を保管し、未処理一覧を作成 | 支払期限、処理済みか、二重支払いの防止 |
メール・チャット：連絡手段と連絡先をセットで確保する
電話に切り替える場合も、電話番号が停止中のクラウドにしかないと連絡できません。主要な連絡先を取り出せるか確認し、社内の問い合わせ窓口を1つにします。業務上の機密情報を個人のメールや私用アプリに送る方法は、会社の承認なしに採用しないでください。
ファイル共有：手元のファイルが本当に開くか確認する
同期フォルダーに名前が見えていても、ファイル本体が端末に保存されていない場合があります。停止中に使えるかは、実際にファイルを開いて確かめます。ローカルにある資料も、更新日時と版を確認し、最新の金額や予約状況が必要な判断には慎重に使います。
勤怠・受付：仮記録には番号を付ける
たとえば仮受付を「日付＋連番」で管理し、受付日時、内容、担当者、未処理・反映済みの状態を記録します。複数の窓口がある場合は窓口記号も付け、同じ番号を使わないようにします。個人情報はその業務に必要な項目に絞り、紙にも保管担当を決めます。
会計・支払い：処理結果が不明な操作を繰り返さない
送信後に画面が固まった場合、操作が失敗したとは限りません。支払い・注文・請求などは、履歴や取引先への確認で処理結果を確かめてから再操作します。確認できない処理は未確認一覧に残し、期限と確認担当を決めて管理します。
手作業で継続できない業務は、受付と確定を分ける
現在の在庫、予約枠、入金状況などが確認できない場合は、受付だけ行い、確定の案内は後にする方法もあります。ただし、仮受付が可能か、利用者へ何を伝えるかは部門責任者と決めます。正確な情報が必要な判断まで、古い一覧で進めないことが大切です。
社内への連絡は、障害情報と仕事の進め方をセットにする
第一報には、対象サービス、確認済みの影響、原因と復旧見込み、当面の業務手順、次回更新時刻を入れます。以下は記入式の例です。
【サービス利用障害／第一報】
確認時刻：○月○日 ○時○分
対象：○○サービス
影響：○○部門で、○○の登録・閲覧ができません。ほかの部門は確認中です。
原因・復旧見込み：現在確認中です。復旧時刻は未定です。
当面の対応：○○業務は指定の仮受付票へ記録してください。確定処理は○○責任者の判断を受けてください。結果が不明な登録・送信は繰り返さず、担当者へ連絡してください。
問い合わせ先：○○担当／電話○○
次回案内：○時○分。新情報がない場合も状況をお知らせします。
取引先への影響がある場合は、連絡担当と説明内容も統一します。「いつ復旧するか」を無理に約束せず、受け付けられる内容と、次に回答する時刻を伝えます。
障害対応中に、むやみに設定を変えない
サービス側の障害であれば、端末の設定変更では解消しないことがあります。調査内容を記録せずに変更を重ねると、元の問題と変更による問題を区別しにくくなります。
- 処理結果を確認せず、登録・送信・支払いを繰り返さない
- 原因を確認せず、アカウントの削除・再作成や同期解除を行わない
- 代替の保存先やサービスは、承認されたものを使う
- 変更が必要な場合は、内容・時刻・実施者と元に戻す方法を記録する
不審なログイン、情報の改ざん、ウイルス対策ソフトの警告などがある場合は、通常の障害対応からセキュリティ対応へ切り替えます。自社端末の感染が疑われる場合と、サービス提供者側の障害では、対応対象が異なります。責任者や保守業者と連携し、被害の拡大防止と記録の保全を進めてください。
IPAの「中小企業のためのセキュリティインシデント対応の手引き」も、原因不明の停止ではセキュリティ上の問題を含めて対応し、代替策を検討する考え方を示しています。
「復旧しました」の後に確認すること
サービス提供者の復旧案内を確認したら、自社の業務でも正常に使えるかを確かめます。仮記録を急いで戻す前に、停止前後の処理結果を照合しましょう。
| 確認項目 | 具体的な確認内容 |
|---|---|
| 必要な機能 | 閲覧・保存・送受信・検索・外部連携が正常に動くか |
| 停止直前の処理 | 入力途中・送信途中の申請や注文が登録済みか |
| データの欠落・重複 | 件数・連番・処理履歴に抜けや二重登録がないか |
| 仮記録の反映 | 照合してから登録し、反映済みの印と担当者を残したか |
| 通常運用への切替 | 切替時刻と残っている未処理を全員に知らせたか |
仮記録は、登録済みデータと照合してから戻す
障害中の処理が遅れて反映される場合もあるため、紙やExcelの内容をそのまま一括登録しないようにします。受付番号や申請者、日時などで照合し、未登録のものだけを反映します。反映済みの仮記録も、社内の保管ルールに沿って残してください。
通常運用へ戻す時刻をそろえる
「14時以降は通常のシステムへ入力。14時までの仮記録は担当者が反映」のように境界を決めます。紙とシステムへの二重記録が続くのを防ぎ、未処理一覧は担当者へ引き継ぎます。
次の障害に備える「クラウド停止対応表」を作る
サービス別対応表・障害対応記録・復旧確認表をまとめたExcelのひな形を用意しました。例示行を自社の内容に変更してご利用ください。
クラウド停止対応チェック表をダウンロード（Excel・無料）
平時の準備は、よく使うサービスを3つ挙げるところから始められます。サービスごとに、止まる業務と代替手段を記入してください。契約先の問い合わせ窓口だけでなく、社内で誰が業務の判断をするかも必要です。
| 対応表 | 記入する項目 |
|---|---|
| サービス別対応表 | サービス名、利用業務、公式障害確認先、社内・契約先の連絡先、許容停止時間、代替手段、判断者 |
| 障害対応記録 | 確認時刻、影響、公式情報、対応内容、担当者・判断者、次回更新時刻 |
| 復旧確認表 | 必要な機能、欠落・重複、仮記録の反映、未処理の引継ぎ、通常運用への切替 |
許容停止時間は「何時間まで止められるか」、復元が必要な業務では「どの時点のデータまで戻せればよいか」を部門と話し合います。予備の保存先やエクスポートがあっても、取り出して使えるかを試しておく必要があります。
対応表と主要な連絡先は、停止する可能性のあるクラウド以外からも参照できるようにします。紙や会社管理の端末への保存など、情報の機密性に合った保管方法を決めてください。
システムと保存情報を整理する段階から始めたい場合は、情報資産台帳の作り方とシステム総点検も参考になります。台帳で把握したサービスに、障害時の担当者と代替運用を追加すると、初動に使いやすくなります。
まとめ：止められない業務を1つ選び、代替手段を決める
クラウド障害では、影響を確認して連絡し、重要な業務から代替運用へ移すことが最初の仕事です。復旧後は、仮記録とシステムのデータを照合し、通常運用へ戻す時刻をそろえます。
まずは止められない業務を1つ選び、代替手段・担当者・記録先を決めておくことから始めてみてください。サービスが使えない状態を想定して、その手順で実際に仕事が続けられるか確認すると、足りない準備が見えてきます。
