SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2016】セッションレポート(AD)

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

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

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をサポートしていくので、ぜひ一緒にチャレンジしてほしい」と会場に呼びかけた。

お問い合わせ

 ヤフー株式会社

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
【デブサミ2016】セッションレポート連載記事一覧

もっと読む

この記事の著者

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

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

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9306 2016/03/28 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング