一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
社団法人 電子情報通信学会
INFORMATIONAND COMMUNICATION ENGINEERS

信学技報
IEICE Technical Report
信学技報
ICM2020-51,LOIS2020-39(2021-01)

THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERSTECHNICAL REPORT OF IEICE.

コロナ時代の密を考慮した避難所ナビゲーションアプリの開発
中田 大翔†

室谷 敏生††

中村 匡秀††† 兵庫県立姫路西高等学校†† 神戸大学大学院システム情報学研究科
E-mail: †{hiroto.nakata,musan}@ws.cs.kobe-u.ac.jp, ††masa-n@cs.kobe-u.ac.jp
あらまし

日本は災害大国であり, 毎年甚大な被害が出ている. 2020 年には COVID-19 の世界的流行により, 災害時の避難所において住民の受け入れ人数の削減などが行われ, 避難所に収容できないケースが発生している. 本研究では, 住民の自助によって避難所での密の形成を回避するアプリケーション Shelter Navi を提案する. Shelter Navi は自治体内に存在する避難所の場所と混雑度合いを管理し，地図上に可視化して，災害時に住民が密を避けて分散避難するための情報を提供する．住民が避難所に「チェックイン」すると，Shelter Navi は混雑度合いをリアルタイムに更新する．
これによって，各避難所に特別な設備を必要とすることなく，避難所での密を考慮した避難が可能となる．本稿では，Shelter Navi のユースケースを定義し，ドメインモデルおよびサービスの設計を行う．さらに，Shelter Navi のプロトタイプを Spring Boot および Bootstrap を活用したモバイル Web アプリケーションとして実装する．
キーワード

新型コロナウイルス，防災，避難所，Web アプリケーション，避難所，自助，自治体

Development of Shelter Navigation with Considering Three Cs in the Corona
Age
Hiroto NAKADA† , Toshiki MUROTANI†† , and Masahide NAKAMURA††† Himeji West High School†† Graduate School of System Informatics, Kobe University
E-mail: †{hiroto.nakata,musan}@ws.cs.kobe-u.ac.jp, ††masa-n@cs.kobe-u.ac.jp
Abstract Japan is a disaster-prone country, and tremendous damage occurs every year. Due to the global pandemic of
COVID-19 in 2020, evacuation shelters have been forced to reduce the number of residents, in order to reduce the risk ofinfection. Some evacuation shelters have been unable to accommodate evacuators due to full capacity. In this study, we
propose a novel application, Shelter Navi. It aims to avoid the formation of dense crowd in evacuation shelters by self-eﬀorts
of citizens themselves. Shelter Navi manages the location and the congestion status of every shelter within a local government,
and visualizes the information on a map. When a disaster occurs, citizens check the information with mobile phones, andevacuate to vacant shelters. As a citizen

checks in

to a shelter, Shelter Navi updates the status at real time. Thus, the app

allows crowd-aware evacuation without any special equipment in the shelter. In this paper, we ﬁrst deﬁne use cases of Shelter
Navi, and then conduct domain modeling and service API design. Finally, we implement a prototype of Shelter Navi as a Web
application, using latest application frameworks Spring Boot and Bootstrap.
Key words COVID-19, disaster preparedness, evacuation shelters, Web application, self-eﬀort, local government
災害警戒区域内であり，避難行動を促す情報が事前に発令され

1. は じ め にていた. つまり，特に豪雨災害においては，住民が逃げ遅れに

日本は災害大国であり，毎年大規模な自然災害が発生していよって死亡している事例が多い. 逃げ遅れの主な要因は，「自分る. 近年では，いわゆる異常気象による豪雨により甚大な被害は大丈夫だ」と思い込む正常性バイアス等の心理効果による避が発生しており，命を落とす人も後を絶たない. 2018 年 7 月の難意識の欠如 [2]〜[4]，災害時における適切な行動が分からな

西日本で発生した豪雨災害では，死者 200 人を超える被害が出

いなどの知識不足，避難場所の確認不足などが挙げられる [5]．

た [1]．犠牲者が出た地域の多くは，洪水浸水想定区域や土砂さらに 2020 年に起こった新型コロナウイルス感染症の流行- 100 -

