災害時の在館者の安否と所在をリアルタイムに把握し初動対応の遅れを防ぐ方法

地震や火災が発生した直後、最も重要なのは建物内にいる人の安全確認です。しかし多くの企業では、入退館の記録は入退室管理システムに、安否の回答は安否確認システムに、フロアごとの在席状況は別の台帳やチャットに散らばっています。災害発生から数分以内に全員の所在と安否を突き合わせたいのに、それぞれのシステムを個別に開いて目視で照合しているのが現実です。この数分の遅れが避難誘導の判断を鈍らせ、最悪の場合は人命に関わります。

この記事は、従業員50〜500名規模のオフィスビルや自社ビルを持つ企業で、総務・防災担当を兼務している管理部門の方を想定しています。読み終えると、災害発生から5分以内に在館者リストと安否回答を突き合わせ、未回答者の所在フロアをチャットで防災チームに共有するまでの一連の運用フローを自社に導入できるようになります。なお、数千名規模の大規模キャンパスや工場向けの専用BCP統合基盤の設計、各ツールの網羅的な機能比較は扱いません。

本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、災害発生時に在館者名簿・安否回答・未確認者リストを自動で突き合わせてチャットに投稿するまでの運用手順書のたたき台が手に入ります。

Workflow at a glance: 災害時の在館者の安否と所在をリアルタイムに把握し初動対応の遅れを防ぐ方法

• Step 1: 在館者リストをリアルタイムに維持する (Akerun) (受付・入退室管理システム)
• Step 2: 安否確認を自動発報し回答を収集する (安否確認サービス2) (安否確認システム)
• Step 3: 在館者リストと安否回答を突き合わせて未確認者をチャットに投稿する (Microsoft Teams) (Web会議システム)

なぜ災害時に在館者の安否と所在が即座に分からないのか

入退館データと安否確認が別システムで動いている

入退室管理システムは物理的なカードリーダーやスマートロックで入退館の事実を記録します。一方、安否確認システムはメールやアプリのプッシュ通知で社員に安否を問い合わせ、回答を集計します。この2つは本来まったく別の目的で導入されているため、データの形式も管理者も異なります。結果として、入退館記録では建物内にいるはずの人が安否確認に未回答なのか、そもそも外出中で建物にいないのかを瞬時に判別できません。

在席状況の把握が属人的になっている

フリーアドレスやリモートワークが広がった結果、座席表だけでは誰がどのフロアにいるか分かりません。多くの企業では、フロアごとの在席確認を防災担当者が目視や内線電話で行っています。災害時にこの作業を人力で回すと、確認漏れや二重確認が発生し、初動対応が10分、20分と遅れていきます。

情報の集約先が決まっていない

入退館データを見る人、安否確認の管理画面を見る人、現場で声掛けする人がそれぞれ別の場所で作業しているケースが大半です。情報を一か所に集める手順が決まっていないため、災害対策本部が全体像を把握するまでに何度も電話やメールのやり取りが発生します。この集約の遅れこそが、避難誘導の判断を遅らせる最大の原因です。

重要な考え方：在館者リストと安否回答を自動で突き合わせ、未確認者だけを即座に抽出する

災害対応で最も価値があるのは、全員の安否が分かることではなく、まだ安否が分からない人が誰で、どこにいる可能性が高いかを素早く特定することです。全員に一斉通知を送って回答を待つだけでは、未回答者が建物内にいるのか外出中なのか区別がつきません。

この課題を解決する原則は、入退室管理システムが持つ最新の在館者リストを正とし、安否確認の回答状況と突き合わせることです。在館記録があるのに安否未回答の人だけを抽出すれば、建物内で身動きが取れない可能性がある人を優先的に捜索できます。

突き合わせの粒度はフロア単位で十分

入退室管理システムの多くは、最終入館ゲートの情報しか持っていません。つまり、何階のどの部屋にいるかまでは分からないケースが大半です。しかし、フロアごとにカードリーダーが設置されている場合は、最終通過フロアを特定できます。完璧な位置情報を求めるのではなく、最終通過フロアという粗い粒度でも十分に捜索範囲を絞り込めます。

突き合わせは事前に仕組みを作っておく

災害が起きてからデータの突き合わせ方法を考えていては間に合いません。平時のうちに、入退室管理システムからの在館者データ取得、安否確認システムの回答データ取得、両者の突き合わせ、結果のチャット投稿という一連の流れを自動化しておくことが不可欠です。

災害発生から5分以内に未確認者リストをチャットに届けるワークフロー

ステップ 1：在館者リストをリアルタイムに維持する（Akerun）

平時から、Akerunの入退室ログを使って在館者リストを常に最新の状態に保ちます。Akerunはクラウド上で入退室履歴をリアルタイムに記録しており、APIを通じて現在の在館者を取得できます。総務担当者は月に1回、在館者リストが実態と合っているかを抜き打ちで確認します。具体的には、任意の時間帯にAkerunの管理画面で在館者一覧を表示し、実際にオフィスにいる人と照合します。退館処理をせずに退出する尾行退出が多い場合は、退館忘れ通知の設定や、翌朝の自動リセットルールを追加します。この日常的なメンテナンスが、災害時のデータ精度を左右します。

ステップ 2：安否確認を自動発報し回答を収集する（安否確認サービス2）

