Azure IoT Hubとは？機能・料金・IoT Operationsとの使い分けを解説

Azure IoT Hub（アジュール・アイオーティー・ハブ）は、数百万台規模のIoTデバイスとクラウドを安全につなぐマネージドサービスです。

Azure IoT Operationsは2024年11月にGAしており、2026年3月の2603リリースで一部機能が追加GAされました。「クラウド接続はIoT Hub／工場全体のOTデータはIoT Operations」という2層構造が定着しつつあり、既存のIoT Hubを使い続けるべきか、Operationsを組み合わせるべきかの判断が最初の論点になります。

本記事では、Azure IoT Hubの定義とAzure IoTサービス群での位置づけ、Azure IoT Operationsとの使い分け、主要機能と業種別活用シーン、料金プランと選び方、Azureポータルでの作成手順までを、2026年7月時点の最新情報で解説します。

Azure IoT Hubとは？デバイスとクラウドを繋ぐ中央メッセージハブ

Azure IoT Hub（アジュール・アイオーティー・ハブ）とは、IoTデバイスとMicrosoft Azureクラウドの間の双方向通信を担うマネージドサービスです。

Microsoftは「クラウドベースのIoTソリューションの中央メッセージハブ」と定義しており、SLA 99.9%で数百万台のデバイスと毎秒数百万のイベントを扱えるスケール設計になっています。

2026年現在、Azure IoT Hubは単独プロダクトというより、Azure IoTサービス群のなかで「クラウド接続」レイヤーを担うコアサービスとして位置づけられています。

2024年11月にAzure IoT OperationsがGAし、2026年3月の2603リリースで一部機能が追加GAされたことで、「クラウド直結の双方向通信はIoT Hub」「工場全体のOTデータ統合はIoT Operations」という2層の役割分担が定着してきました。

Azure IoT サービス群の中での位置づけ

Azure IoT のサービス群は、デバイス接続・エッジ処理・データ分析の役割で階層化されています。IoT Hubはその中核である「クラウド接続層」を担う位置づけです。

以下の表で、Azure IoTを構成する主要サービスとIoT Hubの位置づけを整理しました。

サービス	主な役割	IoT Hubとの関係
Azure IoT Hub	デバイスとクラウド間の双方向通信・メッセージルーティング	中核サービス
Azure IoT Hub Device Provisioning Service（DPS）	デバイスIDの自動割り当てとゼロタッチプロビジョニング	IoT Hubの補助サービス
Azure IoT Operations	工場全体のOTデータ統合・エッジ処理	IoT Hubと共存（別レイヤー）
Microsoft Fabric Real-Time Intelligence	ストリームデータの分析・AI活用	IoT Hubからのデータ受け側
Azure Digital Twins	物理資産のデジタル表現・関係モデリング	IoT Hubからのデータで駆動

この構成から読み取れるのは、IoT Hubが「デバイスからクラウドへデータを届ける入口」に特化しているという点です。

エッジ側の工場全体制御はIoT Operationsが担い、分析基盤はFabric、資産モデリングはDigital Twinsに委ねる分業構造で、IoT Hubは通信レイヤーに集中しています。

Azure IoTのクラウド接続パターン全体像（出典：Microsoft Learn）

Microsoft Learnが示す「クラウド接続パターン」の全体像を見ると、IoT Hubは中央のMessage processing層にいて、左のGateway経由でDevices（MCU/MPU/Server class）から届くテレメトリを受け止め、右のCloud services（Storage・Analysis・Visualization・Automation）へルーティングする役割を担っています。

上段のIoT cloud services（Device registry・Service APIs・Device provisioning・Device updates）はIoT Hubを取り囲む付帯サービスで、下段のSecurity・Solution management・High availability・Scalabilityは横断機能として全レイヤーに効く構造です。

---

Azure IoT Hub と Azure IoT Operations の使い分け