—1—
This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.
Copyright ©2021 by IEICE

によって，感染対策を考慮した新たな避難所運営が必要になっ同じリスク評価，つまり事態を楽観視してしまう傾向であるている [6]．その一環として，三密回避のための避難所の受け入「平常性バイアス」が働く. これにより，自身に都合の良いよう

れ人数制限・管理があり，避難してきた住民が避難所に入れなに解釈をしてしまい，「自分は大丈夫だ」といったような思考がくなる事態が想定される．実際に 2020 年 9 月九州に台風 10 号

生まれ，結果として意思決定や避難行動の遅れにつながっていが直撃し避難所が開設された際に，避難してきた住民が 2 か所ると考えられている. [2] 加えて，避難する避難所の確認ができ

続けて受入拒否された事例が発生している [7].

ていない，避難経路がわからないなどの住民の事前準備や意識

このような問題に対して，独自に対策を行なっている自治体の低さも避難率の低下につながっている．

もある. 宮崎県日南市では，飲食店などの混雑状況を配信する

2. 2 コロナ時代の避難所運営

アプリケーション VACAN を用いて, 避難所の混雑状況の配信

2020 年，新型コロナウイルス感染症の世界的流行により，社を行い，一定の効果を上げている [8]．しかしながら，避難所の会のあらゆる場面で様式の変化が求められた. 防災の面では，

混雑状況は，自治体職員の手作業によって計測・更新されてい避難所での感染対策が急務で進められ，各自治体から感染対策る．したがって，コロナ時代に必要な新たな施策も，各自治体が盛り込まれた新たな避難所運営マニュアルが発行された. 具に任せきりになっており，職員の職務負担の増大につながって体的には，避難スペースの設置レイアウト例（収容人数，間隔いるのが現状である．

など）や避難所受け入れ前の検温・問診などの実施などが新た

このような背景の下，我々は「コロナ時代に災害が起きた場
合，住民が自治体に頼ることなく，自分たちで適切な避難所へに示された. また，密集を避けるため，避難所当たりの収容人数を大きく制限せざるをえなくなった．
このような感染対策により，状況がわからずに避難してき

分散避難できないか？」をリサーチクエスチョンに設定して研た住民が避難所に入れてもらえないケースが懸念されている．

究を進めている．
本研究では，住民の自助によって避難所での密の形成を回避

2020 年 9 月九州に台風 10 号が直撃し避難所が開設された際に，し，迅速且つ安全な避難の実現を支援するモバイル・アプリケー

避難してきた住民が 2 か所続けて受入拒否された事例が発生し

ション Shelter Navi を提案する. Shelter Navi は，クラウドサーている [7].

バで自治体内の避難所の場所と混雑状態を管理し，地図上に可このような問題に対し，独自に対策を行なっている自治体も視化して，災害時に住民が密を避けて分散避難するための情報ある．宮前県日南市では，飲食店の混雑状況などを配信するアを提供する．住民が避難所に「チェックイン」すると，Shelter

プリケーション「VACAN」を用いて，避難所の混雑状況の配信

Navi は混雑度合いをリアルタイムに更新する．これによって，を行っている．しかしながら，避難所の混雑状況は，自治体職

各避難所に特別な設備を必要とすることなく，避難所での密を員の手作業によって計測・更新されている．
このように，コロナ時代における避難所運営の新たな施策も考慮した避難が可能となる．
本稿では，Shelter Navi のユースケースを定義し，ドメインモ

試行錯誤的に行われてきているが，基本的には自治体に任せきデルおよびサービスの設計を行う．さらに，Shelter Navi のプロりになっており，職員の職務負担の増大につながっているのがトタイプを Spring Boot [9] および Bootstrap を活用したモバイ現状である．さらには，このような自治体の対策に住民が依存

ル Web アプリケーションとして実装する．Shelter Navi によっ

してしまい，住民の自助が抑制されてしまうことも懸念される.

て，住民の避難意識の向上と，With/After コロナ時代の避難所

2. 3 リサーチクエスチョン

運営の効率化につながることが期待できる.

以上を踏まえて，我々は以下のリサーチクエスチョンを設定

2. 準し，それに答える手法を研究している．

備

