JP7559823B2 - アラート通知プログラム、装置、及び方法 - Google Patents

Description

開示の技術は、アラート通知プログラム、アラート通知装置、及びアラート通知方法に関する。

従来、災害発生時に避難所に関する情報を提供する技術が存在する。例えば、災害発生時に携帯電話端末を所有する利用者に対して避難所情報を提供するシステムが提案されている。このシステムにおいて、携帯電話端末情報収集サーバは、携帯電話プロバイダから取得した情報に基づいた各携帯電話端末の位置情報を記憶し、特定の携帯電話端末の位置情報を抽出し提供する手段を備える。また、避難所情報提供サーバは、各避難所について海抜及びエリアの情報を含む避難所登録情報を予め記憶し、津波の高さを含む災害情報を取得する。また、避難所情報提供サーバは、携帯電話端末情報収集サーバから取得した特定の携帯電話端末の位置情報を利用者位置情報として用いて決定したエリアに存在し、かつ津波の高さに対して所定の十分な高低差のある海抜に位置する避難所を決定する。そして、避難所情報提供サーバは、避難所の情報を特定の携帯電話端末に対して提供する。

特開２０１３－５４５４３号公報

感染症が発生している状況において、災害避難所の受付では、検温や消毒等の手順が加わることにより、受付に時間を要する。受付に要する時間が長時間化することにより、受付待ちの混雑が誘発され、混雑の中に感染症への感染者が存在する場合に、感染拡大につながるリスクが高まってしまう。従来技術では、災害避難所における感染リスクについては考慮されていない。また、上記のような現象は、災害避難所の受付に限らず、スーパーマーケットのレジ、テーマパークへの入場等、人が集まる施設で受付が必要な状況において、同様に生じ得る。

一つの側面として、開示の技術は、受付における感染リスクのアラートを通知することを目的とする。

一つの態様として、開示の技術は、受付待ち人数の第１の推移を取得する。また、開示の技術は、感染者に関する情報、人物発生分布、及び受付の運営体制の少なくとも１つがそれぞれ異なる場合の受付待ち人数の推移の各々と、感染リスクの推移の各々との関係を参照する。そして、開示の技術は、この関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、推定した前記指標が閾値を超える場合に、アラートを通知する。

一つの側面として、受付における感染リスクのアラートを通知することができる、という効果を有する。

第１実施形態に係るアラート通知装置の機能ブロック図である。 混雑状況と感染リスクとの関係の一例を示す図である。 受付待ち人数の推移と感染リスクの推移との関係を示すシナリオの作成を説明するための図である。 受付待ち人数の推移と感染リスクの推移との関係を示すシナリオの作成を説明するための図である。 運営体制の支援情報を説明するための図である。 取得された受付待ち人数の推移に対する感染リスクの推定を説明するための図である。 受付待ち人数の観測限界を説明するための図である。 受付待ち人数が観測限界に達している場合の感染リスクの推定の一例を説明するための図である。 受付の運営体制の変更を説明するための図である。 アラート通知装置として機能するコンピュータの概略構成を示すブロック図である。 事前準備処理の一例を示すフローチャートである。 第１実施形態における運営時処理の一例を示すフローチャートである。 第２実施形態に係るアラート通知装置の機能ブロック図である。 推定モデルの機械学習を説明するための図である。 推定モデルを用いた感染リスクの推定を説明するための図である。 機械学習処理の一例を示すフローチャートである。 第２実施形態における運営時処理の一例を示すフローチャートである。 感染リスクを示す指標の他の例を説明するための図である。

以下、図面を参照して、開示の技術に係る実施形態の一例を説明する。以下の各実施形態では、感染症が発生している状況で、災害避難所等へ入場する入場者の受付における感染リスクのアラートを通知する場合について説明する。

＜第１実施形態＞
図１に示すように、第１実施形態に係るアラート通知装置１０は、機能的には、作成部１１と、取得部１３と、推定部１４と、通知部１５とを含む。また、アラート通知装置１０の所定の記憶領域には、シナリオＤＢ（Database）２１が記憶される。

作成部１１は、受付待ちの人々の感染リスクを推定するためのシナリオを作成する。ここで、感染リスクは、人口に対する感染者の数で表される感染率の大小で変化する。さらに、感染リスクは、受付待ちの入場者の混雑状況に応じて段階的に変化する。なお、本実施形態において、感染リスクは、感染者との接触の度合いに基づく指標である。

図２に、混雑状況と感染リスクとの関係の一例を示す。図２において、丸印の各々は、受付待ちの入場者の各々を表している。また、黒い丸印が感染者、網掛が付された丸印が感染者との接触者を表している。なお、接触者の定義は、例えば、感染者の半径１ｍ以内に１０秒以上存在した人等、適宜設定する。図２に示すように、混雑が生じていない状態では、入場者同士が接触しないため、感染の可能性は極めて低い。また、受付に並ぶ入場者により列が形成される場合、感染者の前後の接触者に一次元的に感染が拡大する可能性がある。また、受付待ちの入場者が面的に滞留している場合、感染者の周辺の接触者に二次元的に感染が拡大する可能性がある。上記のような混雑状況は、受付周辺の構造、受付の運営体制、受付にどのタイミングでどれだけの入場者が集まるか等に応じて変化する。

