ホームネットワークシステムの概要と現状報告書

平成 27 年 3 月
一般財団法人テレコム先端技術研究支援センター

まえがき

本報告書は、近年再び注目を浴びつつあるホームネットワークシステムの概要について解説したものである。ホームネットワークは長い開発の歴史と、広範にわたるサービス分
野があるため、一般に、混沌としてわかりにくいという印象を与えている感が否めないが、その研究開発を行なっているコミュニティ内では全体像の見通しをつけ、各種の技術開発の積み上げを可能とするための整理と標準化が行われてきていることも事実である。

ホームネットワークは人間が生活を続けていく上で必要な様々な活動を支援するものであることから、ニーズ自体は常に存在し続けている。従って、無線LANの開発のようなシーズ的な進展、あるいは、震災後の電力不足のようなニーズ的な状況の変化が生じると、それをきっかけに多数の新規参入者が同時期に現れることも珍しくないが、多くの場合、
過去に積み上げられてきたホームネットワークに関する知見が必ずしも活かされることな
く、過去と同様の開発を繰り返して難題に突き当たり、実用化の観点ではうまく行かないといった状況になりがちである。

本報告書では、こうした状況を少しでも改善すべく、ホームネットワークシステムの全体像について概説するとともに、近年、ホームネットワーク市場を牽引しているエネルギ
ーマネジメントサービスについて、また、2014 年度末現在のホームネットワーク市場全体について述べていく。

調査委員会名簿（順不同 敬称略）

康雄

北陸先端科学技術大学院大学
情報科学研究科 教授

委員長

丹

事務局

門馬 弘

一般財団法人テレコム先端技術研究支援センター
研究企画部 部長

事務局

牧野 淳一

一般財団法人テレコム先端技術研究支援センター
事業部 調査役

目 次
第 1 章

ホームネットワークとは何か………………………………………………………1

1.1

ホームネットワークのサービスとアプリケーション…………………………………1

1.2

ホームネットワークのアーキテクチャ…………………………………………………4

第 2 章 システムを構成する要素技術と各々の現状…………………………………………10
2.1 要素技術 1: 様々なものを通信ネットワークに接続する技術………………………10
2.2

要素技術 2、4: 実世界の状況をセンシングする技術と制御に基づき実世界に働きかけるアクチュエーション技術…………………………………………………15

2.3 要素技術 3、5: ビッグデータによる高度な制御と、そのためのデータベース構築
に関する技術……………………………………………………………………………17
第 3 章 HEMS……………………………………………………………………………………24
3.1

HEMS の目的……………………………………………………………………………25

3.1.1

目的 1) 電力削減: 総量削減

3.1.2

目的 3) 非常時への対応……………………………………………………………26

3.1.3

目的 4) 投資…………………………………………………………………………27

および

目的 2) 電力削減: ピーク削減……25

3.2

システムを構成する機器の種類システムを構成する機器の種類…………………28

3.3

制御の範囲………………………………………………………………………………29

第 4 章 現在の状況および今後に向けて………………………………………………………35
4.1

補助金を利用した導入は実際に進んだ………………………………………………35

4.2 ECHONET Lite 対応機器のメーカーが増えた………………………………………37
4.3 政策的には HEMS 構築は終わり次のサービスへ……………………………………38
4.4 HEMS 関連機器はより汎用、コンポーネント化へ……………………………………39
4.5

パーソナルデータの扱いが大きなテーマに…………………………………………40

4.6

稼働し続けることが求められる時代に………………………………………………41

あとがき…………………………………………………………………………………………43

第１章

ホームネットワークとは何か

ホームIoT、スマートホーム、スマートハウス、レジデンシャルICT、ホームICT、コネ
クテッドホーム、デジタルホーム、ホームネットワーク、電脳住宅、ホームオートメーシ
ョン、など、過去に様々な呼び方がなされてきたが、何れも情報技術や通信技術を用いて人々の日常生活をより豊かで安心・安全なものとするとともに、こうした生活を持続可能なものとしていこうとするシステムであることは共通している。本報告書では、こうしたシステムを総称してホームネットワークシステム、あるいは単にホームネットワークと称することにする。

本章では、まず、ホームネットワークとはどのようなものであり、どのような構成要素から成るかについて述べることとする。

１．１ ホームネットワークのサービスとアプリケーション
ホームネットワークシステムは家庭内のあらゆるニーズに対してICT(情報通信技術)を用いたソリューションを提供しようとするものであることから、多種多様なサービス分野をカバーする必要がある。これらのサービスには以下の様な種類がある。

(1). 負担軽減型
家事労働のような、人間にとって面倒であったり、負担となるような作業について、容易にしたり肩代わりしたりすることにより、負担軽減を図る類のサービス。いわば、日常におけるマイナス面をゼロに近づけるもの。

(2). 娯楽教養提供型
オーディオビジュアルコンテンツの視聴や、ゲーム、あるいは家庭における習い事など、新たな楽しみや自己啓発をもたらす類のサービス。いわば、日常生活に新しいプラスの何かをもたらすもの。

(3). 環境負荷低減型
個人単位でのメリットというよりは、CO2削減や廃棄食料の削減による地球環境保全といった人類全体としての課題への取組みを支援する類のサービス。これは、他のサービスと相反することが多く、いかにバランスをとりながら実現していくかが問題となる。実際には個人としてのメリットが出なければ使われないため、補助金で初期投資を軽減した上で売電による金銭的な見返りを実現するようなケースが多い。

1

(4). LCP(Life Continuity Plan)型
通常の生活を継続するために必要となる条件を整える類のサービス。電力の供給や、暖冷房、換気、飲料水や食料の保存、緊急情報の家族への通知、家族の緊急状況の外部への通知など、平常時には何も行わないが、災害や火災、急病などの際に必要とされるもの。

こうした分類は厳密なものというよりも、目的が異なるサービスが存在していることを認識するために列挙したものと考えた方が良い。一つのサービスで複数の種類にまたがるものも当然ながら存在してくる。一方で、技術的な要求要件での分類も可能である。一つのサービスを実現するためには複数の機能が必要となることは珍しくなく、ここでは、複数の「アプリケーション」で「サービス」が実現されていると表現することにしよう。技
術的な要求要件はこのサービス単位にかかってくることが通常で、以下の様な種類が挙げられる。

A. 制御系
センサデータを収集したり、制御コマンドのための情報(単体の情報量は少ないことが多い)をやりとりすることが中心となるアプリケーション。

B. コンテンツストリーミング系
映像や音声、あるいは、時々刻々と変わるセンサの値のように、連続性を持ったデータを時間軸に沿って伝送することが中心となるアプリケーション。映像音声の場合、コンテンツの権利保護の仕組みが必要となることが多い。

C. メッセージ伝送系
メールやWeb、SNS(Social Networking Service)のように、ある程度まとまったサイズのデータをやりとりするアプリケーション。情報のやりとりする時間間隔は秒単位から日単位まで様々であり、同様に、一度に伝送する情報量も数十Byteから数M Byteまでバリエー
ションがある。情報が欠けたり失われると問題になることが多い。

D. バルクデータ伝送系
AVコンテンツや機器のファームウエアなど、サイズの大きなデータを主にダウンロード
するアプリケーション。

2例えば、現在の代表的なホームネットワークシステムであるHEMS(Home Energy
Management System)の場合には、基本的には(3). 環境負荷低減型のサービスで、場合によっては蓄電池を装備することにより、(4). LCP型サービスの性質も有することになる。また、一部の製品においては、家中の照明やエアコンを一箇所で制御したり、あるいは時間になると自動的に制御したりすることにより、外出時や帰宅時などに行わねばならない作
業量を減らすという意味で(1). 負担軽減型の性質を持つ場合もある。HEMSの通信は典型的なA. 制御系であり、現在のHEMSのように家庭内のセンサや制御対象機器の数が極めて少ない状況においては通信の頻度もデータ量も極めて少ないアプリケーションといえる。
しかしながら、もともと価格に対する制約の強いセンサや白物家電を対象とせねばならな
かったり、配線の容易さが求められたりするといった事情もあり、IEEE802.15.4ファミリのような低速無線通信が使われることが多い。

一方で、家庭内での AV コンテンツの共有を行なう DLNA(Digital Living Network
Aliance)の場合を考えれば、サービスの性質としては(2). 娯楽教養提供型であり、システムのつくりとしては、B. コンテンツストリーミング系を主軸に、制御などにおいて一部 A. の要素も有するアプリケーションとなる。こちらは、通信速度が重要となるため、有線のEthernet(IEEE802.3 ファミリ)で接続することが基本となる。設置場所の問題や、家庭内を移動しながらの利用など、無線が必要な場合には接続高性能な無線規格であるIEEE802.11 フ ァ ミ リ が 使 わ れ る 。 何 れ の 場 合 に も 、 コ ン テ ン ツ 保 護 を 実 現 す る
DTCP-IP(Digital Transmission Content Protection over Internet Protocol)技術が使われる 。 ま た 、 部 屋 間 の 接 続 で は な く 同 じ 部 屋 の 中 で の AV ネ ッ ト ワ ー ク に は 、HDMI(High-Definition Multimedia Interface)や IEEE1394 が用いられる。これらは、DLNA とは異なった技術で同等の機能を実現するだけでなく、極めて低い遅延での接続を可能とし、テレビと録画機が一体となって動作しているような操作感を実現することができる。

3

１．２ ホームネットワークのアーキテクチャ
このように目的や技術要件が異なるシステムが存在するのがホームネットワークの本質的な難しさである。いわば、ホームネットワークシステムの中に、異なる目的のために異なる技術で構築された複数のサブシステムが存在しているような形となっている。しかし、このサブシステムは全く独立して導入、実装されるべきものではない。その理由は主に3点ある。

第一に、これらのサブシステムはユーザーからみれば互いに連携することが本来自然であるからである。たとえば、現在は機器単体の機能として実現しているタイマー機能がネットワーク化されたことにより一つのUI(ユーザーインタフェース)機器から設定できるようになったとき、これがエアコンなどの白物家電群、電動カーテンや照明などの住設機器群、テレビなどのAV家電群と、全く独立して実現されているといった状況は、ユーザーにとってはかなりの違和感を感じるものとなろう。特に、AV家電は大きな高解像度画面にス
ピーカ、それからユーザーの使い慣れたリモコン、更には機種によってはUSBのキーボード・マウスといった高度なUI要素を持っており、他の機器においてもこの機能を活用するのが自然である。UIにスマホやタブレットを用いる場合も同様で、それぞれのサービス領
域ごとにアプリケーションが別々という形ではなく、家にあるもの全てをトータルに設定できるようになっている形が自然である。

第二に、異なるサブシステムを構成する要素には重複があり、これらをまとめずに設置することは現実的ではないことに加え、システムのトータル価格を抑えるためにも極力共用する部分を増やす必要があるためである。例えば、各種の機器を制御するコントローラのようなものはひとつにまとまっている方がよく、同じような箱型の装置が多数並んだり、似たようなタッチパネル装置が壁面にずらりと並んだりするような状況は受け入れられないものであろう。コントローラやタッチパネルディスプレイを様々なサービスで共有でき
れば、サービスごとにかかるコストが下がることになり、実用化の点で望ましい。後述するように、それぞれのサービスは家庭内にある機器のみで実現されるのではなくクラウド
内のサービスにも依存するため、このクラウド内のサーバーを個別に用意するのではなく共有することで削減できるコストは更に大きくなる。

第三に、それぞれが密に連携することで実現可能となるサービスが多数あり、これらが将来的にも有望なビジネスになると考えられるためである。たとえば、HEMSと見守りの類似性はしばしば指摘されるところである。HEMSではエネルギーの消費状況を把握する

4

