JP2018124766A - 体調不良予測方法、体調不良予測プログラム、及び体調不良予測装置 - Google Patents

Abstract

【課題】体調不良の発生予測が外れた場合に、体調不良とその発生要因の関係性の学習を抑制できる体調不良予測方法を提供する。
【解決手段】体調不良予測方法は、体調不良と体調不良の発生要因との関係性を体調不良の種別毎に記憶する記憶部を参照して、体調不良が発生する発生予定日を特定し、発生予定日に体調不良が発生しなかった場合、発生予定日を特定してから発生要因が変化しているか否かを判定し、発生要因が変化している場合、発生要因が変化していない場合に実行される関係性の学習より低い学習度合で関係性を学習する、処理をコンピュータが実行する。
【選択図】図２３

Description

本件は、体調不良予測方法、体調不良予測プログラム、及び体調不良予測装置に関する。

肺音といった患者の生理学的データと温度や湿度といった環境的データとに基づいて、患者の呼吸器健康状態データを生成し、呼吸器健康状態データに応じて患者に対する今後の警告といった予測的モデルを生成する技術が知られている（例えば特許文献１参照）。また、気象と疾病発生予測との相関関係を明らかにしたモデル判別式を作成することにより気象変化に伴う疾病発生を予測する技術も知られている（例えば特許文献２参照）。

特表２０１０−５４００６７号公報 特開２００１−０６７４０３号公報

しかしながら、上述した疾病を含む体調不良の発生予測が外れたにも関わらず、体調不良とその発生要因（例えば気象など）の関係性を学習してモデル判別式を作成してしまうと、作成したモデル判別式に基づく以後の予測では、体調管理に対する警告や注意喚起が行われにくくなるおそれがある。

そこで、１つの側面では、体調不良の発生予測が外れた場合に、体調不良とその発生要因の関係性の学習を抑制できる体調不良予測方法、体調不良予測プログラム、及び体調不良予測装置を提供することを目的とする。

１つの実施態様では、体調不良予測方法は、体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、処理をコンピュータが実行する体調不良予測方法である。

１つの実施態様では、体調不良予測プログラムは、体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、処理をコンピュータに実行させる体調不良予測プログラムである。

１つの実施態様では、体調不良予測装置は、体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、処理を実行する処理部を備える体調不良予測装置である。

体調不良の発生予測が外れた場合に、体調不良とその発生要因の関係性の学習を抑制することができる。

図１は体調不良予測システムの一例を説明するための図である。 図２はウェアラブルデバイスのハードウェア構成の一例である。 図３はゲートウェイのハードウェア構成の一例である。 図４はサーバのハードウェア構成の一例である。 図５はスマートデバイスのハードウェア構成の一例である。 図６（ａ）は第１実施形態に係るウェアラブルデバイスの機能ブロック図の一例である。図６（ｂ）は第１実施形態に係るゲートウェイの機能ブロック図の一例である。 図７は第１実施形態に係るサーバの機能ブロック図の一例である。 図８はスマートデバイスの機能ブロック図の一例である。 図９はウェアラブルデバイスの動作の一例を示すフローチャートである。 図１０は実測データの生成を説明するための図である。 図１１はゲートウェイの動作の一例を示すフローチャートである。 図１２はサーバの動作の一例を示すフローチャートである。 図１３は実測データ記憶部の一例である。 図１４はサーバの動作の他の一例を示すフローチャートである。 図１５（ａ）は特徴量の一例である。図１５（ｂ）は予測データ記憶部３５０の一例である。 図１６は咳有無予測処理の一例を示すフローチャートである。 図１７は関係性モデル第１記憶部の一例である。 図１８は第１実施形態に係るサーバによる学習処理（その１）の一例を示すフローチャートである。 図１９は第１実施形態に係るサーバによる学習処理（その２）の一例を示すフローチャートである。 図２０は発生主要因の変化について説明する図である。 図２１は第１実施形態に係る関係性学習処理の一例を示すフローチャートである。 図２２は第１実施形態に係る関係性モデルの更新例を説明する図である。 図２３は予測と学習の関係の一例を説明する図である。 図２４はスマートデバイスの動作の一例を示すフローチャートである。 図２５は予測メッセージの一例である。 図２６は第２実施形態に係るサーバによる学習処理（その２）の一部を例示するフローチャートである。 図２７は第２実施形態に係る関係性学習処理の一例を示すフローチャートである。 図２８は第２実施形態に係る関係性モデルの更新例を説明する図である。 図２９は第３実施形態に係るサーバの機能ブロック図の一例である。 図３０は第４実施形態に係るウェアラブルデバイスの機能ブロック図の一例である。 図３１は第４実施形態に係るゲートウェイの機能ブロック図の一例である。 図３２は第４実施形態に係るサーバの機能ブロック図の一例である。

以下、本件を実施するための形態について図面を参照して説明する。

（第１実施形態）
図１は体調不良予測システムＳの一例を説明するための図である。体調不良予測システムＳはウェアラブルデバイス１００、ゲートウェイ２００、体調不良予測装置としてのサーバ３００、及びスマートデバイス４００を備えている。図１では、スマートデバイス４００の一例としてスマートフォンが示されているが、携帯情報端末であれば特に限定されず、タブレット端末やノート型のPersonal Computer（ＰＣ）であってもよい。ウェアラブルデバイス１００、ゲートウェイ２００、及びスマートデバイス４００は例えば家屋Ｘ内などで利用される。一方、サーバ３００は例えばクラウドＣＬ上のデータセンターＤＣ内に設置される。

ウェアラブルデバイス１００とゲートウェイ２００は互いに無線ネットワークＮＷ１を介して接続することができる。無線ネットワークＮＷ１としては例えばBluetooth（登録商標）Low Energy（以下、ＢＬＥという）がある。ここで、ウェアラブルデバイス１００はリストバンドを備えている。このため、利用者はウェアラブルデバイス１００を手首に巻き付けることができる。また、ウェアラブルデバイス１００は各種のセンサを備えている。詳細は後述するが、各種のセンサにより、ウェアラブルデバイス１００は利用者のＲ波、利用者の周囲の気温及び湿度、利用者の現在位置、利用者の動きを検知することができる。さらに、ウェアラブルデバイス１００はマイクも備えている。これにより、ウェアラブルデバイス１００は利用者をとりまく周囲の環境音を集めることができる。尚、環境音には例えば利用者の咳の音が含まれることがある。ウェアラブルデバイス１００は定期的に咳の有無と気温と湿度とを関連付け、これらを実測データとしてゲートウェイ２００に送信する。

ゲートウェイ２００とサーバ３００は互いに無線ネットワークＮＷ２、アクセスポイントＡＰ、及び有線ネットワークＮＷ３を介して接続することができる。無線ネットワークＮＷ２としては例えばＷｉ−Ｆｉ（登録商標）がある。有線ネットワークＮＷ３としては例えばインターネットやLocal Area Network（ＬＡＮ）などがある。ここで、ゲートウェイ２００は各種のセンサを備えている。詳細は後述するが、各種のセンサにより、ゲートウェイ２００は自身の周囲の気温及び湿度、利用者の気配を検知することができる。また、ゲートウェイ２００はウェアラブルデバイス１００との接続が完了すると、接続が完了した時刻を利用者が家屋Ｘに帰宅した帰宅時刻として保持することができる。ゲートウェイ２００はウェアラブルデバイス１００から上述した実測データを受信すると、実測データをサーバ３００に送信する。尚、必要に応じて、ゲートウェイ２００は実測データに気温及び湿度が含まれていない場合、自身が検知した気温及び湿度を関連付けたり、自身が保持する帰宅時刻を関連付けたりして実測データをサーバ３００に送信してもよい。

