JP2024042829A - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】比較的簡単な構成により車内に人が取り残されることを防止できる情報処理装置、方法及びプログラムを提供する【解決手段】管理サーバと、バス内の施設端末とが、ネットワークを介して通信可能に接続されている管理システムにおいて、車内の見回りを促すための情報処理装置である施設端末３０は、車両のエンジンの稼働を検知する検知部３４と、検知部３４の検知結果に応じて、警告を出力する音声出力部３７と、近接して識別情報を読み取る撮像制御部３６とを有する。音声出力部３７は、撮像制御部３６が識別情報が読み取ると、警告を停止する。【選択図】図３

Description

本開示は、情報処理装置、情報処理方法、及びプログラムに関する。

従来、車両内に子供が置き去りにされていることを検知し、警報を行う置き去り防止システムが知られている。特許文献１には、前方座席（運転席や助手席）から人が離れる離席状態が発生したか否かを検知し、離席状態の発生を検知した時に、車室内の検知エリア内の物体が人であると判定されると警報を出力する乗員状態検知システムが記載されている。

特開２０２０－１０１４１５

しかしながら、センサやカメラなどの機器により自動的に乗員状態を検知するシステムでは、システムが正確に遂行されるようにするため、機器の設置やメンテナンスの負荷が高くなってしまう。

そこで、本開示の一側面は、比較的簡単な構成により車内に人が取り残されることを防止できる情報処理装置を提供することを目的とする。

本開示の一側面に係る装置は、車内の見回りを促すための情報処理装置であって、車両のエンジンの稼働を検知する検知手段と、前記検知手段の検知結果に応じて、警告を出力する出力手段と、近接して識別情報を読み取る読み取り手段とを有し、前記出力手段は、前記読み取り手段により前記識別情報が読み取られると、前記警告を停止することを特徴とする。

本開示の一側面によれば、比較的簡単な構成により車内に人が取り残されることを防止できる情報処理装置を提供することができる。

一実施形態に係る管理システムの構成を示す図である。 管理サーバ及び施設端末のハードウェア構成の一例を示す図である。 管理システムの機能構成図である。 施設テーブルの一例を示す図である。 見回り促進処理のフローチャートである。 表示画像の一例を示す図である。 自動監視処理のフローチャートである。 要否判定処理のフローチャートである。 乗車登録処理のフローチャートである。

以下、添付図面を参照して、本開示の一実施形態について詳細に説明する。図面の説明において同一又は相当要素には同一符号を付し、重複する説明を省略する。尚、以下の実施形態は本開示の技術を限定するものではなく、また、本実施形態で説明されている特徴の組み合わせの全てが上記課題の解決手段に必須のものとは限らない。

［第１の実施形態］
＜管理システム１の構成例＞
第１の実施形態では、バス内においてバス車内の見回りを促進するためのシステムについて説明する。

図１は、一実施形態に係る管理システム１の全体構成を示す図である。図１に示されるように、管理システム１は、管理サーバ１０と、バス２０内の施設端末３０とを含んで構成されている。バス２０は、例えば幼稚園や保育園などの施設Ａが送迎に利用するための乗り物である。バス２０には、前方の座席（運転席や助手席）の付近に施設端末３０が取り外し可能なように設置され、バス２０の後方（リアウインドウや最後列座席の背面など）には、ＱＲコード（登録商標）が印字されたカード（印刷物）が掲示されている。ＱＲコードは、バス２０を運営する施設Ａに固有に与えられた識別情報をコード化した情報である。なお、本実施形態ではＱＲコードを用いるが、施設端末３０が近接して読み取り可能なコードであれば、他の二次元コードでもよいし、一次元バーコードでもよい。

管理サーバ１０と施設端末３０は、ネットワーク５０を介して通信可能に接続されている。ネットワーク５０は、有線又は無線の任意の通信ネットワークであり、例えば、インターネット、公衆回線網、専用回線網等である。

施設端末３０は、バス３０の運営に携わるスタッフ（運転手や付き添いの先生など）によって利用される情報処理装置であり、例えば、スマートフォンやタブレットなど端末である。施設端末３０は、カーチャージャーやシガーソケットを介してバス２０と有線で接続され、エンジンの起動と連動してバス２０から給電されるものとする。施設端末３０は、給電状況の監視することによりバス２０のエンジン起動や停止を検知する検知機能を有する。

また、施設端末３０は、車内の見回りを促すための見回り促進機能を有する。施設端末３０は、見回り促進機能として、見回りを促す画面用ユーザインターフェース（ＧＵＩ）を表示しつつ、エンジンの停止を検知した後、所定時間経過すると、警告を出力する。また、バス２０のエンジンが停止された後、スタッフにより警告を停止するための警告停止操作を行われると、施設端末３０は警告を停止する。本実施形態において、警告停止操作は、施設端末３０のカメラ（撮像部）を起動して、バス２０の後方に掲示されたＱＲコードを施設端末３０で読み込む操作である。つまりスタッフは、バス２０のエンジンを停止した後、施設端末３０を携帯してバス車内の見回りをしながら後方に行き、後方のＱＲコードを施設端末３０で読み込むと、警告を停止、あるいは、事前に警告が出力されないように警告を解除することができる。

管理サーバ１０は、施設端末３０から受信した情報に基づいて、バス２０に関する情報を格納するデータベースを更新したり、警告通知の１つとして所定の条件が満たされた場合には事前に設定されたアドレスに連絡したりする。

＜管理サーバ１０のハードウェア構成例＞
図２は、管理サーバ１０及び施設端末３０のハードウェア構成の一例を示す図である。管理サーバ１０は、情報処理装置であり、汎用のサーバ向けのコンピュータやパーソナルコンピュータ等を利用することが可能である。また、複数のコンピュータを用いて管理サーバ１０を構成することも可能である。図に示されるように、管理サーバ１０は、物理的には、プロセッサである一以上のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１０と、メモリ１２０とストレージ１３０とネットワークＮと通信を行うための通信インタフェース等の通信部１４０と、入出力部１５０とを有する。管理サーバ１０のハードウェアの各構成要素は、バスを介して相互に接続されている。

ＣＰＵ１１０は、ストレージ１３０に予め格納されている後述のプログラムを実行することにより、ＣＰＵ１１０の制御のもとで各ハードウェアが動作し、図３に示される管理サーバ１０の各機能が実現される。メモリ１２０は、ストレージ１３０からロードしたプログラムを一時的に記憶し、ＣＰＵ１１０に対して作業領域を提供する。メモリ１２０には、ＣＰＵ１１０がプログラムを実行している間に生成される各種データも一時的に保存される。メモリ１２０は例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などを含む。ストレージ１３０は、各種のプログラムを記憶する。ストレージは例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）である。通信部１４０は、ネットワークを介して外部の情報処理装置と各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。

入出力部１５０は、管理サーバ１０に対する各種操作による入力を受け付けて、当該入力にかかる情報をＣＰＵ１１０に伝達する入力装置、およびＣＰＵ１１０の処理結果を出力する出力装置を有する。入力装置は、タッチパネル、マウス及びキーボード等、マイクなどにより実現される。また出力装置は、ディスプレイ及びスピーカ等である。入出力部１５０は、タッチパネルディスプレイのように入力装置と出力装置が一体化していても良いし、入力装置と出力装置それぞれに分離していてもよい。

施設端末３０のハードウェア構成として、ＣＰＵ３１０、メモリ３２０、ストレージ３３０、通信部３４０、入出力部３５０は、管理サーバ１０のＣＰＵ１１０、メモリ１２０、ストレージ１３０、通信部１４０、入出力部１５０それぞれと同様であるため、説明を省略する。施設端末３０における撮像部３６０は、画像を取得可能なカメラである。撮像部３６０としては、例えば、一般的なタブレット端末同様、背面側の背面カメラと、画像を表示するスクリーン側を撮像可能な前面カメラとが設置されている。施設端末３０は、バス２０に設置されると、入出力部１５０であるタッチパネルディスプレイが運転席や助手席に座っている人から閲覧可能であり、かつ、そのまま車内全体を撮像できる位置に撮像部３６０が設置されている。

＜管理システムの機能構成例＞
図３は、管理サーバ１０及び施設端末３０を含む管理システムの機能構成図である。管理サーバ１０の機能構成から説明する。管理サーバ１０は、ＣＰＵ１１０が実行するソフトウェアモジュール（各種プログラムがＣＰＵ１１０の内部メモリに展開されて構成される機能）として、受信部１１、管理部１２、送信部１３、保持部１４を備える。以下では記載の便宜上、これらモジュールを動作主体として記載するが、実際にこれらモジュールを実行するのはＣＰＵ１１０であるため、ＣＰＵ１１０を動作主体とすることもできる。

まず、管理サーバ１０の機能構成から説明する。保持部１４は、施設Ａが運営するバスに関するデータベースを格納している。データベースは、施設テーブル１４１を含む。図４は、保持部１４が保持する施設テーブルの一例を示す図である。なお、本実施形態では、施設テーブル１４１はテーブル形式で表されているが、この形式に限らず、各データが紐付けされていればどのような形式で構築してもよい。

施設テーブル１４１は、施設毎に施設に関する情報を格納するデータセットある。一例として、１つの施設情報（すなわち、１レコード）は、施設ＩＤ、名称、施設端末ＩＤ、バスID、エンジン稼働状態、認証情報、連絡先を関連付けた情報である。
「施設ＩＤ」は、施設Ａを一意に特定するための識別情報である。「名称」は、施設ＩＤにより特定される施設Ａの名称である。「端末ＩＤ」は、施設Ａが運営しているバス２０に設置された施設端末３０を一意に特定するための識別情報である。端末ＩＤとしては例えば、施設端末３０に内蔵された通信部３４０のＭＡＣアドレスを事前に登録しておいてもいいし、機器に固有の識別情報の代わりに、施設端末３０を用いてログインすることによって施設に関する情報を登録できるようにする場合には、ログイン情報や認証情報を端末ＩＤとしてもよい。

