特開 2022-184742 プログラム、電力制御方法、及び電力制御システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022184742

(43)【公開日】2022-12-13

(54)【発明の名称】プログラム、電力制御方法、及び電力制御システム

(51)【国際特許分類】

   G06Q 50/06 20120101AFI20221206BHJP

   G06Q 10/04 20120101ALI20221206BHJP

【ＦＩ】

G06Q50/06

G06Q10/04

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2022070366

(22)【出願日】2022-04-21

(31)【優先権主張番号】P 2021091597

(32)【優先日】2021-05-31

(33)【優先権主張国・地域又は機関】JP

(71)【出願人】

【識別番号】000183646

【氏名又は名称】出光興産株式会社

(74)【代理人】

【識別番号】110000752

【氏名又は名称】弁理士法人朝日特許事務所

(72)【発明者】

【氏名】森本 卓也

(72)【発明者】

【氏名】黒田 さよ子

(72)【発明者】

【氏名】齋藤 清雄

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA04

5L049CC06

(57)【要約】

【課題】より長期間における電力の利用計画を立てやすくする技術を提供する。
【解決手段】プログラムは、コンピュータに、電力調達価格の予測をするステップと、前記電力調達価格の予測に基づいて、電力使用量の調整を需要家に要求する期間を決定するステップと、前記期間に関する情報を前記需要家に対応するユーザに提示するステップとを実行させる。
【選択図】図５

【特許請求の範囲】

【請求項1】

コンピュータに、
電力調達価格の予測をするステップと、
前記電力調達価格の予測に基づいて、電力使用量の調整を需要家に要求する期間を決定するステップと、
前記期間に関する情報を前記需要家に対応するユーザに提示するステップと
を実行させるためのプログラム。

【請求項2】

前記コンピュータに、対象となる地域の天気予報を含む気象予報データを取得するステップを実行させ、
前記期間を決定するステップにおいて、前記電力調達価格の予測及び前記天気予報に基づいて前記期間が決定される
請求項１に記載のプログラム。

【請求項3】

前記気象予報データが、前記天気予報の信頼度を示す情報を含み、
前記期間を決定するステップにおいて、前記電力調達価格の予測、前記天気予報、及び前記信頼度に基づいて前記期間が決定される
請求項２に記載のプログラム。

【請求項4】

前記期間を決定するステップにおいて、一の候補期間について、前記信頼度が基準以上であり、前記電力調達価格が基準よりも低く、かつ前記天気予報が所定の条件を満たす場合、当該一の候補期間が前記電力使用量の調整を需要家に要求する期間として決定される
請求項３に記載のプログラム。

【請求項5】

前記期間を決定するステップにおいて、一の候補期間について、前記信頼度が基準以上であり、前記電力調達価格が基準よりも低く、かつ前記天気予報及び当該一の候補期間の属性が所定の条件を満たす場合、当該一の候補期間が前記電力使用量の調整を需要家に要求する期間として決定される
請求項４に記載のプログラム。

【請求項6】

前記所定の条件が、前記天気予報が晴れであり、かつ前記一の候補期間が日中に相当する時間帯であるという条件を含む
請求項５に記載のプログラム。

【請求項7】

前記所定の条件が、前記天気予報が雨であり、かつ前記一の候補期間が夜間に相当する時間帯であるという条件を含む
請求項５に記載のプログラム。

【請求項8】

前記期間を決定するステップにおいて、一の候補期間について、前記信頼度が基準以上であり、前記電力調達価格が基準よりも低く、かつ前記天気予報、当該一の候補期間の属性、及び前記需要家の属性が所定の条件を満たす場合、当該一の候補期間が前記電力使用量の調整を需要家に要求する期間として決定される
請求項５に記載のプログラム。

【請求項9】

前記プログラムが、
複数の需要家を、定義された複数のグループのうちいずれかのグループに分類するステップ
をさらに実行させるためのプログラムであって、
前記電力使用量の調整を需要家に要求する期間が、前記グループ毎に決定される
請求項１に記載のプログラム。

【請求項10】

前記複数のグループは、需要家が有する設備の種類に応じて区分される
請求項９に記載のプログラム。

【請求項11】

前記設備の種類が、太陽光発電設備及びＶ２Ｈ機器の有無に応じて区分される
請求項１０に記載のプログラム。

【請求項12】

前記複数のグループは、需要家に対応するユーザの属性に応じて区分される
請求項９に記載のプログラム。

【請求項13】

電力調達価格の予測をするステップと、
前記電力調達価格の予測に基づいて、電力使用量の調整を需要家に要求する期間を決定するステップと、
前記期間に関する情報を前記需要家に対応するユーザに提示するステップと
を有する電力制御方法。

【請求項14】

電力調達価格の予測をする予測手段と、
前記電力調達価格の予測に基づいて、電力使用量の調整を需要家に要求する期間を決定する決定手段と、
前記期間に関する情報を前記需要家に対応するユーザに提示する提示手段と
を有する電力制御システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、需要家に電力使用量の調整を要求する技術に関する。

【背景技術】

【0002】

住宅等の需要家におけるエネルギー機器を管理する技術として、いわゆるデマンドレスポンスが知られている。デマンドレスポンスは、例えば電力小売事業者が需要家に対して電力の使用を要求し、これに応答する形で需要家がエネルギー機器の使用を制御するものである。例えば特許文献１は、ＨＥＭＳシステムを有する需要家に供給するために電力小売事業者が電力を調達する際の調達額を最適化するため、蓄電池における充放電タイミングを制御する技術を開示している。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】国際公開第２０２０／０２６８７４号

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１の例において、電力調達価格は、日本卸電力取引所（Japan Electric Power Exchange，ＪＥＰＸ）から所定の時刻に提供される。しかし調達価格データは、翌日１日のみの価格変化を示すものであり、翌々日以降の調達価格は未確定のままである。すなわちこの調達価格データを用いる限り、翌々日以降の長期間に渡る充放電タイミングを決めることが難しく、需要家のユーザに対しては短期間での判断を求めることになる。この状況で需要家のユーザは、電気自動車及び蓄電池等の負荷の利用計画を立てづらいという問題がある。

