平成 28年度補正

IoTを活用した社会システム整備事業

（スマートホームに関するデータ活用環境整

備推進事業）

成 果 報 告 書

＜第１分冊＞

平成 30年 3月

調 査 報 告 書

i

－ 目 次 －

第 1 章 事業概要 ........................................................................................................................ 1

1.1. 事業の背景・目的 .............................................................................................................. 1

1.2. 事業概要 ............................................................................................................................ 1

1.2.1. スマートホームに関するデータ活用環境整備に向けた実証事業の公募・採択・進捗管理

等 1

1.2.2. スマートホーム分野におけるデータ活用環境整備に向けた調査等 ................................... 2

1.3. 実施方法 ............................................................................................................................ 3

1.3.1. 実証事業（再委託事業）の公募、採択 ............................................................................... 3

1.3.2. 事業環境構築検討会・サブワーキンググループの設置・運営 ........................................... 6

1.3.3. 実証事業全体の取り纏め等 ................................................................................................. 9

1.4. 実施体制 .......................................................................................................................... 10

第 2 章 実証事業の概要 ........................................................................................................... 11

2.1. 新規サービス創出のための情報クラウド間連携基盤の実証 ............................................. 11

2.1.1. 事業の目的と全体像 ........................................................................................................... 11

2.1.2. 実証内容 .............................................................................................................................. 11

2.1.2.1. モニタ募集及び実証環境整備 .......................................................................................... 11

2.1.2.2. 機器間連携のシステム構築 ............................................................................................ 12

2.1.2.3. 社会課題解決に向けたサービス実証 .............................................................................. 15

2.1.2.4. 実施体制及びスケジュール ............................................................................................ 15

2.1.3. 実証結果 ............................................................................................................................. 17

2.1.3.1. モニタ募集及び実証環境整備 ......................................................................................... 17

2.1.3.2. 機器間連携のシステム構築 ............................................................................................ 20

2.1.3.3. 社会課題解決に向けたサービス実証 .............................................................................. 21

2.1.4. 実証を通じた論点の整理 ................................................................................................... 22

2.1.4.1. データカタログ............................................................................................................... 22

2.1.4.2. セキュリティ・製品安全 ................................................................................................ 24

2.1.4.3. プライバシーデータの活用／サービスの創出 ............................................................... 27

2.1.5. スマートライフの今後に向けた考察、提言 ...................................................................... 29

2.1.5.1. サービスプラットフォームのあり方について ............................................................... 29

ii

2.1.5.2. 企業間連携の壁............................................................................................................... 29

2.1.5.3. 法整備の必要性............................................................................................................... 29

2.1.5.4. 実証事業の在り方（本実証を踏まえ） .......................................................................... 30

2.2. IOT を活用したスマートホームクラウド構築及び検証 .................................................... 31

2.2.1. 事業の目的と全体像 .......................................................................................................... 31

2.2.2. 実証内容 ............................................................................................................................. 31

2.2.2.1. モニタ募集及び実証環境整備 ......................................................................................... 33

2.2.2.2. 機器間連携のシステム構築 ............................................................................................ 35

2.2.2.3. 社会課題解決に向けたサービス実証 .............................................................................. 37

2.2.2.4. 実施体制及び実証スケジュール ..................................................................................... 38

2.2.3. 実証結果 ............................................................................................................................. 40

2.2.3.1. モニタ募集及び実証環境整備 ......................................................................................... 40

2.2.3.2. 機器間連携のシステム構築 ............................................................................................ 42

2.2.3.3. 社会課題解決に向けたサービス実証 .............................................................................. 44

2.2.4. 実証を通じた論点の整理 ................................................................................................... 45

2.2.4.1. データカタログ............................................................................................................... 45

2.2.4.2. セキュリティ・製品安全 ................................................................................................ 48

2.2.4.3. プライバシーデータの活用／サービスの創出 ............................................................... 52

2.2.5. スマートライフの今後に向けた考察、提言 ...................................................................... 53

2.2.5.1. 事業の総括 ...................................................................................................................... 53

2.2.5.2. 全体を通じての考察 ....................................................................................................... 54

2.2.5.3. 今後に向けた提言 ........................................................................................................... 54

2.3. スマート製品ライフサイクルに関する実証 ...................................................................... 57

2.3.1. 事業の目的と全体像 .......................................................................................................... 57

2.3.2. 実証内容 ............................................................................................................................. 58

2.3.2.1. 実証内容の全体像 ........................................................................................................... 58

2.3.2.2. 製品ライフサイクルアプリケーションの例 ................................................................... 59

2.3.3. 実証結果 ............................................................................................................................. 63

2.3.4. 実証を通じた論点の整理 ................................................................................................... 63

2.3.4.1. データカタログ............................................................................................................... 63

2.3.4.2. セキュリティ・製品安全 ................................................................................................ 66

2.3.4.3. プライバシーデータの活用／サービスの創出 ............................................................... 68

第 3 章 実証を通じた論点の整理 ............................................................................................. 70

3.1. データカタログ ................................................................................................................ 70

3.1.1. 目的 .................................................................................................................................... 70

3.1.2. 論点 .................................................................................................................................... 70

3.1.3. 検討結果 ............................................................................................................................. 71

iii

3.1.4. 検討成果の位置づけと意義 ............................................................................................... 76

3.1.5. 関連調査 ............................................................................................................................. 78

3.1.5.1. ECHONET Lite とネットワークレイヤー .................................................................... 78

3.1.6. 今後の課題 ......................................................................................................................... 79

3.2. セキュリティ・製品安全 .................................................................................................. 79

3.2.1. 目的 .................................................................................................................................... 79

3.2.2. 論点 .................................................................................................................................... 80

3.2.3. 検討結果 ............................................................................................................................. 80

3.2.4. 主な検討ポイント .............................................................................................................. 87

3.2.5. リスクベースアプローチ ................................................................................................... 88

3.2.6. 製品安全 ............................................................................................................................. 89

3.2.7. 今後の課題 ......................................................................................................................... 91

3.3. プライバシーデータの活用／サービスの創出 .................................................................. 92

3.3.1. データ主体への説明および同意取得 ................................................................................. 93

3.3.2. オプトアウト ..................................................................................................................... 98

3.3.3. 海外での事業展開における留意点 .................................................................................. 100

3.3.4. 今後の課題 ....................................................................................................................... 102

3.4. リコール・リサイクル ................................................................................................... 102

3.4.1. 実証結果を踏まえた成果と課題（主なもの） ................................................................ 103

3.4.2. まとめ .............................................................................................................................. 107

第 4 章 スマートライフ関連市場の創出に向けて .................................................................. 108

4.1. スマートライフのイメージ ............................................................................................ 108

4.2. 接続に関連するルールの整理及び今後の課題 .................................................................110

4.2.1. データカタログ ................................................................................................................. 110

4.2.2. セキュリティ・製品安全 .................................................................................................. 111

4.2.3. プライバシーデータの活用 .............................................................................................. 112

4.3. 社会課題やテーマ毎のサービス創出に向けて .................................................................112

参考資料 ...................................................................................................................................115

iv

1

第1章 事業概要

1.1. 事業の背景・目的

IoT（モノのデジタル化・ネットワーク化）の拡大等による膨大なデータ収集と AI（人工知能）

による解析能力の向上等によって、今後、様々な分野で、生産性の向上や新たなビジネスモデル

の創出が期待されている。

特に、スマートホーム分野については、「新産業構造ビジョン中間整理」（平成 28 年 4 月 27 日

産業構造審議会新産業構造部会）においても、有力分野とされており、IoT 技術等によって家庭内

の機器をネットワーク化し、それらのデータを活用することで、既存ビジネスモデルの変革や新

たなビジネスモデルの創出が期待される他、例えば、家事負担の軽減による就業環境の改善や見

守りによる独居高齢者問題の解消、家庭内での事故死（ヒートショック等）の減少、製品情報の

把握によるリコール回収率の向上やリサイクルの円滑化、家庭部門の省エネルギー化など、社会

課題の解決にも貢献することが期待されている。

他方、本分野においては、欧米を中心に先進的な取組が進められており、我が国では、機器間

の連携・接続に必要となる一定のルールやセキュリティ、製品安全、プライバシー等の課題から

企業の枠を超えた取組が十分に進んでおらず、革新的な新たなサービスも生まれにくい状況であ

る。

そのため、本事業では、家庭内の機器のネットワーク化やそれによる新たなビジネス創出に必

要となる事業環境の整備に向けた実証事業を行った。

1.2. 事業概要

1.2.1. スマートホームに関するデータ活用環境整備に向けた実証事業の

公募・採択・進捗管理等

本事業における三菱総合研究所（以降 MRI）の実施事項を下記に示す。大きく分けて、事業当

初の実証事業公募・採択、次いで、再委託事業者との契約および進捗管理、各種会合（事業環境

構築検討会、サブワーキンググループ（以降 SWG））の設置・運営を中心にプロジェクトの進捗

管理および経済産業省への報告を行った。

2

表 1-1 本業務における実施事項一覧

項 目 内 容

実証事業の公募・採

択

実証事業の公募要領の作成

MRI 及び経済産業省のホームページ上で公募を実施

審査委員会の設置・運営、審査基準案の作成

実証事業者の採択

再委託事業者との契

約・進捗管理

実施計画書を精査の上、再委託事業者と契約

実証事業の適切な実施のため、再委託事業に対する指導、助言、進捗

管理及び実証事業の成果のとりまとめを実施

再委託契約期間終了後は、速やかに確定検査を行い、額の確定、支払

処理を実施

プロジェクト進捗管

理・報告

事業全体が円滑に行われるよう、進捗管理を行うとともに、定期的に

経済産業省への報告を実施

各種会合（事業環境構築検討会、SWG）の設置・運営

報告書とりまとめ（再委託事業者分含む）

1.2.2. スマートホーム分野におけるデータ活用環境整備に向けた調査等

これまでのスマートホームに関する官民の取組みや、近年のグローバル・トレンドを踏まえ、

ライフスタイルのカスタマイズ化と製品ライフサイクルの把握の観点から、平成 28 年度 IoT 推

進のための新産業モデル創出基盤整備事業（家庭内機器のネットワーク連携等調査）を踏まえ、

第 1 回事業環境構築検討会で以下の論点が示されている。

本事業においてはこれらの論点について、SWG における議論を通じた検討を行い、その結果

を事業環境構築検討会にて報告・議論を行った。

3

表 1-2 本業務における主要論点一覧

（出所：平成 28 年度 IoT 推進のための新産業モデル創出基盤整備事業（家庭内機器のネット

ワーク連携等調査）、経済産業省、平成 29 年 3 月）

MRI ではこれら論点について、テーマ毎に設置された SWG において、必要な調査を実施し

つつ、実証事業者と連携した検討を実施した。

1.3. 実施方法

1.3.1. 実証事業（再委託事業）の公募、採択

(1) 実証事業の公募

実証事業公募で行う主な業務として、公募要領の作成及び公募の実施を行った。

公募資料の作成

公募実施にあたり、経済産業省と相談の上、以下の資料を作成した。

論点①

データプロファイル個々のアクション（業務）についてマンダトリーの出入力データ項目を整理

アクションの追加（新規設計）が随時行える拡張性が高いデータ構造を検討。

論点②

セキュリティ・製品安全

機器サービス接続に当たり各主体が接続先に求めるセキュリティ上の認証基準の整理（セキュリティ）

ネットワーク機器のモニタリング・ログ管理の在り方（メリデメ含む）の整理（セキュリティ）

遠隔操作を始めとする製品安全に係る現状ルールの明確化（製品安全）

論点③

リコール（製品安全）・リサイクル

リコール対象製品に係るユーザーへのIoTを活用した適切な周知、回収方法等の整理

適正なリサイクル／リユースルートに排出されるために消費者にとって容易で身近な方法の整理

論点④

プライバシーとデータ活用ルール

様々な機器・サービス事業者の参入を前提としたプライバシー・個人情報ルールの検討

（サービスの性質を踏まえ）モニターが用途を予見した上での事前同意取得の在り方を整理

論点⑤

サービス創出 課題や個人のニーズに沿った総合的なサービス創出を促すための方策の検討

4

表 1-3 公募資料一覧

資料名 内容

公募要領 公募実施に際して、応募者に示す書類。

事業内容、応募対象、応募手続き、審査・選定プロセス、契約手続き等

について記載。

公募申請書 公募の際に、応募者の情報を記載させる様式。

応募団体の代表者及び担当者を特定する。

公募提案書 公募の提案書の様式。

申請団体調書 提案団体及び協力団体の概要及び財務状況を記載させる様式。

会社案内、財務諸表等を添付させて、記載内容が正しいことを証明さ

せるようにする。

予算計画書 予算計画について記載させる様式。

採択時にこの予算をすべて認めるものではない。

応募条件・同意書 応募の条件を示し、同意した上で応募していることを証明するための

様式。

本公募について、プロジェクト運営に関する注意事項や、委託事業で

あることから精算条項への同意等を予め得るために利用する。

個人情報の取扱 公募で、応募者の個人情報を取得するため、取得した情報の取扱につ

いて説明するための書類。

委託事業事務処理マ

ニュアル

経済産業省の委託事業事務処理マニュアルへのリンクを掲載する。経

費の取扱についての詳細はこれを見てもらうようにする。

http://www.meti.go.jp/information_2/publicoffer/jimusyori_manual.

html

契約書ひな形 実証事業の採択を受けた場合に、実際に交わすことになる契約書。

公募の実施

(a)の資料確定後、平成 29 年 3 月 1 日から 3 月 22 日に公募を実施した。公募にあたっては、

MRI 及び経済産業省のウェブサイトを活用し、公募を周知した。また、対面での公募説明会を 3

月 8 日に開催した。

必要な提出資料を含めてすべて公募段階で提示することで、選定から実証事業の契約、実施に

スムーズに移れるように工夫した。

なお、最終的な応募件数は 7 件であった。

(2) 審査委員会の設置、採択

ここでは応募案件を採択するための組織として、審査委員会の設置及び採択を実施した。

5

審査委員会の設置

再委託事業者の採択に際して、外部有識者からなる審査委員会を設置し、応募された実証事業

の審査を行った。委員はスマートホーム分野に関する有識者（学識経験者等）より 3 名で構成し

た。

公募締切後、速やかに開催するために、経済産業省と相談の上、審査委員会の人選を行い、公

募と平行して委員委嘱手続きを実施した。

採択

採択については、1 回の審査委員会にて的確な審査を行うために、以下のように実施した。

表 1-4 採択までの手順

項目 内容

① 審査基準、審査の視点の提示 審査基準と審査の視点を公募要領にも記載するこ

とで、応募者がこの視点を踏まえて応募できるよ

うにした。

② 資料の事前送付 応募資料を〆切後速やかに審査委員に送付した。

また、応募資料の内、審査にかかわる部分を抜き出

してまとめた資料を事務局で作成、送付した。

③ 委員による評価の実施 委員会に先立ち、審査委員に評価を実施いただき、

結果を事務局にて集約し、評価結果を審査委員会

に提示した。

④ 審査委員会の審議 事務局による集約結果をもとに各委員からの質疑

を行い、採択予定者として 3 社を決定した。

⑤ 採択 事務局から実施内容・予算の調整を行った上で最

終的な採択者を決定した。

審査について、基本的に審査委員と事務局、及び経済産業省で審査委員会を実施した。

なお、選定・採択手法の一つとして、「条件付採択」を取り入れた。これは応募者に対して、審

査委員や経済産業省からの改善要望・依頼等を受け入れることを条件に採択するもので、採択決

定前あるいは採択候補として決定後に、応募者と調整を行い、応募者の受諾後に採択を確定させ

るものである。本事業での採択にあたっても、このプロセスを採用した。

審査基準

審査基準の骨子は以下のとおりである。

6

表 1-5 審査基準

審査基準 小項目

1 実証・評価内

容

(1) 経済産業省の委託調査「平成 28年度 IoT推進のた

めの新産業モデル創出基盤整備事業（家庭内機器

のネットワーク連携等調査）」で示されたスマート

ホームの将来像のイメージ、検討の方向性等を十

分に踏まえているか

(2) 実証・評価の目的・目標が、活用する技術等から

達成可能な内容となっているか

(3) 実証・評価の内容に新規性・先進性・具体性等は

あるか

(4) 具体的な実証・評価課題を設定しているか、設定

された課題は適切か、また、実証・評価の内容は

当該課題の解決方法として適切か

(5) 実証・評価の進め方は目標達成に向けて適切か、

実証事業の実施期間内で実施可能な実証・評価内

容となっているか

(6) 機器・設備等の設置計画等は妥当か、また提案額

が実証・評価の内容に照らして適当かどうか

(7) 連携する機器の追加やサービス追加などの拡張が

容易に行えるよう、システム設計・開発において

柔軟性を確保するための十分な工夫がなされてい

るか

2 政策との合致 (1) 経済産業省の政策に合致しているか

1.3.2. 事業環境構築検討会・サブワーキンググループの設置・運営

事業実施にあたっては、外部有識者等から構成される事業環境構築検討会およびサブワーキン

グ（SWG）を設置し、検討を行った（図 1-1 参照）。

7

図 1-1 事業環境構築検討会、サブワーキンググループの構成

(1) 事業環境構築検討会

本事業では、下記事項について、各テーマの専門知識を有する有識者により構成された検討会

を設置し、後述の SWG における検討結果を踏まえた議論を実施した。

➢ 機器間の制御やデータ連携の仕組みの在り方や最低限協調化すべきルール

➢ 機器のネットワーク化の進展に伴うセキュリティ、製品安全の在り方

➢ 家庭にまつわるデータ活用における同意取得、プライバシーポリシーの在り方

➢ 機器情報を活用したリサイクル・リコールの在り方 等

検討会メンバは以下の構成とし、事業期間内に検討会を 3 回開催した（表 1-6 参照）。

➢ 学識者、有識者

➢ 再委託事業者：本実証における再委託事業者（幹事会社 3 社、その他協力企業等）

➢ 業界団体

➢ 行政：経済産業省の関連部署

➢ 事務局：MRI

検討会には後述の SWG での検討結果および再委託事業者からの実証成果を提示し、本実

証において検討するべき課題事項に関する議論を行い、成果としてとりまとめた。

(2) サブワーキンググループ（SWG）

第 1 回事業環境構築検討会では本事業実施にあたり、他社間連携上の表 1-2 に示す論点が提

示され、必要な検討課題に応じた SWG を適宜開催することが合意された。これを受け、経済産

業省と調整のうえ、以下に示す 4 つの SWG を設置し、検討を実施した。

➢ データカタログ

➢ 製品安全・セキュリティ

8

➢ プライバシー・データ活用／サービス創出

➢ リコール・リサイクル

SWG メンバは以下の構成とし、事業期間内に各テーマについて 2～3 回開催した（表 1-6

参照）。

➢ 学識者、有識者

➢ 再委託事業者：本実証における再委託事業者（幹事会社 3 社、その他協力企業等）

➢ 業界団体（必要に応じ）

➢ 行政：経済産業省の関連部署

➢ 事務局：MRI

SWG には検討が必要とされた各論点に関し、事務局にて作成した資料や再委託事業者から

の実証関連資料を提示の上、議論を行い、検討成果として事業環境構築検討会に報告を行った。

以下には、これら事業環境構築検討会等の開催状況と議事内容を示す。

表 1-6 事業環境構築検討会等の開催状況、議事内容

審査委員会／事業環境構築検討会 サブワーキンググループ（SWG）

（データカタログ、製品安全・セキュリティ、プライバシー・データ活用／サービ

ス創出、リコール・リサイクル）

平成29 年3 月～4 月

3 月下旬に審査委員会を開催

➢ 応募された提案書の確認・評価

➢ 再委託事業者の採択 等

5 月 第 1 回検討会を開催(5/24)。

➢ 全体計画、実証内容の共有

➢ 検討課題の共有

➢ 今後の進め方 等

6 月～7 月

第 1 回検討会にて共有された検討課題について、テーマ毎に SWG にて検討。

➢ データカタログ(6/22, 7/11)

➢ 製品安全・セキュリティ(7/12)

➢ プライバシー・データ活用／サービス創出(7/21)

➢ リコール・リサイクル(6/28)

8 月 SWG での検討を踏まえ、第 2 回検討会を開催(8/8)。

➢ SWG での検討状況の報告

➢ 各コンソーシアムの実証準備状況の共有

➢ 意見交換

➢ 今後の進め方 等

8 月～1 月

＜実証事業の実施＞

2 月 実証事業踏まえ、本事業の成果等をテーマ毎に SWG にて検討

➢ データカタログ(2/19)

➢ 製品安全・セキュリティ(2/8)

9

審査委員会／事業環境構築検討会 サブワーキンググループ（SWG）

（データカタログ、製品安全・セキュリティ、プライバシー・データ活用／サービ

ス創出、リコール・リサイクル）

➢ プライバシー・データ活用／サービス創出(2/14)

➢ リコール・リサイクル(2/14)

2 月 SWG での検討結果を第 3 回検討会に報告。今後の方向性について議論を実施(2/27)。

➢ SWG での検討結果の報告

➢ スマートホームデータ連携に向けて

➢ スマートライフ政策について

➢

1.3.3. 実証事業全体の取り纏め等

MRI は実証事業全体のマネジメント、とりまとめ等業務として、以下を実施した。

(1)実施内容精査、リスク管理

(2)

事業の進捗・品質管理等

(4)実証の準備

(5)実証の実施

(6)実証結果のとりまとめ、報告書作成

(3)実証検証項目の設定

計画

実証事業

の実施

結果の評

価・分析

図 1-2 全体マネジメント・進捗管理・情報共有等の業務フロー

10

1.4. 実施体制

本事業は下記に示す体制により実施した。

MRI による公募で採択した、積水ハウス、大和ハウス工業、及び日立製作所を各々幹事会社と

する 3 つのコンソーシアムが、MRI からの再委託先として実証事業の実施を担った。

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 1-3 本事業の実施体制

実証事業の内容は、本報告書＜第 1 分冊＞2.1 節～2.3 節にて概要を示し、詳細については、以

下に示す各々の報告書＜第 2 分冊＞、＜第 3 分冊＞及び＜第 4 分冊＞において報告する。

＜第 2 分冊＞新規サービス創出のための情報クラウド間連携基盤の実証

再委託先：積水ハウス株式会社

＜第 3 分冊＞IoT を活用したスマートホームクラウド構築及び検証

再委託先：大和ハウス工業株式会社

＜第 4 分冊＞スマート製品ライフサイクルに関する実証

再委託先：株式会社日立製作所、東京電力パワーグリッド株式会社、株式会社 Warrantee、

ヤマトシステム開発株式会社

スマートホーム実証●三菱総合研究所（3月～準備、8月頃～実証、3月報告書）

ライフスタイルに関するサービス実証

製品ライフサイクルに関するサービス実証

音声認識ロボットやSNS等と家電・設備機器・制御機能が連携。

●大和ハウス（戸建て住宅モニター）○富士ソフト（UIクラウド構築）○NEC（HEMSデータ提供）○ソニーCSL（GW構築）

○パナソニック（エアコン） ○シャープ（エアコン）○三菱電機（エアコン） ○フィリップス（LED照明）○ユカイ工学（BOCCO）○IIJ（スマートメーター）

○アイホン（ドアホン） ○Yahoo（ｍyThings） 等

サービス実施

エアコンや空気清浄機の遠隔操作や、不在時にも遠方から来訪者を確認したり、プラットフォームを通じた照明操作などを実現。

●積水ハウス（集合住宅モニター）○日本ユニシス（クラウド・認証 基盤構築）○富士通（個人情報クラウド連携構築）

○シャープ（エアコン・空気清浄機・UI構築）○アイホン（ドアホン）○NECパーソナルコンピュータ（Benlly）※Benllyを経由してLED照明操作 等

サービス実施

リコール・リサイクルのサービスについて、消費者に身近になるよう、製品ライフサイクルに係る他のサービス（例：使用状況（電力使用量）の見える化、

故障時の修理手配、保証書管理）と一体的に実施。

●日立製作所（サービス提供取りまとめ）○東京電力パワーグリッド（電力使用状況把握）○Warrantee（サービス実施主体）○ヤマトシステム開発（物流） 等

11

第2章 実証事業の概要

本章では、MRI による公募で採択した、積水ハウス、大和ハウス工業、及び日立製作所を各々

幹事会社とする 3 つのコンソーシアムが実施した実証事業の概要を報告する。

2.1. 新規サービス創出のための情報クラウド間連携基盤の実証

本節では、積水ハウスによる実施概要を示す（詳細は第 2 分冊を参照）。

2.1.1. 事業の目的と全体像

経済産業省で示されたスマートホームの将来像のイメージ、検討の方向性等を十分に踏まえ、

スマートホームに関するデータ活用環境整備に関する実証を実施した。

家庭内の機器のネットワーク化やそれによる新たビジネス創出に必要となる事業環境の整備を

目的に行っている。また、実証を通じて、機器間の連携・接続に必要となる一定のルールやセキ

ュリティ・製品安全、プライバシーなどの課題に対し、企業の枠を超えた取り組みの検討を行っ

た。

2.1.2. 実証内容

2.1.2.1～2.1.2.3 の 3 つの項目に関して実証を行った。

2.1.2.1. モニタ募集及び実証環境整備

集合住宅を 3 棟計 31 戸のモニタでの実証を計画し、メーカの異なる複数のネットワーク機器

を設置、機器の制御やデータ取得が行える環境を整備した。また、機器の入替えや搬入、モニタ

への事業内容の説明やデータ活用に関する同意取得等、すべてのモニタ対応を行った。実証実験

環境として、全戸がネットワークにつながる必要があり各戸のセキュリティが担保された環境を

実現するため全戸にホームゲートウェイ（以降、HGW）を設置し、実証期間中はインターネット

への常時接続を行った。

また、本実証でモニタから得られるデータを、クラウド間連携先等に提供することについて、

モニタから同意を得た。設置する対象機器とメーカを表 2-1 に示した。

表 2-1 設置機器一覧

設置機器 メーカ

ルームエアコン シャープ

空気清浄機 シャープ

12

設置機器 メーカ

インターホン アイホン

照明 NECパーソナルコンピュータ

2.1.2.2. 機器間連携のシステム構築

① 全体構成

図 2-1 に示すように、住宅機器及び家電機器の空気清浄機、エアコン、インターホンをネット

ワーク化し、機器ごとのクラウドと接続した。さらに、機器クラウドに対して機器の制御やデー

タ取得を可能とする接続 API を新規開発した。この API を使用して、各機器クラウドに蓄積した

データを取得し、「積水ハウスクラウド」に集約させて蓄積した。

積水ハウスクラウドは、機器クラウドが取得したデータの蓄積だけでなく、各機器の制御を統

一的に管理することが可能となるため、本事業において、家全体のデータ蓄積基盤として活用し

た。また、モニタのお住まいの地域の防犯や天気など「生活情報」を含めた積水ハウスが管理す

る個人情報と機器のデータをクロスさせ、積水ハウスクラウドとセキュアに連携させた。

シャープ、アイホンは「機器クラウド」を構築し、それぞれの家電機器であるエアコン・空気

清浄機、インターホンの制御やデータ取得と蓄積した。NEC パーソナルコンピュータは、「IoT プ

ラットフォーマ」である「plusbenlly」を用いて照明器具の制御を行った。

スマートフォン、音声認識デバイスを使用して、モニタがそれぞれの機器を統一的かつ簡便に

遠隔操作できるユーザインタフェースクラウド（以降、UI クラウドと呼称）をシャープが構築し

た。

図 2-1 機器間連携の全体像

② 機能要件

機器間連携の機能要件について、表 2-2 に示した。

13

表 2-2 機能要件

分類 要件

認証 ① サービス利用者であるモニタに対して、ユーザ ID とパ

スワードによってユーザ認証ができること。

② 実証実験対象の住戸と住戸内の機器に対して紐付けで

きること。

機器との連携 ① 機器との連携が行われるきっかけ（トリガー）は以下の

3 つの場合があり、それぞれの連携ができること。

(ア) モニタがトリガーとなる場合

(イ) 積水ハウスクラウドがトリガーとなる場合

(ウ) 家電クラウド、IoT プラットフォーマがトリガー

の場合

② 機器クラウドと連携するタイミングや間隔を機器毎に調

整できるように積水ハウスクラウドを構築すること。た

だし、これは積水ハウスクラウドの内部処理の要件であ

るため、調整用の画面等のユーザインタフェースは必要

としない。

③ 積水ハウスクラウドは、機器クラウドの API を利用

し、機器クラウドに蓄積したデータを取得できること。

④ 積水ハウスクラウドは、機器クラウドの API を利用

し、機器の制御ができること。

⑤ 機器クラウドから取得したデータを、住戸毎に識別して

積水ハウスクラウドに蓄積できること。

ユーザインタフェース

との連携

1. ユーザインタフェースは、積水ハウスクラウドの API

を利用し、積水ハウスクラウドに蓄積されたデータを

取得できること。

2. ユーザインタフェースは、積水ハウスクラウドの API

を利用して、機器の制御ができること。

3. ユーザインタフェースからのリクエストをログファイ

ルとして保存すること。

③ セキュリティ対策

本事業における機器間連携システムを、「機器」、「ネットワーク」、「プラットフォーム」、「サ

ービス」の 4 階層に分類し、機器をネットワークに接続することによるシステム全体としてのセ

キュリティの課題を整理し、IPA による「情報セキュリティ対策」にある「脆弱性対応ガイドラ

イン」や「安全なウェブサイトの作り方」の指摘を遵守するセキュリティ対策を行った。

14

④ データの汎用性の確保

本事業で蓄積する機器データ等は、CSV 形式などの標準的なフォーマットにより管理するこ

と。これにより、データ利活用を検討するハッカソン等に対する情報提供を可能とする。

「積水ハウスクラウド」は、以下の機能を持ったクラウド環境を構築した(図 2-2 を参照)。

１． UI クラウド連携 Web サービス

(ア) UI クラウドと API による連携を行い、スマートフォンや音声認識デバイスからの遠隔

操作の受信と各機器の操作状態の表示を行う。

(イ) 防犯情報、天気情報等の生活情報を API の連携によって受信し、UI クラウドを通じて

スマートフォンもしくは音声認識デバイスに対して通知を行う。

２． 機器クラウド連携 Web サービス

(ア) 機器クラウドもしくは IoT プラットフォーマと API による連携を行い、各機器の遠隔

操作や機器状態などのデータの取得を行う。

３． データ収集バッチ Web サービス

(ア) 機器クラウドもしくは IoT プラットフォーマと API による連携を行い、各機器のデー

タの取得を定期的（15 分もしくは 30 分単位）に行い、積水ハウスクラウド内へのデー

タの蓄積を行う。

図 2-2 システム構成図

また、積水クラウドと各クラウド間（機器クラウド、UI クラウド、生活情報クラウド）は、ア

クセストークンによる認証を行い、IP アドレスによる流入制限を行うことで、想定外のサイトか

らのアクセスを制限した。

15

図 2-3 機器クラウドとの認証イメージ（例）

2.1.2.3. 社会課題解決に向けたサービス実証

機器の遠隔制御を可能とするサービスを行った。加えて、そのデータを活用する等により、例

えば、高齢者や子供の見守りサービス、食材の宅配サービス等による家事負担の軽減など、社会

課題解決に資するサービスの実証を行った。

積水ハウスでは暮らしサービスの考え方として、「エコ」、「健康」、「防犯」、「お手入れ」、「コミ

ュニティ」、「趣味」に情報を分類し、お客様の生活スタイルに合わせて適宜必要な情報を提供で

きるプラットフォームの構築に力を入れている。今回の実証事業においては、この中から「健康」、

「防犯」、「お手入れ」、「コミュニティ」にフォーカスして、日々の暮らしに必要な情報を楽しく

