1.　はじめに

高齢化社会を迎える日本では介護を必要とする高齢者の数が年々増加しており，家族や介護施設のスタッフによる介護負担の増加が大きな問題となっている．特に，人口減少率が全国1位である秋田県では，働き手が減り，人材確保が困難ななかで，介護施設における介護サービスのレベルの維持は大きな課題である．

我々が介護施設にヒアリングしたところ，送迎バスによる利用者の送迎業務の負担が大きいと分かった．たとえば，利用者家族からの送迎バス到着時間の問い合わせ対応に時間が取られたり，利用者の受け入れ準備が間に合わず利用者を待たせるケースがあった．また送迎バスが利用者宅に到着時に，利用者の出発準備ができておらず，待ち時間が発生することもあった．これらの多くの無駄はICT技術の活用で，負担を大幅に削減できる可能性がある．たとえば，利用者を迎えに行った送迎バスの施設への帰着時間が分かれば，それに合わせて事前の準備ができる．

この課題解決のために，送迎バスに付けた端末がGNSSを用いて取得した位置情報をクラウドに送ることで，(1) Webブラウザで表示した地図上へ送迎バスの位置を表示し，(2)利用者宅に近づいた際に到着予告メールを送信するシステムを開発した．ただし，介護施設へのヒアリングから，通信部分に携帯電話網を利用する同様なシステムは，通信料金がかかることが導入への障害になっていることが分かっている．そのため，位置情報の送信には，日本において免許不要で使用可能な920 MHz帯を用いた省電力長距離無線技術（LPWA）の一種であるLoRa [1], [2], [3]を用いた．実験に協力いただいた秋田県由利本荘市の介護施設の送迎バスに位置情報送信端末を取り付け，開発システムの実証実験を実施した．

多くの山間部を含む由利本荘市にて本システムを運用するためには，山間部においてもLoRaで通信できる必要がある．以前，我々が由利本荘市と同様に山が多いにかほ市において実施したLoRaの通信可能距離調査では，最大15 km離れた地点からも通信が可能であった一方，土地の隆起により見通しの取れない地点では，距離が短くても通信できなかった[4]．由利本荘市にて開発システムを運用する場合，位置情報が取得できる地域が限定されることが予想されたため，LoRaの受信機側に受信感度向上の対策を実施し，その効果を評価した．また，実証実験を実施したところ，山間の地域からの位置情報取得ができないことが判明したため，複数箇所への基地局設置によりこの問題に対処した．

本稿では，開発した介護施設送迎バス位置管理システムとその実証実験の結果について報告する．本稿の貢献は，次の3点である．一つ目は，LoRa通信可能エリア拡大に向けた取り組みとその結果の報告である（5章と6章）．二つ目は，本システムに用いたLoRaのパラメータとその決定方法の紹介である（4.2）．三つ目は，バス到着を予告するメール送信方式に関する実践（4.3，4.5）と，実証実験後に得られたユーザの評価（7章）に関する報告である．これら3点はいずれも，他の地域にて，本システムと同様なシステムを開発・運用する際の参考になると考える．

本稿の構成は，以下のとおりである．まず2章にて関連研究を述べる．3章にて本システムを開発するにあたり掲げた要件を説明し，4章にて今回開発したシステムを説明する．5章にてLoRaのカバーエリア拡大について述べ，6章にて評価結果を説明する．7章，8章にて考察と今後の課題を述べ，最後に9章にてまとめを行う．

2.　関連研究

センサーデータなど少量のデータを省電力に送るといった用途に対して，近年LPWA（Low-Power Wide-Area）と呼ばれる無線技術[2]が登場し，活用が始まりつつある．特にLPWAの一種であるLoRa [1]は，日本において免許不要で使用できる920 MHz帯を使用する点[3], [5]，またLoRa変調に対応したチップを搭載したモジュールが市販されている点から，誰もが自営網を構築可能である．そのため，幅広い分野での活用に向けて多くの研究が進められている[6], [7], [8], [9], [10]．

バスなどの位置情報を利用者に提供するバス位置情報管理サービスやそれに用いるシステムに関して数多くの研究がなされ，実用化されている[11], [12], [13]．これらの多くは位置情報の送信に携帯電話網を使っており，その利用にはコストがかかるため，保下らはLoRaを用いたバス位置情報管理システムを提案している[14], [15]．文献[15]は，携帯電話網の代わりにLoRaを使うことで，通信コストを大幅に削減できることを示している．これらのシステムは，我々のシステムとLoRaやクラウドを使う点では共通しているが，文献[15]が示す評価ではLoRaの通信範囲は最大で2.1 kmである．我々は，6.2で示すとおり，最大で20 km超のより広いエリアを対象とするため，本研究を実施した．

実環境におけるLoRa通信可能距離に関して，多くの調査報告がなされている[4], [16], [17], [18]．しかし，本稿のようにシステム全体の実証過程の中で，数ヶ月の長期間にわたりLoRaの受信強度情報を測定し，その結果を報告した例はほかにない．

無線通信における通信可能距離の概算には，広く電波伝搬モデルが用いられる．その中でも広く用いられている電波伝搬モデルの一つに，奥村・秦モデルがある[19]．このモデルでは，距離Rと電波の減衰Lの関係が式(1)で表される．\[L = A + B\log_{10} (R)\](1)

式(1)中のA，Bは，開放地・郊外・中小都市・大都市といった環境ごとに用意されたパラメータである．本研究では，異なる条件で実施した実測データ同士の比較のために行った回帰分析において，この式を用いた．詳細は，5章にて述べる．

3.　要件

今回のシステムでは，ユーザに対して以下のサービスを提供することを目的とした．

• (1)送迎バスが利用者宅に一定距離近づいたときに，バスがまもなく到着する旨を記載したメールを利用者の家族に送信する．
• (2)送迎バスが介護施設に一定距離近づいたときに，バスがまもなく到着する旨を記載したメールを施設スタッフに送信する．
• (3)Webブラウザ上にて地図を表示し，その上に送迎バスの現在位置をプロットする．
• (4)本サービスは，由利本荘市内の在住の利用者を持つ介護施設向けに提供する．

図1に本サービスの提供地域である由利本荘市の陰影起伏図を示す^*1．由利本荘市は，図1中にある8市町が2005年に合併してできた市であり，その面積は約1210平方km（東西約32 km，南北約65 km）と秋田県内で一番大きな市町村である．図中のマーカーは市役所と共同研究センターの所在地を表しており，この両地点にLoRaの基地局を設置した（詳しくは5章で説明する）．

今回の実証実験に協力してくれた介護施設の利用者は図1中の8地区中，矢島，鳥海を除く6地区にいるため，この6地区で利用できることを目標とした．

4.　システムの実装

4.1　全体構成

今回開発したシステムの全体構成を，図2に示す．要件(1)から(3)の機能はクラウドを用いて実装することにした．また，送迎バスの現在位置情報収集は，要件(4)を満たすために，免許不要で誰もが利用できる省電力長距離無線技術（LPWA）であるLoRaを用いた．LoRaを用いた位置情報送信端末と基地局の構成を，図3に示す．

図2中の送迎バスには，図3に構成を示す位置情報送信端末が取り付けられている．位置情報送信端末内のMCUは，9秒間隔でGNSSモジュールから取得した位置情報をLoRaモジュールを用いて送信する（詳細は4.2にて説明する）．拠点に設置するLoRa基地局は，図3に示すとおり，受信機とRaspberry Piから構成されている．当初開発した受信機にはインターネット接続のためのネットワークインタフェースがなかったため，インターネットに接続する役割を担うRaspberry Piと受信機を組み合わせ，LoRa基地局を構成した．受信機は，位置情報送信端末から送られた無線信号を受信し，受信回路経由でLoRaモジュールへと送る（受信回路は6.2にて説明する）．LoRaモジュールは，LoRa変調された信号を復調し，得られた位置情報およびLoRa受信時の電波強度（RSSI）をMCUへと送る．MCUはこれらの情報をUSBインタフェース経由でRaspberry Piへと渡す．Raspberry Piは，受け取った情報をJSON形式に変換したうえでhttpのpostメソッドを使ってクラウドへと送る．図2中のクラウドは，送迎バスの位置情報に応じてメールを送信すべき利用者家族・スタッフがいるかを調べ，いる場合にはメールを送信する．また，現在位置情報を表示する画面を開いているWebブラウザからの要求に基づき，送迎バスの最新の位置情報を送信する．これらクラウドの動作については4.3で詳しく説明する．

4.2　LoRaを用いた位置情報の送信

本システムでは，図2中の送迎バスから基地局へと位置情報を送るためにLoRaを用いた．LoRaモジュールには，EASEL社のES920LRB [22]を用いた．LoRaを使用する場合，拡散率や通信に使用する周波数帯域といったパラメータ[23]を用途に合わせて設定する必要がある．本システムにて使用したパラメータを，表1に示す．

