旅行中に自宅の様子をモニターしたり、別荘の暖房をあらかじめ入れておいたりするときも、モノのインターネット（IoT）を利用する場合は、こっちとあっちのコミュニケーションのためにインターネット・プロトコルを使用する。そのため私は、３年間に書いた著書『Getting Started with the Internet of Things』の中で、IoTを、インターネット・プロトコルで接続されたコンピューター、センサー、アクチュエーターのグローバルネットワーク」と定義した。
これは、大幅に単純化して理想化したIoTの姿だ。美しく澄み渡った技術的な風景だ。そこではIPパケットが温度センサーからクラウドデータセンターを通り、暖房のコントローラーへと伝わる。その間には、厄介なプロトコルの変換や、設定やプログラムで苦労させられる複雑なゲートウェイもない。
しかし、現実はその逆だ。ときには補完し合い、ときには対抗し合う、訳の分からない標準規格の動物園だ（多いほどみんな元気）。
3年後には、または10年後には、この光景はどう変わっているのだろうと私はよく考える。ここにさらに新しい技術が加われば、もっと面白くなる。私の友人たちと私の人生の時間と、血と汗と涙をつぎ込んで特定の技術に賭けるというのは、楽しくない。クライアントにひとつの技術を勧めて、それが後で大コケするなんていうのもつまらない。
王道か裏道か？
この分からない状況に対する人々のリアクションには、大きく分けて2つのタイプがあることを私は発見した。ひとつは、身震いして袖をまくり上げ、「よーし、理想に近づくためにできる限りのことをしよう。いたるところにIPプロトコルをばらまこう。どの道、歴史的にIPプロトコルが他のすべての競合プロトコルに勝利したのだから」と言うタイプ。もうひとつは、肩をすぼめ、「世の中はそうやって動いていくのだ。競争はいいことだ。インターネット・プロトコルの大騒ぎもいい。他にも使えるプロトコルはたくさんある。各自が好きなものを選んで使えばいい」というタイプだ。
これを、ひとつの“王道”対たくさんの“裏道”という視点で見てみよう。熱い議論を煽る面白い綱引きだ。「最初から低消費電力用に設計して、センサーネットワークの無線プロトコルを最適化する必要がある。さもなければ電力を食い過ぎて実用的でない。IPプロトコルはやめるべきだ」に対して、「IPヘッダ圧縮やいろいろな技がある。だから、センサーからルーターまでの無線通信で電力を多く食うことはない。IPこそ未来への切符だ」
技術論争の焦点は、IoTまでの最後の1マイルか数メートルのところで要求されるアーキテクチャの質に集まる。そこは、IoTが“物質になる”部分だ。庭に置いたバッテリー式の植物センサーの最低消費電力、コンベアベルトの制御のためのリアルタイム・デターミネーション、技術的に未熟で平均年齢80歳のシスアドのためのシステム管理の簡易化、ほとんど知識のない現場技術者がセットアップした工作機械のコントローラーのキー管理の簡易化、などだ。
そんな状況でもインターネット・プロトコルは“十分にいい”と言えるのだろうか。どれだけよければ、十分によいとされるのか。いろいろな議論や研究報告を読んでみても、どちらも一理あるように思える。しかし、長い目で見た場合にどちらが正しいのかを考えると、わからなくなる。身震いするときもあれば、肩をすぼめたくなるときもある。たしかに、インターネット・プロトコルは、IBMのトークンリングのような独自規格をブルドーザーのように排除して驚くべき世界記録を打ち出し、明らかに不適切と思われるようなところにまで進出した。たとえば、Ethernetは、工業分野に対応できるリアルタイム性を備えるなど見事に進化した（ただし現在はリアルタイムEthernetを追い落とそうと20（！）もの新規格が争っているので、ひとつを選ぶのは難しい）。
ということは、歴史が示すとおり、インターネット・プロトコルが、その他の“レガシー”なプロトコルを追いやってしまうのは、単に時間の問題なのだろうか。
Bluetooth Low Energy
ここに2つの反例がある。インターネットと並行して成功した通信技術、USBとBluetoothだ。これらはインターネット・プロトコルに対して強い免疫がある。それらを使ってIPをトンネリングさせることすら可能だ。だから、IoTまでの最後の数メートルでも免疫を発揮するかもしれない。
2005年、私のクライアントのCTOが、ノキアの研究センターで新しい無線テクノロジーが開発されていると教えてくれたことがある。それはWibreeという名前だった。短距離の、ホームオートメーションの省電力シナリオや医療向けなどに、大変に有効な技術に見えた。数年後、じつに巧妙な戦略で、ノキアはWibreeをBluetoothスペシャル・インタレスト・グループに受け渡したのだ。そして、Bluetoothの既存の規格にフィットするように改良が加えられ、2010年、Bluetooth 4.0の公式なパートとなった。現在それは、Bluetooth Low Energy（BLE）と呼ばれている。マーケティング向けには、Bluetooth Smartという名前が付けられている。
IPとの互換性がないにも関わらず、BLEを爆発的に成長させた特徴に、以前のBluetoothソリューションと比較して追加コストが非常に安いという点がある。既存のBluetooth対応製品をBLEにも対応させる場合のアップグレード費用が大変に安いのだ。iPhone 4S以降、Appleでは全製品がBLE対応となった。新しいBluetoothチップを搭載しただけでなく、BLE対応アプリが開発できるようにAPIも発表した。そのようなアプリは、それに接続して使うデバイスも含めて、“アプセサリー”と呼ばれたりもする。たとえば、現場技術者が自分のスマートフォンを使って新しいポンプの設定をBLEを通して行うことができる。そのため、ポンプ自体には設定用液晶パネルもUSBプラグもいらない。必要ならば、たとえば印刷機とインターネットをつなぐ臨時のゲートウェイにもなる。それにより、印刷機は新しいファームウェアを入手できるのだ。
もちろん、アプセサリーは仕事専用ではない。私たちがその分野に初めて足を踏み込んだのが、2012年のクリスマスに発表した電子アドベントリースだ。これは勉強になった。たとえば、Appleはデバイスを送るように言ってくる。さもないと、アプリをApp Storeで販売する認可が下りないのだ。ならば、BMWが高級車にBLEを搭載したら、車をAppleに送らないといけないのか、などと考えたりしたものだ。
昨年、GoogleのAndroid APIもようやくBLE対応となった。今年はMicrosoftもWindows PhoneをBLE対応にしなければならなくなるだろう。それによってBLEは、靴のセンサーや心拍モニターといった運動デバイスからスマートウォッチまで、さらには、ドア、テレビ、庭の散水機など、身の回りのコントロールしたいと思うものすべてに対応する、本当の意味でのアプセサリーのクロスプラットフォーム技術となる。
Google APIが登場したことで、Android対応のアドベントリースを2013年のクリスマスに出すことができた。GoogleのBLEはまだ実装して間がないので、Appleほど熟れていない。いくつか問題も残っている。しかし、それは着実に改善されている。開発者たちの情報交換も活発だ。私たちは、そのためのFacebook グループも立ち上げた。
ここが落としどころなのか？
BLEは、おそらくインターネットの巨大勢力にも屈しない新しい通信技術だ。まだ生まれたばかりなのに、すでにガキ大将のようだ。先日、ビルディング・オートメーションのプロジェクトを持ちかけられた。照明のコントロールにBLEが必要だというのだ。私は、その建物にはZigBeeが相応しいと思っていたのだ。どうやら、「スマートフォンやタブレットからコントロールできる」という言葉が、反BLE派が探し出した対抗意見をすべてなぎ倒してしまったようだ。しかし、うまくいかないこともある。大きな商用施設の中で、数百台ものセンサーをBLEを使って、ひとつのGSMゲートウェイに直接接続するという構想を持つスタートアップ企業と契約したことがあるのだが、残念なことに、今のBLEは最後の数メートルのための技術なので、異なる階から、または何枚もの壁を通して安定的に接続させることができなかった。
デバイスのためのサービス本位のアーキテクチャー
ソフトウェアアーキテクトという肩書きを持つ私は、BLEのある側面が妙に入り組んでいて、イライラさせられることがある。非常に低レベルの最適化と、非常に高レベルなアーキテクチャー概念が同居しているのだ。低い消費電力に最適化されたデザインで、転送する必要のあるデータ量を最小に抑えるようにしてある。しかし同時に、いわゆる「ジェネリック・アトリビュート・プロファイル」（GATT）も定義している。これには（たとえば、部屋の気温やバルブの開閉の状態といった）“キャラクタリスティック”、“サービス”と呼ばれる関連する特徴のセット、“プロファイル”と呼ばれる関連するサービスのセットが含まれる。プロファイルは使用目的に対応している。たとえば、血圧測定プロファイルは血圧の測定に使う、といった具合だ。サービスは再利用が可能なインターフェイスだ。たとえば、デバイス情報サービスはデバイスの製造者や製品番号などの情報を提供する。
ファームウェア地獄：ステロイド依存のDLL地獄
サービスはBLEの主要コンセプトだ。ひとつのサービスは、変更不能なキャラクタリスティックのセットを定義する。なぜ変更不能なのか。それにどんな意味があるのだろうか。理由はこうだ。低コストのデバイスは、ほとんどがファームウェアのアップデートを簡単に行えるようにはできていない。またはまったくできない。そのため、そうしたデバイスの販売を開始すると、サービスを変更したくなったときに問題が起きる。たとえば、便利なキャラクタリスティックを追加したいと思ったときだ。世の中に広まったすべてのデバイスに新しいファームウェアを届けることができない。アップデートされたスマートフォンのアプリが、古いデバイス上で新しいキャラクタリスティックにアクセスしようとすると、そこで厄介な問題が起きる。そうしたコンポーネント間のバージョンのミスマッチは、ソフトウェアの世界では“DELL hell”（DELL地獄）と呼ばれている。その場合、ミスマッチはファイルの互換性のあるセットを再インストールすることで解決されるが、互換性のないデバイスで、ファームウェアのアップデートができない場合は、もっと深刻な“ファームウェア地獄”に落ちる。
そのため、そのサービスを含むデバイスを出荷するとき、サービス定義“ServiceA”を変更不能にしておくのだ＜*注＞。後になってサービスを変更する必要が生じたとき、新しいサービス定義“ServiceA1”を追加する。これはServiceAの上位集合となるので、たとえば、追加のキャラクタリスティックを含むことができる。新しいデバイスは、その両方のサービスを実装する（追加のキャラクタリスティック以外は同一なら、そのほうが安い）。ここに4つの群がある。サービスの提供者（“ペリフェラル”）が、このサービスのユーザー（“セントラル”）と接続されたときの状態だ。セントラルをあなたのスマートフォンに置き換えて考えてみよう。
- オリジナルのサービスのためのアプリが入ったあなたのスマートフォンがオリジナルのデバイスに接続されると、スマートフォンはデバイスの中のServiceAを探す。それが見つかればオーケーとなる。
- オリジナルのサービスのためのアプリが入ったあなたのスマートフォンが拡張されたデバイスに接続されると、スマートフォンはデバイスの中のServiceAを探す。それが見つかればオーケー。アプリは、拡張されたデバイスが対応する追加のキャラクタリスティックについては知らないので、それを使うことはできない。しかしそれで問題はない。オリジナルの機能はきちんと提供できる。
- 拡張されたサービスのためのアプリが入ったあなたのスマートフォンが拡張されたデバイスに接続されると、スマートフォンはデバイスの中のServiceA1を探す。それば見つかればオーケー。アプリは追加キャラクタリスティックのことを知っているので、それを利用できる。
- 拡張されたサービスのためのアプリが入ったあなたのスマートフォンがオリジナルのデバイスに接続されると、スマートフォンはデバイスの中のServiceA1を探す。しかしデバイスは「なにそれ？ ServiceA1なんて知らない」と返す。そこでアプリは古いほうのServiceAを探す。それは見つかるので、古いデバイスとして機能することになる。新しいデバイスほどクールじゃないが、普通に使える。
以上の4つの状態を図解しよう。
古いデバイスはもう使われていないことがわかっている場合、またはもうサポートしないと決めた場合は、アプリの次のバージョンでは別の対応が必要になる。デバイスがServiceA1に対応していないとき、アプリはそれ以上の処理を諦めて、対応していないことをユーザーに知らせるようにするのだ。こうすれば、ユーザーが望む限りずっと古い荷物を引きずっていくといった心配がなくなる。
あらゆる種類のデバイスとアプリが相互に接続される将来は、このメカニズムが基本となる。デバイスとアプリの組み合わせには、さらに、新しいもの、ちょっと古いもの、かなり古いものの組み合わせも加わることになる。
コアにインターネット・プロトコル、周辺に他の技術
これからも、迷路のようなたくさんの裏道を私たちは走ることになるだろう。そこには、王道への入口や出口もいっぱいある。とくにネットワークの“周縁”では、いろいろな技術がしばらくは生き残るだろう。その中には、インターネット・プロトコルには対応せず、メッシュルーティングのような高度な機能は持たないが、BLEも含まれる。私は、BLEへの高い関心が最大の問題にならないことを祈っている。BLEをいろいろな形で拡張しようとするグループが数多くあり、新しいBluetooth 4.1の仕様にはBLEハブが組み込まれ、IPv6をBLE上で走らせようという試みもある。
しかし、その他のIoT周辺技術はどうなんだろう。使えそうなものもあるが、やはりIPの世界とシームレスに統合されることはないのだろうか。それらの利点（すでに利用できる、ジョブに完璧に合う、など）が、欠点（新技術を学ばなければならない、“ネットワークエフェクト”が少ない、など）を超えればよいのか？ 同様の疑問が、アプリケーションレイヤーのプロトコルの問題をクローズアップする。“モノのウェブ”に使う統一プロトコルとしてのHTTPについて、いつ真剣に考えればよいのか。MQTT、XMPP、AMQP、ZeroMQへはいつ移行したらよいのか、などだ。
みなさんの意見を聞かせてほしい。
*注：MicrosoftのComponent Object Model（COM）をご存知ならわかるだろう。BLEサービスと似て、COMインターフェイスは変更不能なメソッドの集合だ。私に言わせてもらえれば、これはMicrosoftから出てきたもののなかで、もっともイノベーティブで適切なアイデアだったが、その後に開発された.NETによって行き場を失った。最近、Windows Runtimeの開発者によって見直されている。
– Cuno Pfister
［原文］