快適に活用いただける環境を用意した。また、「製品ライフサイクルに関する実証」に関する採択

事業者と連携、協調した。

2.1.2.4. 実施体制及びスケジュール

コンソーシアム形態の実施体制および実証スケジュールを表 2-3、図 2-4 に示す。

16

表 2-3 実施体制図

図 2-4 実証スケジュール

事業者 役割

積水ハウス株式会社 実施主体、契約主体、モニタ募集及び管理、実証実

験工事、管理

日本ユニシス株式会社 積水ハウスクラウド基盤・認証基盤構築、コンソ情

報共有サーバ作成、報告書作成

富士通株式会社 個人情報クラウド連携構築

シャープ株式会社

家電クラウド API 構築（エアコン・空気清浄機）、

ユーザインターフェース構築（スマートフォン・音

声認識デバイス）

アイホン株式会社 家電クラウド API 構築（ドアホン）

NEC パーソナルコンピュータ株式会社 IoT 基盤連携構築、実証実験サポートサービス

東映コミュニケーションズ株式会社 インフラ工事・現場現状復帰作業

株式会社ギガプライズ 宅内通信ログの取得、管理

17

2.1.3. 実証結果

2.1.3.1. モニタ募集及び実証環境整備

本実証事業フィールドに選定した物件は、IT リテラシーの高い、共働きで子供を持たない夫婦

（DINKS）や 3～7 歳ぐらいの小児（トドラー）のいる世帯を入居ターゲットにしている。実証

事業の意義や仕組みについての理解は概ね得られたが、募集時において、IoT 物件であることの

魅力・価値の形成までには至らず、また、外国人入居者を想定していなかったため、外国語対応

ができておらず、参加拒否などの理由により、3 棟 28 戸での実証となった。

図 2-5 モニタ属性（上：世帯主世代、下：家族構成）

機器利用率は全体的に芳しくなく、一定の利用がある世帯であっても入居直後に一定の利用率

はあるものの、その後は減衰する傾向にあることが分かった。原因として、クラウド間連携によ

るレスポンスの悪さ、音声認識の精度や実行までの確認手順がユーザに煩わしさを与えたことが

考えられる。スマートフォンや音声認識デバイスより、設備機器付属のリモコンやスイッチの方

が操作性に長け、一般的にはあまり利用されないことが分かった。

図 2-6 機器利用率（30 代、DINKS）

18

図 2-7 機器利用推移（40 代、トドラーのいる世帯）

図 2-8 機器利用推移（30 代、単身世帯）

モニタ募集時における担当者の声、コールセンター対応履歴、入居者アンケート、入居者訪問

時ヒアリング内容及び機器操作ログを分析し、「ユーザ属性」、「ユーザベネフィット」、「IoT 導入

時のインテグレーション」の 3 つの観点から課題と解決策を整理した。

① ユーザ属性

IT リテラシーの高い DINKS やトドラーのいる世帯であっても利用されるとは限らないという

ことが分かった。前述にあるとおり、操作性に難があったことがその原因であると考えられるが、

一世帯に 1 つのユーザインタフェース（スマートフォン及び音声認識デバイス）であったことも

その原因の一つだと考えられる。一般的に機器操作は世帯の誰もが操作できる必要がある。本実

証においてはユーザインタフェースを一つにまとめることで複数機器を操作することを可能にす

る実証用のスマートフォンを提供したが、一般的には個人のスマートフォンで操作することにな

る。この場合、スマートフォンを持っていなければ操作することができず、従来とおりリモコン

や機器付属のスイッチでの操作になってしまう。つまり、同一世帯に複数人が居住している場合、

複数個所から同時に機器を操作することとなり、操作性があまり良くない。一方、単身世帯では

1 つのスマートフォンから操作できれば良いため、複数人居住の世帯に比べ機器操作に対して抵

抗はなく、機器操作推移からも継続的な利用があることが分かる。

一方、音声認識デバイスは複数人で利用することに長け、1 つのユーザインタフェースで複数

19

人が利用することができる。しかし、本実証においては音声認識デバイスに応えられる部分が少

なく、利用率は芳しくなかった。そのような中、アンケート結果より高齢者は癒し（コミュニケ

ーション）を求め、子どもは親しみ（形状やデザインなど）を求める傾向があるという結果が分

かった。機器操作やサービスについてはユーザ属性に応じたパーソナライズサービスが必要であ

るとの認識に至った。

② ユーザベネフィット

本実証では機器操作と生活情報の提供を主として行ったが、それだけでは満足が得られなかっ

た。機器操作をすることでベネフィットが享受できなければ利用促進につながらないことが分か

った。

機器操作においてレスポンスの悪さや実行に至るまでの手順が煩わしい点が課題としてある。

これはクラウド間連携を行うことにより発生しており、避けては通れず、また、現状の法規制

（電安法）に準拠した手順を再現しているため、煩わしさが生じてしまう。実証後半では、音声

の利用促進として、音声端末から自発的な発話機能を搭載し、使いこなしや興味を引く話題など

で 1 日 1 回ユーザへの語り掛けを実施した。今後音声認識デバイスならではの利便性（手がふさ

がっているときなど）やユースケースの創出が求められる。

ユーザがベネフィットを享受するためには個人情報などを提供する必要がある場合があるが、

そう言った場合にセキュリティ面に関する不安があるかどうか、アンケート結果から、不安は特

に感じられないとの結果を得た。しかし、通信ログを調査した結果から、情報セキュリティリス

クにさらされている実態が発覚した。ユーザは情報セキュリティリスクにさらされている実感が

ない一方で、このような実態があるということは情報セキュリティ対策の周知徹底の必要性があ

ると、言い換えることができる。今後、IoT 社会が拡大する上で、情報セキュリティに対する周

知は必須であると考えられる。ユーザベネフィットを提供するためにはユーザニーズに合わせた

システム構築と万全のセキュリティ対策が必須となる。

③ IoT 導入時のインテグレーション

住宅内に設置する IoT 機器を正しくセットアップし各クラウドサービスへの申込を行うオペレ

ーション、および自分の生活スタイルに合った状況に設定・変更を行うオペレーションは、現状

のオペレーションでは難解・複雑なものになっている。

特に当コンソーシアムのモニタのように不特定多数の一般ユーザを対象にするとなると、IT リ

テラシーが不明な状況下でモニタが積極的に機器を利用した生活を送ることを期待するためには、

ユーザベネフィットが明確になっていてそれを享受したい生活者か、最先端な生活にチャレンジ

する生活者など限定的されたものとなる。本実証では前者の決定的な価値を明確にすることが出

来ない状態でのスタートだったために、実証として成立が困難と考え予めインテグレーションを

実施した状態で体験していただいているが、今後あらゆるレンジのユーザに利用してもらうこと

を考えた場合、導入時のインテグレーションは課題になると考えている。

新築であれば同様の作業は引渡し前に実施できるが、既存住宅など中古市場においては価値を

明確化した上でこの課題解決のためにインテグレーションサービスも含めて実施できる仕組みや

体制を構築していく必要があると考える。

20

2.1.3.2. 機器間連携のシステム構築

以下に機器間連携のシステム構築を行う上での課題について、記載する。

① 連携方針の齟齬

➢ 問題

プロジェクト開始時に連携方法等について各連携先と共有していたが、仕様のすり合せ

を行うと各社で仕様の齟齬が発生していることが判明した。そのため、当初の連携方法

から逸脱した仕様に対する確認や再調整を行う必要があり、作業の手戻り等が発生した。

➢ 解決策

政府もしくは業界団体主導でクラウド接続の標準仕様を策定し、連携方法の明確化、API

の雛形化、各機器のパラメータの共通化を図ることが必要ではないかと考える。接続元、

接続先がプロジェクト開始時にともに合意した仕様を共有することで開発のリードタイ

ム短縮が図ることができ、仕様の認識の齟齬から発生する手戻りを防止できることが予

想される。

② 責任分界点

➢ 問題

IoT プラットフォーマ経由で照明設備との連携を行ったが、IoT プラットフォーマから

先の照明設備との連携については、責任分界点が曖昧なまま接続を行っていた。そのた

め、トラブルが発生すると照明設備部分が海外メーカとの接続の事情もありブラックボ

ックス化してしまった。

➢ 解決策

プロジェクト開始時、IoT プラットフォーマとの接続においても責任分界点を明確にし

て同意することが必要であるではないかと考える。更に IoT プラットフォーマの先にあ

る機器との接続についても接続が正常なのか異常なのかを判断する手段を提示してもら

い、トラブル発生時に問題がどこにあるのかを明確にすることでブラックボックス化・

問題の長期化を防ぐことができると考える。また、この合意形成のプロセスを標準化す

ることが同じトラブルを起こさないための方策と考える。

③ クラウドのトラブル、メンテナンスの情報公開

➢ 問題

クラウドのトラブル時の対応方法や各クラウドのメンテナンス時の連携方法の仕様やル

ールを策定していなかったため、トラブルが発生した場合、連携先のシステムがクラウ

ドの障害を検知することができなかった。メンテナンスの連絡についても手動での対応

で行ったためモニタへの告知までの効率が悪かった。

➢ 解決策

クラウド間連携におけるトラブル発生時の検知方法やメンテナンス情報の共有など運用

ルールの標準仕様を策定し、トラブル発生時やメンテナンス実行時の連絡方法や利用者

への告知方法を標準化する。

21

④ データ量

➢ 問題

各機器から取得できる情報を定期的に取得して、その情報をデータベースに蓄積してい

たが、機器や対象の住戸が増えれば増えるほど、蓄積したデータのレコード数が増加す

る。そのため、ユーザインタフェース上で過去 1 ヶ月の稼動履歴を調べようとすると、

検索自体に時間がかかるためユーザインタフェース上の表示の利用には使えなかった。

➢ 解決策

蓄積する値が前回値と異なる場合のみ蓄積するような対応を行うことで、データ量が増

えないような対策を行うことが必要である。

2.1.3.3. 社会課題解決に向けたサービス実証

本実証で用意した 4 つのコンテンツのうち、「コミュニティ」、「防犯」の利用が多く、「健康」、

「お手入れ」の利用はあまり見られなかった。日々の暮らしに必要な情報であることがその要因

と考えられる。各コンテンツについて、以下のとおり結果を整理した。

① 健康（熱中症予防）

➢ 熱中症のリスクが高まり温湿度になるまでエアコンを利用しないケースは少なく、本サ

ービス単体ではあまり効果がないことが分かった。本実証では実現し得なかったが、高

齢者や子どもの見守りサービスなど、サービスを複合的に提供することでサービスの質

向上が期待される。

② 防犯（防犯通知、在宅装い）

➢ 防犯通知の閲覧は約半数で見られたものの、在宅装いの利用はあまり見られなかった。

普段の生活において、防犯への意識はあるものの対策を講じるまでに至らないことが分

かった。また、在宅装いサービスの利用方法としては長期休暇時の利用であり、平日不

在時の利用は見られなかった。建物自体のセキュリティ対策で充分であったこと、サー

ビス利用時の設定に煩わしさを覚えたことが日常的な利用に至らなかった原因と予想さ

れる。各種センサとの組合せや音声認識デバイスから設定させるなど、サービスの利用

を簡単にすれば積極的な利用に繋がり、防犯に対する意識がさらに向上するものと考え

られる。

③ お手入れ情報（住まいの長寿命化、製品安全）

➢ 定期的なメンテナンス、正しい使用方法に準拠した機器類の取扱いは建物、住宅設備機

器の長寿命化、製品安全を実現するにあたり必須である。しかし、本実証フィールドは

賃貸住宅であることから、メンテナンス等への意識が低く、お手入れ情報の取得率の低

さに影響したものと予想される。また、メンテナンスや正しい使用方法は不具合が起こ

った場合に意識されるものであることが利用率に影響したと考えられる。入居者への意

識付け、戸建と賃貸の違いなど、検討すべき課題が明確になった。

22

④ 生活情報（天気予報）

➢ 日常的に利用されるコンテンツであることから、利用率が最も高かった。アンケート結

果からも天気予報の利用が多いことが分かる。

また、社会課題解決に向けたサービス実証課題と対策について、以下のように整理した。

本実証において 4 つのサービスコンテンツを用意したが、日常的に利用されるには至らなかっ

た。ベネフィットが明確でなかったことが原因と考えられる。サービス提供時にはベネフィット

が具体的に分かる動画コンテンツ等を用意し、ユーザに利用してもらえるような動機付けが必要

になると考えられる。また、お知らせメール、プッシュ通知機能等を利用し、コンテンツの定期

的な利用を促す仕掛けも必要だと考えられる。

社会課題解決に対し、機器操作（遠隔）やデータ利活用におけるサービス提供、音声認識デバ

イスなどが、少なからず効果的であることということが分かった。本実証では限られた期間、コ

ストなどの理由から、機能やサービスを画一的に構築したが、データや機能、さらに個人情報や

属性、世代などを複合的に組合せたパーソナライズされたサービスを実現することが社会課題解

決の実現に繋がると考えられる。

2.1.4. 実証を通じた論点の整理

2.1.4.1. データカタログ

機器が扱う基本データについて機器横断的に共通するものを可能な限り集約し整理した。（表

2-4 基本データ）また、機器レベルの API を想定したデータ基本要素だけではなく、家の中の多

様な機器データを統合した家全体の API、ライフスタイルの API を提供するための共通概念（要

素）を整理した。サービスとも近い領域だが、最終サービスを開発するための基盤として再利用、

組み合わせて利用できるデータ（表 2-5 高次データ）を対象とする。

23

表 2-4 基本データ

データ名

（データ種別）機器種別 データ意味

データ項目・単

位

通信方式

（プロトコル）拡張属性 利用データ 関連情報

動作状態エアコン、空気清浄機

機器の動作状態 ON/OFFhttps (RESTful API), web

socketは含まないなし 機器の内部状態 ECHONET Lite規格書

設置場所エアコン、空気清浄機

機器の設置場所 設置場所https (RESTful API), web

socketは含まないなし 人間が入力した値 ECHONET Lite規格書

瞬時消費電力エアコン、空気清浄機

瞬時消費電力 単位Whttps (RESTful API), web

socketは含まないなし 機器のセンサ値 ECHONET Lite規格書

積算消費電力エアコン、空気清浄機

積算消費電力 単位0.001kWhhttps (RESTful API), web

socketは含まないなし 機器のセンサ値 ECHONET Lite規格書

異常発生状態エアコン、空気清浄機

異常発生有/無 有/無https (RESTful API), web

socketは含まないなし 機器の内部状態 ECHONET Lite規格書

風量設定エアコン、空気清浄機

風量レベル 風量https (RESTful API), web

socketは含まないなし 機器の設定値 ECHONET Lite規格書

運転モード設定エアコン、空気清浄機

運転モード 運転モード名https (RESTful API), web

socketは含まないなし 機器の設定値 ECHONET Lite規格書

温度設定値 エアコン 温度設定値 単位℃https (RESTful API), web

socketは含まないなし 機器の設定値 ECHONET Lite規格書

室内相対湿度計測値エアコン、空気清浄機

室内相対湿度計測値 単位％https (RESTful API), web

socketは含まないなし 機器のセンサ値 ECHONET Lite規格書

室内温度計測値エアコン、空気清浄機

室内温度計測値 単位℃https (RESTful API), web

socketは含まないなし 機器のセンサ値 ECHONET Lite規格書

外気温度計測値 エアコン 外気温度計測値 単位℃https (RESTful API), web

socketは含まないなし 機器のセンサ値 ECHONET Lite規格書

空気汚れ検知状態 空気清浄機 空気汚れ検知有/無 有/無https (RESTful API), web

socketは含まないなし 機器のセンサ値 ECHONET Lite規格書

スマートフォンによる動

作状態制御

エアコン、空気清浄機

スマートフォンから

の動作状態の制御動作状態 https

スマホアプリの利用状況の

算出ECHONET Lite規格書

スマートフォンによる風

量制御

エアコン、空気清浄機

スマートフォンから

の風量の制御風量 https

スマホアプリの利用状況の

算出ECHONET Lite規格書

スマートフォンによる運

転モード制御

エアコン、空気清浄機

スマートフォンから

の運転モードの制御風量 https

スマホアプリの利用状況の

算出ECHONET Lite規格書

音声端末による動作状態

制御

エアコン、空気清浄機

音声端末からの動作

状態の制御動作状態 https 音声端末の利用状況の算出 ECHONET Lite規格書

音声端末による風量制御 エアコン、空気清浄機

音声端末からの風量

の制御風量 https 音声端末の利用状況の算出 ECHONET Lite規格書

音声端末による運転モー

ド制御

エアコン、空気清浄機

音声端末からの運転

モードの制御風量 https 音声端末の利用状況の算出 ECHONET Lite規格書

リモコン等による動作状

態制御

エアコン、空気清浄機

リモコンからの動作

状態の制御動作状態 https

クラウド経由の機器操作の

比率の算出ECHONET Lite規格書

リモコンによる風量制御 エアコン、空気清浄機

リモコンからの風量

の制御風量 https

クラウド経由の機器操作の

比率の算出ECHONET Lite規格書

リモコンによる運転モー

ド制御

エアコン、空気清浄機

リモコンからの運転

モードの制御風量 https

クラウド経由の機器操作の

比率の算出ECHONET Lite規格書

スマートフォンによる温

度制御エアコン

スマートフォンから

のエアコンの温度設

定値の制御

温度(℃) httpsスマホアプリの利用状況の

算出ECHONET Lite規格書

音声端末による温度制御 エアコン

音声端末からのエア

コンの温度設定値の

制御

温度(℃) httpsスマホアプリの利用状況の

算出ECHONET Lite規格書

リモコンによる温度制御 エアコン

リモコンからのエア

コンの温度設定値の

制御

風量 httpsクラウド経由の機器操作の

比率の算出ECHONET Lite規格書

24

表 2-5 高次データ

また、機器制御およびクラウド間データ連携 API について、ECHONET Lite に準拠して構築

し、データ連携のフォーマットは JSON、通信プロトコルは HTTPS を使用した。ECHONET Lite

を採用した理由として、機器メーカに依存しない中間的なデータ形式であるためである。

今回の実証では 1 機種 1 メーカという扱いになったため検証が難しかったが、1 機種複数メー

カとなった場合のクラウド間 API 仕様について、今回の仕様をベースにすることで開発費用を抑

えることが可能になると期待している。また、機器が扱う基本データ単体を抽出して分析を行う

場合、生活パターンなどの予測には限界がある。一方、電力データなど、複数のデータを組み合

わせて分析を行った場合、ある一定レベルでの予測をすることができる。ただし、個人特定や詳

細な行動までは推測できない。人感センサ、照度センサ及びガス・水道などの情報を組み合わせ

ることで精度の高い分析が可能になると期待している。

2.1.4.2. セキュリティ・製品安全

セキュリティ対策基本事項と実施観点について、ハウスメーカ、システムインテグレータ、機

器メーカの各視点でセキュリティ対策内容を表 2-6 セキュリティ対策項目に整理した。

データ名

（データ種

別）

データカテゴ

リデータ意味

データ項目・単

位

通信方式

（プロトコル）拡張属性 利用データ 計算方式 関連情報 活用サービス例

（DINKS生活

スタイル）起

床時刻

生活パターン指定時刻帯における

行動確率確率（％） － －

[宅内データ]エアコン操作履歴、空気清浄

機操作履歴、電力消費、室内温度平日・休日における活動パターンを平均化し予測 －

（DINKS生活

スタイル）睡

眠時刻

生活パターン指定時刻帯における

行動確率確率（％） － －

[宅内データ]エアコン操作履歴、空気清浄

機操作履歴、電力消費、室内温度平日・休日における活動パターンを平均化し予測 －

（DINKS生活

スタイル）外

出時刻

生活パターン指定時刻帯における

行動確率確率（％） － －

[宅内データ]エアコン操作履歴、空気清浄

機操作履歴、電力消費、室内温度平日・休日における活動パターンを平均化し予測 －

飲食料品の最適な提

供量提示

（DINKS生活

スタイル）帰

宅時刻

生活パターン指定時刻帯における

行動確率確率（％） － －

[宅内データ]エアコン操作履歴、空気清浄

機操作履歴、電力消費、室内温度平日・休日における活動パターンを平均化し予測 －

飲食料品の最適な提

供量提示

（DINKS生活

スタイル）食

の志向

（内食・外

食）

生活パターン曜日別における行動

確率確率（％） － － [宅内データ]家電別電力消費 平日・休日における活動パターンを平均化し予測 －

飲食料品の最適な提

供量提示

（DINKS生活

スタイル）洗

濯予測

生活パターン曜日別における行動

確率確率（％） － －

[宅内データ]家電別電力消費、電力消費

[宅外データ]天気予報平日・休日における活動パターンを平均化し予測 －

邸宅出入り 生活パターン玄関からの出入り情

報

https (RESTful

API), web

socketは含まな

い

玄関での人感センサー

画像データ

ドアセンサー（出入り判断）

天気予報

ドアセンサー＋人感センサーによる出入りの判断

・ドアセンサーON+人感センサー感知⇒出

・ドアセンサーOFF+人感センサー感知⇒入

出入りする人をカメ

ラで撮影して出入り

を通知する

出入りする人に対し

て挨拶や天気情報を

通知する

家電利用状況 生活パターン家電の利用状況と故

障予測確率（％）

https (RESTful

API), web

socketは含まな

い

データカタログ基礎レベルデータ（電力消

費量、家電操作履歴）

ON/OFF操作履歴と電力消費量から操作した家電の電

力使用量を算出する

ON/OFF操作履歴、電力の消費実績をもとにディープ

ラーニングを行い、故障予測を行う

ECHONET Lite規格

書

機器メンテナンス通

知

居住者の生活異常通知生活パターン居住者の生活異常検

出とPUSH通知

異常種別、緊急

度等TBD TBD TBD TBD 見守りサービス等

連絡可否Statusの確認 生活パターン連絡可否Status確認

API

連絡可否受容度

（4段階など）TBD TBD TBD TBD 宅配サービス等

25

表 2-6 セキュリティ対策項目

実証後

実証事業における実施内容「セキュリティ対策指針」の除外・追加す

べき項目とその理由

「セキュリティ対策指針」の必須/任意の

変更の必要性

①経営層によるコミット（必

要なリソースの割当等）

社内経営層および法務部門向けに実証事業の内容を説明（ハ

ウスメーカ）

システム開発上のセキュリティ対策推進部署によるセキュリ

ティ対策基準やプロセスを策定（システムインテグレータ）

IoTを含む製品セキュリティに対する組織体制を構築。定期

的なWGの開催及び組織横断的にノウハウや情報共有を実施

（機器メーカ）

-

担保すべき個人情報に対するセキュリティ

ポリシーにはあらかじめ決められている対

策が実施されるよう、ベンダーへ開発委

託。開発する規模により考慮すべき内容が

異なってくるため予算やリソース割り当て

は明記し難い（ハウスメーカ）

②PDCAサイクルによる改善

の仕組みを導入する

実施していない（ハウスメーカ）

社内の開発セキュリティプロセスに従い、セキュリティレ

ビュ、脆弱性検査を実施（システムインテグレータ）

未然にセキュリティリスクを軽減するための取り組みをWG

の中で検討（機器メーカ）

HGWを含めた通信デバイスの選択は住宅

購入者が行うためハウスメーカの保守責任

範疇ではない。ハウスメーカとしてはセ

キュリティが担保されたデバイス、宅内イ

ンフラを推奨するところまで（ハウスメー

カ）

必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

①守るべきものの特定、つな

がることによるリスク、アー

キテクチャ、物理的なリスク

