DSCにはバージョンがいくつもあるようですが、どれを使えばよいですか？

これから宣言的な構成管理を始めるならMicrosoft DSC v3(dsc.exe)です。DSCには、Windows PowerShell 5.1に内蔵されたPSDSC v1.1、PowerShell 7向けモジュールのPSDSC v2、Azure Machine ConfigurationのLinux対応で使われるPSDSC v3(プレビュー)、そしてPowerShellに依存しない独立したコマンドとして書き直されたMicrosoft DSC v3の4系統があります。v3はクロスプラットフォームで、構成をPowerShellスクリプトではなくYAML/JSONのデータとして書き、既存のPSDSCリソースもアダプタ経由で再利用できます。検索時は「DSC v3」「dsc.exe」を付けると旧世代の情報と区別しやすくなります。

DSC v3と手順書スクリプト(BATやPowerShell)は何が違うのですか？

手順書スクリプトは「実行する手順」を書くため、2回目の実行で二重適用やエラーが起きないよう冪等性を自分で作り込む必要があります。DSCは「あるべき状態」をデータとして書き、現在の状態との比較(test)と差分の適用(set)をリソースが引き受けます。同じ構成ドキュメントを何度実行しても、すでに望む状態にある項目には何もしないので、実行回数を気にせず配布・再実行できます。また構成がYAMLのデータなので、Gitでの差分レビューや世代管理がスクリプトより格段にしやすくなります。

既存のPowerShell DSCリソースやWinGet Configurationの資産は無駄になりますか？

無駄になりません。DSC v3はアダプタリソース(DSC 3.2以降はMicrosoft.Adapter/PowerShellとMicrosoft.Adapter/WindowsPowerShell、それ以前はMicrosoft.DSC/PowerShellとMicrosoft.Windows/WindowsPowerShell)を通じて、クラスベース・MOFベースの既存PSDSCリソースを呼び出せます。またWinGet Configurationはv3スキーマ(WinGet 1.11以降)からDSC v3をプロセッサとして使うようになっています。既存のv2形式の.wingetファイルは従来どおりの処理系で動き続けますが、DSC v3の処理系に載せるには公式の変換ガイドに従ってv3形式へ変換する必要があります。

DSC v3で構成を「継続的に」強制するにはどうすればよいですか？

DSC v3自体はコマンドとして起動されるツールで、v1.1のLCM(Local Configuration Manager)のような常駐エージェントや自動修復の仕組みを持ちません。継続的な適用・監査が必要なら、タスクスケジューラやCIからdsc config testを定期実行してドリフトを検出する仕組みを自分で用意するか、AzureのMachine Configuration(Azure Arc経由でオンプレサーバーも対象化可能)のようなオーケストレーション層に載せます。

dsc config setをいきなり実行するのが怖いのですが、事前に影響を確認できますか？

できます。dsc config testを実行すれば、どのリソースインスタンスが望む状態にないかを変更なしで確認できます。さらにdsc config setには--what-ifオプションがあり、実際には変更せずに「実行したら何がどう変わるか」の予測を表示できます。まずtestと--what-ifで差分を確認し、問題なければsetを実行する、という手順にすれば安全です。

DSCでWindowsを宣言的に構成管理する ── dsc.exeで始めるIaC

2026年08月28日 00:00 · 小村豪 · Windows, DSC, IaC, PowerShell, winget, 構成管理

新しいPCのセットアップ手順書、サーバーの構築手順のExcel、退職者が残した秘伝のBATファイル ── Windowsの構成管理は、いまも多くの現場で「手順を書いた文書」と「手順を実行するスクリプト」で回っています。この方式の弱点は明確で、手順は実行した瞬間から現実とずれ始め、スクリプトは2回目の実行で壊れることです。

LinuxやクラウドではTerraformやAnsibleのような宣言的なIaC(Infrastructure as Code)が当たり前になりました。ではWindowsのクライアントやサーバーそのものを、同じ発想で管理するには何を使えばよいのか。Microsoftの答えがDSC(Desired State Configuration)であり、2025年にPowerShell非依存のコマンドラインツールとして書き直されたMicrosoft DSC v3(dsc.exe)で、ようやく「普通に始められる」形になりました。¹

対象読者は、Windows端末・サーバーの構成を手順書とスクリプトで管理していて、宣言的な管理に移行したい開発者・情シス担当者です。前提環境はWindows 10/11とDSC 3.0以降で、PowerShellの基本操作を前提知識とします。難易度は中級です。

1. まず結論

DSCでは「実行する手順」ではなく「あるべき状態」をYAMLで書く。現在の状態との差分検出(test)と適用(set)はリソースが引き受けるので、同じファイルを何度実行しても安全(冪等)になり、構成はGitでレビューできるデータになる。これから始めるならMicrosoft DSC v3(dsc.exe)一択である。