LoRaの一般的な用途において，拡散率は7から12までのいずれかの値を設定できる．この値が大きいほど，ノイズ耐性が高くなり，より遠距離での通信が可能となるが，その分ビットレートが低くなる．周波数帯域幅が125 kHzの場合，ビットレートは拡散率7で約5.5 kbps，拡散率12で約290 bpsとなる．今回，広域での利用を想定し，拡散率には最大の12を用いた．使用可能な周波数帯域は．今回使用したLoRaモジュールでは，125 kHz，250 kHz，500 kHzから選択することができる．使用する帯域が広いほど，ノイズによる影響を受けやすい．一方で，ビットレートは帯域幅に比例するため，同じデータ量であれば，使用する帯域幅が広いほうが通信時間が短くなり，通信が成功する可能性が高くなる．事前に125 kHzと250 kHzの比較評価を行ったところ，通信の成功率に大きな差がみられなかったので，本システムではより短い時間で通信が完了する250 kHzを採用した．拡散率が12，周波数帯域幅が250 kHzの場合，ビットレートは約590 bpsとなる．位置情報送信端末が一回の送信で送るデータのサイズは35 byteであり，そのデータの送信には約0.5秒かかることになる．送信電力は，法令上の上限[5]である13 dBmとした．

今回の実証では，位置情報送信端末をつける送迎バスの台数は3台とし，それぞれの端末が位置情報を送信する間隔は9秒とした．仮にバスが時速40 kmで走行したとすると，9秒間で約100 m進む．バスが住宅街などを進む際には，9秒間に進む距離はさらに小さくなる．この距離は，利用者宅や介護施設に近づく際のメール送信タイミングの誤差となるが，この誤差はメール送信の基準となる距離1.5 km，2.0 kmに対して十分許容できると考えた．そのため，位置情報の送信間隔を9秒とした．

920 MHz帯を使用する場合，送信前に，使用する周波数帯域を他の無線端末が使用しているかを調べるキャリアセンスを実施する必要がある．キャリアセンスにおいて−80 dBm以上の信号を検知しない場合のみ，送信を行って良いと法令で定められている[5]．他の無線端末の送信中であれば，自らは送信を行わず，一定時間待つことで電波干渉の発生を防ぐ．しかし，LoRa変調では，5章や6章で示す評価結果からも分かるように，−80 dBmを大幅に下回る信号でも復調可能である．つまり，ある端末が，キャリアセンスにおいて−80 dBmを下回るが十分復調可能な強度の信号を検知した場合でも，送信処理が行われる可能性がある．ある端末の送信中に他の端末が送信した場合，基地局は，強度の低いほうもしくは両方の信号を受信できない．このキャリアセンスの機能は，LoRaモジュール内に組み込まれているため，我々が改良することは困難であった．そのため，我々は，電波干渉の発生を避けるために，各端末が位置情報を送信するタイミングが3秒ずつずれるよう設定した．つまり，端末Aが送信してから3秒後に端末Bが送信し，その3秒後に端末Cが送信し，さらにその3秒後に再び端末Aが送信する．正確な時刻情報はGNSS経由で取得し，各端末があらかじめ決められたタイミングで位置情報を送信することで，電波干渉を避ける設計とした．

基地局は，受信確認を示すACKを送信しないこととした．今回のシステムにおいてACK送信を用いる場合の問題点を考える．今回の実証実験では，6.1で示すように，端末がある時点で送信した情報を複数の基地局が受信する場合がある．このとき，それぞれの基地局が送信したACK同士の電波干渉で，いずれのACKも届かず，送信端末は位置情報を再送する可能性がある．また，基地局から遠く離れた場所より端末が送信した情報が基地局に届かなかった場合，送信端末は一定時間ACKの受信を待った後，基地局に届かない可能性が高いにも関わらず情報を再送することになる．いずれの再送も，無線資源の無駄遣いであるのみならず，再送の頻度によっては，さらなる電波干渉発生の要因ともなる．ACKを送信しないことが，3章で示した要件実現に与える影響については7章にて考察する．

4.3　クラウド部分の構成と動作

本システムのクラウド部分は，Amazon Web Services（AWS）社が提供する各種クラウドサービスのうち，以下のサービスを利用して実装した．

• ・Amazon API Gateway：REST APIを作成，保守，モニタリングするためのサービス
• ・AWS Lambda：ユーザ配備のコードをイベントドリブンで実行できるコンピューティングサービス
• ・Amazon DynamoDB：Key-Value型のNoSQLデータベースサービス
• ・Amazon Simple Email Services（SES）：クラウドベースのEmail送信サービス

今回実装したシステムの全体像を図4に示す．送迎バスに設置した位置情報送信端末から送られた位置情報が基地局経由で，クラウドに送られたときの処理について説明する．基地局から送られた位置情報は，Amazon API Gatewayを用いて実装されたBusLocation-APIにて受け取り，AWS Lambdaで実装されたBusLocationに送られる．BusLocationは，BusLocation-APIでの位置情報受信をトリガーに起動し，次のように動作する．

