プロローグ — なぜ2026年にIoTクラウドを再点検すべきか

2018年頃にIoTクラウドプラットフォームを整理した人がいるとしたら、その表は今や半分が空白だ。最初の合図はGoogleが2023年8月にCloud IoT Coreを終了したこと。同じ年代、IBM Watson IoT Platformも2024年8月に追随して消えた。「ビッグスリークラウド」という表現はIoTでは通用しない。残ったのはAWSとAzureの2社のみで、両社とも自社マネージドIoTスタックを猛烈に拡張している。

だからといってマネージドIoTが死んだわけではない。むしろ逆だ。Particleはセルラー領域で堅固になり、Arduino CloudはIoT Cloud Editorを追加してメイカー・教育市場の参入障壁を下げ、Adafruit IOとBlynkは5ドル基板ユーザーの事実上のデフォルトになった。オープンソース陣営ではThingsBoardがフルスタック(メッセージブローカー・ルールエンジン・ダッシュボード)を束ねてセルフホストの選択肢を作り、BalenaがDockerベースのfleet管理でラズベリー・パイの量産級運用を可能にした。Mainfluxは2024年にMagistralaへリブランドされ、同じアーキテクチャを引き継ぐLF Edge親和の後継となった。エンタープライズ産業領域はBosch IoT SuiteとSchneider Electric EcoStruxureが獲った。EdgeランタイムはAzure IoT Edge・AWS Greengrass・Open Horizon(LF)・KubeEdge(CNCF)の4本に絞り込まれた。

> 「Googleが去った場所で、マネージドはより分化し、オープンソースはより堅くなった。」 — 2026年IoTクラウド地図の一文要約。

本稿の目的は、18のプラットフォームを同じ軸で分解して正直に比較することだ。比較のあとはDIYメイカー・スタートアップ・エンタープライズ・セルラー事業者の4シナリオでどの組み合わせが合うかの決定木まで描く。価格・機能の数値はすべて2026年5月時点であり、構造的な差に焦点を当てる。

価格はすぐ変わる。6か月後に数値が変わっても判断フレームは有効でなければならない。

1章 · 2026年のIoTクラウド地図 — 4分類

プラットフォームは数が多いように見えるが、結局は4分類に集約される。分類自体が意思決定の最初のボタンだ。

**(A) ハイパースケーラーIoT — AWS / Azure**

ハイパースケーラーが自社クラウド内にIoTスタックをマネージドで提供。AWS IoT Core・Greengrass・Device Defender・SiteWise、Azure IoT Hub・IoT Edge・Azure Sphere。強みは他のクラウドサービス(Lambda、Kinesis、Event Hubs、Stream Analytics、S3、Cosmos DB)との統合。弱みはロックインとデバイス当たりコスト。Google IoT Coreは終了し、IBM Watson IoTも消えた。

**(B) マネージドIoT専業 — Particle / Arduino / Adafruit / Blynk / Losant**

IoTそのものを本業とするSaaS。セルラーモデムまで束ねるParticle、メイカー・教育に強いArduino CloudとAdafruit IO、モバイルアプリビルダーが強いBlynk、産業・中間市場を狙うLosant。強みはドメイン集中とシンプルさ。弱みはハイパースケーラーほどのデータ分析・AI統合の深さがないこと。

**(C) オープンソースセルフホスト — ThingsBoard / Balena / Magistrala (Mainflux)**

自社でサーバーを運用するか自社クラウドに載せる。ThingsBoardはJavaフルスタック(MQTT・ルールエンジン・ダッシュボード)、BalenaはDockerベースのfleet管理(ラズベリー・パイ・NVIDIA Jetsonに強い)、MagistralaはGoマイクロサービスアーキテクチャ(Mainfluxの後継)。強みはデータ主権・ロックインなし・カスタマイズ性、弱みは運用負荷。

**(D) エンタープライズ産業IoT — Bosch / Schneider EcoStruxure**

産業・ビル・エネルギードメインに特化。Bosch IoT Suiteは自動車・インダストリー4.0、Schneider EcoStruxureは電力・HVAC・ビル自動化。強みはドメインモデルとOT(運用技術)統合、弱みは価格と閉鎖性。

この4分類の上に**Edgeランタイム**レイヤーが別に存在する。Azure IoT Edge、AWS Greengrass、Open Horizon(LF Edge配下)、KubeEdge(CNCF)の4本が市場を獲った。デバイス上でコンテナや関数を実行することが核心。

そして**プロトコル**レイヤー。MQTT 5.0が2018年の3.1.1を急速に置き換えつつあり、CoAP・AMQP・OPC UA・LoRaWAN・Sigfoxはそれぞれの領域で生き残っている。Matterはスマートホーム専用なので本稿では扱わない(別記事予定)。

> 4分類を頭に入れ、ここから順に見ていく。各章は同じテンプレート — Surface・強み、デバイスSDK、メッセージング・ルーティング、Edge・デバイス管理、価格、弱み、一行要約 — で整理する。

2章 · AWS IoT Core + Greengrass + Device Defender + SiteWise

**Surface・強み**

AWSのIoTスタックは単一サービスではなく**パズルピースの集合**だ。コアメッセージングはAWS IoT Core、エッジランタイムはAWS IoT Greengrass v2、セキュリティ・異常検知はAWS IoT Device Defender、産業資産モデリングはAWS IoT SiteWise、デバイス管理はAWS IoT Device Management、デバイスシミュレーション・テストはAWS IoT Device Tester。このモザイクが強みであると同時に学習曲線でもある。

**デバイスSDK**

公式SDKはC、C++、Python、JavaScript / Node.js、Java、Embedded C(FreeRTOS統合)。AmazonがFreeRTOSを2017年に買収して自社スタックに統合した成果として、2026年時点でESP32・STM32・Nordic・NXPでFreeRTOS + AWS IoT Device SDKの組み合わせが事実上の標準リファレンスになった。

**メッセージング・ルーティング**

MQTT 3.1.1とMQTT 5.0の両方をサポート。5.0の核心機能であるUser Properties、Reason Codes、Shared Subscriptions、Message Expiryは2024年からGA。メッセージはIoT Rules Engineを通過してLambda、Kinesis、S3、DynamoDB、SQS、SNS、Step Functions、Timestreamなどへルーティングされる。ルールエンジンはSQL風の構文。

