震度トリガーの検知から配信開始までの処理フロー
安否確認システムが「自動で動き出す」仕組みは、気象庁の震度情報をリアルタイムで受信するAPIとシステム内部の条件判定エンジンが組み合わさって実現しています。
震度情報の受信と条件判定の仕組み
多くのクラウド型安否確認システムは、気象庁が提供する地震情報や民間気象サービスのデータを利用して震度情報を取得しています。地震が発生すると、震度・観測地域・発生時刻などの情報がシステムへ配信されます。システムはこのデータを受け取った瞬間、あらかじめ設定された条件テーブル（閾値震度・対象エリア・トリガー種別）と照合し、配信すべきかどうかを自動で判定します。
条件が一致した場合、配信ジョブが即時生成されます。本社・支社ごとに異なる震度閾値を設定しているシステムでは、地域ごとの条件テーブルを並列で評価する設計が取られています。このため、東京と大阪の拠点で配信条件が異なっていても、それぞれ独立して判定・配信が開始されます。
配信ジョブの生成と通知チャネルへの分配
条件判定でトリガーが確定すると、システムはキュー（待ち行列）に配信タスクを積みます。配信対象となる従業員リストを取得し、各員に紐付けられた通知手段（メール・SMS・プッシュ通知）へタスクが振り分けられます。大規模企業では数百～数千件のタスクが一度に生成されますが、クラウドシステムは負荷分散のため複数のワーカープロセスでキューを消化する設計を取るのが一般的です。
この処理が完了するまでの時間は、システムによって数秒～数十秒の差があります。配信完了のログは管理画面で確認できるものが多く、「何時何分にどのチャネルで何件配信されたか」を事後に追うことができます。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
未回答者への再送制御（リトライ）の動作原理
リトライ機能は「一定時間後に再送する」というシンプルな説明にとどまりがちですが、実際には回答状態の追跡・チャネル切り替えロジック・再送回数の上限管理という3層の処理が組み合わさって動いています。
回答状態の追跡と未回答判定のタイミング
配信後、システムは各従業員の回答状態を「未送信」「送信済み・未回答」「回答済み」という状態遷移で管理します。メールが到達しても開封されなければ「未回答」として扱われます。SMSでは開封確認ができないため、回答フォームへの送信操作がない場合は未回答と判定されます。
リトライジョブはこの状態テーブルを一定間隔でスキャンし、未回答のまま設定時間を超過したレコードを抽出します。抽出されたリストに対して再送タスクが生成され、キューに追加されます。スキャン間隔の設定はシステムによって異なります。回答が届いた時点で当該レコードはリトライ対象から除外されます。
チャネル切り替えと再送回数の上限制御
1回目の配信がメールで到達しなかった場合、2回目以降はSMSや電話音声に切り替えて再送する設計のシステムがあります。これは「フォールバックチャネル」と呼ばれる仕組みで、設定画面で優先順位を指定しておくと自動で切り替わります。チャネルを切り替えながら再送するたびに、到達確認の方式も変わるため、システム内部の状態管理は単純な「送った/送っていない」ではなく、チャネルごとの到達状態をまとめて保持する設計になっています。
再送回数の上限に達した場合、システムはそれ以上の自動送信を停止し、管理者へ「未回答のまま上限到達」として通知します。この通知を受けた管理者が電話などの個別手段でフォローするフローに移行する設計です。上限をどこに設定するかは運用コストと到達率のトレードオフになるため、訓練時に実際の再送ログを見て調整することが効果的です。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
回答データの受信・集計・ダッシュボード反映の仕組み
従業員が回答ボタンを押した瞬間から、管理者のダッシュボードに数字が反映されるまでの間には、データの受信・検証・集計という処理が走っています。このフローを理解することで、大規模訓練時の集計遅延への備えや、集計結果の正確性を客観的に評価できます。
回答受信と重複防止の処理
従業員がフォームを送信すると、サーバーはリクエストを受け付けると同時に、送信元のユーザーIDと配信IDを照合して「どのイベントへの回答か」を特定します。同一ユーザーから複数回送信された場合（通信不安定による二重送信など）は、最新の回答で上書きするか、最初の回答を採用するかを設定で切り替えられるシステムがあります。
回答データは従業員ごとのレコードとして保持され、「安否状態（安全/負傷など）」「出勤可否」「コメント」「回答時刻」「使用チャネル」などのフィールドが記録されます。これらのフィールドは後の集計・フィルタリング・CSVエクスポートに使用されます。
リアルタイム集計とダッシュボードへの反映
回答データはリアルタイムで集計テーブルに反映されます。集計の実装方式はシステムによって異なりますが、回答が届くたびに集計値をインクリメントする「イベント駆動型」か、一定間隔でバッチ処理を走らせる「ポーリング型」かで、ダッシュボードの更新頻度に差が出ます。イベント駆動型のシステムは回答から表示まで数秒以内で反映されますが、大量同時回答時の負荷が課題になることがあります。
管理画面のダッシュボードは、部署別・拠点別などのディメンションでフィルタリングができる設計のシステムが多く、フィルタをかけるたびに集計クエリが走る仕組みになっています。数千人規模の組織でフィルタリングが遅延する場合は、集計テーブルのインデックス設計や、サマリーテーブルを事前に持つアーキテクチャを採用しているかどうかがパフォーマンスに影響します。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料を取り寄せて機能や特徴をさまざまな製品で比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）で安否確認システムの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
代理入力機能の権限制御と監査ログの動作
本人が回答できない状況で管理者が代わりに入力する「代理入力機能」は、単なる手動入力ではなく、権限検証・本人レコードの書き換え・操作ログの記録という一連の処理を経て実行されます。
代理入力時の権限検証フロー
管理者が代理入力を実行しようとすると、システムはまずログイン中のアカウントに代理入力権限が付与されているかどうかを確認します。権限がない場合は操作がブロックされます。次に、入力対象の従業員が自分の管理範囲（部署・グループ）に含まれているかどうかを検証するシステムもあります。これにより、権限範囲外の従業員への誤入力や不正書き換えを防ぐ設計になっています。
権限検証を通過すると、対象従業員のレコードに「回答者がシステム本人か管理者か」を示すフラグが付与された状態でデータが保存されます。ダッシュボードや集計レポートにこのフラグが表示されるシステムでは、どの回答が代理入力によるものかを一見して識別できます。
操作ログ（監査ログ）に記録される情報
代理入力が実行されると、監査ログには「操作したアカウントID」「対象従業員のID」「入力内容」「操作時刻」が自動で記録されます。このログは管理者による削除や改ざんを制限する仕組みを備える製品もあり、内部統制や事後の振り返りに活用できます。監査ログをCSVでエクスポートできるシステムでは、総務・法務部門への報告資料をスムーズに作成できます。
代理入力の操作ログは、訓練時の記録としても有効です。「どの拠点で何件の代理入力が発生したか」を訓練後に集計することで、スマートフォン操作に不慣れな従業員の分布や、個別フォロー体制の課題を把握する手がかりが得られます。
この記事をご覧の方には、以下の記事もおすすめです。あわせて参考にしてください。
家族連絡・災害掲示板・訓練配信の内部処理
安否確認システムには、会社への報告以外のコミュニケーション機能や、平常時の訓練機能が組み込まれているものがあります。これらの機能がどのような処理の上に成り立っているかを把握しておくと、運用ルールの設計がしやすくなります。
家族連絡機能のメッセージルーティング
家族連絡機能は、従業員と登録された家族ユーザーの間でメッセージをやり取りできる仕組みです。会社への安否報告とは別のメッセージチャンネルが用意されており、従業員が入力したメッセージは、家族ユーザーに紐付いた専用の画面に届く設計です。会社の管理者はこのチャンネルの内容を閲覧できない設定にしているシステムが多く、プライバシーの分離が処理レベルで担保されています。
家族ユーザーの登録は、従業員が事前に家族のメールアドレスや電話番号を登録することで行います。家族側は招待メールのリンクから専用アカウントを作成し、災害時にはそのアカウントでメッセージを受け取ります。家族向けの通知手段（プッシュ・メール・SMS）は従業員本人とは別に設定できるシステムもあり、家族のデバイス環境に合わせた設定が可能です。
訓練配信モードと本番配信の処理上の違い
訓練データを本番データと分離して管理できるシステムもあります。従業員が受け取る通知のヘッダーに「訓練」の文字が入るほかは、回答フォームの操作は本番と同一です。これにより、実際の操作フローを体験させつつ、本番の集計データを汚染しない設計になっています。
訓練結果のレポートは訓練イベント単位で保持され、前回・前々回との回答率の推移を比較できるシステムもあります。「訓練のたびに回答率が上がっているか」「未回答の集中している部署はどこか」を時系列で確認できると、訓練の効果測定と次の改善策の立案につなげやすくなります。
安否確認システムの機能に関するよくある疑問（FAQ）
安否確認システムの動作原理についてよく寄せられる疑問をまとめました。システムの仕組みを正確に理解したい方の参考にしてください。
- ■Q1：震度トリガーが誤作動した場合、配信を止めることはできますか？
- 多くのシステムでは、トリガーが発動した後でも管理者が手動で配信をキャンセルできる機能を備えています。配信ジョブがキューに積まれた段階であればキャンセルが間に合いますが、既に送信済みの通知を取り消すことはできません。トリガーの誤作動を防ぐには、震度閾値を保守的に設定し、テスト環境で条件を事前に検証しておくことが有効です。
- ■Q2：回答データはどのくらいの期間保存されますか？
- 保存期間はシステムやプランによって異なります。1年間保持するものから、追加費用で長期保管に対応するものまでさまざまです。BCPの観点から過去の訓練記録を長期間保持したい場合や、監査ログの法定保存要件がある場合は、契約前にデータ保持期間と削除ポリシーをベンダーに確認してください。
- ■Q3：クラウド障害時でも安否確認は機能しますか？
- クラウド型システムでは、データセンターが複数拠点に分散されているものや、障害発生時に自動でフェイルオーバーする設計を採用しているものがあります。SLA（サービスレベル合意）でシステムの稼働率が明記されているベンダーを選ぶと、可用性を客観的に評価できます。ベンダーのインフラ冗長化の仕様は導入前に必ず確認しましょう。
まとめ
安否確認システムの主要機能は、震度情報の受信と条件判定・配信ジョブの生成・回答状態の追跡・リトライの再送制御・データの集計・監査ログの記録という一連の処理で成り立っています。機能の動作原理を理解しておくと、トリガー条件の設計・訓練のサイクル設定・権限体制の整備など、運用設計をより具体的に詰めることができます。システムを選ぶ際は、カタログの機能一覧だけでなく、処理の仕組みについてもベンダーに確認してみてください。