ことで利用者にアドバイスを提供したり制御を行なったりするが、ここで利用しているデータは人間の活動状況そのものともいえ、一人暮らしの高齢者がいつも通りの生活をしているかどうかを判断するデータとしても活用が可能である。もちろん、重複するセンサを設置することも可能であるが、それは上記の第二の理由により望ましくない。また、最初から目的を決めてセンシングを行なうだけでなく、様々な目的でセンシングしているデー
タを組み合わせることで新しいサービスが提供できるようになる可能性は極めて高い。家
庭内においても、照明のOn/Offをする機能をエネルギーマネジメントの観点からだけでな
く、緊急地震速報の際などに住人に警告を与える手段として利用するなど、サービス分野間の連携は極めて意義深いものと考えられる。

以上のように、複数の異なるサブシステムが連携してシステムを構成する必要があることを明示的に述べた国際標準規格がITU-T J.190[2]である。その概要を図1.1に示す。

J.190は、1999年から2004年まで活動していた日本の宅内情報通信・放送高度化フォーラム(通称宅内フォーラム、英語名称Digital Homenetwork Forum: DHF)の成果である「宅内フォーラムアーキテクチャ」にもとづき、ITU-T SG9で標準化が行われたものである。宅内フォーラムアーキテクチャそのものについては、宅内フォーラムの発行した標準文書「DHF-STD-001システム管理規定」に記載されているが、現在ではこの文書は一般には入手が難しくなっている。しかしながら、当時の宅内フォーラムのメンバで執筆した専門書[11]が存在し、主要な内容についてはこちらで入手することが可能である。国際標準化にあたっては、ITU-T内でもCATVシステムを所掌するSG9において作業が行われたため、2002
年に最初の版が国際標準となった際には、「Architecture of MediaHomeNet that supports cable-based services」のように、CATVに関連した名称がつけられたが、我が国としてはCATVに限らず、一般的なホームネットワ
ークアーキテクチャをあらわすものとして考えていたため、2007年の改版の際に、「Architecture of MediaHomeNet」と改題している。

5

図 1.1 ITU-T J.190 ホームネットワークアーキテクチャ
図1.1をみても明らかなように、J.190のスコープは家庭内である。左端が広域ネットワー
クで、右端が端末である家電機器群や住宅設備群となる。J.190ではドメインとプレーンという2つの分類概念を導入している。図の中央から左側と右側では異なる色に塗り分けられているが、この区分がドメインである。図の下方に矢印で示したように、左側半分はIP(インターネットプロトコル)を使う「IPドメイン」、右半分が、特定領域プロトコル(proprietary
protocol)を使う「特定領域プロトコルドメイン」である。特定領域プロトコルドメインの方にはIPも記載されているが、これは、機器が直接IP接続されているような場合を示している。一方、右半分で、AV plane、PC plane、TEL/FAX plane、Home appliance plane、
Other planesと縦にならんでいるものが、サービスの分野を示すプレーンという概念である。AVプレーンでは、テレビや録画機を始めとしたAV機器が存在しており、くらし環境プレーン(Home appliance plane)では、エアコンや冷蔵庫といった白物家電が含まれている。
一番下のOther planesは複数になっているのでもわかるように、その他、様々なプレーンが存在しうることを示したものである。

6

J.190では、本章でも述べてきたようにサービス分野によって必要とされる技術的要求要件が大きく異なることから、まず、これらをプレーンという形で分類し、更に、それぞれのプレーンでは利用されるプロトコルや伝送技術が異なっていて、個別の独立したサブシ
ステムを形成するような部分が存在する、ということを特定領域ドメインとして明示的に示している。一方で、家全体のホームネットワークシステムとしての統合や、外部ネット
ワークとの接続についてはIPが使われることから、共通プロトコルとしてのIPで接続されるIPドメインが存在することを同時に示している。特定領域プロトコルとIPとの何れにも対応できる機器は両側のゲートウェイ的な役割を担うものと期待され、これらの機器をHC(Home Client Class)と呼んでいる。家電や住宅設備そのものはHD (Home Device/Decoderclass)と呼ばれ、家庭と広域ネットワークを接続する機器、一般的にはホームゲートウェイが相当するが、これらはHA (Home Access class)と呼ばれる。IPドメインにおいて伝送媒体を変換する、例えば無線LANアクセスポイントのような装置をHB (Home Bridge class)と呼び、HA, HB, HC, HDと語呂の良い機器分類を行なっている。なお、HDがHome
Decoder classと呼ばれるのはCATVでの映像伝送システムの規格としての性質を受け継いたものであったが、ホームネットワークの趣旨としてはより一般的なDeviceのクラスと考えるのが妥当である。また、アクセスネットワークからの入り口がAVプレーンに限って複数存在しているのは放送波を受信するチューナーがこのプレーンには含まれることを示しており、これも放送システム的な概念が反映されたものである。

J.190の示すホームネットワークアーキテクチャは家庭内をモデル化するものとして現在でも有効であるが、次の章で述べるように、現在のホームネットワークシステムは家庭内のみに留まるものではなく、インターネットなどの広域ネットワーク内のクラウドサー
ビスに依存するようになっている。

こうした状況を受け、クラウドも含めた全体アーキテクチャを示す新たな国際標準規格
が2015年1月に勧告となった、「ITU-T Y.2070 Requirements
and architecture of home energy management system and home network services」[3]である。図1.2にアーキテクチャの概要図として同規格内の(a)と(b)を示す。図1.2では、HGWの右側が家庭内、左側が広域ネットワークとなっている。左側がApplicationとManagement
PFという二階層になっている理由は第二章で述べるが、サービスそのものを実現するための仕組みと、それを稼働させるための共通部分も含めた基本的な仕組みがクラウド側に存在している形になっている。

7

P-H1

(a)
IP Basic
DeviceApplication

P-D

P-N

P-A

Adapter

Application

IP
Network

Management
PF

HGW

Application(b)

Non-Basic
DeviceP-H2(c)

Non-IP
Basic
Device(d)

P-D
Non-Basic
DeviceInside the home (HN)

Outside the home (WAN)(a)

HEMS based on HN service architecture

Device Operation

Application Execution
Applications
Home energy
managementHome
security

Applicationinterface

Healthcare

WAN

Management
applications

Management

Application interface

Management PF

HGW

DeviceApplication
for disconnect

Applications
management
VirtualdeviceCommand

Data format
conversion

CommandDeviceobjectHTTP
processing

WAN

HTTP/IPconversion

IP HN

IP packets
processing

Management

Resource info.
collector

Management

Managedagent

Resource
management

Management(b) Functional architecture for IP based basic device

図 1.2 ITU-T Y.2070 にみるサービスプラットフォーム型の
ホームネットワークアーキテクチャと参照点
家庭内においてもJ.190とはやや異なる観点での記述がなされている。Y.2070ではその名称にもあるように、サービスとしてHEMSを主眼に置いた構成となっているため、基本的には前述の制御系のアプリケーションを想定して記述されている。これらのアプリケーシ
ョンにおいては、機器を制御するコマンド体系や機器自体の持つ変数(状態)といったモデルがある程度のレベル感で統一されている必要がある。Y.2070では日本のECHONET規格[9]を念頭に置き、機器側が基本的な機能を備えている場合、それらを基本デバイス(Basic
Device)と呼んでいる。インテリジェンスを持たない機器はアダプタを経由して同レベルの機能を備えた上で基本デバイスと同等に扱われるようになる。また、接続形態については、

8直接IP接続される場合、ホームゲートウェイから何らかの非IPネットワークで接続される
場合、ホームゲートウェイと直接接続され、ホームネットワーク内にアダプタ相当の機能が実装されていて、広域網からみれば基本デバイスとして扱えるような場合など、各種のパタンに対して参照点の名称を与えている。これらは、J.190が制定された時代と比較して、商品化が進んでいる状況を受け、より実際のシステムとの整合性を重視した結果だといえる。

このように、ホームネットワークでは全体像を整理するためのアーキテクチャに関する標準化が進められており、こうした成果を活用することで、様々なシステムをより容易に理解できるようになるとともに、各種の技術の接続点を明確にすることで技術の積み上げが可能となる。実のところ、ホームネットワークのアーキテクチャについては、ITU-T の
規格についてだけでも、ここで述べた J.190 と Y.2070 以外にも多数の規格が存在する。しかしながら、それらはどちらかというと、特定の観点、例えば伝送規格やセキュリティといった視点からのアーキテクチャであり、J.190 と Y.2070 はシステムの全体像を整理しようとするアーキテクチャとして存在意義は大きい。

9

第2章

システムを構成する要素技術と各々の現状

ホームネットワークに限らず、最近の「スマート」なシステムは、実世界とのインタラ
クションを有する。つまり、実世界の状況を把握し、その情報に基いて何らかの情報処理をし、その結果として実世界の状況に変化を与えるような働きかけをする。こうしたシス
テムは我が国では「ユビキタス」という用語で呼ばれていたが、近年になってM2M(Machine
to Machine)、IoT(Internet of Things)、CPS(Cyber Physical Systems)など、新たな用語でも呼ばれるようになっている。

こうした実世界とのインタラクションを伴う近年のシステムにおいては、以下の5つの構成要素が必要となる。

要素技術1 様々なものを通信ネットワークに接続する技術
要素技術2 実世界の状況をセンシングする技術
要素技術3 センシングした情報と過去のデータベースおよび外部からの情報にもとづいて制御する技術
要素技術4 制御に基づき実世界に働きかけるアクチュエーション技術
要素技術5 一連のデータをデータベースに蓄える技術

従来の組込みシステムでは、要素技術1によって構築されたシステムにおいて、要素技術
2でセンスした情報にもとづき、要素技術3として多くの場合はROM(Read Only Memory)
内に書き込まれたプログラムによって次のアクチュエーションのしかたを決定し、要素技
術4で物理的な作用をし、再び要素技術の2でのセンシングに戻る、というループ構造で動いていたが、現在のスマートなシステムは、2.3節で後述するように、要素技術3での処理にデータベースの参照と、外部からの情報に基づいた情報処理を行なうようになっている。
そのためにはデータベースを構築する技術が必要となり、要素技術5が求められるようになった。

以下に、ホームネットワークにおけるこれらの要素技術の現状について述べる。

２．１

要素技術 1: 様々なものを通信ネットワークに接続する技術

要素技術1は、システムを構成する様々な機器を情報通信ネットワークで相互に接続するための技術である。これは、いわばシステムを現実のものとして実用化するためには最も基本的に必要となる技術であり、理論的な検討や実験環境のみを対象とした場合には必ず10

しも重要ではないかもしれないが、実用化にあたっては極めて重要な要素技術といえる。
実のところ、1970年代から始まるホームネットワークの研究の初期においては家電や住宅設備でも利用可能な通信媒体とそのプロトコルを開発することが中心的な課題であった。
専用の媒体を用いる技術や無線技術のみならず、電力線や電話線のような既存の配線を活用する技術の開発が盛んに行われてきた。というのも、新規の配線の敷設はどのようなシステムにおいてもコストの増大を招くものであるが、特に、ホームネットワークのように一般ユーザーが逐次機器を追加購入して構築していくことが想定されるシステムにおいては、新規の配線作業を行わないで済むというのは極めて重要な性質となるためである。

各種の技術とも概ね20世紀中にはひと通り姿を現し、その後も高度化と標準化が継続している。このような長い歴史を有するだけに成果も上がっており、現状のシステムでは様々な技術が利用可能となっている。特に、我が国ではHEMSの分野においては2012年ごろか
ら経済産業省や総務省など政府が後押しをして推奨技術のリストアップを行なうとともに、それぞれの運用規定を業界団体でまとめたことから、極めて明確に整理された状況になっている。これには、HEMSで使う機器制御のアプリケーション層プロトコルとして、元々日本の規格であるECHONET Lite[9]を活用するという方針が決まったこと、更に、
ECHONET Lite規格では従来のECHONET規格とは異なり、伝送メディア、つまり、
ECHONETの電文(パケット)をやりとりするための物理層からトランスポート層までの規格については規格の対象外とするという方針が打ち出されたことを受け、この伝送メディ
ア部分にあたる通信規格部分を別途整理しようとする流れになったという事情がある。

