JP7390594B2 - 情報処理方法及び情報処理装置 - Google Patents

Description

本開示は、睡眠中の人が存在する空間に設置された空調装置を制御する情報処理方法及び情報処理装置に関するものである。

従来、人が睡眠している空間の空調制御方法としては、例えば、特許文献１に記載の技術がある。

特許文献１では、室内温度、室内相対湿度、気流速度、平均放射温度、人体の代謝量及び着衣の熱抵抗から人体の熱収支量Ｑを算出し、熱収支量Ｑが所定値になるように空気調和を実行する空調装置が提案されている。

また、例えば、非特許文献１は、夏期の睡眠時における最適な冷房条件についての実験結果を開示している。非特許文献１では、夏期の睡眠時において、空気温度を２８℃～２９℃の一定に制御し、入眠時の湿度を４０％前後に設定し、体温が安定し始める約３時間後の湿度を６０％前後に上昇させることが最適な制御方法として開示されている。

特許第４５３８９４１号明細書

川島庸、垣鍔直、「夏期の睡眠時における最適な冷房条件に関する実験的研究」人間と生活環境、人間－生活環境系学会、２００４年、第１１巻、第１号、ｐ．１７－２３

特許文献１記載の空調装置では、睡眠中の熱収支量Ｑが所定値になるように、温度及び湿度を制御している。しかしながら、快適な温熱環境は、睡眠中一定とは限らない。そのため、特許文献１記載の空調装置では、人の睡眠中の快適性が損なわれるおそれがある。

本開示は、上記の問題を解決するためになされたもので、人に対する快適な睡眠環境を実現することができる情報処理方法及び情報処理装置を提供することを目的とするものである。

本開示の一態様に係る情報処理方法は、コンピュータが、睡眠中の人が存在する、空調装置が設置された空間に存在するセンサによって測定された少なくとも温度及び湿度を取得し、前記人の入眠を判定するための入眠判定情報を取得し、取得した前記入眠判定情報から前記人が入眠したと判定した後、取得した前記少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報を決定し、決定した前記送風制御情報を用いて前記空調装置の送風を制御する。

本開示によれば、人に対する快適な睡眠環境を実現することができる。

本開示の実施の形態における空調制御システムが提供するサービスの全体像を示す図である。 機器メーカがデータセンタ運営会社に該当する例を示す図である。 機器メーカ及び管理会社の両者又はいずれか一方がデータセンタ運営会社に該当する例を示す図である。 本開示の実施の形態における空調制御システムの構成を示すブロック図である。 人の睡眠状態を説明するための図である。 センサ情報取得部によって取得されたセンサ情報と制御情報取得部によって取得された空調制御情報とを格納する履歴ＤＢのテーブル構造の一例を示す図である。 睡眠状態情報取得部によって取得された睡眠状態情報及び生体情報を格納する履歴ＤＢのテーブル構造の一例を示す図である。 睡眠前に睡眠開始予定時刻及び起床予定時刻の設定を受け付ける際に端末に表示される表示画面の一例を示す図である。 起床時に睡眠中の温熱環境に対する主観評価のユーザによる入力を受け付ける際に端末に表示される表示画面の一例を示す図である。 インターフェースによって取得された温熱環境主観評価を格納する履歴ＤＢのテーブル構造の一例を示す図である。 本開示の実施の形態における設定ＤＢのテーブル構造の一例を示す図である。 本開示の実施の形態における空調装置の制御の流れを時系列に説明するためのグラフである。 本開示の実施の形態の空調装置及びクラウドサーバにおけるデータ蓄積処理を説明するためのフローチャートである。 本開示の実施の形態の睡眠状態検知機及びクラウドサーバにおけるデータ蓄積処理を説明するためのフローチャートである。 本開示の実施の形態のクラウドサーバにおける空調設定処理を説明するためのフローチャートである。 本開示の実施の形態のクラウドサーバにおける温熱指標上昇処理を説明するためのフローチャートである。 本開示の実施の形態において、温熱指標の上昇を開始するタイミングを睡眠周期に応じて決定する例について説明するための図である。 本開示の実施の形態において、空調装置の制御パラメータを変更するタイミングの他の例を説明するための図である。 本開示の実施の形態において、起床予定時刻よりも前の温熱指標上昇終了時刻までに起床時温熱指標に到達するように温熱指標を上昇させる例を説明するための図である。 本開示の実施の形態において、温熱指標としてＰＭＶを用いる場合のクラウドサーバにおける温熱指標上昇処理を説明するためのフローチャートである。 サービスの類型１（自社データセンタ型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。 サービスの類型２（ＩａａＳ利用型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。 サービスの類型３（ＰａａＳ利用型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。 サービスの類型４（ＳａａＳ利用型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。

（本開示の基礎となった知見）
上記の特許文献１記載の空調装置では、睡眠中の熱収支量Ｑが所定値になるように、温度及び湿度を制御している。しかしながら、快適な温熱環境は、睡眠中一定とは限らない。例えば、人は、深部体温が、夜に低くなり、明け方に上昇するという生体リズムになっている。そのため、この生体リズムに合わせて、徐々に室内温熱環境を暖めていくことが好ましいと考えられている。

また、空調装置からの風量が多くなると騒音が発生するとともに、風が直接人の肌に触れるおそれがあり、人の睡眠中の快適性が損なわれるおそれがある。

以上の課題を解決するために、本開示の一態様に係る情報処理方法は、コンピュータが、睡眠中の人が存在する、空調装置が設置された空間に存在するセンサによって測定された少なくとも温度及び湿度を取得し、前記人の入眠を判定するための入眠判定情報を取得し、取得した前記入眠判定情報から前記人が入眠したと判定した後、取得した前記少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報を決定し、決定した前記送風制御情報を用いて前記空調装置の送風を制御する。

この構成によれば、人が入眠したと判定された後、睡眠中の人が存在する、空調装置が設置された空間に存在するセンサによって測定された少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報が決定され、決定された送風制御情報を用いて空調装置の送風が制御されるので、空調装置からの風量を低減することにより、空調装置から発生する騒音を低減するとともに、風が直接人の肌に触れることを防止し、人に対する快適な睡眠環境を実現することができる。

また、上記の情報処理方法において、さらに、前記送風制御情報を用いた送風の制御を開始した後に、前記指標値を前記目標指標値に近づけるための温度に関する温度制御情報を決定し、さらに、決定した前記温度制御情報を用いて前記空調装置の設定温度を制御してもよい。

この構成によれば、送風制御情報を用いた送風の制御が開始された後に、指標値を目標指標値に近づけるための温度が決定され、空間内の温度が、決定された温度になるように空調装置の設定温度が制御されるので、空調装置の設定温度が制御されることにより、指標値を目標指標値に近づけることができ、人に対する快適な睡眠環境を実現することができる。快適な睡眠環境を実現することは、言い換えると、人の眠りが浅くなったり、人が睡眠中に覚醒したりすることを抑制することである。

また、上記の情報処理方法において、さらに、前記送風制御情報を用いた送風の制御を開始した後に、前記空調装置の除湿運転を制御してもよい。

この構成によれば、送風制御情報を用いた送風の制御が開始された後に、空調装置の除湿運転が制御されるので、空調装置の除湿運転が制御されることにより、指標値を目標指標値に近づけることができ、人に対する快適な睡眠環境を実現することができる。

また、上記の情報処理方法において、前記温度制御情報を用いた前記設定温度の制御を開始した後に、前記除湿運転を制御してもよい。

この構成によれば、設定温度の制御が開始された後に、空間内の湿度が所定値以上になった場合、除湿運転により空間内の湿度が下げられ、空間内の湿度が人にとって快適な湿度に保たれるので、人に対する快適な睡眠環境を実現することができる。

また、上記の情報処理方法において、さらに、前記空間に存在する前記人による、送風、温度及び湿度の少なくとも１つに対する反応を示す反応情報を取得し、さらに、取得した前記反応情報に基づいて、前記送風の制御、前記設定温度の制御及び前記除湿運転の制御を行うか否か、前記送風の制御、前記設定温度の制御及び前記除湿運転の制御の内容又は実行順序を決定してもよい。

この構成によれば、空間に存在する人による、送風、温度及び湿度の少なくとも１つに対する反応を示す反応情報に基づいて、送風の制御、設定温度の制御及び除湿運転の制御を行うか否か、送風の制御、設定温度の制御及び除湿運転の制御の内容又は実行順序が決定されるので、送風、温度及び湿度に対する人の反応の個人差に応じたより快適な睡眠環境を提供することができる。

また、上記の情報処理方法において、さらに、取得した前記入眠判定情報から前記人が入眠したと判定した後、前記目標指標値を経時的に上昇させてもよい。

この構成によれば、最終的に人が起床する時点において最適な指標値となるように、指標値が、目標指標値の上昇に合わせて経時的に上昇するので、人に対する快適な睡眠環境を実現することができる。

また、上記の情報処理方法において、さらに、前記空間に存在する前記人の生体情報を取得し、さらに、取得した前記生体情報に基づいて前記目標指標値を上昇させるタイミングを決定してもよい。

この構成によれば、例えば、人の眠りが浅いタイミングで目標指標値を上昇させるのではなく、人の眠りが深いタイミングで目標指標値を上昇させることにより、睡眠中の人が中途覚醒するのを防止することができ、人に対する快適な睡眠環境を実現することができる。

また、上記の情報処理方法において、さらに、前記空間に存在する前記人による、過去の少なくとも前記送風制御情報を用いた送風の制御結果に対する評価を示す評価情報を取得し、さらに、取得した前記評価情報に基づいて前記目標指標値を決定してもよい。

この構成によれば、過去の少なくとも送風制御情報を用いた送風の制御結果に対する評価が、人の起床時における目標指標値に反映されるので、空間に存在する人の睡眠中の制御結果に対する評価に応じたより快適な睡眠環境を提供することができる。

また、上記の情報処理方法において、さらに、少なくとも前記送風制御情報を用いた送風の制御が行われている間に測定された、前記空間に存在する前記人の生体情報を取得し、さらに、取得した前記生体情報に基づいて前記目標指標値を決定してもよい。

この構成によれば、少なくとも送風制御情報を用いた送風の制御が行われている間に測定された、空間に存在する人の生体情報が、人の起床時における目標指標値に反映されるので、睡眠中の設定温度の制御に対する人の生体情報に応じたより快適な睡眠環境を提供することができる。

本開示の他の態様に係る情報処理装置は、睡眠中の人が存在する、空調装置が設置された空間に存在するセンサによって測定された少なくとも温度及び湿度を取得するセンサ情報取得部と、前記人の入眠を判定するための入眠判定情報を取得する入眠判定情報取得部と、取得された前記入眠判定情報から前記人が入眠したと判定された後、取得された前記少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報を決定する決定部と、決定された前記送風制御情報を用いて前記空調装置の送風を制御する制御部と、を備える。

この構成によれば、人が入眠したと判定された後、睡眠中の人が存在する、空調装置が設置された空間に存在するセンサによって測定された少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報が決定され、決定された送風制御情報を用いて空調装置の送風が制御されるので、空調装置からの風量を低減することにより、空調装置から発生する騒音を低減するとともに、風が直接人の肌に触れることを防止し、人に対する快適な睡眠環境を実現することができる。

以下添付図面を参照しながら、本開示の実施の形態について説明する。なお、以下の実施の形態は、本開示を具体化した一例であって、本開示の技術的範囲を限定するものではない。

（実施の形態）
まず、本実施の形態における空調制御システムが提供するサービスの全体像について説明する。

図１は、本実施の形態における空調制御システムが提供するサービスの全体像を示す図である。図２は、機器メーカがデータセンタ運営会社に該当する例を示す図である。図３は、機器メーカ及び管理会社の両者又はいずれか一方がデータセンタ運営会社に該当する例を示す図である。

空調制御システムは、グループ１００、データセンタ運営会社１１０及びサービスプロバイダ１２０を備える。

