Azure IoT Hub

解決する課題

工場の機器・センサー・車載端末などの大量のデバイスを、ネットワーク越しに安全かつ確実につなぎ、テレメトリ収集と遠隔制御を中央集権的に行うための接続基盤を提供します。

• 数万から数百万台規模のデバイスを 個別 ID で認証 して接続したい
• デバイスからクラウドへの テレメトリ送信と、クラウドからデバイスへの コマンド送信の両方をしたい
• 一時的に切断されるデバイスにも、再接続後に 状態や設定を同期 したい
• TLS・トークン・証明書で なりすましや盗聴を防ぎ、デバイスごとに権限を絞りたい
• 受信したテレメトリを 後続の分析・保存・処理へ自動で流したい

主要概念と用語

• IoT Hub: デバイスとクラウドの間に立つマネージドな接続エンドポイント。メッセージのルーティングと ID 管理を担う
• デバイス ID（Identity Registry）: 接続を許可するデバイスを登録したレジストリ。デバイスごとに固有の資格情報を持つ
• デバイスツイン（Device Twin）: 各デバイスのメタデータと状態を表す JSON ドキュメント。希望状態（desired）と報告状態（reported）を保持して同期に使う
• ダイレクトメソッド（Direct Method）: クラウドからデバイスの関数を即時に呼び出す要求応答型の制御。デバイスのオンライン時に応答を受け取る
• クラウドからデバイスへのメッセージ（C2D）: クラウドが特定デバイスへ送るキュー型のコマンド配信
• デバイスからクラウドへのメッセージ（D2C）: デバイスが送るテレメトリ。組み込みエンドポイントまたはルーティングで後続へ流す
• メッセージルーティング: テレメトリやイベントを条件に応じて Event Hubs・Service Bus・Storage などへ振り分ける機能
• デバイスプロビジョニングサービス（DPS）: 多数のデバイスを自動で適切な IoT Hub に割り当てるゼロタッチ登録サービス
• IoT Edge: ゲートウェイ機器上でモジュールを実行し、現場側でフィルタリングや推論を行う拡張

仕様・制限・クォータ

• プロトコル: MQTT・AMQP・HTTPS に対応し、WebSocket 上での MQTT/AMQP も利用できる。常時接続が必要なら MQTT または AMQP を選ぶ
• メッセージサイズ: 1 メッセージには上限があり、超える場合は分割や前処理が必要。大きなファイルはファイルアップロード機能で Blob Storage へ直接送る
• メッセージ単位課金: 課金は転送バイト数を一定サイズのメッセージ数に換算してカウントする方式が基本
• 層（Tier）: 無料層・Basic 層・Standard 層がある。Basic 層は D2C のみで、デバイスツインやダイレクトメソッドなどの双方向機能は Standard 層が必要
• スロットリングとクォータ: 1 ユニットあたりの 1 日のメッセージ数や接続スループットに上限があり、ユニット数や層でスケールする
• デバイスツインのサイズ: タグや希望・報告プロパティにはドキュメントサイズの上限がある
• 具体的な上限値・単価は層やユニット、リージョンで変わるため、最新の公式情報で確認する

内部の仕組み

IoT Hub は、登録済みデバイスからの接続を デバイスごとの資格情報（SAS トークンまたは X.509 証明書）で認証し、TLS で保護された常時接続を維持します。デバイスが送る D2C テレメトリは、まずハブの組み込みエンドポイント（Event Hubs 互換）に入り、ここから メッセージルーティングによって条件に応じた宛先へ振り分けられます。

クラウドからの制御には複数の経路があります。即時の指示には ダイレクトメソッド（要求応答）、キュー型の片方向配信には C2D メッセージ、設定の宣言的な同期には デバイスツインを使います。デバイスツインでは、クラウドが希望状態（desired プロパティ）を書き込み、デバイスが再接続時にそれを取得して適用し、結果を報告状態（reported プロパティ）として書き戻します。これにより、オフラインだったデバイスも復帰後に最新の設定へ収束できます。

大規模な初期登録は **DPS（デバイスプロビジョニングサービス）**が担い、デバイスを地理やルールに応じて適切な IoT Hub へ自動割り当てします。現場側で前処理が必要な場合は IoT Edge をゲートウェイに置き、フィルタリングやローカル推論を行ってからクラウドへ送る構成にできます。

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

