CodeZine(コードジン)

特集ページ一覧

【デブサミ2016】18-A-3レポート
IoTは量産こそが難しい――myThingsをつくって感じたIoTの可能性と課題

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2016/03/28 14:00

 ヤフーは2015年7月、「すべてをつなげる」というコンセプトのもと、IoTプラットフォーム「myThings」をリリースした。「すべて」の中には、Webはもちろん、企業や人、街、データ、そして昨今すさまじい勢いで進化しているIoTデバイスをも含み、IoTサービス同士を連携させて新しい価値を生み出すことが目的だという。本セッションでは、myThingsを設計・開発・運用する中で見えてきたIoTの未来、可能性、そして課題と解決に向けた取り組みについて、同社スマートデバイス推進本部 大阪開発室の山本学氏、そして決済金融カンパニー開発本部の倉林雅氏が語った。

ヤフー スマートデバイス推進本部 大阪開発室 山本学氏
ヤフー スマートデバイス推進本部 大阪開発室 山本学氏
ヤフー 決済金融カンパニー開発本部 倉林雅氏
ヤフー 決済金融カンパニー開発本部 倉林雅氏

IoTサービス同士を連携させて新しい価値を生み出すmyThings

 もはや説明不要なキーワードになりつつあるIoT。IoTは、スマートファクトリーやインダストリー4.0などビジネス向け(工業系IoT)と、スマートトイやスマートハウスなど消費者向け(商業系IoT)の大きく2つに分けられる。2015年7月に「すべてをつなげる」をコンセプトにローンチしたmyThingsは、商業系IoTを対象にしたプラットフォームだ。まずはIoTとWebにフォーカスした「myThingsアプリ」を同日に発表している。

myThings
myThings

 myThingsの開発を担当してきた山本氏は「昨今急速にIoTへの関心が高まり、デブサミでもクラウドに次ぐキーワードとなっている」と語り、現状況を “群雄割拠”と評する。さらに「課題に対する解決、そして新たな課題が見つかって解決というブレイクスルーの繰り返しによってIoTサービスは複雑化しているのではないか」と分析する。

 そんな状況下で登場したmyThingsのIoT領域における立ち位置を説明するにあたり、山本氏は「レイヤー」「マーケット」「フェーズ」の3つのキーワードを掲げた。まず気になるのは、「myThingsがIoTのどこのレイヤーを担うのか」ということだろう。IoTは各種センサーやアクチュエーター、プロセッサー、ネットワーク、そしてクラウドというレイヤーに分かれている。一方、myThingsは これらレイヤーの連携の上に成り立っているIoTサービス同士を連携させる役割を担っているという。myThingsは「あるIoTサービス自体をセンシングして、その状態に応じて、別のあるIoTサービスを操作する」という連携を実現させるわけだ。

 山本氏は「IoTは、モノがインターネットにつながるだけではなく、人やモノの状況を理解して、その人やモノ、もしくは他の何かとつながり連携し“コト”をなすことが大事」と語る。そのつながりを連携する部分をサポートするのがmyThingsなのだ。

 続いて、myThingsが狙う「マーケット」について。myThingsは、既に述べたように商業系IoT向けのプラットフォームであるため、ウェアラブル端末など、商業系のIoTデバイスとの連携を可能にしている。myThingsの現在の対応サービスは41チャンネル、うちIoTが10、Webサービスが30程度だ(2016年2月18日時点)。これらの対応サービスにより、たとえば「ウェアラブルガジェット『Jawbone』で睡眠を検知したらネットワーク接続型の高機能学習リモコン『iRemocon』でスイッチを切る」という連携も可能になる。

 「睡眠検知という情報自体がリモコンを操作することはできないし、エアコンも持ち主が寝たのに気づかない。myThingsを間に入れることで、両者が連携して一つの課題解決を実現する」(山本)というわけだ。

 続いて「フェーズ」だが、一般に製造者が何かのサービスを消費者に提供する際、大きくは「試作」と「量産」の2つのフェーズを経ることになる。myThingsが担うのは、試作のところのみ。加えて、想起者の手に渡ってからの「ユーザー体験」を提供する。たとえば、IDCFクラウドと連携させると自作のガジェットやサービスもmyThingsと連携可能になる。ここでは、Googleカレンダーと自作の鳩時計の連携の例が紹介された。