グループ１００は、例えば企業、団体又は家庭等であり、その規模を問わない。グループ１００は、第１の機器及び第２の機器を含む複数の機器１０１及びホームゲートウェイ１０２を備える。複数の機器１０１は、インターネットと接続可能な機器（例えば、スマートフォン、パーソナルコンピュータ（ＰＣ）又はテレビ等）、及びそれ自身ではインターネットと接続不可能な機器（例えば、照明、洗濯機又は冷蔵庫等）を含む。複数の機器１０１は、それ自身ではインターネットと接続不可能な機器であっても、ホームゲートウェイ１０２を介してインターネットと接続可能となる機器を含んでもよい。また、ユーザ１０は、グループ１００内の複数の機器１０１を使用する。

データセンタ運営会社１１０は、クラウドサーバ１１１を備える。クラウドサーバ１１１は、インターネットを介して様々な機器と連携する仮想化サーバである。クラウドサーバ１１１は、主に通常のデータベース管理ツール等で扱うことが困難な巨大なデータ（ビッグデータ）等を管理する。データセンタ運営会社１１０は、データの管理、クラウドサーバ１１１の管理、及びそれらを行うデータセンタの運営等を行っている。データセンタ運営会社１１０が行っている役務の詳細については後述する。

ここで、データセンタ運営会社１１０は、データの管理又はクラウドサーバ１１１の管理のみを行っている会社に限らない。例えば、図２に示すように、複数の機器１０１のうちの一つの機器を開発又は製造している機器メーカが、データの管理又はクラウドサーバ１１１の管理等を行っている場合は、機器メーカがデータセンタ運営会社１１０に該当する。また、データセンタ運営会社１１０は一つの会社に限らない。例えば、図３に示すように、機器メーカ及び管理会社が共同又は分担してデータの管理又はクラウドサーバ１１１の管理を行っている場合は、両者又はいずれか一方がデータセンタ運営会社１１０に該当する。

サービスプロバイダ１２０は、サーバ１２１を備える。ここで言うサーバ１２１とは、その規模は問わず、例えば、個人用ＰＣ内のメモリ等も含む。また、サービスプロバイダ１２０がサーバ１２１を備えていない場合もある。

なお、上記のサービスにおいて、ホームゲートウェイ１０２は必須ではない。例えば、クラウドサーバ１１１が全てのデータ管理を行っている場合等は、ホームゲートウェイ１０２は不要となる。また、家庭内の全ての機器がインターネットに接続されている場合のように、それ自身ではインターネットと接続不可能な機器は存在しない場合もある。

次に、上記サービスにおける機器のログ情報（操作履歴情報及び動作履歴情報）の流れを説明する。

まず、グループ１００の第１の機器又は第２の機器は、各ログ情報をデータセンタ運営会社１１０のクラウドサーバ１１１にそれぞれ送信する。クラウドサーバ１１１は、第１の機器又は第２の機器のログ情報を集積する（図１の矢印１３１）。ここで、ログ情報とは、複数の機器１０１の例えば運転状況又は動作日時等を示す情報である。例えば、ログ情報は、テレビの視聴履歴、レコーダの録画予約情報、洗濯機の運転日時、洗濯物の量、冷蔵庫の開閉日時、又は冷蔵庫の開閉回数などを含むが、これらの情報に限らず、種々の機器から取得が可能な種々の情報を含んでもよい。なお、ログ情報は、インターネットを介して複数の機器１０１自体から直接クラウドサーバ１１１に提供されてもよい。また、ログ情報は、複数の機器１０１から一旦ホームゲートウェイ１０２に集積され、ホームゲートウェイ１０２からクラウドサーバ１１１に提供されてもよい。

次に、データセンタ運営会社１１０のクラウドサーバ１１１は、集積したログ情報を一定の単位でサービスプロバイダ１２０に提供する。ここで、一定の単位とは、データセンタ運営会社１１０が集積した情報を整理してサービスプロバイダ１２０に提供することの出来る単位でもよいし、サービスプロバイダ１２０が要求する単位でもよい。また、一定の単位で提供するとしているが、一定の単位でなくてもよく、状況に応じて提供する情報量が変化してもよい。ログ情報は、必要に応じてサービスプロバイダ１２０が保有するサーバ１２１に保存される（図１の矢印１３２）。

そして、サービスプロバイダ１２０は、ログ情報をユーザに提供するサービスに適合する情報に整理し、ユーザに提供する。情報が提供されるユーザは、複数の機器１０１を使用するユーザ１０でもよいし、外部のユーザ２０でもよい。ユーザ１０，２０への情報提供方法としては、例えば、サービスプロバイダ１２０から直接ユーザ１０，２０へ情報が提供されてもよい（図１の矢印１３３，１３４）。また、ユーザ１０への情報提供方法としては、例えば、データセンタ運営会社１１０のクラウドサーバ１１１を再度経由して、ユーザ１０に情報が提供されてもよい（図１の矢印１３５，１３６）。また、データセンタ運営会社１１０のクラウドサーバ１１１は、ログ情報をユーザに提供するサービスに適合する情報に整理し、サービスプロバイダ１２０に提供してもよい。

なお、ユーザ１０は、ユーザ２０と異なっていても同一であってもよい。

図４は、本開示の実施の形態における空調制御システムの構成を示すブロック図である。

空調制御システムは、空調装置３１０、クラウドサーバ３２０、睡眠状態検知機３３０及び端末３４０を備える。クラウドサーバ３２０の構成の一部又は全ては、データセンタ運営会社のクラウドサーバ又はサービスプロバイダのサーバのどちらかに属す。

空調装置３１０は、ネットワークを介してクラウドサーバ３２０と互いに通信可能に接続される。また、睡眠状態検知機３３０は、ネットワークを介してクラウドサーバ３２０と互いに通信可能に接続される。端末３４０は、ネットワークを介してクラウドサーバ３２０と互いに通信可能に接続される。なお、ネットワークは、例えば、インターネットである。

空調装置３１０は、室内の空質環境を調整する機器であり、例えば、ルームエアコンである。空調装置３１０は、センサ３１１、センサ情報取得部３１２、空調制御部３１３、制御情報取得部３１４及び通信部３１５を備える。

空調制御部３１３は、室内の空気の温度又は湿度などを調整する制御機能を有し、具体的には、室内を冷却する冷房機能、室内を暖める暖房機能及び室内の湿度を下げる除湿機能などの空調機能を有している。なお、空調制御部３１３は、部屋の温度又は湿度を制御できる制御機能を有していればよく、空調機能に限らない。空調制御部３１３は、クラウドサーバ３２０の空調設定部３５５によって指定される制御パラメータに基づいて制御を行う。制御パラメータは、例えば、運転ステータス、運転モード、設定温度、風量及び風向を含む。運転ステータスは、空調装置３１０の電源をオンするか又はオフするかを示すパラメータである。運転モードは、冷房、暖房、除湿又は自動のうちのいずれのモードで空調装置３１０を運転するのかを示すパラメータである。設定温度は、空調装置３１０に指定される目標温度を示すパラメータである。風量は、空調装置３１０が排出する風の量を示すパラメータである。風向は、空調装置３１０が排出する風の向きを示すパラメータである。

センサ３１１は、空調装置３１０が搭載する種々のセンサを含む。センサ３１１は、例えば、室内の温度を測定する温度センサ、室内の湿度を測定する湿度センサ、室外の温度を測定する温度センサ、室外の湿度を測定する湿度センサ、室内に人がいるか否かを検知する人感センサ、及び空調装置３１０が消費する電力量を測定する電力センサを含む。人感センサは、例えば、赤外線により人を検知する。また、電力センサは、空調装置３１０の稼動時の電流から電力量を求める。なお、センサ３１１は、送風口からの吹き出し温度を測定するセンサ、及び圧縮機の回転数（冷暖房強度）を測定するセンサを含んでもよい。また、センサ３１１は、空調装置３１０が設置された空間内の少なくとも温度及び湿度を測定すればよい。

センサ情報取得部３１２は、空調装置３１０に搭載されるセンサ３１１を使用して種々のセンサ情報を取得する。センサ情報取得部３１２が取得するセンサ情報としては、例えば、センサ３１１から取得される、室内の温度、室内の湿度、室外の温度、室外の湿度、室内に人がいるか否かを示す在／不在情報、及び空調装置３１０が消費する電力量がある。なお、センサ情報取得部３１２は、送風口からの吹き出し温度及び圧縮機の回転数を取得してもよい。

制御情報取得部３１４は、空調制御情報を空調制御部３１３から取得する。空調制御情報は、空調制御部３１３の制御内容を示し、具体的には、運転ステータス、運転モード、設定温度、風向及び風量などのパラメータ情報を含む。

通信部３１５は、クラウドサーバ３２０へ種々の情報を送信するとともに、クラウドサーバ３２０から種々の情報を受信する。通信部３１５は、センサ情報取得部３１２によって取得されたセンサ情報をクラウドサーバ３２０へ送信する。また、通信部３１５は、制御情報取得部３１４によって取得された空調制御情報をクラウドサーバ３２０へ送信する。また、通信部３１５は、クラウドサーバ３２０によって送信された制御パラメータを受信する。通信部３１５は、受信した制御パラメータを空調制御部３１３へ出力する。

睡眠状態検知機３３０は、電波センサ３３１、睡眠状態情報取得部３３２及び通信部３３３を備える。睡眠状態検知機３３０は、例えば、人が就寝するベッドの上方又は下方に配置される。

電波センサ３３１は、睡眠状態検知機３３０に搭載され、人の生体情報を非接触で測定する。電波センサ３３１は、マイクロ波を人に照射し、反射波のドップラーシフトから、電波センサ３３１と人との間の微小な距離変化を計測することで、人の生体情報を測定する。生体情報は、例えば、体の動きの量（以降、体動量）、呼吸数及び心拍数などを含む。

睡眠状態情報取得部３３２は、電波センサ３３１から生体情報を取得するとともに、取得した生体情報から人の睡眠状態を推定する。睡眠状態情報取得部３３２は、取得した生体情報及び推定した睡眠状態情報を通信部３３３へ出力する。

図５は、人の睡眠状態を説明するための図である。図５において、縦軸は睡眠状態を示し、横軸は睡眠経過時間を示す。

図５に示すように、人の睡眠は、眠りの深さ又は眠りの特徴によって、時系列で変化する複数の睡眠状態に分類できる。図５に示すように、睡眠は、レム睡眠とノンレム睡眠とに分類される。レム睡眠は、高速眼球運動を伴う睡眠であり、睡眠状態の一つである。レム睡眠では、体は休息状態であるが、脳は活動している状態である。人が夢を見るのはレム睡眠中であることが多いとされている。ノンレム睡眠は、高速眼球運動を伴わない睡眠であり、眠りの深さによってステージ１からステージ４の４つの段階にさらに分けられる。ステージ４が最も深い睡眠レベルである。睡眠状態がノンレム睡眠である時、周波数が１Ｈｚから４Ｈｚであるデルタ波と呼ばれる低周波かつ高振幅の脳波が高頻度で計測される。通常、入眠から４５～６０分以内にノンレム睡眠のステージ３又はステージ４まで到達し、その後、１～２時間ほどで徐々に眠りが浅くなってレム睡眠になる。以後は、ノンレム睡眠とレム睡眠とが、９０～１１０分の睡眠周期で交互に繰り返される。

体動量、呼吸数及び心拍数の生体情報は、図５で示す睡眠状態に相関がある。例えば、ノンレム睡眠のステージ３又はステージ４といった深い睡眠状態においては、体動量が少なく、心拍変動（ＲＲＩ）が低くなることが知られている。睡眠状態情報取得部３３２は、このような相関関係を用いて、生体情報から人の睡眠状態をリアルタイムに推定する。睡眠状態は、睡眠状態情報としてクラウドサーバ３２０に送信される。睡眠状態情報取得部３３２は、生体情報に基づいて、人が、覚醒、レム睡眠、ステージ１のノンレム睡眠、ステージ２のノンレム睡眠、ステージ３のノンレム睡眠、及びステージ４のノンレム睡眠のいずれの睡眠状態であるかを推定する。

通信部３３３は、睡眠状態情報取得部３３２によって取得された生体情報及び睡眠状態情報取得部３３２によって推定された睡眠状態情報をクラウドサーバ３２０へ送信する。