図2.1にTTC(一般社団法人情報通信技術委員会)発行のテクニカルレポートとして公開されている「TTC TR-1043 ホームネットワーク通信インタフェース実装ガイドライン」[7]に記載されている通信技術一覧を示す。このガイドラインは新世代ネットワーク推進フォーラムレジデンシャルICT SWG[8]において議論を行い、TTCにて文書化したもので、後述
するECHONET Liteプロトコルが実装可能な伝送技術のうち、実際に実装されて商用化される見込みのある技術を概説している。このガイドラインにはアドレスやパラメータ類など実装に必要な最低限な情報はまとめているが、規格そのものは原典を参照することとし、また、立ち上げの手順や暗号化など、相互接続性を有する実装を行なうために必要な情報は別の文書としてまとめることとしている。実際に、東京電力のスマートメーターで使われている実装に関しては、「TTC TR-1052 HEMS-スマートメーター(Bルート)通信インタ
フェース実装詳細ガイドライン」に記述されている。なお、TTCの文書はWebサイト[6]から無償でダウンロード可能である。

11

図 2.1 TTC TR-1043 に記載されている通信技術
TTC TR-1043は図2.1でも明らかにように、上位層としてECHONET Lite規格を用いる
ことを前提としているが、間にIP層を挟んで実装する場合と、データリンク層に直接ECHONET Liteを載せる場合の両方がありうる。しかし、理論的にはどの媒体であってもデータリンク層直接の実装は可能であるが、実際には無線の一部の規格でしか製品化する目的での標準規格づくりが行われていないため、図2.1の右端に現れるのみとなっている。
TR-1403は常にアップデートされているため、今後、例えばEthernetフレームの上に直接
ECHONET Liteを載せる実装が実用化されるような動きがあればそれを受けて更新されることになる。

図2.1をみてもわかるように、伝送媒体として専用の通信線を用いるものは既に広く普及しているEthernetに限られ、それ以外は既存配線である電力線と、無線が使われていることがわかる。また、Ethernetと「みなしEthernet」として扱える高速な伝送媒体である、
ITU-T G.hn、IEEE1901、Wi-Fi、Bluetoothにおいては旧来のECHONETでも用いられてきたIPv4やIPv6の実装がそのまま踏襲されている。一方で、近年になって開発されてきた
ITU-T G.hnemやIEEE802.15.4においては
6LoWPAN(IPv6 over Low power Wireless Personal Area Networks)という技術を用い、IPv6を載せるようになっている。これは、これらの新しい通信技術では超低消費電力を実12現するために伝送できるデータのサイズが限られているなど制約があり、そのままでは
TCP/IPプロトコルを載せることが困難であるが、6LoWPANという技術がこれを可能としているという事情による。現状は、Wi-FiやBluetoothなどの旧来型の技術が多く使われているが、今後は、この6LoWPANを用いる新しい技術群が中心となることが予想される。

図2.1の下、表の欄外には、関連する規格の名称が記述されている。ここで、同じ技術に複数の名称が書かれているのは、一つの技術が、異なる目的のために複数の規格を有するためである。例えば、ITU-T G.9903の場合には、ITU-Tで標準化された際のプロジェクト
名(規格番号が決まるまでの名称)がITU-T G.hnemであり、元々、この技術を推進している
民間団体がG3-PLC、日本国内で利用するための規格を定めているのがTTC JJ-300.11という位置づけになる。IEEE802.15.4ファミリについては事情はもう少し複雑で、旧来からあるIEEE802.15.4規格と、スマートメーターなどのSmart Utility Network(SUN)向けに拡張されたものが、IEEE802.15.4g(物理層規格)およびIEEE802.15.4e(データリンク層規格)である。IEEE802.15.4が開発されて以来、その上位層の規格を制定する民間団体として
ZigBee Allianceが存在していたが、IEEE802.15.4e/gが開発された後はこれらの拡張規格を主に開発してきたメーカーによるWi-SUN Allianceが設立されており、この2つの民間団体が基本的には同一の規格を用いて市場で競合する形になっている。IEEE802.15.4e/gや
6LoWPANではパラメーターやオプションが多く、これらが異なれば互いに通信することはできない。こうした部分の取り決めを行なっているのがZigBee AllianceやWi-SUN
Allianceという位置づけになる。従って、規格上は同じIEEE802.15.4e/gであっても、ZigBeeとWi-SUNの製品の間には相互接続性は存在しないわけである。

TTC TR-1043はECHONET Liteに向けてのガイドラインであるが、大多数の制御系のア
プリケーションにおいてはここであげた技術がそのまま利用可能である。特に、HEMS用
途向けのネットワークアダプタの製品数がここ1,2年で急速に増加し、価格も著しく安価になりつつあることを考えると、このECHONET Lite向けに整備された通信技術はHEMS以外の他の用途へも転用が期待される。一方で忘れてはならないのは、センサや白物家電、住宅設備など、元々は強力な計算機の機能を有していなかった装置に用いられる「組込み系」のネットワークでは、ECHONET Liteの例のように上位レイヤと下位レイヤでの組合せが複数存在するようになったのは比較的珍しく、通常はデータリンク層の上に直接特定のアプリケーション用プロトコルが載るという点である。物理層とデータリンク層はチッ
プとしてハードウエアで実装されるのが普通であり、これらの層の機能をフルに使って目的のアプリケーションを実現するためのプロトコルを規格化し、その実装にあたっては

13

ROMの中に焼きこんでしまうという形をとる。この特定アプリケーションのためのプロト
コルを「プロファイル」と呼び、例えば、ZigBeeでは、
SE: Smart Energy
RF4CE: Remote Control
HA: Home Automation
HC: Health Care
TA: Telecom Servicesなど、多数のプロファイルが存在している。プロファイルが異なる機器間の通信は行えず、一つの機器が多数のプロファイルを有しているような実装が行われることもある。組込み系のネットワークである、BluetoothやIEEE1394も同様に多数のプロファイルを有している。また、これらのプロファイルの中の一つとして、TCP/IPを載せるためのプロファイル
を有しており、TTC TR-1043でみた例ではこうしたIP通信のためのプロファイルが用いられている。実のところ、2000年前後にECHONETコンソーシアムにおいて通信メディアとしてBluetoothの導入が議論された際、当時の状況としては新しくECHONETプロファイルを定義して直接載せる方法がいわば常識的な方向性であったが、敢えてここに
PAN(Personal Area Profile)を用いてTCP/IPのプロトコルスタックを載せ、その上で
UDP/IPで通信するという方針をとった。これがその後の伝送媒体ごとの詳細をIPで隠ぺいする方向性へとつながり、ECHONET Liteの設計の際には規格から切り離してしまうとい
うところにまで至ったわけである。下位レイヤとして使える技術規格が整備されてくるのに連れてIPを導入して上位レイヤと下位レイヤの自由な組合せを可能とする方向性の現れといえるが、一方で、厳密な相互接続性を要求したり、実装上の無駄を排除してコストを下げたり、あるいはデータリンク層までが持っている通信機能を活用するためには、プロファイルを用いた従来型の組込み系ネットワーク技術がより適していることもある。

本報告書ではHEMSを中心とした制御系アプリケーションに焦点を当てているため詳細は省くが、映像や音声を伝送するコンテンツストリーミング系においては通信速度や通信品質が要求されるとともに、コンテンツのプロテクションメカニズムが必要とされることから、ここで述べた技術とは異なるものが必要とされる。古くにIEEE1394、最近ではEthernet AVBといった技術があるものの、家庭内向けにおいては価格が重要視されることから実際には採用に至るケースは多くない。一方で、安価にするために複数機器のネットワーキングというよりは一対一の機器接続のリンク技術が開発され、使われている。HDMI
はその典型的なものであり、PCのディスプレイを接続するデジタルインタフェースである

14

DVI(Digital Visual Interface)をベースにAV機器接続に必要なコンテンツ保護機能と制御機能を追加したもので、10Gbpsにも至る高速伝送を極めて安価に実現している。

２．２

要素技術 2、4: 実世界の状況をセンシングする技術と制御に基づき実世界に働きかけるアクチュエーション技術

前述のように、スマートなシステムではセンシングによる実世界の情報の取得と、アクチュエーションによる実世界への働きかけが必要となる。センサやアクチュエータそのものの技術はメカニカルやケミカルなものであり、それぞれの分野での技術開発が続いているが、ネットワークの観点からは、これらをシステムの一部として利用できるようにする
ため、アプリケーションプログラムからみたアクセスの方法、つまりプロトコルと、そのときに使うデータの構造を決める必要がある。

HEMSの分野において、これらの要求に対する解決法を与えたのがECHONET規格である。ECHONETは1990年代末に開発が始まった際には伝送媒体などについても規定していたが、本質は家電や住設機器をモデル化してデータ構造を決め、それらに対してアクセスするための手順であるプロトコルを決めたところにある。ECHONETでは2003年に製品化がなされた時点で既に独自の伝送媒体は利用されておらず、Bluetooth、Ethernet、Wi-Fi
といった既存伝送技術を採用しており、2011年にECHONETの後継規格としてECHONET
Liteが制定された際には、前節のTTC TR-1043でみたように、完全に他の標準化団体で開発された通信技術を利用する方針がとられている。一方で、データ構造にあたる「機器オブジェクト」については完全に継承されており、そのアクセスプロトコルも改良は加えられたものの、基本的な考え方は踏襲している。

現在、HEMSにおいてはECHONET Lite規格に沿った機器を利用することで、メーカーに関係なく同じ手順で同じデータ構造での機器アクセスが可能となっており、機器を製造する側からすればアプリケーションまで考えなくてもECHONET Lite対応の機器ということで製品を市場投入することが可能となり、また、システムを構築する側にとっては、ソフトウエアを変更することなく、センサや機器を変更することが可能となっている。また、
前節で述べたように、それらの間を接続する伝送技術には多くの選択肢があるため、その状況に合わせた媒体を選ぶことが可能である。

図2.2にECHONETおよびECHONET Liteで定義されている機器のリストを示す。
ECHONETでは、機器はオブジェクトとしてモデル化され、そのプロパティをECHONET

15

プロトコルで読み書きすることでアクセスする。例えば、温度センサであれば、0xE0というコードの割り当てられたプロパティの値が温度を示しており、2Byteでsigned short型のデータとなっている。その値域は0xF554から0x7FFEとなっており、これは10進では-2732
から32766の値となるが、単位が摂氏0.1度となっているため、-273.2℃から3276.6℃の値を表すことになる。これにより、ECHONET準拠の温度センサはどのような原理のものであってもアプリケーションソフトウェアから見た利用のしかたは同一にすることが可能となる。

センサ関連機器クラスグループ

ガス漏れセンサ, 防 センサ, 非常ボタン, 救急 センサ, 地震センサ, 漏電セン
サ, 人体検知センサ, 来客センサ, 呼び出しセンサ, 結露センサ, 空気汚染センサ,
酸素センサ, 照度センサ, 音センサ, 投函センサ, 重荷センサ, 温度センサ, 湿度
センサ, 雨センサ, 水位センサ, 風呂水位センサ, 風呂沸き上がりセンサ, 水漏れセンサ, 水あふれセンサ, 火災センサ, タバコ煙センサ, CO2センサ, ガスセンサ,
VOCセンサ, 差圧センサ, 風速センサ, 臭いセンサ, 炎センサ, 電力量センサ, 電流値センサ, 水流量センサ, 微動センサ, 通過センサ, 在床センサ, 開閉センサ,
活動量センサ, 人体位置センサ, 雪センサ, 気圧センサ

空調関連機器クラスグループ

家庭 エアコン, 換気扇, 空調換気扇, 空気清浄器, 加湿器, 電気暖房機, ファン
ヒータ, 業務 パッケージエアコン室内機, 業務 パッケージエアコン室外機

用

機器
犯

クラスグループ

用
用

用

用

玄

