Windows 11 24H2を搭載したArm版Copilot+ PCに、Intuneから「Microsoft Windows Update Health Tools 2025 (64-bit)」MSIを配布したら、インストールが無言で失敗して困っていませんか。本記事では、原因となるアーキテクチャの違いと、Arm64端末でエクスペダイト更新を運用するための現実的な対処策を解説します。
想定シナリオの整理
まずは、今回の事象を整理しておきます。実際の現場でよくあるパターンは次のようなものです。
| 項目 | 内容 |
|---|---|
| 対象デバイス | Windows 11 24H2 搭載 Arm64（Copilot+ PC 世代） |
| 配布方法 | Microsoft Intune から MSI（Win32 アプリ or LOB アプリ）として配布 |
| インストーラー | Microsoft Windows Update Health Tools 2025 (64-bit) MSI |
| 目的 | Windows Update for Business（WUFB）のエクスペダイト更新を利用可能にすること |
| 現象 | セットアップは開始されるが、ユーザー画面上はメッセージなしで終了し、アプリも追加されない（無言失敗） |
| 影響台数 | 約 100 台規模の Arm64 端末 |
一見、単なる「MSI インストール失敗」に見えますが、背景には Update Health Tools の前提条件 と Windows on Arm のアーキテクチャ制限 が絡んでいます。
Update Health Tools とエクスペダイト更新の関係
Update Health Tools とは何か
Microsoft Update Health Tools（KB4023057）は、Windows Update の信頼性を向上させるためのコンポーネントで、特に企業環境では WUFB Deployment Service での品質更新・機能更新の管理や、Intune／Graph API からのエクスペダイト更新に必須コンポーネントとして位置付けられています。
KB4023057 のサポート記事では、「Update Health Tools は Windows 10 / 11 向けに配布される更新であり、Intune からセキュリティ更新をエクスペダイトする際に必要」と明記されています。ファイル情報としては、Windows 10/11 21H2・22H2 向けの x86 / x64 版バイナリのみが公開されており、Arm64 向けのファイルは記載されていません。
エクスペダイト更新の前提条件（概要）
Intune の公式ドキュメント「Expedite Windows quality updates」では、エクスペダイト更新を利用するための前提条件として以下が挙げられています。
- サポート期間内の Windows バージョンであること
- x86 または x64 アーキテクチャ上の Windows であること
- デバイスが Intune に登録済みであること（Entra ID Join / Hybrid Join）
- 品質更新の取得元が Windows Update サービスであること
- Update Health Tools がインストールされていること（KB4023057 または手動インストール）
同じドキュメントには、Windows 11 24H2 以降は KB4023057 を適用できず、24H2 へアップグレードすると KB4023057 は削除されるため、KB の有無をチェックする必要はない、という注記もあります。
さらに、Microsoft Q&A では、Windows 11 23H2 以降では Update Health Tools 自体を前提にしないという回答も出ています。
これらを整理すると、エクスペダイト更新における Update Health Tools の扱いは、バージョンによって次のように変化していると考えられます。
| OS バージョン | アーキテクチャ | Update Health Tools の扱い | ポイント |
|---|---|---|---|
| Windows 10 / 11 21H2〜22H2 | x86 / x64 | KB4023057 として提供される Update Health Tools がエクスペダイトの必須前提 | MS サポート記事と KB ファイル情報に明記 |
| Windows 11 23H2 | x64 | Q&A では「Update Health Tools は不要」との回答 | OS に機能が統合されたとみなせるが公式ドキュメントの書きぶりはやや過渡期 |
| Windows 11 24H2 | x64 | KB4023057 自体は適用できず、アップグレード時に削除される。KB の有無チェックは不要 | エクスペダイト自体は継続サポートされる前提 |
| Windows 11 24H2 | Arm64 | Update Health Tools の Arm64 版は公開情報上確認できず。エクスペダイトの前提条件も「x86 / x64」のみが明記 | 少なくとも現時点で Arm64 は公式にサポート対象とは書かれていない |
つまり、「エクスペダイトのために Arm64 端末へ Update Health Tools MSI を入れる」前提がそもそも崩れつつある、というのが現在の状況です。
Arm 版 24H2 で MSI が無言失敗する理由
「64-bit」= ほぼ確実に x64（Intel/AMD）
今回配布しているのは「Microsoft Windows Update Health Tools 2025 (64-bit)」MSI ですが、ここでの「64-bit」は一般的に x64（AMD64） を指し、Arm64 ネイティブ向けではありません。
実際、同じ事象を報告している Microsoft Q&A では、Arm 版 Windows 11 24H2 Copilot+ PC に対するこの MSI 配布について、「64-bit と表示されているが中身は x64 向けであり、Arm64 では正しく動作しない可能性が高い」と指摘されています。
加えて、KB4023057 のファイル一覧には x86 / x64 向けのバイナリしか掲載されておらず、Arm64 用のビルドは公開されていません。
Windows on Arm のエミュレーションと MSI の限界
Windows 11 on Arm では、x86 / x64 アプリケーションをエミュレーションで動作させることができます。特に最新世代の Arm ベース Surface デバイスでは、x86 Win32 アプリや多くの x64 アプリが問題なく動作することが公式にも案内されています。
しかし、今回のような システム寄りのツール（サービス・ドライバー・更新コンポーネント）を含む MSI では事情が異なります。
- MSI の中に プラットフォームチェック（Template Summary / LaunchCondition） が入っている
- サービスやドライバーのインストール先が x64 前提になっている
- InstallShield / WiX などの設定で「x64 専用」としてビルドされている
このような MSI を Arm64 端末で実行すると、Windows Installer の戻り値 1633 = ERROR_INSTALL_PLATFORM_UNSUPPORTED（このプロセッサではサポートされていない）が返されるのが一般的です。Intune のエラーコード一覧でも 1633 は「このインストール パッケージは、このプロセッサ タイプではサポートされていない」と定義されています。
ところが、Intune から /qn（サイレント）でインストールしていると、UI 上は何も表示されず、単に「無言で終わった」ように見えてしまうため、原因がわかりづらくなります。
MSI ログで確認すべきポイント
無言失敗を「見える化」するため、MSI の詳細ログを必ず取るようにしましょう。Intune のインストールコマンドは次のように変更できます。
msiexec /i "WindowsUpdateHealthTools.msi" /qn /l*v "%ProgramData%\Microsoft\IntuneManagementExtension\Logs\WUHT_install.log"
取得した WUHT_install.log では、次のような点を確認します。
| 確認ポイント | 内容 |
|---|---|
| Error 1633 | 「This installation package is not supported by this processor type」＝プラットフォーム不一致。Arm64 端末で x64 専用 MSI を実行した典型的なパターン。 |
| Error 1603 | 致命的エラー。前提条件不足やサービス登録失敗、権限不足など幅広い原因。基本的にはログ内の「Return value 3」周辺を詳細に追う。 |
| Template Summary / ProcessorArchitecture | MSI が x64 専用としてビルドされているかどうかの手掛かりになる。 |
あわせて、イベント ビューアーの「Windows ログ > アプリケーション」に出力される MsiInstaller イベント（エラーや警告）も確認しておくと、Intune ポータルから見える情報と紐付けしやすくなります。
Arm64 端末での成功例・既知の状況
公開されている情報（Microsoft Q&A / KB / Intune ドキュメントなど）を調べる限り、「Windows Update Health Tools 2025 (64-bit)」MSI を Windows 11 24H2 Arm64 端末にインストールできた成功例は見当たりません。
同じ事象を報告している Microsoft Q&A では、Microsoft 社員が質問者で、影響台数やシナリオもほぼ同じですが、受理された回答はコミュニティの Independent Advisor による「64-bit は x64 を指しており Arm64 向けではない。Arm64 ネイティブ版があるか Microsoft サポートに確認すべき」という内容に留まっています。
一方、KB4023057 のファイル情報では、前述の通り Windows 10/11 21H2・22H2 向けの x86 / x64 バイナリのみが列挙されており、Arm64 向けの行は存在しません。
これらを踏まえると、現時点での前提としては次のように考えるのが現実的です。
- Update Health Tools の Arm64 ネイティブ版 MSI は少なくとも一般公開されていない
- エクスペダイト更新の前提条件としても、公式には x86 / x64 アーキテクチャのみが明示 されている
- Windows 11 23H2 以降では、Update Health Tools のインストール有無よりも、OS 自体のエクスペダイト機能とネットワーク要件のほうが重要になっている
実務で取るべき対処フロー
ここからは、運用者目線で「明日からどう設計を変えるか」を具体的な手順として整理します。
1. Intune でアーキテクチャ別にターゲットを分離する
まず最優先は、x64 専用 MSI を Arm64 端末に配布しないようにすることです。現在の Intune では、Win32 アプリ／MSI アプリの要件として OS アーキテクチャを x86 / x64 / ARM64 から選択でき、最近の更新で ARM64 を個別に選べるようになりました。
Windows Update Health Tools 2025 (64-bit) MSI を配布しているアプリについて、次のように設定します。
- Requirements（要件） で
- Operating system architecture = x64 のみを選択
- ARM64 はチェックを外す
- すでに ARM64 端末に割り当てていた場合は、Assignments から対象グループを見直し、Arm 専用グループからは除外する
また、より厳密に分けたい場合は、Intune の Assignment Filter で CPU アーキテクチャを条件にすることもできます。2024 年以降、デバイスフィルターのプロパティとして cpuArchitecture が追加され、amd64 / arm64 / x86 を条件にできるようになっています。
例えば、次のようなフィルターを作成することで、「Arm64 端末だけ除外する」設定が可能です。
- プラットフォーム：Windows 10 and later
- ルール（Rule syntax の例）：
(device.cpuArchitecture -eq "arm64")
このフィルターを Exclude モードで割り当てることで、当該アプリを Arm64 端末から切り離せます。
2. Arm64 端末への Update Health Tools MSI 配布を一旦やめる
上記の設定によって、Arm64 端末には x64 用 MSI を配布しない状態にします。これは「諦める」というより、そもそも Arm64 向け MSI が存在しない以上、無理に流さないほうが安定する、という判断です。
エクスペダイト更新については、公式ドキュメントの前提条件が「x86 / x64 アーキテクチャ」となっているため、Arm64 端末は少なくとも現時点では正式サポート対象とはみなせない状況です。
そのため、Arm64 端末では次のような方針が現実的です。
- エクスペダイト ポリシーの「対象」からは外し、Update rings（更新リング）の期限設定とメンテナンス時間の調整でカバーする
- 深刻なゼロデイなどの際は
- x64 端末：エクスペダイト + 厳しめの期限
- Arm64 端末：専用の「緊急リング」を作成し、品質更新の期限を 0〜1 日に設定
3. Arm64 端末向けの更新ポリシーを具体的に設計する
混在環境を前提としたとき、Windows Update のポリシーは次のように整理しておくと運用しやすくなります。
| デバイス種別 | 平常時 | 緊急時（ゼロデイ等） |
|---|---|---|
| Windows 11 24H2 x64 | 通常リング（デフerral + デッドラインあり） | Intune のエクスペダイト ポリシーで対象更新を指定 |
| Windows 11 23H2 x64 | 同上。Update Health Tools の有無チェックは不要 | 同上（エクスペダイト使用） |
| Windows 11 24H2 Arm64 | Arm 用更新リング（デフerral + デッドラインは x64 よりやや緩く） | Arm 用「緊急リング」に一時的に切り替え、品質更新の期限を 0〜1 日に短縮 |
| Windows 10 / 11 22H2 以前 | Update Health Tools（KB4023057）を WU または Intune で適用 | エクスペダイト利用可。KB4023057 のインストール状況を検出ルールで管理 |
このように「x64 でエクスペダイト」「Arm64 ではリング強化」という二段構えにしておくと、Arm64 が増えてもポリシー設計が破綻しにくくなります。
4. Intune の「Expedite Client missing」エラーへの向き合い方
Windows 11 24H2 端末で、Intune のレポートに「Expedite Client missing」等のアラートが出るケースがありますが、Microsoft Q&A では 23H2 以降は Update Health Tools が必須ではない と回答されており、エラー表示がロジック上の齟齬である可能性も指摘されています。
そのため、次のように割り切るのが現実的です。
- 24H2 x64 端末：
- 実際にエクスペダイト更新が適用されているか（Windows Updates レポートやクライアントの更新履歴）を優先して見る
- Update Health Tools の有無は参考程度にとどめる
- 24H2 Arm64 端末：
- そもそもエクスペダイトが公式サポート対象外の可能性が高いため、「Expedite Client missing」は 仕様に追随していない警告 と捉える
- どうしても必要なら Microsoft サポートに公式見解を問い合わせる
ログと検出ルールのベストプラクティス
MSI インストールログの標準化
今後同様のトラブルに備えるため、MSI インストールのログ取得方法を標準化しておくと調査が格段に楽になります。
- Intune のインストールコマンドは 必ず
/l*v付き にする - ログ出力先は、運用チームで収集しやすい共通パス（例：
%ProgramData%\Microsoft\IntuneManagementExtension\Logs配下）に統一 - トラブル時は Intune の「診断ログ収集」機能で一括取得する運用を決めておく
検出ルール（Detection Rule）の例
x64 端末向けに Update Health Tools が正しく入っているか確認するための、フォルダー＋サービス検出の例を示します。
# フォルダー存在確認（Win32 アプリの検出ルール）
C:\Program Files\Microsoft Update Health Tools\
# PowerShell 検出スクリプトの例
if (Get-Service -Name "Microsoft Update Health Service" -ErrorAction SilentlyContinue) {
Write-Host "Installed"
exit 0
} else {
Write-Host "Not installed"
exit 1
}
このスクリプトは、Microsoft のエクスペダイト ドキュメントでも紹介されているロジックと同様に、サービスの有無で Update Health Tools の存在を判定するものです。
混在アーキテクチャ時代の WUFB 設計ポイント
最後に、x64 と Arm64 が混在する環境で、Windows Update for Business を設計する際の観点を整理しておきます。
- アーキテクチャごとに「できること／できないこと」を明確に分ける
- x64：エクスペダイト更新、Update Health Tools、従来のロジックがそのまま使える
- Arm64：エクスペダイトは現時点で公式サポート外と捉え、リング／期限設定でリスクを抑える
- Intune の「OS アーキテクチャ」と「cpuArchitecture フィルター」をフル活用
- アプリ要件で OS アーキテクチャを絞る
- ポリシー／アプリの割り当てには cpuArchitecture フィルターで Arm64 を明示的に含める／除外する
- レポーティングは WUFB レポートで統一
- Windows Update for Business reports を有効化し、品質更新・エクスペダイトの状態を一元管理する
こうした分離を最初から前提に設計しておけば、今後 Arm64 端末が増えても、Update Health Tools やエクスペダイトの仕様変更に振り回されにくくなります。
まとめ
- 今回の無言失敗の本命原因は「x64 向け MSI を Arm64 端末に配布していること」です。MSI ログでは多くの場合 Error 1633 が確認できます。
- Update Health Tools の Arm64 ネイティブ版 MSI は公開されておらず、エクスペダイトの前提条件も公式には x86 / x64 のみが明記されています。
- Windows 11 23H2 以降では Update Health Tools の有無より、OS とネットワーク要件のほうが重要であり、24H2 では KB4023057 自体が適用対象外です。
- 現実的な運用としては、x64 端末に対してのみ Update Health Tools 2025 (64-bit) MSI を配布し、Arm64 端末には配布しないよう Intune の要件・フィルターで切り分けるのが安全です。
- Arm64 端末の緊急パッチ適用は、エクスペダイトではなく「品質更新リングの期限短縮」と「メンテナンス時間の調整」でカバーする設計に切り替えると運用が安定します。
- MSI 詳細ログ（/l*v）と WUFB レポートを標準化しておくことで、今後のトラブルシュートが大幅に効率化されます。
コメント