シリコンバレーでクラウド・プラットフォームを開発するMODE社が、このほど日本法人を設立した。CEOの上田学氏は、Google MapsやTwitterで大規模なウェブ・モバイルサービスの開発に従事してきた日本人エンジニア(詳しくは当サイトのインタビュー記事「MODE, Inc.上田ガク流シリコンバレーの歩き方」を参照)。満を持しての日本展開に、注目が集まっている。9月14日には東京で、日本法人MODE JAPANの設立発表とともに、日本向けプロダクトの詳細公表を行った。
今回は、発表会当日の様子、上田氏とMODE JAPANの今後の展開を紹介していく。
MODE社が目指したのは、カスタマイズが最小限になるシステムの開発
2014年に起業した米MODE社が手がけているのは、センサーデータの収集と機器の制御を、遠隔で行えるクラウド・プラットフォーム事業である。
活用事例としては、バイオ燃料分野(アイルランド)、自動運転研究開発(アメリカ)、生体センサーからのデータ収集(アメリカ)といったところがあり、すでに着実に実績を重ねている。
上田氏がIoTに注目し、特にセンサーデータの活用に可能性を見出したのは、2013年末頃に自宅のスプリンクラーを自動化したときだったという。きっかけは、DIYだったのだ(このあたりの経緯は前出記事を参照)。電子工作を楽しみながら(制御システムにはRaspberry Pi使用)、趣味の範囲でクラウド制御のスプリンクラーを作りはじめたものの、完成にこぎ着けるまでには、ソフトウェアの専門家(それもとびきりの)である上田氏をもってしても、簡単にはいかなかった。基本のアーキテクチャをどう設計するかにはじまって、ソフト面ではバックエンドから組み込み、モバイルアプリまでプログラミングしなければならない。不慣れなハードウェア面も学びながら、である。
3カ月ほどかけてようやく自動スプリンクラーシステムを作りあげた上田氏は、「これを事業化できないか?」と考えるようになった。かいつまむと、「世界には山ほどセンサーがあるじゃないか」「特に日本には優れたセンサー技術があるじゃないか」「世界中のあらゆるセンサーがつながってデータを活用できたら、世界で戦えるビジネスになるのではないか」ということである。
センサー技術を中心にしたIoT技術で語られる可能性については、それほど耳新しいことではない。デバイスの接続と遠隔制御の観点からなら、それこそ20年来ずっと提唱されていると言ってもよいだろう。問題は、「実際の活用がそう進んでいない」(上田氏・以下同)ことにある。上田氏は、自分のDIY体験から、その根本原因が「大部分がカスタム開発する必要があるから」だと実感した。その考えは、事業化に向けてMODE社を設立、実地にスタートアップを伸展させていく中で、より深まっていったようだ。
世の中を見渡してみたところ、すでに企業が使っているセンサーや収集しているデータは、大量にある。けれども、一口にセンサーデータの収集といっても、そのシステム上のレイヤーは複雑で、組み合わせは多種多様だ。目的や用途も多岐にわたる。一般に「IoTプラットフォーム」と呼ばれる既製のものがカバーするのはほんの一部で、「アプリケーション開発」「データ蓄積・活用」「インターネット接続機器・キャリアなどの選定」「組込ソフトウェア開発」「センサーの選定」といったところは、どうしてもカスタム開発になってしまう。さらに、ソフトウェア屋から見れば、下のほうのレイヤーになればなるほどハードウェア寄りとなるので、それはハードを専門とするエンジニアとすみ分けをせざるを得ない。データ活用のアイデアや需要があったとしても、そう簡単にチャレンジできず、また開発の投資(カスタム開発部分には数千万~億単位が必要になるという)が効果に見合うかどうかは不透明のままここまできたというのが、IoTをめぐる実際の状況だったようだ。
そこでMODE社は、カスタマイズが最少限になるシステムの開発を目指すことになった。そのメインとなる技術は、以下の2つ
- 「MODE IoT ゲートウェイ」――あらゆるセンサーに対応予定の専用ゲートウェイボックス
- 「階層バケツ型時系列データベース」――センサーデータに特化した自社開発の時系列データベース
である。センサーメーカーであるアルプス電気のBluetooth LE環境センサーモジュールが、この2つにセットされた「センサークラウド評価キット」は、アメリカやヨーロッパの企業で活用されている。
発表会で行われたデモでは、上田氏が「使い勝手のよさにこだわっている」と語る「MODEセンサークラウド」の画面が目を引いた。時系列に沿ったかたちでクラウドにためられたセンサーデータを、MODEセンサークラウドではどんどん短かい時間に分割して、解像度を上げて取り出すことができる。デモでは、シリコンバレーのMODE本社の、冷蔵庫の温度センサーの状態をリアルタイムで見られたが、月、週、日、時、分、秒と、スムーズにズームインしていく様子が見てとれた。必要なデータ(この場合は機器の使用実態と電気料金等の管理情報)に、すばやくリーチできる。もちろん、ダッシュボードに表示するグラフのスタイルや種類のカスタマイズは自在で、多様な使途をイメージさせる仕上がりとなっている。
MODE JAPANとしては、この「MODE IoT ゲートウェイ」と「時系列データベース」を中心に、以下の3つのサービスを展開していく。
- センサーを使ったシステム開発向け「センサークラウド」
- 車両研究開発向け「ビークルリサーチクラウド(VRC)」
- 製造ライン向け「FAクラウド」
「センサークラウド」は、上記のゲートウェイとデータベースを組み合わせたオープンクラウドプラットフォーム。
「ビークルリサーチクラウド(VRC)」は、複数の車両を同時にトラッキングして、ミリ秒単位のデータをクラウドに記録し、テストデータを一括集中管理して資産化ができる。自動車メーカーおよび部品メーカーが、過去のテストデータを含めて分析して、AI技術の適用を進めるために役立つソリューションになっている。こちらのゲートウェイは「MODE車載ゲートウェイ」といい、3G/LTE接続ですぐに車両からのデータ収集が可能になる。トラックなどの営業車両に搭載すれば、適正配車のシステムなどにも応用できそうだ。
「FAクラウド」は、各工場のFAシステムで収集されていながらも、あまり活用されていない現状のデータをクラウドに送ることで、製造プロセスの改善や問題発見への活用を可能にする狙いから取り組んでいるものだ。製造業をスマート化するシステムの、コンサル等を行っている企業であるFAプロダクツに技術提供することで、日本での展開を広げていく予定だ。
この発表会には、メーカー系のシステム担当者が少なからず参加していた模様で、デモ後には、実務的な運用に関する質疑応答が熱心に行われた。後半は、その内容を紹介していこう。
デモ後に行われた、実務的な運用に関する質疑応答
―― 「センサークラウド」はIoTプラットフォームの一種で、実用のフロント部分はユーザーの独自開発になるわけですよね。それはどのくらいの開発が必要なのか、具体的に教えてください。
A. センサークラウドは、各社の各種センサーをつないでデータを収集、見える化するパッケージで、イメージで言えば「登山で一気に八合目までいけるヘリコプター」のようなものでしょうか。残りの2割、実際の業務に使うソフトウェアのフレームワークや、センサークラウドのアプリケーションのカスタマイズは必要です。ですが、土台になる8割はできているため、カスタマイズの作業量はぐんと減り、ゴールにつながりやすくなります。
―― こうしたシステムをカスタム開発で全部やると、費用が数千万~1億円かかるという話がありました。これを使うと、具体的にどのくらいの金額になりますか?
A. これまでの事例ですと、従来の開発費が1億円なら1/10ほどに、一桁安くなるレベルになるのではないかと想定しています。カスタマイズの量にもよりますが、単純なものならそのまま使えることが多くなってきています。業務ロジックを追加していった場合でも、一桁安くなるとは言えそうです。
―― 他社製のIoTプラットフォームもあります。その差別化は? また価格帯も教えてください。
A. 米国だけでも、こうしたIoTプラットフォームは160以上あります。それらとの違いは、大きく2点あります。1点目は、あらゆるセンサーをつなぐのが目標であること。IoTプラットフォームというよりは、センサー接続のためのソリューション、オープンなセンサープラットフォームであると考えてください。われわれは、センサーに特化することで決め打ちができ、センサーを扱うゲートウェイを持つことで、内部のソフトウェアをはじめ、関連ソフトをコントロールできるようになりました。あらゆるセンサーは、プロトコル、メーカー、センサーの種類に限らず、ほぼ1週間くらいで追加していくことができます。そして2点目としては、センサーに特化した、時系列データベースを実現できていることです。これまではクラウドにたまったデータを活用しようとしても、そこからデータベースを作っていくために工数は激増し、費用の上乗せにつながっていました。センサーの時系列データしか使わない弊社のデータベースならば、工数は劇的に削減されます。価格帯は、「センサークラウド評価キット」の場合、1ゲートウェイ1000円/月ほどです。台数が少ないとやや高くなりますが、スタート地点としてはそのくらい。センサーも、ハードウェアの工数に加えて1センサー数百円/月くらいでしょうか。センサー数が100、1000と増えても、弊社が扱える範囲であれば相談しながら進めていくかたちになります。
―― どんなセンサーでも1週間以内につなぎ込むというお話。それは確実にそうなのですか?
A. そうです。世の中にはものすごい数の、何万種類のセンサーが存在します。しかし、そんな泥臭い仕事はおまかせを! たしかに、最初のころはセンサー1種の追加ごとにカスタム開発が必要でした。現在は、センサーを扱う際のパターンが見えてきていて、センサーごとの定義も、クラウド側のシステムをほとんど変更することなく行えるようになっています。われわれは、特殊用途のセンサーをサポートし、ラインナップを増やすことで、何千、何万というセンサーがつながるプラットフォームを作り上げ、欲しいデータが即座に取れる世の中を実現したいと思っています。
―― 画像を扱いたいケースもあると思いますが、そのあたりの対応は?
A. 弊社の第3のテクノロジーとして「バルクデータアップローダ」を開発中です。画像データのような大きなデータをニアリアルタイムで送り、1フレームごとに処理をかけるような仕組みを持つものです。FAの検査データに画像解析をかける、自動車の特定データが出た際にカメラの様子を同期させる、そういうニーズに対応していきます。技術は用意しておき、適宜投入できる態勢でいく予定です。
―― センサーの生データを活用するだけでなく、センサーとセンサー、加速度と地磁気といったような、センサーフュージョン的な処理もできますか?
A. 同一ゲートウェイにつながっている複数のセンサーからの演算データをクラウドに上げることは簡単にやれます。ゲートウェイのソフトウェアは弊社コントロールなので。取得後のデータをクラウド側で処理することも、そう簡単ではないケースもありますが、エッジ側かクラウド側のどちらでも実現できます。
―― センサーのデバイス管理はどんなかたちで実現しているのでしょうか?
A. ゲートウェイのデバイスの管理とセンサーモジュールの管理、センサーモジュールのON/OFFといったことをやらないと、このシステムは実現しません。ところが、これを一般的なIoTプラットフォームでやろうとすると、あまりに多様な概念が入ってきてしまいます。そこで弊社は、センサーのみに限定するコンセプトをたてました。センサーのためのプラットフォームなので、すべてのレイヤーにセンサー管理の概念を持たせています。モノとしてのセンサーの管理、状態の管理、そのあたりが各レイヤーに含まれ、IoTプラットフォームに載ったかたちとなっています。
―― モニタリングだけならいろんなシステムがあります。そこからセンサーの制御まで可能かどうか。そこは需要に係わってくるかと思いますが、どうですか?
A. もともとベースにあるのがスプリンクラーのシステムでして、リアルタイム双方向通信ができるものです。「センサークラウド」もセンサーのパラメーターをいじって書き換え、送信のインターバルを変えたり、センサーをOFFにしたりといった制御は、リアルタイムでできるようになっています。センサークラウドでデータを集めた後にも、制御できます。
―― セキュリティは、どの程度まで考慮されていますか?
A. アクセスコントロールは非常に考えて作っています。標準的なインターネットのクラウドサービスもずっと作ってきましたので、標準セキュリティにはもちろん対応しています。さらに、生体データを扱うアメリカのプロジェクトの、医療データ関連の厳しい基準にも対応して開発しています。ですので、通常の工場、自動車の試験データよりも厳格な基準を突破できるインフラとなっていると考えます。
―― まだまだIoTは広がりきっていないようです。BtoBでもBtoCでも、日本での可能性のある分野についてはどう考えていますか?
A. 日本で弊社に興味を持っていただいている分野は、やはり自動車を使うところでしょうか。営業車両からデータを集めて配車を最適化するというような、そうしたニーズは強いようです。もともと弊社はセンサークラウド、動かないセンサーを扱ってきましたけれど、動くクルマ+センサー、これが今、日本ではすごくホットな状況なのではないかと思っています。
以上が、今回の発表会の概要だった。センサーに特化、使い勝手のよいボックスとセットのプラットフォームでIoTを実現していこうとするMODE JAPANの意気込み、そこへの期待感はおわかりいただけただろうか。
ネットワーク関連技術、特にIoT分野では、しばらく前から「ヒト、モノ、コト」をつなげることでアイデアを実現する、あるいはイノベーションを生み出す、ということが語られてきている。果たして、現実的にもそうなのだろうか。「ヒト、モノ、コト」はそれぞれに、もう充分な物語をはらんでいるように思える。モノであるセンサーも、それこそ「世の中に山ほど」普及しきっているのだから。そこにあるコンテクスト(文脈)は、埋もれていたり、途切れていたりすることはよくあり、そこに気づき、掘り起こせるかどうかが鍵であったのではないか。また、個人のDIYレベルであっても、例えば上田氏の自動スプリンクラー製作体験のように、もっと便利なツールがあれば、アプリがあれば、と思えるのはよくあることだ。ツールやアプリがあれば、コンテクストはつながり、アイデアは浮上していく。
IoTの広がりに必要なのは、すでにある物や状況への「気づき」と「掘り起こし」、適切なツールとアプリの活用である、とMODE JAPANと上田氏の取り組みからは思えたことだった。
この連載の記事
-
第55回
プログラミング+
AIに味はわかるか? AIが考えた斬新すぎる豆腐バーガーを作ってみた -
第54回
プログラミング+
GPAIシンポジウム「AI原則と実践の橋渡しに関する国際的な最前線」開催 -
第52回
プログラミング+
濃厚接触者を追跡するコンタクト・トレーサーなど、事業家は準備を始めている -
第51回
プログラミング+
なぜテスラはトヨタの時価総額を超えたのか。日本の歩むべき道を考察する -
第50回
プログラミング+
天才ジム・ケラーに学ぶ。テクノロジー業界では倒産寸前でも逆転できる -
第49回
プログラミング+
ジェットエンジンの原理は?冤罪で捕まったら?専門的な議論や体験談を役立てよう -
第48回
プログラミング+
大混乱なのに株価はほぼ最高額のアメリカ。混迷の時代を書き残そう。 -
第47回
プログラミング+
DXとAI、withコロナ時代のディープラーニングを語る! -
第46回
プログラミング+
価値のある仕事を価値があると伝えるスキルをQuoraで磨く -
第45回
プログラミング+
「Quora」のキレッキレなQ&Aがつまった公式本刊行!! -
第44回
プログラミング+
ITの新常識、日本ディープラーニング協会の「G検定」が受験料半額で実施! - この連載の一覧へ