-- 温度が80度を超えたらLambda呼び出し、全メッセージをTimestreamに保存

SELECT *, topic(2) AS device_id

FROM 'sensors/+/temperature'

WHERE temperature > 80

**Edge · Greengrass v2**

Greengrassはデバイス上でLambda関数、Dockerコンテナ、MLモデルを実行するエッジランタイム。v2はコンポーネントベースアーキテクチャ — `aws.greengrass.Cli`、`aws.greengrass.StreamManager`、`aws.greengrass.Nucleus`などのビルトインコンポーネントとカスタムコンポーネントを組み合わせる。デプロイは`greengrass-cli`またはクラウドコンソール経由。

**Device Defender · セキュリティ**

異常検知(Detect)、セキュリティ監査(Audit)、MQTTトピック単位のACL自動検証。2026年にはML基盤の異常検知がデフォルトに。脅威インテリジェンス統合もGA。

**SiteWise · 産業資産モデリング**

工場ラインのOPC UAサーバからデータを取得し、資産階層をモデル化する。SiteWise Edgeでオンプレミスでのデータ収集・集計が可能。産業IoTの中核ツール。

**価格**

- メッセージ: 100万件あたり約1ドル(米国東部基準)

- デバイス接続: 100万分あたり0.08ドル

- ルールエンジン: 100万ルール実行あたり0.15ドル

- Greengrass: デバイス当たり月0.16ドル(最初の1000台は無料)

- SiteWise: 資産・属性数に比例

実際の請求書で最大の項目はRules EngineとTimestream / Kinesisコストになることが多い。

**弱み**

- 学習曲線が急。6~7のサービスを習得しないとフルスタックが回らない。

- 他クラウドへデータを送るには追加作業が必要(取り込みは容易、送出はコスト・複雑度ともに上昇)。

- 100万台超の規模でデバイス当たりコストが負担になる(特にGreengrass)。

**一行要約**

> 最も完成度の高いスタック。学習曲線とロックインを受け入れられるならIoTの最終形。産業IoTまたはAWSコアインフラが既にある組織のデフォルト。

3章 · Azure IoT Hub + IoT Edge + Azure Sphere

**Surface・強み**

マイクロソフトのIoTスタックはAzure IoT Hub(コアメッセージング)、Azure IoT Edge(エッジランタイム)、Azure IoT Central(SaaS型IoTアプリプラットフォーム)、Azure Digital Twins(資産・関係モデリング)、Azure Sphere(MCU級セキュアOS・ハードウェア)で構成される。2025年にはAzure IoT Operationsが追加され、ArcベースのKubernetesエッジへ拡張された。

**デバイスSDK**

公式SDK: C、.NET、Python、Java、Node.js、Embedded C。Azure RTOS(旧ThreadX)が無料化されESP32・STM32でも動く。2025年にはAzure RTOSがEclipse Foundationへ移管され、**Eclipse ThreadX**として再オープンソース化された — マイクロソフトは引き続き主要コントリビュータ。

**メッセージング・ルーティング**

MQTT 5.0サポートは2024年GA。デバイス → IoT HubがD2C(device-to-cloud)、クラウド → デバイスがC2D(cloud-to-device)。メッセージはEvent Hubs、Service Bus、Blob Storage、Cosmos DBへルーティングされる。Device Twin — JSON文書でデバイス状態をミラーする中核抽象。これがAzureの最も独自な部分。

{

"deviceId": "thermostat-001",

"desired": { "targetTemp": 22, "fanSpeed": "auto" },

"reported": { "targetTemp": 22, "fanSpeed": "auto", "currentTemp": 23.4 }

}

`desired`はクラウドが望む状態、`reported`はデバイスが報告した実際の状態。両者が一致するまでデバイスが追従する。宣言的デバイス制御の標準パターン。

**Edge · IoT Edge**

Docker(正確にはMoby)ベースのコンテナランタイム。各モジュールはコンテナイメージとしてデプロイされる。Stream Analytics(エッジでSQL)、Function App、Custom Visionなどマイクロソフトサービスがモジュールとして提供。モジュール間通信は`edgeHub`というメッセージルータを介する。

**Azure Sphere — 終了したと思われたあのOS**

2024年に終了発表があったが2025年に生き残った。MediaTek MT3620 MCU + Plutonセキュリティサブシステム + LinuxベースのセキュアOS。MCU級デバイスに対しマイクロソフトが7年間セキュリティパッチを提供するモデル。価格はデバイス当たり一括8.95ドル(2026年時点)。

**Azure IoT Operations — 2025年の新規**

ArcでKubernetesエッジを束ねる新スタック。Kafkaベースの MQTTブローカー、OPC UAコネクタ、データ処理パイプラインが核心。産業IoTをArc + K8sで再構成する試み。

**価格**

- IoT Hub無料ティア: 日8000メッセージ(テスト用)

- B1: デバイス当たり月10ドルから開始、デバイス数とメッセージ頻度で変動

- IoT Edge: IoT Hub価格に含まれ、デバイス当たり追加コストなし(コアがオープンソースのため)

- Sphere: デバイス当たり8.95ドル一括

**弱み**

- Device Twinモデルは強力だが学習曲線がある。

- Azure IoT Centralはよくできているが価格が予測しにくい。

- Azure Sphereの将来は依然不透明。2024年の終了騒動で信頼が削られた。

**一行要約**

> Device TwinとEclipse ThreadXが武器。Azureインフラが既にある組織ではAWSと同等。マイクロソフトエコシステムとの統合が判断要因。

4章 · Google Cloud IoT Core終了(2023.8) — その意味

2022年8月16日、Googleが発表した。「Cloud IoT Coreを2023年8月16日に終了する。」1年間の移行期間。業界が揺れた。

**なぜ終了したか**

Googleの公式見解は「パートナーエコシステムが十分に成熟したため直接運用する必要がない」。実際の理由はもっと複雑だ。(a) AWS・AzureがIoTで圧倒的だったため追従が難しかった。(b) IoT Coreの売上がGCPの他領域に比べて小さかった。(c) デバイス当たりコスト構造がGCPの他サービスと合わなかった。

