Visual Studioで開発している最中に、Visual Studio Launcher / Visual Studio Installerが突然「Sorry, something went wrong」と表示され、起動できなくなることがあります。再インストールを急ぐ前に、まずはInstaller側の破損を疑って“入れ直し”を行うと、Visual Studio本体に触れず短時間で復旧できるケースがあります。
症状を整理：どこが起動できないのか
「起動できない」といっても、止まっているのがVisual Studio本体（devenv.exe）なのか、Visual Studio Installer（インストーラー）なのかで、対処は大きく変わります。今回のようにエラー文言が「Sorry, something went wrong」で、しかもLauncher/Installerが立ち上がらない場合は、VS本体よりもセットアップ基盤（Installer側）の不整合を最優先で疑うのが近道です。
| よくある見え方 | まず疑う範囲 | 理由（目安） |
|---|---|---|
| Visual Studio Installerを開こうとすると「Sorry, something went wrong」 | Installer本体の破損/更新失敗 | Workload変更や更新に使う実体が起動できない |
| Visual Studioの起動時にLauncherが落ち、Installerも開けない | Launcher→Installer連携の破損 | 起動導線がInstaller側の状態に依存する |
| VS本体は起動するが「変更/修復」ができない | Installerのみ障害 | IDEは動くがメンテができない |
| VS本体も起動せずクラッシュ/例外が出る | 拡張機能/キャッシュ/コンポーネント | Installer以外の切り分けも必要 |
結論：まずはVisual Studio Installerを“入れ直す”
結論から言うと、今回のタイプはVisual Studio本体ではなく「Visual Studio Installer（インストーラー）」側の破損・不整合が原因になっている可能性が高いです。したがって、最初に行うべき対処はVS Installerの再インストール（入れ直し）です。
ポイントは、Visual Studio本体（インストール済みのIDEやWorkload）を消さずに、管理ツールだけを再構築すること。Installerが正常化すれば、更新・修復・Workload追加が再び可能になり、結果としてLauncher経由の起動も復旧することがあります。
最短で効く手順：Installerフォルダーを退避して再インストール
以下は、復旧事例が多い“まず効く”手順です。やっていることはシンプルで、壊れている可能性があるInstallerのフォルダーを退避し、新しいセットアップ（ブートストラップ）でInstallerだけを入れ直すという流れです。
作業前のチェック（失敗しやすいポイントを潰す）
- Visual StudioとInstaller関連プロセスを終了（バックグラウンドで残っているとリネームが失敗します）
- 管理者権限が使えるアカウントで実施（企業PCで制限がある場合は情シスへ）
- VPN/プロキシ切り替え直後なら、ネットワークを安定させてから（社内Wi‑Fi⇔テザリング切替などで失敗しがち）
プロセスが残っていそうな場合は、タスクマネージャーで以下を終了します。
- Visual Studio（devenv.exe）
- Visual Studio Installer（vs_installer.exe）
- setup関連（例：vs_setup_bootstrapper.exe など環境により名称は異なります）
手順
| 手順 | 操作 | 狙い / 注意点 |
|---|---|---|
| 1 | C:\Program Files (x86)\Microsoft Visual Studio\Installerへ移動 | Installer実体が入っている標準パスです |
| 2 | フォルダー名をInstaller→Installer_backupにリネーム（退避） | 破損している可能性があるファイル群を“残したまま”切り離します |
| 3 | 新しいVisual Studioのセットアップ（ブートストラップ）を入手し、空のフォルダーへ配置 | Community/Professional/Enterpriseなど、使っているエディションに合うものを選びます |
| 4 | セットアップを管理者として実行 | Installerが再インストールされます（通常、VS本体はそのまま） |
| 5 | Installer/Launcherの起動を再確認 | 起動できたら、必要なら「修復」や「更新」を実行します |
なぜ「リネームして退避」が効くのか
Installerが壊れている場合、単に再実行しても同じ壊れた実体を読み続けるため、起動エラーが繰り返されます。フォルダーをリネームして退避すると、セットアップは“Installerが存在しない”状態として扱い、必要なファイルを新規に展開し直します。
また、削除ではなく退避なので、万一うまくいかなかった場合でも元に戻しやすいのが利点です（フォルダー名を戻すだけ）。
ブートストラップ入手のコツ
- 入手先は「Visual Studioの公式ダウンロードページ」からが安全です。
- 社内ネットワークでダウンロードが不安定なら、別回線で取得して持ち込むなど、まず実行ファイルを確保してから作業するとスムーズです。
- 複数バージョンが共存している環境は、基本的に一番新しい世代（例：2022）のブートストラップでInstallerが更新されることが多いですが、運用ポリシーがある場合は組織のルールに従ってください。
入れ直し後に確認するポイント
Installerが起動できるようになったら、次の観点で状態をチェックします。
| 確認項目 | 期待される状態 | 補足 |
|---|---|---|
| Visual Studio Installerが起動する | 「インストール済み」一覧が表示される | ここまで来れば“管理基盤”は復旧傾向 |
| 更新の確認ができる | 更新チェックが進み、必要なら更新が提示される | ネットワーク制限があると失敗することがあります |
| 「修復」が実行できる | 対象インスタンスに対して修復が走る | IDE起動不良も併発しているなら有効 |
| Workloadの変更ができる | 追加/削除が開始できる | 壊れていたのがInstallerならここが改善します |
まだ直らない場合：追加チェックで“どこが壊れているか”を切り分ける
Installerの入れ直しで改善しない場合は、Installer自体の破損以外に、.NETの設定破損、一時ファイル、セキュリティ/ネットワーク、Windowsのシステム整合性などが絡んでいることがあります。ここからは「原因の当たり」を付けるための切り分けです。
まずはログを集める（再現条件を固定する）
エラーが再現する状態で、できる限りログの保存をしておくと、後戻りが楽になります。一般的にセットアップ関連は以下の場所にログが出ます（環境により差があります）。
| 場所（例） | ログの種類 | 見るポイント |
|---|---|---|
%TEMP%配下 | dd_setup_*.log / dd_bootstrapper_*.log など | Error/Exception、通信失敗、パッケージ展開失敗 |
C:\ProgramData\Microsoft\VisualStudio配下 | キャッシュ/状態情報（構成により） | 権限不足や破損があると挙動が不安定になります |
| Installerが起動できる場合 | 「ログの収集」機能（vslogs.zip等） | まとめて採取でき、問い合わせにも使えます |
ログの読み方に迷ったら、まずは次のキーワードで検索すると、当たりを付けやすくなります。
Exception/Fatal/ERRORAccess is denied（権限）proxy/certificate/SSL（ネットワーク/証明書）machine.config/ConfigurationErrorsException（.NET設定）
.NETのmachine.configを疑う：壊れた構成でInstallerが落ちるケース
Visual Studio InstallerはWindows上で.NETを利用して動作する場面があるため、.NETのグローバル設定が壊れていると、Installerが起動直後に例外で落ちることがあります。ログにmachine.configが登場する場合は、この切り分けが有効です。
差し替え手順（例：Framework64の場合）
- 対象パス：
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config - 作業前に必ずバックアップを取ります（復旧できなくなると他アプリにも影響します）。
| 手順 | 操作 | 注意点 |
|---|---|---|
| 1 | machine.configをmachine.config.backupなどにリネーム | 元に戻せるように必ず退避 |
| 2 | machine.config.defaultをコピーし、machine.configとして配置 | 既定値へ戻すイメージ |
| 3 | 再起動後、Installer起動を再確認 | キャッシュが残る環境では再起動推奨 |
「Framework64」だけでなく、環境によっては「Framework（32bit）」側が参照されることもあります。ただし、むやみに両方を触ると影響範囲が広がるので、ログに出ている方から優先して切り分けるのが安全です。
一時フォルダー（Temp）を再生成する：壊れた一時ファイルの影響を排除
Installerはダウンロードや展開で一時フォルダーを多用します。Temp配下の壊れたファイル、権限の崩れ、セキュリティソフトによる隔離があると、起動や更新が不安定になります。次の手順で、Tempを“きれいな状態”に戻して切り分けできます。
手順
- PCを再起動（ロック中の一時ファイルを解放）
C:\Users\username\AppData\Local\TempをTemp_backupにリネーム- 再度Installerを起動（必要なTempが自動生成されます）
Tempを丸ごと削除せずリネームにするのは、もし別の作業で必要なファイルが残っていた場合でも戻せるようにするためです。容量が大きい場合は、まずリネームできるか（ロックされていないか）だけ確認しても十分な切り分けになります。
セキュリティ/ネットワーク要因：更新・認証・通信をブロックしていないか
昼休憩のタイミングで急に発生する場合、社内ネットワークの切替（有線→Wi‑Fi、VPN接続/切断、プロキシの自動構成）や、セキュリティ製品の定義更新・ポリシー適用がトリガーになっていることがあります。Installerは更新確認やパッケージ取得で通信するため、ここがブロックされると不具合が表面化します。
| 疑う要因 | 起きやすい症状 | 簡易テスト |
|---|---|---|
| プロキシ/SSLインスペクション | 更新確認で失敗、起動直後に落ちる | 社外回線（テザリング等）で起動を試す |
| ウイルス対策/EDR | Installerフォルダーのファイルが隔離・ブロック | 一時的に保護を緩める/例外設定（可能な範囲で） |
| グループポリシー | ProgramDataやTempへの書き込みが拒否 | イベントログ/セキュリティログで拒否痕跡を確認 |
| 証明書ストアの不整合 | HTTPS通信で失敗（SSL関連エラー） | Windows Updateの状態や証明書更新状況を確認 |
企業環境では、ユーザー側で無効化できない保護機構もあります。無理に回避しようとせず、「Installerが起動しない」「通信が失敗する」という事実とログを添えて、管理者に相談するのが最短ルートになることも多いです。
Windowsのシステム修復：DISM / SFCで土台を整える
.NETやシステムファイルの破損が疑われる場合は、Windows標準の整合性チェックが有効です。特に、過去に強制終了やストレージ障害があった場合、InstallerだけでなくOS側のファイル破損が残っていることがあります。
管理者のコマンドプロンプト（または管理者PowerShell）で、次を順番に実行します。
DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow| コマンド | 役割 | 終わったら |
|---|---|---|
DISM.exe /Online /Cleanup-image /Restorehealth | コンポーネントストア（Windowsの部品倉庫）を修復 | 完了後に再起動すると安定します |
sfc /scannow | システムファイルを検証し、不整合を修復 | 結果に「修復できない」が出たらログ確認 |
どうしても復旧しない場合の選択肢（影響が大きい順に注意）
ここまで試しても改善しない場合は、症状が「Installerの破損」ではなく、別の層（ユーザープロファイル、権限、VSインスタンス、ストレージ）にある可能性が高まります。次の手は影響が大きくなりやすいので、必要性とリスクを見ながら進めてください。
別ユーザーでの起動確認（ユーザープロファイル切り分け）
同じPCでも、別のWindowsユーザーでInstallerが起動するなら、原因はユーザープロファイル（AppData/Temp/権限）に寄っている可能性があります。新しいローカルユーザーを作れる環境なら、ここで切り分けができます。
Installerの強力なクリーンアップ（最終手段）
Visual Studioにはインストール状態を強制的にクリーンアップするツールが付属していることがあります。ただし、これはインストール済みのVisual Studio自体を消す方向に働くため、プロジェクト環境やWorkloadを作り直す覚悟が必要です。
- 例：
InstallCleanup.exe（存在場所は環境/バージョンで異なります） - 実行するなら、事前に必要なWorkload/コンポーネント、SDK、証明書などを記録しておく
- 可能なら、まずは「Installerの入れ直し」や「修復」で済ませる
再発防止：Installerトラブルを起こしにくくする運用Tips
Installerは「更新・追加・削除」を扱う都合上、途中で止まると壊れやすい領域でもあります。日々の運用で次を意識すると、再発確率を下げられます。
| ポイント | 具体例 | 狙い |
|---|---|---|
| 更新中に中断しない | Windows再起動やシャットダウンを急がない | 更新途中の破損を防ぐ |
| ディスク容量を確保 | システムドライブに十分な空き（数十GB目安） | 展開失敗・キャッシュ破損を防ぐ |
| ネットワークを安定させる | VPN切替直後は更新を避ける | 途中で通信が途切れるリスク低減 |
| セキュリティ製品の影響を把握 | 隔離ログやブロック履歴を確認 | 「突然壊れた」を説明できる材料になる |
| 構成を記録しておく | 導入WorkloadやSDKバージョンをメモ | 最悪の再インストールでも復旧が早い |
まとめ：VSが壊れたと決めつけず、Installerを最初に疑う
Visual Studio Launcher / Visual Studio Installerが「Sorry, something went wrong」で起動できないときは、IDEそのものよりもInstaller側の破損・不整合が原因になっていることがあります。まずはInstallerフォルダーを退避→ブートストラップを管理者実行して入れ直しを試し、それでもダメならmachine.configやTemp、セキュリティ/ネットワーク、DISM/SFCの順に切り分けるのが効率的です。
原因がInstallerに寄っているケースほど、復旧は意外と短く済みます。焦って全消しする前に、まずは“管理ツールの再構築”から着手してみてください。
コメント