I
概要
近年、ネット対応家電を高度に連携させて家庭 内で省エネかつ快適な環境を提供するスマート ホームに関する技術が注目を集めている。しかし、 既存のネット対応家電および関連サービスは、単 独利用もしくは同一メーカの家電との連携しかサ ポートしていない。本稿では、スマートホーム向け の家電連携サービスの開発促進を目指した基盤 ソフトウェア（ミドルウェア）を提案する。本ミドル ウェアは、家庭のコンシェルジュとして家庭内デバ イス群とユーザを仲介し、(1)
各デバイスへの操作 コマンドの送信や状態・センサ値の取得、(2)
ユー ザからの操作命令の受信、ユーザへの結果の通 知などを容易に行える機能を提供する。また、近 年注目を集めている「集合知」を利用するサービ ス開発のため、(3)
各家庭でのデバイスの状態や センサ値の変化履歴データを第3
者に送信する 機能を提供する。(1)(2)
の機能の実現においては、 ユーザにとって使い勝手が良くかつ不正な利用を 防ぎ安全性を担保すること、(3)
の実現においては、 デバイスの履歴データからユーザが特定されない ことが求められる。本ミドルウェアに、自然言語 ベースの操作命令体系とSNS
等を用いた外部通 信機構、k-
匿名化を拡張したセキュリティ機構等 を組込むことで、これらの課題を解決する。本ミド ルウェアを実装し評価実験を行った結果、遠隔操 作の応答性能が6
秒以内程度と実用に十分耐えう ること、様々なアプリケーションを少ない工数で開 発できることを確かめた。II
はじめに
近年、インターネットに接続し、遠隔から操作・ 動作状況の確認ができる家庭内デバイス（テレビ、スマートホーム
実現
に
向
けた
家庭内
デバイスへの
統合
アクセスミドルウェア
安本慶一 Keiichi Yasumoto 奈良先端科学技術大学院大学 情報科学研究科 / 教授 論文1）http://www.echonet.gr.jp/ ハードディスクレコーダ、エアコン、カメラ、体重計 等）の製品開発が盛んに行われている。また、ホー ムネットワークに接続された家庭内デバイスの通 信プロトコルとして
ECHONET Lite
1）が2011
年 に国際標準化され、スマ ートハウスにおけるHEMS
（Home Energy Management System
） の標準プロトコルとして経産省に認定されている。 しかし、ネットワークアクセス可能な家庭内デバイ スはまだ少数であり、ネットワーク対応していても、 スマートフォンなどから専用ソフトを用いて、個別 のデバイスに対してのみ操作や動作確認ができる 程度に留まっている。現状では、販売メーカの異な る多種のデバイスを一元的に操作可能なサービス やアプリケーションは存在せず、また、そのような アプリケーションの開発を促進する基盤ソフトウェ アも提供されていない。今後、ネットワーク対応デ バイスがより一般的になり、家庭内の様々なデバ イスがネットワークに接続されると、家庭内におい て住人毎にパーソナライズされた快適な環境（空 調や照明の一括設定など）を簡単な操作で再現し たり、部屋の状況や住人の状況の変化に従って自 動でデバイスを操作する（就寝前に寝室を温める、 消し忘れた空調・照明をオフにする等）、さらには、 ユーザと似た他の家庭のお勧めの省エネ設定を 集合知から自動的に取得して推薦する、といった スマートな家電連携サービスが実現可能になって 行くと予想される。このような高度なスマートホー ム向けサービスを容易に構築可能にする基盤ソフ トウェアの必要性が高まっている。 ネット対応デバイスが採用する多様な通信方式 の差異を吸収し、統一されたインタフェースによる デバイス操作を実現するゲートウェイシステムが 幾つか提案されている[1]
∼[3]
。しかし、これらの 既存システムは、(i)
ゲートウェイシステムを利用可 能なアプリケーションが限定されている、(ii)
任意 に設定した条件を満たした時にユーザやサーバに イベントの発生を通知する機能を持たない、など の問題を持ち、これらを全て解決したシステムは 存在しない。ホームネットワーク上の家電の使用 ログを監視し、異常を検出する見守りアプリケー ション[4], [5]
や、ホームオートメーションや分散 監視アプリケーション向けのセンサネットワーク ゲートウェイ[6]
が提案されている。しかし、複数の サービスを同時に動作させた場合、同じデバイス への異なる操作要求が同時に発生し思わぬ不具 合が発生する恐れがある。多種多様なデバイス、 アプリケーションに対応できる柔軟性を持った、 家庭内デバイス操作ミドルウェアが必要である。 本稿では、既存研究の問題を解決し、家庭内 の様々なデバイスを容易かつ柔軟に管理・操作す る基盤ソフトウェア（ミドルウェア）を提案する。提 案ミドルウェアでは、「家」とユーザとの自然な会 話により家庭内の各デバイスの操作や動作状況 の確認、複数のデバイスの一括操作や適応的・自 律的なデバイス操作、さらには集合知に基づく省 エネ設定の推薦等を可能にする。 本ミドルウェアは、ホームサーバ上で実行され、 ユーザとデバイス群を仲介する家庭の「コンシェ ルジュ」として機能し、(1)
ホームネットワークを介 した各家庭内デバイスとの通信（各種操作コマン ドの送信や動作状況・センサ値の取得等）、(2)
イ ンターネットを介したユーザとの通信（各種遠隔操 作・監視・条件設定命令の受信、ユーザへの結果 の通知等）の機能を提供する。また、集合知を利 用するサービスの開発のため、(3)
各デバイスの各 時点における状態・センサ値等をユーザ以外の第3
者に送信する機能も提供する。(1)
の機能の実現 においては、赤外線しか対応していないデバイス を含む様々なデバイスを利用可能なこと、(2)
の機 能の実現においては、ユーザにとって使い勝手が元の電話番号を用いて認証を行うことで、セキュリ ティを確保しつつテキストによるデバイス制御を実 現している。しかし通信のインタフェースが
SMS
に 固定されており、また警報の発報条件が遠隔地か ら新規設定や変更ができない等柔軟性に欠ける。 よって、このシステムを本研究の目的の一つである 様々なアプリケーションの開発のために使用する ことは難しい。 三次らはUPnP
やZigBee
で通信を行う家電や セ ン サ デ バ イ ス をCoAP
（Constrained
Application Protocol
）を用いて接続するゲート ウェイを提案した[2]
。CoAP
は現在標準化策定 中の、リソースに制約のあるインターネットデバイ スでの使用を想定したWeb
転送プロトコルである[9]
。ユーザは遠隔地のサーバ等からゲートウェイ にHTTP
リクエストを送ることでセンサデバイス の監視や操作が可能である。しかし、このシステム は条件を設定しての通知ができないため、センサ の監視を行いたい場合、アプリケーション側でセ ンサデータのポーリングを行う必要がある。また、 認証機能を持たないなど、セキュリティ面が考慮さ れていない。 幾つかの家電メーカから、自宅の家電やセンサ デバイスをインターネットと接続するゲートウェイ が発表され、実際に運用されている。パナソニッ クは、対応デバイスのインターネットを介したデバ イスの遠隔制御や、電力消費状況の見える化、自 動制御による節電等を実現するAiSEG[10]
を販 売している。しかし、対象デバイスが限定されてお り、制御のできる範囲が限られている等の課題が 存在する[11]
。 III. 2 デバイスとSNSを接続する研究 近年、ソーシャル・ネットワーキング・サービス （SNS
）の普及により、デバイスをSNS
に接続し、 良く、かつ不正な利用を防ぎ安全性が担保される こと、(3)
の機能の実現においては、デバイスの履 歴データ等からユーザが特定されないようにする ことが課題となる。そのため、(1)
に対しては、赤外 線デバイスとホームネットワークを仲介するゲート ウェイ機構、(2)
に対しては、SNS
や電子メール等 で送受信可能な自然言語に基づく操作命令体系、 および、各デバイス・ユーザの組に対し操作権限 を個別に設定できる機構、(3)
に対しては、k-
匿名 化[7]
を拡張したプライバシ保護機構を実現する。 提案ミドルウェアを実装し、基本性能を調べる 実験と、3
つの異なるアプリケーションの開発実験 を行った。結果、応答時間に関しては約6
秒以内と 実用十分な性能を持つこと、アプリケーション開 発に関しては、種類を問わず十分少ない工数での 開発ができることが確認できた。III
関連研究
本章では、関連研究として、様々なデバイスを携 帯電話網やインターネットに接続するゲートウェイ に関する研究、デバイスをSNS
と接続する研究に ついて順に概要を述べる。 III. 1 デバイスをインターネット接続する研究
Khiyal
らは、携帯電話のSMS
（Short Message
Service
）を用いたデバイスの遠隔制御・警報シス テムHACS
（Home Appliance Control System
） を提案した[8]
。HACS
は、システムソフトウェア が動作しているパソコンと、SMS
の送受信機能を システムに提供するGSM
モデム、そしてSMS
を実 際に送受信するモバイルデバイスで構成されてい る。HACS
はユーザに家電の遠隔制御機能と、不 審者を発見した際の警報機能を提供する。ユーザ との対話はSMS
を通じて行われ、システムは発信5）http://www.lgnewsroom.com/newsroom/ contents/64064 6）http://www.upnp.org/ 7）http://jp.dlna.org/ 2）http://facebook.com/ 3）http://twitter.com/ 4）http://line.me/ かし、このシステムはセキュリティを考慮しておらず、 結果の信頼性を担保することが難しい。 また、近年では
[15]
など）。しかし、これらは基 本的に通知のためだけに使用され、公開された情 報を利用したアプリケーションなどは発展途上に ある。ごく最近になって、LG
エレクトロニクスがSNS
の一つであるLINE
4）を介して家電を操作す るHomeChat
と呼ばれるサービスを発表した5）。 本サービスは、本稿で提案するシステムと同じく ユーザと家とのLINE
上での会話をベースに家電 の制御を行うことができる。しかし、セキュリティ 機能や様々なアプリケーション開発に向けた柔軟 性などの詳細については触れられていない。IV
家庭内デバイスへの
統合アクセスミドルウェア
本章では、提案するミドルウェアの目的および 利用シナリオと、実現する際の課題と要件を述べ、 課題解決に向けたアイデアを記す。 IV. 1 ミドルウェアの目的と利用シナリオ 本ミドルウェアは、次の3
つの利用シナリオ（サー ビス/
アプリケーション）を想定している。 a) 家電の遠隔操作 近年、ネットワークに接続可能な家庭内デバイ スが多数登場してきているが、採用する通信方式が
UPnP
6）やDLNA
7）、Echonet Lite
などまちまちで互換性がなく、それぞれ専用のアプリケーション やインタフェースを介して操作を行う必要がある。 例えば外出先から帰宅前に室温をチェックし、予 めエアコンの電源を入れておくことや、録画予約 忘れを思い出した時に外出先からレコーダを操作
SNS
を介してデバイスの状態を閲覧したり制御す る手法が幾つか提案されている。Kamilaris
らは、Web
を統合する手法を提 案した[12]
。この手法では、スマートホームのイン タフェースとしてFacebookAPI
を利用したアク セス制限も実装されており、セキュリティも確保さ れている。しかし、厳格なアクセス制限のため、デ バイスの情報を第3
者に提供するのは困難であり、 集合知を利用したサービス開発には利用できない。 米澤らは、無線センサネットワーク（WSN
）のセ ンサ情報に基づいたイベントを[13]
。このプラットフォームでは、収集されたセ ンサ情報の状態に対して予め定義されたイベント が発生した時、自動的にWSN
内にある監視対象の動向をシーム レスかつ容易に定義し共有することができる。し かし、共有される情報は定義されたイベントのみ であり、デバイスの遠隔操作には対応していない。Demirbas
らは、[14]
。 このシステムにより、ユーザがめ、本利用シナリオの実現のためには、収集した デバイス情報に対し異常となる条件を設定し、条 件が成立した時に何らかのアクションを起こす機 能が必要となる。柔軟性を持たせるために、異常 を判定する条件や、その時実行するアクションを 自由に設定・変更できるインタフェースも必要であ る。また、異常時以外でも見守りが実現できるよう に、ユーザ側からのクエリを受けて随時デバイス 情報を返信できることが望ましい。 c) 集合知による省エネ設定の推薦 東日本大震災以来、全国的な電力不足が続き、 節電の必要性が高まっている。これまで、コンテキ ストアウェアネス技術を用いて、コンテキストの変 化に合わせてデバイスを省エネ制御する方法が幾 つか提案されてきたが、自動制御によって削減で きる電力量は限定的であり、省エネのためにユー ザの自制を効果的に促す方法が求められている
[17]
。現在および過去の消費電力を可視化するシ ステムが多数提案されている[18], [19]
が、得られ るのは自宅の消費電力の値だけであり、比較対象 は過去の自分の行動のみである。集合知の概念 に基づき、ユーザとよく似た家庭（地域や間取り等） の電力消費状況から、快適性を損ねずに賢く省エ ネできている家庭の家電設定を自動的に発見し、 その設定をユーザに推薦できれば、より効果的な 省エネが見込める。また、収集したデバイスの使 用パターンなどのビッグデータを解析することで、 節電だけではなく快適性を向上させる提案（新た な家電の設置、リプレース等）に活用できる可能性 も考えられる。 本利用シナリオを実現するためには、ユーザの 家のデバイス情報を、要求に応じた粒度、タイミン グで第3
者に送信する機能が必要である。提供す るサービスによって、デバイス情報の取得間隔や、 必要な統計値の種類は異なる。そのため、取得間 して録画予約や録画操作をすることなどが同じイ ンタフェースで行えると便利である[1]
。 このようなシナリオに対応するためには、異なる 通信方式のデバイスを統一されたインタフェース で扱えるようにするデバイスアクセス機構をミドル ウェアが提供する必要がある。デバイスアクセス 機構は、ネット未対応の従来型家電も同様に扱え ることが望ましい。また、前述の通り、ユーザが異 なるデバイスを遠隔操作する際に、ユーザから見て 一つのインタフェースから行うことができることも 必要となる。 ある家の家電を遠隔操作できるのは、その家の 住人や指定した人のみに限定する必要がある。ま た、住人であっても、小さな子どもによる潜在的に 危険なデバイス（ストーブなど）の操作や、自宅に 誰もいない状況で鍵を解錠するといった誤操作の 危険性は常に存在する。そのような危険性を低減 する仕組みの導入も必要である。 b) 見守り 近年、一人暮らしの人が誰にも看取られることな く亡くなる孤独死が社会問題となっている[16]
。公 的機関による日常的な見守りなど様々な対策が講 じられているが、時間や範囲、頻度に限りがあり、 十分ではない。ネットワークに接続された既存の デバイスを利用して、継続的かつ即時性のある見 守りが実現できれば、孤独死の発生を抑制できる と考えられる。 本利用シナリオでは、継続的かつ即時性のある 見守りを実現するために、家の各所に設置してあ るセンサの情報やテレビやエアコン等のデバイス の動作状況（以後、デバイス情報と呼ぶ）を随時 収集する必要がある。これにより、例えば室温が異 常に高い（または低い）かつ人が在室している時に エアコンの動作を確認できない場合は、在室して いる人に異常がある可能性を検出できる。そのた場合と同等の操作性を実現しつつ、上記利用シナ リオで示したサービスの容易な実現を可能とする。 提案言語の詳細は、次節で述べる。 要件
(R1c)
、(R3b)
はセキュリティに関するもので あり、V
章で実現方法の詳細を述べる。 IV. 3 自然言語ベースの独自テキスト言語 表1
に、提案する言語で用いる記号を示す。前節 のシステム要件(R1b)
、(R2b)
、(R3a)
より、提案言 語には以下の機能を持たせ、自然言語風の文法 で簡潔かつ明瞭に指定できるようにする。 ・デバイスの操作、センサ値の取得 ・指定した条件成立時のアクションの設定 ・第3
者によるセンサデータの購読要求 ・ユーザ権限の変更 表2
に、提案言語のコマンド一覧を示す。UPnP
デバイス等、ホームネットワークに接続さ れたデバイスに最初から設定されているデバイス 名やコマンド名は、デバイスの型番など独特の識 別子であり、ユーザがそのまま利用するのに適さな 隔と統計値の種類が外部から指定でき、かつそれ に基づいて期間毎の統計値をホームネットワーク 内で集計し、結果だけを送る機能が必要となる。 また、送信したデータからユーザが特定されない よう、プライバシを保護する仕組みも同時に必要 となる。 IV.2 システム要件と基本方針 以上より、本ミドルウェアの要件は以下のように まとめることができる。R1
：(a)
ミドルウェアによる通信方式の異なるデバ イスへの統一されたインタフェースによるアクセス;
(b)
ユーザによる多種多様なデバイスの一つのイン タフェースによる操作; (c)
不正利用の防止と危険 なデバイス操作の制限R2
：(a)
デバイス情報の随時収集; (b)
イベント発 生条件とイベント発生時実行アクションの任意 設定R3
：(a)
デバイス情報の統計値の作成と第3
者へ の送信、送信間隔・統計値種別の任意設定; (b)
ユーザのプライバシ保護 これらの要件を満たす方針を以下に述べる。 要件(R1a)
、(R2a)
については、全てのデバイス で共通して利用する通信インタフェース(UPnP
な ど)
を定義し、各デバイスに対しそのインタフェー スを実装する形で独自通信方式を使ったコマンド の送受信を実現する。ネット未対応のデバイスに ついては、赤外線通信とホームネットワークのゲー トウェイを導入して、間接的な制御を実現する。こ れにより、各デバイスに対し、独自プロトコルによ るメッセージの送受信部分のみを実装するだけで 容易に新しい通信方式を追加することができる。 要件(R1b)
、(R2b)
、(R3a)
は、自然言語ベース の独自テキスト言語を用いて実現する。提案言語 は、デバイス本来の通信方式、コマンドを使った 記号 書式 意味 Room 部屋の名前 User ユーザ名 Device デバイス名DeviceID RoomのDevice デバイスの識別子
Sensor センサ名
SensorID DeviceID : Sensor センサの識別子
Command コマンド名 Role 権限 Term 条件文 TimeSpan 時間間隔 Security セキュリティオプション Function 統計関数 表1 独自言語で用いる記号
コマンドを実行できるようにした（例えば、リビン グのエアコン
ON=
エアコンON
とするなど）。 センサ値などのデバイス情報の購読は、値をそ のまま取得するものと、統計値を計算した上で返 すものの2
つの形式を用意した。いずれも、集合知 サービスに利用できるようにするため、位置情報と ともに送信される。統計値を計算するための関数 を容易に定義できるように、統計処理によく使用 する複数の関数（平均、最大、最小、分散、累積度 数など）を予め用意している。また、それぞれ、デー タの取得間隔（TimeSpan
）及びセキュリティオプ ション（Security
）が指定できる。セキュリティオプ ションでは、V
章で述べるように、位置情報やデバ イス情報の粒度などが指定できる。 IV. 4 コマンドの使用例 提案言語によるデバイス操作例を記述する。 a) 基本操作コマンド 想定環境において、寝室にある扇風機をON
に するには、以下のコマンドを送信する。 寝室の扇風機をON コマンドを送信すると、そのコマンドの実行の成 否が返される。このとき、権限の制限により管理 者の確認が必要な場合は、管理者へ確認を求め るメッセージが送信される。上記のコマンドをユー ザAlice
が送信し、かつそのコマンドの確認が必 要であった場合の、管理者へ送信されるメッセー ジ例は以下である。 Aliceが"寝室の扇風機をON"しようとしています。 よろしいですか？ このメッセージに対し、管理者は"
はい"
又は"
いい え"
を返信し、コマンドの実行を制御する。 センサの値を参照したい場合は、デバイスID
の末尾にセンサ名を付与する（デバイスの状態を 取得したい場合は、センサ名として"
状態"
を指定 い。提案言語では、部屋名やデバイス名、コマンド 名は自由に命名できるようにすることで、定型文な がら、ユーザにとってわかりやすい文となるように する。一方、部屋やデバイス、コマンドの名前を全 てユーザが記憶しておくことは難しいため、提案言 語には部屋の一覧、部屋にあるデバイスの一覧、 デバイスで実行できるコマンドの一覧、デバイス が持つセンサ一覧をそれぞれ参照できる機能を 設ける。また、コマンドの実行には部屋名とデバイ ス名、コマンド名を列挙する必要があり、ユーザが コマンドを手入力する際は、入力にかかる手間や 誤入力が問題となる。そのため、提案言語には別 名（エイリアス）を設定する機能を持たせ、簡単に 操作内容 コマンド 基 本 操 作 デバイスでコマンドを 実行 DeviceID を Command デバイスで実行できる コマンド一覧 DeviceID 覧 ? のコマンド一 指定された場所にある デバイス一覧 Room のデバイス一覧 ? 家にある場所の一覧 部屋一覧 ? 別名の設定 DeviceID を Command = Alias センサ値を取得 SensorID ? デバイスのセンサ一覧 DeviceID のセンサ一覧 ? 条 件 付 き 操 作 ・ デ ー タ の 購 読 条件成立時にコマンド を実行 Term のとき DeviceID を Command 条件成立時に通知 Term のとき通知 センサデータ情報の購 読要求 Sensor を TimeSpan毎に 要求 センサデータの統計 値購読要求 Function を TimeSpan 毎に要求 セ キ ュ リ テ ィ ユーザの権限を変更 User の権限を Role に 変更 ユーザにデバイス操作 を許可 User に DeviceID の操作 を許可 表2 コマンド一覧することによってプライバシが漏えいするのを防ぐ ことである。センサデータの値や、デバイスの使用 ログはそれ自体にプライバシ情報を含む場合があ る。また、一つ一つのデータだけでは問題ないが、 それらを組み合わせたり、収集することでプライバ シ情報を得られる可能性も考えられる。そのため、 これらのデータを外部へ送信する場合は、プライ バシを保護するための何らかの処理が必要となる。 （課題
3
）3
点目は、提案ミドルウェアはインターネッ トを介してメッセージをやり取りするため、メッセー ジの順番が前後したり、欠落することもあり、その ような場合でもシステム全体が正しく動作するよう ミドルウェアに耐障害性を持たせることが課題と なる。赤外線によるデバイスへのアクセスにおいて も、赤外線信号が正しく受信されないことによる不 具合発生の可能性があり、なんらかの対策が求め られる。 V. 2 課題解決に向けたアイデア 上述した課題の解決法について述べる。 a) デバイス操作に関する課題の解決 まず、デバイス操作におけるセキュリティ上の課 題（課題1
）を解決するために、提案ミドルウェアに ユーザ管理機能を導入する。ユーザの操作権限 の強さを数段階用意しておき、各コマンドには必 要な権限の下限を設定しておく。ユーザからのコ マンドを受け取った際にそのユーザの権限の強さ を調べ、コマンドの実行に必要な権限を満たして いる場合に限り操作を許可する。ユーザの認証は、 各通信媒体におけるユーザ名を利用する。例えば、 メールの場合メールアドレス、35
度以上になった時通知するよ う設定したい場合は次のコマンドを送信する。 寝室の温湿度計:温度>=35のとき通知 登録後、条件成立時に以下の通知が送信される。 寝室の温湿度計:温度>=35となりました (c) セキュリティコマンド ユーザAlice
にリビングのライトの操作を許可し たい場合は以下のコマンドを送信する。 Aliceにリビングのライトの操作を許可V
セキュリティ課題と
解決のアイデア
提案ミドルウェアは、ホームネットワークのデバ イスをオープンなインターネットに接続するため、 幾つかのセキュリティ上の課題を持つ。 V. 1 セキュリティ上の課題 （課題1
）1
点目は、IV.2
節の要件R1c
で挙げた、不 正利用の防止と危険なデバイス操作の抑制であ る。提案するミドルウェアはインターネットに接続 されるため、そのアドレスを知っているユーザであ れば誰でもアクセスし、操作コマンドを発行でき てしまう。また、提案ミドルウェアが実行する操作 は、時に危険を伴う可能性がある。例えば、親の関 知しない時に、子どもがストーブ等のデバイスを操 作してしまう場合や、自宅を留守にしている状況で、 自宅の鍵を解錠してしまう場合などである。このよ うな操作を未然に防ぐことは重要な課題である。 （課題2
）2
点目は、IV.2
節の要件R3b
で挙げた、集 合知サービスのためユーザがデバイス情報を提供れてしまう。このような事態を防ぐために、提案シ ステムでは位置情報に
k-
匿名化[7]
を施す。位置情 報の粒度を下げることで、該当する位置範囲にい るユーザがk
人以下にならないようにし、個人の特 定を防ぐ。しかし、提案システムの利用状況により、 位置情報の粒度を下げるだけでは対策にならない 場合も存在する。例えば、夜間における照明の使 用状況データを提供していた時に、粒度を下げた 位置情報の範囲内に、照明をつけている家が1
軒 のみであった場合はユーザおよびユーザ宅の特定 を許してしまう。このように、位置情報とデバイス 情報を同時に投稿する提案システムにおいては、 位置情報だけではなく提供するデバイス情報につ いても同時に考慮する必要がある。 提案手法では、デバイス情報（センサ値）の粒 度 を下げ（ 例えば、照度 を0
∼100lux
、100
∼200lux
、...
の範囲に分けるなど）、ユーザと同じ範 囲のセンサ値を投稿しているユーザが少なくともk
人いるように位置情報の粒度を調整する。この際、 センサ値の粒度と位置情報の粒度のどちらを優 先するかは、情報提供先が実現するサービスの種 類に応じて適切に決める必要がある。 ば、決まった時間帯だけデバイスの操作を許可す る等の柔軟なユーザ権限の設定が可能となる。 誤操作の問題については、操作の前に確認を 行うモデレート機能を提案ミドルウェアに組込む ことで、その低減を図る。ミドルウェアは、危険性 や誤操作の可能性のある命令を受信した時、それ を実行する前に、 ・他のユーザ（管理者）に確認を取る ・本人に最終確認を取る ことを行う。そして、確認がとれた時に限り、命令 を実行する。危険性や誤操作の可能性があるコマ ンドや条件については、確認メッセージの送付先 の指定も含めて、あらかじめミドルウェアに登録し ておくものとする。 メッセージの遅延や欠落などへの耐障害性の 問題については、一つのデバイスを一度に操作で きるユーザを一人に限定することで解決する。これ により、デバイス操作中に他のユーザからの干渉 を受けて予期せぬ操作結果を招くことを防ぐとと もに、送信するコマンドにユーザごとのシーケンス 番号を付与することで、順番の逆転やメッセージ の欠落を検出し、必要に応じて再送要求や並べ替 えなどの処理を行う。 赤外線によるデバイスの操作では、デバイス側 で赤外線信号が受信されず電源がオフであるに もかかわらず、システム側でデバイスの電源がオン になっていると認識されるケースが発生する。この 問題に対処するため、電力計を用いてデバイスの 状態を推定し誤動作を防ぐ。 b) データ提供に関する課題の解決 送信する情報の中で、最もセンシティブなプライ バシ情報は、位置情報である[20]
。例えば、位置 情報と消費電力値を併せて投稿しているとき、位 置情報が正確な値であれば、悪意あるユーザに家 の位置と、消費電力の値によって在宅状況を知ら 図1 ミドルウェアを含むシステムの全体構成VII
提案ミドルウェアの評価
本章では、提案ミドルウェアの汎用性および有 用性を示すための評価実験を行う。
VII. 1 実験内容
V
章で述べた提案ミドルウェアの実装を、ホームサーバである、
Windows 7
搭載PC
（Intel Core
i7 2600 3.40GHz
、12GB RAM
）で実行した。 データベースはOracle MySQL 5.5
を、開発環境 はJava SE 7 1.7.0 03
を使用した。Sun SPOT
通信プログラムや無線センサノード 通信プログラムも同一の実験サーバ上で動作させ た。ミドルウェアに接続されているデバイスおよび その配置は、図2
の通りである。 実験1
では、ミドルウェアの基本性能として、デ バイスを遠隔操作した時の応答時間を計測した。 なお、実験においては、不足しているデバイスを補 うため、ソフトウェアのみのUPnP
デバイスをサー バ上で実行した。 a) 実験1-1: 外部からのコマンド実行 本実験では、デバイス遠隔操作コマンドを送信 してから実際にコマンドが実行されるまでの時間 を測定する。(i)
コマンドが送信されてから、ミドル ウェアで受信されるまでの時間、(ii)
受信されてかVI
ミドルウェアの設計と実装
提案ミドルウェアを使用したシステムの全体構 成を図1
に示す。システムは、ホームネットワークに 接続されたネットワーク対応デバイスとホームサー バ、赤外線対応デバイス、無線センサノードから 構成される。本ミドルウェアは、ホームサーバで実 行される。ミドルウェアは、各デバイスからの情報 とユーザが選択した通信媒体（SNS
、電子メール） からの情報を随時取得・格納し、必要に応じて通 信媒体へのデバイス情報の投稿や、デバイスの操 作を行う。また、外部に設置されたアプリケーショ ンサーバが通信媒体を介して、公開された情報を 収集・蓄積し、様々なサービスに応用する。通信 媒体はSMS
、電子メール等様々なも のが考えられるが、本稿では代表的なSNS
の1
つ であるUPnP
を利用す る。また、UPnP
に対応していないデバイスについ ても、そのデバイスが使用する通信プロトコルとUPnP
のゲートウェイ機能を実装し、UPnP
を介し て通信を行う。 ホームネットワークに対応していないデバイス の制御を行うために、赤外線の送受信機能を有し たSun SPOT[21]
を家の各所に配置してUPnP
を介したデバイスの赤外線制御を行う。
Sun SPOT
のホストとデバイスは
IEEE802.15.4(ZigBee)
を 使用して通信しており、一つのホストに対して複数のデバイスが接続可能である。ホストとなる
PC
には
UPnP
を実装したSun SPOT
通信プログラムが 動作しており、UPnP
を介してSun SPOT
に任意のコマンドを送信できる。
種類である。以下で、それぞれに対応したシナリオ の詳細を述べる。 c) 実験2-1: 家電の遠隔操作 実験環境におけるデバイス群を
1
つの画面で同 時に操作が可能なリモコンアプリケーションを開 発する。ただし、全てのデバイス名及びコマンド名 は開発者に既知であり、新たなデバイス及びコマ ンドの追加は行わない。 d) 実験2-2: 見守り 実験環境の各部屋に設置されている温度セン サを使って、リビングの室温が異常に高温になっ た場合、火事などの異常が発生したとしてユーザ に通知を行う見守りアプリケーションを開発する。 e) 実験2-3: 消費電力データ収集 消費電力データを定期的に収集するアプリケー ションを開発 する。ここで、本ミドルウェアは#iotc
というハッ シュタグを付加しており、ユーザはハッシュタグ#iotc
を検索することで、任意のアカウントから発 せられた情報を取得できる。また、位置情報は要 求せず、1
時間毎の消費電力の平均値のみを取得 する。 VII. 2 評価結果と考察 a) 実験1: 基本性能に関する評価結果 インターネット経由でデバイスを操作するコマ ンドの実行を行った時（実験1-1
）の応答時間の平 均値を表3
に示す。 ら、コマンドが実行完了するまでの時間、の両方を 計測する。2
つの値の合計値がデバイス遠隔操作 の応答時間となる。デバイス数の増加による応答 時間への影響を調べるため、登録デバイス数を1
、10
、50
、100
と変化させ、それぞれ100
回コマンド を送信し計測した。 b) 実験1-2: 条件付きのコマンド実行 本実験では、条件成立時にデバイスを自動操 作する時の応答時間を確認するため、ホームネッ トワーク内のデバイスの状態（もしくはセンサの 値）が変化し、設定された条件を満たした時から、 コマンドが実行されるまでの時間を測定する。デ バイス数や条件数の増加による応答時間への影 響を調べるため、デバイス数と1
つのセンサに登録 する条件数を1
、10
、50
、100
と変化させ、それぞれ100
回ずつ計測する。条件は重複しないものと する。 実験2
として、いくつかの利用シナリオに基づい たアプリケーション開発を実際に行い、実装にか かった時間やソースコードの行数からミドルウェ アの評価を行う。アプリケーション開発実験は、 全て同じ環境、プログラミング言語、被験者で行 い、実装環境は、実験サーバと同一とし、プログラ ミング言語はJava
を使用する。被験者は、本実験 で利用するJava
言語について、簡単なGUI
アプリ ケーションが開発できる程度の知識を有しており、Java
の標準ライブラリだけでなく、インターネット 上に公開されているライブラリは自由に利用できる こととする。また、ソースコードの行数は操作・監 視を行う主要ロジック部分の行数のみを評価対 象とし、GUI
等実際の動作には影響の少ない部 分の行数は含めない。 アプリケーション開発実験に使用する利用シナ リオは、(i)
家電の遠隔操作、(ii)
見守り、(iii)
消費電力データ収集（集合知を利用するサービス）の
3
デバイ ス数 コマンド 受信まで コマンド実 行完了まで 合計 （合計）最大 1 407.85 495.50 903.35 1420 10 425.19 509.78 934.97 1692 50 418.40 513.49 931.89 1342 100 408.39 542.64 951.03 1413 表3 デバイス遠隔操作の応答時間（単位ms）かな増加が見られた。これは、ミドルウェアがデバ イスのセンサ値の変化を検出した際に、そのセン サに関連する全ての条件文を検査するためである。 しかしながら、実際の利用において、
1
つのセンサ に100
以上の条件が設定されることはほとんどな く、また、100
個の条件が1
つのセンサに関連付け られていても応答時間は6000ms
程度に抑えられ ていることから、実用上十分高速であると言える。 b) 実験2: アプリケーションの開発コストに関する 評価結果3
種類のアプリケーション実装時間とソースコー ドの行数を表5
に示す。 全てのアプリケーションにおいて、通信媒体であ るTwitter4J
8）を利用した。表5
の結果が示す ように、全てのシナリオにおいて実装に要した時 間は1
時間以内に収まり、また主要ロジック部の ソースコードの行数も最大で35
行という結果と なった。 また、実装に要した時間が一番長かった家電の 遠隔操作シナリオについても、要した時間のうち の大半はGUI
部分の実装の時間であり、実際の 操作を行う処理の実装にはあまり時間を要さな かった。その他の利用シナリオにおいても、主要ロ ジック部分の実装に要した時間は少ない。これは、 本実験で使用した通信媒体である1000ms
未満でコマンドの 受信に成功した。一方、コマンド実行完了までの 時間は、デバイス数の増加に伴い、緩やかに増加 する傾向が見られた。これは、デバイス数が増加 するとデータベースのレコード数も増加し、それに 伴いレコードの検索にかかる時間も増加したため である。以上から、遠隔からデバイスを操作した時 の応答時間の合計は、平均で930.75ms
、最大で も1692ms
となり、実用上十分高速に動作すること が分かった。 条件を設定し自動でコマンド実行を行う時（実 験1-2
）の応答時間の平均値を表4
に示す。 表4
に示すように、デバイス数の違いによる応答 時間の差異は337ms
以内に収まり、デバイス数の 影響は小さいことが分かる。一方、1
つのセンサに 対する条件数は、その増加に伴い応答時間の明ら 条件数 デバ イス数 1 10 50 100 最大 1 52.38 282.07 1331.64 3107.00 5462 10 41.69 262.04 1251.97 2771.57 4781 50 42.29 289.74 1290.43 2770.42 5312 100 38.40 299.80 1306.03 2773.28 4563 最大 287 876 2543 5462 5462 表4 条件設定時のデバイス操作の応答時間（単位ms） アプリケーション 種別 実装時間（分） ソースコード行数 家電遠隔操作 52 35 見守り 15 22 消費電力収集 20 24 表5 アプリケーション開発コスト 8）http://twitter4j.org/が滋賀大学経済学部在職時から現在に亘り多大 なご支援とご指導を賜り、本特集号への論文投 稿の機会を与えてくださった森將豪教授に感謝の 意を表します。 参考文献 [1] 清川皓太、山本眞也、柴田直樹、安本慶一、 伊藤実（2011）／3D 仮想空間を用いた情報家電のための リモコンフレームワーク、情報処理学会論文誌、 52 (2): 596-609。
[2] J. Mitsugi, S. Yonemura, H. Hada,
and T. Inaba(211) / Bridging UPnP and ZigBee with CoAP, Proc. of the workshop on
Internet of Things and Service Platforms (IoTSP '11), pp.1-, .
[3] K.-S. Kim, C. Park, and J. Lee(26) /
Internet Home Network Electrical Appliance Control on the Internet with the UPnP Expansion,
Proc. of Int' l. Conf. on Hybrid Information Technology 2006 (ICHIT '06), pp.62-63. [4] 新谷祐司、岡田康義、佐藤直（2009）／ ホームネットワークにおける 人間行動の機械学習に基づく異常検出、 信学技報. ISEC（情報セキュリティ）108 (473): 23-28。 [5] 石田和生、廣澤一輝、田村美保子、甲斐正義（2010）／ 家電の利用状況モニタリングによる 独居者安否見守りシステム(1) : 全体概要と基本コンセプト、 情報科学技術フォーラム講演論文集、9 (4): 539-540。 [6] G. Song, Y. Zhou, W. Zhang, and A. Song(2) / A multi-interface gateway architecture for home automation net-works, IEEE Trans. on Consumer Electronics, (3): pp.111-1113. [7] L. Sweeney(22) / k-anonymity:
a model for protecting privacy, Int' l. J. on Uncertainty, Fuzziness and Knowledge-based Systems,
1 (): -, .
[8] M.S.H. Khiyal, A. Khan, and E. Shehzadi(2) / SMS based wireless home appliance control system (HACS) for automating appliances and security, Issues in Informing Science and Information Technology, vol.6. ドを文字列として容易にコーディングできたためだ と考えられる。 以上の結果より、本ミドルウェアは多種多様な アプリケーションに利用できる汎用性、及び多種 多様なアプリケーションを少ないコストで実装でき る有用性を持つと言える。
VIII
おわりに
本稿では、家庭内デバイス群を高度に連携させ るスマートホーム向けサービスの開発促進を目指 し、多種多様なデバイスへの統合アクセスミドル ウェアを提案し、設計・実装および評価を行った。 本ミドルウェアでは、ホームネットワークで利用さ れる各種プロトコルとのゲートウェイ機能、デバイ スの操作やセンサ値の取得をSNS
や電子メール を介した独自テキスト言語に基づいた分かりやす いコマンドにより行う機能、家庭内デバイスの操 作を安全に行うためのセキュリティ機能などを実 現した。また、見守りや集合知を利用するサービス に対応できるよう、条件を設定しプッシュ型で情報 を取得する機能やデバイス情報をホームネットワー ク内で統計処理した後に取得する機能も実現 した。 提案ミドルウェアを実装し評価実験を行った結 果、応答時間は、最大でも6
秒程度となり、実用に 十分耐えうる応答性能を持つことが分かった。ま た、本ミドルウェアのAPI
を用いることで、少ない工 数で様々なアプリケーションを実現可能であるこ とを確認した。 【付記】 本研究の遂行にあたりご協力頂いた奈良先端 科学技術大学院大学情報科学研究科の大野淳 司氏（修了生）、玉井森彦助教に感謝します。著者[20] 中西健一、高汐一紀、徳田英幸（2005）／ 粒度の動的変更による位置匿名性についての考察、 情報処理学会論文誌、46 (9): 2260–2268。 [21] D. Simon and C. Cifuentes(2) /
The squawk virtual machine: JavaTMon the bare metal, Proc. of 20th annual ACM SIGPLAN Conf.
on Object-oriented Programming, Systems, Languages, and Applications (OOPSLA '05), pp.1-11.
[9] Z. Shelby, K. Hartke, C. Bormann, and B. Frank: Constrained application protocol (coap) draft-ietf-core-coap-13.
https://datatracker.ietf.org/doc/draft-ietf-core-coap/. [10] Panasonic: Panasonic aiseg.
http://sumai.panasonic.jp/hems/aiseg/. [11] 井上理（2012）／ スマホでエアコン操作 パナソニック断念の不可思議／ 日本経済新聞。 http://www.nikkei.com/article/ DGXBZO46180800V10C12A9000000/. [12] A. Kamilaris and A. Pitsillides(21)/ Social networking of the smart home,
2010 IEEE 21st Int' l. Symp. on Personal Indoor and Mobile Radio Communications (PIMRC), pp.2632-263.
[13] T. Yonezawa and H. Tokuda: Twitthings: sharing, discovering and defining things' happening using wire-less sensor networks, Proc. of Int' l. Conf. on Internet of Things 2010, pp.21-23, 21.
[14] M. Demirbas, M.A. Bayir, C.G. Akcora, Y.S. Yilmaz, and H. Ferhatosmanoglu(21) / Crowd-sourced sensing and collaboration using twitter,
Proc. of 2010 IEEE Int' l. Symp.
on World of Wireless Mobile and Multimedia Networks (WoWMoM 2010), pp.1-.
[15] covia: WiFi body scale.
http://www.covia.net/main/product-bodyscale.html. [16] 内閣府（2011）／平成23 年版 高齢社会白書。 http://www8.cao.go.jp/kourei/whitepaper/w-2011/
zenbun/23pdf_index.html.
[17] Y. Kashimoto, K. Ogura, S. Yamamoto, K. Yasumoto, and M. Ito(213) /
Saving Energy in Smart Homes with Minimal Comfort Level Reduction, Workshop Proc.
of IEEE Int' l. Conf. on Pervasive Computing and Communications (PerCom 2013), pp. 32-36. [18] 株式会社エネゲート、Smart ecowatt.
http://www.enegate.co.jp/smarteco_portal/. [19] 埼広エンジニヤリング株式会社、
省エネルギー監視機器ps03。