• (1)Amazon DynamoDB上のテーブルであるbuslocation_usersを参照し，利用者宅の位置情報，メールアドレス，前回送信時刻を取得する．
• (2)送迎バスの位置が利用者宅に一定距離以内であり，かつ前回送信時刻から一定時間経過している場合に，Amazon SESを使い，バスがまもなく到着する旨を記載したメールを利用者の家族に送信する．メールを送信した場合，現在時刻を前回送信時刻としてbuslocation_usersに登録する．
• (3)再度buslocation_usersを参照し，スタッフのメールアドレスを取得する．
• (4)送迎バスの位置が介護施設に一定距離以内である場合に，Amazon SESを使い，バスがまもなく到着する旨を記載したメールをスタッフに送信する．メールを送信した場合，現在時刻を前回送信時刻としてbuslocation_usersに登録する．
• (5)buslocation_users中に利用者家族・スタッフが複数登録されている場合，それぞれの利用者家族・スタッフに対し上記の処理を実行する．
• (6)送迎バスの位置情報をAmazon DynamoDB上のテーブルcurrent_buslocationに登録する．

送迎バス到着の3分から5分前に通知できるよう，送迎バスが利用者宅から2 km以内に近づいたときにメール送信することとした．また利用者家族へのメール送信は，午前中のお迎え時と午後のお送り時の二回であり，複数の利用者をすべてお迎え（お送り）するのに最大2時間程度であることから，前回送信時刻から3時間経過しないと再度メールは送信しないこととした．スタッフへのメール送信の距離は1.5 kmとし，再度メール送信までの制限時間は10分とした．その理由は，日中に送迎バスを使って利用者が2 km以内の近場に外出することがあり，外出の時間は一定ではなく，また複数回外出する可能性があるためである．

本システムでは，ある時点に位置情報送信端末が送信した位置情報が，複数の基地局によって受信され，同じ位置情報に基づきBusLocationが重複実行される可能性がある．この重複実行による同じ内容のメールの連続送信を防ぐために，本システムではロックによる排他制御を用いている．(1)の処理でbuslocation_usersをロックし，(5)の処理でロックを解放する．同一時点の位置情報に基づき，二回目以降にBusLocationが呼び出された場合のメールの送信は，一回目の呼び出し時に記録された前回送信時刻を参照することで防ぐことができる．なお，(6)の処理の重複実行は，current_buslocationに同じ位置情報を複数回登録することになるが，システムの動作上問題は生じない．

4.4　Webブラウザでのバスの現在位置表示

次に，Webブラウザにて送迎バスの現在位置情報を表示する際の処理について説明する．送迎バスの現在位置情報を表示するための処理はjavascriptにて記載した．このjavascriptのコードを含むhtmlファイルは，図4中には記載していないがAWS CloudのWebサーバ上に配置した．ブラウザは，まずこのhtmlファイルをWebサーバから読み込むと，buslocation_current-API（Amazon API Gateway）に送迎バスの現在位置情報取得のリクエストを送信する．このリクエストが送られたbuslocation_current（AWS Lambda）は，テーブルcurrent_buslocationから取得した送迎バスの位置情報をJSON形式に変換し，buslocation_current-APIを介してWebブラウザへと返す．Webブラウザは，現在位置情報取得のリクエストを3秒間隔の非同期処理（Ajax）にて送るため，画面遷移せずに3秒ごとに送迎バスの現在位置情報を更新して表示することができる．ここで表示される地図には，OpenStreetMap [24]を使用した．送迎バスの現在位置は，基地局が最後に位置情報を受信してから30秒以上経過している場合には赤，位置情報を受信しているが30秒以上同じ位置にいる場合に黄，それ以外は青で表示することとした．このようにすることで，仮にバスが位置情報が届かない場所に移動したとしても，バスの向かった方向をユーザが推測できるようにした．図5にWebブラウザの表示イメージを示す．

4.5　メール送信可否の判定

前節で説明した利用者・スタッフ向けに送迎バスの到着を知らせるメールを送信する単純な処理では，いくつかの問題があることが分かった．単純なメール送信処理における問題点は以下のとおりである．

• (1)利用者A宅の近くを通り過ぎ，利用者Bをお迎えしたあと，利用者Aをお迎えする場合，はじめに利用者A宅に近づいた段階でメールが送信される．
• (2)スタッフのメール送信は，送迎バスが介護施設から一定距離に入った際に送られる．もともと送迎バスは介護施設から出発するので，出発時にメールが送られてしまう．