**移行の結果**

GoogleはClearBlade、Akenza、SoftServeなどのパートナーを推奨した。実際には多くのユーザーが**AWS IoT CoreまたはAzure IoT Hubへ移行**した。一部はThingsBoard・EMQXなどのオープンソースへ。

**残ったもの**

- Pub/Subは生き残った — IoTデータ取り込みのバックエンドとしてGCPで依然利用可能。

- BigQuery・DataflowはIoTデータ分析に強力 — 取り込みを別の場所で受けてBigQueryに入れればよい。

- Google Distributed Cloud Edgeはエッジコンピューティングに生き残ったがIoT Coreの直接後継ではない。

**意味**

ビッグテックがIoTを去ったことで市場は2方向に分かれた。(a) AWSとAzureがシェアを吸収した。(b) オープンソース陣営(ThingsBoard、EMQX、Magistrala)が反射的な利益を得た。「Googleが去った」この事件がオープンソースIoTを再浮上させた最大の動因だ。

> Googleが去った場所には、ロックインを恐れる組織がThingsBoardやMagistralaなどのオープンソースへ向かった。「また去るかもしれない」という恐れが判断基準になった。

5章 · IBM Watson IoT終了(2024.8) — もう一人の去ったビッグプレイヤー

2023年8月にGoogleが去った場所。その1年後、IBMが同じ道を歩んだ。

**Watson IoT Platform終了**

2023年12月、IBMはWatson IoT Platformを2024年12月に終了すると発表した。実際の終了日は予定通り進行。Maximo Application SuiteのIoT機能が一部を引き継いだが、「デバイス → クラウド → 分析」を統合マネージドで提供していたWatson IoTの座は空いた。

**なぜ**

Googleと似ている。(a) AWS・Azureに押された。(b) IBMのIoT営業は産業ソリューション(Maximo)に吸収され、デバイス課金型IoTサービスが別個に生き残るのが難しかった。(c) Red Hat買収後、IBMのIoT戦略はOpenShift・MQTT(HiveMQパートナーシップ)方向にシフトした。

**Maximoへの吸収**

IBM Maximo Application Suiteは資産管理SaaSで、IoTモニタリング・予知保全機能を含む。Watson IoTユーザーは(a) Maximoへ移行するか(b) AWS・Azureへ向かった。

**残ったIBM IoT資産**

- HiveMQパートナーシップ — MQTTブローカーの標準のひとつ。

- Red Hat AMQ Streams(Kafkaベース) — IoTデータ取り込みに使われる。

- OpenShift on Edge — エッジコンピューティングプラットフォーム。

> ビッグテックが「IoTは我々が直接やらない」という姿勢を二度連続で示した。Google・IBMが去った場所はAWS・Azureに集約されるか、オープンソースへ分散した。

6章 · Particle — マネージドセルラーIoTの覇者

**Surface・強み**

ParticleはセルラーIoTをマネージドで一気通貫に売る唯一の会社と言ってよい。デバイス(Photon 2 = Wi-Fi、Boron 404X = LTE-M、Tracker SoM = LTE-M+GPS)、セルラーSIM(自社回線または提携キャリア)、クラウド(Particle Cloud)、デバイスOS、SDKを一括で販売する。

**デバイスSDK・Device OS**

公式SDKは自社Device OS(C++ベース、ARM Cortex-Mシリーズ)とWiring互換API。Arduinoを知っていれば5分で書ける。Webhookで外部API呼び出し、Variables / Functionsでクラウドからデバイス関数を直接呼べる。

// Particle Device OS — 5分で習得するパターン

void setup() {

Particle.variable("temp", currentTemp);

Particle.function("setLed", setLed);

}

void loop() {

currentTemp = readTemp();

Particle.publish("temperature", String(currentTemp), PRIVATE);

delay(60000);

}

**セルラー領域の差別化**

ParticleはSIMカードを自社で発行し、グローバルLTE-Mローミングを提供し、データ料金までデバイスサブスクリプションに含める。**料金はMB単位**で、デバイス当たり月データ枠の範囲内で自由に使える。これがAWS・Azureにはない決定的価値だ。

**Edge · Mesh**

当初はMeshネットワーク(802.15.4ベース)を推していたが2020年に終了。現在はデバイス単位のセルラー・Wi-Fiに集中。Particle Edge SoMラインは産業用途。

**価格**

- デバイスアクティベーション: デバイス当たり一括約3ドル

- セルラーデータ: デバイス当たり月3MBまで約2ドルから、50MBまで約5ドル

- クラウドメッセージ: 無料枠あり、追加はメッセージ数ベース

- Photon 2(Wi-Fiデバイス): 約25ドル

- Boron 404X(LTE-M): 約50ドル

**弱み**

- デバイスがParticleハードウェアに縛られる。ESP32・STM32をそのまま使うのは難しい。

- グローバルセルラーローミングが一部の国(特に中国)で制約あり。

- 分析・AI統合はAWS・Azureほど深くない。

**一行要約**

> セルラーIoTをシンプルに始めたいならParticle。デバイス・SIM・クラウドを1社から受け取れる価値は圧倒的。ロックインは受け入れる前提。

7章 · Arduino Cloud + IoT Cloud Editor

**Surface・強み**

Arduinoが運営するIoTクラウド。2019年にArduino IoT Cloudとして始まり、2024年にIoT Cloud Editorを追加してブラウザから直接コードを書きデバイスにアップロードできるようになった。ESP32・MKRシリーズ・Nano IoT・Portenta・Niclaシリーズなど ArduinoボードだけでなくESP32 / ESP8266の一般ボードも一部サポート。

**デバイスSDK**

Arduino標準ライブラリ(ArduinoIoTCloud)。ボード宣言、変数マッピング、コールバック関数を数行で済ませる。

// Arduino IoT Cloud — 最短のパターン

#include "thingProperties.h"

void setup() {

Serial.begin(9600);

initProperties(); // クラウドで自動生成

ArduinoCloud.begin(ArduinoIoTPreferredConnection);

}

