クラウドサービス

Azure IoT Hub Device Provisioning Service (DPS)

大量の IoT デバイスを人手を介さず適切な IoT Hub へ自動登録。ゼロタッチでプロビジョニングできるヘルパーサービスで、AWS の IoT フリートプロビジョニング相当。

中級セキュリティ運用上の優秀性信頼性
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. 製造時の資格情報で端末を検証し、適切なIoT Hubへ初回登録する。
  2. 割り当て後のテレメトリはDPSを通らず、端末がHubへ直結する。
  3. 再割り当ては一斉実行を避け、状態移行と再試行を設計する。

解決する課題

工場出荷後に世界各地へ展開される大量の IoT デバイスを、人手で 1 台ずつ IoT Hub に登録することなく、初回起動時に自動で適切なハブへ割り当てて接続させるための、ゼロタッチ登録の仕組みを提供します。

  • 数千から数百万台規模のデバイスを 製造時の情報だけで自動登録したい
  • 各デバイスに 接続先の IoT Hub やキーを焼き込まずに出荷したい
  • デバイスの所在地や属性に応じて 複数の IoT Hub へ振り分けたい
  • 負荷分散や移行のために、デバイスの 接続先ハブを後から付け替えたい
  • 個別の資格情報や証明書チェーンで なりすましを防ぎつつ大規模に展開したい

主要概念と用語

  • DPS(Device Provisioning Service): デバイスの初回接続を仲介し、適切な IoT Hub への登録と割り当てを自動化するヘルパーサービス。テレメトリは扱わず、登録だけを担う
  • ID スコープ(ID Scope): DPS インスタンスを一意に識別する値。デバイスはこの値とグローバルエンドポイントへ接続して登録を要求する
  • 登録(Enrollment): どのデバイスを受け入れるかを定義する設定。個別登録と登録グループの 2 種類がある
  • 個別登録(Individual Enrollment): 1 台のデバイスを単独で登録するエントリ。TPM 認証や単独デバイスに使う
  • 登録グループ(Enrollment Group): 同じ認証情報を共有する複数デバイスをまとめて受け入れる設定。X.509 中間証明書や対称キーのグループに使う
  • 証明書の構成証明(Attestation): デバイスの正当性を確認する方式。X.509 証明書・TPM(エンドースメントキー)・対称キーの 3 つがある
  • 割り当てポリシー(Allocation Policy): 複数の IoT Hub が候補のとき、どのハブへ割り当てるかを決める規則。均等加重分散(既定)、最小待ち時間、静的構成、カスタムの4方式がある
  • 再プロビジョニング(Reprovisioning): デバイスが再度 DPS に接続した際の振る舞い。接続先ハブの再評価や移行に使う
  • カスタム割り当てポリシー: Azure Functions などで独自ロジックを実装し、属性に応じてハブを動的に選ぶ仕組み

仕様・制限・クォータ

  • 役割: DPS はあくまで初回登録の仲介役であり、テレメトリや C2D メッセージは扱わない。接続後の通信は IoT Hub が担う
  • 構成証明の方式: X.509 証明書・TPM・対称キーの 3 方式に対応する。グループ単位の登録は X.509 中間証明書または対称キーで構成する
  • 複数ハブのリンク: 1 つの DPS に複数の IoT Hub をリンクでき、割り当てポリシーで振り分けられる。地理分散や負荷分散に使う
  • 登録数: 登録状態 1,000,000、個別登録 1,000,000、X.509 登録グループ 100、対称キー登録グループ 100。前3つはサポート申請で緩和可能だが、対称キーグループ上限は固定
  • 関連資源: CA 25(緩和申請可)、リンク済み IoT Hub 50(固定)、メッセージ最大 96 KB(固定)
  • レート: 1 DPS あたり 1,000 操作/分が既定で、緩和には事前のサポート申請が必要。一斉起動は指数バックオフと状態照会で波形を抑える
  • インスタンス数: 1 サブスクリプションの DPS は既定 10。大規模展開では早期に緩和可否と複数 DPS への分割を確認する
  • グローバルエンドポイント: デバイスは固定のグローバルデバイスエンドポイントへ接続し、ID スコープで自身の DPS を特定する
  • 再プロビジョニング: 既定は再割り当てして初期状態へ戻す。ほかに「再割り当てしない」「再割り当てして現在のツイン状態を移す」を選べるが、端末側が DPS に再登録を要求して初めて実行される

