ハードウェアのエラーハンドリング、どうやってる？　4社のエンジニアが語る、IoTサービスづくりの工夫

タクシー車載機は長時間稼働を前提にバッテリーレスに

須田桂伍氏（以下、須田）：株式会社ソラコムのSAをやっております。須田と申します。

私はSAをやっているんですが、プロフェッショナルサービスというかたちで実際にお客様の案件に入って一緒にモノを作ったりコードを書いたりしているので、その辺の経験を踏まえて何かお話できたらなと思います。

僕は社会インフラ系をやっていて、例えば某ガス事業会社さんで改善したりとか、あとは普通に生きていれば出会うことはないと思いますが、石油プラントって爆発しちゃうので火気厳禁じゃないですか。そういうところで使うようなデバイスをどう作ったらいいか、ということを一緒にやったりしています。こんな感じです。

司会者：ありがとうございます。それではSli.doに来ていた質問を私の手元でいくつか集計をして質問をまわしていきたいなと思っています。

では最初に、JapanTaxiさんに来ていた質問からいきたいと思います。「機器選定をどういう基準でやられていたのか。その上での問題や課題にはどんなものがあったのか」。そういった話を聞かせていただければと思います。

大林直樹氏（以下、大林）：機器選定については前後のタブレットがあって、まず後部座席に付いているタブレットは自社開発のタブレットになっています。

やはり車載器なので、夏場にはすごく高温になります。タクシーの1乗務、1営業というのは20時間になるので、かなり長時間動かす必要があるので、後部座席に関しては自社で設計していてバッテリーレスになっています。

実はあのタブレットはエンジンと連動していて、エンジンが付くと後ろのタブレットが付きます。そしてエンジンがオフになってから10分経過すると自動的にシャットダウンするようなタブレットになっています。前のタブレットに関しては現在は既製品を使っています。ただ、後部座席と同じようにバッテリーレスであったり、長時間に耐えるようなタブレットに変更していきたいと考えております。以上です。

どんなプロトコルを使うかも大切

司会者：ありがとうございます。機器選定という観点については、せっかくなので他の会社さんにも聞いてみたいと思います。600さんいかがでしょうか。

岡前直由氏（以下、岡前）：そうですね。機器選定はすごく難しい問題で、弊社では冷蔵ショーケース本体やAndroidタブレットなど、いろいろ変数が多いんですが、現状はそれほど洗練できてないというのが実状です。

最初は弊社の取締役が1人で立ち上げたプロトタイプがあって、そこから現状のインクリメンタルに改善をしている中で、出てきた課題に対応できるような機器を選んで少しずつ改善しているという感じになります。

例えばこれは今年の夏ぐらいに出た筐体で、当初の問題は解決できたんですが新しい問題、例えば結露しやすいとか、サイズが大きすぎてお客さんによっては設置できないとか、そういう問題も起きています。それをまた次のバージョンで改善していく。そして過去の境遇教訓も蓄積していく、というかたちになります。

司会者：ありがとうございます。ちなみにソラコムさんは、いろんな会社さんから「こういうところは……」みたいな相談を受けたりすることもあるのかなと思ったんですけど、その辺り何かございますでしょうか？

須田：そうですね。もちろんやりたいことがぜんぜん違うんですけど、見落としがちなのってたぶん「筐体を既存のデバイスを使ってやります」というときに、どんなプロトコルを使うかけっこう見落としがちで。とくにバッテリーで駆動するときって、HTTPみたいな高級なプロトコルを使うとハンドシェイクだけでバッテリーの消費がバカにならなくて、そういうときって生のUDPを使いたかったりするんですけど、意外と全部が全部そういうプロトコルが喋れるわけではないので、そういうところもポイントになるかなと思っています。

エラーハンドリング、どう工夫する？

司会者：ありがとうございます。次の質問に行きたいと思います。これはクックパッドマートに来ていた質問なんですが、「デバイス固有のエラーハンドリングの観点、なかなか狭い話ではありますが、たとえばインク切れとかそういう問題に対してどういう対応をしているのか」というところで、もしあれば。

今井晨介 氏（以下、今井）：あのプリンタはサーマルプリンタなのでインクはありません。熱を加えてラベルを黒くするかたちになっています。デバイス固有の問題としては、プリンタだと最後に印刷しきれなかったみたいなことが発生したりするので、そのプリンタが印刷できたかどうかを検知する仕組みがあります。

内部で印刷できたらとある数字をインクリメントする、みたいなのはあるんですけど、それがちゃんとインクリメントされているかを印刷をしている最中に問い合わせて、インクリメントされたら「印刷終わったね。成功したね」というので成功。

もしそれが上がらなかったら失敗したからもう1回印刷をリトライするであったり、アラートをあげるとか再起動を促すとかそういったことをしていますね。

司会者：ありがとうございます。この話も他社さんとで共通した話になりそうかなと思うんですけど、例えばポケットチェンジさんでもデバイス固有の問題で何か似たような話があるかなと思うんですけど。

青山新 氏（以下、青山）：デバイスのところではccTalkという規格がありまして、コインを自販機の中で扱うプロトコルですね。

すごい古いプロトコルなんですが、だいたいそれが網羅していてグルグル回るような機械なので、それをちょっと拡張しているんですけど、そういった部分を実装するというか、そうですね。