void loop() {

ArduinoCloud.update();

// 変数を変えるだけでクラウドに自動同期

}

`thingProperties.h`はArduino Cloudコンソールで変数を定義すると自動生成される。「コードはほとんど書かず変数だけ変える」が設計哲学。

**ダッシュボード**

ドラッグ&ドロップウィジェット(チャート、ゲージ、スイッチ、スライダー、アラートなど)。誰でも15分以内に自分のIoTダッシュボードを作れる。これがArduinoがメイカー・教育市場のデフォルトになった核心理由。

**価格**

- Free: デバイス1台、データ容量制限あり

- Maker: 月5ドル、デバイス25台

- Maker Plus: 月10ドル、デバイス100台

- School: 教室向け別プラン

- Pro: デバイス当たり価格、産業用機能を含む

**弱み**

- デバイス数制限が厳しい(Free 1台、Maker 25台)。産業規模は不可。

- データ分析は基本可視化レベル。外部にデータを出さないと分析できない。

- コード自由度が低い — 変数モデルに合わせる必要がある。

**一行要約**

> メイカー・学生・教室のデフォルト。産業規模にしたいなら別のところへ行くが、学習曲線の最初の30分はArduino Cloudが最短。

8章 · Adafruit IO・Blynk — メイカー市場の二大巨頭

**Adafruit IO**

ハードウェア会社Adafruitが運営するIoTクラウド。ESP32・ラズベリー・パイ・Circuit Playgroundなどどんなボードでも MQTT・HTTPで接続できる。設計がシンプル — Feeds(データストリーム)、Dashboards(可視化)、Triggers(条件 → アクション)、Actions(Webhook)。それで全部。

Adafruit IO — Pythonクライアントの一行

from Adafruit_IO import Client

aio = Client("your_user", "AIO_KEY")

aio.send_data("temperature", 23.5)

**価格**

- Free: データ30日保持、30点/分処理量、Feeds 10個、Dashboards 5個

- IO+: 月10ドル、データ60日保持、60点/分、Feeds・Dashboards無制限

**Blynk**

モバイルアプリビルダーがシグネチャ。ウィジェットをドラッグしてデバイス制御アプリを作れる。2018年頃の1.0が無料だったが、2021年にBlynk IoT(2.0)としてクラウドベースで再ローンチ。現在はSaaSモデル。

**価格**

- Free: デバイス2台、メッセージ100件/日

- Plus: 月8.99ドル、デバイス10台、メッセージ500件/日

- Pro: 月19.99ドル、デバイス50台、メッセージ5,000件/日

- Business: デバイス当たり価格、ホワイトラベルアプリ対応

**Adafruit vs Blynkの決定木**

- モバイルアプリが先 → **Blynk**(ドラッグ&ドロップアプリビルダー)

- Webダッシュボードで足りる → **Adafruit IO**またはArduino Cloud

- Adafruitでハードウェアも買いたい → **Adafruit IO**

- ホワイトラベルモバイルアプリ → **Blynk Business**

**弱み(共通)**

- スケール上限が明確。デバイス100台を超えると別プラットフォームへ。

- データ分析・AI統合はほぼない。

**一行要約**

> Adafruit IOは最もシンプルなIoT、Blynkは最速のモバイルアプリビルダー。両方ともメイカー・趣味・教育のデフォルト、産業規模には合わない。

9章 · ThingsBoard — オープンソースフルスタックの標準

**Surface・強み**

2017年に始まったJava / Spring基盤のオープンソースIoTプラットフォーム。フルスタックという点が決定的だ — MQTT / CoAP / HTTPブローカー、デバイス管理、ルールエンジン、ダッシュボード、ユーザー・テナント管理、アラームまで1パッケージに束ねている。Apache 2.0のCommunity Editionと商用のProfessional Editionがある。

**アーキテクチャ**

- コア: Java Spring Boot、PostgreSQLまたはCassandra(時系列用)

- メッセージキュー: Kafkaまたは自社キュー(開発用)

- ルールエンジン: ノードベースのビジュアルエディタ(Node-RED風)

- ダッシュボード: ウィジェットライブラリ + カスタムウィジェット

**デバイスSDK**

公式SDK: Python、Java、C(MQTT)、JavaScript、Node.js。MQTTさえ分かればどんなデバイスも接続できる。デバイスプロファイルという抽象があり、デバイス種別ごとのテレメトリキー・属性・トランスポート設定を事前定義できる。

**ルールエンジン — シグネチャ**

ThingsBoardのルールエンジンは他プラットフォームと最も異なる見た目をしている。メッセージが入るとノードグラフを流れる。「温度80度超 → Slack通知 + DB保存 + アラーム生成」のようなロジックをコードなしでGUIで描く。

[Device Telemetry Upload]

↓

[Filter: temperature > 80]

↓

[Save Timeseries] → [Create Alarm] → [Slack Webhook]

このビジュアルなルールエンジンのおかげで非開発者でも運用ポリシーを作れる。

**ダッシュボード**

50以上のビルトインウィジェット。カスタムウィジェットはJavaScriptで作る。テナント別のホワイトラベルが可能。

**Edge · ThingsBoard Edge**

オンプレミスゲートウェイまたはエッジサーバでThingsBoardコアの一部を実行する方式。クラウドと双方向同期。産業現場のゲートウェイによく合う。

**Professional Edition — 商用差別化**

Community Editionは無料だが、高度な機能(クラスタリング、細粒度RBAC、ホワイトラベル、高度なアラーム、OAuth2)はProにある。Pro価格はインスタンス・テナント数・機能により交渉。

**弱み**

- Java・PostgreSQL・Kafka・Cassandraをすべて運用しなければならない。運用負荷が大きい。

- 大規模(数十万デバイス)ではCassandraチューニングが必要。

- ライセンス分離 — CommunityにあるものとProのみのものを事前に把握する必要がある。

**一行要約**

> オープンソースフルスタックIoTの事実上の標準。クラウドロックインを避けつつフル機能が必要な時のデフォルト。運用人員がいるなら強力な選択。

10章 · Balena(旧resin.io) — Dockerベースfleet管理

