2026年4月29日にMicrosoft PowerShell Teamが公開した「Announcing Microsoft Desired State Configuration v3.2.0」は、Windows管理者・開発者・Microsoftエコシステムを追う読者にとって見逃せない更新です。結論から言うと、Microsoft Desired State Configuration v3.2.0は、Windowsリソースの拡充、個別リソースへのWhatIf対応、バージョン固定、Bicep連携の強化により、Windows構成をより安全にコード化しやすくするリリースです。(Microsoft for Developers)
特にWindows運用の現場では、「サービス設定」「Windows機能」「ファイアウォールルール」「OpenSSH Server設定」を構成管理の対象にしやすくなりました。一方で、Bicep連携や一部の拡張機能は実験的な位置づけを含むため、いきなり本番全体へ展開するのではなく、検証環境で--what-ifとバージョン固定を組み合わせて評価するのが現実的です。(Microsoft for Developers)
Microsoft Desired State Configuration v3.2.0とは
Microsoft Desired State Configuration、通称DSCは、マシンやアプリケーション環境を「こうあるべき状態」として宣言的に定義するための構成管理プラットフォームです。手順を順番に書くスクリプトではなく、到達したい状態をJSONやYAMLで記述し、DSCが現在の状態との差分を確認・適用します。Microsoft Learnでは、DSCを宣言型の構成プラットフォームとして説明しており、dscコマンドはWindows、Linux、macOSで動作するとされています。(Microsoft Learn)
従来のPowerShell DSCを知っている読者は、「PowerShell専用の構成管理」と捉えがちですが、DSC v3系はそれより広い位置づけです。Microsoft Learnによると、DSC v3はPowerShellやWindows PowerShellへの依存を前提にせず、bash、Python、C#、Rustなどで書かれたリソースも扱える設計になっています。また、従来のLocal Configuration Managerのようにサービスとして常駐するのではなく、コマンドとして呼び出されます。(Microsoft Learn)
つまり、DSC v3.2.0は「PowerShell管理者だけの更新」ではありません。Windows運用、IaC、Bicep、GitOps、セキュリティ標準化、開発環境の再現性に関わる人が確認すべきアップデートです。
DSC v3.2.0で押さえるべき主な変更点
DSC v3.2.0の公式発表では、General Availabilityとしての提供に加え、新しいWindowsリソース、BicepのgRPC連携、WhatIf対応の拡張、式言語の改善、アダプター改善などが紹介されています。(Microsoft for Developers)
| 更新内容 | 何が変わったか | 実務で見るべきポイント |
|---|---|---|
| 新しいWindowsリソース | Windowsサービス、Optional Features、Features on Demand、ファイアウォール、OpenSSH Server設定などを標準リソースで扱える範囲が拡大 | Windows構成の標準化をカスタムスクリプトだけに頼らず進めやすい |
dsc resource set --what-if | 個別リソース単位で変更前のプレビューが可能 | 変更申請や本番前レビューで使いやすい |
| バージョン固定 | DSC本体やリソースのバージョン条件を構成ドキュメントに指定可能 | 「環境によって違うリソース版が使われる」事故を抑えやすい |
| Bicep gRPC連携 | BicepからDSCリソースを直接オーケストレーションする基盤を追加 | Azure/IaC担当者は将来の構成管理連携として要注目 |
| 式言語の改善 | map()、filter()、dataUri()、reference()などの利用範囲が拡大 | 同じ値の重複記述を減らし、構成ドキュメントを保守しやすくする |
| アダプター改善 | PowerShellアダプターやリソースマニフェスト周りを改善 | 既存のPowerShell資産やPSDSCリソースを扱うチームに影響 |
| 拡張機能の強化 | 構成のインポートやシークレット取得の能力を拡張 | 将来的に多様な構成ファイル形式や秘密情報管理と連携しやすくなる |
Windows管理者が特に注目すべき新しいWindowsリソース
今回の更新で最も分かりやすく実務に効くのは、新しいWindows向け組み込みリソースです。公式発表では、次のようなリソースがDSC v3.2.0に含まれると説明されています。(Microsoft for Developers)
| リソース | 管理できる対象 | 活用例 |
|---|---|---|
Microsoft.Windows/Service | Windowsサービス | 特定サービスの起動種類を標準化する |
Microsoft.Windows/OptionalFeatureList | Windows Optional Features | 必要なWindows機能の有効・無効を管理する |
Microsoft.Windows/FeatureOnDemandList | Windows Features on Demand | 言語機能や追加機能の構成管理に使う |
Microsoft.Windows/FirewallRuleList | Windowsファイアウォールルール | サーバーや端末ごとのルール差異を抑える |
Microsoft.OpenSSH.SSHD/sshd_config | OpenSSH Server全体の設定 | SSHサーバー設定をコードで管理する |
Microsoft.OpenSSH.SSHD/Subsystem、Microsoft.OpenSSH.SSHD/SubsystemList | OpenSSHのサブシステム設定 | SFTPなどのサブシステム設定を管理する |
Microsoft.OpenSSH.SSHD/Windows | Windows固有のOpenSSH設定 | 既定シェルなどWindows側のSSH設定を管理する |
注意したいのは、Microsoft.Windows/OptionalFeatureListとMicrosoft.Windows/FeatureOnDemandListは、現時点ではZIPパッケージ版のDSCを使う必要があると公式発表で説明されている点です。Microsoft Store経由のインストールだけで検証していると、期待したリソースが使えずに詰まる可能性があります。(Microsoft for Developers)
実務では、最初から全社端末や本番サーバーへ展開するより、まずは影響範囲が明確な設定から試すのが安全です。たとえば、検証用Windows Serverで特定サービスの起動種類を確認し、次にファイアウォールルールやOpenSSH設定へ広げる、といった進め方が向いています。
WhatIf対応で本番適用前の確認がしやすくなった
DSC v3.2.0では、dsc resource setコマンドに--what-ifが追加されました。これにより、構成全体ではなく個別リソース単位で「適用したら何が変わるか」を確認できます。公式発表によると、従来はdsc config setで構成全体に対して--what-ifを使うことはできましたが、個別リソースに対して実行する方法はありませんでした。(Microsoft for Developers)
たとえば、Windowsサービスの設定変更を事前確認する場合は、次のような使い方が想定できます。
dsc resource set --what-if --resource Microsoft.Windows/Service --input '{
"name": "spooler",
"startupType": "disabled"
}'この機能は、変更管理プロセスがある組織ほど役立ちます。作業前にWhatIfの結果を残しておけば、変更申請やレビューで「何を変える予定なのか」を説明しやすくなります。
ただし、WhatIfはバックアップやロールバック手順の代替ではありません。実際の適用時には、権限、依存サービス、再起動要否、グループポリシーやMDMによる上書きなど、プレビューだけでは見落としやすい条件があります。本番環境では、WhatIf、検証環境での適用、戻し手順の確認をセットで扱うべきです。
バージョン固定は構成管理の再現性を高める
DSC v3.2.0では、構成ドキュメントを特定のDSCバージョンに固定したり、構成内のリソースインスタンスを特定のリソースバージョンに固定したりできます。公式発表では、versionディレクティブとrequireVersionフィールドによるバージョン指定が紹介されています。(Microsoft for Developers)
directives:
version: '=3.2.0'
resources:
- name: os
type: Microsoft/OSInfo
requireVersion: '^1.0'
properties: {}この変更は、CI/CDやGitOps的にWindows構成を管理したいチームにとって重要です。バージョン固定がない場合、ある端末では新しいリソース、別の端末では古いリソースが使われ、同じ構成ドキュメントでも結果がずれる可能性があります。
公式発表によると、指定条件に合うリソースがシステム上で見つからない場合、DSCはエラーを返します。また、versionディレクティブを指定した場合、構成ドキュメントを処理するDSCのバージョンが互換条件を満たさなければエラーになります。これは面倒に見えますが、本番運用ではむしろ安全側の挙動です。(Microsoft for Developers)
Bicep gRPC連携は将来のIaC連携として見る
DSC v3.2.0では、BicepがDSCリソースを直接オーケストレーションできるようにするためのgRPCサーバーが導入されました。公式発表では、dsc-bicep-ext拡張がMSIXパッケージに含まれ、PATH上で利用できると説明されています。また、この連携はARMを経由せず、BicepがgRPC経由でDSCの実行をオーケストレーションする基盤とされています。(Microsoft for Developers)
ここで大切なのは、Bicep連携が「experimental」と明記されている点です。Azureリソースの定義にBicepを使っているチームにとっては魅力的ですが、すぐに本番構成管理の中心へ置くより、まずは検証プロジェクトで挙動を確認する段階と考えるのが安全です。
特に、次のような観点で検証すると実用性を判断しやすくなります。
| 確認項目 | 見るべきポイント |
|---|---|
| 実行経路 | BicepからDSC実行までの流れをチームが説明できるか |
| 失敗時の扱い | エラー内容、再実行、ロールバック判断が明確か |
| 権限 | DSC実行に必要な権限を過不足なく付与できるか |
| 既存IaCとの関係 | ARM/Bicep、Azure Policy、Azure Machine Configurationなどとの役割分担が整理できるか |
| 監査 | 誰が、いつ、どの構成を適用したかを追跡できるか |
式言語の改善で構成ドキュメントが書きやすくなる
DSC v3.2.0では、構成ドキュメントの式言語も改善されています。公式発表では、map()やfilter()を使うラムダ式、dataUri()、dataUriToString()、copyループ内でのreference()利用、そしてバージョン要件としてのrequireVersionが紹介されています。(Microsoft for Developers)
これは一見すると開発者向けの細かい変更に見えますが、運用現場にも効果があります。たとえば、複数のサービスやファイアウォールルールを似たパターンで定義する場合、値を何度も手書きするとミスが増えます。式言語が強化されることで、重複記述を減らし、構成ドキュメントを読みやすく保ちやすくなります。
ただし、式を使いすぎると、今度は構成ファイルが読みにくくなります。運用チームでは、「誰が見ても意図が分かること」を優先し、複雑な式を使う場合はコメントや設計メモを残すのがよいでしょう。
アダプター改善と拡張機能は既存資産を持つチームに効く
DSC v3.2.0では、PowerShellアダプターや適応リソースマニフェストに関する改善も含まれています。公式発表では、PowerShellストリームをDSCトレースへ自動変換できること、適応PSDSCリソースインスタンスへの資格情報渡しの修正、重い探索処理を避けるための適応リソースマニフェスト対応などが説明されています。(Microsoft for Developers)
既存のPowerShell DSC資産を持っている組織では、この部分が重要です。新しいDSCへ移行する場合でも、すべてを一から書き直すのではなく、既存資産をどの程度再利用できるかが導入判断に直結します。
また、DSC v3.2.0では、構成のインポートとシークレット取得に関する新しい拡張機能も追加されています。公式発表では、任意のファイルをDSC構成ドキュメントとして処理するimport能力と、実行時に名前でシークレットを取得するsecret能力が紹介されています。(Microsoft for Developers)
この方向性は、将来的に「構成ファイルの形式を柔軟にする」「秘密情報を構成ファイルへ直書きしない」といった運用へつながります。ただし、シークレット管理はセキュリティ上の影響が大きいため、どのストアから取得するのか、アクセス権をどう管理するのか、ログに値が出ないかを必ず確認する必要があります。
導入前に判断すべきポイント
DSC v3.2.0はGAリリースですが、すべての機能を同じ温度感で本番投入すべきという意味ではありません。Windows運用での導入判断は、次のように分けると整理しやすくなります。
| 利用シーン | 導入判断 | 最初にやること |
|---|---|---|
| Windowsサービス設定を標準化したい | 比較的検証しやすい | 検証端末でMicrosoft.Windows/Serviceを使い、--what-if結果を確認する |
| ファイアウォールルールを管理したい | 慎重に進める | リモート接続を失わないよう、検証環境とロールバック手順を用意する |
| Optional FeaturesやFeatures on Demandを管理したい | パッケージ方式に注意 | ZIP版DSCで検証し、Store版だけで進めない |
| 既存のPowerShell DSC資産を使いたい | 互換性確認が必要 | アダプター経由で既存リソースが期待通り動くか確認する |
| Bicepと組み合わせたい | 検証段階として扱う | experimentalであることを前提に、PoCで実行経路と権限を確認する |
| 本番サーバーへ適用したい | 段階導入が必須 | バージョン固定、WhatIf、変更記録、戻し手順をセットにする |
特に本番サーバーでは、「便利そうだからすぐ適用する」よりも、「どの設定をDSCで管理し、どの設定は既存のGPO、Intune、MDM、手動運用に残すのか」を先に決めることが重要です。複数の構成管理手段が同じ項目を上書きし合うと、原因調査が難しくなります。
DSC v3.2.0をWindowsで試す基本手順
WindowsでDSCを試す場合、公式発表ではMicrosoft Store経由のwingetインストールと、GitHubリリースからZIPパッケージを入手する方法が案内されています。Storeからインストールすると自動更新を受けられる一方、Optional FeaturesやFeatures on Demandのリソース検証ではZIPパッケージが必要とされています。(Microsoft for Developers)
安定版を探すには、次のコマンドを使います。
winget search DesiredStateConfiguration --source msstore安定版をインストールする場合は、公式発表で示されているIDを使います。
winget install --id 9NVTPZWRC6KQ --source msstore検証を始めるときは、いきなりsetで適用するのではなく、次の順序で進めると失敗しにくくなります。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 検証用のWindows環境を用意する | 本番影響を避ける |
| 2 | DSCのインストール方式を決める | Store版かZIP版かを明確にする |
| 3 | 利用可能なリソースを確認する | 期待するリソースが見えているか確認する |
| 4 | getやtestで現在状態を確認する | 変更前の状態を把握する |
| 5 | --what-ifで差分を確認する | 適用前に変更内容をレビューする |
| 6 | 小さい対象にだけ適用する | 影響範囲を限定する |
| 7 | バージョン固定を追加する | 再現性を高める |
| 8 | 適用結果と戻し手順を記録する | 運用に載せる準備をする |
運用に組み込む場合は、DSC本体やリソースの更新タイミングも管理対象に含める必要があります。公式発表では、DSC v3.2.0が現在の安定版であり、安定版は次の安定版リリース後3カ月間、重大なバグやセキュリティ脆弱性に対するパッチを受けると説明されています。また、利用中リリースの最新パッチへ更新することも推奨されています。(Microsoft for Developers)
失敗しやすいポイント
GAリリースと実験的機能を混同する
DSC v3.2.0自体はGeneral Availabilityとして発表されていますが、Bicep gRPC連携やPowerShell検出拡張のように実験的な位置づけの機能も含まれます。GAだからすべてを本番標準にしてよい、とは考えない方が安全です。(Microsoft for Developers)
本番利用しやすい機能と、検証段階で追うべき機能を分けて扱いましょう。Windowsサービス管理やWhatIf、バージョン固定は比較的すぐ検証しやすい一方、Bicep連携は実行経路や権限設計まで含めて確認する必要があります。
パッケージ方式の違いを見落とす
WindowsではMicrosoft Store経由のwingetインストールが便利ですが、一部のWindowsリソースではZIPパッケージが必要です。特にOptional FeaturesやFeatures on Demandを検証したい場合、Store版だけで進めると期待した結果にならない可能性があります。(Microsoft for Developers)
検証計画には、必ず「どのパッケージ方式で試したか」を記録してください。チーム内でStore版とZIP版が混在していると、同じ構成ドキュメントでも結果が違うように見えることがあります。
WhatIfを過信する
WhatIfは変更前レビューに役立ちますが、実行時のすべてのリスクを消すものではありません。たとえば、ファイアウォール設定の変更では、リモート管理ポートを閉じてしまう可能性があります。サービス設定では、依存関係のあるアプリケーションが影響を受ける場合があります。
実務では、WhatIfの結果だけで承認するのではなく、変更対象、影響範囲、戻し方、作業者、実施タイミングをセットで確認する必要があります。
バージョン固定を後回しにする
検証時は「とりあえず最新で動けばよい」と考えがちですが、本番運用ではそれがトラブルの原因になります。構成ドキュメントが同じでも、実行環境にあるDSCやリソースのバージョンが違えば、動作差が出る可能性があります。
DSC v3.2.0で追加されたバージョン固定は、再現性を守るための機能です。構成をGitで管理するなら、versionとrequireVersionを早い段階で設計に入れるべきです。(Microsoft for Developers)
既存の管理手段との競合を確認しない
Windows環境では、DSC以外にもグループポリシー、Intune、MDM、Configuration Manager、手動設定、ログオンスクリプトなどが存在することがあります。DSCで設定しても、別の仕組みが後から上書きすれば、現場では「DSCが効かない」と見えてしまいます。
DSC v3.2.0を導入する前に、どの設定をどの仕組みが管理するのかを棚卸ししましょう。特にファイアウォール、サービス、OpenSSH、Windows機能は、複数の管理経路が重なりやすい領域です。
日本のWindows運用で使いやすい活用シーン
DSC v3.2.0は、次のようなWindows運用で効果を出しやすいリリースです。
| 活用シーン | 期待できる効果 | 注意点 |
|---|---|---|
| サーバーのサービス起動設定を標準化 | 設定漏れや手作業ミスを減らせる | 業務アプリの依存関係を事前確認する |
| ファイアウォールルールの統一 | 環境ごとの差異を把握しやすい | リモート管理経路を失わないよう段階適用する |
| OpenSSH Server設定の管理 | SSH設定を構成ファイルとしてレビューできる | セキュリティポリシーや鍵管理と合わせて設計する |
| Windows機能の有効・無効管理 | 端末やサーバーの構成を揃えやすい | ZIPパッケージ要件と再起動要否を確認する |
| 監査対応の構成管理 | 変更前後の説明がしやすい | 実行ログ、承認フロー、バージョン固定が必要 |
| 開発・検証環境の再現 | 同じWindows構成を作り直しやすい | 環境固有値をパラメーター化する |
実務で最初に狙うなら、「1つのリソース、1つの設定、1台の検証環境」から始めるのがよいでしょう。たとえば、検証用Windows Serverで特定サービスの状態を確認し、--what-ifで変更内容を見て、問題がなければ小さく適用する。そこで得たログや手順をもとに、ファイアウォールやOpenSSHへ広げる流れです。
DSC v3.2.0を読むときの実務的な見方
「Announcing Microsoft Desired State Configuration v3.2.0」は、新機能の一覧として読むだけではもったいない発表です。実務視点では、次の3つに分けて読むと判断しやすくなります。
1つ目は、すぐ試せる改善です。新しいWindowsリソース、WhatIf、バージョン固定は、Windows管理者が比較的早く検証しやすい領域です。
2つ目は、既存資産への影響です。PowerShellアダプター改善やPSDSCリソースとの関係は、過去にPowerShell DSCを使っていたチームほど確認する価値があります。
3つ目は、将来のIaC連携です。Bicep gRPC連携や拡張機能は、DSCが単体ツールではなく、Bicepやほかのオーケストレーション基盤と連携する方向へ進んでいることを示しています。
まとめ：まずは検証環境でWhatIfとバージョン固定を試す
Microsoft Desired State Configuration v3.2.0は、Windows構成管理をより安全に、より再現性高く扱うための重要な更新です。特に、Windows向け組み込みリソースの拡充、個別リソースへのWhatIf対応、構成ドキュメントとリソースのバージョン固定は、日常的なWindows運用に直結します。
一方で、Bicep gRPC連携や一部の拡張機能は、将来性があるものの、まずは検証段階として扱うべきです。実務での第一歩は、検証用Windows環境を用意し、対象を1つに絞って--what-ifを実行することです。そのうえで、バージョン固定、戻し手順、既存管理手段との競合確認まで整えれば、DSC v3.2.0を本番運用へ広げる判断がしやすくなります。
コメント