手順書スクリプトと宣言的構成の違いは、「壊れ方」に現れます。手順を書いたスクリプトは、途中で失敗した端末や、すでに設定済みの端末に対してもう一度流すと、二重適用やエラーで止まります。宣言的な構成は「あるべき状態」しか書いていないので、何度流しても、どんな中間状態から流しても、同じ結果に収束します。²

flowchart TB
    accTitle: 命令的な手順書と宣言的な構成の対比
    accDescr: 命令的なスクリプトは手順を上から実行するため再実行で二重適用や停止が起きるのに対し、宣言的なDSCはあるべき状態を宣言して差分だけを適用するため何度実行しても同じ状態に収束する
    imp["命令的：手順を書く（BAT・手順書）"] --> i1["上から順に実行"]
    i1 --> i2["再実行で二重適用・エラー"]
    dec["宣言的：状態を書く（DSC）"] --> d1["現在との差分を検出"]
    d1 --> d2["差分だけ適用・何度でも安全"]

図1: 命令的スクリプトは「実行回数」に敏感だが、宣言的構成は何度実行しても同じ状態に収束する。

この記事の知識マップ

手順書スクリプトによるWindowsの構成管理を、あるべき状態をYAMLで宣言するMicrosoft DSC v3（dsc.exe）に置き換える記事。DSC v3はPowerShell非依存に書き直されたPSDSCの後継で、構成ドキュメントに宣言された状態をDSCリソースのget・test・setが冪等に収束させる。既存のPSDSCリソースはアダプタリソース経由で呼び出せ、WinGet Configurationはv3スキーマからDSC v3を処理系として使う。v3にはLCMのような常駐エージェントがないため、構成ドリフトの検出はdsc config testの定期実行として自分で用意するか、Azure Machine Configurationのようなマネージドの受け皿に載せる。アダプタはMicrosoft.Adapter/PowerShellがPowerShell 7上で、Microsoft.Adapter/WindowsPowerShellがWindows PowerShell 5.1上で既存リソースを動かす。運用面では、マシン全体に関わるリソースのsetに管理者権限が必要なこと、Gitに置く構成ドキュメントへシークレットを直書きせずパラメーター化することが注意点になる。

flowchart LR
    accTitle: DSCによるWindowsの宣言的構成管理の知識マップ
    accDescr: PSDSCの後継であるMicrosoft DSC v3が構成ドキュメントとDSCリソースを使って冪等な適用を実現し、アダプタリソースがPowerShell 7とWindows PowerShell 5.1の上で既存PSDSC資産を、wingetが実装するWinGet Configurationのv3スキーマがwinget側の資産を接続し、LCM不在の継続的強制はタスクスケジューラによるdsc config testの定期実行やAzure Machine Configurationが受け持ち、マシン全体に関わるリソースには管理者権限が、構成ドキュメントには平文シークレットを書かない設計が必要になる関係を示す図
    microsoft_dsc_v3["Microsoft DSC v3"]
    dsc_configuration_document["DSC構成ドキュメント"]
    idempotency["冪等性"]
    powershell_dsc["PowerShell DSC"]
    dsc_resource["DSCリソース"]
    dsc_adapter_resource["アダプタリソース"]
    winget_configuration["WinGet Configuration"]
    configuration_drift["構成ドリフト"]
    dsc_config_test["dsc config test"]
    local_configuration_manager["LCM"]
    azure_machine_configuration["Azure Machine Configuration"]
    winget["winget"]
    powershell_7["PowerShell 7"]
    windows_powershell_5_1["Windows PowerShell 5.1"]
    task_scheduler["タスクスケジューラの無人実行"]
    admin_rights["管理者権限"]
    plaintext_secret_storage_risk["秘密情報の平文保存リスク"]
    microsoft_dsc_v3 -->|"の後継"| powershell_dsc
    microsoft_dsc_v3 -->|"利用する"| dsc_configuration_document
    microsoft_dsc_v3 -->|"利用する"| dsc_resource
    dsc_configuration_document -->|"利用する"| dsc_resource
    microsoft_dsc_v3 -->|"実装を担う"| idempotency
    microsoft_dsc_v3 -->|"利用する"| dsc_adapter_resource
    dsc_adapter_resource -->|"利用する"| powershell_dsc
    winget_configuration -.->|"利用する"| microsoft_dsc_v3
    configuration_drift -->|"で確認できる"| dsc_config_test
    local_configuration_manager -.->|"軽減する"| configuration_drift
    azure_machine_configuration -.->|"軽減する"| configuration_drift
    winget -->|"実装を担う"| winget_configuration
    dsc_adapter_resource -.->|"利用する"| powershell_7
    dsc_adapter_resource -.->|"利用する"| windows_powershell_5_1
    task_scheduler -->|"自動化する"| dsc_config_test
    dsc_resource -.->|"前提とする"| admin_rights
    dsc_configuration_document -.->|"原因になり得る"| plaintext_secret_storage_risk

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全17件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 「DSC」という名前の混乱を整理する ── 4つの系統