内部の仕組み

横にスクロール

端末がDPSで構成証明を受け、割り当てられたIoT Hubへ以後は直接接続する経路図
DPSは初回登録と再割り当てだけを仲介します。通常のテレメトリ経路には入らず、大量再試行と移行時の状態引き継ぎは利用側で制御します。

デバイスは出荷時に ID スコープとグローバルデバイスエンドポイント、そして自身の構成証明情報(証明書や対称キーなど)だけを持って起動します。初回接続時、デバイスは IoT Hub ではなく DPS のグローバルエンドポイントに対して登録を要求します。

DPS はデバイスの構成証明を検証し、対応する 登録(個別登録または登録グループ)を探します。一致すれば、リンクされた候補の IoT Hub の中から 割り当てポリシーに従って 1 つを選び、そのハブにデバイス ID を登録します。最後に DPS は、割り当てられたハブの接続情報をデバイスへ返します。

デバイスは返された接続情報を保存し、以降は 直接その IoT Hub に接続します。つまり DPS が経路に入るのは初回登録時だけで、平常時のテレメトリは DPS を通りません。負荷分散や移行が必要になったときは、端末側から 再プロビジョニングを要求して DPS に再接続し、ポリシーに応じて割り当て先を再評価します。DPS が稼働中の全端末を自動で押し出す仕組みではありません。

DPS は経路ではなく仲介役

DPS は初回登録のときだけ介在し、割り当て後はデバイスが IoT Hub へ直接つなぎます。テレメトリの帯域や遅延に DPS は影響しません。「どのハブへつなぐか」を決めるのが DPS、「実際の通信」を担うのが IoT Hub という役割分担で考えます。

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

  • 登録グループで一括受け入れ: 同一機種を大量展開するなら、X.509 中間証明書か対称キーの登録グループでまとめて受け入れ、1 台ごとの個別登録を避ける
  • 証明書チェーンで安全に配布: 製造ラインで各デバイスにリーフ証明書を発行し、中間証明書を DPS の登録グループに登録して信頼チェーンで検証する
  • 要件に合う割り当てを選ぶ: 重み付き分散は均等加重分散、近接リージョンは最小待ち時間、固定先は静的構成を使う。API / CLI 上の値 hashed は均等加重分散を表す
  • 動的な振り分けはカスタム割り当て: デバイスの属性やペイロードに応じてハブを選びたい場合は、Azure Functions のカスタム割り当てポリシーで実装する
  • 移行・再分散は再プロビジョニング: ハブの統廃合や負荷の偏りには、再プロビジョニングでデバイスを別ハブへ付け替える
  • 資格情報はデバイス固有に: 登録グループでもリーフ証明書はデバイスごとに固有とし、漏洩時に個別失効できるようにする

運用・監視

  • Azure Monitor のメトリクスで、登録の試行数・成功・失敗を監視し、一斉登録時のスロットルや認証失敗を早期に検知する
  • 登録の失敗ログで、構成証明の不一致や無効化された証明書による拒否を追跡する
  • 診断設定でログを Log Analytics へ送り、デバイス単位の登録履歴と傾向を分析する
  • 個別登録・登録グループの無効化で、廃棄や漏洩したデバイス群の受け入れを止められるようにしておく
  • 大量の一斉起動が見込まれるときは、登録のスループット上限を踏まえて 段階的にロールアウトする

コスト

DPS は 1,000 操作単位で課金されます。端末の初回登録と再登録だけでなく、登録状態・個別登録・登録グループに対するサービス API の作成・更新・取得・照会も課金対象です。端末の登録状態照会と操作状態照会、証明書 API、DPS リソース API は課金対象外です。また、登録エントリが6か月非アクティブになるごとに維持操作が計上されます。

