災害情報をシステムへ取り込むには｜外部データ連携の基本設計
安否確認システムを自動発令させるためには、地震や気象などの災害情報を外部から取得し、システム内部で利用できる状態にする必要があります。
しかし、外部から取得したデータをそのまま発令処理へ渡せばよいわけではありません。
外部データと安否確認システムの内部処理を分けて考え、取得した情報をシステムで扱いやすい形に整理することが重要になります。
災害情報を外部から取得する
自動発令を行う安否確認システムでは、まず災害情報を外部から取得します。
取得する情報には、地震や気象などの災害種別だけでなく、発生日時、対象地域、規模など、発令判定に必要となる情報が含まれます。
ここで重要なのは、「外部から情報を取得する処理」と「安否確認を発令する処理」を同じものとして扱わないことです。
災害情報を受け取った段階では、まだ安否確認を発令するかどうかは決まりません。
まず取得した情報を整理し、その後の判定処理へ渡す構成にしておくことで、それぞれの役割が明確になります。
取得したデータをそのまま使わない
外部から提供される災害情報は、その情報提供元の仕様に従った形式になっています。
一方、安否確認システムでは、発令判定や対象者の抽出など、システム独自の処理を行います。
この二つを直接結びつけてしまうと、外部データの形式が変わった場合、その影響が発令処理などの内部ロジックまで及ぶ可能性があります。
そこで、取得した災害情報を一度システム内部の形式へ変換します。
外部データを受け取る部分と、内部で利用する部分の間に整理する処理を置くことで、外部仕様と内部処理を分離できます。
システム内部で必要な情報を整理する
内部データとして扱う際には、後続処理で必要になる情報を整理して保持します。
例えば、
- 発生日時
- 災害種別
- 対象地域
- 災害の規模
- 災害イベントを識別する情報
といった項目です。
こうした情報を共通した形で扱えるようにしておけば、その後の発令判定では、外部データそのものを意識する必要がありません。
発令判定側は、整理された内部データだけを見て処理できます。
災害を識別する情報を持つ
災害情報を扱う際には、それぞれの情報がどの災害に関するものなのかを識別できることも重要です。
同じ災害について、外部から複数回情報を受け取ることがあります。
そのたびに新しい災害として扱ってしまうと、同じ災害に対して安否確認を複数回発令する原因になります。
そのため、災害イベントを識別する情報を保持し、すでに処理した災害なのか、それとも新しい災害なのかを判断できるようにしておきます。
これは重複発令を防ぐための重要な準備になります。
外部仕様の変更を内部へ広げない
外部の情報提供元と連携するシステムでは、将来的な仕様変更も考えておく必要があります。
外部データの項目名や形式と、安否確認システム内部の処理を直接結びつけていると、外部仕様が変更された際に多くの処理を修正する必要が出てきます。
一方、外部データを内部形式へ変換する部分を分けておけば、変更の影響をその部分に限定しやすくなります。
安否確認の発令判定や通知処理まで変更する必要がない構成にしておくことが、システムを維持しやすくするうえで重要です。
まとめ
災害情報を安否確認システムで利用するためには、外部から取得した情報をそのまま使うのではなく、システム内部で扱いやすい形に整理することが重要です。
災害の種類、発生日時、対象地域、警報レベルなどを共通した形式で管理することで、その後の発令判定や対象者への通知につなげやすくなります。
jkabu安否では、気象庁の防災情報を取得し、あらかじめ定めた条件に基づいて安否確認を自動発令する仕組みを採用しています。
jkabu安否の詳しい機能については、以下をご覧ください。
