Visual StudioのWorkloadsとComponentsを変更する方法｜2026年4月更新ポイント

Visual Studioの開発環境を軽くしたい、チーム全員のワークロードをそろえたい、不要なコンポーネントを安全に外したい――そんな場合に見るべき公式ドキュメントが「Modify Visual Studio workloads, components, and language packs」です。

2026年4月24日のMicrosoft公式リポジトリ上の更新は、本文手順が大きく変わるアップデートというより、ドキュメント管理用メタデータの整理が中心です。実務上の重要ポイントは変わらず、Visual Studio InstallerからWorkloads、Individual components、Language packsを追加・削除し、チーム運用では.vsconfigや管理ポリシーを併用することです。特にdevelopers、DevOps engineers、platform teamsは、個人端末の調整だけでなく、再現性のある開発環境管理として捉える必要があります。(GitHub)

Visual Studioの最新動向: Modify Visual Studio Workloads and Componentsで何が変わったか

Microsoft Learnの「Modify Visual Studio workloads, components, and language packs」は、Visual Studioを必要な機能だけに調整するための公式手順をまとめたページです。対象は、Visual Studio Installerを使って既存のVisual Studioインストールを変更するケースです。(Microsoft Learn)

2026年4月24日のGitHub履歴を見ると、同ページに対して2件のコミットがありました。内容は「ownership updates for bill」と「removing metadata that’s automatically inserted by the docfx file」で、該当ファイルでは管理者メタデータやms.subserviceなどのドキュメント管理情報が更新されています。つまり、Visual Studio Installerの操作手順そのものが全面的に変わったわけではありません。(GitHub)

一方で、このページが改めて押さえる価値が高いのは、Visual Studio 2026世代も含め、開発環境の構成管理がより重要になっているためです。Visual Studioは「全部入り」で入れるより、プロジェクトに必要なWorkloadsとComponentsだけを選ぶほうが、ディスク容量、更新時間、トラブル調査、セキュリティ管理の面で扱いやすくなります。

今回の更新ポイントは「機能追加」ではなく「運用確認」の意味が大きい

今回の更新を読むうえで誤解しやすい点は、「2026年4月24日にVisual Studioの新機能が追加された」と受け取ってしまうことです。公式ページの本文で説明されている中心内容は、従来どおり以下の操作です。

確認ポイント	内容	実務での意味
Workloadsの変更	開発対象に応じた機能セットを追加・削除	.NET、C++、Web、デスクトップなど用途別に環境を整理できる
Individual componentsの変更	SDK、ツール、ライブラリなどを個別に選択	特定のビルド要件やCI環境に合わせて細かく調整できる
Language packsの変更	Visual Studioの表示言語を変更	グローバルチームや日本語・英語混在環境で役立つ
管理者権限の確認	インストール、更新、変更には原則として管理者権限が必要	企業端末では権限設計が必要
`.vsconfig`の活用	構成ファイルでインストール内容を共有	チーム内の環境差を減らせる

公式ドキュメントでは、Visual Studio Installerを開き、対象のVisual Studioインスタンスを選んで「Modify」から変更する流れが説明されています。また、Workloadsタブで大枠を選び、Individual componentsタブで追加コンポーネントを選択できるとされています。(Microsoft Learn)

Visual Studio WorkloadsとComponentsの違い

Visual Studioの構成変更でまず理解すべきなのは、WorkloadsとComponentsは粒度が違うという点です。

Workloadsは、開発目的ごとのまとまった機能セットです。たとえば、Web開発、デスクトップ開発、C++開発、ゲーム開発のように、特定の開発シナリオに必要なツール群をまとめて選べます。公式ドキュメントでも、Workloadsは使用するプログラミング言語やプラットフォームに必要なコンポーネントを含むものとして説明されています。(Microsoft Learn)

Componentsは、SDK、ランタイム、ビルドツール、言語ツールなどを個別に選ぶ単位です。Workloadだけでは不足するものを追加したり、逆に不要なものを外したりする場合に使います。

項目	Workloads	Individual components
粒度	大きい	細かい
主な用途	開発目的に応じた一括選択	SDKやツールを個別に追加
向いている人	初心者、一般的な開発者	DevOps、ビルド担当、上級者
失敗しやすい点	不要なものまで入りやすい	必要な依存関係を見落としやすい