2. 1 日本における災害避難

RQ 「コロナ時代に災害が起きた場合，住民が自治体に頼る

近年わが国では，異常気象などの影響により「数十年に一度」

ことなく，自分たちで適切な避難所へ分散避難できないか？」と言われるような大規模な豪雨災害が頻繁に発生しており，毎

3. 提 案 手 法

年多くの犠牲者が発生している． 2018 年 7 月の西日本豪雨災
害では，避難勧告が発令されていたにもかかわらず，人的被害

3. 1 システム概要が多く発生したことが報告されている．[1] 犠牲者の中には「逃我々は，災害時にできるだけ住民の自助行動によって，密の形成を回避しつつ，安全かつスムーズに避難を行うことを支援すげ遅れ」によるものが多く存在した．
災害時における住民の避難を促すための情報として，気象庁

るアプリケーション Shelter Navi を提案する．Shelter Navi は，から発令される大雨・暴風・洪水等の気象警報，各自治体からクラウドサーバと住民各自が所有するスマートフォンを ICT で発令される避難勧告並びに避難指示等がある. 避難指示に関し連携することで構成される．リサーチクエスチョンを解決すては，強制力はないため，避難するかどうかは，避難することるために，我々は以下の A1 A3 のアプローチによって Shelter

による危険などを踏まえた住民の判断に任されている. しかし，

Navi を実現する．図 1 にその概要図を示す．

このような自身の身に危険が迫っている場合は，大量の情報のA1. クラウドサーバによる避難所の情報の管理

処理を時間的制約がある中で正確に行うことを迫られることな

Shelter Navi は，自治体が管理する避難所の情報をクラウド

どによる強いストレスにより，冷静さを保つ目的で，平常時とサーバで管理する．避難所の情報はマスタ情報と状態情報に分- 101 -

—2—

図 1 ShelterNavi の全体概要図

かれる．マスタ情報は，避難所名，住所，緯度経度，収容可能
人数，管理人等で構成され，事前に自治体の職員によって登録されるものとする．状態情報は，各避難所の現在の収容者，収容人数，混雑度合い等で構成され，A3 で後述するチェックイ
ンによって更新される．また，Shelter Navi を利用する住民は，住民ユーザ情報をクラウドサーバに登録する必要がある．住民
ユーザ情報は氏名，メールアドレス，パスワード，世帯人数，
自宅住所である．

A2. リアルタイムな避難所混雑状況の配信と可視化災害が発生した際，Shelter Navi は A1 の避難所情報を地図上に可視化する．住民は自身のスマートフォンで，自分の現在地

図 2 ユースケース図（GPS で取得）と近隣の避難所（地図上のピンで表示）を確認する．各避難所の混雑度は，ピンの色や詳細情報で確認できるため，住民は自身の状況と混雑状況に基づいて，最適な避難所を自分で探し避難を行う．

住民は Shelter Navi の利用にあたり，事前に自身の住民情報を登録する必要がある．サインアップ画面から，氏名，メール
アドレス，パスワード，世帯人数，住所などの情報を登録する．

A3. 避難所へのチェックイン
目的の避難所に到着したら，住民はスマートフォンのアプリ
ケーション上でチェックイン操作を行う．Shelter Navi はその住民のチェックイン時刻をクラウドサーバに記録するとともに，住民の世帯人数をその避難所の収容人数に加算し，混雑状況を更新する．チェックイン機能により，各避難所に収容されている住民とその数を職員の手を借りずに自動集計できる．また，スマートフォンの扱いに不慣れな住民のために，担当者が住民のチェックインを代理で行う機能も提供する．

登録後，住民はメールアドレスとパスワードでアプリにログイ
ンする．

C2. 避難所を検索する災害発生時に，住民は近隣の避難所を
Shelter Navi 上で検索する．自分の現在位置周辺の避難所が地図上にピンで表示され，その混雑度をピンの色で確認できる．
また，ピンをクリックすると，その避難所の詳細情報を確認できる．詳細情報は，避難所名，住所等のマスタ情報と現在の混雑度等の状態情報である．

C3. チェックインする住民は，目的の避難所に到着したら，