「バスID」は、施設Aが管理し、送迎に利用するバスを一位に特定するための識別情報である。「エンジン稼働状態」は、バスのエンジンが稼働中であるか、停止されているかを示す情報である。エンジン稼働状態は、施設端末３０から送信される情報に基づいて更新される。「認証情報」は、施設端末３０から出力される警告を停止する警告停止操作に利用される情報である。認証情報は、各施設によって互いに異なる情報であり、施設の名称や電話番号などから類推されない文字列であることが望ましい。なお、認証情報をQRコードに変換し、印字したものがバス２０の後方に掲示される。「連絡先」は、警告のメッセージや見回り完了報告の送信先であり、ここではメールアドレスを用いることとする。ここでは連絡先として１つのみ登録されるようにしたが、これはメーリングリストでもよいし、複数の連絡先が登録されていてもよい。

受信部１１は、施設端末３０からエンジンの起動や停止を通知するための情報や、見回りが完了したこと示す情報を受信する。管理部１２は、施設端末３０から受信した情報に基づいて施設テーブル１４１を管理する。送信部１３は、施設端末３０から送信された情報に基づいて、施設テーブル１４１に登録された連絡先に警告のメッセージや見回り完了報告を送信する。

次に施設端末３０の機能構成を説明する。施設端末３０は、受信部３１、表示制御部３２、送信部３３、検知部３４、判定部３５、撮像制御部３６を有する。施設端末３０の各機能または処理は、施設端末３０が備えるＣＰＵ３１０が各種プログラムを実行することにより実現される。

受信部３１は、管理サーバ１０との通信を行い、管理サーバ１０から事前に認証情報や連絡先などの各種情報を受信する。表示制御部３２は、事前に保存されたＧＵＩ画面データに基づいて、ＧＵＩ画面を生成して表示する。また表示制御部３２は、ＧＵＩ画面を介してユーザによる操作を受け付ける。検知部３４は、バス２０のエンジンが起動したこと、及び停止したことを検知する。本形態では、検知部３４は、バス２０からの給電を検知することによりエンジンの起動を検知し、給電の終了を検知することによりエンジン停止を検知する。判定部３５は、検知部３４の検知結果に応じて、警告を出力するか否かを判定したり、警告を停止するか否かを判定する。撮像制御部４６は、ＧＵＩ画面を介し操作に応じて、撮像部３６０を起動する。

音声出力部３７は、判定部３５における判定結果に応じて警告を出力すると判定された場合には、入出力部３５０として備えられた施設端末３０のスピーカーから警告音を出力する。送信部３３は、検知部３４の検知結果や、車内の見回りを完了したことを通知する完了報告を、管理サーバ１０に送信する。

＜見回り促進処理＞
施設端末３０における見回り促進処理について説明する。図５は、施設端末３０が実行する見回り促進処理のフローチャートである。なお、以下の説明について各工程（ステップ）を「Ｓ」と表記することとする。施設端末３０のＣＰＵ３１０が以下に示す処理を実現可能なプログラムを実行することにより、施設端末３０の見回り促進機能が実現される。

まずＳ５０１において検知部３４は、バス２０からの給電を検知すると、エンジンが起動されたとみなし、Ｓ５０２において送信部３３は、施設端末ＩＤ、検知時刻とともにエンジンが起動されたことを示す給電通知（エンジン起動情報）を管理サーバ１０に送信する。なお管理サーバ１０において受信部１１がエンジン起動情報を受信すると、管理部１２は、バス２０の稼働履歴として保存する。

Ｓ５０３において表示制御部３２は、初期画像を生成して表示する。図６（ａ）は、初期画像の一例を示す。画像６０は、運転後の車内の見回りを促すテキストと、後部座席のＱＲコードの読み取りを促すテキストを含む。表示制御部３５は、事前に保存された初期画像用データに基づいて画像６０を生成し、画面に表示させる。

Ｓ５０４において検知部３４は、バス２０からの給電が停止したことを検知すると、エンジンが停止されたとみなし、Ｓ５０５において送信部３３は、施設端末ＩＤ、検知時刻とともにエンジンが停止されたことを示す給電停止通知（エンジン停止情報）を管理サーバ１０に送信する。なお管理サーバ１０において受信部１１がエンジン停止情報を受信すると、管理部１２は、バス２０のエンジン稼働履歴として保存する。

Ｓ５０６において判定部３５は、見回り促進機能を実行するか否かを判定する。具体的には判定部３５は、エンジン起動から停止まで第１の所定時間（例えば、１０分など）以上あるか否かを判定する。判定部３５は、エンジンが起動されて停止されるまでの時間（以下、エンジン稼働時間とする）が第１の所定時間以上である場合には、見回り促進機能を実行すると判定し、エンジン稼働時間が第１の所定時間未満である場合には、見回り促進機能を実行しないと判定する。これは例えば、バス２０のメンテナンスや、忘れ物を取りに戻るなどの理由により、送迎に回ることなくエンジンを停止させた場合には、見回りを省略しても問題ないため、見回り促進機能を実行しないようにする。したがって、第１の所定時間は、送迎にかかる時間よりは十分短い時間が設定される。Ｓ５０６において判定部３５が見回り促進機能を実行すると判定すると、Ｓ５０７及びＳ５１５の処理に進み、見回り促進機能を実行しないと判定した場合には、処理を終了する。