とその範囲を考慮する(内部不

正やミスの発生を考慮する）

システムをサービスレイヤで分類し（UI、プラットフォー

ム、機器）、各レイヤごとにリスク評価を実施、アーキテク

チャに反映。守るべきデータを特定し、つながることによる

リスクを洗い出し、リスクを評価し、対策をシステムに反

映。

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

②プライバシー情報漏洩のリ

スクと影響分析の実施

システムをサービスレイヤで分類し（UI、プラットフォー

ム、機器）、各レイヤごとにリスク評価を実施し、対策をシ

ステムに反映

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

①セキュリティ、セーフ

ティ、プライバシーの影響を

考慮した設計(Security,

Safety, Privacy by Design：

SSPbD)

機器のセキュリティ対策については限度があるため、機器側

で任意の入力を受け付けないようにする事でセキュリティリ

スクを低減する設計としている。具体的には機器側にサーバ

を持たせる事はせず、クラウド側に機器側から接続をして双

方向通信のセッションを行う等、攻撃できる箇所を機器側に

持たせない設計としている。

クラウド基盤構築において製品安全が担保

されたIoT機器と接続することを前提とし

ているため

必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

②遠隔操作における製品安全

に係わる問題の考慮

家電製品の制御については、遠隔操作後に操作完了通知の受

信もしくは、一定時間後に機器の状態を取得して行った制御

が完了していることを確認。電気用品安全法に基づき適性に

設計を実装。※機器メーカーのAPIを活用した第3者のサービ

スに対しては、その対応が電安法に基づく適正設計となって

いることを認証（証明）する方法が現時点ではなく、自主的

な対応として実装

クラウド基盤構築において製品安全が担保

されたIoT機器と接続することを前提とし

ているため

制御後の検証の実施（システムインテグ

レータ）

③安全安心を実現する設計の

検証の実施

社内のセキュリティ検査対策部門によりセキュリティプロセ

スを策定。※WebAPについての約200項目のセキュリティ項

目のチェックを実施

IoTによる接続の有無に関わらず、製品のデザインにおい

て、DRを行う等の検証を継続実施

クラウド基盤構築において製品安全が担保

されたIoT機器と接続することを前提とし

ているため

インジェクション対策や、不正なパラメー

タのチェックなど基本的なリスクの対策の

実施の確認の追加（システムインテグレー

タ）

④多層防御（多重のセキュリ

ティ対策の考慮）

DMZ、内部セグメントの各レイヤごとにセキュリティ対策を

実施。ファイアウォール、WAFの設置、IPS（不正侵入防

御）、IDS（不正侵入検知）、APIキー認証、IPアドレス制

限、ウィルス検知

- -

⑤ログ・監視機能の導入

ファイアウォールの通信、IPS（不正侵入防御）、IDS（不正

侵入検知）を監視し記録。クラウドシステム側においてログ

の収集を行っており、商用運用しているサーバは365日24時

間監視の対象として実施

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

⑥主要IoTセキュリティガイド

ラインの考慮(OWASP/IoT

Top 10等）

なし

クラウド基盤構築において製品安全が担保

されたIoT機器と接続することを前提とし

ているため

-

⑦つながる相手のリスクを回

避する設計

自社内で閉じずに連携する場合には必ず接続先を識別できる

形で接続をしているので、万一不都合が発生した場合には特

定の接続先のみを遮断する仕組みを用意

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

⑧つながる相手に損害を与え

ない設計

⑧と同様に他社から当社の接続である事を識別できる形で連

携するようにする事で、問題が生じた場合は先方から接続を

遮断できるように設計

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

⑨認証機能、暗号化の導入必

要性の検討（参考

www.cryptrec.go.jp）

CRYPTRECや世の中のIT企業の動静等も参考にしながら、認

証や暗号化の強度の検討を行っており、必要に応じてネット

ワーク経由でセキュリティ強度の改善を継続実施

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

①設計を満たす実装であるこ

とのテストの実施

認証方式のテスト、クラウド間連携におけるパラメタの正当

性確認の実施、および設計側評価、第三者期間による評価の

双方を実施。

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

②構築（インテグレーショ

ン）時の設定等の検証各クラウドとの接続をサービス提供前に検証 - -

③機器の状態把握、記録機能

の実現

CPU使用率、メモリ空き容量、ディスク空き容量、イベント

ログ、IISログ、不正侵入を監視し記録。IoT機器はクラウド

側に主たる機能が存在するので接続ログ=機器の状態把握と

して実現。

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

①消費者へのリスクの周知入居問合せ時に専用チラシで説明後、入居契約時において当

社特約店による詳細説明。- -

②サービス追加・連携におけ

る検証と利用者同意の実施

しおり実装完了。小規模な機能追加は随時実施しUIでお知ら

せ。製品ライフサイクルの同意取得に協力。- -

③モニタリングと異常検知の

実施

CPU使用率、メモリ空き容量、ディスク空き容量、イベント

ログ、IISログ、不正侵入を監視し、異常検知を実施。機器の

接続ログより機器の状態監視を実施。

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

④機器設置後の不具合（脆弱

性）の確認とアップデートの

実施

脆弱性レポート(CVNやJVN)の定期的な確認を行い製品セ

キュリティWGより社内関係部署へ展開と、ネットワーク機

能を有する通信モジュールに対するソフトウェアのOTAアッ

プデートを実施。

-必須か任意かは各ベンダが規定するもので

はなく、世の中の基準によって決めるべき

実証初期に記入セキュリティ対策指針

（チェックリスト）

1. 基本方針の

策定

2. リスク評価

5. 運用・保

守・廃棄の対

策

4. 実装・構築

時の対策

3. 設計時の対

策

対策区分

26

また、各クラウドで守るべき対象を整理し、図 2-9 のとおり検討した。また、クラウド間の API

連携を許可するための認証方式として、不正な API 利用を防ぐ目的でアクセストークンや API キ

ー認証を採用した。更にアクセストークン、API キーの漏洩対策として、HTTPS 通信を採用し、

表 2-7 のとおり構築した。

図 2-9 クラウド間連携図

表 2-7 認証方式について

NO 認証する側 認証される側 認証方式 シナリオ例

① UI クラウド UI デバイス ID・パスワード認証 スマートフォンからロ

グイン

② 積水ハウスク

ラウド

UI クラウド アクセストークンによる

認証

IP アドレスアクセス制限

機器制御、蓄積データ取

得

③ 生活情報クラ

ウド

積水ハウスク

ラウド

API キー認証

IP アドレスアクセス制限

生活情報（気象）取得

④ 積水ハウスク

ラウド

生活情報クラ

ウド

API キー認証

IP アドレスアクセス制限

生活情報（防犯）通知

⑤ 機器クラウド 積水ハウスク

ラウド

アクセストークンによる

認証

IP アドレスアクセス制限

機器制御、機器情報取得

⑥ 機器クラウド 機器 デバイス認証 機器制御、機器情報取得

27

NO 認証する側 認証される側 認証方式 シナリオ例

⑦ 積水ハウスク

ラウド

機器クラウド 署名での認証

IP アドレスアクセス制限

機器状態通知

⑧ UI クラウド 積水ハウスク

ラウド

API キー認証

署名での認証

IP アドレスアクセス制限

ユーザインタフェース

に通知

スマートフォンや音声認識デバイスでの遠隔操作については、同時に複数箇所からの遠隔操作

を受付けないように、機器・機器クラウド・ユーザインタフェースに対して認証を行い、認可さ

れた場合に対して遠隔操作を可能とするルールを構築した。一方、課題として事例に挙げると、

昨今のエアコンは電源を OFF とした場合、自動でフィルター掃除モードに入るものがある（動作

状態はユーザインタフェース上、ON のまま）。スマートフォンから遠隔制御でエアコンを OFF

とした場合、フィルター掃除モードで運転しているため、ユーザは OFF にしたつもりが、ON の

ままとなっているように見えてしまう。このようにユーザ側の認識と本来の運転状況が異なるケ

ースが発生するため、ユーザが困惑しないような配慮が必要であり、またメーカ毎に機能が異な

る可能性があるため、その配慮も必要である。

また、情報セキュリティ脅威に対してのセキュリティ・製品安全の観点から、ネットワーク機

器のモニタリング及びログ管理を実施した。実施方法としては、ネットワーク機器（HGW）のモ

ニタリングを常時実施し、障害発生時にログ解析を行う運用とし、ログ蓄積期間は 2017 年 8 月 4

日～2018 年 1 月 31 日とした。ログ解析の結果、Mirai 等による IoT デバイスに対する不正アク

セスのための攻撃があった。ルータの通信ログから一般家庭においても常に情報セキュリティの

脅威にさらされているという実態が明らかになった。本実証事業においては前述のセキュリティ

対策を講じたことで障害は起こらなかった。情報セキュリティの脅威にさらされながらも内部感

染は発生しなかったことから、ある一定水準の有効性があると判断できる。さらにパケットの取

得・分析を行うことで、不正アクセスの抑止となると考えられる。ルータ等にパケットキャプチ

ャの取得を標準化するような対策が必要だと考えられる。

2.1.4.3. プライバシーデータの活用／サービスの創出

本実証にて条件となっている第三者機関における情報利用について、全入居者様に対して積水

ハウスが定める「モニタ契約書」を交わしてお客様の同意をいただいた。契約書では個人情報の

定義や取扱い及び利用目的について示しているが、文章のみの場合、双方の理解に齟齬が生じる

懸念があったため、図 2-10 宅内における IoT 機器利用情報及び表 2-8 取得データの種類と利

用目的の図表を用い明確にした。

28

図 2-10 宅内における IoT 機器利用情報

表 2-8 取得データの種類と利用目的

家電 情報 利用用途

エアコン 温度・湿度情報 室内外環境サービスに利用。

ユーザ操作情報 正しくシステムが動作しているかの監視・評価。

遠隔・自動制御情報 正しくシステムが動作しているかの監視・評価。

空気清浄機 温度・湿度情報 室内環境サービスに利用。

遠隔・自動制御情報 正しくシステムが動作しているかの監視・評価。

ＴＶドアホン 来訪者ログ 来訪者確認サービスに利用。

来訪者画像 来訪者確認サービスに利用。

音声対話ロボット 音声発話ログ 正しくシステムが動作しているかの監視・評価。

音声会話ログ 正しくシステムが動作しているかの監視・評価。

照明（スタンド） 自動制御情報 各サービス通知制御のための状態監視・評価。

スマートフォン 機器操作、通信ログ 正しくシステムが動作しているかの監視・評価。

センタールータ 全体通信ログ 実証事業の検証活動（情報セキュリティ分析）に利

用。

プライバシーやセキュリティに関するリスクについては普段からスマートフォンを使用してい

ることもあり、もともと一定の理解があった。一方で、本実証事業で取り扱われるデータの内、

プライバシーに関わるものは何か、その対象が明確に理解し難く、個人によって捉え方が異なっ

た。データ活用からサービス創出を行うためには、データの取扱いについて明確な取り決めが必

要であると考えられる。

29

また、個人情報の取扱いについては、個人が特定されない形での利用と目的を強調することで

概ね理解を得ることができた。国の実証事業の一環であることが安心感につながった側面もある

と考えられる。

2.1.5. スマートライフの今後に向けた考察、提言

2.1.5.1. サービスプラットフォームのあり方について

生活者がベネフィットと感じるサービスは、その生活者の価値観や嗜好に大きく左右され万人

にうけるものを創出するのはかなり難しい。生活者ひとりひとりの趣味嗜好や時代で変化する生

活様式を背景としたベネフィットを提供できるかがサービスの成否を決めると言える。このため

には住まい手に寄り添い、どのような生活を送っているかを把握する必要があるが、そこには個

人情報の問題や家電をはじめとした遠隔制御の課題が残る。特に複数のサービス事業者と共に企

画するサービスを提供する場合などは、企業間である程度の個人情報の授受が発生するため、お

互いに対策を講じる必要がある。結果、ユーザインタフェースは煩雑なものになってしまい、こ

れがサービス購入の手間としてユーザから敬遠されやすい一因であることが本実証でも明らかに

なった。サービスを受けやすくなるような企業間情報伝達のルールを整備することで、連携部に

かかる開発運用費用を最小に抑えることが出来れば、多くのサービス事業者と繋がることが可能

になり、その数をベースに様々な住まい手にサービスをレコメンドしやすい仕組みを提供できる

可能性がある。

2.1.5.2. 企業間連携の壁

本実証で複数の企業クラウドとの連携を実装し、具体的な情報通信を確立したがその通信で利

用するフォーマットは機器メーカ毎に異なるためそれぞれに構築する必要がある。今後サービス

事業者を含め様々な企業との接続を推奨するのであれば、宅内機器接続に関して定義がある

ECHONET Lite のようなクラウド間の通信仕様の標準化が必要と考える。

同時にサービス事業者によってはクラウドサービスを持っていない企業が多々あり（むしろそ

ういう企業の方が良いサービスを持っている）、これらが積極的に利活用できるパブリックな共通

プラットフォームが整備出来ると参画しやすい環境が出来るのではないか。

また、クラウド間連携を実施するにあたり、各社によって仕様が異なるため、仕様の統一また

は、異なる仕様であった場合でも自動的に追加あるいは組み込める仕組みづくりが必要である。

ガイドラインを策定することで様々な企業やサービス事業者が参画しやすい環境を構築すること

ができると考えられる。一方、企業間で連携を行う場合、責任分界点を明確にすることが必須で

あると考えられる。ガイドラインと責任分界点とが明確になれば企業間連携サービスは広く一般

化されると考えられる。

2.1.5.3. 法整備の必要性

例えば電気錠やシャッターなど住宅電気設備に対する制御、特に遠隔での活用を考えた場合に

30

どのガイドラインに準拠すべきか、またどのような規制や制約が存在するのかなど、本実証の企

画段階においてベンチマークとなるものを見つけることが出来なかった。電気錠などはBluetooth

などを利用した簡易的なものも存在しているが、万一の事故などに対してどのような対策を打て

ばよいのかなどの指標を示すべきではないか。ただし、その内容をいかようにも解釈できてしま

う表現は市場を混乱させるだけであり、参入しようとする企業が同じ見解となるような具体的な

表現が必要だと考える。

2.1.5.4. 実証事業の在り方（本実証を踏まえ）

入居者と賃貸借契約を交わす前の段階でスマートホーム環境を整備し、実際に操作可能な状態

を説明することで、理解度とベネフィットへの期待度が向上すると考えられる。サービス利用の

様子（住戸内外での機器操作の様子やスマートフォン上のユーザインタフェース画面等）を動画

にして見せることが、サービスそのものへの理解やベネフィット体感に有効な施策と考えられる。

また、本実証では、モニタが元々所持するスマートフォンで操作できる環境の整備（セキュリテ

ィ、プライバシーの問題はあるが）が必要であったと考えられる。

IT リテラシーが高いとはいえ、一般的にスマートホームについての認識はまだまだである。機

器操作を音声認識デバイスで行い、室内環境やバイタルをセンシングし、見える化をすることは

現時点でも可能ではあるが、それ以上にユーザベネフィットを与えるには至っていない。ユーザ

にとってベネフィットとなるものは何かを予め検討し、それに対したサービスを提供することが

実証事業の効果を高めたのではないか。

31

2.2. IoTを活用したスマートホームクラウド構築及び検証

本節では、大和ハウス工業による実施概要を示す（詳細は第 3 分冊を参照）。

2.2.1. 事業の目的と全体像

提案のコンセプトは、「スマートハウスと IoT の課題をクラウド連携で解決し、機器単体ではで

きない複合的なサービスにより、新たな付加価値創出に繋げる」こととした。

図 2-11 提案コンセプト

2.2.2. 実証内容

以下の 3 つの項目に関して実証を行った。その概念図を図 2-12 に示す。UI クラウドを中心に

様々な機器やサービスが連携されているが、主に下半分が機器やサービスを接続する為の技術的

なレイヤを示し、上半分が連携した機能を活用したアプリケーションやサービスレイヤを示す。

32

図 2-12 開発する情報基盤のイメージ

まず、下半分の技術的なレイヤについて説明する。接続する機器やサービスは、①気象情報等の

Web サービスや各種センサ等の IoT 機器、②家電メーカ等が提供するクラウドサービス、③

ECHONET Lite 機器を統合するホームゲートウェイの三つに大別される。①はヤフーが提供す

る API 連携サービス myThings developers を活用したもので、既に連携されている 42 種類（2018

年 1 月時点）の Web サービスや IoT 機器と一気に接続することができる。②は各社クラウドと直

接連携するものであり従来から行われているものであるが、外部公開を前提とした WebAPI を通

じて連携を行った。③については、ホームゲートウェイに実装したローカル API（大和ハウス工

業では住宅 API と呼称）をクラウドから呼び出す事で、ホームネットワークに接続された

ECHONET Lite 機器のモニタリングや制御を行う。クラウドとの通信には IoT で一般的な通信

プロトコルである MQTT の PUB、SUB を活用し、リアルタイムに近い制御を実現している。

次に上半分のサービスレイヤについて説明する。最大の特徴は、下半分で連携した機能を企業

内だけでなく外部の事業者からも活用できるよう実装した統合 WebAPI の提案である。REST に

準拠し、HTTP リクエストを投げる事で接続した機器のモニタリングや制御を行う事ができ、結

果は JSON 形式で返却される。スマートフォンによるエアコンの遠隔制御や施錠確認といったサ

ービスに活用できるだけでなく、同時に音声認識端末による音声での制御に活用できる。今回の

実証では、下半分のレイヤで統合した IoT 機器や Web サービス、ECHONET Lite 家電機器を統

合的に扱えるスマートフォン画面開発や、音声認識対応の家庭用ロボットを活用した音声コント

ロールサービスの開発を行った。

33

2.2.2.1. モニタ募集及び実証環境整備

つくば市の分譲住宅地を中心とした 33 件の住宅に設置し、モニタリング評価を計画した。図

2-13 に示す IoT センサやスマートメーター、エアコンや LED 照明等を設置し、評価を行った。

評価のポイントとしては、以下の 2 点である。

① 個別画面（アプリ）と、統合的な UI 画面での閲覧・操作の比較

② スマートフォンによる閲覧・操作と音声による通知・操作の比較

①については、個々のスマートフォンアプリで閲覧・操作をする場合と、それらの機能を統合

した Web 画面での閲覧・操作との比較を行うものである。

②については、現在主流であるスマートフォンのタッチパネルでの操作と、新たなユーザイン

タフェースとして注目されている音声による通知やコントロールの比較を行うものである。音声

認識デバイスにはユカイ工学が販売しているコミュニケーションロボット「BOCCO」を今回の

実証向けにカスタマイズ開発したものを使用した。また、シャープが開発中の「ホームアシスタ

ント」も活用した。

図 2-13 モニタ概要

また、開発した UI クラウドを活用し、図 2-14 に示す機器を設置することとした。

34

図 2-14 モニタ実証システム概要

①の ECHONET Lite(HEMS)系の機器としては、新たに開発したホームゲートウェイを活用

した三菱電機のエアコン制御、既設の HEMS を活用した消費電力収集や東芝エアコン制御を行

う。②のメーカクラウド系は、パナソニック、シャープが提供する家電遠隔操作サービスを活用

した、各社エアコン制御、シャープが開発中の音声認識端末「ホームアシスタント」による音声

制御や通知を行う。また、IIJ が提供するスマートメーター経由での消費電力収集を行う。③の

myThings developers 系では、鍵開閉センサやドアホンセンサを活用した動作履歴収集、LED

照明や iremocon によるエアコン制御を行う。

通信機器とクラウドサーバーとの接続は、モニタ家庭のインターネット回線の種類や不具合に

影響されないよう、専用の通信 SIM カードを使って接続した。近年では低速で通信量も少ない

IoT 機器に特化した通信サービスが普及しており、例えば soracom 社であれば基本料金が 300

円/月で SIM の発行から通信速度設定、規定の通信量を超えた際の通知や利用制限等のサービス

が利用できる。過去の自社 HEMS 販売を通じて、設置時の簡便さやその後の保守を考慮すると

専用の通信回線で直接クラウドと接続する方が、メリットが高いと判断したものである。

35

UI クラウド経由で取得可能なデータについて表 2-9 に示す。大別すると、①設置されている機

器の数や種類といった基本情報、②エアコンを制御する際に提供される機能や指定できるパラメ

ータの範囲といった制御可能な機器の情報取得、③玄関錠の開閉や消費電力量など機器の動作履

歴、④機器のステイタスや瞬時電力といった状態取得が可能となっている。

表 2-9 モニタ家庭より収集したデータ

区分 対象 内容

①設置され

ている機器

の基本情報

UI クラウドに接続されている全

ての機器

・接続されている機器数

・各機器の名称（制御に使用する device 名）、機器タイプ

（Entrance key Robot 等）

設置されている電力センサの

一覧

・接続されている電力センサ数

・電力センサの種別（ECHONET Lite 電力センサ、スマートメータ

ー等）

分電盤の分岐回路名

センサを設置した分岐回路の名称

（台所、洋室、子供室等）

※機器設置時に現地で入力したもの

②制御可能

な機器の情

報

エアコン

（ECHONET Lite、シャープ家電

クラウド経由、パナソニック家

電クラウド経由、赤外線リモコ

ン経由）

ECHONET Lite エアコンで制御可能な機能や指定できるパラメ

ータの範囲

・ステイタス確認（赤外線リモコンは×）

・ON/OFF 制御

・温度設定、風量設定

LED 照明 Hue LED 照明 Hue で制御できる機能と指定できる範囲（調光できる

色の種類等）

コミュニケーションロボット

（BOCCO、ホームアシスタント）

BOCCO で制御できる機能（動作履歴は×、メッセージ送付は

○）

③動作履歴

（積算値）

玄関鍵（BOCCO 経由） BOCC 経由で取得した玄関鍵の履歴

（15 分間毎の最新の開閉履歴とタイムスタンプ）

ドアホン（BOCCO 経由） BOCC 経由で取得したドアホンの履歴

（15 分間毎の最新の呼び鈴が押された時刻）

ECHONET Lite 分電盤 ECHONET Lite 分電盤（パナソニック）から取得した電力計測値

（主幹、各分岐回路１～３２まで：30 分毎）

スマートメーター スマートメーターから取得した電力計測値（売り電、買い電気：30

分毎）

④状態取得

（瞬時値）

※表示のみ

ECHONET Lite 分電盤の瞬時

電力（主幹、分岐回路）

ECHONET Lite 分電盤（パナソニック）から取得した瞬時電力の

値

スマートメーターの瞬時電力情

報 スマートメーターの瞬時電力

ECHONET Lite エアコン ECHONET Lite エアコン（三菱電機製）のステイタス

シャープエアコン（シャープクラ

ウド経由） シャープエアコンのステイタス

パナソニックエアコン

（パナソニッククラウド経由） パナソニックエアコンのステイタス

2.2.2.2. 機器間連携のシステム構築

図 2-15 に示す 3 つの要件でシステムを構築することとした。

・ UI クラウドと各社のクラウドサーバーを異なる三つの方法で接続する（①～③）

・ 接続した各社サーバーの機能を統合的「統合 WebAPI」を UI クラウド上に実装する

36

・ 「統合 WebAPI」を活用したスマートフォン操作画面、音声認識によるエアコン操作等の

ユーザインタフェースを開発する

図 2-15 構築するシステムの要件設定

中心となる UI クラウドは、データ蓄積機能、演算・制御処理機能、統合 WebAPI、閲覧・操

作画面の四つに機能分離し、外部通信機能により HTTPS やトークン等による認証をかけた上で

①～③の外部クラウドサーバーと接続する。これにより、IoT 機器や ECHONET Lite 機器のデ

ータ収集、蓄積、制御等を実現する。また連携した機能を活用する「統合 WebAPI」は外部企業

やサービスからの利用を前提に開発を行う。

①のメーカクラウド経由については、既に WebAPI を公開している場合はそのまま活用し、

そうでない場合は WebAPI の開発も含めて行う。

②の API 連携サービス経由では、IF～THEN ロジックで構築された組み合わせ機能（API）

を UI クラウドから実行、もしくは API 連携サービスから UI クラウドの外部通信機能を実行す

ることで、センサデータの蓄積や照明の制御を行う。

③のエッジ側サーバー経由では、ホームネットワーク上に接続されたホームゲートウェイに実

装されたローカル API（大和ハウス工業では住宅 API と呼称）を、UI クラウドから MQTT を

活用し遠隔で実行させることで制御や情報収集を行う。ローカルとクラウド経由での制御を両立

させることで、セキュリティ等のクリティカルなサービスはローカル API で、遠隔での施錠確

認やエアコン ON/OFF 等の生活支援サービスはクラウド経由など、提供するサービスの内容に

応じて使い分けることが可能となる。

37

2.2.2.3. 社会課題解決に向けたサービス実証

物の購入やコミュニケーション手段がネットに置き換えられビジネスモデルが激変しているの

に対し、建設からメンテナンスまで現地で実施しなければならない住宅はネット化による影響を

受けにくい。一方で住宅がネットワークに接続され、在／不在や活動量、家電や設備機器の使用

状況が把握できるようになれば、宅配の合理化や高齢者の見守り、保守やリコールの合理化など

社会的な課題解決につながるとの期待も大きい。問題はそのためのコストをどう償却するかであ

り、HEMS で一般的なエネルギーの見える化だけでは企業・顧客側共に負担するのは難しい。

そこで、本実証ではユーザの利便性を提供しつつ企業側の経費削減につながるサービスの可能

性について検討を行う事とした。具体的には、住宅内に企業側から遠隔設定・管理できる通信機

器類を設置し、下記 3 点について、検討を行った。

家電や住宅設備の遠隔制御サービスを提供すると同時に、障害が発生した際も遠隔で状況

を確認し再起動やソフトウェアのアップデート等を行う事で現地訪問の削減につなげられ

るか

音声発話が可能なロボットを通じ、生活情報に交えて企業側からのお知らせを通知するこ

とで、カスタマーサービスへの問い合わせ削減につなげられるか

上記の実施を通じて管理側サーバーに求められる要件

また、評価のポイントは以下とした。

・家電の属性や機器の稼働状況に基づく情報提供が、顧客満足度につながるか

・上記サービス提供が、企業側の問い合わせ件数の削減、業務効率化につながるか

なお、本実証にて提供したサービスは図 2-16 に示す①～③である。

① スマートフォンによる家電や設備機器のモニタリング、遠隔操作

➢ スマートフォンの画面で、居住地の天気予報や鍵の施解錠状態、エアコンや LED照明の

遠隔操作が可能

② ネットワーク経由でのシステム運用

➢ 無線ルータや IoT用の通信カード等の通信機器、エッジ側サーバー（ECHONET Lite

コントローラー）の設定から稼働状況の確認、再起動やファームウェア更新がインター

ネット経由で可能

③ 生活情報や家電・設備機器使用上のアドバイス等

➢ クラウドサーバー経由で音声発話が可能なユカイ工学の BOCCO、シャープのホームア

シスタントを活用し、天気予報等の生活情報や豆知識、住宅のメンテナンス情報等の送

付が可能

38

図 2-16 サービス概要

2.2.2.4. 実施体制及び実証スケジュール

コンソーシアム形態の実施体制および実証スケジュールは以下のとおり。

39

図 2-17 実施体制図

表 2-10 実証スケジュール

経済産業省

(株）三菱総合研究所

大和ハウス工業（株） 富士ソフト（株） ・UIクラウド構築（Amazon AWS)

　・全体統括 ・連携サービス、スマートフォン画面開発

　・企画立案・基本設計 ・API開発、システム構築技術支援

　・開発管理

　・モニタ募集・検証実施 ヤフー（株） ・API連携サービス提供(myThings)

・連携チャンネル追加開発

パナソニック（株） ・家電機器制御クラウド連携開発（エアコン）

シャープ(株） ・家電機器制御クラウド連携開発（エアコン、音声端末）

日本電気（株） ・スマ・エコクラウドＡＰＩ連携開発

ユカイ工学（株） ・家庭用ロボットの音声認識機能開発

(株）ソニーＣＳＬ ・エッジ側サーバー連携API開発

（株）協和エクシオ ・モニタ家庭システム設置・設定工事

その他　　　 ・サポートダイヤル運営

　三菱電機（株） ・エアコン制御アダプタ提供及び設置工事

（株）ＩＩＪ ・スマートメーターＢルートアダプタ提供・技術支援

再委託請負契約

委託

再委託

委託

4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月

基本設計書作成

各システム要求仕様書作成

請負契約書作成・発注

開発管理

検証内容検討・申込書作成

モニタ募集

機器設置・設定

検証実施

アンケート調査等

撤収業務（サービス停止、機器回収等）

再委託契約締結

定例報告会等への参加

報告書作成・報告実施

項目2017年度

シ

ス

テ

ム

開

発

モ

ニ

タ

検

証

そ

の

他

40

2.2.3. 実証結果

2.2.3.1. モニタ募集及び実証環境整備

つくば市の 29 件のモニタ家庭に機器を設置、8 月中旬～1 月末まで実証を行った。また、モニ

タ実証は図 2-18 に示す四つのステップで実施した。Step1 では、まず BOCCO や Hue など既存

の IoT 機器や Web サービスそのものについて体験してもらい、利便性や操作方法が理解できたか

等について評価してもらう。Step2 では、それらの機能を統合した UI クラウドのスマートフォン

画面で操作してもらうことで、複数サービスをまとめて操作する「機能」について評価をしても

らった。Step3 では、現状のスマートフォン画面に代わる新たなユーザインタフェースとして、

音声による機器操作や情報配信について比較をしてもらう。最後に Step4 としてそれらの結果を

ふまえ、Web アンケートを実施した。

実証にあたっては日立コンソーシアムの製品ライフサイクル実証とも連携を行い、モニタ開始

の案内や操作マニュアルの送付、Web アンケート等については共同で実施した。

図 2-18 実証ステップ

アンケートの回答者の大半は男性で、IT には詳しくないが IT や IoT については興味があると

いう人が多かった。評価ポイント①、②についてのアンケート結果は以下のとおり。

① 個別画面（アプリ）と、統合的な UI 画面での閲覧・操作の比較

・複数の機能やサービスを「まとめる」という考え方への支持が高い

41

・アプリの数が増えると使いづらいという意見の他、スマホの容量が気になるという方も

図 2-19 個別アプリと統合画面による操作の比較

その他統合画面でのサービス体験においては、エアコンや照明の遠隔操作は便利だという意

見や、HEMS 画面をスマホで確認できる機能は意外に評価の高い結果となった。

② スマートフォンによる閲覧・操作と音声による通知・操作の比較

・音声での操作は、うまく認識しない、リモコン操作の方が早いという意見が半数

・天気予報を音声で知らせてくれる等、シンプルなサービスの評価が高い

図 2-20 スマートフォンと音声による操作との比較

最後に、今回提供したサービスの中で、実証期間が終了した後も継続して使いたいサービスを

選択していただいた。使いたい（欲しい）サービスが無い場合は何も選択しないよう注記してい

たが、大半のモニタ家庭で多くのサービスの継続意向が見受けられた。トップランクは複数機器

をまとめて操作できるスマートフォン画面だったが、毎朝天気予報を音声で教えてくれるサービ

スの評価が次いで高い結果となった。理由についても記載してもらったが、一言でいえば「内容

が理解しやすく」、「シンプル」なサービスが支持されたという事ではないかと思われる。逆に遠

隔操作の評価に比べ本体の評価が低かった LED 照明の Hue は、「1,600 万色以上」の色設定や

ライフシーンに合わせた調光・調色といった機能の使いこなし方がわかりづらかった点が評価に

影響したのではないかと思われる。

42

図 2-21 今後も継続したいと思う製品・サービス

2.2.3.2. 機器間連携のシステム構築

システム連携の中核となる UI クラウド構築および、各社サーバーとの接続について、開発し

た内容を説明する。

(1) UI クラウド構築

連携の中心となる UI クラウドには、IoT 機器との通信や機械学習など多様な機能を利用でき

るクラウドコンピューティングサービスを利用した。一からプログラムする必要がなく、使った

分だけ料金を支払う仕組みにより、初期開発コストを抑え、利用者数に応じた柔軟なシステム運

用が可能となる。機能的には①データ蓄積、②認証・蓄積・制御処理、③外部通信、④統合 WebAPI、

⑤閲覧・操作に大別される。

(2) 各社サーバーとの連携

各社サーバーとの接続方法は以下の三つに分類される。

各社クラウドサーバーとの直接接続

ＡＰＩ連携サービス経由での接続

エッジ側サーバーとの接続

各社クラウドサーバーとの接続方法と接続事業者、提供するサービスについて表 2-11 に示

す。

43

表 2-11 接続する事業者及びサービス概要

接続事業者 接続機器・サービス 主な機能

①

ＩＩＪ IIJ スマートメーターB ルート活用サービ

ス 住宅全体の瞬時電力、30 分毎の積算電力データ収集

パナソニック スマート家電 スマート家電（エアコン）の状態取得・遠隔制御

シャープ スマート家電 スマート家電（エアコン）の状態取得・遠隔制御

音声認識端末（ホームアシスタント） 音声による機器制御・情報配信

NEC スマ・エコクラウド 大和ハウス工業 スマートタウンの住宅、共用設備等のデ

ータ収集

② ヤフー

家庭用ロボット（ユカイ工学 BOCCO) 音声による情報通知（機器制御は別途開発）

鍵センサ・ドアホンセンサの履歴取得

LED 照明（Philips Hue） LED 電球の ON/OFF、調色（7 色）

気象センサ(Netatomo) 屋外の温湿度、風速、雨量

気象情報（Yahoo!天気） 地域を指定しての週間天気予報

Gmail 収集したデータや情報のメール通知

③ Sony CSL 家電・設備コントローラー ECHONET Lite に対応した家電・設備機器制御

①は各社のクラウドサーバーと WebAPI を介して直接接続するものであり、外部公開用の

WebAPI を開発・開示している企業（IIJ）についてはそのまま活用したが、未開発の企業のサ

ーバーについては新規開発、既に自社顧客向けサービスを提供している企業とは、UI クラウド

のモニタ ID と相手先のクラウドサービス ID を紐づけ、連携を行った。密な連携（継続性、粒

度の高いデータ取得、目的に応じたカスタマイズ）には向いているが、契約交渉に時間がかか

る、外部公開を前提に設計されていない場合は連携が難しいなどの課題がある。

②は各社のクラウドサーバーと直接接続するのではなく、ヤフーが提供する myThings

developers という API 連携サービスを介して接続を行うものである。提供されている機器やサ

ービスの中から事例として、BOCCO のセンサ（鍵・ドアホン）の履歴取得、Philips の Hue を

活用した機器制御等を開発した。1 社（ヤフー）と契約することで、多様なサービス（現状 42

種類）との連携が可能であり、異なるメーカのサービスでも同じ作法で連携でき、開発側の負担

を軽減できる一方で密な連携には向かないので、提供したいサービスに内容に応じて検討が必用

である。

③は住宅との接続を想定したもので、ECHONET Lite に対応した HEMS 重点８機器（スマ

ートメーター、太陽光発電、蓄電池、燃料電池、EV/PHV、エアコン 、照明機器、給湯器）の

他に、HA（ホームオートメーション）対応の電気錠、電動窓、防犯センサ等が対象となる。こ

れらの機器は直接クラウドに接続する事ができないので、ECHONET Lite ミドルウェアを搭載

したエッジ側のサーバー（ホームゲートウェイ）に実装した API を用いてクラウドと接続し

た。MQTT の PUB/SUB を活用しローカル API を叩く事で、ローカル/クラウド制御を両立が可

能。ECHONET Lite に準拠した REST ベースの API 標準化の検討が待たれる。ただ、ローカ

ル API を実装した HGW がほとんど存在しないことは現状の課題である。

44

2.2.3.3. 社会課題解決に向けたサービス実証

本実証では、①スマートフォンによる家電や設備機器のモニタリング・遠隔操作、②ネットワ

ーク経由でのシステム運用、③生活情報や家電・設備機器使用上のアドバイス等の 3 つのサービ

ス実証を行った。①については、実証結果 (1)モニタ募集及び実証環境整備 にて説明したため、

ここでは、②、③についてサービス実証の結果を説明する。

② ネットワーク経由でのシステム運用

機器設置後は各種管理画面を通じて稼働状況の確認と保守を実施した。本来は現地を訪問し、

原因の調査や復旧を行わないといけないところを、遠隔で完了する事ができ、サービスを提供す

る企業側、自宅待機しなければならない顧客側双方にメリットがある事を確認した。一方で、消

費電力や鍵開閉の状況から個人の生活パターンがわかってしまうので、保守に不要な情報は顧客

ID と個人情報は分離する等で丸める必要がある。また、今回は無線ルータやコントローラー等の

遠隔管理機能が付属した端末を用いたが、今後は同じしくみを家電や住設機器にいかに拡張して

いくかが課題である。

③ 生活情報や家電・設備機器使用上のアドバイス等

顧客コミュニケーションツールとしての郵便やメールは、なかなか見てもらえないのが現状で

ある。そこで、今回モニタ実証を行う音声による生活情報提供の中に、省エネアドバイスやメン

テナンス情報を織り込む事で、確実性が向上しないかについて検討を行った。

具体的にはシャープのホームアシスタントを用い、12 月上旬～翌年 1 月末まで毎日午後 7:00

に表 2-12 に示すような内容を日替わりで発話をさせた上で、アンケートにより音声通知の許容

度や配信して欲しい内容等についてアンケートを取ることとした。

ただ、実施にあたっては、突然端末が喋り始めることになるので、発話時間やモニタ家庭への

周知など慎重に検討した。子育て世代が多い分譲地なので在宅確率が高い朝食や昼食時は乳幼児

が寝ている可能性があり避ける事としたが、クレームにつながらないかという点は非常に気を使

った。アンケート調査でも、企業側の情報が入る事には抵抗感が強いという結果も出ており、新

たなコミュニケーションツールとしては有望ではあるが、実施にあたっては注意が必用と思われ

る。

表 2-12 音声による生活情報提供（抜粋）

区分 内容

共通（毎回発話） こんばんは。今日は○月○日、○曜日、午後 7 時になりました。

HA の利用促進 わたしの名前は”りんちゃん”。りんちゃんってなんやねん！と思った人も、思わなかった人も、とき

どき「りんちゃん」って話しかけてみてね。寂しがり屋だから。

住宅メーカからのアド

バイス

エアコンのフィルターの掃除ってしてますか？ 風の通り道がふさがれちゃうので、効きが悪くなる

んだって。

寝ている間に発生する水蒸気って、家族 4 人で 500ml にもなるんだって。だから寝室はよく結露す

るんだね。こまめに換気をしましょう！

晴れた日中には電気ヒーターと同じぐらいの熱が南の窓からはいってくるんだって。うまく使うとエ

コだよね。

イベントに関連したつ

ぶやき

メリークリスマス！サンタクロースさーん。私の枕元にプレゼントを忘れてませんか～。

新年あけまして、おめでとうございます！2018 年がやってまいりました。今年こそは、とやりたいこ

とはたくさんありますが、一歩一歩お役に立てることを増やしながら、頑張りますね。

45

区分 内容

雑学

日本の 12 月の観測史上最高気温は、東京都南鳥島で 1952 年 12 月 5 日に記録した、31.6 度ら

しいですよ。すごいですね。それってもう夏の気温と変わらないです。

今日は、衣類乾燥機の日だよ。 衣類乾燥機がもっとも活躍する冬の 1 月 28 日を、"衣類ふんわ

り"の語呂合わせから定めたんですって。

純粋なつぶやき

この週末は、少し遠出してみませんか？というか、わたしは留守番ですけどね

スマートホームって、スマートフォンみたいなおうちってですかね。手放せなくなるかもしれません

ね。

2.2.4. 実証を通じた論点の整理

2.2.4.1. データカタログ

以下について整理・検討した結果について説明する。

①個々のアクション（業務）についてマンダトリー（必須）の出入力データ項目

②アクションの追加（新規設計）が随時行える拡張性が高いデータ構造

まず、個々のアクション（業務）について想定される入出力項目について整理を行った。②の

アクションの追加（新規設計）が随時行える拡張性が高いデータ構造の検討については、JSON 等

のスキーム追加が容易な形式でのデータ蓄積、サービス事業者からの汎用的な要求（エアコン ON

等）と家庭内に設置される機器の通信プロトコル、メーカ、製造年月等の差異を吸収する機能を

クラウドに実装することで、機能拡張を容易にできるよう配慮した。

次に、機器の ON/OFF 状態やエアコンの設定温度など、サービスを提供する上で基本となるデ

ータ（基本データ）を、表 2-13 の項目について整理した。

46

表 2-13 基本データ検討結果

大別すると、屋外環境データ、屋内環境データ、消費電力、機器稼働状況、機器制御の 5 項目

に分かれる。環境データであれば、温湿度・照度・騒音・空気質等がデータとして挙げられる。

大半はホームネットワークの標準プロトコルである ECHONET Lite のオブジェクトコードが定

義されているが、対応した製品が少ないため、各社が独自に定義した IoT センサ等のデータを活

用する必要がある。機器稼働状況と機器制御については、住宅内に設置される大半の家電、設備

機器について ECHONET Lite の定義がされているが、赤外線機器や IoT 機器については各社が

独自に定義しているほか、赤外線はステイタスの取得ができないこと、IoT 機器の多くは、状態

変化があった時しかステイタス取得ができないこと等について留意が必要である。

さらに、在宅／不在情報による宅配の効率化やデマンドコントロール指示による電力制御など、

外部のサービス事業者が活用しやすいように加工したデータ（高次データ）の検討も行った。サ

ービス事業者からの要求に応じて、基本データを複数組み合わせる、重み付けを行う等の処理を

行い、結果は確率や調整可能な電力量等のデータを返却する。

整理にあたっては宅配等の具体的な業務よりも、自宅への訪問や節電制御など目的ベースで整

理した方が良いと考えた。表 2-14 に整理した内容を示す。大別すると、現地訪問業務の効率

化、節電・省エネ業務の効率化、遠隔保守、属性情報の把握など、BtoB 向けのサービス、室内

区

分

データ名

(データ種別)機器種別

Echonet機器

オブジェクトコードデータ区分 データ方向 データ定義 上位データ 下位データ 基本属性

気象データ － 屋外温度（単位℃）

温度センサ 0x11（温度センサクラス） 屋外温度（単位℃）

エアコン計測値 0x30（家庭用エアコンクラス） 屋外温度（単位℃）

気象データ － 屋外湿度（単位%）湿度センサ 0x12（湿度センサクラス） 屋外湿度（単位%）

屋内湿度 加湿器 0x39（加湿器クラス） 屋内湿度（単位%）気象データ － 屋外空気室

0x0B（空気汚染センサクラス） 屋外空気室0x1B（CO2センサクラス） 屋外空気室0x1D（VOCセンサクラス） 屋外空気室0x20（臭いセンサクラス） 屋外空気室

気象データ － 屋外照度（単位lx）照度センサ 0x0D（照度センサクラス） 屋外照度（単位lx）気象データ － 屋外風速（単位m/s)風速センサ 0x1F（風速センサクラス） 屋外風速（単位m/s)

屋外風向 気象データ － 屋外風向（単位：方位）

気象データ － 降水量（単位：ｍｍ）降雨センサ 0x13（雨センサクラス） 降水量（単位：ｍｍ）

屋外騒音 騒音センサ 0x0E（音センサクラス） 屋外騒音（単位：dB)温度センサ 0x11（温度センサクラス） 屋内温度（単位℃）エアコン計測値 0x30（家庭用エアコンクラス） 屋内温度（単位℃）

