停電・通信障害・システム停止で業務が止まったら？BCPの法務対応

システムが止まったら、会社は何から確認する？

結論から言うと、最初に確認すべきは「どのシステムが止まったか」ではなく「どの重要業務が止まるか」です。

情報システム部門からは「サーバーAが停止」「データベースBに接続できない」といった報告が上がります。技術的には正確でも、経営判断にはそのままでは使えません。法務・BCP担当者が知りたいのは、「それで、今日の出荷は止まるのか」「17時の通知は送れるのか」「支払は実行できるのか」です。

システム停止時の対応は、おおむね次の流れで整理できます。

ポイントは、②の原因調査が終わるまで③以降を止めないことです。原因の特定に半日かかることは珍しくありません。その間も、重要業務の継続判断は進める必要があります。初動全体の考え方は第5話（災害直後の初動）もあわせて確認してください。

IT復旧と事業継続は同じではない

例えば、販売管理システムの復旧に8時間かかるとします。一方で、重要顧客への出荷は2時間以内に継続しなければなりません。この場合、「8時間待つ」ではBCPになりません。

そこで、事前に出力した顧客一覧や紙の出荷指示書、電話での確認、予備端末、別拠点、手作業などを組み合わせ、重要業務だけでも継続する方法を検討します。

内閣府の「事業継続ガイドライン」（令和5年3月版）も、重要業務を特定し、目標復旧時間内に再開させるという考え方を基本にしています。同ガイドラインの令和5年改定では、テレワークの活用やオンラインでの意思決定の仕組み、情報セキュリティの強化にも言及が加えられました。システム停止は、まさにこうした「平時の仕組み」が試される場面です。

システム停止を6種類に分ける

システムが止まった直後は、原因がわからないことがほとんどです。そこでLegalGPTでは、「どの代替策を発動するか」を決めるための整理として、システム停止を次の6種類に分けています。政府の正式な分類ではありません。また、原因調査のための分類でもありません。

表は横にスクロールできます →

実際の事案では複数が重なります。停電がきっかけで通信機器が落ち、認証基盤も止まる、といった具合です。また、最初は④に見えた停止が、調査の結果⑥だったということもあります。最初は「原因不明のシステム停止」として扱い、原因調査と事業継続対応を並行させるのが基本です。

重要業務とシステムの依存関係を見える化する

第2話で解説したBIA（事業影響度分析）で重要業務を特定したら、次はその業務がどのシステムに依存しているかを紐付けます。

例えば「当日出荷」という重要業務は、受注システム、在庫システム、WMS（倉庫管理システム）、送り状発行システム、承認フローに依存しているかもしれません。このうちWMSだけが止まったなら、「在庫の引当と棚の特定を手作業で代替できるか」が問いになります。

表は横にスクロールできます →

このマップがあれば、障害報告を受けた瞬間に「どの重要業務に波及するか」を逆引きできます。反対に、マップがない会社では、障害のたびに「このシステムは何に使っているのか」を調べるところから始まり、初動が遅れます。

RTO・RLO・RPOをどう使い分ける？

第2話で扱った指標に、IT-BCPでよく使うRPOを加えて整理します。

表は横にスクロールできます →

例えば「RTO＝4時間、RPO＝前日23時、RLO＝受注業務の50％」といった組合せが考えられます。ただし、これは説明のための例示であり、標準値ではありません。

重要なのは、「システムの100％復旧」だけをBCPのゴールにしないことです。完全なシステム復旧には8時間かかっても、重要顧客向け出荷を手作業で30％だけ2時間以内に再開する、という設計は十分にあり得ます。RTOとRLOは、システムではなく業務を単位に設定するのが出発点です。

また、RPOは法務にとっても無関係ではありません。前日23時のバックアップに戻れば、当日朝に受けた注文や、当日発行した請求書のデータは失われます。「失われた時間帯に何の取引・通知があったか」を別の手段で再構成できるかは、後の紛争対応にも影響します。

バックアップがあれば安心？

「バックアップは取っています」は、BCPの説明として最もよく聞く言葉の一つです。IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」（2026年3月27日公開）でも、最初に取り組む基本対策に「バックアップを取ろう！」が追加され、従来の5か条が6か条になりました。バックアップの重要性は明らかです。

