Azure IoTとは？IoT Hub・IoT Operationsの使い分けから料金・移行判断まで解説

Azure IoT（アジュール アイオーティー）は、Microsoftが提供するデバイス接続・データ収集・エッジ処理・分析を統合したIoTプラットフォームです。

2026年現在、Azure IoTは「IoT Hub（クラウド接続型）」と「Azure IoT Operations（エッジ接続型）」の2軸に整理され、Microsoft Fabricと組み合わせた「Adaptive Cloud」戦略の中核として再定義されています。

本記事では、Azure IoTの全体像、2つの接続パターン、主要サービス、Azure IoT Operationsの新機能、Microsoft Fabricとの統合、料金体系、Azure IoT Central廃止への対応、導入判断で詰まる論点までを2026年7月時点の最新情報で解説します。

Azure IoTとは？モノとクラウドをつなぐMicrosoftのIoTポートフォリオ

Azure IoT（アジュール アイオーティー）とは、Microsoftが提供するIoTデバイスおよび産業機器を大規模に接続・管理・分析するためのサービス群の総称です。

単一のサービスではなく、クラウド側のIoT Hub、エッジ側の Azure IoT Operations、共通データ基盤のMicrosoft Fabricなどを組み合わせたポートフォリオとして提供されています。

026年現在、Azure IoTは単なる「デバイス接続サービス」にとどまらず、Adaptive Cloudアプローチの中核として、現場データとAIをつなぐレイヤーとして再定義されつつあります。

Microsoftは公式ドキュメントで、Azure IoTを「クラウド接続デバイスとオンプレミスOT環境を、共通の管理・データ・AIモデルの下で統合する」ポートフォリオとして位置づけています。

Adaptive Cloud時代のAzure IoTの位置づけ

2020年代後半に入り、Azure IoTは「デバイスを接続してデータを送るサービス」から、「工場・拠点・車両などの物理環境をAIで扱えるようにする土台」へと役割を広げてきました。

Microsoftはこれを「Adaptive Cloud」戦略と呼び、Azure IoTをその物理側のインターフェースとして位置づけています。

• 共通の管理プレーン（Azure Resource Manager）
  デバイス・エッジクラスタ・IoTサービスを、RBACやAzure Policyといった他のAzureリソースと同じ仕組みで統制する（Microsoft Learn）
  
  

• 共通のデータプレーン（Microsoft Fabric）
  デバイスから上がってくるテレメトリはFabricのReal-Time IntelligenceとOneLakeに直接流れ、Power BIやAI Foundryから利用される（Microsoft Learn）

ここでのポイントは、IoTを他のAzureサービスと切り離した「別世界」として扱わないことです。

デバイスも工場も、AIモデルもBIレポートも、同じARMリソースとして統制し、同じデータ基盤に集約する——これがAdaptive Cloud時代のAzure IoTの設計思想です。

---

Azure IoTの2つの接続パターン：Cloud-connected と Edge-connected

Azure IoTは接続方式で大きく2つのパターンに分かれます。デバイスがクラウドに直接つながる「Cloud-connected」と、現場のエッジ環境を経由してつながる「Edge-connected」です。

どちらを選ぶかで、使うサービスもアーキテクチャも変わるため、最初にこの軸を押さえておく必要があります。

Cloud-connected パターン（IoT Hub中心）

Cloud-connectedパターンは、デバイスがインターネット経由で直接Azureに接続する構成です。

Cloud-connectedパターンの全体構成：デバイスがIoT Hub・Device Provisioning・Device updates・Message routing等を経由してクラウドサービスに接続する（出典：Microsoft Learn）

図の左手にはIoTデバイス、真ん中にIoT Hubを中核とした「IoT cloud services」ブロック（Device registry・Service APIs・Device provisioning・Device updates等）、右手にはDevice management and controlやSolution backend／Analytics／Storageが並びます。デバイスとクラウドが直接1本のパイプでつながる構造がこのパターンの本質です。

配送トラック、家電、地理的に分散したセンサー群など、標準的なインターネットプロトコルで通信できるデバイスに向いています。中心となるのはAzure IoT Hubで、MQTT・AMQP・HTTPで数百万台のデバイスと双方向通信できます。