Azure IoT Operationsは2024年11月19日にGAし、Kubernetes・Azure Arc・MQTTを基盤にしたエッジ統合基盤として提供されています。2026年3月のバージョン2603（v1.3.38）で一部機能が追加GAされ、2026年7月時点の現行パッチは1.3.137（2606）です。

「これから新規IoT基盤を検討するなら、どちらを選ぶべきか」——本セクションでは、IoT HubとIoT Operationsの想定シーンと選定判断のポイントを整理します。

それぞれの想定シーン

IoT HubとIoT Operationsは競合ではなく、担当するレイヤーが異なるサービスです。

対比で確認しておくと、Azure IoTのエッジ接続パターンは、Devices側のCamera・OPCUAサーバー・Assetといった現場機器からデータを吸い上げる部分がEdge runtime environmentに集約されており、その内部にIoT Operationsが担うSouthbound connectivity・Message broker (pub/sub)・Northbound connectivityの3層が並びます。

Azure IoTのエッジ接続パターン全体像（出典：Microsoft Learn）

Cloud側にはRouting・Storage・Analysis・Visualizationに加え、OT management・IT managementといった運用系サービスが並び、工場全体を管理する視点で組まれています。IoT Hub中心のクラウド接続パターン（前セクション参照）とは、データ集約の起点が「デバイス個々」ではなく「現場全体」になっている点が最大の違いです。

以下の表で、それぞれの想定シーンを整理しました。

観点	Azure IoT Hub	Azure IoT Operations
主な用途	クラウド直結のデバイス通信基盤	工場全体・生産ライン・OTデータの統合
実行環境	クラウドマネージド	Azure Arc対応Kubernetesクラスター（エッジ側）
通信プロトコル	MQTT / AMQP / HTTPS	MQTT（内蔵ブローカー）・OPC UA
想定デバイス	単体デバイス・センサー	生産ラインの機器群・OT機器・PLC
データの流し先	Event Hubs / Storage / Cosmos DB / Event Grid	Microsoft Fabric / Event Hubs / Event Grid
ハードウェア要件	軽量デバイスでも可	エッジ側に相応のK8s実行環境が必要

この整理から見えるのは、IoT Hubは「1台のデバイスをクラウドに繋ぐ」用途、IoT Operationsは「工場丸ごとのOTデータを標準化してクラウドに集める」用途という分業構造です。

Microsoftは「IoT OperationsはIoT Hubの置き換えではなく、新しいエッジ寄りソリューションの推奨」と明言しており、両者は共存前提の設計になっています。

Azure IoT Operationsの詳細アーキテクチャ（出典：Microsoft Learn）

IoT Operationsの内部構造をもう一段掘ると、EdgeのAzure Arc対応Kubernetesクラスター上にConnector for ONVIF・OPC UA・media・MQTT data flows・Layered network services・Discovery servicesが並び、Data services・App services・Machine LearningのAzure Arc対応サービスがユーザーワークロードを支えています。

Cloud側ではAzure portal・Azure Device Registry・Operations experience・Power BI・Microsoft Fabric・Azure Data Lake Storage・Azure Data Explorerが接続先として並び、工場データを分析・可視化・監視まで一気通貫で扱う構成になっています。

選定判断のポイント

どちらを選ぶかは、実行環境・データの粒度・既存資産の3つで判断します。

• クラウド直結でデバイスから素直にテレメトリを送る構成
  資産追跡・遠隔監視・スマートホーム・車両テレメトリなど、デバイス個々がインターネット経由でクラウドに繋がる形はIoT Hubが第一候補。
  
  

• 工場・プラント・店舗全体のOTデータを一元化する構成
  PLC・SCADA・複数機種の生産機器から出るOPC UAデータをエッジで正規化してクラウドに流したい場合はIoT Operations。エッジ側にKubernetes運用体制があることが前提。
  
  