3. 2 ユースケース
Shelter Navi で実現する機能を明確化するために，ユースケー
ス定義を行う．Shelter Navi の利用者は，住民と自治体職員であり，それぞれのユーザロールでユースケース定義を行う．な
お，住民のユーザ登録は住民自身が行うが，自治体職員のユー

Shelter Navi 上でチェックイン操作を行う．システムは，その住民のチェックインを記録する．さらにシステムは，その避難所の収容人数にその住民の世帯人数を加算し，避難所の混雑状態を更新する．

3. 2. 2 自治体ユースケース

ザ登録は Shelter Navi の管理者が行うものとする．これは，自治体職員ユーザが災害時に住民の個人情報を参照するためであり，セキュリティ上の考慮である．図 2 に Shelter Navi のユー
スケース図を示す．

3. 2. 1 住民ユースケース
住民のユースケースとして，以下の C1〜C3 を示す．

C1. 住民情報を登録する

自治体ユースケースとして、以下の G1〜G3 を示す．

G1. 避難所を登録する自治体の担当職員が，避難所のマスタ情報を登録する．避難所名，住所，緯度経度，収容可能人数などのデータ項目を登録する．

G2. 避難所の状態を確認する災害が発生した際，自治体の担
当職員が各避難所の状態を確認する．画面には，地域内の全自- 102 -

—3—

図 3 システムアーキテクチャ

治体のリストと混雑ｒ状況がリアルタイムに表示される．特定の避難所を選択することで，チェックインしている住民の情報や人数を確認できる．これにより，自治体職員は混雑状況確認のために避難所に直接赴く必要がなくなり，感染拡大防止及びUser
ShelterCheck-In

避難所ID
場所
面積
最大収容世帯数
避難所の利用状態

職務負担軽減につながる．

1

0..*

チェックインID
ユーザID
避難所ID
チェックイン時刻
チェックアウト時刻

0..*

1

ユーザID
Email
パスワード
世帯人数
名前
住所
電話番号

1

G3. 住民の安否確認をする災害時に，自治体の担当職員が，特

更新

1

作成

定の住民の安否確認を行うことができる．名前やメールアドレ
1

スで住民を検索し，どの避難所に避難しているか，いつチェッ

0..*
ShelterStateクインしたか等の情報を確認する．安否確認は，親族や病院等，シェルターステートID
避難所ID
収容人数
混雑度(%)
更新日時

関係者や関係機関からの要請に基づいて，自治体職員が行うことを想定している．

3. 3 システムアーキテクチャ

ケーションとして構成される．
サーバサイドは，クラウドサーバの機能を配置し，避難所，
ユーザ，チェックイン等の主要なデータを管理する．コント
ローラ層，ドメイン層，永続層を有する典型的なレイヤードアー
キテクチャを採用し，データや操作へのアクセスは，REST-API
を通して行う．また，地図機能のために，外部の地図クラウドサービスを連携して利用する．サーバサイドで利用する技術としては，Java を実装言語とし，Spring Boot アプリケーション
フレームワーク，Apache Tomcat Web サーバを用いる．また，
データベースは MySQL，地図サービスには Google Maps APIを用いる．

エンティティが存在し，それぞれ Shelter（避難所），User（住民・ユーザ），Check-In（避難所へのチェックインまたはチェッ
クアウト），ShelterState（避難所の状態），UserState（ユーザの状態）となっている．

Check-In は，あるユーザとそのユーザが利用した避難所を関連付けるもので，1 回の Check-In には必ず 1 つの User と 1 つの Shelter が結びつく．また，ShelterState は各避難所の状態を表しており，UserState はユーザの避難状態を示している．それぞれ，新しい Check-In オブジェクトが生成された際に，更新・作成される．以下では，ShelterNavi の各エンティティのデータ
項目を説明する．

3. 4. 2 Shelter: 避難所エンティティ

一方クライアントサイドには，主にユーザインタフェースの機能を配置する．OS や機種の違いを意識せずに済むように，
スマートフォンまたは PC の Web ブラウザ上で Shelter Navi のユースケースを実行できるようにする．HTML，CSS，JavaScript
を実装言語とする．また，スマートフォンの画面で使いやすい

ユーザステートID
ユーザID
状態：[準備中，避難済み]
更新日時