以下では、Ｓ５０７からＳ５１２までの処理と、Ｓ５１４からＳ５１７までの処理が並行して進められることになる。

Ｓ５０７において表示制御部３２は、見回り促進用の表示画像を表示する。図６（ｂ）に見回り促進用の表示画像の一例を示す。画像６１は、見回りを促進するテキストとともに、ＱＲスキャンを開始するためのボタン６２を含む。表示制御部３２は、見回り促進用画像データに基づいて画像６１を生成し、表示する。

画像６１におけるボタン６２をスタッフによりタッチ操作されると、Ｓ５０８において表示制御部３２は、スキャン開始操作を受け付ける。Ｓ６０９において撮像制御部３６は、カメラを起動し、ＱＲコードを読み取るスキャンモードを開始する。スタッフが施設端末３０をバス後方に掲示されたＱＲコードにかざすと、Ｓ５１０において撮像部３６０がＱＲコードを読み取り、Ｓ５１１において判定部３５は、認証情報に基づいて照合判定処理を実行する。読み取ったQRコードを解析して得られるスキャン情報が、事前に管理サーバ１０から受信した認証情報と一致するか否かを判定する。

Ｓ５１２において判定部５１２は、適切なＱＲコードが読み取られた場合には、車内の見回りが完了したとみなして、Ｓ５１３に進む。一方、照合判定処理の結果、読み取られたＱＲコードが事前に設定された情報ではなかった場合、Ｓ５０９に戻る。なお、一度ＱＲスキャンしたが適合できなかったためにスキャンモードに戻る場合には、「ＱＲ
コードを読み直してください」のような再読み込みを促すメッセージや「正しいＱＲコードではない可能性があります」のように原因を提示するメッセージを表示するようにしてもよい。

このようにＳ５０７からＳ５１２までの処理は、スタッフによる車内の見回り作業を促し、見回り作業が完了したことを確認するための処理である。一方で、Ｓ５１４からＳ５１７の処理では、必要に応じて警告を行う処理である。

Ｓ５１４において検知部３４は、エンジン停止を検知してから第２の所定時間（例えば１０秒）が経過したことを検知する。検知部３４がエンジン停止してから第２の所定時間が経過したことを検出したら、Ｓ５１５に進む。
Ｓ５１５において、第１の警告出力として、音声出力部３７は事前に設定された警告音をスピーカーから発生させる。なお、第２の所定時間が長いと、スタッフが車内の見回りを忘れてバス２０の施錠をしてしまいかねないので、見回りせずにスタッフがバス２０を降りようとする前に警告がスタッフに聞こえるように、第２の所定時間は比較的短い時間が設定されている。

さらにＳ３１６において検知部３４が、エンジン停止してから第３の所定時間（例えば５分）が経過したことを検知する。検知部３４がエンジン停止してから第３の所定時間が経過したことを検出したら、Ｓ５１６に進む。
Ｓ５１６において、第２の警告出力として、音声出力部３７は、第１の警告出力ときは異なる音で、より大きな警告音をスピーカーから発生させる。また、送信部３３は、事前に登録されたメールアドレスに、バスの名称とともに、エンジン停止後、見回り作業が完了していないことを通知するメールを送信する。

Ｓ５１３において施設端末３０は、完了処理を実行する。第１の警告や第２の警告の出力中である場合には、音声出力部３７は警告音を停止させる。また、第２の警告出力を行った後である場合には、Ｓ５１７においてメールを送信したメールアドレスに対して、見回り作業を完了したことを通知するメールを送信する。また、第１の警告出力および第２の警告出力いずれも実行される前である場合には、事前に登録されたメールアドレス（Ｓ５１７においてメールを送信したアドレスと同じでもよいし、異なるアドレスであってもよい）に対して、送迎後の見回り作業が完了したことを示すレポートを送信し、表示制御部３２が完了画面を表示させる。図６（ｃ）は、完了画面の一例を示す図である。画像６３は、見回り作業が完了したことを示すテキストを含む。表示制御部３２は、完了画面を生成するためのデータに基づいて、画像６３を生成し、表示する。
以上で、施設端末３０における見回り促進処理を終了する。