電動ブラインド・日よけ, 電動シャッター, 電動雨戸・シャッター, 電動ゲート, 電動
窓, 電動 関ドア・引き戸, 散水器（庭 ）, 電気温水器, 電気便座（温水洗浄便
座・暖房便座など）, 電気錠, 瞬間式給湯機, 浴室暖房乾燥機, 住宅 太陽光発電, 冷温水熱源機, 床暖房, 燃料電 , 蓄電 , 電気自動車充放電器, エンジン
コージェネレーション, 電力量メータ, 水流量メータ, ガスメータ, ＬＰガスメータ, 分
電盤メータリング, 低圧スマート電力量メータ, スマートガスメータ, 高圧スマート
電力量メータ, 一般照明, 単機能照明, ブザー
電気ポット, 冷凍冷蔵庫, オーブンレンジ, クッキングヒータ, 炊飯器, 洗濯機, 業務
シューケース, 衣類乾燥機, 洗濯乾燥機, 業務 ショーケース向け室外機
体重計
スイッチ(JEM-A/HA端子対応)
ディスプレー, テレビ, オーディオ, ネットワークカメラ
用

用

・家事関連機器クラスグループ
理健康関連機器クラスグループ
管 ・操作関連機器クラスグループ
ＡＶ関連機器クラスグループ

用

理
調

池

池

住宅・設備関連機器クラスグループ

14.09.03 Appendix Rel.F

図 2.2 ECHONET にみるセンサ、アクチュエータオブジェクト
ECHONETのオブジェクトには複雑なものもあり、エアコンでは45個におよぶプロパテ
ィが存在する。これは、元々ECHONETにおいては本体付属のリモコンでできる機能はすべてネットワークからも利用できるようにすべく、ECHONETオブジェクトでは、市販されている製品の機能が網羅できるようにプロパティを追加してきたことによる。現実の製品においての実装は必ずしもすべての機能がネットワーク側からのアクセスに対応するわけではないが、主要なプロパティは必須プロパティとして実装が義務付けられているため、どのメーカーの製品であっても基本的な制御は可能である。

16

HEMSの用途においては、単純な見える化のようなものから、燃料電池や蓄電池の運転タイミングの制御まで、様々なアプリケーションが実現できるだけのオブジェクトが規定されている。但し、実際の製品としてECHONETが実装されているものは温度、湿度、照度などの代表的なセンサやエアコン、照明関連機器に集中しており、すべての種類の製品が容易に入手可能な状況に至るには今しばらくの時間を要するが、2012年以降の製品の増加ペースには目覚ましいものがあり、そう遠くない将来に状況は変わるものと期待される。
特に、スマートコミュニティアライアンスで指定された重点8機器(スマートメーター、電気
自動車充電器、エアコン、照明、太陽電池、給湯器、燃料電池、蓄電池)についてはECHONET
オブジェクトの規格整備も迅速に行われ、製品開発が進められている。

このように、HEMSという領域においてはセンサとアクチュエータのモデルとアクセス方法に関する標準ができあがっており、センサやアクチュエータそのものの技術が進展す
れば、すぐにそれらを活用できる素地ができている。前節の場合と同様、ECHONET規格のセンサやアクチュエータはHEMSに用途が限られるものではなく、オブジェクトの定義
が目的に合致していれば、その他の用途においても流用は可能である。実際、植物工場に
ECHONET機器を転用し、従来よりもはるかに低価格なシステムを構築している例[27]な
どがある。

２．３

要素技術 3、5:

ビッグデータによる高度な制御と、そのためのデータベース構

築に関する技術
残る2つの要素技術は互いに関連が深い。CPSではセンシングした情報にもとづきアクチ
ュエータの制御を行なうが、その制御の技術が要素技術3となる。従来型の制御であれば、センシングした値にのみ基づいて制御を行なっていたが、近年のシステムはそう単純な制御ではなく、クラウド側の情報処理機能と連携しながら制御を変えてくるようになってきている。たとえば、HEMSであれば、当日一日の気象予測を踏まえ機器の運転ポリシーを変え、たとえ家庭内のセンサの値が同じであったとしても、前日とは異なった動作となる
ような制御を実行する。

このクラウド側の情報処理のためには、現場である家庭内の各センサの値がどのようなときにどう制御すると、結果としてどうなるかといったデータが必要であり、これを蓄積するのが要素技術の5である。このデータはもっぱら学習する専用の期間を特定の箇所に設けて蓄積するというよりは、実際に利用するシステムを稼働させながら蓄積する。システ

17

ム全体の動きとしては、2のセンシングの結果、3の制御を4のアクチュエータで行い、その一連のデータを5として蓄積しておくという流れになる。従来の組込みシステムは2から4を繰り返したのに対し、5という手順を含めた2から5で繰り返しを行なうのが最近のスマートなシステムの特徴といえる。

HEMSにおいては、前節までに述べてきた要素技術が既に確立されつつあるものであるのに対し、本節の要素技術はこれから発展するものであり、現状では標準といえるようなものは存在していない。これは、a) そもそもHEMSとしてどのような動作を行なうべきかというアプリケーションとしてのアルゴリズムの意味で確固とした技術がないということとともに、b) そのアルゴリズムをどのように実装すればよいのかの技術も固まっていないということを意味している。ここでは、後者b)の実装技術についてもう少し詳しく述べることにする。

図2.3に制御およびデータ蓄積を家庭内のコントローラで行なう場合の構成を示す。この構成では、家庭内のコントローラにはすべての種類の機器と通信するためのプロトコルが実装されているのに加え、すべてのアプリケーションもコントローラに搭載されている。
各アプリケーションは必要があればインターネットを通じて情報を得ることもあり、また、
家庭内のセンサや動作履歴などのデータもすべてここに蓄積される。

情報収集
制御
ルータ

コントローラ
図 2.3 スタンドアロンモデル

18

この構成は直感的にみてもシンプルで実現性が高くみえ、実際、1980年代以降現在に至るまで、各種の実験住宅ではこの構成でシステムが構築されている。しかしながら、これを実用化しようとすると非常に大きな困難に突き当たってしまう。というのは、コントローラにおけるソフトウエアがほぼすべての機能を担うことになり、その構築と維持に多大なコストがかかるのである。家庭の中の機器の構成などは住宅ごとに異なるし、中にいるユーザーの世帯構成や嗜好もそれぞれに異なっている。こうしたバリエーションに対応するためには住宅ごとにソフトウエアのカスタマイズが必要となり、そのメンテナンスにも多大な工数を要するようになってしまう。実験住宅のようにひとつ限りのシステムを構築するのであればこのコストは許容されようが、大量生産しようと考えたときには大きな問題となってくる。逆にいえば、このコストを何らかの形で負担できればこの構成は実用的であり、実際、米国などにおける富裕層向けソリューションはこうした形態をとることが珍しくない。

一方、図2.4に我が国の製品やサービスで広くとられている構成を示す。この形態のポイ
ントは、複雑な機能を持つソフトウエアを家庭内のコントローラからクラウドに移した点にある。こうすることで、ソフトウエアのメンテナンス作業は各家庭内のコントローラにおいて行なうのではなく、サーバーの中で一括して行えるものとなる。家庭内コントロー
ラは、各機器と直接通信をする機能を担うとともに、場合によってはローカルで処理をする部分とクラウド内の処理とを分担し、レスポンスの向上やネットワーク切断時のサービ
ス継続を実現する。各家庭ごとに環境が異なる点も、サーバー側で多くの選択肢を用意し、それを組み合わせるような仕組みで吸収することができる。この構成では、家庭内(端末側)に載っていた機能をクラウド側のサービスに移行したという意味で、ASP(Application
Service Provider)型のモデルということができる。パソコンからシンクライアント(内部にアプリケーションプログラムやファイルなどのためのストレージを持たず、ネットワーク
で接続されたサーバー側で処理や記憶を行なう形態の端末装置)に移行するのと同様の効果を期待できるわけである。

19

VOD

制御

サービス
ホームゲートウエイ
HVAC

ASP: Application Service Provider
VOD：Video On Demand
HVAC：Heating、Ventilation、and Air Conditioning

図 2.4 クラウド連携(ASP 型)モデル

現在、図2.4の形態で様々な実サービスが商用化されているが、この構成にも大きな制約が存在する。それは、端末とサービスが垂直統合されている、つまり、家庭内の家電や住設機器と、その特定の製品群を対象としたサービスのコンビ、という形で実現されているということである。図2.4でホームゲートウェイが2台記載されているのに象徴されるように、家庭内に置く家電機器の設計と製造、インターネット内のサービスの開発と運用、さらに、家庭内機器とサーバーとを接続するのに必要な途中の通信デバイスの提供ができて初めてこうしたシステム形態が実現できる。こうした開発ができるのは一部の極めて限られた大企業ということになり、機器のバリエーションもサービスの発展も限られてしまうことにつながる。我が国におけるHEMSサービスも現状はこうした構成となっており、メーカー
ごとに機器とサービスがそれぞれ提供され、エアコンなど、実際にはECHONET Lite準拠
で相互接続性のあるものまでメーカーの縛りを受けているような状況にある。

いくら機器のインタフェースとプロトコルを標準化してもこのようなビジネスモデルでは家庭内のすべての機器を活用したサービスの実現は望めない。これに対し、図2.5のような形態への移行に関する議論が2007年ごろから行われている。

20

図2.5では、家庭内には集約した一つのホームゲートウェイがあり、これがインターネッ
ト等の広域網を通じて通信する相手はサービス自体を提供するサーバーではなく、サービスを実現するための基盤を提供するサービスプラットフォームになっている。典型的な

VOD

サービス

HVAC

制御
顧客情報

ホームゲートウエイ

サービス
プラットフォーム
SPF: Service PlatForm

図 2.5 クラウド連携(SPF 型)モデル
実装では、サービスプラットフォームを運用する事業者は自社の契約する家庭にホームゲ
ートウェイを設置する。このホームゲートウェイは各種の機器と通信できる機能を有するとともに、サービスプラットフォームと連携してサービスを実現できる能力を有している。
一方、サービスプラットフォーム事業者は各種のサービスを提供するサービス事業者に対して自社のプラットフォーム経由でユーザー宅の家電や住設機器を制御するためのAPI(Application Programming Interface)を提供する。サービスプラットフォーム事業者とサービス事業者間はe-Commerce同様のWebサービスインタフェースで接続され、必要に応じて他社のサービスを利用する、いわゆるマッシュアップも行われる。ホームゲートウェ
イ以下の家庭内機器は種類が膨大になる可能性があることから、極力標準プロトコルに準拠した機器の採用を進める。ECHONET Liteのような規格に沿ったものであれば、サービ
スプラットフォーム事業者は機器のメーカーに関係なくこれを利用することが可能である
し、また、家庭内に複数の規格が存在してもサービスプラットフォームのレベルである程
度差異を吸収することが可能となる。たとえばエアコンを冷房の26℃設定で運転というサービス側のAPIに対して、実際にサービスを提供する家庭の中にECHONETエアコンがあればその通りに設定して稼働させるが、HA端子(JEM-A: 日本電機工業会規格で定められている制御端子で、On/Off程度の情報しか扱えないが、ローコストであることから住宅設備などで広く用いられている)でコントローラに接続されているエアコンがあるだけであれば、運転状態にはするが、運転モードと温度の設定はできなかった旨のエラーが返る、といった実装ができる。もちろん、ECHONETやHA端子それぞれに対応した詳細APIを提供する

21

ことも可能であるが、概ね、今朝出掛けに止めたエアコンを出先からONにしたい、という程度の用途であれば統合化されたAPIを利用するほうが合理的である。

また、このサービスプラットフォーム型においては、家庭内のセンサ情報や機器の稼働状況といったデータの蓄積はサービスプラットフォーム側で行なうことが可能となる。パ
ーソナルデータの取り扱いに関する注意は必要となるが、多数の顧客のデータがサービス
プラットフォーム事業者に集中することになり、ビッグデータ解析のためには望ましい状
況が生まれる。解析した結果はより高次の概念を持つAPIを実現可能とする。例えば、エアコンの温度を数値で直接的に指定するのではなく、利用者の住む地域での平均的なエアコン設定温度に設定する、という機能も可能となってくる。もちろん、特定の家庭に対して、その家庭が普段設定している温度に設定する、というAPIも可能であり、サービス提供事業者はひとつのソースコードでそれぞれの家庭で違う動作をするようなプログラムを、サー
ビスプラットフォームの提供するAPIによって実現できるわけである。