図 4 ドメインモデル図

図 3 に Shelter Navi のシステムアーキテクチャのイメージを示す．Shelter Navi はクライアント・サーバ方式の Web アプリ

UserState

Shelter エンティティは，システムがどの避難所かを識別する
ための ID を持っている．また，避難するユーザに向けて避難所の名称，位置情報を示す必要がある．そして，避難所の開放
情報も取り扱う．

ように，Bootstrap を利用したレスポンシブルデザインを取り入
れる．

3. 4 ドメインモデリング
3. 4. 1 全体の構成とエンティティ関連
Shelter Navi で管理する情報を明確化するために，ドメインモデリングを行う．図 4 に ShelterNavi のドメインモデル図を示す．図 4 に示すように，Shelter Navi のドメインには 5 つの- 103 -•

sid：避難所 ID•

name：避難所の名称•

address：避難所の住所•

lat：避難所の緯度•

lng：避難所の経度•

capacity：避難所の収容可能人数•

isActive：避難所が利用可能か

—4—

を示す．

3. 4. 3 User: ユーザエンティティ

3. 5. 1 ShelterService: 避難所サービス

User エンティティは，ユーザを一意に識別するユーザ ID が避難所の CRUD(生成，読出，更新，削除) を行うサービスで必要である．また，本サービスに登録するための email アドレ
スとパスワード，安否確認で必要となる名前，住所，混雑度をある．以下に API の一覧を示す．

計算するための世帯人数を取り扱う．

•

uid：ユーザ ID•

email：メールアドレス•

password：パスワード•

name：ユーザの名前•

address：ユーザの住所•

of families：世帯人数•

createShelter( shelterForm )：避難所 ID，避難所名，位置情報を基に避難所データを作成し，取得する．

•

getShelter( sid )：避難所 ID を指定することで該当する

避難所データを取得する．

•

deleteShelter( sid )：避難所 ID を指定することで該当す

る避難所データを削除する．

•

clearAllShelters()：全ての避難所データを削除する．

3. 4. 4 Check-In: チェックインエンティティ•

getAllShelters()：全ての避難所データを取得する．

Check-In エンティティは，どのユーザがどの避難所にチェッ•

searchSheltersByDistance( lng, lat, distance )：経度，緯クインしたかを管理するために，ユーザ ID と避難所 ID が必要

度，そして距離を指定することで，指定位置座標 (lng, lat) からである．また，複数の避難所への多重チェックインがないかを

半径 distance[km] 以内にある避難所データ全てを取得する．当確認するために，チェックイン時刻と，チェックアウト時刻もAPI では，地球上における大圏距離を計算する手法を採用し，取り扱う．

ユーザの現在位置 𝑝 と与えられた避難所の距離 𝑠 の間の直線•

cid：チェックイン ID

距離 𝑑 ( 𝑝, 𝑠) 計算する．具体的には，地球の半径を 6371[km]，•uid：ユーザ ID

ユーザの経度座標を 𝑙𝑛𝑔，緯度座標を 𝑙𝑎𝑡 ，各避難所データの経•

sid：避難所 ID

度座標を 𝑠.𝑙𝑛𝑔，緯度座標を 𝑠.𝑙𝑎𝑡 としたとき，𝑑 ( 𝑝, 𝑠) を以下の•checkin-datetime：チェックイン時刻

計算式で求める．

•

checkout-datetime：チェックアウト時刻

𝑑 ( 𝑝, 𝑠) = 6371 × arccos(

3. 4. 5 ShelterState: 避難所の状態

cos(𝑟𝑎𝑑 (𝑙𝑎𝑡)) × cos(𝑟𝑎𝑑 (𝑠.𝑙𝑎𝑡)) × cos(𝑟𝑎𝑑 (𝑠.𝑙𝑛𝑔) − 𝑟𝑎𝑑 (𝑙𝑛𝑔))

ShelterState エンティティは，住民のチェックイン（および+ sin(𝑟𝑎𝑑 (𝑙𝑎𝑡)) × sin(𝑟𝑎𝑑 (𝑠.𝑙𝑎𝑡))

チェックアウト）とともに変化する避難所の状態を表現する．
対象とする避難所の ID，現在の収容人数，現在の混雑度，更新)