＜第１の実施形態のまとめ＞
本実施形態に係る管理システム１において、バス２０内に設置された施設端末３０がエンジン停止を検知すると、所定時間経過後に警告が出力され、スタッフが施設端末３０を用いてバス２０内の後方に掲示されたＱＲコードをスキャンすると、警告が停止する。撮像部（カメラ）を用いてＱＲコードをスキャンするためには、ＱＲコードが掲示されている位置に近づく必要がある。そこでＱＲコードのスキャンを警告の停止操作とすることで、スタッフはバス２０後方まで行く必要が生じ、車内の見回りを促進できる。
エンジンの起動と停止を検知する検知機能や、必要に応じて警告する警告機能を施設端末３０が備えることで、入手しやすいタブレットやスマートフォンを用いて、見回り促進する管理システムを簡単に導入することができる。また、施設端末３０をカーチャージャーやシガーソケットなどにつなげるだけで、エンジンの起動・停止を検知することができるので、面倒な配線なしに取り付けることができる。

本管理システムは、スタッフによる車内の見回りを支援するシステムである。従来のセンサやカメラを用いて自動で着席・離席を検知してアラートする方法では、センサやカメラに不具合が生じた場合には、取り残された子供の検知が漏れてしまう。このようなシステムによりスタッフが自動検知を頼る運用になっていると、機器の不具合により取り残された子供を見落としかねない。現実的には機器が不具合を起こさないようにするためには、高頻度のメンテナンスが必要にあり、バス２０を運営する施設Ａにとっては重い負担になってしまう。一方、本実施形態における管理システムでは、人が目視で車内を確認する仕組みを支援する。これにより、日常的な管理体制を強力にバックアップし、負荷の高いメンテナンスなく車内の置き去りを防止することができる。

なお、上述では、バス２０の後方にＱＲコードを掲示し、施設端末３０を用いて読み取ることとしたが、ＱＲコードを他の機器で読み取ることを可能としたシステムにすることもできる。例えば、警告を出力する施設端末３０とは別に、スタッフが携帯する携帯端末（スマートフォンなど）を用いて、ＱＲコードをスキャンできるようにしてもよい。この場合、Ｓ５１１における照合判定処理を携帯端末が実行するか、あるいはスキャンすることで得られるスキャン情報を携帯端末が施設端末３０に送信するようにすればよい。

また、バス２０の稼働や第２の警告出力のために、施設端末３０は管理サーバ１０に各種情報を送信するようにしたが、管理サーバ１０へのデータ送信ができなくても処理を進めることもできる。このとき、第２の警告において連絡するメールアドレスを事前に施設端末３０に登録しておいてもいいし、特定のメールアドレスへの連絡はなしに、警告音のみの警告としてもよい。このようにすることで、通信環境が悪い場合や一時的に管理サーバ１０と通信できない場合においても、施設端末３０の見回り促進機能は保持される。

また、上述の説明では、警告としては警告音や連絡を例に説明したが、施設端末３０の表示部に表示する画像を、注意喚起を促すようなユーザインターフェースを表示したり、振動したりしてもよい。第１の警告では、図６（ｂ）に示す画像６１の背景を緑色として、第１の警告時に背景が黄色になり、さらに第２に警告時には背景が赤色になるようにする。さらに例えば、第２の警告では、管理サーバ１０からの通信を介して、施設端末３０に電話をかけたり、呼びかけできるようにしてもよい。さらに、警告を促すだけではなく、車内に人がいることにそなえて、第２の警告として、バス２０に対して遠隔からエンジンやエアコンをつけられるようにしたり、ドアを遠隔で開けられるようにしてもよい。

また、警告を出力するまでの第２の所定時間、第３の所定時間は、自由に設定することができる。バス２０で１回に送迎する園児の数や年齢に応じて、園児の降車にかかる時間は異なるので、適宜設定すればよい。第２の所定時間は、上述では１０秒とした。スタッフが施設端末３０を取り外して、車内を見回りすることを想定すると、見回り促進機能は、基本的にエンジン停止まもなく警告音が鳴り、その後、スタッフの警告停止操作により警告音が停止される。上述の通り、スタッフが見回りを忘れないようにするため、第２の所定時間を十分短く設定して、エンジン停止後すぐに警告音がなり、積極的に注意喚起することができる。しかしながら例えば、バス２０内に警告音がなると園児の不安が強まるなどを懸念して極力警告音が鳴らないようにしたい場合は、施設端末３０の表示画像による注意喚起のみにしてもよいし、第２、第３の所定時間を例えば、５分、１０分のように長く設定してもよい。ただしこの場合には、スタッフがつい車内見回りを忘れてしまった場合には、本来見回りすべきスタッフに警告音が届かない可能性があるので、第１の警告として所定の連絡先に通報することが望ましい。

