災害時の被害報告・安否を集約する仕組みの設計

結論：点呼リストは新しく作らず、既存マスタから毎回生成する

地震や台風のあと、管理物件の被害状況と現場の安否を集約する仕組みの核は、次の2点です。

1. 日常運用している物件マスタ・現場マスタを、そのまま点呼対象リストに転用する（災害用の別リストを作らない）
2. 「報告が集まった件」ではなく「報告がない件」を主画面に出す（報告ゼロを正常ではなく異常として扱う）

災害対応システムが機能しない最大の原因は、システムが落ちることではありません。平時に誰も触らない専用リストを作ってしまい、発災時にそのリストが古いことです。管理を解除した物件、完工した現場、退職した担当者が混ざったリストで点呼を始めると、集計そのものが信用できなくなります。

この記事は、不動産管理会社・建設会社の総務／管理部門で、災害時の情報集約の仕組みをこれから作る方を対象にしています。

点呼対象リストの生成ルールを先に決める

発災時に最初に必要なのは「誰に・何について聞くか」の確定です。これを人手で判断すると数時間溶けます。次のルールをシステム側に持たせて、ボタン一つで対象を絞り込めるようにします。

絞り込みの3軸

ここで実務的に効いてくるのは市区町村コードの保持です。住所が「盛岡市○○1-2-3」という文字列でしか入っていないと、「震度5強を観測した市町村だけ」という絞り込みができません。住所文字列の前方一致で無理やり絞ると、同名の町名や政令市の区で取りこぼします。マスタ設計の段階で、住所とは別に市区町村コード列を持たせておいてください。

リストの鮮度を保つ運用条件

点呼リストを既存マスタから生成する設計は、マスタが正しいことが前提です。次の3つが満たされていないと、この設計は機能しません。

• 管理解除・退去・完工のタイミングで、マスタ側のステータスが必ず更新されている
• 担当者の異動・退職が、マスタの担当者欄に反映されている
• 協力会社の職長の連絡先が、現場マスタに紐づいている（個人の携帯に頼っていない）

逆に言えば、災害対応の仕組み化は日常のマスタ整備そのものです。発災時だけ正しいリストは存在しません。

「未報告」を主画面に置く引き算方式

報告収集の仕組みで最もよくある失敗は、報告が入った順に一覧へ積み上げる足し算方式です。この画面では、100件のうち20件から報告が入ると「20件集まった」ように見えます。しかし本当に知りたいのは、残り80件が無事なのか、報告できない状況なのかです。

設計の骨格

1. 発災時、対象リスト全件を初期状態「未報告」でレコード生成する
2. 報告が1件入るたびに、そのレコードが「未報告」から消える
3. 主画面のデフォルト表示は「未報告のみ」
4. 未報告レコードには経過時間を表示する（発災から何時間連絡が取れていないか）

報告できない状況ほど重大である可能性が高い、というのがこの設計の前提です。停電、通信断、本人の負傷、避難中。いずれも「報告がない」という同じ見え方をします。だからこそ、報告ゼロを正常として扱ってはいけません。

未報告の内訳を分ける

未報告を一括りにすると、対応の優先順位がつきません。少なくとも次の3状態に分けます。

「送信済・未応答」が長時間続く先と、「応答不能」の先では、取るべき行動が違います。前者は本人が手が離せないだけかもしれませんが、後者は通信インフラごと落ちている可能性があります。状態を分けておくと、地域単位で応答不能が固まっているかどうかも見えます。

報告フォームは「30秒で終わる」設計にする

現場の担当者は、余震のなか、片手でスマホを操作します。入力項目が多いフォームは埋まりません。最初の一報は、選択肢のタップだけで完了する構成にします。

一次報告（速報）の項目

• 自分の安否：無事／軽傷／要救助（3択タップ）
• 物件・現場の状態：異常なし／軽微な損傷／重大な損傷／未確認（4択タップ）
• 写真：任意（後追い可）
• 自由記述：任意

ここで重要なのは「未確認」という選択肢を必ず置くことです。これがないと、まだ現地に行けていない担当者は何も報告できません。結果として未報告のまま残り、応答不能と区別がつかなくなります。「本人は無事だが物件は未確認」という状態を報告できることが、集計の解像度を決めます。

二次報告（詳細）は別フォームにする

被害箇所の詳細、応急処置の要否、入居者からの申告内容は、一次報告とは別のフォームに分けます。同じフォームに詰め込むと、詳細が書けない段階では一次報告すら送られません。

段階を分ける基準は「発災直後に判断できるかどうか」です。外観目視で分かることは一次、建物内部に入らないと分からないことは二次、というのが実用的な切り分けです。