• テレメトリの後段はルーティングで分離: メッセージルーティングで、ホット分析は Event Hubs・Stream Analytics へ、長期保存は Blob Storage へと宛先を分ける
• 大量デバイスは DPS でゼロタッチ登録: 製造時にデバイスへ資格情報を焼き込み、初回接続時に DPS が自動で割り当てる
• 設定配布はデバイスツイン: 個別のコマンド送信ではなく、希望プロパティで宣言的に構成を配り、報告プロパティで適用結果を確認する
• 大きなデータはファイルアップロード: 画像やログなどはメッセージに載せず、SAS で Blob Storage へ直接アップロードする
• 現場前処理は IoT Edge: 帯域や遅延が問題なら、エッジでフィルタリング・集約・推論してから送る
• 冪等なメッセージ処理: 再送や重複に備え、後段の処理はメッセージ ID で冪等に設計する

運用・監視

• Azure Monitor のメトリクスで、テレメトリ送信数・接続デバイス数・スロットルやエラーの発生を監視する
• 接続イベントのログで、デバイスの接続・切断・認証失敗を追跡し、頻繁な切断や認証エラーを早期に検知する
• メッセージルーティングのフォールバック経路を用意し、どの条件にも一致しないメッセージを取りこぼさないようにする
• 診断設定でログを Log Analytics へ送り、デバイス単位のトラブルシュートと傾向分析に使う
• スロットルが出たら ユニット数の増設や層の見直しを検討する

コスト

課金は主に 層（Tier）とユニット数、および 1 日に送受信する メッセージ数で決まります。双方向機能が不要ならコストの低い層を、必要なら Standard 層を選びます。

セキュリティ

• デバイス認証: デバイスごとに SAS トークンまたは X.509 証明書で認証する。大規模・高セキュリティでは証明書ベースを推奨
• 最小権限: デバイスは自分の ID の範囲でしか操作できないよう権限を絞り、サービス側アクセスは用途別のポリシーや RBAC で分離する
• 転送の暗号化: 通信はすべて TLS で保護される
• マネージド ID と Entra ID: ルーティング先などへの接続はマネージド ID を使い、接続文字列のハードコードを避ける
• ネットワーク制御: プライベートエンドポイントや IP フィルターで公開アクセスを制限できる
• 資格情報の失効: 漏洩や廃棄に備え、デバイス資格情報を個別に無効化・ローテーションできるようにする

Well-Architected の観点

• セキュリティ: デバイスごとの個別認証、TLS、最小権限、プライベートエンドポイントで攻撃面を絞る。共有資格情報を避け、失効とローテーションを運用に組み込む
• 信頼性: 一時切断に強いデバイスツインで設定を収束させ、ルーティングのフォールバックでメッセージを取りこぼさない。DPS と複数ハブで大規模・地理分散にも対応する
• 運用: メトリクスと接続ログで接続品質を可視化し、スロットルや認証失敗を早期に検知する
• コスト: 双方向機能の要否で層を選び、ユニット数とメッセージ数を需要に合わせて調整する

試験で問われるポイント

関連サービス・比較

IoT Hub は AWS の IoT Core に相当し、デバイス接続・認証・双方向通信・ルールによる転送を担います。主な対応関係を示します。

ハンズオン / CLI例

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

# IoT Hub を作成（双方向機能を使うため Standard 層を指定）
az iot hub create \
  --resource-group demo-rg \
  --name demo-iothub-0614 \
  --location japaneast \
  --sku S1

# デバイス ID をレジストリに登録（対称キー認証）
az iot hub device-identity create \
  --hub-name demo-iothub-0614 \
  --device-id sensor-001

# デバイスツインの希望プロパティを設定（設定を宣言的に配布）
az iot hub device-twin update \
  --hub-name demo-iothub-0614 \
  --device-id sensor-001 \
  --desired '{"telemetryInterval": 30}'

# クラウドからデバイスの関数を即時呼び出し（ダイレクトメソッド）
az iot hub invoke-device-method \
  --hub-name demo-iothub-0614 \
  --device-id sensor-001 \
  --method-name reboot \
  --method-payload '{}'