スマートフォンのブラウザ記憶領域を用いた災害情報流通システムの提案
Proposal for a Disaster Information Distribution System
Using Smartphone Browser Storage Space筒井 巽水 1∗
Tatsumi Tsutsui1
諏訪 博彦 1
Hirohiko Suwa1

松田 裕貴 1
Yuki Matsuda1

峯 英一郎 2Eiichiro Mine2

秦 恭史 1
Kyoji Hata1

稲場 圭信 3
Keishin Inaba3

安本 慶一 1
Keiichi Yasumoto1

1 奈良先端科学技術大学院大学
1 Nara Institute of Science and Technology
2 一般社団法人地域情報共創センター
2 Regional Information Co-Create Center
3 大阪大学3 Osaka University

Abstract: 災害時には避難所への支援物資の供給やボランティア派遣などを行うために，各機関との連携が不可欠である．連携には電話や FAX，インターネットを利用した通信が一般的だが，災害時には建物の倒壊や停電の影響で通信が断絶する可能性が高い．そのため，本研究では避難所などの人が集まる場所にエッジサーバを設置し，インターネットに接続されていないエッジサーバ間におけるデータ交換を実現するための，Web ブラウザの一時ストレージを活用した DTN（Delay TolerantNetworking）の構築法を提案する. 本提案手法では，災害時にネットワーク接続が切断された状況下でも，避難所間を移動する自治体職員，社会福祉協議会職員，防災士，災害ボランティアおよび一般市民をデータフェリーとして活用することで，低コストで距離に依存しない通信を実現する．

1 はじめに
日本では地震などの自然災害が多く発生している [1]．
近年の例では，東日本大震災や熊本地震，能登半島地震などの地震が起こっており，津波や火災による建物の倒壊から人々の生活に大きな影響を与えている．これらの地震の直後，被災者は正確な情報を取得した上で在宅避難及び避難所への避難が推奨されている [2] が地震の影響により，基地局の倒壊や停電が起き，外部との通信が遮断される可能性が高い．そのため，被災者は適切な情報の取得や家族や友人の安否確認を容易に行えない. また，災害時には一般的に災害対策本部が設置され被災地からの情報収集を行うが，通信インフラが断絶された状況では既存の電話や FAX，インターネットが利用できず，効率的に情報収集を行うのが難しい．これらの問題から，災害時には既存の通信イン∗ 連絡先：奈良先端科学技術大学院大学〒 630-0192 奈良県生駒市高山町 8916 番地-5
E-mail: tsutsui.tstsumi.tr2@is.naist.jp

フラが崩壊した状況でも被災地の情報を流通させるシステムが必要である．
そこで，本研究では災害時に通信インフラが断絶された状況でも被災者に災害情報を提供するためのインフラレスな災害情報流通システムの構築を提案する．また，本提案では多くの被災者が所持しているスマートフォンを利用し，特別なネイティブアプリのインストールが不要なシステムの構築を行う.
本稿の構成は以下の通りである．2 章では，災害支援アプリケーションに関する関連研究について述べる．
3 章では，本稿で想定する災害シナリオについて述べる．4 章では，3 章の災害シナリオを解決するための提案手法について述べる．5 章ではプロトタイプシステムの実装について述べ，6 章では本稿のまとめについて述べる．

表 1: Web 上で利用できる災害マップ比較

災救マップ
Yahoo! 避難場所マップ
国土地理院 ハザードマップ

リアルタイム性◯△△

インタラクティブ性◯
××

情報の信憑性◯◯◯

通信インフラ断絶時の使用
×××

2 関連研究本章では，提案システム実現のために災害に関連するアプリケーションの開発事例について概観する．