なお、本実施の形態では、睡眠状態情報取得部３３２が睡眠状態を推定しているが、本開示は特にこれに限定されず、睡眠状態の推定は、睡眠状態検知機３３０ではなく、クラウドサーバ３２０で行ってもよい。その場合は、クラウドサーバ３２０が睡眠状態推定部を備えてもよい。睡眠状態推定部は、睡眠状態検知機３３０から送信される体動量、呼吸数及び心拍数などの生体情報又は履歴ＤＢ３６１に記憶されている過去のデータを用いて、睡眠状態を推定してもよい。

また、本実施の形態では、睡眠状態検知機３３０は非接触型の電波センサを備えているが、睡眠状態を推定可能な生体情報を取得できるセンサであれば、電波センサに限定されない。睡眠状態検知機３３０は、例えば、接触型のセンサを備えてもよい。睡眠状態検知機３３０は、例えば、腕に装着するウェアラブル端末であってもよく、ウェアラブル端末に設けられた接触型のセンサが、体動量及び心拍数等の生体情報を測定してもよい。また、就寝時に人が横たわるマットの下に設けた感圧式のセンサが生体情報を測定してもよい。

また、本実施の形態において、空調装置３１０が電波センサ３３１及び睡眠状態情報取得部３３２を備えてもよい。

クラウドサーバ３２０は、通信部３２１、プロセッサ３２２及びメモリ３２３を備える。プロセッサ３２２は、センサ情報格納部３５１、制御情報格納部３５２、睡眠状態情報格納部３５３、制御パラメータ決定部３５４、空調設定部３５５及びインターフェース３５６を備える。メモリ３２３は、履歴データベース（ＤＢ）３６１及び設定データベース（ＤＢ）３６２を備える。

通信部３２１は、空調装置３１０によって送信されたセンサ情報及び空調制御情報と、睡眠状態検知機３３０によって送信された睡眠状態情報及び生体情報と、端末３４０によって送信された設定情報とを受信する。

通信部３２１は、睡眠中の人が存在する、空調装置３１０が設置された空間に存在するセンサ３１１によって測定された少なくとも温度及び湿度を取得する。

センサ情報格納部３５１は、空調装置３１０のセンサ情報取得部３１２を通じて取得した室内温度、室内湿度、在／不在情報及び電力量を含むセンサ情報を履歴ＤＢ３６１に格納する。なお、センサ情報は、室内温度及び室内湿度を少なくとも含む。通信部３２１は、インターネット等のネットワークを介して、定期的に（例えば、１分毎に）、空調装置３１０に対してセンサ情報を要求する。通信部３２１は、クラウドサーバ３２０からの要求に応じて空調装置３１０によって送信されたセンサ情報を受信する。センサ情報格納部３５１は、通信部３２１によって受信されたセンサ情報を履歴ＤＢ３６１に格納する。なお、空調装置３１０の通信部３１５は、センサ情報取得部３１２によって取得されたセンサ情報を、定期的に（例えば、１分毎に）、クラウドサーバ３２０へアップロードしてもよい。

制御情報格納部３５２は、空調装置３１０の制御情報取得部３１４を通じて取得した空調制御情報を履歴ＤＢ３６１に格納する。通信部３２１は、インターネット等のネットワークを介して、定期的に（例えば、１分毎に）、空調装置３１０に対して空調制御情報を要求する。通信部３２１は、クラウドサーバ３２０からの要求に応じて空調装置３１０によって送信された空調制御情報を受信する。制御情報格納部３５２は、通信部３２１によって受信された空調制御情報を履歴ＤＢ３６１に格納する。なお、空調装置３１０の通信部３１５は、制御情報取得部３１４によって取得された空調制御情報を、定期的に（例えば、１分毎に）、クラウドサーバ３２０へアップロードしてもよい。また、空調装置３１０の通信部３１５は、制御内容が変更されたイベントをトリガーとして、空調制御情報をクラウドサーバ３２０へアップロードしてもよい。

通信部３２１は、人の入眠を判定するための睡眠状態情報を取得する。なお、睡眠状態情報は、入眠判定情報の一例である。

睡眠状態情報格納部３５３は、睡眠状態検知機３３０の睡眠状態情報取得部３３２を通じて取得した睡眠状態情報を履歴ＤＢ３６１に格納する。通信部３２１は、インターネット等のネットワークを介して、定期的に（例えば、５分毎に）、空調装置３１０に対して睡眠状態情報を要求する。睡眠状態情報格納部３５３は、通信部３２１によって受信された睡眠状態情報を履歴ＤＢ３６１に格納する。なお、睡眠状態検知機３３０の通信部３３３は、睡眠状態情報取得部３３２によって取得された睡眠状態情報を、定期的に（例えば、５分毎に）、クラウドサーバ３２０へアップロードしてもよい。

また、睡眠状態検知機３３０の通信部３３３は、睡眠状態情報だけでなく生体情報もクラウドサーバ３２０へ送信してもよい。この場合、クラウドサーバ３２０の通信部３２１は、空調装置３１０によって送信された睡眠状態情報及び生体情報を受信する。睡眠状態情報格納部３５３は、睡眠状態情報とともに生体情報を履歴ＤＢ３６１に格納する。

履歴ＤＢ３６１は、センサ情報格納部３５１から受け取ったセンサ情報、制御情報格納部３５２から受け取った空調制御情報及び睡眠状態情報格納部３５３から受け取った睡眠状態情報を記憶するデータベースである。データベースの形式としては、ＳＱＬ等のリレーショナルデータベースが一般的であるが、Ｋｅｙ－Ｖａｌｕｅ型データベースなどの簡素な関係性でデータを構成するＮｏＳＱＬ系データベースであってもよい。

図６は、センサ情報取得部によって取得されたセンサ情報と制御情報取得部によって取得された空調制御情報とを格納する履歴ＤＢのテーブル構造の一例を示す図である。図７は、睡眠状態情報取得部によって取得された睡眠状態情報及び生体情報を格納する履歴ＤＢのテーブル構造の一例を示す図である。

図６のテーブルにおいて、ＩＤは、各レコードを識別するためのユニークな識別情報であり、時刻は、各情報を取得した時刻である。室内温度、室内湿度、室外気温、吹き出し温度、在／不在情報及び電力量は、センサ情報取得部３１２から取得したセンサ情報である。運転ステータス、運転モード、設定温度、風量及び風向は、制御情報取得部３１４から取得した空調制御情報である。なお、説明を容易にするため、センサ情報と空調制御情報を１つのテーブルにまとめて管理しているが、それぞれを別のテーブルで管理してもよい。また、図６の電力量は、前レコードから現レコードまでの積算電力量（ｗｈ）を示している。

図７のテーブルにおいて、ＩＤは、各レコードを識別するためのユニークな識別情報であり、時刻は、各情報を取得した時刻である。睡眠状態、心拍数、呼吸数及び体動量は、睡眠状態情報取得部３３２から取得した情報である。睡眠状態は、図５で説明した人の睡眠状態であり、各時刻における睡眠状態を示している。「ＷＡＫＥ」は、覚醒している状態を示し、「ＲＥＭ」は、レム睡眠の状態を示し、「ＳＴＡＧＥ１」は、ステージ１のノンレム睡眠の状態を示し、「ＳＴＡＧＥ２」は、ステージ２のノンレム睡眠の状態を示し、「ＳＴＡＧＥ３」は、ステージ３のノンレム睡眠の状態を示し、「ＳＴＡＧＥ４」は、ステージ４のノンレム睡眠の状態を示す。

心拍数は、各時刻における心拍数を示し、図７の例では１分間あたりの心拍数を示す。呼吸数は、各時刻における呼吸数を示し、図７の例では１分間あたりの呼吸数を示す。また、体動量は、各時刻における体の動き量を示し、例えば、１分間あたりの最大の体動量、又は１分間に体動と判定する閾値を超えた回数を０～１００の値に正規化した値で示される。

端末３４０は、例えば、スマートフォン、タブレット型コンピュータ又はパーソナルコンピュータである。端末３４０は、不図示の入力部及び表示部を備える。端末３４０は、睡眠前に睡眠開始予定時刻及び起床予定時刻のユーザによる入力を受け付けるとともに、起床時に睡眠中の温熱環境に対する主観評価のユーザによる入力を受け付ける。また、端末３４０は、ユーザにより入力された睡眠開始予定時刻、起床予定時刻及び温熱環境主観評価結果（すなわち評価情報）をクラウドサーバ３２０へ送信する。

インターフェース３５６は、ユーザによる入力を受け付ける外部インターフェースであり、例えば、ｈｔｔｐ／ｈｔｔｐｓプロトコルで通信するＷｅｂＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。インターフェース３５６は、端末３４０から受け取った設定情報を設定ＤＢ３６２又は履歴ＤＢ３６１に格納する。設定情報は、例えば、睡眠開始予定時刻及び起床予定時刻である。また、インターフェース３５６は、履歴ＤＢ３６１に格納された睡眠状態情報、空調制御情報又はセンサ情報を、通信部３２１を通じて端末３４０に送信してもよい。

図８は、睡眠前に睡眠開始予定時刻及び起床予定時刻の設定を受け付ける際に端末に表示される表示画面の一例を示す図である。図８に示すように、端末３４０は、１週間の各曜日における睡眠開始予定時刻と起床予定時刻との入力を受け付ける設定画面３４１を表示する。設定画面３４１は、睡眠開始予定時刻及び起床予定時刻の入力を受け付けるための項目１８０１，１８０２を含む。図８の例では、項目１８０１は、月曜日、火曜日、水曜日、木曜日及び金曜日において、睡眠開始予定時刻が２３：００に設定され、起床予定時刻が７：００に設定されていることを示している。項目１８０２は、土曜日及び日曜日において、睡眠開始予定時刻が２３：３０に設定され、起床予定時刻が８：００に設定されていることを示している。端末３４０に表示される各項目１８０１，１８０２がタップされると、睡眠開始予定時刻及び起床予定時刻を設定するための詳細画面に遷移し、設定完了とともに、クラウドサーバ３２０に設定情報が送信される。

図９は、起床時に睡眠中の温熱環境に対する主観評価のユーザによる入力を受け付ける際に端末に表示される表示画面の一例を示す図である。図９に示すように、現在時刻が起床予定時刻になると、端末３４０は、睡眠中の温熱環境に対する主観評価の入力をユーザに促すための起床画面３４２を表示する。図９に示す起床画面３４２には、「今日の空調はいかがでしたか？アイコンを押してね！」とコメントしているキャラクター画像と、「寒い」、「少し寒い」、「快適」、「少し暑い」及び「暑い」の５段階の評価項目を示す５つのアイコンとが表示される。起床画面３４２において、睡眠中の温熱環境に対する主観評価が入力される。

５つのアイコンのうちの１つがユーザによりタップされると、端末３４０は、評価結果画面３４３を表示する。そして、ユーザによって選択された「寒い」、「少し寒い」、「快適」、「少し暑い」及び「暑い」の５つの評価項目のうちのいずれかが評価結果としてクラウドサーバ３２０に送信される。本実施の形態において、ユーザによる温熱環境に対する主観評価は、「温熱環境主観評価」と定義される。温熱環境主観評価は、「寒い」、「少し寒い」、「快適」、「少し暑い」及び「暑い」の５段階の温度感の評価だけでなく、温度感、湿度感及び快適感に細分化してもよい。また、温熱環境主観評価は、睡眠の前半、中盤及び後半ごとに細分化してもよい。温熱環境主観評価結果は、クラウドサーバ３２０の通信部３２１で受信され、インターフェース３５６によって履歴ＤＢ３６１に保存される。

図１０は、インターフェースによって取得された温熱環境主観評価を格納する履歴ＤＢのテーブル構造の一例を示す図である。具体的には、履歴ＤＢ３６１は、図１０に示すようなテーブルで温熱環境主観評価を管理する。履歴ＤＢ３６１は、実際の睡眠開始時刻及び実際の起床時刻とともに、温熱環境主観評価を記憶する。

