避難所・災害対応拠点管理 設計書

• 企画キー: hinanjo-saigai-kanri(apps.yaml)
• kintoneスペース: 避難所・災害対応拠点管理(spaceId: 54)
• 関連ドキュメント: DFD / ER図

1. 目的

避難所を含む災害対応拠点(位置・種別・収容人数)を1つのマスタで一元管理し、各拠点の混雑状況を記録・共有するとともに、災害従事職員の情報と配置状況を管理する。また、避難者の受付(世帯単位)・入退所管理と、物品(食料・生活用品等)の貸出管理も行う。JavaScriptカスタマイズは行わず、kintone標準機能(フィールド・レイアウト・グループ・LOOKUP・サブテーブル・計算フィールド)のみで構成する。

もとは「避難所管理」(避難所マスタ+混雑状況)と「災害従事職員管理」(職員マスタ+施設マスタ+配置管理)の2企画として構想していたが、避難所マスタと施設マスタはいずれも「災害対応拠点の位置情報」を管理する点で重複するため、1企画・1マスタに統合した。

避難者受付・物品貸出管理は、もともとGoogle Workspace(フォーム/スプレッドシート/Apps Script)で構想されていたもの(hinanjo_idea.md参照)をkintoneへ移植したもの。フォームはkintone標準のレコード追加画面をそのまま使うため、Google版にあった専用フォーム(受付/退所/物品貸与/物品返却の4フォーム)・フォーム回答シート・GASの正規化処理(onFormSubmitRouter)は不要になった。世帯構成員はGoogle版ではJSON配列文字列だったが、kintoneでは「世帯構成」サブテーブルとして構造化して持つ。物品の貸与ログもGoogle版では別シート(物品貸与)だったが、kintoneでは「物品マスタ」アプリ内の「貸出履歴」サブテーブルに統合し、現在の在庫・貸出状況は物品マスタのメインフィールド(計算フィールド)で把握する。

2. アプリ構成

マスタアプリ(施設・避難所マスタ、職員マスタ、物品マスタ)を先に作成し、業務アプリ(混雑状況、配置管理、避難者名簿)がそれらを参照する構成とする。

3. 業務フロー概要

1. 防災担当の職員が、拠点の指定・変更時に「施設・避難所マスタ」へ施設番号・施設名・避難所種別(指定緊急避難所/指定避難所/福祉避難所)・住所・位置(緯度経度)・収容人数・管理者等を登録する。避難所以外の災害対応拠点(災害対策本部となる施設等)を登録する場合は、避難所種別を空欄のままにできる。 2. 人事・防災担当の職員が、「職員マスタ」へ災害従事職員の職員番号・氏名・所属・役職・連絡先・参集区分を登録する。 3. 物資担当の職員が、平時に「物品マスタ」へ物品ID・対象施設(LOOKUP)・品名・カテゴリ・単位・総数を登録する。 4. 災害発生時、各避難所の担当職員が「混雑状況」アプリに対象施設(LOOKUP)・報告日時・混雑状況(空きあり/やや混雑/満員/受入不可)・現在の避難者数を随時登録する。対象施設を選択すると、マスタの収容人数が「定員(収容人数)」に自動コピーされ、定員との比較がしやすくなっている。同じレコード内の「避難者名簿一覧」(関連レコード一覧)で、対象施設と同じ避難所の受付(世帯)ごとの避難者数(在所人数)を視覚的に確認できる。 5. 災害対策本部の職員が、「配置管理」アプリで対象職員(LOOKUP)・配置先施設(LOOKUP)・配置期間(開始/終了日時)・役割(施設責任者/受付/物資管理/巡回/その他)を登録し、状況(配置予定/配置中/配置終了)を随時更新して職員配置を管理する。 6. 受付職員が、避難者の来所時に「避難者名簿」アプリでレコードを1件新規作成し(=世帯単位の受付)、受付ID・避難所(LOOKUP)・代表者氏名・世帯人数・住所・電話番号・ペット同伴・入所日・世帯構成(サブテーブルに世帯員を1行ずつ、入退所状況=在所として入力)を登録する(ステータス=在所)。世帯の一部だけが退所・転居する場合は、その世帯員の行の入退所状況を個別に「退所」へ変更する(避難者数(在所人数)は自動で再集計される)。世帯全員が退所する場合は、世帯構成の全行を「退所」にした上で、世帯側の退所日・ステータスも更新する。 7. 物資係が、物品を貸し出す際は「物品マスタ」の対象レコードを開き、「貸出履歴」サブテーブルへ貸与日時・借用世帯(避難者名簿の受付ID)・数量・返却予定日・ステータス(貸与中)の行を追加する。返却時は同じ行のステータスを「返却済」に変更し、返却日時を入力する。貸出中数量・残数・現在の貸出状況はメインフィールドの計算フィールドが履歴サブテーブルから自動集計する。

