Visual Studio 2022 の「管理者更新（Administrator Updates）」を Intune と Windows Update for Business（WUfB）で自動配布できるようにしたのに、「セキュリティ更新だけ？」「17.12→17.13 のような機能更新も入る？」と迷うことがあります。結論と、機能更新まで含めるための運用案を整理します。
結論：Intune／WUfB で自動配信される Visual Studio 2022 の管理者更新は、現時点では「セキュリティ更新のみ」
Intune（Microsoft Endpoint Manager）で WUfB を構成し、Windows Update の「Microsoft 製品の更新プログラムも受け取る」経由（Microsoft Update チャネル）で配布される Visual Studio の管理者更新は、現時点ではセキュリティ更新のみです。そのため、17.12.4→17.12.5 のような同一マイナーバージョン内のサービシング更新（セキュリティ修正を含む更新）は適用され得ますが、17.12→17.13 のようにマイナーバージョンが上がる機能更新（Feature update / Feature pack）は WUfB では配信されません。
「将来はどうなるのか？」についても、Microsoft の Q&A では少なくとも 2025 年 2 月時点で「現状はセキュリティのみ」「バージョン更新を WUfB で配信する計画は今のところ把握していない」といった回答が出ています。ロードマップの確度が必要なら Developer Community で製品チームに確認するのが確実です。
| やりたいこと | Intune／WUfB（Microsoft Update）でできる？ | 現実的な代替手段 |
|---|---|---|
| 17.12.4 → 17.12.5（同一 17.12 系のパッチ適用） | できる可能性が高い（セキュリティ更新として配信される範囲） | そのまま WUfB 運用で OK |
| 17.12 → 17.13（機能更新・マイナーバージョン更新） | できない（WUfB にはセキュリティ更新のみ） | Update Catalog／SCCM 取り込み／レイアウト更新／Installer 経由の計画展開 |
混乱ポイントを解消：Visual Studio の「バージョン更新」と「セキュリティ（サービシング）更新」は別物
Visual Studio 2022 の更新は、大きくマイナーバージョン更新（例：17.3→17.4）と、サービシング更新（例：17.2.3→17.2.4）の二層で整理できます。前者が「新機能やプラットフォーム更新を含む更新」、後者が「既存機能に対する累積的な修正（セキュリティ／品質）」という位置づけです。
管理者更新（Administrator Updates）の配布チャネルは3つある
Visual Studio の管理者更新は、配布の“入口”がいくつか用意されています。ポイントは「管理者更新のパッケージそのものは Microsoft Update 側に公開されるが、どのチャネルで受け取るかで“流れてくる更新の種類”が変わる」という点です。
| 配布チャネル | 主な制御主体 | 自動で流れる更新の種類 | 向いている用途 |
|---|---|---|---|
| WSUS／SCCM（Configuration Manager） | オンプレ中心の端末管理（MECM） | 既定ではセキュリティ更新が中心（機能更新・品質更新はカタログから取り込みが必要） | 社内ネットワーク中心、細かい承認・展開制御をしたい |
| WUfB（Microsoft Update）／Intune | クラウド管理（Intune） | 現時点ではセキュリティ更新のみ | クラウド接続端末に“最低限の安全”を自動適用したい |
| Microsoft Update Catalog | 手動 or SCCM に取り込み | セキュリティ／品質／機能（Feature Pack）など、必要な更新を選んで入手 | 機能更新（17.12→17.13 など）を計画的に進めたい |
特に WUfB（Microsoft Update）チャネルについては、Microsoft Learn のドキュメントで「現在このチャネルにはセキュリティ更新のみ公開される」と明記されています。つまり Intune で WUfB を整えても、Visual Studio の“機能更新の自動配信”まではカバーしない、というのが今の仕様です。
「セキュリティ更新のみ」でも 17.12.x が進む理由
「セキュリティ更新だけ」と聞くと “バージョンは固定” のイメージになりがちですが、Visual Studio では同一マイナーバージョン内のサービシング更新（17.12.4→17.12.5 のようなパッチ）にセキュリティ修正が含まれるため、結果として “17.12.x が進む” ことが起こります。
管理者向けセキュリティ更新は「月次」を前提にスケジュールしやすい
Visual Studio 2022 の管理者向けセキュリティ更新は、原則として月次（いわゆる Patch Tuesday のタイミング）で公開される前提で案内されています。運用側は「毎月この週は開発端末の更新が走る」ことを織り込んで、更新リング（パイロット→全体）や、業務影響が少ない時間帯のメンテナンス設計をしておくと事故が減ります。
管理者更新は“累積”なので、最新版が最短ルート
Visual Studio の管理者更新は累積更新で、より新しい更新（より高い製品バージョン）ほど過去の更新を包含します。途中の更新を取りこぼしても、次の更新を適用できれば結果的に追いつける構造なので、運用設計としては「最新版を確実に当てる」ことに集中するのが合理的です。
逆に、17.12→17.13 のようにマイナーバージョンが変わる更新は Feature Pack（機能更新）扱いで、WUfB（Microsoft Update）には流れません。ここを取り違えると「設定したのに上がらない」「端末によって 17.13 になったりならなかったりする」という運用事故につながります。
運用設計の基本は「レーン分離」：セキュリティは自動、機能更新は計画的に
現場で安定するのは、更新を 2 本立てで設計する方法です。WUfB の強みは“毎月のセキュリティを取りこぼさないこと”なので、そこに役割を限定し、機能更新（マイナーバージョン更新）は別の仕組みで管理します。
| 更新レーン | 対象 | 頻度の目安 | 配布方法の例 | 狙い |
|---|---|---|---|---|
| セキュリティ（自動レーン） | サービシング更新（17.12.x の x が進む） | 月次 | Intune＋WUfB（Microsoft Update） | 脆弱性対応の遅延を最小化 |
| 機能更新（計画レーン） | マイナーバージョン更新（17.12→17.13 など） | 四半期・半期・プロジェクト都合 | Update Catalog／SCCM 取り込み／レイアウト更新／Installer | 互換性検証を挟みつつ、組織で標準化 |
Intune／WUfB で「管理者更新（セキュリティ）」を成立させる設定チェック
「セキュリティ更新だけでよい（まずは自動化したい）」という場合でも、設定が 1 つ抜けると端末が更新を受け取れません。ここでは実務で効くポイントだけを抜粋します。
まず確認したい：Visual Studio ポリシーが参照するレジストリの優先順位
Visual Studio のポリシーは、複数のレジストリ パスを上から順に参照し、どこかで値が見つかった時点で残りは見に行きません。端末ごとに「どこに設定したか」が揃っていないと、意図せず違う値が効いてしまうので、運用では配置場所も標準化しておくのがおすすめです。
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\VisualStudio\Setup（優先）
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\Setup
- HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\Setup（64-bit OS の場合）
| チェック項目 | 狙い | 確認ポイント |
|---|---|---|
| 端末が WUfB で Microsoft Update を利用できる状態か | Windows Update で「他の Microsoft 製品」更新を受け取る | Intune 側で WUfB ポリシーを適用し、AllowMUUpdateServicePolicy（= “他の Microsoft 製品の更新も受け取る”）を有効化する |
| Visual Studio が「管理者更新を受け取る」意思表示をしているか | 意図しない一斉更新を防ぎつつ、管理者更新を許可 | AdministratorUpdatesEnabled を適切に設定（WUfB／Intune 経由なら推奨値は 2） |
| ユーザー側で “受け取り拒否” にされていないか | 現場の端末だけ更新されない事故を潰す | AdministratorUpdatesOptOut が 1 になっていないか（OptOut が優先される） |
| 更新実行アカウント（SYSTEM）が更新ソースに到達できるか | 「検出するが失敗する」を防ぐ | 既定では SYSTEM がダウンロード／更新するため、インターネットまたは社内レイアウト共有へのアクセス権が必要 |
| Visual Studio が起動中で更新がブロックされていないか | 失敗→放置、を防ぐ | Visual Studio 使用中は更新が適用できない。必要なら通知ポリシー（管理者更新通知）で “閉じてください” を促す |
| Client Detector Utility が入っているか | 管理者更新を正しく検出する | VS 2022 では通常同梱されるが、検出トラブル時は前提条件として確認する |
現場でよく使う：レジストリ値の確認コマンド例
Intune の設定カタログを使っていても、トラブルシュートでは「端末のローカルで最終的に何が効いているか」を確認する場面が出ます。まずは優先度が高い SOFTWARE\Policies 配下から確認し、値が無ければ次のパスを追いかけます。
reg query "HKLM\SOFTWARE\Policies\Microsoft\VisualStudio\Setup" /v AdministratorUpdatesEnabled
reg query "HKLM\SOFTWARE\Policies\Microsoft\VisualStudio\Setup" /v AdministratorUpdatesOptOut
reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\Setup" /v AdministratorUpdatesEnabled
reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\Setup" /v AdministratorUpdatesOptOutWUfB／Intune 経由で受け取りたい場合は、AdministratorUpdatesEnabled が 2 になっているか、OptOut が 1 になっていないかを最優先で確認すると切り分けが早いです。
AdministratorUpdatesEnabled の値で挙動が変わる点に注意
「管理者更新を有効にしたはずなのに、Intune／WUfB だと更新が来ない」というケースでありがちなのが、AdministratorUpdatesEnabled の値です。Microsoft Learn のポリシー表では、値 1 は WSUS／SCCM 向け、値 2 が WSUS／SCCM と WUfB／Intune の両方に対応する推奨値として説明されています。
“更新パッケージ”と“実体のバイナリ”は別に動く
管理者更新のパッケージ自体は Windows Update 側で検出されますが、実際の更新バイナリは Visual Studio Installer が取得します。端末がインターネットから更新する構成なのか、社内のレイアウト（ネットワークインストール）から更新する構成なのかで、必要な疎通・権限が変わります。
機能更新（17.12→17.13 など）まで自動化したい場合の選択肢
結論として、機能更新まで含めるなら WUfB だけでは完結しません。とはいえ「毎回手作業」しかないわけではなく、組織の管理基盤に合わせて現実的なルートがあります。
| 選択肢 | 17.12→17.13 のようなマイナーバージョン更新 | 向いている組織 | ポイント |
|---|---|---|---|
| SCCM（MECM）で Update Catalog から Feature Pack を取り込んで配布 | 可能 | オンプレ管理が強い、承認フローを重視 | Feature Pack はカタログ提供。WSUS 既定同期だけでは入らないため “取り込み” が前提 |
| Microsoft Update Catalog から入手して、レイアウト更新→クライアント更新 | 可能 | 閉域／プロキシ環境、オフライン端末が多い | レイアウトを最新化し、クライアントの更新ソースをレイアウトに固定しておくと運用しやすい |
| Visual Studio Installer を SYSTEM で実行（スクリプト／配布ツール） | 可能 | Intune 中心だが、アプリ配布やスクリプト運用に慣れている | 検証リング＋実行タイミング制御が重要（業務時間に IDE が閉じていないと失敗しやすい） |
SCCM 取り込みが堅い理由
Visual Studio の Feature Pack（機能更新）や Quality update は、Microsoft Update Catalog から入手でき、必要に応じて Configuration Manager に取り込んで配布できる、という建て付けです。WSUS 側に「自動で降ってくる」更新だけを見ていると、機能更新が見えないのはこのためです。
レイアウト（ネットワークインストール）を前提にすると、機能更新の“再現性”が上がる
大規模環境では「どのバージョンを標準にするか」を決めたうえで、レイアウトをそのバージョンに更新し、クライアントはそのレイアウトからのみ更新するように統一すると、端末ごとのバージョンばらつきが起きにくくなります。特に閉域環境では必須に近い運用です。
Intune 中心なら「セキュリティは WUfB、機能更新はアプリ配布」で割り切る
Intune でできるのは WUfB だけではありません。機能更新は Win32 アプリ配布やスクリプト配布で Visual Studio Installer を実行し、更新リング（パイロット→本番）を回す設計にすると、クラウド完結でも管理可能です。ポイントは「IDE を閉じる運用」と「失敗時の再実行」です。
よくある落とし穴と、先回りの対策
- WUfB の “Feature updates” は Windows の機能更新の話で、Visual Studio の機能更新ではない：用語が同じで混同しやすいですが、Visual Studio の 17.x を上げる話は別ルートになります。
- AdministratorUpdatesEnabled=1 のまま：WSUS／SCCM 向けの設定で止まっていると、WUfB で受け取れる状態になりません（Intune を狙うなら推奨値 2）。
- “他の Microsoft 製品の更新も受け取る” が無効：Windows Update の設定として無効だと、Visual Studio の管理者更新が流れてきません。
- AdministratorUpdatesOptOut が 1：ユーザー側の OptOut が優先され、IT 側が有効化してもブロックされます。
- Visual Studio が開きっぱなし：更新は中断／失敗します。閉じる通知やメンテナンス時間の設計が重要です。
- SYSTEM がレイアウト共有にアクセスできない：端末側の “人” ではなく SYSTEM が取得する点が落とし穴。共有権限やプロキシ例外を見直します。
更新が入ったか確認する方法
管理者更新が適用されたかどうかは、まず Visual Studio の [ヘルプ]→[バージョン情報] でビルド番号を確認するのが確実です。更新タイトルに含まれるバージョン番号と一致しているかを見ます。併せて、vswhere を使って複数インスタンスのバージョンを列挙する運用も有効です。
将来、WUfB で機能更新が配信される可能性は？
少なくとも 2025 年 2 月の Microsoft Q&A では、WUfB でバージョン更新（機能更新）を配る計画について「今のところ把握していない」と回答されています。将来の確約を取りたい場合は、Developer Community でチケットを起票して製品チームに確認するのが安全です。
なお、Visual Studio 2022 の管理者更新に関する KB には、2027 年 2 月以降「セキュリティ更新に最終の Feature Pack を含める」といった注記もあります。これは通常の月次運用で “常に 17.x を上げていく” という意味ではなく、サポートライフサイクルの都合で例外的な取り扱いが入る可能性を示唆するもの、と捉えるのが無難です。運用方針を決める際は、公式ドキュメントの最新記述を定期的に確認してください。
まとめ
- Intune／WUfB（Microsoft Update）で自動配信される Visual Studio 2022 の管理者更新は、現時点ではセキュリティ更新のみ。
- 17.12.x のようなサービシング更新は進むが、17.12→17.13 のような機能更新（マイナーバージョン更新）は WUfB では配られない。
- 機能更新まで組織で自動化したいなら、Update Catalog／SCCM 取り込み／レイアウト更新／Installer 実行のいずれかを別レーンで設計する。
コメント