UnityでC#スクリプトを開いた瞬間、Visual Studioが「Target framework not installed」と表示してAssembly-CSharpが読み込めない。さらに「Unable to locate Visual Studio Installer」まで出て修復すらできない――そんな“連鎖崩壊”は、Program Filesの参照先がレジストリでずれていると起きがちです。この記事では原因の見分け方と直し方を、チェック項目付きでまとめます。
起きている現象を整理：Unity→Visual Studioで「連鎖的に壊れて見える」症状
今回のトラブルは、Unity側というよりWindowsとVisual Studio側の「参照先のパス解決」が破綻している時に典型的に起きます。まずは症状を整理して、どこが壊れているかの当たりを付けましょう。
| 症状 | 見えているエラー例 | 疑うべきポイント |
|---|---|---|
| UnityのC#スクリプトをダブルクリック→Visual Studioが開くがプロジェクトが壊れている | 「Target framework not installed」／「Load failed」／Assembly-CSharp が読み込めない | .NETのランタイムではなくターゲティングパック（参照アセンブリ）、または参照先パスの破綻 |
| Visual Studioから「Get Tools and Features…」が開けない | 「Unable to locate Visual Studio Installer」 | Visual Studio Installer の実体パスをOS/VSが見失っている |
| Windowsの「アプリと機能」→Visual Studio→「変更（Modify）」が失敗 | 存在しないパス例：D:\Microsoft Visual Studio\Installer\setup.exe を探す | Windows側の既定Program Files参照（レジストリ）が別ドライブを指している可能性が高い |
ポイントは、「.NET Framework 4.8は入れているのに未インストール扱い」という矛盾です。ここを正しく理解すると、最短で直せます。
結論：原因は「.NETが無い」ではなく「Windowsが参照すべき場所を間違えている」
Visual Studioが「Target framework not installed」を出すと、つい「.NET Frameworkを再インストールしよう」となりがちです。しかし今回のように、
- .NET Framework 4.8 を入れている（手動でもVS Installer経由でも）
- なのに Visual Studio が未インストール扱い
- さらに Visual Studio Installer まで見失う
という状況では、Visual Studioが参照する“標準の場所”そのものがずれている可能性が非常に高いです。
特に濃厚なのが、WindowsのレジストリにあるProgram Filesの既定パス（ProgramFilesDir系）が、CドライブではなくDドライブなど別ドライブを指してしまっているケースです。
なぜ「.NET Framework 4.8が入っているのにTarget framework not installed」になるのか
ここは誤解されやすいので、少し踏み込みます。
ランタイムとターゲティングパックは別物
Windowsに「.NET Framework 4.8」が入っていると言うとき、多くの場合それは実行用（ランタイム）です。ところがVisual StudioでUnityプロジェクト（.csproj）を開いてビルド／解析するには、ランタイムだけでなく参照アセンブリ（Reference Assemblies）を含むDeveloper Pack / Targeting Packが必要になります。
Visual Studioは、例えば次のような場所にある参照アセンブリを見て「このターゲットフレームワークは使える」と判断します。
- C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\…
つまり、
- 参照アセンブリが本当に無い（ターゲティングパック未導入）
- 参照アセンブリはあるのに、Visual Studioが別ドライブの存在しない場所を探している
のどちらでも「Target framework not installed」が発生します。
Installerが見つからないのも同じ根っこ
Visual Studio Installerの標準的な配置先は多くの環境で次の配下です。
- C:\Program Files (x86)\Microsoft Visual Studio\Installer
ところが、Windowsが「Program Files (x86)はD:\だ」と誤認していると、
- D:\Program Files (x86)\Microsoft Visual Studio\Installer を探す
- あるいは D:\Microsoft Visual Studio\Installer\setup.exe のような、過去の配置情報に引っ張られる
といった形で、Installerまで「見失い状態」になります。結果、修復や変更に進めず、Unityプロジェクトの読み込みエラーだけが残って悪化して見えます。
最優先チェック：Program Filesの参照先が別ドライブを指していないか
根本対応として効果が高いのが、WindowsのレジストリでProgram Files参照先を確認することです。Visual Studioの不具合に見えて、実はOS側の前提が崩れているパターンです。
確認すべきレジストリキー
次の場所を見ます。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
| 値の名前 | 一般的な既定値（例） | ここがズレると起きやすい問題 |
|---|---|---|
| ProgramFilesDir | C:\Program Files | 64bitアプリの既定配置・一部検出パスが狂う |
| ProgramFilesDir (x86) | C:\Program Files (x86) | 32bit要素（参照アセンブリ、Installer等）が狂い、VS/Unity連携が壊れやすい |
今回の症状だと、特にProgramFilesDir (x86)がD:\などを指しているケースが当たりです。
GUIで確認する手順（regedit）
- Win + R → regedit と入力して起動
- 左ツリーで HKEY_LOCAL_MACHINE → SOFTWARE → Microsoft → Windows → CurrentVersion へ移動
- 右ペインで ProgramFilesDir と ProgramFilesDir (x86) を探す
- 値が C:\Program Files / C:\Program Files (x86) になっているか確認
PowerShellで一発確認する（GUIが苦手な人向け）
管理者権限のPowerShellで、次のコマンドでも確認できます。
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion" |
Select-Object ProgramFilesDir, "ProgramFilesDir (x86)"結果がD:\などになっていれば、今回の「Installerが見つからない」「Target framework not installed」がセットで出る説明がつきます。
根本対応：ProgramFilesDirを正しいCドライブへ修正する
レジストリ編集は影響が大きいので、手順を守って進めてください。ここで狙うのは「好きなドライブに変える」ことではなく、実際に存在する標準パスへ戻して矛盾を解消することです。
作業前の安全策
- 可能なら復元ポイントを作成する
- 最低限、該当キー（CurrentVersion）をエクスポートしてバックアップする
修正手順
- レジストリエディターで HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion を開く
- ProgramFilesDir をダブルクリックし、C:\Program Files に修正
- ProgramFilesDir (x86) をダブルクリックし、C:\Program Files (x86) に修正
- レジストリエディターを閉じる
- 再起動（またはサインアウト→サインイン）
この修正で、Visual Studioが参照アセンブリやInstallerの位置を正しく辿れるようになり、結果としてUnityプロジェクトの「Target framework not installed」や「Unable to locate Visual Studio Installer」が一気に収まることがあります。
修正後に確認するチェックリスト
レジストリを直したら「直った気がする」で止めず、次の観点で“完全復旧”を確認すると再発防止にもなります。
| 確認項目 | 見る場所 | 期待される状態 |
|---|---|---|
| Visual Studio Installer の実体がある | C:\Program Files (x86)\Microsoft Visual Studio\Installer | フォルダが存在し、vs_installer.exe / setup.exe 相当が見える |
| Visual Studio でUnityの .sln / .csproj が読み込める | Unityからスクリプトを開く or .slnを直開き | Assembly-CSharp が Load failed にならない |
| 「Target framework not installed」が消える | Visual Studioのエラー一覧、ソリューションエクスプローラー | 対象フレームワークとして .NET Framework 4.x が認識される |
| .NET Framework 4.8 の参照アセンブリが見える | C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\ | v4.8（またはUnityが指定する版）配下が存在する |
ここで「Installerフォルダが存在しない」「参照アセンブリが無い」場合は、次の“追加策”に進みます。
追加策：Visual Studio Installerがまだ壊れている場合の修復手順
レジストリ修正で参照先が正しくなっても、Installer自体の構成が壊れていると、修復が必要です。基本方針は以下の順です。
- 存在するならInstallerからRepair
- ダメならブートストラップ（公式インストーラー）でInstallerを再構築
Installerフォルダが存在する場合：コマンド/GUIで修復
まずはInstallerを起動できるか試します。
- エクスプローラーで C:\Program Files (x86)\Microsoft Visual Studio\Installer を開く
- vs_installer.exe（または setup.exe 等）を起動
- 対象のVisual Studioに対して 修復（Repair） を実行
GUIが開けるならGUI修復が無難です。どうしても自動化・CLIで行いたい場合は、環境により利用可能なコマンドが異なるため、まずインストールパスを特定してからRepairします。
例：インストールパスの確認（vswhereがある場合）
"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -latest -products * -property installationPath例：修復コマンド（環境により実行ファイル名が異なるため、存在するものを使用）
"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe" repair --installPath "C:\Program Files\Microsoft Visual Studio\2022\Community"※Community部分はProfessional/Enterprise等、環境に合わせます。パスが分からない場合は、上のvswhereの出力をそのまま使うと迷いません。
Installerを完全に見失っている場合：公式ブートストラップで再構築
「Tools → Get Tools and Features…」が「Unable to locate Visual Studio Installer」になり、さらにフォルダ自体も欠落しているなら、Visual Studio Installerを再構築します。
- Visual Studio公式サイトから、使用エディションに合うブートストラップ（例：vs_community.exe など）を入手
- 起動して既存のVisual Studioを検出させ、Modify / Repair を実行
ここで重要なのは「Visual Studio本体を消して入れ直す」より先に、Installerを正常化することです。Installerが復旧すると、足りないコンポーネント（Unity向けワークロードや.NETターゲティングパック）を後からきれいに足せるようになります。
追加策：.NET Framework 4.8は入っているのに読み込めない場合の“もう一つの盲点”
レジストリが正常でも「Target framework not installed」が残る場合、次はDeveloper Pack / Targeting Packの不足を疑います。ランタイムはWindows Update等で入っていても、開発用が入っていないことがあります。
Visual Studio Installerで入れるべき代表例
Visual Studio Installer の「Individual components（個別のコンポーネント）」で、次のような項目が入っているか確認します。
| コンポーネント例 | 目的 | 症状との関係 |
|---|---|---|
| .NET Framework 4.8 Targeting Pack | 参照アセンブリを追加 | 不足すると「Target framework not installed」になりやすい |
| .NET Framework 4.8 SDK | 開発用ツール一式 | ビルドや一部機能で必要になることがある |
| Game development with Unity（ワークロード） | Unity向け統合（必要な拡張など） | Unityプロジェクトの扱いが安定しやすい |
ここを入れた後、Visual StudioでUnityのソリューションを開き直し、エラーが消えるか確認します。
Unity側でやっておくと復旧が早い設定
原因がWindows/Visual Studio側にあっても、Unity側の設定を整えておくと“復旧の確認”がスムーズです。
External Script Editor を明示的に設定
- Unity：Edit → Preferences（またはUnity → Settings）→ External Tools
- External Script Editor を Visual Studio（使用している版）に設定
プロジェクトファイルの再生成
Unityはソリューション/プロジェクトファイルを自動生成します。壊れた状態が残っている場合は、再生成が効くことがあります。
- External Tools 付近にある Regenerate project files を実行
- それでも怪しい場合は、Unityプロジェクト直下の *.sln / *.csproj（および .vs フォルダ）を削除して再生成
※削除するのは生成物のみで、Assets配下のスクリプト自体は消しません。ただしバージョン管理をしていない場合は、作業前にバックアップを推奨します。
Visual Studioを別ドライブに入れている人がハマりやすいポイント
「Cドライブが小さいから、Visual Studio本体はF:\に入れたい」という運用は珍しくありません。結論から言うと、Visual Studioのインストール先が別ドライブでも動くことは多いです。
ただし今回のようなトラブルは、次のような“混同”があると起きやすくなります。
| やりがちな設定 | 何が起きるか | おすすめ |
|---|---|---|
| ProgramFilesDir / ProgramFilesDir (x86) をD:\等に変更して「OSの既定」ごと移す | 多くのソフトが標準パス前提で作られているため、検出・修復・更新が壊れやすい | 変更しない（既定はC:\のまま） |
| Program Filesは既定のまま、Visual Studioのインストール先だけ別ドライブにする | 比較的安定。Installerや参照アセンブリの検出も破綻しにくい | 容量事情があるならこの方法を優先 |
| 途中でProgramFilesDirを変えた／戻した（OS移行やクローン作成後に発生しがち） | 今回のように「存在しないD:\を参照」など矛盾が出る | まずは実体があるパスに整合させる |
「Visual Studio本体を別ドライブに置く」のと、「Windowsの既定Program Files参照を変える」は別物です。今回の症状が出たなら、まず後者（レジストリの不整合）を疑うのが近道です。
再発防止：なぜProgramFilesDirを触るとVisual Studioが壊れやすいのか
Visual Studioは、エディタ本体だけでなく周辺要素が非常に多い製品です。
- Installer（更新・修復の司令塔）
- MSBuildや各種SDK
- ターゲティングパック（参照アセンブリ）
- 拡張機能、テンプレート、キャッシュ
これらが「Program Files (x86)配下のどこか」に散らばって配置され、さらに検出も「既定パス前提」で組まれている部分があります。ProgramFilesDirがずれると、見つけられない→修復できない→不足を補えないの負のループに入りやすいのが厄介なところです。
容量対策をしたい場合は、
- Visual Studioのインストール先を変更する（可能な範囲で）
- キャッシュやダウンロードの場所を別ドライブにする
- UnityプロジェクトやLibraryフォルダを別ドライブに置く
など、“OS標準の前提を崩さない”方向で調整するほうが長期的に安定します。
よくある質問（つまずきポイントの解消）
Q. レジストリを直したのに「Target framework not installed」が消えません
A. 次の順で切り分けるのが効率的です。
- 参照アセンブリのフォルダ（Reference Assemblies）に、Unityが要求するバージョンが存在するか確認
- Visual Studio Installerで .NET Framework 4.8 Targeting Pack（必要に応じてSDKも）を追加
- Unity側でプロジェクトファイルを再生成し、Visual Studioを開き直す
Q. Windowsの「変更（Modify）」がまだ別ドライブのsetup.exeを探します
A. ProgramFilesDir修正後も、過去のインストール情報が残っていることがあります。Installerが起動できるならRepairを優先し、起動できないなら公式ブートストラップでInstallerの再構築を行うと、更新経路が戻りやすいです。
Q. そもそもなぜProgramFilesDirがD:\を指していたのですか？
A. よくある原因は、
- PC移行（クローン/イメージ復元）時の設定引き継ぎミス
- 過去にProgram Filesを別ドライブへ移すためにレジストリを書き換えた
- メーカー製ユーティリティや最適化ツールが意図せず変更した
などです。原因特定よりも、まずは現在の実体（Cドライブ）と参照先（レジストリ）を一致させることが復旧には重要です。
まとめ：Unity×Visual Studioの不調は「OSの参照先」を疑うと早い
Unityプロジェクトが突然「Target framework not installed」になり、Visual Studio Installerまで見失う場合、.NETの再インストールだけで戦うのは遠回りになりがちです。ProgramFilesDir / ProgramFilesDir (x86) の不整合は、エラーのつじつまが一気に合う“根本原因”になりやすいので、最優先で確認してみてください。
レジストリを正しい状態に戻し、必要ならInstallerの修復・ターゲティングパック追加まで行えば、UnityのAssembly-CSharpが正常に読み込める状態へ戻せる可能性が高まります。
コメント