サーバ３００とスマートデバイス４００は互いに有線ネットワークＮＷ３、携帯基地局ＢＳ、及び無線ネットワークＮＷ４を介して接続することができる。より詳しくは、携帯基地局ＢＳの通信可能領域ＡＲ内にスマートデバイス４００が含まれていれば、サーバ３００は無線ネットワークＮＷ４を介してスマートデバイス４００と接続することができる。尚、無線ネットワークＮＷ４としては例えばLong Term Evolution（ＬＴＥ）がある。ここで、サーバ３００はゲートウェイ２００から送信された実測データを受信すると、受信した実測データと咳が発生する環境条件（例えば気温及び湿度等）との関係性を定義した後述する関係性モデルに基づいて、咳が発生する可能性の有無を予測する。尚、以下では咳を体調不良の一例として説明するが、例えば発熱や頭痛などが体調不良であってもよい。サーバ３００は咳が発生する可能性の有無を予測し、咳が発生する可能性がある場合、発生予定日と咳を引き起こす主たる発生要因（以下、発生主要因という）を含む予測メッセージをスマートデバイス４００に送信する。尚、サーバ３００の詳細については後述する。

スマートデバイス４００はサーバ３００から送信された予測メッセージを受信して、表示する。これにより、利用者は数日後に発生する可能性がある咳を事前に把握することができ、適宜、予防に必要な措置をとることができる。

以下、図２から図５までを参照して、上述したウェアラブルデバイス１００、ゲートウェイ２００、サーバ３００、及びスマートデバイス４００のそれぞれの構成について詳しく説明する。

図２はウェアラブルデバイス１００のハードウェア構成の一例である。図２に示すように、ウェアラブルデバイス１００は、Central Processing Unit（ＣＰＵ）１００Ａ、Random Access Memory（ＲＡＭ）１００Ｂ、Read Only Memory（ＲＯＭ）１００Ｃ、マイク１００Ｄ及びＢＬＥ回路１００Ｅを含んでいる。ＢＬＥ回路１００ＥにはアンテナＡＴＮが接続されている。

また、ウェアラブルデバイス１００は、加速度センサ１００Ｆ、気温センサ１００Ｇ、湿度センサ１００Ｈ、脈拍センサ１００Ｉ、及びＧＰＳセンサ１００Ｊを含んでいる。ＣＰＵ１００ＡからＧＰＳセンサ１００Ｊまでは、内部バス１００Ｋによって互いに接続されている。少なくともＣＰＵ１００ＡとＲＡＭ１００Ｂとが協働することによってコンピュータが実現される。

上述したＲＡＭ１００Ｂには、ＲＯＭ１００Ｃに記憶されたプログラムがＣＰＵ１００Ａによって格納される。格納されたプログラムをＣＰＵ１００Ａが実行することにより、後述する各種の機能が実現され、また、各種の処理が実行される。尚、プログラムは後述するフローチャートに応じたものとすればよい。

図３はゲートウェイ２００のハードウェア構成の一例である。図３に示すように、ゲートウェイ２００は、ＣＰＵ２００Ａ、ＲＡＭ２００Ｂ、ＲＯＭ２００Ｃ、マイク２００Ｄ、及びＢＬＥ回路２００Ｅを含んでいる。ＢＬＥ回路２００ＥにはアンテナＡＴＮが接続されている。

また、ゲートウェイ２００は、気温センサ２００Ｆ、湿度センサ２００Ｇ、人感センサ２００Ｈ、及び無線ＬＡＮ回路２００Ｉを含んでいる。無線ＬＡＮ回路２００ＩにはアンテナＡＴＮが接続されている。ＣＰＵ２００Ａから無線ＬＡＮ回路２００Ｉまでは、内部バス２００Ｊによって互いに接続されている。少なくともＣＰＵ２００ＡとＲＡＭ２００Ｂとが協働することによってコンピュータが実現される。

上述したＲＡＭ２００Ｂには、ＲＯＭ２００Ｃに記憶されたプログラムがＣＰＵ２００Ａによって格納される。格納されたプログラムをＣＰＵ２００Ａが実行することにより、後述する各種の機能が実現され、また、各種の処理が実行される。尚、プログラムは後述するフローチャートに応じたものとすればよい。

図４はサーバ３００のハードウェア構成の一例である。図４に示すように、サーバ３００は、少なくともＣＰＵ３００Ａ、ＲＡＭ３００Ｂ、ＲＯＭ３００Ｃ、及びネットワークＩ／Ｆ（インタフェース）３００Ｄを含んでいる。サーバ３００は、必要に応じて、Hard Disk Drive（ＨＤＤ）３００Ｅ、入力Ｉ／Ｆ３００Ｆ、出力Ｉ／Ｆ３００Ｇ、入出力Ｉ／Ｆ３００Ｈ、ドライブ装置３００Ｉの少なくとも１つを含んでいてもよい。ＣＰＵ３００Ａからドライブ装置３００Ｉまでは、内部バス３００Ｊによって互いに接続されている。少なくともＣＰＵ３００ＡとＲＡＭ３００Ｂとが協働することによってコンピュータが実現される。

入力Ｉ／Ｆ３００Ｆには、入力装置７１０が接続される。入力装置７１０としては、例えばキーボードやマウスなどがある。
出力Ｉ／Ｆ３００Ｇには、表示装置７２０が接続される。表示装置７２０としては、例えば液晶ディスプレイがある。
入出力Ｉ／Ｆ３００Ｈには、半導体メモリ７３０が接続される。半導体メモリ７３０としては、例えばUniversal Serial Bus（ＵＳＢ）メモリやフラッシュメモリなどがある。入出力Ｉ／Ｆ３００Ｈは、半導体メモリ７３０に記憶されたプログラムやデータを読み取る。
入力Ｉ／Ｆ３００Ｆ及び入出力Ｉ／Ｆ３００Ｈは、例えばＵＳＢポートを備えている。出力Ｉ／Ｆ３００Ｇは、例えばディスプレイポートを備えている。

ドライブ装置３００Ｉには、可搬型記録媒体７４０が挿入される。可搬型記録媒体７４０としては、例えばCompact Disc（ＣＤ）−ＲＯＭ、Digital Versatile Disc（ＤＶＤ）といったリムーバブルディスクがある。ドライブ装置３００Ｉは、可搬型記録媒体７４０に記録されたプログラムやデータを読み込む。
ネットワークＩ／Ｆ３００Ｄは、例えばポートとPhysical Layer Chip（ＰＨＹチップ）とを備えている。サーバ３００は、ネットワークＩ／Ｆ３００Ｄを介して有線ネットワークＮＷ３と接続される。

上述したＲＡＭ３００Ｂには、ＲＯＭ３００ＣやＨＤＤ３００Ｅに記憶されたプログラムがＣＰＵ３００Ａによって格納される。ＲＡＭ３００Ｂには、可搬型記録媒体７４０に記録されたプログラムがＣＰＵ３００Ａによって格納される。格納されたプログラムをＣＰＵ３００Ａが実行することにより、サーバ３００は後述する各種の機能を実現し、また、後述する各種の処理を実行する。尚、プログラムは後述するフローチャートに応じたものとすればよい。

図５はスマートデバイス４００のハードウェア構成の一例である。図５に示すように、スマートデバイス４００は、ＣＰＵ４００Ａ、ＲＡＭ４００Ｂ、ＲＯＭ４００Ｃ、Non Volatile Memory（ＮＶＭ）４００Ｄ及びRadio Frequency（ＲＦ）回路４００Ｅを含んでいる。ＲＦ回路４００ＥにはアンテナＡＴＮが接続されている。

