IoTクラウドプラットフォーム 2026 — AWS IoT Core / Azure IoT Hub / Particle / Arduino Cloud / ThingsBoard / Balena / Magistrala (Mainflux) 徹底比較

• プロローグ — なぜ2026年にIoTクラウドを再点検すべきか
• 1章 · 2026年のIoTクラウド地図 — 4分類
• 2章 · AWS IoT Core + Greengrass + Device Defender + SiteWise
• 3章 · Azure IoT Hub + IoT Edge + Azure Sphere
• 4章 · Google Cloud IoT Core終了(2023.8) — その意味
• 5章 · IBM Watson IoT終了(2024.8) — もう一人の去ったビッグプレイヤー
• 6章 · Particle — マネージドセルラーIoTの覇者
• 7章 · Arduino Cloud + IoT Cloud Editor
• 8章 · Adafruit IO・Blynk — メイカー市場の二大巨頭
• 9章 · ThingsBoard — オープンソースフルスタックの標準
• 10章 · Balena(旧resin.io) — Dockerベースfleet管理
• 11章 · Mainflux → Magistrala — オープンソースのリブランド
• 12章 · Losant / Bosch IoT Suite / Schneider EcoStruxure — エンタープライズ
• 13章 · Edgeランタイム — Azure IoT Edge / AWS Greengrass / Open Horizon / KubeEdge
• 14章 · プロトコル — MQTT 5.0 / CoAP / AMQP / OPC UA / LoRaWAN / Sigfox
• 15章 · 韓国・日本 — 自国市場のIoTクラウド
• 16章 · 誰が何を選ぶべきか — 4シナリオの決定木
• 17章 · アンチパターン · よくある失敗
• 18章 · 次回予告 · 結論
• 参考 / References

プロローグ — なぜ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クラウド利用中 → 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
• AWS IoT Greengrass v2 — Developer Guide
• AWS IoT Device Defender
• AWS IoT SiteWise
• Azure IoT Hub — Documentation
• Azure IoT Edge — Documentation
• Azure Sphere — Documentation
• Azure IoT Operations — Overview (2025)
• Google Cloud IoT Core Retirement Notice
• IBM Watson IoT Platform Retirement
• Particle — Cellular IoT Platform
• Arduino IoT Cloud
• Adafruit IO
• Blynk IoT
• ThingsBoard — Open-Source IoT Platform
• Balena — Container-based IoT
• Magistrala (Mainflux successor)
• Losant — Enterprise IoT Platform
• Bosch IoT Suite
• Schneider Electric EcoStruxure
• Open Horizon — LF Edge
• KubeEdge — CNCF
• MQTT 5.0 Specification — OASIS
• CoAP — RFC 7252
• OPC UA — OPC Foundation
• LoRaWAN — LoRa Alliance
• Sigfox / UnaBiz
• Samsung SmartThings
• LG ThinQ
• Sony AITRIOS
• Hitachi Lumada
• NTT Communications