室内湿度 湿度センサ 0x12（湿度センサクラス） 屋内湿度（単位%）気象データ － 屋外照度（単位lx）照度センサ 0x0D（照度センサクラス） 屋外照度（単位lx）

屋内照度 照度センサ 0x0D（照度センサクラス） 屋内照度（単位lx）0x0B（空気汚染センサクラス） 屋内空気室0x1B（CO2センサクラス） 屋内空気室0x1D（VOCセンサクラス） 屋内空気室0x20（臭いセンサクラス） 屋内空気室

空気清浄機 0x35（空気清浄機クラス） 屋内空気室騒音センサ 0x0E（音センサクラス） 屋内騒音（単位：dB)防犯センサ 0x02（防犯センサクラス） しきい値（個別に設定）音声認識ロボット － しきい値（個別に設定）

スマートメーター0x88（低圧スマート電力量メータークラス）

消費電力量

分電盤 0x87（分電盤メータリングクラス） 消費電力量

電力センサ 0x22（電力量センサクラス） 消費電力量

スマートメーター0x88（低圧スマート電力量メータークラス）

しきい値(瞬時データ）

分電盤 0x87（分電盤メータリングクラス） しきい値(瞬時データ）

ＩｏＴ機器 －

ECHONET機器EPC：0x80　ON ＝0x30　OFF ＝0x31

状態変化データ

赤外線機器 －ＩｏＴ機器 －

ECHONET機器EPC：0x80　ON ＝0x30　OFF ＝0x31 等

室内温度

屋外照度

屋内空気室

屋内騒音

消費電力

機器稼働状況

屋外温度

屋外湿度

屋外空気質

屋外照度

屋外風速

降水量

情報取得

－

－

－

－

測定時刻、精度、測定位置

測定時刻、精度、測定位置

測定時刻、測定間隔

発生時刻、対象機器、対象機能

機器制御

インバウンド 機器制御データ － 発生時刻、対象機器、対象機能機器制御 機器制御データ機器制御

屋外環境データ

屋内環境データ

機器稼働状況データ

消費電力

消費電力データ

アウトバウンド

空気質センサ

空気質センサ

機器稼働状況

屋内環境データ

屋外環境データ

47

の環境の最適制御や防犯など BtoC 向けのサービスを挙げて、データの定義や関連する上位下位

データについて整理した。

現地訪問の効率化については、在宅状況の確率、推定帰宅時間、推定訪問可能日など、現地を

訪問しなくてはならない業務全般に活用できる高次データの代表事例と考えられる。利用する下

位データとしては、鍵の開閉状況、消費電力量等、機器から取得できるデータもあるが、個人の

スケジューラや自己申告によるデータ等を組み合わせる事でより精度が高まる。

節電・省エネ業務の効率化については、デマンドコントロールや HEMS で一般的な電力の見

える化サービスが想定できる。また、太陽光を売電している家庭は「発電事業者」として扱われ

るため、BtoC 向けのサービスとしても活用できる。利用する下位データとしては、住宅全体は

回路毎の消費電力データであるが、節電可能な電力量はユーザによる許諾や設定が必要になる。

分電盤による各回路単位のデータが取得できることが理想だが、スマートメーターの情報に加え

蓄電池・太陽光の制御を ECHONET Lite コントローラーで行う事で補完も可能と思われる。

遠隔保守の効率化としては、リコール対応、遠隔メンテナンス、買い替え対応等をあげたが、

各家庭が保有している機器をいかに把握するかが課題となる。ECHONET Lite 対応の設備機器

であれば HEMS コントローラーから接続機器の一覧を取得できるが、ユーザの自己申告による

データと一元化する必要がある。また、ECHONET Lite でも定義されている家電・設備機器の

エラーデータが取得できるようになればより効率化が図れると考えられる。

BtoC 向けのサービスとしては室内環境快適制御を想定したが、AI スピーカー等と称される音

声デバイスによる音声指示への対応がわかりやすいと思われる。ただ、エアコンの ON/OFF だ

けならリモコンでも可能なので、「でかけます」、「ただいま」といった発話に対して、外出時や

帰宅時の一連の作業を自動的に行うことが求められる。

48

表 2-14 高次データ整理結果

2.2.4.2. セキュリティ・製品安全

以下の内容について整理・検討を行った。

①機器サービス接続にあたり各主体が接続先に求めるセキュリティ上の認証基準

③ ネットワーク機器のモニタリング・ログ管理の有り方の整理

① について、委員会にて提示された内容に沿って検討を行った結果を表 2-15 に示す。

データ名

（データ種別）データ区分 データ方向 データ定義 上位データ 下位データ 利用データ 基本属性 その他 関連情報

在宅状況（現在） 情報取得 在宅確率 個人別在宅状況（現在）消費電力（瞬時）、宅内家電・設備機器稼働状況

在宅確率

帰宅予測時間 情報取得 推定帰宅時間 個人別在宅状況（現在）消費電力パターン、宅内家電・設備機器電源操作履歴データ

推定帰宅時間

訪問可能日程の調整 情報取得 訪問可能日時 個人のスケジュールスケジューラ、個人からの申告データ

訪問可能日時リスト －

使用電力の調整（瞬時値） 削減（増加）可能電力(kW)回路別・機器別削減可能電力（kW)

回路別・機器別使用電力、削減可能電力値（kW)

回路別・機器別の削減（増大）可能電力量（ｋW)

Echonet Lite規格書

使用電力の調整（積算値） 削減（増加）可能電力(kWh)回路別・機器別削減可能電力（kWh)

回路別・機器別使用電力、削減可能電力値（kWh)

回路別・機器別の削減（増大）可能電力量（ｋWh)

Smart Energy Profile 2.0

消費電力の履歴情報 情報取得 電力使用状況（kW,ｋWh)電力使用状況(見える

化）

住宅全体、各分岐回路、各家電機器の消費電力データ

消費電力情報（スマートメーター、分電盤、電力センサ等）

回路別・機器別の使用電力データ（瞬時、30分、時、日、月、年毎履歴）

Echonet Lite規格書

リコール対応 リコール対象機器リスト リコール通知家電・設備機器の品番リスト

家電・設備機器の品番リスト情報

リコール対象機器の有無 Echonet Lite規格書

メンテナンス対応 メンテナンス対象機器リスト メンテナンス通知家電・設備機器の品番リスト、使用実績、エラー情報

家電・設備機器の品番リスト、使用実績、エラー情報

メンテナンス対象機器の有無 －

買い替え対応 買い替え対象機器リスト 買い替え通知家電・設備機器の品番リスト、使用実績、エラー情報

家電・設備機器の品番リスト、消費電力情報、使用実績、エラー情報

買い替え対象機器の有無 Echonet Lite規格書

住宅属性情報

住宅の属性（建築場所、メーカー、構造、階数、竣工日時、延床面積、省エネ・創エネ設備等）

住宅属性参照要求 各項目データ住宅メーカーが保有する契約データ、お客様自身が開示する住宅属性情報

各属性データ、開示許諾情報 －

氏名生年月日性別住所家族構成温度 K湿度 %気圧 hPa照度 照度

室内環境最適制御（温湿度度）

空調機の温度制御データ 最適温度制御指示保有する空調機の種別、稼働状況

保有する空調機の種別、稼働状況、制御データ

空調機の温度制御データ

室内環境最適制御（照度） 照明器具の制御データ 最適照度制御指示保有する照明器具の種別、稼働状況

保有する照明器具の種別、稼働状況、制御データ

照明器具の制御データ

起床時の作業を行う起床時に実施する一連の作業リスト

起床指示

就寝時の作業を行う就寝時に実施する一連の作業リスト

就寝指示

外出時の作業を行う外出時に実施する一連の作業リスト

外出指示

帰宅後の作業を行う帰宅時に実施する一連の作業リスト

帰宅指示

セキュリティー

侵入者の通知情報取得／制御

アウトバウンド／インバウンド

正常／異常の状態 侵入異常通知防犯センサ、在／不在情報

防犯センサのステイタス、セキュリティーシステム作動状態

閾値の設定と、超えた場合に実行する作業項目のリストデータ

なし Echonet Lite規格書

区分

Bto

C

現地訪問業務の効率化

節電・省エネ業務の効率化

遠隔保守

属性把握

室内環境快適制御

Bto

B

情報取得／制御

アウトバウンド／インバウンド

なし Echonet Lite規格書

保有する空調、照明、家電・設備機器、セキュリティー機器のリスト、稼働状況

保有する空調、照明、家電・設備機器、セキュリティー機器のリスト、稼働状況、制御データ、要求制御項目

発生時の機器稼働状況データ、作業リスト

なし

なし

なし

なし

Echonet Lite規格書

各項目データ、開示許諾情報

各項目データ

情報取得／制御

情報取得

情報取得 アウトバウンド

アウトバウンド

アウトバウンド／インバウンド

アウトバウンド

各項目データ、開示許諾データ

各項目データ

デマンドコントロール指示

住民属性参照要求

建設地属性参照要求

住民属性情報

住民による申請・登録・許諾した計測情報,、住宅メーカー等が個人に了解を得て開示する情報

MozillaFoundation

http://iot.mozilla.org/wot/

Healbe Web APIhttps://docs.google.com/document/d/1T5jP_CJXVdWX1RF1LfnIwYcqDhdp1MKZHpM3

CxM2VOY/edit

建設地属性情報

一般物理量API (三次元位置（緯度・経度・高度）を指定するとその地点の物理量を求められる汎用API。定

最適訪問日時要求

49

表 2-15 接続先に求める認証基準検討結果

実証後に記入

「セキュリティ対策項目」への実施有無と内容 「セキュリティ対策項目」から除外・追加すべき項目とその理由 実証後の「セキュリティ対策項目」に対する改訂案等

①ハウスメーカー、機器ベンダー等の経営層がIoTセキュリ

ティにコミットする（必要なリソースの割当等）。

今回の実証試験においては実施しない。（理由）どういった課題が存在するか

を抽出するのが実証の目的であるため。事業化する際に抽出した課題に対して

の対応及び具体策については検討したい。

－

②PDCAサイクルを回す仕組みを導入する。

今回の実証試験においては実施しない。（理由）どういった課題が存在するか

を抽出するのが実証の目的であるため。事業化する際に抽出した課題に対して

の対応及び具体策については検討したい。

まず必要か否かについて議論すべき。（理由）各機器、サービスの安

全性が確保されている前提において統合するシステム構築を行うので、

機器ベンダー、サービスベンダーと、住宅メーカーのようにその機能を

利用する側とでは対応が異なると思われる。

①守るべきものの特定、つながることによるリスク、アーキ

テクチャ、物理的なリスクとその範囲を考慮する(内部不正や

ミスの発生を考慮する）

接続する機器やサービスについては左記の安全性が担保されている事を前提

に、それらをつなぐ事での物理的なリスクについて検討したい

住宅メーカーにて実用化する場合、接続するメーカー、機器、機能を

精査しホワイトリスト化するので、その範囲内にて検討する。

全てのリスクを想定するのは困難なので、常に最新情報の入手と

アップデートを心掛けたい

②プライバシー情報漏洩のリスクと影響分析の実施 当社社内規定に即して実施する 当社社内規定に即して項目を選定する －

①つながる相手のリスクを回避する設計接続先のセキュリティーポリシーを確認し、HTTPS等適切な手段で接続を行

う－

一部のクラウドサーバーとの接続にて、システム上の制約でクラ

イアント証明書での認証ができないケースがあった。そうした場

合の代替え手段についても事前に検討しておきたい。

②つながる相手に損害を与えない設計自社サーバー経由での不正なアクセスを防止するよう、クライアント端末との

接続はHTTPS等の適切な手段で接続を行う－ －

③セキュリティとセーフティの相互影響を考慮した設計

(Security, Safety, Privacy by Design：SSPD) 製品安全を考慮

したセキュリティ設計等

今回クラウドサービスを構築するプラットフォーム（AWS)のポリシーに沿っ

て設計を行う－

セキュリティーポリシーも随時アップデートされるため、常にアッ

プデートを心掛けたい。

④遠隔操作により安全性に係わる問題の考慮

手元操作が優先されるよう設計を行う。電気錠のように、誤操作や誤動作によ

る意図しない開錠が想定される機器については施錠のみの機能に限定する等の

対策を行う。

遠隔操作時の安全性を確保することに異論ないが、そのレベルをどこ

に置くか、具体的な対策方法についての議論が必要と思われる

モニタ家庭より、音声認識ロボットが勝手にエアコンを操作した

旨のお申し出があった。UIクラウドのAPI実行のログは確認できた

が、誤動作によるものかまでの確認はできなかった。実用時には

原因を辿れるような対策を取りたい。

⑤安全安心を実現する設計の検証の実施

④の対策を取った上で、その内容を顧客に理解してもらう（＝安心）配慮を行

う。具体的にはポータル画面での説明、パンフレットや重要事項説明書への盛

り込みを行う

－

長文では読み飛ばされるため、ポイントを押さえた説明、図・表

等での表現、使用直前などタイムリーな情報提供に留意する必要が

ある。

⑥認証機能、暗号化の導入必要性の検討（参考CRYPTREC）ユーザーの利便性、企業側の事業性とのトレードオフとなるので、今回の実証

及びワーキング活動を通じてて必要性について検討したい。

ユーザーの利便性、企業側の事業性を考慮したレベル設定が必要と思

われる－

⑦多層防御（多重のセキュリティ対策の考慮）ユーザーの利便性、企業側の事業性とのトレードオフとなるので、今回の実証

及びワーキング活動を通じてて必要性について検討したい。

ユーザーの利便性、企業側の事業性を考慮したレベル設定が必要と思

われる－

⑧ログ・監視機能の導入企業側としては、不具合発生時の状況確認のため、必要なログや監視機能は実

装したい。

ユーザーの理解を得た上でのログ取得、監視が必要（Webの閲覧履歴

等についてはプライバシー情報に該当するので対象外）

稼働確認の上で不要な情報（例えば、鍵が開か閉か等の詳細）は

極力排除し、実行時間や正常稼働か否かの情報のみに丸めて表現

すべきと感じた。⑨主要IoTセキュリティガイドラインの考慮(OWASP/IoT Top

10等）

各種ガイドラインについては、一般的なレベルをふまえた上で考慮した設計と

したい－ －

・接続先に求める認証方式とその水準今回クラウドサービスを構築するプラットフォーム（AWS)のポリシーに準

じ、JSON Web キートークン方式で実施する。企業側の事業性も考慮したレベル設定が必要

一部のクラウドサーバーとの接続にて、システム上の制約でクラ

イアント証明書での認証ができないケースがあった。そうした場

合の代替え手段についても事前に検討しておきたい。

・接続サービスとのデータ受渡し方法（暗号化方式等）

今回クラウドサービスを構築するプラットフォーム（AWS)のポリシーに準

じ、ホームGWに対してはMQTTで、他社サービスに対してはHTTPSで、共に

TLSプロトコルによる暗号化通信を行う。

企業側の事業性も考慮したレベル設定が必要 －

①設計を満たす実装であることのテストの実施 通常の受け入れ検査として実施する － －

②構築（インテグレーション）時の設定等の検証 通常の受け入れ検査として実施する － －

③機器の状態把握、記録機能の実現可能な範囲内において実装する。（ｻｰﾊﾞｰのログ、ECHONET機器の状態変化

のデータ等）ユーザーの理解を得た上でのログ取得、監視が必要

④で記載した内容をふまえ、IoT機器やロボット等の端末において

は、事前にどこまでのログが取得できるのかについて確認を取っ

ておくべきと感じた。

①機器設置後の不具合（脆弱性）の確認とアップデートの実

施

ホームGWについては、遠隔アップデートを前提とする。また、接続するIoT機

器についても極力遠隔でのアップデートが可能なよう求める

ユーザーの利便性、企業側の事業性を考慮したレベル設定が必要と思

われる

ネットワーク管理が可能な通信機器類については、遠隔管理や

ファームアップの利便性が確認できたので、今後は主要な端末に

対しても広げていく必要があると感じた。

②モニタリングと異常検知の実施今回クラウドサービスを構築するプラットフォーム（AWS)の標準機能を活用

する－ 運用をしながら常にアップデートする必要がある

③利用者へのリスクの周知 モニタ契約書、スマートフォンの画面等を通じて周知する － ポイントを絞ってタイムリーに伝達する必要がある

④サービス追加・連携における検証と利用者同意の実施 モニタ契約書、スマートフォンの画面等を通じて周知する －ID認証の場合、接続相手先ごとに有効期限が異なるので、統一を

図る必要があると感じた

実用化の際は、提供するサービスや仕様する機器、クラウドサー

ビスに応じて検討を進めていきたい

4. 実装・構築時の対策

5. 運用・保守・廃棄

対策区分 セキュリティ対策項目（チェックリスト）

実証初期に記入

1. スマートホームの性

質を考慮した基本方針

を定める

2. リスク評価の実施

3. 設計時のセキュリ

ティ考慮

50

②について、委員会で示された内容に沿って検討を実施した結果を示す。

51

表 2-16 ネットワーク機器のモニタリング・ログ管理のあり方

スマートホーム機器 モニタリングデータ データ要素 想定、期待されるセキュリティ分析（脅威検知等）

UIクラウドサーバー 連携したIoT機器やクラウドサーバーを操作した履歴

（例）

・myThingsで連携したLED照明のON/OFF、色変更

・panasonic、シャープのクラウドサーバーを経由し

て取得したエアコンの操作、状態取得

・IIJのクラウドサーバーを経由してスマートメーター

が取得した消費電力データ

・UIクラウドの統合WebAPIを使って取得した消費電

力情報やエアコンの操作

・クラウドサーバーで収集するﾃﾞｰﾀの蓄積履歴、エ

ラー発生状況

・UIクラウドへのアクセス履歴（関数実行等）

開始時刻、アクセス元IPアドレス、アクセス元

ポート、アクセスしたURL、実行したロジック及

び実行時間、エラー履歴

・配布されたモニタIDを元にしたID,PWの推測

・不正に取得したID,PWを使った個人データの不正取得、

不正な遠隔操作

・DDOS攻撃

・偽URLページに誘導し不正に公人情報を取得する

・モニタ利用者のスマートフォンにインストールさせた不

正なアプリによる、個人情報収集や操作履歴データの取

得、クラウドサーバーへの不正な侵入

IIJ Bルートアダプタ

（兼LTEルーター）

・ルーターの接続設定情報

・個々の端末の異常発生状況（インターネットへ、

スマートメーターとの接続不良等）

・スマートメーターの消費電力履歴

・無線LAN有効／無効、ID,PW情報

・スマートメーター認証情報

・クラウドとの切断、及び切断時間

・スマートメーターとの切断、及び切断時刻

・住宅全体の消費電力（瞬時、積算値）

・無線LANのID,PWを不正に取得しデータを収集する

・住宅全体の消費電力情報から、在宅／不在を推定し、宅

内に侵入する

ホームゲートウェイ

・ECHONETLiteで接続したエアコンの属性情報、作

動履歴

・メーカー名、取得・制御可能な機能一覧等

・ON/OFF、運転モード、温度設定、風量

・不正にホームネットワークにアクセスし、ホームゲート

ウェイ経由でエアコンを不正に操作する

家庭用ロボット

・付属する鍵センサ経由での、鍵（サムターン）の状

態が変化した際の時刻とその状態

・付属するドアホンセンサ経由での、ドアホンが押さ

れた時刻

・鍵の状態変化（開／閉）、時刻

・ドアホンが押された時刻の履歴

・UIクラウドのID,PWを不正に入手し、UIクラウド経由で

鍵の状態変化を取得する

LED照明器具（Hue)LED電球の操作履歴（クラウド経由で操作した場合の

み）ON/OFF、光色（赤・青・黄色等）

・UIクラウドのID,PWを不正に入手し、照明の遠隔操作を

行う

・消費電力状態をLEDの青色で通知するサービスを提供し

た場合、カーテン越しに在宅／不在を推測される可能性が

ある

赤外線リモコン（iRemocon)エアコンの操作履歴（クラウド経由で操作した場合

のみ）エアコンON/OFF、運転モード

・不正アクセスによる遠隔操作でユーザーに不安を与える

・乳児や高齢者がいる家庭で設定温度を極度に低く（高

く）遠隔操作をすることで体調を悪化させる

スマートメーター 住宅全体の消費電力 売／買電力、瞬時値、積算値・UIクラウド、IIJサーバーに不正にアクセスし、消費電力

から在宅／不在を推測し、宅内に侵入する

52

2.2.4.3. プライバシーデータの活用／サービスの創出

プライバシーデータの活用について、以下の項目で整理・検討を行った。

①様々な機器・サービス事業者の参入を前提としたプライバシー・個人情報ルール

②サービスの性質を踏まえ、モニタが用途を予見した上での事前合意取得の在り方

まず、様々な機器・サービス事業者の参入を前提としたプライバシー・個人情報ルールについ

て述べる。今回の実証では７社のクラウドサーバーと連携開発を行ったが、それぞれ独立したサ

ービスとして運用されているため、機密保持や請負契約時の条件交渉に非常に時間がかかった。

また、利用規約の内容も各社で異なるので、提供する企業側の説明責任、顧客側の規約を読み込

む労力など、双方に負担がかかる。中立な機関でベースとなる共通規約を作成し、そこからの差

異のみを提示し承諾を得るなどの対策が必要と思われる。

モニタが用途を予見した上での事前同意取得の在り方についてだが、文書で表現するとどうし

てもボリュームが多くなるため、極力図表を活用しポイントのみ文章で注記するなどの対策が必

要と思われる。図 2-22 に大和ハウス工業のモニタ実証で収集するデータ項目と使用目的につい

て説明した資料を示す。

図 2-22 実証で取得するデータと利用目的

次に、課題や個人のニーズに沿った総合的なサービス創出を促す為の方策について検討を行っ

た。ポイントとなるのは本実証において UI クラウドに実装した「統合 WebAPI」ある。モニタ実

53

証で活用したスマートフォン画面や、BOCCO やホームアシスタントでの音声によるエアコン操

作も、全てこの API を活用して開発を行ったものである。ID やトークンを発行することで、宅配

や高齢者見守り等の外部サービスから、本実証で連携した IoT 機器や ECHONET Lite 家電・設

備機器等を利用することができる。その一例として音声デバイスを使ったサービス開発を実施し、

短期間・低コストにてサービス連携が可能であることを確認した。

今回開発した統合 WebAPI の企画にあたっては、こうしたサービスを提供する IT ベンダーや、

賃貸住宅への IoT 活用を検討しているグループ会社等へのヒアリングを行った。実用化を見据え

た設計としており、今後は様々なデバイスやサービスへの適用を進めていきたいと考えている。

また、本実証で得た知見については、大和ハウス工業スマートホームの取り組みの中にも反映し

ていく予定である。

2.2.5. スマートライフの今後に向けた考察、提言

2.2.5.1. 事業の総括

まず今回の実証事業について総括したい。提案コンセプトは、エネルギーの見える化だけでは

顧客ベネフィットが出しにくい現状のスマートハウスと、安価で利便性の高い製品が提供されて

いるものの横の連携が取り難い IoT 機器の課題を、クラウドサーバーで連携する事で解決してい

くことだった。これに向け、IoT 機器や Web サービスと、ECHONET Lite に対応した住宅設備

機器を WebAPI で接続し、シームレスに扱える情報基盤の構築を行った。また、スマートフォン

画面による遠隔制御や音声認識端末によるエアコン制御等のサービスを試作し、既存住宅のモニ

タ家庭にてサービスの評価や機器の遠隔モニタリングの有用性等について評価を行った。

システムの構築にあたっては、各社クラウドサーバーと直接、ヤフーが提供する API 連携サー

ビス経由、宅内に設置したエッジ側のサーバー（ホームゲートウェイ）経由の 3 つの異なる方法

でシステム連携を行った。各社サーバーとの直接接続では、企業同士の密な連携には向いている

が接続する上での技術検討や契約交渉に時間を要すること、各社が提供している既存サービスに

左右されるためメーカ間での差異が発生しやすいことを確認した。逆に API 連携サービス経由で

は、1 社と契約することで多様な機器と連携でき、複数の機器を組み合わせたサービスの提供が

できるが、現時点ではリアルタイムなモニタリングや制御など、密な連携が難しいことを確認し

た。ホームゲートウェイ経由での接続では、ローカルネットワーク向けの API を MQTT の

PUB/SUB を活用することでほぼリアルタイムなモニタリングや制御が可能なことを確認した。

また情報基盤に実装した「統合 WebAPI」を用いて、連携した機能やサービスを組み合わせた様々

なサービス開発が可能であることを確認した。

モニタ評価では、連携した機能やサービスをまとめて閲覧・操作できるスマートフォン画面や

音声によるエアコン操作や情報配信などのサービスを体験してもらった上でアンケート調査を行

った。スマートフォン画面では、個々のアプリや Web サービスなど複数の機能を「まとめる」事

54

へのニーズが高いことが確認できたが、個人のニーズや各社のビジネス展開もふまえ、いかにま

とめていくかは今後の課題である。音声による操作との比較では、スマートフォン画面、音声、

内容によるといった意見に三分されたが、新たなユーザインタフェースとして一定の評価を確認

できた。一方で認識率や反応速度の改善、単なるリモコンの置き換えではない顧客ベネフィット

の向上が課題として挙げられた。その上では今回評価が高かった、毎朝天気予報を通知するとい

った音声発話と組み合わせる方法が考えられるが、企業からの情報が入る事には否定的な意見が

多かったので注意が必要である。

また実施にあたっては、取得するデータや個人情報等の扱いを定めた規約を作成、合意を得た

33 件の家庭に通信機器や IoT 機器を設置し遠隔管理を行うことで、販売から保守を含めた運用面

での検証も行った。規約の合意にあたっては、住宅を購入して頂いた顧客ということもあり個人

情報保護には関心が低かったものの、情報量が多すぎてわかりにくいという意見も多かった。IoT

機器については、設定にユーザのスマートフォンを操作する必要があるなど、現状では住宅メー

カとして扱うのは課題が多いことを確認した。保守については、通信機器やコントローラーの遠

隔モニタリングやファームウェア更新を可能とすることで、保守費用の軽減に寄与できることを

確認した。本来なら現地に出向いて調査・復旧が必要な障害をインターネット経由で解決できた

事例もあり、今後のスマートホーム展開には必須要件と考えられる。

2.2.5.2. 全体を通じての考察

本実証にて様々な企業の IoT 機器やクラウドサービスを連携させたが、各社が独自に展開して

いるものを後付けで連携するのはまとめる側の開発・運用負担が大きい。とはいえ全体で接続方

法の標準化を図るのは難しいほか、変化の速い情報技術の展開から取り残される可能性も高い。

まずはシステム開発の初期段階から外部サービスとの連携を前提に設計を行うこと、何等かの

API を実装し開示できる準備をしておくことが重要だと思われる。その際サービス全体としての

責任区分が不明確になるので、住宅・家電・通信など、業界ごとにある程度の指針を示し事前に

調整をしておくほか、その内容を顧客にも周知させる必要がある。今では当たり前となった情報

化配線も、住宅設備として定着するまでには 10 年の期間を要した。最新の技術や機器を現実路線

で取り込みつつ、定着させていく上での地道な努力が必要と思われる。

サービス面では、狙いとしていた複数の機器やサービスを「まとめる」コンセプトへの評価が

高かったが、毎朝決まった時間に天気予報を通知するような「わかりやすくシンプルなサービス」

が求められているということかと思われる。わかりやすいとは、サービスに活用するデータやロ

ジック等の中身をユーザが「理解できる」ことであり、まとめる事でサービスがより複雑になっ

たり、ブラックボックス化しては意味が無い。取得する情報や機器を制御する上でのリスク次項

も含めて、直感的に理解しやすいロジック作成機能やユーザインタフェースを工夫する必要があ

る。

2.2.5.3. 今後に向けた提言

最後に今回の実証結果をふまえ、今後に向けた提言を述べたい。

55

① ECHONET Lite 機器は、「つながる」から「つなげる」へ

今回実証に使ったエアコンは、家電メーカのクラウドサーバー経由、赤外線リモコン経由、