2.1 通信環境下でのアプリケーション開発事例
上杉らの研究 [3] では，平常時から利用できるスマートフォン向け防災ゲームアプリ「防災 Go!」を開発しており，防災まちづくりに資する効果や課題を検証している．本アプリは，ゲーミフィケーションを導入することで，住民が日常生活を通じてコミュニティに親しみ，災害が発生する前に避難できるように動機づけることを意図している．熊本県緑川流域周辺の住民を対象とした検証実験では，さまざまな世代の利用者が地域の災害危険リスクを探究し，理解する動機づけとなることが示されている．
Jawahir らの研究 [4] では，災害後の救援活動を支援するための地理情報システム（GIS）ベースのモバイルアプリケーション「E-Trip」を提案している．このアプリケーションは，地震，洪水，土砂崩れなどの災害後の行動をガイドするもので，国家災害管理機関，地域保健センター，および民間病院と連携している．主な機能としては，災害に遭った住民が写真などで，災害地点や周りの情報を提供できるようになっており，政府や救援団体による効率的な支援活動が可能となることが期待されている．
ブラウザ上で利用できる Web アプリケーションには，稲場らが開発した未来共生災害救援マップ（以下，災救マップ）[5] や，Yahoo！ Japan の避難場所マップ [6]，国土交通省の特別機関である国土地理院が避難場所のデータをまとめたウェブマップ [7] が存在する．それぞれのマップに共通して被災に対応している避難所の確認や位置情報などが確認できる．各 Web マップの特徴をまとめた表を表 1 に示す．
「リアルタイム性」は，現地の情報をリアルタイムに更新できるかという観点である．
「インタラクティブ性」はマップを通じて，ユーザ同士が情報交換できるかという観点である．
「情報の信憑性」は，アップロードされている情報が信頼できるかという観点である．
「通信インフラ断絶時の使用」は，

図 1: 災救マップの投稿画面ネットワークが利用できない時にデータを取得できるかという観点である．Yahoo！ Japan の避難場所マップ
や国土地理院 ハザードマップは情報の信憑性は高いが，市民からの情報を集めるのが難しく，自治体に応じて表示画面の変更などが行えないため，表 1 の評価となっている．その点，災救マップは図 1 のようなユーザの投稿からリアルタイムの情報を詳細に取得できるのが特徴である．また，投稿機能を利用して，メッセージを伝えることも可能である．そのため，リアルタイム性，インタラクティブ性において，他のマップよりも有用と考える．しかし，全てのマップに一貫して，通信インフラ（インターネットを想定）断絶時には利用できないという課題を抱えている．本研究では，通信断絶時の使用を部分的に可能にすることを目指す．

2.2 オフライン環境でのアプリケーション開発事例
西山らの研究では，自律分散ネットワークの制御を行い，スマートフォンアプリの「スマホ de リレー」の開発を行なっている [8]．自律分散ネットワークとは，スマートフォンに代表されるモバイル端末のみを用いて通信ネットワークを構築する技術である．また，スマホ de リレーは，Wi-Fi Direct や Bluetooth などのスマートフォン同士の直接通信手段を駆使して通信をリレー（中継）することで，通信インフラがない場所でもスマートフォン同士のコミュニケーションを可能とする．これにより，インターネットに接続していない状態でも相互にコミュニケーションをとることが可能なチャットアプリを実現できる．また，本アプリケーションは高知県で導入されており，避難者情報の伝達・収集のために利用されている．
Muhammad らの研究 [9] では，火山災害における緊急医療対応の一環として，DTN を用いた医療画像配信サービスが提案されている．このサービスは，災害地域から都市の病院へ被災者の目の怪我に関する画像データを効率的に送信することを目的としている．専門医は，受け取った画像を基に目の怪我のタイプと重症度を診断し，適切な医療指示を医療従事者に提供する．この研究では，画像は高優先度と低優先度の部分に分割され，それぞれの優先度付けにより，重要な医療画像がより迅速に送信される．また，このシステムは Androidデバイス用のアプリケーションとして設計・実装が行われている．
Edgar らの研究 [10] では，災害による通信インフラが崩壊した時を想定し，災害時におけるデジタル歩行者地図作成システムの提案を行なっている．提案手法
では，主に三つの主要な課題に対処しており，最初に，GPS トレースを用いて地図データを収集し，災害地域に設置されたエッジノードで処理を行う．次に，遅延耐性ネットワークとエピデミック通信を用いて，断続的な通信環境でもデータを共有できるようにしている．
最後に，負荷バランスのヒューリスティックを提案し，地図生成タスクの効率を向上させている．このシステ
ムは，大量のデータを処理する極端なケースで地図の生成と配信時間を約 2 時間短縮できることが確認されている．