• 既存IoT Hub利用者の移行判断
  既存IoT Hubで運用している資産追跡・遠隔監視系はそのままIoT Hubで継続。工場のOTデータ統合を新規に検討するタイミングでIoT Operationsを重ねる形が現実的。

AI総研の支援現場でも、既存IoT Hub基盤の即時移行は薦めず、Operations導入は「新規のOTデータ統合案件」から段階的に始めるパターンが定着しつつあります。

---

Azure IoT Hub の主要機能と活用シーン

Azure IoT Hubは、双方向通信・デバイス管理・メッセージルーティング・セキュリティ・プロビジョニングの5つの機能ブロックで構成されています。

本セクションでは、それぞれの機能と、業種別の活用シーンを合わせて解説します。

デバイスとクラウド間の双方向通信

Azure IoT Hubの中核は、デバイスからクラウド（Device-to-Cloud、D2C）とクラウドからデバイス（Cloud-to-Device、C2D）の双方向メッセージングです。

D2Cではセンサーデータや状態通知をクラウドに送信し、C2Dではクラウド側の判断結果や制御コマンドをデバイスに戻します。加えて、大容量のログファイルや画像を送るための「ファイルアップロード」機能も用意されています。

• D2C
  最大256KBのメッセージをデバイスから送信。テレメトリ・イベント通知・アラートに使う。
  
  

• C2D
  最大64KBのメッセージをクラウドから送信。設定変更・ファームウェアアップデート指示・アラート通知に使う。
  
  

• ファイルアップロード
  Azure Storageと連携し、ログや画像・録音などの大容量データをデバイスから直接アップロード。

対応プロトコルはMQTT・AMQP・HTTPSの3種類で、デバイス側のリソース制約に合わせて選択できます。TLS 1.2以上が前提で、TLS 1.0/1.1のサポートは2025年8月31日に終了しています。デバイス側SDKもTLS 1.2に対応させておく必要があります。

デバイスの管理と制御（Device Twin・ダイレクトメソッド）

デバイスの状態管理と制御は、Device TwinとDirect Methodsの2つで実装します。

Device Twinはデバイスの状態をJSON形式でクラウドに保持する仕組みで、Direct Methodsはクラウドからデバイスへの即時応答型の呼び出しです。

• Device Twin
  デバイスのプロパティ（気温設定・稼働モードなど）と、実際の状態（現在温度・エラー履歴など）をクラウド側でJSON管理。オフライン中の変更はデバイス再接続時に自動同期される。
  
  

• Direct Methods
  「デバイス再起動」「設定リロード」などの即時応答型コマンドを送信。HTTP呼び出しに近い挙動で、成功/失敗をタイムアウト付きで受け取れる。
  
  

• IoT Plug and Play
  デバイスモデルを標準化された記述で共有し、初期接続時にクラウド側が自動でスキーマを認識する仕組み。ハードウェアベンダー横断でデバイス統合を簡素化する。

これらの機能はStandardレベル（S1・S2・S3）でのみ利用できます。Basicレベル（B1・B2・B3）はD2Cのみ提供のため、双方向通信を必要とする構成ではStandard選択が前提です。

メッセージルーティングとFabric・AI基盤への連携

Azure IoT Hubで受信したメッセージは、条件分岐で複数のAzureサービスへ振り分けられます。

以下の表で、代表的なルーティング先とユースケースを整理しました。

ルーティング先	主な用途
Azure Event Hubs	大量ストリームデータの受け皿・下流サービスへのファンアウト
Azure Storage	長期保管・後続分析のためのデータレイク
Azure Service Bus (queue/topic)	ワークフロー連携・キューベースの非同期処理
Cosmos DB	デバイス状態・イベントログのNoSQL永続化
Event Grid	イベント駆動アーキテクチャのトリガー分岐

この一覧から見えるのは、IoT Hubを起点にすれば下流のAI・分析基盤へ「配線」だけで到達できる設計思想です。