IoTは現実世界の課題を解決できるか、限界集落で確かめた

 それでは、そもそもヤフーがIoTにチャレンジするのはなぜなのか。その質問に対し、山本氏は「現実世界の課題をより自然な形で解決したいから」と答える。これまでヤフーはインターネットを通じて、パソコンやスマホを使った様々な課題解決を行ってきた。しかし、それ以外のものがインターネットにつながる時代が到来しようとしており、パソコンやスマホを使った課題解決をもっと自然な形で手間なく実現できないか、パソコンやスマホではできなかった課題解決をIoTで解決できるのではないか、そんな思いに至ったという。

 それでは、はたして本当にIoTは現実世界の課題を解決できるのか。その問いに対して、山本氏は実際に行ってきたフィールドワークの例を紹介した。岐阜県の限界集落にデバイスとmyThingsを持ち込み、課題解決にチャレンジしてきたという。

 「獣害を防ぐためのシステムだったり、ライフラインとなっている湧き水の定期監視だったり。IoTとmyThingsで生活課題をすべて解決できる……、とまでは言えないが、『糸口を発見できた』という実感を得ることができた」と山本氏は語り、「今後はもっとこうした過疎地域が増えることを鑑みると、先んじて対応することで、地域の課題解決にも貢献できる。また、IoTのハードルを下げたことで、myThingsを使った課題解決の仕組みが自然発生的に登場してくるのではないか」と期待を覗かせる。

 ただし、こうした課題解決を一般化する上で顕在化している課題は「量産」部分だという。つまり、何か試作を作り、その効果が得られたとしても、それをビジネスとして展開するには量産が不可欠となる。電子工作で終わってしまったという例は枚挙に暇がない。製造はもちろん、品質管理や在庫管理、ユーザーの区別やマスキングなどもあるだろう。試作段階では見えなかった問題が、量産を考えると次々に出てくるというわけだ。しかし、山本氏は「そうした課題に対しても、myThingsとして何かソリューションを提供したいと考えている。ぜひ、今後のmyThingsに期待してほしい」と語り、セッションを倉林氏へ引き継いだ。

IoTの課題はユーザーとデバイスに関する「認証」

 続いて登壇した倉林氏は、ID連携“黒帯”としてWeb、ネイティブアプリ、Web API、IoTなどの領域で活動しているという。そんな倉林氏が認識するmyThingsの課題とは多岐にわたる。

 そもそもプロトタイプはあくまで製品を量産する前に機能や性能を検証するための試作品であり、使用者は開発者・テストユーザーに限られる。一方、量産型プロダクトではあくまで製品であり、使用者はエンドユーザーになるので、想定外の使い方をされたり、不具合が生じてもプログラムを更新できなかったりする可能性が高い。

 倉林氏は「プロトタイプで認証機能やデータの保存・管理、運用開始後のプログラムの更新、APIの組み合わせによる安全性などの検証を怠ると致命的な問題を引き起こす可能性がある」と指摘する。

 考慮すべきポイントとして筆頭にあげられるのが「認証」だが、デバイスが設置される場所や利用環境の違いで認証方法は変わってくる。利用可能なプロトコル方式も重要事項だ。たとえば、HTTPSや署名に対応するかといったこと、Bluetoothなどのペアリングをするなら母艦となるアプリが必要となることなどだ。また、ディスプレイの有無、さらにはリッチUIの有無でも変わってくる。リッチUIがあれば、PCのように認証窓を設置して対応ができるが、ない場合はスマホなどによるDevice FlowやQRコード、バーコードによるアクティベートを使う方法もある。

 こうした認証には、サービスの利用者を認証する「ユーザー認証」と、IoTデバイス自体を認証するという「デバイス認証」がある。まず、エンジニアが気になるのはどんなプロトコルが使えるかだろう。最近よく耳にするMQTT、CoAP(DTLS)などは通信プロトコルであり、ユーザーやデバイスの認証方法は含まれていない。なので、IoT を扱うためにはユーザーを認証する必要がある。また「デバイス認証」については、ゲートウェイやルーターの経由やSIMを利用するものもあり、それらの認証も考慮が必要となる。

 なお、ヤフーではPCやアプリで認証するためのOAuthやOpenID ConnectといったID連携の仕組みを提供している。その強みを活かしたユーザーとデバイスの連携方法として、OAuthを利用してユーザーのアクセストークン(クレデンシャル)をデバイスに埋め込むというのも考えられる。一方、埋め込まずにデバイスはサーバー側で認証を行うという方法もある。