問題(1)に関しては，利用者の送迎順序を設定することで対処した．送迎順序は，送迎バスが出発する前に介護施設側にて決定できる．そのため，送迎順序は既知であることを前提とした．利用者A宅に近づいたときに，利用者Bへのメール送信時刻を確認し3時間以上経過している場合，まだ利用者B宅についていないと判断し，メールを送信しない．利用者Bへのメール送信が3時間以内である場合には，利用者Bをお迎えし，利用者A宅に向かっていると判断し，メールを送信することとした．

問題(2)に関しては，図6の状態遷移図のように，送迎バス位置の状態を管理することで対処した．送迎バスが介護施設近傍にいる状態（home），介護施設から離れている状態（foreign）に加え，送迎バスが介護施設から一定距離離れ10分以内経過するまでの状態（border）の三つの状態を用意した．borderを用意した理由は，道路の曲がり具合などの関係により，介護施設から一定距離を出たり入ったりする際にメールが送られることを防ぐためである．送迎バスが介護施設を出発し，一定距離（1.5 km）離れると状態がhomeからborderへと遷移する．その後，10分以上一定距離離れた状態でいると，状態がborderからforeignへと遷移する．その後，送迎バスが介護施設に戻る際に，一定距離以内に近づくと，状態がforeignからhomeに遷移し，このときスタッフへとメールを送信する．

5.　LoRaにおけるカバーエリアの拡大

2章でも述べたようにLoRaは条件次第では数十km離れている地点間での通信が可能であるが，土地の隆起や建物の陰では通信できないケースがあることが報告されている．LoRaにおけるカバーエリアを拡大するために，以下の項目を実施した．

• (1)1/2 λ モノポールアンテナの代わりに5/8 λ 4段C-Loadノンラジアルアンテナを使用した（図7）．

  

• (2)図3に示した基地局において，LoRaモジュールの前段にある受信回路に受信信号を増幅するローノイズアンプを搭載した．

電波暗室を用いて受信信号強度を測定した結果，前記対策前と比べ，対策(1)のみを実施した場合には4 dBから6 dBの改善，更に対策(1)に加えて対策(2)も実施した場合には12 dBから14 dBの改善を確認した．

電波暗室とは異なり，実環境では，建物や土地の隆起が，電波を反射したり，障害物となり電波を減衰させたりする．電波暗室で確認できた改善効果が，実環境でも同様に得られるかを確認するために，フィールド評価を実施した．受信可能な地点を比較するために，前述の対策前と対策後の二つの基地局を用意した．位置情報送信端末取り付けた車を走らせ，それぞれの基地局にて受信できた地点を地図上にプロットした（図8）．位置情報送信端末を取り付けた車は，図8の右上の基地局設置地点を出発し，海沿いの一般道を通り，図8の左下の受信地点まで行った．帰りは，内陸側の高速道路を通り，基地局設置地点まで帰還した．受信時のRSSIの値が−142 dBm未満を青，−142 dBm以上−136 dBm未満を緑，−136 dBm以上を黄色でプロットした．図8には，基地局設置場所を中心に1 km単位で同心円を記した．

図8の左側を参照すると，受信地点から5 km以遠では，高速道路上と一部の地点を除き，ほとんどの地点で受信できていない．対策前と比べ対策後は，5 km以遠の多くの地点で受信が可能となっていることが分かる．特に，受信地点の南西方向にある丘陵地帯の裏側からは，対策前では受信できていないが，対策後では受信できている．

図9は，往路において基地局から約1.2 km以遠の受信地点におけるRSSIと基地局からの距離の関係を示した図である．図9中の直線は，1.3 kmから3.4 kmまでのデータを式(1)にフィッティングした回帰直線であり，これらの回帰直線の切片Aおよび回帰係数Bはそれぞれ，対策前が−53.5，−25.4，対策後が−94.2，−6.86であった．これらの回帰直線を比較すると1.3 kmから3.4 kmの区間で17 dBから25 dBの差があり，実環境では電波暗室での測定よりも大きな改善効果を確認できた．

6.　実証評価

本章では，4章で説明したシステムの実証評価の結果を示す．本実証では，由利本荘市の介護施設にて実際に利用者の送迎に使用している送迎バスに位置情報送信端末を設置した．メールの送信先には，介護施設スタッフ5名，利用者の家族2名を設定した．

6.1　設置場所による比較

当初，図1中の共同研究センター2階（海抜9 m，地上5 m）の北側，南側の二つのみ基地局の設置する予定であった．しかし，これらの基地局のみでは，由利方面からの受信に問題があったため，市役所の6階（海抜8 m，地上20 m）にも基地局を設置した．