図１０のテーブルにおいて、ＩＤは、各レコードを識別するためのユニークな識別情報であり、実睡眠開始時刻は、ユーザが実際に睡眠を開始した時刻である。睡眠状態検知機３３０から取得された睡眠状態が覚醒状態からノンレム睡眠状態に移行した時刻が実睡眠開始時刻として記憶される。実起床時刻は、ユーザが実際に起床した時刻である。睡眠状態検知機３３０から取得された睡眠状態がノンレム睡眠状態から覚醒状態に移行した時刻が実起床時刻として記憶される。温熱環境主観評価は、睡眠中の温熱環境のユーザによる評価結果を示し、例えば、「１（寒い）」、「２（少し寒い）」、「３（快適）」、「４（少し暑い）」及び「５（暑い）」の５段階の評価項目のうちのいずれかで表される。

なお、図８及び図９の例では、端末３４０のアプリケーションにより表示されるイメージを説明しているが、アプリケーションの形態は問わない。端末３４０は、ＶＰＡ（Ｖｉｒｔｕａｌ Ｐｅｒｓｏｎａｌ Ａｓｓｉｓｔａｎｔ）のような対話型アプリケーションによって、設定情報及び温熱環境主観評価の入力を受け付けてもよい。

設定ＤＢ３６２は、インターフェース３５６によって取得された設定情報を格納するデータベースである。データベースの形式としては、ＳＱＬ等のリレーショナルデータベースが一般的であるが、Ｋｅｙ－Ｖａｌｕｅ型データベースなどの簡素な関係性でデータを構成するＮｏＳＱＬ系データベースであってもよい。

図１１は、本開示の実施の形態における設定ＤＢのテーブル構造の一例を示す図である。設定ＤＢ３６２のテーブルは、ＩＤ、睡眠開始予定時刻、起床予定時刻、曜日及び起床時温熱指標のカラムから構成される。ＩＤは、各レコードを識別するためのユニークな識別情報であり、睡眠開始予定時刻は、ユーザによって入力された睡眠開始予定時刻であり、起床予定時刻は、ユーザによって入力された起床予定時刻であり、曜日は、各レコードの睡眠開始予定時刻及び起床予定時刻の対象となる曜日を示している。図８に示す端末３４０で実行されるアプリケーションによって、これらの値が設定される。また、起床時温熱指標は、起床時において目標とする温熱指標であり、図１１の例では不快指数の値を示している。起床時温熱指標は、制御パラメータ決定部３５４の処理で利用される。制御パラメータ決定部３５４の処理の詳細については後述する。

制御パラメータ決定部３５４は、履歴ＤＢ３６１及び設定ＤＢ３６２を用いて、空調装置３１０を制御するための制御パラメータを算出する。制御パラメータ決定部３５４は、取得された睡眠状態情報（入眠判定情報）から人が入眠したと判定した後、取得された少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報を決定する。例えば、制御パラメータ決定部３５４は、人が入眠したと判定された後、所定時間（例えば１時間）経過後に、空調装置３１０から送風される空気の風量を減少させる。

制御パラメータ決定部３５４は、送風制御情報を用いた送風の制御を開始した後に、指標値を目標指標値に近づけるための温度に関する温度制御情報を決定する。制御パラメータ決定部３５４は、人の起床時における最終目標指標値（起床時温熱指標）を用いて、指標値を目標指標値に近づけるための温度に関する温度制御情報を決定する。具体的には、制御パラメータ決定部３５４は、最終目標指標値を用いて個々の時点の目標指標値又は経時的な目標指標値の変更量を決定する。そして、制御パラメータ決定部３５４は、個々の時点の目標指標値又は経時的な目標指標値の変更量に基づいて送風制御情報を決定する。例えば、制御パラメータ決定部３５４は、目標指標値を時間に比例して変更する場合、取得された睡眠状態情報（入眠判定情報）から人が入眠したと判定した後、最終目標指標値から現時点の目標指標値を決定することで、目標指標値を経時的に上昇させる。なお、目標指標値の変更は時間に比例しなくてもよく、他の態様であってもよい。例えば、ユーザの特性又は好みなどに応じて目標指標値が変更されてもよい。

空調設定部３５５は、制御パラメータ決定部３５４によって決定された制御パラメータを、通信部３２１を介して空調装置３１０に通知する。通信部３２１は、空調設定部３５５から出力された制御パラメータを空調装置３１０へ送信する。空調設定部３５５は、制御パラメータ決定部３５４によって決定された送風制御情報を用いて空調装置３１０の送風を制御する。

空調設定部３５５は、制御パラメータ決定部３５４によって決定された温度制御情報を用いて空調装置３１０の設定温度を制御する。空調設定部３５５は、送風制御情報を用いた送風の制御を開始した後に、空調装置３１０の除湿運転を制御する。空調設定部３５５は、温度制御情報を用いた設定温度の制御を開始した後に、除湿運転を制御する。

図１２は、本開示の実施の形態における空調装置の制御の流れを時系列に説明するためのグラフである。

図１２において、横軸は、睡眠時の時間経過を示し、縦軸は、温度、不快指数、湿度及び風量の大きさを示している。破線１１０２は、不快指数の時系列推移を示す。実線１１０３は、湿度の時系列推移を示す。実線１１０４は、制御パラメータ決定部３５４によって決定される空調装置３１０の設定温度の時系列推移を示す。実線１１０５は、空調装置３１０の室内機から実際に排出される風量の時系列推移を示す。運転モード１１０７は、空調装置３１０の運転モードの時系列変化を示す。なお、図１２では、睡眠中の前半は冷房運転で推移し、途中で除湿運転に切り替えられている。以降、図１２に示すグラフを用いて空調装置３１０の制御について説明する。

図１２において、ユーザの入室時刻から就寝開始時刻までの空調は、ユーザ自身の好みに応じて設定される。具体的には、空調装置３１０を遠隔操作するリモートコントローラなどを用いて、ユーザは、運転モード、風量、風向及び設定温度を任意に設定する。制御パラメータ決定部３５４は、現在時刻が設定ＤＢ３６２の睡眠開始予定時刻を過ぎている場合に、ユーザが就寝を開始したと判断し、制御パラメータを算出する。ここで、制御パラメータ決定部３５４は、ユーザが入眠したことを検知した入眠検知時刻から１時間が過ぎるまでは、就寝開始時の制御パラメータを継続し、空調装置３１０の制御パラメータを変更しない。入眠は、睡眠状態検知機３３０から送信される睡眠状態情報によって検知される。

制御パラメータ決定部３５４は、就寝開始時刻（睡眠開始予定時刻）以降で、深い睡眠（ステージ３のノンレム睡眠又はステージ４のノンレム睡眠）を示す睡眠状態を検知した場合、ユーザが入眠したと判定する。ユーザが入眠してから１時間の時間帯は、最初の睡眠周期である。最初の睡眠周期は、良質な睡眠にとって、最も重要な睡眠周期である。そのため、入眠検知時刻から１時間が経過するまでの時間帯は、環境変化を与えずに就寝開始時の睡眠環境を継続させる。

なお、本実施の形態では、入眠検知時刻から１時間が経過するまでは就寝開始時の制御パラメータが維持されるが、本開示は特にこれに限定されず、制御パラメータ決定部３５４は、入眠検知時刻から所定の時間が経過するまでは就寝開始時の制御パラメータを維持すればよく、所定の時間は、ユーザの睡眠履歴などに基づいて調整してもよい。

入眠検知時刻から１時間が経過した後、制御パラメータ決定部３５４は、温熱指標を用いて、室内を徐々に暖めるように、空調装置３１０の制御パラメータを変更する。図１２の例では、温熱指標として不快指数が用いられている。不快指数は、温度及び湿度から算出される温熱指標であり、下記の式（１）を用いて算出される。

不快指数（ＤＩ）＝０．８１×Ｔ＋０．０１×Ｈ×（０．９９×Ｔ－１４．３）＋４６．３・・・（１）
なお、上記の式（１）において、Ｔは、乾球温度（℃）を表し、Ｈは、湿度（％）を表す。制御パラメータ決定部３５４は、設定ＤＢ３６２により設定された起床時不快指数（起床時温熱指標）に到達するように空調制御の制御パラメータを決定する。

クラウドサーバ３２０のインターフェース３５６は、空間に存在する人による、過去の少なくとも送風制御情報を用いた送風の制御結果に対する評価（温熱環境主観評価）を示す評価情報を取得する。そして、インターフェース３５６は、取得した評価情報に基づいて目標指標値（起床時温熱指標）を決定する。インターフェース３５６は、設定ＤＢ３６２に記憶されている最終目標指標値（起床時温熱指標）を、決定した最終目標指標値（起床時温熱指標）に更新する。

起床時温熱指標は、過去の履歴の温熱環境主観評価に基づいて、快適となる値を設定する。例えば、起床時不快指数が７７．５に設定され、不快指数が起床時不快指数に到達するように空調装置３１０が制御された後、ユーザが起床時に暑いと評価した場合、次回の制御では、起床時不快指数は７７．０に下げられる。一方、ユーザが起床時に寒いと評価した場合、次回の制御では、起床時不快指数は７８．０に上げられる。図１２に示すように、制御パラメータ決定部３５４は、入眠検知時刻から１時間が経過した後、起床予定時刻の起床時不快指数と入眠検知時刻から１時間が経過した時刻の不快指数とを結ぶ線分１１０１に沿って不快指数が遷移するように、空調装置３１０の設定温度を変更する。

なお、最初にユーザが睡眠する場合において、制御パラメータ決定部３５４は、就寝開始時刻から、入眠検知時刻から１時間経過した時刻までの間の温熱指標の値に、所定の値を加算した値を、起床時温熱指標の初期値として設定してもよい。例えば、就寝開始時刻の不快指数が７５であれば、制御パラメータ決定部３５４は、就寝開始時刻の不快指数に所定の値である「２」を加算した７７を、起床時温熱指標の初期値として設定する。なお、加算する所定の値は、例えば「２」であるが、過去の別のユーザの快適とする起床時温熱指標から算出してもよい。このように構成することで、初回利用時であっても、好ましい起床時温熱指標を決定できる。

また、最初にユーザが睡眠する場合において、起床時温熱指標の初期値は、「暑がり」、「寒がり」又は「普通」といったユーザの空調に対する主観評価に基づいて決定されてもよい。例えば、端末３４０は、ユーザが睡眠する前に、ユーザの主観評価の入力を受け付けてもよい。インターフェース３５６は、ユーザの主観評価が暑がりであれば、起床時不快指数を７６に決定し、ユーザの主観評価が普通であれば、起床時不快指数を７７に決定し、ユーザの主観評価が寒がりであれば、起床時不快指数を７８に決定してもよい。このように構成することで、初回利用時であっても、好ましい起床時温熱指標を決定できる。なお、インターフェース３５６は、ユーザの空調に対する主観評価を設定ＤＢ３６２に予め設定する。

なお、本実施の形態において、インターフェース３５６は、空調装置３１０の少なくとも送風制御情報を用いた送風の制御が行われている間に測定された、空間に存在する人の生体情報を取得し、取得した生体情報に基づいて目標指標値（起床時温熱指標）を決定してもよい。生体情報は、例えば、睡眠中の人の体動量である。起床時において、インターフェース３５６は、履歴ＤＢ３６１から睡眠中のユーザの体動量を取得する。インターフェース３５６は、睡眠中のユーザの体動量が、中途覚醒を示す所定値以上であるか否かを判断する。インターフェース３５６は、睡眠中のユーザの体動量が所定値以上であると判断した場合、設定ＤＢ３６２に記憶されている起床時温熱指標を現在の値から下げる。一方、インターフェース３５６は、睡眠中のユーザの体動量が所定値より小さいと判断した場合、設定ＤＢ３６２に記憶されている起床時温熱指標を現在の値で維持する。

ここで、家庭用の空調装置３１０の夏場の運転モードとしては、「冷房」及び「除湿」がある。空気が含むことができる水分（水蒸気）の量は温度によって変わる。高温の空気ほど多量の水分を含み、低温の空気ほど含められる水分量が少ない。空調装置３１０は、この空気の性質を利用しており、冷房によって室温を低下させて結露した水分を室外に排出させて、屋内の湿度を低下させることで除湿を実現している。冷房によって結露した水分が室内機にある状態で風が送られると、水分を含む空気を室内に戻してしまう「湿度戻り」と呼ばれる現象が発生する。そのため、湿度戻りを回避するために、空調装置３１０の除湿運転においては、圧縮機の動作が止まると一定期間、風を止めることが一般的である。つまり、空調装置３１０の冷房運転では、風が一定の風量で送り続けられ、除湿運転では、風が間欠して送られる。空調装置３１０の制御によっては、冷房運転時においても、間欠して送風されることもあるが、本実施の形態における冷房運転では、一定の風量で風を送る。

