#洪水災害時における避難支援のためのオフライン3Dハザードマップの開発と評価
###1．序章
本章では背景，問題意識を明らかにするとともに，目的，研究意義について述べ，本研究の概要と構成について説明する．
###1．1本研究の背景
近年，自然災害が多発するなかで，市民の避難を適切にかつ安全に実施することは極めて重要な点である．特に洪水災害においては，2005年の水防法改正により浸水想定区域の指定を受けた市町村は市民に対して，洪水予測の公表が義務付けられた．また，2005年から2009年に洪水ハザードマップ作成に対する国庫補助制度が策定されたことを契機にハザードマップの普及は進んだ（榎村，2012）．各自治体のWebページにおいてpdfデータでハザードマップの提供，自治体が主導となり各世帯への紙のハザードマップの配布のみならず，国土地理院が国土交通省水管理・国土保全局と協力して提供する「国土交通省ハザードマップポータルサイト」等のWeb上でインタラクティブに災害情報を伝えるハザードマップも存在する（泉谷，2020）．Web媒体でハザードマップの閲覧が可能になることで，広域を網羅したハザードマップの作成，各レイヤ情報の表示・非表示が可能となり，多くの情報を盛り込んでもインターフェイスが雑多で見づらくならない，ピンチイン・アウトが可能となり詳細な地図情報を表示できるようになる等のpdf，紙媒体でのハザードマップの表現の限界を克服している．
###1．2本研究における問題意識
紙からWebに媒体を変えることでハザードマップの表現方法が豊かになる一方で，洪水被害が発生した際にはインターネットが断絶する事例が報告されている．2020年7月4日大雨の影響により熊本県球磨川が氾濫するなどして，死者・行方不明者が69人がでる被害が発生した（NHK，2023）．この大雨の影響で，停電，土砂崩れ等が発生し回線が断絶するなどして，22市町村でインターネットの接続が困難となった（総務省，2020）．また，回線が断絶するといった直接的な被害のみならず，大雨や洪水によって交通インフラが損傷し，インターネットサービスプロバイダー等の通信に関わる事業者の業務が中断されることで，インターネットサービスの提供に支障をきたすことを指摘する研究報告も上がっている（FeketeandAlexander，2019）．加えて，災害時には通信が輻輳し，インターネットに接続が難しくなる状況も発生する（増田，2012）．オフライン環境下では，従来の紙媒体での洪水ハザードマップの利用が想定されるが，避難所や浸水域等の情報を1枚の紙に集約しなくてはいけない都合上，インターフェイスが雑多になってしまうことや，配布されて時間が経過することによってハザードマップを紛失してしまう住民が存在するなどの課題がある（方田他，1999）（榎村，2012）． 洪水ハザードマップの役割の一つに発災時において市民が避難をする際のマニュアルとして機能することが挙げられる（片田他，2004）．「Google Maps」や「Maps．me」等のオフライン環境下であっても，スマートフォンで地図を閲覧できる機能を有したサービスはあるが，浸水深や浸水域の情報，避難所の位置情報，標高情報といった洪水被害の避難の際に避難者が認識するべき情報は有していないため，避難ルートを検討することが難しい．
###1．3．本研究の目的と研究意義
以上の背景を踏まえ，本研究の目的は洪水災害発生時のインターネットインフラが機能しない状況において，スマートフォンのブラウザアプリケーションを用いてアクセス可能な3D洪水ハザードマップシステムを構築し，避難者に危険地帯を認識させる手法を提案することである．
本研究を通して，洪水災害時のインターネット接続が困難な場合でも，避難者が危険地帯を把握し，適切な避難ルートの検討支援の一助となることを目指す．
###1．4．本研究の概要
本研究の目的は洪水災害発生時のインターネットインフラが機能しない状況において，スマートフォンのブラウザアプリケーションを用いてアクセス可能な3D洪水ハザードマップシステムを構築し，避難者に危険地帯を認識させる手法を提案することである．本目的を達成するためには，以下の2つの条件を満たす必要がある．
-検証1:オフライン環境下で適切にWebハザードマップを避難者に提供できるシステムであること -検証2:作成した洪水ハザードマップを通して避難者が危険地帯を把握できること
検証1では，オフライン環境において本システムの稼働可能時間とハザードマップ表示までかかる描画時間を検証した．調査2では参加者を集め，作成したハザードマップが洪水災害時における危険地帯の認識につながるかを検証した．検証1では避難想定時間を超えるシステム稼働時間が確保できることが確かめられると同時に，適切なスピードでWebページ描画を表示できることが示された．調査2本研究で作成したハザードマップが浸水予想域，低地，傾斜地を利用者に認識させることが可能であることが示された．これにより本目的は達成された．
###1．5本研究の構成
本論文の章構成を次に示す．「1-3．本研究の目的と研究意義」で述べた目的を達成するために，研究手法を4つに分けて説明する．手法の詳細は第3章「研究手法」で説明する．
序章では，本研究の背景と問題意識を明らかにし，研究の目的と意義を詳細に述べる．加えて，論文の全体概要と各章の構成について説明する． 第2章「関連研究・関連事例」では，洪水災害時におけるインターネット障害の実態と，ハザードマップの媒体の変遷について概説する．その後，オフライン環境で動作する地図システムおよびハザードマップの必要性に触れ，既存のオフラインWebハザードマップを概説した上で，その限界点を指摘する．さらに，これらの課題を踏まえた上で，本研究の指針を導き出し，リサーチクエスチョンを設定する． 第3章「研究手法」においては，本研究で開発したシステムの概要と，その構築に必要とされた4つの具体的な実装について説明する．以下の通り，「Raspberry Pi 4を用いたWebハザードマップ配信システム」，「複数レイヤーによる情報の可視化」，「異なるOSで利用可能なシステムの設計」，「標高情報の3D表現」にわけ，実装方法の解説を行う．第4章「検証」では，2つの検証を通じて，システムの耐久性と有効性を評価する．検証1では，オフライン環境下でシステムが避難予想時間に対して十分な稼働時間を保つこと，及び適切な読み込みスピードでハザードマップを表示できることを検証する．検証2では，参加者を用いて，洪水ハザードマップが浸水予想域，浸水予想深度，低地，傾斜地を適切に認識できるかを検証する．検証結果として，検証1ではオフライン環境下におけるシステム稼働時間が内閣府が定義する洪水災害時の避難予想時間を上回ると同時に，Google社が定義するWebパフォーマンスを測る指標に基づいて，本システムが適切な表示スピードでWebハザードマップを表示できることが確認された．検証2では参加者の7割が浸水予想域，浸水予想深度，低地，傾斜地をWebハザードマップを通じで知覚することができた． 第5章「結論」では，検証1と検証2の結果を基に，洪水災害発生時のオフライン環境下での本システムの機能性と，避難時におけるその有効性について考察する．その上で，研究の限界点を明らかにし，洪水災害時の危険箇所の認識における今後の課題を提示する．そして，本研究が持つ意義と将来の研究方向性について論じる．
##2．関連研究・関連事例
本章では，洪水災害時におけるネットワーク障害の実態について，オフライン環境下でのハザードマップに関する既往研究・先行事例を示し，本研究の位置づけを明らかにする．
###2．1．洪水被害地域における通信インフラ環境
本節では洪水被害環境下におけるネットワーク障害に関して，どのような事例が発生したのか，また既往研究についてを明らかにする． 2020年7月4日に熊本県に豪雨が発生し，死者・行方不明者が69人がでる甚大な洪水被害が起きた．岸川（2023）によると，本豪雨の影響により氾濫流と呼ばれる，家屋をも流してしまう大きい威力の濁流が発生するなど，氾濫地域に多くの影響を及ぼし，住居等のインフラを破壊したのみならず，通信インフラにも影響を及ぼしたことが報告されている．総務省（2020）によると，2020年7月4日の豪雨による停電，土砂崩れ等によって，被災地域の携帯電話基地局が停波した．最大影響時にはNTTドコモ社22市町村，KDDI（au）社15市町村，ソフトバンク社23市町村で電波障害が発生した．NTT西日本（2020）によると，インターネットサービス100回線でインターネット障害が発生したことが報告された．これらのことから，熊本豪雨では甚大なインターネット障害が発生し，オフライン環境が発生したことがわかる．洪水発生時には停電，土砂崩れ等の影響のみならず，2次的な影響によってインターネットが断絶または，通信インフラの復旧が長期化する懸念もある．甚大な洪水被害によって，交通インフラ等が機能が停止し，電力や通信インフラの従事者が通常業務を行うためやインフラ復旧のために現場に駆けつけることが難しくなり，定常業務および復旧作業を行うことが難しくなる状況が発生する（Fekete，2019）．このように，洪水被害は直接的または間接的に，インターネットインフラに影響を及ぼすことがある． 近年のスマートフォン普及によって，地図を閲覧する媒体は紙からデジタルへと変遷してきた．日常生活における地図利用において，紙地図の利用は減少傾向にあり，一方でデジタル地図の利用は増加している（株式会社ゼンリン，2018）．また，紙媒体でのハザードマップは紛失しやいことも看過できない問題である（関西大学社会安全学部，2014）．今後，紙地図の普及が増加する見込みは低い中で，洪水災害時のオフライン環境であっても，使い慣れたデジタル媒体でのアクセス手法を確立することは急務であるといえる．
###2．2オフラインで利用可能な地図サービス
インターネットが断絶した際に，紙媒体でのハザードマップはオフライン環境下で利用できる地図ツールとして有効である．ただ紙媒体であるがゆえに広い範囲をカバーしようとすると，紙のサイズを大きくする必要があり，携帯することが難しくなる．実際に自治体が配布するハザードマップのなかには，サイズが大きいため避難時に持ち運ぶには不便なものも存在する（榎村，2012）．ハザードマップは災害時において避難のマニュアルとして活用される．故に，避難の際に帯同が難しい形態であっては本来の目的を遂行できない．2．1で述べた通り，紙地図の利用は減少していくことが想定されていることから，オフライン環境であってもスマートフォン等のデバイスでデジタル地図を利用できることが求められる．このような背景を踏まえて本節では，既存のオフライン地図についての動向をまとめる． 2005年にサービスが開始されたGoogle Mapsは2022年には全世界におけるダウンロード数が10億件を超え，現代社会においては最も使われている地図サービスと位置づけられる（日経新聞，2022）．Google MapsはWebブラウザ，スマートフォン，タブレット端末に対応しており，インターネット接続を通じて地図を閲覧することができる．加えて，Google Mapsはオフライン環境下でも地図サービスの利用を可能としている．インターネット接続が遅い，利用できない環境を考慮して予め任意のエリアの地図情報を端末に保存し，オフラインで使用することができる（Google，2023）．オフライン環境でも事前に利用したいエリアを保存しておくことで，ルート検索，ナビゲーション機能，地名検索も行える．ただしオフライン状態であると，公共交通機関，自転車，徒歩の経路を表示することはできず，自動車のルートのみが表示される（図1）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/e932b838-f281-467c-bb6f-aaeb594259f7">
<palign="center"> （図1iOSアプリ版オフライン時におけるGoogle Mapsのナビゲーション画面）
Google Mapsはオフライン機能を有しているが，あくまでもサブ機能であり通常はインターネット通信を基本とした利用が想定されている．オフラインでの利用に特化したデジタルマップでいうと最も有名なサービスの一つとしてMAPS.MEが挙げられる．MAPS.MEは契約する通信キャリアが利用できない地域に旅行する人々をターゲットに広く使われており，執筆時で1億4000万ダウンロードされている（MAPS.ME，2024）．Google Mapsと同様に事前に任意のエリアをダウンロードすることで，オフライン環境下での利用が可能となる．MAPS.MEでもGoogle Mapsと同様にルート検索，ナビゲーション機能，地名検索が行える．加えて，MAPS.MEではオフライン環境下で自動車，徒歩，自転車に合わせたナビゲーションが行える（図2）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/0e0a9516-46b5-411d-8d7a-7d10fddfce2b">
<palign="center"> （図2iOSアプリ版オフライン時におけるMAPS.MEのナビゲーション画面）
Google MapsとMAPS.MEともにインターネット接続が困難な状態であっても，地図の提供が行えるシステムとなっている．これらのサービスはルート検索，ナビゲーション機能，地名検索が行える一方で，洪水災害の避難の際に必要となる浸水域の表示や避難所の表示は行えていない．上記2点のサービスは日常的な利用や旅行先での利用を想定しているため，洪水災害のシチュエーションには対応しているとは言い難い．洪水災害発生時においては，浸水域，斜度のある地域，標高が低い地域等の把握が重要となる（日本気象協会，2021）．これを踏まえ次の節では，オフライン環境でかつ災害時の避難に必要となる地図の提供に対して取り組む既往研究を挙げ，オフラインハザードマップの現状を整理する．
###2．3．オフラインハザードマップの先行研究
2．2で論じた通り，洪水災害時のインターネット接続が困難な場合においてデジタルなハザードマップへのアクセスを確立することは急務である．本節では災害時のオフライン環境下におけるハザードマップ及びオフライン地図の先行研究を紹介するともに，既往研究における課題を整理する．災害時のオフライン環境でのハザードマップ利用を可能とするものとして，オフライン対応型災害時避難支援システム「あかりマップ」が挙げられる（吉野ほか，2017）．「あかりマップ」は災害時のオフライン環境での稼働に特化した災害時避難支援システムである．このシステムはAndroidが搭載されたスマートフォン端末でのみ利用することができ，災害が発生する前に利用者が自身の端末に地図情報，避難支援情報をダウンロードすることを想定している（図3）． 事前にダウンロードされた情報は，災害が発生し通信網が利用不可能になった場合でも，利用者が端末上でアクセスできるようになっている．端末上で表示される情報には，浸水域，避難所の位置，AED（自動体外式除細動器）の設置場所，コンビニエンスストアの場所，自動販売機の設置場所が含まれ，これらの情報はオフライン状態でも参照可能となっている．また，利用者にデバイスの電池残量を意識させるため，画面上部に電池残量を示すバーが設置されている．「あかりマップ」は2．2で指摘した課題を克服し，オフライン環境下で激甚災害の避難において重要な情報を提供できる設計になっている．一方で，オフラインで活用可能な洪水ハザードマップとしては3つの課題が存在している．1つ目は特定オペレーティングシステム（以下OSという）に依存している点である．「あかりマップ」はAndroidを搭載したスマートフォンのみで利用することができ，他のOSでの利用が不可能な設計になっている．2点目はユーザーによる事前のダウンロードが必要な点である．2．1で述べた通り，洪水被害発生時にはインターネットに接続することが難しい場合が生じる．ユーザーが地図情報，避難支援情報を事前にダウンロードしていない場合，「あかりまっぷ」を利用することができない．3つ目は標高に関する情報が地図上で確認できない点である（図4）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/2f32189f-7727-4009-8304-fcc726a80f48">
<palign="center"> （図3あかりマップのシステム図．吉野ほか『災害時支援システム“あかりマップ”の地域住民による防災マップ作成への適用』から引用）
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/2f256f20-1c0f-4e11-a8d9-5f28844bea39">
<palign="center"> （図4あかりマップの表示画面．吉野ほか『災害時支援システム“あかりマップ”の地域住民による防災マップ作成への適用』から引用）
「あかりマップ」はベースマップとしてOpenStreetMapとGoogle Mapsの地図データを利用している．ベースマップ上には等高線や陰影起伏図といった標高を明示する情報は含まれていない．洪水災害における避難の際には，水の流れが早くなる傾斜地および，アンダーパスや地下街などの低地は危険地帯とされている（日本気象協会，2021;国土交通省河川局，2010）．傾斜地，低地を特定するには標高情報が必要となり，標高情報が掲示されていない「あかりマップ」ではオフライン環境で扱える洪水ハザードマップとしての機能を満たしているとは言えない．次節では洪水ハザードマップにおいて，どのように標高情報が提示されているかを整理し，オフライン洪水デジタルハザードマップに適した標高データの可視化方法を検討する．
###2．4．洪水ハザードマップにおける標高表記について
洪水ハザードマップは浸水予想域等の危険地帯を表示することで，市民に対し洪水被害の危険性を訴求する役割を持っている．ただし，ハザードマップに表示されている浸水想定はシナリオの一つに過ぎない．これを超える洪水災害があることを避難者は理解し，災害時においてはあらゆるシナリオを想定して避難しなければならない（片田ほか，2004）．水が氾濫した際にどこに水が溜まりやすいのか，どこが傾斜地で水の流れが速くなると想定されるかを地図から把握できれば，避難シナリオの検討が行える．言い換えると，標高情報がないと水の溜まりやすい地域や流水の速度を検討することが難しくなる．従来のハザードマップで表示されるものは浸水深のみである場合が多く，そこから流水を検討することが難しい．故に，避難者は流速については考慮せず，浸水深の浅い地域のみに着目し，その他の地域に関しては関心を失う懸念がある（片田ほか，2011）．標高情報が掲載されているものでも，従来のハザードマップでは等高線や高さの数値を直接記入することで，標高情報を提示している（図5）（図6）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/20e0a76e-e30a-4b21-b1f7-aa38f89b9a8a">
<palign="center"> （図5大阪府池田市内洪水ハザードマップ令和4年3月版から引用）
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/f7185c52-25f9-442c-8228-65f8fb5078b3">
<palign="center"> （図6文京区水害ハザードマップ令和5年3月版から引用）
こういった等高線や標高数値を地図に直接記述する表現は，ハザードマップのインターフェイスを煩雑にさせ，他の情報が視認しづらくなる問題がある．関谷・田中（2001）によると，住民からはよりシンプルで視認し易いハザードマップが求められていることが報告されている．これを踏まえ，インターフェイスを煩雑にさせない標高表現が求められていることがわかる．本研究では，３D表現を用いて標高を表現することで，低地および傾斜地の認識を促す手法を採用した．具体的な実装方法や検証については「3．提案手法」，「4．実験・検証」で論じる．
###2．5．本研究の指針
本節では，2．1から2．4で整理した既往研究，先行事例を踏まえ課題点を整理する．その後，本研究におけるリサーチクエスチョン，仮説，研究目的をまとめ，研究の指針を定める．
これまで，洪水時に発生するインターネット障害について，オフライン地図の先行事例，オフラインハザードマップの先行研究，ハザードマップにおける標高表示について論じ，課題を整理した．これらを踏まえ本研究におけるシステムに要求されるものは，以下の3点にまとめられる．
・利用者がデータの事前ダウンロードを必要としないオフラインハザードマップシステムの構築 ・特定OSへの依存がなく，多様なOSに対応したシステム設計 ・洪水災害の避難の際に危険地帯を検討する上で必要となる標高情報の表示
上記の課題を踏まえた上で，本研究のリサーチクエスチョンとそれに対する仮説を次のように設定する．
・リサーチクエスチョン1:利用者による事前のデータダウンロードを必要とせず，多様なOSに対応し，かつ洪水時の危険地帯を認識を支援する標高情報を効果的に表示できるオフライン洪水ハザードマップシステムは，どのように設計し実装することが可能なのか．
・リサーチクエスチョン2:本システムを活用することで，洪水災害時の避難においてどのような変化が起こるか．
・リサーチクエスチョン1に対する仮説:Raspberry Pi 4 Model B（以下Raspberry Pi 4という）を活用して，アクセスポイントおよびWebサーバーとして機能する地図システムを開発する．このシステムは，Raspberry Pi 4に格納されたハザードマップデータを，Wi-Fi通信を用いてイントラネット環境内で配信できるようにし，オフラインでもWebベースの洪水ハザードマップを利用者のスマートフォンを介して提供する．また，国土地理院が公開する標高情報と，オープンソースの地図ライブラリであるMapLibre GL JSを組み合わせることで，標高情報を3D表示し，ユーザーが地形の高低差を直感的に理解できるようにする．これらのアプローチにより，多様なOSに対応し，洪水時の危険地帯である低地と傾斜地を利用者に認識させるオフラインハザードマップシステムの実現を目指す．
・リサーチクエスチョン2に対する仮説:3D表現を用いた可視化により，低地と傾斜地の認識が可能になり，浸水予測と予想深度に加え，高さ情報を意識した避難ルートの検討を行うようになる．
本節で設定したリサーチクエスチョンを検討する具体的な手法については第3章「提案手法」にて論じる．
##3．提案手法
###3．1本研究で行った実装
本章ではまず，本研究で提案するオフラインで稼働するWeb洪水ハザードマップのシステム概要及び運用フローについて述べる．次にシステムを構築するにあたり行った7つの実装について論じる．
###3．1．1システムの概説
本節では，本システムの概要について論じる．本研究では，低コストでありながら高い汎用性と拡張性を持つマイクロコンピューターであるRaspberry Pi 4を用いた地図サーバーの構築を試みた（図7）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/e22dd171-40fe-4226-9aed-2455d09a76ee">
<palign="center"> （図7Raspberry Pi 4ModelB本体画像．Raspberry Pi公式Webページ『BuyaRaspberry Pi 4ModelB–Raspberry Pi』から引用．URL:https://www.raspberrypi.com/products/raspberry-pi-4-model-b/）
Raspberry Piは教育や研究，趣味のプロジェクトなど，多岐にわたる分野で使用されているマイクロコンピューターである（Raspberry Pi Foundation，2021）．各種ソフトウェアをRaspberry Pi 4にインストールさせ，アクセスポイントとして機能させることにより，Raspberry Pi 4を基点としたイントラネットを構築し，オフライン環境下でもスマートフォンを通じてアクセス可能な地図サーバーとしての役割を果たすよう設定した．アクセスポイントとは，ワイヤレスネットワークにおけるデバイス間の通信を仲介する装置のことを指す．Raspberry Pi 4のアクセスポイント化に関する具体的な実装方法は「3．2．1．Raspberry Pi 4を用いたWebハザードマップ配信システム」で述べる．利用者はRaspberry Pi 4のイントラネットにアクセスすることで，オフライン環境下であってもスマートフォンのブラウザアプリケーション上で洪水ハザードマップを閲覧することができる．また，洪水災害時の避難時における本システムの持ち運び性能を上げるために，3Dプリンターを用いてハードカバーを作成した．図5の通り，Raspberry Pi 4単体だと基盤がむき出しの状態であり持ち運びには適していない．そこで，Webサイト「きっと何かに役立つでしょ！？」においてCCBY-NC-SA4．0ライセンス下でstl形式で公開されているRaspberry Pi 4のケースのデータを活用した（2020，きっと何かに役立つでしょ！？）．上記のデータを用いて3Dプリンタでケースを作成し，Raspberry Pi 4を持ち運びしやすい形にした（図8）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/01ed58df-27fd-4c93-b80f-44a7636889e6">
<palign="center"> （図8Raspberry Pi 4のケース）
本節を踏まえて，次節ではシステムの構成について述べ，具体的な利用フローを明らかにする．
###3．1．2システムアーキテクチャ
本節ではシステム構成を示した後に，洪水災害時のオフライン環境下で本システムの運用フローについて述べる．まず，本システムのアーキテクチャーを図9に示す．
<palign="center">
<imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/1faa8025-ab91-4a47-aad8-91b697aeed67">
<palign="center"> （図9システムアーキテクチャー図）
Raspberry Pi 4を稼働させるため，本システムではモバイルバッテリーを用いた給電を想定する．加えて，Raspberry Pi 4の給電ポートがタイプCであるため，タイプCで給電可能なモバイルバッテリーを前提とする．給電されたのち，Raspberry Pi 4のアクセスポイントとWebサーバーが立ち上がり，ハザードマップの配信準備が始まる．アクセスポイントが立ち上がるとスマートフォンのWi-Fi選択欄に，Raspberry Pi 4のSSIDが表示される（図10）．本検証においては"dronebird"というSSID名を設定している．利用者はSSIDを選択し，自身のスマートフォンとRaspberry Pi 4を接続する．
<palign="center"> <imgwidth="430"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/dd245e1e-8406-4761-be3a-b8ae16fe0921">
<palign="center"> （図10Wi-FiのSSID選択画面）
スマートフォンとRaspberry Pi 4の接続が完了した後，Raspberry Pi 4の中に格納されているハザードマップにアクセスするために，Raspberry Pi 4に格納されているHTMLファイルのURLにスマートフォンのブラウザアプリケーションを通じてアクセスする．本検証ではハザードマップのURLを「 http://172.16.0.1 」とした．SSIDの設定及びハザードマップのURLの設定についての詳細は「3．2．1．Raspberry Pi 4を用いたWebハザードマップ配信システム」にて述べる．URLにアクセスした後，利用者はスマートフォンで洪水ハザードマップを閲覧できるようになる（図11）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/b29d78b6-9ba5-4fc2-8e94-5c670f543dab">
<palign="center"> (図11スマートフォンに表示される洪水ハザードマップ)
ハザードマップの性質上，スマートフォンの扱いに慣れている人も慣れていない人も利用することが想定される．スマートフォンを使い慣れていない人々にとっては，スマートフォンのWi−Fi選択欄からRaspberry Pi 4のSSIDを選択し，後にブラウザ上でURLを打ち込む操作が困難であることが想定される．このことから，Raspberry Pi 4への接続および，ハザードマップのURL検索を簡略化させた．具体的には，QRコードを作成しそれをスマートフォンのカメラで読み込むことにより，Raspberry Pi 4への接続および，ハザードマップのURLの検索を完了させる実装を行った．これを踏まえ，次に本システムの運用フローについて述べる．まず，本システムの利用フロー図を図12に示す．
<palign="center">
<palign="center"> (図12システム利用フロー図)
利用者はRaspberry Pi 4に給電を行ったのち，Raspberry Pi 4の背面にある「①スキャンしてスマートフォンとサーバーを接続」と書かれたQRコードをスマートフォンのカメラでスキャンをする．スキャンを行うことでスマートフォンとRaspberry Pi 4が自動的に接続される（図13）． 次にRaspberry Pi 4の背面にある「②スキャンしてハザードマップをハザードマップを表示」のQRコードを読み込むことで，スマートフォンにインストールされているブラウザアプリケーションが自動で立ち上がり，Raspberry Pi 4に格納されているHTMLファイルのURLに接続され，ハザードマップが閲覧可能となる（図12）．QRコードを媒介にしたアクセス手法を実装することで，SSIDの選択及びURLを打ち込む操作を簡易化させた．QRコードの作成に関する詳細は「3．2．1．Raspberry Pi 4を用いたWebハザードマップ配信システム」と「3．2．2．多様なOSに対応したシステム設計」で説明する．次節以降では，具体的なRaspberry Pi 4に施した実装と洪水ハザードマップの作成手法について述べる．
<palign="center">
<palign="center"> （図13Raspberry Pi 4の背面に貼られた2種類のQRコード）
####3．1．3．Raspberry Pi 4を用いたWebハザードマップ配信システム
本節では，Raspberry Pi 4を基調に構築した，オフライン環境下でのハザードマップを配信するシステムについて述べる．はじめに，本システムに利用したRaspberry PiOSについて述べ，最後にRaspberry Pi 4をアクセスポイント化及びWebサーバー化させた実装について論じる．Raspberry Pi 4はOSがインストールされたSDカードをRaspberry Pi 4本体に差し込むことで稼働させることができる．Raspberry PiのOSはRaspberry Pi財団が公式でリリースしている「Raspberry PiImager」を用いることでインストールすることができる．本研究では，"RaspbianGNU/Linux11(bullseye)"をOSとして採用した（図14）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/1f99a40c-6573-4ede-81c2-67902892e141">
<palign="center"> （図14Raspberry Pi 4にインストールしたOSの詳細）
次にRaspberry Pi 4のアクセスポイント化とWebサーバー化の実装について述べる．本研究ではRaspberry Pi 4をアクセスポイント化させ，イントラネットを構築すると同時に，Raspberry Pi 4内にWebサーバーを立ち上げることで，オフライン環境下でもスマートフォンのブラウザを通じてハザードマップにアクセスできるシステムを構築した．本システムは，Apache2，hostapd，dnsmasqと呼ばれる三つのオープンソースソフトウェアパッケージにより構成される．Apache2は世界で最も普及しているWebサーバーソフトウェアの一つであり，ユーザーリクエストに応じてWebページや画像，その他のデータを配信する機能をRaspberry Pi 4に提供する．これをRaspberry Pi 4内に構築することで，Webサーバーとして機能させることができる．hostapdは無線LANデバイスをアクセスポイントとして機能させるためのソフトウェアであり，Raspberry Pi 4に接続されるスマートフォン等の各デバイスの管理を担う．hostapdインストール後，hostapd配下（/etc/hostapd/）にhostapd．confを作成し，以下の記述を行うことで，Raspberry Pi 4のWi−Fi接続時に求められるSSID，パスコード等を設定する（図15）．また，Wi-Fiに接続するためのSSID，パスコードをQRコード化することにより，スマートフォンのカメラでQRコードをスキャンするだけでRaspberry Pi 4に接続が可能となる（図13）．利用者が仮にSSID，パスワードを忘れる等の事態が発生してもハザードマップにアクセスすることができる設計にした．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/72ac21ac-fb03-4425-8a13-78456f4b2dd7">
<palign="center"> （図15hostapd．confに記述した内容）
dnsmasqは，ネットワーク上のデバイスに対してDNSサーバーの役割を果たし，動的にIPアドレスを割り当てる機能を提供するともに，ホストデバイスであるRaspberry Pi 4に対して固定IPを付与する．また，dhcpcd．confと呼ばれるファイル（/etc/dhcpcd．conf）に対して下記の記述を追記することにより，Raspberry Pi 4に対して固定IPを付与することができる（図16）．本検証では固定のIPを172．16．0．1に設定した．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/8e5ff368-201c-4a15-a6f2-24cc3ba02328">
<palign="center"> （図16dhcpcd．confに記述した内容）
固定のIPを設定することにより，洪水ハザードマップにアクセスするためのURLが決定する．本検証では「 172.16.0.1 」を固定IPと設定したので，「 http://172.16.0.1 」がハザードマップのURLとなる．これらのパッケージを組み合わせることで，Raspberry Pi 4を基点にしたイントラネットを構築し，オフライン時においてスマートフォンのブラウザアプリケーションを通じて地図データを提供することが可能となった．
####3．1．4．多様なOSに対応したシステム設計
「2．3．オフラインハザードマップの先行研究」で述べたように，既往研究で示されたオフラインデジタルハザードマップにおいては，特定OSでのみ利用が可能となっている．これにより，特定のプラットフォームやデバイスを利用している人のみがハザードマップにアクセスできる状態になっており，対応OS以外を使っている場合，ハザードマップにアクセスすることができない．この問題に対処するために，本研究ではOSに依存しないブラウザベースの描画方法を採用した．既往研究では，アプリケーションベースでハザードマップを配信していたため，特定のプラットフォームに依存せざるを得ない状態になっていた．ブラウザアプリケーションを通じてハザードマップを描画することで，特定OSへの依存を解消した．本システムはFirefox，Chrome，Safariといった主要なウェブブラウザに対応しており，ユーザーがどのようなOSを使用していても，どのようなスマートフォンを持っていても，同様のアクセス体験を提供する（図17）．ブラウザアプリケーションからの表示方法を実践することで，洪水災害時のオフライン環境において，様々なOSに対応したハザードマップ閲覧手法を確立することができる．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/d9cdedac-9f33-488e-9f06-8d709d4fcc84">
<palign="center"> （図17各種ブラウザアプリケーションからのアクセス）
利用者はブラウザの検索窓にRaspberry Pi 4から配信されるハザードマップのURLを入力することで，閲覧が可能となる．本システムのURLはドメイン名ではなくIPアドレスで表記されているため，入力ミス，URLを忘れる等のヒューマンエラーが起きやすいと想定される．このような背景から事前にURLをQRコード化させ，スマートフォンのカメラで読み込むだけでブラウザにURLが自動入力されアクセスできる手法を確立した．「3．1．2システムアーキテクチャ」でも述べた通り，QRコードによるアクセス手法を確立することで，URLを検索窓に入力してアクセスする手法よりも，ハザードマップ表示へのハードルを低くすることができた．
####3．1．5．洪水ハザードマップの視認性を向上
洪水ハザードマップは平常時に事前に準備しておくことが記載された"防災教育型"と災害時における避難に活用が想定される"避難型"に大別できる（谷垣内，2005）．本システムで表示するハザードマップは"避難型"であり，洪水災害発生時の避難を支援する目的で作成した．利用者に適切な避難を促す使いやすく，見やすいハザードマップを作成するには，文字数はできるだけ少なくシンプルに，避難所等のランドマークを目立たせその他の情報はできるだけ厳選することが求められる（関谷・田中，2008）．上記を踏まえ本システムで表示するハザードマップでは，文字情報の表示と図のシンプル性と情報の重要度を考慮したデザインを施した．本節では，作成したハザードマップデザインの工夫点について論じる．
まず，文字数に関しての工夫点を述べる．文字数を減らしシンプルなデザインにすることが見やすいインターフェイスの条件ではあるが，凡例の説明や避難所の名称等においては詳しく書かざるを得ない．これを考慮し，レイヤーの表示・非表示機能を使うことでハザードマップの表記と説明文を共存できるようにした．凡例部分では，まず洪水災害時に危険箇所とされる，浸水域，低地，傾斜地を避けるように促す警告文を赤背景に文字色を黄色にすることで目立たせて表示した．下部には浸水深の凡例と避難所の説明を記述した．凡例部は左上に位置する「閉じる/開く」ボタンをクリックすることで，表示と非表示が切り替えられる（図18）．利用者がハザードマップの浸水域や避難所を閲覧する際には，凡例部分を非表示にすることで，表示情報が煩雑にならなくなる．レイヤー機能を追加し，表示と非表示を任意に切り替えることで文字数とインターフェイスの煩雑性の問題を克服した．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/db6d2540-615a-495e-b563-f190de71c0dd">
<palign="center"> （図18凡例部分の表示と非表示の切り替え）
次に，洪水ハザードマップに掲載する重要情報を目立たせるために行った工夫について述べる．避難時に重要となる浸水予想域，浸水予想深度及び避難所を目立たせるために，ベースマップの配色に注目した．ベースマップをモノクロを基調としたカラーリングにすることで，浸水情報を青系統，避難所を赤にすることで，ベースマップの視覚的なノイズを減少させ，重要な情報をより際立たせることが可能となった（図19）．ベースマップの配色を作成するにあたり，（地理院地図Vector（仮称），2020）を参考にした．また，避難所のポイントをクリックすることで，避難所名，エレベーターの有無，避難スペースが1回にあるか，スロープの有無，点字ブロックの有無，多様性に配慮したトイレの有無，備考を表として確認することができる（図20）．これらの情報を活用することで，体の不自由な方や高齢の方がいた場合に，避難所のステータスを確認した上で避難先を検討することができる．右上のバツ印をクリックすることで，凡例部分と同様に表示と非表示を切り替えることができる．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/e3aa9ed5-ce56-4fbc-b176-372b55b28802">
<palign="center"> （図19ベースマップと避難時に必要となる情報のコントラストを示した図）
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/fc9158a9-6241-4a9d-bb3f-fde3a3952724">
<palign="center"> （図20避難所の詳細表示）
本ハザードマップでは，洪水災害時の避難において重要となる標高の可視化も行った．標高表示は従来の等高線や標高数値を記載する手法ではなく3D表現を用いて，低地や高地，傾斜地の認知を促した．次節では標高の3D表現の実装理由と実装手法について述べる．
####3．1．6．標高情報の3D表現
洪水災害発生時において，水の流れが速くなる斜度のある地域，水が溜まりやすい低地の把握は重要である（日本気象協会，2021）．斜度および低地を把握するには，標高情報が必要となる．従来のハザードマップは等高線を記載することで土地の高さをハザードマップで表現している（国土交通省水管理・国土保全局河川環境課水防企画室，2019）．一方で等高線はその性質上，大量の線を記載する必要があり，ハザードマップのインターフェイスを煩雑にし，視認性を悪くしている．この課題を踏まえて，本研究では標高情報を3D表現することで利用者に低地や高地，傾斜地の訴求を試みた．本節では3D標高の可視化表現の概説とその実装方法について論じる．まず，本ハザードマップにおける標高の3D表現部分について図21で示す．3D表現を行うことで，高地の部分は盛り上がり，低地の地域は凹んで表示され，立体的に視認できるようになる．また，陰影起伏図を追加し低地と高地に陰影を付けることで，立体感をより引き立てることができる．陰影起伏図とは，太陽の位置を仮定し，地形による陰影を表現することで起伏を視覚化する手法である．標高情報は国土地理院が公開する標高タイル（基盤地図情報数値標高モデル）のDEM10Bを利用した．DEM10Bとは写真測量によって図化された1/25，000地形図の等高線（10m間隔）から作成され，標高精度が5m以内となっているデータのことを指す．同様に，陰影起伏図も国土地理院が公開する陰影起伏図（データソース:標高タイル（基盤地図情報数値標高モデル））を利用した．上記のデータを踏まえて，オープンソース地図ライブラリMapLibre GL JSを用いて標高の3D表現を行った．
等高線表示とは違い，ハザードマップのインターフェイスを煩雑にすることなく，標高を表現することができた．実際に3D表示にすることで洪水災害発生時の危険地帯とされる低地，傾斜地の認識を利用者に訴求できているかについては，「4．実験・検証」で論じる．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/114c0807-51af-4269-88bd-8c2b6345084f">
<palign="center"> （図213D標高に陰影起伏図をオーバーレイした表現）
本研究ではオープンソースライブラリのMapLibre GL JSを用いた標高情報の3D表示を行った．標高情報は洪水被害発生時，土地の高低差や傾斜地の認識が安全な避難行動に直接関連するため，これらの情報を直感的かつ明瞭に伝える方法を確立することが求められている．従来のハザードマップでは，標高情報が等高線等によって表現されることが多いが，この表現方法は一般市民にとって理解しづらいという課題があった．特に，地図上での低地と高地，急傾斜地を直感的に識別することは困難であり，実際の避難行動において適切な情報提供がなされていない問題点がある．本研究では，3D地図機能を導入し，標高や傾斜の情報を視覚的に捉えやすい形で表現することにより，ユーザーが低地や高地，傾斜地を容易に識別できるようなインターフェイスを開発した．3D表示により，等高線だけでは把握しづらい地形の起伏や傾斜度を，ユーザーが直感的に理解できるようになる．従来の2D地図による表示では実現できなかった，地形の微細な変化を視覚的に捉えることが可能となった．実験当初はヒルシェード（陰影起伏図）機能を利用した高度情報の表示を行っていた．ヒルシェードとは，太陽の位置を仮定し，地形による陰影を表現することで起伏を視覚化する手法である．しかし，実証実験および指導教員のフィードバックを通じてヒルシェード（陰影起伏図）に馴染みのないユーザーにとってここから，高さ情報を理解することは難しいことがわかった．このフィードバックを踏まえて，より直感的な理解を促進するため3D機能へと移行した．国土地理院が提供する高精度な標高データを利用することで，3D地図上での地形表現は正確なものとなり，現実の地形に即した情報を表示できるようになった．
##4．実験・検証
##4．1検証の概要
本研究の目的は洪水被害発生時におけるオフライン環境において，避難者自身のスマートフォンのブラウザアプリケーションを通じて避難ルートを検討するための情報が掲載された洪水ハザードマップを閲覧可能とするシステムの提案をすることである．本目的を達成するためのシステム構築については「3．提案手法」で述べた．本章では構築したシステムが，洪水災害時を想定したオフライン環境下において，本研究の目的を満たすかどうかを検証する．本検証は以下の2つに分けて行われる．
-検証1:オフライン環境下で適切にWebハザードマップを避難者に提供できるシステムであることの検証 -検証2:作成した地図デザインを通して避難者が危険地帯を把握できることの検証
検証1では，オフライン環境において本システムの稼働可能時間とハザードマップ表示までかかる描画時間を検証する．避難の際にシステムの稼働可能時間が避難想定時間よりも短い，またハザードマップの表示に時間を要するようではシステムの可用性を満たしているとは言えない．このことから，本システムには避難想定時間を上回る稼働時間と，スムーズにハザードマップが閲覧できることが求められる．これを検証するために，内閣府が定義する洪水災害時の避難予想時間を閾値に設定し，これを上回る稼働時間が確保できるかを検証した．次いで，Google社が定義するWebページのパフォーマンスを評価する指数を複数用いて本システムにおけるハザードマップの表示スピードを計測した．調査2では参加者を集め，標高を3D表示し，陰影起伏をオーバーレイさせた地図デザインが，洪水災害時の危険地帯である低地と傾斜地を認識させるかを検証した．10人の参加者に対して，2Dの標高表現と陰影起伏を加えたハザードマップと3Dの標高表現と陰影起伏のハザードマップを見比べて3D表現の効果を分析した．検証1では避難想定時間を超えるシステム稼働時間が確保できることがわかるとともに，Webページのパフォーマンスを測る指数において，最上位の基準を満たす地図描画が可能であることが計測できた．調査2では本地図デザインが洪水災害において危険地帯とされる，低地，傾斜地を認識させることが可能であることが示された．本章では検証1を「4．1．システム稼働時間とページ表示スピードの計測」で，検証2を「4．2．3D標高表現に関するユーザビリティ評価」で論じる．
###4．2．システム稼働時間とページ表示スピードの計測
本節ではシステムの可用性を確かめるため，システムの稼働可能時間の計測と，ハザードマップの描画スピードの測定を行う．
####4．2．1システム稼働時間の計測
本システムが洪水災害時の避難において十分な稼働時間を確保できるかを検証する．内閣府防災情報（2018）が定義する洪水災害時の避難に要する想定時間を閾値に設定し，本システムがそれを超える稼働が可能かどうかを確かめる．内閣府防災情報（2018）では荒川と江戸川による浸水被害のシュミレーションを行い，江東5区（墨田区・江東区・足立区・葛飾区・江戸川区）における避難者を178万人と定義し，避難者の9割が避難完了する時間を約17時間と推定した．本検証ではこれを閾値に設定し，システムがこの閾値を超えて稼働可能かを検証する．はじめに，本検証における概略図を示す（図22）．本システムはモバイルバッテリーを用いた給電を想定する．加えて，Raspberry Pi 4の給電ポートがタイプCであるため，タイプCで給電可能なモバイルバッテリーを用いた稼働を前提とする．モバイルバッテリーとRaspberry Pi 4の間に電圧・電流測定器を設置し消費電力を計測した．なお計測器には，ルートアール社のRT-TC5VABKを用いた．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/dcacc716-c555-4be2-b2eb-80413163d689">
<palign="center"> （図22 システム消費電力の計測の構成図）
本検証ではシステムに対し，約28時間の通電を行い消費電力を計算したところ，1時間あたりの消費電力は2.435Wとなった（図23）．一般的に販売されているモバイルバッテリーにはリチウムイオン電池が使われており，その定格電圧は一般的に3．7Vであることから，この数値をモバイルバッテリーの電圧と定義する．これを踏まえてシステムの稼働時間を計算すると，10000mAのモバイルバッテリーで1232分（20時間32分）稼働できることがわかる．以上により，本システムは避難時において，十分な稼働時間を確保できるものであるということが確かめられた．
<palign="center"> （図23消費電力の計測*作成中）
####4．2．2．ハザードマップの描画スピードの計測
本検証ではシステムから配信されるハザードマップの表示スピードの評価を行う．検証を行う上でGoogle社が定義するWebパフォーマンスを計測するための，FirstContentfulPaint（FCP），LargestContentfulPaint（LCP），TimetoInteractive（TTI）と呼ばれる3つの指標を用いる．FCPは，ページの読み込みが始まってからテキストや画像などのコンテンツが画面上に初めて表示されるまでの時間を測定し評価する尺度である．1．8秒未満が良好，1．8秒以上3．0秒未満が要改善，3．0秒以上が不良と定義される（Walton，2023）．LCPとはウェブページの読み込み性能を測定する尺度で，ページが読み込まれてからサイトのメインビジュアルやテキストブロックが画面に表示されるまでの時間を示す．LCPを用いることで，ユーザーがページの主要な内容をどの程度の速度で見ることができるかを示し，ユーザー体験の質を評価することができる．2．5秒未満は良好，2．5秒以上4秒未満は要改善，4秒以上は不良と定義される（Walton・Pollard，2023）．TTIとはWebページが最初にロードされた後，ページが完全にインタラクティブになるまでの時間を計測する指標である（Walton，2023）．これは，ページが表示されてからユーザーが完全にページをインタラクティブに操作できるようになるまでの時間を示す．0秒から3．9秒未満が高速とされ，3．9秒以上7．3秒未満が中速，7．3秒以上は低速と定義される．各指標とその評価軸について表1にまとめる．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/66b63231-7e23-4082-93f3-4108d06d28ef">
<palign="center"> （表1FirstContentfulPaint（FCP），LargestContentfulPaint（LCP），TimetoInteractive（TTI）の評価表）
本検証を行うにあたり，図24の環境で計測を行った．Raspberry Pi 4に給電を行い，イントラネット内で3台のスマートフォンと1台のラップトップPCにハザードマップを配信している状態での計測を行った．なお，Raspberry Pi 4と4台のデバイスは1．7mの距離を保った状態で計測した．本計測は，夫婦と未婚の子供2人の核家族世帯が避難する場面で，計4台デバイスで接続することを想定している．計測はラップトップPC（MacBookPro13-inch，M1，2020チップAppleM1メモリ16GBmacOSVentura13．3．1）上でGoogle Chrome（119．0．6045．199（OfficialBuild）（arm64））のPerformance Insightsの機能を用いて計測した．Performance Insightsはネットワークの接続状況と利用するCPUの性能を予め設定した上でFCP，LCP，TTIの計測を行える．これらを設定することにより，任意の接続環境及びCPUスペックを指定して値を出すことができる．本検証では，Raspberry Pi 4のネットワークを利用するため，ネットワークスロットリングはNothingで設定した．次いで，CPUストロットリングの値を4xslowdownに設定した．これは計測器であるラップトップPCが保有するCPUの1/4のスペックで計測することを意味する．一般的にスマートフォンのCPUはラップトップPCより性能が劣ることが多いため，本検証では1/4のスペックを設定した（図25）
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/42694701-6ba8-421c-9857-7f86381a8084">
<palign="center"> （図24検証環境の概略図）
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/e4e69b89-fa90-42dc-be65-969007793663">
<palign="center"> （図25ネットワークスロットリングとCPUストロットリングの設定）
上記の条件で計測を行った結果，FCP0．53秒，LCP0．53秒，TTI1．66秒の値を示した（図26）．これは各種指標において最上位のステータスに分類される値であり，オフライン環境下でも高いWebパフォーマンスでハザードマップを配信できることが確かめられた．このことから，本システムはオフライン環境下であっても，十分な速度でハザードマップを表示できることが示せた．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/16407298-eb5a-4faf-bba2-1c190e70ef58">
<palign="center"> （図26PerformanceInsightsでの計測結果）
###4．33D標高表現に関するユーザビリティ評価
本節では作成した標高を3D表示し，陰影起伏表現を加えた地図デザインが，危険地帯である低地と傾斜地を利用者に認識させることができるのかを検証する．本節の構成は，はじめに検証方法について述べ，次いで参加者の属性について説明し，最後に検証結果を論じる．
####4．3．1．検証方法
本検証はオンラインビデオツールを用いて10人の参加者に対して，2Dの標高表現と陰影起伏を加えたハザードマップと3Dの標高表現と陰影起伏のハザードマップを見比べて3D表現が危険地帯の認識に対してどのような効果があるかを確かめた（図27）（図28）．参加者は自身のスマートフォンでハザードマップにアクセスし，はじめに2Dのハザードマップを閲覧し，自身が徒歩で避難すると想定した時に，どこが危険地帯であると感じる場所を複数個抽出する．次に3D表現を用いたハザードマップを閲覧し，同様に危険地帯であると思われる場所を指摘する．ハザードマップを閲覧する時間は最長で5分までとした．2Dと3Dのハザードマップを閲覧した上で，危険地帯の認識がどう変化したのか，変化しない場合はなぜ変化しなかったのかをインタビュー形式でヒアリングをした．インタビューを終えたのち，図29と表2で示す質問事項にオンラインフォームを通じて入力してもらい，結果を集計した．
（図27参加者が閲覧した2Dマップ） （図28参加者が閲覧した3Dマップ） （図29質問事項一覧） （表2職業欄選択肢一覧）
####4．3．2被験者の属性
本検証では，参加者が日常的にどの程度デジタル地図を利用するか，ハザードマップを閲覧するかを集計した．図30に参加者の職業，図31にどのような頻度でデジタル地図を利用するかについて，図32にどのような頻度でハザードマップを閲覧しているかについてのアンケートの結果を示す．なお，参加者は実施者の身辺に有志を募り募集した．参加者の職業を見ると学生〇〇割，．．．．という構成となった．アンケート結果を見ると，参加者の〇〇%はデジタル地図を利用する一方で〇〇%はほとんど使わない結果となった．ほとんど使わないと回答した参加者を対象に，なぜデジタルマップを利用しないかを質問したところ，日頃同じ道しか通らないので旅行の時にしか地図アプリを開かないとの回答を得た（表3）．また，ハザードマップの閲覧頻度に関しては，全ての参加者がほとんど利用しないと回答した．なぜ，ハザードマップを日常的に閲覧しないかを質問に対しての回答を表5に示す．ハザードマップ配布時や住居の検討，防災訓練の際にのみ利用する結果がでた．
（表3デジタル地図をほとんど利用しない参加者の回答）
（表4ハザードマップをほとんど利用しない参加者の回答）
（図30参加者の職業比率）
（図31どのような頻度でデジタル地図を利用しますか？に対する回答）
（図32どのような頻度でハザードマップを閲覧しますか？に対する回答）
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/f86b2475-6a8e-4238-bac5-af4a5ce5973c">
<palign="center"> （表5ハザードマップをほとんど利用しない参加者の回答）
年に1回定期的にハザードマップを閲覧する参加者が1名おり，回答があったそれ以外の参加者は，1度もしくは1度もハザードマップを閲覧したことがない結果となった．このことから，デジタルマップを利用する機会はあるが，ハザードマップの利用は日常的にほとんどない層が大部分を占める検証となることがわかる．
####4．3．3調査結果
本節では，文京区周辺の2Dの標高表現と陰影起伏を加えたハザードマップと同じく文京区周辺の3Dの標高表現と陰影起伏のハザードマップを見比べて得られた参加者の回答を示す．はじめに，2Dの標高表現と陰影起伏を加えたハザードマップを閲覧してどの地域を危険だと認識したかを示し，その後3Dハザードマップではどこを認識したかを述べる．参加者が危険地帯を指摘する際には，具体的に地名や町丁目名といった特定の箇所を指定する回答のみならず，浸水域全般といった広い地域を指す回答も許容するものとした．最後に，2Dと3Dを見比べた上危険地帯の認識にどのような影響があったかについての参加者の回答をまとめる．まず，2Dの標高表現と陰影起伏を加えたハザードマップを閲覧した上で得られた回答を表5に示す．結果を見ると，参加者全員が浸水予想域全般を危険地帯と認識していた．浸水予想域に囲まれている地域や浸水予想域の中でも河川に近い土地を危険地帯だと認識する参加者もいた．一方で，低地と傾斜地を危険地帯だと認識している回答は1名のみであった．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/ae0aa8fe-51ab-4c74-81a5-a5797b2ec04d">
<palign="center"> （表52Dハザードマップを見た上でどこを危険地帯だと感じたかについての回答）
次に，3Dの標高表現を用いたハザードマップを閲覧した上で危険地帯と感じた場所の回答を表6に示す．2Dの標高表現と同様に3Dの標高表現のハザードマップでも参加者全員が浸水予想域全般を危険地帯と認識していた．加えて，3Dの標高表現を用いたハザードマップでは，70%の参加者が標高の高低差がある箇所全般を危険箇所であると認識した．2D表現では見られなかった，傾斜に囲まれた地帯や斜度のある地域を危険地帯と認識する回答も見られた．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/a0d49b7b-e928-4316-a68d-c33483fee21e">
<palign="center"> （表63Dマップを見た上でどこを危険地帯だと感じたかについての回答）
最後に，2D表現と3D表現で危険地帯の認識にどのような変化があったかについての回答についてまとめる．回答結果を表7にまとめる．2D表現と3D表現を比較した時に，参加者の70%は3D表現があることで高低差を危険地帯と認識し，50%が傾斜地を危険地帯と認識できたと回答した．また，3D表現があることで，水の流れる方向や流速のイメージをすることができたという意見も見られた．一方で3D表現の地図を用いても，30%の参加者は高低差および傾斜地を認識できなかったと回答した．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/41b6532c-26b9-4571-bb0e-5506651ffabb">
<palign="center"> （表7 2Dマップと3Dマップを見比べた上で，危険地帯の認識にどのような変化があったかについての回答）
##5．結論
本章では初めに，第4章「実験・検証」における成果を基に，洪水災害発生時のオフライン状況における当該システムの有効性に関して総括する．その後，研究目的に対しての結論を述べる．続いて，本研究の学術的寄与に関する議論を展開し，システムの潜在的課題を指摘する．最終的には，研究の制約点を明らかにし，将来的な研究方向性について検討を加える．
####5．1．洪水災害時のオフライン環境における本システムの可用性について
本研究の目的は，洪水被害発生時に通信インフラがダウンした状況でも，スマートフォンのブラウザアプリケーションを通じて避難ルートを検討するための情報が掲載された洪水ハザードマップを閲覧可能とするシステムの提案することであった．そのために，Raspberry Pi 4を基盤とした洪水ハザードマップ配信システムを構築するとともに，洪水災害時の危険地帯である低地と傾斜地の認識を可能にするため，標高の3D表現と陰影起伏を加えた地図デザインを設計した．本システムが洪水災害時のネットワーク障害が発生している際に，求められる機能を満たしているかを確かめるため，検証1と検証2を行った．その結果，本システム次の3つの機能性を有していることが示された．
-稼働時間について 本システムの稼働可能時間は10000mAのモバイルバッテリー利用時で1232分（20時間32分）であった．これは内閣府防災情報（2018）が定義する洪水災害時の避難に要する想定時間を超える稼働時間であり，避難にかかる時間以上に稼働することを示せるものである．
-ページの表示スピードについて Webページのパフォーマンスを評価するFirstContentfulPaint（FCP），LargestContentfulPaint（LCP），TimetoInteractive（TTI）と呼ばれる3つの指標において，本システムは全ての指標において最高位の基準を満たす数値を示せた．よって，オフライン環境下であっても十分な速度でハザードマップを描画できることを確認できた．
-ハザードマップにおける低地と傾斜地の認識ついて ハザードマップにおける低地と傾斜地の認識を可能にするため，標高の３D表現と陰影起伏を加えた地図デザインを設計した．本地図デザインを施すことで，2Dでは低地と傾斜地の認識が10%だったのに対し，3Dの表現を加えることにより70%まで向上させることができた．このことから，低地と傾斜地の認識させることにおいて，3D表現が有効であることが確かめられた．
####5．2．リサーチクエスチョンと仮説に対する結論
前述のシステムの可用性に関する3つの検証結果を基に，本研究のリサーチクエスチョンへの回答を導き出す．第2章で概説した関連研究と事例を踏まえ，設定されたリサーチクエスチョンと仮説は以下の通りである．
・リサーチクエスチョン1:利用者による事前のデータダウンロードを必要とせず，多様なOSに対応し，かつ洪水時の危険地帯を認識を支援する標高情報を効果的に表示できるオフライン洪水ハザードマップシステムは，どのように設計し実装することが可能なのか．
・リサーチクエスチョン2:本システムを活用することで，洪水災害時の避難においてどのような変化が起こるか．
・リサーチクエスチョン1に対する仮説:Raspberry Pi 4を活用して，アクセスポイントおよびWebサーバーとして機能するWeb地図システムを開発する．このシステムは，Raspberry Pi 4に格納されたハザードマップデータを，Wi-Fi通信を用いてイントラネット内で配信できるようにし，オフラインでもWebベースの洪水ハザードマップを利用者のスマートフォンを介して提供する．また，国土地理院が公開する標高情報と，オープンソースの地図ライブラリであるMapLibre GL JSを組み合わせることで，標高情報を3D表示し，ユーザーが地形の高低差を直感的に理解できるようにする．このアプローチにより，多様なOSに対応し，洪水時の危険地帯である低地と傾斜地を利用者に認識させるオフラインハザードマップシステムの実現を目指す．
・リサーチクエスチョン2に対する仮説:3D表現を用いた可視化により，低地と傾斜地の認識が可能になり，浸水予測と予想深度に加え，高さ情報を意識した避難ルートの検討を行うようになる．
Raspberry Pi 4を基盤とした，ハザードマップをイントラネット内で配信可能なWeb地図サーバーを構築し，スマートフォンのブラウザ経由でハザードマップを表示させることで，特定OSに依存しない表示方法を確立できた．また，MapLibre GL JSを用いた標高情報の3D表示と陰影起伏をオーバーレイした表現と，グレートーンのベースマップデザインを設計することで，等高線や標高の数値を直接記入することなく高さ情報の可視化を行うと同時に，重要情報を目立たせる効果を示せた．本研究を通じて，当システムを活用することで利用者は浸水予想域のみならず，低地と傾斜地の認識した避難ルートの検討が可能となることが示唆された．また，傾斜地帯が可視化されることで，洪水災害時における水の速度や流れる方向をイメージできたという回答も得られた．従来のハザードマップでは濁流の速度を利用者に訴求できないことが課題であった（片田ほか，2004）．この課題に対し，本システムを活用することで濁流が激しい部分と穏やかな部分のイメージを避難者に訴求できる可能性を示せた． 一方で，本検証では参加者の3割は3D表現を用いたとしても，土地の高低差の認識することができなかった．そのため今後，標高を認識させるための地図デザイン及び可視化手法について再考し，より確実に低地と傾斜地を認識させるための手法について追加検証する必要がある．
####5．3本研究の意義
本研究の学術的な貢献はまず，洪水災害時におけるインターネット障害の実情と現行のハザードマップの表現手法およびを整理した上で，現行のハザードマップの補完すべき要因を整理した点である．避難時には低地と傾斜地の把握が重要であるのも関わらず，現行のハザードマップではこれらの認識が難しいことがわかった．この問題に対し，標高の3D表現を用いて低地及び傾斜地の認識に有効である地図デザインを開発した点に新規性と独自性があると考えられる．次に，本研究によって開発したシステムを利用することで，災害時におけるインターネット障害が発生した際に，従来の紙媒体ではなくデジタル地図の選択肢を提示できたことは学術的な貢献があるといえる．さらに，本研究を通じて洪水流速の認識について，オフライン時のハザードマップ利用に関する示唆が得られた．以下で2点の示唆について呈示する．
####5．3．1濁流速度の認識の向上
洪水ハザードマップに掲載されている浸水域や浸水深は，ある一定の条件下でのシュミレーション結果であり，避難者はハザードマップの情報と現場の状況を踏まえて避難計画を練る必要がある．浸水域や浸水深の情報のみならず，流速を把握することでより綿密な検討が行える．しかし，既存のハザードマップでは流速の認識のために効果的な可視化表現を行っているとは言えない．一般的には流速の認識を促すために，ハザードマップ上に最大予想流速を数値で記載される（李瑾・周霏，2020）．濁流被害に関して知識や経験がある者であれば，数値の記載のみで被害想定を行うことが可能かもしれないが，そうでない人々にとっては数値から被害レベルをイメージすることは困難であると予想される．本研究を通じて，標高の3D表現により土地の高低差と斜度の可視化を行い，利用者に流速の速さのイメージを訴求できる可能性が示唆された．3Dで表現することで，立体的に斜度を把握することが可能になり急勾配の地域が可視化された．急勾配は水の流れが早いという感覚から，穏やかな傾斜と急勾配を比較し流水速度をイメージできるのだろう．本研究で得た示唆を活かすことで，既存の数値表現と本研究で提示した3D手法を組み合わせ，より効果的な濁流速度の表現が可能となるかもしれない．これは，片田ほか（2004）が指摘している，避難者に濁流の速度を利用者が認識できていない課題に対する1つの解決策として提案することが可能と考える．
####5．3．2オフライン時のハザードマップ利用に関する示唆
各世帯でハザードマップを保管している場合，避難者は発災時にそれを取り出し避難を検討することができる．一方，ハザードマップを保管していない場合，避難者は自治体のWebページにアクセスし，ハザードマップを閲覧もしくはダウンロードを行うフローが想定される．金井ほか（2017）はハザードマップの保有世帯を6．9%と推定している．これを踏まえると過半数以上の世帯は発災時にハザードマップが手元にない状態となる．大半の世帯がハザードマップを保有していないことを踏まえ，インターネット障害が起きておらず接続で可能な状態であっても，一度に大勢が被災地帯のハザードマップにアクセスしようとすると，サーバー側のキャパシティを超え，アクセスが難しい状態となる．2024年1月1日に発生した令和6年能登半島地震の被災地である輪島市と珠洲市の津波ハザードマップにおいて，発災直後にはサイトにアクセスできない状態が発生した．執筆期間と発災時期が非常に近かったこともあり，執筆時点ではアクセスができなかった要因は公式に発表されてはいないが，自治体のサーバーが想定するアクセス数を超えたことが理由であると考えられる．筆者は発災直後にCheckIfDownと呼ばれるサービスを用いて，被災地のハザードマップへのアクセスについて検証を行った．CheckIfDownは特定のウェブサイトのアクセシビリティを判定するために設計されたツールであり，サーバー側に障害が発生しているかを確認することができる．輪島市が公開する津波ハザードマップに対し，1月1日(月)16:50頃アクセスを試みたがサーバーがダウンしている表示となった（図33）．また，珠洲市も同様に，Web上で公開される津波ハザードマップに対して1月1日(月)16:58頃アクセスしたが，ページを表示することはできなかった（図34）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/117894fa-d9c2-405c-9367-447ec217e70a">
<palign="center"> （図33CheckIfDownにて輪島市津波ハザードマップにアクセスした時の分析結果）
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/b5167294-2a79-4260-88bc-87f40bc09903">
<palign="center"> （図34CheckIfDownにて珠洲市津波ハザードマップにアクセスした時の分析結果）
上記の結果を踏まえると，インターネット障害が発生していなくとも，ハザードマップにアクセスできない状況は発生しうることが予想される．第4章実験・検証で示した通り，本システムは高速にハザードマップを表示することが可能である．自治体のハザードマップが格納されているサーバーに負荷がかかっており，アクセス不可の状態であっても本システムを用いればハザードマップを閲覧することができると考えられる．インターネット障害時のみならず，サーバー側で障害が発生していてアクセス不可の状況に対して，本システムはこれを解決する1つの有効な手法として提案できると考えられる．
####5．4本研究の限界
はじめに，「4．2．3D標高表現に関するユーザビリティ評価」の結論についての限界が考えられる．本検証は日常的にスマートフォンを利用する人々を対象に実験を行った．本実験の参加者に関しては3D表現による低地と傾斜地の認識の有効性は示せたが，日常的にスマートフォンを利用しない層を対象とした検証はできていない．ハザードマップは多様な年齢層や属性の方々が満遍なく利用するものであることから，今回検証できなかった層に対しても低地と傾斜地の認識が向上するかについて検証する必要がある．よって，後続の研究においてはより多様な属性の参加者を集め，検証を行うことが求められる．それに伴い，本検証では参加者を10人と設定したが，本研究で扱わなかった層に対してアプローチするためには，より多くの参加者を集めて本システムの検証を行うことが重要となる．
次に，災害時における避難行動に関する本研究の限界について論じる．本研究を通じて洪水災害時の危険地帯である低地と傾斜地の認識において，本システムの有効性を示すことができた．一方で，危険地帯を認識した後の実際の避難行動にどのような効果をもたらすかについては検証できていない．発災時において，危険地帯を認識することは重要であるが，避難所をはじめとした安全地帯に避難することが最も重要なことである．本研究では危険地帯の認識について焦点を当てていたが，将来的な追加研究を行う場合は，実際に適切な避難が行えるかどうかについて検証する必要がある．実際に避難を促すためには，現在位置の取得と避難所までのルーティング機能を追加することが重要であると考える．「2．2オフラインで利用可能な地図サービス」で示したGoogle MapsやMaps．meのようにオフライン環境で目的地を設定しルーティングを行う機能は現時点で本システムには搭載されていない．本研究で得られた結果を踏まえて，現在位置取得とルーティング機能を追加して，実際の避難行動に対して本システムがどのように機能するかを検証することが求められる．
####5．5．今後の研究展開
本研究を通じて，既往研究において課題とされていた濁流速度の可視化表現について，その解決策となる示唆を提示できた．一方で，本研究の限界である，避難行動に関する検証についても論じてきた．災害発生時には危険地帯の認識のみならず，そこから実際に避難することが重要とされるが，本システムでは，利用者に危険地帯の認識させることで留まっており，避難者に対し危険地帯を考慮した具体的な避難ルートの提示までは行えていない．上記の2点を踏まえて，本節では本研究の将来的な発展可能性を示す．
#####5．5．1濁流速度の可視化手法の発展について
「4．2．3D標高表現に関するユーザビリティ評価」で述べた通り，3D表現を用いることで土地の高低差と傾斜地が可視化され，危険地帯の把握のみならず，流水の速度を利用者にイメージさせる可能性を示せた．本研究では実験参加者に対して，流水の速度に関する質問は行わなかったため将来的な研究では流水の速度に焦点を当てた調査を行うことが求められる．また，より流水の速度を意識させるため，インターフェイスを改良する必要があると考える．国土交通省（2023）では，水の流れを矢印表現を用いて，速度を色別で表示し利用者に流水の速度の認識を促している（図33）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/5f068dec-ace5-4637-be4e-51dd461103b7">
<palign="center"> （図35ProjectPLATEAU（国土交通省）『高度な浸水シミュレーション』から引用（URL:https://www.mlit．go．jp/plateau/use-case/uc22-009/））
本事例の検証結果を見ると，利用者が流速を考慮して経路検討を行うことが可能になったと示されている．将来的な研究では，この可視化手法を加えることで，より高度な流水速度の表現が可能になると予想する．本研究を素地に流水の表現を改良することで，避難者に対して低地，傾斜地のみならず流水速度の認識を促すことができると考える．
#####5．5．2現在位置情報の表示について
本研究を通じて利用者に対して，洪水災害時における危険地帯の認識させることは示せたが，本システムが実際の避難行動にどのように影響するかについては検証できていない．本研究を発展させ今後は危険地帯の認知のみならず，危険地帯を踏まえた上で適切な避難経路のルーティングを行う機能実装が必要であると考える．本節では，実装の寄与となりうる先行事例を提示し，最後に今後の研究の発展可能性について論じる． 危険地帯を考慮したルーティングを行うには，2点の機能実装が必要である．1つはオフライン環境における位置情報の取得について，2つ目は危険地帯を避ける避難ルート検索機能である．現在位置を取得するためにはRaspberry Pi 4本体にGPSレシーバーを装着する必要がある．本システムはhttpsプロトコルではなくhttpプロトコルを採用しているため，利用者のスマートフォンの位置情報を取得してブラウザ上で利用することはできない．故にRaspberry Pi 4自体にGPSレシーバーを導入し，位置情報を利用する必要がある．一方で，オフライン環境下で位置情報を取得する場合はコールドスタートとなり，現在位置を表示するのにかなりの時間を要する場合がある．コールドスタートとは，GPSレシーバーが初めての位置情報を決定するプロセスのことである．この状態では，受信機はその時点で位置情報取得に係るデータを一切知らず，これらの情報をゼロから取得しなければならない．このプロセスには時間がかかることがあり，特に衛星信号が弱いか，障害物によって遮られている場合には，受信機が必要な全ての情報を集めるまでに数分から数十分かかることがある．コールドスタートでは位置情報表示にかなりの時間を要する場合があるため，事前に位置情報取得に必要なデータをプリインストールするなどして，コールドスタートを回避するなどの手法が求められる． 危険地帯を考慮したルーティングシステムの構築に関しては，既往事例を援用することで実装が可能であると考える．国土交通省（2023）では洪水災害時の浸水地帯を避けるルーティングシステムを構築を実現させた．この事例ではOpenStreetMapの道路ネットワークデータとPostgreSQLデータベースの拡張機能であるpgRoutingを用いて，浸水域を避けるルート検索機能を実装している（図36）．
<palign="center"> <imgwidth="600"alt="image"src="https://github.com/ShogoHirasawa/2023-syuron/assets/29940264/55aecd98-a21d-439d-a693-e6361a373af6">
<palign="center"> （図36ProjectPLATEAU（国土交通省）『住民個人の避難行動立案支援ツール』から引用（URL:https://www.mlit．go．jp/plateau/use-case/uc22-041/）
Raspberry Pi 4上にOpenStreetMapの道路ネットワークデータベースをPostgreSQLで構築し，pgRoutingを稼働させることで本システム上で稼働する危険地帯を避けるルーティング機能を実装が行えると考える． 近年多発する自然災害において，ハザードマップを利用して避難行動を促す必要性は益々高まっている一方で，インターネット障害等の問題によってハザードマップにアクセスできない状況が発生している．こうしたことから，オフライン環境下でもデジタルマップを利用し，危険地帯の認識および避難ルートの検討を行う研究には意義がある．本研究で得られた結論を踏まえて，今後さらなる検証を行なうことには，学術的な意義があると考えられる．
##6．謝辞
本研究の遂行にあたり，多くの方々にご指導ご鞭撻を賜りました．
まず，東京大学大学院学際情報学府高木聡一郎教授には，本研究の指針を照らし，継続的な深い洞察と詳細な指導を賜りました．教授の広範な知識と豊かな経験は，研究の質を大きく高め，学問的視野を広げる貴重な財産となりました．心より感謝申し上げます．副指導教官である東京大学大学院学際情報学府渡邉英徳教授には，研究における的確なアドバイスと献身的なサポートをいただきました．特に国際会議の参加に際しては，貴重なご意見と寛大な支援を賜り，自信を持って臨むことができました．深く感謝の意を表します．同じく青山学院大学地球社会共生学部の古橋大地教授には，技術的見地からの指導と学問的なアドバイスを賜り，研究の方向性を見定める上で大いに助けられました．教授のご指導は，私の研究への理解を一層深めるものでした．また，高木聡一郎研究室及び渡邉英徳研究室のメンバー各位には，日々の議論と支援を通じて，研究を進める上での励みとなる多くの示唆をいただきました．皆様の持つ多様な視点と知識は，本研究をより豊かなものにしてくれました．国際会議FOSS4GとStateoftheMapにおける本研究の口頭発表とポスター発表を可能にしてくださった運営委員会の皆様，そして発表を聴講し，有益なフィードバックをくださった参加者の皆様にも，深く感謝申し上げます．最後に，修士課程の学業と職務を両立させることを可能にしてくださった株式会社ユーカリヤの関係者の皆様に，特別な感謝を表します．皆様の理解と支援があったからこそ，この研究を遂行することができました． これらすべての方々のご支援と助言がなければ，本研究の完成はあり得ませんでした．重ねて心からの感謝を申し上げます．
##8．参考文献