SORACOM買収からわかるIoTの未来

2016年12月29日

初出: TechReport 2016.12

本書の執筆中に「株式会社ソラコムの KDDI グループ参画」というニュースが飛び込んできました。日経新聞曰く200億円という買収額をどう感じるかは視点次第ではありますが、玉川さんのインタビュー40にある「ビジョンをやりきるため、アクセルを踏み込むための M&A」という言葉のとおり、世界をねらうためのステップとして期待をしています。

オープニングポエムはさておき、単なる IoT/M2M 機器向けに価格プランを作り込んだだけの安価な MVNO キャリアと勘違いされがちな SORACOM ですが、その真価は「通信とクラウドを融合したIoT 通信プラットフォーム」であることです。本章では、これがどういうことか解き明かしていこうと思います。

SORACOMとは

端的に言えば、SORACOM は株式会社ソラコムが提供する IoT 通信プラットフォームです。

正直「IoT なんちゃらプラットフォーム」という単語自体にバズワード感がありますが、一般的にはIoT41デバイスが通信をするために必要なものを揃えたパッケージという感じで使われているようです。SORACOM のように通信にフォーカスしたものだけでなく、（ネットワーク接続を前提に）IoT デバイスから集まってきたデータを分析・可視化するサービスや、デバイスからデータをクラウドに投げるときのライブラリ群、あるいはそれらを包括的に提供するものといくつかのパターンがあるようです。

SORACOM はざっくり三つの役割を提供しています。

SORACOM サービス構成

SORACOM はこれらを下から上まで「垂直統合」で提供し相互に価値を高め合うことで、利用者に対して高度なサービスを提供しているわけです。

回線接続サービス

IoT デバイスがネットワークに接続するための回線を提供する、プラットフォームとしては一番低い部分です。サービス名称としては「SORACOM Air」が対応し、SORACOM の最初のサービスでもあります。

当初は NTT ドコモの MVNO として日本国内向けにサービスを開始しましたが、その後海外でも利用可能なグローバル向け Air SIM が提供されたほか、920MHz 帯の LPWA（Low Power Wide Area Network42）である LoRaWAN と Sigfox にも対応しました。（追記：その後、KDDI 回線を利用できる SORACOM Air SIM（plan-K）と、今回の SORACOM Button も利用しているLTE-M（plan-KM1）が提供されました。）

また、株式会社ソラコムとしてのサービスではありませんが、ソラコムが開発した SORACOM のエンジンである「SORACOM vConnec Core」を KDDI が採用した「KDDI IoT コネクト Air」があります。MVNO と同等の接続サービスとしては同じように提供されていますが、この後に紹介する上位層の機能は残念ながら SORACOM 本家から若干遅れての提供になっているようですが。KDDI グループへの参加により、サービス内容の共通化も進んでいくと考えられます。なお、技術的詳細は明かされていないので、KDDI としてのサービスについて、これ以降は触れません。

（上記のとおり SORACOM 本体から plan-K が提供されたことにより、こちらの KDDI IoT コネクト Air の新規申し込みは終了になった模様です。その結果、全てのサービスがドコモ回線と同じスピードで提供されるようになっています！）

SORACOM Air は NTT ドコモと L2卸契約する MVNO ですが、NTT ドコモからの専用線から先の MVNO キャリアとして必要なシステム全てを AWS 上で構築しています。データトラフィックの転送や通信網の管理を、クラウドネイティブな設計でソフトウェアによって実装しています。これにより、利用数の増加を見込んだ設備投資を避けつつ、高い頻度での開発サイクルを回しています。その副産物として、1日10円＋最低0.2円/1MB（たとえば月間1GB であれば約500円）という低トラフィックでは極めて安価な従量課金を実現しています。

ただ、安いことは SORACOM の価値の中ではぶっちゃけ些細なことではないでしょうか。単に安いインターネット接続回線だけが欲しいのであれば、月額300～500円や、一定転送量まで0円というMVNO キャリアも登場している昨今です。

SORACOM Air の価値の半分は、その管理機能を API として提供していることにあります。APIから SIM ごとの設定（回線速度や回線自体の有効・無効など）を変更でき、通信量などを監視してAWS Lambda を呼び出すイベントハンドラー機能もあります。これを利用することで、SORACOMの上に仮想 MVNO 事業者を構築したり、SIM を組み込んだ形で製品を出荷してから契約状況に合わせて通信を有効化・無効化したりといったことが可能になるわけです。

