何も操作していないのに「Microsoft .NET Host – 8.0.13 (x64)」のウィンドウが画面右下などに何度も出る場合、ほとんどはWindows Installer（MSI）が“.NET関連の修復”を繰り返し、必要なインストール元ファイルが見つからず失敗している状態です。ここでは原因の見分け方と、ポップアップを止めるための手順を優先度順にまとめます。
まず起きていること（結論）
表示されている文面から判断すると、PC内のどこかに「Microsoft .NET Host / .NET Runtime 8.0.x」のインストール情報（MSI）が残っており、何らかのタイミングでWindows Installerの自動修復（セルフヒーリング）が起動しています。しかし修復に必要なキャッシュ（例：C:\ProgramData\Package Cache\{GUID}...）や、変換ファイル（例：dotnet-host-8.0.11-win-x64.MST）が既に存在しないため、修復が完了できず、同じダイアログが何度も出続けます。
「Microsoft .NET Host – 8.0.13」とタイトルに出ていても、内部的には8.0.11など別バージョンの残骸を参照しているケースが珍しくありません。Microsoft 365（Office）の導入直後に増えたのは、Officeのバックグラウンド処理やアドイン等で.NETに触れる機会が増え、修復トリガーが頻発したためと考えると筋が通ります。
症状チェック（このパターンなら本記事の手順が刺さります）
| チェック項目 | 該当すると起きやすいこと | 意味 |
|---|---|---|
| 「利用できないネットワーク リソース上にあります」と出る | OKを押しても再発する | MSIが参照する“元ファイルの場所”が無い |
dotnet-host-8.0.11-win-x64.MST のようなMSTファイル名が出る | 特定バージョンを要求してくる | 過去に入っていた同一系統の.NETの修復が走っている |
C:\ProgramData\Package Cache\... が案内されるが実在しない | 手動で作っても解決しない | キャッシュが消えており、再インストールで復元が必要 |
| Microsoft 365を入れてから発生回数が増えた | 放置していると頻発 | Officeのバックグラウンド実行が修復を誘発 |
やってはいけないこと（悪化しやすい落とし穴）
C:\ProgramData\Package Cacheを丸ごと削除しない：ここは複数製品が共有するインストールキャッシュ領域で、削除すると別の修復・更新まで壊れることがあります。- 適当な“レジストリクリーナー”で一括削除しない：MSIの参照関係が崩れ、アンインストールも修復もできない状態になりがちです。
- 手当たり次第に.NETを全部消さない：業務アプリが.NET依存の場合、起動不能になります。後述の「残す/消すの判断」を見てから進めてください。
最短で止めるための実践手順（おすすめ順）
作業前の準備（安全策）
- 可能なら復元ポイントを作成（企業PCなどポリシーで不可の場合は無理に行わない）。
- 作業は管理者権限のあるアカウントで実施。
- Teams/Outlookなどは閉じ、インストール・修復中は他の作業を控える（裏で更新が走ると失敗しやすい）。
.NET 8系の“該当コンポーネント”を把握する（最初にやると迷いが減ります）
Windows 10/11では、まず「インストールされている.NETが何か」を確認します。ポイントは、.NETは1つではなく複数コンポーネントに分かれることです。
| 表示されやすい名前（例） | 役割 | 一般的なOffice利用PCでの扱い |
|---|---|---|
| Microsoft .NET Runtime 8.0.x | .NETアプリ実行の基礎 | 業務アプリ次第。入っていて問題なし |
| Microsoft .NET Desktop Runtime 8.0.x | Windowsデスクトップ（WPF/WinForms）向け | デスクトップアプリが使うことが多い。入れておくと安全 |
| Microsoft ASP.NET Core Runtime 8.0.x | Web系（サーバー/ローカルWeb）向け | 通常のOffice利用だけなら不要なことも多い |
| Microsoft .NET SDK 8.0.x | 開発用（コンパイル/ツール） | 開発しないなら不要。入っていても問題は少ない |
| Microsoft .NET Host – 8.0.x | 起動ホスト（インストールの“核”） | ここが壊れると修復ループの原因になりやすい |
確認方法：
- 設定 → アプリ → インストールされているアプリ（または「アプリと機能」）で「.NET」「dotnet」で検索
- 旧UIならコントロール パネル → プログラムと機能
最優先：壊れた.NET 8の修復/アンインストール → 最新を入れ直す
このタイプのポップアップを止める王道は、“中途半端に残っている.NET 8の情報を正規の状態に戻す”ことです。特に、ポップアップ文面に出る「8.0.11」など古い8.0.xが混ざっている場合は効果が出やすいです。
手順（おすすめ）
- 「インストールされているアプリ」または「プログラムと機能」で、Microsoft .NET Host / .NET Runtime / Desktop Runtime の 8.0.xを確認します。
- 同名で複数ある場合、まずは問題の起点になりやすい“Host”、次に古いパッチ番号（例：8.0.11）を優先して処置します。
- 対象の項目を選び、以下のいずれかを実行します。
- 修復が選べる → 修復を実行
- 修復がない/失敗する → アンインストール
- アンインストール後、PCを再起動します（再起動を挟むと修復ループが止まりやすい）。
判断に迷う場合の目安
- ポップアップに
dotnet-host-8.0.11と出るなら：8.0.11に近い古い8.0.xや、Host項目を優先的に疑う - 8.0.13など新しいものだけに見えるのに出るなら：内部参照が古い可能性があるため、Hostの再インストールが効くことが多い
次に：Microsoft公式から.NET 8.0 ランタイムを再インストール（最新版でOK）
アンインストールや修復で“欠けたキャッシュ/構成”を戻すには、正規インストーラーで上書きするのが一番確実です。ここは非公式サイトやまとめ配布ではなく、必ずMicrosoftの公式配布から入手してください。
- Microsoft公式の「.NET 8.0 ダウンロード」ページを開く
- Windows向けは通常x64を選択
- まずは以下を優先
- .NET Runtime 8.0（x64）
- 可能なら.NET Desktop Runtime 8.0（x64）（デスクトップアプリ利用PCでは特におすすめ）
- インストール後、再起動して現象を確認
ここでの狙いは「壊れた状態で残っていた.NET 8のインストール情報を、最新の正しい状態で再構成する」ことです。結果としてWindows Installerの自動修復が走らなくなり、ポップアップが止まります。
コマンドで状態確認（できる人向け：原因切り分けが速くなります）
.NETが動く環境なら、インストール状態を一覧で確認できます。表示内容はPCによって異なりますが、8.0.xが複数混ざっているかの判断に役立ちます。
| 目的 | コマンド | 期待する見え方 |
|---|---|---|
| インストール済みランタイム一覧 | dotnet --list-runtimes | Microsoft.NETCore.App 8.0.xx などが列挙される |
| インストール済みSDK一覧 | dotnet --list-sdks | 8.0.xx SDKがあるか確認できる |
| システムファイルの整合性確認 | sfc /scannow | 破損修復の有無が出る |
※dotnet コマンドが見つからない場合でも、.NETが一部入っているケースはあります（Hostだけ壊れている等）。その場合は前述の「アプリ一覧から修復/再インストール」を優先してください。
Windows側の修復（DISM / SFC）で“土台”を整える
.NETの修復が何度も失敗するPCでは、Windowsコンポーネントストア側の不整合が絡むことがあります。ここは副作用が少なく、やって損が出にくい手順です（管理者権限が必要）。
手順：
- スタートメニューを右クリックし、Windows ターミナル（管理者）またはコマンド プロンプト（管理者）を開きます。
- 次を実行します。
dism /online /cleanup-image /restorehealth完了後、続けて実行します。
sfc /scannow終わったら再起動し、ポップアップの再発を確認します。
Microsoft 365（Office）側の修復を実施（トリガーがOfficeの場合に効きます）
.NET側を整えてもまだ出る場合、Officeの更新・修復が引き金になっていることがあります。Microsoft 365の修復は、Office本体や関連コンポーネントの不整合を戻す効果が期待できます。
- コントロール パネル →「プログラムと機能」
- Microsoft 365（またはMicrosoft Office）を選択 → 変更
- まずクイック修復を実行
- 改善しなければオンライン修復を実行（再ダウンロードが走るため時間がかかるが効果が出やすい）
- 再起動して確認
それでも止まらないときの“深掘り”対処（原因を特定して根を断つ）
イベントビューアーで「何が修復を呼んでいるか」を特定する
ポップアップが1日に何度も出る場合、裏で同じMSIが繰り返し起動しています。イベントビューアーを見ると、どの製品の修復が走っているのか、手がかりが得られます。
確認手順：
- スタートメニューで「イベント ビューアー」を検索して起動
- 「Windows ログ」→「アプリケーション」
- 右側の「現在のログをフィルター」で、ソースをMsiInstallerに絞る（表示がない場合は検索でも可）
- ポップアップが出た時刻周辺のイベントを開き、製品名やGUID、失敗内容を確認
ここで製品名が「Microsoft .NET Host」や.NET関連であれば、原因はほぼ確定です。もし別製品（特定の業務アプリ名など）が出る場合、そのアプリが.NET修復を間接的に呼んでいる可能性があるため、当該アプリの修復/再インストールも視野に入ります。
「消えたPackage Cache」が発生する代表例（実務で多い）
案内されたフォルダーが存在しない場合、原因は1つとは限りませんが、よくあるのは次のパターンです。
| 代表パターン | 起きること | 対策の方向性 |
|---|---|---|
| ストレージ清掃・最適化ツールがキャッシュを削除 | MSI修復に必要な元ファイルが消える | 正規インストーラーで再インストールしてキャッシュを復元 |
| 途中で更新/アンインストールが失敗 | 古いバージョンの情報だけ残る | 古い8.0.xを除去→最新版で上書き |
| 企業環境で配布/管理が一部失敗 | 端末ごとに状態がズレる | 情シスの配布パッケージで再適用、または管理者に依頼 |
“壊れたアンインストール情報”を掃除する（Microsoftのトラブルシューティングを使う）
修復もアンインストールも途中で失敗し、アプリ一覧に残り続ける場合は、MSIの登録情報が壊れている可能性があります。こういうときは、Microsoftが提供している「プログラムのインストールとアンインストールのトラブルシューティング」系ツールが効くことがあります（いわゆる“消せないプログラム”の修復用）。
- ツールを実行し、「アンインストールの問題」を選ぶ
- 一覧からMicrosoft .NET Host 8.0.xや、関連する.NET 8の項目を選んで修復/削除を試す
- その後、最新版の.NET 8 Runtime / Desktop Runtimeを再インストールして整える
この手順は「壊れたMSI登録が原因で、通常のアンインストールができない」タイプに特に有効です。
一時的に“要求されているバージョン”を入れてから最新版に戻す（最終手段に近いが効くことがある）
ポップアップに明確にdotnet-host-8.0.11のような特定バージョンが出続けるのに、最新版の再インストールでも止まらない場合、MSIが「そのバージョンの変換ファイル（MST）を使って修復する」前提になっていることがあります。
この場合、次の流れで収束することがあります。
- Microsoft公式の過去バージョン（アーカイブ）から、要求されている近いバージョンのHost/Runtimeを入れ直してキャッシュを復元
- その後、Windows Updateや最新インストーラーで8.0.13以降の最新パッチへ更新
ただし、古いランタイムを入れること自体に抵抗がある場合は、先に「トラブルシューティングツールで壊れた登録を除去」→「最新版を入れ直す」を優先してください。企業PCなら、セキュリティポリシー上この方法が禁止されることもあるため、管理者へ相談が安全です。
ポップアップが再発しないようにする予防策
“キャッシュ削除系”の設定を見直す
ディスククリーンアップや最適化ソフト、サードパーティのクリーナーで、ProgramData配下まで掃除対象にしていると、再び同様の症状が出ることがあります。設定に「アプリのキャッシュ削除」「インストーラーキャッシュ削除」のような項目があれば無効化を検討してください。
Windows Update と Microsoft 365 更新を止めない
.NET 8系は更新頻度が高く、脆弱性修正も含まれます。更新を止めると、古い残骸が残ったまま次の更新が重なり、失敗しやすくなることがあります。更新が組織で制御されている場合は、適用サイクルの確認も有効です。
企業PCでの注意点
- 管理者権限がない/ソフト配布が管理されている場合、自己流の削除よりも情報システム部門（情シス）に相談した方が早く確実です。
- イベントビューアーのMsiInstallerログ（発生時刻、製品名、エラー内容）を添えると、対応がスムーズになります。
よくある質問（検索されやすい疑問をまとめて解消）
「Microsoft .NET Host – 8.0.13」と出ているのに、なぜ8.0.11のMSTを要求されるの？
表示上のタイトルは現在のコンポーネント名でも、修復の参照先が過去のMSI登録情報（8.0.11など）になっていることがあります。特に更新の途中失敗やキャッシュ欠落があると、「古い定義に基づいて修復しようとして失敗」を繰り返します。対策は、古い8.0.xを正しく除去し、最新版で上書きして参照を作り直すことです。
放置しても問題ない？
ポップアップが出るだけで直ちに致命的とは限りませんが、裏ではWindows Installerが繰り返し動くため、PCが重くなる、スリープからの復帰で固まる、別のインストールが失敗するなど二次被害につながることがあります。業務中に出て邪魔になる点も含め、早めの収束がおすすめです。
.NETを全部アンインストールしてもいい？
おすすめしません。業務アプリ、プリンター関連ツール、会計ソフト、社内ツールなど、.NET依存アプリは多いです。今回の目的は「壊れた登録を正しい状態に戻して修復ループを止める」ことなので、基本は問題のある8.0.xを整えて最新化の方針が安全です。
まとめ（この順で実施すると止まりやすい）
| 優先度 | やること | 狙い |
|---|---|---|
| 高 | .NET 8（特にHost/古い8.0.x）の修復またはアンインストール | 自動修復ループの原因を断つ |
| 高 | Microsoft公式から.NET 8 Runtime / Desktop Runtime を再インストール | 欠落したキャッシュ/構成を正規状態に戻す |
| 中 | DISM / SFC の実行 | OS側の不整合を修復し、修復失敗を減らす |
| 中 | Microsoft 365 のクイック修復→オンライン修復 | Office起点のトリガーや関連不整合を解消 |
| 低（深掘り） | イベントビューアー（MsiInstaller）で原因特定、トラブルシューティングで登録修復 | “消せない/直らない”ケースの根本解決 |
上から順に進めるだけでも、1日に15〜20回出るような「Microsoft .NET Host – 8.0.13 (x64)」のポップアップは、止まる可能性が高いです。特に「案内されたフォルダーが存在しない」ケースは、正規の再インストールでキャッシュを復元できるかどうかが勝負どころになります。
コメント