また、上述の説明では、ＱＲコードをバス２０の後方に掲示することで、車内の後方までスタッフが見回りに行く動機付けとした。近接して識別情報を読み取る方法であれば、QRコードの読み取り以外の方法を用いることもできる。例えばＱＲコードの代わりに、ＲＦＩＤを適用する。ＲＦタグをバス２０の後方に配置しておき、スタッフが携帯できるＲＦリーダライタを用いてＲＦタグを読み取る。ＲＦＩＤリーダライタ（読み取り手段）は、読み取ったＲＦタグの情報を施設端末３０に送信すると、施設端末３０は、Ｓ５１１を実行する（この場合には、Ｓ５０７～Ｓ５１０の処理は不要）。ＲＦＩＤを用いる場合には、ＲＦＩＤリーダライタによるＲＦタグの読み取り可能な範囲は、バス２０の後方まで移動しないとできない程度に近接する必要のある範囲であることが望ましい。また、QRコードを識別情報として用いる場合には、図４に示すようなランダムな文字列以外にもURLなど識別可能な情報であればなんでもよい。QRコードがURLである場合、施設端末３０は、QRコードが示すURLにアクセスすることで、識別情報を取得し、照合判定処理を実行する。

＜第１の実施形態の変形例＞
第１の実施形態の変形例として、さらに、施設端末３０が自動監視機能を実行するシステムついて説明する。自動監視機能とは、施設端末３０が有する撮像部３６０が自動で車内を撮影する機能である。Ｓ５１３における見回り促進機能の完了処理を実行した後、施設端末３０は、スタッフにより運転席付近の前方に施設端末３０の設置位置に戻される。施設端末３０（ここではタブレット端末）の表示画面はバス２０の車内を向いている。そこで、施設端末３０の前面カメラを自動で起動し、見回り完了した後の車内を定期的に撮影し、管理サーバ１０に送信する。

図７は、施設端末３０が実行する自動監視処理のフローチャートを示す。施設端末３０のＣＰＵ３１０は、Ｓ３１２の完了処理が実行された後に、以下の処理を実現可能なプログラムを実行する。

まずＳ７０１において撮像制御部３６は、前面の撮像部３６０（カメラ）を起動し、Ｓ７０２において車内を撮像する。Ｓ７０３において送信部３３は、撮像した車内の画像を管理サーバ１０に送信する。

Ｓ７０４において判定部３５は、自動監視処理を終了するか否かを判定する。ここでは、判定部３５は、撮像を開始してから第４の所定時間（例えば２時間）が経過したか否かを判定基準とする。判定部３５は、自動監視処理を開始してから第４の所定時間経過していると判定した場合には、処理を終了し、まだ第４の所定時間には達していない場合にはＳ７０２に戻る。なお、Ｓ７０２においては、前回の撮像から一定期間（１分など）の間隔が空くようにしてもよい。

管理サーバ１０は、施設端末３０から車内の画像を受信すると、公知の方法を用いて解析し、画像に人物が写っていないかを検出する。画像における人物検知方法は公知なので説明は省略するが、ここで人物が検知された場合には、管理サーバ１０は、所定のメールアドレスに連絡したり、電話番号に自動音声で連絡したりする。
このように、施設端末３０を用いて自動的に車内を撮影しつつ、管理サーバ１０が解析することで、送迎に関わるスタッフ以外にも車内の見回りを多重化し、置き去りを抑止することができる。

なお自動監視機能は、Ｓ５０５の処理の後以外に実行するようにしてもよい。例えば、施設端末３０が前方に設置される状態で、Ｓ５０５の処理の後に図７に示す処理を実行し、自動で撮像する。ただし、施設端末３０の撮像部３６０が撮像すると、車内全体が画像に含まれ、仮に園児（人）がいた場合には必ず写り込むように、施設端末３０が設置されていることが望ましい。Ｓ５０６において判定部３５は、撮像した画像を解析した結果に基づいて、見回り促進処理を実行するか否かを判定することもできる。撮像した画像を１回以上解析した結果、人物が一人でも検出された場合に、判定部３５は見回り促進機能が必要であると判定する。このような構成にすることにより、車内に人物がいる場合に、警告を出力することができる。

［第２の実施形態］
第１の実施形態では、Ｓ５０６においてエンジン稼働時間に基づいて見守り促進機能を実行するか否か判定した。第２の実施形態では、事前に登録された送迎時間に基づいて判定する方法について説明する。以下、第２の実施形態について説明するが、第１の実施形態と共通する構成については説明を省略し、第１の実施形態と異なる構成について主に説明する。

図８は、見守り促進処理のＳ５０６において実行される要否判定処理のフローチャートである。
Ｓ８０１において判定部３５は、事前に設定された送迎時間情報をメモリ３２０から取得する。送迎時間情報は、バス２０が送迎に使用され得る時間を規定する情報であり、曜日と送迎開始時間と送迎終了時間とによって定義される。例えば、平日、午前０８：００を送迎開始時間、１０：００を送迎終了時間が送迎時間情報として設定されているものとする。

Ｓ８０２において判定部８０２は、エンジンが起動されたと検知してからのエンジン起動時間が第１の所定時間以上であるか否かを判定する。ここでエンジン起動時間が第１の所定時間未満である場合は、Ｓ８０５に進み、エンジン起動時間が第１の所定時間以上である場合には、Ｓ８０３に進む。