2.3 関連研究の課題
従来の研究で開発されているシステムの多くはネットワークへの接続が不可欠であり，災害時に通信インフラが断絶された状態では利用することができない．また，通信インフラが断絶された状態を想定されたシステムの実装も行われているが，これらはネイティブアプリの実装が不可欠である．実際の災害現場では，ネイティブアプリを持っていないユーザも多くいることが想定され，多人数のユーザに向けた情報提供が困難なことが想定される．これらの問題点を踏まえ，本研

災害対策本部

被災地

情報収集
⾃治体職員、社会福祉協議会、災害ボランティアなどは複数の避難所を周る

活動内容

避難所への物資輸送

災害⽀援をするＮＰＯ／ＮＧＯなどの⺠間組織のボランティア

ü 情報収集ü 物資の⽀援ü 救援活動図 2: 避難所をめぐる人の流れ
究ではオフラインの状況でも特別なインストールが不要な Web ブラウザを利用した通信システムを構築する．

3 想定シナリオ
本章では，2024 年 1 月 1 日に起きた能登半島地震を例として，本提案手法で想定する災害シナリオについて述べる．

3.1 被災地の現状
能登半島地震では，最大震度７の非常に大きな地震が起こり，建物の倒壊や断水，火災など被害が発生した [11]．また，約 34000 戸の家で停電となり，これらの被害の影響で多くの市民が避難所への避難を行った．
避難所での生活には食料や衣類，医療の物資の供給や情報収集・提供が必要となる．これらの物資や情報流
通は，被災地に設置された災害対策本部や災害支援を行う NPO/NGO などの民間組織から派遣される職員やボランティアが各避難所を周ることで行われている．
災害対策本部は，被災地から離れた金沢市におかれ，被災地との間を往来して活動が行われている．また，通信インフラの利用が可能な状況であれば各地の情報収集には電話や FAX，インターネットなどが利用されるが，今回の震災時のように通信インフラが断絶された状況では，自治体の職員や自衛隊隊員，災害支援を行う
NPO/NGO などの民間組織から派遣される職員やボランティアが，直接現地を訪問することで情報収集を行っている [12]．避難所をめぐる人の流れを図 2 に示す．
また，通信インフラの断絶に対応するために，スターリンクや発電機が導入された. これにより，通信が復旧された避難所は存在するが，バッテリーや発電機の燃料制約，衛星通信の不安定さもあり，全ての地域で安定した通信の供給が行われたとは言い難い．実際，スターリンクが避難所に届くまで通信が断絶されていた避難所はあり，届いたあとも通信が途絶える時間帯が発生している．

表 2: 想定する災害状況
災害時の要素想定状況

災害
通信インフラ地震
被災地外との通信は不可 (中継機の利用により，一時的なアクセスは一部地域で可能)
被災地内外の移動は可能
地域に応じて利用可能
スマートフォン
数日から１ヶ月程度

交通インフラ
水道・電気・ガス
使用可能な機器期間

今後の震災時においては，船上基地局，車両中継器，スターリンク，成層圏通信プラットフォーム HAPS などが使われることによって，通信インフラ断絶の期間は短縮されると考えられるが，通信を安定して供給するのは依然として難しく，「中継機が届かない地域や通信が行えない時間帯に如何に情報を集約して管理するか」は今後も重要な課題になると考える.

