MENU

PowerShellGetが見つからないエラー解決完全ガイド｜Windows10/PowerShell 5.1・7対応と再発防止策

PowerShell

Windows 10 上の PowerShell（5.x / 7.x）で Install-Module や Get-PSRepository が失敗し「Unable to find module providers (PowerShellGet)」と表示される――この症状の9割は、ユーザー プロファイルの壊れたモジュール、プロキシ設定、または「ブロック」属性の3点に集約できます。この記事では再発防止まで最短で直す具体手順と深掘りの知識をまとめます。

目次

症状（何が起きているか）

  • Install‑PackageProvider / Install‑Module / Get‑PSRepository がエラー。
  • エラー例：Unable to find module providers (PowerShellGet)、No match was found for the specified search criteria and provider name ‘NuGet’、Unable to resolve package source など。
  • Get‑PackageProvider -ListAvailable に NuGet は出るが PowerShellGet（または MSI） が出ない。
  • $Env:PSModulePath の先頭に %USERPROFILE%\Documents\WindowsPowerShell\Modules があり、そこに古い/壊れた PackageManagement または PowerShellGet が存在することが多い。

根本原因（なぜ起きるのか）

モジュール検索順序とユーザー側の“優先読込”

PowerShell は $Env:PSModulePath の順にモジュールを探索します。既定では ユーザー プロファイルのモジュール パスが最優先のため、ここに壊れた/古い PackageManagement や PowerShellGet があると、システム標準（C:\Program Files\...）より先にそれを読み込み、結果として PowerShellGet プロバイダーが見つからない/動作しない状態になります。

さらに OneDrive の 既知フォルダー移動 (KFM) を使っている場合、Documents\WindowsPowerShell\Modules が複数PCに同期されるため、不具合が横展開されます。

プロキシ/証明書/TLS による接続失敗

企業ネットワークのプロキシ経由では、PowerShell ギャラリー（PSGallery）への接続が認証や TLS 設定で遮断されることがあります。接続失敗は Register‑PSRepository -Default や Find‑Module の段階で顕在化します。

ダウンロード ファイルの「ブロック」属性

インターネットから取得した ZIP/ファイルには NTFS の代替データストリーム Zone.Identifier が付くことがあり、モジュールの読込が拒否されます（特にユーザー配下に配置した場合）。

最短復旧（まずはこれだけやれば直る）

  1. ユーザー モジュールを隔離
    エクスプローラーで %USERPROFILE%\Documents\WindowsPowerShell\Modules を 丸ごと削除（心配なら別ドライブに退避）。
    OneDrive 同期を使っているなら、削除後に同期が完了するまで待ちます。
  2. 管理者 PowerShell での確認 Get-PackageProvider -ListAvailable Get-PSRepository ここで PowerShellGet と PSGallery が表示されれば復旧です。表示されない場合は続行します。
  3. 標準モジュールの再取得（TLS/代理認証込みの安全版） # 推奨: TLS 1.2 を確実に有効化（PS 5.1/古い .NET 環境向け） [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # プロキシ環境なら OS 既定の資格情報を使用 [System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials # Windows Update サービスが停止中だと NuGet 取得に失敗する場合あり # 必要に応じて有効化（権限があれば） try { Get-Service wuauserv -ErrorAction Stop | Start-Service } catch {} # NuGet プロバイダーのブートストラップ Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force # 破損を避けるため先に古いモジュールをアンロード Remove-Module PackageManagement, PowerShellGet -ErrorAction SilentlyContinue # PowerShellGet をシステム共通で入れ直す Install-Module PowerShellGet -Scope AllUsers -Force -AllowClobber # 既定リポジトリを登録（既にあればメッセージが出るだけ） Register-PSRepository -Default # 利便性: 明示的に信頼（無人化用途。手動運用なら省略推奨） try { Set-PSRepository -Name PSGallery -InstallationPolicy Trusted } catch {}
  4. 検証 Get-PSRepository Find-Module Pester -Repository PSGallery -Verbose Install-Module Pester -Scope AllUsers -Force -Confirm:$false 問題なく検索・インストールできれば復旧完了です。