残りの半分は、SORACOM Air という回線契約があることで、安全にデバイスを識別でき、それによって上位層の機能を提供できるということです。セルラー43であれば SIM が、Sigfox であればデバイス内蔵のセキュアエレメントが耐タンパー性44を持ち、デバイス識別のための秘密情報が安全に保存されています。また LoRaWAN の場合にも、出荷時に SORACOM 側と同期されてデバイスに設定される AppKey を使ってセッション鍵を作成するため、耐タンパー性とまではいきませんがそれなりに保護されています。

接続回線という一番下の層において個別のデバイスを一つの ID 基盤上で識別できているからこそ、異なる通信網を性質の違いのみを意識するだけで、その上に多種多様なサービスを統一的に提供できます。

概念的な表現をすると、閉域網の中でデバイス別に IP アドレスが割り振られる旧来のネットワークセキュリティのモデルに対して、回線の接続点で直接認証される ID ベースのセキュリティという新しいモデルがあり、それに基づいて SORACOM のあらゆるサービスが実現されています。

要するに、「Air」に続く「B」以降のサービスのために、SORACOM Air としては様々な通信方式に対応する必要があり、今後来る5G ベースの携帯通信網や、グローバルの世界制覇のために KDDI と手を組んだのだと思います。

ソフトウェアベースの高機能な仮想ネットワーク

先ほど書いたとおり、SORACOM のネットワークは全てクラウド上のソフトウェアで構築されています。つまり一種の Software-defined Network（SDN）や Network Function Virtualization（NFV）です。通信回線の反対側にそのまま SDN/NFV の世界を接続したことで、閉域網として様々な機能を提供しています。

閉域網という視点では接続先に応じて3種類のサービスを提供しています。AWS 上の自分のVPC に接続する最も安価な「SORACOM Canal」、物理専用線として AWS Direct Connect を利用する「SORACOM Direct」、インターネット VPN を利用する「SORACOM Door」です。

これらを利用する場合は、Virtual Private Gateway（VPG）という仮想ルータを構築して、SORACOM Air の回線ごとに VPG に接続します。

自分独自の VPG を利用することで、デバイスに割り振られる IP アドレスレンジ45を変更したり、デバイス毎に固定の IP アドレスを指定したりといったことも可能です（次に紹介する SORACOM Gateを使わない限りその IP アドレスが直接見えることはありません）。ただし、これらは閉域網と言ってもVPG で NAPT されるため、あくまでデバイス側からクラウド側への方向の接続のみを提供しています。

クラウド側からデバイス側への接続、あるいはデバイス同士の接続を実現するのが「SORACOM Gate」です。SORACOM Gate を有効にするとデバイス毎の IP アドレスを利用して相互に通信が可能となります。さらに、SORACOM Canal 等で接続されたネットワーク上に Gate Peer と呼ばれるルータ（実際には VXLAN が設定された Linux ホスト等）を構築することで、そこからデバイスまで一つの仮想 L2ネットワークが提供され、自分のネットワークからデバイスに直接接続できるようになります。Gate Peer まで L2で伸びてきてくれるため、そこから自分の VPC 内のネットワークにさらに L2ブリッジしても良いですし、もっとシンプルに NAPT するのも手軽です。

さて、このあたりまでは気合いの入った閉域網サービスであれば実現できるところですが、SDN であることを最大限に活かす SORACOM らしいサービス「SORACOM Junction」がつい先日リリースされました。これは VPG を通過するパケットに対して、ミラーリング、リダイレクション、インスペクションの3つの操作を提供します。

ミラーリングとリダイレクションは、名前の通りパケットを複製したり転送先を変更したりすることで、ユーザ企業が独自の監視システムを通したりトラフィックの制御を行ったりと言うことが可能となります。インスペクションはパケットの統計情報を外部サービス46に送信します。

これら SORACOM の高機能な仮想ネットワークは、全てクラウドネイティブな設計で実現されているため、SORACOM の利用者やその転送速度・秒間パケット数などが増えても（万が一 AWS のリソースが頭打ちしない限り）いくらでもスケールすることができます。その一方で、たとえば SORACOM Canal の VPG は1時間あたり50円（30日間で36,000円）と、きちんと利用者にそれなりの負担が求められます47。このあたりはうまく技術上の制約をビジネスとして成立させていると感じます。