風は、人の触覚及び聴覚に影響を及ぼすため、睡眠中においては、風が間欠して送られることは好ましくなく、可能な限り冷房運転を行い、一定の風量で風を送ることが好ましい。しかしながら、現在の温熱指標が適切な範囲内であったとしても、湿度が高すぎる場合は、ユーザが不快に感じることがあり得るため、運転モードを除湿運転に切り替えることが好ましい。そこで、制御パラメータ決定部３５４は、図１２に示す湿度限界超過時点のように、現在の湿度が、予め設定した湿度の許容範囲を超えた場合には、運転モードを冷房運転から除湿運転へ切り替える。

なお、温熱指標として不快指数を用いているのは一例であり、別の温熱指標を用いてもよいことは言うまでもない。温熱指標としては、例えば、温度、湿度、気流速度、放射温度、代謝量及び着衣量から算出される、人体の熱収支量、ＰＭＶ（予想平均温冷感申告）又はＳＥＴ（標準新有効温度）であってもよい。このような気流速度を考慮するパラメータの場合には、徐々に温熱指標を高める際に、気流速度を優先して低減させることが好ましい。具体的には、制御パラメータ決定部３５４は、風量を最小化させるとともに、風向を人がいない方向に変更させた後、設定温度を上昇させる。このように、早い段階で気流速度の影響を最小化することで、気流が人の触覚又は聴覚に影響を及ぼすことによる睡眠中の覚醒を防止することができる。

また、制御パラメータ決定部３５４の処理の詳細については、図１５及び図１６に示すフローチャートを用いて説明する。

以上が本実施の形態における空調制御システムの構成についての説明である。

次に、本実施の形態における空調制御システムの処理について説明する。本実施の形態における空調制御システムの処理は、空調装置３１０及びクラウドサーバ３２０におけるデータ蓄積処理と、睡眠状態検知機３３０及びクラウドサーバ３２０におけるデータ蓄積処理と、クラウドサーバにおける空調設定処理との３つの処理に分けられる。

図１３は、本開示の実施の形態の空調装置及びクラウドサーバにおけるデータ蓄積処理を説明するためのフローチャートである。

まず、ステップＳ１において、空調装置３１０のセンサ情報取得部３１２は、室内の温度、室内の湿度、室内に人がいるか否かを示す在／不在情報、及び空調装置３１０が消費する電力量を含むセンサ情報をセンサ３１１から取得する。

次に、ステップＳ２において、空調装置３１０の制御情報取得部３１４は、運転ステータス、運転モード、設定温度、風向及び風量を含む空調制御情報を空調制御部３１３から取得する。

次に、ステップＳ３において、空調装置３１０の通信部３１５は、ステップＳ１で取得したセンサ情報及びステップＳ２で取得した空調制御情報をクラウドサーバ３２０へ送信する。

次に、ステップＳ４において、クラウドサーバ３２０の通信部３２１は、空調装置３１０によって送信されたセンサ情報及び空調制御情報を受信する。

次に、ステップＳ５において、センサ情報格納部３５１は、センサ情報を履歴ＤＢ３６１に格納する。

次に、ステップＳ６において、制御情報格納部３５２は、空調制御情報を履歴ＤＢ３６１に格納する。

次に、ステップＳ７において、空調装置３１０の通信部３１５は、一定期間（例えば、１分間）の待機処理を行う。一定期間が経過すると、ステップＳ１に処理が戻る。

上記データ蓄積処理は、空調装置３１０とクラウドサーバ３２０との通信経路が確立されており、電源がオンの状態である場合に、常に実行される。このようにして、室内環境及び空調制御情報がすべて履歴ＤＢ３６１に記憶される。また、図１３では、センサ情報の取得と空調制御情報の取得とは、シーケンシャルに実行されているが、並列に実行されてもよい。また、制御情報取得部３１４は、空調制御情報を定期的に取得するのではなく、制御内容が変更されたタイミングで取得し、クラウドサーバ３２０へアップロードしてもよい。

以上が空調装置３１０のデータ蓄積処理の説明である。

図１４は、本開示の実施の形態の睡眠状態検知機及びクラウドサーバにおけるデータ蓄積処理を説明するためのフローチャートである。

まず、ステップＳ１１において、睡眠状態検知機３３０の睡眠状態情報取得部３３２は、人の心拍数、呼吸数及び体動量を含む生体情報を取得する。

次に、ステップＳ１２において、睡眠状態情報取得部３３２は、生体情報から人の睡眠状態を推定する。睡眠状態は、覚醒、レム睡眠及びステージ１～４のノンレム睡眠のいずれかである。

次に、ステップＳ１３において、睡眠状態検知機３３０の通信部３３３は、ステップＳ１１で取得した生体情報及びステップＳ１２で推定した睡眠状態情報をクラウドサーバ３２０へ送信する。

次に、ステップＳ１４において、クラウドサーバ３２０の通信部３２１は、睡眠状態検知機３３０によって送信された生体情報及び睡眠状態情報を受信する。

次に、ステップＳ１５において、睡眠状態情報格納部３５３は、生体情報及び睡眠状態情報を履歴ＤＢ３６１に記憶する。

次に、ステップＳ１６において、睡眠状態検知機３３０の通信部３３３は、一定期間（例えば、１分間）の待機処理を行う。一定期間が経過すると、ステップＳ１１に処理が戻る。

上記データ蓄積処理は、睡眠状態検知機３３０とクラウドサーバ３２０との通信経路が確立されており、人の生体情報が取得された場合に、常に実行される。このようにして、生体情報及び睡眠状態情報がすべて履歴ＤＢ３６１に記憶される。

なお、睡眠状態検知機３３０は、睡眠状態情報のみをクラウドサーバ３２０へ送信してもよく、睡眠状態情報格納部３５３は、睡眠状態情報のみを履歴ＤＢ３６１に記憶してもよい。

以上が、睡眠状態検知機３３０のデータ蓄積処理の説明である。

図１５は、本開示の実施の形態のクラウドサーバにおける空調設定処理を説明するためのフローチャートである。

まず、ステップＳ２１において、制御パラメータ決定部３５４は、現在時刻を、設定ＤＢ３６２に記憶されている起床予定時刻と比較し、現在時刻が起床予定時刻を過ぎているか否かを判定する。ここで、現在時刻が起床予定時刻を過ぎていると判定された場合（ステップＳ２１でＹＥＳ）、ステップＳ２７に処理が移行する。

一方、現在時刻が起床予定時刻を過ぎていないと判定された場合（ステップＳ２１でＮＯ）、ステップＳ２２において、制御パラメータ決定部３５４は、現在時刻を、入眠検知時刻に所定時間を加算した時刻と比較し、現在時刻が、入眠検知時刻に所定時間を加算した時刻を過ぎているか否かを判定する。なお、本実施の形態において所定時間は、例えば１時間であるが、本開示は特にこれに限定されない。制御パラメータ決定部３５４は、睡眠状態検知機３３０から送信される睡眠状態情報によって入眠を検知する。制御パラメータ決定部３５４は、設定ＤＢ３６２に記憶されている睡眠開始予定時刻以降で、深い睡眠（ステージ３のノンレム睡眠又はステージ４のノンレム睡眠）を示す睡眠状態のレコードを検知した場合、検知した当該レコードの時刻を入眠検知時刻と判定する。

ここで、現在時刻が、入眠検知時刻に所定時間を加算した時刻を過ぎていると判定された場合（ステップＳ２２でＹＥＳ）、ステップＳ２３において、制御パラメータ決定部３５４は、制御パラメータを決定する温熱指標上昇処理を行う。なお、温熱指標上昇処理については、図１６を用いて説明する。

次に、ステップＳ２４において、空調設定部３５５は、制御パラメータ決定部３５４によって決定された制御パラメータを、通信部３２１を介して空調装置３１０へ送信する。

一方、現在時刻が、入眠検知時刻に所定時間を加算した時刻を過ぎていないと判定された場合（ステップＳ２２でＮＯ）、ステップＳ２５において、制御パラメータ決定部３５４は、空調装置３１０の現在の制御パラメータの設定を維持する。この場合、制御パラメータ決定部３５４は、空調装置３１０の制御パラメータを設定しなくてもよい。あるいは、制御パラメータ決定部３５４は、履歴ＤＢ３６１を参照して、空調装置３１０の現在の制御パラメータを取得してもよい。空調設定部３５５は、制御パラメータ決定部３５４によって取得された現在の制御パラメータを空調装置３１０に送信してもよい。

次に、ステップＳ２６において、制御パラメータ決定部３５４は、一定期間（例えば、１分間）の待機処理を行う。一定期間が経過すると、ステップＳ２１に処理が戻る。

また、ステップＳ２１において、現在時刻が起床予定時刻を過ぎていると判定された場合（ステップＳ２１でＹＥＳ）、ステップＳ２７において、通信部３２１は、端末３４０によって送信された温熱環境主観評価結果を受信する。

次に、ステップＳ２８において、インターフェース３５６は、通信部３２１によって受信された温熱環境主観評価結果に応じて、設定ＤＢ３６２に記憶されている起床時温熱指標を更新する。例えば、温熱環境主観評価結果が、「寒い」又は「少し寒い」であれば、インターフェース３５６は、起床時温熱指標を現在の値よりも高くなるように更新する。また、温熱環境主観評価結果が、「快適」であれば、インターフェース３５６は、起床時温熱指標を現在の値のまま維持する。さらに、温熱環境主観評価結果が、「暑い」又は「少し暑い」であれば、インターフェース３５６は、起床時温熱指標を現在の値よりも低くなるように更新する。

以上が、クラウドサーバ３２０の空調設定処理の説明である。

図１６は、本開示の実施の形態のクラウドサーバにおける温熱指標上昇処理を説明するためのフローチャートである。

まず、ステップＳ４１において、制御パラメータ決定部３５４は、空調装置３１０の現在の風量が、就寝開始時の風量と一致するか否かを判定する。

ここで、空調装置３１０の現在の風量が、就寝開始時の風量と一致すると判定された場合（ステップＳ４１でＹＥＳ）、ステップＳ４２において、制御パラメータ決定部３５４は、空調装置３１０の風量を最小値に決定する。このとき、制御パラメータ決定部３５４は、人の睡眠を阻害しないために、風向を人がいない方向に変更し、人に気流があたらないようにしてもよい。

次に、ステップＳ４３において、制御パラメータ決定部３５４は、風量変化経過時刻を決定する。風量変化経過時刻とは、風量を変化させてから、温度を変化させるまでの時間を基に決定される時刻である。風量の変化は、温熱指標に影響を与える。そのため、風量変化経過時刻は、風量の変化が落ち着くまでの時間を考慮して、風量変化の温度及び湿度への変換量の履歴などを基にして決定される。例えば、制御パラメータ決定部３５４は、レベル５の風量からレベル１の風量に変化する場合には、風量を変化させた時刻から３０分後の時刻を風量変化経過時刻に決定し、レベル３の風量からレベル１の風量に変化させる場合には、風量を変化させた時刻から１５分後の時刻を風量変化経過時刻に決定し、レベル１の風量からレベル１の風量に変化させる場合には、風量を変化させた時刻から０分後の時刻を風量変化経過時刻に決定する。このように、風量の変化量が小さくなるにつれて、風量を変化させた時刻から風量変化経過時刻までの時間は短くなる。

次に、ステップＳ４４において、制御パラメータ決定部３５４は、現在時刻を風量変化経過時刻と比較し、現在時刻が風量変化経過時刻を過ぎているか否かを判定する。現在時刻が風量変化経過時刻を過ぎていないと判定された場合（ステップＳ４４でＮＯ）、温熱指標上昇処理は終了する。