サービスプラットフォーム型では、機器側とサービス側が互いに独立して発展できることが大きな特徴である。前述のASP型の場合には機器とサービスを提供する事業者が基本的には同一であったが、サービスプラットフォームで機器が一旦抽象化されるようになると、機器側は標準インタフェースの搭載までを考えていれば、システム内でどのようなア
プリケーションに使われるのかを気にせずに製品開発を進めることができる。一方で、サービス側も実際にどのようなデバイスでAPIの機能が実現されているのかを気にすることなくサービスの開発を進めることができる。これによりそれぞれの開発に対するハードルが下がり、様々な製品やサービスが市場に出回ることが期待される。サービスプラットフ
ォーム事業者自身は、自らが提供するAPIによりサービスが増えれば利用者も増え、利用者が増えればより多くのデータが集まるため、より洗練されたAPIが提供可能となって更にサービスが増える、という好循環を狙うことが可能となる。

しかしながら、現実的にはGoogleを始めとするクラウド事業者が抱える数多くの訴訟や、昨年我が国でも交通系ICカードのデータを巡って巻き起こった議論と一般利用者の感情などを考慮しつつ進める必要があるのに加え、技術的にもシステムの安定稼働や異常時への対応をはじめとし、解決せねばならない課題が多数残されている。そもそもが、どのようなサービスの記述(プログラミング)方法をとるのが良いのか、また、処理やデータはどう分散させるのが良いのか、あるいは、複数のサービスが家庭内のデバイスを取り合うような形になった場合にどう調停するのが良いのかなど、研究レベルのテーマも多数存在してい22る。また、ビジネス的にも、強大なサービスプラットフォーム事業者が中心となって利益を集める一方、機器を提供する側はコモディティ化した製品を価格勝負で提供するような形になってしまっては全体としてのエコシステムがうまく回らなくなる。サービスプラッ
トフォームは対象が国内に限られているわけではないのでワールドワイドな展開も考えつつ戦略を練る必要がある。とはいえ、将来の産業という観点では、これらの課題を克服して一日でも早くこのサービスプラットフォーム型のビジネスを立ち上げる必要性は高いものと考えられる。

23

第3章

HEMS

HEMS(Home Energy Management System:ヘムス)は家庭内のエネルギー関連機器、具体的には、
a) エネルギー消費を計測し、その結果を可視化する機器b) 他の機器を制御する機器c) エネルギーを生成する機器d) エネルギーを蓄積する機器e) 家電や住宅設備などのエネルギー需要機器を通信ネットワークで接続して相互連携させ、家庭のエネルギー利用の効率化をはかった
り、非常時のエネルギーを確保したりするものである。ここでいうエネルギーは、原理的には様々な形態がありうるが、実際には電力と熱(温水などの温熱)がほとんどを占める。

HEMS と類似した用語に BEMS(Building Energy Management System: ベムス)、
FEMS(Factory Energy Management System:

フ ェ ム ス ) 、 CEMS(Cluster/Community Energy Management System: セムス)がある。HEMS が家庭環境を対象としているのに対し、
BEMS はビルを、
FEMS は工場をそれぞれ対象としている。一方で、CEMSはひとつの地域を対象とするものであり、その中に含まれる BEMS, FEMS, HEMS から情報を取得したり、指示を与えたりしながら動作するものとなる。

BEMS や FEMS は HEMS と比べると・ エネルギー消費が極めて大きい・ 自家発電設備を有することが珍しくない・ 多量の排熱を出すことがあるなどの点で違いがあり、電力事業者との契約形態も異なっていることから、システムの構成も利用される技術も異なっている。
特に、HEMS では、・ 設備の導入および運用費用は個人が負担するためコストに対する制約が厳しい
・ システム管理者が不在であるため、日常的な運用においてメンテナンスフリーである
必要がある
・ 全体をみるシステム設計者もいないため、互いに接続されない複数のシステムが逐次導入される可能性が高いといった課題を抱えるため、他のシステムとは少々状況が異なることになる。

24

なお、HEMS という用語は本来はシステム全体を指すことばであるが、我が国においては、HEMS 内のコントローラとなる装置、つまり、前述の a)-e)の機器群のうちの a)と b)を実現する機器自体のことを HEMS と呼んでいる場合があり、注意が必要である。

HEMS という単語は広く認知されるに至っているが、そのバリエーションが極めて多様である点はあまり知られておらず、少なからぬ混乱を招いている。以下に、HEMS の分類について、目的の観点、構成機器の観点、それから制御範囲の観点について、順に述べる。

３．１

HEMS の目的

1.1 節でサービスの種類として HEMS は主に環境負荷低減型ではあるが、LCP 型や負荷軽減型の要素を持つと述べたとおり、HEMS の目的はひとつではない。残念ながら、この事
実は一般的にはあまり認識されておらず、混乱の元になっているように見受けられる。これらの複数の目標は同時に達成できるものとは限らず、むしろ、相反する場合も多い。実際の HEMS においてはこれら全ての観点で総合的に評価するか、実現したい目標を明確に絞る必要がある。以下にそれぞれの目的について述べていく。

３．１．１ 目的1) 電力削減: 総量削減

および 目的2) 電力削減: ピーク削減

多くの消費者が思い浮かべる HEMS の目的は省エネルギーであろう。しかしながら、省エネルギーには利用するエネルギーの総量を減らそうとする総量削減と、ピーク時のエネ
ルギー消費量を削減しようとするピーク削減とがあり、これらは基本的に違うものである
ことはあまり認識されていない。

総量削減は無駄の低減をシステムが実現するもので、人がいない部屋機器を止めるなどの不要な電力消費の削減、換気扇やブラインドとエアコンを連携させるなどの効率的な運転、電力利用状況を利用者に伝える(見える化する)ことによる利用者への省エネ意識の喚起、
燃料電池や家庭用コジェネ設備による熱と電力の効率的な生成などの手段で実現することができ、これらは多くの消費者にとっても理解しやすいものであろう。

一方、ピーク削減は電力システムの性質に依存するもので、必ずしも多くの消費者に知られているものとは言いがたい。電力の供給は、需要の発生と常に同時に行われなければならないため、発電から送配電まで含めた電力系統は、需要のピークに対しても十分に対応できるだけの余力を持たねばならない。ピークの値が平均の値よりもはるかに大きけれ
ば、多くの時間帯において設備は有効に利用されないことになる。また、逆に、電力需要25

の総量が増えてもピークの値が変わらなければ、現在の設備で対応できることにもなる。

ピークを抑えることと、需要の総量を減らすことは基本的には独立である。ピーク時への対応として、以下のような例を考えてみよう。

1) エアコンを止めて外気導入で対処したり、この時間帯に外出したりする
2) IH 調理器や洗濯機、掃除機などの利用を他の時間帯に行なう
3) エアコンをピーク時間帯前に十分稼働させておき、ピーク時間帯は停止する。蓄電池に貯めておいた電力を使ってエアコンを運転する

1)は、ピーク時間帯に電力の需要そのものを削減してしまうものであり、総量削減にもつながる。2)は、需要の時間帯をピーク時からずらす、ピークシフトを行なう。一日を通じて利用する電力は変わらないことから、総量には影響しないことになる。一方、3)ではエネル
ギーを何らかの形で保存しておき、ピーク時には保存されたエネルギーを利用することで電力系統の負担を軽減する。蓄電池は電力エネルギーでの保存であり、エアコンの事前運
転は熱エネルギーでの保存である。3)も家という単位で考えればピークシフトに相当し、むしろ、蓄電池を備えたシステムにおいてはピークシフトと言うと、こちらを指すことの方が多い。しかし、こうしたエネルギーの保存はロスを伴うため、需要の総量は増加することになる。

省エネというと、CO2 排出量や資源保護の観点から総量を減らすことが思い浮かぶが、現状の我が国の状況下においてはピークシフトの方が喫緊の課題であり、これを蓄電池を用いて上記の 3)のような方法で実現しようとすれば、蓄電池の製造・廃棄に関わる分も含
めて CO2 の排出量は増え、より多くの資源を使ってしまうことにもなる。このように、電力の削減といっても異なる目的があることは注意すべきである。

３．１．２

目的3) 非常時への対応

2011 年の震災においては、関東地区で輪番停電が実施されるなど、一過性ではない停電
が我が国でも現実に生じ、その影響というものを多くの国民が体験することとなった。このときに意外な事実として話題になっていたのが、「太陽光発電設備のついている家庭も停電する」ことであった。実のところ、当時の(現在でもほとんどの)家庭向け太陽光発電装置
は電力系統が正常に働いていることを前提とした動作を行なうものとなっており、停電で系統からの電力がなくなった場合には、動作を停止するか、自立運転モードと呼ばれるモ

26

ードに手動で切り替え、かつ、自立運転モード用として装置内に装備されたコンセントにのみ電力が出てくるという仕様のものであった。

一般常識的に考えれば、系統からの電力が遮断しても、家庭内で発電装置が存在していれば、その発電容量内で通常通りの電力利用が行えても良さそうに思えるが、これを実現するためには高品位な交流を直流電源から生成する装置が必要となることや、復電作業の際に電力が逆流しないようなしくみを実現する必要があるなど、コスト的にも見合わないものと考えられていた。しかしながら、その後この状況は変わりつつあり、現在では太陽電池と蓄電池を組み合わせ、系統からの電源が途絶しても自動的に元ブレーカーのところから家庭内全体に電源を供給し、利用者にとっては瞬間停電程度の影響しか生じないようなシステムも実用化されている。

家庭によっては、常に通電しなければならない医療機器があったり、医薬品を冷蔵して確保しておかなければ生命に関わる家族のいる家庭もある。離島のような物流手段の限られている地域では、夏期には冷蔵庫内の食料品が極めて重要であり、停電は直接食料事情の悪化につながる場合もある。停電時にも通常の生活を維持するということだけでなく、震災の際に避難路の照明を確保したり、火災を未然に防ぐために機器の設定を変えたり、
また、倒壊時にも何人の家族がその住宅の中に居たのかという情報を外部に発信し、円滑な救助を実現したりするなど、非常時に行なうべき動作の電源を確保するという、いわばライフラインを守るということも HEMS の目的のひとつである。

３．１．３

目的4) 投資

我が国でも平成 23 年 8 月に成立した「電気事業者による再生可能エネルギー電気の調達に関する特別措置法」に基づき、再生可能エネルギーは電力事業者が買い取る制度が運用されている。電力を売るときの単価はそのエネルギー源(太陽光発電、風力、地熱、バイオマス、小規模水力)によって異なるが、太陽光発電の 2014 年時点での買い取り価格は 38 円
/kWh に設定されるなど、家庭が電力会社から買う電力(契約や使用量に依存するが概ね 26
円/kWh 程度)と比較して高価になっている。

これは、自宅の太陽光発電の電力は自分で使わずに売電してしまったほうが得であるということを意味している。現在の我が国の制度では 10kW 以下の太陽光発電装置の場合には全量買取ではなく、余剰買取というしくみになっており、太陽光発電で得られた電力から家庭内で利用した電力を差し引き、その余剰分のみが買い取りの対象となるが、家庭内

27

に蓄電池を設置し、太陽光発電が行われている時間帯の電力消費全てを蓄電池でまかない、
夜間により安価な価格の電力で蓄電池に充電すれば、太陽光発電の電力は全て余剰分として売電対象となってくる。

買い取り価格は当初の契約時点で決められ、家庭用 10kW 以下の場合には 10 年間変わらないため、この金額の総量が設備の設置にかかる投資額を超えれば利益となる。天候の影
響で発電量が伸びなかったり、設備が故障してしまったりするリスクはあるものの、低金利時代の現在においては無視のできないほどの利回りとみることができる。収益をあげないにしても、設備費用を回収できる可能性は高く、非常時のための設備が実質的に無料で入手できると考えれば導入メリットはあるものといえる。

