LASSIC Media らしくメディア

2026.07.13 らしくコラム

安否確認システムの開発を外注で進める

LASSIC IT事業部|元請(プライムベンダー)としてシステム開発を一括受託

防災のイメージ

この記事のポイント

  • 安否確認システムは、内閣府の事業継続ガイドラインが初動対応の一つに位置づける仕組みで、緊急地震速報との連動や多チャネル配信、集計・再送といった機能で構成されます。
  • 気象庁の緊急地震速報は観測点数や予想震度など公表された条件に基づいて発表され、システム側はこの情報を受けて自動配信を行う設計が一般的です。
  • 既製サービスとスクラッチ開発では対応できる範囲が異なり、対象拠点数や既存システムとの連携要件によって外注の進め方も変わってきます。

安否確認システムとは何か——BCPにおける初動対応の役割

緊急連絡のイメージ

安否確認システムとは、地震や風水害、大規模障害などが発生した際に、企業が従業員(場合によってはその家族)の状況を迅速に把握するための情報システムを指します。内閣府の事業継続ガイドラインでは、事業継続計画(BCP)の実施・運用段階における対応の一つとして「迅速な安否確認」を挙げ、従業員の状況把握を独立した項目として整理しています*1。事業を止めない判断をする前提として、まず人の状況を確認する取り組みだと位置づけられているわけです。

図
図:安否確認システムの一般的な動作フロー(検知→自動配信→回答受付→再送→集計・共有)

同ガイドラインが示す枠組みでは、被害状況の把握や事業継続の判断に先立って、まず人の状況を確認する初動対応が求められます*1。中小企業庁の中小企業BCP策定運用指針でも、安否確認の方法として緊急連絡網の整備や複数の連絡手段の確保が具体的に示されており、災害だけでなく大規模障害や感染症などの有事にも共通する初動対応として扱われています*3。安否確認システムは、この初動対応を人手ではなく仕組みとして回すためのツールだと整理できます。

対象は従業員本人にとどまりません。企業によっては、従業員の家族の状況もあわせて確認できる機能を備えたシステムを選ぶこともあるでしょう。取引先や協力会社を含めた関係者まで対象を広げるケースもあり、BCPで想定する範囲に応じてシステムに求める機能も変わってきます。

導入で押さえておきたい6つの機能——自動配信から拠点別集計まで

安否確認システムと一口にいっても、製品によって備える機能の幅には差があります。導入検討時に確認しておきたい主な機能を整理すると、次の6つに集約できます。

機能 概要
自動配信トリガー 気象庁の緊急地震速報など外部の観測情報と連動し、条件を満たした際に手動操作なしで配信を開始する仕組み*4*5
多チャネル配信 メール、SMS、専用アプリのプッシュ通知、LINEなど複数の経路へ同時に配信し、いずれかの経路で従業員に届く可能性を高める設計
回答集計 従業員からの回答をリアルタイムに集計し、管理画面上で状況を一覧できるようにする機能
未回答者への再送 一定時間が経過しても回答がない従業員に対し、別の経路も使いながら自動で再送する仕組み
家族安否の登録 従業員本人だけでなく、あらかじめ登録した家族の状況も確認できるようにする機能
拠点・部門別集計と掲示板 回答結果を拠点や部門ごとに集計してBCP対策本部へ共有し、あわせて全社への指示事項を掲示・伝達する機能

これらの機能をすべて備えた製品もあれば、一部の機能に絞ったシンプルな製品もあります。自社が想定する災害シナリオや対象人数、既存の人事システムとの連携要否によって、どこまでの機能を求めるかは変わってきます。

気象庁の緊急地震速報と連動する自動配信の仕組み

安否確認システムの自動配信トリガーとして広く使われているのが、気象庁の緊急地震速報です。緊急地震速報は、震源に近い地震計がP波を検知した段階でデータを解析し、遅れて到達するS波が来る前に情報を配信する仕組みで、震源推定法とPLUM法という2つの手法を使い分けています*4

緊急地震速報には警報と予報の2種類があり、発表条件が公表されています。警報は、2点以上の地震観測点で地震波が検知され、予想される震度が5弱以上、または予想される長周期地震動階級が3以上となった場合に発表されます*5。予報は、マグニチュード3.5以上、または予想される震度が3以上といった条件のもとで発表され、地震発生から数秒から1分程度の間に複数回発表される点が特徴です*5

