台風でも業務を止めないDX｜72時間前の対策と仕組み

台風接近時にまず最優先すべきは従業員の安全です。そのうえで「すべてを通常どおり続ける」ことを目指すのではなく、顧客・売上・法令対応に直結する“重要業務”の中断を最小限に抑え、短時間で復旧する体制を作ることが目的です。本記事では、72時間前を目安にできる現場で使えるチェックリスト、優先するDX施策、停電・通信障害や担当者不在への代替手順、平常時の訓練まで、実務的にまとめます。

導入の結論（端的な回答）

台風で業務を止めないためには、紙・押印・オフィス内専用システムを見直し、①重要業務の選定、②社外からの安全なアクセス（多要素認証・端末管理等）、③代理承認と代行ルール、④緊急連絡の一元化、⑤停電・通信障害時の代替手段をセットで準備することが必要です。

台風時に業務が止まる6つの原因

台風によって業務が停止する原因は単なる「出社できない」だけではありません。代表的な6つを整理します。

1. 公共交通機関の停止で出社が困難になる

計画運休や道路規制により従業員が出社できず、オフィス依存の業務が止まります。発令基準と発令者をあらかじめ定めましょう（例は後述）。

2. 紙・押印・郵送に依存して承認が滞る

稟議書や契約書の押印フローがオフィス前提だと、担当不在で決済できません。電子化だけでなく、代理承認・簡易承認ルールを併せて整備します。

3. 社内サーバー・固定電話に依存している

オンプレミスのシステムや代表番号の電話対応がオフィスでしか動かないと顧客対応が止まります。クラウド化と代表電話の転送・クラウドPBXが有効です。

4. 業務が特定担当者に属人化している

パスワードやノウハウが個人に閉じていると、担当者不在で処理不能になります。業務の棚卸と代理者の事前指定が必須です。

5. 停電や通信障害でクラウドも使えなくなる

クラウド化だけでは自宅側や拠点の停電・回線断をカバーできません。予備電源、複数キャリア回線、オフライン参照資料の設計が必要です。

6. 切り替え基準や判断者が未整備

在宅勤務や休業に切り替える判断基準が曖昧だと発令が遅れ、従業員の安全や業務の無駄な継続につながります。事前に条件・発令者・通知手段を定めておきましょう。

最初にやるべき：継続すべき重要業務の洗い出し

まずは「全部守る」ではなく、「どれを最優先で継続するか」を業務単位で決めます。以下の手順で実施してください。

ステップ1：業務を3区分に分ける

• 止められない：顧客対応、受発注、決済、法定期限がある業務など
• 短期間なら止められる：内部会議、定例報告、一部の事務処理など
• 停止してよい：長期的な資料作成、イベント準備など

ステップ2：RTOとRPOを定義する（初めての方へ）

RTO（目標復旧時間）：その業務を何時間以内に再開する必要があるか。
RPO（目標復旧時点）：障害発生時にどの時点までのデータ（何時間前まで）を確保できれば良いか。

例：受注業務のRTOを4時間、RPOを1時間に設定すると「4時間以内に業務を再開し、最大でも1時間分の受注データの欠損にとどめる」ことを目標にします。

ステップ3：出社前提の工程を明確化

押印・現金決済・専用端末・対面確認など、出社しないとできない工程を列挙します。可能な工程は電子化・代理化を検討します。

ステップ4：業務一覧に担当・代理・代替手段を登録

最低限のテンプレ項目：業務名／優先度（RTO）／主担当／代理担当／承認者／必要データ／代替手段／復旧手順。テンプレート化して台風シーズン前に更新しましょう。

72時間前から使える業務継続チェックリスト（ステップ・バイ・ステップ）

72時間は目安です。台風の進路・勢力や交通情報によっては前倒しが必要になります。以下を参考に、社内ルールに落とし込んでください。

72〜48時間前に確認すること（優先）

• 気象庁の台風・防災気象情報を定期確認する（気象庁：https://www.jma.go.jp/bosai/）。
• 交通事業者の計画運休情報を確認する（鉄道・バス各社の公式情報）。
• 在宅勤務切替の発令基準と発令者を経営層で最終確認する（例：計画運休発表時、暴風警報発表時など）。
• 重要業務リストを最終確定し、主担当と代理担当へ通知する。
• 従業員へPC・モバイル端末の持ち帰りと充電器準備を指示する。
• 緊急連絡網と安否確認システム（テスト送信）を実行し、応答状況を確認する。
• 重要データの最新バックアップ状況を確認（復元可能か担当が確認）。
• 顧客・取引先向けの案内テンプレート（遅延・休業・対応窓口）を用意する。

