Azure Localを帯域の細い拠点、閉域寄りの拠点、海外拠点などで運用している場合、2026年4月更新の重要点は「更新パッケージを事前に取得し、PowerShellでインポート・検出できる手順が明確化されたこと」です。特に、CombinedSolutionBundleを静的ペイロードとして準備しておけば、更新開始時のダウンロード量を減らし、複数のAzure Localインスタンスへ同じ更新パッケージを展開しやすくなります。ただし、完全なオフライン更新ではありません。Azure Arc resource bridgeやAzure Kubernetes Service on Azure Localで必要になる更新済みコンテナーイメージは静的ペイロードに含まれず、更新処理中に自動ダウンロードされる点に注意が必要です。(Microsoft Learn)
Azureの最新動向: Import and Discover Update Packages For Azure Local With Limited Connectivityで何が変わったか
Microsoft Learnの「Import and discover update packages with limited connectivity」は、2026年4月22日に更新され、Azure Localの限定的な接続環境でソリューション更新パッケージをインポート・検出する手順を説明しています。対象は、Azureへの帯域が限られるサイトに展開されたAzure Localです。(Microsoft Learn)
今回のポイントは、更新をいきなり開始するのではなく、事前に更新バンドルをダウンロードし、整合性を確認し、Azure Local側の更新サービスに認識させてから更新フェーズへ進む運用を取りやすくなったことです。
特にIT管理者やプロダクトオーナーは、次のように捉えると実務に落とし込みやすくなります。
| 観点 | 2026年4月更新で押さえること | 実務上の判断 |
|---|---|---|
| 更新方式 | CombinedSolutionBundleを事前取得してPowerShellでインポート | 帯域が細い拠点、複数拠点展開で有効 |
| 対象バージョン | この機能はAzure Local 2411.3以降で利用可能 | まず現行バージョンを確認する |
| 2604の更新 | 12.2604.1003.209、OS build 26100.32690が2026年4月22日に提供 | 2604へ進める更新パスか確認する |
| 含まれる内容 | OSセキュリティ更新、拡張機能、コアエージェントなど | OSだけの更新ではなく「ソリューション更新」として扱う |
| 含まれない内容 | Arc resource bridgeやAKS on Azure Local向けの更新済みコンテナーイメージ | 完全オフライン前提で計画しない |
Azure Localの2604更新で確認すべきバージョン情報
2026年4月リリースのAzure Localは、ソリューションバージョン12.2604.1003.209、OS build 26100.32690として示されています。Microsoftのリリース情報では、新規デプロイでもこのビルドが使用されるとされています。(Microsoft Learn)
限定接続環境向けの更新バンドル一覧でも、OS build 26100.32690に対応する12.2604.1003.209が掲載され、提供日は2026年4月22日です。あわせてSHA256ハッシュも公開されているため、ダウンロード後に必ずGet-FileHashで整合性を確認してください。(Microsoft Learn)
実務では、次の3つを更新計画書に明記しておくと、運用チーム・セキュリティチーム・現地作業者の認識ずれを防げます。
| 確認項目 | 2604での値・考え方 |
|---|---|
| ソリューションバージョン | 12.2604.1003.209 |
| OS build | 26100.32690 |
| バンドル名の形式 | CombinedSolutionBundle.<build number>.zip |
| 整合性確認 | Microsoft Learnに掲載されたSHA256と照合 |
| 最新バンドル公開の注意 | リリース後、バンドルとSHA256の反映に最大24時間かかる可能性がある |
「限定接続」は完全オフラインではない
この更新手順で最も誤解しやすいのは、「Limited Connectivity」を「完全なオフライン更新」と考えてしまうことです。
Microsoftの説明では、静的ペイロードに含まれるのは、主にOSセキュリティ更新、拡張機能、コアエージェントです。一方で、Azure Arc resource bridgeコンポーネントやAzure Kubernetes Service on Azure Localに必要な更新済みコンテナーイメージは静的ペイロードに含まれず、更新プロセス中に自動ダウンロードされます。(Microsoft Learn)
そのため、次のような運用設計が必要です。
| 環境 | 推奨される考え方 |
|---|---|
| 帯域が細いがAzure接続はある | 更新バンドルを事前取得し、更新当日の通信量を抑える |
| プロキシ経由で通信制御している | 更新時に必要な通信先を事前確認し、許可設定を準備する |
| 完全閉域に近い環境 | コンテナーイメージ取得が必要になる可能性を前提に、更新可否を事前検証する |
| 複数拠点展開 | 中央でバンドル取得・ハッシュ確認後、各拠点へ安全に配布する |
「バンドルを置けばすべて終わる」と考えると、更新当日にAdditionalContentRequiredやダウンロード失敗で止まる可能性があります。更新前のリハーサルでは、Get-SolutionUpdateで状態を確認し、必要な追加コンテンツがないかを必ず見てください。
CombinedSolutionBundleとは何か
CombinedSolutionBundleは、Azure Stack HCI OS、コアエージェントとサービス、ソリューション拡張機能の更新パッケージを含むZIPファイルです。ファイル名はCombinedSolutionBundle.<build number>.zipの形式で、ダウンロード後はSHA256ハッシュで整合性を確認します。(Microsoft Learn)
ここで重要なのは、Azure Localの更新を単なるWindows Updateとして扱わないことです。Azure Localの更新は、OS、エージェント、サービス、場合によってはSolution Builder Extension、ドライバー、ファームウェアなどを含む「ソリューション全体の更新」として管理されます。MicrosoftはAzure Localの更新について、オーケストレーターによりOS、コアエージェント、サービス、ソリューション拡張を一貫して管理する仕組みとして説明しています。(Microsoft Learn)
特にOEMやハードウェアベンダーが関係する環境では、SBE、つまりSolution Builder Extensionの扱いが更新成否に直結します。SBEが必要な更新では、ハードウェアベンダー由来の追加コンテンツが必要になることがあります。
限定接続環境での更新前チェックリスト
更新作業に入る前に、次の項目を確認してください。特に本番クラスターでは、ダウンロード手順よりも事前確認の質が更新成功率を左右します。
| チェック項目 | 確認方法・判断基準 | 見落とした場合のリスク |
|---|---|---|
| Azure Localの現行バージョン | Get-SolutionUpdateEnvironmentなどで確認 | 2411.3未満では限定接続向け機能を使えない可能性 |
| 対応する更新パス | Microsoft Learnのリリース情報で確認 | 対象外のビルドへ進もうとして更新不可 |
| バンドルのSHA256 | Get-FileHashで照合 | 破損・改ざん・誤配布に気づけない |
| 空き容量 | インフラストラクチャボリュームと展開先を確認 | 展開中に失敗 |
| SBEの要否 | Get-SolutionUpdateの状態で確認 | AdditionalContentRequiredで停止 |
| メンテナンス時間 | ノード数、負荷、ハードウェアを考慮 | 作業時間超過 |
| AKS/Arc関連通信 | 更新時に必要なダウンロードを想定 | コンテナーイメージ取得で失敗 |
MicrosoftのPowerShell更新手順では、更新前に現行ソフトウェアバージョンとクラスターの健全性を確認し、利用可能な更新を検出し、推奨手順として事前ダウンロードと準備状況チェックを行ってからインストールする流れが示されています。(Microsoft Learn)
更新パッケージをダウンロードして整合性を確認する
まず、対象ビルドのダウンロードURIとSHA256をMicrosoft Learnの表で確認します。ダウンロード先は、例としてインフラストラクチャボリューム配下のimportフォルダーが示されています。(Microsoft Learn)
# CombinedSolutionBundleをダウンロード
Invoke-WebRequest `
-Uri "<download URI>" `
-OutFile "C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import\CombinedSolutionBundle.<build number>.zip"ダウンロード後は、必ずハッシュ値を確認します。
# ダウンロードしたCombinedSolutionBundleのSHA256を確認
Get-FileHash -Path "C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import\CombinedSolutionBundle.<build number>.zip"ハッシュ値がMicrosoft Learnに掲載された値と一致しない場合は、更新に進めず、再ダウンロードしてください。帯域が細い環境では「時間がかかったからそのまま使う」という判断をしがちですが、破損したZIPを展開してから失敗すると、原因切り分けにさらに時間がかかります。
Azure Localに更新バンドルをインポートする手順
更新サービスに検出させるため、インフラストラクチャボリューム内にimportフォルダーを作成し、バンドルを配置します。公式手順では、作成したフォルダーにZIPをコピーし、Solutionサブフォルダーへ展開してからAdd-SolutionUpdateでインポートします。(Microsoft Learn)
# 更新サービスが検出するフォルダーを作成
New-Item C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import -ItemType Directory# CombinedSolutionBundleをSolutionサブフォルダーへ展開
Expand-Archive `
-Path C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import\CombinedSolutionBundle.<build number>.zip `
-DestinationPath C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import\Solution# 更新パッケージを更新サービスにインポート
Add-SolutionUpdate `
-SourceFolder C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import\Solutionインポート後は、Get-SolutionUpdateで更新が検出されるか確認します。更新サービスの検出は非同期で行われるため、すぐに表示されない場合は少し間を空けて複数回実行します。(Microsoft Learn)
Get-SolutionUpdate実務では、ここで「表示されたか」だけでなく、Stateを確認することが重要です。Ready系の状態なら準備・インストールへ進めますが、AdditionalContentRequiredが返る場合は、SBEなど追加コンテンツのインポートが必要です。
AdditionalContentRequiredが出たときの考え方
AdditionalContentRequiredは、更新に必要な追加コンテンツが不足している状態です。Microsoftの更新フェーズ説明では、この状態はハードウェアベンダーのコンテンツを必要とするSBE更新や、SolutionとSBEを組み合わせた更新で発生し得るとされています。(Microsoft Learn)
この状態が出た場合は、次の順で確認してください。
| 確認順 | やること | 判断ポイント |
|---|---|---|
| 1 | ハードウェアモデルとSKUを確認 | 対象SBEが一致しているか |
| 2 | SBEの配布元・取得手順を確認 | OEMの提供物が必要か |
| 3 | 追加ファイルをインポート | SBE_Discovery_*.xmlやSBE ZIPなどが必要になる場合 |
| 4 | Get-SolutionUpdateを再実行 | 状態がReady系に変わるか |
| 5 | 事前準備チェックを実行 | メンテナンス時間前に失敗要因を潰す |
PowerShell更新手順では、追加コンテンツが必要な場合、SBE関連ファイルとして検出用マニフェスト、インベントリと署名済みソフトウェアBOM、ペイロードZIPのようなファイルを扱うことが示されています。(Microsoft Learn)
更新前にPrepareOnlyでリスクを下げる
限定接続環境では、更新作業を「ダウンロード・検証」と「インストール」に分けるのが実務上のコツです。Microsoftの更新フェーズは、準備フェーズとインストールフェーズの2段階で構成されます。準備フェーズでは、コンテンツのダウンロード、検証、展開、ヘルスチェックが行われます。(Microsoft Learn)
インストールを始めずに準備だけを行うには、Start-SolutionUpdate -PrepareOnlyを使います。これは、メンテナンスウィンドウ前に更新コンテンツを事前配置し、クラスターの更新準備状況を確認するために有効です。(Microsoft Learn)
Get-SolutionUpdate -Id <ResourceId> | Start-SolutionUpdate -PrepareOnly準備状況は次のように確認できます。
Get-SolutionUpdate -Id <ResourceId> |
ft Version, State, UpdateStateProperties, HealthStateReadyToInstallになれば、インストールへ進む準備が整っています。HealthCheckFailedが表示された場合は、原因を解消してから再度チェックしてください。
2026年4月の2604で注目すべき改善点
Azure Local 2604の「Features and improvements」では、2026年4月リリースのバージョンが12.2604.1003.209であることに加え、信頼性改善とバグ修正、OS build 26100.32690、.NET更新、AKS enabled by Azure Arcの対応Kubernetesバージョン変更、SANストレージ対応、更新設定管理、GPU関連などが示されています。(Microsoft Learn)
特に運用面で注目したいのは、次の項目です。
| 項目 | 管理者が見るべきポイント |
|---|---|
| OS build 26100.32690 | 対応ドライバーやOEM提供イメージの確認が必要 |
| AKS enabled by Azure Arc | Kubernetes 1.30はサポート外となり、サポート対象バージョンへの更新が必要 |
| SAN storage | Azure LocalでSANストレージが一般提供され、構成選択肢が広がる |
| 更新設定管理 | Azure Local更新の適用方法を制御できるようになる |
| 検証改善 | デプロイ・更新時の検証時間短縮や失敗地点からの再開が期待できる |
| GPU acceleration | Azure Local VMでGPU利用を計画している環境では確認価値が高い |
また、2604の既知の問題ページでは、このリリースで修正された問題として、Azure Local VM作成時のストレージパス事前チェック、ギャラリーイメージ操作、VM Connect、SBE更新検出、更新サービスのサイドロード時クラッシュなどが挙げられています。2604リリース自体の既知の問題は「なし」とされていますが、以前のリリースから持ち越された既知の問題は引き続き確認が必要です。(Microsoft Learn)
April OS security updateも確認する
2604に関連するOSセキュリティ更新として、Azure Local向けのApril OS security update、KB5082063がOS build 26100.32690に関連付けられ、2026年4月14日リリースとして説明されています。主な改善には、Secure Boot、Kerberos、認証、SMB compression over QUIC、PowerShell、Remote Desktopなどが含まれます。(Microsoft Learn)
セキュリティチームとの調整では、単に「Azure Localを2604へ上げる」だけではなく、次の観点も共有するとよいでしょう。
| 領域 | 確認ポイント |
|---|---|
| Secure Boot | 証明書更新やBitLocker Recovery関連の挙動を事前確認 |
| Kerberos / 認証 | ドメイン認証ポリシーや暗号化設定への影響を確認 |
| SMB over QUIC | 利用している場合は通信安定性改善の影響を確認 |
| Remote Desktop | RDPファイル利用時のセキュリティ警告や設定表示の変化を周知 |
| WSUS | エラー詳細表示に関する既知の制限を確認 |
特にリモート運用が多いグローバル拠点では、RDPファイルやKerberos関連の変更は問い合わせにつながりやすい領域です。更新後に「接続画面の表示が変わった」「認証の挙動が違う」といった連絡が来ても、事前に変更点を把握していれば一次対応が速くなります。
使ってはいけない更新経路に注意する
Azure Localの更新では、サポートされる更新経路を守ることが重要です。Microsoftは、PowerShellまたはAzure portalのAzure Update Managerを更新インターフェイスとして示しています。一方で、SConfig、Windows Admin Center、Machine-Azure Arcリソース側の更新ペイン、手動のCluster-Aware Updating、サードパーティツールなどは、Azure Local更新では使わないよう案内されています。(Microsoft Learn)
これは単なる推奨ではなく、運用ルールに落とし込むべきポイントです。たとえば、Windows Server運用の延長でSConfigやWindows Admin Centerから更新を当てると、Azure Localのライフサイクル管理とずれたアウトオブバンド更新になり、互換性問題やサポート上の問題につながる可能性があります。
社内手順書には、次のように明記しておくと安全です。
| 操作 | 可否 | 理由 |
| ———————————– | -: | ———————— |
| PowerShellでのAzure Localソリューション更新 | 可 | 公式手順で案内されている |
| Azure Update ManagerでのAzure Local更新 | 可 | Azure Local向け更新管理として利用可能 |
| SConfigによる更新 | 不可 | Azure Localの更新経路として非推奨 |
| Windows Admin Centerからの更新 | 不可 | アウトオブバンド更新につながる可能性 |
| 手動のCluster-Aware Updating | 不可 | オーケストレーター管理外になる |
| サードパーティツール更新 | 不可 | Microsoftがサポートしない |
更新作業で失敗しやすいポイント
限定接続環境では、更新バンドルそのものよりも、周辺条件で失敗することが多くあります。以下は、実務で特に注意したいポイントです。
バンドルの取得だけで満足してしまう
CombinedSolutionBundleを取得しても、コンテナーイメージやSBE追加コンテンツが別途必要になる場合があります。更新当日に通信が必要になる可能性を前提に、ネットワーク許可、プロキシ、名前解決、証明書検査の影響を事前に確認してください。
更新パスを確認しない
Azure Localでは、リリーストレインやOS buildによって更新パスが変わります。リリース情報では、2504以降に2系統のソリューションバージョンがあり、それぞれ対応するOS buildが示されています。(Microsoft Learn)
特に23H2系、24H2系、既存デプロイ、新規デプロイが混在する環境では、単純に「最新へ上げる」と考えず、現在のCurrentVersionと対象ビルドの関係を確認してください。
ヘルスチェックをメンテナンス時間内に初めて実行する
ヘルスチェックでCriticalやWarningが出ると、更新作業を進められない場合があります。Microsoftのトラブルシューティング情報では、更新前の準備チェックは重要で、Criticalは更新を妨げる問題、Warningもバイパス可能な場合はあるものの更新を妨げる可能性がある分類として説明されています。(Microsoft Learn)
本番更新では、メンテナンス日の数日前にPrepareOnlyを実行し、失敗要因を先に解消しておくのが現実的です。
Azure portalの表示だけで判断する
既知の問題として、Azure portal側の更新状態表示が遅れたり、正しく反映されないケースが持ち越しの既知問題に含まれています。2604の既知問題ページでは、更新が完了していてもポータルで失敗や進行中と表示される場合があり、PowerShellで状態を確認する手順が示されています。(Microsoft Learn)
更新後の完了確認では、Azure portalだけでなくPowerShellのGet-SolutionUpdateも併用してください。
IT管理者向けの実行フロー
実際の運用では、以下の流れで作業を組むと失敗を減らせます。
| フェーズ | 作業 | 主なコマンド・確認 |
|---|---|---|
| 事前確認 | 現行バージョン、更新パス、SBE要否を確認 | Get-SolutionUpdateEnvironment |
| バンドル取得 | 対象のCombinedSolutionBundleをダウンロード | Invoke-WebRequest |
| 整合性確認 | SHA256を照合 | Get-FileHash |
| 配置・展開 | import配下に配置し、Solutionへ展開 | Expand-Archive |
| インポート | 更新サービスへ登録 | Add-SolutionUpdate |
| 検出確認 | 更新が認識されたか確認 | Get-SolutionUpdate |
| 事前準備 | ダウンロード・検証・ヘルスチェック | Start-SolutionUpdate -PrepareOnly |
| インストール | メンテナンス時間内に更新実行 | Start-SolutionUpdate |
| 完了確認 | 状態とバージョンを確認 | Get-SolutionUpdate |
この流れを拠点ごとに標準化しておくと、中央IT部門が更新バンドルと手順を管理し、各国・各拠点の運用チームが同じ品質で作業しやすくなります。
プロダクトオーナーが判断すべきこと
Azure Localの更新は、単なるインフラ保守ではなく、サービス継続性、セキュリティ、サポートライフサイクルに関わります。プロダクトオーナーは、技術的なコマンド詳細よりも、次の判断に責任を持つべきです。
| 判断項目 | 見るべきポイント |
|---|---|
| いつ更新するか | サポート期限、セキュリティ要件、業務影響を比較 |
| どの拠点から始めるか | 低リスク拠点で先行検証し、本番重要拠点へ展開 |
| どの機能を有効活用するか | SAN、GPU、更新設定管理など2604の改善点を評価 |
| 失敗時の戻し方 | Microsoft Supportへの連絡基準、ログ取得、メンテナンス延長判断 |
| 完全オフライン前提を避けるか | Arc/AKS関連の追加ダウンロード要否を確認 |
Azure Localのリリース情報では、サポート状態を維持するには最新リリースから6か月以内に更新する必要があること、Azure Arc resource bridgeでは証明書の有効性やAzure Local VM機能維持のために1年以内のソリューション更新が必要であることも示されています。(Microsoft Learn)
つまり、更新を先送りし続けると、セキュリティだけでなくAzure Local VM管理やサポート対応にも影響する可能性があります。
まとめ: まず現行バージョンと更新パスを確認する
2026年4月22日に更新されたAzure Localの限定接続向け更新手順は、帯域が限られる環境での更新計画を現実的にするものです。CombinedSolutionBundleを事前に取得し、SHA256で検証し、Add-SolutionUpdateとGet-SolutionUpdateでインポート・検出できるため、更新当日の通信量と作業リスクを減らせます。
一方で、これは完全オフライン更新ではありません。Arc resource bridgeやAKS on Azure Localに関連するコンテナーイメージ、SBEの追加コンテンツ、ハードウェアベンダー検証、更新パスの制約を考慮する必要があります。
次に取るべき行動は明確です。まず、対象クラスターでGet-SolutionUpdateEnvironmentを実行し、現行バージョン、ヘルス状態、SBE情報を確認してください。そのうえで、2604の12.2604.1003.209へ進める更新パスかをリリース情報で確認し、メンテナンス日より前にバンドル取得、ハッシュ確認、PrepareOnlyによる事前検証まで済ませておきましょう。
コメント