そこで、作成部１１は、感染を考慮した人流シミュレーションにより、多数のケースを事前に解析して、各ケースにおける受付待ち人数の推移と、その受付待ち人数が生じる場合における感染リスクの推移とをシナリオとして作成する。なお、シナリオは、開示の技術の「受付待ち人数の推移の各々と、感染リスクの推移の各々との関係」の一例である。各ケースは、各運営体制について、感染者に関する情報及び受付周辺における入場者発生分布の少なくとも一方がそれぞれ異なる場合に相当する。運営体制は、受付の数、受付の配置、受付毎の要員数等の要因を含む。感染者に関する情報は、感染率、受付周辺に発生させる感染者の配置及びタイミング（以下、「感染者の初期配置」という）等である。入場者発生分布は、受付周辺に入場者を発生させる配置、タイミング、その配置及びタイミング毎の発生人数等である。なお、入場者発生分布は、開示の技術の「人物発生分布」の一例である。

具体的には、作成部１１は、上記の感染者の初期配置、入場者発生分布、及び運営体制を含むシミュレーション条件をそれぞれ異ならせて、多数のパターンについて、受付周辺の人流をシミュレーションする。より具体的には、作成部１１は、各シミュレーションにおいて、受付周辺の道路や建物の形状等の構造に基づいて、入場者が存在可能な位置に、入場者発生分布に従って入場者に相当するオブジェクト（以下、単に「入場者」という）を発生させ、受付に移動させる。また、作成部１１は、発生させた入場者のうち、感染率に基づく数の入場者であって、例えば乱数によって決定した入場者を、感染者の初期配置に基づいて感染者に設定する。さらに、作成部１１は、受付の運営体制に応じた各入場者の受付時間を考慮して、受付に到達した入場者を受付で一時停止させたうえで、受付を通過させる。

なお、感染率は、人口に対する地域の感染者数等から、適切な値を設定する。例えば、対象自治体Ｘ市の人口に対する、Ｘ市の現在の感染者数の割合に、安全係数（例えば、１０）を乗算した値を感染率とする。シミュレーションで発生させる入場者の総数に感染率を掛け合わせた数が感染者数となる。例えば、Ｘ市の感染者が６００人、Ｘ市の人口が１５０万人で、安全係数を１０とすると、感染者率は０．００４であり、入場者が５００人とすると、感染者は２人となる。また、人の移動速度等、人流シミュレーションに必要な一般的な他のパラメータは適宜設定すればよい。

作成部１１は、シミュレーション結果に基づいて、例えば、図３上図に示すような、シミュレーションの時間経過に伴う受付待ち人数の推移を求める。受付待ち人数は、各時間において発生している入場者のうち、受付通過前の入場者の数である。また、作成部１１は、シミュレーション結果に基づいて、入場者毎に、例えば、感染者を中心とした半径１ｍ以内にいる時間を接触時間として計測し、各時間における接触時間の全入場者分の合計を述べ接触時間として計算する。そして、作成部１１は、図３下図に示すような、シミュレーションの時間経過に伴う延べ接触時間の推移を求める。なお、図３に示すように、シミュレーション条件として、入場者分布が固定の場合、感染者の初期配置を変更しても、受付待ち人数の推移はシミュレーション毎に変化しない。一方、感染者の初期配置が異なる場合には、延べ接触時間の推移（図３下図の点線）はシミュレーション毎に変化する。そこで、作成部１１は、入場者分布及び運営体制の条件を固定して、感染者の初期配置を変更した複数のシミュレーション条件を、シミュレーションの１パターンとする。作成部１１は、各パターンのシミュレーション毎に計算した延べ接触時間の各時間における平均をとり、そのパターンについての延べ接触時間の平均の推移（図３下図の実線）を求める。

作成部１１は、図４に示すように、シミュレーションのパターン毎に求めた受付待ち人数の推移、及び延べ接触時間の平均の推移から、一人当たりの延べ接触時間の推移を求める。具体的には、作成部１１は、時間ｔの受付待ち人数をＮ（ｔ）、時間ｔの延べ接触時間の平均をＴ＿ａｌｌ（ｔ）とすると、時間ｔの一人当たりの延べ接触時間をＴ＿ａｌｌ（ｔ）／Ｎ（ｔ）として求める。本実施形態では、この一人当たりの延べ接触時間を、感染リスクを示す指標として用いる。なお、感染リスクを示す指標は、この例に限定されず、各入場者と感染者との接触の度合いに基づく指標であればよい。

