---
title: "安否確認システムとは？仕組み・費用相場と自社に合う選び方を開発会社が解説"
url: "https://www.issoh.co.jp/column/details/15302/"
published: 2026-07-17
updated: 2026-10-12
categories: ["業務システム"]
publisher: "株式会社一創"
---

# 安否確認システムとは？仕組み・費用相場と自社に合う選び方を開発会社が解説

地震や台風の発生直後は音声通話がつながりにくくなり、電話連絡網だけでは従業員の無事を確かめきれません。安否確認システムは、災害時に安否確認の連絡を自動で一斉配信し、回答を自動集計する仕組みで、この初動の課題を解決します。本記事では、システムの動作の流れと主な機能、サービスの類型と費用の目安、選定基準7項目までを受託開発会社の視点で整理しました。気象庁の防災情報XMLから最大震度を読み取って配信可否を判定する実装例も載せています。SaaSの導入で足りる企業と、人事・勤怠システムとの連携や自社開発を検討すべき企業の線引きも示します。BCPの初動を具体的に設計したい方に向けた内容です。

## まとめ：安否確認システム導入の判断要点

安否確認システムとは、地震などの災害発生時に従業員へ安否確認の連絡を自動配信し、回答をリアルタイムに集計するツールを指します。気象庁の震度速報と連動して人手を介さず配信が始まるため、深夜や休日でも初動が止まりません。

導入判断の結論は次の通りです。単一拠点・従業員500名未満の企業なら、専業ベンダーのSaaSをそのまま導入すれば足ります。一方、複数拠点で人事異動が多い企業や、協力会社・家族まで確認範囲を広げたい企業は、人事・勤怠システムとの従業員マスタ連携まで含めて設計しないと、名簿の陳腐化で回答率が下がっていきます。費用は従業員数に連動する月額課金が主流で、小規模なら月額数千円台からが相場です。

選定では、配信手段の多重化・未回答者への自動再送・訓練機能を優先して確認してください。製品の知名度より、自社の名簿運用と訓練の続けやすさが定着を左右します。

## 安否確認システムの定義と災害発生から集計までの基本的な仕組み

最初に、安否確認システムがどのような順序で動き、従来の連絡手段と何が違うのかを押さえます。仕組みを理解しておくと、後半の選定基準の意味がつかみやすくなります。

### 地震・気象情報と連動した自動配信から回答集計までの動作フロー

安否確認システムの動作は、配信のきっかけとなる災害情報の受信から始まります。多くのサービスは気象庁が発表する震度速報や特別警報と連動しており、「震度5弱以上の地震が対象地域で発生したら配信する」といった条件をあらかじめ設定できる仕組みです。条件に合致すると、管理者が操作しなくてもメールやアプリのプッシュ通知で安否確認の質問が全従業員へ届きます。

ここで基準になる震度階級は、気象庁が0・1・2・3・4・5弱・5強・6弱・6強・7の10階級で定めています（[気象庁「震度について」](https://www.jma.go.jp/jma/kishou/know/shindo/index.html)）。5弱と5強、6弱と6強は別の階級として扱われるため、配信条件を社内規程に書くときは「5弱以上」のように弱・強まで明示してください。「震度5以上」という書き方では、システム側の設定値と規程が一対一に対応しません。

従業員はスマートフォンから「無事」「負傷あり」「出社可否」などの選択肢を1〜2タップで回答します。回答は管理画面に即時集計され、部署別・拠点別の回答状況を一覧で追えます。深夜に発災しても、担当者が目を覚ます前に第一報の集計が進んでいる状態をつくれることが、このフローの核心です。

### 電話連絡網・一斉メールと比べた場合の到達速度と集計負荷の違い

電話連絡網の弱点は、2011年3月の東日本大震災で広く認識されました。発災直後は音声通話へアクセスが集中し、携帯各社が大規模な発信規制を実施したため、つながらない番号に何度もかけ直す作業へ時間を奪われた企業が多くあります。連絡網は途中の1人が不通になると後続全員へ伝わらない、という構造的な弱点も抱えています。

手動の一斉メールは配信自体はできるものの、返信の集計を表計算ソフトで人力処理する負担が残ります。従業員300名の返信を1件ずつ転記すると、集計だけで数時間かかる計算です。安否確認システムは配信の自動化と集計の自動化を同時に解決する点で、この両者と役割が異なります。

### 安否確認サービスに共通する標準機能と周辺機能の具体的な守備範囲

標準機能として、ほぼ全てのサービスが自動配信・自動集計・未回答者への再送・掲示板機能を備えています。ここは製品間の差が小さい領域です。

- 災害情報と連動した自動配信と、震度などの配信条件の設定
- 回答の自動集計と部署・拠点別の絞り込み表示
- 未回答者への自動再送と管理者からの個別連絡
- 従業員同士の情報共有に使える掲示板・メッセージ機能

差が出るのは周辺機能です。家族の安否確認、多言語配信、訓練の自動実施、人事システムとの名簿連携などは対応範囲がサービスごとに分かれます。この周辺機能こそ、後述する選定基準の中心になります。

## 気象庁の防災情報XMLと連動して配信条件を判定する処理の実装例

「震度と連動して自動配信する」という説明は各社のサイトに並びますが、内側で何が起きているかまで書かれた資料は多くありません。判定の材料は公開されているため、手元で再現できます。ここでは気象庁が無償公開している防災情報XMLを読み、拠点の都道府県が閾値以上かどうかを判定するところまでを実際のコードで示します。

### 気象庁の高頻度フィードを定期取得して最大震度を読み取る実装手順

気象庁は電文をAtom形式のフィードで配信しており、地震・火山の高頻度フィードは[eqvol.xml](https://www.data.jma.go.jp/developer/xml/feed/eqvol.xml)から誰でも取得できます。電文の要素構成は[気象庁防災情報XMLフォーマット](https://xml.kishou.go.jp/)の技術資料に定義されており、震源・震度に関する情報（VXSE53）であれば、Intensity要素の下に全国のMaxIntと都道府県ごとのMaxIntが並びます。

次のコードは、フィードから地震情報の電文を拾い、拠点のある都道府県の震度が閾値以上なら配信対象と判定します。標準ライブラリだけで動くため、そのまま保存して実行できます。

```
import urllib.request
import xml.etree.ElementTree as ET

FEED = "https://www.data.jma.go.jp/developer/xml/feed/eqvol.xml"
ATOM = "{http://www.w3.org/2005/Atom}"
SEIS = "{http://xml.kishou.go.jp/jmaxml1/body/seismology1/}"
RANK = ["1", "2", "3", "4", "5-", "5+", "6-", "6+", "7"]
THRESHOLD = "5-"                        # 震度5弱以上で安否確認を配信する
BASES = ["東京都", "神奈川県", "茨城県"]  # 拠点のある都道府県
UA = "anpi-watcher/1.0 (contact: bcp@example.co.jp)"


def fetch(url):
    req = urllib.request.Request(url, headers={"User-Agent": UA})
    with urllib.request.urlopen(req, timeout=20) as res:
        return res.read()


def quake_reports(feed_xml):
    """フィードから地震情報の電文URLを新しい順に返す"""
    root = ET.fromstring(feed_xml)
    urls = []
    for entry in root.findall(ATOM + "entry"):
        title = entry.findtext(ATOM + "title") or ""
        if "震度" in title:
            urls.append(entry.find(ATOM + "link").get("href"))
    return urls


def pref_intensity(report_xml):
    """電文から全国の最大震度と都道府県ごとの震度を取り出す"""
    root = ET.fromstring(report_xml)
    obs = root.find(".//" + SEIS + "Intensity/" + SEIS + "Observation")
    if obs is None:
        return None, {}
    by_pref = {}
    for pref in obs.findall(SEIS + "Pref"):
        by_pref[pref.findtext(SEIS + "Name")] = pref.findtext(SEIS + "MaxInt")
    return obs.findtext(SEIS + "MaxInt"), by_pref


def should_dispatch(by_pref):
    """拠点のある都道府県が閾値以上なら配信すると判定する"""
    limit = RANK.index(THRESHOLD)
    for name in BASES:
        value = by_pref.get(name)
        if value in RANK and RANK.index(value) >= limit:
            return True, name, value
    return False, None, None


for url in quake_reports(fetch(FEED))[:1]:
    overall, by_pref = pref_intensity(fetch(url))
    print("電文:", url)
    print("全国の最大震度:", overall, "/ 拠点別:", by_pref)
    print("配信判定:", should_dispatch(by_pref))
```

2026年9月7日に実行した際の出力は、全国の最大震度1・拠点別は茨城県の震度1で、配信判定はFalseでした。閾値を「4」に下げれば同じ電文で判定が反転するため、社内の配信基準を決める前に過去の電文で素振りしておくと、条件設定の妥当性を数字で確認できます。なお気象庁の電文は利用規約の範囲で使う前提であり、常時取得する場合は取得間隔と識別可能なUser-Agentの設定が求められます。

### 自動配信の判定ロジックを自前で持つ場合に生じる運用上の負担と限界

上のコードが30行程度で書けるからといって、安否確認システムを自作する根拠にはなりません。判定は処理全体のごく一部だからです。実際に必要になるのは、フィードの取得失敗時のリトライ、同一地震の続報（Serial要素）による二重配信の抑止、深夜でも止まらない実行基盤、そして発災直後のアクセス集中に耐える回答受付側の設計です。

特に負荷の山が生じるのは、配信ではなく回答の受付側です。従業員1,000名へ同時配信すれば、数分のうちに数百件の回答が同じ画面へ集中します。平常時のアクセス数で設計したサーバーでは、必要な瞬間に応答が返らない事態が起こり得ます。専業ベンダーがデータセンターの分散と負荷試験に投資しているのは、この一点のためです。判定ロジックの実装可否ではなく、災害時に落ちない基盤を維持し続けられるかで判断してください。

## BCP対策と安全配慮義務からみた安否確認システム導入の必要性

安否確認は「あると安心」の福利厚生ではなく、法的義務と事業継続の両面から必要性を説明できる投資です。稟議を通す立場の方は、この章の論拠をそのまま社内説明に使えます。

### 労働契約法第5条の安全配慮義務と初動対応で企業に問われる責任

労働契約法第5条は、使用者に対して労働者の生命・身体の安全を確保する配慮義務を定めています（条文は[e-Gov法令検索の労働契約法](https://laws.e-gov.go.jp/law/419AC0000000128)で確認できます）。災害時に従業員の状況を把握する手段を用意していなかった場合、この安全配慮義務を尽くしたかが問われる余地が生まれます。出社可否の確認を経ずに出勤を求め、二次被害が生じた場合の企業リスクは小さくありません。

切迫度を示す数字も公表されています。地震調査研究推進本部の[南海トラフの地震に関する評価ページ](https://www.jishin.go.jp/regional%5Fseismicity/rs%5Fkaiko/k%5Fnankai/)では、今後30年以内の発生確率がすべり量依存BPTモデルで60%〜90%程度以上、BPTモデルで20%〜50%と示されています（2026年9月時点の掲載値）。同ページは防災対策では高い側の値を念頭に行動するよう補足しており、この水準を前提にすると「連絡手段を整えていなかった」という説明は通りにくくなります。

### BCP発動の起点となる安否確認と事業復旧までの位置づけの整理

BCP（事業継続計画）の初動フェーズは、安否確認の結果が出ないと次へ進めません。出社できる人員が何名いるかが分からなければ、どの業務を縮小し、どの拠点へ要員を回すかの判断材料がそろわないためです。安否確認システムは、BCP全体から見ると「発動判断に必要な情報を最速で集める装置」に当たります。

BCPそのものの策定手順や運用体制は、[BCP対策の意味・目的と策定手順](/column/details/10933/)で詳しく解説しています。復旧の目標時間であるRTOや目標復旧レベルの決め方は[BCPとRTO・RLOの考え方](https://www.issoh.co.jp/column/details/10933/)にまとめました。安否確認だけを単独で導入するより、BCP文書の初動フローに位置づけて運用ルールまで決めるほうが、投資の説明も定着もしやすくなります。

拠り所にする文書としては、内閣府の[事業継続ガイドライン](https://www.bousai.go.jp/kyoiku/kigyou/keizoku/sk.html)が基本形です。省庁別のガイドラインとの使い分けは[BCP策定ガイドラインの選び方](https://www.issoh.co.jp/column/details/10951/)で整理しました。あわせて中小企業庁の[事業継続力強化計画](https://www.chusho.meti.go.jp/keiei/antei/bousai/keizokuryoku.html)の認定制度でも、緊急時の従業員の安否確認手段は計画へ盛り込む基本項目の1つに挙げられており、認定を取ると税制措置や補助金の加点の対象になります。

## 安否確認サービスの類型別特徴と従業員規模別の費用相場の考え方

市場のサービスは出自によって3つの類型に分かれ、強みが異なります。類型を先に決めてから個別製品を比較すると、候補選びの迷いが減ります。

### 専業ベンダー型・警備会社型・グループウェア連携型それぞれの特徴

安否確認サービスは、安否確認を専業とするベンダーの製品、警備・防災会社が提供する製品、グループウェアの拡張機能として提供される製品に大別できます。

| 類型         | 出自          | 強み         | 確認すべき点     |
| ---------- | ----------- | ---------- | ---------- |
| 専業ベンダー型    | 安否確認専用のSaaS | 機能の厚みと訓練支援 | 名簿連携の対応範囲  |
| 警備会社・防災系   | 警備・防災サービス   | 防災体制と一体で運用 | 単体費用は高めの傾向 |
| グループウェア連携型 | 社内ポータルの拡張   | 既存IDで早期に開始 | 配信手段の多重化   |

機能の網羅性を求めるなら専業ベンダー型、備蓄や警備と合わせて防災体制ごと整えたいなら警備会社型、まず小さく始めたいならグループウェア連携型が向きます。自社の運用体制に近い類型から候補を2〜3件に絞り込むと、比較の工数を抑えられます。絞り込んだあとの進め方は[安否確認システムの比較で使う選定軸の重み付けと料金の総額試算](https://www.issoh.co.jp/column/details/15761/)にまとめました。

### 従業員数に応じた課金と月額固定が混在する料金体系と費用の目安

料金体系は「登録ユーザー数に応じた月額課金」が主流で、一部に人数帯ごとの固定料金プランがあります。公開料金を掲示している主要サービスを概観すると、2026年9月時点では従業員50名前後の規模で月額数千円台から、1,000名規模で月額数万円台が目安です。初期費用は無料から数十万円まで幅があり、名簿連携や設定支援を含むかどうかで変わります。

見積もり時は月額だけでなく、対象人数の数え方に注意が必要です。パート・アルバイトや協力会社の要員を含めると、課金対象が想定の1.5倍になる例もあります。家族の安否確認をオプション扱いにするサービスもあるため、確認範囲を先に決めてから見積もりを取ると差異が出ません。

### LINEや通話アプリなど無料の代替手段で運用した場合に残る限界

「LINEのグループで十分ではないか」という検討は必ず出ます。実際、数名〜十数名の組織であれば、既読確認と通話で成立する場面が多いのも事実です。

限界は3つあります。第一に、発災を検知して自動で配信が始まらないため、担当者自身が被災すると初動が止まる点です。第二に、既読は付いても「無事かどうか」の構造化された回答が集まらず、人数が増えると集計が破綻していきます。第三に、私用アカウント頼みの名簿は退職・異動で更新されず、いざという時に届かない宛先が残る状態です。従業員数が50名を超えたあたりから、無料手段の運用コストは専用システムの費用を上回っていきます。

### 災害用伝言ダイヤルなど公共の安否確認手段と企業向けの守備範囲の違い

無料の手段としてもう1つ挙がるのが、通信事業者や公共機関が提供する安否確認の仕組みです。代表例が[災害用伝言ダイヤル（171）](https://www.ntt-east.co.jp/saigai/voice171/)で、被災地の電話番号をキーに音声メッセージを預け、家族などが後から再生できます。体験利用日が毎月1日・15日などに設けられており、社内の防災訓練で試すこともできます。

ただし、これらは「個人が自分の状況を登録し、探す側が番号で照会する」設計です。企業側から全従業員へ質問を投げ、回答を部署別に集計するという用途は想定されていません。誰が未回答かを機械的に洗い出せない点が決定的な差です。公共の手段は家族との連絡確保の手段として社内へ周知し、企業としての安否集計は専用システムで行う、という二本立てにすると役割が重なりません。

## 災害時に確実に機能する安否確認システムを見極める選定基準7項目

選定基準は、配信の確実性に関わる2項目、回答率に関わる2項目、運用定着に関わる3項目の計7項目に整理できます。優先度の高い順に説明します。

### 配信手段の多重化とデータセンターの耐障害性で確認すべき具体的水準

第1の基準は配信手段の数です。メール1本のサービスでは、キャリアの迷惑メールフィルタや遅延で届かない場面を吸収できません。専用アプリのプッシュ通知・メール・SMSの3経路以上を備え、1経路が不通でも別経路で届く構成を条件にしてください。

第2の基準は提供側の基盤です。安否確認サービス自身が被災して停止しては意味がないため、データセンターの地理的な分散配置や、大規模災害時のアクセス集中に耐えた実績を確認します。過去の震度6弱以上の地震で配信遅延が生じなかったかを問い合わせると、各社の回答に差が出ます。

### 未回答者への自動再送や家族の安否確認など回答率を左右する機能

第3の基準は未回答者への自動再送です。初回配信への回答率は訓練でも6〜8割にとどまることが多く、残りをどう回収するかで集計完了までの時間が変わります。30分〜1時間間隔で自動再送し、未回答者だけを管理者へ一覧表示する機能があれば、電話での個別追跡を最小限にできます。

第4の基準は家族の安否確認です。従業員本人が無事でも、家族の安否が分からない状態では出社の判断ができません。家族用の回答ページを人数無制限で提供するサービスと、家族分をオプション課金とするサービスの2通りです。通勤中や外出先でも回答できる手段を増やすほど、初動の集計は速くなります。スマートフォンアプリで回答する方式については、[アプリ型の通知到達率と回答率を高める要件と選定基準](https://www.issoh.co.jp/column/details/15763/)で通知設計と配布の条件を整理しています。

### 操作性・訓練機能・多言語対応の3点で導入後に生まれる運用の差

第5の基準は従業員側の操作性です。回答までのタップ数が多い、ログインIDを忘れると回答できない、といった製品は本番の回答率が伸びません。ID・パスワードの入力なしで回答できる方式かどうかは、試用で確かめる価値があります。

第6の基準は訓練の自動化です。訓練配信の日時指定・自動実施・結果レポートまで揃っていれば、担当者の手間なく定期訓練を回せます。第7の基準は多言語対応で、外国籍の従業員が在籍する場合は配信文と回答画面の両方が対象言語に対応しているかの確認が必要です。7項目のうち、配信手段の多重化と自動再送の2つだけは妥協しない、という優先順位で選ぶと失敗が減ります。

## SaaS導入で足りる企業と自社開発・システム連携を検討すべき場面の判断基準

受託開発会社の立場からの結論を先に述べると、安否確認システムをゼロから自社開発すべき企業はごく少数です。判断の分かれ目は開発の要否ではなく、既存システムとの連携をどこまで設計するかにあります。

### 従業員500名未満の単一拠点企業でSaaS標準機能が足りる理由

単一拠点で組織変更が年1回程度の企業なら、専業ベンダーのSaaSを標準機能のまま導入すれば足ります。名簿の更新が少なく、拠点別集計のような機能を使い込む場面も限られるためです。この規模で作り込みに費用をかけるのは過剰であり、当社でも受託開発は推奨しません。月額数千円〜数万円のSaaS費用に対し、開発では初期に数百万円規模の投資が発生し、回収の説明が立たないためです。

この場合の判断は速さを優先します。2〜3サービスの無料試用で配信テストまで行い、1〜2か月で本契約に進む段取りが現実的です。

### 人事・勤怠システムとの従業員マスタ連携が必要になる具体的な場面

複数拠点で異動・入退社が月単位で発生する企業は、名簿の鮮度が最大の課題になります。安否確認システムの名簿を手動更新に頼ると、発災時に「登録が古く新入社員に届かない」という事故が起こります。人事システムや勤怠管理システムを従業員マスタの起点にして、安否確認システムへ自動同期する連携設計が解決策です。[勤怠管理システムの機能と選び方](https://www.issoh.co.jp/column/details/15081/)で解説している通り、勤怠側には最新の在籍・所属データが日次で集まるため、同期元として適しています。人事情報そのものの持ち方は[人事システムの機能・種類と自社開発の判断軸](https://www.issoh.co.jp/column/details/13557/)で扱っています。

連携方式はAPI連携が第一候補で、対応していない場合はCSVの自動連携で代替します。ここは大規模な開発ではなく、設定と小規模な連携構築の範囲であり、SaaS利用を前提にしたまま実現できます。

### 名簿をCSVで自動同期する場合に決めておく項目設計と更新の頻度

CSV連携を選ぶ場合、最初に決めるのは項目とキーです。従業員番号を不変のキーに据え、氏名・所属コード・拠点・役職・連絡先（会社メール、私用メール、携帯番号）・在籍区分を並べる構成が扱いやすい形になります。氏名をキーにすると、同姓同名や改姓で名寄せが崩れます。

次に決めるのは差分の扱いです。全件洗い替えは実装が単純な半面、連携が1回失敗した日の名簿が空になる危険を抱えます。在籍区分の列を持たせて退職者を「無効」で送り、受け側で配信対象から外す方式のほうが事故に強い作りです。更新頻度は日次で足ります。異動が集中する4月と10月の前後だけ手動実行を足し、連携ログの件数を担当者が目視する運用にすると、名簿の欠落に気づけます。

### 自社開発を見送るべき場面と受託開発会社へ相談する価値がある場面

安否確認の配信・集計そのものを自社開発するのは、ほぼ全ての企業で見送るべきです。災害時のアクセス集中に耐えるインフラを自前で維持する費用が、SaaSの利用料を大きく上回るためです。

相談する価値があるのは、安否確認を含む緊急時の情報基盤全体を設計したい場合です。基幹システムの従業員データを起点に、安否確認・拠点の被災状況・復旧タスクを1つのダッシュボードで見たい、協力会社や店舗網まで確認範囲を広げたい、といった要件はパッケージの守備範囲を超えます。この領域は[基幹システム開発](https://www.issoh.co.jp/service/business%5Fsystem/core%5Fbusiness/)の一部として、既存の業務データと連携させながら構築する対象になります。SaaSで足りる範囲はSaaSに任せ、連携と可視化だけを開発する切り分けが、費用対効果の面で成立しやすい構成です。

## 導入から運用定着までの手順と回答率を高める訓練の実務ポイント

導入の作業自体は難しくありません。つまずくのは名簿の整備と、導入後に訓練が続かない運用面です。手順と定着策を分けて押さえます。

### 要件整理から全社展開まで標準的な導入スケジュールと体制づくり

標準的な導入は次の5段階で、全体で2〜3か月を見込みます。

1. 確認範囲の決定（従業員のみか、家族・協力会社まで含めるか）
2. 類型の選択と2〜3サービスの試用・配信テスト
3. 従業員データの登録と私用連絡先の取得同意
4. 管理者・代行者の複数名体制の決定と初動ルールの文書化
5. 全社説明会と初回の訓練配信

体制面では、管理者を1名にしない点が肝心です。配信条件の変更や手動配信の権限を持つ担当を本社と別拠点に最低2名置き、担当者自身の被災に備えます。あわせて、システムが使えない場合に何をするかの代替手順も1枚にまとめておきます。

### 私用の連絡先を登録するときの取得同意と削除ルールの実務での決め方

私用のメールアドレスや携帯番号は個人情報に当たるため、収集の前に利用目的を特定して本人へ通知または公表する必要があります。判断の拠り所は個人情報保護委員会の[個人情報の保護に関する法律についてのガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)です。「災害・事故発生時の安否確認および緊急連絡」と目的を書き切り、就業規則や社内規程へ位置づけたうえで登録を依頼すると、現場の抵抗が小さくなります。

登録は任意にしつつ、未登録者には会社貸与端末への通知経路を必ず1本用意してください。全員が私用連絡先を出すとは限らないためです。もう1つ決めておくのが削除の運用で、退職後も私用連絡先が残り続ける状態は保有の必要性を説明できません。退職手続きのチェックリストへ安否確認システムからの削除を1行加えると、名簿の鮮度と個人情報の適正な保有を同時に保てます。

### 年2回の訓練配信と初動回答率90%を目標にした運用改善の進め方

訓練は年2回、防災週間のある9月と、組織変更直後の4月に設定すると、名簿の陳腐化を同時に点検できます。1回目の訓練で回答率が7割を下回ることは珍しくありません。回答率の低かった部署を特定し、未登録・宛先エラーの従業員を洗い出して更新する、という改善を2〜3回繰り返すと、24時間以内の回答率90%が現実的な水準になります。

訓練結果は経営層へ報告し、BCP全体の見直しと連動させます。回答率という数字が出るため、防災投資の中では効果を示しやすい施策です。数字が頭打ちになったら、配信経路の追加や家族安否の対象拡大など、システム側の設定を見直す段階に入ります。

## よくある質問

安否確認システムの検討時に問い合わせの多い質問へ、簡潔に回答します。

### 安否確認システムの費用はどのくらいかかりますか？

登録人数に応じた月額課金が主流で、公開料金のあるサービスを概観すると、従業員50名規模で月額数千円台から、1,000名規模で月額数万円台が目安です（2026年9月時点）。初期費用は無料のサービスも多い一方、家族安否や名簿連携をオプション課金とする場合があります。確認範囲を決めてから見積もりを比較してください。

### 無料で使える安否確認の手段はありますか？

LINEなどのメッセージアプリや通話で代替する方法があり、十数名までの組織なら成立します。ただし自動配信が働かないため担当者が被災すると初動が止まり、回答の集計も人力になります。災害用伝言ダイヤル（171）のような公共サービスは個人の安否登録が目的で、企業側からの一斉確認・自動集計はできません。50名を超える組織には専用システムを推奨します。

### アプリとメールのどちらで配信すべきですか？

どちらか一方ではなく併用が原則です。アプリのプッシュ通知は到達が速い一方、未インストールの従業員には届きません。メールは全員に配れる半面、迷惑メールフィルタや遅延の影響を受けます。SMSも含めた3経路以上を備えたサービスを選び、従業員ごとに届く経路を複数登録しておくと、1経路の障害を吸収できます。

### 訓練はどのくらいの頻度で実施すべきですか？

年2回を推奨します。年1回では組織変更による名簿のずれを拾えず、四半期ごとでは現場の負担感から回答率が下がる傾向があるためです。9月の防災週間と4月の年度初めに固定すると、実施忘れを防げます。訓練のたびに部署別回答率と宛先エラーを点検し、名簿更新とセットで運用してください。

### 従業員の家族の安否まで確認できますか？

多くのサービスが家族向けの回答手段を提供しており、標準機能に含む場合とオプション課金の場合があります。従業員本人の無事だけでは出社可否を判断できないため、初動要員に指定している部署だけでも家族安否を対象に含める設計を推奨します。家族の人数制限や登録方法はサービスごとに異なるため、試用時に確認が必要な項目です。

### 配信の条件は震度いくつに設定するのが妥当ですか？

拠点のある都道府県で震度5弱以上を初期値にし、訓練と実際の地震の結果を見て調整する進め方が現実的です。震度4で配信すると年に何度も動いて回答率が落ち、6弱まで上げると出社可否の判断が必要な規模の揺れを取りこぼします。台風や大雨の警報を条件に加えるかは別に決め、地震とは配信文面を分けてください。

### 人事システムと連携せず手動で名簿を更新しても問題ありませんか？

従業員数が100名未満で異動が年1回程度なら、手動更新でも運用できます。月単位で入退社が発生する規模になると、更新漏れが宛先エラーとして表面化します。判断の目安は、直近1年の入退社と異動の合計件数です。年間で全従業員の1割を超えるなら、CSVまたはAPIによる自動同期の検討に入ってください。

## 関連記事

- [グループウェアとは？主な機能とクラウド型・オンプレ型の違い、選び方を解説](https://www.issoh.co.jp/column/details/13295/)：安否確認の連携型サービスが拡張機能として載る、社内情報基盤の選び方を解説しています。
- [ビジネスチャットとは？主な機能とメール・グループウェアとの違い、選び方を解説](https://www.issoh.co.jp/column/details/13545/)：平時の連絡手段の整備は、緊急時の情報の到達しやすさにも直結します。
- [人事システムとは？機能・種類・選び方と自社開発の判断軸を開発会社が解説](https://www.issoh.co.jp/column/details/13557/)：安否確認の名簿連携の起点になる、従業員マスタの整え方を扱っています。

---

出典: [安否確認システムとは？仕組み・費用相場と自社に合う選び方を開発会社が解説](<https://www.issoh.co.jp/column/details/15302/>)（株式会社一創）