48〜24時間前に確認すること（接続と権限）

• 代理承認者に必要な権限を付与（事前通知）し、承認フローの簡略化ルールを適用可能にする。
• 各部門の代表利用者が社外からログインして「ログイン→データ参照→申請→承認」まで実行できるかテストする。情報システムは認証・接続ログを確認する。
• 代表電話の転送やクラウドPBXの設定を確認する。
• 処理が必要な紙書類は優先度別に電子化／例外対応を決める。
• 未処理の申請・請求・受発注を洗い出し、重要度順にリスト化する。
• 従業員の安否確認連絡先・居所（業務上必要な範囲）を更新。ただし位置情報の収集は利用目的と保存期間を明確にし最小限にする。
• モバイルバッテリー・予備端末の配備と配布計画を確認する。

24時間前〜接近中に行うこと（運用へ切替）

• 在宅勤務・休業・時差出勤などの方針を一斉通知（発令者名を明記）。
• 連絡手段をビジネスチャットやヘルプデスクのチケットへ切り替え、電話依存を減らす。
• 安否と稼働可否を重点担当から順に確認し、未応答はエスカレーションする。
• 重要業務へ人的リソースを集中し、不要不急の対応は延期する。
• 顧客・取引先へ重要な変更がある場合に通知する（連絡過多を避ける）。

通過後に行うこと（復旧と振り返り）

• 拠点・従業員・設備・システムの被害状況を一次確認する。安全最優先で出社は段階的に。
• 未処理業務を一覧化し、顧客影響度に応じて対応順を決定する。
• 発生事象・対応履歴を記録し、BCPと運用ルールに反映する（改善担当と期限を設定）。

台風でも業務を止めにくくする7つのDX施策（実行優先例）

以下は一般例です。自社の停止時損失や予算によって優先順位は変わります。

1. クラウド化と安全な社外アクセスの設計

ファイルや業務システムをクラウドに移行するだけでなく、次を組み合わせて運用設計を行います：多要素認証（MFA）、端末管理（MDM）、接続元の制御（IP制限等）、アクセスログの監視。企業によってはVPNとゼロトラスト型アクセスを併用します。設計例：重要情報は社内PC（MDM登録）からのみアクセス可、個人端末は閲覧限定。

2. 電子申請・電子承認・電子契約の運用ルール化

稟議・経費・契約を電子化するとともに、代理承認ルール、緊急時の承認簡略化、承認有効期限を設定します。電子帳簿保存法など法令要件も確認してください（国税庁：https://www.nta.go.jp/）。

3. 安否確認と緊急連絡の一元化

チャットと安否確認システムを連携し、「所在」「安否」「業務可否」を分けて把握します。未回答者への自動リマインドや、管理者による電話フォローのエスカレーションを設計します。

4. 業務マニュアルとナレッジの共有

クラウド上で業務手順（誰が何をするか、代行手順、ログイン手順）を公開し、更新責任者と最終更新日を明記します。災害時の操作は簡易フローにしておくこと。

5. 顧客対応を場所に依存させない仕組み

CRMで顧客情報と対応履歴を共有、クラウドPBXや転送で代表番号を外部で受電可能にします。問い合わせはチケット化して優先度を付け、担当不在時の代替対応ルールを明確化します。

6. バックアップと復旧手順の強化

多世代のバックアップを遠隔地に保管し、復元テストを定期実施します。ランサムウェア対策としてバックアップは本番環境とは別の認証で管理し、復旧担当者と手順を文書化します。

7. 予備電源・予備回線・予備端末の準備

拠点用のUPS、従業員向けのモバイルバッテリー、モバイルルーター、複数キャリア契約を組み合わせます。何を優先的に稼働させるか運用リストを作成しておきます。

クラウド化だけでは台風対策にならない理由（運用設計の重要性）

• 判断者が不在なら切り替えできない：発令者と代行順位を明確化。
• アクセスしても権限がなければ処理不可：代理承認と緊急権限の設計が必要。
• 通信・電源が止まればクラウドも使えない：オフライン参照資料や電話代替を用意。
• 現場が操作できなければ機能しない：平常時から同じツールを使い訓練する。

停電・通信障害・担当者不在への具体的な備え

重要：代替手段は「誰が、いつ、どのトリガーで切り替えるか」まで決めておくこと。これが運用設計の肝です。

災害時リモートワークのセキュリティ対策（現実的運用）

