PowerShell の起動に関する問題のトラブルシューティング

PowerShell を使用する準備が整う前に問題が発生することがあります。スタートアップの問題は、特に PowerShell を使用して支援する場合に、トラブルシューティングが困難な場合があります。スタートアップには、主に次の 3 つのフェーズがあります。

プロセスの作成
PowerShell SessionState の初期化
プロファイル処理

最も一般的な問題は次のとおりです。

起動時間が長い、またはパフォーマンスが低下する
Errors
クラッシュ

スタートアップシーケンスの手順

起動時に PowerShell が実行する手順を理解しておくと役立ちます。これにより、問題が発生している場所を絞り込むことができます。

手順 1: プロセスの作成

プロセスの作成には、いくつかの手順があります。

ホストウィンドウを作成する

Windows では、ホストには Windows ターミナル、Windows コンソールホスト、Visual Studio Code、またはその他のホスティングアプリケーションを使用できます。ここで発生する問題は、通常、PowerShell とは無関係ですが、非常にまれです。
プロセスホストプロセスを開始する

ここで発生する問題は、通常、破損した実行可能ファイルまたはオペレーティングシステムの問題が原因で発生します。
.NET の準備

PowerShell は .NET ベースであり、完全に読み込む必要があります。開始しようとしている PowerShell のバージョンに応じて、Windows PowerShell 5.1 と Windows 統合の完全な .NET Framework または PowerShell 7 に含まれる新しい .NET を取得します。

PowerShell の初回起動時に、PowerShell と .NET は最適化タスクを実行します。この最適化タスクは、インストール後の最初の起動時、アップグレード中、またはキャッシュが空の場合にのみ実行されます。この初回の最適化では、起動に時間がかかります。最適化中にエラーが発生すると、破損したキャッシュが作成される可能性があります。 PowerShell キャッシュが破損すると、コマンドの検出とモジュールの読み込みに関する問題が発生する可能性があります。

手順 2: PowerShell SessionState の初期化

PowerShell バイナリの読み込みとエンジンの初期化には、PowerShell 構成とキャッシュされたデータの処理が含まれます。

プロセス構成ファイル: JEA およびその他のリモート処理シナリオで使用される powershell.config.json および PSSession 構成ファイル。これらのファイルには、言語モードに影響する可能性のある設定、使用可能なコマンドとモジュール、およびいくつかのポリシー設定が含まれている場合があります。
グループポリシーと Windows セキュリティポリシーを確認します。 Windows グループポリシーは、 powershell.config.jsonの設定をオーバーライドできます。セキュリティポリシーを使用すると、WDAC (Windows Defender アプリケーション制御) などの機能を有効にできます。また、使用可能な言語モードを制限することもできます。
既定のモジュール (Microsoft.PowerShell.Core と PSReadLine) と、PSSession 構成で定義されているすべてのモジュールとアセンブリを読み込みます。

PowerShell のセキュリティ機能の詳細については、次の記事を参照してください。

手順 3: プロファイル処理

最後に、PowerShell は使用可能なプロファイルファイルを実行します。プロファイルスクリプトは、次の順序で実行されます。

すべてのホスト、すべてのユーザー
現在のホストにいるすべてのユーザー
すべてのホストの現在のユーザー
現在のホスト現在のユーザー

注

プロファイルスクリプトは、リモートセッションでは実行されません。

プロファイルの詳細については、about_Profilesを参照してください。

問題の範囲を絞り込む

変数を削除し、問題が発生する場所の特定のスコープを絞り込むのが役立ちます。削除する最も簡単な変数はプロファイルです。多くの場合、プロファイルにはカスタムコード (特にユーザー固有のプロファイルスクリプト) が含まれています。

プロファイルを無効にして PowerShell を実行してみてください。

# PS 5.1:
powershell -NoProfile

# PS 7.*:
pwsh -NoProfile

次に、問題がバージョン固有であるかどうかを確認します。 Windows PowerShell 5.1 と PowerShell 7 の両方でプロファイルを実行してみてください。 Windows PowerShell と PowerShell 7 では、プロファイルが異なる場所に格納されます。両方のバージョンでプロファイルが同じでない場合があります。ファイルを比較して違いを理解します。 Windows PowerShell 5.1 で PowerShell プロファイルをインストールしてみてください。ただし、一部の PowerShell 7 コマンドとモジュールは Windows PowerShell 5.1 と互換性がありません。