選択肢の文言は社内で統一する

「軽微な損傷」の定義が人によって違うと、集計が意味を失います。フォームの選択肢の横に、判断例を短く添えてください。

• 軽微な損傷：外壁のひび、タイルの浮き、共用部の照明破損など、居住・稼働を継続できる状態
• 重大な損傷：傾き、基礎の露出、階段や手すりの破損、水漏れなど、立入や使用の制限が必要な状態

この文言は自社の判断基準です。建物の安全性の最終判断は、応急危険度判定士や構造の専門家が行います。システム上の分類は初動の優先順位付けのためのものであり、安全宣言ではないことを、運用ルールとして明記しておいてください。

写真は「保険請求の証跡」まで見据えて保存する

速報時に撮った写真は、後からオーナー報告書と保険・共済の請求資料に使われます。ここで多いのが、アップロード時に自動圧縮・リサイズしてしまい、撮影日時やGPS情報が落ちるという設計ミスです。

保存設計の原則

被害の写真は、いつ撮ったかの証明が価値の大半を占めます。加工済み画像しか残っていないと、災害との因果関係を示す材料が弱くなります。原本を消さずに保持し、閲覧用は別ファイルとして持つ二層構成にしてください。

なお、保険金・共済金の支払い可否は保険会社・共済の審査によります。写真の要件も約款や商品によって異なるため、契約している保険会社に必要書類を事前確認したうえで、保存仕様を決めることをおすすめします。

撮影のガイドを仕組みに埋め込む

現場任せにすると、被害箇所のアップだけが送られてきて「どの物件のどこか」が分からない写真が溜まります。フォーム上に撮影順のガイドを表示します。

1. 物件全景（建物名の看板が入るように）
2. 被害箇所を含む面の全景（どこの部分かが分かる距離）
3. 被害箇所のアップ
4. 可能なら、被害の大きさが分かるもの（メジャー、養生テープなど）を添える

この4枚構成は、後工程のオーナー報告と保険請求のどちらでも使えます。

集約結果を「次の連絡」に直結させる

被害情報を集めただけでは、業務は終わりません。集約直後に必ず発生するのは、オーナーへの一次報告と、修繕手配です。ここを人力に戻すと、せっかく集めた情報が転記作業に化けます。

オーナー向け一次報告の自動組み立て

物件マスタにはオーナーが紐づいています。報告が入った物件について、次の要素を差し込んだ文面を自動生成します。

• 物件名
• 確認日時
• 現時点の状態区分（異常なし／軽微／重大／未確認）
• 写真（閲覧用の圧縮版）
• 次のアクション（業者手配予定／再訪予定日／現時点で未定）

「現時点で未定」と書けることが重要です。発災直後に確定できる予定はほとんどありません。未定と伝えることも報告です。何も送らないと、オーナーからの電話が集中します。

重大損傷からの手配フロー接続

「重大な損傷」に分類されたレコードは、そのまま修繕手配のフローへ渡します。災害時は協力会社側も被災し、通常の手配先が動けないことが前提になります。手配の仕組みについては、賃貸の修繕手配を仕組み化する設計手順で扱っている、業者の選定と進捗追跡の考え方が土台になります。

また、建設現場側の被害で資材の再手配が必要になる場合は、建設資材の発注・納期管理を仕組み化する設計手順の納期追跡の考え方が使えます。災害時は納期が全面的に崩れるため、平時から納期の遅延を検知できる状態になっているかどうかが分かれ目になります。

発災から24時間の運用手順（設計例）

以下は仕組みと運用手順をセットで設計する際の一例です。実際の閾値や時間は、管理エリアの特性と要員数に合わせて調整してください。

この表で押さえてほしいのは順序です。物件の被害より先に人の安否を確認します。理由は単純で、担当者が動けるかどうかが分からないと、物件確認の割り当てができないからです。

この仕組みでできないこと

正直に書きます。以下は、システムで解決できません。

通信が途絶した地域の情報は取れません。 携帯回線が落ちている地域では、Webフォームも電話も届きません。この場合、システムができるのは「その地域が応答不能である」ことを地図上で示すことだけです。実際の確認は、人が向かうしかありません。衛星通信や無線を代替手段として持つかどうかは、システム設計ではなくBCPの判断です。

被害の深刻度を自動判定することはできません。 写真から「この建物は立入禁止にすべきか」を判定するAIを作ることはできますが、その判定を根拠に安全宣言を出すことはできません。建築物の応急危険度判定は制度に基づいて判定士が行うものです。システム上の状態区分は、あくまで社内の初動優先順位付けに使う分類です。