しかし、バックアップがあることと、復旧できることは別です。最低限、次の点を確認します。

• どこに保管されているか（本番環境と分離されているか）
• いつ時点のものか（RPOを満たすか）
• バックアップ自体が破損・暗号化されていないか
• 復元手順が文書化されているか、誰が復元権限を持つか
• 復元に何時間かかるか（RTOに間に合うか）
• 実際に復元テストをしたことがあるか

さらにランサムウェア等の場合、バックアップから復元しても、攻撃者の侵入経路やマルウェアが残っていれば再び被害を受けるおそれがあります。つまり、復元できることと、安全に復旧できることも別です。なお、同ガイドラインは中小企業等を想定した資料であり、記載事項がすべての企業に法的義務として課されているわけではありません。ただ、実務上の目安としては規模を問わず参考になります。

電子決裁が止まったらどうする？

電子決裁システムが止まったとき、「決裁できないので何もできない」は誤りです。一方で、「緊急だから誰が決めてもよい」も誤りです。

必要なのは、平時から次の事項を規程で決めておくことです。

• システム停止時に使える代替決裁手段（メール、電話、紙の決裁書など）
• 代替手段を使える案件の範囲（金額、緊急性）
• 決裁者不在時の代行順位と代行権限
• 口頭承認をした場合の事後記録と、システム復旧後の正式登録

代表権・代理権・社内決裁の違いと代行順位は第3話で詳しく扱っています。社内決裁は会社内部の意思決定手続であり、取引の相手方との関係では、署名・押印する人に代表権や代理権があるかが別途問題になる点に注意してください。

緊急時の承認は、次のようなログで管理します。

表は横にスクロールできます →

ポイントは「事後登録」の列です。システム復旧後に正式な決裁システムへ登録し、電話メモやSMSのスクリーンショットを証跡として添付します。これを怠ると、同じ案件について別の担当者がシステム上で再度決裁を申請し、二重承認・二重発注が起きます。

メール・電子契約が使えない場合

第9話では、取引先への第一報・正式通知・到達（民法97条）・変更合意を扱いました。本記事で扱うのは、その前提となる通常の連絡手段そのものが使えない場合です。

メールが止まった場合

メールだけを唯一の連絡手段にしないことが基本です。代替手段としては、携帯電話、SMS、あらかじめ用意した別ドメインのメール、緊急連絡システム、Web会議、取引先ポータルなどが考えられます。

ただし、契約書で通知方法が「書面」や「指定のメールアドレス」に限定されている場合、代替手段で送った連絡が契約上の正式通知として扱われるとは限りません。代替手段で第一報を入れつつ、契約が定める方法での正式通知をどう確保するかを並行して検討します。

また、会社のシステムが使えないからといって、私物のSNSや個人メール、個人クラウドを無制限に使ってよいわけではありません。この点は第11話で詳しく扱います。

電子契約サービスが止まった場合

電子契約サービスが停止しても、ただちに「契約を一切締結できない」とは限りません。確認すべきは次の点です。

• 基本契約等が締結方式を限定していないか
• 法令上、書面や特定の方式が求められる契約ではないか
• 紙の契約書、別の電子署名サービス等で締結できるか
• 署名者に権限があるか

クラウド・SaaSが止まった場合

自社のサーバーが無事でも、クラウドやSaaSが止まれば業務は止まります。CRM、ERP、勤怠、会計、ストレージ、電子契約など、いまや重要業務の多くが外部サービスの上で動いています。「クラウドだからBCPは不要」ではありません。

クラウド契約で確認する事項

平時に、少なくとも次の点を利用規約・契約書・SLA（サービス品質保証）で確認しておきます。

• 稼働率の保証水準と、その算定方法
• 障害時の通知方法と、ステータスページの有無
• サポート窓口（重大障害時・夜間休日の窓口）
• 復旧目標の有無と、その法的位置付け（保証か努力目標か）
• バックアップの責任分担（事業者が取るのか、利用者が取るのか）
• データのエクスポート方法
• 再委託先、データの保管場所
• サービス終了時のデータ返還
• 責任制限条項、不可抗力条項、サービスクレジット（SLA未達時の利用料減額）