**Surface・強み**

2013年にresin.ioとして始まり2018年にBalenaへリブランド。デバイス上で**Dockerコンテナを運用するfleet管理**プラットフォーム。ラズベリー・パイ、NVIDIA Jetson、BeagleBone、Intel NUCなどLinuxデバイスに強い。ラズベリー・パイ100台を一気にデプロイ・更新・モニタリングしたければBalenaがほぼデフォルト。

**Balenaスタック**

- balenaOS: Yoctoベースの最小Linux OS。ブート・更新・復旧を自動化。

- balenaEngine: Mobyベースの軽量コンテナランタイム(Docker互換)。

- balenaCloud: SaaS型fleet管理コンソール。

- openBalena: セルフホスト可能なオープンソース版。

**デバイスSDK・コンテナモデル**

別途のデバイスSDKがない — **コンテナそのものがSDK**だ。開発者は自分のアプリをDockerイメージにし、Balenaへ`git push`するとデバイスにデプロイされる。

Balenaの最短ワークフロー

balena push my-fleet

balenaCloudビルダーがマルチアーキテクチャイメージをビルド → 全デバイスにOTAデプロイ

このシンプルさが決定的。CI / CDが`git push`で終わる。

**OTA・A/B更新**

balenaOSはA/Bパーティションを持っており、更新失敗時に自動ロールバック。コンテナ単位の更新はより速く安全。

**価格・balenaCloud**

- Free: デバイス10台まで、一部機能制限

- Production: デバイス当たり月約3ドルから(年間契約)

- Enterprise: 交渉

**openBalena**

完全オープンソース版。balenaCloudのAPI互換バックエンドをセルフホスト可能。無料だが運用負担あり。

**弱み**

- デバイスがLinux SBC級(ラズベリー・パイ・Jetson)でないと合わない。MCUは対象外。

- コンテナイメージサイズで帯域に負担(特にセルラーで)。

- balenaCloudはSaaS — セルフホストするにはopenBalena。

**一行要約**

> ラズベリー・パイ100台を運用しなければならないならBalenaがデフォルト。「DockerコンテナがIoTファームウェアに取って代わる」という哲学の最も成熟した実装。

11章 · Mainflux → Magistrala — オープンソースのリブランド

**Mainfluxの歴史**

2016年に始まったGoベースのオープンソースIoTプラットフォーム。マイクロサービスアーキテクチャ(MQTTブローカー、HTTPゲートウェイ、NATSメッセージバス、PostgreSQL、Redis、InfluxDBなど)。Apache 2.0ライセンス。軽量で拡張可能なのが強みだった。

**なぜMagistralaに変わったか**

2024年、MainfluxはMagistralaへリブランドされた。同じチーム(Abstract Machines)が作り、同じアーキテクチャを引き継ぐ。変更理由は(a) 商標・法的整理、(b) LF Edge配下プロジェクトへの道筋、(c) 新機能(認証・権限・ポリシー)追加に伴い新しい名前が必要だった。

**アーキテクチャ**

- コア: Goマイクロサービス — 各機能が別コンテナに分離。

- メッセージバス: NATS(高性能pub/sub)。

- プロトコル: MQTT、HTTP、CoAP、WebSocket、OPC UA。

- ストレージ: PostgreSQL(メタ)、InfluxDB / TimescaleDB(時系列)。

- 認証・権限: Magistralaの新ポリシーエンジン(OPAベース)。

**Mainflux vs Magistralaの新点**

- ポリシーエンジン統合 — OPA(Open Policy Agent)ベースの細粒度認可。

- ドメインモデル整理 — Things、Channels、Domains、Groupsなどの抽象を明確化。

- LF Edge互換 — Open Horizon・EdgeXなどLF Edgeプロジェクトとの統合像。

**デバイスSDK**

標準MQTT / HTTP / CoAPさえ知っていれば接続できる。別途SDKを強制しないのが哲学。

**価格**

オープンソース — 無料。商用サポートはAbstract Machinesと交渉。

**弱み**

- ThingsBoardよりダッシュボード・ルールエンジンが弱い。可視化は外部ツール(Grafanaなど)で補う必要がある。

- コミュニティサイズはThingsBoardより小さい。

- リブランド直後の移行関連の摩擦が一部残る。

**一行要約**

> Goベースの軽量マイクロサービスIoTコア。ダッシュボードより バックエンドを重視し、自前で可視化ツールを付ける用意があるなら強力な選択。LF Edge陣営の自然な合流地点。

12章 · Losant / Bosch IoT Suite / Schneider EcoStruxure — エンタープライズ

**Losant**

米国発のエンタープライズIoTプラットフォーム。デバイス管理、ビジュアルワークフローエンジン、ダッシュボード、ユーザー管理、ホワイトラベルオプションを束ねて販売。産業IoT・中間市場がターゲット。ワークフローエンジンがシグネチャ — ノードベースのGUIでデータ処理・通知・統合を描く。

価格: デバイス数・ワークフロー実行数ベース。見積もり交渉。

**Bosch IoT Suite**

ドイツのBoschが運営するIoTプラットフォーム。自動車・インダストリー4.0・HVAC・ビル自動化ドメインに特化。Eclipse IoTプロジェクト(Ditto、Hono、Vorto、Kanto)の主要コントリビュータであり、自社の商用スタックをEclipseの上に積んでいる。

- Bosch IoT Things(Eclipse Dittoベース) — デジタルツイン。

- Bosch IoT Hub(Eclipse Honoベース) — デバイス接続性。

- Bosch IoT Insights — 分析。

- Bosch IoT Manager — デバイス管理。

Eclipseの上に積んだおかげで閉鎖的でないという利点。価格はエンタープライズ交渉。

**Schneider Electric EcoStruxure**

フランスSchneider ElectricのIoT・OT統合プラットフォーム。電力・HVAC・ビル自動化・産業自動化ドメイン。ドメイン深度が差別化要因。

- EcoStruxure Building Advisor — ビル運用最適化。

- EcoStruxure Power Monitoring Expert — 電力モニタリング。

- EcoStruxure Asset Advisor — 資産予知保全。