一方、現在時刻が風量変化経過時刻を過ぎていると判定された場合（ステップＳ４４でＹＥＳ）、ステップＳ４５において、制御パラメータ決定部３５４は、設定ＤＢ３６２から起床時温熱指標である起床時不快指数ＤＩ＿Ｌａｓｔを取得して、起床時不快指数ＤＩ＿Ｌａｓｔに到達するための現在の目標不快指数ＤＩ＿Ｔａｒｇｅｔを算出する。図１２に示すように、制御パラメータ決定部３５４は、起床時不快指数と、入眠検知時刻から１時間が経過した時刻の不快指数とを結ぶ線分１１０１に沿うように、現在の目標不快指数ＤＩ＿Ｔａｒｇｅｔを算出する。

制御パラメータ決定部３５４は、現在時刻ｔ＿Ｎｏｗにおける、現在の目標不快指数ＤＩ＿Ｔａｒｇｅｔを下記の式（２）を用いて算出する。

ＤＩ＿Ｔａｒｇｅｔ＝ＤＩ＿Ｓｔａｒｔ＋（ＤＩ＿Ｌａｓｔ－ＤＩ＿Ｓｔａｒｔ）×｛（ｔ＿Ｎｏｗ－ｔ＿Ｓｔａｒｔ）／（ｔ＿Ｌａｓｔ－ｔ＿Ｓｔａｒｔ）｝・・・（２）
なお、上記の式（２）において、ＤＩ＿Ｓｔａｒｔは、入眠検知時刻から１時間が経過した時点の不快指数を表し、ｔ＿Ｓｔａｒｔは、入眠検知時刻から１時間が経過した時点の時刻を表し、ｔ＿Ｌａｓｔは、起床予定時刻を表す。制御パラメータ決定部３５４は、入眠検知時刻から１時間が経過した時点の時刻ｔ＿Ｓｔａｒｔにおける温度及び湿度を履歴ＤＢ３６１から取得し、入眠検知時刻から１時間が経過した時点の不快指数ＤＩ＿Ｓｔａｒｔを算出する。

次に、ステップＳ４６において、制御パラメータ決定部３５４は、現在の目標不快指数ＤＩ＿Ｔａｒｇｅｔに到達するための現在の目標温度Ｔ＿Ｔａｒｇｅｔを算出する。

現在の目標不快指数ＤＩ＿Ｔａｒｇｅｔは、現在の目標温度Ｔ＿Ｔａｒｇｅｔと現在の湿度Ｈ＿Ｎｏｗとを用いて、下記の式（３）で表される。

ＤＩ＿Ｔａｒｇｅｔ＝０．８１×Ｔ＿Ｔａｒｇｅｔ＋０．０１×Ｈ＿Ｎｏｗ×（０．９９×Ｔ＿Ｔａｒｇｅｔ－１４．３）＋４６．３・・・（３）
現在の目標温度Ｔ＿Ｔａｒｇｅｔは、上記の式（３）を変形させることにより、下記の式（４）で表される。

Ｔ＿Ｔａｒｇｅｔ＝｛（ＤＩ＿Ｔａｒｇｅｔ＋１４．３×０．０１×Ｈ＿Ｎｏｗ－４６．３）／（０．８１＋０．９９×０．０１×Ｈ＿Ｎｏｗ）｝・・・（４）
制御パラメータ決定部３５４は、上記の式（４）を用いて、現在の目標温度Ｔ＿Ｔａｒｇｅｔを算出する。

次に、ステップＳ４７において、制御パラメータ決定部３５４は、空調装置３１０の設定温度を現在の目標温度Ｔ＿Ｔａｒｇｅｔに決定する。この際、設定温度が０．５度刻みである場合は、制御パラメータ決定部３５４は、現在の目標温度Ｔ＿Ｔａｒｇｅｔを０．５度切り上げる。例えば、現在の目標温度Ｔ＿Ｔａｒｇｅｔが２５．３℃であった場合、設定温度は２５．５℃になる。

次に、ステップＳ４８において、制御パラメータ決定部３５４は、現在の湿度Ｈ＿Ｎｏｗが閾値以上であるか否かを判定する。なお、本実施の形態における閾値は、例えば、８０％である。

ここで、現在の湿度Ｈ＿Ｎｏｗが閾値より低いと判定された場合（ステップＳ４８でＮＯ）、ステップＳ４９において、制御パラメータ決定部３５４は、空調装置３１０の運転モードを冷房運転に決定する。

一方、現在の湿度Ｈ＿Ｎｏｗが閾値以上であると判定された場合（ステップＳ４８でＹＥＳ）、ステップＳ５０において、制御パラメータ決定部３５４は、空調装置３１０の運転モードを除湿運転に決定する。

なお、ステップＳ４８の処理については、一度運転モードが除湿運転に変更された場合には、現在の湿度Ｈ＿Ｎｏｗが、閾値から所定値を引いた値に到達するまで、運転モードを冷房運転に戻さないようにしてもよい。所定値は、例えば、５％である。これにより、空調装置３１０の運転モードの頻繁な変更を避けることができる。

以上が、クラウドサーバ３２０の温熱指標上昇処理の説明である。

本実施の形態のように空調制御システムを構成することによって、就寝から起床にかけて、ユーザにとって快適となるように温熱環境を制御できる。

なお、本実施の形態では、図１２に示す湿度限界超過時点のように、現在の湿度が、予め設定した閾値を超えた場合には、運転モードを除湿運転へ切り替えているが、閾値は、ユーザの睡眠時の快適性に基づいて設定されてもよい。例えば、過去の睡眠において、湿度が６０％、７０％、８０％及び９０％である場合のそれぞれの睡眠時の中途覚醒発生率を比較し、中途覚醒発生率が湿度の上昇に応じて高くなる場合には、湿度に高い反応を示すユーザであるため、閾値を低く設定してもよく、反対に中途覚醒発生率が変化しない場合には、閾値を高く設定してもよい。このように構成することで、ユーザの湿度に対する反応の個人差を反映させて、人に対してより快適な睡眠環境を提供することができる。

また、本実施の形態では、空調装置３１０の設定温度を変更することにより、起床に向けて温熱指標を上昇させているが、空調装置３１０の能力又は方式に合わせて設定温度とは異なるパラメータを変更させてもよい。例えば、空調装置３１０が、湿度をコントロールする機能を有している場合には、設定温度ではなく、設定湿度を上げることで、温熱指標の上昇を実現できる。その場合、ステップＳ４６において、制御パラメータ決定部３５４は、現在の目標不快指数ＤＩ＿Ｔａｒｇｅｔに到達するために、現在の目標温度Ｔ＿Ｔａｒｇｅｔではなく、現在の目標湿度Ｈ＿Ｔａｒｇｅｔを算出し、設定湿度を現在の目標湿度Ｈ＿Ｔａｒｇｅｔに決定してもよい。このように構成することで、空調装置３１０の能力に応じた制御が可能になる。

また、上述のように、温度及び湿度の両方の設定変更により、温熱指標の上昇が実現可能である場合には、温度及び湿度のそれぞれの閾値を定義して、温度及び湿度がそれぞれ閾値以下となるように設定されてもよい。温度の閾値が、例えば２８℃である場合、制御パラメータ決定部３５４は、設定温度を上昇させ、現在の温度が２８℃に到達したら、それ以降は設定湿度を上昇させる。このように構成することで、温熱指標には現れない要素の値を考慮した制御が可能となる。

また、上述のように、温度及び湿度の両方の設定変更により、温熱指標の上昇が実現可能である場合には、温度及び湿度のどちらを優先して設定変更するかを過去のユーザの履歴に基づいて設定してもよい。例えば、睡眠時の温度変化及び湿度変化に対して、どちらの変化の方が睡眠に影響を及ぼすかを判定して、温度変化が睡眠に及ぼす影響が、湿度変化が睡眠に及ぼす影響よりも低い場合は設定温度を優先して変更し、温度変化が睡眠に及ぼす影響が、湿度変化が睡眠に及ぼす影響よりも高い場合は設定湿度を優先して変更してもよい。このように構成することで、ユーザの温度及び湿度に対する反応の個人差を反映させて、人に対してより快適な睡眠環境を提供することができる。

制御パラメータ決定部３５４は、空間に存在する人による、送風、温度及び湿度の少なくとも１つに対する反応を示す反応情報を取得してもよい。制御パラメータ決定部３５４は、取得した反応情報に基づいて、送風の制御、設定温度の制御及び除湿運転の制御を行うか否か、送風の制御、設定温度の制御及び除湿運転の制御の内容又は実行順序を決定してもよい。反応情報は、例えば、空間に存在する人による、過去の制御結果に対する評価を示す評価情報又は生体情報に含まれる体動量である。設定温度の制御結果に対して、不快を示す評価が得られた場合、又は、設定温度の制御結果に対して、体動量が所定値以上であった場合、制御パラメータ決定部３５４は、次回の運転モードを除湿運転に決定してもよい。

また、本実施の形態では、温熱指標の上昇を開始するタイミングは、入眠検知時刻から１時間が経過した時刻であるが、本開示は特にこれに限定されず、睡眠周期に応じて決定されてもよい。

図１７は、本開示の実施の形態において、温熱指標の上昇を開始するタイミングを睡眠周期に応じて決定する例について説明するための図である。

図１７に示すように、制御パラメータ決定部３５４は、睡眠周期のうち２回目の深い睡眠（ステージ３のノンレム睡眠又はステージ４のノンレム睡眠）に遷移したタイミングｔ１又は３回目の深い睡眠に遷移したタイミングｔ２で、温熱指標の上昇を開始してもよい。一般に、深い睡眠ステージでは、温熱環境変化に対する中途覚醒発生率は低い。そのため、深い睡眠ステージに遷移したタイミングは、温熱環境の変化を開始するタイミングとして好ましい。この場合、図１５のステップＳ２２において、制御パラメータ決定部３５４は、睡眠状態検知機３３０によって送信された睡眠状態情報を用いて、ユーザの睡眠状態が、レム睡眠からステージ３のノンレム睡眠又はステージ４のノンレム睡眠に遷移したか否かを判定する。このように構成することで、温熱指標の上昇を、ユーザの睡眠にとって最適なタイミングで行うことができる。

また、本実施の形態では、温熱指標の上昇を開始するタイミングは、入眠検知時刻から１時間が経過した時刻であるが、睡眠状態検知機３３０がユーザの発汗量を計測できる場合には、制御パラメータ決定部３５４は、発汗量が一度上昇した後、低下した時点で温熱指標の上昇を開始させてもよい。一般に、人は入眠したタイミングで、深部体温を下降させ、熱を外部に放出させるため、発汗量が多くなる。また、睡眠の深度と発汗量とには相関があることが知られており、ステージ３のノンレム睡眠又はステージ４のノンレム睡眠時には発汗量が増える。発汗量が増加する間は、睡眠開始時の快適な設定を維持することが望ましい。そこで、制御パラメータ決定部３５４は、発汗量が落ちつき低下するタイミングを検出して、検出したタイミングにおいて温熱指標の上昇を開始させる。

睡眠状態検知機３３０は、睡眠中のユーザの発汗量を検出し、検出した発汗量に関する情報をクラウドサーバ３２０へ送信する。クラウドサーバ３２０の通信部３２１は、睡眠状態検知機３３０によって送信された発汗量に関する情報を受信する。図１５のステップＳ２２において、制御パラメータ決定部３５４は、発汗量が低下したか否かを判定する。発汗量が低下したと判定された場合、ステップＳ２３に処理が移行し、発汗量が低下していないと判定された場合、ステップＳ２５に処理が移行する。このように構成することで、発汗量が増加している間は、睡眠開始時の快適な温度推移を維持することが可能であり、人に対して快適な睡眠環境を提供できる。

また、本実施の形態では、温熱指標の上昇を開始するタイミングは、入眠検知時刻から１時間が経過した時刻であるが、睡眠状態検知機３３０がユーザの皮膚温を計測できる場合には、制御パラメータ決定部３５４は、皮膚温が一度上昇した後、低下した時点で温熱指標の上昇を開始させてもよい。一般に、人は入眠したタイミングで、深部体温を下降させ、熱を外部に放出させるため、皮膚温が高くなる。皮膚温が上昇する間は、睡眠開始時の快適な設定を維持することが望ましい。そこで、制御パラメータ決定部３５４は、皮膚温が落ちつき低下するタイミングを検出して、検出したタイミングにおいて温熱指標の上昇を開始させる。