Ｓ８０３において判定部３５は、Ｓ８０１において取得した送迎時間情報を参照して、現在日時が送迎時間に含まれるか否かを判定する。現在日時が送迎時間に含まれる場合は、Ｓ８０４に進み、判定部３５は、見回り促進機能を実行する必要があると判定する。また、現在日時が送迎時間に含まれない場合は、Ｓ８０５に進む。Ｓ８０５において判定部３５は、判定結果として見回り促進機能を実行する必要はないとする。

以上の通り、第２実施形態では、エンジンの稼働時間が第１の所定時間よりも長く、現在日時が送迎時間として想定されている時間内である場合に、Ｓ５０７からＳ５１７までの処理を実行することとする。バス２０を送迎以外に利用する場合もある。そのような場合には、置き去りを防止する見回り促進機能は不要なため、送迎時間に応じて要否判定処理をする。これにより、見回り促進機能を適切に働かせることができる。

［第３の実施形態］
上述の実施形態では、バス２０の後方にＱＲコードを設置することで、車内の見回りを促進した。第３実施形態では、園児それぞれ固有のＱＲコードを名札など園児の持ち物に貼り付け、バス２０に乗車した園児、降車した園児を管理できるようにすることで、バス２０に残っている園児がいないことを確認する方法について説明する。

図９は、乗車する園児を登録する乗車登録処理のフローチャートである。施設端末３０を用いてスタッフは、園児が乗車するときに園児のＱＲコードを順にスキャンすることで、園児の乗車を登録する。なお、施設端末３０および管理サーバ１０には、事前に、バス２０の送迎でバス２０に乗車する可能性のある園児それぞれに対応するＱＲコードを園児テーブルに記憶しておく。各園児には、例えば１２文字のアルファベットなど固有の識別情報が割り当てられ、識別情報をＱＲコードに変換したものを配布する。

Ｓ９０１において撮像制御部３６は、撮像部３６０を起動し、ＱＲコードをスキャンする。Ｓ９０２において判定部３５は、ＱＲコードをスキャンすることで取得できる識別情報に基づいて、園児テーブルから園児を検索する。
Ｓ９０３において判定部３５は、Ｓ９０２において検索した園児に対応する乗車フラグを、乗車したことを示す状態に更新する。
Ｓ９０４において判定部３５は、バス２０に乗車した園児の数をカウントアップし、処理を終了する。

以上の処理を、施設端末３０を用いて園児のＱＲコードをスキャンするたびに実行することで、バス２０に乗車した園児を検知し、乗車している人数を管理する。

次に、第３の実施形態における見回り促進処理を説明する。本実施形態においては、施設Ａにバス２０が到着して園児が施設Ａに登園する際に、スタッフは施設端末３０を用いて再度、各園児のＱＲコードをスキャンすることで、各園児の降車を検知し、車内に取り残された園児がいないことを確認する。ここでは図５に示すフローチャートにうち、異なる部分を説明する。

まず、Ｓ５０３において表示される初期画像や、図５０７において表示される見回り促進用ＵＩは、「降車する園児全員のＱＲコードをスキャンして下さい」のようなテキストを含む。Ｓ５０９において施設端末３０がスキャンモードになると、園児がバス２０を降車する際にスタッフが園児が保有するＱＲコードをスキャンすることで、Ｓ５１０においてＱＲコードを読み取り、識別情報を取得できる。

Ｓ５１１において判定部３５は、Ｓ５１０において取得した識別情報に基づいて、園児テーブルから園児を検索し、検索した園児に対応する乗車フラグを、降車したことを示す状態に更新する。また、施設端末３０は、バス２０に乗車している園児の人数から１を減算し、バス２０内に残っている園児数を導出する。
Ｓ５１２において判定部３５は、バス２０内に残っている園児の数が０になったか否かを判定することにより、車内確認が完了したか否かを判定する。判定部３５は、バス２０に残っている園児数が０になったら、車内確認が完了したとみなして、Ｓ５１３に進む。

以上の通り第３の実施形態では、園児がバス２０に乗車するときと、降車するときに、園児のＱＲコードを読み込むことで、バスの乗車人数を管理することができ、乗車した全員が降車しないと施設端末３０からの警告を停止できないため、バス２０車内に残っている人がいないか見回りを促進することができる。

第３の実施形態では、各園児の乗車、降車を管理できるので、バスの送迎により登園する園児の出欠確認システムとしても機能させることができる。そのため例えば、園児それぞれの保護者の連絡先（メールアドレス）も園児テーブルに登録しておき、施設端末３０は、バス２０の降車時にＱＲコードがスキャンされたことを園児に対応する保護者の連絡先に送信するようにしてもよい。または、施設Ａが管理する情報端末において、園児の名前と、各園児のステータス（乗車中、降車済み）とを一覧で表示できるようにすることもできる。