- EcoStruxure Augmented Operator Advisor — ARベース運用者補助。

価格はシステムインテグレータ(SI)経由の交渉が一般的。

**エンタープライズ決定木**

- 一般産業IoT、自社ドメインが大きい → **Losant**または**Bosch IoT Suite**

- 自動車・インダストリー4.0 → **Bosch IoT Suite**

- 電力・HVAC・ビル → **Schneider EcoStruxure**

- AWS・Azureインフラが既にある → **AWS IoT + SiteWise**または**Azure IoT Hub + Digital Twins**

**弱み(共通)**

- 価格が不透明。デバイス当たりコストが分かりにくい。

- SI依存度が高い — 自社開発チームだけでフル構築するのが難しい場合が多い。

- 一部はドメイン外利用で違和感がある。

**一行要約**

> 産業ドメインモデルとOT統合が必要な時に行く場所。自動車・電力・ビルなど深いドメインならAWS・Azureより速く価値を作る。価格は交渉の領域。

13章 · Edgeランタイム — Azure IoT Edge / AWS Greengrass / Open Horizon / KubeEdge

**なぜEdgeランタイムが別カテゴリで存在するか**

デバイス上でコード・コンテナ・MLモデルを実行できる必要がある。クラウドへすべてのデータを送るモデルは(a) 帯域、(b) レイテンシ、(c) オフライン動作で限界が明確。だからEdgeランタイムが分離したカテゴリとして存在する。

**Azure IoT Edge**

Docker(Moby)ベースコンテナランタイム。モジュール単位デプロイ。`edgeAgent`・`edgeHub`の2システムモジュールがコア。Stream Analytics、Function App、Custom Visionをモジュールとして提供。Device Twin・ルーティングモデルがクラウドと一貫しているのが強み。

**AWS Greengrass v2**

コンポーネントベース。自社コンポーネント + ビルトインコンポーネント(StreamManager、Lambda、Docker、ML、CLIなど)。Lambda関数をデバイス上で直接実行できるのがシグネチャ。ML推論コンポーネントでSageMaker Neoモデルをデプロイ。

**Open Horizon(LF Edge)**

IBMが寄贈してLF Edge配下になったオープンソースエッジオーケストレーション。自律ポリシーベース — デバイスにポリシーを付与すると、マッチするワークロードが自動デプロイされる。クラウド依存がない点が差別化。100万デバイス規模を目標に設計。

**KubeEdge(CNCF)**

Kubernetesをエッジへ拡張したCNCF卒業プロジェクト。デバイスをK8sノードのように扱い、kubectlでデバイスへワークロードをデプロイする。クラウド側コンポーネント(CloudCore)とエッジ側コンポーネント(EdgeCore)で構成。K8s運用経験のあるチームに自然。

**比較表**

| 項目 | Azure IoT Edge | AWS Greengrass v2 | Open Horizon | KubeEdge |

|---|---|---|---|---|

| ライセンス | MIT(コア) | Apache 2.0 | Apache 2.0 | Apache 2.0 |

| クラウド依存 | Azure | AWS | なし(自律) | なし(自K8s) |

| デバイスモデル | Dockerコンテナ | コンポーネント + Lambda | コンテナ + ポリシー | K8sノード |

| デバイス数目標 | 数万 ~ 数十万 | 数万 ~ 数十万 | 100万+ | 数十万 |

| シグネチャ | Device Twin | Lambda on Edge | ポリシーベース自律デプロイ | kubectlでデバイス管理 |

**選択ガイド**

- Azureクラウド利用中 → **Azure IoT Edge**

- AWS利用中、Lambdaに親しみ → **AWS Greengrass**

- クラウドロックイン回避、大規模自律デプロイ → **Open Horizon**

- 既にK8sを運用、デバイスをK8s式に扱いたい → **KubeEdge**

> Edgeランタイムの選択はIoTプラットフォーム選択と部分的に分離可能。AWS IoT Coreを使いつつKubeEdgeでエッジを運用する組み合わせもあり得る。

14章 · プロトコル — MQTT 5.0 / CoAP / AMQP / OPC UA / LoRaWAN / Sigfox

**MQTT 5.0 — 事実上の標準**

MQTTはIoTの基本プロトコル。3.1.1から5.0への移行で(a) User Properties(メタデータ)、(b) Reason Codes(エラー明確化)、(c) Shared Subscriptions(負荷分散)、(d) Message Expiry、(e) Flow Control(フロー制御)が追加された。2024年GAの後、2026年現在はすべての主要プラットフォームが5.0をサポート。

**CoAP — RESTのIoT版いとこ**

UDPベース、HTTP風メソッド(GET / POST / PUT / DELETE)、Observeパターン。非常に軽量で(a) バッテリー・メモリ制約の大きいデバイス、(b) 6LoWPAN / Threadネットワークに合う。AWS IoT Core・Magistrala・ThingsBoardがサポート。

**AMQP — エンタープライズメッセージキュー**

RabbitMQ・Azure Service Busが代表。IoTより エンタープライズメッセージキューの標準。Azure IoT HubはAMQPを一オプションとして提供。MQTTより重いがより豊富なメッセージ意味論。

**OPC UA — 産業オートメーションの標準**

工場・プラントのPLC・SCADAからデータを取り込む標準。AWS IoT SiteWise・Azure IoT Operations・KEPServerExなどのミドルウェアがMQTT / AMQPに変換してクラウドへ上げる。産業IoTのデフォルト。

**LoRaWAN — 低消費電力広域**

1日1回送信、数年間バッテリー。農業・資産追跡・都市インフラに強い。The Things Network・ChirpStackなどのLoRaWANネットワークサーバがAWS・Azureへデータを送る。AWSはIoT Core for LoRaWANを直接提供。

**Sigfox — 超低消費電力広域、事業的に揺らぐ**

2022年にSigfox SAが破産しUnaBizに買収された。2026年現在ネットワークは稼働中だが将来は不透明。新規プロジェクトはLoRaWANかNB-IoTを検討するのが安全。

**プロトコル決定木**

- 一般IoTデバイス → **MQTT 5.0**

- 非常に制約のあるデバイス、IPv6 / Thread → **CoAP**