• 向いているケース
  デバイスが地理的に散らばっている／台数が多く一元管理したい／リアルタイム性はセカンド・スケーラビリティ優先
  
  

• 代表的な使い方
  配送車両のテレメトリ、家電のリモート診断、屋外センサーからの気象・環境データ収集

Edge-connected パターン（IoT Operations中心）

Edge-connectedパターンは、デバイスがまず現場のエッジ環境に接続し、そこで前処理してからクラウドに送る構成です。

Edge-connectedパターンの全体構成：現場のOPC UA・ONVIF等のデバイスがSouthbound connectivity→Message broker→Northbound connectivityを経由してクラウドサービスへ到達する（出典：Microsoft Learn）

図の下段には工場・拠点にあるOT機器（OPC UA server / ONVIF camera 等）、その上に南向き接続（Southbound connectivity）＋Message broker（pub/sub）＋北向き接続（Northbound connectivity）を含むEdge runtime environmentがあり、さらに上のCloudレイヤーへData routing・Storage・Analysis・Visualizationが接続されます。現場でデータを整えてからクラウドに渡すのがこのパターンの本質です。

工場のPLC、OPC UA対応の産業機器、監視カメラなど、産業用プロトコルを使うデバイスや、セキュリティ要件でインターネット直結を避けたい環境で必須になります。中心となるのは Azure IoT Operations で、Azure Arc対応のKubernetesクラスタ上で動きます。PLC×AIによる製造ライン最適化のような用途とも相性が良い構成です。

• 向いているケース
  OT（制御系）ネットワークが分離されている／低レイテンシの現場処理が必要／OPC UAなど産業プロトコルを扱う
  
  

• 代表的な使い方
  製造ラインの品質検査、設備の予知保全、プロセス製造の連続監視、エッジAIによる現場即時判定

2パターンの選び方

多くの企業では、両方を組み合わせて使うのが実務的な答えになります。以下の表で、どちらを起点に設計すべきかを整理しました。

判断軸	Cloud-connected（IoT Hub）	Edge-connected（IoT Operations）
デバイスの物理的な分散度	全国・全世界に分散	特定拠点（工場・倉庫）内
ネットワーク	インターネット直結OK	OTネットワーク分離／専用線
主要プロトコル	MQTT・AMQP・HTTPS	OPC UA・ONVIF・MQTT v5・カスタム
現場処理の要求	クラウド送信後の分析中心	ミリ秒単位の現場判定が必要
インフラ	クラウドサービス（PaaS）	オンプレKubernetes+Azure Arc

この表から見えるのは、Cloud-connectedは「デバイスを広く薄く管理する」用途、Edge-connectedは「特定拠点で深く早く処理する」用途に分かれるという点です。

工場現場のデータをAI分析に回したいが、車両にも同じ仕組みを展開したい、というケースでは両方を併用します。デバイスと資産の実体はAzure Device Registryを通じて1つのARMリソースとして扱えるため、管理面は統合できます。

---

Azure IoTを構成する主要サービス

Azure IoTは、接続層・管理層・分析層のそれぞれに独立したサービスを持ちます。ここでは2026年時点で押さえておくべき主要サービスを整理します。

「サービスが多くて何から手をつけるべきかわからない」という状態は、この構成表で解消するはずです。

IoT Hub：クラウド接続の中核

Azure IoT Hubは、クラウドとデバイスを双方向で結ぶマネージド接続サービスです。数百万台のデバイスを、標準プロトコル（MQTT・AMQP・HTTPS）で接続し、テレメトリ受信・コマンド送信・デバイスツイン管理・ファイルアップロードなどをまとめて提供します。

Cloud-connectedパターンの中心であり、IoT Hubがなければクラウド側のデバイス管理が成立しません。詳細は本記事のIoT Hub料金セクションおよび別記事でも扱っています。

Azure IoT Operations：エッジ接続の中核（2026年新主力）

Azure IoT Operationsは、Azure Arc対応のKubernetesクラスタ上で動くエッジ統合データプレーンです。

MicrosoftはAzure IoT Operationsを「新規のエッジ接続ソリューション向けの推奨プラットフォーム」と明言しており、Azure IoT Edge（1.5 LTSは2026年11月までサポート）から段階的に移行する流れが公式に示されています。詳細は次のセクションで扱います。