睡眠状態検知機３３０は、睡眠中のユーザの皮膚温を検出し、検出した皮膚温に関する情報をクラウドサーバ３２０へ送信する。クラウドサーバ３２０の通信部３２１は、睡眠状態検知機３３０によって送信された皮膚温に関する情報を受信する。図１５のステップＳ２２において、制御パラメータ決定部３５４は、皮膚温が低下したか否かを判定する。皮膚温が低下したと判定された場合、ステップＳ２３に処理が移行し、皮膚温が低下していないと判定された場合、ステップＳ２５に処理が移行する。このように構成することで、皮膚温が高い間、すなわち深部体温を下降させる間は、睡眠開始時の快適な温度推移を維持することが可能であり、人に対して快適な睡眠環境を提供できる。なお、皮膚温を用いて、深部体温を推定することができれば、深部体温の推定値を用いて、温熱指標の上昇を開始させるタイミングを決定してもよい。

上記のように、制御パラメータ決定部３５４は、空間に存在する人の生体情報を取得する。生体情報は、例えば、発汗量又は皮膚温である。制御パラメータ決定部３５４は、取得した生体情報に基づいて目標指標値を上昇させるタイミングを決定する。

また、本実施の形態では、温熱指標の上昇を開始するタイミングは、入眠検知時刻から１時間が経過した時刻であるが、制御パラメータ決定部３５４は、深部体温の上昇が始まる午前４時～午前５時の間の時間帯に温熱指標の上昇を開始させてもよい。一般に、人の深部体温は、入眠したタイミングから下降し、午前４時～午前５時の間の時間帯から上昇する。

制御パラメータ決定部３５４は、深部体温が上昇するタイミングで、温熱指標の上昇を開始させる。図１５のステップＳ２２において、制御パラメータ決定部３５４は、現在時刻が午前４時～午前５時の間の時間帯であるか否かを判定する。現在時刻が午前４時～午前５時の間の時間帯であると判定された場合、ステップＳ２３に処理が移行し、現在時刻が午前４時～午前５時の間の時間帯ではないと判定された場合、ステップＳ２５に処理が移行する。このように構成することで、深部体温が上昇する時間帯に合わせて、温熱指標の上昇を開始させることが可能であり、人に対して快適な睡眠環境を提供できる。

また、本実施の形態では、温熱指標の上昇を開始するタイミングは、入眠検知時刻から１時間が経過した時刻であるが、制御パラメータ決定部３５４は、過去の睡眠時の体動量、中途覚醒回数及び温熱環境主観評価の学習結果から、温熱指標の上昇を開始する最適なタイミングを決定してもよい。

例えば、温熱指標の上昇を開始させる時刻で、体動量及び中途覚醒回数が増え、かつ、起床時の温熱環境主観評価が「少し暑い」又は「暑い」であった場合には、温熱指標の上昇を開始させる時刻が早すぎると考えられる。そのため、制御パラメータ決定部３５４は、温熱指標の上昇を開始させる時刻で体動量及び中途覚醒回数が増え、かつ、起床時の温熱環境主観評価が暑さを感じた評価であった頻度が所定値以上である場合、温熱指標の上昇を開始する時刻を遅らせる。また、温熱指標の上昇を開始させる時刻で、体動量及び中途覚醒回数が増え、かつ、起床時の温熱環境主観評価が「少し寒い」又は「寒い」であった場合には、温熱指標の上昇を開始させる時刻が遅すぎると考えられる。そのため、制御パラメータ決定部３５４は、温熱指標の上昇を開始させる時刻で体動量及び中途覚醒回数が増え、かつ、起床時の温熱環境主観評価が寒さを感じた評価であった頻度が所定値以上である場合は、温熱指標の上昇を開始する時刻を早める。制御パラメータ決定部３５４は、調整された時刻を用いて、図１５のステップＳ２２の判定を行う。このように構成することによって、ユーザの個人の快適性に合わせた睡眠時の温熱環境を提供できる。

また、本実施の形態では、図１２に示すように、入眠検知時刻に１時間を加算した時刻の温熱指標（不快指数）と、起床時温熱指標（起床時不快指数）とを結ぶ線分１１０１に沿うように、温熱指標が上昇される。これは、睡眠時に覚醒を促さないように、できるだけ温熱環境の変化を最小化するためである。しかし、一般の空調装置３１０においては、設定温度は１度毎又は０．５度毎に変更されるため、設定温度の変更により温熱環境が急激に変化するおそれがある。そこで、起床予定時刻に向けて温熱指標を上昇させるための空調装置３１０の制御パラメータの変更は、深い睡眠（ステージ３のノンレム睡眠又はステージ４のノンレム睡眠）を示す期間に行うことが好ましい。

図１８は、本開示の実施の形態において、空調装置の制御パラメータを変更するタイミングの他の例を説明するための図である。図１８のグラフ１７０１は、睡眠中のユーザの睡眠深度（眠りの深さ）を示しており、上から下に向かって眠りが深くなっている。つまり、下方がステージ３のノンレム睡眠又はステージ４のノンレム睡眠を示す。図１８において、第１～第５ディープ睡眠期間は、ユーザの睡眠状態がステージ３のノンレム睡眠又はステージ４のノンレム睡眠のいずれかである期間を示している。実線１７０２は、制御パラメータ決定部３５４が決定する設定温度の時系列推移を示す。破線１７０３は、不快指数の時系列推移を示す。

一般に、睡眠状態が深い睡眠ステージである場合には、温熱環境変化に対する中途覚醒発生率は低くなり、温熱環境変化が睡眠に与える影響は低いと考えられる。そのため、深い睡眠を示す期間は、温熱環境を変化させるタイミングとして好ましい。制御パラメータ決定部３５４は、睡眠状態検知機３３０から取得した睡眠状態情報を用いて、ユーザの現在の睡眠状態がステージ３のノンレム睡眠又はステージ４のノンレム睡眠であるか否かを判定する。そして、制御パラメータ決定部３５４は、ユーザの現在の睡眠状態がステージ３のノンレム睡眠又はステージ４のノンレム睡眠であると判定された場合のみ制御パラメータを決定する。このように構成することで、睡眠中のユーザが不快にならないタイミングで適切に温熱指標を上昇させることができる。

なお、個人の睡眠状態又はセンサの検知エラーなどにより、ステージ３のノンレム睡眠又はステージ４のノンレム睡眠が現れないこともある。その場合は、タイムアウト時間を設けて、ステージ２のノンレム睡眠、レム睡眠及びステージ１のノンレム睡眠の優先度順で、制御パラメータが変更されてもよい。

また、本実施の形態において、制御パラメータ決定部３５４は、起床予定時刻までに起床時温熱指標に到達するように温熱指標を上昇させるが、本開示は特にこれに限定されず、起床予定時刻よりも前の温熱指標上昇終了時刻までに起床時温熱指標に到達するように温熱指標を上昇させてもよい。

図１９は、本開示の実施の形態において、起床予定時刻よりも前の温熱指標上昇終了時刻までに起床時温熱指標に到達するように温熱指標を上昇させる例を説明するための図である。図１９において、破線１１０２は、不快指数の時系列推移を示す。

制御パラメータ決定部３５４は、入眠検知時刻から１時間が経過した後、起床予定時刻よりも前の温熱指標上昇終了時刻の起床時不快指数と、入眠検知時刻から１時間が経過した時刻の不快指数とを結ぶ線分１９０１に沿って不快指数が遷移するように、空調装置３１０の設定温度を変更する。なお、図１９の温熱指標上昇開始時刻は、入眠検知時刻から１時間が経過した時刻である。このように構成することにより、温熱環境主観評価に基づいて温熱指標上昇終了時刻を調整することで、よりユーザの好みを反映した温熱環境を提供することができる。例えば、睡眠終盤に中途覚醒が多く、かつ温熱環境主観評価が「暑い」又は「少し暑い」であった場合には、制御パラメータ決定部３５４は、温熱指標上昇終了時刻を遅らせるなどの調整を行うことが可能である。

また、本実施の形態では、温熱指標として不快指数を用いているが、別の温熱指標を用いてもよい。例えば、温熱指標としては、温度、湿度、気流速度、放射温度、代謝量及び着衣量から算出する人体の熱収支量又はＰＭＶといったパラメータがある。熱収支量又はＰＭＶを利用する場合には、気流速度、放射温度、代謝量及び着衣量の計測が必要となり、空調装置３１０のセンサ３１１は、それらを計測してもよい。また、センサ３１１による計測に対する代替として、気流速度は、空調装置３１０の風量及び風向から算出されてもよく、放射温度は、空気温度及び外気温から推定されてもよく、代謝量は、睡眠中の代表値であってもよく、着衣量は、端末３４０からユーザにより入力されてもよい。

図２０は、本開示の実施の形態において、温熱指標としてＰＭＶを用いる場合のクラウドサーバにおける温熱指標上昇処理を説明するためのフローチャートである。

まず、ステップＳ６１において、制御パラメータ決定部３５４は、設定ＤＢ３６２から起床時温熱指標である起床時ＰＭＶ値ＰＭＶ＿Ｌａｓｔを取得して、起床時ＰＭＶ値ＰＭＶ＿Ｌａｓｔに到達するための現在の目標ＰＭＶ値ＰＭＶ＿Ｔａｒｇｅｔを算出する。制御パラメータ決定部３５４は、起床時ＰＭＶ値と、入眠検知時刻から１時間が経過した時刻のＰＭＶ値とを結ぶ線分に沿うように、現在の目標ＰＭＶ値ＰＭＶ＿Ｔａｒｇｅｔを算出する。

なお、ＰＭＶは、１９６７年にデンマーク工科大学のファンガーによって提唱された温熱指標であり、人体熱負荷と代謝量とを加味した計算式となっており、温度、湿度、風速、放射熱、代謝量及び着衣量から算出される。放射熱は、センサを用いて正確に計測してもよいし、温度からの推定値を用いてもよい。また、代謝量は、センサを用いて計測してもよいし、過去の睡眠時の知見から所定の値を設定してもよい。着衣量は、センサを用いて計測してもよいし、睡眠時の服装のユーザによる入力を受け付け、入力された服装に対応する値を設定してもよい。気流速度は、センサを用いて計測してもよいし、空調装置３１０の風量設定からの推定値を用いてもよい。ＰＭＶは、上記の６つの要素から計算される温熱指標であり、詳細な計算式については省略する。

制御パラメータ決定部３５４は、現在時刻ｔ＿Ｎｏｗにおける、現在の目標ＰＭＶ値ＰＭＶ＿Ｔａｒｇｅｔを下記の式（５）を用いて算出する。

ＰＭＶ＿Ｔａｒｇｅｔ＝ＰＭＶ＿Ｓｔａｒｔ＋（ＰＭＶ＿Ｌａｓｔ－ＰＭＶ＿Ｓｔａｒｔ）×｛（ｔ＿Ｎｏｗ－ｔ＿Ｓｔａｒｔ）／（ｔ＿Ｌａｓｔ－ｔ＿Ｓｔａｒｔ）｝・・・（５）
なお、上記の式（５）において、ＰＭＶ＿Ｓｔａｒｔは、入眠検知時刻から１時間が経過した時点のＰＭＶ値を表し、ｔ＿Ｓｔａｒｔは、入眠検知時刻から１時間が経過した時点の時刻を表し、ｔ＿Ｌａｓｔは、起床予定時刻を表す。制御パラメータ決定部３５４は、入眠検知時刻から１時間が経過した時点の時刻ｔ＿Ｓｔａｒｔにおける温度、湿度、風速、放射熱、代謝量及び着衣量を履歴ＤＢ３６１から取得し、入眠検知時刻から１時間が経過した時点のＰＭＶ値ＰＭＶ＿Ｓｔａｒｔを算出する。

次に、ステップＳ６２において、制御パラメータ決定部３５４は、空調装置３１０の現在の風量が最小値であるか否かを判定する。ここで、空調装置３１０の現在の風量が最小値であると判定された場合（ステップＳ６２でＹＥＳ）、ステップＳ６５に処理が移行する。