既存のプロファイルを上書きすることなく、Windows PowerShell 5.1 で PowerShell 7 プロファイルをテストできます。

プロファイルを無効にして Windows PowerShell 5.1 を起動します。
PowerShell 7 プロファイルファイルを Windows PowerShell 5.1 セッションに手動でドットソースします。
```
. $env:USERPROFILE\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
```
問題が発生したかどうかを確認します。

問題が解決しない場合は、問題がプロファイル外の環境問題であることがわかります。

別のデバイスでプロファイルを実行してみてください。プロファイルが別のデバイスで正しく動作する場合は、問題が元のデバイスに固有であることがわかります。

一般的な環境問題のトラブルシューティング

起動時にクラッシュする

起動時、特に早期に、フィードバックなしで PowerShell コンソールがクラッシュした場合は、プロセスキャッシュが破損している可能性があります。これは、キャッシュをクリアすることで解決できるまれな状態です。クリアできるキャッシュの場所は 2 つあります。

ユーザーキャッシュ: $env:LOCALAPPDATA\Microsoft\Windows\Caches
システムキャッシュ: $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\Caches

最初にユーザーキャッシュフォルダーの内容を削除してから、PowerShell をもう一度起動してみてください。問題が解決しない場合は、システムキャッシュの内容を削除して、もう一度やり直してください。

PowerShell 分析キャッシュを削除する必要がある場合もあります。キャッシュファイルは、次の場所にあります。

Windows PowerShell: $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\PowerShell
PowerShell 7: $env:LOCALAPPDATA\Microsoft\PowerShell

次のファイルパターンのみを削除します。

ModuleAnalysisCache-*
StartupProfileData-*

キャッシュされたデータは、次回 PowerShell を起動するときに再作成されます。

Windows PowerShell 5.1 で問題が解決しない場合は、.NET Framework のインストールを修復することが必要な場合があります。詳細については、「 .NET Framework の修復」を参照してください。

プロファイルに関する一般的な問題のトラブルシューティング

このセクションでは、PowerShell の起動時に発生する可能性がある一般的な問題とそのトラブルシューティング方法について説明します。

プロファイルの実行に時間がかかりすぎる

まず、 "長すぎる" ものを定義する必要があります。PowerShell では、スクリプトによって指示された操作のみが実行されます。すべてのプロファイルパスを確認します。複数のプロファイルスクリプトが実行されている可能性があります。コードを確認して、実行しようとしていることを理解します。

遅延が発生する場所を決定する

AllUsers スコープのプロファイルスクリプトがある場合は、それらのファイルを編集できない可能性があります。システム管理者と協力して、これらのファイルを確認してください。 CurrentUser スコーププロファイルスクリプトの場合は、これらのファイルを編集してタイミングメッセージを追加し、遅延が発生する場所を見つけるのに役立ちます。たとえば、プロファイルスクリプトのさまざまなポイントに次の行を追加できます。
```
Write-Host "$(Get-Date -Format 'HH:mm:ss.fff') | Profile: Step X"
```
依存関係を減らす

プロファイルを実行するために読み込む必要があるモジュールの数を減らします。プロファイルの実行後 Get-Module 実行して、起動時に読み込まれたモジュールを確認します。既定では、PowerShell は Microsoft.PowerShell.Core モジュールと PSReadLine モジュールを読み込みます。プロファイルスクリプトによって、どの追加モジュールも読み込まれました。

モジュールは、 Import-Module を使用して明示的に読み込むか、それらのモジュールで定義されているコマンドを使用して暗黙的に読み込むことができます。起動時にコマンドまたはモジュールを読み込む必要があるかどうかを検討します。
リダイレクトされたフォルダーにモジュールをインストールしないようにする

Windows では、多くの場合、 Documents フォルダーをネットワークファイル共有または OneDrive にリダイレクトできます。特に、ネットワークが混雑しているか、サーバーの負荷が高い場合は、ネットワークファイルへのアクセスが遅くなる可能性があります。 OneDrive の構成方法によっては、プロファイルの実行中に遅延が発生したり、エラーが発生したりする可能性もあります。

この問題を軽減するには、いくつかのオプションがあります。
- Documents フォルダーをリダイレクトしないでくださいが、これは望ましくない可能性があります
- OneDrive の Modules フォルダーを常にディスクに保持するように構成します。これにより、エラーと遅延読み込み時間が回避されます。
- ユーザープロファイルフォルダーの外部にある AllUsers スコープにモジュールをインストールします。
実際のパフォーマンスを測定する