Azure Digital Twins：現実世界のモデル化

Azure Digital Twinsは、工場・ビル・都市などの物理環境を、モデルとしてクラウドに再現するサービスです。

デバイスの「状態」だけでなく、「工場ラインAは製品ラインBに部品を供給する」といった関係性まで表現できます。IoT HubやIoT Operationsから届いたテレメトリを、意味のあるビジネス構造に紐付ける役割を担います。

Device Provisioning Service（DPS）：デバイス自動登録

Device Provisioning Serviceは、大量のデバイスを IoT Hubに自動割り当てするサービスです。

例えば10万台のセンサーを世界各地に出荷するとき、工場出荷時点では接続先IoT Hubが決まっていなくても、DPSがデバイスを起動時に最適なIoT Hubに登録してくれます。工場でファームウェアに個別接続情報を書き込む必要がなくなるため、大規模展開で必須のサービスです。

Device Update for IoT Hub：ファームウェア更新

Device Update for IoT Hubは、デバイスに対してOTA（Over-The-Air）でファームウェアや設定を配布するサービスです。

現在の安定APIバージョンはAPI 2022-10-01で、Microsoft公式によれば最新のエージェント参照実装は1.3.0（2026年5月リリース）です。非推奨版でも最低3年の移行猶予が保証されているため、工場出荷後もセキュリティパッチを送り続けたい産業機器で特に重要な機能となります。

Azure Device Registry：デバイスをAzureリソース化

Azure Device Registryは、IoT HubやIoT Operationsに接続されたデバイス・資産をARMリソースとして扱えるようにするサービスです。

Azure Portal・CLI・Bicep・ARMテンプレートといった既存のAzure運用ツールで、デバイスにもRBACやAzure Policyを適用できます。IoT Hub側とIoT Operations側で管理体系がバラバラだった時代のAzure IoTから、統合的な運用が可能になった転換点でもあります。

Azure IoT Central：SaaS型IoTアプリ基盤（廃止予定）

Azure IoT Centralは、ノーコードでIoTアプリケーションを構築できるSaaSプラットフォームです。

ただし2027年3月31日での廃止が公式にアナウンスされており、2024年4月1日以降は新規アプリケーションを作成できません。詳細と移行判断は本記事後半で扱います。

以下の表で、各サービスの位置づけを整理しました。

サービス	役割	位置づけ
IoT Hub	クラウドとデバイスの双方向通信	Cloud-connectedの中核（GA）
Azure IoT Operations	エッジ統合データプレーン	Edge-connectedの中核（GA）
Azure Digital Twins	物理環境のモデル化	意味付けレイヤー
DPS	デバイス自動プロビジョニング	大規模展開の必須補助
Device Update for IoT Hub	OTA更新	ライフサイクル管理
Azure Device Registry	ARMリソース化	Adaptive Cloud統合の要
Azure IoT Central	SaaS型IoTアプリ基盤	2027年3月廃止予定

この表から読み取れるのは、IoT HubとAzure IoT Operationsが2つの主軸で、他は補助・共通サービスに位置づけられているという点です。

新規案件を設計するときは、まず「Cloud-connected か Edge-connected か」を決め、そのうえでDPSやDigital Twinsを組み合わせる、という順序で考えると迷いません。

---

Azure IoT Operations：2026年の新主力プラットフォーム

ここからは、2026年のAzure IoTで最も注目度が高い Azure IoT Operations について詳しく整理します。

Microsoftが「新規のエッジ案件はIoT Operations推奨」と明言しているため、これから設計する現場側IoTのほとんどが、この基盤を前提にすることになります。

Azure IoT Operationsの基本設計

Azure IoT Operationsは、オンプレミスのKubernetesクラスタ（Azure Arc経由でAzureに接続）の上で動くモジュラー型のデータサービス群です。

Azure IoT Operations Portal Overview：MQTT broker listeners・MQTT broker authentication policies・Data flow profiles・Connector templates・Registry endpointsの状態が1画面で確認でき、右パネルからOPC UA connectorを含むOptional componentsを追加できる（出典：Microsoft Community Hub）

