Azure IoT Central

解決する課題

IoT ソリューションを一から組み立てると、デバイス接続・認証・データ取り込み・可視化・ルール・ユーザー管理などを個別に統合する必要があり、立ち上げに時間がかかります。IoT Central は、これらをホスト済みの SaaS としてまとめて提供し、コードレスで素早くソリューションを開始できるようにします。

• 接続基盤・ダッシュボード・ルールなどを 一つずつ統合せず、まとめて使い始めたい
• インフラの構築や運用を抱えず、マネージドな土台の上でアプリ側に集中したい
• デバイスの機能を テンプレートで定義 し、UI から可視化やルールを作りたい
• 現場担当やビジネス側の利用者にも、ローコード/ノーコードで扱える管理画面を渡したい
• まず PoC や小規模から始め、必要に応じて本格的な構成へ広げたい

主要概念と用語

• アプリケーション: IoT Central の単位となるホスト済みのソリューション。デバイス・ダッシュボード・ルール・ユーザーを内包する
• デバイステンプレート: デバイスの機能（テレメトリ・プロパティ・コマンド）を定義する設計図。DTDL（Digital Twins Definition Language）で記述する
• デバイス: テンプレートに基づいて接続される個々の機器。テンプレートに従ってデータを送受信する
• テレメトリ: デバイスが送る計測値などの時系列データ
• プロパティ: デバイスの設定値や状態。クラウドから設定する書き込み可能プロパティもある
• コマンド: クラウドからデバイスへ送る指示
• ダッシュボード: テレメトリやプロパティをグラフ・タイルで可視化する画面。コードレスで構成する
• ルール: テレメトリの条件成立時にメール送信や Webhook などのアクションを起こす仕組み
• データエクスポート: テレメトリやイベントを Event Hubs・Service Bus・Blob Storage などへ継続的に転送する機能
• 組織（Organizations）: デバイスやユーザーを階層的に区切り、アクセス範囲を分けるマルチテナント向けの仕組み

仕様・制限・クォータ

• 接続方式: 初回は内部の DPS で接続先を割り当て、その後は MQTT 3.1.1 / AMQP の常時接続または HTTPS で通信する。認証は SAS または X.509 証明書を使う
• デバイスモデル: デバイスの機能は DTDL で記述したデバイステンプレートで定義する
• マルチテナント: 組織機能でデバイスとユーザーを階層的に分離でき、サービスプロバイダー的な構成も取れる
• 規模: 1 アプリ最大 200,000 台（シミュレート端末は 100 台）。アプリ全体のテレメトリは 200 メッセージ/秒で、個々の端末は一時的に 10 メッセージ/秒まで送れる
• サイズ: D2C メッセージは最大 256 KB、C2D メッセージは最大 64 KB。希望・報告プロパティは各 32 KB、タグは 8 KB が上限
• データ保持: アプリ内のテレメトリ保持は最大 7 日。長期保存はデータエクスポートで外部ストレージへ送る
• 操作レート: プロパティ更新は 100/秒、コマンドは 20/秒（いずれもソフト上限）。Query API は 1 要求/秒、その他の API は 20 要求/秒
• 構成上限: テンプレート 1,000、1 テンプレートの機能 300、端末グループ 500、ルール 50、1 ルールのアクション 5、同時ジョブ 5
• 外部出力: 出力ジョブ 10、宛先 10、1 ジョブの宛先 10、フィルターと付加情報 10。大量時は最大約 60 秒の遅延を見込む
• 拡張の前提: 高度なカスタムロジックは、エクスポート先や連携サービス側で実装するのが基本
• 上限緩和の可否と価格は変更され得るため、導入時は公式のクォータ・料金ページも確認する

内部の仕組み

横にスクロール

IoT Central は、デバイス接続やメッセージ処理の土台として IoT Hub や デバイスプロビジョニングサービス（DPS） といったプラットフォーム機能を内部に取り込み、それらをマネージドな SaaS として隠蔽しています。利用者はハブのプロビジョニングやスケールを意識せず、アプリケーション単位でソリューションを扱えます。

