Azureの更新情報を見て「バージョン番号が上がっただけなのか」「本番環境に影響するのか」を判断しにくいことがあります。今回の Microsoft Azure documentation update: build: version increments for 2605 release は、Azure IoT Operations CLI拡張を2605リリースへ進めるための更新で、単なる表記変更ではありません。
結論から言うと、主な変更は Azure IoT Operations CLI拡張の2.6.0化、AIO_RELEASEの2605化、デプロイ用テンプレート内のcertManager・secretStore・iotOperationsバージョン更新 です。既存環境が即座に自動更新されるという意味ではありませんが、管理者や開発者が az extension add --upgrade --name azure-iot-ops や az iot ops upgrade を実行するタイミングで、デプロイ・アップグレード対象が変わる可能性があります。GitHubの公式リリースでは azure-iot-ops 2.6.0 が2026年5月21日に公開され、今回のPR #878もその変更に含まれています。(GitHub)
Microsoft Azure documentation update: build: version increments for 2605 releaseの要点
今回の更新は、Azure IoT Operationsを使っている管理者、Azure CLIで展開を自動化しているDevOps担当者、Bicep/ARMテンプレート差分を管理している開発者に関係します。
Azure IoT Operationsは、Azure Arc対応Kubernetesクラスター上で動くエッジ向けの統合データプレーンです。MQTTブローカー、Akriコネクタ、データフロー、Device Registryなどを組み合わせ、オンプレミスの設備データをエッジで処理してクラウドへ連携します。(Microsoft Learn)
今回の更新で見るべきポイントは、次の3つです。
| 見るべきポイント | 内容 | 実務上の意味 |
|---|---|---|
| CLI拡張のバージョン | azure-iot-ops が2.6.0系へ更新 | CI/CDや運用端末で使うCLI拡張の挙動が変わる可能性がある |
| AIOリリース識別子 | AIO_RELEASE が2604から2605へ更新 | 2605リリース向けのデプロイ・アップグレード識別子になる |
| テンプレート内バージョン | certManager、secretStore、iotOperationsが更新 | 新規展開やアップグレード時に適用されるArc拡張・AIOコンポーネントのバージョンが変わる |
特に重要なのは、VERSION、AIO_RELEASE、VERSIONS.iotOperations は同じものではない点です。VERSION はAzure CLI拡張のバージョン、AIO_RELEASE は2605のようなリリース識別子、VERSIONS.iotOperations はテンプレートが参照するAzure IoT Operations側のコンポーネントバージョンです。ここを混同すると、「CLIは新しいのにインスタンスは古い」「テンプレート差分を見落とした」といった運用ミスにつながります。
何が変わったのか
公式PR #878の差分では、azext_edge/constants.py、azext_edge/edge/providers/orchestration/template.py、テスト用のtest_template_unit.pyが更新されています。ファイル差分としては、直前の2.6.0a1から2.6.0への確定、テンプレートのcommit_id更新、Bicep生成メタデータ更新、依存拡張バージョンの更新が確認できます。(GitHub)
リリース識別子とCLI拡張バージョンの変更
| 項目 | 変更前 | 変更後 | 補足 |
|---|---|---|---|
VERSION | 2.5.0 | 2.6.0 | リリース全体としてのAzure IoT Operations CLI拡張バージョン |
AIO_RELEASE | 2604 | 2605 | Azure IoT Operationsの2605リリース識別子 |
constants.py上の最終差分 | 2.6.0a1 | 2.6.0 | 2605向けの事前バージョンから安定版表記へ確定 |
5月6日の先行PR #873ではVERSIONが2.5.0から2.6.0a1へ、AIO_RELEASEが2604から2605へ更新されていました。その後、PR #878で2.6.0として確定した流れです。(GitHub)
Enablementテンプレートの変更
Enablementテンプレートは、Azure IoT Operationsを有効化する際の依存拡張に関わる部分です。今回の更新では、certManagerとsecretStoreのバージョンが上がっています。
| 対象 | 変更前 | 変更後 |
|---|---|---|
commit_id | cb318bfe4bc1fcc887fb3f902436110a713fe797 | c0eedd7b4a50a5e4bc83cd43d3bda34be6e5e19d |
_generator.version | 0.42.1.51946 | 0.43.8.12551 |
_generator.templateHash | 10665750777960080296 | 10429247713227659883 |
VERSIONS.certManager | 0.11.0 | 0.12.0 |
VERSIONS.secretStore | 1.4.0 | 1.4.1 |
TRAINS.certManager | stable | stable |
TRAINS.secretStore | stable | stable |
TRAINSがstableのままなので、リリーストレインがPreviewへ切り替わったわけではありません。ただし、バージョンは変わっているため、証明書管理やシークレットストア拡張の状態確認は必要です。
Instanceテンプレートの変更
Instanceテンプレートでは、Azure IoT Operations本体のバージョンが更新されています。
| 対象 | 変更前 | 変更後 |
|---|---|---|
commit_id | f3f0f91039428f78b382b6ef9bdf194a51d8e684 | 10b8355545af3a29f48fafd6e936ef120e4f74c8 |
_generator.version | 0.42.1.51946 | 0.43.8.12551 |
_generator.templateHash | 11558826619663515380 | 5208211492871219312 |
VERSIONS.iotOperations | 1.3.70 | 1.3.105 |
TRAINS.iotOperations | stable | stable |
実務上の注目点は、iotOperationsが1.3.70から1.3.105へ上がっていることです。2604相当の環境から2605相当へ進める場合、CLI拡張の更新だけでなく、実際のAzure IoT Operationsインスタンス側のアップグレード可否と適用タイミングを確認する必要があります。
影響範囲：誰が何を確認すべきか
今回の変更は、Azureを使っているすべてのユーザーに影響するものではありません。影響を受けやすいのは、Azure IoT Operationsを運用している環境、またはazure-iot-ops拡張を使ってデプロイやアップグレードを自動化している環境です。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| Azure IoT Operations管理者 | 2605へのアップグレード判断、Arc拡張のバージョン確認が必要 | Azure PortalのUpgrade表示、Arc対応クラスターのExtensions、稼働状況 |
| DevOps担当者 | CI/CDで使うCLI拡張が2.6.0へ変わる可能性 | パイプライン内のaz extension add、バージョン固定、テンプレート差分 |
| 開発者 | dataflowgraph関連などCLI機能変更の影響を受ける可能性 | CLIコマンドの互換性、エラーメッセージ、設定ファイルJSON |
| セキュリティ・運用担当者 | 証明書管理、Secret Store、管理ID、ロール割り当て確認が必要 | certManager、secretStore、Key Vault連携、Event Grid関連権限 |
| 検証環境のみの利用者 | 影響は限定的だが、Preview版から安定版への切り替えに注意 | 2.6.0a1を使っていた端末やコンテナイメージの更新 |
既存インスタンスがただちに書き換わるわけではありません。ただし、運用端末やCI/CDで「常に最新のCLI拡張を入れる」設定にしている場合、次回のデプロイ・アップグレード実行時に2.6.0が使われる可能性があります。Azure CLI拡張はaz extension add --upgrade --name <extension>で更新でき、特定バージョンを指定することもできます。(Microsoft Learn)
管理者が最初に確認すべき設定
2605リリースへ進める前に、まず現在の状態を確認します。いきなり本番でaz iot ops upgradeを実行するのではなく、CLI本体、CLI拡張、Azure IoT Operationsインスタンス、Arc拡張の順に見ます。
CLI本体と拡張機能の確認
az --version
az extension show --name azure-iot-ops --output table拡張機能を2605対応の2.6.0へ更新する場合は、次のように実行します。
az extension add --upgrade --name azure-iot-opsバージョンを明示して検証したい場合は、次のように固定します。
az extension add --upgrade --name azure-iot-ops --version 2.6.0Azure IoT Operationsのアップグレード手順ではAzure CLI 2.62.0以上が前提として示されています。一方、az iot opsのCLIリファレンスでは、azure-iot-ops拡張はAzure CLI 2.70.0以降の一部として案内されています。運用では、社内で検証済みの最新系Azure CLIへ更新してから拡張機能を入れ直すほうが安全です。(Microsoft Learn)
Azure IoT Operationsインスタンスの確認
az iot ops show \
--resource-group <RESOURCE_GROUP_NAME> \
--name <INSTANCE_NAME>アップグレード可能なバージョンを確認するには、公式のバージョンガイドやAzure PortalのOverviewを確認します。az iot ops get-versionsは既定ブラウザーでバージョンガイドを開くコマンドとして案内されています。(Microsoft Learn)
az iot ops get-versionsAzure Portal上でUpgradeオプションが表示される場合は、そのインスタンスがアップグレード対象です。表示されない場合は、すでに最新扱い、または対象条件を満たしていない可能性があります。(Microsoft Learn)
アップグレード時の実務手順
2605へ進める場合は、検証環境で次の順序を踏むのが現実的です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 事前確認 | az --version、az extension show、PortalのOverviewを確認 | 現在のCLI・拡張・インスタンスバージョンを把握する |
| 検証環境の更新 | az extension add --upgrade --name azure-iot-ops --version 2.6.0 | 2605向けCLIでコマンドが通るか確認する |
| 事前ヘルスチェック | az iot ops check --preなどを使う | クラスター側の準備状態を確認する |
| アップグレード実行 | az iot ops upgradeを実行 | 対象コンポーネントを確認してから適用する |
| 事後確認 | az iot ops check、Portal、Arc拡張一覧を確認 | broker、dataflow、Device Registryなどの状態を見る |
| CI/CD反映 | バージョン固定値やテスト期待値を更新 | 本番反映時の差分を管理する |
アップグレードコマンドは、利用可能な更新コンポーネントの表を出力し、続行確認を求めます。計画外のコンポーネントが含まれる場合は、その場で進めずに差分を確認してください。(Microsoft Learn)
az iot ops upgrade \
--resource-group <RESOURCE_GROUP_NAME> \
--name <INSTANCE_NAME>az iot ops checkは、デプロイ済みIoT Operationsサービスのクラスター側の準備状況とランタイム正常性を評価するコマンドです。プレビュー扱いのコマンドではありますが、検証環境やCIでの補助チェックとして有用です。(Microsoft Learn)
az iot ops check
az iot ops check --svc broker --detail-level 1
az iot ops check --svc dataflow --as-objectデプロイ・移行で注意すべきポイント
ライブアップグレード前提で予定を組まない
Azure IoT Operationsはライブアップグレードをサポートしていないため、アップグレード中のダウンタイムを想定する必要があります。本番環境では、設備データの収集停止が許容される時間帯、MQTTクライアントの再接続設計、監視アラートの抑制ルールを事前に決めてください。(Microsoft Learn)
CLI拡張だけ更新して満足しない
azure-iot-ops拡張を2.6.0にしても、Azure IoT Operationsインスタンス本体が自動的に1.3.105へ更新されるとは限りません。CLI拡張は「操作するためのツール」であり、インスタンスのアップグレードはPortalまたはaz iot ops upgradeで別途確認・実行します。
Bicepテンプレート差分を軽視しない
今回の差分には_generator.versionと_generator.templateHashの変更が含まれます。これは、Bicep生成テンプレートのメタデータや生成結果に差分があることを示します。
自社のIaC管理で次のような運用をしている場合は、必ず更新してください。
| 運用パターン | 起きやすい問題 | 対応 |
|---|---|---|
| テンプレートのハッシュを監査している | templateHash差分を不正変更と誤検知する | 許可リストや監査ルールを更新する |
| CLI生成テンプレートをスナップショットテストしている | テスト期待値が古くなり失敗する | 2.6.0の生成結果で再取得する |
| GitOpsでArc拡張バージョンを固定している | CLI側の期待バージョンとGitOps側がずれる | certManager、secretStore、iotOperationsの固定値を見直す |
| 本番と検証でCLIバージョンが違う | 検証で再現しない差分が本番で出る | CLI拡張を同一バージョンに固定する |
certManagerとSecret Storeの状態を確認する
Enablementテンプレートでは、certManagerが0.12.0へ、secretStoreが1.4.1へ更新されています。証明書管理やKey Vault連携、シークレット同期を使っている環境では、アップグレード後に次の点を確認します。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Arc拡張のプロビジョニング状態 | Azure PortalのArc対応クラスター > Extensions | FailedやUpdatingのまま止まっていない |
| シークレット同期 | Key Vault、SecretSyncリソース、関連Podログ | 参照先シークレットを取得できている |
| 証明書管理 | cert-manager関連リソース、証明書更新ログ | 証明書期限・Issuer・Secret名に異常がない |
| IoT Operations本体 | Portal、az iot ops show、az iot ops check | broker、dataflow、Device Registryが期待どおり動作する |
既知の問題ページでは、アップグレード時にクラウド側の拡張状態がFailedとして残り、az iot ops upgradeが後続で更新不要のように見えるケースが案内されています。類似の症状が出た場合は、Arc拡張の状態と再送信操作を確認してください。(Microsoft Learn)
MQTTブローカーの冗長性を確認する
MQTTブローカーのアップグレードではローリング更新が考慮されていますが、ローリング更新は2つ以上のbackend replicaがある場合に成立します。公式手順では、単一レプリカのMQTTブローカーアップグレードはサポートされないと説明されています。検証環境で最小構成を作っている場合でも、本番と同じ冗長構成でアップグレードを検証してください。(Microsoft Learn)
開発者・DevOps担当者が見るべきCLI 2.6.0の変更
今回のPR #878はバージョン更新が中心ですが、2.6.0リリース全体では、dataflowgraphコマンドグループの追加、Dataflow Graphの接続方向や必須設定の検証、--config-fileで不正なJSONを渡した場合の分かりやすいエラー表示なども含まれています。(GitHub)
| 変更 | 影響しやすい場面 | 確認ポイント |
|---|---|---|
| dataflowgraphコマンドグループ追加 | データフローグラフをCLIで管理する場合 | 既存スクリプト名や補完、社内手順書を更新する |
| Dataflow Graph検証強化 | ノード接続方向や必須パラメーターが曖昧な構成 | 以前は通った不完全な設定が早期にエラーになる可能性 |
| 不正JSONのエラー改善 | --config-fileを使う自動化 | エラーメッセージ依存のテストがあれば見直す |
EG MQTT dataflow endpointのclientIdPrefix対応 | Event Grid MQTT連携を使う管理アクションやデータフロー | クライアントID設計、権限、Topic Space設定を再確認する |
CI/CDでは、次のようにCLI拡張のバージョンを明示しておくと、ある日突然パイプラインの挙動が変わるリスクを抑えられます。
az extension add --upgrade --name azure-iot-ops --version 2.6.0
az extension show --name azure-iot-ops --query version -o tsv本番パイプラインで「常に最新」を使う場合は、少なくとも検証パイプラインを先に流し、テンプレート差分、az iot ops checkの結果、アップグレード対象コンポーネント一覧を保存してから本番へ進めるべきです。
失敗しやすいポイント
今回のようなバージョンインクリメント更新では、機能追加リリースよりも油断しやすいのが問題です。実務では次のミスが起きやすくなります。
| 失敗パターン | なぜ問題か | 回避策 |
|---|---|---|
| 「バージョン番号だけ」と判断して本番で即実行する | certManager、secretStore、iotOperationsの実体バージョンが変わる | 検証環境でArc拡張とデータフローを確認する |
| CLI拡張だけ更新してインスタンスも更新済みと思い込む | ツールと実環境のバージョンが別物 | Portalまたはaz iot ops showでインスタンス側を見る |
| CI/CDで最新拡張を自動取得している | 本番デプロイ時に意図せず2.6.0が使われる | --version 2.6.0などで固定する |
2.6.0a1を検証済みとして扱う | 安定版2.6.0とは差分がある可能性 | 安定版で再度スモークテストする |
| アップグレード中の停止を見込まない | Azure IoT Operationsはライブアップグレード前提ではない | 変更ウィンドウ、復旧手順、監視抑制を準備する |
| 旧バージョンからの経路を確認しない | ダウングレードやPreview/GA間アップグレードには制約がある | 公式バージョンガイドとPortalのUpgrade表示を確認する |
公式のアップグレード手順では、同一minor内のpatch、または次のminorへのアップグレードは可能ですが、ダウングレードはできません。またPreview版からGA版、GA版からPreview版への直接アップグレードにも制約があります。(Microsoft Learn)
今回の更新への対応方針
2605リリースに対しては、次の順で対応するのが安全です。
| 優先度 | 対応 | 理由 |
|---|---|---|
| 高 | 運用端末とCI/CDのazure-iot-ops拡張バージョンを棚卸しする | 意図せず2.5.0と2.6.0が混在するのを防ぐ |
| 高 | 検証環境でaz extension add --upgrade --name azure-iot-ops --version 2.6.0を実行する | 本番前にCLI差分を確認する |
| 高 | az iot ops upgradeで表示される対象コンポーネントを確認する | certManager、secretStore、iotOperations更新を把握する |
| 中 | Bicep/ARMテンプレートのスナップショットや監査ルールを更新する | templateHash変更による誤検知を防ぐ |
| 中 | MQTT、dataflow、Device Registry、SecretSyncのヘルスチェックを実施する | アップグレード後の業務影響を早期検知する |
| 中 | dataflowgraph関連スクリプトや設定ファイルJSONを再検証する | CLI 2.6.0で検証やエラー表示が変わる可能性がある |
今回のMicrosoft Azure documentation updateは、Azure IoT Operations 2605リリースへ向けた重要な更新です。まずはCLI拡張の現行バージョンを確認し、検証環境で2.6.0を固定してテストしてください。そのうえで、Azure PortalのUpgrade表示、Arc拡張の状態、az iot ops upgradeの対象コンポーネント、az iot ops checkの結果を確認してから本番反映に進むのが最も安全です。
コメント