初心者はまずWorkloadsで必要な開発領域を選び、ビルドエラーやチーム要件に応じてIndividual componentsを追加するのが現実的です。最初からComponentsだけで細かく選ぶと、必要なSDKやビルドツールを見落としやすくなります。

Visual Studio InstallerでWorkloadsとComponentsを変更する手順

Visual Studioの構成変更は、基本的にVisual Studio Installerから行います。公式ページでは、スタートメニューからVisual Studio Installerを検索する方法、C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exeを実行する方法、Visual Studio上の「Tools > Get Tools and Features」から開く方法が紹介されています。(Microsoft Learn)

基本手順

手順	操作	注意点
1	Visual Studio Installerを起動	必要に応じてInstaller自体の更新が求められる
2	変更したいVisual Studioを選ぶ	複数バージョンや複数Editionがある場合は取り違えに注意
3	「Modify」を選択	更新ではなく構成変更を行う
4	Workloadsタブで必要な項目を選択	開発対象に必要なものだけ選ぶ
5	Individual componentsタブで不足分を追加	SDK、Build Tools、言語関連を確認
6	インストール方式を選ぶ	通常は「Install while downloading」でよい
7	「Modify」を実行	Visual Studioを閉じてから実行すると失敗しにくい

Visual Studio Installerでは、既定の「Install while downloading」と、事前にまとめてダウンロードしてからインストールする「Download all, then install」を選べます。ネットワークが不安定な環境や社内配布では、後者のほうが失敗しにくい場合があります。(Microsoft Learn)

どのWorkloadを選ぶべきかの判断基準

Workload選びでよくある失敗は、「念のため全部入れる」ことです。全部入りは一見安心ですが、更新時間が長くなり、ディスク消費も増えます。さらに、不要なSDKや古いコンポーネントが残ると、ビルドやセキュリティ管理の確認範囲も広がります。

開発者個人であれば、現在担当しているプロジェクトに必要なWorkloadから選びます。チームやプラットフォーム担当であれば、リポジトリ単位で必要なWorkloadとComponentsを定義し、.vsconfigとして共有するのが有効です。

利用シーン	選び方の目安	補足
.NETアプリ開発	.NET関連のWorkloadを中心に選ぶ	対象フレームワークのSDKを確認
C++開発	C++関連WorkloadとMSVC、Windows SDKを確認	プロジェクトで使うツールセットのバージョンに注意
Web開発	ASP.NET、Web関連ツールを選ぶ	Node.jsやブラウザ連携が必要か確認
CI/CD用ビルド環境	IDEではなくBuild Tools中心に検討	GUI操作よりコマンドライン管理が向く
グローバルチーム	Language packsを含めて設計	英語UIを標準にするか、日本語UIを許可するか決める

Visual StudioのWorkloadとComponent IDは、公式の一覧ページで確認できます。コマンドラインや.vsconfigを使う場合は、表示名ではなくIDを正しく指定する必要があります。(Microsoft Learn)

Language packsの変更はグローバルチームで重要

Visual Studio Installerは、既定ではOSの言語に一致するLanguage packを選択します。公式ドキュメントでは、Language packsタブから希望する言語を選べると説明されています。(Microsoft Learn)

日本語環境では日本語UIのほうが使いやすい場面もありますが、グローバルな開発チームでは英語UIのほうがトラブルシューティングしやすい場合があります。エラーメッセージ、メニュー名、拡張機能の説明、海外ドキュメントとの照合がしやすくなるためです。

特にDevOps engineersやplatform teamsは、個人の好みだけでなく、サポート効率を考えて標準言語を決めるとよいでしょう。

方針	向いている環境	注意点
日本語UIを標準にする	国内メンバー中心、初心者が多い	英語情報との照合に時間がかかる場合がある
英語UIを標準にする	グローバルチーム、OSS開発、海外サポート利用	日本語メンバーへのオンボーディング資料が必要
複数言語を許可する	個人裁量が大きいチーム	問い合わせ時に画面名がずれやすい

管理者権限とAllowStandardUserControlを確認する

Visual Studioのインストール、更新、変更は、既定では管理者権限が必要です。公式ドキュメントでも、操作を行うアカウントには管理者権限と、更新元にアクセスする権限が必要だと説明されています。通常ユーザーで操作した場合は、管理者資格情報を求めるUser Account Controlが表示されます。(Microsoft Learn)

企業端末では、開発者にローカル管理者権限を付与しない方針も珍しくありません。その場合は、Visual Studioの管理ポリシーを使って標準ユーザーにどこまで操作を許可するかを決める必要があります。

