「GitHub documentation update: Update release notes for v1.3.0-p1」は、GitHub本体の機能変更ではなく、MicrosoftDocs上のPowerShellGet/PSResourceGet公式ドキュメント更新です。結論から言うと、管理者や開発者が特に見るべき点は、Microsoft.PowerShell.PSResourceGet v1.3.0-preview1の追加内容、Microsoft Artifact Registry（MAR）の既定リポジトリ化、リポジトリ優先順位、CI/CDでのインストール元の固定です。公式PRは2026年5月20日にマージされ、リリースノートと複数のコマンドレット参照が更新されています。日本時間では2026年5月21日前後に確認した組織もあるため、社内アナウンスでは日付の表記をそろえておくと混乱を避けられます。 (GitHub)
GitHub documentation update: Update release notes for v1.3.0-p1で何が変わるのか
今回の更新は、GitHub上の MicrosoftDocs/PowerShell-Docs-PSGet リポジトリに対するPR #352「Update release notes for v1.3.0-p1」です。PR名では v1.3.0-p1 とされていますが、Microsoft Learn上のリリースノート本文では Microsoft.PowerShell.PSResourceGet v1.3.0-preview1 として記載されています。PRでは22件のMarkdownファイルが対象になり、リリースノート、概要ページ、サポート対象リポジトリ、各コマンドレットの構文・メタデータが更新されました。 (GitHub)
この更新を「GitHubの障害対応」「GitHub Actionsの仕様変更」「GitHub Packagesの破壊的変更」と捉える必要はありません。実務上は、PowerShellモジュール管理でPSResourceGetを使っている環境、PowerShell GalleryやMAR、Azure Artifacts、GitHub Packagesなどをリポジトリとして登録している環境に影響が出る可能性があります。
変更点の全体像
主な変更点は、次のように整理できます。
| 変更領域 | 変更内容 | 実務上の確認ポイント |
|---|---|---|
| リリースノート | v1.3.0-preview1の項目が追加 | 本番適用ではなく、まず検証環境で確認する |
| 既定リポジトリ | MARがPSGalleryと並ぶ既定リポジトリとして扱われる | Trusted と Priority の値を確認する |
| インストール処理 | Install-PSResource ワークフローに並列実行が追加 | CI/CDの実行時間短縮とログの見え方を検証する |
| DSC | PSResourceGet向けDSC v3リソースが追加 | 構成管理でDSCを使う組織は検証対象に含める |
| 不具合修正 | Windows PowerShellとPowerShellの判定ロジック改善など | Windows PowerShell 5.1とPowerShell 7系の混在環境で確認する |
| コマンドレット参照 | 複数の構文ブロックとメタデータを更新 | 古いドキュメントをもとにした社内手順書を見直す |
Microsoft Learnのリリースノートでは、v1.3.0-preview1の新機能として、MARの既定登録、Install-PSResource ワークフローの並列実行、PSResourceGet向けDSC v3リソースの追加が示されています。改善点としては、Azure.Identity の更新、Windows PowerShellとPowerShellを区別するロジックの修正、Update-PSResource がローカルコピーのプレリリース文字列を考慮する改善が挙げられています。 (Microsoft Learn)
もっとも重要なのはMARの既定リポジトリ化
今回の更新で管理者が最初に確認すべきなのは、Microsoft Artifact Registry、略してMARの扱いです。
Microsoft Learnの概要ページでは、Microsoft.PowerShell.PSResourceGet v1.3.0-preview1以降、MARがPSGalleryと並ぶ既定リポジトリになると説明されています。MARは Register-PSResourceRepository -MicrosoftArtifactRegistry で既定設定として登録でき、既定では Trusted がTrue、Priority が40、ApiVersion が ContainerRegistry になります。PSGalleryの既定優先度は50のため、数値が小さいMARのほうが高い優先順位になります。 (Microsoft Learn)
この「優先順位」は軽視できません。PSResourceGetのリポジトリ優先順位は0から100で、数値が小さいほど優先度が高く、複数リポジトリを横断して検索する場合は優先順位と名前で並べられ、最初に見つかった一致が返されます。つまり、スクリプトでリポジトリ名を明示せずに Install-PSResource や Find-PSResource を使っている場合、今後の検証環境では取得元の確認がより重要になります。 (Microsoft Learn)
管理者が確認すべきコマンド
まず、対象環境でPSResourceGetのバージョンとリポジトリ設定を確認します。
Get-Module Microsoft.PowerShell.PSResourceGet -ListAvailable |
Sort-Object Version -Descending |
Select-Object Name, Version, PathGet-PSResourceRepository |
Sort-Object Priority |
Format-Table Name, Uri, Trusted, Priority, ApiVersionMARが登録されているかを個別に確認する場合は、次のように実行します。
Get-PSResourceRepository -Name MicrosoftArtifactRegistry検証環境でMARを既定設定で登録する場合は、次のコマンドを使います。
Register-PSResourceRepository -MicrosoftArtifactRegistry -PassThruただし、既存の MicrosoftArtifactRegistry リポジトリをリセットする目的で -MicrosoftArtifactRegistry パラメーターは使えません。既存設定を変更する場合は Set-PSResourceRepository を使う必要があるため、設定変更と初回登録を混同しないようにしてください。 (Microsoft Learn)
影響を受けやすい環境
今回のGitHub documentation updateはドキュメント更新ですが、記載されているv1.3.0-preview1の内容は、次のような環境で確認価値が高いです。
| 対象環境 | 影響の見方 | 推奨対応 |
|---|---|---|
| PowerShellモジュールをCI/CDで自動取得している環境 | 取得元リポジトリや優先順位の影響を受ける可能性がある | -Repository と -Version を明示する |
| 複数リポジトリを登録している開発端末 | MAR、PSGallery、社内リポジトリの優先順が重要になる | Get-PSResourceRepository で棚卸しする |
| 社内プロキシや閉域網を使う環境 | mcr.microsoft.com への接続可否が問題になる可能性がある | プロキシ、許可リスト、監査ログを確認する |
| Azure Artifactsを使う環境 | 資格情報プロバイダー設定を確認する必要がある | CredentialProvider の対象条件を確認する |
| GitHub PackagesをNuGetリポジトリとして使う環境 | GitHub Packages自体の変更ではないが、リポジトリ指定の運用確認が必要 | PAT管理とリポジトリ明示を継続する |
特にCI/CDでは、「これまで動いていたから問題ない」と判断しないほうが安全です。プレビュー版を試す場合は、同じジョブを本番とは別のランナーや検証用コンテナで実行し、インストール元、バージョン、ログ、失敗時の再試行挙動を比較してください。
CI/CDではリポジトリ名とバージョンを明示する
PSResourceGet v1.3.0-preview1では Install-PSResource ワークフローに並列実行が追加されています。これは処理時間の短縮につながる可能性がありますが、ログの順序や失敗箇所の見え方が変わる可能性もあります。複数の依存モジュールを一括インストールするジョブでは、検証時に「成功したか」だけでなく、「どのリポジトリから何を取得したか」を確認してください。 (Microsoft Learn)
悪い例は、取得元とバージョンを曖昧にしたまま実行することです。
Install-PSResource -Name <ModuleName>検証や本番展開では、次のようにリポジトリとバージョンを明示したほうが管理しやすくなります。
Install-PSResource -Name <ModuleName> -Repository PSGallery -Version <Version>MARから取得することを意図している場合も、同じようにリポジトリを明示します。
Install-PSResource -Name <ModuleName> -Repository MicrosoftArtifactRegistry -Version <Version>社内標準モジュールを使う場合は、PSGalleryやMARではなく、社内のAzure Artifacts、GitHub Packages、JFrog Artifactory、ファイル共有、セルフホストNuGetなどを明示する運用も考えられます。Microsoft Learnでは、PSResourceGetが複数のリポジトリ種別に対応する一方で、リポジトリごとに検索・公開・認証の制約が異なることも示されています。 (Microsoft Learn)
MARは読み取り専用で、公開先としては使えない
MARはMicrosoftの公式アーティファクトを収容する公開レジストリとして説明されており、公式パッケージの発行主体をMicrosoftに限定することで、名前の乗っ取りリスクを抑え、サプライチェーンの透明性を高める意図があります。一方で、MARは読み取り専用であり、パッケージの公開には対応していません。 (Microsoft Learn)
そのため、社内モジュールや自作モジュールの公開先としてMARを検討するのは誤りです。公開先は、要件に応じて次のように分けて考えると判断しやすくなります。
| 目的 | 向いている公開先 |
|---|---|
| 一般公開するPowerShellモジュール | PowerShell Gallery |
| 社内限定のモジュール配布 | Azure Artifacts、GitHub Packages、JFrog Artifactory、MyGet、社内NuGet |
| オフライン環境への配布 | ファイル共有ベースのリポジトリ、社内ミラー |
| Microsoft公式アーティファクトの取得 | MAR |
この区別をしないまま「既定リポジトリに追加されたから公開にも使える」と判断すると、展開設計をやり直すことになります。MARは取得元として考え、公開先は別途設計してください。
Azure ArtifactsとGitHub Packages利用時の注意点
Set-PSResourceRepository の更新では、CredentialProvider が動的パラメーターであり、名前付きリポジトリがAzure Artifactsフィードの場合にのみ利用できることが説明されています。また、この動的パラメーターは既定のMicrosoftArtifactRegistryとPSGalleryでは利用できません。 (Microsoft Learn)
Azure Artifactsを使っている場合は、資格情報プロバイダーの設定が期待どおりに適用されるかを確認してください。特に、リポジトリ名を変更したり、既存の登録情報をスクリプトで上書きしたりしている環境では、CredentialProvider の指定が有効になっているかを見落としやすくなります。
GitHub PackagesをNuGetリポジトリとして使っている環境では、今回のPRがGitHub Packages自体の仕様変更を示しているわけではありません。ただし、Microsoft LearnではGitHub PackagesフィードのURI形式、認証の必要性、PATを使った公開方法、検索機能上の制約が説明されています。PSResourceGetのリポジトリ優先順位が意図せず変わると、GitHub Packagesではなく別リポジトリから取得してしまう可能性があるため、CI/CDではリポジトリ名を明示する運用が重要です。 (Microsoft Learn)
本番環境ではプレビュー版をそのまま採用しない
v1.3.0-preview1は、名前のとおりプレビューリリースです。Microsoft Learn上でも、現在の安定版は Microsoft.PowerShell.PSResourceGet v1.2.0、v1.3.0-preview1はプレビューリリースとして扱われています。 (Microsoft Learn)
本番環境で取るべき基本方針は、次の3段階です。
| 段階 | 実施内容 | 判断基準 |
|---|---|---|
| 棚卸し | 現在のPSResourceGet、PowerShellGet、登録済みリポジトリを確認 | どの端末・ランナーが影響対象か分かる |
| 検証 | v1.3.0-preview1を検証環境で試す | 取得元、認証、速度、ログ、失敗時挙動を比較できる |
| 展開判断 | 本番適用または見送りを決める | 社内リポジトリ運用とセキュリティ要件に合う |
検証時は、単にモジュールをインストールできるかだけでなく、以下を確認してください。
Get-PSResourceRepositoryの結果でMAR、PSGallery、社内リポジトリの優先順位が意図どおりかTrustedがTrueになっているリポジトリを社内ポリシー上許容できるか- プロキシ環境で
mcr.microsoft.comへの通信が許可されているか Install-PSResourceの並列実行でCI/CDログの解析に支障がないかUpdate-PSResourceがプレリリース版を含むローカルコピーを期待どおりに扱うか- 古い
Install-Moduleベースの手順と新しいInstall-PSResourceベースの手順が混在していないか
社内手順書を更新する際のポイント
今回のPRでは、リリースノートだけでなく、Register-PSResourceRepository、Set-PSResourceRepository、Reset-PSResourceRepository、Install-PSResource、Update-PSResource など複数のコマンドレット参照が更新されています。PR内の検証では、対象ドキュメントのビルド検証が通過していることも示されています。 (GitHub)
社内Wikiや運用手順書を更新する場合は、次の観点で差し替えると実務に直結します。
| 更新箇所 | 見直す内容 |
|---|---|
| モジュール導入手順 | PSResourceGetの安定版とプレビュー版を分けて記載する |
| リポジトリ登録手順 | MAR、PSGallery、社内リポジトリの優先順位を明記する |
| CI/CDテンプレート | -Repository と -Version を必須にする |
| セキュリティ手順 | Trusted リポジトリの扱いと監査方法を明記する |
| 障害対応手順 | 取得元リポジトリ、認証、プロキシ、名前解決を確認項目に入れる |
とくに「最新化」を目的にした手順では、プレビュー版を自動で取り込まないように注意が必要です。社内標準が安定版である場合、検証用途を除いてプレビュー版を導入しない、または導入対象を明確に分離する運用が安全です。
まず取るべきアクション
今回のGitHub documentation updateは、GitHubの利用者全員に影響する変更ではありません。しかし、PowerShellのパッケージ管理を自動化している組織にとっては、MARの既定リポジトリ化と優先順位の考え方が重要です。
最初に行うべきことは、対象環境で次の2つを確認することです。
Get-Module Microsoft.PowerShell.PSResourceGet -ListAvailable |
Sort-Object Version -Descending |
Select-Object Name, Version, PathGet-PSResourceRepository |
Sort-Object Priority |
Format-Table Name, Uri, Trusted, Priority, ApiVersionそのうえで、CI/CDや社内スクリプトではリポジトリ名とバージョンを明示し、v1.3.0-preview1はまず検証環境で確認してください。MARは公式アーティファクトの取得元として有用ですが、読み取り専用であり、社内モジュールの公開先にはなりません。今回の更新をきっかけに、PowerShellモジュールの取得元、信頼設定、優先順位、認証方式を一度棚卸ししておくと、将来の展開トラブルを減らせます。
コメント