PowerShellのモジュール管理をPowerShellGetのまま運用している場合、今後はPSResourceGetを前提に移行計画を立てるのが現実的です。2026年5月20日にMicrosoft PowerShell Teamが公開した公式情報では、PowerShell PSResourceの方向性として、Microsoft Artifact Registry（MAR）の活用、リポジトリ信頼設定、社内リポジトリへの集約、PowerShellGetからの移行が強く打ち出されています。(Microsoft for Developers)
特に管理者や開発者が最初に確認すべき点は、「どのリポジトリから直接インストールしているか」「本番環境が外部フィードに依存していないか」「PowerShell 7系へ移行できるか」の3つです。PSResourceGetは単なる新しいコマンド群ではなく、PowerShellパッケージをソフトウェアサプライチェーンの一部として扱うための運用基盤と考えるべきです。
PowerShell PSResourceで何が変わるのか
PowerShell PSResourceGetは、PowerShellモジュール、スクリプト、DSCリソースなどを扱うための新しいパッケージ管理ソリューションです。従来のPowerShellGetでは、Install-ModuleやInstall-Scriptのように対象ごとにコマンドが分かれていましたが、PSResourceGetではPowerShell Gallery上のパッケージを「PSResource」として統一的に扱います。(Microsoft Learn)
Microsoftの公式ブログで示された重要な方向性は、次の4点です。
| 変更点 | 実務上の意味 | まず確認すべきこと |
|---|---|---|
| MARをMicrosoft公式モジュールの信頼できる入手元として位置付け | Microsoft製モジュールの取得元を明確にできる | Microsoft製モジュールをどこから取得しているか |
| PowerShell Galleryを本番環境の直接依存先にしない | 外部コミュニティリポジトリへの依存を減らす | 本番サーバーやCI/CDがPSGalleryへ直接アクセスしていないか |
| 社内の承認済みリポジトリを中心に運用 | レビュー、スキャン、承認済みバージョンの配布がしやすい | Azure Artifacts、ACR、ファイル共有などの候補 |
| PSResourceGet 1.3以降でPowerShell Core寄りの方向性 | Windows PowerShell 5.1中心の運用は見直しが必要 | PowerShell 7系へ移行できない端末・サーバーの有無 |
ここで重要なのは、「新しいコマンドに置き換える」だけでは不十分という点です。PowerShell PSResourceのロードマップは、モジュールの取得元、信頼設定、承認プロセス、本番環境でのインストール方法まで含めた運用変更を求めています。
PowerShellGetからPSResourceGetへの移行で押さえるべき違い
PowerShellGetからPSResourceGetへ移行する際は、コマンド名の違いだけでなく、リポジトリの扱い方と依存関係の管理を確認する必要があります。
Microsoft Learnでは、PowerShell 7.4以降にはMicrosoft.PowerShell.PSResourceGetが含まれており、PSResourceGetはPowerShellGetやPackageManagementを使わずにPowerShellリソースを管理できる新しいソリューションと説明されています。PowerShellGetやPackageManagementとはサイドバイサイドで導入されるため、既存環境をすぐに壊すものではありません。(Microsoft Learn)
主なコマンド対応は次のとおりです。
| 従来のPowerShellGet | PSResourceGet | 用途 |
|---|---|---|
Find-Module / Find-Script | Find-PSResource | モジュールやスクリプトを検索 |
Install-Module / Install-Script | Install-PSResource | リソースをインストール |
Save-Module / Save-Script | Save-PSResource | リソースをローカルや検証環境へ保存 |
Update-Module / Update-Script | Update-PSResource | インストール済みリソースを更新 |
Get-InstalledModule / Get-InstalledScript | Get-InstalledPSResource | インストール済みリソースを確認 |
Register-PSRepository | Register-PSResourceRepository | リポジトリを登録 |
Set-PSRepository | Set-PSResourceRepository | リポジトリ設定を変更 |
Unregister-PSRepository | Unregister-PSResourceRepository | リポジトリ登録を解除 |
たとえば、従来の次のコマンドは、
Install-Module -Name Az -Repository PSGallery -Scope CurrentUserPSResourceGetでは次のように書き換えます。
Install-PSResource -Name Az -Repository PSGallery -Scope CurrentUserInstall-PSResourceは、PowerShellGet v2のInstall-ModuleとInstall-Scriptの機能を統合したコマンドです。ただし、インストールしたモジュールは現在のセッションに自動読み込みされないため、必要に応じてImport-Moduleするか、新しいセッションを開始します。(Microsoft Learn)
まず実施すべき移行前チェック
PowerShellGetからの移行では、いきなり全スクリプトを書き換えるよりも、現在の状態を棚卸しする方が失敗しにくくなります。
インストール済みバージョンを確認する
まず、PowerShellGet、PackageManagement、PSResourceGetの導入状況を確認します。
$Names = @(
'PowerShellGet',
'PackageManagement',
'Microsoft.PowerShell.PSResourceGet'
)
Get-Module -Name $Names -ListAvailable |
Select-Object Name, Version, PathPowerShell 7.4以降ではPSResourceGetが含まれますが、Windows PowerShell 5.1では古いPowerShellGetが残っている環境もあります。Windows PowerShell 5.1に標準搭載されるPowerShellGet 1.0.0.1は機能が限られるため、PSResourceGet導入前にPowerShellGetの更新が必要になる場合があります。(Microsoft Learn)
既存リポジトリを確認する
次に、PowerShellGet側とPSResourceGet側のリポジトリを確認します。
Get-PSRepository
Get-PSResourceRepositoryPowerShellGet v2で登録済みのNuGetリポジトリは、Import-PSGetRepositoryでPSResourceGetへ取り込めます。ただし、このコマンドが取り込むのはNuGetリポジトリのみで、PSGalleryは既定で登録されるためインポート対象外です。(Microsoft Learn)
Import-PSGetRepository -Verbose -WhatIf-WhatIfで内容を確認してから、問題なければ実行します。
Import-PSGetRepository同名のリポジトリがすでに登録されている場合は上書きされません。上書きする場合のみ、影響範囲を確認してから-Forceを使います。
Import-PSGetRepository -Force既存スクリプトのコマンドを棚卸しする
管理スクリプト、CI/CD、構成管理、オンボーディング手順書などに、次のようなコマンドが残っていないか確認します。
Select-String -Path .\*.ps1 -Pattern 'Install-Module|Save-Module|Update-Module|Find-Module|Register-PSRepository' -List移行対象は、単純なインストールスクリプトだけではありません。GitHub Actions、Azure DevOps Pipeline、Intune配布スクリプト、VDI初期化処理、Windows Serverの構築手順にもPowerShellGetコマンドが埋め込まれていることがあります。
リポジトリ運用の考え方：発見用と本番用を分ける
今回の公式情報で最も重要なのは、PowerShell Galleryを「本番環境が直接依存する場所」ではなく、「発見・検証の入口」として扱うべきだという点です。
Microsoft PowerShell Teamは、PowerShell Galleryについて、PowerShellエコシステムにとって重要なコミュニティリポジトリである一方、セキュリティ面では既定で信頼しない、コミュニティ所有、本番ワークロードの直接依存先には適さない、という扱いを示しています。(Microsoft for Developers)
実務では、次のように役割を分けると運用しやすくなります。
| リポジトリ | 役割 | 本番環境からの直接利用 | 運用ポイント |
|---|---|---|---|
| Microsoft Artifact Registry（MAR） | Microsoft公式モジュールの信頼元 | 条件付きで利用候補 | Microsoft製モジュールの取得元として優先 |
| PowerShell Gallery | コミュニティモジュールの発見・検証 | 原則避ける | 検証後に社内リポジトリへ昇格 |
| Azure Artifacts | 社内承認済みNuGetフィード | 推奨 | 承認済みバージョンを配布 |
| Azure Container Registry（ACR） | OCIレジストリを使った社内管理 | 推奨候補 | ID、RBAC、監査と組み合わせる |
| ファイル共有リポジトリ | 小規模・閉域環境向け | 条件付きで可 | SMB/NFSのアクセス制御を厳格化 |
本番環境では、PowerShell Galleryからその場でInstall-PSResourceするのではなく、検証済みパッケージだけを社内リポジトリに配置し、そこからインストールする構成が安全です。
Microsoft Artifact Registry（MAR）はどう扱うべきか
Microsoft Artifact Registry（MAR）は、Microsoftが所有・公開するPowerShellモジュールの信頼できる入手元として位置付けられています。Microsoftの公式ブログでは、MARによりMicrosoft管理の公開パイプライン、由来や所有権の保証、PowerShell Galleryより改善された可用性が期待できると説明されています。(Microsoft for Developers)
PSResourceGet 1.3.0-preview1では、MARを既定の登録済みリポジトリとして追加する変更が含まれています。Microsoft Learnのリポジトリ構成ドキュメントでは、MARはMicrosoftArtifactRegistryという名前で、https://mcr.microsoft.com/をURIとし、TrustedがTrue、Priorityが40、API VersionがContainerRegistryとして登録されると説明されています。(Microsoft Learn)
MARを手動登録する場合は、次のコマンドを使います。
Register-PSResourceRepository -MicrosoftArtifactRegistry確認は次のように行います。
Get-PSResourceRepository |
Sort-Object Priority |
Format-Table Name, Uri, Trusted, Priority, ApiVersion注意したいのは、MARが「すべてのPowerShellモジュールの置き場」ではないことです。Microsoft公式モジュールの取得元として使い、コミュニティモジュールや社内モジュールは別の承認済みリポジトリで管理するのが基本です。
PowerShell Galleryを本番で直接使わない理由
PowerShell Galleryは、モジュールの発見や検証には便利です。しかし、誰でも公開できるコミュニティリポジトリである以上、本番環境の自動化スクリプトが直接依存する形は避けるべきです。
失敗しやすい例は、次のような構成です。
Install-PSResource -Name SomeModule -Repository PSGallery -TrustRepository -AcceptLicenseこのコマンド自体が常に悪いわけではありません。検証環境でモジュールを試す用途なら問題ない場面もあります。ただし、本番サーバーの初期構築やCI/CDのデプロイ処理で使うと、次のリスクがあります。
| リスク | 具体例 | 対策 |
|---|---|---|
| 取得元の統制不足 | 似た名前のモジュール、所有者変更、意図しない依存関係 | 社内承認済みリポジトリへ昇格してから利用 |
| バージョン差分 | 実行タイミングにより最新版が変わる | バージョン固定または範囲指定 |
| 可用性への依存 | 外部サービス障害やネットワーク制限で構築失敗 | 社内ミラーやキャッシュを利用 |
| 監査不足 | 誰が何を導入したか追跡しづらい | 承認フローとログを残す |
| 秘密情報の扱い | PATやAPIキーをスクリプトに直書き | SecretManagementなどを利用 |
特に-TrustRepositoryは、未信頼リポジトリへの確認プロンプトを抑制するためのパラメーターです。自動化には便利ですが、「検証済みだから信頼する」のではなく「プロンプトが邪魔だから付ける」という使い方をすると、リポジトリ統制を形骸化させます。Install-PSResourceでは、未信頼リポジトリに対する信頼確認プロンプトを-TrustRepositoryで抑制できます。(Microsoft Learn)
社内リポジトリ運用のベストプラクティス
企業やチームでPowerShell PSResourceを使う場合は、中央のプライベートリポジトリを「本番環境が信頼する唯一の取得元」として設計するのが基本です。Microsoft PowerShell Teamも、承認済みパッケージのみを含む中央のプライベートリポジトリを本番システムの信頼元にするパターンを推奨しています。(Microsoft for Developers)
推奨フロー
PowerShell Gallery / MAR / パートナー提供元
↓
検証環境でレビュー
↓
セキュリティ・ライセンス・互換性確認
↓
社内リポジトリへ昇格
↓
本番環境は社内リポジトリのみ利用この流れにすると、本番環境の自動化処理が外部フィードの状態に左右されにくくなります。
社内リポジトリ登録例
Azure ArtifactsなどのNuGetフィードを使う場合は、次のように登録します。
$params = @{
Name = 'CorpPowerShell'
Uri = 'https://pkgs.dev.azure.com/contoso/_packaging/powershell/nuget/v3/index.json'
Trusted = $true
Priority = 10
}
Register-PSResourceRepository @paramsその後、本番用スクリプトではリポジトリ名を明示します。
Install-PSResource -Name Az.Accounts -Repository CorpPowerShell -Version '3.0.0' -Scope AllUsersRegister-PSResourceRepositoryでは、名前、URI、Trusted、Priorityなどを指定してリポジトリを登録できます。またAzure Artifactsフィードでは、URLに応じてAzure Artifacts Credential Providerが使われる設定になる場合があります。(Microsoft Learn)
優先度は「本番で使ってよい順」に設定する
PSResourceGetでは、複数リポジトリを検索する場合、Priorityの値が小さいリポジトリほど優先されます。Install-PSResourceは、優先順位に従って最初に見つかったパッケージをインストールします。(Microsoft Learn)
たとえば、社内リポジトリを最優先にしたい場合は次のようにします。
Get-PSResourceRepository |
Sort-Object Priority |
Format-Table Name, Trusted, Priority, Uri望ましい例は次のような並びです。
| Priority | Repository | Trusted | 用途 |
|---|---|---|---|
| 10 | CorpPowerShell | True | 本番用の承認済み社内リポジトリ |
| 40 | MicrosoftArtifactRegistry | True | Microsoft公式モジュール |
| 50 | PSGallery | False | 検証・探索用 |
本番環境では、リポジトリ名を明示せずにInstall-PSResource -Name モジュール名だけで実行する運用は避けた方が安全です。どのリポジトリから取得されたかが、優先度や登録状況に依存するためです。
スクリプト自動化で見直すべき書き方
PSResourceGetへの移行では、スクリプトの「動く・動かない」だけでなく、再現性を高める書き方に変えることが重要です。
バージョンを固定または範囲指定する
最新版を毎回取得する書き方は、検証環境と本番環境で挙動が変わる原因になります。
避けたい例です。
Install-PSResource -Name Az.Accounts -Repository CorpPowerShell本番では、少なくとも明示的にバージョンを指定します。
Install-PSResource -Name Az.Accounts -Repository CorpPowerShell -Version '3.0.0'互換性のある範囲で更新を許容する場合は、NuGetのバージョン範囲構文を使います。PSResourceGetのVersionパラメーターは、NuGetのバージョン範囲構文を利用できます。(Microsoft Learn)
Install-PSResource -Name Az.Accounts -Repository CorpPowerShell -Version '[3.0.0,4.0.0)'この例では、3.0.0以上、4.0.0未満を対象にします。大規模環境では「完全固定」と「範囲指定」を使い分けます。
| シーン | 推奨 | 理由 |
|---|---|---|
| 本番サーバー構築 | 完全固定 | 再現性を最優先するため |
| CIの検証ジョブ | 範囲指定 | 互換性のある更新を早期検知できるため |
| 開発者PC | 範囲指定または最新版 | 検証・探索の自由度を残すため |
| 監査対象システム | 完全固定 | 変更履歴を説明しやすくするため |
RequiredResourceFileで依存モジュールをまとめる
複数モジュールをまとめて管理する場合は、インストールコマンドを何行も並べるより、.psd1または.jsonのRequiredResourceFileを使うと管理しやすくなります。Install-PSResourceには、.psd1や.jsonで指定したリソースをインストールする-RequiredResourceFileパラメーターがあります。(Microsoft Learn)
例として、required-resources.psd1を用意します。
@{
'Az.Accounts' = @{
version = '3.0.0'
repository = 'CorpPowerShell'
}
'Pester' = @{
version = '[5.6.0,6.0.0)'
repository = 'CorpPowerShell'
}
'Microsoft.Graph.Authentication' = @{
version = '2.26.1'
repository = 'CorpPowerShell'
}
}インストールは次の1行です。
Install-PSResource -RequiredResourceFile .\required-resources.psd1 -Scope AllUsersこの形式にすると、レビュー対象が「スクリプトの処理」ではなく「必要なモジュールとバージョン一覧」になります。変更管理やPull Requestレビューとの相性も良くなります。
Save-PSResourceで検証・昇格フローを作る
外部リポジトリから取得したモジュールをすぐ本番に入れるのではなく、一度保存して検証する場合はSave-PSResourceを使います。Save-PSResourceは、PowerShellGet v2のSave-ModuleとSave-Scriptを統合したコマンドで、リソースを指定パスへ保存できます。.nupkg形式で保存することも可能です。(Microsoft Learn)
Save-PSResource -Name Pester -Repository PSGallery -Version '5.6.1' -Path .\intakeパッケージとして保存したい場合は次のようにします。
Save-PSResource -Name Pester -Repository PSGallery -Version '5.6.1' -AsNupkg -Path .\packages検証後に社内リポジトリへ公開する流れにすれば、取得元と本番配布元を分離できます。
認証情報とAPIキーをスクリプトに直書きしない
社内リポジトリ、Azure Artifacts、MyGet、NuGetサーバーなどを使う場合、APIキーやPATを扱う場面があります。ここで避けるべきなのは、次のような直書きです。
$ApiKey = 'xxxxxxxxxxxxxxxx'
Publish-PSResource -Path .\MyModule -Repository CorpPowerShell -ApiKey $ApiKeyMicrosoft Learnのリポジトリ構成ドキュメントでも、資格情報を平文でスクリプトに書くべきではなく、SecretManagementモジュールなどを使って安全に保存・取得することが推奨されています。(Microsoft Learn)
登録例として、SecretManagementのボールトに保存したシークレットを参照する形があります。
$credentialInfo = [Microsoft.PowerShell.PSResourceGet.UtilClasses.PSCredentialInfo]::new(
'SecretStore',
'CorpPowerShellToken'
)
$params = @{
Name = 'CorpPowerShell'
Uri = 'https://pkgs.dev.azure.com/contoso/_packaging/powershell/nuget/v3/index.json'
Trusted = $true
Priority = 10
CredentialInfo = $credentialInfo
}
Register-PSResourceRepository @paramsポイントは、スクリプト内に秘密情報そのものを持たせないことです。CI/CDでは、Azure DevOpsのシークレット変数、GitHub ActionsのSecrets、管理対象IDなど、実行基盤側の仕組みと組み合わせて管理します。
Windows PowerShell 5.1環境はどう考えるべきか
PowerShell PSResourceのロードマップで注意すべき点の一つが、Windows PowerShellサポートの扱いです。Microsoft PowerShell Teamは、PSResourceGetの将来バージョン、具体的には1.3以降について、PowerShell Coreを中心とする方向に合わせ、Windows PowerShellサポートを外す方向性を示しています。(Microsoft for Developers)
一方で、現行ドキュメントではWindows PowerShell 5.1にPSResourceGetを導入するための説明も残っています。つまり、すでにWindows PowerShell 5.1で動いている既存環境が即座に使えなくなると断定する必要はありません。ただし、新機能や今後の改善を前提にするなら、PowerShell 7系への移行計画を並行して進めるべきです。
判断基準は次のとおりです。
| 環境 | 方針 |
|---|---|
| 新規構築の管理端末・CI/CD | PowerShell 7系を標準にする |
| 既存のWindows Server運用スクリプト | 影響調査後に段階移行 |
| Windows PowerShell 5.1でしか動かないモジュールがある環境 | 互換性検証を優先し、無理に即時移行しない |
| 長期運用する自動化基盤 | PowerShell 7系とPSResourceGet前提で再設計 |
特に、Active Directory管理、古いExchange関連モジュール、オンプレミス製品の管理モジュールなどは、Windows PowerShell 5.1依存が残りやすい領域です。PSResourceGet移行とPowerShell 7移行を同時に進めると切り分けが難しくなるため、まずモジュール取得方法を棚卸しし、次に実行ランタイムを検証する順序が安全です。
PSResourceGet 1.3のロードマップで注目すべき機能
PSResourceGet 1.3.0-preview1では、MARの既定リポジトリ追加、Install-PSResourceワークフローの並列実行、DSC v3リソースの追加が新機能として示されています。(Microsoft Learn)
MARの既定リポジトリ化
Microsoft製モジュールをどこから取得すべきかが明確になります。これにより、コミュニティリポジトリ上の同名・類似名パッケージに依存するリスクを下げやすくなります。
Install-PSResourceの並列実行
大規模な自動化やCI/CDでは、複数モジュールのインストール時間がボトルネックになることがあります。1.3系のロードマップでは、Install-PSResourceワークフローの並列実行が含まれており、将来的に大規模展開の効率改善が期待できます。(Microsoft for Developers)
ただし、プレビュー機能を本番へすぐ投入するのは避け、検証環境でパフォーマンスと依存関係の挙動を確認してから判断します。
DSC v3リソース対応
DSCを使って構成管理を行っている環境では、PSResourceGetがDSC v3リソースを提供する方向性にも注目です。Microsoftの公式ブログでは、従来のRequiredResourceFilesのような仕組みに依存するのではなく、ネイティブなDSCリソースサポート、構成成果物の一貫した扱い、現代的なDSCワークフローとの統合を進めると説明されています。(Microsoft for Developers)
移行時に起きやすいトラブルと対策
PowerShell PSResourceへの移行では、コマンド置換だけを進めると次のような問題が起きやすくなります。
| トラブル | 原因 | 対策 |
|---|---|---|
| 期待と違うリポジトリからインストールされる | Repositoryを省略し、Priorityに依存している | 本番では-Repositoryを明示する |
| 自動化ジョブでプロンプトが出て止まる | 未信頼リポジトリやライセンス確認がある | Trusted設定、-AcceptLicense、事前承認を整理 |
| モジュール更新後に動作が変わる | バージョン固定していない | -VersionまたはRequiredResourceFileを使う |
| 既存のPowerShellGetリポジトリが見つからない | PSResourceGet側に登録していない | Import-PSGetRepository -WhatIfで確認して移行 |
| Windows PowerShell 5.1で動かない | 将来バージョンのサポート方針や互換性差分 | PowerShell 7系への移行計画を作る |
| 依存関係の解決で失敗する | リポジトリ種別やNuGet v3の制限 | 依存モジュールを個別に承認・昇格する |
特に注意したいのは、NuGet v3リポジトリを使う場合の依存関係です。Install-PSResourceのドキュメントでは、NuGet v3プロトコルのリポジトリから依存リソースをインストールしないため、依存リソースを個別にインストールする必要があり、将来リリースで対応予定とされています。(Microsoft Learn)
この制限を踏まえると、社内リポジトリへ昇格する際は、対象モジュールだけでなく依存モジュールも含めて承認・登録する運用が必要です。
管理者・開発者向けの実践チェックリスト
PowerShell PSResourceGetへ移行する際は、次の順で進めると実務上の手戻りを減らせます。
| 手順 | 作業 | 確認コマンド・観点 |
| -: | ———————– | ———————————————————————————————- |
| 1 | 実行環境を確認 | Get-Host、$PSVersionTable |
| 2 | モジュール管理ツールを確認 | Get-Module PowerShellGet,PackageManagement,Microsoft.PowerShell.PSResourceGet -ListAvailable |
| 3 | 登録済みリポジトリを棚卸し | Get-PSRepository、Get-PSResourceRepository |
| 4 | PowerShellGet側のリポジトリを移行 | Import-PSGetRepository -Verbose -WhatIf |
| 5 | 本番用リポジトリを決める | Azure Artifacts、ACR、社内NuGet、ファイル共有など |
| 6 | TrustとPriorityを設計 | 社内リポジトリをTrustedかつ最優先にする |
| 7 | 既存スクリプトを書き換える | Install-ModuleからInstall-PSResourceへ |
| 8 | バージョン固定を導入 | -VersionまたはRequiredResourceFile |
| 9 | 検証済みパッケージだけ昇格 | Save-PSResource、レビュー、スキャン |
| 10 | 本番で外部フィードを遮断・制限 | ネットワーク、プロキシ、実行ポリシー、監査ログ |
小規模チームなら、まずは「本番スクリプトでPSGalleryを直接使わない」だけでも効果があります。大規模組織なら、社内フィード、承認フロー、SecretManagement、CI/CDのテンプレート化まで含めて標準化すると、PowerShellモジュール管理の属人性を減らせます。
今後のPowerShellモジュール管理は「取得元の設計」が重要
PowerShell PSResourceのロードマップは、単にPowerShellGetの後継コマンドを覚える話ではありません。Microsoft公式モジュールはMAR、コミュニティモジュールはPowerShell Galleryで発見し、承認済みパッケージは社内リポジトリから本番配布する、という役割分担が重要です。
最初に取り組むべきことは、次の3つです。
1つ目は、既存スクリプト内のInstall-Module、Save-Module、Register-PSRepositoryを棚卸しすることです。2つ目は、本番環境がどのリポジトリへアクセスしているかを確認し、社内の承認済みリポジトリへ集約することです。3つ目は、PowerShell 7系とPSResourceGetを前提に、今後のモジュール管理手順を標準化することです。
PowerShellの自動化は、スクリプト本体だけでなく、利用するモジュールの取得元まで含めて信頼性が決まります。PSResourceGetへの移行を機に、モジュール管理を「その場でインストールする作業」から「承認済み資産を安全に配布する仕組み」へ変えていきましょう。
コメント