日時を属性として持つ．収容人数は，現在チェックインしてい•る全てのユーザの世帯人数の合計から算出する．また，混雑度て避難所を検索する．避難所名，または避難所住所に部分一致

は，収容人数を避難所の収容可能人数で割ることで求める．

•

id：避難所の状態 ID•

sid：避難所 ID•

num of people：収容人数

searchSheltersByKeyword( keyword )：文字列を指定しする避難所エンティティを全て取得する．

3. 5. 2 UserService: ユーザサービス
ユーザの CRUD を行うサービスである．以下に API の一覧•

congestion：混雑度

を示す．

•

changedAt：更新日時•

createUser( userForm )：メールアドレス，パスワード，

3. 4. 6 UserState: ユーザの状態

名前，住所，世帯人数を含むユーザ情報を元に新規ユーザを作

UserState エンティティは，ユーザの避難状態とその履歴を管成する．

理する．特定のユーザの履歴を見るためにユーザ ID が必要であ•る．そして，在宅，準備中，避難中，避難済の避難状態を表す．

ザエンティティを取得する．

•

また，避難状態が変化した際の日時を記録する．なお，ユーザの状態は履歴データを参照できるように，1 つのデータを更新

getUser( uid )：ユーザ ID を指定することで該当するユー
updateUser(uid, userForm )：ユーザフォームを入力して，既存のユーザ情報を更新する．

•

していくのではなく，新規データを追加していく形をとる．

deleteUser( uid )：ユーザ ID を指定することで該当する

ユーザエンティティを削除する．

•

id：ユーザの状態 ID•

uid：ユーザ ID

3. 5. 3 CheckInService: チェックインサービス•

state：避難状態 [在宅, 準備中, 避難中, 避難済]

避難所へのチェックイン，チェックアウト操作を行うサービ•

changedAt：更新日時

スである．以下に API の一覧を示す．

•

3. 5 主要なサービス

checkIn( uid, sid )：ユーザ ID と避難所 ID を指定して，ドメインモデルの各エンティティを操作する主要なサービチェックイン処理を行う．具体的には，Check-In オブジェクト

スを設計する．ShelterNavi では他のアプリケーションとの連を新規作成し，作成日時を記録する．同時に，避難所の収容人

携や拡張性を考慮し，HTTP-REST によって呼び出し可能な数をそのユーザの世帯人数分増加させ，避難所の混雑度を再計

Web-API として配備した．以下に各サービスの詳細算して，ShelterState オブジェクトを更新する．さらに，避難状

RESTful- 104 -

—5—

態を「避難済」に設定した UserState オブジェクトを新規作成する．

•

checkOut( uid, sid )：ユーザ ID と避難所 ID を指定して，チェックアウト処理を行う．ユーザ ID と避難所 ID から一意に定まる最新のチェックインデータを取得し，チェックアウト時
刻を記入する．同時に，避難所の収容人数をそのユーザの世帯
人数分減少させ，避難所の混雑度を再計算して，ShelterState オ
ブジェクトを更新する．さらに，避難状態を「避難中」に設定した UserState オブジェクトを新規作成する．

4. 実

装

4. 1 Shelter Navi プロトタイプの実装
前述した設計に基づき，Shelter Navi のプロトタイプを実装した．今回のプロトタイプでは，住民ユースケース C1〜C3 をカバーする．避難所のデータは神戸市の指定緊急避難所 335 件，
姫路市の指定避難所 255 件をデータベースに手動で登録した．
これらの避難所データは，神戸市 [10] および姫路市 [11] が公開する避難所オープンデータに基づいて作成した．
図5

プロトタイプ実装で用いた技術は以下のとおりである．

•

ログイン画面

サーバ開発言語：Java•

アプリケーションフレームワーク：Spring Boot•

データベース：MySQL 8.0.20•

Web サーバ：Apache Tomcat 9.0•

クライアント開発言語：HTML5, JavaScript•

CSS ライブラリ：Bootstrap 4

以下では ShelterNavi の「ログイン」，「サインアップ」
，
「避難
所検索」
，
「チェックイン」の各画面を例に挙げて，作成したプ
ロトタイプ実装を概説する．