- エンタープライズメッセージキュー統合 → **AMQP**

- 工場・プラント → **OPC UA**

- 農業・資産追跡・低消費電力 → **LoRaWAN**

- セルラー広域低消費電力 → **NB-IoT**または**LTE-M**(Sigfoxは新規推奨しない)

15章 · 韓国・日本 — 自国市場のIoTクラウド

**サムスンSmartThings Cloud**

サムスンのコンシューマー・ホームIoTプラットフォーム。Matter標準に合わせて進化中。家電・ホームデバイスが強み。2024年からSmartThings Proで商用ビル領域へ進出。外部デバイス統合はSmartThings APIを通じて可能。

**LG ThinQ Cloud**

LGのコンシューマーIoTプラットフォーム。家電(冷蔵庫、洗濯機、エアコン)に強い。ThinQ AIという音声・画像モデルが家電と統合。外部開発者にはLG Open Platformが一部開かれているが限定的。

**KT IoT**

KTのLTE-M・NB-IoTベースのセルラーIoTプラットフォーム。韓国国内のLPWAネットワークの中核。AWS・Azureとのパートナーシップを通じてクラウド連携。産業・インフラ(ガス・電力・水)領域に強い。

**SKテレコム・LG U+**

各自のIoTプラットフォームを運用するがKT比でIoT専門ブランドのプレゼンスは弱い。SKTはifland・メタバース・AIへ転換中、LG U+は家庭・メディアに集中。

**Sony Edge AI**

Sony Semiconductor SolutionsのエッジAIプラットフォーム。IMX500・IMX501のようなカメラセンサ内部でAI推論を回す。カメラ自体がIoTデバイスというモデル。クラウド側ではAITRIOSというSaaSでfleet管理。

**NEC IoT**

NECの産業IoT・スマートシティプラットフォーム。日本の政府・自治体プロジェクトに強い。顔認識・生体認証をIoTと組み合わせるソリューションがシグネチャ。

**Hitachi Lumada**

日立の産業IoT・デジタルプラットフォーム。自動車・鉄道・電力・水ドメインに特化。自社のOT資産が深いことが差別化要因。AWS・Azureとのパートナーシップも運営。

**NTT Communications・NTT Data**

日本・アジアの通信事業者。セルラーIoT回線(NTT DocomoのLTE-M・NB-IoT)とクラウド(NTT ComのEnterprise Cloud)を束ねて販売。グローバルセルラーIoTでParticleの競合格。

**韓国・日本市場のパターン**

- コンシューマーIoTは自国家電ブランド(サムスン・LG・Sony・パナソニック)が獲った。

- セルラーIoTは通信事業者(KT・NTT)が自国市場を押さえた。

- 産業IoTは総合電機・重工業(LG CNS・日立・NEC)がSI形で持っていく。

- AWS・Azureは韓国・日本でも多国籍企業・スタートアップのデフォルトだが、自国の通信・産業層では国内プラットフォームが優勢。

> グローバルプラットフォームだけ見ていたら自国市場の半分を逃す。韓国・日本でIoTプロジェクトをやるなら自国の通信事業者・家電・SIのIoT資産を必ず併せて見る。

16章 · 誰が何を選ぶべきか — 4シナリオの決定木

**シナリオA · DIYメイカー / 学生 / 1-10台**

- 予算最小、学習曲線最小 → **Adafruit IO**または**Arduino Cloud**

- モバイルアプリ優先 → **Blynk**

- 自前インフラがほしく学習意欲がある → **ThingsBoard Community Edition** + ラズベリー・パイ

- コードを書かず変数だけ → **Arduino Cloud + IoT Cloud Editor**

**シナリオB · スタートアップ / 100-10,000台**

- Wi-Fiデバイス、AWSインフラ → **AWS IoT Core**

- セルラーデバイス、グローバル → **Particle**

- ロックイン回避、運用人員あり → **ThingsBoard PE**または**Magistrala** + 自社クラウド

- ラズベリー・パイfleet → **Balena**

- メッセージ量少なくシンプルさ優先 → **Adafruit IO+**(ただし10Kが限界)

**シナリオC · エンタープライズ / 10,000-1,000,000台**

- 産業IoT、AWS利用 → **AWS IoT Core + Greengrass + SiteWise**

- 産業IoT、Azure利用 → **Azure IoT Hub + Edge + Digital Twins**

- 自動車・インダストリー4.0 → **Bosch IoT Suite**

- ビル・電力・HVAC → **Schneider EcoStruxure**

- クラウドロックイン回避、100万+ → **Open Horizon**または**KubeEdge** + オープンソースコア

- K8s運用中 → **KubeEdge** + **EMQX / HiveMQ** + **InfluxDB / TimescaleDB**

**シナリオD · セルラーIoT事業者**

- グローバルセルラーfleet → **Particle**

- 韓国LPWA → **KT IoT**

- 日本セルラー → **NTT Communications**

- セルラー + AWS → **AWS IoT Core for LoRaWAN** + 自社SIM

- セルラー + Azure → **Azure IoT Hub** + Azure SIM

**シナリオE · コンシューマー家電 / スマートホーム**

- 韓国家電統合 → **サムスンSmartThings**または**LG ThinQ**

- 日本家電統合 → **Sony AITRIOS**または自国家電ブランドAPI

- グローバルスマートホーム → **Matter**標準 + 自社マネージド(別記事予定)

**プラットフォーム選択の誤った合図5つ**

1. **ベンチマークメッセージ/秒の数字だけ見る。**実運用ではデバイス管理・ルールエンジン・ダッシュボードがより重要なことが多い。

2. **無料ティアだけ見る。**デバイス数が増えると価格が爆発するプラットフォームが多い。1万台基準で月額を推定する。

3. **ハイパースケーラーだけ見る。**ロックイン受容の準備ができていないなら、オープンソースの運用コストを計算し直す。

4. **自国プラットフォームを無視する。**韓国・日本市場では自国の通信・家電・SIが決定的資産を持つ。

5. **単一プラットフォームだけ見る。**AWS IoT Core + ThingsBoardダッシュボード、Particle + Azureバックエンドのような組み合わせがよくある。

