LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

IoTプラットフォームとは——製造業・設備・物流のデータ収集基盤

IoTプラットフォームとは、工場の設備や物流拠点のセンサー・デバイスから発生するデータを収集し、蓄積・可視化・制御までを一気通貫で担う基盤を指します。Microsoftは、世界で100億台を超えるデバイスがすでにネットワークに接続されていると説明しており^*5、製造業や設備管理、物流の現場でもセンサーやアクチュエータの活用が広がっています。

IoTデバイスは、人が操作しないまま稼働するセンサーやアクチュエータであることが多く、遠隔地に設置されて物理的なアクセスが難しい場合や、ファイアウォールの内側にあってインターネットから直接到達できない場合もあります^*5。バッテリー駆動で電力・処理能力に制約がある機器や、通信が不安定・低速な回線しか使えない機器も珍しくありません^*5。こうした特性を前提に基盤を設計する必要がある点が、一般的な業務システムとの違いといえるでしょう。

構成要素は6つ——デバイス管理・接続・データ収集蓄積・可視化分析・セキュリティ・OTA更新

IoTプラットフォームは単一の機能ではなく、複数の要素が組み合わさって成り立っています。AWSやAzureの公式資料をもとに整理すると、次の6つに大別できます。

デバイス管理——フリート全体の登録・監視

接続するデバイスの登録、認証情報の管理、稼働状況の監視を担う機能です。AWS IoT Coreは、サーバーのプロビジョニングなしでデバイスフリートを接続・管理・スケーリングできると説明しています^*1。Azure IoT Hubでは、接続を許可するデバイスやモジュールの情報をIDレジストリで管理する仕組みになっています^*5。

接続——MQTT・HTTPS・AMQPなどのプロトコル

デバイスとクラウドの間の通信を担う部分です。AWS IoT CoreはMQTT・HTTPS・MQTT over WSS・LoRaWANに対応しています^*1。Azure IoT HubもMQTT・AMQP・HTTPSに対応しており、通信はTLS1.2などによって暗号化されます^*5。プロトコルの詳細は次章で扱います。

データ収集・蓄積——ルールエンジンとメッセージルーティング

集めたデータをどこに送り、どう変換するかを制御する層です。AWS IoT Coreはビジネスルールに基づいてデバイスデータをフィルタリング・変換し、動的に処理できるとしています^*1。Azure IoT Hubは、Storageコンテナ・Event Hubs・Service Bus・Cosmos DBなど複数のAzureサービス宛にデータをルーティングする仕組みを備えます^*5。

可視化・分析——ダッシュボードと後続サービスとの連携

蓄積したデータをダッシュボードで確認したり、分析に活用したりする層です。Azure IoT Hubは、Stream AnalyticsやMachine Learning、Logic Appsといった他サービスと連携でき、リアルタイムのデータ活用に使えるとしています^*5。

セキュリティ——相互認証と通信の暗号化

デバイスのなりすましやデータの改ざんを防ぐ層です。AWS IoT Coreは相互認証とエンドツーエンド暗号化によってデバイス接続を保護すると説明しています^*1。Azure IoT HubはSASトークンまたはX.509証明書による認証に対応し、TLSで通信を保護する構成です^*5。総務省と経済産業省が公表したIoTセキュリティガイドラインでも、方針・分析・設計・構築接続・運用保守という5つの指針が示されており、機器のライフサイクル全体を通じた対策の必要性が指摘されています^*11。

OTA更新——ファームウェアの遠隔書き換え

現地に出向かずにファームウェアやソフトウェアを更新する層です。AWS IoT Jobsを使うと、ファームウェア更新や再起動、証明書のローテーションといった遠隔操作を複数デバイスへまとめて配信できます^*4。Azure IoT Hub向けのDevice Updateは、パッケージ単位・イメージ単位の更新に対応し、段階的なロールアウトや自動ロールバックの機能を備えています^*8。

接続を支えるMQTT——軽量なパブリッシュ/サブスクライブ方式

IoTプラットフォームの接続部分で広く使われているのがMQTTです。MQTTはパブリッシュ/サブスクライブ方式を採用しており、送信側(パブリッシャー)と受信側(サブスクライバー)がブローカーを介して通信します^*3。ブローカーは両者を、ネットワーク位置情報を交換しない空間的な分離、同時に稼働する必要がない時間的な分離、互いに干渉せず送受信できる同期の分離という3つの点で切り離す働きをします^*3。