ccTalkのプロトコルのパーサーとかもGitHubにあるんですが、だいたい動いていないので、自分で書く感じになると思います。それは本当に難しくはないのでできると思います。

クレジットカード情報を抜き出されないための工夫

司会者：ありがとうございます。それではまた次の質問にいきたいと思います。これは全部の会社さんにぜひ聞いてみたいなと思うんですけど、セキュリティ系の問題が絶対に出てくるかなと思います。「セキュリティについてどういう取り組みをしているか、どういったことに気を付けているかなど、そういったことを聞かせていただければと思います。ではJapanTaxiさんから。

質問であったのは「クレジットカードの情報をBluetoothで送信するのって、なんか中身が見られるんじゃないか」とか。

大林：なるほど。そういった点で言うと、決済に関しては完全に他社製品を使わせていただいて、かつ、BluetoothではなくUSBでサイネージ側のタブレットとつながっているので、そこで漏洩するということはありません。

ただ、メーターの情報はBluetoothで飛ばしているので、暗号化しなければ解読されてしまう。そこに関しては暗号化していて、簡単には見れないはずです。私はそこの専門ではないので聞いた話にはなるんですけど、そういうところに関しては気を付けています。

司会者：ありがとうございます。続いて600さんお願いします。

岡前：そうですね。弊社もクレジット情報の扱いが一番キモになると思うんですけど、そんなに考えることは難しくなくて、カード情報が平文で無線に流れなきゃいいということで、実はタブレットと上の基盤、クレジットカードリーダーは実は上のボックスの中にRaspberry Piが入っているんですけど、Raspberry Piまでは物理的な通信でいきます。

そこから無線を通ってタブレットにいくんですが、あまり喋らないほうがいいのかな。ちょっと不安になってきた。

（会場笑）

その無線はすごく気を遣って暗号化しています。Wi-Fiはそもそも暗号化されていますし、Wi-Fiの上で利用しているプロトコルもSSL overのプロトコルを使って暗号化しています。以上です。

クックパッドマートにおける課題

司会者：ありがとうございます。では次、クックパッドマートについて。

今井：一応、そのサーバから端末への通信はSSLで通信しているんですけど、一番たぶん気になるところは、先ほど開けて商品を取ったと思うんですけど、他の人の商品を取れてしまうという問題があるんですね。これは僕たちは全然解決ができていなくて、今のところはすごく悪意を持ったユーザさんがいて、いっぱい商品を取っていくといったことはまだ起こってはいませんが、将来的にはそういうことも発生し得るだろうなと思っています。

ちゃんと防犯カメラを置いたり、中の箱自体をロックする。そういったことをいろいろ考えているんですが、まだこの方針で移行は決まっていません

司会者：ありがとうございます。では、ポケットチェンジさん、よろしくお願いします。

青山：最初に出しました緑のチャージ機ですね。両替機、交換機のほうはカードなんかの部分については他社のモジュールを使っていまして、それが直接コネクションに入っています。傾いたりドアがちょっとでも開いたりすると停止して何も起こらなくなる機能が入っていまして、昔はイライラして蹴られたりすると動作が止まるみたいな状態だったんですけど。

（会場笑）

今は改善して、通信についてはクライアント証明書を一つひとつの端末に配っていて、SORACOMのコネクションが来たときにもその端末の証明書でなければ受け付けない状態にしています。

あの小さいデバイスも紹介したと思いますが、あれもBLEを使っているのでけっこう気を遣っています。QRコードやタッチしたときに得る情報で暗号化を掛けて、そのコネクションじゃないと受け付けないとかですね。そういったことをやっています。

司会者：ありがとうございます。それ以外で、ソラコムさんへのサービスの観点から何か。この辺を気を付けてサービスの開発を進めているということが、もし何かございましたら。

須田：IoTという文脈で、以前ならマイコンとかいろいろ出ていたと思うんですけど、最近はRaspberry Piとかそういうものを使っていたりすると、けっこうダイレクトにRaspberry PiからAWSのサービスを呼びたい、使いたいというのがけっこう多いんですね。

そうなると最初に認証キーなどをデバイスに配っていってしまうということもけっこうあるんですが、あれも考えもので「デバイスごとに認証鍵を作っていたらその鍵はどうするんだっけ？」とか、「じゃあ1個の鍵をみんなで使いまわせばいいじゃん」というのもあるんですけど、それが漏れてしまうとみんなの認証鍵がわかってしまうので、極力デバイス側にシークレット情報を持たせない。

やっぱり確かにソラコムのサービスを使うとその辺はいろいろカバーはできるんですけど、まず第一になんでデバイス側にもたせるのがまずいのか、というところは最初に説明したりしています。

司会者：ありがとうございました。まだまだ質問したいんですけど、そろそろお腹のほうも空いてきた頃かなと思いますので、一旦ディスカッションはここで締めさせていただければと思います。ただ、登壇者の方は今日はずっと残っていらっしゃると思うので今そちらにご飯の用意をさせていただいております。ご飯を食べながらみなさん自由にご歓談いただきながら登壇者の方に聞けなかった質問をしていただければと思います。

ここでディスカッションを終わりたいと思います。みなさんどうもありがとうございました。

（会場拍手）