ECHONET Lite コントローラー経由の 3 種類の方法でネットワーク接続を行った。このうち最

も簡単に確実に接続できたのは ECHONET Lite コントローラー経由である。コントローラーと

同一ネットワークに通信アダプタを接続するだけで自動的に発見・登録されるので、メーカや機

器の違いを意識する事なく接続することができた。一般に簡単と言われている赤外線リモコンだ

が、あくまで DIY レベルの話であり、企業として施工するには各社で異なる設定方法の水平展開

やアプリのアップデート対応手間がかかる。スマートスピーカーの登場で家電機器を操作したい

ニーズは高まっており、対応に向け簡単につながりステイタスも取れる ECHONET Lite 機器の

訴求をすべきと思われる。

課題としては、対応機器は普及しているものの実際に活用されていないことである。一番の原

因は専門業者による通信アダプタの設置が必要な点であり、機器への内蔵化、せめて USB のよう

に接続端子の外出しが求められる。また、対応機器に比べ ECHONET Lite 対応のコントローラ

ーが普及していない点もあげられる。これについては新築住宅中心の HEMS コントローラーだ

けではなく、後付け可能な様々な機器に ECHONET Lite コントローラー機能を搭載し裾野を広

げていけばどうかと思われる。今回エッジ側サーバーの開発でベースとした「PicoGW」は、

Javascript で実装した軽量な ECHONET Lite コントローラーであり、node.js が搭載可能な様々

な端末で動作させることができる。神奈川工科大学よりオープンソースで提供されており、外部

連携用の API も実装されていることから、無線ルータや音声認識端末など様々な機器に

ECHONET Lite 制御機能を搭載することが可能である。

② 「まとめた」機能の付加価値を向上させるサービス開発基盤の整備

今回新たなユーザインタフェースとして一定の評価が得られた音声による家電制御も、単なる

ON/OFF だけでは定着するサービスになるとはいい難い。「でかけます」「寝ます」といった生活

シーンに合わせた複数機器のシナリオ制御への展開が求められる。それには、時間帯や屋内外の

温湿度環境、機器の操作履歴や各種センサ情報等からユーザの意図をくみ取り、結果のフィード

バックによる制御ロジックの最適化が必要である。

問題はそうしたロジックをどこにどう実装するかである。クラウドサーバーやローカル側の機

器への実装、企業側が開発する場合やユーザ自身で設定する場合などが考えられるが、トレード

オフの関係にあるので、狙いとするユーザやビジネスモデルに応じて検討する必要がある。

56

表 2-17 サービスロジックの提供方法

③ユーザ自身が開発・設定 ④企業側が開発したものをユーザが利用

実装例 実装例

①

ロ

ー

カ

ル

実

装

ローカルの

API を活用

し、ユーザ自

身がロジック

を実行するア

プリを開発す

る

メ

リ

ッ

ト

・企業側の開発負担が少なく自

由度の高いロジック作成が可能

・ユーザ含めた多様な開発者が

参画できる

企業が開発し

たシナリオを

HGW 上で実行

する

メ

リ

ッ

ト

・企業側の管理下で提供されるの

で、確実な動作が期待できる

・インターネット接続に不具合があ

っても実行可能

課

題

・相応の開発スキルが必要

・スマホアプリの場合、スマホを

持ち出すと実行できない

課

題

・サービスが決め打ちされる

・他企業が参入しにくい

・HGW へのインストールや、バージ

ョン管理が繁雑

②

ク

ラ

ウ

ド

実

装

myThings や

IFTTT 等のア

プリを使い、

シナリオを設

定する

メ

リ

ッ

ト

・ニーズにあったサービスを自

由に開発できる

・スマホを持ち出していても、電

源が OFF でも利用可能

企業が開発し

たシナリオ

（Web アプリ）を

開発しユーザ

に使ってもらう

メ

リ

ッ

ト

・企業側も開発しやすく、ユーザ側

の負担も少ない

・他企業も参入しやすい

課

題

・一般的なユーザには使いこな

すのが難しいと思われる

・サービス連携の為の認証設定

や認証切れ対応等に手間がか

かる

課

題

・サービスが決め打ちされる

・他企業が参入しにくい

・企業側のコスト負担増

③ BtoB 向けの IoT 機器開発の推進

後付け可能で安価に手軽に最新のサービスが利用できる IoT 機器は非常に魅力的であり、

ECHONET Lite で動作する住宅設備機器と組み合わせる事でより付加価値の高いサービスが提

供できる。それには DIY ではなく、住宅メーカをはじめとした事業者が責任を持って提供できる

IoT 機器の開発が必要ではないかと思われる。今回活用した API 連携サービス myThings も、事

業者向けの myThings developers を提供しており、独自のシナリオ作成や画面開発が可能になっ

ている。設定画面や遠隔保守機能、ある程度の機器やサービスの継続性など、事業者側が扱いや

すい機能の実装を期待したい。またスマートロックの鍵の受け渡しのしくみと既存の電気錠を組

み合わせるなど、IoT と住宅設備機器が融合した新たな製品開発にも取り組んでいくべきかと思

われる。

57

2.3. スマート製品ライフサイクルに関する実証

本節では、日立製作所、東京電力パワーグリッド、Warrantee、及びヤマトシステム開発によ

る実施概要を示す（詳細は第 4 分冊を参照）。

2.3.1. 事業の目的と全体像

家電の効率的なリサイクル手続やリコール対応などの製品ライフサイクルサービスをモニタに

使用してもらい、リサイクルやリコールなどの対応促進に繋がるサービス・システム・制度のあ

り方を検討すると共に当該サービスに関する課題を抽出することを目的に実証を実施した。事業

の全体像を図 2-23 に示す。

図 2-23 事業の全体像

製品ライフサイクルサービスでは、リサイクル手配・リユース手配・修理手配・リコール対応

に関する手配手続・物流をワンストップで提供し、また、これを容易化するために製品登録・保

証書登録等、製品使用状況把握のサービスを合わせて提供した。製品ライフサイクルサービスの

概要を図 2-24 に示す。

システム開発・試験 実証 評価

製品のリサイクル手配及びリコール対応を中心とした製品ライフサイクルサービスを提供するシステムを開発・構築し、ハウスメーカのシステムと連係しモニタ宅においてモニタが本サービスを利用できるようにする。

モニタに、本サービスを試行的に使用してもらう。実証終了後にモニタにアンケートを実施する。

システム開発・試験及び実証の結果を基に、リサイクルやリコールなどの対応の促進に繋がる仕組み（サービス・システム・制度のあり方）を検討する。

ハウスメーカ

UI

サービスUI

機器制御

情報提供

その他サービス

リサイクル手配リコール対応その他サービス

ハウスメーカによるスマートホームサービス

製品ライフサイクルサービス

モニタリサイクルやリコールなどの対応を促進するための仕組みの仮説

スマートホームサービスと製品ライフサイクルサービスを連係させる

製品ライフサイクルサービスをUIを介してワンストップで提供する

いつでも利用できるようにする

一度に手配できるようにする

製品ライフサイクルサービスをITサービスとして提供する

簡単に操作できるようにする

58

図 2-24 製品ライフサイクルサービスの概要

2.3.2. 実証内容

2.3.2.1. 実証内容の全体像

本実証では、図 2-25 に示すとおり 5 つのユースケースのサービスを提供し、指定の家電にお

いてモニタに模擬的にサービスを活用していただいた。

図 2-25 サービス内容

No サービス 対象 内容

1 リサイクル手配 家電 4 品目 スマホ操作により、家電リサイクル法に基づき、集荷

（家電リサイクル法上の小売業者への引渡し）並び

にリサイクル料金及び収集運搬料金決済までの手配

を全て行えるようにする。

2 小型家電 スマホ操作により、小型家電リサイクル法に基づき、

集荷（認定事業者までの運搬を行う事業者への引渡

し）並びにリサイクル料金及び収集運搬料金決済ま

での手配を全て行えるようにする。

3 リコール対応 家電 4 品目、

小型家電

リコール発生家電製品メーカからのリコール通知依

頼があると、その対象家電製品の所有者のスマホに

リコール通知を届ける。また、その回収をスマホ操作

により申し込むことができるようにする。

4 リユース手配 スマホ操作により、家電製品の売却の手配を行える

ようにする。

連係サービスクラウド

修理会社物流クラウド

電力情報クラウド

リサイクル・廃棄物処理業者

中古品販売業者

製品梱包

機器メーカ

訪問

回収

配送（運搬）

物流事業者

物流手配

物流手配各種手配

製品情報DB

保証書登録

使用状況提供（家電種別、消費電力）

機器メーカリコール担当

リコール通知

製品検索

リコール通知UI

クラウド(ﾊｳｽﾒｰｶ)

電力センサ

モニタ宅

モニタ スマホ

物流クラウド

物流クラウド

※家電４品目は指定引取場所への引渡し※小型家電は認定事業者への引渡し

59

No サービス 対象 内容

5 修理手配 スマホ操作により、家電製品の修理の手配を行える

ようにする

※任意参加のサービスとして、実際にモニタが所有する家電についても上記と同様のサービスを

提供するようシステム開発・試験を実施した。システム開発・試験による検証は行うことがで

きたが、モニタの使用は発生しなかった。

本実証で提供するサービス利用に誘導するため等のサービスとして、図 2-26 に示す 2 つを提

供した（これらは本実証で用意した家電以外の、モニタ所有の家電も対象とした。）

図 2-26 サービス利用に誘導するためのサービス

No サービス 内容

6 製品登録・保証書

登録等

スマホで保証書を撮影して家電製品と共に保証書も管理する機能の

他に、家電製品のメーカ名や製品名の一部を入力すると候補をリスト

アップして、家電製品を簡単に登録できるようにした。

7 使用家電把握 対象家庭に設置した電力センサからデータを収集し、クラウドにて家

庭にある家電の種別を推定し、製品登録を促すお知らせを通知するよ

うにした。

2.3.2.2. 製品ライフサイクルアプリケーションの例

本実証では、下記アプリケーションを用いて、各種サービスの実証を行った。

まず本実証用に用意された家電製品データベースを基に、家電 4 品目・小型家電、実証対象機

器か否かの判別をシステムで自動判別できるようデータベース改変を行う事でそれを実現した。

それにより、モニタがリサイクル模擬実験対象の家電製品を登録したら模擬実証用の WEB サ

ービス画面を表示・遷移させ、模擬実験を行えるようにした。

また、モニタの居住地域毎に、当該自治体にモニタが直接依頼してリサイクル手配もできるよ

う、WEB サービス画面遷移の中で案内を行った。

以下に製品ライフサイクルアプリケーションの画面フローの一例を示す。

60

■実証Ⅰ（家電 4 品目）

61

図 2-27 リサイクル手配（家電 4 品目）の主な画面フロー

62

■実証Ⅰ（リサイクル小型家電）

図 2-28 リサイクル手配（小型家電）の主な画面フロー

63

2.3.3. 実証結果

実証結果を表 2-18 に示す。実証参加に同意したものの実際に操作するモニタ数が伸びなかっ

たため、実証期間中に戸別訪問し実証への協力をお願いした。

表 2-18 参加モニタ数

積水ハウスモニタ 大和ハウスモニタ

製品ライフサイクル

実証参加モニタ数

同意者数 24 件 29 件

製品登録者数 19 件 26 件

実証参加者数 16 件 25 件

アンケート回答数 20 件 25 件

2.3.4. 実証を通じた論点の整理

2.3.4.1. データカタログ

データカタログは、データを利用してサービスを開発・提供するサービス事業者向けに、デー

タを見つけ、利用する際に必要となる情報（データの説明、形式等）を分かり易い形で提供する

ものである。本実証では、データ提供およびデータ利用の両方の視点で、サービス開発に有効と

考えられるデータの基本要件について検討を行った。特に、本検討では、高次レベルデータにつ

いて重点的に検討した。なお、高次レベルデータとは、複数の機器や機器以外のデータを複合的

に利用し生成されるデータである。

下表に、高次レベルデータの検討結果を示す。なお、本検討にあたっては、製品ライフサイク

ルサービスおよびそのための物流サービスというサービス事業者側視点と、電力センサによる分

（１）積水ハウスモニタ宅操作者数（単位：モニタ数（件））

（２）大和ハウスモニタ宅操作者数（単位：モニタ数（件））

ログイン

製品登録 リサイクル リユース 修理 リコール

エアコン

照明空気清浄機

特定家電その他機器

空気清浄機

特定家電空気清浄機

特定家電エアコン

エアコン

空気清浄機4品目

小型家電

4品目小型家電

4品目小型家電

モニタ数

19 18 18 19 2 8 6 14 1 5 16 1 2 14 12 12

ログイン

製品登録 リサイクル リユース 修理 リコール

照明赤外線ﾘﾓｺﾝ

その他機器

照明赤外線ﾘﾓｺﾝ

エアコン

エアコン

鍵センサ

モニタ数

26 26 26 12 26 20 25 20 21

※モニタが実証を行う住居への引っ越しの際に買い替えた家電製品があれば、当該家電製品も本サービスにおける実証対象機器とするようモニタに依頼した。上記表においては、当該家電を、「特定家電」と記載している。

64

析結果に加えて他のセンサ等の情報を複合的に利用し生成されるデータをどのように利活用でき

るかの視点を考慮した。

表 2-19 高次レベルデータの検討結果

データ名

（データ種

別）

データカテゴ

リデータ意味

データ項目・単

位利用データ 計算方式 活用サービス例

在宅予測 生活パターン指定時刻帯の在宅確

率確率（％）

[宅内データ]データカタログ基礎レベル

データ（電力消費、エアコン操作履歴、ス

マートロック動作履歴、室内温度）、カレ

ンダー情報

[宅外データ]天気予報

過去の時刻ごとの在宅・不在情報、家電の操作履歴、

天気予報などの利用データをもとにディープラーニン

グによる学習

宅配最適ルート提示

製品安全情報 製品情報

各家庭が保有してい

る家電のリコール情

報

リコール情報

（製品単位）

メーカーのリコール情報、家電保証書登録

情報、電力機器分離情報- リコール通知

配送状況 輸送情報

該当住宅までの所要時

間、もしくは配達時間

(帯)

時間(分)

or

時間帯(○時～○時)

[位置情報]

・配達員の位置情報

・地図情報

[荷物情報]

・配送情報(件数／配送先／配送順etc..)

配送情報を基として、配達員の現在地、配達予定(件

数、順番)と配送先住所を照らし合わせて所要時間、到

着予想時刻を算出

配達時刻お知らせ

家電種別毎電力 使用情報 家電毎の消費電力 電力値(W) 分電盤で計測する電力波形 ー 家電買い替え判断

家電金額(時

価)製品情報 家電の価値 金額（円）

家電の定価、使用年数、使用頻度、中古市

場価格

使用状況などから経年劣化を考慮した時価額を算出で

きることが望ましい

レンタル家電の資産

管理

家電稼動開始

時期使用情報

家電が設置・稼動開

始した年月日

年月日

(YYYYMMDD)ー ー

レンタル家電の資産

管理

家電稼動日履

歴使用情報

家電が稼動していた

期間

年月日

(YYYYMMDD)～

年月日

(YYYYMMDD)

ー ーレンタル家電の資産

管理

家電所有者 使用情報所有している人物・

事業者を識別する

名称（文字

列）、何らかの

ID

購入決済情報、製品登録した人物の識別子・購入品の場合は所有している人物を識別する情報

・レンタル・リース品の場合は事業者を識別する情報広告配信

家電使用者 使用情報使用している人物を

識別する

名称（文字

列）、何らかの

ID

遠隔制御したユーザの識別子

・家族全員で使用するものか、個人で飛揚するものか

を識別する情報

・個人で使用する場合は使用する人物を識別する情報

広告配信

買い替え製品

情報製品情報 買い替えアドバイス 文字列

既存製品情報（製品メーカ名、種別名、型

番）、新製品情報（製品メーカ名、種別

名、型番）、比較情報

ー 広告配信

在宅活動状態

使用情報

活動時間帯、活動場

所（部屋）、活動人

物、活動量、活動量

推移

要検討人感センサ情報、家電稼動情報、場所情

報、活動量センサー 見守り訪問

65

また、高次レベルデータの活用について検討した結果を 2 つ示す。

下図は、データカタログ「時間帯毎の活動量」を見守り訪問サービスに活用する例である。

図 2-29 データカタログの活用例（見守り訪問）

図 2-30 データカタログの活用例（レンタル家電の資産管理）

66

2.3.4.2. セキュリティ・製品安全

セキュリティ対策については、以下のような 3 つの観点で検討・実装を進めた。

・システム全体でのセキュリティ対策

・クラウド間（サブシステム間）でのセキュリティ対策

・クラウド内（サブシステム内）でのセキュリティ対策

なお、宅内機器から直接データを入手することや、宅内機器からクラウドを経由してそのデー

タを入手することはないので、具体的には、以下を検討対象とした。

・システム全体でのセキュリティ対策

積水ハウスおよび大和ハウスのシステムとの連係におけるセキュリティ対策

・クラウド間（サブシステム間）でのセキュリティ対策

サービスクラウドと関連する各クラウドとの連係におけるセキュリティ対策

・クラウド内（サブシステム内）でのセキュリティ対策

サービスクラウド内でのセキュリティ対策

物流クラウド内でのセキュリティ対策

電力情報クラウド内でのセキュリティ対策

なお、本実証では宅内機器からデータを取得した宅内機器を制御したりすることはないため製

品安全に関しては検討対象外とした。

上記観点を踏まえ、各セキュリティ対策指針に対して、以下のような対策を施した。

67

表 2-20 本実証でのセキュリティ対策

システムインテグレータ

セキュリティ対策指針

（チェックリスト）実証事業における実施内容

「セキュリティ対策

指針（チェックリス

ト）」の改訂案（除

外・追加すべき項目

とその理由、必須/任

意の変更）

「セキュリティ対策

指針（チェックリス

ト）」の必須/任意の

変更の必要性

①経営層によるコミット（必要なリソースの割当

等）（任意）

CEOがセキュリティポリシー作成および執行の総責任者として社内への周

知・ポリシーの策定・教育・予算化を自ら担い、CTOがシステム面における

セキュリティ設計・開発・運用を行った。

なし なし

②PDCAサイクルを回す仕組みを導入する（必須）要件定義に沿った開発に対するコンソ内レビュー・改善案を再開発による改

善・課題解決するサイクルを実施した。なし なし

①守るべきものの特定、アーキテクチャを元に、