17章 · アンチパターン · よくある失敗

1. **ハイパースケーラーを自動で選ぶ。**「AWS使ってるからAWS IoT」という推論が当たる場合もあるが、デバイス数・メッセージ頻度・分析深度によっては別の選択がより安く単純な場合が多い。

2. **Googleが去った事件を忘れる。**ビッグテックがIoTサービスを終了した前例がある。ロックインを恐れるべき理由。データ取り込みは標準プロトコル(MQTT 5.0)で、データは標準フォーマット(JSON / Parquet)に置けば移行が容易。

3. **セルラーコストを推定しない。**デバイス当たり月データコストがIoTプラットフォームコストの5~10倍になることが多い。クラウド請求書だけ見たら真のコストを見逃す。

4. **Edgeランタイムを後から追加する。**デバイスが増えた後にエッジ処理を追加するとアーキテクチャ再設計が必要。最初からエッジ処理が必要かを判断する。

5. **デバイスセキュリティを後付けする。**AWS IoT Device Defender、Azure Defender for IoT、ThingsBoardのOAuth2のようなセキュリティツールは最初からオンにする。100万台になってからセキュリティ事故が起きれば コストは1000倍。

6. **オープンソース運用コストを過小評価する。**ThingsBoard・Magistrala・EMQXを自前運用するならSRE・DBA・セキュリティ人員が必要。マネージドとの真のコストを計算する。

7. **プロトコルロックインを忘れる。**AWSの非標準MQTT拡張(例: HTTP-MQTT変換)に依存すると移行が困難。標準MQTT 5.0だけを使うよう強制する。

18章 · 次回予告 · 結論

次回は**Matter標準とスマートホームIoT 2026** — サムスンSmartThings、Apple Home、Google Home、Amazon AlexaのMatter互換状況と、家庭用IoTがビッグテック5社に圧縮されていく像を見る。その後は**OPC UA + 産業IoT 詳説** — 工場・プラントのPLC・SCADAからどのようにデータを引き出してAWS IoT SiteWise・Azure IoT Operationsへ上げるかの実アーキテクチャ。

**核心整理**

- ハイパースケーラーIoTはAWS・Azureの2社のみ。Google IoT Core(2023.8)・IBM Watson IoT(2024.8)は終了。

- マネージドはParticle(セルラー)、Arduino Cloud(メイカー)、Adafruit IO・Blynk(趣味)に分化。

- オープンソースはThingsBoard(フルスタック)、Balena(Docker fleet)、Magistrala(Mainflux後継)が定着。

- エンタープライズはBosch IoT Suite・Schneider EcoStruxure・Losantがドメインを獲得。

- EdgeランタイムはAzure IoT Edge・AWS Greengrass・Open Horizon・KubeEdgeの4本。

- プロトコルはMQTT 5.0が標準、OPC UAが産業、LoRaWANがLPWAで生きる。

- 韓国・日本は自国の通信・家電・SI(KT・NTT・サムスン・LG・Sony・日立)が自国市場の半分を獲った。

> 2026年のIoTの本質は「どのハイパースケーラーを使うか」ではなく **「デバイス数・データ主権・ロックイン回避・運用人員」の4軸でどこに立つか**である。18のプラットフォームはこの4軸のどこかに位置している。自分の座標を正確に分かれば、答えは3つに絞られる。

参考 / References

- [AWS IoT Core — Overview](https://aws.amazon.com/iot-core/)

- [AWS IoT Greengrass v2 — Developer Guide](https://docs.aws.amazon.com/greengrass/v2/developerguide/)

- [AWS IoT Device Defender](https://aws.amazon.com/iot-device-defender/)

- [AWS IoT SiteWise](https://aws.amazon.com/iot-sitewise/)

- [Azure IoT Hub — Documentation](https://learn.microsoft.com/en-us/azure/iot-hub/)

- [Azure IoT Edge — Documentation](https://learn.microsoft.com/en-us/azure/iot-edge/)

- [Azure Sphere — Documentation](https://learn.microsoft.com/en-us/azure-sphere/)

- [Azure IoT Operations — Overview (2025)](https://learn.microsoft.com/en-us/azure/iot-operations/overview-iot-operations)

- [Google Cloud IoT Core Retirement Notice](https://cloud.google.com/iot/docs/release-notes)

- [IBM Watson IoT Platform Retirement](https://www.ibm.com/cloud/architecture/architectures/iotArchitecture/)

- [Particle — Cellular IoT Platform](https://www.particle.io/)

- [Arduino IoT Cloud](https://cloud.arduino.cc/)

- [Adafruit IO](https://io.adafruit.com/)

- [Blynk IoT](https://blynk.io/)

- [ThingsBoard — Open-Source IoT Platform](https://thingsboard.io/)

- [Balena — Container-based IoT](https://www.balena.io/)

- [Magistrala (Mainflux successor)](https://github.com/absmach/magistrala)

- [Losant — Enterprise IoT Platform](https://www.losant.com/)

- [Bosch IoT Suite](https://bosch-iot-suite.com/)

- [Schneider Electric EcoStruxure](https://www.se.com/ww/en/work/campaign/innovation/overview.jsp)

- [Open Horizon — LF Edge](https://www.lfedge.org/projects/openhorizon/)

- [KubeEdge — CNCF](https://kubeedge.io/)

- [MQTT 5.0 Specification — OASIS](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)

- [CoAP — RFC 7252](https://datatracker.ietf.org/doc/html/rfc7252)

- [OPC UA — OPC Foundation](https://opcfoundation.org/about/opc-technologies/opc-ua/)

- [LoRaWAN — LoRa Alliance](https://lora-alliance.org/about-lorawan/)

- [Sigfox / UnaBiz](https://www.unabiz.com/)

- [Samsung SmartThings](https://www.smartthings.com/)

- [LG ThinQ](https://www.lg.com/global/lg-thinq/)

- [Sony AITRIOS](https://www.aitrios.sony-semicon.com/en/)

- [Hitachi Lumada](https://www.hitachi.com/products/it/lumada/global/en/index.html)

- [NTT Communications](https://www.ntt.com/en/services/network/iot.html)