PowerShellスクリプトを実行する前に確認したい実行ポリシーの公式設定

PowerShellスクリプトを実行する前に確認したい実行ポリシーの公式設定を、Windowsでの実作業に使える形で整理します。スクリプトが動かないとき、いきなりポリシーを緩めるのではなく、まず現在の有効値、適用範囲、グループポリシーによる上書きを切り分けるのが近道です。

実行ポリシーは何を制御するのか

PowerShellの実行ポリシーは、構成ファイルの読み込みやスクリプト実行の条件を決める安全機能です。ただし、強固なセキュリティ境界ではなく、悪意のあるコードを完全に阻止する仕組みでもありません。コマンドラインへ内容を直接入力するなど、ポリシーを回避できる場合があるため、ポリシーだけで安全性を判断するのは危険です。

Windowsで主に登場する値は次のとおりです。

• Restricted：個別のコマンドは実行できますが、スクリプトやプロファイルなどのスクリプトファイルは実行しません。Windowsクライアントの既定値です。
• RemoteSigned：ローカルで作成したスクリプトは署名不要ですが、インターネットから取得したスクリプトや構成ファイルには信頼された発行元の署名を求めます。Windowsの既定ポリシーとして説明されています。
• AllSigned：ローカル作成分を含め、すべてのスクリプトと構成ファイルに信頼された発行元の署名を求めます。
• Bypass：ブロック、警告、確認プロンプトを出しません。利用目的が限定される設定なので、安易な常用には向きません。
• Undefined：その範囲に設定値がない状態です。すべての範囲がUndefinedなら、WindowsクライアントではRestrictedが有効値になります。

最初に現在の状態を調べる

まず、現在のPowerShellセッションで有効な値だけを見るには、次を実行します。

Get-ExecutionPolicy

一方、どの範囲に何が設定されているかを見るには、こちらです。

Get-ExecutionPolicy -List

表示される主な範囲は、MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachineです。優先順位は、グループポリシーのMachinePolicyとUserPolicyを含めて判断されます。ローカル設定だけで見ると、Processが最も高く、CurrentUser、LocalMachineの順です。

たとえば、LocalMachineがAllSignedでもCurrentUserがRemoteSignedなら、CurrentUser側が優先され、有効値はRemoteSignedになります。逆に、設定コマンドが成功したように見えても、別の範囲やグループポリシーに上書きされて有効値が変わらないことがあります。スクリプト実行のトラブルでは、単一の値だけでなく一覧を読むのがポイントです。

変更するなら範囲を限定する

現在のユーザーだけにRemoteSignedを設定する例は次のとおりです。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

LocalMachineを変更すると、そのコンピューターを使う全ユーザーに影響します。LocalMachineを変更するには、PowerShellを「管理者として実行」で起動する必要があります。個人の開発環境で自分のスクリプトだけを扱うなら、影響範囲が狭いCurrentUserのほうが判断しやすい選択です。

設定後は、次のコマンドで各範囲と有効値を見ます。

Get-ExecutionPolicy -List
Get-ExecutionPolicy

設定を元に戻すときは、対象範囲をUndefinedにします。

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser

一時的な検証だけなら、Process範囲も候補になります。

Set-ExecutionPolicy -ExecutionPolicy AllSigned -Scope Process

Processの設定は現在のPowerShellセッションと子プロセスに限られ、セッションを閉じると保持されません。恒久的な設定変更を避けたい場面に適しています。ただし、グループポリシーによる設定を上書きするものではありません。

ダウンロードした.ps1だけが止まる場合

RemoteSignedで、取得したスクリプトだけが「署名されていない」として実行できない場合があります。Windowsでは、ブラウザーなどがファイルにインターネット由来の情報を付けることがあり、PowerShellがそれを判定します。

コードを読んで安全性を判断できたファイルに限り、ポリシー自体を変更せずにブロックを解除できます。

Unblock-File -Path .\Start-ActivityTracker.ps1
.\Start-ActivityTracker.ps1

この方法は実行ポリシーを変更しません。対象ファイルの内容を確認できない場合や、入手元を説明できない場合に、単にUnblock-Fileを適用するのは避けるべきです。また、curl.exe、Invoke-RestMethod、Invoke-WebRequestなど、取得方法によってはインターネット由来の印が付かない場合もあります。したがって、同じ取得元でもファイルの状態が一律とは限りません。

グループポリシーやPowerShellの種類にも注意

MachinePolicyまたはUserPolicyに値があれば、ローカルのSet-ExecutionPolicyでは変更できません。企業内の設定では、グループポリシーの「Turn on Script Execution」が優先され、すべてのスコープのローカル設定を上書きします。コンピューターの構成とユーザーの構成の両方に設定がある場合は、コンピューター側が優先されます。

また、Windows PowerShell 5.1のpowershell.exeと、PowerShell 6以降のpwsh.exeでは、実行ポリシーの保存場所が異なり、設定は別々に管理されます。片方で設定を変えたのに、もう片方のシェルで結果が変わらない場合は、起動している実行ファイルの違いを疑います。

Windows Server CoreやNano Serverでは、デスクトップシェルが利用できないことなどにより、ゾーン判定でスクリプト実行に失敗する場合があります。通常のWindowsクライアントと同じ切り分けが通用しないケースがある点にも注意が必要です。

まとめ：目的別の選び方

まずはGet-ExecutionPolicy -Listで全範囲を確認し、次にGet-ExecutionPolicyで有効値を見ます。個人ユーザーだけの変更ならCurrentUser、試験的な一時変更ならProcess、全ユーザーに影響する運用変更ならLocalMachineという順で検討すると、影響範囲を整理しやすくなります。

ダウンロードしたスクリプトだけが止まる場合は、コードと入手元を確認したうえでUnblock-Fileを選べることがあります。グループポリシーが設定されている環境ではローカル変更に固執せず、MachinePolicyとUserPolicyの値を切り分けるのが先です。実行ポリシーは万能な防御策ではありませんが、スクリプトを不用意に動かさないための基本的な防波堤として、範囲と優先順位を理解して使うのが実務的な扱いです。

筆者の環境で実際に確認した結果

確認日：2026年10月14日／環境：Windows 11 Home（ビルド26300）、Windows PowerShell 5.1、Python 3.14

Windows PowerShell 5.1で Get-ExecutionPolicy -List を実行した結果です。

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process          Bypass
  CurrentUser    RemoteSigned
 LocalMachine       Undefined

ふだんは CurrentUser の RemoteSigned が効いていますが、ツールから -ExecutionPolicy Bypass 付きで起動されたPowerShellでは、Process スコープが Bypass になっていました。Processは上位のスコープより優先されるので、「自分の画面では止められるのに、別の起動方法では動く（またはその逆）」という差は、どのスコープが効いているかを一覧で見ると説明がつきます。