Azure IoT Edge

解決する課題

工場・店舗・車両などの現場では、すべてのデータをクラウドへ送ってから処理する方式が必ずしも適しません。Azure IoT Edge は、クラウドで開発したロジックをエッジ機器側へ持ち込んで実行することで、こうした制約を解消します。

• ネットワークが不安定・断続的でも、ローカルで処理を継続したい（オフライン耐性）
• センサーの大量データを全部送らず、現場で前処理・集計・フィルタリングして帯域コストを下げたい
• 制御や検知の判断を低レイテンシで行いたい（クラウド往復を待てない）
• カメラ映像などを外に出さず、機密データを現場内で処理したい（データ主権・コンプライアンス）
• 多数の機器へ配るロジックを、クラウドから一元的に配信・更新したい

主要概念と用語

• IoT Edge デバイス: エッジで IoT Edge ランタイムを動かす機器。ゲートウェイや産業用 PC、サーバーなどが該当する
• IoT Edge ランタイム: デバイス上でモジュールの起動・通信・監視・クラウド連携を担う基盤。エッジエージェント（デプロイ管理）とエッジハブ（メッセージ仲介・接続）の2つのシステムモジュールから成る
• モジュール: ビジネスロジックや推論を入れた Docker 互換のコンテナ。これがデプロイ・実行の単位
• モジュールツイン / デバイスツイン: モジュールやデバイスの状態と構成を表す JSON ドキュメント。クラウドから望ましい状態を指定し、現場の報告状態を受け取る
• デプロイメントマニフェスト: どのモジュールをどう動かし、どうメッセージを流すかを定義する JSON。これをクラウドから機器へ配る
• ルート（ルーティング）: エッジハブ内でモジュール間およびクラウドとのメッセージ経路を宣言的に定義する仕組み
• IoT Hub: クラウド側の管理ハブ。デバイス登録、構成配信、テレメトリ受信、双方向通信の中心となる
• エッジゲートウェイ: IoT Hub へ直接つながらない下位デバイスを束ねて中継するパターン（透過・プロトコル変換・ID 変換）

仕様・制限・クォータ

• 現行版: 2026年7月時点の現行 LTS は 1.6（2028年11月14日まで）。1.5 LTS は2026年11月10日に終了するため、セキュリティサブシステムとランタイムコンテナの両方を更新する
• コンテナエンジンが前提: デバイスには Moby / Docker 互換のエンジンが必要。Linux コンテナは Linux または IoT Edge for Linux on Windows で動かせるが、Windows コンテナはサポート終了している
• 管理は IoT Hub 経由: デプロイ・監視・構成は IoT Hub のレイヤー（Standard 相当のレイヤーが必要）を通じて行う
• オフライン動作: 最初に一度 IoT Hub と同期した後は、切断中もモジュールと下位端末を動かせる。保持 TTL の既定は 7,200秒で、実際の保持量は TTL と空きディスクの小さい方で決まる
• 配信保証: Edge Hub のルートは 少なくとも1回。保持期限切れ、ディスク枯渇、送信側の重複を前提に、業務側で冪等化と欠損監視を行う
• ゲートウェイ階層: 1 台の親 IoT Edge が直接接続できるクライアントは既定 100。端末だけでなく各モジュールの論理接続も数える
• メッセージサイズ・スループット: クラウド連携は IoT Hub の 256 KB メッセージ上限、日次容量、レート制限に従う
• モジュール数: 1 デバイスに複数モジュールを配置できるが、実機の CPU・メモリ・ストレージといったハードウェア資源が実質的な上限になる
• OS サポート: Tier 1 は Microsoft が継続テストとパッケージ提供を行い、Tier 2 はコミュニティ支援・ベストエフォート。ホスト OS の標準サポート期限も別に追跡する

内部の仕組み

横にスクロール

IoT Edge デバイス上では、まず2つのシステムモジュールが動きます。エッジエージェントは IoT Hub からデプロイメントマニフェストを受け取り、指定どおりにモジュール（コンテナ）を取得・起動・再起動し、状態を報告します。エッジハブはローカルのメッセージブローカとして働き、モジュール間およびクラウドとのメッセージを仲介します。下位デバイスからの接続をエッジハブが肩代わりすることで、IoT Hub へのコネクション数も集約できます。

メッセージの流れはルートで宣言的に定義します。たとえば「センサーモジュールの出力を推論モジュールへ渡し、その結果のうち異常だけをクラウドへ送る」といった経路を、コードではなく構成として記述します。これによりモジュールを差し替えてもパイプラインを保ったまま組み替えられます。

デプロイは望ましい状態（desired state）モデルです。クラウド側でモジュールツイン／デプロイメントマニフェストに目標構成を書くと、エッジエージェントがそれに収束するよう実機を調整します。接続が切れている間はローカルで処理とキューイングを続け、再接続時に報告状態（reported state）とテレメトリを同期します。これがオフライン耐性の中核です。

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