【0005】

これに対し本発明は、より長期間における電力の利用計画を立てやすくする技術を提供する。

【課題を解決するための手段】

【0006】

本開示の一態様は、コンピュータに、電力調達価格の予測をするステップと、前記電力調達価格の予測に基づいて、電力使用量の調整を需要家に要求する期間を決定するステップと、前記期間に関する情報を前記需要家に対応するユーザに提示するステップとを実行させるためのプログラムを提供する。

【0007】

本開示の別の一態様は、電力調達価格の予測をするステップと、前記電力調達価格の予測に基づいて、電力使用量の調整を需要家に要求する期間を決定するステップと、前記期間に関する情報を前記需要家に対応するユーザに提示するステップとを有する電力制御方法を提供する。

【0008】

本開示の別の一態様は、電力調達価格の予測をする予測手段と、前記電力調達価格の予測に基づいて、電力使用量の調整を需要家に要求する期間を決定する決定手段と、前記期間に関する情報を前記需要家に対応するユーザに提示する提示手段とを有する電力制御システムを提供する。

【発明の効果】

【0009】

本発明によれば、より長期間における電力の利用計画を立てることができる。

【図面の簡単な説明】

【0010】

【図1】一実施形態に係る電力制御システムの概要を示す図。

【図2】電力制御システムの機能構成を例示する図。

【図3】サーバのハードウェア構成を例示する図。

【図4】電力制御システムの動作の概要を示すシーケンスチャート。

【図5】デマンドレスポンスを要求するスケジュールを決定する処理の詳細を例示するフローチャート。

【図6】天気予報を例示する図。

【図7】電力調達価格の推移を例示する図。

【図8A】ＵＩ画面を例示する図。

【図8B】ＵＩ画面を例示する図。

【図8C】ＵＩ画面を例示する図。

【図9】デマンドレスポンスの対象期間となる条件の別の例を示す図。

【図10】変形例に係る動作の概要を示すシーケンスチャート。

【図11】各グループの代表的な電力消費を例示する図。

【発明を実施するための形態】

【0011】

１．構成
図１は、一実施形態に係る電力制御システム１の概要を示す図である。電力制御システム１は、発電装置１０、蓄電池２０、電力負荷３０、電力量計４０、制御装置５０、サーバ６０、及びユーザ端末７０を有する。これらのうち、発電装置１０、蓄電池２０、電力負荷３０、及び制御装置５０は、需要家Ｈに設置される。図面を簡単にするため図１では単一の需要家Ｈのみを図示しているが、電力制御システム１は複数の需要家Ｈを含んでもよい。また、各需要家Ｈには商用電源（図１では略）からの電力も供給される。商用電源からの電力は、電力小売事業者により販売（又は提供）される。サーバ６０は、需要家Ｈの制御装置５０とネットワーク９０を介して接続される。電力制御システム１において、サーバ６０からの指示に応じて制御装置５０が電力制御を行う。制御装置５０は、いわゆるＨＥＭＳコントローラー及びゲートウェイ機器の機能を有する。制御装置５０は、需要家Ｈ内の装置（発電装置１０、蓄電池２０、電力負荷３０、及び電力量計４０）に指示を送ったり、これらの装置から応答やデータを受け付けたりする制御を行う。また、制御装置５０は、サーバ６０等の外部装置から指示を受け付けたり、外部装置にデータ又は要求を送信したりする制御を行う。一例として、制御装置５０の機能には、例えば、電力量計４０から電力量データの入力を受け付け、受け付けた電力データを記録又はサーバ６０等の外部装置に送信する機能が含まれる。

【0012】

ユーザ端末７０は、需要家Ｈのユーザが使用する端末である。ユーザ端末７０は、ネットワーク９０を介してサーバ６０にアクセスすることができる。

【0013】

発電装置１０は、発電を行う装置である。一例において、発電装置１０は、自然エネルギーを用いて発電を行う装置、具体的には太陽光発電装置である。蓄電池２０は、発電装置１０又は商用電源から供給された電力を用いて充電され、蓄えた電力を必要に応じて放電する装置である。一例において、蓄電池２０は据置型である。据置型蓄電池に代えて、又は加えて、電気自動車のバッテリーが蓄電池２０として用いられてもよい。電力負荷３０は、需要家Ｈにおいて電力を消費する装置であり、家電製品、冷暖房装置、及び照明装置等を含む。電力量計４０は、買電及び売電に係る電力量を計測する装置である。この例において、電力量計４０は、いわゆる買電メーター及び売電メーターの機能を含む。なお、図示は省略したが、電力制御システム１は、発電装置１０の発電量を計測する電力量計、及び蓄電池２０の充放電量を計測する電力量計を有する。制御装置５０は、その需要家Ｈにおいて発電装置１０、蓄電池２０、電力負荷３０、及び電力量計４０に関する制御を行う。

【0014】

電力制御システム１における電力制御には、いわゆるデマンドレスポンスが適用される。デマンドレスポンスとは、電力卸市場価格の高騰時または系統信頼性の低下時において、電気料金価格の設定またはインセンティブの支払に応じて、需要家側が電力の使用を増加又は抑制するよう電力の消費パターンを変化させることをいう。具体的には、デマンドレスポンスとは、例えば電力調達価格が相対的に安いときに（電気料金を割り引く等のインセンティブを付与したりして）電力を使用するよう需要家Ｈに促し、電力調達価格が相対的に高いときに（電気料金を引き上げたり等、インセンティブを低くしたりして）電力を使用しないよう需要家Ｈに要求する又は促すことをいう。

【0015】

課題の項で説明したように、日本卸電力取引所から所定の時刻に提供される、確定した電力調達価格のデータは翌日１日のみの価格変化を示すものであり、翌々日以降の調達価格は未確定のままである。すなわちこの調達価格データを用いる限り、翌々日以降のデマンドレスポンスの計画を立てることは難しい。本実施形態においては、確定した電力調達価格のデータにより示される期間よりも長い期間においてデマンドレスポンスを提供するためのサービスが提供される。以下デマンドレスポンスのために需要家にインセンティブを与えることを「特定サービス」という。特定サービスは、例えば、電気料金の割引、キャッシュバックの付与、ポイントの付与、及びクーポンの発行の少なくとも１種を含む。