Portal を開くと、左サイドにOverview／Activity log／Access control／Components（MQTT broker・Data flow profiles・Connector templates・Registry endpoints）／Monitoring等が並び、中央に各コンポーネントのプロビジョニング状態が円グラフで表示されます。

右側の Optional components からOPC UA connectorのような追加コネクタを有効化できるのも、IoT Operationsが「モジュラー構成」で作られていることを示しています。

工場や倉庫のエッジで、MQTTブローカー・データフロー処理・OPC UA/ONVIF/RESTなど産業プロトコルの接続・南北両方向のルーティングまでを1つの基盤で担います。

従来のIoT Edgeが「デバイスにコンテナを配布するランタイム」だったのに対し、IoT Operationsは「エッジのデータ処理全体を統合するプラットフォーム」まで役割を広げました。

2603リリースで入った主要機能と最新2606

Microsoft Community Hubで公開されているAzure IoT Operations 2603（v1.3.38）のリリースノートによれば、2026年3月の2603リリースで以下の3つがGAに昇格しました。

2026年7月時点の最新GAは2606（v1.3.137）で、こちらは2603のGA機能を土台にセキュリティ・安定性のパッチが積まれています。

• ノーコード データフロー グラフ（GA）
  カスタムWebAssemblyの実装なしに、変換・フィルタリング・エンリッチメントをUI上で組める
  
  

• クラウドツーエッジ管理アクション（GA）
  ARMとEvent Gridベースのメッセージングで、クラウドから現場資産に対して制御命令・設定変更を安全に流せる
  
  

• MQTTコネクタ（GA）
  外部MQTTブローカーとの接続がGA化。ThingsBoard・HiveMQなど既存資産との相互運用がしやすくなる

これらは「工場・現場で回している運用を、クラウドから見て制御する」ためのピースです。これまで PoC 止まりだった案件を本番運用に載せるうえで、ノーコードデータフローとクラウドツーエッジ管理は特に効きます。

ノーコード データフロー グラフ エディタ：Buffer-data→Check-if-valid→Split-by-type→Contextualize/Reshape→Merge-allの処理を組み立て、右パネルでbranch条件やInputsを設定する（出典：Microsoft Community Hub）

エディタの左側でBuilt-in Window（Buffer-data）／Built-in Branch（Check-if-valid）／Custom Split／Built-in Map（Contextualize・Reshape）／Built-in Concatenate（Merge-all）といったブロックを配線し、右パネルでExpression（「$1 <= 30 && $2 <= 95」のような条件）やInputs（weight・volume）を編集していきます。

従来はWebAssemblyのカスタムコードでしか組めなかった変換を、この画面だけで組み立てられる点が2603 GAの実務的インパクトです。

Create asset ワークフロー：Onvif・Media・Mqtt・OpcUa・Http・SSEHttp等のInbound endpointから接続元を選び、Asset name・Custom propertiesを入力して現場アセットをAzureリソースとして登録する（出典：Microsoft Community Hub）

このウィザードは「クラウドツーエッジ管理アクション」の入口の1つで、ARMとEvent GridベースのMQTTメッセージングを通じて現場アセットに制御命令を届けられます。

Inbound endpointの一覧に Microsoft.Onvif・Microsoft.Mqtt・Microsoft.OpcUa・Microsoft.Http などの主要産業プロトコルが並んでいることが、IoT Operationsが実際にどこまでのプロトコルをカバーしているかを示しています。

Physical AI基盤としての役割

Microsoftは、Azure IoT Operationsを「Physical AIシステムを産業規模で構築・展開・運用するための基盤」と位置づけています。

Physical AIとは、現実世界の物理環境に対して知覚・推論・行動を行うAIのことです。詳しくは物理AI（Physical AI）の解説記事にまとめています。

Azure IoT Operationsは以下の役割を担うことで、Physical AIの土台になります。

• 現場デバイスから高頻度テレメトリを取り込む
• スキーマ・アセット定義に沿って構造化する
• エッジ側でAI推論を回して即時判断する（ミリ秒級レイテンシ）
• クラウド側のFabricへ集約してクラウドAI・Copilotで活用する

これらのステップは、Microsoft公式が示す「Raw telemetry → Structured → Contextualized → Analysis-ready → AI-ready」というデータパイプラインに対応しています。