リスクとその範囲を考慮する(内部不正やミスの発

生を考慮する）(必須)

認証・情報・経路について、各々リスクの洗い出しと対策について分析を

行った。なし なし

②プライバシー情報漏洩のリスクと影響分析の実

施(必須)認証・情報・経路においてそれぞれリスク分析を行った。 なし なし

①セキュリティ、セーフティ、プライバシーの影

響を考慮した設計(Security, Safety, Privacy by

Design：SSPbD) (必須)

・ユーザーがデータにアクセスする場合は認証トークンを必須とし、ユー

ザー自身以外のデータにはアクセス出来ないように制限した。

・パスワードやクレジットカード情報は、トークン化もしくは暗号化するこ

とによって、仮に漏洩しても特定されないように設計した。

・DBの定期的なバックアップを実施した。

・データアップロードやＡＰＩ連携では多重認証を実装し、各種リスクに対

する防護策をとった。

・クラウド間連携(SFTP)では多重認証を実装し、各種リスクに対する防護策

をとった。

なし なし

②遠隔操作における製品安全に係わる問題の考慮

（必須）対象外（遠隔操作なし）

③安全安心を実現する設計の検証の実施(必須) 社内検証用・コンソおよび関係者検証用・本番環境と、相互に影響の出ない

よう3つにシステムを完全分離し、検証を実施。なし なし

④多層防御（多重のセキュリティ対策の考慮）(必

須)

・サーバーとクライアント間にSSLやVPCを導入し、データベースの項目事態

にも暗号化を施した。

・クラウド間連携ではID・PW認証に加え、IPフィルタリングを実施し、多重

の防護策をとった。

なし なし

⑤ログ・監視機能の導入(必須)

・ソフトウェアを通じ、機器登録・サービス依頼発生時にログ収集が実施さ

れる仕組みを構築した。

・またシステム上で不具合検知した際等にアラート通知する仕組みを構築し

運用した。

・モニタ宅のネットワーク異常や不正アクセスを検知する機能を実装した。

・ネットワーク、機器の異常や不正アクセスを監視・検知する機能を設計に

組み込んだ。

なし なし

⑥主要IoTセキュリティガイドラインの考慮

(OWASP/IoT Top 10等）(任意) ー ー ー

①設計を満たす実装であることのテストの実施(必

須)

・認証・情報・経路について、セキュリティが設計通りに実装されている事

を検証環境で確認した上で本番環境への実装・反映を行った。

・実装前に実施した。

なし なし

②構築（インテグレーション）時の設定等の検証

（必須）

・複数のアカウントを用意し、それぞれに対して各画面で正しい認証トーク

ン、間違った認証トークンでアクセスを実施。仕様の想定通りにアクセス制

御が出来ることを確認した。

・各電力センサーが個別の認証キーをもっており、それを用いてクラウド連

系を実施した。

・ID・PW認証に加え、IPアドレスの制限が機能していることを確認し、事前

にWaranteeクラウドとヤマトシステム開発クラウドとの疎通テストを実施し

た。

なし なし

③機器の状態把握、記録機能の実現（任意） データアップロード状態を監視した。 なし なし

①モニタリングと異常検知の実施(必須)

・ネットワーク・サーバー環境、システム、モニターの操作に伴う情報登録

等について、アラートシステムの仕組みを構築し、ログ収集および監視を

行った。

・データアップロード、ＡＰＩへのアクセス等各種ログの取得と監視を運用

した。

なし なし

②サービス追加・連携における検証(任意)

・新規サービスを開始する際、事前にハウスメーカUIとの疎通確認を実施し

た。

・テスト環境を構築し検証を随時実施した。

・ハウスメーカ向けにモニター操作ログを閲覧するための管理ツールを開

発・提供した。

なし なし

5. 運用・保守・廃棄の

対策

システム・インテグレータ記入欄

対策区分

1. 基本方針の策定

2. リスク評価

3. 設計時の対策

4. 実装・構築時の対策

68

2.3.4.3. プライバシーデータの活用／サービスの創出

プライバシーデータの活用については、以下の観点で検討を進めた。

①製品ライフサイクルサービスにおける個人情報および実証データの明確化

②製品ライフサイクルサービスにおける関連事業者間での個人情報および実証データの移

転およびその契約

③ハウスメーカとの間での個人情報および実証データの移転の明確化

詳細については後述する。

④モニタに提示する同意書（規約）の作成

別紙として添付する。個人情報および実証データの詳細は同意書に記載。

⑤モニタに提示する個人情報の取扱いに関するリーフレットの作成

別紙として添付する。

上記③のデータの移転について、下表のように整理した。

表 2-21 ハウスメーカとの間での個人情報および実証データの移転

そして、この検討結果に基づき、モニタとの契約（実証への参加同意）、実証システムの開発・

運用、製品ライフサイクルサービスの提供を行い、実証を進めた。

その結果、以下に示すように、プライバシーデータの活用に関して特に問題は発生しなかった。

69

・同意取得は容易だったか

同意取得時に、プライバシーやデータ利用に関する問い合わせ等はなく、スムーズだった。

・実証期間中に苦情や問い合わせは無かったか

プライバシーやデータ利用に関する問い合わせや利用停止の要請は、特になかった。

・個人情報の取扱いへの不安に関するアンケート結果

積水ハウスモニタ：下図に示すように不安がないという傾向であった。

図 2-31 個人情報の取扱いへの不安に関するアンケート結果

大和ハウスモニタ：大和ハウスの個人情報取扱いに関するアンケートの中で実施。

特に不安はない、という傾向であった。

自由記入意見について：

・どんな情報がどこまで取られ、利用されるのか不安。

・レンタルのスマホだったため不安。

・宅配業者に情報が届くことが不安（会社としてしっかりしていても、配送員まで

ルールが徹底しているか不安）。

特に問題は起きなかったものの、積水ハウスのアンケート結果から、約 1/5 のモニタが不安に

感じており、契約時だけでなくサービス利用している途中にも個人情報や実証データの取扱いに

関する情報を提供するなど、常に不安をなくす努力が必要であろう。

70

第3章 実証を通じた論点の整理

本事業では、実際の世帯（戸建て、集合）において、一つのユーザインタフェース上で多様な

機器の操作やサービスを享受できる実証環境を構築し、実モニタに対してサービスを提供するこ

とで、他社間連携上の論点について検討を行った。本章では、各々の論点に係る検討結果を示す。

3.1. データカタログ

3.1.1. 目的

スマートホーム機器の横断的なデータ連携により、IoT のネットワーク効果、ポジティブフィ

ードバックを高めることで、新たなサービスの創出を促進することを目指し、求められる入出力

データ項目および拡張性の高いデータ構造について検討することを目的とする。

3.1.2. 論点

当初の論点およびSWG、事業環境構築検討会を通じて挙げられた論点は以下のとおりである。

表 3-1 データカタログに関する論点

区分 論点内容

当初からの論点

個々のアクション（業務）についてマンダトリーの出入力データ項目は

どうあるべきか

アクションの追加（新規設計）が随時行える拡張性が高いデータ構造は

どうあるべきか。

SWG・事業環境

構築検討会を通

じて挙げられた

論点

サービス事業者のニーズとデータ提供者のシーズのギャップを解消する

仕組みが必要

プリミティブなデータからサービスを開発するにはギャップが大きいた

め、サービスのレベルに近い高次のデータ（複数のデータを組合わせて

分析したデータ）の提供を促進する仕組みが必要

変化の速い競争領域であるため、具体的な API 設計は、民間事業者に委

ね、利用者が必要とするデータの説明（データカタログ）の整理に焦点

を当てるべき。

プリミティブなデータについても、機器によるデータの意味、属性が多

様であるため、既存の ECHONET Lite も活用しつつ共通するデータ項

目を整理する。

業界でのデータの蓄積に伴い、共通する概念(位置、時間、温度など)の分

類・整理を行い、改訂メンテナンスの方法を検討する必要がある。

71

データカタログに、データの信頼性など評価情報を追加する必要がある

のではないか。

3.1.3. 検討結果

本検討では、スマートホーム機器の横断的なデータ連携により、新たなサービスの創出を促進

することを目的として、データカタログの枠組みとデータの基本構造について検討した結果を整

理した。

データカタログとは、データを利用してサービスを開発するサービス事業者に対して、データ

を見つけ、利用する際に必要となる情報（データの分類、形式等のメタ情報）を提供するもので

ある。

(1) データカタログの枠組み

データ連携によるサービス開発においては、サービス開発者（データ利用者）のニーズとデー

タ提供者のシーズのギャップを解消する仕組みが必要である。プリミティブなデータからサービ

スを開発するにはギャップが大きいため、サービスのレベルに近い高次のデータ（複数のデータ

を組合わせて分析したデータ）の提供を促進する仕組みが必要である。したがって、本検討にお

いては、下図に示すとおり、機器のセンサから提供されるプリミティブなデータのインタフェー

スである基礎レベルのデータと、それらのデータを組合せてサービスに近い高次レベルのデータ

をサービス事業者に近い高次レベルのデータ・インタフェースを提供する。これにより、高次レ

ベルのデータと基礎レベルのデータが明確になり、そのギャップを埋めることが可能となる。

図 3-1 データカタログの枠組み

高次レベルのデータ（サービス事業者に合ったデータ・インタフェース）

基礎レベルのデータ※（機器の提供データ・インタフェース）

サービサー プロシューマサービサー プロシューマ

サービス事業者 プロシューマ

機器ベンダー機器ベンダー

機器ベンダー

利用

ギャップ解消

提供データシーズ

ギャップ

ITベンダー

機器ベンダー

サービス事業者

提供提供

利用

提供

利用データニーズ

72

※1 高次レベルのデータの例

在宅予測、健康状態、ストレス状態、メンテナンス要否、活動パターン、統合空調環境、統合照明

環境、外出時機器一括操作、…

※2 エコーネットコンソーシアムの活動成果を活用

高次レベルのデータと基礎レベルのデータについて説明するデータ（メタデータ）の基本構造

を示すことにより、データの管理を可能にする。データの基本構造については次のとおりである。

(2) データの基本構造

高次レベルのデータと基礎レベルのデータの基本構造は下図のとおりである。

図 3-2 データカタログのデータ基本構造

高次レベル、基礎レベルともに、必須とオプション項目があり、記述要素において、データ

区分 記述要素（メタデータスキーマ）

(例)在宅予測※1

（データカタログ）

必須

データ意味 時間帯ごとの在宅確率

データ項目・単位 4時間ごとの確率(%)

拡張属性等 過去1年のデータからの推定値

通信方式(プロトコル)

https (RESTful API), web socketは含まない

オプ

ション

利用データ

[宅内データ]家電の操作履歴、スマートロック動作履歴、室内温度、カレンダー情報[宅外データ]天気予報

計算方式ディープラーニングによる学習結果

区分 記述要素（メタデータスキーマ）

(例)室温（データカタログ）

必須

データ意味 現在の室温

データ項目・単位 最新時刻の摂氏温度(℃)

拡張属性等 位置情報(室内中央、高さ1m)

通信方式(プロトコル)

https (RESTful API)

オプション

利用データ エアコン室内温度センサー

計算方式 センサーデータを温度変換

高次レベルのデータ

データの記述要素(WSDL等で記述）

記述要素に基づきデータを説明

基礎レベルのデータ

73

意味、単位、利用データなどデータについて提供すべき情報を規定する。それらの項目に従

い、対象とするデータに関する説明をまとめたものがデータカタログである。データカタログ

はデータに対する説明でありメタデータに相当するものであり、記述要素は、メタデータのデ

ータ構造を規定するためメタデータスキーマと捉えることができる。

(3) 電子情報技術産業協会における検討

事業構築検討会にオブザーバ参加している電子情報技術産業協会において、データカタログ

の考え方について検討・整理した結果が下図である。

（出所：スマートホームデータ連携に向けて、（一社）電子情報技術産業協会（JEITA）、

平成 30 年 2 月）

図 3-3 スマートホームデータカタログの定義

(4) 高次レベルのデータの整理

本実証においては、問題意識として、分野横断的なデータ連携によるサービス創出を促進する

上で、サービスレベルに近い高次レベルデータの提供が重要という議論のもと、新たなコンセプ

トとして高次レベルのデータの重点を置いて検討を行った。

実証を通じて、事業者による検討の結果、高次レベルのデータを収集し整理を行った。主な高

次レベルのデータを整理した結果が下図である。

74

図 3-4 主な高次レベルのデータと活用サービス例

※主な属性のみ抽出

高次レベルのデータは、生活パターン、製品情報などのカテゴリで分類され、データ項目の単

位や利用するデータ（基礎レベルのデータ等）をまとめている。データの利用者は、カテゴリ、

データの意味、活用サービスなどの確認することで利用するデータを特定したり、データのイン

タフェースを確認することができる。

(5) 高次レベルデータ活用サービスの検討結果（例）

実証事業を通じて、データカタログの活用イメージの理解と有用性を摑むため、高次レベルデ

ータを活用するサービスの検討を行った。下図は、データカタログの高次レベルデータを活用し

たサービスの例として、宅配サービスのルート提示を示したものである。

データ名（高次データ）

データカテゴリ

データ意味 データ項目・単位 利用データ 活用サービス例※2

在宅予測

生活パターン

指定時刻帯の在宅確率 確率（％）[宅内データ]データカタログ基礎レベルデータ（電力消費、エアコン操作履歴、スマートロック動作履歴、室内温度）、カレンダー情報[宅外データ]天気予報

宅配最適ルート提示

安否異常安否に関わる異常が発生した確率

％家電機器の操作履歴、睡眠センサ（リストバンド）による睡眠パターン、玄関錠操作履歴

遠隔ケアサポートサービス 17

（DINKS生活スタイル）食の志向（内食・外食）

曜日別における行動確率 確率（％） [宅内データ]家電別電力消費 飲食料品の最適な提供量提示 13

邸宅出入り 玄関からの出入り情報 時刻玄関での人感センサー、画像データ、ドアセンサー（出入り判断）、天気予報

玄関見守りサービス22

家電利用状況 家電の利用状況と故障予測 確率（％）データカタログ基礎レベルデータ（電力消費量、家電操作履歴）

機器メンテナンス通知 23

居住者の生活異常通知

居住者の生活異常検出とPUSH通知

異常種別、緊急度等

電力使用量、家電操作履歴 見守りサービス等 14

連絡可否Statusの確認

連絡可否Status確認API連絡可否受容度（4段階など）

家電操作履歴、電力使用量 宅配サービス等 15

製品安全情報

製品情報

各家庭が保有している家電のリコール情報

リコール情報（製品単位）

メーカーのリコール情報、家電保証書登録情報、電力機器分離情報

リコール通知

家電金額(時価) 家電の価値 金額（円） 家電の定価、使用年数、使用頻度、中古市場価格 レンタル家電の資産管理 20

買い替え製品情報 買い替えアドバイス 文字列既存製品情報（製品メーカ名、種別名、型番）、新製品情報（製品メーカ名、種別名、型番）、比較情報

広告配信

節電可能電力値電力消費パターン

指定時間における節電可能な電力量

kW、kWh過去の消費電力パターンと当日の消費電力量、ユーザーの自己申告による節電可能機器のリスト

節電割引サービス 18

配送状況 輸送情報該当住宅までの所要時間、もしくは配達時間(帯)

時間(分)or時間帯(○時～○時)

[位置情報]・配達員の位置情報・地図情報[荷物情報]・配送情報(件数／配送先／配送順etc..)

配達時刻お知らせ

故障予測 遠隔保守 故障発生確率 ％ 電力消費データ、機器操作履歴、エラー発生時刻・内容 遠隔保守サービス 16

家電種別毎電力

使用情報

家電毎の消費電力 電力値(W) 分電盤で計測する電力波形 家電買い替え判断

家電所有者所有している人物・事業者を識別する

名称（文字列）、何らかのID

購入決済情報、製品登録した人物の識別子 広告配信

在宅活動状態活動時間帯、活動場所（部屋）、活動人物、活動量、活動量推移

要検討人感センサ情報、家電稼動情報、場所情報、活動量センサ

見守り訪問 21

生活パターン関連サービス

75

図 3-5 高次レベルデータの活用サービス例（宅配サービス最適ルート提示）

このサービス例は、宅配事業者が、配達先の在宅予測、配達時間指定、配達先住所などの情

報をもとに、最適な配達ルートを提示するものである。利用する高次レベルデータは、スマー

トホーム機器からの様々なデータを総合して、宅内の在宅確率を示す在宅予測データである。

これにより以下のような効果と価値が得られると想定される。

効果

配達先の在宅予測情報を活用することで、不在による時間ロスを最小化した宅配の効率

化を図る。

➢ 関連市場規模

(宅配市場規模)1.9兆円×(再配達率)約 2割×(宅配コスト率)3割(想定)＝1100億

円/年

➢ クール便、直接渡しなど、宅配ボックスが利用できない場合には必須

ステークホルダと価値創出

➢ サービス事業者：

宅配事業者または IT 事業者（アルゴリズム開発、機械学習等は IT 事業者等）

➢ データプラットフォーム提供者：

IT 事業者、ハウスメーカ、機器メーカ等

➢ 価値創出：

✓ 宅配事業者は、配達コストの低減メリットが得られ、その対価をデータ

プラットフォーマおよびサービス事業者に支払う。

✓ 宅配受取客は、宅配料金の低減および荷物をより早く受け取れる対価と

して、データを提供する。

在宅確率データ

データカタログ

活用

共通実装

最適な宅配ルートの出力

76

本事業では、以上のような形式で、12 件の具体的なサービス活用例を検討した。

(6) データカタログとデータ連携 APIの関係

データカタログの位置づけを示すため、データカタログとデータ連携 API の関係を整理する。

論点に示すとおりスマートホーム分野のデータ連携によるサービス創出は変化の速い分野であ

り競争領域と炉ら得ることができる。一方で、データの形式や概念の整理がばらばらであっては、

ベンダー横断でのデータ連携が進まないという課題がある。したがって、本事業においては、デ

ータ連携のための共通ルールとして、データカタログを整理する部分を協調領域と捉え、それに

基づき具体的にデータ連携 API やシステム実装を行う部分を競争領域と捉えて下図のとおり整

理した。

図 3-6 データカタログとデータ連携 API の関係

3.1.4. 検討成果の位置づけと意義

本事業の検討成果の位置付けと意義をまとめる。

スマートホーム分野においては、対話型 UI プラットフォーム、サービスプラットフォームな

ど海外の既存プラットフォームは登場している。すでに民間ベースで提供されるプラットフォー

ムに対して、不足しているサービス事業者よりの高次レベルデータの提供を多数のベンダーが協

調して取組むべき協調領域と捉えて、既存のプラットフォームと連携することで、サービス事業

者とユーザをつなぐバリューチェーンの重要な領域を占めるサービスフレームワークを構築する

ことを本事業の意義と捉えている。

今後、多様なサービス事業者、プロシューマによる新しいサービス創出エコシステムにおいて

は、高次レベルのサービス基盤が、新たなサービス創出のエネイブラー（実現技術）として重要

①サービス指向データモデル（基礎レベル） ②サービス指向データモデル（高次レベル）

データ連携ＡＰＩ、プラットフォーム（業界・ベンダー標準）

データの説明が必要な項目（メタデータスキーマ）

データの説明（データカタログ）

ＳＷＧのスコープ

・・・

協調領域

競争領域

部分的に実証

※APIは競争領域としてベンダーに委ねる

データの説明が必要な項目（メタデータスキーマ）

データの説明（データカタログ）

共通ルール

共通ルールに従った実装

77

になると考えられる。

図 3-7 スマートホーム分野のエコシステムにおける本事業の位置づけ

データカタログは、データを利用してサービスを開発するサービス事業者に対して、データを

見つけ、利用する際に必要となる情報（データの分類、形式等）を提供するものである。下図の

とおり、データ利用者とデータ提供者の真中に位置し、サービス事業者が、データ提供者に対し

て、必要なデータをリクエストするために用いることで、データの提供を促すためにも利用する

ことができる。以上より、データカタログは、データの提供者とデータの利用者の間で、有用な

データのインタフェース（共通ルール）を調整するための基盤と捉えることができる。

図 3-8 データカタログの用途と意義

ユーザ（Consumer）

サービス

高次レベルサービス

基礎レベルサービス

対話型UI

プラットフォーム

サービス連携プラットフォーム(Platform)

スマート家電

サービス提供者（Producer）

機器提供者

スマート家電

サービス事業者（Producer）

ユーザ（Consumer）

利用 提供

連携

連携 連携

連携

提供

本事業の重点領域

機器提供者

海外プレイヤ（既存勢力）

プロシューマプロシューマ拡大

利用 提供

サービス創出の注目領域

ECHONETLite

サービス事業者（データ利用者）

データ提供者データカタログデータベース

室温状況空気状況宅内照度電力使用状況・・・

検索

データ提供者

データ提供者

サービス事業者（データ利用者）

サービス事業者（データ利用者）

データ分類のリクエスト

カタログ形式の登録

ニーズ把握

・・・ ・・・

基礎レベルのデータの組み合わせにより高次レベルのデータ※生成

※ 高次レベルのデータ例在宅予測、食生活予測、生活異常検出、安否確認等の見守り、機器メンテナンス、…

78

3.1.5. 関連調査

スマートホームの既存プレイイヤーの動向と本事業の関係性について整理する。

3.1.5.1. ECHONET Liteとネットワークレイヤー

ECHONET Lite の仕様書と国際的なネットワーク階層モデル OSI 参照モデルとの関係を整理

する。ECHONET Lite 仕様書では、下図のとおりアプリケーション通信インタフェース仕様書、

ECHONET Lite 機器オブジェクト詳細規定、ECHONET Lite 規格書は、OSI 参照モデルにおけ

るレイヤーL5 から L7 に対応する。また、その下位層は、Ethenet, WiFi, Bluetooth, WiSUN な

どの既存プロトコルを利用することでネットワークを構成する。

（出所：ECHONET Lite, www.infraexpert.com を元に作成）

図 3-9 ECHONET Lite の標準仕様と OSI 参照モデルのネットワークレイヤーの関係

OSI参照モデルのネットワークレイヤー概要ECONETLiteのネットワークレイヤー

79

3.1.6. 今後の課題

本検討においては、データカタログに関する枠組みとデータの基本構造を整理し、実証事業者

により具体的なデータの検討を行った。本検討の結果整理された今後の課題をまとめると以下の

ようになる。

項目 内容

データカタログにおける属性・概

念の具体化

具体的なデータの増加に応じて、共通する概念(位置、時間、

温度など)の分類・整理を行い、業界横断的な言葉の共通化

を図る。

データカタログのメンテナンス方

法

データカタログは継続的に進化し続けるものであるため、

誰がどのようにメンテナンスを行うか検討する。

データの信頼性等、評価情報の組

込み

データの評価情報(第三者評価等)を「どのような評価軸」と

し、「どのように伝達する」かについて検討する。

国際標準の動向把握とデータカタ

ログの関係性考慮

IEC、ISO/IEC JTC1、ITU-T 等の国際標準の動向を把握し

つつ、具体化の検討を進める。

参照できる既存データの整理 ECHONET Lite, Continua など既存規格のデータを参照す

るための方法を整理する。

サービス分野を具体化した社会実

証

スマートホームからスマートライフへと拡張し、有望なサ

ービス分野を複数特定し、データカタログを活用した社会

実証を推進する。

3.2. セキュリティ・製品安全

3.2.1. 目的

スマートホーム分野において企業による新サービスの創出を促進する上でセキュリティを確保す

ることは不可欠となっている。本検討では、スマートホームにおいて求められる製品安全・セキ

ュリティ対策の主な項目について整理する。

80

3.2.2. 論点

当初の論点および WG、事業環境構築検討会を通じて挙げられた論点は以下のとおりである。

表 3-2 セキュリティ・製品安全に関する論点

区分 論点内容

当初からの論点

機器サービス接続に当たり各主体が接続先に求めるセキュリティ上の認

証基準の整理（セキュリティ）

ネットワーク機器のモニタリング・ログ管理の在り方（メリデメ含む）

の整理（セキュリティ）

遠隔操作を始めとする製品安全に係る現状ルールの明確化（製品安全）

ＷＧ・事業環境

構築検討会を通

じて挙げられた

論点

「モノ」の制御を含むスマートホームにおいては、セキュリティとセー

フティの両面に渡るリスクへの対策が重要ではないか。

システム全体のセキュリティレベルは、最も弱い箇所で決まるため、一

部の対策強化ではなく、全体のバランスを考慮した対策が重要ではない

か。

サービス事業者（ハウスメーカ）、プラットフォーマ（システムインテグ

レータ）、機器メーカ等の立場により求められる役割や対策は異なるた

め、立場に応じた対策指針が重要ではないか。

脆弱性アップデート確認、注意喚起などアフターケアの観点を含めて、

誰がどこでログを取るのかモニタリングの在り方の整理が必要

3.2.3. 検討結果

本事業においては、CSA, OWASP, ENISA など既存の IoT セキュリティガイドラインを参考

に、スマートホーム分野のセキュリティ対策指針の一次案を作成し、実証事業を通じて事業者の

現場における検討から対策指針一次案に対する改訂案を受付け、それらを反映することによりス

マートホーム分野の対策指針（チェックリスト）をまとめた。

対策指針の検討における基本的な考え方は以下のとおりである。

表 3-3 スマートホーム分野のセキュリティ・製品安全対策指針の検討の基本方針

スマートホームにおけるライフサイクル全体に渡りフェーズごとに実施すべき項目を整理

する。

エコシステムにおける役割に応じて求められる対策指針（チェックリスト）を提示する。

妥当なセキュリティ対策について消費者を含むステークホルダで合意することで、説明責

任を果たす。

81

消費者へのリスクの周知、事業者等のステークホルダ間の責任範囲を考慮した対策とする。

実証事業を通じて、スマートホーム分野の事業者の意見を踏まえて検討した結果、対策指針を

以下のとおり策定した。以下に示す対策指針（チェックリスト）は、平成 30 年度実証事業に参加

する事業者に対するセキュリティ実証の要件とすることを合意した。

82

表 3-4 スマートホーム分野のセキュリティ・製品安全対策指針（チェックリスト）全体構成

対策区分(第1階層)対策指針・留意点(第2階層)

サービス事業者(ハウスメーカ) プラットフォーマ(システム・インテグレータ) 機器メーカ

1. 基本方針の策定

① 経営層によるコミット（必要なリソースの割

当等）(任意/必須)② PDCAサイクルによる改善の仕組みを導入す

る（必須/任意）

① 経営層によるコミット（必要なリソースの割当等) (任意)

② PDCAサイクルによる改善の仕組みを導入(必須)

① 経営層によるコミット（必要なリソースの割当等) (任意)

② PDCAサイクルによる改善の仕組みを導入(必須)

2. リスクの評価

① リスク評価に基づく対策レベルの特定(必須)

② 発注先の選定基準（必須）③ ベンダーの対策の確認方法の検討（必須）④ 発注先との事故の責任範囲の取り決め（必

須）

① 守る対象の特定、アーキテクチャに元にリスクとその影響を考慮(内部不正やミスの発生を考慮）(必須)

② プライバシー情報漏洩のリスクと影響分析の実施(必須)

① ①守る対象の特定、つながることによるリスク、アーキテクチャ、物理的なリスクとその影響を考慮する(内部不正やミスの発生を考慮する))(必須)

② プライバシー情報漏洩のリスクと影響分析の実施）(必須)

3. 設計時の対策① 設計時の発注先の管理・対策状況の確認

（必須）

① セキュリティ、セーフティ、プライバシーの影響を考慮した設計(Security, Safety, Privacy by Design：SSPbD) (必須)

② 遠隔操作における製品安全に係わる問題の考慮（必

須）③ 安全安心を実現する設計の検証の実施(必須)

④ 多層防御（多重のセキュリティ対策の考慮）(必須)⑤ ログ・監視機能の導入(必須)⑥ 主要IoTセキュリティガイドラインの考慮(CSA,

OWASP等）(任意)

① つながる相手のリスクを回避する設計（必須）② つながる相手に損害を与えない設計（任意）③ セキュリティとセーフティの相互影響を考慮した設

計(Security, Safety, Privacy by Design：SSPD)

（必須）④ 遠隔操作により安全性に係わる問題の考慮（必須）

⑤ 安全安心を実現する設計の検証の実施（必須）⑥ 認証機能、暗号化の導入必要性の検討（CRYPTREC

等）（必須）⑦ ログ・監視機能の導入（任意）

4. 実装時の対策① 実装時の発注先の管理・対策状況の確認

（必須）

① 設計を満たす実装であることのテストの実施(必須)② 構築（インテグレーション）時の設定等の検証（必

須）③ 機器の状態把握、記録機能の実現（任意）

① 設計を満たす実装であることのテストの実施(必須)② 機器の状態把握、記録機能の実現（必須）

5. 保守・廃棄の対策① 消費者へのリスクの周知（必須）

② サービス追加・連携における検証と利用者同意の実施（必須）

① モニタリングと異常検知の実施(必須) ② サービス追加・連携における検証(任意)

① 機器設置後の不具合（脆弱性）の確認とアップデートの通知および実施(必須)

② モニタリングと異常検知の実施（任意）③ 消費者に機器の同意事項の周知(必須)

ライフサイクル・プロセス

エコシステムにおけるプレイヤー分類

83

対策指針は、サービス事業者（ハウスメーカ）、プラットフォーマ（システムインテグレータ）、

機器メーカ等の役割に応じて規定している。役割ごとの対策指針項目とその説明を以下にまとめ

る。

表 3-5 セキュリティ・製品安全対策指針（チェックリスト）（サービス事業者）

対策区分 サービス事業者（ハウスメーカ）

対策指針 説明・対策例

1. 基本方針

の策定

①経営層によるコミッ

ト（必要なリソースの

割当等）（任意）

役員（経営層）の責任の下で、組織としてセキュリ

ティポリシーを策定し、社内に周知、セキュリティ

対策の人員と予算等リソースを割り当てる。

②PDCA サイクルによ

る改善の仕組みを導入

する（必須）

策定したセキュリティポリシー、体制、対策計画等

に対して、PDCA サイクルに基づき改訂する仕組み

を導入する。

2. リスク評

価

①リスク評価に基づく

対策レベルの特定(必

須)

スマートホームにおいて想定されるリスクを洗い出

し、被害の大きさと発生可能性について評価する。

被害には企業ブランドの失墜などレピュテーション

リスクも含む。

②発注先の選定基準

（必須）

リスク評価の結果に基づき、システムインテグレー

タ、機器メーカ等の発注先を選定する際の基準、要

件などを検討する。

③ベンダーの対策の確

認方法（必須）

ベンダーに対する対策要件が満たされていることを

確認する方法を明確化する。ISMS 等の認証取得、

ツールによる検査結果の提示、第三者テスト機関の

利用などがある。

④発注先との事故の責

任範囲の取り決め（必

須）

セキュリティ事故が発生した場合の責任範囲、損害

賠償に関する取り決めを行う。

3. 設計時の

対策

①発注先の管理・対策

状況の確認（必須）

ホームネットワーク、機器の設計をアウトソースす

る場合、発注先の管理・対策状況の確認事項を明確

化し、確認を実施する。設計時の確認事項は IoT 推

進コンソーシアム「IoT セキュリティガイドライ

ン」等が参考になる。

4. 実装・構

築時の対策

①発注先の管理・対策

状況の確認（必須）

実装・構築の発注先に対して、実装・構築段階の確

認を行う。実装・構築時の確認には、ネットワーク

の接続テスト、ファジングツールによる検査、初期

設定の検査などが含まれる。

84

対策区分 サービス事業者（ハウスメーカ）

対策指針 説明・対策例

5. 運用・保

守・廃棄の

対策

①消費者へのリスクの

周知（必須）

消費者（住人）に対して機器取扱い注意事項やリス

クに関する説明書を用いた説明を行う。

②サービス追加・連携

における検証と利用者

同意の実施（必須）

スマートホームに新たな機器等を追加・接続する場

合に動作検証および利用者の同意取得を行う。

表 3-6 セキュリティ・製品安全対策指針（チェックリスト）（プラットフォーマ）

対策区分 プラットフォーマ（システムインテグレータ）

対策指針 説明・対策例

1. 基本方針

の策定

①経営層によるコミット

（必要なリソースの割当

等）（任意）

役員（経営層）の責任の下で、組織としてセキュ

リティポリシーの策定し、社内に周知、セキュリ

ティ対策の人員と予算等リソースを割り当てる。

②PDCA サイクルによる

改善の仕組みを導入する

（必須）

策定したセキュリティポリシー、体制、対策計画

等に対して、PDCA サイクルに基づき改訂する仕

組みを導入する。

2. リスク評

価

①守るべきものの特定、

アーキテクチャを元に、

リスクとその範囲を考慮

する(内部不正やミスの

発生を考慮する）(必須)

スマートホームにつながる機器において、ユーザ

情報、決済機能の保護情報（パスワード等）、コ

ンテンツ、異常動作による安全性のリスクなど守

るべきものを洗い出し、被害規模と発生可能性に

ついて評価する。

②プライバシー情報漏洩

のリスクと影響分析の実

施(必須)

プライバシー情報が漏洩した場合のリスクと影響

分析を行う。リスクには、ハウスメーカ等、機器

メーカ等の企業ブランドの毀損なども含む。

3. 設計時の

対策

①セキュリティ、セーフ

ティ、プライバシーの影

響を考慮した設計

(Security, Safety,

Privacy by Design：

SSPbD) (必須)

ネットワークや機器の設計において、セキュリテ

ィ、セーフティ、プライバシーの各リスクに対し

て防御策がとられているか確認する。

②遠隔操作における製品

安全に係わる問題の考慮

（必須）

電安法技術基準の解釈改正（遠隔操作に伴うリス

クに対する 7 項目の追加条件）が実施されている

か確認する。

③安全安心を実現する設

計の検証の実施(必須)

技術的な安全対策と利用者にとっての安心感を確

保するための設計が行われているか確認する。

85

対策区分 プラットフォーマ（システムインテグレータ）

対策指針 説明・対策例

④多層防御（多重のセキ

ュリティ対策の考慮）

(必須)

洗い出したリスクに対して、多重の防御策を必要

とするか検討し、必要性に応じて多重防御を行

う。

⑤ログ・監視機能の導入

(必須)

ネットワーク、機器の異常や不正アクセスをお検

知するためのログ・監視機能の必要性を検討し、

設計に組み込む。

⑥主要 IoT セキュリティ

ガイドラインの考慮

(CSA, OWASP 等）(任

意)

CSA Security Guidance for Early Adopters of the

Internet of Things、OWASP Top Ten Project な

どの IoT セキュリティガイドラインのうち必要な

項目について対策を行う。

4. 実装・構

築時の対策

①設計を満たす実装であ

ることのテストの実施

(必須)

設計時に検討したセキュリティ、セーフティ、プ

ライバシーのリスク防御策に対して、実装時に実

現されていることをテストする。

②構築（インテグレーシ

ョン）時の設定等の検証

（必須）

ネットワークや機器のアクセス権限、パスワード

設定等が適切なレベルで実施されているか確認す

る。

③機器の状態把握、記録

機能の実現（任意）

インテグレートした機器の状態把握、記録機能を

実現する。

5. 運用・保

守・廃棄の

対策

①モニタリングと異常検

知の実施(必須)

ネットワーク、機器のログ・監視機能を動作さ

せ、運用する。

②サービス追加・連携に

おける検証(任意)

ハウスメーカの依頼に応じて、サービス追加・連

携における検証を行う。また、サービス終了時の

データの適切な廃棄等を実施する。

表 3-7 セキュリティ・製品安全対策指針（チェックリスト）（機器メーカ）

対策区分 機器メーカ

対策指針 説明・対策例

1. 基本方針

の策定

①経営層によるコミット

（必要なリソースの割当

等）（任意）

役員（経営層）の責任の下で、組織としてセキュ

リティポリシーの策定し、社内に周知、セキュリ

ティ対策の人員と予算等リソースを割り当てる。

②PDCA サイクルによる

改善の仕組みを導入する

（必須）

策定したセキュリティポリシー、体制、対策計画

等に対して、PDCA サイクルに基づき改訂する仕

組みを導入する。

86

対策区分 機器メーカ

対策指針 説明・対策例

2. リスク評

価

①守るべきものの特定、

つながることによるリス

ク、アーキテクチャ、物

理的なリスクとその範囲

を考慮する(内部不正や

ミスの発生を考慮する）

(必須)

スマートホームにつながる機器において、ユーザ

情報、決済機能の保護情報（パスワード等）、コ

ンテンツ、異常動作による安全性のリスクなど守

るべきものを洗い出し、被害規模と発生可能性に

ついて評価する。

②プライバシー情報漏洩

のリスクと影響分析の実

施）(必須)

プライバシー情報が漏洩した場合のリスクと影響

分析を行う。リスクには、ハウスメーカ等、機器

メーカ等の企業ブランドの毀損なども含む。

3. 設計時の

対策

①つながる相手のリスク

を回避する設計（必須）

アクセス制御、つながる相手のデータを利用する

際のリスクを考慮して、リスクを回避する設計を

行う。

②つながる相手に損害を

与えない設計（任意）

機器の異常が発生した場合に、つながる相手への

送信データの停止や自身の停止など影響が波及す

ることを防止する設計を行う。

③セキュリティとセーフ

ティの相互影響を考慮し

た設計(Security, Safety,

Privacy by Design：

SSPD) （必須）

ネットワークや機器の設計において、セキュリテ

ィ、セーフティ、プライバシーの各リスクに対し

て防御策がとられているか確認する。製品出荷後

に発見された脆弱性をネットワークを介してアッ

プデートする機能の必要性を検討し、設計に組み

込むことも含む。

④遠隔操作により安全性

に係わる問題の考慮（必

須）

電安法技術基準の解釈改正（遠隔操作に伴うリス

クに対する 7 項目の追加条件）が実施されている

か確認する。

⑤安全安心を実現する設

計の検証の実施（必須）

技術的な安全対策と利用者にとっての安心感を確

保するための設計が行われているか確認する。

⑥認証機能、暗号化の導

入必要性の検討

（CRYPTREC 等）（必

須）

機器へのログイン、データ送受信に係わる機能に

ついて、アクセス制限、データ暗号化が必要な箇

所を特定し、設計に組み込む。標準的な暗号化機

能の一覧は www.cryptrec.go.jp が参考となる。

⑦ログ・監視機能の導入

（任意）

ネットワーク、機器の異常や不正アクセスをお検

知するためのログ・監視機能の必要性を検討し、

設計に組み込む。

87

対策区分 機器メーカ

対策指針 説明・対策例

4. 実装・構

築時の対策

①設計を満たす実装であ

ることのテストの実施

(必須)

設計時に検討したセキュリティ、セーフティ、プ

ライバシーのリスク防御策に対して、実装時に実

現されていることをテストする。

②機器の状態把握、記録

機能の実現（必須）

インテグレートした機器の状態把握、記録機能を

実現する。

5. 運用・保

守・廃棄の

対策

①機器設置後の不具合

（脆弱性）の確認とアッ

プデートの実施(必須)

機器の不具合（セキュリティ脆弱性）について

IPA 等の関係機関を通じて監視し、 出荷後に脆

弱性が発見された場合は、ネットワークアップデ

ートを実施する。脆弱性対策については、IPA 脆

弱性対応ガイドラインが参考となる。

②モニタリングと異常検

知の実施（任意）

ネットワーク、機器のログ・監視機能を動作さ

せ、運用する。

③消費者に機器の同意事

項の周知(必須)

機器利用におけるリスクを消費者に周知し、利用

許諾などの同意をとる。

3.2.4. 主な検討ポイント

策定したセキュリティ・製品安全対策指針（チェックリスト）について、主な検討ポイントは

以下のとおりである。

表 3-8 対策指針に関する主な検討ポイント

検討事項 ステークホルダ 意見等

経営層による

コミット サービス事業者

役員の責任のもと体制と予算を確保等は、必須とし

ても良いが、体制や予算配分などは程度により明記す

ることが難しい場合がある。

発注先の選定

基準 サービス事業者

ベンチャー企業による新技術の導入を阻害しない程

度であることが好ましい。任意が妥当。

責任分界点に

関する対応

サービス事業者、

プラットフォー

マ、

機器メーカ

ホーム GW、デバイスなどについて、ステーク

ホルダの責任範囲の取り決めが必要

住人の操作によるリスクの周知と免責事項の

説明が必要

セキュリティ事故発生時の賠償範囲、紛争解決

の取り決め等の参考例が有用。

88

検討事項 ステークホルダ 意見等

電安法：遠隔操

作に係わる安

全対策

機器メーカ、

プラットフォー

マ

機器レベルで電気用品安全法に基づき適性に

設計を実装可能

クラウド基盤構築において製品安全が担保さ

れた IoT 機器の接続を前提としているため、制

御の完了確認を主とする。

認証方式の考

え方

プラットフォー

マ、

機器メーカ、

サービス事業者

データアップロード、ＡＰＩ連携等においては

多重認証が必要。

サーバーとクライアント間にSSLやVPC等を

想定する。

CRYPTREC を参考とした認証対策が可能。

モニタリング

の在り方

プラットフォー

マ、

機器メーカ、

サービス事業者

宅内ネットワークや機器の異常や不正アクセ

スを検知する機能が有効

データアップロード、ＡＰＩ等のアクセスにつ

いて各種ログの取得と監視が有効

リスク低減のためクラウド主体のシステムと

し、クラウドシステム側においてログを収集す

ることを想定される。

3.2.5. リスクベースアプローチ

セキュリティ対策においては、対象環境を最もよく理解した事業者（当事者）自らが、リスク

評価（影響と原因）を行い、必要な対策を示すことで説明責任を果たすという考え方が重要であ

る。このようなリスクベースアプローチにより、意味のある対策を実施すると共に、過剰な対策

を回避する。平成 30 年度の実証事業においいては、リスクベースアプローチの実証を行うことが

重要である。

リスクベースアプローチによるセキュリティ対策の流れは以下のとおりである。

89

（出所：三菱総合研究所、参考：CSMS, ISMS リスクアセスメント）

図 3-10 リスクベースアプローチに基づくセキュリティ対策の流れ

来年度はこの手順に基づきセキュリティ・製品安全の実証事業を実施することを予定する。

3.2.6. 製品安全

本事業においては、電安法技術基準の解釈改正（遠隔操作に伴うリスクに対する 7 項目の追加

条件）に対して、実証コンソの意見に基づき、ソフト側とハード側それぞれが担保すべき領域や

境界について整理し、問題ないものであるかを検討した。対策チェックリストの 3. 設計時の対策

「遠隔操作における製品安全に係わる問題の考慮」を具体化した項目として実証を行った。

製品安全における遠隔操作に係わる基準としては、国から以下の解釈が提示されている。

(1) 守るべき資産の特定セキュリティ、セーフティの侵害により被害を生じる可能性のある対象を洗い出す。情報資産、IoT機器、サービス、無形資産等

(2) 脅威、脆弱性の洗い出しと分析意図的、非意図的な脅威、システムやサービスの脆弱性とそれらの影響関係について分析する。

(3) リスクの影響規模、可能性の評価守るべき対象の価値、脅威、脆弱性の関係性から、セキュリティ、セーフティの侵害により生じる影響規模と発生可能性を評価する。

(4) リスクに応じた対策の検討リスクに応じた対策を検討する。影響規模、発生可能性に応じて、リスクの低減、回避、受容、移転の判定を行い、具体的な対策法に基づき対策を決定する。

90

本実証においては、これらについて検討を行い対策指針（チェックリスト）への反映を行った。

主な意見・議論は以下のとおりであった。

91

表 3-9 遠隔操作に係わる７つの追加条件に対する意見・検討結果

ステーク

ホルダ 項目 意見等

プラット

フォーマ

③不意な動

作の抑制対策

を講じること

制御命令実行中に別の命令を行う場合に発生しうる。

対応としては、以下の 2 とおり：

【機器側】 遠隔操作時にリモコンでの操作を受け付

けない。また、その逆の場合も受け付けない

【クラウド側】 遠隔操作が完了していない機器の操

作を受け付けない。リモコン操作時に機器の操作を受

け付けない

遠隔操作対象の機器の動作状況を例えばカメラやセン

サなどで把握して利用者に知らせるなどの方法を認め

るなど、多様な方法を認めていただきたい。

⑦適切な誤

動作防止対策

が施されるこ

と

UI 側のつくりによる。→UI 側の対策が必要。

機器メー

カ 自主対応

機器メーカの APIを活用した第 3者のサービスに対しては、

その対応が電安法に基づく適正設計となっていることを認証

（証明）する方法が現時点ではなく、自主的な対応として実装

3.2.7. 今後の課題

本検討においては、スマートホーム分野におけるセキュリティ・製品安全対策指針（チェック

リスト）の検討を行った。ハウスメーカ、ホームシステムインテグレータ、家電メーカ等のスマ

ートホームに係わる主要なステークホルダによる実証事業を通じた検討の結果を反映し、現場の

実態を考慮した対策指針を策定した。

本検討の結果整理された今後の課題をまとめると以下のようになる。

92

表 3-10 セキュリティ・製品安全に関する来年度実証事業における課題

項目 内容

リスク評価に基づくセキ

ュリティ対策（リスクベー

スアプローチ）の考え方の

実証

対象環境を最もよく理解した事業者（当事者）自らが、リスク

評価（影響と原因）を行い、必要な対策を示すことで説明責任を

果たすという考え方を実証する。過剰な対策を回避する意味を含

む。

サプライチェーンを考慮

したセキュリティ対策の

実証

消費者に対するリスクの周知や免責事項、事業者ごとの製品

安全・セキュリティに関する役割に応じてサプライチェーンを考

慮したセキュリティ対策指針に基づく実証を行う。

モニタリングの在り方の

検討

プライバシー、アフターケア、住人の安心確保の観点で、

誰が、どこでどうログを取るか整理が必要

脆弱性アップデートの確認・注意喚起も含めて、住人に

対して選択肢としてセキュリティサービスの提供の在り

方を検討

スマートホームからスマ

ートライフへの拡大に向

けた要件の検討

スマートホームから、街、職場、社会インフラなどに広がるス

マートライフ分野に対応した製品安全・セキュリティ対策指針が

満たすべき要件

(コンシューマ向け機器からインフラ事業者を含むステークホ

ルダへの拡大対応)

3.3. プライバシーデータの活用／サービスの創出

プライバシー・データ活用／サービス創出 SWG を設置し、以下の 3 つの論点を設定・検討し

た。

（1）データ主体への説明および同意取得

（2）オプトアウト

（3）海外での事業展開における留意点

以下、それぞれの論点に関する実証・検討結果を記載する。

93

3.3.1. データ主体への説明および同意取得

(1) 論点の概要

スマートホームを含む IoT サービスの特徴として、多くの事業者が関与して、さまざまなデバ

イスやセンサ等から各種のデータを取得し、多様なサービスを提供することが挙げられる。すな

わち、データを取得する事業者、取得されるデータ、データを取得するデバイス、データ取得の

タイミング、データ取得の目的（データが何に使われるか）が複雑になりやすいという特徴を持

っている。そのため、SWG では、データ主体への説明および同意取得の方法・あり方について、

そうした複雑な内容をどのように伝えることが適切か、という点が論点の一つとして挙げられた。

(2) 検討方法

まず各実証事業の開始前に、モニタ等の参加者への説明および同意取得に用いる文書について

事前検討を行い、留意すべき点等について整理した。

また実証終了後には参加者を対象にアンケート調査を行って、説明の理解度や、説明側の意図

と参加者の理解のギャップに関する分析を行った。

検討の順序およびスケジュールは以下のとおりである。

表 3-11 検討スケジュール

時期 実施内容

2017 年 7 月～8 月 実証事業ごとに同意書・説明書の事前検討

2017 年 8 月 同意書・説明書の確定

2017 年 8 月～2018 年 1 月 実証事業実施

2018 年 1 月～2 月 各実証事業の参加者向けアンケート調査

2018 年 2 月 アンケート調査結果もふまえた分析・検討

(3) 検討結果１：同意書の事前検討

実証実験に関する同意書/利用規約について事前に確認を行った。

本実証事業においては、文章での説明を正確にするとともに、有識者からのコメントもふまえ、

図・イラストを記載し、利用者（モニタ）が理解しやすくなるように留意した。

文章での説明のポイント

同意書については、「HEMS データ利用サービス市場におけるデータ取扱マニュアル［第 1.0

版］」1における同意書ひな形に基づき、個人情報の取扱方針を記載した文書を作成した。なお、最

1 http://www.meti.go.jp/committee/kenkyukai/shoujo/smart_house/pdf/009_s14_00.pdf（2018 年 3 月 16 日アクセス）

94

終的な同意書の形式は、実証事業者により、ひな形を踏襲する形と、ひな形の項目をふまえた独

自様式とに分かれた。

SWG では有識者委員より、以下のような指摘があったため（以下は複数の委員の意見をまと

めたもの）、それらをふまえて修正を行い、確定版とした。

文書だけでは理解が難しい。スマートホームでは、どの情報がいつ取得され、個人情報として

扱われるのか、誰が利用するのか、どのような形態（委託、第三者提供、共同利用、等）で利

用するのか、が複雑になりやすいため、イラストや図を用いて「どこでデータが取られて、誰

にどのように扱われるか」が一覧でわかるような資料も必要である。

図・イラストによる説明

前項に記載した有識者の意見をふまえ、各実証事業者の同意書において、利用規約に加え、図・

イラストによる説明資料も作成・配布した。

図 3-11 積水ハウス実証事業の利用規約における説明図

95

図 3-12 大和ハウス実証事業の利用規約における説明図

(4) 検討結果２：アンケート調査による評価

モニタに対しては、各実証事業者が個人情報に関する点も含めて規約内容について実証開始前

に対面で説明済みであるが、その上で、実証実験終了時にアンケート回答への協力を依頼した。

アンケート結果のポイント

アンケート結果のポイントは以下のように整理される。

表 3-12 参加者アンケート結果のポイント

① 個人情報に関する規約はある程度

読まれていた。

半数以上は規約を事前に読んでいた。（モニタ契約書

に含まれていたことも理由として考えられる）

「ざっと読んだ」が半数以上と多いが、「詳しく読ん

だ」は少なかった。

個人情報に関する規約への関心度にはややバラツキ

もみられた。（新築への入居、既築既入居者の違い等

さまざまな理由が考えられる）

② 規約内容について基本的には理解

されていたが、図・イラストを使っ

た説明が望ましいとの意見が多か

った。

規約の内容は全体的には理解されており、説明図は効

果的だったと考えられる。他方、項目による差もみら

れた。（「個人情報を取得すること」と比べると他の項

目の理解度は相対的に低かった。）

説明内容について、ほとんどは「今の説明でよい」だ

ったが、「取得された個人情報を誰がどのように使う

かについて」については、「今よりも詳しい説明がよ

い」もやや多くみられた。

96

説明形式については、「文章のほかに、図やイラスト

の説明がある方がいい」が多かった。

説明方法について「説明員から直接説明を受けたい」

と「必要なときにその都度アプリ等で通知を受け取

り、説明を受けたい」が多く、次いで「動画を視聴す

ることで説明を受けたい」「書面で説明を読みたい」

だった。また、「モニタ実施前にすべての説明を読み

たい」は少なかった。

③ 自分の理解と実態とでイメージが

違ったかについては、ない・少ない

との回答が多かった。

今回は、あまり複雑な操作やデータ収集・処理が行わ

れていなかったことも念頭におく必要はある。（「わか

らない」もややあった）

「いつ、どのように個人情報が取得されるか」につい

ては、事前理解と経験に基づく印象との間のギャップ

もややみられた。

主なアンケート結果を以下に示す。

最初に、積水ハウス実証事業におけるモニタアンケートから、上記に関連する主な集計結果を

示す。

図 3-13 積水ハウス実証事業におけるモニタ向けアンケート結果（抜粋）(n=20)

97

次に、大和ハウス実証事業におけるモニタアンケートから、上記に関連する主な集計結果を示

す。

図 3-14 大和ハウス実証事業におけるモニタ向けアンケート結果（抜粋）(n=25)

アンケート結果のポイントをふまえた集約

上記の結果をふまえると、以下のように集約できる。

○ 図・イラストによる説明を行った効果もあり、規約内容は全体的には理解されていた

○ 説明の形式や詳しさは、基本的には今回と同程度でよいとの意見が多かった

○ 可能な限り負担の少ない形で規約内容を知りたいという回答が多い（アプリによる説明、説明員に

よる直接説明）

○ ただし、「取得された個人情報を誰がどのように使うかについて」は、現在よりも詳しいせつめいを

求めるとの回答もやや多くみられた

上記をふまえて、より望ましい説明・同意取得のあり方を検討することが重要である。具体的

には、図・イラストによる説明は前提とした上で、アプリなども効果的に活用して「取得された

98

個人情報を誰がどのように使うか」をより詳しく、かつ利用者の負担の少ない形で説明すること

が重要と考えられる。

(5) 検討結果３：SWG等での議論も踏まえた整理

説明方法や内容について、説明を行う側の事業者からも「どこまでを説明すればいいのか（ど

の範囲の事業者やサービスまでを説明すればよいのか）が悩ましい」という趣旨のコメントがあ

った2。

他方、有識者からは、「サービス内容と対応させて説明しないと本質的には理解できないのでは

ないか」「今回の実証は比較的理解が難しくないサービスが対象だったが、今後は複雑なサービス

も出てくるので、説明をいかに分かり易くできるかが重要である」という趣旨のコメントがあっ

た3。また、SWG でも「製品の取扱いマニュアルなどは、すでに紙ではなくアプリで提供され、

アプリを参照することも増えている」というコメントもあった。

なお、事前検討、アンケートによる評価、有識者等による議論、の結果をふまえた検討結果は、

次の「オプトアウト」の検討結果と合わせて次項で述べる。

3.3.2. オプトアウト

(1) 論点の概要

第一の論点にて記載したように、スマートホームを含む IoT サービスでは、サービス事業者や

取得されるデータ、取得に用いるデバイス・センサ、取得タイミング、取得目的（データが利用

されるサービス）などの対応関係が複雑なため、同意取得だけでなく、同意内容を撤回する際の

方法についても検討する必要があることが SWG において指摘された。

(2) 検討方法

各実証事業では、途中時点でサービスを停止または追加する状況を想定していなかったため、

スマートホームサービスにおけるオプトアウトのための要件については机上検討にて実施した。

(3) 検討結果

机上検討は、基本的には SWG での議論もふまえ、事前の説明の難しさ等から考えるとオプト

アウトの際にはどうあるべきかという観点から検討を行った。前節に記載したとおり、スマート

ホームでは、関係する事業者やデータ、デバイス、サービス等が多数あり、またその他方関係も

複雑なため事前説明が難しいが、オプトアウトの際にはそれが途中時点で一部変化することにな

るため、さらに説明が難しくなることが想定される。加えて、どのサービスやデータ取得に関す

る同意をオプトアウトするかは個々のユーザにより異なるため、説明書をその都度修正すること

も困難と考えられる。

2 本事業で設置した第３回事業環境構築検討会（2018 年 2 月 27 日）での発言。 3 同上。

99

オプトアウトに関する検討結果は、オプトアウトに関する記載も事前の説明文書・同意書に含

まれていることが必要であることから、同意書・説明書のあり方と合わせて整理した。結果を以

下に示す。

説明・同意・オプトアウト等に求められること

検討結果は以下のように整理できる。

○ 図･イラストを用いた説明は必須。とくに「いつ・どのように個人情報を取得するか」「取得された個人

情報を誰がどのように使うか」の詳しい説明。サービス理解と関連づけて説明することも重要。

○ 機器・機能・サービスの途中追加・途中終了がある場合には、アプリによる説明、同意、オプトアウト

が望ましい。ただし、アプリによる説明方法について、どのような方法・形式・内容・タイミングがよい

かについては、理解しやすさと法令順守の面から、実証に基づいてさらなる検討が必要。

また、SWG において有識者からは以下の点についても指摘があった。

○ 収集した個人情報等からセンシティブな情報を推知しないこと、一部サービスに同意しない場合で

も全体または基本のサービスは利用できること、子どもも含めた世帯全員の個人情報が取得されう

ること、を考慮した規約であること4。

説明・同意書の構成および説明形式（案）

以上をふまえて、説明書・同意書の構成および説明形式（案）（表 3-13）、及び個人情報の取扱

方針（ひな形（暫定版））（参考資料）を作成した。

前述の「HEMS データ利用サービス市場におけるデータ取扱マニュアル［第 1.0 版］」をベー

スに、上記の検討結果を盛り込んだもので、表中で赤文字の部分が新規に追加された部分である。

基本的な考え方としては、図・イラストでの説明は必須とし、また、とくに途中から追加され

る機器・機能・サービスに関し、わかりやすい説明、同意取得、オプトアウト手段提供を行うこ

とが望ましい。

表 3-13 説明・同意書の構成および説明形式（案）

説明項目 プラットフォーマ サービス事業者

１． 基本方針 コンプライアンスの宣言等、個人情報を取扱う上での基本方針を明示す

る。

２． 適用範囲 本プライバシーポリシーの効力が及ぶ範囲を明示する。サービス毎にポリ

シーが異なる場合は、サービス毎に作成する必要がある。

３． 個人情報の取得と

利用目的 ※ 図・イラストでも説明

（可能なら Web・アプリ

での説明・同意）

以下の 3 点を明記する必要がある。

収集する情報

収集方法（直接取得、間接取得を

含む）

利用目的（※第三者提供すること

を利用目的に含めることも可能）

以下の 3 点を明記する必要がある。

収集する情報

収集方法（直接取得、間接取得を

含む）

利用目的

なお、プラットフォーマからの第三

者提供以外で、サービス事業者が個

人情報を独自に収集している場合

4 「放送受信者等の個人情報保護に関するガイドライン（平成 29 年 4 月 27 日総務省告示第 159 号）」等を参照。

100

説明項目 プラットフォーマ サービス事業者

は、その旨を明記する必要がある。

４． 個人情報の管理 ※ 図・イラストでも説明

利用者から取得した情報について、どのような管理を行うかについて明記

する。（個人情報管理体制、委託先管理、保存期間など）

個人情報の管理については、具体的に記載することで、より利用者からの

信頼を得ることが可能である。そのため、個人情報管理体制、委託先管理、

保存期間などについても記載することが望ましい。

５． 第三者提供の有無 ※ 図・イラストでも説明

（可能なら Web・アプリ

での説明・同意）

第三者提供の有無について明記す

る。

第三者提供を行わない場合、今後

第三者提供を行う場合は利用者

から同意を得て実施することを

明記することが望ましい。

第三者提供を行う場合、同意が得

られた場合のみ第三者提供を行

うことを明記する。なお、第三者

提供する個人情報、提供先企業に

おける利用目的、が明記されてい

ることが望ましい。

利用目的の必要な範囲内において、

他の事業者へ個人情報を委託する

場合、委託することを明記する。

第三者提供の有無について明記す

る。

第三者提供を行う場合、同意が得

られた場合のみ第三者提供を行

うことを明記する。なお、第三者

提供する個人情報、提供先企業に

おける利用目的、が明記されてい

ることが望ましい。

６． 個人情報の開示・

訂正・利用停止等

利用者からの求めに応じ、保有個人データの開示・訂正・利用停止・それ

らの手続き等に関する事項を明記する。

とくに、オプトアウトの条件・方法についてはわかりやすく記載する。（可

能であれば Web やアプリによる説明と同意取得が望ましい。）

７． 問合せ先 苦情や問合せに対応する窓口について、連絡先を明記する。問合せ可能な

連絡先と連絡方法が明示されていることが望ましい。

８． 改訂 プライバシーポリシー等の個人情報に係る取扱い方針の改訂状況（策定

日、改訂日等）を明記する。

3.3.3. 海外での事業展開における留意点

(1) 論点の概要

今後、スマートホームに関するサービスを海外において提供する場合、あるいは訪日外国人に

対して提供する場合には、海外の法制度が関係する可能性があるため、海外（とくに欧州）の法

制度において留意すべき点について事前に把握・検討すべきとの指摘が SWG にてあった。

(2) 検討方法

現時点では海外や訪日外国人向けのサービス提供は具体的には想定されていないことから、文

献調査により実施した。

(3) 検討結果

対象として想定すべき法制度

スマートホームで取得したデータの取扱いについて、プライバシーの面からは、欧州であれば

101

一般データ保護規則（General Data Protection Regulation: GDPR）、米国であれば連邦取引委員

会法（Federal Trade Commission Act）などの個人情報保護法・プライバシー保護法が関係する。

実務的にはそれぞれの法律の規定に従って同意取得や情報公開、適切な利用、安全管理措置な

どを行うことになるが、その他に、取得したデータを当該国で保管、処理する義務や国外移転の

制限5などの規定があるか、といった点に注意すべきである。こうした規制は個人情報保護・プラ

イバシー保護法制度だけでなく、データローカリゼーション規制によって行われている場合もあ

る。また、プライバシーに関して国内と異なる規制（例、子どものプライバシー保護6）が行われ

ている場合にも留意が必要である。

サービス提供地域やサービス利用者の国籍7等が具体的に想定できる場合には、関係する法制度

の制定状況を把握した上で、サービス提供のシステム構成や各種ポリシー、サービス提供レベル

等の検討が必要になるため、必要に応じて今後検討すべきである。

留意すべき点

将来的に海外でサービスを提供する場合、あるいは海外からの来訪者等にサービスを提供する

場合には以下のような点についての留意・検討・対応が必要になると考えられる。

○ システム構成：特定国へのローカルサーバの設置、データ同期の可否、特定拠点での体制構築

（例：苦情処理、当局対応、・・・）、等

○ 各種ポリシー：データ取扱、セキュリティ、その他のポリシーを統一的に適用できない場合（当該国

の法制度による制約を受ける場合）の対策が必要

○ サービス提供レベル：上記の対策の結果、当該国でのサービス内容・レベル等を変更しなければ

ならない可能性が生じうる

○ 法令対応：GDPR等の規定に従う必要が生じうる

当面の対応

本実証で提供したサービスについては、日本に居住する個人/世帯に対して日本語でサービスを

提供しているものであり、GDPR 等の規制対象には該当しないと考えられる。ただし、海外での

事業展開、訪日外国人向けサービスの提供等、今後のサービス展開の進展によっては、より詳細

に検討する必要が出てくると考えられる。

5 GDPR では個人データの域外移転を制限している。なお、現行のデータ保護指令においても域外移転は制限されている。

6 GDPR では 16 歳以下の子供の個人データについては保護者の同意も必要とされる。他方米国では子供のオンラインプライバシー保護法（Children's Online Privacy Protection Act: COPPA）により、13 歳以下の子供の個人情報を取得する際には保護者の同意も必要とされている。COPPA ではその他にも規定があるが、国・地域により保護対象となる子供の年齢基準が異なるなどの点にも留意が必要である。なお日本では、

7 GDPR では、EU 居住者の個人データを取扱う場合、GDPR の適用対象となる。

102

3.3.4. 今後の課題

上記の検討結果および SWG での議論に基づき、それぞれの論点の実証結果および今後の課題

を整理すると以下のとおりである。

表 3-14 各論点に関する実証結果および今後の課題

論点 実証結果 今後の課題

① 同意書・

説明

図・イラストによる説明が効果的であ

ることがわかった。

同意を取得する際は、サービス理解に

基づいて同意できるようにすること

が重要。（サービスとの対応において、

個人情報がどのように使われるかの

理解に基づいて同意を得ることが重

要。）

サービス創出という視点からも、プラ

イバシーとサービス内容の理解を深

めるような説明方法が重要

サービス提供に関して多様なプレイ

ヤーがさまざまな役割を担うので、ど

の範囲までをどのように、いつ、説明

すべきか難しい場合もある。

図・イラストでの説明は必須。（例：図・

イラストをメインに、説明しきれない

点を文章で補足する等。）

アプリ・Web による説明。（理解しや

すい、常に最新状況を確認できる等の

メリットが期待。）

説明範囲・説明タイミング等について

の、実証に基づく検討。

サービス創出にもつながるような説

明方法の検討。

標準的規約・共通の説明フォーマット

の検討。（利用者の理解しやすさ・事業

者の負担削減が可能な方法について

検討。）

② オプトア

ウト

説明が複雑になってしまいやすいた

め、説明方法の工夫が必要。（※本実証

ではオプトアウトが生じるシーンが

なかったため、同意取得時の状況を踏

まえた机上検討）

現状からの変化、誰がどのように個人

情報・データを取得し、誰がどのよう

に使うかなど、アプリや Web による

説明が効果的ではないか。

複雑な状況を設定した実証に基づく、

説明へのニーズ、説明方法への評価、

理解状況、誤解が生じやすい点の分

析、などの実施。

利用者が理解しやすく、事業者の負担

が大きくならない方法（アプリ、Web

等）の検討。

③ 海外展開

における

留意点

GDPR、データローカリゼーションの

動向をふまえて、今後検討すべきと考

えられる課題を提示。

事業展開、利用者動向（訪日外国人向

けサービス、海外でのサービス提供

等）を見つつ、課題を検討。

3.4. リコール・リサイクル

ここまでの「データカタログ」、「セキュリティ・製品安全」、「プライバシーデータの活用／サ

ービスの創出」については、あらかじめ設定した論点に基づき、実証から得られた成果や課題等

の検討を SWG 等にて行ってきた。一方、リコール・リサイクルについては、他の項目と異なり、

実証自体が主要な検討テーマであり、実証内容や得られた結果について SWG 等にて検討を行っ

てきたところである。このため、ここではリコール・リサイクル実証結果を踏まえた成果と課題

に関する検討結果を整理することとした。

103

3.4.1. 実証結果を踏まえた成果と課題（主なもの）

(1) リサイクル手配（家電４品目のリサイクル)

実証結果

· 端末から廃棄のフローに従い操作するだけで廃棄の手配を行うことができ、便利さを感じ

てもらうことができた。とりわけ、転居前に家電を処分した経験と比較して、処分方法が

分かりやすいこと、集荷の日時を選べること、取りに来てもらえるので自分で運ばなくて

済むこと、にこのサービスのメリットを感じてもらうことができた。

· 廃棄フローの中で、正しいリサイクル方法や違法な不用品回収業者に関する注意喚起の情

報を出し、約半数の人に見てもらうことができた。

成果

· このようなサービスにより、家電 4 品目の廃棄方法を知らない人であっても、廃棄方法を

調べる手間をかけることなく、引き取る小売店の連絡先などを確認する手間もかけること

なく、正しい排出が可能となった。このようなサービスを広げることにより、適正なリサ

イクルが促進される可能性があることが分かった。

· このリサイクル手配サービスにより、廃棄のタイミングを捉えて廃棄に係る注意喚起情報

を効果的に発信することが可能となった。このようなサービスを広げることにより、適正

なリサイクルが促進される可能性があることが分かった。

課題

· 本実証において用意したシステムは「小売業者の引取義務外品」が対象であり、小売業者

に引取義務がある場合については対応していない。小売業者に義務がある 2 つの場合に対

応するためには、幅広い小売業者を巻き込んだ仕組みを考える必要がある。（スマートホ

ームが広がり、こうしたサービスを利用し得る者が増えれば、小売業者の参画が得やすく

なると考えられる。）

· 本サービスに協力してくれる小売業者を探して調整を行うのには、一定の時間を要した。

· 全国を１社でカバーできる小売業者は少ないため、全国でこのサービスを使用する場合、

引取りを行う小売業者を各地で探す必要がある。また、品目によっては全国を１社でカバ

ーできる小売業者もあるが、こうしたサービスに対応する体制を全国で構築するには一定

のコストがかかると考えられる。（スマートホームが広がり、こうしたサービスを利用し

得る者が増えれば、小売業者の参画が得やすくなると考えられ、また、コスト面での課題

も解消しやすくなると考えられる。）

· 消費者にリサイクル行動を促すには、経験を積んでもらうことが重要であり、そのために

如何にアプリの利用頻度を上げることができるかが重要である。（今回用意したサービス

に加えて、利便性が高い他のサービスも一体で提供していくことで、アプリ全体の利用頻

度が上昇すると考えられる。）

104

(2) リサイクル手配（小型家電のリサイクル)

実証結果

· 端末から廃棄のフローに従い操作するだけで廃棄の手配を行うことができ、便利さを感じ

てもらうことができた。（過去に小型家電を廃棄した経験があるモニタであって引越業者

による引き取り経験がある者には便利さを感じてもらうには至らなかったが、それ以外の

モニタには便利さを感じてもらうことができた。）

· 廃棄フローの中で、正しいリサイクル方法、違法な不用品回収業者に関する注意喚起、自

治体の回収方法の情報を出し、半数弱の人に見てもらうことができた。

成果

· 小型家電 28 品目の廃棄方法を知らない人であっても、廃棄方法を調べる手間をかけるこ

となく、回収拠点情報や認定事業者の連絡先などを確認する手間もかけることなく、正し

い排出が可能となった。このようなサービスを広げることにより、適正なリサイクルが促

進される可能性があることが分かった。

· このリサイクル手配サービスにより、廃棄のタイミングを捉えて廃棄に係る注意喚起情報

を効果的に発信することが可能となった。このようなサービスを広げることにより、適正

なリサイクルが促進される可能性があることが分かった。

· 家電リサイクル法と小型家電リサイクル法という異なる 2 つの制度に従う廃棄方法を、端

末から手配することができる 1 つのサービスとしてワンストップで提供できることは利

便性向上に繋がり、このようなサービスを広げることにより、適正なリサイクルが促進さ

れる可能性があることが分かった。

課題

· 全国を１社でカバーできる物流事業者等（認定事業者と連携している者）は少ないため、

全国でこのサービスを使用する場合、引取りを行う物流事業者等（認定事業者と連携して

いる者）を各地で探す必要がある。（スマートホームが広がり、こうしたサービスを利用し

得る者が増えれば、物流事業者等の参画が得やすくなると考えられる。）

· 自治体数が増えた場合には一覧表示することはユーザの負担感につながるため、自動的に

自治体の案内ページにリンクするような仕組みが必要である。（住所情報などにより自動

的に当該自治体の案内ページを表示させることが考えられる。）

(3) リコール手配

実証結果

· ハウスメーカ UI にリコールのお知らせが届くので、気付きやすく、また、その UI から

のリンクで回収手配でき、便利さを感じてもらうことができた。

· 機器メーカからも、製品の所有情報を入手できる製品登録サービスにはリコール対応の観

点から関心が示され、実際のリコール対応を行うには製造番号やロット番号など更に情報

が必要であることなど、様々な意見を頂くことができた。

105

成果

· 所有情報に基づいてリコールのお知らせと回収手配を行うリコール手配サービスは、リコ

ールの回収促進に繋がる可能性があることが分かった。

· 製品の所有情報を機器メーカに公開（ただし匿名化）することにより、リコール対応に役

立つ可能性があることが分かった。

課題

· メーカがリコールに対応するにはより多くの情報が必要であり、個別に様々な対応を行っ

ている。リコールの回収方法については、製品やメーカによって様々な対応があるため、

今回の実証で用意したフローはベーシックな例の一つであり、あらゆる場合に対応できる

ものではないことが明らかになった。汎用性を高める観点からは、今回作成したフローを

基礎としつつ、複数の回収方法についてフローを整理していく必要がある。

· 製品情報データベースがあると便利であるが、更なる改善が必要という意見を頂いた。

· 既に廃棄や譲渡を行ったという製品について、どのように対応するのかという指摘もあっ

た。（指摘を踏まえて、今回は、既に廃棄・譲渡を行っている場合にはその旨回答するフロ

ーとした。最低限の仕組みとして、こうした機能が必要であると考えられ、スマートホー

ムが広がった場合には、さらに高度な個品管理を促進する機能の検討が必要であると考え

られる。）

(4) リユース手配

実証結果

· 端末からリユースのフローに従い操作するだけで、リユースの手配を行うことができ、便

利さを感じてもらうことができた。

成果

· スマートホームのリユース手配サービスは、リユースが手間であるから、あるいはリユー

ス手配の方法が分からないから、まだ使える製品であっても廃棄するという人がリユース

を手配するようになり、リユース促進に繋がる可能性があることが分かった。

課題

· 製品の状況もワンストップで伝えることができるようにしたが、写真や文字で伝えること

に関しては限界があった。利用者の操作により製品が正常動作することを証明する情報を

入力してもらうことは困難であり、何らかの方法で自動化する方が効率的であることが明

らかになった。（スマートホーム機器の機能により、製品の状況（使用頻度や動作状況）に

関するデータを得ることなどが考えられる。）

※修理手配についても、リユース手配と概ね同様の結果・成果・課題が得られた。

106

（過去に修理手配経験があるモニタは、経験がないモニタよりも、より便利さを感じても

らえた。）

(5) 製品登録と各種サービス

実証結果

· 製品登録サービスにより、所有している家電が一覧表示されると、家電の管理が容易にな

ることを感じてもらうことができた。（とりわけ不使用家電のリユースへの活用に魅力を

感じてもらえ、また、保証書の一括管理にも興味が示された。）

· 電力センサによる分析を用いて、所有する家電の製品登録を促すことができた。（例えば

電子レンジを検出した場合、電子レンジの登録をお願いする通知画面を表示してモニタに

操作してもらうようにした。）

· 機器メーカからも、製品の所有情報を入手できる製品登録サービスには関心が示された

（再掲）。

成果

· 最初に登録さえ行われることができれば、所有している家電を把握しやすくなり、退蔵品

のリユース・リサイクルにつながる可能性があることが分かった。

· 電力センサの活用は、製品登録と、その先にある各種のサービスの展開に重要な役割を果

たすと考えられる。電力センサによる分析により、使用されていない家電を認識し、リユ

ース・リサイクルを促すことも可能ではないか。

課題

· 製品登録サービスの開発については、様々な課題があった。今後とも、製品登録サービス

事業者においては、開発に関する研究が必要と考えられる。

· 電力センサによる分析では、現在は品目までしか分からない。より簡便な方法が望ましく、

今後、メーカや型番の認識技術の検討が必要である。

· 家電４品目であるか否か、小型家電 28 品目であるか否かの判定を自動的に行うのが難し

い（特殊な製品について試行しところ、判定ミスが多少あった）。正確に自動判定し、リサ

イクル料金を自動表示する仕組みが必要である。実際にサービスを広く行う場合、この点

が問題となるため、製品登録サービス事業者による製品情報の整理が必要である。

· 本実証の直接的な検討対象外ではあったが、今回、製品登録のインセンティブとして実証

事業対象外のサービスである家電延長保証を訴求したものの、実際には製品登録はあまり

促進されず、個別にモニタに対して登録を促すこととなり、予想以上に製品登録へのハー

ドルが高かった。このため、製品登録自体の煩わしさを取り除く方法や、モニタに対する

製品登録インセンティブについて、更なる検討が必要であることが明らかになった。家電

は、利用者所有、賃貸住宅据付、リース・レンタル品等、様々な所有形態がある。こうし

た所有形態の違いにより製品登録方法や管理方法が異なることを意識した製品ライフサ

イクルサービスを考える必要がある。

107

3.4.2. まとめ

スマート製品ライフサイクルに関する実証から得られた結果と課題、今後の検討の方向性を図

3-15 のとおり整理した。

図 3-15 スマート製品ライフサイクルに関する実証のまとめ

リサイクルなどの対応を促進する仮説

スマートホームサービスとの連係

ワンストップで提供

ITサービスとして提供

実証から得られた結果

今回開発・実証したような、左記の３要素（※）を実現するサービスを普及させることにより、リサイクル、リユース、リコールなどが促進される可能性がある。※ただし、製品登録のハードルの高さという課題を考慮すると、ワンストップで提供することにはこだわらず、機器メーカー個社によるIot機器の登録を有効活用した展開も考えられる。

サービスの提供に当たっては、左記の３要素に加えて、リサイクル手配の注意喚起情報の表示など、今回の実証で実施した工夫を参考にすると、より効果的であると考えられる。

製品の所有情報はこれらのサービスを提供するために重要である。

その他、リサイクル、リコール、リユースといったそれぞれの分野ごとに課題も整理されたところであり、サービスを提供するに当たっては、こうした課題の解消や、今回の実証において課題に対する最低限の対応として講じた措置（リコール手配時の家電所有確認フローなど）を参考にした工夫が必要である。

課題

＜製品登録の促進＞製品登録の簡便化や、利用者のインセンティブ

＜使用頻度の向上＞アプリの使用頻度の向上、サービスの利用経験の向上

＜自動化の促進＞家電4品目・小型家電の判定、リサイクル料金の表示

＜対象の拡大＞全国規模への拡大、小売業者の義務品回収への対応

今後の検討の方向性

・電力センサ分析によるメーカ・型番識別技術、音声での誘導、TVとの連係によるビジュアルガイダンス 等・製品ライフサイクル以外のサービスを提供する多様な事業者との連携による付加価値向上

・メーカや各種事業者からの有益情報の提供による利用機会増加・他のアプリとまとめることによる利用機会増加

・メーカとの協力による最新製品情報・リサイクル料金表との連係

・スマートホームの普及による、サービス利用者（利用し得る者）の拡大・使用済家電4品目及び小型家電の収集運搬を行うより多くの関係者（小売業者、物流事業者等）が参画できる仕組みづくり。

108

第4章 スマートライフ関連市場の創出に向けて

4.1. スマートライフのイメージ

AI スピーカー等と称される音声デバイスの登場により、我が国においてもスマートホーム市場

がにわかに動き出している。現在、産業界の各方面で、家電やウェアラブル、センサ等で宅内等

から収集される環境情報やユーザの生活関連情報、すなわちライフデータを活用したビジネス提

案が活発化している状況である。

経済産業省では、これらの情報が、ユーザ・消費者のニーズを踏まえた複数のサービス創出に

繋がるのではないか、また、既にあるサービスに対してもその利活用を推進させ、さらなるサー

ビスの高度化にも繋げていくことが求められているとの問題意識を有している。

図 4-1 は、機器等から取得されるユーザの生活関連情報が、プラットフォームに収集・蓄積さ

れ、さらにサービス事業者がそれらを活用して、ユーザにサービスを提供する、スマートライフ

関連市場の創出イメージを示す。

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-1 スマートライフ関連市場の創出イメージ

スマートライフが実現するとは、データ連携による企業間アライアンスで、生活上のあらゆる

情報（ライフデータ）が繋がり、生活する上での悩み、不便を解消する等のサービスが提供可能

になることである。図 4-2 が示すように、スマートライフにおけるデータ連携・サービス提供が、

生活の悩みと解決策（ソリューション）を結び付けている。

サービスの提供

・サービス利用履歴

・ユーザーの生活関連情報

プラットフォーム家電等を通じた情報のAI解析

・機器制御データ・電力使用データ・環境情報・ウェアラブル、センサデータ等

機器の制御指示

サービス事業者クラウド

・ユーザーの生活関連情報

機器の利用等

109

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-2 スマートライフのイメージ

一方で、スマートライフにおけるデータ連携・サービス提供を実現するための、技術的な方向

性（イメージ）を図 4-3 に示す。

現在の企業間のデータ連携は、Web API を用いたクラウド間連携が主流との認識のもと、スマ

ートライフ市場も Web API を用いることで、独自に構築されたクラウド同士でも容易にデータ等

のやり取りを行うことを目指す。

さらに、サービス事業者によるデータ利活用を促進するためには、データの協調領域を拡大す

ることや、複数のデータを組み合わせて分析し、サービス事業者にとって有意義な高次元のデー

タを生み出していくことが必要である。

その上で、Web API の技術仕様を公開し、ライフデータを活用したサービスアプリケーション

の開発を容易にする環境を整えて、サービス事業者の勃興を導くものである。

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-3 スマートライフのデータ連携市場イメージ

悩み

安全✓ 宅配便を受け取れない

家事✓ 買い物に行くのが面倒✓ スーパーまでの移動手段がない✓ 炊事・洗濯・掃除の時間がない

健康✓ 日々の体調管理ができない

介護✓ 両親の浴室事故を防ぎたい✓ 孤独死が怖い

子育て✓ 遠隔での帰宅確認✓ 学校からの連絡がプリント✓ 塾へ行かせたいけど高い

提供可能な解決策

安全✓ IoT宅配(不在配達＋スマートロック)

家事✓ 献立提案・ネット宅配サービス✓ デマンド交通ソリューション✓ 家事代行サービス、家電の遠隔制御等

健康✓ デバイスデータ連携ソリューション

介護✓ 浴室見守りソリューション✓ 家電のモニタリングによる異常検知

子育て✓ 入退出見守りソリューション✓ ICTコミュニケーション✓ オンライン学習サービス

スマートホーム 健康・医療等

行政他業種

データ連携・サービス提供

機器メーカークラウド

機器メーカークラウド

サービス事業者クラウド

HEMSコントローラー提供クラウド

プラットフォーム

サービス事業者クラウド

サービス事業者クラウド

サービス事業者クラウド

HEMSコントローラー

プラットフォーム プラットフォームWeb API連携

ECHONET Lite

ECHONET Lite規格も活用しつつ、機器のネットワーク化を促す

協調領域のデータはオープン化を目指す

Web APIを公開して、契約に基づきデータ活用を促進

※使いやすいWeb API開発は（データ提供・契約方式）競争領域

AI

AI

AI

AI

AI

機器メーカークラウド

ホームゲートウェイ

機器メーカークラウド

110

4.2. 接続に関連するルールの整理及び今後の課題

本事業を通じて検討を行った他社間連携上の論点は、今後のスマートライフの実現に向けた、

データ連携・サービス提供における接続に関連するルールの整理と位置づけられる（図 4-4 参照）。

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-4 スマートライフ実証の方向性

4.2.1. データカタログ

サービス事業者のニーズが想定される情報は、在宅予測や健康状態等といった、基礎的な、あ

るいはプリミティブなデータの複数の掛け合わせを必要とする高度な情報（高次データと表現）

である。

現在は、そのような高次データを提供する仕組みやスキームは存在しないが、今後に向けてデ

ータ流通を促進するために、本事業では、高次データや基礎データの持つ意味や属性を整理した

データカタログの取り纏めを行った。

2017年度接続に関連するルールの整理

2018年度社会課題やテーマ毎のサービス創出

社会課題の解決テーマの設定

消費者ニーズの深堀り

サービスを起点としたデータ活用の在り方を検討

①データカタログ

②セキュリティ・製品安全

③プライバシーデータ

111

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-5 接続ルール① データカタログ

データカタログについては、今後の課題として以下の点が挙げられる。

実サービスとの連携によるカタログの有用性評価、データの信憑性確保の追加検討

データカタログの管理の在り方や、市場拡大に向けた利活用スキームの確立

国際標準や既存規格との整合性

4.2.2. セキュリティ・製品安全

システム全体の製品安全・セキュリティレベルは、構成要素のうち、最も弱い対策レベルで決

まってしまう。本事業では、システムにおける役割に応じて求められる対策指針（チェックリス

ト）の整理を行った。

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-6 接続ルール② セキュリティ・製品安全

◆データカタログとは➢ 「データの分類、略形式等を検索するためのメタデータ」をデータの種類ごとにまとめたものと定義。

➢ サービス提供事業者が関心のある対象（人・家・地域など）において、利用可能なデータ種類の一覧とそのメタデータを確認するため

に利用される。

➢ サービス提供事業者は適切な方法で住宅・住設・機器側にデータを要求することができ、メーカ側も機器データ等をサービス提供事業者に適切に提供が可能になり、スマートライフ分野におけるデータ連

携の促進が期待される。

対策区分(第1階層)

対策指針・留意点(第2階層)

サービス事業者(データ活用) プラットフォーマ(データ連携) 機器メーカ（データ提供）

1. 基本方針の策定

① 経営層によるコミット（必要なリソースの割当等）(任意/必須)

② PDCAサイクルによる改善の仕組みを導入する（必須/任意）

① 経営層によるコミット（必要なリソースの割当等) (任意)② PDCAサイクルによる改善の仕組みを導入(必須)

① 経営層によるコミット（必要なリソースの割当等) (任意)② PDCAサイクルによる改善の仕組みを導入(必須)

2. リスクの評価

① リスク評価に基づく対策レベルの特定(必須)② 発注先の選定基準（必須）③ ベンダーの対策の確認方法の検討（必須）④ 発注先との事故の責任範囲の取り決め（必須）

① 守る対象の特定、アーキテクチャに元にリスクとその影響を考慮(内部不正やミスの発生を考慮）(必須)

② プライバシー情報漏洩のリスクと影響分析の実施(必須)

① ①守る対象の特定、つながることによるリスク、アーキテクチャ、物理的なリスクとその影響を考慮する(内部不正やミスの発生を考慮する))(必須)

② プライバシー情報漏洩のリスクと影響分析の実施）(必須)

3. 設計時の対策

① 設計時の発注先の管理・対策状況の確認（必須）

① セキュリティ、セーフティ、プライバシーの影響を考慮した設計(Security, Safety, Privacy by Design：SSPbD) (必須)

② 遠隔操作における製品安全に係わる問題の考慮（必須）③ 安全安心を実現する設計の検証の実施(必須)④ 多層防御（多重のセキュリティ対策の考慮）(必須)⑤ ログ・監視機能の導入(必須)⑥ 主要IoTセキュリティガイドラインの考慮(CSA, OWASP等）

(任意)

① つながる相手のリスクを回避する設計（必須）② つながる相手に損害を与えない設計（任意）③ セキュリティとセーフティの相互影響を考慮した設計(Security,

Safety, Privacy by Design：SSPD) （必須）④ 遠隔操作により安全性に係わる問題の考慮（必須）⑤ 安全安心を実現する設計の検証の実施（必須）⑥ 認証機能、暗号化の導入必要性の検討（CRYPTREC

等）（必須）⑦ ログ・監視機能の導入（任意）

4. 実装時の対策

① 実装時の発注先の管理・対策状況の確認（必須）① 設計を満たす実装であることのテストの実施(必須)

② 構築（インテグレーション）時の設定等の検証（必須）③ 機器の状態把握、記録機能の実現（任意）

① 設計を満たす実装であることのテストの実施(必須)② 機器の状態把握、記録機能の実現（必須）

112

セキュリティ・製品安全については、今後の課題として以下の点が挙げられる。

各社におけるそれぞれの事業内容に応じたリスク評価の深堀り

誰が、どこで、どのようにログを取るかなどの責任分界点を検討

4.2.3. プライバシーデータの活用

本事業では、複数事業者間でデータ利活用する際の利用者からの同意書（雛形）の整備を行っ

た。

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-7 接続ルール③ プライバシーデータの活用

プライバシーデータの活用については、今後の課題として以下の点が挙げられる。

より複雑なサービスにおける、分かりやすいデータ流通の説明をイラスト化した同意書の

雛形検討

サービスを途中で解約した（オプトアウト）場合のデータ管理の在り方を検討

多言語化した際に生じる、海外規制等への対応を検討

4.3. 社会課題やテーマ毎のサービス創出に向けて

スマートライフ市場を創出するためには、まず社会課題を捉えた上で、それを解決するために

はどのようなサービスが有効か、さらにそのサービスを実現するためには、どのようなライフデ

ータが必要か、との検討が求められる。

経済産業省では、今後に解くべき社会課題（仮説）として、人口動態が大きく変化し、少子高

説明項目 プラットフォーマ サービサ

１． 基本方針 コンプライアンスの宣言等、個人情報を取扱う上での基本方針を明示する。

２． 適用範囲 本プライバシーポリシーの効力が及ぶ範囲を明示する。サービス毎にポリシーが異なる場合は、サービス毎に作成する必要がある。

３． 個人情報の取得と利用目的

※ 図・イラストでも説明（可能ならWeb・アプリでの説明・同意）

以下の3 点を明記する必要がある。• 収集する情報• 収集方法（直接取得、間接取得を含む）• 利用目的（※第三者提供することを利用目的に含めることも可能）

以下の3 点を明記する必要がある。• 収集する情報• 収集方法（直接取得、間接取得を含む）• 利用目的

なお、プラットフォーマからの第三者提供以外で、サービサが個人情報を独自に収集している場合は、その旨を明記する必要がある。

４． 個人情報の管理※ 図・イラストでも説明

利用者から取得した情報について、どのような管理を行うかについて明記する。（個人情報管理体制、委託先管理、保存期間など）

個人情報の管理については、具体的に記載することで、より利用者からの信頼を得ることが可能である。そのため、個人情報管理体制、委託先管理、保存期間などについても記載することが望ましい。

５． 第三者提供の有無※ 図・イラストでも説明（可能ならWeb・アプリでの説明・同意）

第三者提供の有無について明記する。

第三者提供を行わない場合、今後第三者提供を行う場合は利用者から同意を得て実施することを明記することが望ましい。

第三者提供を行う場合、同意が得られた場合のみ第三者提供を行うことを明記する。なお、第三者提供する個人情報、提供先企業における利用目的、が明記されていることが望ましい。

利用目的の必要な範囲内において、他の事業者へ個人情報を委託する場合、委託することを明記する。

第三者提供の有無について明記する。

第三者提供を行う場合、同意が得られた場合のみ第三者提供を行うことを明記する。なお、第三者提供する個人情報、提供先企業における利用目的、が明記されていることが望ましい。

６． 個人情報の開示・訂正・利用停止等

利用者からの求めに応じ、保有個人データの開示・訂正・利用停止・それらの手続き等に関する事項を明記する。

とくに、オプトアウトの条件・方法についてはわかりやすく記載する。（可能であればWebやアプリによる説明と同意取得が望ましい。）

７． 問合せ先 苦情や問合せに対応する窓口について、連絡先を明記する。問合せ可能な連絡先と連絡方法が明示されていることが望ましい。

８． 改訂 プライバシーポリシー等の個人情報に係る取扱い方針の改訂状況（策定日、改訂日等）を明記する。

113

齢化、生産年齢人口が減少する状況下において、次の 2 点、「①経済成長率の低下－新たな労働力

確保」、「②社会保障費の増大－社会保障費の現状維持」を挙げられている（図 4-8 参照）。

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-8 今後に解くべき社会課題（仮説）

共働き世帯や子育て世帯の家事負担軽減のためには、どのようなデータを活かせるか、また、

高齢者の健康増進、健康維持や、介護負担軽減のためには、どのようなデータを活かせるか、に

ついて、今後のスマートライフ実証等を通じてデータ活用の在り方が具体的に検討されていく。

スマートライフ実証の全体イメージを図 4-9 に、実証要素を図 4-10 に示した。

ライフデータを活用したサービス実証を、①サービス事業者（データ活用）、②プラットフォー

マ（データ収集・分析）、③機器メーカ（データ提供）から組成されるコンソーシアムが行う。こ

の時、コンソーシアムは、大小様々な事業者が参画できるような仕組み、スキームになるよう工

夫することが重要である。

①経済成長率の低下-新たな労働力確保

②社会保障費の増大-社会保障費の現状維持

• 無償労働（家事、育児、介護など）から解放することにより、有償労働へシフトさせるサービス創出ができないか。

• 「家事負担軽減・有償労働へのシフト」➢ 共働き世帯や子育て世帯の家事負

担軽減のために、どのようなデータを活かせるか。

社会課題 内容 検討の方向性（仮説）

• 「高齢者の健康増進・介護負担軽減」➢ 高齢者の健康増進、健康維持や、

介護負担軽減のために、どのようなデータを活かせるか。

• 社会保障費を現状維持するため、健康な高齢者を増やすことに加え、介護負担を抑えるようなサービス創出ができないか。

114

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-9 スマートライフ実証 全体イメージ

（出所：スマートライフ政策について、経済産業省、平成 30 年 2 月）

図 4-10 スマートライフ実証 実証要素

有効なデータ活用の促進今年度整理したデータカタログの考え方を用いて、サービス起点で有効なデータカタログを提供できるのか検証する。また、データカタログの管理の在り方（新サービス

への対応やデータ種類の追加等）について掘り下げる。

セキュリティ・製品安全におけるリスクベースアプローチの掘り下げ

セキュリティはサービス形態・事業者連携状況によってリスク評価は可変することが想定されるため、プロジェクトごとに各社が行うべきリスク評価（①守るべき資産の特定、②脅威・脆弱性の洗い出し、③リスクの影響規模、④対策の検討）を行い、責任分界点について掘り下げる。

プライバシーデータ取扱いの在り方の掘り下げ

より複雑なサービスにおける、分かりやすいデータ流通の説明をイラスト化した同意取得のあり方について検討を進めるとともに、必要に応じて特定の主体にプライバシーデータの流通を本人同意のもと一括して信託できる仕組み（情報銀行）の議論も取り込んでいく。

公平・公正な企業間連携の在り方の掘り下げ

企業間のデータ連携の在り方について、データ契約ガイドラインの議論を踏まえ、スマートライフ分野の検討を進める。

115

参考資料

個人情報の取扱方針（ひな形（暫定版））

参考資料

1

個人情報の取扱方針（ひな形（暫定版））

【目次構成】

1. 基本方針

2. 適用範囲

3. 個人情報の取得と利用目的

4. 個人情報の管理

5. 第三者提供の有無

6. 個人情報の開示・訂正・利用停止等

7. 問い合わせ先

8. 改訂

参考資料

2

【プラットフォーマ】

1. 基本方針

※ コンプライアンスの宣言等、個人情報を取扱う上での基本方針を明示する。

記載例

＜○○（事業体名称）＞ (以下、「当社」といいます。)は、個人情報の重要性を認識し、

個人情報を保護することが社会的責務であると考え、個人情報に関する法令及び社内規程

等を遵守し、当社で取扱う個人情報の取得、利用、管理を適正に行います。

2. 適用範囲

※ 本プライバシーポリシーの効力が及ぶ範囲を明示する。サービス毎にポリシーが異なる場合

は、サービス毎に作成し、企業全体のプライバシーポリシーと区別する他、それらの相互の

関係を明示する必要がある。

記載例

本プライバシーポリシーは、当社が行う各種サービスにおいて、お客様の個人情報もしくはそれ

に準ずる情報を取り扱う際に、当社が遵守する方針を示したものです。

3. 個人情報の取得と利用目的

※ 当該項目では、以下の 3点を明記する必要がある。

• 収集する情報

• 収集方法（直接取得、間接取得を含む）

• 利用目的

※ スマートホーム関連サービスは利用者において情報の流れの把握が困難であるため、図・イ

ラストでも説明すること（Web・アプリでの説明・同意が望ましい）

記載例

当社はお客様から以下の情報をご提供いただいております。

• 利用データ

本サービスで設置、提供等する機器を通じて、当社が収集いたします

• 氏名、住所、連絡先

サービス申込時に申込書に御記入いただくことで、当社が収集しております。

また、当社は、お客様からご提供いただく情報を以下の目的の範囲内において、当社が提

供する○○○サービスに利用します。お客様の同意なく、情報の収集、目的外の利用を行うこ

とはありません。

参考資料

3

＜以下は、利用目的例となる＞

• 利用データを利活用した○○○サービス（電力使用量見える化、見守りなど）を提供するた

め（または、「（サービサ名）の○○○サービス（電力使用量見える化、見守りなど）を提供する

ため」等、サービス提供形態に即して記載する）

• 本サービスの提供や機能拡張に向けた研究開発のため

• 本サービスの利用に伴う連絡・メールマガジン・DM・各種お知らせ等の配信・送付のため

• お客さまの承諾・申込みに基づく、本サービス利用企業・提携企業・団体等への個人情報

の提供のため

• 本サービスの改善・新規サービスの開発およびマーケティングのため

• キャンペーン・アンケート・モニター・取材等の実施のため

• 本サービスに関するご意見、お問い合わせ内容の確認・回答のため

• 利用規約等で禁じている行為などの調査のため

4. 個人情報の管理

※ 利用者から取得した情報について、どのような管理を行うかについて明記する。（個人情報

管理体制、委託先管理、保存期間など）

個人情報の管理については、具体的に記載することで、より利用者からの信頼を得ること

が可能である。そのため、個人情報管理体制、委託先管理、保存期間などについても記

載することが望ましい。

（『個人情報の保護に関する法律についてのガイドライン（通則編）』の「個人データの管理」

P42~P44 に記載されている事項を実施している場合は、記載することが望ましい）

※ スマートホーム関連サービスは利用者において情報の流れの把握が困難であるため、図・イ

ラストでも説明すること（Web・アプリでの説明・同意が望ましい）

記載例

当社は、お客様からご提供いただいた情報の管理について、以下を徹底します。

1). 情報の正確性の確保

お客様からご提供いただいた情報については、常に正確かつ最新の情報となるよう努めます。

2). 安全管理措置