【0016】

図２は、電力制御システム１の機能構成を例示する図である。電力制御システム１は、記憶手段６１、取得手段６２、予測手段６３、決定手段６４、提示手段６５、処理手段６６、記憶手段７１、取得手段７２、表示手段７３、及び送信手段７４を有する。この例において、記憶手段６１、取得手段６２、予測手段６３、決定手段６４、提示手段６５、及び処理手段６６はサーバ６０に実装される。記憶手段７１、取得手段７２、表示手段７３、及び送信手段７４はユーザ端末７０に実装される。

【0017】

サーバ６０において、記憶手段６１は、各種のデータを記憶する。この例において、記憶手段６１が記憶するデータには、スケジュールデータベース（図示略）が含まれる。スケジュールデータベースは、デマンドレスポンスを需要家に要求するスケジュールに関する情報が記録されたデータベースである。取得手段６２は、対象となる地域の天気予報を含む気象予報データを取得する。予測手段６３は、電力調達価格の予測をする。決定手段６４は、少なくとも電力調達価格の予測に基づいて、電力使用量の調整（デマンドレスポンス）を需要家に要求する期間を決定する。一例において、決定手段６４は、電力調達価格の予測及び天気予報に基づいて期間を決定する。提示手段６５は、電力使用量の調整を需要家に要求する期間に関する情報を、需要家に対応するユーザに提示する。

【0018】

ユーザ端末７０において、記憶手段７１は、各種のデータを記憶する。取得手段７２は、電力使用量の調整を需要家に要求する期間に関する情報を取得する。表示手段７３は、電力使用量の調整の要求に対する応答を入力するための画面を表示する。送信手段７４は、電力使用量の調整の要求に対する応答をサーバ６０に送信する。

【0019】

サーバ６０において、処理手段６６は、ユーザ端末７０から送信された、電力使用量の調整の要求に対する応答に応じた処理を行う。

【0020】

図３は、サーバ６０のハードウェア構成を例示する図である。サーバ６０は、ＣＰＵ（Central Processing Unit）６０１、メモリ６０２、ストレージ６０３、及び通信ＩＦ（Interface）６０４を有するコンピュータ装置である。ＣＰＵ６０１は、プログラムを実行して各種の演算を行い、サーバ６０の他のハードウェア要素を制御する制御装置である。メモリ６０２は、ＣＰＵ６０１がプログラムを実行する際のワークエリアとして機能する主記憶装置である。ストレージ６０３は、各種のプログラム及びデータを記憶する不揮発性の補助記憶装置である。通信ＩＦ６０４は、所定の通信規格（例えばイーサネット（登録商標））に従って他の装置と通信する通信装置である。

【0021】

この例において、ストレージ６０３に記憶されるプログラムには、コンピュータ装置を電力制御システム１におけるサーバ６０として機能させるためのプログラム（以下「サーバプログラム」という）が含まれる。ＣＰＵ６０１がサーバプログラムを実行することにより、コンピュータ装置に図２の機能が実装される。ＣＰＵ６０１がサーバプログラムを実行している状態において、メモリ６０２及びストレージ６０３の少なくとも一方が記憶手段６１の一例である。ＣＰＵ６０１が取得手段６２、予測手段６３、決定手段６４、提示手段６５、及び処理手段６６の一例である。

【0022】

詳細な説明は省略するが、ユーザ端末７０は、プロセッサ、メモリ、ストレージ、ディスプレイ、入力装置、及び通信ＩＦを含むコンピュータ装置、例えばスマートフォン又はパーソナルコンピュータである。この例において、ストレージに記憶されるプログラムには、コンピュータ装置を電力制御システム１におけるユーザ端末７０として機能させるためのプログラム（以下「クライアントプログラム」という）が含まれる。プロセッサがクライアントプログラムを実行している状態において、メモリ及びストレージの少なくとも一方が記憶手段７１の一例である。プロセッサが取得手段７２の一例である。ディスプレイが表示手段７３の一例である。通信ＩＦが送信手段７４の一例である。

【0023】

２．動作
図４は、電力制御システム１の一実施形態に係る動作の概要を示すシーケンスチャートである。ステップＳ１において、サーバ６０は、デマンドレスポンスを要求する（すなわち特定サービスを提供する）スケジュールを決定する。すなわち、サーバ６０は、需要家Ｈが電力を使用するインセンティブを与える期間を決定する。

【0024】

図５は、ステップＳ１の処理（デマンドレスポンスを要求するスケジュールを決定する処理）の詳細を例示するフローチャートである。図５のフローは、例えば、所定のイベントが発生したことをトリガとして開始される。図５のフローを開始させるイベントは、例えば、毎日、所定の時刻になったというイベントである。なお以下において、サーバ６０又はユーザ端末７０を処理の主体として記載するが、これは、サーバプログラム等のプログラムを実行しているＣＰＵ６０１等のハードウェア要素が、他のハードウェア要素と協働して処理を実行することを意味する。

【0025】

ステップＳ１０１において、サーバ６０は、電力制御システム１に含まれる複数の需要家Ｈのうち、対象となる１以上の需要家（以下「対象需要家」という）を特定する。この例において、まず地域（例えば区市町村）が特定され、その地域に存在する需要家が対象需要家として特定される。換言するとステップＳ１０１の処理は、対象地域を特定しているということもできる。

【0026】

ステップＳ１０２において、サーバ６０は、気象予報データを取得する。気象予報データは、対象需要家が属する地域における所定の期間（以下「対象期間」という）の天気予報を含む。対象期間は、例えば１週間又は１ヶ月間等、比較的長い期間をいう。ここでいう「長い期間」とは、後述する、確定した電力調達価格が提供される期間（例えば将来の２４時間）よりも長い期間をいう。ここで取得される気象予報データは、ステップＳ１０１において特定された対象需要家に対応する地域、具体的には、対象需要家が存在する地域の気象予報データである。