詳細手順（原因別に深掘り）

ユーザー側モジュールの“隔離”と確認

  • 隔離：%USERPROFILE%\Documents\WindowsPowerShell\Modules を空にする（退避可）。OneDrive KFM 環境なら同期完了を待つ。
  • 現状把握： $Env:PSModulePath -split ';' Get-Module -ListAvailable PowerShellGet,PackageManagement | Sort-Object Name, Version | Format-Table Name,Version,Path
  • ポイント：表示パスが C:\Program Files\WindowsPowerShell\Modules（5.1）または C:\Program Files\PowerShell\7\Modules（7.x）配下になっていれば“システム標準”が使われています。

プロキシ環境の正しい扱い

PSGallery への到達確認：

# まず資格情報をOS既定と同じに
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

# 疎通チェック（エラー詳細を必ず確認）

Invoke-WebRequest [https://www.powershellgallery.com/api/v2](https://www.powershellgallery.com/api/v2) -UseBasicParsing -ErrorAction Stop

必要に応じて Install-Module / Find-Module に -Proxy / -ProxyCredential を明示し、WinHTTP 側のプロキシ設定（netsh winhttp show proxy）も併せて点検します。

ファイルの「ブロック」属性を解除

ユーザー配下にコピーしたモジュールや ZIP 展開物で読込が失敗する場合は、ADS（Zone.Identifier）を解除します。

# 一括解除（失敗しても安全）
Get-ChildItem "$env:USERPROFILE\Documents\WindowsPowerShell\Modules" -Recurse |
  Unblock-File -ErrorAction SilentlyContinue

# 付与状況の確認（必要に応じて）

Get-Item "$env:USERPROFILE\Documents\WindowsPowerShell\Modules*" -Stream * -ErrorAction SilentlyContinue |
Where-Object Stream -eq 'Zone.Identifier' </code></pre>

<h3>再発防止（2つのアプローチ）</h3>
<ol>
  <li><strong>OneDrive で “ドキュメント” を同期しない</strong><br>KFM を無効化する、または PowerShell 用フォルダのみ対象外にします（運用/ポリシーに合わせて判断）。</li>
  <li><strong>ユーザー パスを PSModulePath から除外する</strong><br>プロファイルに以下を記載（セッション単位の無効化例）：<br>
    <pre><code class="language-powershell">$paths = $Env:PSModulePath -split ';' | Where-Object { $_ -notlike "$Env:USERPROFILE\Documents*" }
$Env:PSModulePath = ($paths -join ';')

<p>全端末で徹底するなら、環境変数をシステム側で統制します。</p>

“手順表”で一気に把握

手順内容ひと言メモ
① 不良モジュールの隔離Documents\WindowsPowerShell\Modules を丸ごと削除/退避OneDrive 同期環境は削除後の同期完了を要確認
② 動作確認Get‑PackageProvider -ListAvailable / Get‑PSRepositoryPowerShellGet と PSGallery が表示なら復旧
③ 標準モジュールの再取得Install‑PackageProvider -Name NuGet -Force
Install‑Module PowerShellGet -Scope AllUsers -Force
Register‑PSRepository -Default		Windows Update 停止中だと NuGet 取得に失敗する場合あり
④ プロキシ環境対応セッション先頭で [System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentialsその後 Register‑PSRepository -Default を実行
⑤ ブロック属性の解除Get-ChildItem "$env:USERPROFILE\Documents\WindowsPowerShell\Modules" -Recurse | Unblock-File直らなければ ① を採用
⑥ 再発防止OneDrive でドキュメント同期を止める、または PSModulePath からユーザー パスを除外組織なら KFM/環境変数をポリシーで統制

診断フロー（最小コマンドで素早く切り分け）

  1. PSModulePath を見る： $Env:PSModulePath -split ';' 先頭が %USERPROFILE%\Documents\WindowsPowerShell\Modules なら、まずはそこを空に。
  2. 提供プロバイダー/リポジトリを確認： Get-PackageProvider -ListAvailable Get-PSRepository
  3. 疎通/TLS 確認： [Net.ServicePointManager]::SecurityProtocol Invoke-WebRequest https://www.powershellgallery.com/api/v2 -UseBasicParsing
  4. プロキシ：OS のプロキシ資格情報を流用 [System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials
  5. NuGet の再導入： Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
  6. PowerShellGet の再導入： Install-Module PowerShellGet -Scope AllUsers -Force -AllowClobber

Windows PowerShell 5.1 と PowerShell 7.x の違い

  • モジュール パス：
    5.1 は主に C:\Program Files\WindowsPowerShell\Modules、7.x は C:\Program Files\PowerShell\7\Modules（バージョンによりパス末尾が変化）。
  • 管理者権限：-Scope AllUsers でのインストールには管理者が必要。ユーザー単位 (-Scope CurrentUser) は破損時に再発しやすいので基本は AllUsers を推奨。
  • コマンド互換：5.1 では TLS 設定の影響を受けやすく、[Net.ServicePointManager]::SecurityProtocol = Tls12 の明示が安定。

閉域/オフライン環境での復旧手順

  1. インターネットに接続できる別 PC で以下を実行： # 依存関係ごと保存（例：PowerShellGet と PackageManagement） Save-Module PowerShellGet, PackageManagement -Path C:\Temp\PSOffline -Force
  2. 保存されたフォルダー（PowerShellGet\<version> など）を対象端末の C:\Program Files\WindowsPowerShell\Modules または C:\Program Files\PowerShell\7\Modules 配下へ丸ごとコピー。
  3. （任意）社内共有を ローカル リポジトリ として登録： Register-PSRepository -Name LocalRepo -SourceLocation "\\srv\share\PSRepo" -InstallationPolicy Trusted Install-Module PowerShellGet -Repository LocalRepo -Scope AllUsers -Force

よくあるエラーと対処早見表

エラー/メッセージ原因の傾向即時対処
Unable to find module providers (PowerShellGet)ユーザー配下の壊れたモジュールが優先読込ユーザー モジュールを削除/退避 → PowerShellGet を AllUsers で入れ直す
No match was found for provider ‘NuGet’TLS/プロキシ/Windows Update サービスTLS 1.2 有効化、プロキシ資格情報付与、wuauserv 起動、NuGet を再取得
Unable to resolve package sourcePSGallery への疎通不可Invoke-WebRequest で疎通確認、ファイアウォール/SSL 検査を点検
モジュールが見つからない/読み込めないZone.Identifier によるブロックUnblock-File で解除、ZIP 展開直後は特に注意
Constrained Language Mode で失敗WDAC/Device Guard による制限サイン/ポリシーで許可、監査ログを精査

安全運用のベストプラクティス

  • AllUsers での標準配置：ユーザー配下へのインストールは避け、システム共通に配置。
  • 署名と発行元の確認：無人化のために Set-PSRepository -InstallationPolicy Trusted を設定する場合も、導入前に一度は Get-AuthenticodeSignature で署名を確認。
  • プロキシ/証明書のガバナンス：SSL 検査や中間証明書の更新を運用フローに組み込む。
  • バックアップ：安定稼働の端末から Save-Module でモジュール セットをエクスポートし、復旧キットとして保管。

復旧のための“全部入り”スクリプト（コピペ用）

# === PowerShellGet/PackageManagement 復旧スクリプト ===
# 1) セッション健全化（TLS/プロキシ）
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

# 2) ユーザー モジュールの影響排除（退避する場合は Rename-Item に変更）

$UserMod = Join-Path $env:USERPROFILE "Documents\WindowsPowerShell\Modules"
if (Test-Path $UserMod) { try { Remove-Item $UserMod -Recurse -Force } catch {} }

# 3) サービス状態（可能であれば）

try { Get-Service wuauserv -ErrorAction Stop | Start-Service } catch {}

# 4) 競合の予防

Remove-Module PackageManagement, PowerShellGet -ErrorAction SilentlyContinue

# 5) NuGet プロバイダーを確実に導入

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

# 6) PowerShellGet をシステム共通に再導入

Install-Module PowerShellGet -Scope AllUsers -Force -AllowClobber

# 7) 既定リポジトリの復旧

Register-PSRepository -Default
try { Set-PSRepository -Name PSGallery -InstallationPolicy Trusted } catch {}

# 8) 動作確認

Get-PSRepository
Find-Module PowerShellGet -Repository PSGallery -ErrorAction Stop
Write-Host "== PowerShellGet/PSGallery の復旧が完了しました ==" -ForegroundColor Green </code></pre>

<h2>期待される結果（ゴール）</h2>
<ul>
  <li><code>Get‑PSRepository</code> に <strong>PSGallery</strong> が正常表示される。</li>
  <li><code>Install‑Module</code> / <code>Update‑Module</code> がエラーなく実行できる。</li>
  <li>モジュール管理コマンドが通常どおり機能し、スクリプトやツール導入が継続的に行える。</li>
</ul>

<h2>補足情報（覚えておくと便利）</h2>
<ul>
  <li><strong>システム既定のモジュール格納先</strong>
    <ul>
      <li>PowerShell 5.x：<code>C:\Program Files\WindowsPowerShell\Modules</code></li>
      <li>PowerShell 7.x：<code>C:\Program Files\PowerShell\7\Modules</code> など</li>
    </ul>
  </li>
  <li><strong>ExecutionPolicy</strong> が厳しすぎる場合はセッション限定で緩和：<br>
    <code>Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force</code>
  </li>
  <li><strong>DISM による OS 修復</strong>（システム破損が疑われる場合）：
    <pre><code class="language-plaintext">DISM /Online /Cleanup-Image /RestoreHealth

ログの手掛かり：Get-WinEvent -LogName Application -MaxEvents 100 で直近のエラーを確認。
代替の新世代パッケージ管理：環境により Microsoft.PowerShell.PSResourceGet の利用も検討可（ただし既存運用との互換/統制を事前に評価）。

ケーススタディ：複数端末で同時に再現する場合

複数 PC で同症状なら、まず OneDrive KFM を疑います。1台を直しても、同期により壊れたユーザー モジュールが再び配布されるため、ユーザー配下のモジュールを使わない方針（AllUsers への再配置・PSModulePath での除外）を組織標準にしてください。オフライン端末が混在する場合は、Save-Module で作った“良品セット”を配布し、構成管理ツールやスクリプトで横展開すると確実です。

チェックリスト（公開前/運用前の最終確認）

  • Get-PSRepository に PSGallery が 1件だけ、正しい URL で登録されている。
  • Get-Module -ListAvailable PowerShellGet で Program Files 配下の 1本が参照されている。
  • プロキシ配下で Invoke-WebRequest が成功する（認証プロンプトが出ない）。
  • ユーザー配下の WindowsPowerShell\Modules は空、もしくは PSModulePath から除外されている。
  • バックアップ（Save-Module したアーカイブ）が保管されている。

以上の手順と知識を押さえれば、「PowerShellGet が見つからない」問題は短時間で復旧でき、同時に再発もしっかり防げます。運用でつまずきやすいのはユーザー配下モジュールの優先読込とプロキシ/TLS まわりです。まずはユーザー モジュールの隔離と標準配置化、そしてセッション健全化（TLS/プロキシ）を“最初の一手”として習慣化してください。

PowerShell
windows10 プロキシ PowerShell OneDrive NuGet PackageManagement PowerShellGet

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次