特に2026年時点では、Microsoft FabricのReal-Time HubがIoT Hubを「ソース」として接続する構成が代表的な接続構成として整備されており、Fabric Real-Time IntelligenceやFabric IQ経由でAI基盤に繋げる場合もFabric側でIoT Hubをソース登録するだけで済みます。

Azure Functionsを繋ぐ場合は、IoT Hubの組み込みEvent Hubs互換エンドポイントまたはEvent Grid経由でトリガーする構成が公式の推奨パターンです。

Microsoft Fabric Real-Time HubでAzure IoT Hubをソースとして接続する画面（出典：Microsoft Learn）

Fabric側の操作は数クリックで完結します。Real-Time Hubの「Add data」画面でMicrosoftソースタブを選び、並んでいるカードの中から「Azure IoT Hub」を選択、あとは接続情報を入力するだけでFabric側にストリームが流れ込みます。

IoT Hub側の設定を書き換えることなくFabric取り込みが始まるのが特徴で、Fabricの分析ワークロードやAzure Machine Learningによる予測モデルにIoTデータを接続する際の接続ルートの一つとして機能します。

セキュリティと認証（SAS・X.509・2026 ADR統合）

IoT Hubは、SASトークンとX.509証明書の2種類の認証方式に対応しています。デバイスごとに認証情報を持たせ、TLSで暗号化された通信路の上で運用する多層構造です。

• SASトークン認証
  対称キーをデバイスに配布し、その鍵で署名したトークンで認証。実装が簡単で、対称キーを安全に保管できる用途に向く。
  
  

• X.509証明書認証
  TLSハンドシェイク時にデバイス証明書を提示。管理コストは上がるが、大規模フリートの標準的な認証方式。
  
  

• Azure Device Registry統合（2025年11月〜2026年4月プレビュー）
  Azure Device Registry（ADR）との統合により、X.509証明書のゼロタッチ更新とフリート単位のポリシー駆動管理が可能に。証明書失効制御でデバイス単位・フリート単位のリスク分離も実現。

現時点ではFree/S1ティアのみ対象で、S2/S3・Basicで利用を検討する場合は最新の提供条件を確認する必要がある。

大規模フリート運用や高セキュリティ要件のある業種では、X.509証明書認証を最初から選ぶことをAI総研でも推奨しています。SASトークン認証は開発・検証環境向けと割り切り、本番はX.509に統一する運用が現実的です。

DPS連携によるゼロタッチプロビジョニング

Device Provisioning Service（DPS）は、IoT Hubに紐づく補助サービスで、デバイス起動時に自動で適切なIoT Hubへ登録・接続する仕組みを提供します。

工場出荷時に個別のIoT Hub情報を焼き込む必要がなくなり、大規模導入時のオペレーションコストが大幅に下がります。

• X.509・TPM認証によるゼロタッチ登録
  デバイス起動時にDPSが認証情報を確認し、割り当てポリシーに従って対応するIoT Hubに登録。
  
  

• マルチHub・マルチリージョン割り当て
  地域や顧客ごとに異なるIoT Hubへ振り分ける割り当てポリシーが設定可能。グローバル展開でも1つのDPSインスタンスで対応できる。

DPSはIoT Hubとセットで導入するのが基本設計です。「デバイスを100台以上運用するならDPSを検討」というのが目安になります。

Device Provisioning Serviceのゼロタッチプロビジョニングフロー（出典：Microsoft Learn）

実際の登録フローは5ステップです。①デバイスがDPSエンドポイントに接続 → ②DPSがEnrollmentリストと突合して割り当て先のIoT hubを決定し、そのhubにデバイスを登録 → ③DPSがhub接続情報をデバイスに返却 → ④デバイスは受け取った情報でIoT Hubに直接認証 → ⑤以降はDPSを経由せずIoT Hubと直接通信、という流れです。工場出荷後にデバイスの電源を入れた瞬間から人手を介さずに接続が確立されるのがゼロタッチの実体で、10万台規模でも同じフローがそのままスケールします。