作成部１１は、シミュレーションのパターン毎に求めた受付待ち人数の推移と、一人当たりの延べ接触時間、すなわち感染リスクの推移とをセットにしたシナリオを、入場者分布及び運営体制の各々の条件を異ならせたシミュレーションのパターン毎に作成する。作成部１１は、作成したシナリオをシナリオＤＢ２１に記憶する。図４の例では、ある運営体制について、入場者分布Ａ、Ｂ、及びＣの３つの異なる入場者分布の条件について、３つのシナリオが作成されることを表しているが、シナリオＤＢ２１にはより多くのシナリオが記憶される。例えば、感染率は固定とし、感染者の初期配置の条件を１００パターン、入場者分布の条件を１００パターン、運営体制の条件を１０パターンとする。この場合、作成部１１は、１０００パターン（入場者分布１００パターン×運営体制１０パターン）について、１００回（感染者の初期配置１００パターン）のシミュレーションを実行することになる。そして、この場合、シナリオＤＢ２１には、１０００個のシナリオが記憶されることになる。

また、作成部１１は、図５に示すように、作成したシナリオから、特定の入場者分布についての運営体制毎のシナリオを抽出し、支援情報としてシナリオＤＢ２１に記憶する。図５の例では、運営体制Ａ、Ｂ、及びＣについて３つのシナリオを支援情報として抽出した場合を表しているが、支援情報に含める運営体制毎のシナリオは、２つであってもよいし、４つ以上であってもよい。運営体制の条件を１０パターン用意した場合には、１０パターン分のシナリオを含めてもよい。

取得部１３は、各時間における実際の受付待ち人数を取得する。例えば、取得部１３は、受付周辺をカメラで撮影したカメラ画像を取得し、カメラ画像を画像解析することにより、カメラ画像に映っている入場者の人数をカウントし、受付待ち人数を取得する。カメラ画像から入場者の人数をカウントする画像解析の方法は、従来既知の手法を用いることができるため、ここでは詳細な説明を省略する。なお、カメラは、開示の技術の「センシングデバイス」の一例である。取得部１３は、時間毎に取得した受付待ち人数を記憶しておくことにより、現時点までの所定期間における、受付待ち人数の推移を取得する。

推定部１４は、シナリオＤＢ２１に記憶されたシナリオに基づいて、取得部１３により取得された受付待ち人数の推移に対する、現時点以降の１以上の時点における感染リスクを推定する。具体的には、推定部１４は、図６に示すように、シナリオＤＢ２１に記憶されたシナリオのうち、現在の運営体制についてのシナリオであって、取得された受付待ち人数の推移に対応するシナリオを特定する。例えば、推定部１４は、取得された受付待ち人数の推移と、各シナリオに含まれる受付待ち人数の推移とで、最小二乗法等によりマッチングを行う。そして、推定部１４は、取得された受付待ち人数の推移と最もマッチする部分を有する受付待ち人数の推移を含むシナリオを特定する。この際、推定部１４は、マッチングにより、取得された受付待ち人数の推移と、シナリオに含まれる受付待ち人数の推移とで時間軸の対応をとり、取得された受付待ち人数の推移の現時点に対応する、シナリオに含まれる受付待ち人数の推移における時間（図６における「ｔ＝ｎｏｗ」）を特定する。

推定部１４は、特定したシナリオに含まれる感染リスクの推移において、例えば、現時点における感染リスクＴ_ｎｏｗと、現時点から所定時間α後の感染リスクＴ_＋αとを、取得された受付待ち人数の推移に対する感染リスクとして推定する。図６の例では、推定部１４は、Ｔ_ｎｏｗと共に、α＝１０分として、現時点から１０分後の感染リスクＴ_＋１０を推定している。

なお、受付周辺の構造及びカメラの撮影範囲によっては、図７の上図に示すように、受付に向かって集まっている入場者が存在する全領域を撮影できない場合がある。すなわち、カメラによって観測可能な入場者の数には限界がある。そのため、図７の下図に示すように、取得部１３に取得される受付待ち人数が、観測限界値に達して、本来の値（図７下図中の破線部分）を示さない場合がある。このような場合、推定部１４は、図８に示すように、シナリオに含まれる受付待ち人数の推移の各々についても、観測限界値以上の値を観測限界値に変換した上で、取得された受付待ち人数の推移とマッチングを行えばよい。又は、推定部１４は、取得した受付待ち人数の推移のうち、受付待ち人数が観測限界値に達した時点以前の受付待ち人数の推移を用いて、シナリオに含まれる受付待ち人数の推移の各々とのマッチングを行ってもよい。

通知部１５は、推定部１４により推定された感染リスクが予め定めた閾値を超える場合に、アラートを通知する。推定部１４により、現時点以降の複数の時点の感染リスクが推定されている場合、通知部１５は、いずれの時点の感染リスクが閾値を超えているかに応じて、異なるアラートを通知してもよい。例えば、現時点の感染リスクＴ_ｎｏｗと１０分後の感染リスクＴ_＋１０とが推定されている場合、通知部１５は、Ｔ_ｎｏｗが閾値Ｔｔｈを超えている場合には、緊急性の高いアラートを通知する。また、通知部１５は、Ｔ_ｎｏｗは閾値Ｔｔｈを超えていないが、Ｔ_＋１０が閾値Ｔｔｈを超えている場合には、１０分後には感染リスクが閾値を超えることを予告するアラートを通知する。