図10は，2019年6月27日に共同研究センター（南側），市役所に設置した基地局で，送迎バスにつけた送信機からの位置情報を受信できた地点をプロットした図である．図中には，基地局設置場所を中心に1 km単位で同心円を付した．この図を見ると共同研究センターは，東側がすぐ山になっており，由利方面（基地局設置地点の南南東）が見通せないことが分かる．一方，市役所から由利方面は見通せるため，市役所から15 km程度離れた地点からも位置情報を受信できている．

6.2　カバーエリア

図11は，2019年8月，9月の二ヶ月間に，共同研究センター北側，南側と市役所に設置した三台の基地局にて受信したデータ（411,438件）を地図上にプロットした図である．図中のプロットは，RSSIの値が−142 dBm未満を青，−142 dBm以上−136 dBm未満を緑，−136 dBm以上を黄色でプロットした．同一地点からの送信データを複数の基地局で受信していた，もしくは異なる日に受信していた場合には，RSSIが一番高いデータだけをプロットした．この期間のデータ中においてRSSIの最小値は，−150 dBmであった．5章の対策(1)，(2)の改善効果はそれぞれ約6 dB，約8 dBであったため，対策なしの場合は−136 dBmまで，対策(1)のみ実施した場合−142 dBmまでしか受信できなかったと推測できる．つまり，黄色でプロットした地点は対策なしで受信可能と推測できる地点，緑と青はそれぞれ，対策(1)のみ，および対策(1)，(2)の実施で受信可能となる地点と考えられる．プロット地点の数は，黄色が116,005件，緑が5,008件，青が1,178件であった．

共同研究センター北側，南側に設置した基地局における受信地点数はそれぞれ約9.8万件，10万件であり，重複を除いたこれらの合計は約10.7万件であった．また，市役所に設置した基地局における受信地点数は約10.9万件であった．そのうちこの基地局でのみ受信した地点の数は約1.4万件であった．6.1にて述べた市役所への基地局設置により，共同研究センターのみに基地局を設置した場合に比べ，約13%多くの地点からデータを受信できた．

6.3　メール送信可否判定の評価

4.5で説明したメール送信可否判定を，クラウド上のメール送信履歴およびバス位置情報の履歴を用いて評価した．

問題(1)への対処に関して，2019年8月，9月の履歴を用いて確認した．利用者B宅は利用者A宅よりも遠いため，システムに登録された送迎順は，午前中は利用者B，利用者Aの順，午後は利用者A，利用者Bの順であった．この期間中の17日は送迎があり，そのうち5日は午前もしくは午後のみの送迎であったため，この期間の送迎回数はのべ29回になる．このうち正しくメールが送られないケースは，以下の5回のみであった．

• ・利用者Aのみの送迎日が1日あり，その午前中は利用者B宅に近づかなかったため，利用者Aの家族にもメールが送られなかった．
• ・4回（いずれも午後）は実際の送迎順序がシステム登録と逆であったため，利用者Aの家族にのみメールが送られ，利用者Bの家族には送られなかった．

いずれも，システムは仕様どおり動作しているが，事前設定順での二名送迎という前提が崩れていることが原因である．この問題への対処は今後の課題である．また，この期間，メールは，利用者A宅より1.69 kmから1.89 km，利用者B宅より1.31 kmから1.90 kmの地点で送信されていた．利用者B宅から1.31 km地点までメールが送られなかった理由は，利用者B宅に2 km以内に近づいた後送信された位置情報数回分が基地局まで届かなかったためである．利用者B宅へ続く道は，山に囲まれた川沿いにあり，基地局を設置した市役所と直線で結ぶとその間に山がある地点がある．そのため，位置情報が基地局まで届かないケースが生じたと考えられる．

問題(2)への対処に関しては，事前評価で図6中のすべての状態遷移が想定どおり動作することを確認したうえで，2019年8月の履歴を用いて実証実験中の動作を確認した．この期間中158回メール送信されており，いずれの送信時刻も前のメール送信から10分以上経過後であった．介護施設から1.5 km以内に入った直後に送られた位置情報が基地局に届かず，次の位置情報（介護施設から1.34 km地点）受信時にメールが送信された回数は，1回のみであった．

7.　考察

6章で示した実証実験の結果と，実験後，本システムのユーザである介護施設スタッフと利用者の家族からいただいたコメントを元に，本システムが3章で示した要件を満たしているかを考察する．

要件1に関連して，利用者の家族からは，

• (1)いつ頃来るかといった不安が解消できた．（利用者A）
• (2)お知らせは実際に役立てることができた．（利用者B）

