Yahoo! Groupsというメーリングリストサービスを立ち上げ、Google Searchしかない頃のGoogleに入社、Google Mapの日本版を作り、芸能人やメディア向けのTwitterサービスを立ち上げるなど、今でこそ当たり前に使っているインターネットサービスを開発してきたというMODE, Inc. Co-Founder兼CEOの上田氏。
シリコンバレーを本拠地としてIoTプラットフォームを作ってきたというが、このたび東京オフィスを開業することとなったという。
そこで、シリコンバレーのエンジニアが作るIoTプラットフォームとはどういうものなのか、そして、技術を使うことでどういうことまでできるのか、についてMODE, Inc. Co-Founder兼CEO 上田学氏、同社 日本のカントリーマネージャーの上野聡志氏に伺った。（聞き手、IoTNEWS代表 小泉耕二）
－御社について教えてください。
上田： 私は2001年にシリコンバレーに行ったのですが、当初Yahoo! Groupsというメーリングリストサービスを作っていて、次のGoogleでは私は日本人で二人目のエンジニアでした。
当時はGoogle Searchしかなかった時代で、かなり早い段階でGoogleマップをつくるチームに入ってチームを大きくし、東京でもエンジニアを雇いGoogleマップを日本で強くしていきました。
その後Twitterに行き、エンジニアリングディレクターをやっていたのですが、芸能人やメディア向けの機能を作るチームを立ち上げ、サンフランシスコとロンドンチームのマネジメントをやっていました。
その後、スタートアップを立ち上げてみようと思い、色々なアイデアを試したのですがなかなかうまく行かず、気分転換に「違うことやろう」と思って、やり始めたのがIoTです。
実は、起業した当初は、スマートスプリンクラーの会社を作ろうと思っていました。
アメリカの庭は広いのでスプリンクラー水をまくのですが、コントローラーがガレージにあるので、それを操作しに行くのが大変でした。だから、アプリでピッと押したら水が出るというモノを作ってみたら結構うまく動いたのです。
それで、「これみんな欲しいんじゃないかな？」と思って、昔からの友人で今の共同創設者のEthanにアイディアを話したら、「お、いいね！」と。彼は今まで、僕がスタートアップのアイディアをいくら話しても乗ってこなかったのですが、たぶん10年目にして初めて「いいね！」と言ってくれたのです。
それで一緒にやることになっていたのですが、実際に作ってみると、競合がもう10社くらいある一方で、僕らはハードウェアもまだないし、2年遅れくらいといった感じだったので、スプリンクラーは諦めました。
－それはいつごろですか？
上田： 2014年の頭くらいですね。その後、ホームセキュリティシステムを作ってました。そこで気づいたことが、「実はスマートプロダクトの楽しいところというのはほんの一部で、そこに至るまでの地道な作業が大量にある」ということでした。
「この地道な（デバイスとクラウドをつなぐ）作業をみんながやるのは無駄じゃないか？じゃあプラットフォームにして出せばいいんじゃないか？」と思い、IoTプラットフォームを提供する会社をつくったのです。
現在では「あらゆるセンサーをつなぐ」ことをビジョンにしております。
私は、IoTって実はセンサーなしでは語れないのに、センサーをつないでシステム作ることがあまりに難しいので、なかなか進んでないんじゃないかと感じています。
そこで、そのハードルをグッと下げたいと思っております。世界中のあらゆるセンサーをつないで、そのデータをビジネスに活用できる、ということをMODE社が可能にします。
－なるほど、今はどうしているのでしょうか？
上田： 最初はIoTガジェットのバックエンドもやろうとしていたのですが、ビジネス的にすごく厳しい分野だったので、コンシューマー用途ではなく業務用途に特化したIoTプラットフォームとしました。
弊社のソリューションでは、どの会社のセンサーでも、データを取ることができます。クラウド側もシステムを1から作らなくても、ある程度センサーのデータを扱うというパターンは決まっているので、その部分までは弊社で全て用意して、「データを見るだけ、監視するだけ」だったらカスタム開発ゼロでできています。ここまでできたことで、いろいろな企業のユーザー様に使っていただけるようになりました。
ここまでが2014年に創業してから今に至る3年間で、一言で言うとIoTプラットフォームからセンサーソリューションに進化しました。
－今対応しているセンサー一覧などはありますか？
上田： 一覧表はありませんが、すでにサポートしているセンサー以外についても、1週間くらいあればつないでご提供できるようになっています。さらに通信機能のないアナログのセンサーをつなげるソリューションも用意していますので、通信機能のないセンサーでも通信が可能です。
－センサーと言ってもいろんなメーカーや、いろんな種類のものが数多くあります。しかも単位が違うので、そういう差分をきちんと吸収しなきゃいけないと思うのですが、そういうところはクラウド上で変換されているのでしょうか。
上田： いえ、ゲートウェイでやっています。このゲートウェイのソフトウェアも自社で開発しているというところが強みです。センサーの値っていろんな意味がありますが、何を測っているのか、どういう単位なのかというのを、弊社のソフトウェアではセンサーのスキーマみたいなもので定義できるようになっています。
例えばCO2センサーで、単位がPPMで、取得する頻度はどれくらいで・・・といった定義ができるソフトウェアです。ソフトウェアは継続して開発をしているので頻繁にブラッシュアップされていて、新しいタイプのセンサーもどんどん対応していっています。
例えば、あるメーカーにしかない独自のインデックスや指標などもあるのですが、スキーマを定義することで簡単に追加できるようになっています。
－なるほど。そのスキーマというか、デバイスの登録はクラウド側でやるのですか？
上田： そうですね。画面はこのようになっています。
上田： この画面にあるアルプス電気のセンサーは、「温度」「湿度」「気圧」「照度」「紫外線」が取れます。こういったものを、実際にはスペックシートを頂いて、「こういうセンサーだ」とスキーマを定義すると、クラウド側は変更なしでこのセンサーをサポートできるようになっています。
－デバイスとゲートウェイ間は、どういう通信プロトコルに対応しているのですか？
上田： 本体にはWi-Fi/EthernetとBluetoothしか入ってないですが、ドングルを差すことで結構何でも通信可能です。Modbus/RS485、BACnet、独自のMQTTのプロトコル、各社のサブギガプロトコル、シリアルなど、さまざまです。
―センサーからゲートウェイにデータが入ってくると、ゲートウェイのレイヤーでちゃんと構造化したデータになり、それがクラウドに上がってくるということですね。普通のゲートウェイだと、素データがそのままクラウドに入ってくるので、それを構造化する処理もクラウド側でやるけど、これはゲートウェイでやるということでしょうか？
上田： そうですね。
－ということは、これは御社のクラウドだけではなく、他のクラウドでもつながってしまうのではないか？という点が気になるのですが、そこはどうですか？
上田： それが、ただデータを流すだけだったらできるのですが、センサーに特化したというのが実は鍵でして、クラウド上でデータを扱うデータの構造をセンサー用に定義されていないと、たぶん扱えないと思うのです。
例えば温度を測るセンサーは、センサーモジュールと呼ばれるものの１センサーです。一方で、センサーモジュールにはたいてい複数のセンサーが載っています。
そして、そのセンサーモジュールはあるゲートウェイ・ある場所に紐づいていて、それを所有しているユーザーさんがいて、この人が何ヶ所かにこういうデバイスを持っています、という所有者情報があります。そこまでの構造が全部定義できていれば、他のクラウドでも扱えると思いますが、他のクラウドプラットフォームでは、ここまでのオーナーシップ構造を持っているものは見たことがありません。
－もしくは自力でデータベースに書かなきゃいけないですよね。
上田： はい。データベースの中で今お話したようなことを全部定義することで、使えるようになるのですが、弊社はここをIoT全般ではなく、「センサー」に特化することで、ここの構造ごと提供可能になります。
－使う側からすると、データ構造が理解できるカタチになっているから、それを好きにAPIなりなんなりで引っ張って使ってくればいいってことですよね。
上田： はい。先ほどお見せしたデモでも、実際にはデータを吸い上げて構造化したデータを格納する部分と、そのデータを活用して可視化する部分に分かれております。
－このIoTプラットフォーム上では、インベントリー管理というか、センサーの管理を細かくしているのですね。
上田： そうですね。それが今のこの画面です。
 
