安否確認だけでは、会社は守れない。
2026/06/01.
情報は届いている。しかし、判断が止まっている。
安否確認は完了した。
それでも、事業が止まる場合があります。
事業が止まる原因は、
従業員の安否が分からないことではなく、
「次に何を判断すべきか？」
それが分からないことかもしれません。
|
DEFINITION — 判断停止とは 安否確認は完了した。それでも「何をすべきか」を決断できない状態。 |
安否コールの定義
安否コールは、単なる安否確認システムではありません。
BCPの判断停止を防ぐ、BCP初動プラットフォームです。
安否確認は完了した。それでも、事業が止まる場合があります。
事業が止まる原因は、従業員の安否が分からないことではなく、「次に何を判断すべきか？」それが分からないことかもしれません。
安否コールは、単なる安否確認システムではありません。
BCPの判断停止を防ぐための、BCP初動プラットフォームです。
2005年、防災先進県・静岡の大手国際物流グループ（約140社・従業員16,000名超）のBCP初動支援を目的として生まれました。
| 国際物流は、災害時こそ止めることができない。港・輸送・倉庫・燃料・生活インフラを支える企業群が、発災直後に動けるための設計が必要でした。求められたのは、単なる安否確認ではありません。 |
災害発生時、自動配信で即時に届くこと。
担当者が状況を把握する前に、安否確認はすでに動いている設計。
パスワード不要で、極限状態でも迷わず回答できること。
パニック状態の従業員でも、高齢の家族でも、迷わず回答できる設計。
家族の安心を支え、従業員が事業継続に集中できること。
家族7名の安否確認を標準装備。家族が心配な従業員は、会社に集中できない。
掲示板によって、被災状況や意思決定を即時共有できること。
ヒト・モノ・カネ・情報を一元管理し、対策本部が「判断できる状態」になる。
GPSによって、経営判断につなげられること。
誰がどこで被災しているかを可視化し、参集計画と初動判断を支援する。
| 安否コールは、こうしたBCP初動の実務要件から進化してきました。設計の起点は、社会インフラを担う企業の現場です。 |
index
なぜ安否確認システムだけでは、BCP対策として不十分なのか
| BCP対策において、安否確認システムだけでは不十分と言われる理由があります。それは「確認」と「判断」が、まったく別の機能だからです。 |
災害が発生した。安否確認システムが動き、30分後には従業員の8割から返信が届いた。それでも、対策本部の担当者は次の一手を打てずにいました。
従業員が無事であることは分かった。しかし、何をすべきかが分からない。
誰が今日出社できるのか。どの拠点が被災しているのか。ライフラインの状況は。安否確認は「人の状態を知る」手段です。そこから先の「組織の判断」は、また別の情報と設計を必要とします。
| KEY DEFINITIONS | |
| 安否確認 | 人の「生存・所在・状態」を収集する仕組み。BCPの入口。 |
| BCP初動判断 | 収集した情報をもとに「誰が・どこで・何ができるか」を意思決定する仕組み。BCPの本体。 |
| 初動格差 | 同じ規模の災害でも、初動設計の有無で事業継続コストに大きな差が生まれること。 |
| 判断停止 | 情報は届いているのに、次に何をすべきかが決断できない状態。企業防災において最も多発する、最大のリスク。安否確認の完了後に発生する。 |
| BCP初動プラットフォーム | 安否確認を超え、災害時の情報集約・状況可視化・意思決定支援を一体的に担うシステム。 |
| 企業が止まる原因は、安否確認ができないことではない。 「次に何を判断すべきか、分からないこと」である。 |
|
安否確認はできても、次の判断が止まる可能性があります。 自社のBCP初動で「誰が・どこで・何を判断するか」が設計されているか、確認できます。 自社の判断停止リスクを確認する → |
安否確認システムを選定する際に「料金」「導入社数」「機能一覧」から入ることは自然です。しかしBCP対策として機能するかどうかは、企業防災における「判断」まで設計されているかで決まります。BCP初動の設計として選定するとき、本当の基準はここにあります。
企業防災で組織が止まる、本当の5つの理由
BCP初動とは、発災後6時間以内の意思決定設計である。
| 企業防災においてBCP初動で組織が機能しなくなるのは、安否確認システムの有無よりも、初動対応の設計の問題です。東日本大震災・熊本地震・各地の水害対応の現場から見えてきた、BCP対策に共通するパターンです。 |
- 情報が集まらない
多拠点企業では、各地の被災状況が電話・メール・LINEとバラバラな手段で報告されます。形式が統一されていないため、対策本部は全体像を把握できません。 - 状況が見えない
人の安否は確認できても、その人がどこにいて、出社できる状態かどうかが分からない。BCP判断に必要な情報が可視化されていないと、対策本部は霧の中で舵を切る状態になります。 - 災害対策本部が混乱する
情報が断片的に届くと「何が起きているか」のすり合わせに終始します。本来やるべき「何をするか」の決定が後回しになり、初動の数時間が消費されます。 - 判断が遅れる
BCP初動における最初の1〜2時間の判断の質が、その後の事業継続コストを大きく左右します。「もう少し情報を集めてから」という慎重さが、初動対応の遅れを生みます。 - 指示系統が分断される
対策本部からの指示が現場に届かない。届いても伝言ゲームで変質する。情報と指示が双方向でリアルタイムに流れる仕組みがなければ、組織は有機的に動けません。
|
BCP INITIAL CHECK 自社はどこで止まるのか、
|
東日本大震災が示した、「初動格差」という現実
| 2011年3月11日の震災は、BCP対策・企業防災における準備の有無が初動対応にどれほどの差を生むかを示しました。この経験が、安否確認サービスとしての安否コールの設計思想の原点になっています。 |
2011年東日本大震災において、安否コールは発災直後から自動配信を開始し、担当者がPCを開く前に安否確認がすでに始まっていました。平均初報到達時間：約54秒。「安否確認は終わった。しかし誰を出社させるか、どの拠点が動けるか、決められない」——その声が、BCP初動プラットフォームへの設計思想につながっています。
令和6年能登半島地震においても、安否コールはメール配信とアプリ通知の多重設計により、通信混雑下で平均54秒での初報配信を完了しました。平時の機能説明だけでなく、実災害時の運用記録に基づく実績です。（当社運用記録）
災害時は、操作の複雑さそのものが人と組織の判断を妨げます。「あるかどうか」ではなく「誰でも、すぐに、確実に使えるか」——これがUXの問題であり、企業防災の本質です。
| SHIZUOKA MODEL — 南海トラフと生きる
「静岡モデル」——
災害を"前提"として設計する思想。 静岡では、災害は"もしも"ではなく"前提"として扱われてきました。東海地震対策が50年以上続くこの地域では、企業防災はマニュアルではなく、経営そのものです。防災訓練は文化として根付き、BCPは義務ではなく日常の一部になっています。 安否コールは、南海トラフ最前線の現実と向き合い、大手国際物流グループ（約140社・従業員16,000名超）の実務要件から設計された、一次情報ベースのプロダクトです。静岡という土地が、このシステムの設計思想の起源です。 |
|
DISASTER EVOLUTION 日本の災害と共に、20年間実戦進化してきた。 2005内閣府「事業継続ガイドライン」策定
2005年前後、日本企業においてBCPの考え方が本格的に広がり始めました。内閣府の事業継続ガイドラインも、企業・組織における事業継続の必要性を明示し、BCP策定・改善を促すものとして位置づけられています（内閣府）。この年、防災先進県・静岡の大手国際物流グループからの要望を受け、BCP初動支援システムとして開発開始。最初から、サービス展開を前提として設計されました。 LEARNED 「安否確認」ではなく、"企業継続"そのものが必要だった。 2007大規模企業の強い顧客要望
パニック状態でも操作できる、シンプルで直感的なUXデザインへの強い顧客要望を前提に、パスワードレス・自動配信・GPS・掲示板・家族安否を実装。担当者変更や組織改編があっても運用が止まらないこと、数万人規模でも全社員が迷わず使えること——「使い方を説明しなくても動けること」自体を、BCP初動設計として捉えています。 LEARNED 災害時、人は複雑な操作ができない。 2009駿河湾を震源とする地震
御前崎沖を震源とする地震で、安否コールは問題なく稼働。実災害での運用実績が評価され、FUJIFILM（旧 Fuji Xerox）と販売店契約を締結。思想ではなく、「実際に動いた」という事実が、信頼につながりました。 LEARNED "動くかどうか"は、本番でしか証明できない。 2010経営革新計画承認・BCP統合サービスリリース
BCP支援と安否確認を統合した拡張サービスを、業界に先駆けてリリース。現在の「BCP初動プラットフォーム」思想が形になり始めた時期です。 LEARNED 安否確認だけでは、企業は止まる。 2011東日本大震災
全国が「判断停止」を経験した年。安否コールは発災直後から稼働。問い合わせが急増し、BCPセミナー動員は累計1,000名超へ。大津波警報など、特別警報への対応も強化。 LEARNED 安否確認の完了は、BCP初動のスタート地点だった。 2016熊本地震
益城町のお客様から、被災時の実運用情報を取得。安否確認後、電話もメールも不通。掲示板だけが、唯一のコミュニケーション手段になりました。この経験から、複数グループ掲示板へ進化。 LEARNED 災害時、"連絡手段"そのものが消える。 2024能登半島地震
問題なく稼働。自動配信平均54秒。20年間磨き続けたBCP初動思想が、現在も全国で機能しています。 LEARNED 初動速度が、企業継続を左右する。 安否コールは、机上で設計されたSaaSではありません。 |
|
CASE & OPERATION RECORD 実災害で動くBCP初動設計を、資料で確認できます。自動配信、SMS・アプリ通知、掲示板、家族安否、対策本部ダッシュボードなど、災害時に必要な設計思想をまとめています。 |
|
TIME AXIS — 静岡が刻んだ3つの転換点
|
|
Design Philosophy — 現場から生まれた3つの確信 "
訓練で使えないシステムは、本番でも使えない。 "
災害時、人はパスワードを思い出せない。 "
家族が心配な従業員は、会社に集中できない。 これらは機能説明ではありません。静岡での50年の防災文化と、東日本大震災・熊本地震・令和6年能登半島地震の実運用から得た経験知です。安否確認システムのUX設計は、この3つの確信を中心に構成されています。 |
|
整理すると、こういうことです。 安否確認は完了した。 事業が止まる原因は、従業員の安否が分からないことではなく、 TRACK RECORD — 実績数値と、その意味
|
BCP初動では、「配信できるか」ではなく「判断開始まで何分短縮できるか」が重要です。平均54秒という数字は、実災害時の運用記録に基づく実績値であり、単なる通知速度ではなく企業の初動時間を前倒しするための設計思想です。（当社実績）
BCP初動に本当に必要な 9つの情報とは
| 安否確認システム・安否確認サービスが収集するのは「人の状態」です。企業防災のBCP初動において、対策本部が意思決定するためには、さらに多くの情報を統合する必要があります。この違いが、安否確認システム選定の本質的な基準になります。 |
|
従業員の安否
生存・負傷・連絡不通の状況
|
現在位置
自宅・外出先・被災地域との関係
|
参集可否
出社できる人数と時間軸
|
|
拠点被災状況
建物・設備・インフラの損壊
|
ライフライン
電気・水・ガス・通信の状況
|
初報時刻
いつ誰から何が届いたか
|
|
現場写真
被災箇所のビジュアル記録
|
家族の安全
従業員が動ける精神状態か
|
通信状況
各地域の回線・ネットワーク品質
|
初動対応を止めない、8つの実行力
| TODAY — 導入した日から変わること | ||
|
発災時、担当者不在でも動く
気象庁連動の自動配信で、人の操作なしに安否確認が開始。夜間・休日・管理者被災でも止まりません。
|
対策本部が「見える化」される
全拠点・全従業員の状況が一画面に集約。「確認」から「判断」へ、6時間以内に移行できます。
|
家族の安心が、初動力を生む
家族7名の安否確認が標準装備。「家族が心配」な従業員が、安心して職務に集中できます。
|
| 安否確認システムの機能比較でよく挙げられる「通知機能」や「料金」よりも、企業防災において本当に重要なのは、初動対応の現場で誰でも確実に使えるかどうかです。 |
|
安否確認システムを「BCP初動」視点で比較する 料金や導入社数だけでなく、自動配信・家族安否・掲示板・GPS・対策本部ダッシュボードまで比較できます。 |
企業継続OSへの接続 OSは、災害時だけでは育たない
安否コールが企業継続OSになるためには、災害時だけでなく平時に使われることが不可欠です。年1回の安否確認訓練で終わるシステムはツールです。日常業務に溶け込んでこそ、OSになります。
| 使われているシステムだけが、 有事に機能する。 |
| EVERYDAY USE — 平時から使われる安否コールの活用シーン | ||
|
???? 熱中症・健康確認
猛暑日の現場スタッフへの一斉確認。平時から操作に慣れる。
|
???? 出社・在宅管理
リモートワーク時の出社可否・体調確認を日常ルーティンに。
|
???? 施設・設備点検
拠点ごとの設備状況を定期収集。拠点統合管理を平時から体験。
|
|
???? 感染症・体調管理
感染症流行期の出勤可否・症状確認を一元管理。
|
???? BCP訓練・定期演習
年複数回の実地訓練で操作習熟と体制を強化。
|
???? 緊急一斉連絡
台風接近・大雪・交通障害など、日常的な緊急連絡にも活用。
|
|
???? 気象・河川アラート
特別警報・河川氾濫情報と連動した自動通知。
|
???? サプライチェーン確認
取引先・協力会社の稼働状況を一元把握（将来機能）。
|
???? 自治体・地域連携
地域防災計画との統合・スマートシティ連携（L5・将来）。
|
| 平時の利用頻度が、有事の回答率に直結します。日常業務でアクセスする習慣があるから、発災時に「いつもの操作」として自然に動ける。これが安否コールの設計思想です。 |
なぜ安否コールは、BCP初動に強いのか
機能の優位ではなく、構造の優位。5つのレイヤーが統合されているから、競合には真似できない設計になっています。
PATENT — 特許第6603430号
IoT連携による拠点状況把握技術
拠点のセンサー・設備とシステムを連携させる技術に特許を保有。BCP初動支援における、安否コール独自の技術的優位性の一つです。
DESIGN — スマートウォッチ対応
スマートフォンが手元になくても、腕の上で応答できる。
地震直後、スマートフォンは手元にないかもしれない。スマートウォッチ応答まで含めて設計している点は、安否コールの特徴の一つです。
VISION — 安否コールが目指す先
現在提供中の機能と、開発中・将来構想を分けて記載しています。
安否確認から企業継続OSへ。
人・拠点・情報・判断を統合し、
平時から有事まで企業の意思決定を止めない基盤。
「人と人とのコミュニケーションをデザインする」——アドテクニカの経営理念が、企業継続OSとして具現化する先。
対策本部で、本当に起きていること
夜中2時に担当者が手動でメールを送っている。拠点長が一人で判断できず、本部に電話し続けている。家族と連絡が取れず、業務に集中できない従業員がいる。これは想像ではありません。企業防災の現場で、実際に起きていることです。
これらの混乱は、情報が「一元化・可視化・リアルタイム化」されれば防げます。発災から6時間以内に対策本部が「判断できる状態」になることが、BCP初動プラットフォームの存在意義です。
設計思想の比較
| サービス | 思想軸 | 設計の目的 |
|---|---|---|
| NTT系サービス | 連絡インフラ思想 | 緊急連絡網の確実な配信。「届ける」ことが中心。 |
| セコム系サービス | 警備・監視思想 | 異常検知と警備。「守る」ことが中心。 |
| 普及型サービス | 安否収集特化思想 | 安否の確認と集計。「把握する」ことが中心。 |
| 安否コール | BCP初動判断思想 | 情報を集め、状況を可視化し、組織が「判断できる」状態をつくること。 |
南海トラフ臨時情報が発令されたとき、本当に企業は動けるのか
2024年8月8日、気象庁は初めて「南海トラフ地震臨時情報（巨大地震注意）」を発表しました。そのとき、多くの企業が気づきました。「臨時情報が出たら、自社は何をすべきか分からない」と。
安否コールは静岡で生まれました。南海トラフを「次の現実」として設計されたプロダクトです。臨時情報が発表された場合、企業は情報の種類に応じて、安否確認体制・参集可否・対策本部立ち上げ・拠点状況確認の準備を段階的に確認しておくことが望まれます。安否コールは、各フェーズに対応した段階的自動配信をサポートしています。
| PHASE 1
調査中
M6.8以上を観測。気象庁が調査開始。企業はBCP確認開始。
|
PHASE 2
巨大地震注意
M7.0以上。1週間の警戒継続。安否確認体制・参集可否の確認が望まれます。
|
PHASE 3
巨大地震警戒
M8.0以上。半割れケース。対策本部の立ち上げ・初動判断体制を確認することが重要です。
|
PHASE 4
本震発生
安否・拠点・ライフライン情報をリアルタイムで集約することが求められます。
|
|
本記事の情報の位置づけ 本記事は、企業のBCP初動設計を検討するための考え方を整理したものです。南海トラフ地震・自然災害リスクに関する数値は、気象庁・内閣府・地震調査研究推進本部などの公的情報を参照しています。安否コールの機能・配信実績・稼働実績に関する情報は、当社のサービス仕様および運用記録に基づいています。自治体連携・医療ネットワーク・スマートシティ連携等、「開発中」「将来構想」と記載している機能は、現時点での提供機能とは区別して記載しています。 |
よくある質問 FAQ
|
Q. BCP初動で最も重要なことは何ですか？ 発災後6時間以内に対策本部が「誰が動けるか・どの拠点が使えるか・何を優先すべきか」を判断できる状態をつくることです。安否確認の完了はBCP初動のスタートラインであり、そこから先の意思決定を支える設計が、BCPの本質です。 |
|
Q. なぜ安否確認だけでは会社は止まるのか？ 「確認」と「判断」は別の機能だからです。安否が集まっても、拠点状況・出社可否・物流停止・ライフラインの情報が統合されなければ、対策本部は次の行動を決定できません。この状態を「判断停止」と呼びます。企業防災における最も深刻なリスクです。 |
|
Q. BCP初動プラットフォームと安否確認システムの違いは？ 安否確認システムは「人が無事かどうか」を収集する仕組みです。BCP初動プラットフォームは「組織として何ができるか」を判断できる状態をつくる仕組みです。前者は情報収集、後者は意思決定支援。安否確認の「その後」まで設計する考え方と言い換えることもできます。 |
|
Q. 南海トラフ臨時情報が発令されたら企業はどう動けばよいですか？ 段階的な対応が必要です。「調査中」→「巨大地震注意」→「巨大地震警戒」の各フェーズで、安否確認配信・参集確認・対策本部立ち上げの準備を進めます。平時から自動配信・拠点統合管理が整っているシステムを使っていることが、迅速な初動の前提になります。 |
|
Q. 企業継続OSとは何ですか？ 「人・拠点・情報・判断」を統合し、平時から有事まで企業の意思決定を止めないための経営基盤のことです。安否確認→BCP初動プラットフォーム→企業継続OSという進化の方向性があります。自治体・病院・サプライチェーン・IoT・スマートシティと連携することで、地域防災インフラとしても機能します。 |
|
Q. なぜ平時の利用が有事の対応力を高めるのですか？ 使い慣れたシステムは有事に自然に機能します。日常的にアクセスする習慣があるから、発災時に「いつもの操作」として迷わず動けます。熱中症確認・出社管理・施設点検・訓練など平時の利用が、そのまま有事の回答率と初動速度に直結します。 |
|
Q. BCP初動の6時間とは何ですか？ 災害発生後6時間は、拠点の稼働可否・参集人員・物流継続・顧客対応の開始可否など、事業継続の方向性を決定する最重要の時間帯です。この6時間以内に対策本部が「判断できる状態」になれた企業とそうでない企業では、その後の復旧速度と事業継続コストに大きな差が生まれます。 |
|
Q. 災害時にSMSが強い理由は何ですか？ 災害時、インターネット回線は混雑しますが、SMS（ショートメッセージ）は電話回線を使用するため、通信混雑の影響を受けにくいです。また、スマートフォンにアプリをインストールしていない場合でも、携帯電話番号があれば届きます。開封率98%というデータも、緊急時の高い到達性を示しています。 |
|
Q. 安否確認システムとBCP対策の関係を教えてください。 安否確認システムはBCP（事業継続計画）対策の実行において、最初の情報収集インフラです。ただし安否確認の完了はBCP初動のスタートラインであり、その後の拠点状況把握・参集判断・対策本部運営まで含めた設計が、BCPの実効性を決めます。安否確認システム単体ではなく、BCP初動全体の設計として選定することをお勧めします。 |
BCP初動の設計とは、確認の次にある「判断」まで
安否確認システムは、BCP対策の入口です。企業防災において本当に必要とされているのは、「すぐ届き、すぐ集まり、すぐ判断できる」仕組みです。
|
BCP初動プラットフォーム（災害初動意思決定支援プラットフォーム）
安否を確認するだけでなく、「誰が・どこで・何ができるか」を即座に可視化し、災害対策本部が迷わず動けるための情報基盤。BCP対策における「確認」の次の段階、「判断」を支える仕組み。安否確認の「その後」まで設計する考え方、と言い換えることもできます。 |
|
BCP初動チェックリスト——「判断」まで機能しているか
発災後30分以内に全従業員へ連絡が届く
夜間・休日でも自動で配信が始まる
全拠点の被災状況が一画面で確認できる
参集できる人数がリアルタイムで分かる
対策本部への連絡フローが明確になっている
家族への情報共有の手段がある
訓練を年1回以上実施している
従業員リストが常に最新状態に保たれている
|
「世界中のコミュニケーションをクラウドで最適に」することをミッションとして掲げ、２０００社以上の法人向けのデジタルコミュニケーションとデジタルマーケティング領域のクラウドサービスの開発提供を行う防災先進県静岡の企業。１９７７年創業後、インターネット黎明期の１９９８年にドメイン取得し中堅大手企業向けにインターネットビジネスを拡大。”人と人とのコミュニケーションをデザインする”ためのテクノロジーを通じて、安心安全で快適な『心地良い』ソリューションを提供している。
- 事業内容
- デジタルマーケティング支援
デジタルコミュニケーションプラットフォーム開発提供 - 認定資格
- ISMS ISO/IEC27001 JISQ27001認定事業者（認定番号IA165279）
プライバシーマーク JISQ15001取得事業者（登録番号10824463(02)）
ASP・SaaSの安全・信頼性に係る情報開示認定事業者（認定番号0239-2004）