3.2 本研究で対象とする災害状況
前節の災害の例から，本研究では表 2 に示す災害状
況を想定する．本研究で対象とする災害は，東日本大震災や能登半島地震などのような大規模な地震である．
また，通信インフラは基地局の倒壊や通信線の切断，電力供給の途絶の影響から基本的に利用できないと想定する．ただし，スターリンクなどの中継機を使うことで，一時的な通信が一部の地域に限っては可能となると考える．
さらに，避難所への移動は可能であり，水道，電気，ガスなどのライフラインは，地域により利用可能とす
る．避難所間を移動する自治体職員，社会福祉協議会
職員，防災士，災害ボランティアおよび一般市民は，スマートフォンを所持しており，Wi-Fi を利用してローカルサーバへのアクセスは可能と想定している．なお，通信インフラの断絶は徐々に改善されていくことが想定されるため，対象とする期間は，災害が発生して数日から１ヶ月程度の間としている．

3.3 被災地で解決すべき課題とアプローチ
被災地の現状を踏まえ，解決すべき課題は 2 つある．
１つ目の課題は，避難所内の情報共有である．避難所内では，避難者数やインフラの状態などの情報共有が必要となる．従来の手法では，手書きの掲示板やメモなどを利用することが想定されるが，人手や時間などコストがかかる．また，掲示板などは特定の場所に設置されるため，情報を取得するためにその都度その場所まで移動しなけれならない．
この課題に対して，Wi-Fi を利用したローカルネットワークを用いることで，手軽に情報提供・取得を行えるようにすることが可能となる．また，デジタル情報で避難所内の情報を管理することで，外部の人でも簡単に避難所の状況を把握することを可能となる．
２つめの課題は，被災地全体及び被災地外との情報共有である．災害時には，支援物資の供給や救援活動計画立案・実施のために，被災地外から被災地内の情報を取得する必要がある．しかし，スターリンクなどの中継機を利用した通信は，バッテリーの問題や衛星の位置の関係から不安定である．
この課題に対して，災害時に各避難所を周る自治体の職員や災害ボランティアなどに情報を運んでもらうことで，避難所間の情報を流通させることを考える．自治体の職員や災害ボランティアは，被災地内外を往来するため，被災地で得た情報を外部に共有することが可能となる．また，通信の不安定性に対しては，通信が行えない時間帯の情報を集約しておき，再度通信が行えるようになった時に情報をまとめてアップロードする仕組みにより，解決を図る．この時，情報の取得やアップロードに手間や時間がかかると情報共有の妨げになるため，できるだけ簡易に実施できる方法を提案する．次章で，具体的な提案手法について述べる．

4 提案手法
本章では，提案システムの概要と各機能の詳細について述べる．

4.1 概要本提案手法では，災害時に通信が断絶された状況を想定してスマートフォンを持つユーザが情報を運ぶことで被災地全体の情報流通を実現する．全体の概要を
図 3 に示す．本システムは，「避難所における情報共有機能」，「データフェリー機能」，「通信回復時のデータ連携機能」の 3 つの機能で構成される．
「避難所における情報共有機能」では，避難所にエッジサーバを設置し，ローカルネットワークを構築することで，スマートフォンを持つユーザと情報共有を行う．
「データフェリー機能」では，ユーザの持つスマートフォンにエッジサーバから取得した情報を保存して移動し，別のエッジサーバと同期することで，被災地内外の情報共有を行う．
「通信回復時のデータ連携機能」では，避難所のエッジサーバに情報を集約することで，通信回復時にまとめてデータアップロードを行う．

通信回復時のデータ連携

クラウド
被災地から戻った時

・災害対策本部
衛星通信

⾞両中継機

避難所内の情報管理ü 被災者数オンライン(被災地外)

・NPO/NGOなどの⺠間組織

