BCP初動とは？ 企業を止める会社と止めない会社の決定的な違い
2026/06/02.
──「安否確認の完了」がゴールだと思っている企業へ
BCPは、計画書ではありません。BCPの成否を分けるのは、初動速度です。日本の物流動脈・静岡県で生まれた実戦型BCP設計の視点から、「企業を止めない6時間」の設計思想を解説します。
- 「どの拠点が今日、稼働できるのか」
- 「誰が出社できるのか。何人、いつ来られるのか」
- 「物流は動いているのか。どのルートが止まっているのか」
- 「代替拠点へ切り替えるべきか。判断の根拠はあるか」
- 「顧客への連絡を、誰が、いつ、どの優先順位で行うのか」
この5つに6時間以内に答えられる企業は、事業を止めません。
答えられない企業は、安否確認が完了していても、事業が止まります。
実際の災害で企業を止めるのは、計画不足ではありません。「初動の遅れ」です。
index
- 1.BCP初動とは24時間以内の意思決定プロセス
- 2.日本の災害リスクと初動遅延の実態
- 3.なぜ「安否確認の完了」はBCP初動のゴールではないのか
- 4.災害対策本部とは「意思決定OS」である
- 5.企業を止める会社と止めない会社 理論型BCPと実戦型BCPの違い
- 6.BCP初動で対策本部が把握すべき5つの情報
- 7.BCP初動成熟度モデル自社はどのレベルか
- 8.南海トラフ時代の「静岡モデル」 実戦型BCPが生まれた場所
- 9.対策本部OSとして機能するための8つの設計要件
- 10.「安否確認システム」から「BCP初動プラットフォーム」へ
- 11.まとめ：BCPの成否を分けるのは、初動速度
- 12.よくある質問
BCP初動とは24時間以内の意思決定プロセス
|
Definition · BCP初動の定義
BCP初動とは、災害発生後24時間以内に行う
事業継続判断プロセスのことです。 従業員安否の集約だけでなく、拠点被災状況・出社可否・停電・物流停止・代替拠点・サプライチェーン影響を統合把握し、経営判断を下すことまでを含みます。 BCP初動の本質は「意思決定速度」です。どれほど精緻な計画書があっても、初動で情報が統合されなければ経営判断は下せません。 |
BCP計画書とBCP初動の違いBCP計画書：「何をすべきか」を定めた文書 |
BCP初動の「最重要6時間」災害発生直後の6時間は、BCP初動において最も重要な時間帯です。物流停止への初動対応・代替拠点への切り替え判断・顧客対応の優先順位づけ・人員配置の意思決定が集中します。この6時間に下せた判断の質と速度が、損失規模を大きく左右します。 |
| BCP初動の定義 | |
| BCP初動とは | 災害発生後24時間以内の事業継続判断プロセス |
| 含まれること | 安否確認・拠点状況把握・出社可否・物流停止把握・経営判断 |
| 最重要時間帯 | 発生後6時間以内 |
| 最も重要なこと | 経営判断に必要な情報が、どれだけ速く対策本部に集まるか |
日本の災害リスクと初動遅延の実態
BCP初動の重要性は、日本の災害リスクの統計に明確に現れています。
南海トラフ巨大地震の被害想定
|
32.3万人
最大死者数
建物倒壊・津波による被害想定
|
220兆円
最大経済的損失
直接・間接損失の総額試算
|
70〜80%
今後30年以内の発生確率
政府機関による最新想定
|
| 広域同時被災という前提の崩壊：この規模の災害では、「一部の拠点が被災しても他の拠点が補完する」という従来のBCP前提が崩れます。静岡・東海・近畿・四国・九州という広域が同時に被災するシナリオでは、広域同時被災を前提とした多拠点統合型のBCP初動設計が不可欠です。 |
風水害リスクの現実
「地震対応中心のBCP」の限界令和元年（2019年）台風19号による被害総額約1兆8,600億円。令和2年（2020年）全国の水害被害総額約6,600億円。 |
「地震のみ自動配信」システムの盲点「地震のみ自動配信」のシステムは、実際の災害発生頻度の大部分に対応できていません。全災害種別（地震・津波・風水害・特別警報）への自動対応が、実戦型BCP初動の最低要件のひとつです。 |
| 初動遅延が企業に与える影響：中小企業庁の調査によると、大規模災害後に事業が継続できなかった中小企業の多くは「初動での情報収集と意思決定の遅れ」を主な課題として挙げています。東日本大震災後の複数の調査では、BCP未整備企業と整備済み企業の間で、廃業率・復旧期間に有意な差が確認されています。 |
なぜ「安否確認の完了」はBCP初動のゴールではないのか
|
安否確認の完了は、BCP初動のスタートラインです。 |
安否確認が完了した後に始まること
対策本部が直面する「答えられない6つの問い」
×「どの拠点が今日稼働できるか、分からない」
×「出社できる人数が分からない。いつ来られるかも分からない」
×「停電している拠点がどこか分からない」
×「物流が止まっているか分からない」
×「各拠点に個別電話をかけ始め、最重要の6時間が情報収集だけで消えていく」
×「経営層への状況報告ができない」
これが「電話地獄」です。
情報分断が生む「意思決定の空白」
|
情報分断の典型的パターン →安否情報はシステムに集まっているが、拠点の稼働状況は別 →出社可否はExcelで手動集計 →停電・断水の情報はLINEグループに散乱 →複数の担当者が同じ拠点に何度も電話している |
必要なのは「情報統合」という設計思想 BCP初動に本当に必要なのは「安否確認ツール」ではありません。安否・拠点状況・出社可否・物流状況を一元的に統合し、対策本部が経営判断を下せる状態にする「情報統合の設計思想」です。この設計思想を持っているシステムかどうかが、BCP初動の成否を分ける最も重要な選定軸になります。 |
災害対策本部とは「意思決定OS」である
災害対策本部とは、被災状況・人的状況・事業影響を統合管理し、経営判断を行う司令塔のことです。単なる「情報収集部門」ではなく、情報をもとに「経営行動を変える場所」です。
対策本部OSとは対策本部OSとは、企業が災害後に経営行動を継続するための意思決定基盤のことです。コンピュータのOSがアプリケーションを動かす基盤であるように、対策本部OSは災害時の経営判断を動かす基盤です。安否情報は「最初の入力」ですが、拠点状況・出社可否・物流状況・顧客影響という追加入力が揃って初めて、対策本部OSは経営判断を出力できます。 |
対策本部OSが機能するための3条件
|
条件 01
情報がリアルタイムで統合されていること
安否・拠点状況・出社可否・物流状況が、ひとつのダッシュボードに集約されていること。
|
条件 02
管理者が被災していても自動で動くこと
管理者依存の設計では、管理者自身が被災した瞬間に情報収集が止まります。自動配信・自律回答の設計が対策本部OSの独立稼働を保証します。
|
条件 03
経営判断に必要な情報が6時間以内に揃うこと
発生後6時間以内に、対策本部OSが動き出せる状態になっていることが求められます。
|
| 対策本部OS視点が選定基準を変える | |
| 従来の選定基準 | 対策本部OS視点の選定基準 |
|
▸どの機能が多いか ▸通知がどれだけ届くか ▸価格はいくらか |
▸対策本部が6時間以内に経営判断を下せる基盤か ▸管理者不在でも自律稼働するか ▸情報統合が設計の中心にあるか |
企業を止める会社と止めない会社 理論型BCPと実戦型BCPの違い
理論型BCP
止まる会社の初動パターン |
実戦型BCP
止めない会社の初動パターン |
|
↓安否確認の開始
↓従業員への一斉メール送信（届かない・返信がない）
↓管理者が各拠点に個別電話（「電話地獄」開始）
↓拠点状況・出社可否がまだ分からない（発生から2時間経過）
↓ExcelやLINEで情報を手動集計
↓対策本部に情報が揃わないまま6時間が経過
→経営判断が遅延し、事業と信用の損失が積み上がる
|
↓災害発生（深夜・休日・管理者不在でも）
↓気象庁連動で対策本部OSが自律稼働・自動配信
↓SMS・スマートウォッチ経由で全従業員に即時到達
↓パスワードレス回答で1タップ完了
↓安否・拠点状況・出社可否が対策本部ダッシュボードに自動集約
↓6時間以内に：物流停止・代替拠点・顧客対応の判断完了
→事業継続・損失最小化
|
| この差は機能の差ではなく「設計思想の差」です：食品・物流・建設・エネルギーという社会インフラを担う業種での実運用から生まれた実戦型BCP設計が、被災直後の最も厳しい環境で機能する理由はここにあります。 |
企業規模別の「止まるリスク」
|
中小企業（50〜300名）
「誰が来られるか」が勝負
人員が少ない分、一人ひとりの出社可否が翌日の業務継続に直結します。安否確認後の「誰が来られるか」の把握が最も重要です。
|
中堅企業（300〜1,000名）
複数拠点の統合が課題
複数拠点の状況統合が課題になります。各拠点への個別電話確認が「電話地獄」を生みやすい規模です。
|
大企業・グループ企業（1,000名以上）
グループ横断統合が不可欠
グループ横断での安否・拠点統合管理が不可欠です。一部拠点の情報だけでは経営判断が下せません。
|
BCP初動で対策本部が把握すべき5つの情報
BCP初動において、対策本部OSが6時間以内に把握すべき情報は5つです。この5つが揃う速度が、損失規模を決めます。
| 第1情報 |
安否収集完了後すぐに必要
従業員安否生存確認・負傷有無・現在地の把握。ただし安否確認はBCP初動の「第1情報」であり、これだけでは経営判断に必要な情報として不十分です。 |
| 第2情報 |
安否確認とは独立して収集が必要
出社可否と交通状況生存しているが出社できない従業員の把握。拠点別の出社見込み人数と時間帯の算出。「安否は確認できたが、誰が来られるか分からない」という状況がBCP初動を止めます。出社可否は安否確認とは独立した項目として収集する必要があります。 |
| 第3情報 |
代替拠点判断の前提情報
拠点被災状況建物損傷・停電・断水・入館可否の拠点別把握。複数拠点の稼働可否の一覧化。拠点の物理的稼働状況が分からなければ、代替拠点への切り替え判断が下せません。 |
| 第4情報 |
社会インフラを守る最重要情報
ライフラインと物流停電・断水・ガス停止の状況。物流ルートの稼働状況。調達先の被災状況。食品・医療・建設・エネルギーという社会インフラを担う業種では、物流停止は企業損失を超え社会的損失に直結します。この情報を6時間以内に把握できるかどうかが、社会インフラとしての責任を果たせるかを決めます。 |
| 第5情報 |
第1〜4が揃って初めて判断できる
顧客影響と対応優先順位影響を受ける顧客の特定。顧客への連絡優先順位の決定。対応可能な業務範囲の確定。顧客への対応が遅れるほど信用と取引の損失が積み上がります。 |
| 安否確認システム選定で本当に問うべきこと：「従業員の安否を確認できるか」ではありません。「この5つの情報が、6時間以内に対策本部OSに揃うか」です。 |
BCP初動成熟度モデル自社はどのレベルか
BCP初動の実力は、5段階の成熟度モデルで整理できます。多くの企業はレベル1〜2に留まっています。
| Lv.1 |
安否確認のみ（メール・電話）安否が集まるだけ。拠点状況・出社可否は把握できない。管理者が被災すると完全に止まる。リスク：最高 |
|
Lv.2
|
安否確認システム導入（到達設計）地震時の自動配信はできるが安否収集にとどまる。メール中心の通知で夜間・現場への到達に課題。管理者依存の設計で、管理者被災時に機能しにくい。6時間以内の経営判断が困難。リスク：中程度 |
| Lv.3 |
多経路通知・回答しやすい設計SMS・スマートウォッチ・パスワードレス回答により、夜間・現場・高齢従業員からも高い回答完了率を実現。管理者不在時でも自動配信が継続。ただし安否後の拠点統合管理はまだ不足。リスク：低〜中 |
| Lv.4 |
対策本部OS（情報統合設計）安否・拠点状況・出社可否・物流状況が対策本部ダッシュボードに統合され、6時間以内の経営判断が可能。電話地獄が解消される。全災害種別への自動対応。管理者不在でも対策本部OSが自律稼働。リスク：低 |
| Lv.5 |
自律分散型BCP（高度な実戦型BCP）各拠点が自律的に状況を報告し、グループ横断での対策本部OSが広域同時被災シナリオにも対応。訓練・定着・継続改善のサイクルが定着。南海トラフ広域同時被災・物流・社会インフラ維持の観点まで組み込んだ設計。リスク：最低 |
| 多くの企業はレベル1〜2に留まっています：「BCPは策定済み」という企業も、実際の初動設計を確認すると「管理者が被災したら止まる」「拠点状況は電話確認」「風水害は手動」というレベル1〜2であることが少なくありません。レベル4以上を目指すことが、「企業を止めないBCP初動」の実現です。 |
南海トラフ時代の「静岡モデル」 実戦型BCPが生まれた場所
広域同時被災が想定される静岡県（※）で生まれた、
実戦型BCP初動設計の思想体系です。
静岡県は単に「地震リスクが高い地域」ではありません。港湾・物流・食品・製造インフラが集中する日本の物流動脈でもあります。この環境下で「対策本部OSが何時間以内に経営判断を出せるか」という実戦要件から生まれたのが静岡モデルです。
食品・物流・建設・エネルギーという社会インフラを担うグループが、広域同時被災・物流停止・多拠点同時判断という最も厳しい条件下で「対策本部が止まらないために何が必要か」を起点に設計されています。
|
核心 01
管理者が被災しても動き続ける自動化設計
気象庁電文連動・全災害自動配信。人に依存しない自律稼働設計
|
核心 02
夜間・現場・高齢従業員でも回答しやすい設計
SMS・スマートウォッチ・パスワードレス。「届ける」から「回答させる」設計へ
|
核心 03
安否収集後に対策本部OSが6時間以内に動ける情報統合設計
拠点統合・出社可否・物流状況を一元可視化。電話地獄を設計で解消
|
コンサル型BCPとの違いコンサル型BCP：策定支援が目的。精緻な計画書が成果物。実際の災害時に機能するかは問われない。 |
物流を止めないことは社会インフラを守ること食品・医療・建設・エネルギーという社会インフラを担う業種において、BCP初動の遅れは企業損失にとどまりません。物流が止まれば被災地への食料・医療品・建設資材の供給が滞り、社会的損失に直結します。BCP初動の本質は「物流と社会インフラを止めないための初動意思決定基盤」という問いにあります。 |
対策本部OSとして機能するための8つの設計要件
|
要件 01
管理者不在でも動く自動化設計
気象庁電文連動の自動配信により、管理者が被災・不在の深夜・休日でも自動で通知が行われること。
なぜ必要か：管理者自身が被災するシナリオはBCP初動で最も起きやすい失敗パターンのひとつです。
|
要件 02
多経路通知設計（SMS・スマートウォッチ標準）
SMS・スマートウォッチ振動通知・アプリプッシュの多経路通知。製造現場作業中・深夜勤務中・就寝中でも到達すること。
なぜ必要か：大規模災害時のメール遅延を前提とした設計が必要。「届ける」より「回答させる」ことが目標です。
|
|
要件 03
回答しやすい設計（完全パスワードレス）
端末認証によりURLを1タップするだけで回答が完了すること。「到達率」ではなく「回答完了率」を目標とした設計であること。
なぜ必要か：IDとパスワードを忘れて回答できない従業員を設計レベルでゼロにします。グッドデザイン賞（2020年度）受賞。
|
要件 04
全災害種別への自動対応
地震・津波・風水害（台風・豪雨・大雪）・特別警報すべてに自動配信対応していること。
なぜ必要か：地震だけに対応したシステムは、年間の災害発生頻度の大部分をカバーできていません。
|
|
要件 05
拠点統合管理ダッシュボード
安否情報だけでなく、拠点被災状況・停電・入館可否・出社可否・交通手段を一元収集し、対策本部ダッシュボードに集約すること。
なぜ必要か：安否情報だけでは経営判断は下せません。情報統合が電話地獄を防ぎ、6時間以内の意思決定を実現します。
|
要件 06
188エリア精密配信設定
全国188エリアから細かく設定でき、本社・拠点ごとに必要なエリアだけを精度高く設定できること。
なぜ必要か：「都道府県単位」の粗い設定では多拠点展開企業に対応できません。
|
|
要件 07
家族安否確認の標準装備
従業員の家族の安否確認が追加費用なしで標準装備されていること。
なぜ必要か：家族安否確認は出社率の実質的な向上に直結します。
|
要件 08
BCP初動成熟度レベル4以上の設計思想
「安否確認ができる」レベル1〜2の設計ではなく、「対策本部OSとして機能する」レベル4の設計思想を持つシステムであること。
なぜ必要か：設計思想を持たないシステムは、いくら機能を追加しても対策本部OSにはなれません。
|
8要件セルフチェック
- 管理者不在でも気象庁連動で自動配信されるか
- SMS・スマートウォッチが標準実装されているか
- パスワードレス回答（端末認証）が実装されているか
- 地震以外の風水害・特別警報にも自動配信されるか
- 拠点被災状況・出社可否を一元管理できるか
- 188エリア以上の細分設定が可能か
- 家族安否確認が標準装備されているか
- 6時間以内に対策本部OSが経営判断を下せる設計か
この8項目を満たすシステムが、対策本部OSとして機能するBCP初動プラットフォームです。
「安否確認システム」から「BCP初動プラットフォーム」へ
「安否確認システムを導入すれば、BCPの初動対応ができる」——この前提は正確ではありません。
|
レベル1〜2
安否確認ツール
目的：従業員の安否を確認すること
限界：安否後の情報統合・経営判断支援がない。安否が集まっても対策本部が動けない。
|
レベル3〜4
BCP初動プラットフォーム
目的：安否収集から拠点状況統合・対策本部への情報統合まで
機能：全災害自動対応・多経路通知・拠点統合・対策本部ダッシュボード
|
レベル4〜5
対策本部OS
目的：対策本部が6時間以内に経営判断を下せる独立基盤
特性：管理者不在でも自律稼働・広域同時被災対応・物流・社会インフラ維持まで設計
|
この3段階の進化が、「企業を止めないBCP」実現のための思想転換です。
汎用安否確認SaaSの限界全業種・全規模に対応する汎用設計。「届ける」ことを目標にした設計。比較表で戦う。 |
実戦型BCP初動プラットフォームとの違い物流・夜間稼働・多拠点・高齢従業員・風水害という極限環境で鍛えられた設計。「回答完了・情報統合・6時間以内の経営判断」を目標にした設計。東日本大震災・熊本地震での実稼働実績を持つ。「汎用であること」と「実戦で機能すること」は異なります。 |
まとめ：BCPの成否を分けるのは、初動速度
|
Final Thought
BCPは、計画書ではありません。BCPの成否を分けるのは、初動速度です。
安否確認システムとは、本来「人の無事を確認するシステム」でした。しかし南海トラフ巨大地震のような広域同時災害において、日本の物流動脈を担う企業が本当に必要としているのは、「人の無事を確認すること」だけではありません。 「安否が集まった後、物流を止めないか。拠点を動かすか。顧客に何時に連絡するか。社会インフラとしての責任を果たせるか。」 これらの経営判断を、被災直後の最重要6時間以内に下せる対策本部OSがあるかどうか。それが「安否確認システムの選定」ではなく、「企業を止めないための対策本部OS設計」という問いです。 |
3つの問いで自社を確認する
|
問い① 「安否確認が完了した後、自社の対策本部OSは6時間以内に動けるか」 問い② 「管理者自身が被災した場合でも、情報収集は自動で続くか」 問い③ 「BCP初動の5つの情報が、発生後6時間以内に対策本部に揃うか」 |
この3つへの答えが「Yes」であれば、あなたの会社はBCP初動成熟度レベル4以上です。「まだできていない」であれば、今が設計を見直すタイミングです。BCPとは、計画書に書いてあることではなく、実際の災害後6時間で何を判断できたかです。
よくある質問
「世界中のコミュニケーションをクラウドで最適に」することをミッションとして掲げ、２０００社以上の法人向けのデジタルコミュニケーションとデジタルマーケティング領域のクラウドサービスの開発提供を行う防災先進県静岡の企業。１９７７年創業後、インターネット黎明期の１９９８年にドメイン取得し中堅大手企業向けにインターネットビジネスを拡大。”人と人とのコミュニケーションをデザインする”ためのテクノロジーを通じて、安心安全で快適な『心地良い』ソリューションを提供している。
- 事業内容
- デジタルマーケティング支援
デジタルコミュニケーションプラットフォーム開発提供 - 認定資格
- ISMS ISO/IEC27001 JISQ27001認定事業者（認定番号IA165279）
プライバシーマーク JISQ15001取得事業者（登録番号10824463(02)）
ASP・SaaSの安全・信頼性に係る情報開示認定事業者（認定番号0239-2004）