【0027】

図６は、天気予報を例示する図である。この例において、対象期間は翌日から１週間である。天気予報は、天気の種別（例えば、晴れ、曇り、雨、又は雪など）、降水確率、信頼度、及び最低／最高気温を含む。このうち信頼度は、天気予報の確からしさを示す。一例において、信頼度は、Ａ、Ｂ、及びＣの３段階で表される。信頼度Ａ、信頼度Ｂ、及び信頼度Ｃはそれぞれ、例えば的中率が８０％程度、７０％程度、及び５０％程度に相当する。なお図６の例においては、翌々日までは信頼度が「－」と記載されているが、これは予報の信頼度が最大限に高いことを示す。

【0028】

この例において、対象期間はさらに複数の期間（例えば２４時間毎の期間）に分割される。天気予報は分割された期間毎に行われる。一部の項目について、この期間はさらに詳細に分割されてもよい。図６の例では、今日及び明日の降水確率に関しては分割された期間がさらに４つ（すなわち６時間毎の期間）に分割される。

【0029】

再び図５を参照する。ステップＳ１０３において、サーバ６０は、電力調達価格を予測する。電力調達価格は、過去の調達価格推移の実績、及び気象予報データを用いて予測される。

【0030】

図７は、電力調達価格の推移を例示する図である。この図は、過去のある時期における、晴れの日、曇りの日、及び雨の日における調達価格の、２４時間分の推移を示す。この例においては、０時から７時まで及び１８時から２４時までの時間帯における調達価格の推移は天気によらずほぼ同一である。一方で７時から１８時までの時間帯における調達価格の推移は天気に応じて異なっている。すなわち、晴れ、曇り、及び雨の順序で価格が高くなる。これは晴れの日は太陽光発電設備から供給される電力が増え、電力卸売市場に流通する電力量が増大するためであると理解できる。

【0031】

サーバ６０は、過去における電力調達価格の推移と気象データ（例えば、天気、最高気温、及び最低気温）との関係を数式化したモデルを有する。サーバ６０は、このモデル及びステップＳ１０１において取得した気象予報データを用いて、対象期間における電力調達価格を予測する。

【0032】

なお対象期間のうち一部（例えば翌日の０時から２４時）については確定した電力調達価格のデータが提供されるので、サーバ６０は電力調達価格の予測を行わず、この確定した電力調達価格のデータを用いる。

【0033】

再び図５を参照する。ステップＳ１０４において、サーバ６０は、対象副期間を特定する。対象副期間とは、対象期間をさらに分解した複数の副期間（デマンドレスポンスの対象期間の候補期間の一例）のうち以下の処理の対象となる一の副期間をいう。一例において、対象期間は１日ずつ、０時から７時まで（夜間に相当）、７時から１８時まで（日中に相当）、及び１８時から２４時まで（夜間に相当）の３つの副期間に分割される。対象期間が１週間であれば、対象期間は２１個の副期間に分割される。サーバ６０は、早い時間帯から順に対象副期間を特定する。

【0034】

ステップＳ１０５において、サーバ６０は、対象副期間における天気予報の信頼度が基準以上であるか判断する。例えば、基準が「信頼度Ａ」である場合、対象副期間の天気予報の信頼度がＡであれば基準以上であると判断され、信頼度がＢ又はＣであれば基準未満であると判断される。対象副期間における天気予報の信頼度が基準以上であると判断された場合（Ｓ１０５：ＹＥＳ）、サーバ６０は処理をステップＳ１０６に移行する。対象副期間における天気予報の信頼度が基準以上でないと判断された場合（Ｓ１０５：ＮＯ）、サーバ６０は処理をステップＳ１０９に移行する。

【0035】

ステップＳ１０６において、サーバ６０は、対象副期間の属性及び天気予報が特定の条件を満たすか判断する。一例において、特定の条件は、以下の（ア）及び（イ）の一方に該当するというものである。（ア）対象副期間が日中であり、かつ（その日中の）天気予報が晴れである。（イ）対象副期間が夜間であり、かつ（対応する日中の）天気予報が雨である。この条件（ア）及び（イ）は以下の想定に基づく。電力調達価格は、供給が多い時間帯は安く、需要が多い時間帯は高くなる。一般には、朝方及び夕方は電力の需要が多く、市場における調達価格も高くなる傾向にある。朝方及び夕方を除くと、一般には日中よりも深夜の方が調達価格が安い傾向にある。ただし、太陽光発電の発電量が多いとき（すなわち晴れのとき）は市場に供給される電力量が増え、深夜よりも日中の方が調達価格は安くなる。したがってサーバ６０は、晴れの日中をデマンドレスポンスの対象（の候補）とする（（ア）のケース）。前述のとおり晴れでなければ深夜の方が調達価格は安いので、同日の日中が（太陽光発電の発電量が少ない確率が高い）雨である深夜をデマンドレスポンスの対象（の候補）とする（（イ）のケース）。なお電力需要は種々の条件に依存して変動するので、これらの条件は、対象需要家の地域及び季節等を考慮してより詳細に設定されてもよい。

【0036】

この条件が満たされた場合（Ｓ１０６：ＹＥＳ）、サーバ６０は、処理をステップＳ１０７に移行する。この条件が満たされなかった場合（Ｓ１０６：ＮＯ）、サーバ６０は、処理をステップＳ１０９に移行する。

【0037】

ステップＳ１０７において、サーバ６０は、対象副期間における電力調達価格の予測値が条件を満たすか、具体的には基準より安いか判断する。電力調達価格は時間とともに変動するが、ここでは対象副期間における平均値が予測値として用いられる。電力調達価格の基準は、対象副期間の属性に応じて定義される。この例では、日中向けの基準及び夜間向けの基準の２つが用いられる。対象副期間における電力調達価格の予測値が基準より安いと判断された場合（Ｓ１０７：ＹＥＳ）、サーバ６０は処理をステップＳ１０８に移行する。対象副期間における電力調達価格の予測値が基準より高いと判断された場合（Ｓ１０７：ＮＯ）、サーバ６０は処理をステップＳ１０９に移行する。