オフライン
（被災地）

⾃治体の職員や災害ボランティアなどが各避難所を周るü インフラの状態
ü 周りの被害の状況
エッジサーバ
サーバアクセス

避難所間のデータ同期

避難所

データフェリー

避難所における情報共有：⼈の動き：情報の流れ

図 3: 提案手法の概要

本提案は，将来的に災救マップにこれらの機能を追加することを想定している．災救マップは，既に避難者数やインフラの使用状況などを共有する機能を備えており，「避難所における情報共有機能」でエッジ版災救マップに蓄積された情報を，「データフェリー機能」や「通信回復時のデータ連携機能」でクラウド版災救マップに連携することを想定している．我々の提案は，提案する 3 つの機能を用いることで，インターネット断絶時においても災救マップを部分的に利用できるようにすることで，表 1 の「通信インフラ断絶時の使用」の評価を「×」から「△」にする提案となる．
また，本手法では，ブラウザ上のローカルストレージを利用することでデータの保存・アップロードを行う．
ローカルストレージは，ブラウザ上に取り扱うデータを保存する仕組みであり，一般的には，Web 上のサービスにログインした際のデータを保存して，次回訪問時には自動でログインできるようにするために利用される．Web 閲覧時の情報を保存できるという点では，ローカルストレージは Cookie と似ているが，ローカルストレージは取り扱えるデータ量がクッキーよりも大きく，必要な場合のみデータ送信を行えるという違いがあるため，ローカルストレージを採用している．

4.2 避難所における情報共有
避難所でユーザに情報を共有するまでのデータフローを図 4 に示す．エッジサーバは，Wi-Fi のアクセスポイ

ント (AP) を提供しており，ユーザはエッジサーバのア
クセスポイント (AP) にアクセスすることで，ローカルネットワークに接続する．Wi-Fi 接続後は，情報を取得するためにブラウザから特定の URL にアクセスして，Web ページを閲覧する．Web ページには，ユーザによる投稿機能もあり，ユーザが被災地の情報をアップロードすることで別のユーザが閲覧することが可能となり，避難所内の情報共有を実現する．
この Web ページの閲覧時に，ユーザがローカルストレージにデータを所有している場合は，閲覧と同時にローカルストレージのデータを自動的にアップロードする．また，Web ページで閲覧した情報の一部は，閲覧と同時に自動的にローカルストレージに保存される．
この情報のアップロードと保存を被災地全体のエッジサーバ間で繰り返すことで，次節で述べるデータフェリー機能を実現する．

4.3 データフェリー
被災地内外におけるデータフェリーのフローを図 5に示す．自治体の職員や災害ボランティアは，被災地外から被災地に移動して各避難所を周る．この時，自治体の職員らは各避難所のエッジサーバの Web ページを閲覧することで避難所の状況を把握する．同時に，Webページで閲覧した情報の一部はローカルストレージに保存される．
データフェリーは，ローカルストレージに情報を保被災者A

エッジサーバ

被災者BにアクセスAP

自治体職員など被災地へ移動

エッジサーバ

災害対策本部等

避難所内データの取得

提供

Wi-Fi

各避難所を経由にアクセス

AP

提供

被災地外へ帰宅Wi-Fiにアクセス

被災地で得た情報をアップロード