また、スマートデバイス４００は、スピーカー４００Ｆ、カメラ４００Ｇ、タッチパネル４００Ｈ、ディスプレイ４００Ｉ、及びマイク４００Ｊを含んでいる。ＣＰＵ４００Ａからマイク４００Ｊまでは、内部バス４００Ｋによって互いに接続されている。少なくともＣＰＵ４００ＡとＲＡＭ４００Ｂとが協働することによってコンピュータが実現される。

上述したＲＡＭ４００Ｂには、ＲＯＭ４００ＣやＮＶＭ４００Ｄに記憶されたプログラムがＣＰＵ４００Ａによって格納される。格納されたプログラムをＣＰＵ４００Ａが実行することにより、後述する各種の機能が実現され、また、各種の処理が実行される。尚、プログラムは後述するフローチャートに応じたものとすればよい。

次に、図６から図８までを参照して、ウェアラブルデバイス１００、ゲートウェイ２００、サーバ３００、及びスマートデバイス４００が実現する各機能について説明する。

図６（ａ）は第１実施形態に係るウェアラブルデバイス１００の機能ブロック図の一例である。ウェアラブルデバイス１００は咳有無判定部１０１及び実測データ送信部１０２を備えている。尚、図６（ａ）において、マイク１００Ｄ、気温センサ１００Ｇ、湿度センサ１００Ｈ、及びＢＬＥ回路１００Ｅについてはハードウェアであるため破線で示している。

咳有無判定部１０１はマイク１００Ｄが集音した環境音に基づいて、咳を検知する。例えば、咳有無判定部１０１は１分単位で環境音を解析し、咳を検知したか否かに応じて所定のテーブルに咳「有」又は「無」を格納する。また、咳有無判定部１０１は咳「有」又は「無」を格納する際、気温センサ１００Ｇ及び湿度センサ１００Ｈから気温及び湿度をそれぞれ取得して咳「有」又は「無」と関連付けて所定のテーブルに格納する。さらに、咳有無判定部１０１は所定のテーブル１時間ぶんを１フレームとし、１フレーム内に閾値回数（例えば５回）以上、咳「有」が存在する場合に、その時間帯に咳があったと判定する。これにより、突発的に出た咳（例えば刺激物や粉塵などに基づく咳）と継続的に出る咳（例えば疾病に基づく咳）とを判別することができる。咳有無判定部１０１は１フレームにおける咳の有無とその時間帯における気温及び湿度を関連付け、これらを実測データとして実測データ送信部１０２に出力する。

実測データ送信部１０２は咳有無判定部１０１から出力された実測データを送信する。より詳しくは、実測データ送信部１０２は実測データをＢＬＥ回路１００Ｅを介してゲートウェイ２００に向けて送信する。

図６（ｂ）は第１実施形態に係るゲートウェイ２００の機能ブロック図の一例である。ゲートウェイ２００は実測データ送受信部２０１を備えている。尚、図６（ｂ）において、ＢＬＥ回路２００Ｅ及び無線ＬＡＮ回路２００Ｉについてはハードウェアであるため破線で示している。

実測データ送受信部２０１はウェアラブルデバイス１００から送信された実測データを受信する。より詳しくは、実測データ送受信部２０１は実測データをＢＬＥ回路２００Ｅを介して受信する。また、実測データ送受信部２０１は受信した実測データを送信する。より詳しくは、実測データ送受信部２０１は実測データを無線ＬＡＮ回路２００Ｉを介してサーバ３００に向けて送信する。すなわち、実測データ送受信部２０１はウェアラブルデバイス１００から送信された実測データをサーバ３００に転送する。

図７は第１実施形態に係るサーバ３００の機能ブロック図の一例である。サーバ３００は実測データ記憶部３１０及び関係性モデル第１記憶部３２０を備えている。また、サーバ３００は特徴量算出部３３０、予測部３４０、予測データ記憶部３５０、予測正誤判定部３６０、学習実施判定部３７０、及び関係性学習部３８０を備えている。尚、図７において、ネットワークＩ／Ｆ３００Ｄについてはハードウェアであるため破線で示している。

実測データ記憶部３１０は実測データを記憶する。より詳しくは、実測データ記憶部３１０はゲートウェイ２００から送信されてネットワークＩ／Ｆ３００Ｄを介した実測データを記憶する。

関係性モデル第１記憶部３２０は関係性モデルを記憶する。例えば、関係性モデル第１記憶部３２０は後述する予測処理日から３日後を予測するための関係性モデルを記憶する。関係性モデルは予測する体調不良の種別（例えば咳など）とその発生要因との関係性を体調不良の種別毎に保持している。尚、体調不良の発生要因としては、体調不良が咳である場合、例えば最大気温差や平均湿度などがある。

特徴量算出部３３０は実測データ記憶部３１０が記憶する実測データに基づいて、咳の発生要因の具体的な環境値を特徴量として算出する。特徴量算出部３３０は気温特徴量算出部３３１と湿度特徴量算出部３３２を備えている。気温特徴量算出部３３１は実測データが有する気温に基づいて、最大気温差を特徴量として算出する。尚、気温特徴量算出部３３１が算出する特徴量は平均気温や気温の分散などであってもよい。一方、湿度特徴量算出部３３２は実測データが有する湿度に基づいて、平均湿度を特徴量として算出する。尚、湿度特徴量算出部３３２が算出する特徴量は最大湿度差や湿度の分散などであってもよい。気温特徴量算出部３３１と湿度特徴量算出部３３２は算出した特徴量をそれぞれ予測部３４０に出力する。

予測部３４０は気温特徴量算出部３３１及び湿度特徴量算出部３３２から出力された各特徴量と、関係性モデル第１記憶部３２０が記憶する関係性モデルとに基づいて、予測処理日から３日後に咳が発生する可能性の有無を予測する。具体的には、予測部３４０は各特徴量と関係性モデルとに基づいて、咳が発生する発生確率を算出し、発生確率が所定の閾値以上であるか否かを判定する。予測部３４０は発生確率が所定の閾値以上であれば咳が発生する可能性があると判断し、逆に閾値未満であれば咳が発生する可能性がないと判定する。また、予測部３４０は予測処理日から３日後を咳が発生する発生予定日として特定するとともに、発生主要因を特定する。発生主要因は具体的には最大気温差と平均湿度のいずれかである。発生主要因の特定の詳細については後述する。予測部３４０は発生予定日と発生主要因を特定すると、咳が発生する可能性の有無と発生予定日と発生主要因を含む予測データを生成し、生成した予測データを予測データ記憶部３５０に格納する。また、予測部３４０は予測データに応じた所定の予測メッセージをスマートデバイス４００に向けて送信する。

予測正誤判定部３６０は実測データ記憶部３１０が記憶する実測データと予測データ記憶部３５０が記憶する予測データとを比較して、予測の正誤を判定する。具体的には、予測正誤判定部３６０は咳の発生予測が外れたか否かを判定する。予測正誤判定部３６０は予測の正誤を判定すると、判定結果を学習実施判定部３７０に出力する。

学習実施判定部３７０は、発生予定日に咳が発生しなかった場合、発生予定日を特定してから発生要因が変化しているか否かを判定する。具体的には、学習実施判定部３７０は、予測正誤判定部３６０から予測が誤ったことを表す判定結果を受け付けた場合、予測部３４０で特定した咳の発生主要因に対し、予測後当日までの特徴量が予測時の特徴量から所定の閾値以上改善しているか否かを判定する。学習実施判定部３７０は、発生要因が変化している場合、咳の発生主要因が改善されたことにより咳が発生しなかったと判断し、関係性学習部３８０に学習の中止を通知する。逆に、学習実施判定部３７０は、発生要因が変化していない場合、咳の発生主要因が改善されずに咳が発生しなかったと判断し、関係性学習部３８０に学習の実行を通知する。