4. 「施設・避難所マスタ」アプリ フィールド一覧

5. 「職員マスタ」アプリ フィールド一覧

6. 「混雑状況」アプリ フィールド一覧

7. 「配置管理」アプリ フィールド一覧

8. 「物品マスタ」アプリ フィールド一覧

Google版(hinanjo_idea.md)では物品マスタと物品貸与ログを別シートに分け、貸出中数量・残数はスプレッドシート関数(SUMIFS)で他シートを横断集計していたが、kintoneには条件付き集計(SUMIF相当)がサブテーブル跨ぎでは使えないため、ログを物品マスタ自身の「貸出履歴」サブテーブルへ統合し、行ごとの計算フィールド(kashidashichuu_h)で条件判定した値をアプリ内のSUM()で集計する構成に変更した。

9. 「避難者名簿」アプリ フィールド一覧

Google版では世帯構成員をJSON配列文字列(避難者名簿シートG列)として1セルに格納していたが、kintoneでは標準のサブテーブル機能で1行1人の構造化データとして持てるため、JSON文字列化やGAS側でのパース処理(parseHouseholdMembers_等)は不要になった。世帯員ごとの入退所状況もサブテーブルの列として持たせたことで、Google版の課題だった「世帯の一部だけの退所に非対応」も解消し、避難者数(在所人数)はこの入退所状況から計算フィールドで自動集計している。

フィールド定義・レイアウトの正はapps.yamlの該当エントリ(fields / layout)であり、本表はその要約。フィールドを追加・変更した場合は、apps.yamlの更新に合わせて本表も必ず更新すること。

10. マスタ参照(LOOKUPフィールド)について

• 「混雑状況」のtaisho_shisetsuは、「施設・避難所マスタ」を参照するLOOKUPフィールド。コピー元フィールドはshisetsu_bangou(施設番号・重複禁止)で、選択時のピッカーにはshisetsu_bangou/shisetsu_mei/hinanjo_shubetsuを表示する。fieldMappingsによりshuuyou_ninzuu(収容人数)をteiin_ninzuu(定員)へ自動コピーする。
• 「配置管理」のtaisho_shokuinは「職員マスタ」を参照するLOOKUPフィールド(コピー元: shokuin_bangou、ピッカー: shokuin_bangou/shimei/shozoku)。
• 「配置管理」のhaichi_saki_shisetsuは「施設・避難所マスタ」を参照するLOOKUPフィールド(コピー元: shisetsu_bangou、ピッカー: shisetsu_bangou/shisetsu_mei/hinanjo_shubetsu)。
• 「物品マスタ」のtaisho_shisetsuは「施設・避難所マスタ」を参照するLOOKUPフィールド(コピー元: shisetsu_bangou、ピッカー: shisetsu_bangou/shisetsu_mei)。
• 「避難者名簿」のhinanjoは「施設・避難所マスタ」を参照するLOOKUPフィールド(コピー元: shisetsu_bangou、ピッカー: shisetsu_bangou/shisetsu_mei/hinanjo_shubetsu)。
• 「物品マスタ」のkariyousha_h(貸出履歴サブテーブル内)は避難者名簿のuketsuke_idを人が参照する想定だが、kintoneのサブテーブル内にはLOOKUPフィールドを配置できない制約があるため、通常の文字列フィールドとしている(自動補完・自動検証は行われない)。サブテーブルルックアッププラグインの導入を想定しており、導入後は本来のLOOKUPに置き換える(下記13.参照)。

apps.yamlではlookup.relatedApp.appKeyのように参照先を企画内のアプリキーで指定しており、scripts/create-apps.mjsがマスタアプリ作成後に実際のappIdへ解決してからkintone APIに送る仕組み(resolveLookupField())を利用している(道路照明管理の設計書6.も参照)。

11. 関連レコード一覧(REFERENCE_TABLEフィールド)について