DSCの学習で最初につまずくのは、技術そのものではなく検索結果の混乱です。「DSC」の名前を持つ仕組みは4系統あり、書き方も実行方法も互換性も違います。³

系統	実体	位置づけ
PSDSC v1.1	Windows PowerShell 5.1内蔵	レガシー。LCM常駐・MOF形式
PSDSC v2	PowerShell 7向けモジュール	PSDesiredStateConfiguration 2.x
PSDSC v3(プレビュー)	PowerShellモジュール	Azure Machine ConfigurationのLinux対応向け
Microsoft DSC v3	独立した`dsc.exe`	本記事の主役。PowerShell非依存・クロスプラットフォーム

Microsoft DSC v3は、それまでのPowerShell DSC(PSDSC)を単に更新したものではなく、PowerShellへの依存を切り離して書き直した別のプロダクトです。構成はPowerShellスクリプトではなくJSON/YAMLのデータになり、リソースはどの言語でも実装でき、Linux・macOS・Windowsで同じように動きます。¹

flowchart TB
    accTitle: DSC 4系統の系譜
    accDescr: Windows PowerShell 5.1内蔵のPSDSC v1.1からPowerShell 7向けのPSDSC v2とMachine Configuration向けPSDSC v3プレビューが派生し、それらとは別にPowerShell非依存で書き直されたMicrosoft DSC v3が現行の主役となる関係
    v11["PSDSC v1.1（WinPS 5.1内蔵）"] --> v2["PSDSC v2（PowerShell 7）"]
    v2 --> v3ps["PSDSC v3プレビュー"]
    v11 -.->|"書き直し"| dsc3["Microsoft DSC v3（dsc.exe）"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["本記事の主役"]

図2: 「DSC」を検索すると4系統の情報が混ざって出てくる。記事や資料がどの系統の話かを最初に見分けることが重要である。

以降、本記事で「DSC」と書いたらMicrosoft DSC v3を指します。旧世代の資産が無駄にならないことは後述します(6節)。

3. 宣言的とはどういうことか ── get・test・setと冪等性

DSCの中心概念はリソースです。リソースは「レジストリ値」「Windows機能」「環境変数」のような構成対象1種類ごとに、状態の取得(Get)・判定(Test)・適用(Set)の操作を提供します。Getはすべてのリソースが実装します。Testは、実装を持たないリソースについてはDSCが取得結果と宣言の比較(合成テスト)で代行します。Setは状態を強制できるリソースだけが実装し、OS情報のような読み取り専用のリソースにはありません。⁴ 利用者は「どうやって設定するか」をリソースに任せ、「何がどうあるべきか」だけをデータで書きます。

この分業が冪等性を生みます。構成ドキュメントの適用(dsc config set)では、DSCが各インスタンスをまずtestし、望む状態にないものに対してだけsetを呼びます。だから同じ構成を何度適用しても安全です。なお、リソースを単体でdsc resource setする場合は常にsetが呼ばれ、事前テストの有無はリソース側の実装(implementsPretest)に依存する、という違いがあります。⁵

flowchart TB
    accTitle: get・test・setによる収束のループ
    accDescr: 構成ドキュメントに書いたあるべき状態をtestが現在の状態と比較し、差分がなければ何もせず、差分があればsetが差分だけを適用してgetで結果を確認できるという冪等な収束の流れ
    doc["構成ドキュメント（あるべき状態）"] --> test["test：現在の状態と比較"]
    test -->|"差分なし"| ok["何もしない（冪等）"]
    test -->|"差分あり"| set["set：差分だけを適用"]
    set --> get["get：結果の状態を確認"]

図3: DSCの適用は「比較してから、必要な分だけ変える」ループであり、実行回数という概念から解放される。

命令的なスクリプトとの違いをコードで見ます。たとえば「レジストリにこの値を入れる」処理は、スクリプトでは存在確認・作成・更新をすべて自分で書き分けます。

# 命令的:「手順」を書く。分岐や順序をすべて自分で管理する
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

DSCでは、同じことを「あるべき状態」の宣言として書きます。存在確認も分岐もありません。

# 宣言的:「状態」を書く。作る・直す手順はリソースの仕事
- name: アプリの動作モード
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

4. dsc.exeを入れて、リソースを単体で叩く

DSCのインストール方法は2つあります。GitHubのリリースからアーカイブを展開してPATHに追加するか、WindowsならMicrosoft Storeソース経由でwingetから入れます。¹

# Microsoft Storeソースから安定版を検索・インストール
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

導入できたら、まず手元のマシンで使えるリソースを一覧します。

dsc resource list

構成ドキュメントを書く前に、リソースは1つずつ単体でも呼び出せます。この「小さく試せる」ことがv3の学習を楽にしています。⁶

# 現在の状態を取得する(get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# 望む状態かを判定する(test) ── 変更は一切しない
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: dsc resourceコマンドの4操作
    accDescr: dsc resourceコマンドの下にリソースの一覧を示すlist、現在状態を取得するget、望む状態かを変更なしで判定するtest、状態を適用するset（Setを実装するリソースのみ）の4つの操作がぶら下がる構造
    cli["dsc resource コマンド"] --> l["list：リソース一覧"]
    cli --> g["get：現在状態の取得"]
    cli --> t["test：判定のみ・無変更"]
    cli --> s["set：適用（Set対応リソース）"]

図4: リソースは構成ドキュメントを書かなくても単体で呼び出せる。まずgetとtestだけで観察から始めるのが安全な入門ルートである。

setによる変更を伴う操作や、HKLM・システム設定を扱うリソースには管理者権限が必要です。試行は書き込み先がユーザー配下(HKCUなど)の例から始めるのが安全です。

5. 構成ドキュメント ── YAMLで「あるべき状態」を書く

複数のリソースをまとめて宣言するのが構成ドキュメントです。YAMLまたはJSONで書き、最低限$schemaとresourcesの2つを定義します。各リソースインスタンスはname(文書内で一意な表示名)・type(リソースの完全修飾名)・properties(望む状態)を持ちます。²

# standard-pc.dsc.config.yaml ── 標準端末のあるべき状態
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: アプリの動作モード
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

parametersとvariablesを使うと、環境ごとの差分(部署別の設定値など)を1つのドキュメントで表現できます。式の書き方はARMテンプレートの関数のサブセットです。²

flowchart TB
    accTitle: 構成ドキュメントの構造
    accDescr: 構成ドキュメントは文書スキーマを示すschema、環境差分を吸収するparametersとvariables、リソースインスタンスの配列resourcesからなり、各インスタンスがname・type・propertiesを持つ構造
    docroot["構成ドキュメント（YAML / JSON）"] --> sch["$schema：文書スキーマのURI"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources：インスタンスの配列"]
    res --> inst["name・type・properties"]
    par -.-> inst

図5: 構成ドキュメントは「スキーマ+パラメーター+リソース宣言」だけの素直なデータであり、プログラムではない。

適用の前に必ず「観察」を挟みます。dsc config testは変更なしで差分の有無を報告し、dsc config set --what-ifは「実行したら何が変わるか」の予測を表示します。⁷

# 1. 差分の有無を確認する(変更なし)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. 適用したら何が変わるかを予測表示する(変更なし)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. 納得してから適用する
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. 適用後の状態を確認する
dsc config get --file .\standard-pc.dsc.config.yaml

逆方向の入口もあります。dsc config exportは、--fileで渡した入力文書に列挙したリソース(exportに対応するもののみ)について、システム上の全インスタンスを含む構成ドキュメントを生成し、標準出力へ返します。既存環境の現状を書き起こす出発点に使えます。⁸

# 対象リソースを列挙した入力文書を渡し、現状の構成ドキュメントを保存する
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

flowchart TB
    accTitle: 安全な適用の4ステップ
    accDescr: 変更を加えないdsc config testで差分の有無を確認し、dsc config setのwhat-ifオプションで変更内容を予測表示し、納得してからsetで適用し、getで結果を確認するという安全な順序
    t["dsc config test（差分の有無）"] --> w["set --what-if（変更の予測）"]
    w --> s["dsc config set（適用）"]
    s --> g["dsc config get（結果の確認）"]

図6: 「観察→予測→適用→確認」の順序を崩さなければ、宣言的構成の適用に一発勝負の怖さはない。

構成ドキュメントがプログラムではなくデータであることは、運用面での最大の利点です。「この端末には何が設定されているべきか」がYAMLの差分としてレビューでき、変更履歴がそのまま構成の変更履歴になります。

6. 既存資産を活かす ── PSDSCリソースのアダプタとWinGet Configuration

「v3は別プロダクト」と聞くと過去の資産が心配になりますが、DSC v3はアダプタリソースという仕組みで旧世代のPSDSCリソースを呼び出せます。DSC 3.2以降の現行名では、PowerShell 7のクラスベースリソース向けがMicrosoft.Adapter/PowerShell、Windows PowerShell 5.1のMOFベース・スクリプトベースリソース向けがMicrosoft.Adapter/WindowsPowerShellです(それ以前はMicrosoft.DSC/PowerShell・Microsoft.Windows/WindowsPowerShellという名前でした)。⁹ 長年蓄積されたPSDSCリソースのエコシステムに、v3の構成ドキュメントからそのまま到達できます。

もうひとつの接続先がWinGet Configurationです。PCキッティングの記事で紹介した.wingetファイルは、v3スキーマ(WinGet 1.11以降)からはDSC v3をそのまま処理系として使うようになりました。構成ファイルのmetadataでプロセッサにdscv3を指定すると、文書の中身はDSC v3の構成ドキュメントそのものになります。¹⁰

# WinGet Configuration v3 ── 中身はDSC v3の構成ドキュメント
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: アプリの動作モード
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

注意点がひとつあります。既存のv2形式(properties.configurationVersion: 0.2.0でリソースをpropertiesの下に入れる書式)のファイルが、そのままdscv3プロセッサで動くわけではありません。v2ファイルは従来の処理系で動作し続けますが、DSC v3に載せるには公式の変換ガイド(サンプルリポジトリの「Convert to v3」)に従って書式を移行します。¹⁰

flowchart TB
    accTitle: DSC v3を中心とした層構造
    accDescr: winget configureやAzure Machine Configurationのようなオーケストレーション層がDSC v3を呼び出し、DSC v3はネイティブリソースを直接、既存のPSDSCリソースはアダプタリソース経由で呼び出す層構造
    orch["winget configure・Machine Configuration"] --> dsc["dsc.exe（DSC v3）"]
    dsc --> native["ネイティブリソース（Registryなど）"]
    dsc --> adapter["アダプタリソース"]
    adapter --> psdsc["既存PSDSCリソース（PowerShell資産）"]

図7: DSC v3は単体のツールであると同時に、wingetやAzureといった上位ツールの共通基盤でもある。既存のPSDSC資産はアダプタの下にぶら下がる。

つまり、v3で書いた知識と構成は、手元のdsc.exeでも、キッティングのwinget configureでも、クラウド管理のMachine Configurationでも通用します。学び直しではなく合流です。¹

7. 運用に乗せる ── Gitで管理し、ドリフトを検出する

構成ドキュメントの置き場所はGitリポジトリにします。これで構成変更は「プルリクエストでレビューして、マージして、適用する」というソフトウェア開発と同じ流れになります。手順書の更新漏れという概念自体が消えます。

適用後の課題は構成ドリフト(誰かが手で設定を変えて、あるべき状態からずれていくこと)です。DSCではドリフト検出がそのままdsc config testの定期実行になります。testは変更を加えないので、検出と修復を分離できるのが重要な性質です。まず検出だけを自動化し、修復(set)は差分内容を確認してから、が安全な運用です。

# 定期実行用:test自体の失敗・リソース単位のエラー・ドリフトを区別し、いずれも非ゼロで終わらせる
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "dsc config test の実行自体に失敗しました(終了コード: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # 文書の検証失敗や一部リソースの非ゼロ終了。検査が完走していないので健全と報告しない
    Write-Error "一部のリソースの検査がエラーになりました。messagesを確認してください"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "構成ドリフトを検出しました"
    exit 1
}

定期実行の足回りは、端末ならタスクスケジューラ(無人実行の設計は別記事で解説)、サーバー群ならCIランナーが使えます。Azureに管理を寄せている組織なら、Machine ConfigurationがAzure VMとAzure Arc経由のオンプレサーバーに対して監査・適用をマネージドに行う受け皿になります。¹¹

flowchart TB
    accTitle: Gitを起点とした構成管理の運用サイクル
    accDescr: Gitリポジトリに置いた構成ドキュメントをプルリクエストでレビューしてから適用し、タスクスケジューラやCIによる定期的なtestでドリフトを検出し、差分を確認して修復または構成の更新に戻る循環
    git["Gitリポジトリ（構成ドキュメント）"] --> pr["変更はプルリクでレビュー"]
    pr --> apply["dsc config set で適用"]
    apply --> sched["定期実行：dsc config test"]
    sched -->|"ドリフト検出"| judge["差分を確認して対処を判断"]
    judge -.->|"構成が正しい"| fix["set で修復"]
    judge -.->|"現実が正しい"| git

図8: ドリフトへの対処は「修復」だけではない。現場の変更が正しいなら、構成ドキュメント側を直してマージするのが宣言的管理の作法である。

図8の右下の分岐は見落とされがちです。ドリフトは常に「悪」ではなく、現場で必要だった変更が構成に反映されていないだけのこともあります。その場合は端末を戻すのではなく、構成ドキュメントを現実に合わせて更新します。正はあくまでGitの中の宣言、という規律さえ守れば、どちらに倒しても管理は壊れません。

8. 制約と落とし穴

導入前に知っておくべき制約を正直に挙げます。

LCMがない。 v1.1にあったLCM(Local Configuration Manager)は、構成を保持して定期適用や自動修復を行う常駐エージェントでした。v3は「呼ばれたときだけ動くコマンド」であり、サービスとして常駐しません。¹ 継続的な強制が必要なら、前節のとおり実行の足回り(タスクスケジューラ・CI・Machine Configuration)を自分で選ぶ必要があります。これは退化ではなく、「実行のさせ方」を現代の道具に開放した設計変更ですが、v1.1のpull server運用の感覚で来ると戸惑う点です。

管理者権限の扱い。 マシン全体に関わるリソース(HKLM、Windows機能など)のsetには昇格が必要で、Windows PowerShell系のPSDSCリソースをアダプタ経由で使う場合も管理者実行が前提です。⁶ ユーザー単位の設定とマシン単位の設定を構成ドキュメントの段階で分けておくと、実行コンテキストの設計が楽になります。

シークレットを構成に書かない。 構成ドキュメントはGitに入れるデータです。パスワードやAPIキーを直書きせず、パラメーター化して実行時に渡す設計にします。

他人の構成ファイルは読んでから実行する。 構成ドキュメントはリソースを通じてシステムを変更する力を持ちます。公開リポジトリから取得した.wingetファイルや構成ドキュメントは、内容と参照先リソースの信頼性を確認してから適用します。これは公式ドキュメントも明示的に警告している運用上の必須事項です。¹²

flowchart TB
    accTitle: v1.1のLCM常駐型とv3のコマンド型の対比
    accDescr: PSDSC v1.1では常駐するLCMが構成を保持して定期的なpullと自動修復を担ったのに対し、DSC v3はコマンドとして起動されるだけなので、定期実行の足回りをタスクスケジューラ・CI・Machine Configurationから自分で選んで用意する
    v1["PSDSC v1.1：LCMが常駐"] --> pull["構成を保持し定期pull・自動修復"]
    v3["DSC v3：コマンド起動のみ"] --> push["実行の足回りは自分で用意"]
    push -.-> ex["タスクスケジューラ・CI・Machine Configuration"]

図9: v3には「構成を覚えて勝手に直してくれる誰か」はいない。それを不便と取るか、実行制御を取り戻したと取るかが設計の分かれ目である。

9. まとめ ── 手順書をリポジトリに置き換える

Windowsの宣言的IaCをこれから始めるならMicrosoft DSC v3(dsc.exe)です。4系統ある「DSC」のうち、どの系統の情報を読んでいるかを常に意識してください。³
DSCは「手順」ではなく「あるべき状態」をYAML/JSONで書き、test(比較)とset(差分適用)が冪等な収束を保証します。まずdsc resource get/testによる観察から始め、--what-ifで影響を確認してから適用する流れが安全です。⁷
既存のPSDSCリソースはアダプタ経由で、キッティングの.winget資産はWinGet Configuration v3スキーマ経由で、それぞれv3の世界に合流できます(v2形式のファイルは変換ガイドに従った書式移行が必要です)。⁹¹⁰
v3にLCMはありません。構成の正本をGitに置き、dsc config testの定期実行でドリフトを検出し、「構成が正しければ修復、現実が正しければ構成を更新」の規律で回すのが運用の骨格です。

手順書の宿命は、書いた瞬間から現実とずれていくことでした。宣言的な構成管理は、そのずれを「検出できる差分」に変えます。まずは自分の端末の設定を数個、構成ドキュメントに書き起こしてdsc config testを流すところから始めてみてください。手順書がリポジトリに置き換わっていく感覚がつかめるはずです。

参考リンク

Microsoft Learn, Microsoft Desired State Configuration overview. DSC v3が宣言的・冪等な構成プラットフォームであり、PowerShellに依存せずLinux・macOS・Windowsで動作すること、LCM(Local Configuration Manager)を含まずコマンドとして起動されサービスとして常駐しないこと、アダプタリソースを通じてPSDSCリソースと互換性を持つこと、wingetのMicrosoft Storeソース(安定版ID 9NVTPZWRC6KQ)またはGitHubリリースからインストールできること、WinGet・Microsoft Dev Box・Azure Machine Configurationがオーケストレーション層の早期パートナーであることについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, DSC configuration documents. 構成ドキュメントがあるべき状態を宣言するYAML/JSONのデータファイルであり「どう設定するか」はリソースが担うこと、必須プロパティが$schemaとresourcesで各インスタンスがname・type・propertiesを持つこと、parametersとvariablesで重複定義の削減や動的な値を表現できること、dsc config get/test/set/exportの4操作で処理されること、ARMテンプレートの式関数のサブセットをサポートすることについて。 ↩ ↩² ↩³
Microsoft Learn, Desired State Configuration (DSC) Overview. DSCに4つのバージョン(Windows PowerShell 5.1に内蔵されたPSDSC 1.1、PowerShell 7向けのPSDSC 2.0、Azure Machine ConfigurationのLinux対応で使われるPSDSC 3.0プレビュー、PowerShellに依存しない独立プロダクトとしてのMicrosoft DSC 3.0)があり、Microsoft DSC 3.0が真のクロスプラットフォーム対応で既存のPSDSCリソースも利用できることについて。 ↩ ↩²
Microsoft Learn, DSC Resources. リソースが構成対象の標準化されたインターフェイスであり、宣言的な構文で「何があるべき状態か」を書くと「どう設定するか」はリソースが引き受けること、GetとTestの操作を必ず持ちほとんどのリソースがSetによる強制もサポートすること、完全修飾型名(owner.group.area/name)でリソースを指定すること、アダプタリソースがコマンド型でないリソースの利用を可能にすることについて。 ↩
Microsoft Learn, dsc resource set. dsc config setではDSCが各インスタンスを必ずテスト(リソースのtest実装または合成テスト)し、望む状態にないインスタンスに対してだけsetを呼ぶこと、対照的に単体のdsc resource setは常にsetを呼び、事前テストの有無はリソースマニフェストのset.implementsPretestに依存すること、implementsPretestを持たないリソースではsetの前にdsc resource testの実行が推奨されることについて。 ↩
Microsoft Learn, Get started with DSC. リソースの発見・単体呼び出し・構成ドキュメントの管理という入門の流れ、Microsoft.Windows/Registryリソースのget・test・setによる単体操作、dsc config test/set/getによる構成の検証・適用・確認、Windows PowerShell系のPSDSCリソースを扱う際に管理者権限のターミナルが必要であることについて。 ↩ ↩²
Microsoft Learn, dsc config set. dsc config setが構成ドキュメントのあるべき状態をシステムに適用するコマンドであること、および–what-ifオプションで実際には変更を加えずに「実行した場合に何がどう変わるか」の予測を表示できることについて。あわせてDSC Resource manifest whatIf propertyの、リソースがwhat-if動作を直接実装しない場合はtest結果からの合成でこの情報が作られることについて。 ↩ ↩²
Microsoft Learn, dsc config export. exportサブコマンドが–fileまたは–inputで渡した入力文書に列挙されたリソースについて、既存の全インスタンスを定義する構成ドキュメントを生成して返すこと、入力文書に指定できるのはマニフェストにexportセクションを持つリソースのみで、各リソース型は1回だけ宣言することについて。 ↩
Microsoft Learn, Microsoft.Adapter/WindowsPowerShell. アダプタリソースがWindows PowerShell 5.1互換のPSDSCリソース(スクリプト・クラス・バイナリ)をDSC v3から発見・呼び出しできるようにすること、内蔵のPSDesiredStateConfiguration 1.1モジュールを使うこと、この名前がDSC 3.2で従来のMicrosoft.Windows/WindowsPowerShellアダプタを置き換えたものであること、クラスベースリソースをPowerShell 7で使う場合はMicrosoft.Adapter/PowerShell(旧Microsoft.DSC/PowerShell)を使うことについて。 ↩ ↩²
Microsoft Learn, WinGet Configuration file v3 schema reference. WinGet Configurationのv3スキーマがDSC v3を処理系として使うこと、WinGet 1.11以降とdscv3プロセッサ(別パッケージMicrosoft.DesiredStateConfigurationとして自動インストールされる)が必要なこと、metadata.winget.processor.identifierにdscv3を指定しresourcesを文書のルートに直接書くこと、v2形式からの変換ガイドが公式サンプルリポジトリに用意されていることについて。 ↩ ↩² ↩³
Microsoft Learn, Understanding Azure Machine Configuration. Azure PolicyのMachine Configuration機能がAzure仮想マシンとAzure Arc対応サーバーに対して、OS内の設定の監査(audit)と構成(configure)をマネージドに行えることについて。 ↩
Microsoft Learn, configure コマンド (winget). winget configureがWinGet Configurationファイルでマシンを望ましい状態にセットアップするコマンドであること、実行前にファイルの内容を確認し関連リソースの信頼性を検証すべきという警告、show/list/test/validate/exportのサブコマンドでファイルの内容表示・適用済み構成の一覧・現在状態と望ましい状態の照合・ファイルの検証・構成の書き出しができることについて。 ↩

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

DSCにはバージョンがいくつもあるようですが、どれを使えばよいですか？: これから宣言的な構成管理を始めるならMicrosoft DSC v3(dsc.exe)です。DSCには、Windows PowerShell 5.1に内蔵されたPSDSC v1.1、PowerShell 7向けモジュールのPSDSC v2、Azure Machine ConfigurationのLinux対応で使われるPSDSC v3(プレビュー)、そしてPowerShellに依存しない独立したコマンドとして書き直されたMicrosoft DSC v3の4系統があります。v3はクロスプラットフォームで、構成をPowerShellスクリプトではなくYAML/JSONのデータとして書き、既存のPSDSCリソースもアダプタ経由で再利用できます。検索時は「DSC v3」「dsc.exe」を付けると旧世代の情報と区別しやすくなります。
DSC v3と手順書スクリプト(BATやPowerShell)は何が違うのですか？: 手順書スクリプトは「実行する手順」を書くため、2回目の実行で二重適用やエラーが起きないよう冪等性を自分で作り込む必要があります。DSCは「あるべき状態」をデータとして書き、現在の状態との比較(test)と差分の適用(set)をリソースが引き受けます。同じ構成ドキュメントを何度実行しても、すでに望む状態にある項目には何もしないので、実行回数を気にせず配布・再実行できます。また構成がYAMLのデータなので、Gitでの差分レビューや世代管理がスクリプトより格段にしやすくなります。
既存のPowerShell DSCリソースやWinGet Configurationの資産は無駄になりますか？: 無駄になりません。DSC v3はアダプタリソース(DSC 3.2以降はMicrosoft.Adapter/PowerShellとMicrosoft.Adapter/WindowsPowerShell、それ以前はMicrosoft.DSC/PowerShellとMicrosoft.Windows/WindowsPowerShell)を通じて、クラスベース・MOFベースの既存PSDSCリソースを呼び出せます。またWinGet Configurationはv3スキーマ(WinGet 1.11以降)からDSC v3をプロセッサとして使うようになっています。既存のv2形式の.wingetファイルは従来どおりの処理系で動き続けますが、DSC v3の処理系に載せるには公式の変換ガイドに従ってv3形式へ変換する必要があります。
DSC v3で構成を「継続的に」強制するにはどうすればよいですか？: DSC v3自体はコマンドとして起動されるツールで、v1.1のLCM(Local Configuration Manager)のような常駐エージェントや自動修復の仕組みを持ちません。継続的な適用・監査が必要なら、タスクスケジューラやCIからdsc config testを定期実行してドリフトを検出する仕組みを自分で用意するか、AzureのMachine Configuration(Azure Arc経由でオンプレサーバーも対象化可能)のようなオーケストレーション層に載せます。
dsc config setをいきなり実行するのが怖いのですが、事前に影響を確認できますか？: できます。dsc config testを実行すれば、どのリソースインスタンスが望む状態にないかを変更なしで確認できます。さらにdsc config setには--what-ifオプションがあり、実際には変更せずに「実行したら何がどう変わるか」の予測を表示できます。まずtestと--what-ifで差分を確認し、問題なければsetを実行する、という手順にすれば安全です。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る

DSCでWindowsを宣言的に構成管理する ── dsc.exeで始めるIaC

1. まず結論

この記事の知識マップ

2. 「DSC」という名前の混乱を整理する ── 4つの系統

3. 宣言的とはどういうことか ── get・test・setと冪等性

4. dsc.exeを入れて、リソースを単体で叩く

5. 構成ドキュメント ── YAMLで「あるべき状態」を書く

6. 既存資産を活かす ── PSDSCリソースのアダプタとWinGet Configuration

7. 運用に乗せる ── Gitで管理し、ドリフトを検出する

8. 制約と落とし穴

9. まとめ ── 手順書をリポジトリに置き換える

関連記事

関連する相談領域

参考リンク

winget + PowerShellでPCキッティングを自動化する ── 手順書を実行可能にする

WMI/CIMをC#・PowerShellから使う ── ハードウェア情報取得・プロセス監視・リモート照会の実務ガイド

グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け

Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる

Windows LAPS実務ガイド ── 全PC共通のローカル管理者パスワードをやめる

関連トピック

Windows技術トピック

このテーマがつながるサービス

Windowsアプリ開発

よくある質問

著者プロフィール

小村豪

1. まず結論

この記事の知識マップ

2. 「DSC」という名前の混乱を整理する ── 4つの系統

3. 宣言的とはどういうことか ── get・test・setと冪等性

4. dsc.exeを入れて、リソースを単体で叩く

5. 構成ドキュメント ── YAMLで「あるべき状態」を書く

6. 既存資産を活かす ── PSDSCリソースのアダプタとWinGet Configuration

7. 運用に乗せる ── Gitで管理し、ドリフトを検出する

8. 制約と落とし穴

9. まとめ ── 手順書をリポジトリに置き換える

関連記事

関連する相談領域

参考リンク

関連する記事

winget + PowerShellでPCキッティングを自動化する ── 手順書を実行可能にする

WMI/CIMをC#・PowerShellから使う ── ハードウェア情報取得・プロセス監視・リモート照会の実務ガイド

グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け

Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる

Windows LAPS実務ガイド ── 全PC共通のローカル管理者パスワードをやめる

関連トピック

Windows技術トピック

このテーマがつながるサービス

Windowsアプリ開発

よくある質問

著者プロフィール

小村 豪

小村豪