メッセージの配送品質はQoS(Quality of Service)という3段階のレベルで選べます。レベル0は配信が1回までとなる方式、レベル1は少なくとも1回配信される方式、レベル2は正確に1回配信される方式です^*3。AWSは、MQTTがヘッダーサイズの小さい軽量な仕組みであり、帯域幅が限られ遅延の大きい不安定なネットワークでも動作しやすい点をIoTでの採用理由に挙げています^*3。

AWS IoT CoreとAzure IoT Hubはいずれも主要な接続方式としてMQTTを採用しており、HTTPSやAMQPといった別方式も選べる設計です^*1*5。センサー1台あたりの送信頻度やペイロードサイズが小さいというIoTの特性と、MQTTの軽量性は相性がよいといえるでしょう。

自前構築とクラウドIoTサービス活用——AWS IoT Core・Azure IoT Hub・Google Cloudの動向

基盤の作り方は大きく2通りに分かれます。オープンソースのMQTTブローカーやミドルウェアを組み合わせて自前で構築する構成と、クラウドベンダーが提供するマネージドIoTサービスを使う構成です。デバイス管理・スケーリング・監視の仕組みを一から作り込む自前構築は自由度が高い一方、運用の作り込みには相応の工数がかかります。

AWS IoT Coreは、デバイスフリートの接続・管理・スケーリングをサーバープロビジョニングなしで行える点と、ネイティブMQTTブローカーが永続接続と高度なメッセージ保持に対応する点を特徴として挙げています^*1。

Azure IoT Hubは、クラウドベースのIoTソリューションにおける中心的なメッセージハブとして機能し、数百万台のデバイスと1秒あたり数百万件のイベントに対応できるよう設計されています^*5。デバイスツイン(デバイスのプロパティを読み書きできる仕組み)やダイレクトメソッド(デバイスへのリクエスト応答型の命令)といった双方向通信の機能は、Standardティアで提供される点に注意が必要です^*6。

Google Cloudは事情が異なります。2022年8月、Googleは専用サービスであったIoT Coreの提供終了を発表し、2023年8月に終了しました^*10。同社は、IoT関連のアプリケーションやサービスに特化したパートナー各社の方が顧客のニーズに応えられるとの考えを理由として挙げています^*10。現在のGoogle Cloud公式アーキテクチャガイドでは、単体のMQTTブローカーだけでは足りない場合の構成として、MQTTブローカーとPub/SubやDataflowのMQTTコネクタを組み合わせる構成や、専門のIoTプラットフォームパートナーを活用する構成が案内されています^*9。つまりGoogle Cloudを選ぶ場合、AWSやAzureのような単一のマネージドIoTサービスではなく、複数のコンポーネントを組み合わせる前提での設計が必要になります。

費用構造の考え方——デバイス数・データ量・メッセージ数による従量課金

クラウドIoTサービスの多くは、デバイス数そのものよりも、送受信するメッセージ数やデータ量に応じた従量課金を採用しています。自社の費用感をつかむには、デバイス1台あたりの送信頻度とペイロードサイズを見積もることが出発点になります。

AWS IoT Coreはメッセージを5KB単位で計測しており、8KBのメッセージは2件として課金されます^*2。接続時間は1分単位で計測され、デバイスがAWS IoT Coreに接続していた合計時間に基づく課金です^*2。デバイスシャドウやレジストリの操作は1KB単位、ルールエンジンの処理は5KB単位で計測されます^*2。LoRaWANのFUOTA(ファームウェアの一括配信)は最初の100タスクまで無料で利用できます^*2。

Azure IoT Hubは、Basic/Standardティアでは4KBごとに、Freeティアでは0.5KBごとにメッセージ操作を課金する仕組みです^*7。サイズ1のユニットは1日あたり40万件・1.5GBまで、サイズ2は600万件・22.8GBまで、サイズ3は3億件・1144.4GBまでのメッセージを処理できる設計になっています^*6。ユニット数を増やすことで処理能力をスケールさせる仕組みで、サイズ2を1ユニット契約すると、サイズ1を15ユニット契約した場合と同じ日次上限になります^*6。