課金は登録操作ベース

DPS の課金はテレメトリ量ではなく API 操作数です。通常データのコストは接続後の IoT Hub 側で発生します。端末登録だけでなく、運用ツールによる一覧・照会・更新も分けて見積もってください。

セキュリティ

  • 構成証明: デバイスの正当性を X.509 証明書・TPM・対称キーのいずれかで検証する。大規模・高セキュリティでは証明書ベースを推奨
  • 信頼チェーン: 登録グループでは中間証明書を登録し、製造時に発行したリーフ証明書を チェーンで検証してなりすましを防ぐ
  • 資格情報の焼き込み回避: デバイスには接続先ハブやハブのキーを焼き込まず、ID スコープと自身の証明書だけを持たせて出荷する
  • 個別失効: 漏洩・廃棄に備え、登録エントリやデバイス証明書を 個別に無効化できるようにする
  • 転送の暗号化: 登録時の通信はすべて TLS で保護される
  • マネージド ID と Entra ID: カスタム割り当ての Functions などからの接続はマネージド ID を使い、接続文字列のハードコードを避ける
アンチパターン

全デバイスで同一の対称キーをそのまま焼き込むのは NG。1 台漏洩すると登録グループ全体が危険にさらされます。登録グループの対称キーから デバイスごとの派生キーを生成するか、デバイス固有の X.509 リーフ証明書を使い、個別失効できる構成にしてください。

関連サービス・比較

DPS は AWS の IoT フリートプロビジョニングに相当し、大量デバイスの初回登録とハブ割り当てを自動化します。テレメトリと双方向通信そのものは Azure IoT Hub が担うため、両者は組み合わせて使います。主な対応関係を示します。

観点Azure DPSAWS フリートプロビジョニング
位置づけデバイスの初回登録とハブ割り当てデバイスの初回登録と認証情報配布
前提サービスAzure IoT HubAWS IoT Core
受け入れ単位個別登録 / 登録グループプロビジョニングテンプレート
構成証明X.509 / TPM / 対称キークレーム証明書 / 信頼ユーザー
振り分け割り当てポリシー / カスタム割り当てテンプレートとフックで制御
再割り当て再プロビジョニング再プロビジョニングフロー
DPS だけでは完結しない

DPS は登録の仲介に特化しており、テレメトリの送受信や遠隔制御は持ちません。実際の通信は Azure IoT Hub、現場での前処理は Azure IoT Edge、後続の分析や保存は Event Hubs や Blob Storage と組み合わせて構成します。

ハンズオン / CLI例

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

# DPS インスタンスを作成
az iot dps create \
  --resource-group demo-rg \
  --name demo-dps-0628 \
  --location japaneast

# 既存の IoT Hub を DPS にリンク(割り当て候補にする)
az iot dps linked-hub create \
  --dps-name demo-dps-0628 \
  --resource-group demo-rg \
  --connection-string "<iot-hub-connection-string>" \
  --location japaneast

# 対称キーの個別登録を作成(自動生成キーを利用)
az iot dps enrollment create \
  --dps-name demo-dps-0628 \
  --resource-group demo-rg \
  --enrollment-id sensor-001 \
  --attestation-type symmetricKey

# 登録の状態を確認
az iot dps enrollment show \
  --dps-name demo-dps-0628 \
  --resource-group demo-rg \
  --enrollment-id sensor-001

Azure Service

Azure IoT Hub Device Provisioning Service (DPS)を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

IoT

比較で見る軸

クラウド: Azure / カテゴリ: IoT / 難易度: intermediate

導入後に効く点

割り当て後のテレメトリはDPSを通らず、端末がHubへ直結する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
IoT
難易度
intermediate
関連資格
設計柱
security / operational / reliability

判断チェックリスト

  • 自社の用途が「IoT / security」に近いか確認する。
  • 強みである「製造時の資格情報で端末を検証し、適切なIoT Hubへ初回登録する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

IoTsecurityoperationalreliability