プロファイルの実行にかかる時間がわからない場合は、長すぎるかどうかを判断できません。 Measure-Command コマンドレットは、コマンドまたはスクリプトブロックの実行にかかる時間を示すことができます。

PowerShell Dev Manager の Steve Lee には、プロファイルのパフォーマンスを測定する方法について説明するブログ記事があります。パフォーマンスのベースラインを確立するための手順、詳細なタイミング情報を取得する方法、プロファイルを最適化する方法が含まれています。 $Profileの最適化を参照してください。

分離されたネットワークで PowerShell 7 がゆっくりと起動する

このシナリオでは、Windows コンピューターがインターネットに接続されていないネットワーク上にあります。対話型 PowerShell セッションの場合、PowerShell は PSReadLine モジュールを自動的に読み込みます。 PSReadLine は署名付きモジュールです。 PowerShell では、モジュールのデジタル署名を確認する必要があります。この検証により、切断された環境で遅延が発生する可能性があります。この理論をテストするには、 非対話型 モードで PowerShell 7 を起動します。

pwsh.exe -noninteractive

PowerShell が非対話型モードですぐに起動する場合、問題は証明書失効リスト (CRL) チェックによって発生する可能性があります。デジタル署名を検証するプロセスの一環として、.NET ランタイムは CRL をチェックして、署名証明書がまだ有効であることを確認します。切断された環境では、コンピューターはインターネット上の CRL にアクセスできません。 CRL チェックの既定のタイムアウトは 15 秒です。つまり、PowerShell が署名済みモジュールを読み込むたびに、タイムアウトになるまでに最大 15 秒かかる場合があります。

この問題には、次の 3 つの回避策が考えられます。

ファイアウォールまたはプロキシの除外

CRL チェックに直接インターネットアクセスを許可すると、問題が回避されます。インターネットアクセスへのアクセスを制御できる環境では、CRL URL へのアクセスを許可するようにファイアウォールまたはプロキシを構成できます。これは、影響を最小限に抑えた最も簡単なソリューションです。ファイアウォールログには、PowerShell が到達しようとした URL が表示されます。
CRL タイムアウトの削減

CRL 参照のタイムアウトを減らすことは可能ですが、指定された時間内に完了できない他の参照が失敗するリスクがあります。タイムアウトを変更する方法の詳細については、「ネットワーク取得とパスの検証の管理」を参照してください。
CRL チェックを削除する

CRL チェックの設定は、グループポリシーによって管理されます。詳細については、「信頼できる発行元の管理」を参照してください。

Warnung

CRL チェックを無効にすることはできますが、推奨されません。 CRL チェックを無効にすると、侵害された証明書を実際に失効できなくなります。

エラー: このコマンドは別の言語モードで定義されているため、ドットソースできません

PowerShell は、 ConstrainedLanguage モードで自動的に実行することで、AppLocker や Windows Defender アプリケーション制御 (WDAC) などのアプリケーション制御システムと連携します。 ConstrainedLanguage モードでは、危険な可能性のある一部の機能が制限されます。ただし、特定のコマンドや機能を使用するために FullLanguage モードが必要な場合があります。スクリプトは、ポリシーによって信頼されている場合に FullLanguage モードで実行できます。信頼は、AppLocker または WDAC で構成されたファイル署名またはその他のポリシーメカニズムを使用して示すことができます。

アプリケーション制御下で管理されている PowerShell セッションを開始すると、次のエラーが発生します。

Cannot dot-source this command because it was defined in a different language mode. To invoke this
command without importing its contents, omit the '.' operator.

アプリケーション制御では、PowerShell は ConstrainedLanguage モードで実行されています。このエラーは、プロファイルスクリプトが除外されている場合、または FullLanguage モードで実行するために署名されている場合に発生します。 PowerShell が ConstrainedLanguage モードで実行されている場合、 FullLanguage モードで実行するために信頼されるドットソースコードは使用できません。

問題を解決するには、プロファイルスクリプトから除外または署名を削除する必要があります。プロファイル中に FullLanguage モードで実行する必要があるコードが必要な場合は、除外または署名された別のスクリプトファイルに移動します。プロファイル内からそのスクリプトファイルを呼び出します (ドットソースではない)。

この問題の詳細については、「 PowerShell の制約付き言語モードと Dot-Source 演算子」を参照してください。

詳細については、次を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-01-14