Azure IoT Operationsは、このパイプラインの最初の3段階を担う「エッジ側の受け皿」として設計されています。

IoT EdgeからIoT Operationsへの移行

現在Azure IoT Edgeを使っている場合、いきなり全面移行する必要はありません。IoT Edge 1.5 LTSは公式ロードマップで2026年11月までサポートが約束されており、既存の運用は続けられます。

加えて次期LTSのIoT Edge 1.6は.NET 10 LTSに合わせて計画されており、公式ロードマップでは2028年11月14日までのサポートが予定されています。IoT Edgeを完全に廃止する動きではなく、IoT Operationsと並走する方針が示されている点は押さえておく価値があります。

---

Microsoft FabricとAzure IoTの統合：Real-Time IntelligenceとPhysical AI

Azure IoTを2026年時点で語るなら、Microsoft Fabricとの統合は避けて通れません。

Fabricは、Azure IoTの「共通データプレーン」として公式に位置づけられており、IoT Hub／IoT Operationsどちらの経路でも、最終的にはFabricでデータを扱う設計が主流になっています。

Real-Time Intelligenceがデータ受け口になる

Fabric Real-Time Intelligence（RTI）は、ストリーミングデータを取り込み・変換・保存・分析するFabricのワークロードです。

Fabric Real-Time Intelligenceの全体構成：Kafka・SQL・Cosmos・MQTT等のソースからIngest & Process（Eventstream）→Analyze & Transform（Eventhouse・KQL Queryset・Real-Time Dashboard・Digital Twin Builder）→Act（Activator・Power BI）へと流れ、下地にOneLakeがある（出典：Microsoft Learn）

左の入力ソースブロックにIoTでよく使われるMQTTが含まれている点、真ん中の3層（Ingest & Process → Analyze & Transform → Act）で従来の複数サービスを1つのワークロードに束ねている点、そしてすべてがOneLake上に載っている点が、この図の要点です。

IoT Hubからのデータも、この左端のブロック群と同じレイヤーからEventstream経由で流れ込みます。

IoT HubはEventstreamにネイティブ接続できるため、デバイスから来たテレメトリをそのままRTIに流し、KQLでリアルタイム集計したりPower BIダッシュボードに繋いだりできます。

従来はAzure Stream Analytics＋Event Hubs＋Data Explorer＋Power BIと複数サービスを繋いでいた構成が、Fabric側で一本化されました。

以下の表で、従来の構成とFabric統合後の構成を比較しました。

フェーズ	従来（〜2024年）	Fabric統合後（2026年）
データ受信	IoT Hub → Event Hubs	IoT Hub → Fabric Eventstream
ストリーミング処理	Azure Stream Analytics	Fabric Real-Time Intelligence（Eventhouse）
保存	Azure Data Lake Storage	OneLake
分析	Azure Data Explorer	Fabric KQL Database
可視化	Power BI（別接続）	Power BI（Fabric内蔵）

この表から分かるのは、サービス名は変わっても機能自体は連続していること、そして統合先が「Azure＋Power BI」から「Fabric内で完結」に集約されたという点です。

既存のStream Analytics＋Event Hubs構成をすぐに捨てる必要はありませんが、新規のIoT分析基盤はFabric起点で組むのが2026年の標準的な設計になります。

Fabric IQでデバイスデータを「AI-ready」にする

Fabric IQは、資産・拠点・データポイントの意味的な関係をオントロジーとしてモデル化する機能です。

「温度センサーAが検知した異常は、生産ラインBのコンベア3番の温度上昇を示す」といった業務コンテキストをFabricに持たせられます。これによって、Microsoft CopilotやAI Foundryの上位モデルが、単なる統計異常ではなく「工場ライン運用として意味のある異常」を判定できるようになります。

Azure IoTから流れてくる大量のテレメトリを、Fabric IQで意味付けし、Copilotで自然言語対話に落とす——この一連の流れが、2026年のAzure IoT設計における標準的なアーキテクチャです。

---

Azure IoT Hubの料金体系

Azure IoT Operationsは公式pricingによれば「AIOワークロードを稼働させるArc対応Kubernetesノード数」に対する課金と、Azure Device Registryの「登録済み／検出済みのasset・device数」に対する課金の2軸で構成されます。