関係性学習部３８０は気温特徴量算出部３３１及び湿度特徴量算出部３３２から出力された各特徴量と実測データが有する咳の有無との関係性を学習し、関係性モデルを生成したり、関係性モデル第１記憶部３２０に記憶された関係性モデルを更新したりする。関係性学習部３８０の学習方式は例えばSupport Vector Machine（ＳＶＭ）やNaive Bayes（ＮＢ）といった機械的学習法を利用すればよいが、これらの機械的学習法に特に限定されない。関係性学習部３８０は学習実施判定部３７０から学習の中止が通知された場合には学習を行わずに中止し、逆に、学習の実行が通知された場合には学習を実行する。尚、学習の中止に代えて、関係性学習部３８０は発生要因が変化していない場合に実行される関係性の学習より低い学習度合で関係性を学習するようにしてもよい。

図８はスマートデバイス４００の機能ブロック図の一例である。スマートデバイス４００は予測メッセージ表示部４０１を備えている。尚、図８において、ＲＦ回路４００Ｅについてはハードウェアであるため破線で示している。

予測メッセージ表示部４０１はサーバ３００から送信された予測メッセージを表示する。これにより、利用者は３日後に発生する可能性がある咳を事前に把握することができ、適宜、予防に必要な措置をとることができる。具体的には、予測日から３日後に咳が発生する可能性がある場合、加湿器を用意して湿度を上げる措置をとることができる。

続いて、ウェアラブルデバイス１００、ゲートウェイ２００、サーバ３００、及びスマートデイバス４００の各動作について順に説明する。

図９はウェアラブルデバイス１００の動作の一例を示すフローチャートである。図１０は実測データの生成を説明するための図である。まず、ウェアラブルデバイス１００の咳有無判定部１０１は実測データ送信部１０２が実測データをゲートウェイ２００に送信してから１時間が経過したか否かを判定する（ステップＳ１０１）。

ここで、１時間が経過していない場合（ステップＳ１０１：ＮＯ）、咳有無判定部１０１は咳を検知する（ステップＳ１０２）。より詳しくは、咳有無判定部１０１はマイク１００Ｄが集音した環境音を解析して咳の有無を１分毎に判定し、判定結果を所定のテーブルに格納する。ステップＳ１０２の処理が完了すると、咳有無判定部１０１は気温センサ１００Ｇ及び湿度センサ１００Ｈから気温と湿度を取得する（ステップＳ１０３）。咳有無判定部１０１は気温と湿度を取得すると、判定結果と同様に、取得した気温と湿度を所定のテーブルに格納する。気温と湿度を格納した後、咳有無判定部１０１は再びステップＳ１０１の処理を実行する。したがって、１時間が経過するまで、咳有無判定部１０１は咳の有無を判定して判定結果と気温と湿度とを所定のテーブルに格納する。これにより、図１０（ａ）に示すように、１分毎の咳の有無と気温と湿度が格納された１時間分の所定のテーブルが完成する。

一方、１時間が経過した場合（ステップＳ１０１：ＹＥＳ）、咳有無判定部１００１は咳の有無を判定する（ステップＳ１０４）。より詳しくは、咳有無判定部１０１は１時間分の所定のテーブル（図１０（ａ）参照）を参照し、咳「有」が５回以上格納されている場合、その時間帯について咳「有」と判定する。逆に、１時間以内に咳「有」が５回以上格納されていない場合、その時間帯について咳「無」と判定する。これにより、咳有無判定部１０１は、図１０（ｂ）に示すように、その時間帯についての実測データを生成する。尚、第１実施形態において、咳の有無と関連付ける気温及び湿度はその時間帯の最後の時刻の気温及び湿度を利用するが、例えばその時間帯の最初の時刻の気温及び湿度を利用してもよいし、その時間帯の平均気温及び平均湿度を利用してもよい。咳有無判定部１０１が実測データを生成すると、実測データ送信部１０２は実測データをゲートウェイ２００に送信する（ステップＳ１０５）。ステップＳ１０５の処理が完了すると、咳有無判定部１０１は再びステップＳ１０１の処理を実行する。

図１１はゲートウェイ２００の動作の一例を示すフローチャートである。まず、実測データ送受信部２０１は実測データを受信するまで待機する（ステップＳ２０１：ＮＯ）。実測データ送受信部２０１は実測データを受信すると（ステップＳ２０１：ＹＥＳ）、受信した実測データをサーバ３００に送信する（ステップＳ２０２）。ステップＳ２０２の処理が完了すると、実測データ送受信部２０１は処理を終える。

図１２はサーバ３００の動作の一例を示すフローチャートである。より詳しくは、図１２はサーバ３００による蓄積処理の一例を示すフローチャートである。図１３は実測データ記憶部３１０の一例である。まず、実測データ記憶部３１０は実測データを受信するまで待機する（ステップＳ３０１：ＮＯ）。実測データ記憶部３１０は実測データを受信すると（ステップＳ３０１：ＹＥＳ）、受信した実測データを記憶する（ステップＳ３０２）。これにより、図１３に示すように、実測データ記憶部３１０はウェアラブルデバイス１００から送信された１時間毎の実測データを記憶する。

図１４はサーバ３００の動作の他の一例を示すフローチャートである。より詳しくは、図１４はサーバ３００による予測処理の一例を示すフローチャートである。図１５（ａ）は特徴量の一例である。図１５（ｂ）は予測データ記憶部３５０の一例である。尚、サーバ３００による予測処理は１日１回定時（例えば午前１１時などの午前中）に起動する。

まず、気温特徴量算出部３３１と湿度特徴量算出部３３２は、それぞれ実測データ記憶部３１０から現在から３日前までの気温と湿度を取得する（ステップＳ４０１）。ステップＳ４０１の処理が完了すると、次いで、気温特徴量算出部３３１と湿度特徴量算出部３３２は、それぞれ気温と湿度の各特徴量を算出する（ステップＳ４０２）。具体的には、気温特徴量算出部３３１は特徴量として最大気温差を算出し、湿度特徴量算出部３３２は特徴量として平均湿度を算出する。これにより、図１５（ａ）に示すように、現在から３日前までの最大気温差と平均湿度がそれぞれ算出される。

ステップＳ４０２の処理が完了すると、次いで、予測部３４０は咳有無予測処理を実行する（ステップＳ４０３）。咳有無予測処理は、ステップＳ４０２の処理で算出された最大気温差と平均湿度とに基づいて、予測部３４０が３日後に咳が発生する可能性の有無を予測して、予測結果を表す予測データを生成する処理である。尚、咳有無予測処理の詳細については後述する。これにより、図１５（ｂ）に示すように、予測データが生成される。例えば、予測処理日現在が２０１６年１月１日午前１１時である場合、予測部３４０は２０１６年１月４日に咳が発生する可能性の有無を予測し、発生予定日と発生主要因を特定する。尚、咳が発生する可能性がない場合には（例えばデータＩＤ「Ｂ００１」の場合）、予測部３４０は発生主要因を特定しない。

ステップＳ４０３の処理が完了すると、次いで、予測部３４０は咳「有」を予測したか否かを判定する（ステップＳ４０４）。咳「有」を予測した場合（ステップＳ４０４：ＹＥＳ）、予測部３４０は予測メッセージをスマートデバイス４００に送信する（ステップＳ４０５）。より詳しくは、予測部３４０は生成した予測データに応じた所定の予測メッセージを送信する。一方、咳「有」を予測しなかった場合（ステップＳ４０４：ＮＯ）、予測部３４０はステップＳ４０５の処理をスキップする。ステップＳ４０５の処理が完了すると、予測データ記憶部３５０は予測データを記憶する（ステップＳ４０６）。より詳しくは、予測部３４０が予測データを予測データ記憶部３５０に格納することにより、予測データ記憶部３５０は予測データを記憶する。

続いて、図１６及び図１７を参照して、上述した咳有無予測処理の詳細について説明する。