ユーザーとデバイスの連携方法
ユーザーとデバイスの連携方法

 また、myThingsでは、ユーザーIDとは別にモノを管理するためのIDについても、検討を行っているという。ユーザーとモノが一対一であるとき、たとえば携帯電話とユーザーのような関係の場合、ユーザーと特定できればモノのIDはなくてもよい。しかし、ユーザーとモノが「一対多」「多対多」となればそういうわけにはいかない。そこで、モノのIDを併せて管理する必要が生じるというわけだ。さらに認証した後に、デバイスの解除や再認証、Web APIを利用した場合のアクセストークンの無効化も必要になってくる。

 そして、「データの保存と取り扱い」についてだが、デバイスからサーバーへの送信は、サーバーに保存するセンシングデータがセキュアな情報であるかどうか、どんな種類なのかの判断がポイントとなる。逆もまたしかりで、サーバーからデバイスへの送信においても、アクセストークンと属性情報に関して漏洩時のリスクを想定する必要がある。セキュア領域に保存するか、または保存せずに利用することも考えなければならない。

OSアップデートや拡張性、セキュリティなどは設計時から考慮

 続いて倉林氏は、運用開始後の課題について言及し、一つ目として、デバイスのアプリケーション・OSのアップデートの課題について紹介した。OSが搭載され、インターネットにつながっていれば、大抵アップデート機能の利用が可能だ。しかし、プログラムの更新が難しいデバイスの場合、バグの修正や脆弱性の対応が難しく、接続するAPIの仕様変更やAPIの停止すらも難しくなる。そこで、十分な検証やデバイスに乗せる機能を制限する等の考慮が必要というわけだ。

 また、次に考慮すべき課題としては「APIサーバーのスケーラビリティ」がある。センシングデータやサービスの特徴によっては、APIサーバーのスケールを十分考慮しなくてはならないという。たとえば、気温データの取得は一時間に一回で構わないかもしれないが、GPS情報は毎分・毎秒など頻繁になれば、大量のデータとなりうるからだ。

 そして倉林氏は3つめの課題として「API設計」をあげる。myThingsでは、条件をとりだす部分を「トリガー」、実際にプログラムを実行するのを「アクション」と呼んでいる。様々なセンサーモジュールをトリガーにして、SNSに書き込みを行ったり、データを保存したり、アプリに通知したりすることができる。

API設計
API設計

 現時点でもたくさんのデバイスやアクションを行うチャネルがmyThingsには用意されているが、今後新しく追加される際には、トリガーとアクションがどの組み合わせであっても安全である必要がある。特にヤフーだけでもショッピングや決済などのWebサービスを持っており、APIが組み合わさった際に起こり得る事象を検討し、設計時にAPI側で制御可能な手段の考慮が必要だ。

 最後に、「現状、試作から量産に向けては、技術的にもハードルはたくさん存在している。しかし、数年前までは試作自体にハードルがあり、そこにチャレンジして打破したからこそ、今の課題がある。その繰り返しの途上にいると認識している。今後もmyThingsを通じてIoTをサポートしていくので、ぜひ一緒にチャレンジしてほしい」と会場に呼びかけた。

お問い合わせ

 ヤフー株式会社

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5