【0038】

ステップＳ１０８において、サーバ６０は、対象副期間を、デマンドレスポンスの対象期間として決定する。すなわちサーバ６０は、データベースにおいて対象副期間の識別情報及びその副期間に対応するフラグの値を、特定サービスを提供する旨を示す値に書き換える。

【0039】

さらに、サーバ６０は、対象副期間におけるインセンティブの内容を決定する。例えば、インセンティブが電気料金の割引である場合、サーバ６０はその割引額を決定する。割引額は、例えば、対象副期間における電力調達価格の予測値と基準との差の関数である。

【0040】

ステップＳ１０９において、サーバ６０は、全ての副期間について処理が完了したか判断する。全ての副期間について処理が完了したと判断された場合（Ｓ１０９：ＹＥＳ）、サーバ６０は、処理をステップＳ１１０に移行する。まだ処理されていない副期間があると判断された場合（Ｓ１０９：ＮＯ）、サーバ６０は、処理をステップＳ１０４に移行する。ステップＳ１０４において対象副期間が更新され、以降の処理が繰り返し行われる。

【0041】

なお一例において、サーバ６０は、デマンドレスポンスの対象期間として新たに特定された副期間に対してそのフラグの値を変更するだけでなく、デマンドレスポンスの対象期間として特定されなかった副期間に対してそのフラグの値を、特定サービスを提供する旨を示す値に書き換える。例えば、毎日１７時に翌日０時から７日後の２４時までの期間を対象期間として処理をする例を考える。このとき、対象期間のうち翌日０時から６日後の２４時までの期間については、既に前日１７時の時点で処理が行われており、条件を満たす副期間については既にフラグが書き込まれている。例えば天気予報が昨日から変更された等の事情により、ある副期間が、昨日の処理においてはデマンドレスポンスの対象期間として特定されたにもかかわらず、今日の処理においてはデマンドレスポンスの対象期間として特定されなかった場合、サーバ６０は、その副期間のフラグの値を、特定サービスを提供しない旨を示す値に書き換える。

【0042】

別の例において、サーバ６０は、デマンドレスポンスの対象期間として新たに特定された副期間に対してそのフラグの値を変更するだけであり、デマンドレスポンスの対象期間として特定されなかった副期間に対してそのフラグの値を変更しなくてもよい。すなわち、一度でもデマンドレスポンスの対象期間として特定された副期間については、その後の天気予報の変更等の事情にかかわらず特定サービスを提供する対象としての状態が維持されてもよい。

【0043】

ステップＳ１１０において、サーバ６０は、全ての需要家を対象需要家として処理が完了したか判断する。全ての需要家について処理が完了したと判断された場合（Ｓ１１０：ＹＥＳ）、サーバ６０は、図５のフローを終了する。まだ対象需要家として処理されていない需要家があると判断された場合（Ｓ１１０：ＮＯ）、サーバ６０は、処理をステップＳ１０１に移行する。ステップＳ１０１において対象需要家が更新され、以降の処理が繰り返し行われる。

【0044】

再び図４を参照する。ステップＳ２において、サーバ６０は、ステップＳ１において生成したスケジュール（すなわちデマンドレスポンスの要求）を示すデータをユーザ端末７０に提示（又は送信）する。サーバ６０は、ユーザ端末７０からの要求によらず、新たなスケジュールが生成されたことをトリガとしてこのデータをユーザ端末７０に提示する（すなわちプッシュ送信する）。あるいは、サーバ６０は、ユーザ端末７０からの要求に応じてこのデータを提示してもよい。一例において、このデータは、ユーザにデマンドレスポンスへの応答（すなわち電力の使用予定又は使用予約）を入力させるためのＵＩ画面を含む。

【0045】

ステップＳ３において、ユーザ端末７０は、デマンドレスポンスへの応答（具体的には電力負荷となる装置の使用予定又は使用予約）の入力を受け付ける。デマンドレスポンスへの応答は、ステップＳ２において送信されるデータを用いて表示されるＵＩ画面を介して入力される。

【0046】

図８Ａ～図８Ｃは、ステップＳ３において表示されるＵＩ画面を例示する図である。ここでは説明のため、同じ需要家Ｈのユーザに対し４月１３日（図８Ａ）、４月１６日（図８Ｂ）、及び４月２０日（図８Ｃ）の３つのタイミングで表示されるＵＩ画面を示す。このＵＩ画面は８つの領域（領域９１～９８）を含む。各領域は、それぞれ異なる日付に対応する。領域９１には当日の情報が、領域９２には翌日の情報が、…、領域９８には７日後の情報が、それぞれ表示される。各領域には、（ａ）日付を示す情報、（ｂ）デマンドレスポンスの候補となる時間帯の情報、（ｃ）その時間帯に対応するインセンティブを示す情報、及び（ｄ）そのデマンドレスポンスの対応を指定するＵＩオブジェクトが表示される。図８Ａの領域９８を例として見ると、（ａ）として４月２０日が、（ｂ）として（１）１時から５時まで及び（２）１０時から１２時までの２つの時間帯が、（ｃ）として（１）に対して割引額５円及び（２）に対して割引額８円が、（ｄ）として参加／不参加を切り替えるボタンが、それぞれ表示される。なお（ｄ）に関して「参加」とはその時間帯に指定された負荷（図８Ａの例では電気自動車の充電器）を使用する予定であることを示し、「不参加」とはその負荷を使用しないこと又は使用予定が不明であることを示す。需要家Ｈのユーザは、（ｄ）のボタンをタップ又はクリックすることによりデマンドレスポンスへの応答を指定する。

【0047】