安否確認システムの多くは、この警報を配信元のAPIから受け取り、震度の基準に応じて対象拠点への自動配信を開始する設計になっています。震源に近い場所では原理上、揺れの到達に速報が間に合わない場合がある点にも留意が必要です*4。このため自動配信は初動を早める仕組みとして位置づけつつ、手動での配信操作もあわせて用意しておく設計が実務的だといえるでしょう。

平時の訓練と可用性設計——災害時に機能させるための備え

安否確認システムは、平時に整えておく運用と、発生時に負荷が集中する状況の両方を見据えて設計する必要があります。内閣府の事業継続ガイドラインでは、緊急連絡先を複数確保し緊急連絡網を整備すること、電話回線が混み合う状況でも利用できる災害用の伝言サービスをあわせて活用することなどが、家族を含めた安否確認の具体策として示されています*2

中小企業庁の中小企業BCP策定運用指針でも、安否確認の方法として複数の連絡手段を組み合わせておく考え方が整理されています*3。あわせて重要になるのが、平時からの訓練です。年に一度の防災訓練にあわせて安否確認システムの配信・回答テストを組み込んでおくと、実際の発生時に操作方法で戸惑う従業員を減らせます。連絡先の登録漏れや退職者情報の残存など、名簿の更新不足も訓練を通じて見つかりやすくなります。

可用性の面では、災害発生時にアクセスが特定の時間帯へ集中する特性への備えが求められます。配信基盤をクラウド上の分散構成にしておく、平常時とは桁違いのアクセス増を想定した負荷試験をあらかじめ実施しておく、といった設計上の工夫が、災害時に機能する仕組みづくりにつながります。

既製サービスとスクラッチ開発——安否確認システムの選び方

事業継続のイメージ

安否確認システムを導入する方法は、大きく分けて既製のクラウドサービスを契約する方法と、自社向けにスクラッチで開発する方法の2つがあります。既製サービスは導入までの期間が短く、他社での運用実績を踏まえた機能がすでに用意されている点がメリットです。多くの企業がまず検討するのはこの選択肢でしょう。

一方でスクラッチ開発が向くのは、既存の人事データベースや勤怠システムと密接に連携させたい場合、拠点数や組織構造が独自で既製サービスのテンプレートに収まりにくい場合、グループ会社を横断した権限設計が必要な場合などです。SMS配信網や気象庁の情報配信との連携部分は、既製サービスのAPIを活用しつつ、社内システムとの接続部分だけを個別に開発するハイブリッドな進め方を選ぶ企業もあります。

どちらを選ぶにしても、対象人数の増減にどこまで柔軟に対応できるか、拠点や子会社を追加する際の設定変更が容易かどうかは、事前に確認しておきたいポイントです。

導入の進め方——要件整理から運用定着までの流れ

安否確認システムの導入は、要件整理から運用定着まで段階を追って進めるのが実務的です。最初のステップは、対象範囲(従業員のみか家族まで含めるか)や、想定する災害シナリオ、連携させたい既存システムの洗い出しです。

次に対象者名簿を整備します。氏名や連絡先だけでなく、所属拠点や緊急連絡先の情報も含めて最新の状態に保つ運用ルールを決めておくと、配信対象の抜け漏れを防ぎやすくなるはずです。続いてベンダー選定または開発方式の決定を行い、自動配信のトリガー条件や配信ルール、拠点別の集計方法といった細部の設定に進みます。

設定が固まった段階で、実際に配信・回答・集計までの一連の流れを試す訓練を実施します。訓練で見つかった課題を反映したうえで本番運用に移行し、名簿更新や配信ルールの見直しを定期的に行う体制を整えることが、長く機能させるための土台になります。

内製と外注の分かれ目——安否確認システム開発を任せる判断軸

安否確認システムを自社開発するか外部に委託するかは、求める機能の幅と社内の開発体制によって分かれます。既製サービスの利用にとどまるなら初期設定は自社担当者でも進められますが、SMS配信基盤との接続や気象庁データの受信部分、人事システムとの連携まで踏み込むと、複数領域の実装知識が必要になります。

外部パートナーへ委託する場合は、要件整理から配信基盤の設計、既存システムとの連携開発、訓練の実施支援、導入後の運用保守までを一括して依頼できるかどうかが選定の分かれ目になります。特に配信の到達状況を可視化するダッシュボードや、拠点別集計の自動化といった部分は、開発規模が膨らみやすい領域です。委託先が過去にどのような規模・業種で類似システムを手がけてきたかを確認しておくと、見積もりの精度も上がりやすくなります。