加えて外部データサービスへの接続で別料金が発生する可能性があるため、Operations採用時は3層でコストを見積もる必要があります。まずはメッセージ課金型のIoT Hub側の把握が優先です。

3つの料金ティア（Free / Basic / Standard）

IoT Hubは、無料検証用のFree、シンプルなテレメトリ用途のBasic、双方向通信を含む本格運用のStandardという3ティアで提供されています。

• Free
  デバイスID最大500・1日8,000メッセージまで。PoC専用
  
  

• Basic（B1/B2/B3）
  デバイス→クラウドのテレメトリ送信中心。B1は月額約$10（Japan East／2026年7月時点）で400,000メッセージ／日
  
  

• Standard（S1/S2/S3）
  テレメトリに加えて、クラウド→デバイスのコマンド送信・デバイスツイン・IoT Edge・Direct Methodsをフルサポート。S1は月額約$25で400,000メッセージ／日

B/S ティアの機能差

料金は倍以上違いますが、機能差は明確です。以下の表で、両ティアの主な機能をまとめました。

機能	Basic	Standard
デバイス→クラウド テレメトリ	対応	対応
各デバイスIDプロビジョニング	対応	対応
メッセージルーティング	対応	対応
クラウド→デバイス コマンド	非対応	対応
デバイスツイン（双方向状態同期）	非対応	対応
Direct Methods（即時RPC）	非対応	対応
IoT Edgeサポート	非対応	対応
Device Streams（プレビュー）	非対応	対応

この比較から分かるのは、「一方向でデータを吸い上げるだけならBasic、遠隔制御・状態同期・エッジ処理が必要ならStandard」という切り分けです。

工場ラインの温度監視のようにテレメトリ送信のみで済むケースはBasicで十分ですが、車両の遠隔ロック・家電の遠隔制御など「送るだけでなく操作もする」ケースはStandardが必須になります。

メッセージ課金の計算方法

IoT Hubは、メッセージを4KB単位のチャンクで課金します。100バイトのメッセージも、6KBのメッセージも、それぞれ「1メッセージ」「2メッセージ」として数えます。

例えば1台のデバイスが1分ごとに1KBメッセージを送ると、1日あたり1,440メッセージになります。1,000台なら144万メッセージ／日で、これはS1（400,000／日）を超えるためS2または追加ユニットが必要になります。

コスト削減の定石は、複数センサー読み取りをバッチ化して1メッセージにまとめることです。40回分の100バイト読み取り（合計4KB）を1メッセージにまとめれば、40件が1件にまとまり、S1でも同じ台数を捌けます。

料金選定で注意したいポイント

料金だけを見てBasicを選ぶと、後で機能不足に気づいてStandardに切り替えることになりがちです。逆にStandardを最初から選ぶと、SKUによって差はあるものの、B1/S1で約2.5倍、B2/S2・B3/S3では約5倍のコストが不必要にかかります。

実務では、PoCはFree→本番稼働の最小単位でBasicかStandardを選定→メッセージ量に応じてユニット数を増やす、という段階的なアプローチが安全です。デバイスツインやIoT Edgeを将来使う可能性が少しでもあるなら、最初からStandardで組む方が結果的に安く済みます。

---

Azure IoT Centralの廃止（2027年3月31日）と移行判断

Azure IoT Centralを使っている企業にとって、2026〜2027年は避けて通れない意思決定期になります。

Microsoftは2024年2月の告知以降、IoT Centralの廃止スケジュールを段階的に明確化しています。

廃止スケジュールの整理

以下の表で、公式にアナウンスされているスケジュールをまとめました。

時期	何が起きるか
2024年4月1日	新規のIoT Centralアプリケーション作成が停止
2024年〜2026年	既存アプリは動作継続、サポートも継続
2027年3月31日	Azure IoT Centralサービス完全終了

この表から明らかなのは、「今すぐ止まる」わけではないが、新規開発の選択肢からは既に外れているという点です。

既存アプリを2027年3月まで運用したまま、その間に移行先を選定する時間はあります。ただし後述の通り移行先の選択は簡単ではないため、早めの意思決定が必要になります。

3つの移行ルート