当社は、組織的な個人情報の管理については、社内規定による厳重に取扱い方法を規定し、

それに基づいた取扱いを徹底しています。

3). 従業者の監督

当社は、当社の規程に基づき、個人情報取扱い規程の厳格な運用を徹底しています。

4). 委託先の監督

個人情報の取扱いを外部に委託する場合には、当社の規程に基づき、用件を満たした委託

先にのみ委託を行い、適切な管理を行います。

参考資料

4

5). 保存期間と廃棄

お客様からご提供いただいた情報については、保存期間を設定し、保存期間終了後は廃棄し

ます。また、保存期間内であっても、不要となった場合にはすみやかに廃棄します。

5. 第三者提供の有無

※ 第三者提供の有無について明記する。

※ スマートホーム関連サービスは利用者において情報の流れの把握が困難であるため、図・イ

ラストでも説明すること（Web・アプリでの説明・同意が望ましい）

＜第三者提供を行わない場合＞

※ 第三者提供を行わないことを明記する。今後第三者提供を行う場合は、利用者から同意

を得て実施することを明記することが望ましい。

また、利用目的の必要な範囲内において、他の事業者へ個人情報を委託する場合、委

託することを明記する。

記載例

当社は、お客様からご提供いただいた個人情報を、第三者に提供することはありません。また、