図１６は咳有無予測処理の一例を示すフローチャートである。図１７は関係性モデル第１記憶部３２０の一例である。より詳しくは、図１７は関係性モデル第１記憶部３２０が記憶する３日後予測用の関係性モデルの一例である。尚、第１実施形態では、関係性モデル第１記憶部３２０は３日後予測用の関係性モデルを予め記憶している。

上述したステップＳ４０２の処理が完了すると、予測部３４０は関係性モデル第１記憶部３２０から関係性モデルを取得する（ステップＳ５０１）。ステップＳ５０１の処理が完了すると、次いで、予測部３４０は算出した最大気温差及び平均湿度が関係性モデルの判定基準を満たすか否かを判定する（ステップＳ５０２）。

ここで、予測部３４０が最大気温差「２０℃」及び平均湿度「２９％」を算出した場合に（図１５（ａ）参照）、図１７に示すように、関係性モデルにおける対応する判定基準がそれぞれ最大気温差「１５℃以上」及び平均湿度「３０％未満」であると、予測部３４０は判定基準を満たすと判定する（ステップＳ５０２：ＹＥＳ）。すなわち、最大気温差及び平均湿度が両方の判定基準も満たす場合に、予測部３４０は判定基準を満たすと判定する。逆に、最大気温差及び平均湿度がどちらか一方の判定基準を満たす場合、又は、どちらの判定基準も満たさない場合、予測部３４０は判定基準を満たさないと判定する（ステップＳ５０２：ＮＯ）。尚、関係性モデルにおける有効性は体調不良を引き起こす要因となるか否かを示しており、有効性「有効」は体調不良を引き起こす要因となることを示している。

ここで、判定基準を満たす場合、予測部３４０は３日後に咳「有」を設定する（ステップＳ５０３）。ステップＳ５０３の処理が完了すると、次いで、予測部３４０は特徴量としての最大気温差と判定基準における最大気温差との温度差を算出する（ステップＳ５０４）。ステップＳ５０４の処理が完了すると、次いで、予測部３４０は特徴量としての平均湿度と判定基準における平均湿度との湿度差を算出する（ステップＳ５０５）。ステップＳ５０５の処理が完了すると、次いで、予測部３４０は温度差が湿度差より大きいか否かを判定する（ステップＳ５０６）。

温度差が湿度差より大きい場合（ステップＳ５０６：ＹＥＳ）、予測部３４０は発生主要因「最大気温差」を設定する（ステップＳ５０７）。すなわち、３日後に発生すると予測される咳の発生主要因が最大気温差であると特定される。一方、温度差が湿度差以下の場合（ステップＳ５０６：ＮＯ）、予測部３４０は発生主要因「平均湿度」を設定する（ステップＳ５０８）。すなわち、３日後に発生すると予測される咳の発生主要因が平均湿度であると特定される。ステップＳ５０７又はステップＳ５０８の処理が完了すると、予測部３４０は咳有無予測処理を終える。

尚、ステップＳ５０２の処理において、判定基準を満たさなかった場合、予測部３４０は３日後に咳「無」を設定する（ステップＳ５０９）。ステップＳ５０９の処理が完了すると、予測部３４０は咳有無予測処理を終える。以上により、上述した予測データ（図１５（ｂ）参照）が生成される。

図１８は第１実施形態に係るサーバ３００による学習処理（その１）の一例を示すフローチャートである。図１９は第１実施形態に係るサーバ３００による学習処理（その２）の一例を示すフローチャートである。図２０は発生主要因の変化について説明する図である。尚、サーバ３００による学習処理は１日１回定時（例えば午前０時などの夜間）に起動する。

まず、気温特徴量算出部３３１と湿度特徴量算出部３３２はそれぞれ実測データ記憶部３１０から６日前から３日前までの実測データを取得する（ステップＳ６０１）。ステップＳ６０１の処理が完了すると、次いで、気温特徴量算出部３３１と湿度特徴量算出部３３２はそれぞれ気温と湿度の各特徴量を算出する（ステップＳ６０２）。具体的には、気温特徴量算出部３３１は特徴量として最大気温差を算出し、湿度特徴量算出部３３２は特徴量として平均湿度を算出する。これにより、図２０（ａ）に示すように、６日前から３日前までの最大気温差と平均湿度がそれぞれ算出される。気温特徴量算出部３３１と湿度特徴量算出部３３２は算出した各特徴量を学習実施判定部３７０に出力する。

ステップＳ６０２の処理が完了すると、次いで、予測正誤判定部３６０は実測データ記憶部３１０から学習処理当日の実測データを取得する（ステップＳ６０３）。例えば、学習処理当日が２０１６年１月４日である場合、予測正誤判定部３６０は実測データ記憶部３１０から２０１６年１月４日の実測データを取得する。

ステップＳ６０３の処理が完了すると、次いで、予測正誤判定部３６０は取得した実測データに咳「有」が所定値（例えば１２回）以上あるか否かを判定する（ステップＳ６０４）。ここで、咳「有」が所定値以上でない場合（ステップＳ６０４：ＮＯ）、予測正誤判定部３６０は学習処理当日の予測データを取得する（ステップＳ６０５）。ステップＳ６０５の処理が完了すると、次いで、予測正誤判定部３６０は取得した予測データにおいて咳「有」が予測されているか否かを判定する（ステップＳ６０６）。すなわち、学習処理当日の咳の発生状況と予測時の咳の発生予測により、予測正誤判定部３６０は予測が正しかったか否かを判定する。

咳「有」が予測されている場合（ステップＳ６０６：ＹＥＳ）、気温特徴量算出部３３１と湿度特徴量算出部３３２はそれぞれ実測データ記憶部３１０から３日前から現在までの気温と湿度を取得する（ステップＳ６０７）。すなわち、ステップＳ６０４の処理によって学習処理当日に咳が発生していないと判定されたにも関わらず、予測時に咳が発生する可能性があると予測されていた場合、予測は外れている。この場合、気温特徴量算出部３３１と湿度特徴量算出部３３２はそれぞれ３日前から現在までの気温と湿度を取得する。

ステップＳ６０７の処理が完了すると、図１９に示すように、気温特徴量算出部３３１と湿度特徴量算出部３３２はそれぞれ気温と湿度の各特徴量を算出する（ステップＳ６０８）。具体的には、気温特徴量算出部３３１は特徴量として最大気温差を算出し、湿度特徴量算出部３３２は特徴量として平均湿度を算出する。これにより、図２０（ｂ）に示すように、３日前から現在までの最大気温差と平均湿度がそれぞれ算出される。

ステップＳ６０８の処理が完了すると、次いで、予測正誤判定部３６０は予測データ記憶部３５０から学習処理当日の予測データを取得する（ステップＳ６０９）。予測正誤判定部３６０は予測データを取得すると、予測データに含まれる発生主要因を学習実施判定部３７０に出力する。

学習実施判定部３７０は予測正誤判定部３６０から出力された発生主要因について、対応する特徴量を比較する（ステップＳ６１０）。すなわち、発生主要因が最大気温差である場合には、学習実施判定部３７０は特徴量としてそれぞれ算出した６日前から３日前までの最大気温差と３日前から現在までの最大気温差を比較する。発生主要因が平均湿度である場合には、学習実施判定部３７０は特徴量としてそれぞれ算出した６日前から３日前までの平均湿度と３日前から現在までの平均湿度を比較する。