Microsoftは公式には「直接の後継サービス」を提示していません。実務的な移行ルートは以下の3つに整理できます。

• ルート1：IoT Hub + Fabric/Power BI/Azure Web Apps で内製再構築
  IoT CentralのUI・ダッシュボード・ルール機能をSaaSとして活用していた場合の主ルート。IoT Hubでデバイス接続、Fabric Real-Time IntelligenceとPower BIでダッシュボード、Web AppsやAzure Functionsでカスタムルール処理を組み合わせて自前で構築する。柔軟性は最も高いが工数は最も大きい
  
  

• ルート2：Azure IoT Operationsへの移行（エッジ資産管理中心のケースのみ）
  IoT Centralを「エッジ側の資産管理・OTデータ収集の受け皿」として使っていた場合のみ、Azure IoT Operationsに移行するのが2026年の推奨ルート。Azure Device Registryでデバイスと資産の管理を統合できる。SaaS型UI・ダッシュボード・ルール機能の直接代替ではない点に注意
  
  

• ルート3：サードパーティIoTプラットフォームへの乗り換え
  ノーコードのSaaS運用の使い勝手を優先するなら、DavraなどのIoT Central互換型プラットフォームへの移行も選択肢

移行判断のポイント

「どの移行ルートを選ぶか」は、現在のIoT Centralの使い方によって答えが変わります。

アプリUI・ダッシュボード・ルール機能をSaaSとしてフル活用してきたなら、ルート1（IoT Hub＋Fabric/Power BI/Web Apps）またはルート3（サードパーティSaaS）が現実的です。逆にIoT Centralを「エッジ資産管理・OTデータ収集の受け皿」として使ってきたなら、ルート2（IoT Operations）で自然に置き換えられます。この見極めを飛ばすと、Operationsで代替できないSaaS UXまで無理に置き換えようとして工数が跳ね上がります。

実務観点では、2026年内に現行アプリの機能棚卸しを行い、移行先を確定させて、2026年後半〜2027年前半で実装・並行運用を進めるスケジュールが現実的です。廃止直前になって焦って移行すると、業務停止リスクが跳ね上がります。

---

Azure IoT導入で詰まる3つの判断論点

ここでは、Azure IoTの導入検討で実際に判断が難しくなるポイントを、SIerとして支援する立場から整理します。

「Azure IoTを使いたい」だけでは決まらず、以下の3つのどこかで詰まるケースが多く見られます。

1：IoT Hub と Azure IoT Operations のどちらから始めるか

新規プロジェクトで最初に迷うのが、Cloud-connected（IoT Hub）とEdge-connected（IoT Operations）の選択です。

現場側のデバイスがOPC UA・ONVIFなどIoT Operationsの標準コネクタで扱えるプロトコルを話す、あるいはOT分離要件でインターネット直結を避けたいならIoT Operationsが有力です。Modbusのような追加コネクタ・ゲートウェイが必要なプロトコルは、カスタムコネクタ実装かゲートウェイ経由の構成を前提に判断します。逆にデバイスがすでにMQTT/HTTPS対応で、インターネット経由でクラウドに直接繋がるならIoT Hubで十分です。

判断で最も見落とされがちなのは、「OT側のネットワークセキュリティ要件」です。

工場では外部インターネットへの直接接続が禁じられているケースが多く、この時点でCloud-connected構成は成立しません。ネットワーク管理者・OT担当者との事前合意が、サービス選定より先に必要になります。

2：Azure IoT を使うか、AWS IoT を使うか

Microsoftを含めた3大クラウドのIoTサービス選定も、判断で詰まる論点です。

Google Cloud IoT Coreは2023年8月に廃止済みのため、実質的にAzureかAWSの2択になります。両者の違いを以下の表で整理しました。

判断軸	Azure IoT	AWS IoT
Microsoftエコシステム統合	ARM・Fabric・Power BIとネイティブ統合	別途連携が必要
エッジ機能	Azure IoT Operations（Arc + Kubernetes）	AWS IoT Greengrass
産業プロトコル対応	OPC UA・ONVIF標準サポート	Greengrass Components経由
デバイス数課金	メッセージ課金	接続数＋メッセージ課金
日本国内の実装事例	業種・用途ごとに個別確認（公式導入事例ページ参照）	業種・用途ごとに個別確認（公式導入事例ページ参照）