今後第三者提供を行う事になった場合には、提供する情報と提供目的などを提示し、お客様

から同意を得た場合のみ第三者提供を行います。

また、当社では、利用目的の達成に必要な範囲内において、他の事業者へ個人情報を委

託することがあります。

＜第三者提供を行う場合＞

※ 第三者提供を行うことを明記し、同意が得られた場合のみ第三者提供を行うことを述べる。

なお、以下の項目が明記されていることが望ましい。

• 第三者提供する個人情報

• 提供先企業における利用目的

記載例

当社は、以下のサービスをお客様に提供するため、お客様からご提供いただいた個人情報や

利用データの第三者提供を行います。

• 見える化サービス

……

6. 個人情報の開示・訂正・利用停止等

参考資料

5

※ 利用者からの求めに応じ、保有個人データの開示・訂正・利用停止・それらの手続き等に

関する事項を明記する。

※ 特に、オプトアウト（個人情報保護法第２３条第２項に基づくオプトアウトであるか、任意で

導入したオプトアウトであるかは問わない）の条件・方法についてはわかりやすく記載する。

（Webやアプリによる説明と同意取得が望ましい。）

記載例（簡潔に記載する場合）

開示、訂正、利用停止等のお申し出があった場合には、当社所定の方法に基づき対応致し

ます。具体的な方法については、個別にご案内しますので、下記受付窓口までお問い合わせく

ださい。

＜受付窓口を記載＞

記載例（詳細に記載する場合）

お客様からご提供いただいた情報の詳細については、以下の手続きにていつでもご確認するこ

とができます。また、情報の内容の訂正や利用停止等についても、お客様の申請に基づき、速

やかに処理します。

1). 個人情報取扱事業者の名称

株式会社○○○○

本社所在地：○○○○○○○○○○○○

代表者氏名：○○○○○○○○○○○○

2). 保有個人データの訂正等

ご提供いただいた情報に訂正が必要な場合は、以下の手続きにより情報の更新を行う

ことができます。

＜利用者からの要求により、保有個人データの訂正を行う際の手続きの方法について記

載、又は詳細な説明ページへのリンクなど＞

3). 保有個人データの利用停止等

ご提供いただいた情報の利用停止、情報のご提供の停止、ご提供いただいた情報の削

除等については、以下の手続きにより行うことができます。

＜利用者からの要求により、保有個人データの利用停止を行う際の手続きの方法につい

て記載、又は詳細な説明ページへのリンクなど）

4). 手数料

＜手続きが無償の場合＞

参考資料

6

上記の手続きには、手数料等は発生いたしません。

＜手続きが有償の場合＞

上記の手続きを希望される利用者は、1件につき〇〇〇〇円の手数料をお支払いただくことが

必要となります。

7. 問い合わせ先

※ 苦情や問合せに対応する窓口について、連絡先を明記する。問合せ可能な連絡先と連

絡方法が明示されていることが望ましい。

記載例

本サービス、又は個人情報の取扱いに関しては、下記の窓口まで電話または E メールにてお

問い合わせください。

○○株式会社 ○○部 個人情報保護担当

電話番号： 03-1234-5678

E メールアドレス： privacy@xxxx.co.jp

8. 改訂

※ プライバシーポリシー等の個人情報に係る取扱い方針の改訂状況（策定日、改訂日等）を

明記する。

記載例

平成 27年 4月 1日 策定

平成 28年 9月 1日 改訂

参考資料

7

【サービサ】

1. 基本方針

※ コンプライアンスの宣言等、個人情報を取扱う上での基本方針を明示する。

記載例

＜○○（事業体名称）＞ (以下、「当社」といいます。)は、個人情報の重要性を認識し、

個人情報を保護することが社会的責務であると考え、個人情報に関する法令及び社内規程

等を遵守し、当社で取扱う個人情報の取得、利用、管理を適正に行います。

2. 適用範囲

※ 本プライバシーポリシーの効力が及ぶ範囲を明示する。サービス毎にポリシーが異なる場合

は、サービス毎に作成し、企業全体のプライバシーポリシーと区別する他、それらの相互の

関係を明示する必要がある。

記載例

本プライバシーポリシーは、当社が行うサービスにおいて、お客様の個人情報もしくはそれに準

ずる情報を取り扱う際に、当社が遵守する方針を示したものです。

3. 個人情報の取得と利用目的

※ 当該項目では、以下の 3点を明記する必要がある。

• 収集する情報

• 収集方法（直接取得、間接取得を含む）

• 利用目的

なお、プラットフォーマからの第三者提供以外で、サービサが個人情報を独自に収

集している場合は、その旨を明記する必要がある。

※ スマートホーム関連サービスは利用者において情報の流れの把握が困難であるため、図・イ

ラストでも説明すること（Web・アプリでの説明・同意が望ましい）

記載例

当社は＜プラットフォーマ（第三者提供元）＞から以下の情報を取得しております。

• 利用データ

• 氏名、住所、連絡先

これらの情報は、以下の目的の範囲内において、当社が提供する○○○サービスに利用し

ます。お客様の同意なく、情報の収集、目的外の利用を行うことはありません。

＜以下は、利用目的例となる＞

参考資料

8

• 利用データを利活用した○○○サービス（電力使用量見える化、見守りなど）を提供するた

め

• 本サービスの提供や機能拡張に向けた研究開発のため

• 本サービスの利用に伴う連絡・メールマガジン・DM・各種お知らせ等の配信・送付のため

• お客さまの承諾・申込みに基づく、本サービス利用企業・提携企業・団体等への個人情報

の提供のため

• 本サービスの改善・新規サービスの開発およびマーケティングのため

• キャンペーン・アンケート・モニター・取材等の実施のため

• 本サービスに関するご意見、お問い合わせ内容の確認・回答のため

• 利用規約等で禁じている行為などの調査のため

4. 個人情報の管理

※ 利用者から取得した情報について、どのような管理を行うかについて明記する。（個人情報

管理体制、委託先管理、保存期間など）

個人情報の管理については、具体的に記載することで、より利用者からの信頼を得ること

が可能である。そのため、個人情報管理体制、委託先管理、保存期間などについても記

載することが望ましい。

（『個人情報の保護に関する法律についてのガイドライン（通則編）』の「個人データの管理」

P42~P44 に記載されている事項を実施している場合は、記載することが望ましい）

※ スマートホーム関連サービスは利用者において情報の流れの把握が困難であるため、図・イ

ラストでも説明すること（Web・アプリでの説明・同意が望ましい）

記載例

当社は、お客様からご提供いただいた情報の管理について、以下を徹底します。

1). 情報の正確性の確保

お客様からご提供いただいた情報については、常に正確かつ最新の情報となるよう努めます。

2). 安全管理措置

当社は、組織的な個人情報の管理については、社内規定による厳重に取扱い方法を規定し、

それに基づいた取扱いを徹底しています。

3). 従業者の監督

当社は、当社の規程に基づき、個人情報取扱い規程の厳格な運用を徹底しています。

4). 委託先の監督

個人情報の取扱いを外部に委託する場合には、当社の規程に基づき、用件を満たした委託

先にのみ委託を行い、適切な管理を行います。

5). 保存期間と廃棄

お客様からご提供いただいた情報については、保存期間を設定し、保存期間終了後は廃棄し

参考資料

9

ます。また、保存期間内であっても、不要となった場合にはすみやかに廃棄します。

5. 第三者提供の有無

※ 第三者提供の有無について明記する。

第三者提供がある場合は、以下の項目を明記することが望ましい。また、同意が得られた

場合のみ第三者提供を行うことを明記する。

• 第三者提供する個人情報

• 提供先企業における利用目的

記載例

（第三者提供がない場合）

当社は、取得した個人情報を、第三者に提供することはありません。また、今後第三者提

供を行う事になった場合には、提供する情報と提供目的などを提示し、お客様から同意を得た

場合のみ第三者提供を行います。

（第三者提供がある場合）

当社は、以下のサービスをお客様に提供するため、個人情報や HEMS データの第三者提

供を行います。

• ○○○サービス

6. 個人情報の開示・訂正・利用停止等

※ 利用者からの求めに応じ、保有個人データの開示・訂正・利用停止・それらの手続き等に

関する事項を明記する。

※ 特に、オプトアウト（個人情報保護法第２３条第２項に基づくオプトアウトであるか、任意で

導入したオプトアウトであるかは問わない）の条件・方法についてはわかりやすく記載する。

（Webやアプリによる説明と同意取得が望ましい。）

記載例（簡潔に提示する場合）

開示、訂正、利用停止等のお申し出があった場合には、当社所定の方法に基づき対応致し

ます。具体的な方法については、個別にご案内しますので、下記受付窓口までお問い合わせく

ださい。

＜受付窓口を記載＞

記載例（詳細に記載する場合）

お客様からご提供いただいた情報の詳細については、以下の手続きにていつでもご確認するこ

参考資料

10

とができます。また、情報の内容の訂正や利用停止等についても、お客様の申請に基づき、速

やかに処理します。

1). 個人情報取扱事業者の名称

株式会社○○○○

本社所在地：○○○○○○○○○○○○

代表者氏名：○○○○○○○○○○○○

2). 保有個人データの訂正等

ご提供いただいた情報に訂正が必要な場合は、以下の手続きにより情報の更新を行う

ことができます。

＜利用者からの要求により、保有個人データの訂正を行う際の手続きの方法について記

載、又は詳細な説明ページへのリンクなど＞

3). 保有個人データの利用停止等

ご提供いただいた情報の利用停止、情報のご提供の停止、ご提供いただいた情報の削

除等については、以下の手続きにより行うことができます。

＜利用者からの要求により、保有個人データの利用停止を行う際の手続きの方法につい

て記載、又は詳細な説明ページへのリンクなど）

4). 手数料

＜手続きが無償の場合＞

上記の手続きには、手数料等は発生いたしません。

＜手続きが有償の場合＞

上記の手続きを希望される利用者は、1件につき〇〇〇〇円の手数料をお支払いただくことが

必要となります。

7. 問い合わせ先

※ 苦情や問合せに対応する窓口について、連絡先を明記する。問合せ可能な連絡先と連

絡方法が明示されていることが望ましい。

記載例

本サービス、又は個人情報の取扱いに関しては、下記の窓口まで電話または E メールにてお

問い合わせください。

○○株式会社 ○○部 個人情報保護担当

電話番号： 03-1234-5678

参考資料

11

E メールアドレス： privacy@xxxx.co.jp

8. 改訂

※ プライバシーポリシー等の個人情報に係る取扱い方針の改訂状況（策定日、改訂日等）

を明記する。

記載例

平成 27年 4月 1日 策定

平成 28年 9月 1日 改訂