モバイル通信網の課金体系は、行き過ぎたインセンティブなどにより極めて歪になってしまっていますが、SORACOM の素直な課金体系を見るとほっとします。

クラウド連携

SORACOM の真価はクラウドとの統合にあります。IoT でビジネスをするために必要なのは、単にIoT デバイスを IP ネットワークに接続することだけではなく、その IP ネットワークを介してクラウドの向こう側に大量のデータを期待する品質で届けることです。通信とクラウドの融合を謳っているように、SORACOM には IoT デバイスをクラウドと連携するための仕組みが数多く用意されています。

SORACOM のクラウド連携機能は、大きく二つに区別できます。一つは、AWS や Azure、GCP、あるいは独自に構築したサーバなどの、「クラウド側」との橋渡しをする機能です。サービスとしては「SORACOM Beam」と「SORACOM Funnel」があります。単純にデータを左から右へと転送するだけで無く、クラウドに送る際の認証や暗号化処理、データ量の限られた LPWA を利用する時のデータ形式変換など、「IoT デバイスがクラウドと通信する際のあるある処理」を SORACOM が肩代わりしてくれます。

もう一つは SORACOM 自身がクラウドとして直接的な機能を提供するもので、「SORACOM Endorse」「SORACOM Harvest」「SORACOM Inventory」が対応します。SORACOM Harvest のように単体で完結するものもあれば、SORACOM Endorse のように別の枠組みと連携するための機能もあります。ここからは、これらを個別に掘り下げていきます。

SORACOMの世界観

SORACOM のクラウド連携について具体的な機能を紹介する前に、まず SORACOM が IoT プラットフォームとして提供しようとしている世界観について触れておきます。

IoT における代表的な脆弱性を OWASP がまとめているので、以下に引用します48。

I1 Insecure Web Interface安全でない（製品の）Web インターフェースI2 Insufficient Authentication/Authorization不十分な認証/認可I3 Insecure Network Services安全でないネットワークサービスI4 Lack of Transport Encryption/Integrity Verification転送路における暗号化・完全性確認の欠如I5 Privacy Concernsプライバシーに帯する懸念I6 Insecure Cloud Interface安全でないクラウド上の Web インターフェースI7 Insecure Mobile Interface安全でないモバイルアプリのインターフェースI8 Insufficient Security Configurability不十分なセキュリティ設定I9 Insecure Software/Firmware安全でないソフトウェア・ファームウェア（の更新）

I10 Poor Physical Security物理セキュリティが弱いIoT デバイスが関連するのは I1、I2、I3、I4、I8、I9、I10あたりですが、IoT 固有の物理セキュリティ（I10）を除いて、一般的なウェブアプリ等であれば当然のようにどれも考慮されているべきはずのものばかりです。これらがなぜ IoT デバイスで特に問題にされるかと言えば、IoT 固有の理由でそれらを設計時に「妥協」してしまうからです。

IoT デバイスが一般的なサーバ側システムと異なるのは大きく2点あります。

一つは計算機としての性能です。最近になってようやく ARM ベースなどの比較的高性能なデバイスも増えてきましたが、消費電力であったりサイズであったり、あるいは予算や部材の都合で依然として性能の低い IoT デバイスとはまだ何年も付き合っていく必要があります。ところがデバイス自身を正しく認証する、あるいはデバイスに接続するユーザを認証するには、公開鍵暗号やハッシュ関数などの計算が必要となり、決して低くない演算能力が必要となります。さらに大量のデータをクラウドに送信するようなデバイスでは継続的な暗号化も必要となります。

旧来のネットワーク制御デバイスでは、ネットワークセキュリティを前提として「妥協」をしてきました。その結果として、USB メモリなど様々な手法を組み合わせた Stuxnet などの被害が発生しています。何らかの手段で、低い処理性能しか持たない IoT デバイスからクラウドまでの通信を暗号学的に守っていく必要があることは確定的に明らかです。

もう一つが、IoT デバイスの数が多いということです。様々なデバイスをネットワークに接続して安全に機能させるには、それぞれのデバイスを個別にセキュアに識別する必要があります。そのためには、電子証明書あるいは事前共有鍵どちらでも良いですが、デバイス毎に何らかの秘密の認証情報を持たせる必要があります。ところが、数百数千が前提となるような IoT デバイスでは製造時に個別の情報を持たせ、それをそのまま運用時にも利用するということが難しくなってきます。したがって運用開始時に認証情報を投入する必要が出てくるわけですが、物理的な作業をどう減らすかが重要であり設計の難しさが一気に上がります。また故障時の交換なども踏まえると、開始時だけではなくシステムの運用ライフサイクル全体の中でデバイスの識別方法を設計する必要があります。