通知部１５は、アラートを、例えば、受付の運営担当者が保持するスマートフォン、タブレット端末、パーソナルコンピュータ等の情報処理端末へ通知する。この際、通知部１５は、シナリオＤＢ２１に記憶されている支援情報をアラートと共に通知する。上述したように、支援情報は、図５に示すような、特定の入場者分布についての運営体制毎のシナリオである。例えば、図９上段の図に示すように、受付が１つの場合、その受付に入場者が集中するため、混雑が生じ、感染リスクが高まる。また、図９中段の図に示すように、受付を複数に分けた場合、入場者が分散するため、受付が１つの場合に比べ、混雑が緩和し、感染リスクが低下する。さらに、図９下段の図に示すように、受付前の入場者の待機場所を設け、複数に分けた受付に時間差で誘導する場合、さらに混雑が緩和し、感染リスクが低下する。支援情報である特定の入場者分布についての運営体制毎のシナリオは、上記のような運営体制の違いによる感染リスクの程度を定量的に把握することができる。運営担当者は、この支援情報に基づいて、例えば費用対効果等を考慮し、混雑の緩和が見込める適切な運営体制を決定する。適切な運営体制に変更することにより、混雑が緩和され、感染リスクの低下が図られる。

また、通知部１５は、アラートを、受付に集まる入場者が保持するスマートフォン、タブレット端末、パーソナルコンピュータ等の情報処理端末へ通知してもよい。この場合、通知部１５は、例えば、現在感染リスクが高いため、来場を控えるように促すメッセージを通知する。

アラート通知装置１０は、例えば図１０に示すコンピュータ４０で実現することができる。コンピュータ４０は、ＣＰＵ（Central Processing Unit）４１と、一時記憶領域としてのメモリ４２と、不揮発性の記憶部４３とを備える。また、コンピュータ４０は、入力部、表示部等の入出力装置４４と、記憶媒体４９に対するデータの読み込み及び書き込みを制御するＲ／Ｗ（Read/Write）部４５とを備える。また、コンピュータ４０は、インターネット等のネットワークに接続される通信Ｉ／Ｆ（Interface）４６を備える。ＣＰＵ４１、メモリ４２、記憶部４３、入出力装置４４、Ｒ／Ｗ部４５、及び通信Ｉ／Ｆ４６は、バス４７を介して互いに接続される。

記憶部４３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部４３には、コンピュータ４０を、後述する事前準備処理及び運営時処理を実行するアラート通知装置１０として機能させるためのアラート通知プログラム５０が記憶される。アラート通知プログラム５０は、作成プロセス５１と、取得プロセス５３と、推定プロセス５４と、通知プロセス５５とを有する。また、記憶部４３は、シナリオＤＢ２１を構成する情報が記憶される情報記憶領域６０を有する。

ＣＰＵ４１は、アラート通知プログラム５０を記憶部４３から読み出してメモリ４２に展開し、アラート通知プログラム５０が有するプロセスを順次実行する。ＣＰＵ４１は、作成プロセス５１を実行することで、図１に示す作成部１１として動作する。また、ＣＰＵ４１は、取得プロセス５３を実行することで、図１に示す取得部１３として動作する。また、ＣＰＵ４１は、推定プロセス５４を実行することで、図１に示す推定部１４として動作する。また、ＣＰＵ４１は、通知プロセス５５を実行することで、図１に示す通知部１５として動作する。また、ＣＰＵ４１は、情報記憶領域６０から情報を読み出して、シナリオＤＢ２１をメモリ４２に展開する。これにより、アラート通知プログラム５０を実行したコンピュータ４０が、アラート通知装置１０として機能することになる。なお、プログラムを実行するＣＰＵ４１はハードウェアである。

なお、アラート通知プログラム５０により実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit）等で実現することも可能である。

次に、第１実施形態に係るアラート通知装置１０の作用について説明する。まず、アラート通知装置１０が、図１１に示す事前準備処理を実行する。そして、実際の受付運営時には、アラート通知装置１０が、図１２に示す運営時処理を実行する。なお、事前準備処理及び運営時処理は、開示の技術のアラート通知方法の一例である。

まず、図１１を参照して、事前準備処理について説明する。ステップＳ１１で、作成部１１が、複数パターン（例えば、１０パターン）用意された運営体制から、１つの運営体制を選択し、シミュレーションの条件として設定する。次に、ステップＳ１２で、作成部１１が、複数パターン（例えば、１０００パターン）用意された入場者分布から、１つの入場者分布を選択し、シミュレーションの条件として設定する。次に、ステップＳ１３で、作成部１１が、感染者の初期配置を乱数で決定し、シミュレーションの条件として設定する。