このＵＩ画面において、デマンドレスポンスの対象となる日とならない日とは異なる外観で表示される。具体的には、その時点においてデマンドレスポンスの対象でない日はグレーアウトされる（デマンドレスポンスの対象となる日はグレーアウトされない）。図８Ａの例では、領域９２、領域９５、及び領域９７がグレーアウトされている。グレーアウトされている領域について、ユーザ端末７０は、（ｄ）のボタンに対する操作を受け付けない。すなわち、領域９２、領域９５、及び領域９７においては、（ｄ）のボタンをタップ又はクリックしても参加／不参加を切り替えることはできない。

【0048】

図８Ｂは、図８Ａから３日後に表示されるＵＩ画面を示す。例えば４月１７日の情報は、図８Ａにおいては領域９５に表示されていたが、図８Ｂにおいては領域９２に表示される。ここで、図８Ａにおいて４月１７日（領域９５）はグレーアウトされているが、図８Ｂにおいて４月１７日（領域９２）はグレーアウトされていない。これは、図８Ａを表示した４月１３日の時点では４月１７日の予測が条件を満たさずデマンドレスポンスの対象となっていなかったものの、４月１６日の時点では天気予報が変更された等の理由により４月１７日の予測が条件を満たすようになりデマンドレスポンスの対象となったことを示す。

【0049】

図８Ｃは、図８Ｂから４日後に表示されるＵＩ画面を示す。例えば４月２０日の情報は、図８Ａにおいては領域９８に、図８Ｂにおいては領域９５に、図８Ｃにおいては領域９１に、それぞれ表示される。図８Ａ及び図８Ｂの例において、４月２０日の１０時から１２時までの時間帯における割引額は８円であったが、図８Ｃの例においてその割引額は１０円に変更されている。これは、図８Ｃの時点では電力調達価格が確定しているところ、図８Ｂの時点の電力調達価格の予測値とは差があったことに起因している。なお割引額は日が進むにつれプラスの方向にもマイナスの方向にも変化する可能性がある。サーバ６０は、既にデマンドレスポンスへの参加を指示済のユーザに対しては、参加を指示したときよりも不利な条件とならないよう、割引額を決定する。図８Ｃの例では、４月２４日の１時から５時までの時間帯における割引額は５円でありこのユーザは既に参加を指示しているところ、これが４月２４日当日になって（まだ参加を指示していないユーザ向けの）割引額が３円で確定した場合であっても、このユーザに対しては割引額５円が適用される（ＵＩ画面においても割引額は５円と表示される）。すなわちサーバ６０は、各ユーザについて、デマンドレスポンスへの参加／不参加の別及び参加を指示した時点におけるインセンティブの内容をデータベースに記憶する。ＵＩ画面のデータをユーザ端末７０に送信する際には、サーバ６０は、このデータベースからそのユーザのデータを読み出し、そのユーザに対して適用されるインセンティブを特定する。

【0050】

再び図４を参照する。デマンドレスポンスへの応答が変更されると、ユーザ端末７０は、変更された応答を示す情報をサーバ６０に送信する。サーバ６０は、この応答に応じた処理を行う（ステップＳ４）。例えば、サーバ６０は、そのユーザについてデマンドレスポンスへの参加／不参加の別及び参加を指示した時点におけるインセンティブの内容をデータベースに書き込む。また、サーバ６０は、そのユーザが使用した電力に対する電気料金を計算する際には、データベースに記録されているインセンティブの内容を参照する。

【0051】

以上で説明したように本実施形態によれば、電力調達価格が確定している期間よりも長い期間に対して、デマンドレスポンスの計画を生成することができる。

【0052】

３．変形例
本発明は上述の実施形態に限定されるものではなく種々の変形実施が可能である。以下、変形例をいくつか説明する。以下の変形例に記載した事項の一部が、他の一部又は上述の実施形態と組み合わせて適用されてもよい。

【0053】

３－１．デマンドレスポンスの対象期間となる条件
デマンドレスポンスの対象となる期間の条件は実施形態において例示したものに限定されない。例えば、サーバ６０は、電力調達価格の予測、天気予報、天気予報の信頼度、及び副期間の属性に加え、対象となる需要家の属性に基づいてデマンドレスポンスの対象となる期間を決定してもよい。この場合において、対象となる需要家の属性としては、例えば、太陽光発電設備の有無が用いられる。具体的には以下のとおりである。

【0054】

図９は、デマンドレスポンスの対象期間となる条件の別の例を示す図である。この例では、需要家の属性と、その属性に対応する条件とが示される。電力調達価格は、１日の変動における相対的な高低を示す。図示された表の最上行は、参考として実施形態において説明した条件（ア）及び（イ）を示す。これは、需要家における太陽光発電設備の有無によらずに適用される条件を示している。

【0055】

表の中段は、太陽光発電設備を有する需要家に適用される条件を例示する。この条件は以下のとおりである。（ウ）対象副期間が深夜であり、かつ（対応する日中の）天気予報が晴れである。この条件（ウ）は以下の想定に基づく。すなわち晴れの日の日中は太陽光発電の発電量が多く、市場に供給される電力は増えるが、一方その需要家（太陽光発電設備を有する）内においても太陽光発電設備における発電量が増え、他から電力を購入しても供給過多になり需要家内でその電力を消費できなくなるおそれがある。したがってサーバ６０は、晴れの日中はデマンドレスポンスの対象とせず、その日の深夜をデマンドレスポンスの対象（の候補）とする。

【0056】

表の下段は、太陽光発電設備を有さない需要家に適用される条件を例示する。この条件は以下のとおりである。（エ）対象期間が日中であり、かつ（その日中の）天気予報が晴れである。（オ）対象期間が深夜であり、かつ（対応する日中の）天気予報が晴れである。条件（エ）に関し、晴れの日の日中は太陽光発電の発電量が多く、市場に供給される電力は増える。その需要家（太陽光発電設備を有さない）内においても太陽光発電設備による発電はないので、調達価格が安い日中をデマンドレスポンスの対象（の候補）とする。条件（オ）に関し、深夜の時間帯は（朝方及び夕方と比較して）一般に電力の調達価格が安価であるので、この時間帯をデマンドレスポンスの対象（の候補）とする。なお、太陽光発電設備の有無により適用される条件を決める例においても、実施形態において説明した条件（イ）に相当する条件は維持される。

