Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。API、IoTなどの領域で活動しているという。そんな倉林氏が認識するmyThingsの課題とは多岐にわたる。そもそもプロトタイプはあくまで製品を量産する前に機能や性能を検証するための試作品であり、使用者は開発者・テストユーザーに限られる。量産型プロダクトではあくまで製品であり、使用者はエンドユーザーになるので、想定外の使い方をされたり、不具合が生じてもプログラムを更新できなかったりする可能性が高い。プログラムの更新、APIの組み合わせによる安全性などの検証を怠ると致命的な問題を引き起こす可能性がある」と指摘する。考慮すべきポイントとして筆頭にあげられるのが「認証」だが、デバイスが設置される場所や利用環境の違いで認証方法は変わってくる。利用可能なプロトコル方式も重要事項だ。HTTPSや署名に対応するかといったこと、Bluetoothなどのペアリングをするなら母艦となるアプリが必要となることなどだ。ディスプレイの有無、さらにはリッチUIの有無でも変わってくる。FlowやQRコード、バーコードによるアクティベートを使う方法もある。した認証には、サービスの利用者を認証する「ユーザー認証」と、IoTデバイス自体を認証するという「デバイス認証」がある。エンジニアが気になるのはどんなプロトコルが使えるかだろう。最近よく耳にするMQTT、CoAP(DTLS)などは通信プロトコルであり、ユーザーやデバイスの認証方法は含まれていない。扱うためにはユーザーを認証する必要がある。「デバイス認証」については、ゲートウェイやルーターの経由やSIMを利用するものもあり、それらの認証も考慮が必要となる。ConnectといったID連携の仕組みを提供している。その強みを活かしたユーザーとデバイスの連携方法として、OAuthを利用してユーザーのアクセストークン(クレデンシャル)をデバイスに埋め込むというのも考えられる。埋め込まずにデバイスはサーバー側で認証を行うという方法もある。ユーザーとデバイスの連携方法また、myThingsでは、ユーザーIDとは別にモノを管理するためのIDについても、検討を行っているという。ユーザーとモノが一対一であるとき、たとえば携帯電話とユーザーのような関係の場合、ユーザーと特定できればモノのIDはなくてもよい。なればそういうわけにはいかない。そこで、モノのIDを併せて管理する必要が生じるというわけだ。APIを利用した場合のアクセストークンの無効化も必要になってくる。「データの保存と取り扱い」についてだが、デバイスからサーバーへの送信は、サーバーに保存するセンシングデータがセキュアな情報であるかどうか、どんな種類なのかの判断がポイントとなる。逆もまたしかりで、サーバーからデバイスへの送信においても、アクセストークンと属性情報に関して漏洩時のリスクを想定する必要がある。セキュア領域に保存するか、または保存せずに利用することも考えなければならない。続いて倉林氏は、運用開始後の課題について言及し、一つ目として、デバイスのアプリケーション・OSのアップデートの課題について紹介した。OSが搭載され、インターネットにつながっていれば、大抵アップデート機能の利用が可能だ。プログラムの更新が難しいデバイスの場合、バグの修正や脆弱性の対応が難しく、接続するAPIの仕様変更やAPIの停止すらも難しくなる。そこで、十分な検証やデバイスに乗せる機能を制限する等の考慮が必要というわけだ。次に考慮すべき課題としては「APIサーバーのスケーラビリティ」がある。センシングデータやサービスの特徴によっては、APIサーバーのスケールを十分考慮しなくてはならないという。気温データの取得は一時間に一回で構わないかもしれないが、GPS情報は毎分・毎秒など頻繁になれば、大量のデータとなりうるからだ。倉林氏は3つめの課題として「API設計」をあげる。myThingsでは、条件をとりだす部分を「トリガー」、実際にプログラムを実行するのを「アクション」と呼んでいる。様々なセンサーモジュールをトリガーにして、SNSに書き込みを行ったり、データを保存したり、アプリに通知したりすることができる。現時点でもたくさんのデバイスやアクションを行うチャネルがmyThingsには用意されているが、今後新しく追加される際には、トリガーとアクションがどの組み合わせであっても安全である必要がある。ヤフーだけでもショッピングや決済などのWebサービスを持っており、APIが組み合わさった際に起こり得る事象を検討し、設計時にAPI側で制御可能な手段の考慮が必要だ。最後に、「現状、試作から量産に向けては、技術的にもハードルはたくさん存在している。数年前までは試作自体にハードルがあり、そこにチャレンジして打破したからこそ、今の課題がある。その繰り返しの途上にいると認識している。今後もmyThingsを通じてIoTをサポートしていくので、ぜひ一緒にチャレンジしてほしい」と会場に呼びかけた。非エンジニアの窓口担当者がChatOpsで検証環...もっと読むこの記事の著者CodeZine編集部(コードジンヘンシュウブ)CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。