。対象人数や拠点数、既存システムとの連携要件によって必要な工数は変わってきます。現状の要件を整理したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ:安否確認システム導入で押さえる3つの判断軸

本稿では安否確認システムの機能と導入の考え方を、公的機関の情報をもとに整理しました。要点は3つに集約できます。第一に、安否確認システムはBCPにおける初動対応の一つとして位置づけられ、緊急地震速報との連動や多チャネル配信、集計・再送といった機能で構成されます*1*4。第二に、平時の訓練と可用性設計を組み合わせることで、発生時に機能する仕組みに近づけられます*2*3。第三に、既製サービスとスクラッチ開発のどちらを選ぶか、内製と外注のどちらに委ねるかは、対象人数や拠点数、既存システムとの連携要件によって判断が分かれます。

LASSICに相談するメリット

LASSIC IT事業部は、システム開発の元請(プライムベンダー)として要件整理から設計・開発、導入後の運用保守までを一括で受託しています。安否確認システムについても、既存の人事システムとの連携や拠点別集計の自動化、配信基盤の可用性設計まで含めた対応が可能です。既製サービスとスクラッチ開発のどちらが自社に合うか判断に迷う企業様は、現状の要件整理からご相談いただけます。

よくある質問

安否確認システムはBCPのどの段階で使うものですか。

内閣府の事業継続ガイドラインでは、事業継続計画の実施・運用段階における対応の一つとして「迅速な安否確認」を挙げています*1。被害状況の把握や事業継続の判断に先立ち、まず人の状況を確認する初動対応の場面で使うシステムだと整理できます。

緊急地震速報と連動させる場合、何を基準に自動配信されますか。

気象庁の緊急地震速報のうち警報は、2点以上の地震観測点で地震波が検知され、予想震度が5弱以上、または予想される長周期地震動階級が3以上となった場合に発表されます*5。多くの安否確認システムは、この警報をAPI経由で受け取り、対象拠点への自動配信を開始する設計になっています。

従業員の家族の安否確認にも対応できますか。

対応できる製品があります。内閣府の事業継続ガイドラインでも、緊急連絡先を複数確保し、電話回線が混み合う状況でも利用できる伝言サービスをあわせて活用するなど、家族を含めた確認の具体策が示されています*2。あらかじめ家族の連絡先を登録できる機能を備えたシステムを選ぶ企業もあります。

既製サービスとスクラッチ開発はどちらを選ぶべきですか。

導入までの期間やコストを優先するなら既製サービスが選ばれやすい傾向にあります。既存の人事データベースとの密な連携や、独自の拠点・組織構造への対応が必要な場合はスクラッチ開発、または既製サービスのAPIと自社システムを組み合わせるハイブリッドな方法が検討対象になります。

安否確認システムの開発を外部に委託する場合、何を確認すればよいですか。

要件整理から配信基盤の設計、既存システムとの連携開発、訓練の実施支援、導入後の運用保守までを一括して依頼できるかをまず確認します。あわせて、委託先が過去に手がけた規模・業種を確認しておくと、見積もりの精度をすり合わせやすくなります。

著者:テレリモ総研編集部 鈴木 亮佑


ITアウトソーシング・システム開発のご相談はLASSICへ

元請(プライムベンダー)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。

無料相談はこちら

ご不明な点はお問い合わせフォームからもご連絡いただけます。

  1. *1 出典:内閣府「事業継続 初めての方へ」(防災情報のページ)(https://www.bousai.go.jp/kyoiku/kigyou/keizoku/hajimete.html
  2. *2 出典:内閣府(防災担当)「事業継続ガイドライン-あらゆる危機的事象を乗り越えるための戦略と対応-」(令和5年3月)(https://www.bousai.go.jp/kyoiku/kigyou/pdf/guideline202303.pdf
  3. *3 出典:中小企業庁「中小企業BCP策定運用指針」資料12「安否確認の方法」(https://www.chusho.meti.go.jp/bcp/contents/level_a/bcpgl_08_12.html)※アクセス制限により直接リンク不可のためURL記載のみ
  4. *4 出典:気象庁「緊急地震速報のしくみ」(https://www.jma.go.jp/jma/kishou/know/jishin/eew/shikumi/shikumi.html
  5. *5 出典:気象庁「緊急地震速報(警報)及び(予報)について」(https://www.jma.go.jp/jma/kishou/know/jishin/eew/shikumi/shousai.html


View