• 全員に多要素認証（MFA）を必須化。管理者権限は優先的に保護。
• 業務端末は暗号化、画面ロック、MDM登録。紛失時の遠隔消去を可能にする。
• 公衆Wi‑Fiは原則で機密情報扱い不可。やむを得ない場合はVPN必須、接続ログを残す。
• 緊急連絡を装ったフィッシングに注意。平常時から訓練（フィッシングテスト）を行う。
• 緊急権限は有効期限を設け、使用履歴をログで残し、台風通過後に見直す。

中小企業の優先導入順（短期〜中長期）

投資優先は「停止時の損失（顧客影響、売上、法令罰則、安全）」で決めます。

第1段階（即時〜数週間）

• 緊急連絡手段の統一（チャット＋安否システム）、重要データのバックアップ確認
• 代理責任者・代理承認者の決定、端末持ち帰りルールの周知
• 顧客向けのテンプレ案内文の準備

第2段階（1〜3ヶ月）

• クラウドストレージ、電子申請・承認システムの導入
• 業務マニュアルのクラウド共有、CRM/問い合わせ管理の整備
• MFA導入、モバイル回線や予備電源の配備

第3段階（中長期）

• 回線冗長化、システム冗長化、ゼロトラスト設計
• RPAや自動化による定型業務の軽減、全社BCP訓練の定期実施
• 監視体制と復旧チームの常時設置

業種別の実例（短いケーススタディ）

事例（匿名・実績） — 中堅物流会社の改善例

ある中堅物流会社（匿名）は、台風シーズンに度々代表番号へ着信集中が起き、配送遅延の連絡対応が遅れていました。対策としてクラウドPBX導入、CRMで配送状況を共有、顧客へ自動通知を設定したところ、台風時の初動での顧客問い合わせ対応時間が平均で約5時間短縮、安否確認の一次回答率が70%から95%に向上しました（弊社支援の訓練・導入効果による実測・匿名データ）。

設計のポイント（製造・小売・建設）

• 製造：受発注と在庫を遠隔確認できるようにし、工場停止判断者と手順を明文化。
• 小売：店舗別の営業状況を本部で一元管理、SNSやWebで営業時間を自動発信。
• 建設：現場の安全確認は写真＋クラウド共有で行い、作業中止基準を明確化。

平常時に行う訓練と見直し

訓練は年1回ではなく、台風シーズン前に必ず実施しましょう。訓練では「できたか」だけでなく、実測時間（連絡完了時間、復旧時間、代理承認切替時間）を測ることが重要です。通過後は遅延原因や権限不足を洗い出し、改善担当と期限を設定して運用ルールへ反映します。

よくある質問（FAQ）

Q. 台風対策で最初にDX化すべき業務は？

A. 緊急連絡（安否・所在）、承認（電子申請・代理承認）、顧客対応（CRM・受発注）と、重要データへのアクセスを優先します。停止した場合の損失が大きい業務から順に対応してください。

Q. クラウド化すれば台風時も安心ですか？

A. 部分的には有効ですが不十分です。社外アクセスの認証（MFA）、端末管理、代理権限、予備回線、バックアップ、そして「誰がいつ切り替えるか」の運用設計が必要です。

Q. 在宅勤務へはいつ切り替えるべきですか？

A. 気象庁の防災気象情報、公共交通機関の計画運休、自治体の避難情報、従業員の居住地域と通勤ルートを踏まえて判断します。判断基準・発令者・通知方法は平常時に明文化しておくことが重要です。従業員の安全が確保できない場合は、業務継続より休業を優先してください。

参考リンク（公的情報）

• 気象庁（台風・防災気象情報）：https://www.jma.go.jp/bosai/
• 内閣府（事業継続ガイドライン、防災）：https://www.bousai.go.jp/
• 中小企業庁（BCP関連）：https://www.chusho.meti.go.jp/
• 総務省（テレワークセキュリティ等）：https://www.soumu.go.jp/
• IPA（情報セキュリティ、フィッシング対策）：https://www.ipa.go.jp/
• 国税庁（電子帳簿保存法）：https://www.nta.go.jp/

まとめと次の一手（実践チェック）

台風に強いDXは「単にクラウド化すること」ではなく、重要業務の選定、判断者と代理者、社外アクセスと端末管理、代替回線・電源、そして訓練を一体で設計することです。まずは今週中に以下3つを決定してください：

1. 在宅勤務切替の発令基準と発令者
2. 重要業務リスト（RTOと代理担当を含む）
3. 緊急連絡・安否確認のテスト実施日時