HP(https://test.com)

情報取得

ローカルストレージの情報をアップロード

支援物資の供給、救助

情報取得
ローカルストレージ保存

自治体職員など

投稿

エッジサーバクラウド

災害対策本部等

図 5: 被災地内外におけるデータフェリーのフロー

更新された情報を取得
ローカルストレージ保存

ドの情報を更新する．エッジサーバにクラウドとの接続機能を持たせておくことで，データフェリーおよびインターネット接続という二つの情報流通経路を確保できることとなる．にアクセス

HP(https://test.com)

ローカルストレージの情報をアップロード
情報取得
ローカルストレージ保存
被災者A

クラウド

エッジサーバ

被災者B

図 4: ユーザのデータ取得フロー存したまま，自治体の職員らが移動することで行われる．ローカルストレージは，特定のドメインに関連付けられたデータを保存するため，アクセスする URL が同じでないと共有できない．そこで，各エッジサーバにアクセスする URL を統一させることで，同じローカルストレージを共有できるようにする．
これを各避難所を経由して行うことで避難所間のデータ同期を行う．自治体の職員らが被災地から戻った際には，取得したデータをクラウドにある Web ページを閲覧することで，情報をアップロードして被災地内の情報を被災地外に共有する．これにより，災害対策本部などが被災地内の状況を把握して，適切な物資の供給や支援を行えるようにする．

5 プロトタイプシステムの実装
本章では，提案手法の動作検証をするために開発したプロトタイプシステム「災害情報マップ」及びその動作検証について述べる．

5.1 プロトタイプシステムの概要
プロトタイプシステム「災害情報マップ」は，図３で示した「避難所内の情報共有機能」と「データフェリー機能」の実装を行った．災害情報マップの画面を
図 6 に示す．災害情報マップは，災救マップを想定して作成しており，マップをベースとして災害時に利用される掲示板や重要情報表示の機能を備えた Web ページである．この Web ページを閲覧することで，投稿された情報が自動的にブラウザのローカルストレージに保存され，別サーバの Web ページを閲覧することで，投稿された情報が自動的にアップロードされる．

5.2 動作検証
4.4 通信回復時のデータ連携
被災地では，中継機の設置などにより一時的に外部との通信が可能となるが，安定して外部との通信を行うことは困難である．そのため通信インフラ断絶時にはエッジサーバに情報を蓄積しておき，通信が確立した際にはまとめてクラウドへ送信することで，クラウ検証の概要を図 7 に示す．本検証では，Raspberry Pi
4 Model B（以下，Raspberry Pi）を避難所に設置するエッジサーバと仮定し，検証を行なった．各エッジサー
バは別の部屋に設置し，ネットワークに繋がっていないため直接的な通信は行えない．Raspberry Pi には Wi-Fiでアクセスするためのアクセスポイント化の設定を行Server B

Server A① Wi-Fi接続して情報の取得（⾃動的にブラウザのローカルストレージにデータ保存）② 別の部屋へ移動

重要情報③Server Bにアクセスしてデータの同期を確認

マップ

図 7: 動作検証概要図
ServerA

ServerB

掲⽰板

ServerBのデータ更新

各避難所の情報

ServerAのデータをフェリー

図 6: 災害情報マップの画面い，情報を受発信できるようにしている．また，Webサーバは Flask を利用している．
詳細な手順を下記に示す．

1. ServerA から提供されている Wi-Fi にアクセスして，指定された URL から Web ページにアクセス（閲覧）．
2. ユーザは，ServerA の避難所情報の確認を行う．
同時に必要な情報をローカルストレージに自動保存．
3. ServerB のある別の部屋へ移動．
4. ServerB から提供されている Wi-Fi にアクセスして，指定された URL から Web ページにアクセス（閲覧）．
5. 投稿情報がフェリーされていることを確認する．
手順としては，スマートフォンから ServerA の Web ページを閲覧したのち，別の部屋にある ServerB の Web ペー
ジを閲覧することで，データフェリーができるか確認

ServerAとBのデータ同期

図 8: 動作検証結果を行った．この時，ユーザは「Web ページを閲覧する」という行動を行うだけで能動的に情報のダウンロードやアップロードの操作は行わない．
本検証の結果を図 8 に示す. ServerA で得た情報をローカルストレージに保存し，別サーバの ServerB のWeb ページを閲覧した結果，投稿情報の同期を行えたことを確認している. 本検証の結果からブラウザのローカルストレージを用いて，ネットワーク回線で繋がっていないサーバ間での情報共有を行えることが確認できた．

5.3 今後の展望
今後は，プロトタイプのマップ部分を災救マップに置き換え，図 3 の「データフェリー」と「通信回復時のデータ連携」部分の開発を行う．また，エッジサーバに保存される個人情報やどこまでの情報をエッジ版の災救マップで扱うかなど，セキュリティを含めた業

務要件についても今後検討していく．さらに，地域で行われる防災訓練で本システムを使用して性能評価を行う．

6 おわりに本稿では，災害時に通信インフラが断絶された状況
でも被災者に災害情報を提供するためのインフラレスな災害情報流通システムを提案した．本システムは，多くの人が利用するスマートフォンを利用して情報取得を行い，ブラウザのローカルストレージを利用することで，特別なネイティブアプリを用いずデータフェリーを実現する．今後は，検証システムの改善を行い，実環境での検証実験を行う.

参考文献[1] 最近の主な自然災害について（阪神・淡路大震災以降） : 防災情報のページ - 内閣府. https://www.bousai.go.jp/updates/shizensaigai/shizensaigai.html. (Accessed on 02/13/2024).
[2] 地震発生時の行動から生活再建までのポイント｜
東京都防災ホームページ. https://www.bousai.metro.tokyo.lg.jp/bousai/1000026/100564
2.html. (Accessed on 02/15/2024).
[3] 上杉昌也, 森山聡之, 小山和孝, 和田亨, 新山悠紀,
石本俊亮. 平常時からの地域防災に向けた現地散策型アプリの開発とその有効性の検証. 都市計画
論文集, Vol. 57, No. 3, pp. 1431–1438, 2022.
[4] J Jawahir, Dedy Prasetya Kristiadi, and S Sutrisno.
E-trip: Mobile application of map integrated forpost-disaster relief needs. IJISTECH (InternationalJournal of Information System and Technology),Vol. 5, No. 6, pp. 672–679, 2022.
[5] 稲場圭信, 川端亮, 王文潔, 小島誠一郎, 峯英一郎.
災害時の避難所情報共有システム「災救マップ」の活用. マルチメディア，分散，協調とモバイルシンポジウム 2022 論文集, 第 2022 巻, pp. 445–445,
jul 2022.
[6] 避難場所マップ - yahoo!天気・災害. https://crisis.yahoo.co.jp/map/. (Accessed on
08/25/2023).
[7] 地理院地図 / gsi maps｜国土地理院. https://maps.gsi.go.jp/#10/35.361616/138.733978/&base=std&ls=std&disp=1&vs=c1g1j0h0k0l0u0t0z0r0s0m0f0&d=m. (Accessed on 08/25/2023).

[8] スマホ de リレーとは. https://www.smart-relay.kke.co.jp/about. (Accessed on 07/17/2023).
[9] Muhammad Ashar, Hirohiko Suwa, YutakaArakawa, and Keiichi Yasumoto. Priority medical image delivery using dtn for healthcare workers
in volcanic emergency. Scientiﬁc Phone Apps andMobile Devices, Vol. 2, pp. 1–13, 2016.
[10] Edgar Marko Trono, Manato Fujimoto, HirohikoSuwa, Yutaka Arakawa, and Keiichi Yasumoto. Generating pedestrian maps of disaster areas through adhoc deployment of computing resources across a dtn.
Computer Communications, Vol. 100, pp. 129–142,
2017.
[11] 令和６年能登半島地震による被害状況等について（令和６年２月 16 日 14：00 現在）. https://www.bousai.go.jp/updates/r60101notojishin/
r60101notojishin/pdf/r60101notojishin_31.pdf. (Accessed on 02/18/2024).
[12] デジタルを活用した避難所情報の把握. https://www.pref.ishikawa.lg.jp/chiji/kisya/r6_1_13/1.html. (Accessed on 02/19/2024).