一方、空調装置３１０の現在の風量が最小値ではないと判定された場合（ステップＳ６２でＮＯ）、ステップＳ６３において、制御パラメータ決定部３５４は、現在の目標ＰＭＶ値ＰＭＶ＿Ｔａｒｇｅｔに到達するための現在の目標気流速度Ｗ＿Ｔａｒｇｅｔを算出する。気流速度以外のパラメータは、現在値が用いられる。

次に、ステップＳ６４において、制御パラメータ決定部３５４は、空調装置３１０の設定風量を、現在の目標気流速度Ｗ＿Ｔａｒｇｅｔに対応する風量に決定する。現在の目標気流速度に対応する風量は、過去の履歴データを用いて算出してもよい。また、制御パラメータ決定部３５４は、予め計測された気流速度と空調装置３１０の風量との関係を示すデータを用いて、現在の目標気流速度に対応する風量を算出してもよい。

次に、ステップＳ６５において、制御パラメータ決定部３５４は、現在の目標ＰＭＶ値ＰＭＶ＿Ｔａｒｇｅｔに到達するための現在の目標温度Ｔ＿Ｔａｒｇｅｔを算出する。温度以外のパラメータは、現在値が用いられる。

次に、ステップＳ６６において、制御パラメータ決定部３５４は、空調装置３１０の設定温度を現在の目標温度Ｔ＿Ｔａｒｇｅｔに決定する。この際、設定温度が０．５度刻みである場合は、制御パラメータ決定部３５４は、現在の目標温度Ｔ＿Ｔａｒｇｅｔを０．５度切り上げる。例えば、現在の目標温度Ｔ＿Ｔａｒｇｅｔが２５．３℃であった場合、設定温度は２５．５℃になる。

次に、ステップＳ６７において、制御パラメータ決定部３５４は、現在の湿度Ｈ＿Ｎｏｗが閾値以上であるか否かを判定する。なお、本実施の形態における閾値は、例えば、８０％である。

ここで、現在の湿度Ｈ＿Ｎｏｗが閾値より低いと判定された場合（ステップＳ６７でＮＯ）、ステップＳ６８において、制御パラメータ決定部３５４は、空調装置３１０の運転モードを冷房運転に決定する。

一方、現在の湿度Ｈ＿Ｎｏｗが閾値以上であると判定された場合（ステップＳ６７でＹＥＳ）、ステップＳ６９において、制御パラメータ決定部３５４は、空調装置３１０の運転モードを除湿運転に決定する。

なお、ステップＳ６７の処理については、一度運転モードが除湿運転に変更された場合には、現在の湿度Ｈ＿Ｎｏｗが、閾値から所定値を引いた値に到達するまで、運転モードを冷房運転に戻さないようにしてもよい。所定値は、例えば、５％である。これにより、空調装置３１０の運転モードの頻繁な変更を避けることができる。

以上が、温熱指標としてＰＭＶを用いる場合のクラウドサーバ３２０の温熱指標上昇処理の説明である。このように構成することにより、風量の設定を温熱指標に基づいて設定できるため、風量をきめ細やかに設定することが可能である。

また、本実施の形態において、空調装置３１０が、クラウドサーバ３２０のセンサ情報格納部３５１、制御情報格納部３５２、睡眠状態情報格納部３５３、制御パラメータ決定部３５４、空調設定部３５５、インターフェース３５６、履歴データベース３６１及び設定データベース３６２を備えてもよい。この場合、空調制御システムは、クラウドサーバ３２０を備えなくてもよい。

また、上記の実施の形態では、最終目標指標値を用いて目標指標値が変更される例を説明したが、本開示はこれに限定されない。例えば、目標指標値は予め決定された変更パターンを用いて変更されてもよい。

また、上記の実施の形態では、スマートフォンなどの手動入力を受け付ける端末３４０がユーザによる入力を受け付けることにより、評価情報を取得する例を説明した。しかし、評価情報は、他の形態の入力装置を介して入力されてもよい。具体的には、評価情報は、音声入力を受け付ける装置を介して取得されてもよい。例えば、スマートスピーカーなどのマイクロフォン及びスピーカーを備える装置がユーザからの入力を受け付けてよい。さらに、音声対話形式のインタラクションを用いてユーザから評価情報が取得されてもよい。

以上が本実施の形態における空調制御システムの説明である。

上記態様において説明された技術は、例えば、以下のクラウドサービスの類型において実現されうる。しかし、上記態様において説明された技術が実現されるクラウドサービスの類型はこれに限られるものでない。

（サービスの類型１：自社データセンタ型クラウドサービス）
図２１は、サービスの類型１（自社データセンタ型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。本類型では、サービスプロバイダ１２０がグループ１００から情報を取得し、ユーザに対してサービスを提供する。本類型では、サービスプロバイダ１２０が、データセンタ運営会社の機能を有している。すなわち、サービスプロバイダ１２０が、ビッグデータを管理するクラウドサーバ１１１を保有している。したがって、データセンタ運営会社は存在しない。

本類型では、サービスプロバイダ１２０は、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、オペレーティングシステム（ＯＳ）２０２及びアプリケーション２０１を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ２０２及びアプリケーション２０１を用いてユーザにサービスを提供する（矢印２０４）。

（サービスの類型２：ＩａａＳ利用型クラウドサービス）
図２２は、サービスの類型２（ＩａａＳ利用型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。ここで、ＩａａＳとは、インフラストラクチャー・アズ・ア・サービスの略であり、コンピュータシステムを構築及び稼動させるための基盤そのものを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０が、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、ＯＳ２０２及びアプリケーション２０１を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ２０２及びアプリケーション２０１を用いてユーザにサービスを提供する（矢印２０４）。

（サービスの類型３：ＰａａＳ利用型クラウドサービス）
図２３は、サービスの類型３（ＰａａＳ利用型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。ここで、ＰａａＳとは、プラットフォーム・アズ・ア・サービスの略であり、ソフトウェアを構築及び稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０は、ＯＳ２０２を管理し、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、アプリケーション２０１を管理する。サービスプロバイダ１２０は、データセンタ運営会社１１０が管理するＯＳ２０２及びサービスプロバイダ１２０が管理するアプリケーション２０１を用いてユーザにサービスを提供する（矢印２０４）。

（サービスの類型４：ＳａａＳ利用型クラウドサービス）
図２４は、サービスの類型４（ＳａａＳ利用型クラウドサービス）における空調制御システムが提供するサービスの全体像を示す図である。ここで、ＳａａＳとは、ソフトウェア・アズ・ア・サービスの略である。ＳａａＳ利用型クラウドサービスは、例えば、データセンタ（クラウドサーバ）を保有しているプラットフォーム提供者が提供するアプリケーションを、データセンタ（クラウドサーバ）を保有していない会社又は個人などの利用者がインターネットなどのネットワーク経由で使用できる機能を有するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０は、アプリケーション２０１を管理し、ＯＳ２０２を管理し、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、データセンタ運営会社１１０が管理するＯＳ２０２及びアプリケーション２０１を用いてユーザにサービスを提供する（矢印２０４）。

以上、いずれのクラウドサービスの類型においても、サービスプロバイダ１２０がサービスを提供する。また、例えば、サービスプロバイダ又はデータセンタ運営会社は、ＯＳ、アプリケーション又はビックデータのデータベース等を自ら開発してもよいし、また、第三者に外注させてもよい。

なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

本開示の実施の形態に係る装置の機能の一部又は全ては典型的には集積回路であるＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）として実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。また、集積回路化はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

また、本開示の実施の形態に係る装置の機能の一部又は全てを、ＣＰＵ等のプロセッサがプログラムを実行することにより実現してもよい。

また、上記で用いた数字は、全て本開示を具体的に説明するために例示するものであり、本開示は例示された数字に制限されない。

また、上記フローチャートに示す各ステップが実行される順序は、本開示を具体的に説明するために例示するためのものであり、同様の効果が得られる範囲で上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時（並列）に実行されてもよい。

本開示に係る情報処理方法及び情報処理装置は、人に対する快適な睡眠環境を実現することができるので、睡眠中の人が存在する空間に設置された空調装置を制御する情報処理方法及び情報処理装置として有用である。

１０，２０ ユーザ
１００ グループ
１０１ 複数の機器
１０２ ホームゲートウェイ
１１０ データセンタ運営会社
１１１ クラウドサーバ
１２０ サービスプロバイダ
１２１ サーバ
２０１ アプリケーション
２０２ ＯＳ
２０３ データセンタ（クラウドサーバ）
３１０ 空調装置
３１１ センサ
３１２ センサ情報取得部
３１３ 空調制御部
３１４ 制御情報取得部
３１５ 通信部
３２０ クラウドサーバ
３２１ 通信部
３２２ プロセッサ
３２３ メモリ
３３０ 睡眠状態検知機
３３１ 電波センサ
３３２ 睡眠状態情報取得部
３３３ 通信部
３４０ 端末
３５１ センサ情報格納部
３５２ 制御情報格納部
３５３ 睡眠状態情報格納部
３５４ 制御パラメータ決定部
３５５ 空調設定部
３５６ インターフェース
３６１ 履歴データベース
３６２ 設定データベース

Claims (9)

1. コンピュータが、
   睡眠中の人が存在する、空調装置が設置された空間に存在するセンサによって測定された少なくとも温度及び湿度を取得し、
   前記人の入眠を判定するための入眠判定情報を取得し、
   取得した前記入眠判定情報から前記人が入眠したと判定した後、取得した前記少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報を決定し、
   決定した前記送風制御情報を用いて前記空調装置の送風を制御し、
   取得した前記入眠判定情報から前記人が入眠したと判定してから所定時間経過後に、前記目標指標値を経時的に上昇させ、前記空調装置から送風される空気の風量を減少させる、
   情報処理方法。
2. さらに、前記送風制御情報を用いた送風の制御を開始した後に、前記指標値を前記目標指標値に近づけるための温度に関する温度制御情報を決定し、
   さらに、決定した前記温度制御情報を用いて前記空調装置の設定温度を制御する、
   請求項１に記載の情報処理方法。
3. さらに、前記送風制御情報を用いた送風の制御を開始した後に、前記空調装置の除湿運転を制御する、
   請求項２に記載の情報処理方法。
4. 前記温度制御情報を用いた前記設定温度の制御を開始した後に、前記除湿運転を制御する、
   請求項３に記載の情報処理方法。
5. さらに、前記空間に存在する前記人による、送風、温度及び湿度の少なくとも１つに対する反応を示す反応情報を取得し、
   さらに、取得した前記反応情報に基づいて、前記送風の制御、前記設定温度の制御及び前記除湿運転の制御を行うか否か、前記送風の制御、前記設定温度の制御及び前記除湿運転の制御の内容又は実行順序を決定する、
   請求項３に記載の情報処理方法。
6. さらに、前記空間に存在する前記人の生体情報を取得し、
   さらに、取得した前記生体情報に基づいて前記目標指標値を上昇させるタイミングを決定する、
   請求項１～５のいずれか１項に記載の情報処理方法。
7. さらに、前記空間に存在する前記人による、過去の少なくとも前記送風制御情報を用いた送風の制御結果に対する評価を示す評価情報を取得し、
   さらに、取得した前記評価情報に基づいて前記目標指標値を決定する、
   請求項１～６のいずれか１項に記載の情報処理方法。
8. さらに、少なくとも前記送風制御情報を用いた送風の制御が行われている間に測定された、前記空間に存在する前記人の生体情報を取得し、
   さらに、取得した前記生体情報に基づいて前記目標指標値を決定する、
   請求項１～７のいずれか１項に記載の情報処理方法。
9. 睡眠中の人が存在する、空調装置が設置された空間に存在するセンサによって測定された少なくとも温度及び湿度を取得するセンサ情報取得部と、
   前記人の入眠を判定するための入眠判定情報を取得する入眠判定情報取得部と、
   取得された前記入眠判定情報から前記人が入眠したと判定された後、取得された前記少なくとも温度及び湿度を用いて、温熱に関する指標値を目標指標値に近づけるための送風に関する送風制御情報を決定する決定部と、
   決定された前記送風制御情報を用いて前記空調装置の送風を制御する制御部と、
   を備え、
   前記決定部は、取得した前記入眠判定情報から前記人が入眠したと判定してから所定時間経過後に、前記目標指標値を経時的に上昇させ、前記空調装置から送風される空気の風量を減少させる、
   情報処理装置。

Images