デバイスは初回接続時に内部の DPS 相当の仕組みで自動登録され、割り当てられた接続先へつながります。送られたテレメトリは デバイステンプレート の定義に従って解釈され、ダッシュボードでの可視化やルールの評価に使われます。クラウドからは、テンプレートで宣言したプロパティやコマンドを通じてデバイスを構成・制御します。

取り込んだデータを後続の分析や保存へ流すには データエクスポート を使い、Event Hubs・Service Bus・Blob Storage などへ継続的に転送します。これにより、可視化や簡易ルールは IoT Central 内で完結させ、重い分析や長期保存は外部サービスに委ねる分業ができます。

設計パターン / ベストプラクティス

• 機能はデバイステンプレートで先に定義: テレメトリ・プロパティ・コマンドをテンプレートで宣言し、デバイス実装と画面・ルールの前提をそろえる
• 可視化と簡易ルールは内製機能で: ダッシュボードとルールをコードレスで構成し、開発工数をかけずに運用を始める
• 重い処理は外部へエクスポート: 高度な分析・機械学習・長期保存はデータエクスポートで Event Hubs や Storage に送り、外部で処理する
• マルチテナントは組織で分離: 顧客や拠点ごとにデバイスとユーザーを組織で区切り、アクセス範囲を限定する
• 小さく始めて広げる: PoC を IoT Central で素早く検証し、要件が高度化したら IoT Hub ベースの構成へ移行する判断材料にする

運用・監視

• 組み込みダッシュボードで、デバイスの接続状況やテレメトリの傾向を可視化する
• ジョブ機能で、複数デバイスへのプロパティ更新やコマンド実行を一括で行い、結果を追跡する
• ルールとアクションで、しきい値超過などの条件成立時にメールや Webhook で通知する
• デバイス一覧と状態で、未接続や異常なデバイスを早期に把握する
• ユーザーには ロール（管理者・オペレーターなど） を割り当て、操作できる範囲を分ける

コスト

課金は主に 端末数と月間メッセージ数で決まります。端末ごとの月間割当は ST0 が 400、ST1 が 5,000、ST2 が 30,000 メッセージで、超過分は別課金です。標準メッセージは 4 KB 単位で数え、4.5 KB なら 2 メッセージです。各アプリの最初の 2 台は、プランごとのメッセージ枠内で無料です。

セキュリティ

• デバイス認証: 内部のプロビジョニングを通じ、共有アクセス署名や X.509 証明書 などでデバイスを認証する
• ユーザーとロール: 管理画面の利用者にはロールを割り当て、操作範囲を最小権限に絞る
• 組織による分離: 組織機能でデバイスとユーザーのアクセス範囲を区切り、テナント間の越境を防ぐ
• 転送の暗号化: デバイスとの通信やエクスポートは暗号化された経路で行う
• Entra ID 連携: 管理画面のサインインを組織の ID 基盤と統合し、認証を一元化する
• 資格情報の管理: デバイスごとに固有の資格情報を用い、漏洩時に個別失効できるようにする

関連サービス・比較

IoT Central は、低レベルな接続ハブである Azure IoT Hub の上位に位置する SaaS です。素早く統合済みのソリューションが欲しいなら IoT Central、細かい制御と独自アプリの自由度が欲しいなら IoT Hub を土台にします。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# IoT Central アプリケーションを作成
az iot central app create \
  --resource-group demo-rg \
  --name demo-iotc-0628 \
  --subdomain demo-iotc-0628 \
  --location japaneast \
  --sku ST1

# デバイステンプレート一覧を確認
az iot central device-template list \
  --app-id demo-iotc-0628

# デバイスを登録
az iot central device create \
  --app-id demo-iotc-0628 \
  --device-id sensor-001

# デバイスのテレメトリ最新値を確認
az iot central device show \
  --app-id demo-iotc-0628 \
  --device-id sensor-001