SORACOM はこの課題に対して「まず接続回線を安全に識別し、その上で SORACOM 側に処理を委譲する」という解決策を提示しています。SORACOM Air の回線は、3G/4G 網やLoRaWAN/Sigfox のそれぞれの暗号学的手段によって安全に認証・暗号化されています。そこで、IoT デバイスは純粋にやりとりしたいデータだけを SORACOM に送り、SORACOM が認証や暗号化など本来 IoT デバイス上で行うはずだった処理を肩代わりします。

また、IoT デバイスは必ずネットワークに接続する必要があり、設置時に SIM を挿したり、LoRaWAN や Sigfox のデバイス ID を登録したりします。これまでは別の手段で証明書を配布するなど認証のためだけの作業が必要でしたが、通信路に紐付いてクラウド連携を行うことでそういった作業をゼロにします。

これこそが、SORACOM の世界観において核となる考え方です49。

プラットフォームというものを提供するということは、そのプラットフォームの世界観──すなわち、IoT/M2M デバイスにおける通信とはどういうものなのか、運用も含めたシステム全体をどういう抽象化に基づいて IoT デバイスやクラウドを設計するのか、という共通認識──のシェアを取り合う「抽象化戦争」に参加するということです。

この SORACOM の世界観は、IoT プラットフォームにおける象化戦争においてかなり強い魅力を持っているように思います。

さて、そろそろ個別のサービスを紹介していきます。

SORACOM Beam

SORACOM Beam は、端的に言えば高機能なアプリケーションプロキシサーバです。

SORACOM 内のエントリポイントに IoT デバイスから送りやすいプロトコルで送信すると、上手い具合にプロトコルを変換したりしてクラウド側に送信してくれます。SORACOM が提供するクラウド連携機能のなかでもっともシンプルなものですが、SORACOM が提供しようとする世界観に触れる入口として一番相応しいものです。

また、SORACOM 上で全ての SORACOM Air 回線はグループ単位で管理されますが、SORACOM Beam はこのグループに対して設定されます。したがってグループの Beam 設定を変更するだけで、そこに紐付いた全ての IoT デバイスからの送信先が一括で管理できます。当然ながら、Beam に限らずこのような設定を SORACOM API で変更することも可能であり、デバイスを含むシステムのオンライン開通などを構築することもできるでしょう。

利用するプロトコルで分類すると、6種類の動作に分けられます。

HTTP ⇒ HTTP/HTTPS

IoT デバイスから HTTP でエントリポイントにリクエストを送信すると、そのリクエスト内容をクラウド側の URL に対して HTTP もしくは HTTPS でリクエストを転送します。クラウド側がインターネットの向こう側にある場合など、HTTPS による通信の暗号化処理を SORACOM 側にオフロードできます。IoT デバイスから SORACOM までは各通信手段による暗号化や、NTT ドコモから SORACOM までの専用線で守られているため、SORACOM までは HTTP で良いわけです。

クラウド側にリクエストを送信するときに、接続元 IoT デバイスの IMSI50・IMEI51や、事前共有鍵に基づいた電子署名、個別に指定したカスタムヘッダを HTTP リクエストヘッダに追加することができます。これによって、クラウド側は「誰からの通信なのか」を識別することができます。これはこの後の他のHTTP 転送先でも共通です。

細かくは、ドメイン上の全てのパスをそのまま利用する「Web エントリポイント」と、パスごとに個別の転送先を設定できる「HTTP エントリポイント」の2種類が用意されています。

TCP ⇒ HTTP/HTTPS

TCP でエントリポイントに接続して生のデータ列を投げると、HTTP POST リクエストに変換してクラウドに送信します。データ列は、以下のように Base64エンコードで JSON に埋め込まれて本文として送られます。

{“payload”:“Base64エンコードされたメッセージ”}クラウドからのレスポンスもそれっぽく返ります。

400 Message from server

UDP ⇒ HTTP/HTTPS

TCP と同様に、受信したデータを HTTP/HTTPS に変換して送信します。

