ALSOK安否確認サービスと安否コールを比較|到達率・回答率・BCP初動で選ぶ意思決定ガイド【2026年最新版】
2023/01/12(2026/02/19).
総合セキュリティ統合型の「人的即応力で支える設計」vs 対策本部OSの「自律的に稼働する設計」。発生後6時間以内に経営判断を下せる基盤はどちらか。設計思想の根本から選定軸を整理します。
この記事の結論
| ◼︎ | ALSOK安否確認サービスは、綜合警備保障グループの人的即応補完体制・24時間監視網・物理セキュリティとの統合管理を強みとしています。安否確認を「総合的なセキュリティ管理の一部」として位置づける企業に適しています。 |
| ◼︎ | 安否コールは、南海トラフ巨大地震での甚大な被害が予想され、日本の物流動脈でもある静岡県の国際物流大手グループ(約140社)の実戦BCP課題から生まれた「対策本部OS」です。管理者自身が被災していても従業員が自律的に回答完了できる設計と、拠点状況の可視化によって初動判断を支援します。 |
| ◼︎ | 選定の分岐点は、「総合セキュリティ統合の延長として安否確認を位置づけるか」「企業を止めないための対策本部OSを独立設計するか」にあります。 |
比較の前に、2つだけ確認させてください
| ① | 自社のBCP初動は、安否確認の完了で終わっていないか |
| ② | 管理者自身が被災した場合でも、対策本部は6時間以内に動けるか |
この2つの問いへの答えが、選定の分岐点になります。
index
- 1.設計思想の違い|2つの起点
- 2.「安否確認の完了」はBCP初動のゴールではない
- 3.機能比較|現場の困りごとで比較
- 4.「ログイン不要」に見えて、実際はログインが必要なケースに注意
- 5.「人的即応力」vs「設計で自律化」通知設計思想の根本的な違い
- 6.BCP初動対応力の違い
- 7.発生後6時間以内に下すべき5つの経営判断
- 8.料金・コスト構造の比較
- 9.どちらを選ぶべきか|企業規模・業種別の判断軸
- 10.ALSOK契約企業こそ「機能要件で分けて考える」
- 11.自社のBCP初動成熟度はどのレベルにありますか
- 12.導入前に確認すべき5つのチェックポイント
- 13.よくある質問
- 14.「人を確認するシステム」から「企業を止めないシステム」へ
設計思想の違い|2つの起点
ALSOK安否確認サービスと安否コールは、どちらも災害時の安否確認を目的としたシステムです。しかし、その設計思想の起点は根本的に異なります。
ALSOK安否確認サービスとは
綜合警備保障株式会社(ALSOK)が提供する安否確認システムです。ALSOKは日本全国に展開する警備・防犯・施設セキュリティのインフラを持ち、 有人オペレータによる24時間365日の監視体制 を強みとする総合セキュリティ企業です。安否確認サービスもこの 総合セキュリティ管理の延長線として設計 されており、既にALSOKの警備・セキュリティサービスを利用している企業との統合運用に適しています。
安否コールとは
南海トラフ巨大地震での甚大な被害が予想されている静岡県を拠点とする国際物流大手グループ(約140社)の 実戦BCP課題から生まれた対策本部OS型の安否確認・BCP初動支援システム です。「安否を集めるだけでは経営判断できない」という現場課題を起点に設計されており、発生後6時間以内に対策本部が動き出せる基盤として機能します。グッドデザイン賞2020受賞。
「最重要6時間」とは何か
BCP初動において、最も重要な時間帯は災害発生直後の 6時間 です。この6時間に、物流停止への初動対応・代替拠点への切り替え判断・顧客対応の優先順位づけ・人員配置の意思決定が集中します。この6時間に下せた判断の質と速度が、 その後の事業再開時期と損失規模を大きく左右 します。
「対策本部OS」とは何か
対策本部が意思決定に必要な情報を統合し、 発生後6時間以内の初動行動を加速するための基盤 のことです。安否情報の収集だけでなく、拠点被災状況・出社可否・物流停止・顧客影響を一元的に可視化し、経営判断を支援する機能を指します。「安否確認システム」ではなく「対策本部OSとして機能するか」という問いが本質的な選定軸になります。
2つの設計起点が示すこと
ALSOK安否確認サービス
人的即応力で支える設計
ALSOKの人的即応体制が24時間体制で監視・補完することで、安否確認の確実性を高めます。警備・セキュリティ統合管理の延長として安否確認を位置づける設計です。
安否コール
自律的に稼働する設計
管理者自身が被災していても、従業員が自律的に回答完了できることを設計思想の核に持ちます。人に依存するのではなく、設計レベルで自律的に稼働できるようにすることで、誰がいなくても対策本部が動き出せる基盤を目指します。
どちらが優れているということではありません。自社のBCP体制においてどちらの思想が合っているかで選ぶことが大切です。
「安否確認の完了」はBCP初動のゴールではない
安否確認が完了した瞬間から、対策本部の本当の仕事が始まる
安否確認が完了した直後から、対策本部は次の判断を迫られます。
| ・ | どの拠点が今日稼働できるか |
| ・ | 何人が出社できるか |
| ・ | 停電・断水で使えない施設はどこか |
| ・ | 物流ルートは動いているか |
| ・ | 顧客対応の優先順位はどうするか |
| ・ | 代替拠点に切り替えるかどうか |
これらの判断を下すために必要な情報が揃っていなければ、「安否は集まったが経営判断ができない」という状況が発生します。
そしてここで多くの企業が陥るのが「電話確認の集中」です。
本部担当者が各拠点に個別電話をかけ始め、 最重要の6時間が情報収集だけで過ぎていく。対策本部OSという視点に立つと、「安否確認システムを選ぶ」のではなく、 「6時間以内に対策本部が動ける基盤を選ぶ」 という問いに変わります。
機能比較|現場の困りごとで比較
実際の災害時に管理者が直面する「困りごと」を軸に整理しました。
| 現場の困りごと | ALSOK安否確認サービス | 安否コール |
| 通知が届かず回答が集まらない |
○ 人的即応補完体制によるサポート |
◎ スマートウォッチ対応を標準実装。SMS通知配信をオプションで提供。多経路で到達率を向上 |
| 夜勤・現場スタッフから回答が来ない |
○ 人的即応体制でサポート |
◎ スマートウォッチ振動通知で就寝中・作業中も到達 |
| 管理者が被災して誰も送信できない |
○ 震度5弱以上の地震発生時、安否確認システムが自動起動し、対象社員へ安否確認連絡を自動配信 |
◎ 設定震度(1以上)・エリアの地震発生時、気象庁電文の受信で管理者不在でも安否確認を自動配信。 |
| ログインを忘れて回答できない |
△ ログイン設計。パスワード忘れのリスクあり |
◎ パスワードレス対応。端末認証によりURL1タップで回答画面を表示。グッドデザイン賞2020受賞 |
| 安否は集まったが拠点状況が分からない |
△ 安否集計が中心。拠点統合管理は対応外または限定的 |
◎ 拠点別被災状況・停電・入館可否を統合管理。対策本部OSとして一元可視化 |
| 誰が出社できるか本部で把握できない |
△ 安否情報内での確認が中心 |
◎ 出社可否・交通手段を分離して収集・集計 |
| 複数拠点の状況を電話で確認している |
△ 管理画面での集計が中心 |
◎ 拠点ダッシュボードで全拠点状況をリアルタイム一覧化。6時間以内の判断を支援 |
| 物流停止・顧客対応の判断材料が揃わない |
△ 安否・セキュリティ統合情報として確認 |
◎ 拠点稼働・出社可否・物流状況を統合し、対策本部OSとして初動判断材料を集約 |
| 物理警備・施設セキュリティと統合したい |
◎ ALSOKグループの警備網・人的即応体制・施設連携との一体運用が可能 |
○ BCP初動支援に特化したSaaS設計。API連携で既存システムとの並行運用も可能 |
| 誰が出社できるか本部で把握できない |
△ 公式情報上の標準機能としての記載が確認できません |
◎ 出社可否・交通手段を分離して収集・集計 |
| 対策本部OSとして機能するか |
△ セキュリティ統合・安否収集が中心設計 |
◎ 発生後6時間以内の経営判断支援を設計思想の核に持つ対策本部OS |
| 家族の安否確認もしたい |
◎ 社員とその家族のみが利用できる掲示板機能 |
◎ 家族安否確認が標準装備(7名まで登録可)。GPS位置情報共有も可能 |
| 50名規模の中小企業でも導入したい |
△ 警備契約連動のためやや限定的 |
◎ 50名〜数千名まで同一製品で対応可能 |
※2026年5月時点の各社公式サイト・公開情報に基づきます。最新情報は各社公式サイトをご確認ください。
比較表から読み取れるこ
ALSOK安否確認サービスは、人的即応補完・物理警備統合・24時間監視網との連携という「総合セキュリティ統合型」に強みがあります。
安否コールは、「回答しやすい設計」「安否後の拠点情報を統合する」「6時間以内に対策本部が動ける対策本部OSを構築する」という実運用課題を設計の中心を置いています。
「ログイン不要」に見えて、実際はログインが必要なケースに注意
「管理者が動けなくても従業員が自律回答できる設計」を実現するには、ログインUXが鍵になります。発災直後という極度の混乱状態で「ログイン時の回答負荷」が生じると、回答完了率が大きく下がります。
注意:「ログイン不要」表記について
「ログイン不要」と表記されていても、初回登録・ログアウト後・機種変更後・長期未使用後などにIDとパスワードの再入力が必要になるシステムが多数あります。「パスワードレス(端末認証型)」かどうかは、導入前に必ず仕様を確認してください。
← スクロール →
| 確認ポイント |
ログイン型 (ALSOK等) |
ログイン簡略型 (一部パスワードレス) |
パスワードレス型 (端末認証・安否コール) |
| 初回ログイン | ID+パスワード必須 | ID+パスワード必須 | 端末登録のみ |
| 通常時の回答 | ログイン後に回答 | URL直接または簡略認証 | URLタップのみで即回答画面表示 |
| ログアウト後 | 再ログイン必須 | 再ログイン必要な場合あり | 端末認証で再開 |
| 機種変更後 | 再ログイン必須 (旧端末通知は届かない) |
再ログイン必要な場合あり | 新端末登録が必要 (ガイドで最小化) |
| URLタップ回答 | ログイン後に回答 | 一部対応 | タップのみで即回答画面表示 |
| 管理者被災時の自律回答 | ログイン時の回答負荷が障害になる対策本部OSの阻害要因 | 部分的に改善 | 設計で自律化従業員が自律的に回答完了 |
| 離脱リスク | 高パスワード忘れで離脱 | 中 | 低設計により軽減 |
※各タイプはシステムの設計分類であり、特定製品を直接評価するものではありません。導入前に必ず各製品の公式仕様をご確認ください。
「人的即応力」vs「設計で自律化」通知設計思想の根本的な違い
安否確認システムの本番は「実際の災害時」です。最も重要なのは「届けること」ではなく「回答が完了すること」、さらにその先の「6時間以内に対策本部が判断できること」です。
問題① 通知が届かない
メール遅延・未着(SMTPサーバ集中・スパムフィルター誤判定)、キャリア回線の混雑、端末電源OFFにより、通知が届かない従業員が一定数発生します。
解消策:SMS・スマートウォッチで多経路通知を実装
問題② 届いても回答されない
作業中・就寝中の通知見落とし、ログイン不能による回答断念、操作不慣れによる断念が重なり、「届いたが回答しなかった」従業員が発生します。
解消策:パスワードレス・スマートウォッチ振動で回答率を向上
ALSOK安否確認サービス
人的即応力で支える設計
ALSOKは「有人による即応補完」を強みとします。
人的即応体制が監視し、判断し、補完することで確実性を高めます。総合セキュリティ管理との統合という観点では大きな強みになります。
注意点:大規模災害時にオペレータ自身が被災・通信困難になるリスクがあります。
安否コール
自律的に稼働する設計
スマートウォッチへの振動通知により就寝中・作業中でも届き、パスワードレス回答(端末認証)によりURLをタップするだけで回答画面を表示します。気象庁電文連動の自動配信により、管理者不在でも通知が止まりません。 グッドデザイン賞2020で特にすぐれた機能デザインと評価されました。
対策本部OSという視点で見ると
「人が動けなくても情報が集まり続ける設計かどうか」が、実際の大規模災害での回答完了率と初動判断速度の差になります。
ALSOKの「人的即応補完」は、通常時・小規模インシデントでは大きな強みです。ですが、管理者自身が被災する可能性のある広域大規模災害では、設計で自律化する安否コールの思想が対策本部OSとしてより機能します。
BCP初動対応力の違い
ALSOK安否確認サービス
強み
| ・ | 綜合警備保障グループの人的即応補完体制(24時間365日) |
| ・ | 物理警備・施設セキュリティとの統合管理 |
| ・ | インシデント対応と安否確認の一体運用 |
| ・ | 警備ブランドによる社内稟議の通しやすさ |
| ・ | 総合セキュリティパッケージとしての一元契約 |
目的
人的即応補完による総合セキュリティ管理の一部としての安否確認
安否コール
強み
| ・ | 管理者不在・被災時でも自動配信が継続する設計 |
| ・ | スマートウォッチ標準・SMS通知配信オプションで現場到達率を向上 |
| ・ | パスワードレスで従業員が自律回答 |
| ・ | 拠点被災状況・停電・入館可否の統合管理 |
| ・ | 出社可否・交通手段の一元収集 |
| ・ | 対策本部向けダッシュボード(6時間以内の判断支援) |
| ・ | 家族安否確認標準装備(7名)・GPS可能 |
| ・ | 全災害種別(地震・津波・風水害・特別警報)自動対応 |
目的
管理者が動けなくても企業が止まらない、対策本部OSの構築
最大の分岐点
ALSOK安否確認サービスは「人的即応補完による総合セキュリティ統合」を強みとしています。安否コールは「安否収集から拠点状況の統合把握・6時間以内のBCP初動判断支援まで」を設計思想に持つ対策本部OSです。この違いは、南海トラフ巨大地震で甚大な被害が予想され、かつ日本の物流動脈である静岡県で、物流・食品・建設・エネルギーを担うグループが実際に直面したBCP初動の課題から生まれたものであり、後から機能を追加したものではありません。
発生後6時間以内に下すべき5つの経営判断
災害発生後6時間は、物流・顧客対応・拠点稼働の当日判断が集中する時間帯です。この6時間に対策本部が下すべき経営判断を、対策本部OSという視点で整理します。
判断 1
物流停止への初動対応(最初の2時間が勝負)
どのルートが止まっているか。どの代替ルートを使うか。顧客への納期影響をいつ・誰が連絡するか。サプライチェーン全体への波及を抑えるために最初の2時間が勝負です。
判断 2
拠点稼働優先順位の決定
どの拠点を優先稼働させるか。人員をどこに集中させるか。代替拠点に切り替えるかどうか。拠点被災状況・停電・入館可否が即座に可視化されていなければ、この判断は下せません。
判断 3
サプライチェーン維持判断
調達先の被災状況。在庫の優先配分先。生産継続の可否。物流と製造の両面から、継続可能な業務範囲を確定させる必要があります。
判断 4
顧客対応の優先順位
影響の大きい顧客から順に連絡する体制の立ち上げ。対応可能な業務範囲の確定。この連絡が遅れるほど、顧客信頼への影響が積み上がります。
判断 5
復旧計画の初期立案
事業再開の目標日程。優先復旧業務の定義。外部支援の要否判断。この初期立案が遅れると、復旧全体が後ろ倒しになります。この5つの判断すべてに共通するのは「情報が揃っていなければ判断できない」という事実です。安否コールはこの情報統合を対策本部OSとして実現します。
安否コールが対策本部OSとして設計された理由
静岡県は、南海トラフ巨大地震において甚大な広域同時被災が想定される地域のひとつです。さらに、港湾・物流・食品・製造インフラが集中する日本の物流動脈でもあります。
食品・物流・建設・エネルギーという社会インフラを担うグループが、「対策本部が何時間以内に経営判断できるか」という実際のBCP運用課題から設計されたのが安否コールです。
安否コールは「安否確認システム」ではなく、「対策本部が6時間以内に動き出せる基盤」として機能します。
料金・コスト構造の比較
比較時は「月額費用」だけではなく、SMS費用・訓練費用・サポート費用・運用定着コストを含めたTCO(総所有コスト)で比較されることをおすすめします。
| コスト項目 | ALSOK安否確認サービス | 安否コール |
| 初期費用 |
規模・構成依存 |
プランにより異なります。詳しくはお問い合わせください |
| 月額費用 |
中〜高価格帯(警備契約連動) |
月額5,000円〜の幅広いプランミニマム:月額5,000円〜 |
| SMS対応 |
公式情報上の標準機能としての記載が確認できません |
オプション対応あり |
| 家族安否機能 |
公式情報上の標準機能としての記載が確認できません |
標準装備(7名まで)。追加費用不要 |
| 無料トライアル |
45日間の無料トライアルあり |
1ヶ月無料トライアルあり(全機能使用可) |
| 小規模導入 |
警備契約連動のためやや限定的 |
50名規模から対応可能 |
| PoC・先行導入 |
要相談 |
対策本部先行導入モデルに対応。柔軟対応 |
ALSOKをご契約されている企業への補足
ALSOKの警備契約と安否確認サービスを一体で契約している場合は、安否確認部分のみを切り出した際の費用体系を事前にご確認ください。
どちらを選ぶべきか|企業規模・業種別の判断軸
ALSOK安否確認サービスが向いている組織
| ・ | ALSOKの警備・施設セキュリティをすでに利用しており、安否確認もグループ内で統合管理したい |
| ・ | 人的即応補完による24時間サポート体制の安心感を重視する |
| ・ | インシデント発生時の警備対応と安否確認を一体で運用したい |
| ・ | 総合セキュリティパッケージとして一元契約・一元管理したい |
| ・ | 警備ブランドによる社内稟議の通しやすさを重視する |
安否コールが向いている組織
| ・ | ALSOKの警備・施設セキュリティをすでに利用しており、安否確認もグループ内で統合管理したい |
| ・ | 物流・製造業・工場・医療介護など現場・夜間稼働が多い業種 |
| ・ | 管理者が被災・不在でも対策本部が自律的に動ける設計が必要 |
| ・ | 発生後6時間以内に物流停止・拠点稼働・顧客対応の判断を下したい |
| ・ | 対策本部OSとして機能するBCP初動基盤を構築したい |
| ・ | 警備契約とは別に、BCP初動に特化したシステムを独立選定したい |
| ・ | 静岡・東海・近畿・四国・九州などに拠点があり南海トラフ対策が急務 |
| ・ | 50名~数千名規模でコスト・機能バランスを重視する |
判断に迷う場合の確認軸
|
自社のBCP初動は、安否確認の完了で終わっていないか |
終わっていない場合: 安否コールが適合 |
|
管理者自身が被災した場合でも、対策本部は6時間以内に動けるか |
動けない場合: 安否コールの自律設計が必要 |
ALSOK契約企業こそ「機能要件で分けて考える」
ALSOKの警備・セキュリティサービスをご利用中の企業にとって、「安否確認もALSOKで」という選択は自然な発想です。しかし、この判断を下す前に一度だけ次の問いを立ててみてください。
「自社の対策本部は、災害発生後6時間以内に、物流停止・拠点稼働・顧客対応の優先順位を判断できるか。」
物理警備・施設セキュリティの目的
「不法侵入・犯罪・物理的リスクへの 人的即応対応 」です。ALSOKの最大の強みである24時間有人体制は、この領域で高い効果を発揮します。
対策本部OSの目的
「 企業が止まらないための経営判断基盤を6時間以内に機能させること 」です。安否情報・拠点状況・出社可否・物流停止の統合可視化が核心です。
この2つは、求める機能要件が根本的に異なります。統合の利便性は魅力ですが、「BCP初動で本当に必要な機能」を独立した軸で整理することが、結果として対策本部の実力向上につながります。
以下の3点をご確認ください
| ・ | 管理者が被災した夜間でも、気象庁連動で自動配信・従業員がパスワードレスで自律回答できるか |
| ・ | 対策本部が、全拠点の被災状況・出社可否・停電状況を6時間以内にリアルタイムで一覧できるか |
| ・ | 物流停止・拠点稼働・顧客対応の初動判断材料が、安否情報と統合して可視化されているか |
「警備統合運用との切り分けPoC」という選択肢
安否コールでは、既存のALSOK契約を変えることなく、安否確認・対策本部OS部分だけを並行検証するPoC導入に対応しています。この検証の結果として、「ALSOK統合のままで十分」「対策本部OSとして独立強化すべき」という判断を、実データをもとに下せるようになります。
機能要件の切り分け整理 警備統合 vs 対策本部OSの要件を分離
ALSOK並行での先行PoC 既存契約を維持しながら対策本部OSを検証
6時間判断速度の比較検証 実データで初動改善効果を確認
最適構成の選択・展開 稟議リスク最小で意思決定
ALSOKサービスとの比較検討中の企業担当者にとって、既存契約を維持しながら並行検証できるこのアプローチは、 稟議リスクを低く抑えた導入方法のひとつ です。
自社のBCP初動成熟度はどのレベルにありますか
| Lv.1 |
安否確認のみ(メール・電話) 安否が集まるだけ。拠点状況・出社可否は把握できない。管理者が被災すると事業が止まる。6時間以内の経営判断は難しい。 |
| Lv.2 |
安否確認システム導入(セキュリティ統合型) 人的即応補完体制・警備統合で安否収集をサポート。ALSOK安否確認サービスはこの設計に強みを持つ。安否収集後の拠点統合管理は対応外または限定的。 |
| Lv.3 |
多経路通知・回答しやすい設計 SMS・スマートウォッチ・パスワードレスで高い回答完了率を実現。管理者不在でも自律回答。安否コールはここ以降のレベルに対応。 |
| Lv.4 |
対策本部OS(統合基盤・6時間判断設計) 安否・拠点状況・出社可否・物流停止が対策本部ダッシュボードに統合。6時間以内の経営判断が可能。電話確認の集中が解消。 |
| Lv.5 |
自律分散型BCP(実戦型・高水準) 南海トラフ広域同時被災シナリオにも対応。グループ横断統合・物流・社会インフラ維持まで設計。管理者不在でも自律稼働。静岡モデルの実戦設計。 |
導入前に確認すべき5つのチェックポイント
| ■ |
「安否確認の完了後」に対策本部が6時間以内に動ける設計があるか |
| 物流停止・拠点稼働・顧客対応の初動判断に必要な情報が、6時間以内に対策本部に揃う設計になっているか確認しましょう。この設計がなければ、どのシステムを選んでもBCP初動は機能しません。 |
| ■ |
管理者が被災しても自動で動く設計になっているか |
| 管理者不在・被災時でも気象庁連動で自動配信され、従業員がパスワードレスで自律回答できる設計かを確認しましょう。「人的即応補完」に依存する設計では、広域大規模災害でオペレータ自身が被災するリスクがあります。 |
| ■ |
多経路通知設計になっているか |
| SMS・スマートウォッチなど複数の通知経路が標準で確保されているか。夜間・現場作業中にも届く設計かを確認してください。SMSがオプション扱いの場合は総コストも確認が必要です。 |
| ■ |
拠点情報を対策本部で統合できるか |
| 安否情報だけではBCPとして十分ではありません。拠点被災状況・出社可否・停電状況を一元管理し、対策本部が即座に判断できる可視化があるかを確認してください。 |
| ■ |
警備契約と対策本部OSを機能要件で独立評価しているか |
| セキュリティ統合の利便性と、BCP初動に必要な機能要件は別軸で評価することをおすすめします。ALSOKの物理警備・施設セキュリティはそのままに、対策本部OS部分のみを独立選定する選択肢も検討してください。 |
よくある質問
-
QALSOK安否確認サービスと安否コールの最大の違いは何ですか?
AALSOK安否確認サービスは、綜合警備保障グループの人的即応補完体制・物理セキュリティとの統合管理・24時間監視網との連携を強みとする「総合セキュリティ統合型システム」です。安否コールは、南海トラフ巨大地震での甚大な被害が予想され、日本の物流動脈でもある静岡県の国際物流大手グループ(約140社)の実戦BCP課題から設計された「対策本部OS」であり、管理者が被災していても従業員が自律回答できる設計と、発生後6時間以内の経営判断を支援する拠点統合管理を強みとしています。選定の分岐点は「人的即応補完型のセキュリティ統合を優先するか」「企業が止まらない対策本部OSを独立設計するか」にあります。 -
QなぜBCP初動の「6時間」が重要なのですか?
A災害発生後6時間は、物流停止への初動対応・代替拠点切り替え・顧客対応優先順位・人員配置の意思決定が集中する時間帯です。この6時間に下せた判断の質と速度が、その後の事業再開時期と損失規模を大きく左右します。多くの企業がこの6時間を安否情報収集と個別電話確認で費やしており、結果として回避できたはずの損失が積み上がっています。対策本部OSを正しく設計することで、この6時間の質が根本から変わります。 -
Q「人的即応力で支える」設計と「設計で自律化する」設計の違いは?
AALSOKは「有人による即応補完」を強みとします。人的即応体制が監視し判断し補完することで確実性を高めます。安否コールは「管理者自身が被災していても、従業員が自律的に回答完了できる」ことを設計思想の核に置いています。パスワードレス回答・スマートウォッチ通知・気象庁電文自動配信により、人に依存せず対策本部が動き出せる設計です。どちらが優れているということではなく、自社のBCP体制においてどちらの思想が合っているかで選ぶことが大切です。 -
QなぜSMSやスマートウォッチが重要なのですか?
A大規模災害時はメール遅延・未着が多発します。SMSはメールより小さいデータサイズで送信できるためキャリア回線の混雑時も到達しやすく、スマートウォッチへの振動通知は就寝中・作業中の従業員にも届けることができます。安否確認の目標は「送信成功」ではなく「回答完了」です。管理者が被災した状況でも回答完了率を維持できる通知設計思想が、対策本部OSとして機能するかどうかの差になります。 -
Q「対策本部OS」とは何ですか?
A対策本部OSとは、対策本部が意思決定に必要な情報を統合し、発生後6時間以内の初動行動を加速するための基盤のことです。安否情報の収集だけでなく、拠点被災状況・出社可否・物流停止・顧客影響を一元的に可視化し、経営判断を支援する機能を指します。「安否確認システム」ではなく「対策本部OSとして機能するか」という問いが、BCP初動における本質的な選定軸になります。 -
Q大企業でも安否コールは使えますか?
Aはい、ご活用いただけます。特にお勧めしているのが「警備統合運用との切り分けPoC」です。ALSOKの物理警備・施設セキュリティはそのまま継続しつつ、安否確認・対策本部OS部分だけを先行で安否コールで検証することが可能です。「6時間以内の判断速度がどう変わるか」を実データで確認してから全社展開を判断できます。 -
QALSOKと総合契約している企業はどうすべきですか?
AALSOKの物理警備・施設セキュリティと対策本部OS(安否確認・BCP初動支援)を「別の機能要件」として整理することをお勧めします。「6時間以内に対策本部が経営判断を下せるか」という軸で機能要件を独立評価することで、最適な選定ができます。安否コールはAPI連携にも対応しており、既存のALSOKシステムとの並行運用も可能です。 -
Q南海トラフ地震対策として選ぶ際の注意点は?
A南海トラフ地震では静岡・東海・近畿・四国・九州の広域同時被災が想定されており、港湾・物流ハブ・食品工場・製造拠点が同時に被災するシナリオへのBCP設計が必要になります。安否コールは、この広域同時被災において甚大な被害が予想されている日本の物流動脈・静岡県で、物流・食品・建設・エネルギーを担うグループの実運用要件から設計されており、広域多拠点での6時間以内の判断を支援する設計が組み込まれています。
「人を確認するシステム」から「企業を止めないシステム」へ
まとめ
安否確認システムとは、本来「人の無事を確認するシステム」でした。
しかし、南海トラフ巨大地震のような広域同時災害において企業が本当に必要としているのは、それだけではありません。
「安否が集まった後、物流を止めないか。拠点を動かすか。顧客に何時に連絡するか。」
これらの経営判断を、被災直後の最重要6時間以内に下せる基盤があるかどうか。
それが、「安否確認システムの選定」ではなく、「企業を止めないための対策本部OS設計」という問いです。
ALSOK安否確認サービスは、「人的即応補完・物理警備・24時間監視網による総合セキュリティ統合」を強みとする、ALSOKの警備・施設セキュリティとの統合を重視する企業に適合します。
安否コールは、「管理者が動けなくても企業が止まらない、対策本部OSの設計」を提供します。発生後6時間以内の経営判断を支援するBCP初動独立基盤を重視する企業に適合します。 安否コールは、南海トラフ巨大地震で甚大な被害が予想され、かつ日本の物流動脈である静岡県で、この問いへの答えとして設計されました。
![]() |
「安否コール」お問い合わせ |

「世界中のコミュニケーションをクラウドで最適に」することをミッションとして掲げ、2000社以上の法人向けのデジタルコミュニケーションとデジタルマーケティング領域のクラウドサービスの開発提供を行う防災先進県静岡の企業。1977年創業後、インターネット黎明期の1998年にドメイン取得し中堅大手企業向けにインターネットビジネスを拡大。”人と人とのコミュニケーションをデザインする”ためのテクノロジーを通じて、安心安全で快適な『心地良い』ソリューションを提供している。
- 事業内容
- デジタルマーケティング支援
デジタルコミュニケーションプラットフォーム開発提供 - 認定資格
- ISMS ISO/IEC27001 JISQ27001認定事業者(認定番号IA165279)
プライバシーマーク JISQ15001取得事業者(登録番号10824463(02))
ASP・SaaSの安全・信頼性に係る情報開示認定事業者(認定番号0239-2004)