【0057】

サーバ６０は、デマンドレスポンスの対象（の候補）となる条件を満たすかの判断を、対象期間に含まれる副期間の一部についてのみ行ってもよい。すなわち、サーバ６０は、例えば、過去の履歴から電力小売市場における電力供給量が増える時間帯、一例としては１時から５時まで及び１０時から１２時までの時間帯についてのみデマンドレスポンスの対象（の候補）となる条件を満たすかの判断を行ってもよい。

【0058】

３－２．電力調達価格の予測
電力調達価格を予測する具体的手法は、実施形態において例示したものに限定されない。例えば電力調達価格の予測値は、天気予報によらず、過去の同時期（例えば同月同日を中心とする前後１．５月）の平均値であってもよい。あるいは、電力調達価格の予測値は機械学習を用いて得たものであってもよい。この場合、例えば期間の属性、需要家の属性、及び気象データを入力層に、その期間の確定した電力調達価格の推移を出力層に教師データとして与えて学習をさせた機械学習モデルが用いられる。

【0059】

３－３．対象需要家の特定
対象需要家を特定する具体的手法は実施形態において例示したものに限定されない。例えば地域に応じて対象需要家を特定することに代えて、又は加えて、需要家の属性に応じて対象需要家が特定されてもよい。ここで用いられる需要家の属性は、例えば、保有するエネルギー機器の種類、エネルギー危機の量、過去の電力使用実績、及び過去の発電実績の少なくとも１種である。

【0060】

３－４．需要家群を対象とする制御
この例において、電力制御システム１は、需要家を複数のグループに分類し、グループ毎にデマンドレスポンスのスケジュールを決定する。さらに、この例において、電力制御システム１は、需要家Ｈからのデマンドレスポンスの応答によらず、自動的に需要家Ｈの機器を制御する。これらは、以下の事情による。まず、本願発明者らの実験によれば、複数の需要家Ｈはその属性などに応じて区分されるグループ毎に、似たような電力消費のパターンを有することが分かった。また、複数の需要家全体に対して電力消費を制御するために、毎回、デマンドレスポンスに対する個々の需要家Ｈの応答を待っていたのでは、（需要家Ｈにとって毎回応答を入力するのは手間であるので）デマンドレスポンスへの参加率が（電力制御システム１の運営事業者が期待するよりも）低くなってしまうという問題があった。この例では、この問題に対処する。

【0061】

図１０は、変形例に係る動作の概要を示すシーケンスチャートである。ステップＳ５１において、サーバ６０は、需要家Ｈを複数のグループに分類する。各需要家Ｈをどのグループに分類するかの基準は、例えば電力制御システム１の運営事業者により定義される。サーバ６０は、この定義を示す情報を記憶する。

【0062】

この例において、複数のグループを区分する基準は、その需要家が有する設備の種類に応じて定義される。具体的には、太陽光発電設備の有無及びＶ２Ｈ機器の有無に応じてグループが定義される。Ｖ２Ｈ機器とは、電気自動車の電池に蓄えられている電力を家庭でも利用できるようにした機器であり、Ｖ２Ｈ充放電器又はＥＶ用パワーコンディショナと呼ばれる機器である。詳細には、太陽光発電設備の有無×Ｖ２Ｈ機器の有無により需要家は以下の４つのグループに区分される。
グループＡ：太陽光発電設備無しかつＶ２Ｈ機器無し
グループＢ：太陽光発電設備有りかつＶ２Ｈ機器無し
グループＣ：太陽光発電設備無しかつＶ２Ｈ機器有り
グループＤ：太陽光発電設備有りかつＶ２Ｈ機器有り

【0063】

図１１は、各グループの代表的な電力消費を例示する図である。ここでは、需要家における、買電、売電、ＥＶ充電、及びＥＶ放電の時間変化が示される。どのグループの需要家も、１：００－４：００の時間帯にＥＶ充電を行っている。なおこの時間帯の買電量は、ＥＶ充電に使われる電力を含んだ値であるが、説明のため買電量とＥＶ充電量とを別に図示している。例えばグループＡでは１：００－４：００に約６００（任意単位）の電力量がＥＶ充電に用いられたことが示されている。この時間帯の買電量は約８００（任意単位）であるが、この値にはＥＶ充電に用いられた電力量が含まれている。すなわちＥＶ充電以外に用いられた電力量は約２００（任意単位）である。

【0064】

グループＡは太陽光発電設備もＶ２Ｈ機器も無いので、一部の時間帯にＥＶ充電を行う以外は買電があるだけである。グループＢは太陽光発電設備があるので、７：００－１６：００の時間帯に売電が発生する。グループＣはＶ２Ｈ機器があるので、一部の時間帯にＥＶ放電が行われる。ＥＶ放電によりＥＶの電池残量が減少するので、グループＣでは１０：００－１４：００の時間帯にもＥＶ充電が行われる。グループＤは太陽光発電設備及びＶ２Ｈ機器があるので、１０：００－１４：００の時間帯にもＥＶ充電が行われ、７：００－１６：００の時間帯に売電が発生する。さらに一部の時間帯にＥＶ放電が行われる。

【0065】

このようにグループ毎に電力消費のパターンが異なるので、サーバ６０は、このような電力消費パターンの違いを踏まえたスケジュールを決定する。例えば、需要家に対して電力消費を減らすデマンドレスポンス（いわゆる下げＤＲ）を要求する場合、Ｖ２Ｈ機器を有する需要家であれば買電量を減らしてもＥＶ放電により電力をまかなえるので、下げＤＲの要求に応じてもらえる可能性が高いと予想される。

【0066】

