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、ストレージなどへ流せる

仕様・制限・クォータ

• Kubernetes 前提: Arc 対応の Kubernetes クラスターが必要。現場サーバーや産業用 PC 上に構築する
• オープン標準ベース: メッセージングは MQTT、産業データ取り込みは OPC UA、イベント表現は CloudEvents など、標準仕様に沿って構成される
• クラウド連携は Arc 経由: 構成のデプロイ・管理は Azure Arc とクラウド側のコントロールプレーンを通じて行う
• 宛先の種類: データフローの送り先は Event Hubs / Event Grid / Fabric・OneLake / ストレージなど複数に対応する（対応宛先は拡充される）
• 資源はクラスター依存: 処理スループットや扱えるデータ点数は、現場クラスターの CPU・メモリ・ストレージといったハードウェア資源に実質的に左右される
• 対応プロトコル・宛先・上限値・課金体系は更新されるため、最新は公式ドキュメントで確認すること

内部の仕組み

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 コンポーネントの更新計画をあらかじめ用意する

コスト

費用は主に、現場の Kubernetes クラスターを動かすハードウェア・運用費と、データフローの送り先となるクラウドサービス側の課金（Event Hubs のスループット、Fabric/OneLake の容量、ストレージなど）から生じます。Azure Arc によるクラスター管理にも体系があります。エッジで前処理して送信量を減らすほど、クラウド側の取り込み・保存・処理コストを抑えられます。具体的な料金は変動するため、最新の価格情報で確認してください。

セキュリティ

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

関連サービス・比較

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

ハンズオン / CLI例

# IoT Operations 拡張機能を追加（未導入なら）
az extension add --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

# IoT Operations インスタンスを作成
az iot ops create \
  --resource-group demo-rg \
  --cluster demo-cluster \
  --name demo-iotops

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