4. 2 ロ グ イ ン
Shelter Navi のログイン画面を図 5 に示す．住民ユーザは画
面中央のフォームにメールアドレスとパスワードを入力してログインする．正しいメールアドレスとパスワードが入力できていれば，認証が成功し避難所検索画面に移行する．認証が成功すると，そのユーザに関連するエンティティにアクセスの認可が許可される．一般住民ユーザに認可・付与される権限では，自身のエンティティへのアクセスしか認可されないため，自分の情報が他ユーザから閲覧，更新，削除されることはない．
ユーザ情報をまだ登録していない場合には，「新規登録」ボタンを押すことで，次節で述べるサインアップ画面に移行する．

4. 3 サインアップ
サインアップ画面を図 6 に示す．住民が自身のユーザ情報
をフォームに入力し，新規登録を行う．ユーザの識別に必要な
メールアドレスと，認証に必要なパスワードを指定する．また，
図 6 サインアップ画面

システム内で扱われる名前，住所，世帯人数，電話番号（任意）からなる「個人情報」も併せて入力する．これらの情報を入力したうえで図 6 下部の登録ボタンをクリックすれば，ユーザ新

た地図が表示される．地図上には，現在地周辺（プロトタイプ

規登録の完了となる．

では半径 1[km] 以内としている）の避難所を番号付きのピン4. 4 避難所検索で配置している．周辺の避難所の検索は 3. 5 で紹介した API，

避難所検索画面を図 7 に示す．

searchSheltersByDistance() を利用してリアルタイムで更新する．

避難所検索画面では画面上部に青いマーカーを現在地とし

ピンの色は，避難所の混雑度の値に応じて，緑（低い），黄色- 105 -

—6—

図 7 避難所検索画面
図 8 チェックイン画面（中程度），赤（高い）の色で表示される．避難所のピンをクリッ
クすることで避難所の詳細情報を表示することもできる．
画面下部のリストには，地図上の避難所が距離が近い順に表示される．リストの各項目は，左から地図上のマーカーの番号，
避難所名，避難所の住所，混雑状況の 4 つである．最後に，画面最下部に検索バーでは，避難所 ID，名称，住所で避難所を検索できる．

4. 5 チェックイン
チェックイン画面を図 8 に示す．チェックイン画面では，チェックインする避難所を「現在地」，「エリア」，「地図」のいずれかから選択することができる．「現在地」から選択する場
合，画面上部の青色の「現在地を取得」ボタンをクリックすれ
ば，現在地に存在する避難所を選択することができる．「エリア」から選択する場合は，画面中央の「エリアから選択」の項目である都道府県，市町村，地域をプルダウンメニューから選

図 9 チェックアウト画面

択することで避難所のプルダウンメニューに条件に該当する避難所リストが現れる．「地図」から選択する場合は，画面下部のらのチェックアウトが完了する．

地図上にある赤いマーカーをクリックすることで避難所の選択

5. 考が可能になる．これらのいずれかの方法で避難所を選択してか察ら画面右下の「チェックインする」ボタンを押すことで避難所

5. 1 ShelterNavi の効果・メリット

へのチェックインが完了する．

Shelter Navi の実現によって得られる効果・メリットとして，

チェックアウト画面を図 9 に示す．いずれかの避難所にチェッ以下の 3 点が挙げられる．

クイン済みの場合，チェックアウト画面左下には「現在の避難1 つ目は，住民が受け入れ人数に余裕のある避難所を自力で所：「※チェックイン済みの避難所名」からチェックアウトしま

見つけることができる点である．これは，本稿のリサーチクエ

すか？」の 1 文が表示される．画面右下の「チェックアウトすスチョンである「住民が自治体に頼ることなく，自分たちで適る」ボタンを押すことで，現在チェックインしている避難所か

切な避難所へ分散避難できないか？」という課題の解決に資す- 106 -

—7—

文るものである．

2 つ目は，避難所の混雑度が住民のチェックインとシステム
によって自動的に算出・更新される点である．これによって，各避難所に混雑状況を管理する専任職員を置く必要がなくなる．

3 つ目は，自治体の職員がリアルタイムで登録されている全避難所の状況を確認できる点である．各避難所の状況を Shelter