次に、ステップＳ１４で、作成部１１が、上記ステップＳ１１～Ｓ１３で設定された条件と、予め指定された感染率及び受付周辺の構造とに基づいて、受付周辺の人流をシミュレーションする。次に、ステップＳ１５で、作成部１１が、シミュレーション結果に基づいて、受付待ち人数の推移、及び述べ接触時間を計算する。

次に、ステップＳ１６で、作成部１１が、感染者の初期配置の変更回数が必要回数（例えば、１００回）に到達したか否かを判定する。必要回数に到達している場合には、処理はステップＳ１７へ移行し、到達していない場合には、処理はステップＳ１３に戻る。ステップＳ１７では、作成部１１が、シミュレーション毎に計算した延べ接触時間の各時間における平均をとり、延べ接触時間の平均の推移を求める。また、作成部１１が、上記ステップＳ１５で計算した受付待ち人数の推移と、本ステップで求めた延べ接触時間の平均の推移とから、一人当たりの延べ接触時間の推移を感染リスクとして求める。そして、作成部１１が、受付待ち人数の推移と、感染リスクの推移とをセットにしたシナリオを、上記ステップＳ１１で設定した運営体制、及び上記ステップＳ１２で設定した入場者分布が示すパターンのシナリオをとしてシナリオＤＢ２１に記憶する。

次に、ステップＳ１８で、作成部１１が、入場者分布の全パターンについて処理が終了したか否かを判定する。未処理の入場者分布のパターンが存在する場合には、処理はステップＳ１２に戻り、作成部１１が未処理の入場者分布を選択して、Ｓ１２以降の処理を繰り返す。一方、入場者分布の全パターンの処理が終了した場合、処理はステップＳ１９へ移行する。ステップＳ１９では、作成部１１が、運営体制の全パターンについて処理が終了したか否かを判定する。未処理の運営体制のパターンが存在する場合には、処理はステップＳ１１に戻り、作成部１１が未処理の運営体制を選択して、Ｓ１１以降の処理を繰り返す。一方、運営体制の全パターンの処理が終了した場合、処理はステップＳ２０へ移行する。この段階で、運営体制及び入場者分布の各々が異なるパターン毎のシナリオがシナリオＤＢ２１に記憶されている。次に、ステップＳ２０で、作成部１１が、作成したシナリオから、特定の入場者分布についての運営体制毎のシナリオを抽出し、支援情報としてシナリオＤＢ２１に記憶する。そして、事前準備処理は終了する。

次に、図１２を参照して、運営時処理について説明する。ステップＳ２１で、取得部１３が、受付周辺をカメラで撮影したカメラ画像を取得し、カメラ画像を画像解析することにより、カメラ画像に映っている入場者の人数をカウントすることにより、受付待ち人数を取得する。

次に、ステップＳ２２で、推定部１４が、シナリオＤＢ２１に記憶されたシナリオのうち、現在の運営体制についてのシナリオを抽出する。そして、推定部１４が、抽出したシナリオの中から、取得された現時点（ｔ＝ｎｏｗ）までの受付待ち人数の推移と最もマッチする部分を有する受付待ち人数の推移を含むシナリオを特定する。次に、ステップＳ２３で、推定部１４が、上記ステップＳ２２で特定したシナリオに含まれる感染リスクの推移から、上記ステップＳ２１で取得された受付待ち人数の推移に対する感染リスクを推定する。ここでは、推定部１４は、現時点の感染リスクＴ_ｎｏｗと、現時点から１０分後の感染リスクＴ_＋１０とを推定するものとする。

次に、ステップＳ２４で、通知部１５が、上記ステップＳ２３で推定された感染リスクＴ_ｎｏｗが閾値Ｔｔｈを超えているか否かを判定する。Ｔ_ｎｏｗ＞Ｔｔｈの場合、処理はステップＳ２５へ移行し、通知部１５が、感染リスクが既に閾値を超えていることを示す緊急アラートを通知する。一方、Ｔ_ｎｏｗ≦Ｔｔｈの場合、処理はステップＳ２６へ移行し、通知部１５が、上記ステップＳ２３で推定された感染リスクＴ_＋１０が閾値Ｔｔｈを超えているか否かを判定する。Ｔ_＋１０＞Ｔｔｈの場合、処理はステップＳ２７へ移行し、通知部１５が、１０分後には感染リスクが閾値を超えることを予告する予告アラートを通知する。一方、Ｔ_＋１０≦Ｔｔｈの場合、アラートは通知されることなく、処理はステップＳ２１に戻る。次に、ステップＳ２８で、通知部１５が、シナリオＤＢ２１に記憶されている、特定の入場者分布についての運営体制毎のシナリオである支援情報を通知し、処理はステップＳ２１に戻る。