但し、忘れてはいけないのはこの高額による売電の原資は電気料金という形で電力を使用する全ての国民が負担している点である。売電のできる再生可能エネルギー発電装置を有する人が電気を使う全員から集めた金を受け取るようなモデルになっていることを意味しており、それゆえ、各個人が受け取る側に回れるように設備の導入に積極的になるということを目的としている。この制度が様々な問題を引き起こすことは当初から予想されており、資金力に余裕のある富裕層に有利な制度であることや、先行して実施した諸外国では電力料金が著しく上昇していることなども懸念となっていたが、我が国においては太陽電池の導入が予想よりもはるかに進んでしまったという問題が生じた。前述のように、電力は需要と供給が常に同量でなければならず、気ままに変動する需要に対し、電力事業者
が供給量を調整することでこれを実現している。太陽電池のような不安定な電力が想定以上に増加すれば、電力事業者の調整能力を超え、大停電の原因となる可能性も生じてくる。
こうした状況を鑑み、買取価格の大幅な下落をはじめとした制度の見直しが進む可能性が急速に出てきている。

３．２ システムを構成する機器の種類
3.1 節では HEMS の目的という観点について述べたが、本節では HEMS 内にある機器という観点での HEMS の分類について述べる。

本章の冒頭で述べたように HEMS には a)-e)の 5 つの種類の機器が含まれている。e) 家
電や住宅設備などのエネルギー需要機器 は HEMS が存在しなくても家庭の中にある家電や住宅設備を意味しており、必ず存在するものと位置付けられる。また、a) エネルギー消費を計測し、その結果を可視化する機器 もこうしたものが存在しなければそもそも HEMS

28

という捉え方ができないという意味で必須である。一方で、b) 他の機器を制御する機器 はa) エネルギー消費を計測し、その結果を可視化する機器 に対する追加機能を実現するものであり、c) エネルギーを生成する機器 と d) エネルギーを蓄積する機器 、いわゆる創エネ・
畜エネ機器はオプション的なものといえる。

これらのうち、c) エネルギーを生成する機器 と d) エネルギーを蓄積する機器 の存在はその HEMS の性質を大きく変えるものとなる。何れもが存在しなければその HEMS は専ら消費電力を削減するためのものとなり、前節の目的 1 に述べたような無駄の排除や、ユーザーへのはたらきかけ、また、洗濯機や食器洗い機など一部の機器の時間シフトを行な
うものとなる。

c)の創エネ機器、特に、燃料電池(エネファーム)やコジェネ(エコウィル)といった、運転のタイミングを変えることのできる装置が入ると、家庭内の電力需要、給湯需要に合わせてスケジューリングを行なうことができ、その家庭に合わせた最適な制御という機能が実現できるようになる。また、言うまでもなく、自立運転や売電という機能もこれらの機器があって初めて実現する。

次に、d)の蓄エネ機器、現状においてはもっぱら蓄電池が利用されるが、これがシステムに加わると、ここまで議論してきた全ての機能が実現可能となる。すなわち、利用者の生活パタンに変更を強いることもなく全ての電力需要のピークシフトが可能となり、再生可能エネルギーに関しては売電に回す量も調整できるようになる。

このように、HEMS の中にどのような機器があるのか、特に蓄エネ要素があるのかという点に依存して前節で述べた目的のうち、どれがそのシステムで実現できるのかが変わってくる。HEMS に関する議論を行なう上で、想定するシステム構成は目的同様、最初に明らかにしておかねばならない重要な観点である。

３．３

制御の範囲

前節の議論とも関連するが、b) 他の機器を制御する機器 があるかないかで HEMS の性
質はまた大きく変わってくる。これはつまり、どこまでを誰が主体で制御するかという観点でもある。

a) エネルギー消費を計測し、その結果を可視化する機器 はそれぞれの家電機器や住宅設

29

備機器が稼働している状況をモニタリングし、利用者にとってわかりやすいように情報を処理したり情報を追加して提示したりするようなところまでを行なうものである。例えば、現在の消費電力値を昨日や一年前の同日との比較を交えてグラフにし、今月見込まれる電力料金を月末までの予測も含めて表示する、といったサービスが実現できる。これらは「見える化」システムとして既に広く知られており、様々な形で商用化もされている。

一方で、b)の要素は利用者に知らせるだけでなく、HEMS の中のコントローラが利用者の意向を受けながら様々な機器の制御を積極的に行なうものとなる。いわば、a)のみのパッ
シブな HEMS から b)を加えることによりアクティブな HEMS になるというイメージである。この制御には様々な情報が必要となるため、各種のセンサとの連携が必要になってくる。また、制御ロジックも高度なものとなり、家庭内のコントローラ機器だけでは処理しきれなくなって、クラウド上のサービスと連携して、いわゆるビッグデータ解析のような処理も行われるようになる。

こうした外部との連携の形態も重要な観点となる。HEMS は家庭内に設置されるものなので、外部とのインタラクションが忘れられがちであるが、電力の逼迫はひとつの家庭の中で起こる話ではなく、電力事業者単位の受給バランスで起こるものであり、広域のシス
テムの中の一員としての HEMS という観点、すなわち、本章の冒頭で述べた CEMS の中に含まれる HEMS という観点も忘れてはならない。つまり、HEMS は単一家庭のコント
ローラとしての制御を高度に行なうためにクラウドと連携する以外に、CEMS がコミュニ
ティ全体としての状況を踏まえた上で個々の家庭の HEMS に出してくる要求に対応する外部連携も行わねばならない。

現状では扱うエネルギー量の小さな個人宅とやりとりするのは効率的ではないため
CEMS が相手としているのは BEMS や FEMS となるが、将来的に HEMS との通信網やそれを処理するしくみが整備されれば、例えば電力の逼迫状況を受けて CEMS から特定の時間帯の消費電力量の上限値や、どこまで削減すると価格などのインセンティブが与えられるか、また逆に、それを履行しないとペナルティ的な価格が課せられるか、などの情報がHEMS に送られ、各 HEMS はそれぞれの家庭の事情に合わせて家庭内の機器の運転方法
をユーザーの同意を取りながら変える、といった動作が行われるようになろう。

CEMS について考える上で認識しておかねばならないのは我が国においては、HEMS における ECHONET Lite のような標準規格が CEMS のレベルになると固まっていないとい30

う点である。国内では、太平洋戦争後、地域独占の電力事業者により電力の供給が行われてきたため、電力システムの中で他社との相互接続点を設けるという必要性に乏しかった。
従って、CEMS のようにシステムによる自動化された需給調整や電力取引を行なう素地がなく、プロトコルのような技術的な側面も当然ながら、どのようなモデルで運用するのかという点に関しても合意があるわけではない。電力自由化の流れの中でこうした環境の整備を進めていく必要があるのが現状である。

一方、現在のスマートグリッドブームの火付け役となった米国をはじめとする北米においては、地続きで多数の国が存在するだけでなく、米国内も州ごとに独立して電力システ
ムの制度を決めていること、また、いくつかの州では自由化が進められ複数の事業者が分担して運用することが当たり前になっていたことから、電力に関する情報のやりとりについての標準化が行われていた。図 3.1 に示したのは米国の NIST(National Institute ofStandards and Technology)[5]の提案を元に ITU-T Focus Group on Smart Grid[4]において標準化されたスマートグリッドシステムの全体像である。
太文字で書かれた 7 つの領域、すなわち、Markets domain
Operators domain
Service Providers domain
Bulk Generation domain
Transmission domain
Distribution domain
Customer domain
がいわば独立したサブシステムとして存在し、それぞれの間において通信が行われるインタ フ ェ ー ス が 定 義 さ れ て い る こ と を 示 し て い る 。 ま た 、 Transmission( 送 電 ) とDistribution(配電)においては Operators domain 内のそれぞれに対応する部分も含めて複数の要素がネットワーク化されていることがみてとれる。

31

Conceptual Reference Diagram for Smart Grid

図 3.1 スマートグリッドの全体像(ITU-T FG-Smart 出力文書より)
この 7 領域の全体像の中で、ECHONET Lite での標準化がカバーしている範囲は右下のCustomer domain に過ぎない。家庭内に閉じた HEMS を指向している分には家庭内のHEMS コントローラと、クラウド内のサービスを中心にシステムを構築する素地が我が国では出来上がっているといえるが、一旦、CEMS の領域まで考えを広げるとこれから整備が必要な領域が多いわけである。

図 3.2 に示したのはこうしたスマートグリッド全体における、(主に北米流の)通信規格群である[10]。この図の上下は概ねプロトコルの下位層から上位層に相当し、一番上にアプリ
ケーションとしての電力取引やデマンドレスポンスが並んでいる。最も下位層にあたるのは UML や XML といったユースケースの仕様記述の手法や、通信のデータ記述方法であり、Ethernet や IP といった通信技術はこの図においてははるか下位の層として記載対象に入っていない。UML や XML もこの図の趣旨からするとやや異質であり、実質的には最下層

32

として CIM ベースのエネルギー基本モデルがあると考えた方がよい。基本となるデータ構
造を共有しつつ、スマートグリッドの各ドメインで利用する通信プロトコルが整備されているという見方が適切であろう。

図 3.2 スマートグリッドにおける通信規格群
ホームネットワークという観点で注目すべきは、HEMS として括られたグループの中で、ZigBee SEP2(Smart Energy Profile ver2)が CIM、NAESB の上に載る形で記載されているが、ECHONET は上下関係から外れているという点である。日本国内のマーケットでは、
ECHONET と ZigBee SEP2 を直接比較するような議論もあるが、家電メーカーを中心に、コンスーマー機器に ICT を導入していかに節電をするか、というところから出発した
ECHONET と、スマートグリッドの全体システムの中で家庭内の領域を担当する規格として開発された ZigBee SEP2 との出自の違いは明らかであり、CEMS の一部としての HEMSを考えるためには図 3.2 に記載されているような体系の構築を考慮する必要がある。その際、留意しておかねばならないのは、米国流のスマートグリッドのしくみをそのまま輸入して我が国で利用できるかどうかという点である。電力供給にあたってのビジネスのしかたの違い、国土の違いによるエネルギーミックスの違いなどから、我が国ではそのまま当ては33

まらない部分も多く、独自の事情を盛り込んだ規格を用意する必要がある点や、電力シス
テムの自由化が進んだとしても、家庭内の機器のように、標準規格に沿った機器をバラバラに調達して組合せて使うような利用方法になるのか、つまり、導入する顧客(事業者)の数が限られているのであれば独自規格のままで進めても問題のない部分があるのではないか、といった点を考慮する必要がある。我が国のスマートグリッド議論では真っ先に出てくる「エネルギーの地産地消」は必ずしも諸外国においてはメジャーなものではなく、IEC
TC57 においても地産地消ユースケースは日本からの提案で盛り込まねばならないような状況になっている。日本型のスマートグリッドとして、ホームネットワークのような他のサービスも含めたシステムの一貫として捉え、より細粒度の自然エネルギーを活用するシステムとして新たに定義し直す可能性というものも考えられるのではないか。これからインフラを整備しなければならない途上国への輸出も考えれば、既存の発電設備や送配電設備を気にせず、需要があるところに小規模発電を設置して、それを次第にネットワーク化
していくようなシナリオのスマートグリッドというものも考える余地はあるものと思われ
る。

34

第４章

現在の状況および今後に向けて本章においては、ここ数年のホームネットワークを巡る状況についてトピック的に述べていくことにする。依然としてホームネットワークの実用化はスマートハウス、つまり、エネルギーマネジメントサービスを中心に回っている感があり、その傾向はしばらくは続くものと予想される。そのエネルギーマネジメントサービスについても、内情的には大きな転換がいくつか見られる。基本的に2013年ごろを境にHEMSの構築に向けた動きは官から民へと主役が移りつつあり、官は次の新しい領域へと踏みだそうと誘導している一方で、民ではHEMSそのものにしてもビジネスとしての立ち上げに苦慮しており、官と民の思いがやや開きつつあるように見受けられる。

４．１ 補助金を利用した導入は実際に進んだ2014 年度までに行われてきた、経済産業省の ECHONET Lite 推進策、いわゆる HEMS
補助金は以下の様な点で成功であったと考えられる。