業種別の活用シーン

Azure IoT Hubは、業種を問わず利用されていますが、特に導入が進んでいる領域を3つ整理します。

• 製造業（工場設備の遠隔監視・予知保全）
  工場設備のセンサーデータをIoT Hub経由でクラウドに集約し、異音検知AIや機械学習モデルで故障予兆を検出する構成が定着している。Marsは離散製造領域でMicrosoft Azureをコアデータプラットフォームとして採用し、Defender for IoTと組み合わせたOTセキュリティ運用にも取り組んでいる。
  
  

• エネルギー・インフラ（風力発電・スマートグリッド）
  風力発電機・変電所・スマートメーターなど広域分散型の資産からのテレメトリを、IoT Hubで一元化。稼働状況の可視化と需給予測に活用されている。
  
  

• 物流・移動体（コールドチェーン・車両テレメトリ）
  冷蔵冷凍車の温度センサー・GPS位置情報・車両状態をIoT Hubで収集。物流品質管理と配送最適化に接続する。国内では加賀市が北菱電興の除雪車運行システム「スノプロアイ」を採用し、稼働状況の可視化に活用している。

これらのユースケースの共通点は、**「デバイスからの継続的なテレメトリを、下流のAI分析に繋げる」**という一貫した流れです。IoT Hubを起点として、Fabric・Azure ML・Azure OpenAI Serviceといった分析・AI基盤に接続する構成がAzureの標準アーキテクチャになっています。

---

Azure IoT Hubの料金プランと選び方

Azure IoT Hubの料金は、Free・Basic・Standardの3層構造で、Basic/StandardはさらにB1〜B3・S1〜S3の6つのユニットサイズに分かれます。

本セクションでは、各プランの単価と、どのユニットをどの規模で選ぶべきかの判断軸を整理します。

Free / Basic / Standard の3層構造

料金の全体像を把握するには、まず3層構造の違いを押さえておく必要があります。以下の表で、Free・Basic・Standardの主要な違いを整理しました。

層	想定用途	双方向通信	Device Twin / Direct Methods	IoT Edge統合
Free	検証・PoC専用	○（限定）	○	○
Basic（B1・B2・B3）	片方向テレメトリ運用	×（D2Cのみ）	×	×
Standard（S1・S2・S3）	本番・双方向通信	○	○	○

この表から見えるのは、Basicは「デバイスからクラウドへの片方向送信で完結する用途」に絞られた廉価版という位置づけです。

Device TwinやDirect Methods、IoT Edge統合が必要な場合はStandardが必須になります。開発時の検証はFreeティア（1日8,000メッセージ・デバイス500台まで）でスタートし、要件が固まった段階で新規に有料版IoT Hubを作成してデバイス登録先を切り替える形が基本パターンです（Freeから有料への直接変更は公式に不可とされています）。

Basic（B1・B2・B3）と Standard（S1・S2・S3）の単価表

以下の表で、Azure IoT Hubの各ユニットの単価と1日あたりのメッセージ処理能力を整理しました（2026年7月時点：米国リージョン基準の公表価格）。

ユニット	月額	1日あたりメッセージ数	メッセージあたり単位
Free	$0	8,000	0.5KB
B1	$10	400,000	4KB
B2	$50	6,000,000	4KB
B3	$500	300,000,000	4KB
S1	$25	400,000	4KB
S2	$250	6,000,000	4KB
S3	$2,500	300,000,000	4KB

実際のAzureの料金は為替とMicrosoftとの契約種別で変動しますが、日本での運用でも米ドル基準で近い水準になります（Japan Eastリージョン想定・Microsoft公式試算ツールで要確認）。

BasicとStandardの同容量比較（B1 vs S1）では、Standardが2.5倍の単価です。この差額が「双方向通信・Device Twin・IoT Edge統合」の追加費用と考えると、機能を使うなら間違いなくStandardを選ぶ判断になります。