この比較から見えるのは、M365・Fabric・Power BI をすでに使っている企業ならAzure IoTが有利、一方でAWSクラウドをベースにしたモダンWebアプリの延長ならAWS IoTという棲み分けです。

製造業や大企業の情シスが「クラウド全社標準化」を進めているケースでは、Azure IoTがそのままフィットすることが多くなります。

3：PoCから本番までのスコープをどう区切るか

3つ目に多いのが、「PoCと本番のスコープ設計」で詰まるケースです。

多くのプロジェクトは、10台のセンサーで始めるPoCと、1万台のデバイスを扱う本番で、根本的にアーキテクチャが変わります。

PoC段階でIoT HubのS1・1ユニットで十分でも、本番段階では複数ユニット・DPS・Device Update・Fabric連携まで含めた全体設計が必要になります。

実務的な進め方としては、以下の3段階が現実的です。

• フェーズ1（PoC・1〜3ヶ月）
  IoT Hub Free またはB1・Standardの単一ユニットで10〜100台を接続し、データが正しく上がることを確認
  
  

• フェーズ2（パイロット・3〜6ヶ月）
  1拠点分（1,000台規模）で本番相当の運用を試し、Fabric連携・ダッシュボード・アラート運用を検証
  
  

• フェーズ3（本番展開・6ヶ月〜）
  DPSでデバイス配布を自動化、Device Updateで運用を回し、複数拠点・複数万台に拡張

この段階設計を最初にざっくり描いておかないと、PoC成功→本番でアーキテクチャ再設計→3〜6ヶ月ロスというパターンに陥ります。

実務観点では、フェーズ2の「1拠点1,000台規模」で一度きちんとFabric連携まで通しておくことが、大規模展開の成功率を大きく左右します。

【関連記事】
スマートファクトリー完全ガイド｜仕組み・成熟度4段階・2026年Agentic AI動向を解説
製造業IoT×AI活用事例！データ収集からAI予測・自動化まで解説

---

AzureのIoTとAIを業務にどう組み込むかを整理する

Azure IoTとMicrosoft Fabricの組み合わせは、単なるデータ収集ではなく、AIを業務に埋め込むための土台になります。

現場のセンサーデータ、設備の稼働情報、品質検査ログ——これらをFabric経由でCopilotやAI Foundryに繋げると、「今月の稼働率を改善する打ち手は何か」「異常発生の兆候はどのラインで見えているか」といった問いに、AIが業務コンテキストで答えられるようになります。

ただし単体ツールの導入だけで成果が出るわけではありません。PoCの設計、部門展開の順序、統制・セキュリティのチェックポイントまで含めた業務設計が必要になります。

AI業務自動化ガイド（220ページ）では、PoC段階から全社展開までの進め方、部門別のユースケース、統制・セキュリティ観点でのチェックポイントを整理しています。Azure IoT×Fabric×AIを実業務に落とすときの参考にご活用ください。

---

まとめ：Azure IoTの現在地と選び方

本記事では、2026年7月時点のAzure IoTの全体像と実務判断のポイントを整理しました。

• Azure IoTは「Cloud-connected（IoT Hub）」と「Edge-connected（IoT Operations）」の2軸で選ぶポートフォリオ
• Azure IoT Operationsは2603で主要3機能がGA化、2026年7月時点の最新GAは2606で新規のエッジ案件の第一候補に
• Microsoft Fabricとの統合により、Real-Time Intelligenceが標準のデータ受け口になった
• Azure IoT Hubの料金はメッセージ課金で、Basic月額約$10・Standard月額約$25から
• Azure IoT Centralは2027年3月31日で廃止、既存アプリの棚卸しと移行先選定を2026年内に
• 導入判断で詰まりやすいのは「Hub vs Operations」「Azure vs AWS」「PoC vs 本番スコープ」の3論点

Azure IoTは、単発サービスの選択ではなく、Adaptive Cloudの思想に沿ったポートフォリオ選択が本質です。まずは自社のデバイス・ネットワーク・データ活用の現状を棚卸しし、Cloud-connectedとEdge-connectedのどちらを起点にするかを決めるところから始めるのが、迷わない設計への近道になります。