Azure IoT Operations

解決する課題

工場や設備の現場では、機器ごとにプロトコルが異なり、データの取り込み・正規化・クラウド連携をそれぞれ個別に作り込みがちです。Azure IoT Operations は、こうした現場データの収集から処理・送信までを Arc 対応 Kubernetes の上で動く統合基盤として提供し、ばらばらな仕組みの寄せ集めを置き換えます。

• 機器ごとに違うプロトコルや独自実装を、標準技術（MQTT・OPC UA）に揃えて扱いたい
• 生データを全部クラウドへ送らず、現場で変換・正規化・集約してから送りたい
• 取り込んだデータを、用途別に複数のクラウド宛先へ同時に振り分けたい
• エッジの構成を職人芸の手作業ではなく、Kubernetes の宣言的な仕組みで再現性高く管理したい
• 特定ベンダーやプロトコルに閉じず、オープン標準で移植性を確保したい

主要概念と用語

• Arc 対応 Kubernetes: オンプレや現場の Kubernetes クラスターを Azure Arc 経由でクラウドから管理する仕組み。IoT Operations はこの上に展開される
• MQTT ブローカ: エッジ内のメッセージング中核。コンポーネント間およびデバイスとのパブリッシュ/サブスクライブ通信を担う、可用性を考慮したブローカ
• コネクタ（OPC UA など）: 産業機器の標準プロトコル OPC UA などから資産データを取り込むコンポーネント。サーバーへ接続してタグ値を読み出す
• 資産（アセット）と資産エンドポイント: 現場の物理機器を論理的に表したモデルと、その接続先定義。どの機器のどのデータ点を取り込むかを構成する
• データフロー: 取り込んだデータを変換・エンリッチ・ルーティングして宛先へ流す処理パイプライン。ソース・変換・宛先を宣言的に定義する
• スキーマレジストリ: データの構造（スキーマ）を登録・参照する仕組み。正規化や下流連携の土台になる
• クラウド宛先: データフローの送り先。Event Hubs、Event Grid、Microsoft Fabric / OneLake、ストレージなどへ流せる

仕様・制限・クォータ

• 現行版: 2026年7月時点の最新版は 1.3.x。1.3 / 1.2 / 1.1 がサポート対象で、1.0 は対象外。直前版にはセキュリティ修正が配布されないため、実運用は最新版へ更新する
• 更新停止: ライブアップグレードとダウングレードには対応しない。更新時の停止時間を計画し、プレビュー版と GA 版の相互更新は再インストールになる
• Kubernetes 前提: Arc 対応 Kubernetes が必要。単一ノードは最低 4 vCPU / 16 GB RAM / 30 GB、可用性を求める 3〜5 ノード構成は各ノード 8 vCPU / 32 GB RAM を出発点に実負荷で測る
• オープン標準ベース: MQTT ブローカは MQTT 3.1.1 / 5 に対応し、端末側コネクタは OPC UA、HTTP/REST、SSE、MQTT などを扱う
• クラウド連携は Arc 経由: 構成のデプロイ・管理は Azure Arc とクラウド側のコントロールプレーンを通じて行う
• 宛先の種類: MQTT（組み込みブローカ / Event Grid MQTT）、Kafka（Event Hubs を含む）、OpenTelemetry、Data Lake、Fabric OneLake、Azure Data Explorer、ローカルストレージを使い分ける。ストレージ系はスキーマ指定が必要
• 資源はクラスター依存: 処理スループットや扱えるデータ点数は、現場クラスターの CPU・メモリ・ストレージといったハードウェア資源に実質的に左右される
• 切断運用: クラウドから切断した状態は最大72時間を想定し、その間は機能低下があり得る。長期切断は別途設計する
• 配信保証: MQTT QoS 0 は最大1回、QoS 1 は少なくとも1回、QoS 2 は非対応。購読キューは既定でメモリ上にあり、再起動をまたぐにはセッション有効期限、ブローカ永続化、データフローの永続化要求をそろえる
• 耐障害性: ノード障害時の損失を避けるには最低3ノードと適切な複製数が必要。クラスター全停止やクォーラム喪失では、永続ボリュームを構成していても復旧設計と容量監視が要る

内部の仕組み

横にスクロール

IoT Operations は、Arc 対応 Kubernetes クラスターの上に複数のコンポーネントを展開して動きます。中心にあるのが MQTT ブローカで、エッジ内のすべてのデータがここを通って流れます。各コンポーネントはブローカに対してパブリッシュ／サブスクライブする形で疎結合に連携するため、部品単位で差し替えや拡張ができます。

データの入口はコネクタです。OPC UA などのコネクタが現場の機器へ接続し、構成された資産・データ点を読み出して MQTT ブローカへ流し込みます。どの機器のどのタグを取り込むかは、資産（アセット）と資産エンドポイントとして宣言的に定義します。