といったコメントをいただき，おおむね好評であった．また，介護施設スタッフから，

• (3)今までは利用者が送迎バスを外で待つケースがあったが，安全な場所で待ってもらえるようになった．

というコメントをいただき，当初想定していなかった効果も確認できた．一方，

• (4)役に立ったかというと，どちらとも言えない．利用者自身が元気であり，自分のことはほとんど自分でできているため．（利用者A）

というコメントは，メール送信先を利用者の家族ではなく利用者自身にしたほうがよいかもしれないことを示唆している．しかし，高齢の利用者はスマートフォンや携帯電話の扱いに慣れていない可能性もある．この点は今後十分な検証が必要である．メール送信（設定では2 km手前，約3分前）に関しては，6.3にて示したように，利用者宅から1.31 km地点で送信された日があったにも関わらず，

• (5)メール受信からバス到着までの時間はちょうど良かった．（利用者A，B）

というコメントをいただいた．一方で，

• (6)メール受信時間は10分から15分前のほうが準備により役立てる．（利用者A）

という声もあった．より早くメールを送信するようにすると，4.5で示した問題点1で示す状況の発生頻度が高くなる．このような状況で4.5で示した対策が正しく動作するのか今後検証が必要である．

要件2，3に関連して，介護施設スタッフからは，

• (7)送迎時や外出時に現在位置を確認することができ，待機職員の業務の事前準備など効率化につながった．
• (8)送迎バス同士の現在位置が確認できるため，送迎助手職員が互いに連絡を取り合い，効率よい送迎に切り替えることができた．
• (9)予定の送迎時間に遅れが生じると施設待機職員が利用者宅に電話する必要があった．このシステムを使えば業務の負担が軽減できると思う．
• (10)送迎時間を毎朝電話でお知らせしている方もいるので，このシステムの活用で業務の軽減につながると思う．

といったコメントをいただき，好評であった．しかし，メール送信に関して，以下のコメントもいただいた．

• (11)昼間に送迎以外の用途で出かけた送迎バスが帰着する際にもメールが来るので，届かないようにしてほしい．

この問題に対応するため，暫定的に，送迎時間帯（8:00–10:00，16:00–18:00）以外はメールを送信しないという対策を施した．しかし，スタッフだけではなく，利用者が日中外出するケースが有り，その場合の帰着時におけるメールは，この対策により送信されない．メール送信可否判断のさらなる高度化は今後の課題である．

要件4に関して，住宅地ではない山は除くと，本荘，由利，西目の大半と大内の西側は，カバーできていることが図11から分かる．特に由利，西目，大内の多くの地点は，5章の対策によって受信できるようになったと考えられる．西目の受信地点と基地局設置地点（市役所・共同研究センター）の間には山が存在し，見通しがない．しかし，この山の標高は約100 mとあまり高くなく，山が占める面積も広くないため，西目からの電波はこの山を回り込んで基地局まで届いたと考えられる．一方で，岩城，東由利および大内の一部以外からの電波は，対策済みでも受信できていない．これらの地域は基地局までの間に，広い丘陵地が存在し，見通しがない．そのため，これらの地域をカバーするためには，さらなる基地局の増設が必要となる．

今回の実証実験では，市役所と共同研究センターに基地局を設置した．図10を見ると，この二地点間は直線距離で約2 kmしか離れていないにも関わらず，受信地点可能地点に違いが生じている．このようにLoRaを用いた通信では，受信可能か否かは見通しの有無が大きな影響を与えていることが分かる．つまり，LoRaを用いる際には，送信地点に対して，いかに見通しが取れる場所に基地局をおくかが重要である．また，市役所を中心とするこの地域には3階建て以上の建物が少ないため，遠くまで見通すことができる市役所6階に基地局を設置したことも，より遠方から位置情報を受信できた要因の一つであると考えられる．このように，基地局の設置場所はより高いほうが望ましい．

6.2の結果が示すように，図11中の約8割の受信地点から送信された位置情報は，市役所と共同研究センターの両方で受信できる．これらの基地局はもっと離れた地点に設置したほうが，基地局数を増やさなくても，より広域から位置情報を収集できるようになると考えられる．たとえば，共同研究センターの基地局を大内方面に，もしくは市役所の基地局を由利方面に移設することで，位置情報を収集できる地域を拡げられる可能性がある．しかし，基地局は，次に示すような条件を満たす場所に設置する必要があり，その設置場所は限られる．基地局本体は電源確保や防水などの観点から屋内設置が望ましく，アンテナは屋外設置が望ましい．さらに，屋内設置の基地局本体と屋外設置のアンテナを結ぶケーブルを通すための配管も必要となる．今回は，このような条件を満たす公共施設（市役所，共同研究センター）に許可をいただいたうえで，基地局を設置した．基地局の移設や増設の際には，これらの条件に加え，先に述べた，周辺の見通しの有無や，設置場所の高さなどの条件を加味して，設置場所を決定する必要がある．