災害発生時、安否確認サービス2が気象庁の地震情報や自治体の防災情報と連動して自動的に安否確認を発報します。社員にはメール、アプリ通知、LINEなど複数の経路で安否確認が届き、無事・被害あり・出社不可などの選択肢で回答します。防災担当者がこのステップで行うことは、発報後3分の時点で管理画面を開き、回答率を確認することです。回答率が低い場合は、安否確認サービス2の再送機能を使って未回答者に再通知を送ります。安否確認サービス2は回答結果をCSV形式でエクスポートでき、APIでの取得にも対応しています。

ステップ 3：在館者リストと安否回答を突き合わせて未確認者をチャットに投稿する（Microsoft Teams）

ここが最も重要なステップです。Akerunの在館者リストと安否確認サービス2の回答データを突き合わせ、在館記録があるのに安否未回答の人を抽出します。この突き合わせは、事前に用意したスプレッドシートのテンプレートで行います。Akerunから取得した在館者の社員番号と、安否確認サービス2から取得した回答済み社員番号を照合し、差分を未確認者リストとして出力します。

出力された未確認者リストは、Microsoft Teamsの防災対策チャネルに投稿します。投稿内容には、未確認者の氏名、所属部署、最終通過フロアを含めます。各フロアの防災担当者はこの投稿を見て、自分の担当フロアの未確認者を優先的に捜索します。捜索結果もMicrosoft Teamsに返信する形で報告し、対策本部がリアルタイムに状況を把握できるようにします。

この突き合わせからチャット投稿までの作業は、Power Automateなどの自動化ツールで事前に構築しておくことを推奨します。ただし、自動化が難しい場合は、手順書に沿って手動で実施しても、慣れれば5分以内に完了できます。四半期に1回の防災訓練で必ずこの手順を実行し、所要時間を計測してください。

この組み合わせが機能する理由

Akerun：クラウドベースで在館者データをリアルタイムに取得できる

Akerunを選定した理由は、クラウド型の入退室管理システムとしてAPIが公開されており、在館者データを外部から取得しやすい点にあります。オンプレミス型の入退室管理システムでは、災害時にサーバーが停止するとデータにアクセスできなくなるリスクがありますが、Akerunはクラウド上にデータがあるため、オフィスのサーバーが被災しても管理画面やAPIからデータを取得できます。一方で、Akerunはスマートロック型のため、フラッパーゲートのような大規模ゲートとの連携には追加の検討が必要です。また、尾行退出による在館データの不正確さは完全には防げないため、前述の運用ルールで補う必要があります。

安否確認サービス2：気象庁連動の自動発報と複数経路での通知

安否確認サービス2は、トヨクモが提供する安否確認に特化したサービスで、気象庁の地震速報と連動して人手を介さず自動で安否確認を発報できます。防災担当者が被災して操作できない状況でも、システムが自動で動く点が災害対応において決定的に重要です。メール、アプリ、LINEなど複数の通知経路を持つため、1つの経路が使えなくても別の経路で届く冗長性があります。注意点として、安否確認サービス2の回答データをAPIで取得する場合は、事前にAPI連携の設定とテストが必要です。CSV手動エクスポートでも運用は可能ですが、その分だけ所要時間が増えます。

Microsoft Teams：防災チャネルへの即時共有と双方向のやり取り

未確認者リストの共有先としてMicrosoft Teamsを選定した理由は、多くの企業で日常的に使われており、災害時にも追加のログインや操作習得が不要な点にあります。防災対策専用のチャネルを事前に作成しておけば、未確認者リストの投稿、フロア担当者からの捜索報告、対策本部からの指示をすべて1つのスレッドで時系列に管理できます。メールと異なり、既読状況やリアクション機能で情報の到達確認もできます。ただし、Microsoft Teamsはインターネット接続が前提のため、通信インフラが完全に途絶した場合の代替手段として、トランシーバーや館内放送との併用を計画しておく必要があります。

Recommended tool list

結論：在館データと安否回答の突き合わせを平時に仕組み化しておくことが災害時の初動を決める

災害時の安否確認が遅れる根本原因は、在館者データと安否回答が別々のシステムに閉じていて、突き合わせの手順が決まっていないことにあります。Akerunで在館者リストをクラウド上にリアルタイムで維持し、安否確認サービス2で自動発報と回答収集を行い、その差分をMicrosoft Teamsの防災チャネルに投稿する。この3ステップの流れを平時に構築し、四半期ごとの防災訓練で実際に回すことで、災害発生から5分以内に未確認者を特定できる体制が整います。

まずは次の防災訓練の日程を確認し、Akerunの在館者データ取得と安否確認サービス2の回答データ取得を手動で試してみてください。突き合わせの手順書を1枚作り、訓練で所要時間を計測するところが最初の一歩です。

Mentioned apps: Akerun, 安否確認サービス2, Microsoft Teams

Related categories: Web会議システム, 受付・入退室管理システム, 安否確認システム

Related stack guides: 危機発生時の情報収集から対外発信までの初動対応を迅速化し企業の信頼を守る方法, 災害時の従業員安否確認と事業継続判断を連動させ初動対応の遅れを防ぐ方法, 会議室の予約と実際の利用にズレが生じる問題を解消し無駄な増床投資を防ぐ方法, 会議室予約と備品準備を連動させて会議開始直前の準備漏れをゼロにする方法, トップ営業のノウハウを組織の共有資産に変えて営業力の属人化を解消する方法