SLA未達時にサービスクレジットや利用料減額が定められているサービスもありますが、それが自社の売上損失や顧客への納期遅延まで補償するとは限りません。

ベンダーのRTOと自社RTOを比較する

最も重要なのは、自社の重要業務のRTOと、ベンダーの復旧目標を並べて比較することです。例えば、自社の重要業務のRTOが4時間なのに、ベンダーの契約上・公表上の復旧目標が24時間であれば、そのままでは自社BCPは成り立ちません。

この差を埋めるために、代替サービス、ローカルに保存したデータ、手作業、別ルート、冗長構成などを検討します。ただし、すべてのサービスに冗長化やマルチクラウドを求める必要はありません。業務の重要度とコストを比べて判断します。

ベンダーへのエスカレーション

障害発生後に「担当営業の携帯番号しかわからない」という状態は避けるべきです。通常サポート窓口、重大障害窓口、24時間窓口、セキュリティ窓口を平時に確認し、連絡先一覧を定期的に更新します。IPAのプラクティス・ナビでも、組織内外の連絡先の定期的なメンテナンスが実践例として取り上げられています。

ベンダーからは、障害発生時刻、影響範囲、原因、復旧見込み、暫定回避策、データへの影響、次回の更新時刻を聞き取り、記録します。

システム停止でも法定期限・契約期限が自動的に延長されるとは限らない

企業法務として特に注意すべき点です。社内システムやクラウド、行政の電子申請システムが使えなくても、法令上・契約上の期限が自動的に延長されるとは限りません。

法定期限・行政期限

行政への申請・届出、登記、税務申告、社内機関の決定などには期限があります。期限延長の制度がある分野もありますが、延長の可否や手続は根拠法令ごとに異なります。

例えば国税については、国税通則法11条が災害その他やむを得ない理由による期限延長を定めています。しかし、延長は地域・対象者の指定や個別の申請によって認められる仕組みであり、何もしなくても当然に延びるわけではありません。実際、2022年3月14日からe-Taxで接続障害が発生した際、国税庁は、障害により期限内の申告等が困難な場合に個別に申告期限等を延長することとし、申告書等に「e-Taxの障害による申告・納付期限延長申請」である旨を記載する方法を案内しました。延長できる期間は同年4月15日までとされ、個人事業者の消費税は延長の対象外とされました。

システム障害で期限に間に合いそうにないときは、次の点を確認します。

• 根拠法令と、期限延長の制度の有無
• 所管行政機関による障害時の案内
• 郵送・窓口など代替提出方法
• 提出を試みた記録（画面、エラー表示、時刻）

許認可や行政報告の個別論点は第12話で扱います。

契約上の期限

契約上の通知期限、更新拒絶の期限、解除通知の期限、請求期限も同じです。「システムが使えなかったから当然に延長される」とは限りません。第9話で扱った通知条項を確認し、代替方法による通知、到達の確保、相手方との協議を検討します。債務不履行や不可抗力との関係は第8話を参照してください。

手作業へ切り替えるときの注意

システムが止まれば、紙・Excel・電話で業務を続けることになります。しかし手作業には、承認漏れ、重複発注、二重支払、二重出荷、入力ミス、個人情報の紛失、監査証跡の欠落といったリスクが伴います。

そこで、緊急時の手作業にも最低限の統制を設けます。

1. 通し番号：手作業で処理した伝票・指示書に連番を振る
2. 承認者：誰が承認したかを記録する
3. 日時：処理日時を記録する
4. 原本管理：紙の原本の保管場所と担当を決める
5. 二重処理防止：同じ案件をシステムと手作業で並行処理しない
6. 復旧後の入力担当：誰がシステムへ取り込むかを決める
7. 照合担当：入力担当とは別の人が突合する

危ないのは復旧後の「二重処理」

障害中に紙で発注し、復旧後にシステムへ入力したところ、別の担当者がすでに入力していて二重発注になった。こうした事故は、障害の最中よりも復旧直後に起こります。

そのため、復旧時には、手作業分の一件一件について「未処理」「手作業済み」「システム登録済み」「取消済み」のどれに当たるかを照合する手順が必要です。この復旧後の突合までを、BCPの範囲に含めてください。