TCP ⇒ TCP/TCPS

TCP で送られた内容を、そのまま TCP でクラウドに送信します。IMSI や IMEI 等を送りたい場合は、HTTP リクエストヘッダの代わりに、先頭行として送信されます。

MQTT ⇒ MQTT/MQTTS

クラウド側の MQTT ブローカーと相互に Publish/Subscribe を転送します。

LoRaWAN ⇒ HTTP/HTTPS

LoRaWAN デバイスから送信された Uplink データを、HTTP/HTTPS でクラウドに送信します。先ほどの TCP からの変換と似たような動作をしますが、Base64ではなく Hex 表記が使われるほか、経由した LoRaWAN ゲートウェイの情報や受信電波強度（RSSI）などの追加情報を含む JSONとして送信されます。

LoRaWAN などの LPWA では転送できるデータ量が極めて少ない52ため、JSON のような富豪的なデータを来ることはできず、まさに「1ビットは血の一滴」と送らなければならないデータをビット単位で詰め込んで送ることになります。それをどこかでクラウド側で扱いやすい形に変換しなくてはなりませんが、バイナリパーサー機能を利用することで、バイナリデータを指定した通りに分解して JSON 上に展開することができます。どこかで必要になる処理なので、LPWA の利用者には非常に便利と思います。バイナリパーサーはこの後紹介する SORACOM Funnel や SORACOM Harvest にも対応しています。

SORACOM Funnel

筆者が一番好きなサービスがこの SORACOM Funnel です。

SORACOM Beam が単純なアプリケーションプロキシという形態だったのとは対称的に、SORACOM Funnel は様々なクラウド固有のインターフェースに直接データを投げ込むことができる「クラウドリソースアダプター」です。

様々なパブリッククラウドはデータ収集用のサービスを提供していますが、IoT デバイスからそこに送信しようとすると、IoT デバイス上でクラウド接続用の SDK を組み込んだり、そこに食わせる認証情報の管理が必要となったりします。SORACOM の世界観の通りそれらの面倒な処理全てを肩代わりしてくれるのが SORACOM Funnel です。IoT デバイスは、送りたいデータをそのまま SORACOM Funnel のエントリポイントに HTTP もしくは TCP/UDP で送るだけです。直接 IoT デバイス上のアプリケーションから送信しても良いし、例えば Fluentd が使える環境であれば out-http プラグインが直接使えたりします。

例えば SORACOM Air で接続した IoT デバイスからこんな感じで HTTP POST で投げます。

$ curl -X POST http://funnel.soracom.io ¥-H Content-Type:application/json ¥-d ’{“foo”:“bar”}‘そしてこれを SORACOM Funnel の設定で AWS の Kinesis Streams に送るように設定しておくと、Kinesis Streams には以下のようなレコードが送信されます。