ステップＳ６１０の処理が完了すると、次いで、学習実施判定部３７０は発生主要因が十分に変化しているか否かを判定する（ステップＳ６１１）。例えば、図２０（ａ）及び（ｂ）に示すように、発生主要因が最大気温差である場合に、１０℃以上最大気温差が小さくなっている場合、予測メッセージに従って利用者は予測時（例えば２０１６年１月１日）から自身の環境を変えたと判断し、学習実施判定部３７０は発生主要因が十分に変化したと判定する（ステップＳ６１１：ＹＥＳ）。逆に、１０℃以上最大気温差が小さくなっていない場合、予測メッセージに従わずに利用者は予測時から自身の環境を変えなかったと判断し、学習実施判定部３７０は発生主要因が十分に変化していないと判定する（ステップＳ６１１：ＮＯ）。尚、発生主要因が平均湿度である場合、６日前から３日前までの平均湿度と３日前から現在までの平均湿度の差が１５％以上大きくなっていれば、湿度が上昇しているため、学習実施判定部３７０は発生主要因が十分に変化したと判定する。

発生主要因が十分に変化していない場合、学習実施判定部３７０は関係性学習部３８０に学習の実行を通知する。また、ステップＳ６０４の処理において咳「有」が所定値以上である場合（ステップＳ６０４：ＹＥＳ）や、ステップＳ６０６の処理において咳「有」が予測されていない場合（ステップＳ６０６：ＮＯ）も同様に学習実施判定部３７０は関係性学習部３８０に学習の実行を通知する。これにより、関係性学習部３８０は関係性学習処理を実行する（ステップＳ６１２）。関係性学習処理は咳の有無と発生主要因との関係性を学習する処理である。尚、関係性学習処理の詳細については後述する。一方、発生主要因が十分に変化している場合、学習実施判定部３７０は関係性学習部３８０に学習の中止を通知する。これにより、関係性学習部３８０はステップＳ６１２の処理をスキップする。このように、予測が外れていても、予測メッセージの確認時から利用者の環境が咳の発生を抑える方向に十分に変化していれば、関係性学習部３８０は学習を実行しない。これにより、次回予測時に注意喚起されにくくなることが回避される。

続いて、図２１及び図２２を参照して、上述した関係性学習処理の詳細について説明する。

図２１は第１実施形態に係る関係性学習処理の一例を示すフローチャートである。図２２は第１実施形態に係る関係性モデルの更新例を説明する図である。上述したように、ステップＳ６１１の処理において、発生主要因が十分に変化していない場合、図２１に示すように、関係性学習部３８０は咳「有」が所定値以上であるか否かを判定する（ステップＳ７０１）。より詳しくは、関係性学習部３８０は実測データ記憶部３１０から学習日当日の実測データを取得し、実測データに咳「有」が所定値以上で含まれているか否かを判定する。

ここで、咳「有」が所定値以上である場合（ステップＳ７０１：ＹＥＳ）、関係性学習部３８０は関係性モデル第１記憶部３２０から関係性モデルを取得し（ステップＳ７０２）、判定基準外で咳が発生したか否かを判定する（ステップＳ７０３）。例えば、図２２（ａ）に示すように、関係性学習部３８０が更新前の所定の関係性モデルを取得した場合、最大気温差の判定基準として１５℃以上、平均湿度として３０％未満が定義されているにも関わらず、実際には最大気温差１０℃、平均湿度２９％で咳が発生していれば、関係性学習部３８０は最大気温差の判定基準外で咳が発生したと判定する（ステップＳ７０３：ＹＥＳ）。この場合、関係性学習部３８０は、咳「有」に予測し易い方向に判定基準を変更する（ステップＳ７０４）。例えば、図２２（ｂ）に示すように、関係性学習部３８０は最大気温差の判定基準を予め定めた温度（例えば２℃）下げる。これにより、咳「有」が予測され易くなる。ステップＳ７０４の処理が完了すると、関係性学習部３８０は関係性学習処理を終了する。逆に、関係性学習部３８０は最大気温差の判定基準外で咳が発生していないと判定した場合（ステップＳ７０３：ＮＯ）、ステップＳ７０４の処理をスキップして、関係性学習部３８０は関係性学習処理を終了する。

一方、ステップＳ７０１の処理において、咳「有」が所定値以上でない場合（ステップＳ７０１：ＮＯ）、関係性学習部３８０は関係性モデル第１記憶部３２０から関係性モデルを取得し（ステップＳ７０５）、判定基準内で咳が発生したか否かを判定する（ステップＳ７０６）。例えば、図２２（ａ）に示すように、関係性学習部３８０が更新前の所定の関係性モデルを取得した場合、最大気温差の判定基準として１５℃以上、平均湿度として３０％未満が定義されているにも関わらず、実際には最大気温差２０℃、平均湿度２９％で咳が発生していれば、関係性学習部３８０は最大気温差の判定基準内で咳が発生したと判定する（ステップＳ７０６：ＹＥＳ）。この場合、関係性学習部３８０は、咳「有」に予測しにくい方向に判定基準を変更する（ステップＳ７０７）。例えば、図２２（ｃ）に示すように、関係性学習部３８０は最大気温差の判定基準を予め定めた温度（例えば２℃）上げる。これにより、咳「有」が予測されにくくなる。ステップＳ７０７の処理が完了すると、関係性学習部３８０は関係性学習処理を終了する。逆に、関係性学習部３８０は最大気温差の判定基準内で咳が発生していないと判定した場合、（ステップＳ７０６：ＮＯ）、ステップＳ７０７の処理をスキップして、関係性学習処理を終了する。

続いて、図２３を参照して、上述した予測処理及び学習処理をさらに詳しく説明する。

図２３は予測と学習の関係の一例を説明する図である。まず、予測では、例えば２０１６年１月１日を当日として３日後である１月４日の咳の発生予測を行う場合、３日前から当日までの実測データと関係性モデル第１記憶部３２０に記憶された３日後予測用の関係性モデルとを利用して、発生予測が行われる。

次に、学習では、予測日から３日後である２０１６年１月４日を当日として、まず、予測結果と実際の咳の発生を比較する。例えば１月４日に咳が発生しなかったにも関わらず、１月１日の予測時点では１月４日に咳が発生すると予測されている場合、次に、予測利用範囲と学習実施判定範囲とを比較して利用者の環境が変化したか否かが判定される。そして、最後に、利用者の環境が変化していれば、関係性モデルの学習を中止する。この結果、予測と学習が時系列に進行することで、３日後の咳の発生予測と実際の咳の発生とに基づいて、関係性モデルが定期的に更新されていく。

続いて、図２４及び図２５を参照して、スマートデバイス４００の動作について説明する。

図２４はスマートデバイス４００の動作の一例を示すフローチャートである。図２５は予測メッセージの一例である。まず、図２４に示すように、予測メッセージ表示部４０１はサーバ３００から送信された予測メッセージを受信するまで待機する（ステップＳ８０１：ＮＯ）。予測メッセージ表示部４０１は予測メッセージを受信すると（ステップＳ８０１：ＹＥＳ）、予測メッセージを表示し（ステップＳ８０２）、処理を終える。これにより、図２５に示すように、スマートデバイス４００には予測メッセージが表示され、利用者は予測メッセージに従った措置をとることができる。

以上説明したように、第１実施形態では、予測部３４０と学習実施判定部３７０と関係性学習部３８０とを備えている。予測部３４０は体調不良とその発生要因との関係性を体調不良の種別毎に記憶する関係性モデル第１記憶部３２０を参照して、体調不良が発生する発生予定日を特定する。学習実施判定部３７０は発生予定日に体調不良が発生しなかった場合、発生予定日を特定してから発生要因が変化しているか否かを判定する。関係性学習部３８０は発生要因が変化している場合、発生要因が変化していない場合に実行される関係性の学習より低い学習度合で関係性を学習する。望ましくは、関係性学習部３８０は発生要因が変化している場合、関係性の学習を行わずに中止する。これにより、体調不良の発生予測が外れた場合に、体調不良とその発生要因の関係性の学習を抑制することができる。