グループの分類は、需要家が有する設備の種類により定義されるものに限定されない。需要家が有する設備の種類に加えて、又は代えて、需要家におけるユーザの生活様式により定義されてもよい。生活様式とは、日常的な行動を示す事項であり、一例としては、その需要家に属するユーザがＥＶを日中（例えば通勤に）使用するか否かを示す事項である。例えば、ＥＶを所有してる需要家であっても、そのＥＶをユーザが通勤に使っているのであれば、（たとえＶ２Ｈ機器を有していたとしても）日中の時間帯はＥＶ放電を行うことができない。したがってこの需要家に対して下げＤＲを要求しても応じてもらえる可能性は低いと予想される。

【0067】

さらに、グループの分類は、上記の事項に加えて、又は代えて、需要家に属するユーザの属性に応じて定義される。ユーザの属性は、例えば、そのユーザの家族構成である。例えば幼い子供がいる家庭と単身社会人の家庭とでは電力を消費する時間帯が異なると考えられる。

【0068】

実施形態においては説明を省略したが、デマンドレスポンスのスケジュールを決定する際には、以下の処理が行われる。サーバ６０は、まず、ある対象期間において、電力制御システム１が管理する需要家全体の電力需要を予測する。次に、サーバ６０は、その対象期間において、商用電源における供給予備率の情報を取得する。供給予備率の情報は、例えば電力会社から提供される。さらに、サーバ６０は、需要家全体の発電量（太陽光発電設備などによる自家発電の総量）を予測する。デマンドレスポンスにはいわゆる下げＤＲと上げＤＲとがある。サーバ６０は、下げＤＲを要求する条件（例えば、予測される供給予備率がしきい値を下回る）及び上げＤＲを要求する条件（例えば、下げＤＲの前後の時間帯において余剰供給力が生じる）を記憶しており、これらの条件に従って、下げＤＲを要求するか上げＤＲを要求するかを決める。例えば、サーバ６０は、供給予備率がしきい値を下回り、かつ需要家全体の発電量がしきい値を下回る場合、下げＤＲを要求することを決定する。

【0069】

時間帯及び下げＤＲ／上げＤＲの別によってどのグループにＤＲ要求をすると応じてもらえる可能性が高いか、あらかじめ予測又は判断をすることができる。サーバ６０は、どの時間帯にどちらのＤＲをどのグループに対して要求すると応じてもらえる可能性が高いか、その優劣を示すデータベース（図示略）を記憶している。サーバ６０は、このデータベースを参照して、どのグループに対しＤＲ要求を送信するか決定する。

【0070】

再び図１０を参照する。ステップＳ５２において、サーバ６０は、デマンドレスポンスを要求するスケジュールを決定する。この処理は例えばステップＳ１と同様に行われる。ステップＳ５３において、サーバ６０は、ステップＳ５２において生成したスケジュール（すなわちデマンドレスポンスの要求）を示すデータを、ＤＲ要求の対象となるグループに属する（すべての）ユーザ端末７０に提示（又は送信）する。サーバ６０は、ユーザ端末７０からの要求によらず、新たなスケジュールが生成されたことをトリガとしてこのデータをユーザ端末７０に提示する（すなわちプッシュ送信する）。あるいは、サーバ６０は、ユーザ端末７０からの要求に応じてこのデータを提示してもよい。

【0071】

サーバ６０からデマンドレスポンスの要求を受信すると、ユーザ端末７０は、受信したスケジュールを記憶する（ステップＳ５４）。この例では、図４の例とは異なり、ユーザに対しデマンドレスポンスへの応答（具体的には電力負荷となる装置の使用予定又は使用予約）の入力を受け付けられず、自動的に電力負荷となる装置の使用予定又は使用予約が設定される。なお、そのデマンドレスポンスの要求に応えられないときは、ユーザは、その予定又は予約をユーザ端末７０からキャンセルすることができる。

【0072】

以上で説明したようにこの例によれば、需要家はユーザの生活様式に応じて決まるグループ（又は需要家群）に分類され、そのグループに対してデマンドレスポンスのスケジュールが決定される。したがって、より適正な需要家に対しより適切なデマンドレスポンスの要求をすることができる。

【0073】

なおこの例では、需要家のユーザからのデマンドレスポンスへの応答によらず自動的にデマンドレスポンスのスケジュールを決定する例を説明したが、実施形態の例のように、サーバ６０は、ユーザからのデマンドレスポンスへの応答に応じてデマンドレスポンスのスケジュールを確定してもよい。

【0074】

３－５．インセンティブ
適用されるインセンティブの種類及びその決め方は実施形態において例示したものに限定されない。実施形態においてはデマンドレスポンスが電力の使用を増加させるためのものである例を説明したが、例えば、デマンドレスポンスがその期間の電力の使用を抑制させるためのものであれば、インセンティブは電気料金の割増又はマイナスポイントの付与であってもよい。

【0075】

３－６．他の実施形態
電力制御システム１における機能要素とハードウェア要素との対応関係は実施形態において例示したものに限定されない。例えば、実施形態においてサーバ６０の機能として説明したものの一部を、制御装置５０に実装してもよい。あるいは、実施形態においてサーバ６０の機能として説明したものの一部を、ネットワーク上の他の装置に実装してもよい。

【0076】

電力制御システム１のハードウェア要素は実施形態において例示したものに限定されない。要求される機能を実装できるものであれば、電力制御システム１はどのようなハードウェア構成を有していてもよい。例えば、サーバ６０は物理サーバであってもよいし、仮想サーバ（例えばいわゆるクラウド）であってもよい。

【0077】

実施形態において例示した各種のプログラムは、それぞれ、インターネット等のネットワークを介したダウンロードにより提供されてもよいし、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）等の記録媒体に記録された状態で提供されてもよい。

【符号の説明】

【0078】

１…電力制御システム、１０…発電装置、２０…蓄電池、３０…電力負荷、５０… 制御装置、６０…サーバ、６１…記憶手段、６２…取得手段、６３…予測手段、６４…決定手段、６５…提示手段、６６…処理手段、７０…ユーザ端末、７１…記憶手段、７２…取得手段 、７３…表示手段、７４…送信手段、９０…ネットワーク、６０１…ＣＰＵ、６０２…メモリ、６０３…ストレージ、６０４…通信ＩＦ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図8C】

【図9】

【図10】

【図11】