{“operatorId”: “OP9999999999”,“timestamp”: 1473322750825,“destination” : {“resourceUrl”: “https://kinesis.us-west-2.amazonaws.com/teststream”,“service”: “kinesis”,“provider”:“aws”},“payloads”: { “foo”: “bar” },“imsi”: “440000000000000”}payloads の中に送信した JSON が埋め込まれているほか、SORACOM が受信したタイムスタンプ（Unixtime ミリ秒）や、送信に使われた SORACOM Air の IMSI などが含まれて届きます。クラウド側ではこれらのデータを元に送信元を識別して様々な処理を行います。ね、簡単でしょ？

送信先のサービスも、AWS であれば AWS IoT、Kinesis Streams、Kinesis Firehose と一通り、それ以外のパブリッククラウドも Azure Event Hubs や Google Cloud Pub/Sub などイベントストリーミング系に流し込むことができます。他にも、SORACOM の認定済みパートナー各社のサービスに接続することができる Partner Hosted Adapter が用意されています。現在はデータ分析や可視化エンジンなど国内5社のサービスに対応しています。SORACOM 接続の IoT デバイスから容易に送り込めるかは各サービスで支配的な要素になることが予想できるため、今後もどんどん対応サービスが増えて行くことでしょう。

IoT デバイス「あるある」として、技術上の理由やビジネス上の要件によって利用するハードウェアやOS、ディストリビューションに制約がかかることが多々あります。そのような環境の上で、SDK を直接動かす手間を省き極めて軽く標準的なプロトコルだけでクラウドとの連携ができることは、その開発速度の改善に貢献します。数多くの PoC（実証実験）をこなさなくてはならない IoT ビジネスにおいて、開発速度はビジネス上の支配的な要員となります。決して SDK を利用してクラウドに直接通信することが技術的に難しいわけでは無いですが、「そこは自分達のビジネスでは無い」わけで、単純に計算機資源をオフロードするという意味だけではなく、自らの実装量そのものを減らせることが SORACOM Funnel の魅力です。

さらにセキュリティ上の理由としても、IoT デバイスの盗難などを考慮する場合は IoT デバイス毎にアクセスキーなどの認証情報を個別に用意するか、一時的なリスクならば受容できる場合は盗難が発覚したときに即座に認証情報を一括で交換するなどの対策が必要となります。SORACOM Funnel ではクラウド側に対する認証情報を SORACOM 側で持つので、そもそも IoT デバイス上に何かを管理する必要がありません。こういった「考えることを減らす」という方向性のものが私は大好きです。

地味な副産物として、クラウド側の問題でデータ投入に失敗した場合なども、SORACOM 上のマネジメントコンソールで直近2週間のログが見られるので、IoT デバイスを触らずにトラブルシュートできるのも嬉しいところです。そもそも IoT デバイスなんてファイルシステムが read-only で書けるのはtmpfs だけとか、書き込める容量が数 MB とかしかないとかザラで基本的に必要なログは外部に転送する必要があったりするわけで、とにかく自分でやることを減らすのが IoT 開発の肝です。

ここまでの2つは、IoT デバイスとクラウドを連携させるための橋渡しのサービスでした。残りの3つは、SORACOM 自身がクラウド的なサービスを提供するものです。

SORACOM Endorse

SORACOM のサービスの中でも、地味ながら面白いものの一つが SORACOM Endorse です。

繰り返し述べてきたように、SORACOM Air の3G/4G で接続されたデバイスは3G/4G の SIMにより暗号学的に正しく認証されています。ですが、大量のデータ転送や通信の安定性を必要とする場合など、3G/4G 回線経由で送受信したくないというケースがあります。そんなとき SORACOM Endorse を使うことで、モバイル通信を経由して認証トークンを発行してもらうことができます。

認証トークンは標準的な JWT（Json Web Token）フォーマットで、SORACOM Air で接続に使われている IMSI や IMEI などのほか、任意の情報を追加することができます。また SORACOM の秘密鍵で署名されているため、そのため認証トークンを別のシステムに持っていても SORACOM の公開鍵で検証することができます。

これを使うと、単体で用意すると高価になりがちな耐タンパー性のあるセキュアエレメントによるデバイス認証を、モバイルデータ通信を経由するかどうかによらず様々な状況で利用することができます。COSR 設定も可能なので、ブラウザ等からの直接利用もできそうです。

自分のところでは Funnel/Beam で済んでしまって試せていないのですが、システムの実現可能性を広げることができるポテンシャルを感じています。（追記：この SORAOM Endorse の仕組みを上手く活用できる、SORACOM Krypton が登場しています。）

SORACOM Inventory

大量生産をする IoT デバイスにおける設定情報の管理や、稼働中のはずの IoT デバイスの状況を把握するためには、これまでは Beam などのクラウド連携機能を使って自前で設定レポジトリやテレメトリ収集システムなどを作る必要がありました。そういった部分を SORACOM が提供してくれるのがSORACOM Inventory です。技術的には標準規格 LwM2M（OMA LightweightM2M）のサーバです。

LwM2M は恥ずかしながら作者も SORACOM Inventory の登場まで知らなかったのですが要するに非同期に接続される IoT デバイス等に向けて設計された SNMP のようなものと捉えれば良いようです。具体的には、設定値の参照・変更や、非同期に通知されるデバイス側ステータスの変更監視、コマンドの送信などが行えるようです。

正直あまり詳しくないので深くは触れません。

SORACOM Harvest

最後に紹介する SORACOM Harvest は、SORACOM が提供するサービスの中でもっとも高い層にあるもので、IoT デバイスが SORACOM Funnel などと同じようにデータを投げると、SORACOM 上にデータを蓄積し、可視化できます。簡単な PoC であればもはや外部のパブリッククラウドを必要とせず、むしろ SORACOM 自身がパブリッククラウドとしての役割を果たしていると言えます。

投げ方とかは SORACOM Funnel と似ているので、内部的には Partner Hosted Adapter と同じように SORACOM Harvest Adapter のようなもので送り込んでいるような気がします。

ちょっとした可視化と API だけを提供するような「IoT プラットフォーム」が量産されている昨今ですし、なにより IoT デバイス側の開発に重きを置いてクラウド側はデータが見られれば良いようなプロジェクトであれば SORACOM Harvest はまさにどハマリだと思います。是非使っていきましょう。ここでも、重要なことは「自分のビジネスと関係無いところは、できるかぎり自分でやらない」ということに尽きます。

SORACOM 自身がデータを蓄積し始めたという事は、そのデータを対象とした様々な分析サービスなどを実現できる下地が揃ったと言えます。まだまだアルファベットには Z までたくさん残っているので、例えばリアルタイムな機械学習で異常検知できる SORACOM Machine Learning だとかそんな感じの手厚い系のサービスも出てくるのかもしれません。

（追記：この SORACOM Harvest で蓄積したデータを可視化して他の人に見せることができるSORACOM Lagoon がリリースされています。SORACOM Lagoon はオープンソース BI ツールの Grafana をベースにしたもので、グラフや地図などを用いたダッシュボードを作ったり、条件を指定して Slack などの Webhook にアラートを投げ込んだりすることができます。SORACOM の管理コンソールのログイン権限とは別に、共有 URL を発行してお客さんに直接見てもらうことなども可能です。）

SORACOMで気軽に遊んでみよう

散々述べてきたとおり、SORACOM の魅力は MVNO の回線に紐付いて提供される高レベルのクラウド連携機能です。従って、パブリッククラウドがそうであるように、実際に触ってみないとその面白さ、便利さを実感しづらいものです。

SORACOM のハンズオンもかなり広く実施されていますが、自分で勝手に遊んでみるのであれば、回線速度も不必要なので3G で良いですし、古めの docomo 向け中古 USB モデムが2000円程度で転がっていたりします。USB モデムでは Windows/Mac のドライバインストール用に仮想 CD ドライブが仕込まれている場合がほとんどなので、あらかじめユーザ（人柱）による検証報告があるものを探すと良いです。

また、最近 LPWA のサービス圏内も拡がっているので、それを試して見るのも良いかも知れません。例えば LoRaWAN GPS トラッカーが15,800円で購入できるので、それでそのまま試すことができます。リリースされたばかりですが、Sigfox 対応センサ対応デバイスも8,478円とそこそこお手軽に手が出せそうな価格帯です。このような完結した IoT デバイスを買ってきて、SORACOM Harvestでまず可視化してみたり SORACOM Funnel でクラウドに送ってサーバーレス構成で分析してみたりすると、SORACOM が何を狙っているのか実感できると思います。

今後のSORACOM予想

KDDI グループに参加したことで、特に SORACOM の方向性が変わるとは思いませんが、KDDI自身の世界戦略と絡んで、グローバルなサービス展開の手厚さは変わっていくでしょう。また、KDDI が買収した SORACOM 以外とのシナジーというのはありそうに見えます。あとは、いつ SORACOM Air for 5G/NB-IoT とかそういったものがリリースされるかだけですね。（追記：NB-IoT ではありませんでしたが、LTE-M（Cat.M1）に対応したのは皆様ご存知の通りです。）

仮想ネットワークとしては、以前から要望を送っている VPG 上のファイアウォールや、透過プロキシなどに使える L4レベルの Junction、トラフィック・フローダンプ、そんな感じで既存のネットワーク機能が素直に移植されていくものと思います。

クラウド連携としては夢が尽きないところですが、AWS であることを活かして自分で用意したLambda との結合や、AWS IoT などデバイスツイン系のサービスの SORACOM 独自提供、スマートフォンの NFC/FeliCa 連携によるユーザ認証、先ほど書いた収集データの分析基盤など、複数の利用者が必要としそうな機能を継続的に貪欲に SORACOM-ize していくのではないかと思います。

Harvest のような単体で完結するサービスについても、管理者がコンソールから見るだけではなく、パートナーとの関係性もありますが、外部 ID 基盤と連携して一般ユーザ向けの画面を提供といった BIツールの領域に踏み出す可能性もあります。（追記：既に書いたとおり、一般ユーザ向けの可視化画面を提供する SORACOM Lagoon がリリースされました。）

今後も SORACOM のニューリリースから目が離せなさそうです。