なお、第３の実施形態の説明では、各園児にＱＲコードを持たせる方法を例に説明したが、ここでもＱＲコードの代わりにＲＦＩＤを適用することもできる。携帯型のＲＦＩＤ
リーダライタを用いて園児がバス２０に乗車する時に園児のＲＦタグを読み取り、降車時にも園児のＲＦタグを読み取ることで、上述の説明と同様のシステムを実現することができる。例えば、バス２０の降車時には、携帯型のＲＦＩＤリーダライタではなく、門など必ず児童が通過する場所にＲＦリーダライタを設置しておいてもよい。また、園児がＲＦタグを紛失したり壊したりする可能性を踏まえて、カバン、名札、防止など複数の箇所にＲＦタグを貼り付けておいてもよい。ＲＦＩＤリーダライタが、一人の園児につきどれか１つのＲＦタグを読み取れれば、降車したものと検知する。

また、園児がバス２０に乗車する際には、施設Ａのスタッフではなく、各園児の保護者が園児を乗車させる直前にＱＲコードをスキャンするようにしてもよい。この場合、各保護者が所有する情報端末から、事前に園児の識別情報を管理サーバ１０に送信し、管理サーバ１０が園児テーブルにおける各園児のステータスを管理する。さらに管理サーバ１０は、各保護者の情報端末から送信された情報に基づいて園児テーブルを更新するたびに、施設端末３０にも新しい園児のステータス情報を送信するようにする。

また、例えば、Ｓ５１１において降車時に園児のＱＲコードの読み取りがなされたことを確認できたら、その都度、第２、第３の所定時間に例えば５秒など一定期間の時間を追加して、警告が出力されるまでの時間を延長するようにしてもよい。

［変形例］
説明を簡単にするため、１つの施設２０は１つの施設端末２０を保有している構成としたが、各施設で複数の施設端末２０を利用してもよい。その場合には、各施設端末２０は、管理サーバ１０に検知結果やスキャン情報を送信し、管理サーバ１０が、判定部３５が実行する各種判定処理を実行する。

さらに、上述の説明では施設端末３０が検知機能および警告機能を備えるシステムについて説明したが、例えばバス２０自体が管理サーバ１０と通信可能なように構成され、かつ検知機能や警告機能を有するように設計してもよい。この場合、施設端末３０は、ＱＲコードの読み取りに用いられる。スタッフが施設端末３０を用いてＱＲコードを読み取ると、管理サーバ１０にスキャン情報と施設端末ＩＤを送信する。管理サーバ１０は、施設テーブル１４１を参照してスキャン情報と施設端末ＩＤに基づいて、施設端末ＩＤに対応するＱＲコードが読み取れられたか否かを確認するための照合判定処理を実行し、照合できた場合には、バス２０に警告を停止することを許可する停止許可情報を送信する。

なお、上述の説明では、バス２０を例に説明したが、バス以外の車両でもよいし、たとえば、部屋に適用することもできる。部屋の見回りを促進する場合には、部屋のドアから離れた場所にＱＲコードなど識別情報を掲示することが望ましい。また、１つのＱＲコードでは十分ではない場合には、部屋の複数の箇所の異なるＱＲコードを掲示し、すべてのＱＲコードのスキャンが完了したら、見回り完了したとみなすようにすることもできる。

なお、開示技術は、上述した実施形態に限定されるものではなく、開示技術の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。例えば、上述した各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更し、または並列に実行することができる。

１…管理システム、２０…管理サーバ、３０…施設端末、３１０…ＣＰＵ、３２０…メモリ、３３０…ストレージ、３４０…通信部、３５０…入出力部、３６０…撮像部、３１…受信部、３２…表示制御部、３３…送信部、３４…検知部、３５…判定部、３６…撮像制御部３６、音声出力部３７

Claims (7)

1. 車内の見回りを促すための情報処理装置であって、
   車両のエンジンの稼働を検知する検知手段と、
   前記検知手段の検知結果に応じて、警告を出力する出力手段と、
   近接して識別情報を読み取る読み取り手段とを有し、
   前記出力手段は、前記読み取り手段により前記識別情報が読み取られると、前記警告を停止することを特徴とする情報処理装置。
2. 前記識別情報は、前記車両の後方に掲示されることを特徴とする情報処理装置。
3. 前記出力手段は、前記車両のエンジンの稼働が第１の所定時間以上継続しなかった場合には、警告を出力しないことを特徴とする請求項１に記載の情報処理装置。
4. 前記出力手段は、前記検知手段が前記車両のエンジンの停止を検知してから第２の所定時間、経過すると、第１の警告を出力することを特徴とする請求項３に記載の情報処理装置。
5. 前記出力手段は、前記車両のエンジンの停止を検知してから、前記第２の所定時間よりも長い第３の所定時間、経過すると、第２の警告を出力することを特徴とする請求項４に記載の情報処理装置。
6. コンピュータを請求項１乃至４のいずれか１項に記載の表示制御装置として機能させるためのプログラム。
7. 車内の見回りを促すための情報処理方法であって、
   車両のエンジンの稼働を検知するステップと、
   前記エンジンの稼働の検知結果に応じて、警告を出力するステップと、
   近接して識別情報を読み取るステップとを有し、
   前記読み取ステップにより前記識別情報が読み取られると、前記警告を停止することを特徴とする情報処理方法。