入居者全員の安否確認まで広げるのは現実的ではありません。 管理会社が入居者の安否を能動的に確認する義務は、通常の管理委託契約の範囲には含まれないと解釈されますが、契約内容により異なります。個別の責任範囲は管理受託契約書と専門家にご確認ください。仕組みとしては、入居者からの申告を受け付ける窓口（Webフォーム）を用意する側に振ったほうが、運用が破綻しません。

発災時だけ使うシステムは、発災時に使えません。 年に一度も開かないシステムは、パスワードを忘れ、担当者が変わり、操作方法が失われます。平時の物件マスタ・現場マスタに乗せる設計を勧めているのは、この理由が大きいです。点呼機能だけを切り出した単独システムを作るなら、最低でも年2回の訓練起動をセットで運用ルール化してください。

現場が使わなければ、何も集まりません。 フォームの存在を知らない、URLが分からない、ログインできない。この3つで報告は止まります。通知は必ず「タップしたらそのままフォームが開く」形にし、ログインを挟まない設計にしてください。認証はトークン付きURLで代替できます。導入時の合意形成については、AI導入に現場が反対する時の合意形成手順も参考になります。

まとめ

• 点呼対象リストは災害用に新規作成せず、日常の物件マスタ・現場マスタから毎回生成する。発災時だけ正しいリストは存在しない
• 絞り込みのために、住所文字列とは別に市区町村コードをマスタに持たせる
• 主画面には「報告が集まった件」ではなく「未報告の件」を出す。報告ゼロを異常として扱う
• 未報告は「未着信／送信済・未応答／応答不能」に分ける。取るべき行動が違う
• 一次報告はタップ3回で終わる構成にし、「未確認」の選択肢を必ず置く
• 写真はExifを残した原本と閲覧用の圧縮版を二層で保存する。加工済みだけを残さない
• 通信途絶地域の情報取得、被害深刻度の自動判定、入居者全員の安否確認は、この仕組みの範囲外

よくある質問

Q. 災害時の被害報告システムは、新しく物件リストを作る必要がありますか？

新規作成は不要です。日常運用している物件マスタ・現場マスタをそのまま点呼対象リストに転用します。別リストを作ると更新が止まり、発災時に「今は管理していない物件」や「退去済みの担当者」が混ざります。マスタ側に「所在地の市区町村コード」と「現在の担当者」を持たせておくことが前提条件です。

Q. 報告が集まらない前提で、どう設計すればいいですか？

「報告があった件」ではなく「報告がない件」を主画面に出す設計にします。対象リスト全件を初期状態「未報告」で生成し、報告が入った分だけ消える引き算方式です。停電・通信断・負傷など、報告できない状況ほど重大である可能性が高いため、報告ゼロを正常ではなく異常として扱います。

Q. 現場写真は被害報告用と保険請求用で分けて撮る必要がありますか？

撮影は1回で済ませ、保存側で要件を満たす設計にします。速報時のスマホ撮影で、撮影日時・GPS座標を含むExifを削除せずに原本保存し、閲覧用に圧縮版を別途生成します。損害保険や共済の請求では撮影時期の証明が問われることがあるため、リサイズ・加工した画像だけを残す運用は避けてください。

Q. 安否確認は既存の安否確認サービスではだめですか？

従業員の安否確認だけなら専用サービスで足ります。ただし専用サービスは社員名簿を対象にしており、協力会社の職長、物件の入居者、管理受託先のオーナーは対象外です。物件・現場と人を同じ軸で見たい場合は、既存の安否確認サービスを社員分に使い、物件・現場側は自社マスタから生成する二層構成が現実的です。

Q. 発災直後に電話が集中してしまうのを、どう減らせますか？

電話をゼロにはできません。減らせるのは「こちらから状況を聞く電話」であり、オーナーや入居者から入る電話は残ります。報告フォームで一次情報を集めつつ、集約結果をオーナー向けの一次報告文面に自動で流し込み、かけ直す前に先に送る運用にすると、問い合わせ電話そのものが減ります。

ご相談について

エクサテックは、不動産・建設の現場に入り込んでから仕組みを設計することを基本にしています。株式会社イーリアルティ様の転記エージェント開発でも、契約の前段階から何度も現場に足を運び、困りごとを理解するところから始めました。

災害時の情報集約は、既存の物件マスタ・現場マスタの状態によって設計が大きく変わります。「今のマスタのままで点呼リストが作れるか」を見るところからでも構いません。お気軽にご相談ください。