ブローカに集まったデータはデータフローが処理します。データフローはソース（ブローカ上のトピックなど）を購読し、フィルタリング・変換・エンリッチ・正規化を施したうえで、Event Hubs や Microsoft Fabric などのクラウド宛先へ送ります。1 つのソースから複数の宛先へ振り分けることもでき、用途ごとにデータを流し分けられます。

これら全体の構成は Kubernetes と Azure Arc の宣言的な望ましい状態として管理されます。クラウド側で目標構成を定義すると、現場クラスターがそれに収束するよう調整される、というモデルです。

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

• エッジで絞ってから送る: 生データを全部送らず、データフローで集約・フィルタ・サンプリングしてからクラウドへ流し、帯域と下流コストを抑える
• 標準プロトコルに寄せる: 機器側を可能な限り OPC UA など標準に揃え、独自プロトコルはコネクタ層で吸収して上流を単純に保つ
• 宛先を用途で分ける: 分析用は Fabric、リアルタイム連携は Event Hubs/Event Grid など、データフローで宛先を使い分ける
• スキーマで正規化: スキーマレジストリで構造を定義し、機器ごとにばらつくデータ表現を下流が扱いやすい形へ正規化する
• 宣言的に管理する: クラスター構成・資産・データフローを宣言的定義（GitOps など）で扱い、再現性と監査性を高める
• 疎結合を維持: コンポーネント間は MQTT ブローカ越しに連携させ、個別の差し替え・段階更新をしやすくする

運用・監視

• Arc からの一元管理: クラスターと IoT Operations の構成を Azure Arc 経由でクラウドから把握・更新する
• Kubernetes 標準の運用: 各コンポーネントは Kubernetes 上で動くため、ポッドの状態・ログ・再起動といった標準的な運用手法がそのまま使える
• メトリクスとログ: 稼働状況・データ流量・エラーを Azure Monitor などに取り込んで可視化し、コネクタやデータフローの健全性を追跡する
• 構成のバージョン管理: 宣言的定義をリポジトリで管理し、変更履歴とロールバックを可能にする
• クラスターの更新運用: 現場クラスターの OS・Kubernetes・IoT Operations コンポーネントの更新計画をあらかじめ用意する

コスト

Azure IoT Operations は、インスタンスのワークロードを配置した Kubernetes ノード数を時間単位で課金します。インスタンス作成後の最初の30日分の利用記録は試用扱いです。Azure Device Registry は登録済み・検出済みの資産と端末を時間単位で別課金し、端末課金は2026年5月1日に開始されています。これに現場ハードウェア、AKS Arc 等の基盤、Event Hubs / Fabric / Storage など宛先側の料金が加わります。

セキュリティ

• Arc 経由の認証・管理: クラスターは Azure Arc に接続して認証・構成管理され、クラウド側の ID 基盤と統合できる
• シークレット管理: 機器接続情報や鍵は、Key Vault 連携など安全な仕組みで扱い、平文で散らさない
• コンポーネント間の保護: MQTT ブローカを介した通信を保護し、不要な露出を避ける
• 最小権限: 各コンポーネントやコネクタに必要最小限の権限のみを与え、現場機器を直接クラウドへ晒さない
• データのローカル処理: 機密データを現場内で変換・匿名化してから送ることで、外部流出リスクを下げられる

関連サービス・比較

エッジでワークロードを実行するという点では、コンテナ化したモジュールを動かす Azure IoT Edge と方向性が重なります。ただし IoT Edge が個別モジュール（コンテナ）の実行基盤であるのに対し、IoT Operations は Kubernetes 上で産業データの取り込み・処理・送信を統合した、よりデータプレーン寄りの基盤です。ここでは両者を比較します。

ハンズオン / CLI例

# IoT Operations拡張機能を最新版へ更新
az extension add --upgrade --name azure-iot-ops

# Arc 対応 Kubernetes クラスターを登録（事前に接続しておく）
az connectedk8s connect \
  --resource-group demo-rg \
  --name demo-cluster

# クラスターの前提条件を検証
az iot ops verify-host

# クラスターを IoT Operations 用に初期化
az iot ops init \
  --resource-group demo-rg \
  --cluster demo-cluster

# スキーマレジストリとDevice Registry名前空間を準備後、インスタンスを作成
az iot ops create \
  --resource-group demo-rg \
  --cluster demo-cluster \
  --name demo-iotops \
  --sr-resource-id <スキーマレジストリのリソースID> \
  --ns-resource-id <Device Registry名前空間のリソースID>

# デプロイされたインスタンスの状態を確認
az iot ops instance show \
  --resource-group demo-rg \
  --name demo-iotops \
  --output table