本施策は、10 万円(後に装置の低廉化が進んだとして 7 万円)という HEMS のほぼ市価に相当する金額の補助金を一般家庭に交付することで、太陽電池システムの導入を考えている家庭にとっては、実質的に HEMS の価格を無料にした効果がある。従来から、興味はあるものの、費用をかけてまで導入するには至らなかった購買層にも訴求し、結果としての交付の全体数は明示的に公開されてはいないものの、予算を使い切るだけの申請があって導入が進んだのに加え、岡山市の例(経産省の補助金と同じ基準のものに対して、経産省よりも多くの補助金を市民に出している)に見られるように、経済産業省の施策を別財源で後追いする例も出ることとなった。

これにより、相当数の世帯にセンサとコントローラ、それから何らかの制御対象を持つ機器が実際に設置されることとなった。従来のように「こうした機器が設置された際には」という「たられば」の世界から一歩踏み出した意義は大きい。

一方で、10 万円あるいは 7 万円という金額に対しての見方が、システム価格全体の価格に対して定額 10 万円や 7 万円の補助、というよりは、上述のように太陽電池システムを導入するのであれば、この補助金に沿ったシステムを入れると見える化などの HEMS 機能が無料でついてきます、という捉われ方となってしまったのが市場での実情である。従って、各メーカーは最低限の条件をクリアするクラウド接続型の HEMS をこれらの販売価格で製造しなければならない、という状況を生み出し、それによって、本来は高度なホームネッ

35

トワークシステムへと続くベースとなるべきシステムが、ユーザーにとってみれば単体完結の発展性のあまりないものになり、販売する方にとってもコスト的にぎりぎりで積極的に製造販売するメリットも大きくない、というものになってしまった感が強い。この状況を明らかにする意味でも、補助金の対象となるための条件について以下に列挙してみよう。

