WSUSやWindows Updateの復旧で「Reset-WindowsUpdate.ps1」を実行しようとしたら、Windows 10でスクリプト実行がブロックされることがあります。本記事ではPowerShellの実行ポリシーを“その場だけ”回避して安全に元へ戻す手順と、組織PCで効かない場合の切り分けポイントをまとめます。
Windows 10で「Reset-WindowsUpdate.ps1」がブロックされる理由を切り分ける
「実行できない」「悪意あるスクリプト防止のためブロックされた」と表示されると、つい PowerShellの実行ポリシー（Execution Policy） だけを疑いがちです。しかし、実際には複数の仕組みが絡むため、まずは 表示されたエラーメッセージの種類 で原因を切り分けるのが近道です。
| 見え方（代表的なメッセージ例） | 主な原因 | 優先して試す対処 |
|---|---|---|
| 「このシステムではスクリプトの実行が無効になっているため…」 「running scripts is disabled on this system」 | PowerShell実行ポリシー（Restricted / AllSigned / RemoteSigned など） | ProcessスコープのBypass、または実行コマンドで一時Bypass |
| 「このスクリプトには悪意のある内容が含まれているためブロック…」 | Defender/EDRによる検知（AMSI等） | 出所確認・内容確認・管理者へ例外申請（安易な無効化は非推奨） |
| 「インターネットから取得したファイルはブロックされることがあります」 （プロパティに“ブロックの解除”が出る） | ダウンロード由来のマーク（Mark of the Web / Zone.Identifier） | Unblock-File、またはファイルのプロパティでブロック解除 |
| 「このアプリはシステム管理者によってブロックされています」 | AppLocker / WDAC / 組織の制御 | 管理者ポリシーの確認（端末側での小手先回避は不可の場合が多い） |
この記事の中心は「実行ポリシー」が原因のケースです。まずはエラーに ExecutionPolicy という語や、「スクリプトの実行が無効」といった文言が含まれているかを確認してください。
先に結論：1回だけ実行するなら「Processスコープ」か「-ExecutionPolicy Bypass」
WSUS更新トラブル対応などで、どうしても 一時的に 「Reset-WindowsUpdate.ps1」を通したいなら、次の2つが現場で一番安全・確実です。
| 方法 | コマンド | 影響範囲 | おすすめ度 |
|---|---|---|---|
| そのPowerShellセッションだけBypass | Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass | 今開いているPowerShellウィンドウのみ（閉じると戻る） | 高 |
| 実行コマンド側で一時Bypass | powershell.exe -ExecutionPolicy Bypass -File .\Reset-WindowsUpdate.ps1 | その起動プロセスのみ（コマンド実行時だけ） | 高 |
| Unrestrictedに変更 | Set-ExecutionPolicy Unrestricted | 端末（スコープ次第で広範囲・永続） | 低（理由がある時のみ） |
「一回だけ（または一時的に）」という要件に最も合うのは、上2つです。以降では、現場でつまずきやすいポイントも含めて具体手順を紹介します。
方法：現在のPowerShellを閉じるまでだけ実行許可する（Processスコープ）
まずおすすめなのが Processスコープ の回避です。既存の端末設定を恒久的に変えず、開いているPowerShellセッションの間だけ実行を許可します。
- PowerShellを 管理者として実行 で起動します（Reset系スクリプトはサービス操作やフォルダ削除が発生しやすいため）。
- 次のコマンドを実行します。
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass- スクリプトのあるフォルダへ移動し、実行します。
cd C:\Scripts\ResetWU
.\Reset-WindowsUpdate.ps1この方法の良い点は、作業が終わったら PowerShellを閉じるだけで元に戻る ことです。実行後に「戻し忘れ」が起きにくく、監査面でも説明しやすいのが強みです。
実行前に確認しておくと安心なコマンド
現在どのスコープがどんな実行ポリシーになっているかは、次で一覧できます。
Get-ExecutionPolicy -Listここで MachinePolicy / UserPolicy に値が入っている場合は、後述する「GPO強制」の可能性があります。
方法：コマンド一発で“その実行だけ”Bypassする（powershell.exe）
もう一つの定番が、起動引数で -ExecutionPolicy Bypass を指定してスクリプトを実行する方法です。既存のPowerShellセッションを汚さず、実行したプロセスだけで完結します。
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Reset-WindowsUpdate.ps1-NoProfile を付けるのは、プロファイルに書かれたエイリアスやモジュール読み込みの影響を受けにくくするためです（トラブルシュート中は、なるべく“素の状態”で動かすのが安全です）。
管理者で実行する場合
管理者権限が必要なスクリプトなら、コマンドプロンプトやPowerShellを「管理者として実行」してから上記を実行するのが確実です。Windows Terminalを使っている場合も、ターミナル自体を管理者として起動してください。
（受理回答として多い）Set-ExecutionPolicy Unrestricted はなぜ慎重にすべきか
ネット上の回答では、管理者PowerShellで次を実行して通す方法がよく出てきます。
Set-ExecutionPolicy Unrestricted確かに即効性はありますが、Unrestricted は恒久的に緩くなりやすい のが注意点です。スコープ指定なしで実行すると、既定では LocalMachine が変更対象になり、端末全体に影響する可能性があります。
| 項目 | Unrestricted の挙動イメージ | 実務上のリスク |
|---|---|---|
| 永続性 | 元に戻すまで残る（再起動しても残る） | 戻し忘れで“緩い状態”が継続 |
| 影響範囲 | スコープ次第で端末全体 | 別作業・別ユーザーにも影響する可能性 |
| 監査・説明 | 「恒久的に緩めた」扱いになりやすい | セキュリティレビューで指摘されやすい |
どうしてもUnrestrictedを使うなら、せめてスコープを明示して影響を限定し、作業後に必ず復元する運用にしてください。
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestrictedそれでも「恒久変更」である点は変わりません。基本方針としては、前述の Processスコープ または 起動引数でBypass を優先するのがおすすめです。
実行後に元へ戻す：変更前の値を控えて確実に復元する
実行ポリシーはスコープごとに設定が存在し、どこを変えたかで戻し方が変わります。作業前に一度、現在値を控えておくと安全です。
Get-ExecutionPolicy -List例として、よくある出力イメージを表にすると次のようになります（値は環境により異なります）。
| スコープ | 例 | 意味合い |
|---|---|---|
| MachinePolicy | Undefined / RemoteSigned など | GPO（コンピューター）で強制される設定 |
| UserPolicy | Undefined / AllSigned など | GPO（ユーザー）で強制される設定 |
| LocalMachine | RemoteSigned | 端末全体に適用される既定スコープ |
| CurrentUser | Undefined / RemoteSigned | 現在ユーザーにだけ適用 |
| Process | Undefined / Bypass | 現在のPowerShellプロセスのみ |
作業後の戻し方はシンプルです。たとえば、LocalMachine を RemoteSigned に戻すなら次の通りです。
Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned「元が何だったか分からない」という状態が一番危険なので、作業前に必ず控える、または変更したスコープを明示して実施してください。
Processスコープで回避した場合
Processスコープなら、基本は PowerShellを閉じる だけで元へ戻ります。作業を終えたら、新しくPowerShellを開き直してから追加作業を進めると安心です。
Set-ExecutionPolicyが効かない／すぐ戻るときはGPO強制を疑う
組織管理PCでは、実行ポリシーが グループポリシー（GPO） で強制されていることがあります。この場合、Set-ExecutionPolicy を実行しても反映されなかったり、反映されてもすぐに上書きされます。
見分け方は簡単で、Get-ExecutionPolicy -List の結果で MachinePolicy や UserPolicy に値が入っていれば、GPOが優先される可能性が高いです。
| 状況 | 端末側でできること | 現実的な対処 |
|---|---|---|
| MachinePolicy / UserPolicy が設定済み | ProcessスコープBypassで一時回避できる場合あり（ただし環境次第） | ドメイン管理者に「一時的な許可」または署名運用の相談 |
| LocalMachine / CurrentUser のみで制御 | Set-ExecutionPolicyで調整可能 | 最小範囲（CurrentUser）で変更し、必ず復元 |
| AppLocker / WDAC 等でブロック | 実行ポリシー変更では解決しない | ポリシー側で許可（正規手順） |
特にセキュリティが厳しい環境では、実行ポリシーよりも強い制御（WDAC、AppLocker、EDR）が入っていることが珍しくありません。「実行ポリシーを変えたのに動かない」 ときは、無理に押し通すよりも、まず統制ルールに沿った許可フローを選ぶ方が結果的に早いことが多いです。
よくある詰まり：ファイルが“ダウンロード扱い”でブロックされている
PowerShellの実行ポリシーが RemoteSigned の環境では、インターネットから取得したスクリプト（Mark of the Webが付いたファイル）は署名が必要になり、実行できないことがあります。典型的なのが、GitHub等からZIPで落として展開した .ps1 がブロックされるケースです。
この場合は、次のどちらかで “ブロック解除” できます。
- GUI：ファイルを右クリック → プロパティ → 「ブロックの解除」にチェック → 適用
- PowerShell：
Unblock-Fileを使う
Unblock-File -Path .\Reset-WindowsUpdate.ps1ZIP展開したファイル一式が対象なら、フォルダ配下をまとめて解除する方法もあります。
Get-ChildItem -Path C:\Scripts\ResetWU -Recurse -Filter *.ps1 | Unblock-Fileただし、ブロック解除は「そのファイルを信頼する」操作です。入手元が不明なスクリプトに対しては安易に解除せず、必ず出所を確認してください。
「悪意あるスクリプト」系の表示が出る場合の注意点
エラーメッセージが「悪意のある内容が含まれているためブロック」など、明らかにマルウェア対策の文言を含む場合、原因はExecutionPolicyではなく Defender/EDRによる検知 の可能性があります。このケースで重要なのは、セキュリティ機能を無効化して強行しない ことです。
現場対応としては、次の順で落ち着いて確認すると安全です。
- スクリプトの入手元（公式・社内承認済み・変更履歴）を確認する
- スクリプト本文をテキストで開き、外部URLへのダウンロードや不審な難読化がないかを見る
- 検知が誤検知の可能性があるなら、管理部門に例外申請（ハッシュ値・格納場所・用途を添えて）
- どうしても急ぐ場合は、検証用の隔離環境（VM等）で挙動確認してから本番へ
「WSUSの復旧が急ぎだから」といって守りを外すのは、被害を拡大させる典型パターンです。実行ポリシー回避はあくまで“運用上の摩擦を減らすための一時措置”であり、マルウェア対策のバイパスとは別物だと理解しておくと、判断を誤りにくくなります。
Reset-WindowsUpdate.ps1を安全に実行するための実務フロー（おすすめ）
WSUS更新トラブル対応で「Reset-WindowsUpdate.ps1」を使うなら、次の流れにしておくと、成功率と説明可能性が上がります。
| 作業 | 具体例 | 狙い |
|---|---|---|
| 入手元の確認 | 社内配布・承認済みリポジトリから取得 | 改ざんや誤配布を防ぐ |
| 作業用フォルダへ配置 | C:\Scripts\ResetWU など | ログや証跡を残しやすい |
| ブロック解除（必要な場合のみ） | Unblock-File | RemoteSigned環境での詰まり回避 |
| 管理者PowerShellで一時Bypass | Set-ExecutionPolicy -Scope Process Bypass | 最小影響で実行許可 |
| スクリプト実行 | .\Reset-WindowsUpdate.ps1 | Windows Update関連のリセット |
| PowerShellを閉じる | ウィンドウを終了 | Bypassを自動的に解除 |
| 確認・再起動 | Windows Update/WSUSの再試行 | 復旧確認 |
このフローは「端末全体の設定を変えない」「作業後に戻し忘れない」ことを主眼にしています。特に複数台のトラブルシュートをする場合、毎回Unrestrictedを入れて回る運用は、後で監査対応が苦しくなります。
運用面の補足：実行ポリシーは“標準化”しておくと楽になる
WSUSやWindows Updateのトラブル対応を定期的に行う環境では、端末ごとに実行ポリシーがバラバラだと、毎回つまずきます。次のように考えると整理しやすいです。
- 通常運用：
RemoteSigned（社内で配布したスクリプトは署名または信頼できる配布経路で管理） - 厳格運用：
AllSigned（社内スクリプトも署名必須、変更管理を徹底） - 緊急作業：ProcessスコープBypassで「その場だけ」通す（作業後は閉じて復帰）
「普段からUnrestrictedで問題ない」という判断は、トラブル対応のスピードだけを見ると魅力的に見えますが、長期的には事故コストの方が高くつきます。WSUS対応は“守りを外さずに早く直す”運用設計が鍵です。
よくある質問
PowerShell実行ポリシーを変えるには必ず管理者権限が必要ですか？
LocalMachine を変更する場合は管理者権限が必要です。一方で、CurrentUser や Process はユーザー権限で変更できる場合があります（ただし組織の制御や端末設定によって例外あり）。「一時的に」ならProcessスコープを優先すると、権限面でも運用面でも扱いやすいです。
RemoteSigned と Bypass の違いは何ですか？
RemoteSigned は「インターネット由来（ダウンロード扱い）のスクリプトだけ署名が必要」というバランス型です。Bypass は“チェックを行わない”に近く、検証用・緊急対応向けです。常用は避け、Processスコープで短時間だけ使う運用にすると安全です。
Set-ExecutionPolicyを実行しても反映されないのはなぜ？
MachinePolicy / UserPolicy が設定されていると、GPOが優先されます。まず Get-ExecutionPolicy -List でどのスコープが効いているかを確認し、必要なら管理者（ドメイン管理者）に相談してください。
Reset-WindowsUpdate.ps1が途中で止まったり、サービス操作で失敗します
実行ポリシーとは別の問題で、管理者権限不足、他の更新処理が動作中、EDRがサービス停止をブロック、Windows Update関連フォルダの権限不整合などが原因になり得ます。まずは管理者PowerShellで実行し、Windows UpdateやBITSなど関連サービスが他処理で使用中でないかを確認してください。
まとめ：最小影響で一時実行し、確実に元へ戻す
Windows 10で「Reset-WindowsUpdate.ps1」が実行禁止になる場面は珍しくありません。ポイントは、端末全体を緩めるのではなく、Processスコープ または -ExecutionPolicy Bypass で“その場だけ”通すこと、そして GPO強制やDefender検知など別要因 を切り分けることです。WSUS更新トラブル対応はスピードも重要ですが、再発防止と説明可能性まで含めた運用にしておくと、次回の対応が圧倒的に楽になります。
コメント