メッセージ制限を超えたときの挙動

各ユニットには1日のメッセージ数上限があり、これを超えると**スロットリング（速度制限）**が発生します。

公式ドキュメントによれば、超過時はまずtraffic shapingでキューイング・遅延が発生し、超過が続くと最終的に429 ThrottlingExceptionでメッセージが拒否される流れです。超過分を後追いで課金する形にはなりません。

• 翌日リセット
  1日のカウンタは翌日にリセット。
  
  

• 超過時の対処
  IoT Hub内で単位数（ユニット数）を追加するか、上位ユニットにスケールアップして容量を増やす。
  
  

• 200ユニット超・10ユニット超の運用
  S1/S2/B1/B2で200ユニット超、B3/S3で10ユニット超の運用が見込まれる場合、Microsoftサポートへの事前連絡が必要。

設計時のポイントは、「ピーク時のメッセージ量に合わせてユニットを選ぶ」ことです。平常時に7割程度の使用率になるようマージンを取っておくと、突発的なトラフィックにも対応できます。

プラン選定シグナル

どのユニットを選ぶかの判断は、メッセージ量・双方向通信の必要性・エッジ運用の有無の3軸で決まります。

• 1日40万メッセージ以下・片方向テレメトリのみ
  B1（月額$10）を選択。資産追跡や単純な状態通知向け。
  
  

• 1日40万メッセージ以下・双方向通信必須
  S1（月額$25）を選択。多くの本番運用の起点になるユニット。年間$300前後で開始できる。
  
  

• 1日600万メッセージ規模・IoT Edge統合あり
  S2（月額$250）を選択。工場ライン・大規模フリート運用の標準。
  
  

• 1日3億メッセージ規模の超大規模運用
  S3（月額$2,500）を選択。全国展開のスマートグリッド・大規模車両テレメトリ級。

AI総研の支援現場でも、本番導入時はS1から開始し、実測値に応じてS2にスケールする流れが定着しています。BasicはPoC後にコスト最適化が必要な軽量用途に限定するのが実務的です。

---

Azure IoT Hubの利用手順

ここからは、Azure IoT Hubを実際にセットアップする手順を解説します。Azure PortalからGUI操作で作成できるため、初回でも30分程度でハブ立ち上げとデバイス接続確認まで完了します。

前提条件

作業を始める前に、以下を確認してください。

• Azureサブスクリプション
  Azureの有料または無料アカウント。無料アカウントの場合、$200相当のクレジットとFreeティアが利用可能。
  
  

• Azure Portalへのアクセス
  portal.azure.com からサインイン。
  
  

• リソースグループ
  IoT Hubを配置するリソースグループを事前に作成しておくと後の管理が楽。

Azureポータルからのハブ作成

Azure Portalの検索窓で「IoT Hub」と入力し、サービス一覧から「IoT Hub」を選択します。「作成」ボタンから新規作成画面に進み、以下の項目を順に入力します。

• 基本タブ
  サブスクリプション・リソースグループ・IoTハブ名・リージョン（Japan East推奨）を指定。IoTハブ名はグローバルで一意である必要がある。
  
  

• ネットワークタブ
  接続方法（パブリックエンドポイント/プライベートエンドポイント）を選択。本番運用では、Private Linkを使ったプライベート接続が推奨される。
  
  

• 管理タブ
  価格レベル（Free/B1/S1など）と単位数を選択。検証ならFree、本番ならS1から開始。
  
  

• アドオンタブ
  Defender for IoTの有効化を選択。セキュリティ監視を強化する場合はON。
  
  

• 確認および作成
  入力内容を確認し、「作成」を押下してデプロイ開始。数分でハブが立ち上がる。