• エッジで絞ってクラウドへ送る: 生データを全部送らず、現場で集計・異常検知・サンプリングしてから送信し、帯域とクラウド処理コストを削減する
• 推論はエッジ、学習はクラウド: モデルの学習・再学習はクラウドで行い、できあがったモデルをモジュールとして配信して推論だけ現場で実行する
• モジュールは疎結合に: 役割ごとにモジュールを分け、ルートでつなぐ。差し替え・段階更新がしやすくなる
• 段階的ロールアウト: タグやデバイスツインで対象をグルーピングし、新しいデプロイをまず一部の機器へ当ててから全体へ広げる
• 冪等・再送前提: オフライン後の再送で重複が起こり得るため、下流処理は冪等に設計する
• 資源を見積もる: 実機の CPU・メモリ・ストレージは限られる。モジュール数とコンテナサイズを現実的に抑える

運用・監視

• クラウドからの一元管理: IoT Hub のデプロイメント機能で、対象デバイス群へモジュール構成を一括適用・更新する
• メトリクスとログ: 各モジュールはメトリクスを公開でき、Azure Monitor や Log Analytics に取り込んで稼働状況・メッセージ流量・エラーを可視化する
• モジュールログの取得: クラウド側からダイレクトメソッドでモジュールのログ取得や再起動を遠隔指示できる
• 接続状態の把握: デバイスツインの報告状態で各機器のオンライン・オフラインやモジュールの健全性を追跡する
• OS とランタイムの更新運用: エッジ機器の OS パッチ、コンテナエンジン、IoT Edge ランタイムの更新計画をあらかじめ用意する

コスト

IoT Edge のランタイム自体は無償で利用できます。費用は主に、機器を管理する IoT Hub のレイヤー課金（メッセージ数・機能レベル）、モジュールイメージを置く コンテナレジストリ、エッジ機器そのもののハードウェア・運用費から生じます。エッジで前処理して送信量を減らすほど、クラウド側のメッセージ課金や下流の処理コストを抑えられます。

セキュリティ

• デバイス ID と認証: 各デバイスは IoT Hub に登録した ID で認証する。証明書ベースの認証や、TPM / HSM などのハードウェアセキュリティモジュールに鍵を保護できる
• プロビジョニング: 多数の機器を安全に登録するため Device Provisioning Service（DPS）を使い、ゼロタッチで配備する
• モジュールの信頼性: 信頼できるレジストリからのイメージのみを使い、コンテンツの完全性を担保する
• 最小権限の通信: エッジハブを介して通信を集約し、下位機器を直接クラウドへ露出させない
• データのローカル処理: 機密映像や個人データを現場内で処理・匿名化してから送ることで、外部流出リスクを減らせる

Well-Architected の観点

• オペレーショナルエクセレンス: デプロイメントマニフェストとデバイスツインによる宣言的な望ましい状態管理で、多数の機器を再現性高く構成・更新できる。CI/CD でモジュールイメージをビルドし、段階的にロールアウトする運用が組める
• パフォーマンス効率: 推論や前処理を現場で実行することでクラウド往復のレイテンシを排除し、ネットワーク帯域の消費を抑える。エッジで絞り込むことでクラウド側の負荷もスケールしやすくなる
• 信頼性の面でもオフライン動作とローカルキューイングが効くが、本サービスの主眼は上記2本柱にある

試験で問われるポイント

関連サービス・比較

クラウド側で機器を管理する Azure IoT Hub とセットで使うのが基本です。役割としては、現場で実行する IoT Edge が AWS の IoT Greengrass に相当し、クラウド側の機器管理ハブである IoT Hub が AWS の IoT Core に相当します。ここではエッジ実行基盤どうしの対応として、IoT Greengrass と比較します。

ハンズオン / CLI例

# IoT 拡張機能を追加（未導入なら）
az extension add --name azure-iot

# リソースグループと IoT Hub を作成
az group create --name demo-rg --location japaneast
az iot hub create \
  --resource-group demo-rg \
  --name demo-iothub \
  --sku S1

# IoT Edge デバイスを登録（--edge-enabled が重要）
az iot hub device-identity create \
  --hub-name demo-iothub \
  --device-id edge-device-01 \
  --edge-enabled

# デバイスの接続文字列を取得（実機のランタイム設定に使う）
az iot hub device-identity connection-string show \
  --hub-name demo-iothub \
  --device-id edge-device-01 \
  --output tsv

# デプロイメントマニフェスト（モジュール構成 JSON）を適用
az iot edge set-modules \
  --hub-name demo-iothub \
  --device-id edge-device-01 \
  --content ./deployment.json

# デバイスに割り当てられたモジュール一覧を確認
az iot hub module-identity list \
  --hub-name demo-iothub \
  --device-id edge-device-01 \
  --output table