Microsoftのポリシー説明では、AllowStandardUserControlを使うことで、管理者権限を持たないユーザーにVisual Studio Installer上の操作を許可できるとされています。値が1の場合は手動の更新やロールバック、値が2の場合はModifyやAvailableタブからのInstallを含むInstaller UIの機能を使えると説明されています。ただし、標準ユーザーは--passiveや--quietを使ったInstallerコマンドを実行できない点に注意が必要です。(Microsoft Learn)

権限設計の判断基準

チーム状況	推奨方針
少人数で端末管理が緩い	開発者が必要時にInstallerでModifyできる運用でもよい
企業端末で統制が必要	Intune、Group Policy、管理ポリシーで制御する
CI/CDやビルド端末	個人操作ではなくスクリプトや`.vsconfig`で固定する
セキュリティ要件が高い	不要コンポーネントの削除、更新チャネル、ロールバック可否も管理する

開発者の生産性だけを考えると自由に変更できるほうが便利です。しかし、プラットフォームチームの視点では、誰が何を入れたか分からない状態は再現性を下げます。権限を付与する場合でも、.vsconfigや社内手順書で標準構成を明文化しておくべきです。

`.vsconfig`でVisual Studio構成をチーム標準化する

今回の公式ページでも、既存のVisual StudioインストールにComponentsを追加・削除する方法として、構成ファイルを使えることが案内されています。より詳しい公式ページでは、Visual Studio Installerを使ってWorkloads、Components、Marketplace extensionsの情報を.vsconfigとしてエクスポートでき、既存または新規のVisual Studioインストールにインポートできると説明されています。(Microsoft Learn)

.vsconfigは、チーム開発で非常に有効です。たとえば、新しいメンバーが参加したときに「このWorkloadを入れて、このSDKも入れて」と口頭やWikiで説明するのではなく、リポジトリに.vsconfigを置いておけば、必要なコンポーネントの検出とインストールを促せます。

公式ドキュメントでは、.vsconfigをソリューションルートに保存してソリューションを開くと、Visual Studioが不足コンポーネントを検出し、インストールを促すことが説明されています。(Microsoft Learn)

`.vsconfig`の基本例

{
  "version": "1.0",
  "components": [
    "Microsoft.VisualStudio.Component.CoreEditor",
    "Microsoft.VisualStudio.Workload.CoreEditor",
    "Microsoft.VisualStudio.Component.NuGet"
  ]
}

このように、.vsconfigはJSON形式でComponentsを列挙します。実務では、まず代表的な開発端末で必要なWorkloadsとComponentsを選び、Visual Studio InstallerからExport configurationを実行して、出力された.vsconfigをレビューするのが安全です。

`.vsconfig`を使うべき場面

場面	効果
新メンバーのオンボーディング	セットアップ手順のばらつきを減らせる
複数プロジェクトを並行開発	プロジェクトごとに必要な構成を分けられる
CI/CD環境の再構築	ビルドに必要なComponentsを明示できる
グローバルチーム	口頭説明に頼らず構成を共有できる
監査・セキュリティ対応	不要なコンポーネントを減らす根拠になる

コマンドラインでModifyする場合の注意点

DevOps engineersやplatform teamsは、GUIよりもコマンドラインでVisual Studioの構成を管理したい場面があります。Microsoft Learnでは、Visual Studio Installerのsetup.exeは通常C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exeにあり、modify、update、repair、uninstall、exportなどのコマンドを利用できると説明されています。(Microsoft Learn)

たとえば、既存インストールに.vsconfigを使って構成を追加する場合は、次のような考え方になります。

