ThingsBoardとBlynk、IoT基盤はどれを選ぶべきか 6製品比較

小規模なIoTデバイス群を運用するにあたり、どのクラウド基盤を選ぶかで悩んでいる方に向けた内容です。センサーやESP32（Wi-Fi機能を内蔵した安価なマイコンボード）を数台から数百台つなぐ場合、AWS IoTのような大規模向けサービスはオーバースペックになりがちです。

実際には Blynk、Virtuino Cloud、Arduino Cloud、ThingsBoard Cloud、Ubidots、Adafruit IO といった中小規模向けのIoTダッシュボード基盤が候補になります。それぞれ料金体系も機能もかなり異なり、後から乗り換えるとデバイス側のファームウェアまで書き直しになるケースもあります。SREやインフラ担当の視点で見るべき判断軸を整理し、自分のプロジェクトに当てはめられる形でまとめました。

どんな場面で選定が必要になるか

PoC（概念実証）段階でBlynkやAdafruit IOの無料枠を使い、そのまま本番運用に引きずられてしまう場面はよくあります。

デバイス数が数十台を超えたあたりで、コマンド到達確認の甘さや自己ホスト不可という制約が可用性設計上の弱点として表面化します。契約前にこの記事の判断軸で一度立ち止まることをおすすめします。

判断軸1: コマンド確認の信頼性

IoT基盤でデバイスに指示を送る際、「MQTT（軽量なメッセージ配信プロトコル）ブローカーへの送信成功」と「デバイス側での実行成功」は別物です。

多くの基盤はブローカーへの到達をもって成功扱いにしますが、Virtuino Cloudはデバイスが実行結果をエコーバック（送り返す）するまでUIの状態を更新しません。停止したはずのポンプが実は止まっていない、といった障害を防ぐには、このコマンド確認（Command Confirmation）の仕組みがあるかどうかが重要な判断軸になります。

比較表のとおり、フル対応はVirtuino Cloudのみで、ThingsBoardは部分対応（Tier-Gated、上位プランでのみ有効）、Blynk・Arduino Cloud・Ubidots・Adafruit IOは非対応です。

判断軸2: LWT（Last Will and Testament）によるデバイス死活監視

LWTはMQTTプロトコルの機能で、デバイスが異常切断した際にブローカーが代わりに「オフライン」メッセージを配信する仕組みです。

これがないと、電源断やネットワーク断が起きても基盤側では「最後に見えた状態のまま」表示され続けます。SREの文脈で言えば、ヘルスチェックのタイムアウト検知に近い役割です。

Virtuino Cloud・Blynk・ThingsBoardはLWT対応、Arduino Cloud・Ubidotsは部分対応、Adafruit IOは非対応です。監視対象のデバイスが屋外や不安定な回線にある場合、この差は障害検知までの時間に直結します。

判断軸3: 自己ホストの可否とデータレジデンシー

6製品のうち、自己ホスト可能なのはThingsBoard Community Edition（オープンソース版）のみです。

他はすべてクラウド専用（SaaS）で、ベンダーのデータセンターにデータが置かれます。個人情報保護法や業界規制でデータの保管場所を自社管理下に置く必要がある場合、選択肢は実質ThingsBoardの自己ホスト一択になります。

TerraformやPulumiでインフラをコード管理している組織であれば、ThingsBoardをKubernetes上にコンテナとしてデプロイし、IaC（Infrastructure as Code）の管理下に置く構成も現実的です。他の5製品はマネージドSaaSである以上、この選択肢自体が存在しません。

判断軸4: コスト構造とデバイス数のスケーリング

無料枠だけを見て選ぶと、デバイス数が増えたときの請求額に驚くことになります。料金体系を整理すると以下のとおりです。

Ubidotsはデバイス単価が明快なので、10〜30台規模の商用フリート（車両や設備の集合）の予算試算がしやすい構造です。ThingsBoardはデバイス数が1000台に近づくと月額749ドルまで跳ね上がるため、自己ホストへの切り替えコストと比較する価値があります。

選択肢の全体比較

ケース別の推奨

遠隔でアクチュエータ（バルブやポンプなど物理的に動かす機器）を操作し、実行結果の誤認が事故につながる用途なら、コマンド確認をフル対応するVirtuino Cloudを選ぶ判断が妥当です。

データの保管場所を自社管理したい、あるいは1000台規模まで見据えて自己ホストでコストを抑えたいなら、ThingsBoard Community Editionを検討します。実際に試す際は、公式ドキュメントの「Rule Chain」設定と、Docker/Kubernetesでのデプロイ手順を確認してください。

# ThingsBoard Community Edition を Docker で試す最小構成の例
docker run -it -p 8080:9090 -p 1883:1883 -p 7070:7070 \
  --name tb thingsboard/tb-postgres

学習教材や部活動レベルの小規模プロジェクトで、配線の知識を身につけたい段階ならAdafruit IOの月額10ドル固定プランが分かりやすい選択です。公式Arduinoボードのみで完結する構成ならArduino Cloudの統合の滑らかさが活きます。

あえて見送るべき条件

デバイス数が数百台を超え、かつ可用性要件が厳しいシステムでAdafruit IOを選ぶのは見送るべきです。

スクリプティングVM（デバイス側のロジックをクラウド側で実行する仕組み）もOTA（無線経由のファームウェア更新）も持たないため、運用が手作業に偏ります。

また、複数テナント（顧客ごとにデータを分離する仕組み）でSaaSを外部提供したい場合、Multi-Tenant機能が部分対応にとどまるUbidotsやArduino Cloudは選定段階で候補から外した方が無難です。ホワイトラベル（自社ブランドでのアプリ提供）を上位プランでしか使えないBlynkも、Enterprise予算がなければ同様に見送り対象になります。

まとめ

IoT基盤の選定は、無料枠の台数やダッシュボードの見た目ではなく、障害発生時にどう検知し、どう復旧するかで比較するのが実務的です。

コマンド確認とLWTの有無は公式ドキュメントの「MQTT」「Device Provisioning」のページで必ず確認してください。自己ホストの要否は、社内のデータレジデンシー要件と照らし合わせて早めに決めておくとスムーズです。

まずは候補2〜3製品の無料枠で、実際のデバイスを使ってコマンド確認とLWT検知の挙動を試すことから始めてみてください。