サイバー攻撃の可能性がある場合

システム停止の原因がランサムウェアや不正アクセスと判明した場合、またはそれを合理的に疑う事情がある場合は、単純な設備障害への対応からセキュリティインシデント対応へ切り替えます。

「復旧を急ぐ」と「証拠を壊さない」を両立する

攻撃が疑われる状況で、とにかく再起動・初期化・バックアップからの復元を行うと、侵入経路や被害範囲を調べるための記録（ログ等）が失われるおそれがあります。原因がわからないまま復元すれば、再び同じ攻撃を受ける可能性もあります。

情報システム・セキュリティ担当者、必要に応じて外部の専門家と連携し、被害拡大の防止（感染した端末のネットワークからの切り離しなど）、ログ等の保全、原因調査、安全な復旧を両立させます。ただし、「攻撃が疑われたら必ず全システムを停止する」と一律に決める必要はありません。どこまで止めるかは、影響の大きさと専門的な判断によります。

経済産業省・IPAの「サイバーセキュリティ経営ガイドライン Ver3.0」は、経営者が指示すべき重要10項目の一つに指示8「インシデントによる被害に備えた事業継続・復旧体制の整備」を掲げています。IPAが2026年4月28日に公開した指示8の実践ナビでは、業務停止時にいつまでに復旧すべきかの特定、復旧手順と体制の整備、既存BCPとの連携、サプライチェーンも含めた実践的な演習が示されています。ファーストステップとして、自然災害BCPの担当チームとインシデント対応チームの情報共有、影響度に応じた復旧判断の基準とフローの整備、優先度の高いシステムの復旧手順を演習で確認することが挙げられています。

システム停止＝個人情報漏えい、ではない

単にシステムにアクセスできないことだけで、ただちに個人情報保護法上の漏えい等報告義務が生じるわけではありません。一方で、ランサムウェア等によって個人データが暗号化され、復元できなくなった場合は、個人データの「滅失」や「毀損」として、漏えい等報告（個人情報保護法26条）の対象になり得ます。個人情報保護委員会も、報告対象の例としてこのケースを挙げています。

そのため、原因がサイバー攻撃等である場合は、個人データの漏えい・滅失・毀損、またはそのおそれがないかを確認し、該当すれば報告・本人通知を検討します。報告には速報・確報の期限があるため、確認は早めに始めます。なお、ランサムウェア事案については、2025年10月1日以降、関係省庁の申合せに基づく共通様式で個人情報保護委員会へ報告することもできます。

外部へ原因を断定しない

原因調査中に、「クラウド事業者の障害です」「サイバー攻撃です」「当社に責任はありません」と外部へ断定するのは避けます。後で原因が異なると判明した場合、訂正が必要になり、信頼を損ないます。第一報では、確認できている事実、影響、復旧見込み、代替対応、次回の更新予定を中心に伝えます。

ケース｜ERP・メール・電子決裁が同時に止まった会社

9:05〜9:30｜影響を「業務」の言葉に置き換える

障害の発生を確認し、停止したシステムを洗い出します。同時に、依存関係マップを使って「ERPが止まった」を「B社14時出荷と17時の契約通知に影響する」という業務の言葉に置き換えます。対策本部またはITインシデント対応体制を立ち上げ、連絡は携帯電話に切り替えます。原因は決めつけず、ログの保全を情報システム部門に依頼します。

9:30〜10:30｜代替手段の発動

B社向け出荷を手作業で継続できるか、事前出力した注文情報や在庫の実地確認で検討します。出荷判断に必要な承認は、規程上の代替決裁手続で行い、暫定承認ログに記録します。17時の契約通知は、契約の通知条項を確認し、書面や相手方の指定窓口など代替の送信方法を準備します。クラウドベンダーには重大障害窓口からエスカレーションし、次回の復旧見込みの連絡時刻を確認します。

10:30｜不正アクセスの可能性

ここで「すぐにバックアップから戻す」は避けます。セキュリティ担当者と連携し、影響範囲、隔離の要否、ログ等の保存、個人データへの影響、安全な復旧方法を確認します。前日23時のバックアップが攻撃の影響を受けていないかも確認が必要です。