"C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe" modify `
  --installPath "C:\Program Files\Microsoft Visual Studio\2022\Professional" `
  --config "C:\myconfig.vsconfig" `
  --passive

公式ドキュメントでは、既存インストールに.vsconfigでComponentsを追加する場合、updateではなくmodifyを使う必要があると説明されています。updateは既に入っているComponentsを最新化する操作であり、構成ファイルに書かれた未インストール項目を追加する目的には適していません。(Microsoft Learn)

また、コマンドラインで複数のWorkloadsやComponentsを指定する場合は、--addや--removeを項目ごとに繰り返す必要があります。--configは追加専用の動作で、構成ファイルに書かれていない項目を削除するものではない点にも注意が必要です。(Microsoft Learn)

オフライン環境・ネットワークレイアウトでは更新元を意識する

社内ネットワーク、閉域環境、インターネット接続が制限された開発端末では、Visual Studio InstallerのModify操作も単純ではありません。公式のModifyページでも、手順はインターネット接続がある前提で書かれており、オフラインインストール済み環境を変更する場合はネットワークベースのインストール更新や更新制御のドキュメントを参照するよう案内されています。(Microsoft Learn)

ネットワークレイアウトからインストールされたVisual Studioでは、更新元がMicrosoft hosted serversなのか、社内レイアウトなのかを確認する必要があります。公式ドキュメントでは、レイアウトからインストールされた管理環境では、更新元、レイアウトの更新状況、手動更新か管理者主導かを確認することが重要だと説明されています。(Microsoft Learn)

特に大規模チームでは、以下を決めておくと運用が安定します。

項目	決めるべきこと
更新元	Microsoft公開サーバーか、社内レイアウトか
更新タイミング	毎月のセキュリティ更新後に反映するか
対象端末	開発者PC、ビルドサーバー、検証環境を分けるか
権限	開発者が手動Modifyできるか、管理者のみか
ロールバック	更新失敗時の戻し方を許可するか

Visual Studioの構成変更は、個人端末では数クリックの作業ですが、組織では更新元、権限、セキュリティ、再現性が絡む運用課題になります。

不要なComponentsを削除する前に確認すべきこと

Visual Studioを軽量化したい場合、不要なWorkloadsやComponentsを削除するのは有効です。ただし、削除前にはプロジェクト単位で依存関係を確認する必要があります。

特にC++、Windows SDK、.NET SDK、テストツール、NuGet関連、MSBuild関連は、IDE上では使っていないように見えてもビルドに必要な場合があります。削除後に初めてCIやリリースビルドが失敗することもあります。

削除前チェックリスト

確認項目	理由
ソリューションをローカルでビルドできるか	既存状態の正常性を確認するため
CI/CDで使っているComponent IDを確認したか	ローカルとCIで差が出るのを防ぐため
`.vsconfig`をエクスポートしたか	削除前の構成に戻せるようにするため
Windows SDKやMSVCのバージョンを確認したか	C++やデスクトップアプリで影響が大きいため
チーム内で同じ削除を行う予定があるか	個人だけ違う構成になるのを防ぐため

削除作業は、まず1台の検証端末で行い、対象プロジェクトのビルド、テスト、デバッグ、パッケージ作成まで確認してから展開するのが安全です。

Developers向け: 個人環境では「必要最小限＋復元可能」が基本

個人開発者が意識すべきポイントは、環境を軽くしながらも復元できる状態にしておくことです。

Visual Studioはプロジェクトの種類によって必要なComponentsが大きく変わります。たとえば、普段は.NETアプリしか開発しない人がC++やゲーム開発のWorkloadまで入れていると、更新時間やディスク使用量が増えます。一方で、必要なSDKを外すと突然ビルドできなくなることがあります。

おすすめは、以下の流れです。

手順	内容
1	現在の構成を`.vsconfig`にエクスポート
2	不要と思われるWorkloadを1つずつ外す
3	担当プロジェクトをビルド・テスト
4	問題があればIndividual componentsで不足分を戻す
5	安定した構成を新しい`.vsconfig`として保存

「とりあえず全部外して必要なものだけ戻す」よりも、「1つずつ外して検証する」ほうが失敗しにくいです。

DevOps engineers向け: CI/CDではGUI操作に頼らない

CI/CDやビルドサーバーでは、GUIのVisual Studio Installerで手作業変更する運用は避けるべきです。構成が記録に残りにくく、再構築時に同じ状態を再現できないためです。

DevOps engineersは、.vsconfig、コマンドライン、Build Tools、ネットワークレイアウトを組み合わせて、インストール内容をコードに近い形で管理するのが現実的です。

特に注意したいのは、updateとmodifyの違いです。updateは既存コンポーネントの更新、modifyは構成変更です。.vsconfigで不足コンポーネントを追加したい場合はmodifyを使う必要があります。(Microsoft Learn)

CI/CD環境では、以下のような方針が有効です。

方針	目的
`.vsconfig`をリポジトリ管理する	必要Componentsを明文化する
Build Toolsを優先する	IDE不要のビルド環境を軽量化する
コマンドラインでインストールする	再現性を高める
更新元を固定する	突然のバージョン差を防ぐ
ビルドログにVisual Studio構成を残す	障害調査をしやすくする

Platform teams向け: 標準構成と例外ルールを分ける

Platform teamsが見るべきポイントは、Visual Studioの構成を「個人のセットアップ」ではなく「組織の開発基盤」として扱うことです。

全員に完全に同じ構成を強制すると、不要なものが増えたり、特殊プロジェクトの開発者が困ったりします。一方で、自由にしすぎると環境差による問い合わせが増えます。現実的には、標準構成と例外ルールを分けるのがよいでしょう。

区分	内容
標準構成	ほとんどの開発者が必要とするWorkloadsとComponents
プロジェクト別構成	特定プロジェクトで必要なSDKやツール
例外構成	研究開発、旧バージョン保守、特殊ビルド環境
禁止構成	サポート外、不要、セキュリティ上避けたいComponents

Platform teamsは、標準.vsconfigを配布しつつ、プロジェクトごとの追加.vsconfigを許可すると運用しやすくなります。また、IntuneやGroup Policy、Visual Studio管理ポリシーを利用して、更新、通知、標準ユーザーの操作範囲を設計することも重要です。Microsoft Learnでは、Visual Studioの展開や更新動作をポリシーで制御でき、IntuneのSettings catalogやVisual Studio Administrative Templates、レジストリ値を使えると説明されています。(Microsoft Learn)

よくある失敗と対策

Visual StudioのWorkloadsとComponents変更では、操作自体よりも事前確認不足で失敗することが多くあります。

失敗例	原因	対策
Modify後にビルドできない	SDKやビルドツールを削除した	削除前に`.vsconfig`を保存し、Component IDを確認する
チーム内で動く人と動かない人が出る	各自が違う構成で入れている	リポジトリに`.vsconfig`を置く
企業端末で変更できない	管理者権限がない	管理ポリシーや申請フローを整備する
オフライン端末で追加に失敗する	必要パッケージがレイアウトにない	レイアウト側を先に更新する
更新と構成変更を混同する	`update`でComponents追加を期待した	構成変更には`modify`を使う
言語UIがチーム内でばらつく	Language packsの方針がない	標準UI言語を決める

特に「Visual Studio InstallerでUpdateしたのに必要なComponentが入らない」という問い合わせは起こりやすいです。更新は既存構成の最新化であり、未選択のWorkloadやComponentを自動で追加する操作ではありません。

2026年4月更新を受けて今やるべきこと

今回の更新で新機能を急いで導入する必要はありません。ただし、Visual Studio 2026世代を含む環境移行やチーム標準化を進めるなら、今のうちに構成管理を見直す価値があります。

まず行うべきことは、現在のVisual Studio構成を棚卸しすることです。個人端末ではVisual Studio Installerから不要なWorkloadsを確認し、チームでは代表環境から.vsconfigをエクスポートします。そのうえで、プロジェクトごとに本当に必要なComponentsを整理します。

次に、管理者権限や標準ユーザーの操作範囲を確認します。開発者が自由にModifyできる環境なのか、申請が必要なのか、CI/CDやビルド端末は誰が更新するのかを明確にしておくと、将来のアップデート時に混乱しにくくなります。

最後に、オフライン環境やネットワークレイアウトを使っている組織では、更新元を確認します。Visual Studio本体だけでなく、Installer、レイアウト、チャネル設定、セキュリティ更新のタイミングまで含めて管理することが重要です。

まとめ

「Modify Visual Studio workloads, components, and language packs」の2026年4月24日更新は、本文手順の大幅変更というより、Microsoft公式ドキュメント側の管理情報更新として見るのが正確です。とはいえ、このページが示す内容は、Visual Studio環境を適切に管理するうえで今も重要です。

開発者は、必要なWorkloadsとComponentsだけを入れ、削除前には.vsconfigで復元手段を用意しましょう。DevOps engineersは、GUI操作ではなく.vsconfigとコマンドラインで再現性を高めるべきです。Platform teamsは、標準構成、例外構成、権限、更新元を整理し、Visual Studioを組織の開発基盤として管理する必要があります。

次に取るべき行動はシンプルです。まずVisual Studio Installerを開き、現在のWorkloadsとIndividual componentsを確認してください。そのうえで、チームで必要な構成を.vsconfigとして保存し、不要なコンポーネントを検証しながら減らしていきましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。