（第２実施形態）
続いて、図２６から図２８までを参照して、本件の第２実施形態について説明する。
図２６は第２実施形態に係るサーバ３００による学習処理（その２）の一部を例示するフローチャートである。

第２実施形態では、第１実施形態で説明したステップＳ６１１の処理において、発生主要因が十分に変化している場合、図２６に示すように、学習実施判定部３７０は所定の重みを設定する（ステップＳ９０１）。当該重みは、体調不良が発生すると予測しにくい場合と比較して体調不良が発生すると予測し易くなる重みである。ステップＳ９０１の処理が完了すると、学習実施判定部３７０は学習の実行を関係性学習部３８０に通知する。これにより、関係性学習部３８０は第１実施形態と異なる関係性学習処理を実行する（ステップＳ９０２）。

図２７は第２実施形態に係る関係性学習処理の一例を示すフローチャートである。図２８は第２実施形態に係る関係性モデルの更新例を説明する図である。上述したステップＳ９０１の処理が完了すると、第１実施形態で説明したように、関係性学習部３８０はステップＳ７０１の処理を実行する。ここで、咳「有」が所定値以上でない場合、関係性学習部３８０はさらに重みが設定されているか否かを判定する（ステップＳ９０３）。

重みが設定されている場合（ステップＳ９０３：ＹＥＳ）、関係性学習部３８０は第１実施形態で説明したステップＳ７０２の処理を実行する。ステップＳ７０２の処理が完了すると、関係性学習部３８０は第１実施形態で説明したステップＳ７０３の処理を実行せずに、ステップＳ７０４の処理を実行する。逆に、重みが設定されていない場合（ステップＳ９０３：ＮＯ）、関係性学習部３８０は第１実施形態で説明したステップＳ７０５の処理を実行する。ステップＳ７０５の処理が完了すると、関係性学習部３８０は第１実施形態で説明したステップＳ７０６の処理を実行せずに、ステップＳ７０７の処理を実行する。ステップＳ７０４又はステップＳ７０７の処理が完了すると、関係性学習部３８０は関係性学習処理を終える。

このように、図２６に示すステップＳ９０１の処理において学習実施判定部３７０が所定の重みを設定している場合には、図２７に示すように、ステップＳ７０１の処理において咳「有」が所定値以上である場合でもない場合でも、関係性学習部３８０はステップＳ７０２及びＳ７０４の処理を実行する。これにより、例えば、図２８（ａ）に示すように、関係性モデル第１記憶部３２０が更新前の所定の関係性モデルを記憶している場合に、咳があり、最大気温差の判定基準「１５℃以上」及び平均湿度の判定基準「３０％未満」のいずれも満たさない最大気温差「１０℃」及び平均湿度「３５％」が算出されると、図２８（ｂ）に示すように、関係性学習部３８０は最大気温差の判定基準を予め定めた温度（例えば２℃）下げ、平均湿度の判定基準を予め定めた湿度（例えば２％）上げる。これにより、咳「有」が予測され易くなる。

一方、咳がなく、最大気温差の判定基準「１５℃以上」及び平均湿度の判定基準「３０％未満」の両方をも満たす最大気温差「１５℃」及び平均湿度「２９％」が算出された場合も、図２８（ｃ）に示すように、関係性学習部３８０は最大気温差の判定基準を予め定めた温度（例えば２℃）下げ、平均湿度の判定基準を予め定めた湿度（例えば２％）上げる。これにより、咳「有」が予測され易くなる。

以上説明したように、第１実施形態では発生主要因が十分に変化している場合、関係性学習部３８０は学習を中止していたが、第２実施形態では、発生主要因が十分に変化していても、関係性学習部３８０は学習を実行する。ただし、第２実施形態の場合、発生主要因が十分に変化していない場合に実行される学習に比べて、咳「有」を予測し易い方向に関係性学習部３８０は学習を実行する。これにより、次回予測時に咳「有」が予測され易くなる。

（第３実施形態）
続いて、図２９を参照して、本件の第３実施形態について説明する。
図２９は第３実施形態に係るサーバ３００の機能ブロック図の一例である。尚、第１実施形態に係るサーバ３００と同一の構成には同一の符号を付し、その説明を省略する。

図２９に示すように、サーバ３００は、さらに、関係性モデル第２記憶部３２１及び関係性モデル第３記憶部３２２を備えている。上述した第１実施形態では、関係性モデル第１記憶部３２０が３日後予測用の関係性モデルを記憶することを説明した。第３実施形態では、さらに、関係性モデル第２記憶部３２１が１週間後予測用の関係性モデルを記憶し、関係性モデル第３記憶部３２１が１日後予測用の関係性モデルを記憶する。

したがって、予測部３４０は３日後予測用の関係性モデル、１週間後予測用の関係性モデル、及び１日後予測用の関係性モデルのそれぞれに基づいて、３日後、１週間後、及び１日後のそれぞれの咳の発生の可能性の有無を予測する予測データを生成する。そして、予測部３４０はこれらの予測データに応じた所定の予測メッセージをスマートデバイス４００に向けて送信する。

これにより、利用者は３日後に発生する可能性がある咳だけでなく、１週間後及び１日後に発生する可能性がある咳を事前に把握することができ、適宜、予防に必要な措置をとることができる。

（第４実施形態）
続いて、図３０から図３２までを参照して、本件の第４実施形態について説明する。
図３０は第４実施形態に係るウェアラブルデバイス１００の機能ブロック図の一例である。図３１は第４実施形態に係るゲートウェイ２００の機能ブロック図の一例である。図３２は第４実施形態に係るサーバ３００の機能ブロック図の一例である。特に、図３２ではサーバ３００の機能ブロック図を部分的に示しており、関係性モデル第１記憶部３２０及び予測データ記憶部３５０は省略されて示されている。

まず、図３０に示すように、第４実施形態に係るウェアラブルデバイス１００は、睡眠時間検知部１０３、自律神経検知部１０４、及び帰宅検知部１０５をさらに備える点で第１実施形態と相違する。

睡眠時間検知部１０３はマイク１００Ｄが集音した環境音と加速度センサ１００Ｆが検知した動きとに基づいて、睡眠時間を検知する。例えば、環境音に特徴的な音（例えば寝息といった呼吸音や布団がこすれる音など）が含まれており、一定時間にわたって利用者に大きな又は全く動きがなければ、睡眠時間検知部１０３は利用者が入眠したと判定する。一方、歩行などを表す特徴的な動きがあれば、睡眠時間検知部１０３は利用者が起床したと判定する。睡眠時間検知部１０３は入眠した時刻と起床した時刻の差分に基づいて、睡眠時間を検知する。このように、睡眠時間検知部１０３が検知した睡眠時間を体調不良の発生要因（例えば頭痛の発生要因など）の１つとして利用することができる。

自律神経検知部１０４は脈拍センサ１００ＩからＲ波を検知するとともに、検知した時刻を取得する。自律神経検知部１０４はＲ波を蓄積し、心拍変動を算出する。自律神経検知部１０４は算出した心拍変動がＨＦ（０．１５Ｈｚ〜０．４Ｈｚといった高周波）＞ＬＦ（０．０４Ｈｚ〜０．１５Ｈｚといった低周波）を満たす場合、副交感神経優位（リラックス状態）と判定する。逆に、自律神経検知部１０４は算出した心拍変動がＨＦ＞ＬＦを満たさない場合、交感神経優位（緊張状態）と判定する。自律神経検知部１０４は副交感神経優位及び交感神経優位のそれぞれの開始時刻及び終了時刻を記録し、副交感神経優位及び交換神経優位のそれぞれの継続時間を算出する。このように、自律神経検知部１０４が算出した継続時間を体調不良の発生要因（例えば肩こりの発生要因など）の１つとして利用することができる。尚、加速度センサ１００Ｆによるウェアラブルデバイス１００の着脱を表す動きも自律神経検知部１０４に入力し、例えばウェアラブルデバイス１００が利用者に装着されているときにのみ、自律神経検知部１０４が稼働するようにしてもよい。