4.2で述べたACKの不使用は，前述のコメントから判断すると，要件実現に対する悪影響は少なかったと考える．利用者宅や介護施設に近づいた際送信された位置情報が基地局に届かなくても，次に送信された位置情報が基地局に届けば，メールが送信される．その分，メール送信から到着までの時間が短くなるが，このことはコメント(5)を見る限り，大きな影響はなかったと考える．ただし，実証実験のときよりも，さらに連続して位置情報が届かなかった場合，ユーザに影響を与えるほどメール送信が遅れる可能性がある．このようなケースでは，位置情報を再送したとしても，届かない可能性が高いと考えられる．そのため，この問題はACKを用いた再送制御ではなく，基地局の配置で対処すべきであると考える．

8.　今後の課題

前章では，利用者自身へのメール送信，メール送信可否判断の高度化，基地局の増設が残課題であることを述べた．本章では，本システムを実用化し，他の地域へ広く適用していく際の課題を述べる．

今回の実証では位置情報を管理したバスの台数は3台であったが，実用を考えるとより多くの台数を管理できることが望ましい．しかし，本システムでは，1回の位置情報送信に約0.5秒かかるため，位置情報送信間隔が9秒であると，単純計算でも収容可能台数の上限は18台となる．情報送信間隔を伸ばせば，収容可能台数は増やせるが，利用者がWebブラウザ上でのバスの現在位置を確認する際，現在位置の更新間隔が長くなり，利用者の体感を損なう可能性がある．今後，利用者体感と収容台数増とを両立させる方法の実現が必要である．

4.2にて説明したように，本システムでは，電波干渉を避けるために，位置情報を送信するタイミングは端末ごとに事前設定している．もし，位置情報を管理するバスの台数を増やす場合には，すべての端末を回収して，送信タイミングの設定を変更する必要がある．これは実用化を考えると大きな問題であり，その解決は今後の課題である．

今回の実証実験では利用者宅が比較的離れていたが，より人口の多い地域では，多くの利用者宅が狭いエリアに集まっているケースを想定する必要がある．その場合，メール送信からバス到着するまでに，他の利用者宅を経由することで，想定以上の時間がかかる場合が生じる．メール送信可否判断の高度化で対処できない場合，サービス内容の見直しが必要になる場合もありえる．この問題への対策の検討は今後の課題である．

今回は秋田県由利本荘市で実証を実施したが，秋田県内には広い市街地を持つ秋田市や盆地にある横手市，大仙市など，地形や建物の密度などが由利本荘市とは異なる地域が多数ある．これらの地域での実証も今後の課題である．

今回のシステムでは，ランニングコストを下げるため，携帯電話網の代わりにLoRaを利用した．LoRa自体は通信料金を払うことなく利用できるが，LoRaの基地局を自前で設置し，運用する必要がある．そのため，実用化の際には，基地局の死活監視や障害発生時の対処といった運用に関するコストを考慮する必要がある．運用コストの見積もりや，そのコスト削減は今後の課題である．

9.　おわりに

本稿では，介護施設送迎バス位置管理システムを開発し，その実証評価の結果について述べた．多くの山間部を含む由利本荘市にて本システムを運用するためには，山間部においてもLoRaで通信できる必要がある．本稿では，LoRaのパラメータとその決定方法を紹介し，LoRaのカバーエリアを拡大するための取り組み（受信感度の向上，複数箇所への基地局設置）とその結果を報告した．由利本荘市の介護施設の協力の下，実際に利用者を送迎している送迎バスを使ってフィールド評価を行い，利用者がいる由利本荘市の6地区のうち4地区（大内地区は一部のみ）にて本システムが利用できることが確認できた．また，本システムを利用した介護施設スタッフおよび利用者家族から，本システムが役立ったという多くのコメントを頂いた．これらの結果は，今後同様なシステムを他の地域に展開し，運用する際の参考になると考える．

実用化に向けては，収容可能台数の拡大，LoRaのカバーエリア拡大やメール通知の高度化などいくつかの課題が残っている．今後，これらの課題解決に取り組みたい．

謝辞　社会福祉法人中央会ふるさと学び舎様には，実証実験にご協力いただきましたことを，感謝いたします．本研究の一部は，平成30年度秋田県課題解決型介護福祉機器開発事業「介護送迎バスの位置情報連絡システムの開発」の助成を受けたものです．