作成完了後、リソースの「概要」ページからIoT Hubの接続文字列を取得できます。この文字列がデバイスとの通信基盤の起点になるため、Azure Key Vaultなど秘密情報管理サービスに保管しておきます。

デバイスの登録と接続確認

ハブ作成後、実際のデバイス（またはシミュレーター）を登録して接続確認を行います。

• デバイスの追加
  IoT Hubの「デバイス」メニューから「+デバイスの追加」を選択。デバイスIDを指定し、認証方式（SASトークンまたはX.509）を選ぶ。
  
  

• 接続文字列の取得
  登録したデバイスの詳細画面から「プライマリ接続文字列」をコピー。これをデバイス側の実装に組み込む。
  
  

• サンプルSDKでのテスト送信
  Microsoftが公開しているIoT Device SDK（C・.NET・Python・Java・Node.js対応）を使い、テストメッセージを送信。Azure Portalの「メトリック」画面で受信を確認する。

ここまでで、Azure IoT Hubの基本構成は完成です。実運用ではこの後、メッセージルーティング設定・DPSとの連携・Azure Machine LearningやMicrosoft Fabricへの接続を段階的に組み立てていきます。

---

IoT検知データを予知保全AIから業務プロセスまで繋ぐなら

Azure IoT HubからAzure ML・Fabric Real-Time Intelligenceで予知保全モデルを組み立てるところまでは標準アーキテクチャで到達できます。ただし「異常検知→作業指示→保守記録→基幹反映」の業務プロセス側までAI化しないと、モデルが「アラートを鳴らすだけ」で終わります。

このレイヤーを担うのが、AI総合研究所のAI Agent Hubです。業務特化Agent群がOCR・基幹入力・異常検知後のフロー判定を代行し、Fabric OneLakeやBMS/CMMSと連携。Human-in-the-Loopで熟練保全者の承認を挟みながら判定基準をデータ資産化できます。

AI総合研究所の専任チームがIoT基盤とAIエージェントを組み合わせた業務プロセスAI化を伴走支援します。製造業向けサービスページで、IoT検知データが現場の業務プロセスにどう組み込まれるかご確認ください。

---

まとめ

本記事では、Azure IoT Hubの定義・Azure IoTサービス群での位置づけ、Azure IoT Operationsとの使い分け、主要機能と活用シーン、料金プランと選び方、Azureポータルでの作成手順を、2026年7月時点の最新情報で解説しました。要点を改めて整理します。

• Azure IoT Hubは「クラウド直結のデバイス通信基盤」というレイヤーに特化したマネージドサービスで、Azure IoTサービス群の中核として位置づけられている
  
  

• 2024年11月にGA・2026年3月の2603リリースで一部機能が追加GAされたAzure IoT Operationsとは競合せず、「クラウド接続はIoT Hub／工場全体のOTデータはIoT Operations」という2層構造で共存する
  
  

• 主要機能はD2C/C2Dの双方向通信・Device Twin・Direct Methods・メッセージルーティング・DPS連携・X.509認証の6つ。2025年11月以降のAzure Device Registry統合でX.509証明書のゼロタッチ更新が視野に入った
  
  

• 料金はFree・Basic（B1〜B3）・Standard（S1〜S3）の3層構造。双方向通信・Device Twin・IoT Edge統合を使うならStandard必須、本番は新規に有料IoT Hubを作成してS1（月額$25）から開始するのが実務的（Freeから有料への直接切り替えは不可）
  
  

• 作成手順はAzure Portalから30分程度で完了。ハブ作成→デバイス登録→SDKでのテスト送信までを最初のステップに据える

Azure IoT Hubは、IoT基盤の入口として2026年時点でも第一選択肢の位置づけを維持しています。まずはFreeティアで動作を確認し、要件が固まった時点で有料版IoT Hubを新規作成してS1本番運用へ移すのが、コスト効率と学習コストの両立を狙える現実的なパスです（Freeから有料への直接切り替えは公式に不可）。