上田： ゲートウェイ2002とラベルがつけられたゲートウェイは、実際はサンフランシスコの弊社オフィスにあります。ここに4台のセンサーモジュールが接続されていて、それぞれに名前がついていて、1つは会議室、もう1つは冷蔵庫の環境を測定していることがわかります。
－例えば工場に多数置くのであれば、例えばサンフランシスコ工場の1番目とか2番目とか名前を付けるといいですね。
上田： はい。こうやって、いろんなセンサーから引っ張ってきたデータを活用して、ダッシュボードに作ることができます。ユーザごとにできるようになっているので、何か追加したいとか、グラフがよいとか、自由にカスタマイズすることもできます。
－生データをパッと見る時には、すごく分かりやすいダッシュボードがもうできているってことなのですね。
上田： はい。このサービスを使うことで、IoTのシステムの8合目くらいまでできているイメージです。
－ここまでできていると、利用者はアプリケーションの開発に専念できますね。
上田： そうですね。さらに言ってしまえば、いわゆるUIの部品までもあるので、これを組み合わせることで実際の業務システムが作れます。
－いわゆるルータをつくっている会社が、その延長上でIoTプラットフォームを作るというと、こういう着想になると思うのですが、それとはどう違いますか？
上田： 「データを見える化できます」というソリューションはすでに結構あると思うのですが、それをベースにお客さまごとのシステムに発展させていくことができるかが重要です。
たしかにデータを見ることはできるのですが、「こういう機能が欲しい」とか、「これはいらないから、こういうところを変えて自社システムにしたい」というときの、ベースとなるソリューションなのか、それとも見える化で完結した行き止まりのソリューションなのか、というところが違いだと思います。
実は、このデモも全てAPIを使って作られているので、言ってしまえばこれ自体が、そのサンプルアプリケーションと言えます。
ちなみに、デモのソースコードを提供することができるので、これをベースに色々改造して作っていただけます。
もうひとつは、データを「収集する側」と「貯める側」の両方を弊社で設計しているので、まっさらな更地にシステムを一から設計しなくても、業務アプリケーションとして面白いものに時間と労力を割けるようになるのだと思っています。
次ページ：デバイスのプロトコル対応など
－ところで、このゲートウェイですが、プロトコルが何に対応しているのかとか、温度帯がどれくらいの範囲に入っているのかなどについて教えて下さい。
上田： 車載用の方はインダストリアル仕様でですので、60℃ぐらいの場所でも使用できます。オフィスなどの通常の環境では廉価な据え置き型ゲートウェイをご利用いただけます。その２つのバージョンを用意しています。
－外置きものを提供したり、ルータ側のソフトウェアだけを切り売りしたりするようなことは考えられてないのですか？クラウドはもうあって、この中に入っているソフトウェアを、例えばどこかの別の会社のルータに内蔵してもらうというような考え方です。
上田： それは、もちろんオープンにやろうと考えています。Linuxベースのゲートウェイであれば、ほぼどんなものでも対応できます。「とにかく簡単に早く、買ってきて５分でつないで動く」を目指しています。
－「手軽にPoCを始めたい」という企業は多いのですが、結果が良く本番に移行する時に、費用が過剰にかかると対応に二の足を踏んでしまいます。御社の場合だと、Linuxベースになっているルータであれば、御社のソフトウェアはルータにのせることができるので、今のテスト環境と同じことは実現できる、ということですよね？
上田： そうですね。結局、ハードウェアのコストを抑えるのか、ソフトウェアのカスタマイズのコストを抑えるかなので、ハードウェアのコストを下げるのであれば、ソフトウェアの開発費を少し頂いて、移設してあげれば良いのです。
弊社は弊社のゲートウェイを売って、川上から川下までお客様を囲い込みたいというわけではなくて、川上から川下まで用意されていないと（実務上）手間がかかるので、とりあえず、何でもよければこれをどうぞ、という形で用意しているだけです。
－そこを明確に言い切る人は少ないと思います。なぜかというと、物事って案外構造的にならないし、誰でも本当はバーティカルにやりたいわけですから。
上田： バーティカルにやるのが一番簡単です（笑）。現在の弊社のゲートウェイはかなり高スペックですが、もともとはRaspberry PiやIntel Edisonでやっていたので、そういった安価なプラットフォームにバックポートすることも容易です。
ゲートウェイソフトウェアはGo言語で作っているので、ポーティングはやりやすく、サイズもとてもコンパクトなので、相当低スペックな機器でも動かせると思います。結構無茶な注文をいただいたりもしてますが（笑）、気合でがんばっています。実際、おっしゃる通り「ゲートウェイにこのハードウェア使えませんか？」というご相談が多いです。
―クラウド側より、ルータ側の注文が来るわけですね。IoTプラットフォームがうまくいかない理由は、クラウド側ばかり一生懸命作るからだと思っています。
上田： 弊社もゲートウェイをやるという決断をするまでは、星の数ほどあるIoTプラットフォームの1つでした。「他とどう違うの？」と言われて違いを説明しても、反応がいまいちでした。
いろいろ考えた結果、私達はソフトウェアの専門家だという線引きはやめて、「お客さんが必要とするものなら何でもやります」としました。ハードウェアも売るというところまでやった瞬間に、道が開けました。おかげさまで多くの引き合いが来ています。
－クラウド側は、Googleクラウドにのっているのでしょうか？
上田： 今はAWSと、ニフティクラウドにのっていて、GCPにも載せる予定です。クラウド事業者にロックインされないようかなり注意して作っていますので、どこでも大丈夫です。
－クラウドのスケールアウトなどは、クラウド会社によってそれぞれ違いますよね。
上田： もともとGoogleやTwitterで働いていた頃今のような便利な機能はなかったので、あまり環境に依存せず、スケールする仕組みも自分たちで作っています。
－何気に難しいことをクラウド側がやっているのですね。私は、本当に何億台がつながる日が来たときに、対応できるのかな？と思っています。
上田： 実際、「クラウドサービス」と言っているのに、実はサーバ1台で動いているソフトウェアってすごく多いですよね。
IoTプラットフォームなんかでもそうなのですが、「オンプレミスでいきますとか、お客さんごとにインスタンスを上げています」という話を聞くと、これはつまりサーバ1台で動く、つまりスケールしづらいやり方だと思います。この系統のシステムだと、将来規模が大きくなると速いサーバを買うしかない、デカいデータベースインスタンスを作るしかないということになります。
一方で、「クラウドコンピューティング」というのは、データセンターのどこで、どのコンピュータを使っているかは、よく分からないけど、よろしくやってくれる、というのが本来のクラウドです。私は、クラウドという言葉ができる前からGoogleでそういうシステムの開発をやっていたので、負荷が増えたらサーバを増やせばスケールするというシステムの作り方が染みついているのです。
それで、弊社のシステムは全部分散システムになっています。そこで、キャパシティが増えればマシンを増やせばいいし、どのマシンが落ちたとしても、基本的にはアメーバみたいに自己再生しながら動き続けます。
なので、2年くらい前にサービスをリリースしたのですが、そこからまだ１回も止まっていません。データベースは何度か落ちているのですが、その間もシステム全体としてはそれをカバーしながら動いています。
次ページ：自動車のクラウドサービス
ーセンサークラウド以外のソリューションはあるのですか？
センサー以外だと、自動車の分野で、自動車をセンサーとみなした取り組みをしております。GPSもセンサーだし、車速データ、OBDⅡなどもセンサーなので、同じプラットフォームを使ってこういったもの（下記）が作れます。
こちらは「ビークルリサーチクラウド(VRC)」という名前で出していますが、自動車のフィールドテストを実施する時の開発車両をリアルタイムでデータを取得することができます。
実際に2台のテスト車両が走っていて、すれ違ったデータなどを100ミリ秒単位で収集したりします。
－それをさばけるのですか？相当良いCPU積んでいるのでしょうか？
上田： 大丈夫ですよ。CPU負荷自体は大したことはありませんが、通信の制御が結構大変です。モニタリング用の情報はリアルタイムであげて、その裏ではストリーミングで大量の生データを流しています。
裏の仕組みですが、「バルクデータアップローダー」というのを社内で内製しています。例えば、トンネルに入ったり橋の上を走ったりすると通常データが切れてしまいますが、その時に送れなかったものを後から送り直して、クラウド側で再構成する仕組みも入っています。
あとは収集した2台の車のテストデータを100倍速で再生することができるようになっています。止めたり、ズームインしてみたりして、このときどうだったのを調べることもできます。基本的にはここである程度確認して、データをエクスポートして、さらなる分析に使っていただくイメージです。
自動車業界では、様々な企業でテスト走行を行っています。しかし、大手クルマメーカーでないとコストをかけずらい状況にもあります。そこで、ここでも柔軟なセンサーのスキーマ技術が生きてくるのです。
車両のフリートマネジメントのソリューションは多くあるのですが、多くのフリートマネジメントは車の位置くらいしか取れません。
しかし、実は車の位置情報だけじゃなく、車内の中の環境や、ドライバーの疲労度など、取りたい情報は多岐に渡ります。
こういったクルマの基本データ以外のセンサーデータを取ることができるフリートマネジメントシステムとなると、急に選択肢が減ります。さらにすぐ使える車載ゲートウェイも含むソリューションとなると、弊社のサービスが非常に使いやすいソリューションになるのです。
－表面的に見るとおっしゃるとおりですが、実はバックエンドで動いているバルク処理などが難しいからみんなやれないのですし、結局このルータの中にそれが仕込めないのです。
ドングルから取ってくるデータを、貧弱なネットワークで飛ばすことくらいは誰でもできるので参入障壁が低いですが、さまざまな状態をきちんと制御しながらデータを欠損なくあげようと思ったら、今までであれば、車にパソコンをのせて一緒に走っるしかなかったのですよね。。
要は、いちいちクラウドにあげなくても、データはパソコンで見ることができるし、テスト走行が終わった後にクラウドにあげられるので、最初からクラウドにあげようという発想の人があまりいなかったんじゃないか、と思います。
上野： これまで１時間かけて取ったデータを、また１時間かけてアップロードすることをやらなくても、少しずつアップロードしてくれて、車がピットに着いたらもうデータは大体見えていて、「ちょっと違う走り方してよ」と言われてもすぐに対応できるので、どちらかというと人件費の削減や、手間を省いてくれるのにすごく貢献します。
これまでは、ドライバーと技術者が電話しながらテストされていたというケースもありました。走行テストをするために日本の技術者をアメリカに派遣するので、何週間という出張になるのですが、これを使えば、現地のドライバーに走ってもらって、東京から開発者が遠隔でデータを取り出すということができます。
単純に人件費も削減できますし、もうひとつ大事なのは、今まで技術者のパソコンに入っていた走行データを、会社として全部一箇所に蓄積していくことができるのです。
走行データの分析をするときも、いままで全部のテストデータに対して解析をかけられるようになるので、走行データが会社のデータ資産化できるのがメリットです。
－今日のお話を聞いていて、裏側の技術がすごいということが分かりました。
上野： それをエンドユーザに分かってもらうまでが、すごく大変です。弊社のサービスを実際に触っていただくと、細かいところで裏側のデータベースなどの処理がいかに速いかなどが、分かっていただけると思います。
上田： 例えばさっきの温度のグラフは、1秒単位から何ヶ月の範囲で見たりできますが、30秒に1回のデータを1年間取ると、ちょうど100万件のデータになるんです。
なので、1年間のグラフをパッと出そうとすると、100万件のデータをクエリーしないといけないといけません。これって何十秒、下手をすると何分もかかる処理です。しかし、グラフを1個描くのに1分もかかっていたら使い物にならないので、時系列データベースを自社で作りました。いろんな複雑なクエリはできない代わりに、センサーデータを読み出すことだけはとても速いのです。
－最後に、日本市場を統括される上野さん、日本展開の意気込みを教えてもらえますか。
上野： 日本メーカーのセンサーシェアは世界で6割もあり、日本のセンサーの技術を世界に届けるという、すごくビジョナリーな仕事ができると思っています。実際にMODE経由で日本のセンサーが海外の顧客に売れている事例も出ているので、今後の今までリーチしていなかったロングテールでの「センサーの民主化」をしていきたいと思っています。
－本日はありがとうございました。
【関連リンク】
MODE, Inc