以上説明したように、第１実施形態に係るアラート通知装置は、感染者に関する情報、入場者発生分布、及び受付の運営体制の各々の条件を設定して、感染者の配置を含む受付周辺の人流をシミュレーションする。アラート通知装置は、このシミュレーション結果に基づいて、受付待ち人数の推移の各々と、感染リスクの推移の各々との関係を示すシナリオを作成する。そして、アラート通知装置は、現時点までの受付待ち人数の推移を取得し、シナリオのうち、取得した受付待ち人数の推移に最もマッチするシナリオを特定する。アラート通知装置は、特定したシナリオに含まれる感染リスクの推移から、取得した受付待ち人数の推移に対する現時点以降の１以上の時点における感染リスクを推定し、推定した感染リスクが予め定めた閾値を超える場合に、アラートを通知する。これにより、受付における感染リスクのアラートを通知することができる。

また、アラート通知装置は、アラートの通知と共に、運営体制毎の、受付人数の推移と感染リスクの推移との関係を示すシナリオを、運営体制の支援情報として通知する。この定量的な支援情報を根拠として、適切な運営体制を選択し、受付運営のコストと、感染リスク低減とを両立した受付運営が可能となる。

＜第２実施形態＞
次に、第２実施形態について説明する。なお、第２実施形態に係るアラート通知装置において、第１実施形態に係るアラート通知装置１０と同様の構成については、同一符号を付して詳細な説明を省略する。

図１３に示すように、第２実施形態に係るアラート通知装置２１０は、機能的には、作成部１１と、機械学習部２１２と、取得部１３と、推定部２１４と、通知部１５とを含む。また、アラート通知装置２１０の所定の記憶領域には、シナリオＤＢ２１と、推定モデル２２２とが記憶される。

機械学習部２１２は、シナリオＤＢ２１に記憶されたシナリオから学習データを生成し、生成した学習データを用いて、取得された受付待ち人数の推移に対する、現時点以降の１以上の時点における感染リスクを推定するための推定モデル２２２を機械学習する。なお、推定モデルは、開示の技術の「モデル」の一例である。

具体的には、図１４に示すように、機械学習部２１２は、シナリオに含まれる受付待ち人数の推移から、複数の時点までの部分の各々を抽出する。図１４では、時間ｔ１までの部分、時間ｔ３までの部分、時間ｔ５までの部分、・・・が抽出された例を示している。また、機械学習部２１２は、受付待ち人数の推移に対応する感染リスクの推移における、上記の複数の時点及び複数の時点から所定時間後の時点における感染リスクの値を抽出する。図１４では、時間ｔ１、ｔ３、ｔ５、・・・と、それぞれの１０分後の時間ｔ２、ｔ４、ｔ６、・・・の感染リスクＴ_ｔ１、Ｔ_ｔ２、Ｔ_ｔ３、Ｔ_ｔ４、Ｔ_ｔ５、Ｔ_ｔ６、・・・が抽出された例を示している。機械学習部２１２は、運営体制のパターン毎に、抽出したある時点までの受付待ち人数の推移の部分と、その時点及びその時点以降の時点における感染リスクの値との複数の組を学習データとして生成する。そして、機械学習部２１２は、生成した運営体制のパターン毎の学習データを用いて、例えばニューラルネットワーク等で構成された推定モデル２２２のパラメータを機械学習する。これにより、受付待ち人数の推移を入力することにより、現時点及び現時点から所定時間後の時点における感染リスクの推定結果を出力する、運営体制毎の推定モデル２２２が構築される。機械学習部２１２は、構築した推定モデル２２２を所定の記憶領域に記憶する。

推定部２１４は、図１５に示すように、取得部１３により取得された受付待ち人数の推移を、現在の運営体制についての推定モデル２２２に入力する。これにより、推定部２１４は、推定モデル２２２から出力される、現時点及び現時点から所定時間後の時点における感染リスクの推定結果を取得する。図１５では、現時点（ｔ＝ｎｏｗ）までの受付待ち人数の推移から、現時点における感染リスクＴ_ｎｏｗ、及び現時点から１０分後の時点における感染リスクＴ_＋１０の推定結果が取得される例を示している。

アラート通知装置２１０は、例えば図１０に示すコンピュータ４０で実現することができる。コンピュータ４０の記憶部４３には、コンピュータ４０を、事前準備処理、後述する機械学習処理、及び運営時処理を実行するアラート通知装置２１０として機能させるためのアラート通知プログラム２５０が記憶される。アラート通知プログラム２５０は、作成プロセス５１と、機械学習プロセス２５２と、取得プロセス５３と、推定プロセス２５４と、通知プロセス５５とを有する。また、記憶部４３は、シナリオＤＢ２１及び推定モデル２２２の各々を構成する情報が記憶される情報記憶領域２６０を有する。

ＣＰＵ４１は、アラート通知プログラム２５０を記憶部４３から読み出してメモリ４２に展開し、アラート通知プログラム２５０が有するプロセスを順次実行する。ＣＰＵ４１は、機械学習プロセス２５２を実行することで、図１３に示す機械学習部２１２として動作する。また、ＣＰＵ４１は、推定プロセス２５４を実行することで、図１３に示す推定部２１４として動作する。また、ＣＰＵ４１は、情報記憶領域２６０から情報を読み出して、シナリオＤＢ２１及び推定モデル２２２の各々をメモリ４２に展開する。他のプロセスについては、第１実施形態に係るアラート通知プログラム５０と同様である。これにより、アラート通知プログラム２５０を実行したコンピュータ４０が、アラート通知装置２１０として機能することになる。なお、アラート通知プログラム２５０により実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。