• 「混雑状況」のhinansha_meibo_ichiranは「避難者名簿」を参照するREFERENCE_TABLEフィールド。条件は自アプリのtaisho_shisetsu(対象施設)と避難者名簿のhinanjo(避難所)が一致するレコードを表示し、uketsuke_id/daihyousha_shimei/zaisho_ninzuu/statusをnyuusho_biの降順で最大10件一覧表示する。避難所ごとの避難者数(世帯単位の在所人数)を、混雑状況アプリを開くだけで視覚的に把握できるようにするためのもの。
• apps.yamlではreferenceTable.relatedApp.appKeyで参照先を企画内のアプリキーで指定する(LOOKUPと同じappKey方式、resolveReferenceTableField()で解決)。LOOKUPと異なりkintoneのPUT(フィールド更新)で参照先・条件・表示項目を作成後も自由に変更できるため、参照先アプリ(避難者名簿)が先に作成済みである必要はあるが、apps.yaml上のapp配列の並び順そのものへの制約はLOOKUPほど強くない。
• ただし本企画では、避難者名簿のzaisho_ninzuu(避難者数)フィールドをこのREFERENCE_TABLEのdisplayFieldsが参照しているため、kintone側の実際のデプロイ順序としては避難者名簿のzaisho_ninzuuフィールドが先に存在している必要があった(displayFieldsに存在しないフィールドを指定するとkintone APIがエラーを返す)。そのためapps.yamlのapps配列でも「避難者名簿」を「混雑状況」より前に並べている。
• 「避難者名簿一覧」はレコードを一覧表示するのみで、避難者数の合計値はkintone標準機能では自動集計できない(見た目で目視合算する運用)。関連レコード集計プラグインの導入を想定しており、導入後は避難所単位の避難者数合計をメインフィールドに直接表示できるようにする(下記13.参照)。

12. 地図プラグインについて

「施設・避難所マスタ」のido(緯度)/keido(経度)フィールドの直後に、地図プラグイン設置用のスペース(elementId: map)をレイアウトに配置済み。プラグイン自体の選定・設定は本設計書の範囲外(未着手)。

13. 業務アプリで利用を想定している追加プラグインについて

現時点では未導入・未設定だが、以下2つの自治体向けkintoneプラグイン(govapps-plugin.pons-llc.com)の利用を想定している。プラグイン自体の選定・購入・インストール・フィールド設定は、地図プラグインと同様に本設計書およびapps.yaml/scripts/create-apps.mjsによる管理の範囲外(手作業でのkintone管理画面上の設定が必要)。導入した場合は、該当フィールドの型・設定をこのドキュメントとapps.yamlに反映すること。

• 関連レコード集計プラグイン(https://govapps-plugin.pons-llc.com/plugins/related_record_summary/): 「混雑状況」の避難所情報表示に利用を想定。現状のhinansha_meibo_ichiran(REFERENCE_TABLE、11.参照)は避難者名簿のレコード一覧を表示するだけで、避難者数の合計はkintone標準機能では自動集計できないため、本プラグインにより対象施設に紐づく避難者名簿のzaisho_ninzuu(避難者数(在所人数))の合計値をメインフィールドに表示することを想定している。
• サブテーブルルックアッププラグイン(https://govapps-plugin.pons-llc.com/plugins/subtable_lookup/): 「物品マスタ」の物品の貸出ステータス管理に利用を想定。現状のkashidashi_rireki(貸出履歴)サブテーブル内のkariyousha_h(借用世帯)は、kintone標準ではサブテーブル内にLOOKUPフィールドを配置できないため文字列フィールドの手入力としている(8.・10.参照)。本プラグインによりkariyousha_hを避難者名簿を参照する正式なLOOKUPフィールドに置き換え、貸出先世帯の選択式入力・参照整合性の確保を想定している。

14. 未決定・今後の検討事項

• 避難所の開設・閉鎖(避難所自体の稼働ステータス)を「施設・避難所マスタ」側で持つか、別途管理するか
• 「混雑状況」の報告頻度・報告手段(職員による手入力か、外部システム連携か)の運用フローの詳細化
• 災害対応拠点(避難所以外)の種別(災害対策本部、物資集積所等)をhinanjo_shubetsuとは別に管理するかどうか
• 「避難者名簿」に受付時点の世帯人数を別途保持する固定フィールドは持たない(世帯構成サブテーブルの行数がそのまま世帯人数、zaisho_ninzuu(在所人数)が現在値)。受付時点の人数を後から個別に参照したい場合は、世帯構成サブテーブルの行数を数える運用で代替する。
• QRコード等による受付ID・貸与IDの入力効率化(Google版13章の拡張案)は本移植では対象外