2026年5月5日に確認された Microsoft developer platform documentation update の要点は、Aspire CLI取得スクリプト get-aspire-cli.ps1 の Invoke-WebRequest 呼び出しに UseBasicParsing = $true が追加されたことです。これにより、Windows PowerShell 5.1で対話実行した際に表示される「Security Warning: Script Execution Risk」の確認プロンプトを避けやすくなります。API変更やアプリケーション設定の変更ではなく、主に Windows PowerShell 5.1でAspire CLIを取得・導入する利用者や、同種のPowerShellスクリプトを管理している担当者が確認すべき修正 です。(GitHub)
変更の要点は「IEベースの解析を使わない」こと
今回の変更は、Microsoft AspireリポジトリのPR #15609「fix: add -UseBasicParsing to Invoke-WebRequest in get-aspire-cli.ps1」としてマージされたものです。変更されたファイルは eng/scripts/get-aspire-cli.ps1 で、Invoke-SecureWebRequest 内の $requestParams に UseBasicParsing = $true が1行追加されています。(GitHub)
修正後の考え方は、次のようなものです。
$requestParams = @{
Uri = $Uri
Method = $Method
MaximumRedirection = 10
TimeoutSec = $TimeoutSec
UserAgent = $Script:UserAgent
UseBasicParsing = $true
}
Invoke-WebRequest @requestParams
-UseBasicParsing は、Windows PowerShell 5.1で Invoke-WebRequest がHTMLを処理する際に、Internet Explorerコンポーネントを使ったフルDOM解析を避けるための指定です。MicrosoftのPowerShell 5.1向けドキュメントでも、確認プロンプトを避けるには UseBasicParsing パラメーターを使う必要があると説明されています。(Microsoft Learn)
なぜWindows PowerShell 5.1で警告が出るのか
背景にあるのは、Windows PowerShell 5.1の Invoke-WebRequest が、既定ではWebページの内容を解析し、その過程でページ内のスクリプトが実行される可能性があるという挙動です。Microsoftは、2025年12月9日以降のWindows Update適用後、特別なパラメーターなしで Invoke-WebRequest を使うと、スクリプト実行リスクに関する確認プロンプトが表示されると説明しています。(マイクロソフトサポート)
つまり、今回のAspire CLI取得スクリプトの修正は、「警告を無視して続行する」ための変更ではありません。むしろ、不要なIEベースのDOM解析を使わないことで、より安全な取得処理に寄せる修正です。
特に注意したいのは、表面上の実行コマンドが irm https://aka.ms/aspire/install.ps1 | iex のように見える場合でも、内部の取得処理で Invoke-WebRequest が使われることがある点です。Issue #15608では、Windows PowerShell 5.1の対話セッションでAspire CLIのインストールスクリプトを実行すると、Invoke-WebRequest の警告プロンプトが表示される再現手順が示されています。(GitHub)
影響を受ける人・受けにくい人
このMicrosoft developer platform documentation updateで確認すべき対象は、全ユーザーではありません。影響の中心は、Windows PowerShell 5.1、つまり powershell.exe でAspire CLI取得スクリプトを実行するケースです。PR本文でも、PowerShell 7以降では基本解析が既定で使われるため、主にレガシーな powershell.exe 利用者に影響すると整理されています。(GitHub)
| 利用状況 | 影響度 | 確認すべきこと |
|---|---|---|
| Windows PowerShell 5.1でAspire CLIを対話的にインストールする | 高 | 警告プロンプトが出ない最新スクリプトを使っているか |
社内で get-aspire-cli.ps1 を保存・ミラーして使っている | 高 | 古いコピーに UseBasicParsing = $true が含まれているか |
| CI/CDでPowerShell 5.1を使って取得処理を自動化している | 中〜高 | 同種の Invoke-WebRequest がプロンプト待ちにならないか |
PowerShell 7以降の pwsh で実行している | 低 | 互換性確認程度でよい |
| Aspire CLI本体をすでに利用しているだけ | 低 | CLI機能やアプリ設定への直接影響は基本的にない |
PowerShell 7系では、Web Cmdletsの実装が変更され、Invoke-WebRequest は基本的なHTML解析のみをサポートし、ParsedHtml や Forms などのプロパティは削除されています。したがって、今回の修正はPowerShell 7利用者に大きな挙動変更をもたらすというより、Windows PowerShell 5.1側の挙動を安全な方向にそろえる意味合いが強いです。(Microsoft Learn)
ドキュメント更新として見るべきポイント
2026年5月5日のPR Documentation Checkでは、この変更について「ドキュメントPRは不要」と判断されています。理由は、eng/scripts/get-aspire-cli.ps1 に -UseBasicParsing 相当の指定を追加する内部エンジニアリングスクリプトの修正であり、ユーザー向けAPI、構成、動作仕様の変更ではないためです。(GitHub)
ただし、ドキュメントPRが不要だからといって、現場で確認が不要という意味ではありません。以下のような環境では、運用担当者がスクリプトの取得元や実行環境を見直す価値があります。
- Aspire CLIの導入手順を社内Wikiや手順書にコピーしている
- 社内プロキシや閉域環境向けにインストールスクリプトを保存している
- PowerShell 5.1前提の端末キッティング手順が残っている
- CI/CD、タスクスケジューラ、管理者用スクリプトで
Invoke-WebRequestを使っている powershell.exeとpwsh.exeの違いを明確に分けずに運用している
特に社内でスクリプトをキャッシュしている場合、Microsoft側のリポジトリで修正済みでも、自社環境では古いコードを実行し続ける可能性があります。今回のような小さな修正は、バージョンアップ通知として目立ちにくいため、導入手順の棚卸しで見落としがちです。
対応が必要か判断するチェックリスト
まずは、次の観点で自分の環境に関係するか確認してください。
| 確認項目 | 対応の目安 |
|---|---|
powershell.exe 5.1でAspire CLIを導入している | 最新の取得スクリプトを使う |
pwsh ではなくWindows標準のPowerShellを使っている | 警告表示の有無を検証する |
get-aspire-cli.ps1 を社内に保存している | UseBasicParsing = $true の有無を確認する |
自作スクリプトで Invoke-WebRequest を使っている | ファイル取得用途なら -UseBasicParsing を検討する |
| HTMLフォームやDOMをPowerShellから操作している | 単純に -UseBasicParsing を追加せず、処理方式を見直す |
| タスクスケジューラやCIでPowerShell 5.1を使う | プロンプト待ちで停止しないか確認する |
判断の目安はシンプルです。ファイルをダウンロードするだけ、またはレスポンス本文を文字列として扱うだけなら、-UseBasicParsing を明示する方向が適しています。 一方で、ParsedHtml、Forms、HTML DOMを前提にした処理がある場合は、基本解析に切り替えると取得できるオブジェクト構造が変わる可能性があります。Microsoftも、-UseBasicParsing 使用時はIEコンポーネントによるフルDOM解析ができないと説明しています。(マイクロソフトサポート)
実務での確認手順
PowerShellの種類を確認する
まず、利用しているPowerShellがWindows PowerShell 5.1なのか、PowerShell 7以降なのかを確認します。
$PSVersionTable.PSVersion
$PSVersionTable.PSEdition
目安は次の通りです。
| 表示例 | 意味 |
|---|---|
Major 5 / Desktop | Windows PowerShell 5.1系。今回の警告影響を受けやすい |
Major 7 / Core | PowerShell 7系。基本解析が前提で、影響は限定的 |
コマンドが powershell.exe | Windows PowerShellの可能性が高い |
コマンドが pwsh.exe | PowerShell 7以降の可能性が高い |
「PowerShellを使っている」とだけ把握している現場では、powershell.exe と pwsh.exe が混在していることがあります。手順書には、単に「PowerShellで実行」ではなく、「Windows PowerShell 5.1」または「PowerShell 7以降」と明記したほうがトラブルを減らせます。
保存済みスクリプトを確認する
社内で get-aspire-cli.ps1 を保存している場合は、Invoke-WebRequest に渡すパラメーター付近を確認します。修正済みであれば、$requestParams の中に次のような指定があります。
UseBasicParsing = $true
GitHubのPR差分では、MaximumRedirection、TimeoutSec、UserAgent と並ぶ形で UseBasicParsing = $true が追加されています。(GitHub)
古いスクリプトを使い続けている場合は、公式の最新スクリプトに更新するか、社内レビューのうえで同等の修正を反映します。特に、端末展開用のバッチ、MDM経由の配布、社内ポータルからのダウンロード手順に組み込まれている場合は、手元の1台だけでなく配布元を確認してください。
自作スクリプトも同じ観点で棚卸しする
今回の修正はAspire CLI取得スクリプトに対するものですが、同じ問題は他のPowerShellスクリプトでも起こり得ます。Microsoftは、自動化スクリプトやスケジュールタスクでは Invoke-WebRequest 呼び出しに -UseBasicParsing を追加し、プロンプトが表示されないようにすることを推奨しています。(マイクロソフトサポート)
単発の修正なら、次のように明示します。
Invoke-WebRequest -Uri $Uri -OutFile $OutFile -UseBasicParsing
同じスクリプト内に Invoke-WebRequest が多数ある場合は、スクリプト冒頭で既定パラメーターを指定する方法もあります。
$PSDefaultParameterValues['Invoke-WebRequest:UseBasicParsing'] = $true
ただし、この方法はスクリプト全体の Invoke-WebRequest に影響します。HTMLフォームやDOMを使う処理が同じスクリプト内にある場合は、個別指定のほうが安全です。
移行・設定確認で失敗しやすいポイント
irm | iex だけを見て安心しない
Aspire CLIのインストール手順では、irm、つまり Invoke-RestMethod を使ってスクリプトを取得する形が見えることがあります。しかし、Issue #15608の再現手順では、取得したスクリプト内の Invoke-WebRequest が警告プロンプトの原因として扱われています。(GitHub)
そのため、「実行コマンドに Invoke-WebRequest と書いていないから関係ない」と判断するのは危険です。実際に読み込まれるスクリプトの中身まで確認する必要があります。
リモートスクリプト実行を無条件に許可しない
iex は取得したスクリプトをその場で実行するため、便利な一方でリスクもあります。検証環境では、実行前にURL、取得元、スクリプト内容、社内の許可ポリシーを確認してください。
実務では、次のような運用が望ましいです。
| 運用 | 推奨度 | 理由 |
|---|---|---|
| 公式手順を確認し、検証環境で実行する | 高 | 変更点を把握したうえで導入できる |
| 社内でレビュー済みスクリプトを配布する | 高 | 監査・再現性を確保しやすい |
| 古いコピーを出所不明のまま使い回す | 低 | 修正やセキュリティ改善を取り込めない |
| 警告プロンプトで毎回「Yes」を選ぶ | 低 | 本来避けるべき解析挙動を続けることになる |
DOM解析に依存するスクリプトでは影響を確認する
-UseBasicParsing は、すべてのPowerShellスクリプトに機械的に追加すればよいものではありません。ファイルダウンロード、APIレスポンス取得、静的テキスト取得では有効な選択肢ですが、HTMLフォームやDOM操作を使っている場合は、出力オブジェクトの構造が変わる可能性があります。
たとえば、古いスクリプトで次のような処理をしている場合は注意が必要です。
$response = Invoke-WebRequest -Uri "https://example.com/login"
$form = $response.Forms[0]
このような処理は、PowerShell 7への移行や -UseBasicParsing の追加によって、そのまま動かなくなる可能性があります。長期的には、HTML解析ライブラリ、API利用、専用のWeb自動化ツールへの置き換えを検討したほうが安全です。Microsoftも、信頼できない公開Webコンテンツを扱う処理では、レガシーなフルHTML解析に頼らず、より安全な処理方式へリファクタリングすることを推奨しています。(マイクロソフトサポート)
Aspire CLI利用者が今やるべきこと
Aspire CLIを通常利用しているだけなら、今回の変更でアプリケーションコードや設定ファイルを変更する必要は基本的にありません。確認すべきなのは、CLI本体の機能ではなく、CLIを取得・更新するためのPowerShellスクリプトです。
優先順位は次の通りです。
| 優先度 | 対応 |
|---|---|
| 高 | Windows PowerShell 5.1でAspire CLI導入手順を実行している端末を確認する |
| 高 | 社内保存版の get-aspire-cli.ps1 に UseBasicParsing = $true があるか確認する |
| 中 | CI/CDや端末セットアップ手順でPowerShell 5.1を使っていないか確認する |
| 中 | 自作スクリプト内の Invoke-WebRequest を検索する |
| 低 | PowerShell 7利用環境では、念のため取得手順とログを確認する |
検索するときは、リポジトリやスクリプト保管場所で次の文字列を探すと効率的です。
Invoke-WebRequest
iwr
curl
wget
UseBasicParsing
Windows PowerShellでは Invoke-WebRequest に iwr、curl、wget のエイリアスがあります。表記ゆれを含めて検索しないと、古い処理を見落とすことがあります。(Microsoft Learn)
get-aspire-cli-pr.ps1は変更不要と確認されている
PR内では、関連スクリプトの get-aspire-cli-pr.ps1 についても確認されています。このスクリプトはアーティファクトのダウンロードにGitHub CLIの gh を使っており、Invoke-WebRequest 呼び出しがないため、今回の修正は不要と説明されています。(GitHub)
そのため、確認対象を広げる場合でも、単にファイル名が似ているから一律に修正するのではなく、実際に Invoke-WebRequest が使われているかを基準に判断してください。不要な修正は、かえって差分管理やレビューを複雑にします。
まとめ:小さな1行変更だが、PowerShell 5.1運用では確認する価値がある
今回のMicrosoft developer platform documentation updateは、ユーザー向けAPIやAspire CLIの機能変更ではありません。変更の本質は、get-aspire-cli.ps1 の Invoke-WebRequest に UseBasicParsing = $true を追加し、Windows PowerShell 5.1のIEベース解析によるセキュリティ警告を避けることです。(GitHub)
対応の第一歩は、自分の環境が powershell.exe 5.1に依存しているかを確認することです。次に、社内で保存・配布しているAspire CLI取得スクリプトに修正が反映されているかを見ます。さらに、同じ考え方で自作の Invoke-WebRequest 利用スクリプトも棚卸しすれば、将来のプロンプト停止やセキュリティ警告による運用トラブルを減らせます。
特に、社内手順書や自動化スクリプトを管理している担当者は、「最新スクリプトを使っているか」「PowerShell 5.1と7のどちらで動かしているか」「DOM解析に依存していないか」の3点を確認しておくとよいでしょう。

コメント