次に、第２実施形態に係るアラート通知装置２１０の作用について説明する。まず、アラート通知装置２１０が、第１実施形態と同様に、図１１に示す事前準備処理を実行する。さらに、第２実施形態では、実際の運営の前に、アラート通知装置２１０が、図１６に示す機械学習処理を実行する。そして、実際の受付運営時には、アラート通知装置２１０が、図１７に示す運営時処理を実行する。なお、事前準備処理、機械学習処理、及び運営時処理は、開示の技術のアラート通知方法の一例である。

まず、図１６を参照して、機械学習処理について説明する。ステップＳ３１で、機械学習部２１２が、複数パターン（例えば、１０パターン）用意された運営体制から、１つの運営体制を選択する。次に、ステップＳ３２で、機械学習部２１２が、シナリオＤＢ２１から、選択した運営体制についてのシナリオを抽出する。

次に、ステップＳ３３で、機械学習部２１２が、抽出したシナリオの各々に含まれる受付待ち人数の推移の各々から、時間ｔｉ（ｔｉは複数の異なる時間）の時点までの部分を抽出する。また、機械学習部２１２が、受付待ち人数の推移に対応する感染リスクの推移における、時間ｔｉの時点及び時間ｔｉから所定時間後（ここでは１０分後の時間ｔｉ＋１０とする）の時点における感染リスクの値Ｔ_ｔｉ及びＴ_{ｔｉ＋１０}を抽出する。そして、機械学習部２１２が、時間ｔｉの時点までの受付待ち人数の推移の部分と、感染リスクの値Ｔ_ｔｉ及びＴ_{ｔｉ＋１０}との複数の組を学習データとして生成する。

次に、ステップＳ３４で、機械学習部２１２が、生成した学習データを用いて推定モデル２２２のパラメータを機械学習する。そして、機械学習部２１２が、パラメータが機械学習された推定モデル２２２を、上記ステップＳ３１で選択した運営体制のパターンと対応付けて所定の記憶領域に記憶する。次に、ステップＳ３５で、機械学習部２１２が、運営体制の全パターンについて処理が終了したか否かを判定する。未処理の運営体制のパターンが存在する場合には、処理はステップＳ３１に戻り、機械学習部２１２が未処理の運営体制を選択して、Ｓ３１以降の処理を繰り返す。一方、運営体制の全パターンの処理が終了した場合、機械学習処理は終了する。

次に、図１７を参照して、第２実施形態における運営時処理について説明する。なお、第２実施形態における運営時処理について、第１実施形態における運営時処理と同様の処理については、同一のステップ番号を付して詳細な説明を省略する。

ステップＳ２１で、取得部１３が、受付待ち人数を取得する。次に、ステップＳ２２２で、推定部２１４が、取得部１３により取得された受付待ち人数の推移を、現在の運営体制についての推定モデル２２２に入力する。これにより、推定部２１４が、推定モデル２２２から出力される感染リスクの推定結果（Ｔ_ｔｉ及びＴ_{ｔｉ＋１０}）を取得する。そして、以降、第１実施形態と同様に、ステップＳ２４～Ｓ２８の処理が実行される。

以上説明したように、第２実施形態に係るアラート通知装置は、第１実施形態と同様に作成した受付待ち人数の推移の各々と、感染リスクの推移の各々との関係を示すシナリオから学習データを生成し、推定モデルを機械学習する。そして、アラート通知装置は、現時点までの受付待ち人数の推移を取得し、推定モデルに入力することにより、取得した受付待ち人数の推移に対する現時点以降の１以上の時点における感染リスクを推定する。そして、アラート通知装置は、推定した感染リスクが予め定めた閾値を超える場合に、アラートを通知する。これにより、第１実施形態と同様に、受付における感染リスクのアラートを通知することができる。

なお、上記各実施形態では、感染リスクを示す指標として、一人当たりの延べ接触時間を用いる場合について説明したが、これに限定されない。例えば、図１８に示すように、作成部は、シミュレーション結果から、受付待ちの人数及び延べ接触時間と共に、感染者との接触時間毎の接触者数を計算する。図１８では、接触時間毎の接触者数の一例として、接触者と１０秒以上接触している接触者数を計算した例を示している。そして、作成部は、現時点以降の１以上の時点における、閾値となる接触時間の接触者数を、感染リスクを示す指標としてもよい。この感染リスクを示す指標を用いることにより、一定時間以上感染者との接触がある接触者の数の増加による感染リスクの拡大を予測することができる。なお、図１８の例では、時間を横軸、接触時間を縦軸、接触時間毎の人数を濃度で表しており、現時点及び１０分後の時点における、１００時間以上の接触者数を感染リスクを示す指標とする場合を示している。

