Visual StudioをGUIで1台ずつ入れる運用は、開発PCが数台のうちは問題になりにくいものの、CI/CD用ビルドエージェント、VDI、海外拠点の開発端末、標準開発環境の配布ではすぐに限界が来ます。結論から言うと、2026年4月24日に更新履歴が確認できるMicrosoft公式ドキュメント「Use command-line parameters to install, update, and manage Visual Studio」は、新しいインストール機能の大量追加というより、Visual Studioをコマンドラインで導入・更新・保守するための運用整理として読むべき内容です。該当日のGitHub履歴では、本文仕様の大幅変更ではなくドキュメントメタデータ整理が中心であることも確認できます。(GitHub)
この記事では、Visual Studio コマンドラインインストールを実務で使う開発者、DevOpsエンジニア、プラットフォームチーム向けに、どの実行ファイルを使うべきか、--quiet、--layout、--config、--removeOos、wingetをどう使い分けるべきかを整理します。単なるコマンド一覧ではなく、失敗しやすいポイントと運用判断まで含めて解説します。
Visual Studioの最新動向：Use command-line parameters to install Visual Studioで何が変わったか
今回のポイントは、「Visual Studioを手作業で入れる」から「Visual Studioの導入状態をコードとして管理する」方向がより重要になっている点です。
Microsoft Learnの該当ドキュメントは、Visual Studioをコマンドプロンプトやプログラムからインストールする際に、インストール時の選択、更新自動化、ネットワークレイアウトの作成・維持をコマンドラインパラメーターで制御できると説明しています。対象になる実行方法として、ブートストラッパー、既存端末のVisual Studio Installer、winget、Administrator Updateパッケージが整理されています。(Microsoft Learn)
実務で見るべき更新ポイントは、次の4つです。
| 見るべきポイント | 実務上の意味 |
|---|---|
ブートストラッパーとsetup.exeの役割分担 | 新規インストール、更新、変更、レイアウト作成で使う実行ファイルを間違えない |
.vsconfigと--configの活用 | チーム標準のワークロード構成を再現しやすくする |
--layoutによるネットワーク配布 | オフライン環境、社内配布、ビルドエージェント展開に使える |
| wingetとDSCの位置づけ | 既存の端末管理や構成管理にVisual Studioを組み込みやすくする |
注意したいのは、2026年4月24日の履歴だけを見て「新しいインストールコマンドが大量に追加された」と解釈しないことです。該当日の変更はメタデータ整理の性格が強いため、現場では「現在の公式ドキュメントに沿って、インストール自動化の設計を見直すタイミング」と捉えるのが現実的です。
まず押さえるべき実行ファイルの使い分け
Visual Studioのコマンドラインインストールで最初に迷いやすいのが、「どのexeを呼び出すのか」です。ここを誤ると、コマンド自体は正しくても更新対象が見つからない、待機できない、レイアウトを作れないといった問題が起きます。
| 使うもの | 主な用途 | 代表例 |
|---|---|---|
| ブートストラッパー | 新規インストール、ネットワークレイアウト作成、初期導入 | vs_enterprise.exe、vs_professional.exe、vs_community.exe、vs_buildtools.exe |
| Visual Studio Installer | 既存インスタンスの更新、変更、修復、アンインストール | C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe |
| winget | パッケージ管理の流れで導入・変更する | winget install --id Microsoft.VisualStudio.Community |
| Administrator Update | 管理者更新、SCCMやMicrosoft Update Catalog経由の配布 | visualstudioupdate-...exe |
ブートストラッパーは、小さな実行ファイルから必要なパッケージ取得を開始する仕組みです。一方、既にVisual Studioが入っている端末の更新や変更では、インストール済みのVisual Studio Installerを使う場面が多くなります。公式ドキュメントでも、ブートストラッパー、インストーラー、winget、Administrator Updateのすべてで同じパラメーターが使えるわけではないと説明されています。(Microsoft Learn)
判断基準
新規端末にVisual Studioを入れるなら、まずブートストラッパーを選びます。
既存端末のVisual Studioにワークロードを追加する、更新する、修復するなら、setup.exeを使う前提で考えます。
社内の開発標準を大量配布するなら、--layoutでネットワークレイアウトを作るか、wingetや構成管理ツールと組み合わせるのが現実的です。
代表的なコマンドとパラメーターの意味
Visual Studioのコマンドライン操作は、最初の引数に操作内容を表すコマンドを置き、その後に--addや--quietなどのパラメーターを続ける形が基本です。公式ドキュメントでは、modify、update、updateall、repair、uninstall、exportなどのコマンドが整理されています。(Microsoft Learn)
| コマンドまたはパラメーター | 用途 | 実務での使いどころ |
|---|---|---|
modify | 既存インストールの変更 | ワークロード追加、言語パック追加、不要コンポーネント削除 |
update | 指定インスタンスの更新 | 開発PCやビルドエージェントの定期更新 |
updateall | インストール済み製品を順番に更新 | 複数Visual Studio環境の一括更新 |
repair | 修復 | インストーラー破損やコンポーネント欠落時 |
uninstall | アンインストール | 端末返却、標準環境の再構築 |
export | .vsconfigへ構成出力 | チーム標準構成のテンプレート化 |
--add | ワークロードやコンポーネント追加 | .NET desktop、Azure、C++などの追加 |
--config | .vsconfig指定 | 標準構成をファイルで再現 |
--quiet | UIなしで実行 | サイレント展開、CI、MDM配布 |
--passive | 非対話UIで実行 | 進行状況だけ見せたい配布 |
--norestart | 再起動を遅延 | メンテナンス時間帯に再起動を制御 |
--removeOos true | サポート外コンポーネントを削除 | セキュリティ基準の維持 |
--installPath | インストール先指定 | 複数インスタンスや標準パス管理 |
特に重要なのは、複数のワークロードやコンポーネントを指定する場合、--addや--removeをそれぞれ繰り返す必要がある点です。1つの--addにまとめて書けばよい、と考えると意図した構成にならない可能性があります。(Microsoft Learn)
新規インストールを自動化する基本例
例えば、Visual Studio Enterpriseを日本語UI付きでインストールし、.NETデスクトップ開発ワークロードと推奨コンポーネントを含める場合は、次のような形で設計できます。
vs_enterprise.exe ^
--installPath "C:\Program Files\Microsoft Visual Studio\18\Enterprise" ^
--add Microsoft.VisualStudio.Workload.ManagedDesktop ^
--includeRecommended ^
--addProductLang ja-JP ^
--quiet ^
--wait ^
--norestartこの例で重要なのは、--quietだけで終わらせず、必要に応じて--waitと--norestartを組み合わせることです。自動化スクリプトでは、インストール完了を待たずに次の処理へ進むと、ビルドツールがまだ使えない状態でジョブが始まることがあります。
--quietと--passiveの使い分け
| パラメーター | 画面表示 | ユーザー操作 | 向いている場面 |
|---|---|---|---|
--quiet | なし | 不可 | Intune、SCCM、CI、無人展開 |
--passive | 進行状況を表示 | 不可 | 手元端末で進捗だけ見せたい場合 |
| 指定なし | あり | 可 | 個人PCで手動調整したい場合 |
標準ユーザー権限での実行には制約があります。Visual Studio Installer操作では管理者権限が必要になる場面が多く、--quietや--passiveを標準ユーザーがプログラムから使えないケースがあるため、企業配布では権限設計を先に確認しておくべきです。(Microsoft Learn)
.vsconfigでチーム標準構成を配布する
Visual Studio コマンドラインインストールで、チーム運用に最も効くのが.vsconfigです。.vsconfigは、必要なワークロード、コンポーネント、拡張機能などの構成を保存し、別端末で再利用するためのファイルです。
典型的な流れは次の通りです。
| 手順 | 作業 |
|---|---|
| 1 | 代表端末で必要なワークロードを選んでVisual Studioを構成する |
| 2 | インストール構成を.vsconfigとしてエクスポートする |
| 3 | リポジトリ、社内ファイル共有、構成管理基盤に保存する |
| 4 | 新規端末では--configで同じ構成を適用する |
vs_enterprise.exe ^
--installPath "C:\Program Files\Microsoft Visual Studio\18\Enterprise" ^
--config "\\fileserver\dev-standard\visualstudio.vsconfig" ^
--quiet ^
--wait ^
--norestartただし、--configは「追加」操作であり、ファイルに書かれていない既存コンポーネントを削除するものではありません。不要なコンポーネント削除まで自動化したい場合は、modifyと--removeを別途設計する必要があります。公式ドキュメントでも、--configはadditive、つまり追加のみの動作であると説明されています。(Microsoft Learn)
ネットワークレイアウトはオフライン配布だけでなく標準化にも効く
--layoutは、Visual Studioのインストールに必要なファイルを社内共有フォルダーなどにまとめるためのパラメーターです。インターネット接続が制限された環境だけでなく、全開発者に同じ取得元を使わせたい場合にも役立ちます。
vs_enterprise.exe ^
--layout "\\fileserver\vs-layout\2026" ^
--lang ja-JP ^
--add Microsoft.VisualStudio.Workload.ManagedDesktop ^
--includeRecommended ^
--wait--addを指定した場合は、指定したワークロードやコンポーネントとその依存関係だけがレイアウトに取得されます。指定しない場合は、より広い範囲のコンポーネントが対象になり、容量が大きくなります。(Microsoft Learn)
レイアウト運用で使うべきパラメーター
| パラメーター | 用途 | 注意点 |
|---|---|---|
--layout | オフラインキャッシュや社内配布元を作成 | ブートストラッパーで実行する |
--lang | 言語リソースを指定 | 日本語ならja-JP |
--verify | レイアウト内容を検証 | 欠損・破損の確認に使う |
--fix | 欠損・破損ファイルを再取得 | 修復にはインターネット接続が必要 |
--clean | 古いコンポーネントを削除 | 更新後の容量削減に使う |
--noWeb | Webからのパッケージ取得を抑止 | 更新チェック自体を完全に止めるものではない |
--arch all / --arch arm64 | ARMバイナリも含める | Arm端末を管理する場合に検討 |
特に誤解されやすいのが--noWebです。--noWebは、インストールに必要な製品パッケージをWebからダウンロードしないようにする指定ですが、クライアントの更新設定によってはVisual Studio Installerが更新確認を行う可能性があります。完全に社内更新元へ寄せたい場合は、--channelUriや更新ポリシーも合わせて設計する必要があります。(Microsoft Learn)
更新運用ではupdate、modifySettings、--removeOosを分けて考える
Visual Studioの運用では、「最新版にする」だけでは不十分です。どのチャネルから更新するのか、サポート外コンポーネントをどう扱うのか、更新時に推奨コンポーネントを追加するのかを決める必要があります。
既存インスタンスを更新する基本形は次のようになります。
"C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe" update ^
--installPath "C:\Program Files\Microsoft Visual Studio\18\Enterprise" ^
--passive ^
--norestart更新元のチャネルを変更したい場合は、modifySettingsを使います。
"C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe" modifySettings ^
--installPath "C:\Program Files\Microsoft Visual Studio\18\Enterprise" ^
--newChannelUri https://aka.ms/vs/stable.18.0/channel ^
--removeOos true ^
--quiet--removeOos trueは、サポート外になったコンポーネントを削除するための重要なパラメーターです。1回だけ適用する場合と、更新設定として永続的に適用する場合で使い方が変わります。セキュリティ基準を重視する企業環境では、インストール時だけでなくmodifySettingsで継続運用に組み込むことを検討すべきです。(Microsoft Learn)
wingetでVisual Studioを扱うときの注意点
wingetを使うと、Visual Studioを他のアプリケーションと同じようにパッケージ管理の流れに乗せられます。例えばCommunityエディションを導入するだけなら、次のようなコマンドが使えます。
winget install --id Microsoft.VisualStudio.Communityただし、wingetの既定動作ではVisual Studioのコアワークロードだけが入るため、実務で必要なワークロードを追加するには--overrideで.vsconfigや--addを渡す設計が必要です。
winget install --id Microsoft.VisualStudio.Community ^
--override "--passive --config C:\dev-standard\visualstudio.vsconfig"既にVisual Studioが入っている端末へコンポーネントを追加する場合は、wingetのconfigureとVisual Studio PowerShell DSC provider、YAML、.vsconfigを組み合わせる方法が示されています。一方、wingetのupgradeは基本的に更新操作であり、コンポーネント追加には使えません。公式ドキュメントでも、追加にはconfigureを使う必要があると説明されています。(Microsoft Learn)
winget運用で失敗しやすいポイント
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Visual Studioは入ったが必要なワークロードがない | winget既定ではコアワークロード中心 | --overrideで.vsconfigを渡す |
winget upgradeでコンポーネント追加できない | upgradeは更新操作でありmodifyではない | winget configureを検討する |
| 複数SKUを同時展開しようとして失敗する | 同時インストールには制約がある | Enterprise、Professional、Communityを分けて設計する |
| 更新・変更時に失敗する | Visual Studioが起動中 | 配布前にVisual Studio終了を徹底する |
| 権限昇格で止まる | Installer操作に管理者権限が必要 | Intune、SCCM、管理者権限付きスクリプトで配布する |
エラーコードとログ確認まで自動化に組み込む
Visual Studioのコマンドラインインストールでは、成功・失敗が%ERRORLEVEL%に返されます。例えば、0は成功、740は昇格が必要、1003はVisual Studio使用中、1618は別のインストールが実行中、3010は成功したが再起動が必要、などです。公式ドキュメントでは主要なエラーコードと、%TEMP%配下に生成されるログファイルの確認方法が整理されています。(Microsoft Learn)
自動化では、コマンドを実行するだけでなく、終了コードに応じた処理を入れることが重要です。
vs_enterprise.exe --config C:\dev-standard\visualstudio.vsconfig --quiet --wait --norestart
if %ERRORLEVEL% EQU 0 (
echo Visual Studio installation succeeded.
) else if %ERRORLEVEL% EQU 3010 (
echo Visual Studio installation succeeded. Reboot required.
) else (
echo Visual Studio installation failed. ErrorLevel=%ERRORLEVEL%
exit /b %ERRORLEVEL%
)ログ確認では、%TEMP%フォルダー内のdd_bootstrapper、dd_client、dd_setupで始まるファイルを日付順に確認します。CIエージェントやVDI展開では、失敗時にこれらのログを自動収集するようにしておくと、再現調査がかなり楽になります。
開発チーム別のおすすめ運用パターン
Visual Studio コマンドラインインストールは、チーム規模や端末管理の成熟度によって最適解が変わります。
| チーム・環境 | おすすめ構成 | 理由 |
|---|---|---|
| 小規模開発チーム | .vsconfig + ブートストラッパー | 手軽に標準構成を共有できる |
| CI/CDビルドエージェント | --quiet + --wait + 終了コード判定 | 無人実行と失敗検知がしやすい |
| オフライン・閉域環境 | --layout + --verify + --fix | 社内配布元を安定運用できる |
| 大企業の端末配布 | SCCM/Intune + Administrator Update + 更新チャネル管理 | 更新統制と監査に向く |
| グローバル開発組織 | .vsconfig + 言語パック指定 + チャネル統一 | 拠点差を減らせる |
| Arm端末を含む組織 | --arch allまたは--arch arm64を検討 | x64前提のレイアウト漏れを防げる |
独自の観点として、Visual Studioのインストール自動化は「一度入れれば終わり」ではなく、「開発環境のライフサイクル管理」として扱うべきです。初回導入、ワークロード追加、更新、サポート外コンポーネント削除、ログ収集、ロールバック方針までを1セットで設計すると、開発者ごとの環境差を減らせます。
導入前に確認したいチェックリスト
Visual Studioのコマンドラインインストールを本番展開する前に、次の項目を確認しておくと失敗を減らせます。
| 確認項目 | 判断基準 |
|---|---|
| インストール対象 | Enterprise、Professional、Community、Build Toolsのどれか |
| ワークロード | .vsconfigで管理するか、--addで直接指定するか |
| 権限 | 管理者権限で実行できる配布経路か |
| UI | 完全無人なら--quiet、進捗表示なら--passive |
| 再起動 | --norestartを使い、再起動タイミングを別途制御するか |
| 更新チャネル | MicrosoftのStable系か、社内レイアウトか |
| サポート外コンポーネント | --removeOos trueを運用に入れるか |
| ログ | 失敗時にdd_bootstrapper、dd_client、dd_setupを回収できるか |
| レイアウト | --verifyや--fixで定期点検するか |
| バージョン固定 | Release Historyの固定版ブートストラッパーを使う必要があるか |
バージョンを固定して展開したい場合は、Release Historyでチャネル別・バージョン別の固定版ブートストラッパーを確認するのが安全です。Visual Studio 2026のRelease Historyでは、Stableチャネルの各リリースと固定版ブートストラッパーが一覧化されています。(Microsoft Learn)
まとめ：次にやるべきこと
2026年4月更新ポイントとして重要なのは、Visual Studioのコマンドラインインストールを単なる便利コマンドではなく、開発環境の標準化・自動化・更新統制の仕組みとして扱うことです。
まずは代表端末で必要なワークロードを決め、.vsconfigを作成します。次に、ブートストラッパーで新規インストールするのか、setup.exeで既存環境を変更するのか、wingetやAdministrator Updateを使うのかを分けて設計します。そのうえで、--quiet、--wait、--norestart、--removeOos true、終了コード判定、ログ回収までをスクリプトに組み込めば、Visual Studioの導入と更新はかなり安定します。
特にDevOpsエンジニアやプラットフォームチームは、この記事をきっかけに「Visual Studioをどう入れるか」ではなく、「Visual Studio環境をどう継続管理するか」へ視点を切り替えるとよいでしょう。
コメント