以下は、機器登録の公募文書(https://sii.or.jp/hems25r/file/h25koubo.pdf)の 6 ページに記載されている。
（引用）
補助対象機器に必要な要件
補助対象となるＨＥＭＳ機器は、以下６つの基本要件を満たさなければならない。
1. 標準インターフェイスの搭載（ＥＣＨＯＮＥＴ Ｌｉｔｅ規格認証の取得）
・「ＥＣＨＯＮＥＴ Ｌｉｔｅ」規格を標準インターフェイスとして搭載していること。
2．エネルギーの使用状況の見える化
・補助対象機器を設置した住宅において、その居住者が使用する空調、照明等の電力使用量を計測・蓄積し、電力使用量の「見える化」が実現できること。
3. 省エネに資する制御機能の搭載
・一つ以上の機器に対して、省エネに資する自動制御機能（省エネモードを含む。）を有していること。
※エネルギー使用量を削減するための制御または蓄エネルギー機器のピークカット/ピーク
シフト制御をＨＥＭＳ機器により自動的に実行できること。使用者の確認を介した半自動制
御を含む。
4. 創エネルギー機器及び蓄エネルギー機器との接続
・創エネルギー機器及び蓄エネルギー機器との接続機能を有していること。
※太陽光発電システム等の創エネ機器が設置された場合には創エネ機器による発電量等の情報、蓄電池等の蓄エネ機器が設置された場合には蓄エネ機器による充電量等の情報が取得出来ること。計測のみの接続を含む。
5. クラウドサーバでのデータ蓄積
・電力使用量データをクラウドサーバに蓄積するためのデータアップロード機能を有していること。
※機器登録事業者によりクラウドサーバにデータを蓄積できる環境を本補助事業終了後から少なくとも５年間維持し、そのうち直近１３ヶ月分を保存しておくこと。
※各申請において申請者の同意が得られている場合、本事業において設置されたＨＥＭＳ機
器によりクラウドサーバ上に蓄積された電力使用量の実績データをＳＩＩの求めに応じて提供できること。
6. 省エネ情報の提供
・電力使用量に関わる情報に基づいた省エネを促す情報提供機能を有していること。
※本事業では、上記要件に加え、別表１の「ＨＥＭＳ機器の対象基準」に定める要件を満たしている機器を補助対象機器として指定する。
※補助対象機器が上記要件を満たしていることを機器の仕様書等に明記していること。

36このように、ECHONET Lite 準拠で、見える化と(半)自動制御が求められている以外に、
クラウドへのデータアップロードを義務とし、そのデータも少なくとも 13 ヶ月は保持している必要がある。こうした環境を実現するためのコストを補助金対象の商品を販売した中で捻出することはそれほど容易なことではないといえよう。

一方、商品価値としても「只でついてくる見える化」なら導入を断る理由はないが、2014年度末で補助金制度も終わっており、今後ユーザーが自腹で購入するものとしてみたときには、価格に見合った価値のあるものかという点では再考が必要となろう。事実、各住宅メーカー等も、単にエネルギーマネジメントサービスだけでは魅力に乏しいことは認識しており、見守りやセキュリティなどいくつかのサービスを上乗せしようとする試みは行われているが、その実現にあたっては、第1章で述べたような一般的なホームネットワークを実現可能とする技術を用いたものというよりは、HEMS専用のシステムに付け焼刃的に別のサービスを追加したようなものが多く、その有効性や、将来的にも利用が継続できるかどうかなど、疑問の残るものもある。補助金が切れた後のHEMSは、一度本来の姿に立ち返った見直しが必要な状況にあるように思われる。

４．２ ECHONET Lite 対応機器のメーカーが増えた
ECHONET は極めてシンプルなネットワークプロトコルであり、対応した製品を開発することは容易である。しかしながら、全く新しい技術に対する抵抗感は一般に強く、マーケットが見えないことに加えて、様々な技術的な誤解(風評)もあって、実際に ECHONET
機器を開発するメーカーは、ECHONET コンソーシアムの幹事会員(A 会員)や幹事準会員(A'会員)に限られており、稀に他の会社の製品として発売されていても内情は幹事会員のOEM であったりして、実装のバリエーションが低く、製品としても種類が極めて限られていたと言っても過言ではないのが 2012 年以前の状況であった。

これに対し、補助金でマーケットが見えたこともきっかけとなり、自社で開発を行なうメーカーが一気に増大した。その状況は ECHONET コンソーシアムの会員数(近況で、幹事会員 7 社、幹事準会員 29 社、一般会員 154 社、一般準会員 364 社、学術会員 20 者)にも如実に現れている。また、コンソーシアムに加入した会員企業が実際に製品を開発できる
よう、
神奈川工科大学に設置された HEMS 認証支援センターのような機関が活動を開始し、
ECHONET コンソーシアムも具体的な内容に踏み込んだセミナーを数多く開催するように
なった。

37

これにより、完全に独自開発された ECHONET Lite 製品が多数出現し、個別製品としては市場に出回らないにしろ、様々なシステムの一部として実用に供される状況となった。
今後は、同様の目的を持った ECHONET デバイス、例えば温湿度センサのようなものについて、伝送メディア(通信技術)のバリエーションが増えると同時に精度と価格のバランスの異なる製品群が市場に現れ、システムを構築する側からすれば、選択肢が広がるという状況が生まれるものと考えられる。

なお、このECHONET関連製品の活況を踏まえ、従来は任意団体であったECHONETコ
ンソーシアムは2014年4月から一般社団法人として新たな段階に踏み出すこととなった。

４．３

政策的には HEMS 構築は終わり次のサービスへ

以上のような状況を予見し、政策を考える経済産業省や総務省では、2013 年度から次の段階の施策に移ることになった。上述のように HEMS 補助金の条件の中には、クラウドとの連携が盛り込まれており、これに沿ったシステムが世の中に広まればそこから多くのデータが集まってくる。これを活用して新たなビジネスを創出しようという考えである。

2013 年、経済産業省は従来の HEMS 構築のための規格づくりや導入支援から、集まったデータをどう利活用するか、という方向の検討に舵を切った。たとえば、HEMS 用に取得した電力使用情報を用いて独居高齢者の見守りを行なうことが可能であることは自明である。また、データから家電の稼働状況や操作履歴がわかるため、機器の遠隔メンテや、ユーザーが求めている機能の分析といった方向のテータ活用も考えられる。このように、HEMS を当初の目的として導入した機器が新しい産業を生む可能性は大きく、それに向けてサービスプラットフォームを整備したり、サービスレベルでの規格化を検討したりする余地が生じてくるわけである。

一方で、総務省はこのデータのプライバシはどうなるかについて関心を持っている。総務省はスマートホンに代表される新しいデバイスから生成される各種の情報に関して「パーソナルデータ」の利活用に関する検討という位置付けで検討を進めてきた。スマートホ
ンは特定の個人が所有しているが、位置情報が常に明らかであり、また、加速度センサや明るさのセンサ、カメラ、マイクなどの多数のセンサを有していることや、電話帳に代表されるプライベートなデータベースを有することから、プライバシ侵害につながるおそれが極めて大きな機器である。ホームネットワークは一見スマートホンとは大きく異るシス
テムにもみえるが、実は、個人契約と紐付いていること、各種のセンサを有していてそれ38

らを総合すると行動履歴などが明らかになる可能性が極めて高いことなど、類似した性質を持っている。このような認識から、総務省ではホームネットワークを対象としたパーソ
ナルデータのプライバシ保護に関する検討を2013年に開始し、2014年度はTTCや新世代ネットワーク推進フォーラムレジデンシャルICT SWG[8]にその検討の場が引き継がれ、2015
年3月には「TTC TR-1059 ホームネットワークにおけるパーソナルデータ利活用機能要件」
としてその成果の一部が公開されている。

４．４

HEMS 関連機器はより汎用、コンポーネント化へ

ホームゲートウェイの点でも 2013 年には動きがあった。インテルはホームゲートウェイ
をターゲットとした新しいプロセッサである Quark を 2013 年の 10 月に発表し、開発環境
やサンプルボードの提供を 2014 年 3 月に開始している。これは Atom よりも低消費電力なもので、ARM プロセッサが得意としていた領域に入り込むことが想定されているが、命令セットは x86 であり、ARM よりもハイパフォーマンスなものとなっている。また、組み込みの分野で広く普及している Arduino と互換性のある開発ボードである Galileo が提供されており、ソースコードレベルで Arduino の資産を引き継ぐことができる。また、この新しい Quark プラットフォームについてインテルは、買収した WindRiver 社のリアルタイム
OS である VxWorks を同時に提供し、従来見られなかったハード・ソフトのソリューショ
ン提供を行っている。その後も IoT 向けのプラットフォームとして、SD カードサイズのEdison、ボタンサイズの Curie とラインアップを拡充してきている。

ECHONET Lite のメーカーが増大したことは既に述べたとおりであるが、ホームゲート
ウェイのベースとなるような開発キットが、ECHONET Lite 対応をし始めたことも大きな変化である。ひとつの具体例として 2014 年 2 月にはコンスーマー向け IT 製品を得意としているアイ・オー・データ機器が、NTT-AT(NTT アドバンステクノロジ)とともに OSGi
ゲートウェイ UD-GW1 の販売を始めた。
従来こうした機器はシステム売りするものであり、単品での販売を行なうことは開発向けのサンプル出荷程度であるのが普通であったが、同社の場合には 31,500 円という定価を設定し、直販サイトで個人でも 1 台から購入することを可能としている。アプリケーションのサンプルとして ECHONET Lite デバイスを使った
HEMS プログラムも同梱されており、開発者にとっては従来になかった位置付けの製品といえ、実際、ファーストロットは発売から間もなく売り切れている。この UD-GW1 には多くの拡張スロットがあり、920MHz 帯の無線や G3-PLC など、様々な通信媒体に対応できる可能性を有している。

39

末端の機器についてもここ数年で大きな変化が見られている。従来はECHONETのミド
ルウェアアダプタのようなパーツについても幹事会員が提供するものがほとんどであったが、2014年からはこうしたモジュールレベルでの提供を行なうメーカーが相次いでいる。
現状、国内の全てのエアコンに対応したECHONETモジュールが入手可能となっており、システムを構築する上での自由度が向上している。また、伝送媒体の種類も着実に増えており、近々Wi-SUN方式の製品も市場に出回る見込みとなりつつある。アダプタの種類も、
ECHONET規格で定められているミドルウェアアダプタのような汎用品ではなく、個別カ
スタマイズで既存の製品の制御信号を受けてECHONET Lite化するようなモジュールも提供されてきている。価格面を考えれば最初から本体にECHONET Liteの機能を組み込んだ製品設計を行なう方が有利ではあるが、既存の製品を流用してECHONET化できるモジュールの拡充は直近における現実的な選択肢として極めて重要なものといえる。事実、こうしたモジュールの供給をもとに電動窓などの建材分野においてもECHONET Lite対応製品の発表が始まっており、2015年度からはその傾向が顕著になるものと予想される。

４．５

パーソナルデータの扱いが大きなテーマに

前述のパーソナルデータに関しては、今後は自動車、健康・医療など、様々な分野で同様の問題が生じると考えられることと、このようなデータは今後の産業力を考える上で極めて重要であることから、内閣府の高度情報通信ネットワーク社会推進戦略本部において2013 年 6 月に「パーソナルデータに関する検討会」を設置しており、2014 年 3 月には内閣官房情報通信技術（ＩＴ）総合戦略室内に「パーソナルデータ関連制度担当室」を発足させている。その成果として 2014 年 6 月には、「パーソナルデータの利活用に関する制度改正大綱」が公表された。

パーソナルデータの取り扱いに関しては、2013 年には JR 東日本が Suica 利用データをマーケティング目的で日立に提供した件が社会問題となるなど、既に一般市民の関心事となっている。この一件でも明らかなように、利用者の行動から取得したデータをどのように取り扱うかについて、十分に利用者とのコンセンサスをとらなければ問題になることは明らかであるが、一方で、「ビッグデータ」が喧伝される今日、JR 東日本が行おうとした
ように、顧客から得たデータを違う形で活用することは、新しいビジネスを展開する上では極めて重要である。上記の HEMS データの場合も、自家の HEMS から取得したデータ
でその家庭の利用者の見守りサービスを行なうことについては社会的な認知が得られやす
いものと考えられる一方で、データの利用目的を限定したい利用者がいることも確かであり、そうした意思表示の手段をどう提供するかが問題となる。

40

一般に、何かを始めようとした際に、事前に問題を潰してから始めるようなやり方をオ
プトイン、逆に、始めてしまってから問題に応じて一部の取りやめなどの対処を行なうのがオプトアウトと呼ばれている。法律のしくみや社会的な慣習などから、欧州はオプトイ
ン、米国(および英国)はオプトアウトの立場をとることが多い。インターネットの世界で、
Google を始めとしたクラウド(ビッグデータ)企業は米国に集中していることからみても、
新規に産業を立ち上げる意味ではオプトアウトの立場でビジネスを実施できることは重要である。一方で、利用者の権利や、欧州との相互乗り入れを考えた時にはオプトインのしくみを整備する必要もある。

2014 年 6 月の大綱においては、大まかには、
1. パーソナルデータの利活用は推進すべき
2. 規制ルールなどは国が全部決めるのではなく、民間の自主規制を活用すべき
3. 紛争解決などを行うための第三者機関を設けるという内容であり、基本的にはパーソナルデータ利活用の推進を図るトーンで記載されている。一方で、その後の個人情報保護法の改正議論においては様々な意見が出され、慎重な表現で改正が進められていることを伺わせる。今後、この法改正を受けて、各民間団体
での規制が制定されることが予想されるが、どのような形に落ち着いていくかは予断を許さないところである。

４．６

稼働し続けることが求められる時代にHEMS が家庭に入り込み始めたことを受けての変化はデータの取り扱い以外にも生じている。システムの構築の容易化と、構築後のシステムの正常稼働を保証するための監視に対する関心がメーカーを中心に高まりを見せているのである。今回の補助金の対象として販売されている ECHONET Lite の HEMS システムはあまり拡張性を重視してはおらず、設置時に専門家が行った設定のまま使い続けることが想定されているが、ECHONET Liteという標準プロトコルを使っている以上、システムの拡張は容易である。また、複数の
ECHONET Lite システムが時期を異にして導入されるケースも今後は生じてくると考えられ、新しいシステムの導入でそれまで稼働していたシステムが正常に動作しなくなる可能性もある。

こうした問題は、昔からホームネットワークでは取り扱われており、ITU-T G.9973 として国際標準となっている TTC の HTIP(Home network Topology Identifying Protocol)や、

41

IEC 62608 と し て 国 際 標 準 に な り つ つ あ る JEITA の Multimedia home network
configuration といった国産技術が存在している。以前は、DLNA に代表される AV 系のネットワークのためにこれらを利用することが想定されていたが実用化に至らず、今回、これに HEMS 機器も加わることで管理・監視技術の有用性が一気に高まり、再び注目を集めている状況にある。G.9973 も IEC62608 も実装が広く入手可能な状況にはないため、これから実用性の高い実装と、実装で生じる問題の修正など技術的な検討を経て市場に登場してくるものと考えられる。これらは典型的にはホームゲートウェイに実装されるため、各社のホームゲートウェイに搭載できるソフトウエアコンポーネントとしての製品化が近々行われることになろう。特にこれらの技術については、従来から家電やホームゲートウェ
イを実装してきたメーカーに限らず、ISP( Internet Service Provider)などの通信事業者も興味を示しており、近い将来の実用化も考えられる。

TTCでは、この管理運用技術に関し、2013年度には「TTC TR-1053 サービスプラット
フォームにおけるカスタマサポート機能」、2014年度には「TTC TR-1057

ホームネット

ワークにおけるカスタマサポート機能ガイドライン」を発行している。今後、IEC 62608
もpart2以後の標準化が本格化するが、こちらでは障害検出のためのユースケース群などの議論も盛り込まれる予定であり、今後の実装に向けて要注意な標準化活動といえよう。

42

あとがき

本報告書では、ホームネットワークの全体像を把握するためのアーキテクチャや構成要
素について述べるとともに、近年のホームネットワーク商品化の牽引役となっている
HEMS を中心にその位置づけや目的、現状などについて述べた。

一方で、本報告書では全く触れなかった他のサービス分野についても重要な動きがみられる。HEMS と同じ制御系であるヘルスケア分野は当初よりホームネットワークの重要なサービス分野であると認識されていたが、薬事法の制約が厳しく、技術的ではない理由か
ら参入が難しい状況にあった。しかしながら、高齢化が年々進み、健康保険の健全な運用のためにも国民が健康でくらしていることの重要性が高まっている中、医療までは踏み込
まない、現状健康なユーザーを対象とした健康維持の分野や、介護の労力を減少させる分野において、再度ホームネットワークを活用しようとする動きがある。特に、75 歳以上の高齢者のみで構成される世帯については、様々な観点でのケアを行うことが行政にも求められており、これに対して合理的なトータルソリューションを提供するためのホームネッ
トワークには期待がかかる。

また、ロボットのような新しい機器の出現は今後、様々な新産業を生む可能性を秘めている。掃除ロボットはようやく我が国のメーカーも発売するようになってきたものの、依然、単体での動作が中心であり、ホームネットワークの一員として稼働した場合の可能性については手が付けられていない状況にある。

更に、AV の分野においても、4K 映像、3D 映像といった固定型の受像機のアプリケーシ
ョンは一巡した感はあるものの、プロジェクションマッピングを家庭内で応用するような新しいアプリケーションについてはほぼ手付かずである。

今後も管理運用技術などで足元を固めつつ、クラウドでのビッグデータ処理を活用し、こうした新しい分野のサービスが広がることで新産業が生まれることが期待される。

43

参考文献

[1]ITU-T Recommendations、
http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx[2]J.190 Architecture of MediaHomeNet、
http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=9203[3]Y.2070 Requirements and architecture of the home energy management systemand home network services、
http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12420[4]ITU-T Focus Group on Smart Grid (FG-Smart)、
http://www.itu.int/en/ITU-T/focusgroups/smart/Pages/Default.aspx[5]NIST、”NIST Framework and Roadmap for Smart Grid Interoperability
Standards、Release 2.0”、
http://www.nist.gov/smartgrid/upload/NIST_Framework_Release_2-0_corr.pdf(2012.2)[6]TTC ドキュメントデータベース、
http://www.ttc.or.jp/cgi/document-db/index.html[7]情報通信技術委員会、”ホームネットワーク通信インタフェース実装ガイドライン”、
http://www.ttc.or.jp/j/info/release/20121109/ (2012.12)[8]新世代ネットワーク推進フォーラム ICT SWG、
http://ipnwg.nict.go.jp/[9]ECHONET コンソーシアム、
http://www.echonet.gr.jp/[10]電気学会技術報告、「スマートグリッドにおける需要家施設のサービスインフラ」、
http://www.bookpark.ne.jp/cm/ieej/detail.asp?content_id=IEEJ-GH1332-PDF[11]丹 康雄監修 宅内情報通信・放送高度化フォーラム編、”ホームネットワークと情報家電”、ユビキタス技術シリーズ、B5 版 234 頁、株式会社オーム社 (2004.9)[12]丹 康雄、
” ECHONET Lite 時代を迎えたスマートハウス構築のためのホームネット
ワーク技術 2013”、インターネットメディア総合研究所レポート、A4 版 240 頁、株式
会社インプレス R&D (2012.9)[13]丹 康雄、”スマートハウス構築のためのホームネットワーク技術 2011”、 インター
ネットメディア総合研究所レポート、 A4 版 232 頁、株式会社インプレス R&D(2011.5)[14]丹 康雄、
”CPS を指向するクラウド型ホームネットワークと HEMS”、計測と制御、iVol.53、No.12、pp.1123-1129 (2014.12)[15]丹 康雄、”スマートハウスの現状と今後の展望”、電気計算、Vol.82、No.9、
pp.2-7 (2014.9)[16]丹 康雄、
”ホームネットワークにおける HEMS の現状と動向”、日本ロボット学会誌、
Vol.32、No.3、pp.30-33 (2014.4)[17]丹 康雄(分担執筆)、”グリーン ICT によるスマートな社会の創出”、情報処理学会誌、Vol. 53、No. 10、pp.1021-1027 (2012.10)[18]丹 康雄、
” (解説論文)ホームネットワークの現状と標準化動向”、電子情報通信学会
通信ソサエティマガジン B-plus、Vol.22 (2012.9)[19]丹 康雄、
”HEMS 住宅に必要な設備”、スマートエネルギーネットワーク最前線、第二編第二章第一節 、pp. 274-283、株式会社エヌ・ティー・エス (2012.4)[20]丹 康雄、杉本裕監修、” ネットワーク家電制御による二酸化炭素削減技術”、 二酸
化炭素の有効利用技術、第 6 章 4 節、pp. 361-370、サイエンス&テクノロジー株式会
社 (2010.7)[21]丹 康雄、
”ホームネットワーク(OSGi, ECHONET)モデルに基づく家庭内エネルギー
マネジメント”、情報処理、Vol.51、No.8、pp. 959-965 (2010.8)[22]丹 康雄、財団法人インターネット協会監修、”ホームネットワークの最新動向”、イ
ンターネット白書 2010、第 4 章 1 節、pp.114-117、株式会社インプレス R&D (2010.6)[23]丹 康雄、”転機を迎えるホームネットワーク”、パナソニック技報、Vol.56、No.1、
pp. 4-9 (2010.4)[24]丹 康雄、”進展するホームネットワークの現状と将来展望”、ITU ジャーナル、Vol.40、
No.3、pp.34-37 (2010.3)[25]丹 康雄、”
家庭内 AV ネットワークの現状と課題”、映像情報メディア学会誌、
Vol.63、
No.7、pp.15-18 (2009.7)[26]丹 康雄、
”ホームネットワークが切り開くネット時代の家電産業”、電波技術協会報FORN、No.268、pp.12-15 (2009.5)[27]サカ・テクノサイエンス 植物生育環境制御システム、
http://www.sakatec.jp/led_result.html

ii