また、上記各実施形態では、運営体制の支援情報を、アラートの通知と共に通知する場合について説明したが、これに限定されない。運営体制の支援情報は、受付の運営を開始する前における運営体制の決定時にも有用な情報として利用することができる。

また、上記各実施形態では、開示の技術を、災害避難所の受付の運営に適用した場合について説明したが、これに限定されない。開示の技術は、スーパーマーケットのレジ、テーマパークへの入場等、人が集まる受付業務に対して適用可能である。

また、上記各実施形態では、アラート通知プログラムが記憶部に予め記憶（インストール）されている態様を説明したが、これに限定されない。開示の技術に係るプログラムは、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリ等の記憶媒体に記憶された形態で提供することも可能である。

１０、２１０ アラート通知装置
１１ 作成部
２１２ 機械学習部
１３ 取得部
１４、２１４ 推定部
１５ 通知部
２１ シナリオＤＢ
２２２ 推定モデル
４０ コンピュータ
４１ ＣＰＵ
４２ メモリ
４３ 記憶部
４９ 記憶媒体
５０、２５０ アラート通知プログラム

Claims (9)

1. 受付待ち人数の第１の推移を取得し、
   感染者に関する情報、人物発生分布、及び受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された複数の受付待ち人数の推移の各々と、前記複数の受付待ち人数の推移の各々に対応する複数の感染リスクの推移の各々との関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、
   推定した前記指標が閾値を超える場合に、アラートを通知する、
   ことを含む処理をコンピュータに実行させることを特徴とするアラート通知プログラム。
2. 前記推定する処理は、特定された前記受付待ち人数の推移毎の前記関係のうち、前記受付待ち人数の第１の推移に対応する特定の関係を特定する処理を含む、
   ことを特徴とする請求項１に記載のアラート通知プログラム。
3. 前記推定する処理は、特定された前記受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいた機械学習により生成したモデルを用いて、前記受付待ち人数の第１の推移に対する現時点以降の１以上の時点における感染リスクを示す指標を推定する処理を含む、
   ことを特徴とする請求項１に記載のアラート通知プログラム。
4. 前記感染者に関する情報の条件は、感染率と、前記受付周辺に発生させる感染者の初期配置とを含み、
   前記人物発生分布の条件は、前記受付周辺に人物を発生させる配置と、タイミングと、前記配置及び前記タイミング毎の発生人数とを含み、
   前記受付の運営体制の条件は、受付の数、受付の配置、及び受付毎の要員数の少なくとも１つを含み、
   前記推定する処理は、前記人物発生分布の条件、及び前記受付の運営体制の条件の各々を異ならせたパターン毎に、前記感染率を設定し、かつ前記感染者の初期配置の条件を異ならせて前記受付周辺の人流をシミュレーションして得られる前記感染リスクの推移の各々の平均に基づいて、前記パターン毎の前記関係を特定する処理を含む、
   ことを特徴とする請求項２又は請求項３に記載のアラート通知プログラム。
5. 前記パターン毎に特定した前記関係のうち、特定の前記人物発生分布の条件についての前記受付の運営体制毎のパターンについて特定された前記関係を通知する、
   ことを含む処理を前記コンピュータに実行させることを特徴とする請求項４に記載のアラート通知プログラム。
6. 前記受付待ち人数の推移を取得する処理は、センシングデバイスが検知した前記受付待ち人数を取得する処理を含み、
   前記推定する処理は、検出された前記受付待ち人数が、前記センシングデバイスの観測限界値に到達している場合、前記関係における前記受付待ち人数の推移の各々の上限を前記観測限界値に変換するか、又は、取得した前記受付待ち人数の第１の推移のうち、前記受付待ち人数が前記観測限界値に到達した時点以前の前記受付待ち人数の推移を用いて、前記感染リスクを示す指標を推定する、
   ことを特徴とする請求項１～請求項５のいずれか１項に記載のアラート通知プログラム。
7. 前記感染リスクを示す指標は、感染者との接触の度合いに基づく指標である、
   ことを特徴とする請求項１～請求項６のいずれか１項に記載のアラート通知プログラム。
8. 受付待ち人数の第１の推移を取得し、
   感染者に関する情報、人物発生分布、及び受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された複数の受付待ち人数の推移の各々と、前記複数の受付待ち人数の推移の各々に対応する複数の感染リスクの推移の各々との関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、
   推定した前記指標が閾値を超える場合に、アラートを通知する、
   ことを含む処理を実行する制御部を含むことを特徴とするアラート通知装置。
9. 受付待ち人数の第１の推移を取得し、
   感染者に関する情報、人物発生分布、及び受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された複数の受付待ち人数の推移の各々と、前記複数の受付待ち人数の推移の各々に対応する複数の感染リスクの推移の各々との関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、
   推定した前記指標が閾値を超える場合に、アラートを通知する、
   ことを含む処理をコンピュータが実行することを特徴とするアラート通知方法。