費用の見積もりでは、稼働台数だけでなく、1台あたりの送信頻度・ペイロードサイズ・双方向通信(デバイスツインやダイレクトメソッド)の利用有無を掛け合わせて試算する必要があります。PoC段階の少数台数では低コストに収まっても、本番スケールで数千台規模に拡大すると、メッセージ数やデータ量が桁違いに増える点は見落としやすいポイントといえるでしょう。

構築の進め方と外注の勘所——PoCからパイロット、本番スケールへ

IoTプラットフォームの構築は、いきなり全拠点・全設備へ展開するのではなく、段階を踏んで進める企業が多いといえます。まずはPoC(概念実証)として、少数のセンサーやデバイスで接続・データ収集・可視化までの一連の流れを検証するのが一般的な進め方です。この段階では、MQTTブローカーへの接続確認やダッシュボードの試作が中心になります。

次のパイロット段階では、実際の設備や現場に近い環境で、対象デバイス数を増やしながら運用に耐えるかどうかを確認します。OTA更新の仕組みやセキュリティ設定、異常時のアラート運用など、PoCでは検証しきれなかった項目を洗い出す段階です。

本番スケールでは、対象デバイス数の拡大にともなって、接続の安定性・メッセージ処理能力・費用のいずれもが変化します。Azure IoT Hubのようにユニット数を追加してスケールする仕組みや、AWS IoT Coreのように接続時間・メッセージ数に応じて従量課金される仕組みを踏まえ、拡大時の費用試算を事前に行っておくことが実務上の課題になります^*2*6。

この一連のプロセスを内製で担うには、デバイス管理・MQTTなどの通信プロトコル・クラウド側のルーティング設定・セキュリティ・OTA更新という複数領域の知識が求められます。専門パートナーに委託する場合は、PoCから本番スケールまでを一貫して依頼できるか、対象クラウド(AWS・Azureなど)の実績があるか、既存の設備・センサーとの接続実績があるかを確認します。

まとめ：IoTプラットフォーム構築で押さえる3つの判断軸

本稿ではIoTプラットフォーム構築について、構成要素・接続プロトコル・クラウドサービスの選択・費用構造という観点から整理しました。要点は3つに集約できるでしょう。第一に、IoTプラットフォームはデバイス管理・接続・データ収集蓄積・可視化分析・セキュリティ・OTA更新という6つの要素で構成されます。第二に、AWS IoT CoreとAzure IoT Hubはいずれもマネージドサービスとして機能を提供する一方、Google CloudはIoT Coreの提供を終了しており^*10、複数コンポーネントを組み合わせる設計が前提になります^*9。第三に、費用はデバイス数そのものよりもメッセージ数・データ量・接続時間による従量課金が中心であり、PoCからパイロット、本番スケールへと段階を踏むほど、費用と運用工数の見積もり精度が問われます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「AWS IoT Core」（サービス概要ページ）（https://aws.amazon.com/iot-core/）
2. *2　出典：AWS「AWS IoT Core Pricing」（https://aws.amazon.com/iot-core/pricing/）
3. *3　出典：AWS「What is MQTT? – MQTT Protocol Explained」（https://aws.amazon.com/what-is/mqtt/）
4. *4　出典：AWS「AWS IoT Jobs」（AWS IoT Developer Guide）（https://docs.aws.amazon.com/iot/latest/developerguide/iot-jobs.html）
5. *5　出典：Microsoft「What is Azure IoT Hub?」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/iot-hub/iot-concepts-and-iot-hub）
6. *6　出典：Microsoft「Azure IoT Hub scaling」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-scaling）
7. *7　出典：Microsoft「Understand Azure IoT Hub pricing」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-pricing）
8. *8　出典：Microsoft「Introduction to Device Update for Azure IoT Hub」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/iot-hub-device-update/understand-device-update）
9. *9　出典：Google Cloud「IoT platform product architecture」（Architecture Center）（https://docs.cloud.google.com/architecture/connected-devices/iot-platform-product-architecture）
10. *10　出典：TechCrunch「Google Cloud will shutter its IoT Core service next year」（2022年8月17日）（https://techcrunch.com/2022/08/17/google-cloud-will-shutter-its-iot-core-service-next-year/）
11. *11　出典：総務省「『IoTセキュリティガイドラインver1.0』及び意見募集の結果の公表」（2016年7月5日）（https://www.soumu.go.jp/menu_news/s-news/01ryutsu03_02000108.html）

Tweet