一方で、B社への14時出荷のBCP対応は並行して進めます。原因調査が終わるまで、すべての事業判断を止めるわけではありません。

14:00｜出荷判断

事前出力の注文情報、在庫の実地確認、二名による承認、紙の出荷番号を使った暫定運用で出荷します。ただし、品質・数量・承認を確認できない場合は、無理に出荷しない判断もあり得ます。その場合は第9話の手順でB社へ連絡します。BCPは「必ず業務を続けるための計画」ではなく、続けるか止めるかを適切に判断するための計画です。

復旧後｜突合と振り返り

システムの安全性が確認され復旧した後、紙の処理、代替メール、電話承認、手作業の出荷をシステムに反映します。二重処理を防ぐため、一件ずつ照合します。その後、障害記録、実際の復旧時間と目標との差、問題点を振り返り、BCPを見直します。

システム障害対応ログ

障害対応中は、判断と事実を時系列で記録します。後で「いつ、誰が、何を知って、どう判断したか」を説明できるようにするためです。

表は横にスクロールできます →

「状況」欄は、未確認／調査中／停止／一部利用可／代替運用／復旧確認中／復旧済から選ぶ形にすると、関係者間で状態の認識がずれにくくなります。記録すべき項目としては、ほかに発見時刻、原因不明だった期間、顧客への連絡、復旧時刻、復旧確認の結果があります。保険請求や損害賠償に備えた証拠保存全般は第13話で扱います。

復旧確認チェックリスト

ログインできたからといって、業務が復旧したとは限りません。データが欠けていないか、連携先のシステムに正しく流れているか、手作業分と重複していないかを確認して初めて「復旧」と言えます。「復旧宣言」の基準は平時に決めておきます。

• ログインできる
• 必要なデータが存在する
• データの欠損がない（RPO以降の失われたデータを特定済み）
• 他システムとの連携・夜間の一括処理が正常に動く
• 手作業で処理した分との突合が完了した
• 二重発注・二重支払・二重出荷がない
• 権限設定が障害前と同じ（障害対応で付与した臨時権限を戻した）
• セキュリティ上の安全性を確認した
• 顧客・利用者へ復旧を案内した
• 障害ログ・判断記録を保存した

LegalGPTによる簡易チェックリストです。業種・システム構成に応じて調整してください。

平時に作るシステム停止BCP

最低限、次のものを用意します。

• 重要業務・システム依存関係マップ（RTO・RLO、必要に応じてRPO）
• 復旧優先順位（IT部門が直しやすい順ではなく、重要業務への影響の順）
• バックアップと復元テストの記録
• 代替通信手段と、ベンダーを含む緊急連絡先一覧
• 代替決裁の規程と暫定承認ログの様式
• 業務ごとの手作業手順と、復旧後の突合手順
• 顧客・取引先への連絡方法（第9話の通知先一覧と連動）
• システム障害対応ログと復旧確認チェックリスト

復旧優先順位は、例えば「①安全・設備制御、②受注・出荷等の重要業務、③顧客・取引先との通信、④契約・決裁等の重要管理業務、⑤その他」といった考え方がありますが、業種や企業によって順番は変わります。

演習で「本当にできるか」を確かめる

「バックアップがあります」「手作業でできます」は、試すまでわかりません。メール停止、ERP停止、クラウド停止、電子決裁停止を想定し、例えば「ERPを使わずに重要顧客へ出荷できるか」を実際に試してください。前述の指示8の実践ナビも、対象をIT部門や社内に限定せず、サプライチェーンを含めた実践的な演習を求めています。法務は、演習のシナリオに「17時の契約通知」「行政への届出期限」を組み込むことで、自らの役割を確認できます。

よくある失敗

表は横にスクロールできます →

FAQ

まとめ

最後に、次の問題を考えてみてください。システムが止まると、現場では「会社のPCが使えないなら自宅のPCで」「会社のメールが使えないなら個人のGmailで」「USBメモリでデータを持ち出して作業しよう」という行動が起こりやすくなります。緊急時であれば、こうした例外的な利用を認めて情報管理のルールを緩めてよいのでしょうか。

次回の第11話では、この問いを取り上げます。

シリーズ全体を一覧で点検したい方は、第15話｜企業法務BCPチェックリストをご覧ください。