Navi で一括横断的に管理できるため，自治体職員の職務負担を軽減するとともに，安否確認や分散避難指示など，従来では困難だった避難所運営のアクションが可能となる．

5. 2 ShelterNavi の限界
我々が現状で把握している Shelter Navi の限界として，以下の 3 つが挙げられる．

1 つ目は，正確な避難所情報の登録が必要となる点である．
具体的には，平時において避難所の緯度経度や収容可能人数，
開設状況等のマスタ情報を登録・保守する必要があり，これには自治体の協力が必須である．

2 つ目は，スマートフォンの操作に慣れていない人にとって，

献[1] 国土交通省 平成３０年７月豪雨災害の概要と被害の特徴[2] 菊池聡, 非常時の思い違いと批判的思考 日本科学教育学会年会論文集, Vol.35, pp.9-10, 2011.
[3] 国土交通省 住民自らの行動に結びつく災害情報の提供へ 〜危
機感が伝わる、メディアとの連携策をとりまとめ〜 2018.12.11[4] 皆川勝、中村遼太、高橋翔天 極低頻度の災害に対する避難行動の社会心理学的な考察 土木学会論文集 F ６ Vol.72 No.2
I191 I198 2015.7.10[5] 田中重好 東日本大震災を踏まえた防災パラダイム転換 Vol.64
No.3 p.342-365 2013.
[6] 内閣府 新型コロナウイルス感染症を踏まえた災害対応のポイ
ント【第１版】について[7] 毎日新聞 避難所「先着順で満員、2 回も振られる」台風 10 号、
コロナ対策で収容人数の減少で 2020.09.07[8] 株式会社バカン 株式会社バカンと宮崎県日南市、災害発生時に IoT を活用して避難所の混雑情報配信を支援する協定を締結
2020.08.03[9] Spring Why Spring? https://spring.io/why-spring[10] 神戸市， 災害時の避難所”, https://www.city.kobe.lg.jp/
a46152/bosai/prevention/evacuation.html[11] 姫 路 市 ，“オ ー プ ン デ ー タ カ タ ロ グ サ イ ト”, https://city.
himeji.gkan.jp/gkan/dataset/hinanshisetsu

Shelter Navi をうまく操作できるかという懸念である． Shelter
Navi はスマートフォンでの使用を前提としたアプリケーションであるため，スマートフォンの操作に不慣れな，またスマートフォンを所有していない高齢者などの人々にとって，このアプ
リケーションを利用することは難しいと予想される．

3 つ目は，アプリケーションがモバイル通信網に依存しているという点である．災害時にモバイル通信網が不通になった場
合，サーバへアクセスできなくなるため，Shelter Navi が動作しない．

6. お わ り に本研究ではコロナ時代の災害を想定し，住民の自助によって避難所での密の形成を回避し，迅速且つ安全な避難の実現を支援するモバイル・アプリケーション Shelter Navi を提案した．
クラウドサーバによる避難所の混雑状態の管理・可視化と，住民による避難所の検索とチェックインによって，各避難所に特別な設備を必要とすることなく，避難所での密を考慮した避難が可能となる．また，Shelter Navi のユースケース定義，ドメイ
ンモデル，サービスの設計を行い，プロトタイプを Web アプリ
ケーションとして実装した．
今後の課題としては，実際の避難を想定した有効性評価を行うことである．これには，近隣の自治体に協力を依頼して避難所データの整備を行ったうえで，避難訓練等の機会に住民に試用・評価してもらうことを考えていきたい．また，Shelter Naviの機能強化も併せて行う予定である．まずはユーザによる私的な避難所（親類宅や友人宅など）の登録・管理機能の追加があげられる．さらには，避難所での情報共有や避難者同士のコミュ
ニケーション等，チェックイン後の避難生活の質を向上する機能も考えていきたい．
謝辞 本研究は，JST グローバルサイエンスキャンパス ROOT
プログラム，JSPS 科研費 JP19H01138, JP18H03242, JP18H03342,

JP19H04154, JP19K02973，JP20K11059, JP20H04014, JP20H05706の研究助成を受けて行われている．

- 107 -

—8—