Azure Arc 対応サーバーを運用している場合、2026年5月版の Azure Connected Machine agent 1.64 は「すぐに大規模更新すべき大型機能追加」というより、ネットワーク制御、構成ファイルの信頼性、セキュリティベースライン報告、ESU確認を実務向けに改善するメンテナンス色の強い更新です。特に確認すべきなのは、Arc Gateway のバイパスリスト対応、OpenSSL と同梱 PowerShell の更新、セキュリティベースライン報告の修正、azcmagent show での ESU eligibility 表示です。
なお、Microsoft Learn の英語版リリースノートではページの最終更新日が 2026年5月14日と表示されています。本記事では、2026年5月中旬時点で確認対象となる「Version 1.64 – May 2026」の内容を、管理者・開発者が実際に何を確認すべきかに絞って整理します。(Microsoft Learn)
Azure Connected Machine agent 1.64で変わったこと
Azure Connected Machine agent は、オンプレミス環境や他社クラウド上の Windows / Linux サーバーを Azure Arc 対応サーバーとして管理するためのエージェントです。HIMDS、Machine Configuration、Extension agent などのコンポーネントを通じて、Azure との接続、ポリシー評価、拡張機能管理、マネージド ID 連携を担います。(Microsoft Learn)
今回の 1.64 は、Windows / Linux の両方に影響する変更が多く、Azure Arc Gateway、プロキシ、セキュリティベースライン、ハートビート、構成ファイル、ESU 管理に関係します。すでに Azure Arc を本番運用している環境では、単に「最新版にする」だけでなく、ネットワーク経路やポリシー準拠レポートの見え方が変わる可能性を確認してから展開するのが安全です。
| 項目 | 主な変更 | 対象 |
|---|---|---|
| Guest Config | OpenSSL 3.6.1 から 3.6.2 へ更新 | Windows / Linux |
| Guest Config | 同梱 PowerShell 7.4.14 から 7.4.15 へ更新 | Windows |
| Guest Config | 長い構成パラメーター値によるセキュリティベースラインカスタマイズレポートの JSON エラーを修正 | Windows / Linux |
| Guest Config | 不明な Linux ディストリビューションのセキュリティベースライン割り当てを非準拠として正しく報告 | Linux |
| Guest Config | ポリシー割り当て要求のネットワーク帯域幅を削減 | Windows / Linux |
| Azcmagent | Arc Gateway バイパスリスト対応を追加 | Windows / Linux |
| Azcmagent | localconfig.json のバックアップファイルを追加 | Windows / Linux |
| Azcmagent | Ubuntu Pro サブスクリプション状態を検出プロパティに追加 | Linux |
| Azcmagent | Windows インストールスクリプトで MSI 署名から中間証明書を抽出 | Windows |
| Azcmagent | HIMDS が 421 応答時にリージョンエンドポイントを更新し、ハートビートを再試行 | Windows / Linux |
| Azcmagent | azcmagent show に ESU eligibility を追加 | Windows / Linux |
Microsoft のリリースノートでは、Azure Connected Machine agent 1.64 の Azcmagent は Windows / Linux ともに 1.64、Guest Config は Windows が 1.29.109.0、Linux が 1.26.110.0 とされています。(Microsoft Learn)
管理者が最初に見るべき影響範囲
Azure Connected Machine agent 1.64 の確認ポイントは、環境によって優先度が変わります。すべてのサーバーで同じように影響が出るわけではありません。
| 環境・利用状況 | 優先して確認すること |
|---|---|
| Azure Arc Gateway を使っている | バイパスリスト追加による通信経路の変化 |
| プロキシ経由で Arc に接続している | proxy.url、proxy.bypass、実効プロキシ設定 |
| セキュリティベースラインを割り当てている | カスタマイズレポートと準拠状態の再確認 |
| Linux サーバーを多く管理している | 不明なディストリビューションの非準拠判定、Ubuntu Pro 状態 |
| Windows Server ESU を管理している | azcmagent show の ESU eligibility 表示 |
| 自動アップグレードを使っている | 更新後のバージョンスタンプ、誤検知、段階展開状況 |
| 大規模サブスクリプションを管理している | Configuration UI の Resource Graph クエリ結果 |
特に注意したいのは、ネットワーク周りです。Azure Arc 対応サーバーは TCP 443 で Azure Arc へアウトバウンド通信し、必要に応じてプロキシを利用できます。Azure Arc Gateway を使うと必要なエンドポイント数を減らせますが、今回追加されたバイパスリスト対応により、指定した FQDN が Gateway を通らず、企業プロキシまたは直接接続を使う構成が可能になります。(Microsoft Learn)
Arc Gatewayバイパスリスト対応は何が便利なのか
今回の目立つ新機能は、Arc Gateway bypass list support です。これは、構成済みの FQDN を Arc Gateway 経由ではなく、企業のプロキシまたは直接接続へ逃がせる機能です。(Microsoft Learn)
実務上は、次のような環境で役立ちます。
| シーン | これまで起きやすい課題 | 1.64で期待できる効果 |
|---|---|---|
| Arc Gateway と社内プロキシを併用 | すべての通信を同じ経路に寄せると例外処理が難しい | 特定 FQDN だけ Gateway を回避しやすくなる |
| セキュリティ製品や監査基盤で特定通信を見たい | Gateway 経由だと経路設計が単純化される一方、個別制御しにくい | 監査対象の通信を企業プロキシ側に流せる |
| 段階的に Gateway へ移行中 | 既存プロキシ設計と新しい Gateway 設計が混在する | 移行期間中の例外設計をしやすい |
ただし、これは「Gateway を使っていれば何もしなくても最適化される」という意味ではありません。バイパス対象にした FQDN は別経路を使うため、ファイアウォール、プロキシ認証、SSL インスペクション、DNS 解決、監査ログの保存先をあわせて確認する必要があります。
既存のプロキシ構成は、azcmagent config または環境変数で設定できます。Microsoft のドキュメントでは、エージェント固有のプロキシ設定が優先され、azcmagent show で実効構成を確認できると説明されています。(Microsoft Learn)
azcmagent showプロキシ URL を確認する場合は、次のコマンドも使えます。
azcmagent config get proxy.url既存のプロキシ設定と Arc Gateway の経路を同時に変更する場合は、本番サーバー全体へ一括適用せず、まずネットワーク条件が代表的な数台で疎通、ハートビート、拡張機能、ポリシー評価を確認してください。
OpenSSLとPowerShell更新の見方
Guest Config では、OpenSSL が 3.6.1 から 3.6.2 に更新されました。対象は Windows / Linux の両方です。また、同梱 PowerShell は 7.4.14 から 7.4.15 に更新され、リリースノート上では Windows 側にチェックが付いています。(Microsoft Learn)
この種の更新は、見た目には小さく見えます。しかし、Azure Arc 対応サーバーではポリシー評価、拡張機能、構成処理、スクリプト実行に関わるため、管理者は次を確認しておくべきです。
| 確認項目 | 理由 |
|---|---|
| 拡張機能のインストール・更新が正常に終わるか | 署名検証や通信処理の変更が影響する可能性があるため |
| Machine Configuration の評価結果が従来と矛盾しないか | Guest Config 更新により報告内容が修正される場合があるため |
| 独自スクリプトが PowerShell の細かな差分で失敗しないか | 特に型変換、JSON 処理、外部コマンド呼び出しは確認したい |
| プロキシ・TLS 検査環境で接続が維持されるか | 証明書チェーンや TLS 設定に依存する環境では差分が出やすいため |
更新後に「ポリシー準拠率が急に変わった」場合、必ずしもサーバー構成が変わったとは限りません。今回のように、レポート生成や不明ディストリビューションの判定が修正されると、これまで見えていなかった非準拠が見えるようになることがあります。
セキュリティベースライン利用者はレポートの再確認が必須
Azure Connected Machine agent 1.64 では、セキュリティベースライン関連の修正が複数含まれています。特に重要なのは、長い構成パラメーター値が原因でセキュリティベースラインカスタマイズレポートが不正な JSON になって失敗する問題の修正です。また、未知の Linux ディストリビューションに対するセキュリティベースライン割り当てでは、準拠状態が正しく「非準拠」として報告されるよう修正されています。(Microsoft Learn)
ここで気を付けたいのは、更新後に「悪化したように見える」ケースです。
たとえば、以前はレポートが失敗していたために詳細が見えなかったサーバーが、1.64 適用後に非準拠として表示される場合があります。これは新たな障害というより、報告精度が上がった結果として扱うべきです。
確認手順は、次の順で進めると混乱を避けられます。
| 手順 | 作業 | 判断ポイント |
|---|---|---|
| 1 | 更新前の準拠状態を控える | サーバー単位、ポリシー割り当て単位で記録する |
| 2 | 少数の検証対象に 1.64 を適用 | OS、リージョン、プロキシ条件が異なる代表機を選ぶ |
| 3 | セキュリティベースラインの評価結果を再取得 | 非準拠の増減だけでなく、失敗から非準拠への変化を見る |
| 4 | JSON レポートの生成失敗が解消したか確認 | カスタマイズ値が長い設定を重点的に見る |
| 5 | 本番展開前に運用チームへ共有 | 「準拠率が下がる可能性」を事前に説明する |
準拠率は、監査やセキュリティ KPI に使われることがあります。そのため、エージェント更新に伴う表示・判定の変化を、実際の構成変更と混同しないことが重要です。
localconfig.jsonバックアップで構成ファイルの信頼性が向上
1.64 では、localconfig.json のバックアップファイルが追加されました。これは 1.62 で導入された agentconfig.json のバックアップと同様に、構成ファイルまわりの信頼性を高める変更です。(Microsoft Learn)
この変更は、普段の操作では目立ちません。しかし、大規模運用では価値があります。たとえば、次のようなケースで復旧判断がしやすくなります。
- エージェント更新中に構成ファイルが破損した
- 自動化スクリプトが意図しない値を書き込んだ
- プロキシや接続方式の変更後に Arc 接続が不安定になった
- 障害調査で「いつ、どの設定が変わったか」を追う必要が出た
ただし、バックアップがあるからといって、構成管理をエージェント任せにしてよいわけではありません。IaC、構成管理ツール、変更申請、監査ログのいずれかで、プロキシ設定、接続方式、タグ、拡張機能、ポリシー割り当てを追跡できる状態にしておくべきです。
HIMDSとハートビートの改善で接続安定性が上がる
1.64 では、HIMDS がサービスから 421 応答を受け取った場合にリージョンエンドポイントを更新し、ハートビートを再試行するようになりました。HIMDS は Azure との接続や接続済みマシンの Azure ID を管理するコンポーネントです。(Microsoft Learn)
Azure Arc 対応サーバーでは、ハートビートが途絶えると管理上は切断状態として扱われます。Microsoft の概要ドキュメントでは、Connected Machine agent は 5 分ごとに Azure へハートビートを送り、15 分を超えて送信されない場合、サーバー停止、ネットワーク遮断、エージェント停止などが考えられると説明されています。(Microsoft Learn)
更新後に確認したいのは、次のログと状態です。
| 確認対象 | Windows | Linux |
|---|---|---|
| HIMDS ログ | %ProgramData%\AzureConnectedMachineAgent\Log\himds.log | /var/opt/azcmagent/log/himds.log |
| azcmagent ログ | %ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log | /var/opt/azcmagent/log/azcmagent.log |
| ポリシー関連ログ | %ProgramData%\GuestConfig\arc_policy_logs\gc_agent.log | /var/lib/GuestConfig/arc_policy_logs |
| 拡張機能ログ | %ProgramData%\GuestConfig\ext_mgr_logs\gc_ext.log | /var/lib/GuestConfig/ext_mgr_logs |
一時的な切断が多い環境では、更新後に「切断時間」「再接続までの時間」「421 応答の頻度」「プロキシや Gateway 側のログ」を比較すると、改善の効果を判断しやすくなります。
Ubuntu ProとESU管理への影響
Linux では、検出プロパティに Ubuntu Pro サブスクリプション状態が追加されました。Ubuntu Pro を使ってセキュリティ更新や拡張メンテナンスを管理している組織では、Azure Arc 側のインベントリ情報として状態を把握しやすくなる可能性があります。(Microsoft Learn)
また、azcmagent show の出力に ESU eligibility が追加されました。ESU は Extended Security Updates の文脈で重要になるため、Windows Server の延長セキュリティ更新を Azure Arc 経由で管理している場合は、更新後に表示を確認しておく価値があります。
azcmagent show実務では、次のように使うと便利です。
| 用途 | 確認内容 |
|---|---|
| Windows Server ESU 対象確認 | ESU eligibility が期待どおり表示されるか |
| 台帳との突き合わせ | CMDB や資産管理表の OS 情報と差異がないか |
| 監査対応 | ESU 対象外サーバーが誤って運用対象に残っていないか |
| 移行計画 | ESU 対象サーバーを Azure 移行、OS 更新、廃止の候補に分類する |
ESU や Ubuntu Pro の状態は、ライセンス、サブスクリプション、OS バージョン、契約内容と関係します。azcmagent show の表示だけで最終判断せず、Azure ポータル、契約情報、OS 側の状態も合わせて確認してください。
Windows環境で注意したいインストール関連の改善
Windows では、インストールスクリプトが MSI の Authenticode 署名から中間証明書を抽出し、中間証明書がキャッシュされていない場合の検証失敗を避ける改善が入りました。(Microsoft Learn)
これは、閉域寄りのネットワーク、証明書取得先へのアクセスが制限されている環境、WSUS や Configuration Manager を使った配布環境で意味があります。インストールや更新時に署名検証で失敗した経験がある場合は、1.64 の検証対象として Windows サーバーを優先するとよいでしょう。
ただし、証明書関連の問題がすべて解決するわけではありません。以下のような設定は引き続き確認が必要です。
| 確認項目 | 失敗しやすいポイント |
|---|---|
| ルート証明書・中間証明書の配布 | サーバーが証明書チェーンを構築できない |
| TLS インスペクション | Azure Arc 通信や証明書検証に影響する |
| プロキシ認証 | エージェントや拡張機能が期待どおりプロキシを使えない |
| Microsoft Update / WSUS | Azure Connected Machine Agent の製品・分類が同期対象になっていない |
Windows Server では Microsoft Update が既定で Microsoft 製品の更新を確認しない場合があります。Azure Connected Machine agent を Microsoft Update で更新する運用では、Windows Update クライアントが他の Microsoft 製品も確認するように構成されているか確認が必要です。(Microsoft Learn)
自動アップグレード利用時の確認ポイント
Azure Connected Machine agent は、手動更新だけでなく自動アップグレードも選択できます。Microsoft の管理ドキュメントでは、バージョン 1.57 以降で自動アップグレードを構成でき、この機能はパブリックプレビューとして説明されています。自動アップグレードはバッチでロールアウトされ、ピーク時以外に開始され、失敗した場合は再試行されます。(Microsoft Learn)
1.64 では、自動アップグレード中にバイナリが置き換えられた場合のエージェントバージョンスタンプ修正と、アップグレードランチャースクリプトの誤検知除去も含まれています。(Microsoft Learn)
自動アップグレードを使っている場合は、次を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 更新後のバージョン表示 | Azure ポータル、azcmagent show、ログで 1.64 と整合するか |
| 更新失敗の再試行 | 同じサーバーで失敗が繰り返されていないか |
| メンテナンス時間帯 | 業務影響が少ない時間帯に更新されているか |
| 監視アラート | 更新中の一時的な切断やサービス再起動を障害として扱っていないか |
| 例外サーバー | 重要サーバーだけ手動更新や段階展開に分ける必要がないか |
自動アップグレードは運用負荷を下げますが、変更管理が不要になるわけではありません。特に金融、医療、製造、公共系など、サーバー変更の証跡が必要な環境では、更新タイミング、対象、結果を記録する仕組みを先に整えてください。
アップグレード前に確認すべきチェックリスト
本番環境へ Azure Connected Machine agent 1.64 を展開する前に、最低限次の項目を確認してください。
| チェック項目 | 確認方法 |
|---|---|
| 現在のエージェントバージョン | azcmagent show、Azure ポータル、Azure Resource Graph |
| サポート対象バージョン内か | 直近 1 年以内にリリースされたバージョンか確認 |
| プロキシ・Gateway 設定 | azcmagent show、azcmagent config get proxy.url |
| セキュリティベースラインの状態 | 更新前後の準拠率、失敗数、非準拠理由を比較 |
| 拡張機能の状態 | インストール、更新、削除、Run Command の結果 |
| ハートビート | 更新中・更新後に切断が長引かないか |
| Windows の証明書検証 | MSI 実行、署名検証、プロキシ経由の取得可否 |
| Linux のディストリビューション判定 | 不明ディストリビューションが非準拠として扱われるか |
| ESU / Ubuntu Pro | 表示結果が資産台帳や契約内容と矛盾しないか |
| ロールバック方針 | 問題発生時に更新停止、切り戻し、再接続の手順があるか |
Microsoft は、正式にサポートされる Connected Machine agent は直近 1 年以内にリリースされたバージョンのみであり、顧客はその範囲内のバージョンへ更新するか、自動アップグレードを有効にする必要があると案内しています。(Microsoft Learn)
展開手順の実務例
大規模環境では、1.64 をいきなり全台へ展開するのではなく、サーバーの役割とネットワーク条件でグルーピングして段階展開するのが現実的です。
小規模環境の場合
数台から十数台程度であれば、手動更新でも管理できます。
- 現在のバージョンと接続状態を確認する
- プロキシ、Gateway、ポリシー、拡張機能の利用有無を控える
- 重要度の低いサーバーから更新する
azcmagent showで接続状態、ESU eligibility、検出プロパティを確認する- セキュリティベースラインと拡張機能の状態を確認する
- 問題がなければ残りのサーバーへ展開する
大規模環境の場合
数百台以上では、Azure Policy、自動アップグレード、Configuration Manager、WSUS、Linux パッケージ管理、運用スクリプトのいずれかを組み合わせます。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | 5〜10台 | OS、プロキシ、Gateway、拡張機能の代表パターンを確認 |
| 先行展開 | 5〜10% | 監視アラート、ポリシー準拠、ハートビートの変化を見る |
| 本番展開 | 残り | 業務影響の少ない時間帯に順次更新 |
| 事後確認 | 全台 | バージョン、接続状態、非準拠、失敗ログを集計 |
Microsoft の管理ドキュメントでは、Windows は Microsoft Update、Microsoft Update Catalog、Download Center、Linux は apt / yum / zypper などで更新できると説明されています。また、エージェントのインストール、アップグレード、アンインストールではサーバー再起動は不要とされています。(Microsoft Learn)
よくある失敗と回避策
Azure Connected Machine agent の更新では、エージェントそのものよりも、周辺のネットワーク、証明書、ポリシー、拡張機能でつまずくことが多くあります。
| 失敗しやすい例 | 原因 | 回避策 |
|---|---|---|
| 更新後に Arc が切断状態になる | プロキシ、Gateway、DNS、TLS 検査の影響 | 更新前後で azcmagent show と HIMDS ログを比較 |
| 準拠率が急に下がる | レポート修正で非準拠が正しく見えるようになった | 更新前の評価結果と差分を取り、監査チームへ説明 |
| Windows の MSI 更新が失敗する | 証明書チェーン、権限、配布経路の問題 | 管理者権限、証明書、WSUS / Microsoft Update 設定を確認 |
| Linux の一部だけ評価結果が変わる | 未知のディストリビューション判定や Guest Config 差分 | OS 名、バージョン、サポート状況を棚卸しする |
| 自動アップグレードの結果が追えない | 変更管理やログ集約が不足 | 更新対象、日時、結果を Azure Resource Graph や運用台帳で記録 |
| Gateway 経由の通信だけを想定していた | バイパス対象 FQDN が別経路を使う | ファイアウォールとプロキシログで経路を確認 |
更新作業で重要なのは、「成功したか」だけでなく、「どのサーバーで何が変わったか」を追える状態にすることです。特に Azure Arc はオンプレミス、他社クラウド、エッジ環境をまたいで管理するため、ネットワーク条件の違いが更新結果に出やすくなります。
今回の更新で管理者が次に取るべき行動
Azure Connected Machine agent 1.64 は、Azure Arc 対応サーバーの運用を安定させるための実務的な改善が中心です。すぐに確認すべき優先順位は、次のとおりです。
まず、Azure Arc Gateway またはプロキシを使っている環境では、Arc Gateway バイパスリスト対応による通信経路の変化を確認してください。次に、セキュリティベースラインを利用している環境では、更新前後の準拠状態と JSON レポートの失敗有無を比較します。Windows Server ESU や Ubuntu Pro を管理している場合は、azcmagent show と検出プロパティの表示も確認対象です。
最後に、全台展開の前に、OS、ネットワーク、ポリシー、拡張機能の条件が異なる代表サーバーで検証してください。1.64 は派手な機能追加ではありませんが、ネットワーク設計、準拠性レポート、ライセンス・ESU 管理に関わるため、変更管理の対象として扱うべき更新です。
コメント