帰宅検知部１０５はＧＰＳセンサ１００Ｊから取得される位置情報に基づいて、利用者の家屋Ｘへの帰宅を検知する。例えば、家屋Ｘの立地領域内にＧＰＳセンサ１００Ｊによる位置情報が含まれていれば、帰宅検知部１０５は立地領域内に位置情報が含まれた時刻を帰宅時刻として検知する。このように、帰宅検知部１０５が検知した帰宅時刻が一定期間にわたってばらばらであったり、所定値以上の割合で所定時刻より遅かったりする場合には、帰宅時刻を体調不良の発生要因（例えば発熱の発生要因など）の１つとして利用することができる。

次に、図３１に示すように、第４実施形態に係るゲートウェイ２００は、帰宅検知部２０２をさらに備える点で第１実施形態と相違する。上述したように、ウェアラブルデバイス１００に帰宅検知部１０５を設けずに、ゲートウェイ２００に帰宅検知部２０２を設けるようにしてもよい。

帰宅検知部２０２はＢＬＥ回路２００Ｅからウェアラブルデバイス１００がゲートウェイ２００にＢＬＥ接続した時刻を取得する。帰宅検知部２０２は取得した時刻を帰宅時刻と判定する。帰宅誤判定防止のために、ＢＬＥ接続が切断された後、所定閾値時間（例えば数分）以内の再接続については、帰宅検知部２０２は帰宅と判定しないようにしてもよい。帰宅検知部２０２によっても帰宅検知部１０５と同様の効果を得ることができる。尚、帰宅検知部２０２は人感センサ２００Ｈが利用者の気配を検知したときに、検知した時刻を帰宅時刻と判定してもよい。

次に、図３２に示すように、第４実施形態に係るサーバ３００は、特徴量算出部３３０が睡眠特徴量算出部３３３、帰宅特徴量算出部３３４、及び神経特徴量算出部３３５をさらに備える点で第１実施形態に係るサーバ３００と相違する。例えば、第１実施形態で説明した実測データに睡眠時間、帰宅時刻、並びに交換神経優位の継続時間及び副交換神経優位の継続時間が含まれている場合に、睡眠特徴量算出部３３３、帰宅特徴量算出部３３４、及び神経特徴量算出部３３５は稼働する。

睡眠特徴量算出部３３３は実測データに含まれる睡眠時間に基づいて、平均睡眠時間を特徴量として算出する。
帰宅特徴量算出部３３４は実測データに含まれる帰宅時刻に基づいて、平均帰宅時刻を特徴量として算出する。
神経特徴量算出部３３５は実測データに含まれる交換神経優位の継続時間及び副交換神経優位の継続時間に基づいて、これらの継続時間の各割合（例えば６０％：４０％など）を特徴量として算出する。

これにより、予測部３４０は温度及び湿度の特徴量だけでなく、睡眠時間、帰宅時刻、並びに交換神経優位の継続時間及び副交換神経優位の継続時間の各特徴量に基づいて、体調不良に関する精密な予測データを生成することができる。また、関係性学習部３８０はこれらの特徴量に基づいて、関係性モデル（例えば３日後予測用関係性モデルなど）を高い精度で更新することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。例えば、上述した実施形態では、生体データ及び環境データの一例としてＲ波並びに温度及び湿度を利用したが、例えば生体データとして心拍数や体温を利用したり、環境データとして照度を利用したりしてもよい。また、上述した６日前、３日前、１日後、３日後、１週間後は例示であって、過去何日前に設定するか、何日後を予測するかは適宜変更してもよい。さらに、上述した第２実施形態から第４実施形態を適宜組み合わせてもよい。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１）体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、処理をコンピュータが実行する体調不良予測方法。
（付記２）前記処理は、前記発生要因が変化している場合、前記関係性の学習を行わない、ことを特徴とする付記１に記載の体調不良予測方法。
（付記３）前記処理は、前記発生要因が変化している場合、前記体調不良が発生すると予測しにくい場合と比較して前記体調不良が発生すると予測し易くなる重みを設定して、前記関係性を学習する、ことを特徴とする付記１に記載の体調不良予測方法。
（付記４）前記処理は、前記発生予定日毎に前記関係性を分けて学習する、ことを特徴とする付記１又は３に記載の体調不良予測方法。
（付記５）前記処理は、前記発生予定日を特定してからの利用者の生体情報又は前記利用者の周囲の環境情報の少なくともいずれかの変化に基づいて、前記発生要因が変化しているか否かを判定する、ことを特徴とする付記１から４のいずれか１項に記載の体調不良予測方法。
（付記６）体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、処理をコンピュータに実行させる体調不良予測プログラム。
（付記７）体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、処理を実行する処理部を備える体調不良予測装置。
（付記８）前記処理部は、前記発生要因が変化している場合、前記関係性の学習を行わない、ことを特徴とする付記７に記載の体調不良予測装置。
（付記９）前記処理部は、前記発生要因が変化している場合、前記体調不良が発生すると予測しにくい場合と比較して前記体調不良が発生すると予測し易くなる重みを設定して、前記関係性を学習する、ことを特徴とする付記７に記載の体調不良予測装置。
（付記１０）前記処理部は、前記発生予定日毎に前記関係性を分けて学習する、ことを特徴とする付記７又は９に記載の体調不良予測装置。
（付記１１）前記処理部は、前記発生予定日を特定してからの利用者の生体情報又は前記利用者の周囲の環境情報の少なくともいずれかの変化に基づいて、前記発生要因が変化しているか否かを判定する、ことを特徴とする付記７から１０のいずれか１項に記載の体調不良予測装置。

Ｓ 体調不良予測システム
１００ ウェアラブルデバイス
２００ ゲートウェイ
３００ サーバ
３３０ 特徴量算出部
３４０ 予測部
３６０ 予測正誤判定部
３７０ 学習実施判定部
３８０ 関係性学習部
４００ スマートデバイス

Claims (7)

1. 体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、
   前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、
   前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、
   処理をコンピュータが実行する体調不良予測方法。
2. 前記処理は、前記発生要因が変化している場合、前記関係性の学習を行わない、
   ことを特徴とする請求項１に記載の体調不良予測方法。
3. 前記処理は、前記発生要因が変化している場合、前記体調不良が発生すると予測しにくい場合と比較して前記体調不良が発生すると予測し易くなる重みを設定して、前記関係性を学習する、
   ことを特徴とする請求項１に記載の体調不良予測方法。
4. 前記処理は、前記発生予定日毎に前記関係性を分けて学習する、
   ことを特徴とする請求項１又は３に記載の体調不良予測方法。
5. 前記処理は、前記発生予定日を特定してからの利用者の生体情報又は前記利用者の周囲の環境情報の少なくともいずれかの変化に基づいて、前記発生要因が変化しているか否かを判定する、
   ことを特徴とする請求項１から４のいずれか１項に記載の体調不良予測方法。
6. 体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、
   前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、
   前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、
   処理をコンピュータに実行させる体調不良予測プログラム。
7. 体調不良と前記体調不良の発生要因との関係性を前記体調不良の種別毎に記憶する記憶部を参照して、前記体調不良が発生する発生予定日を特定し、
   前記発生予定日に前記体調不良が発生しなかった場合、前記発生予定日を特定してから前記発生要因が変化しているか否かを判定し、
   前記発生要因が変化している場合、前記発生要因が変化していない場合に実行される前記関係性の学習より低い学習度合で前記関係性を学習する、
   処理を実行する処理部を備える体調不良予測装置。

Images