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

「標準端末を作り直したい」「途中で失敗したセットアップをもう一度流したい」「誰かが手で変えた設定を見つけたい」。Windows端末やサーバーを手順書とスクリプトで管理していると、同じ設定を再現し、維持するところで苦労します。

手順書は実行後の変更を追い続けなければ現実とずれます。BATやPowerShellも、再実行で二重適用やエラーを起こさないようにするには、存在確認や分岐を自分で書く必要があります。この負担を、「手順」ではなく「あるべき状態」を書く管理へ移すのが、DSC(Desired State Configuration)です。

本記事では、2025年にPowerShell非依存のコマンドラインツールとして登場したMicrosoft DSC v3(dsc.exe)を扱います。LinuxやクラウドでTerraform・Ansibleを使うときのように、Windowsのクライアントやサーバーそのものも宣言的なIaC(Infrastructure as Code)で管理するための入口です。¹

対象は、Windowsの構成管理を手順書とスクリプトから移行したい開発者・情シス担当者です。前提はWindows 10/11、DSC 3.0以降、PowerShellの基本操作で、難易度は中級です。DSC 3.2以降のアダプタ名や、WinGet側の必要バージョンは、該当する箇所で分けて説明します。

1. まず結論 ── 状態を書き、確認してから適用する

これからWindowsの宣言的な構成管理を始めるなら、Microsoft DSC v3(dsc.exe)を選びます。 YAML/JSONに「あるべき状態」を書き、現在の状態との比較と適用の処理はDSCとリソースに任せます。同じ構成を繰り返し適用しても、すでに望む状態の項目には何もしない、冪等な管理が基本です。²³

ただし、「何度でも適用できること」と「適用してよい内容であること」は別です。まず状態を読み、差分と予測を確認してから適用します。また、DSC v3は常駐エージェントではないため、定期的な監査や修復は別に設計します。⁴¹

読み進める順序は、次のとおりです。

flowchart TB
    accTitle: 手順の管理から状態の管理へ
    accDescr: 手順書スクリプトでは再実行のための存在確認や分岐を自分で実装するのに対し、DSCではあるべき状態を宣言しDSCとリソースが比較と適用を担う
    imp["手順を書く（BAT・PowerShell）"] --> guard["存在確認・分岐を自分で実装"]
    dec["状態を書く（DSC）"] --> test["現在の状態と比較"]
    test --> set["必要な項目だけ適用"]

図1: 再実行を考える責任を、手順の書き分けから、状態の宣言とリソースの利用へ移す。

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

2. 使うDSCを見分ける ── 4系統と、v3にないもの

2.1. 本記事の主役は、独立したdsc.exe

「DSC」で検索すると、書き方も実行方法も異なる4系統の情報が出てきます。最初に、資料がどれを扱っているかを確認してください。⁵

Microsoft DSC v3は、PowerShell DSC(PSDSC)のモジュールを単に更新したものではありません。PowerShellへの依存を切り離して書き直した別のプロダクトです。構成をJSON/YAMLのデータで記述し、リソースは任意の言語で実装できます。DSC本体は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という名前でも、PowerShellモジュールの世代と、独立したdsc.exeを区別する。

以降の「DSC」はMicrosoft DSC v3を指します。検索語に「DSC v3」「dsc.exe」を加えると、旧世代の資料と区別しやすくなります。既存のPSDSCリソースを呼ぶ方法は6章で扱います。

2.2. v3は、構成を覚えて自動修復する常駐サービスではない

PSDSC v1.1のLCM(Local Configuration Manager)は、構成を保持し、定期適用や自動修復を行う常駐エージェントでした。DSC v3にはLCMがなく、呼ばれたときだけ動くコマンドです。dsc.exeを入れて一度構成を適用しただけでは、その後の変更を自動で直してはくれません。¹

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"]

図3: v3では「どう構成するか」と「いつ実行するか」を分け、後者をタスクスケジューラや上位の管理基盤に任せる。

これは単なる機能の後退ではなく、実行方法を現代の道具に開放した設計変更です。ただし、v1.1のpull server運用をそのまま想定すると戸惑います。継続的な強制が必要なら、タスクスケジューラ・CI・Machine Configurationなどの実行基盤を選ぶ必要があります。具体的な運用は7章へ進んでください。

3. 宣言的な構成を理解する ── 手順と状態を比べる

3.1. 存在確認や分岐を、宣言から取り除く

例として、レジストリにアプリの動作モードを保存します。命令的なPowerShellでは、キーの存在を確認し、必要なら作り、値を設定します。再実行できるようにするための手順を、自分で管理する形です。

# 命令的:「手順」を書く。分岐や順序をすべて自分で管理する
$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では同じ要求を、次のような状態の宣言にします。存在確認も作成の分岐も、宣言する側には書きません。この断片を構成ドキュメントのresourcesに入れた完全な例は5章で示します。

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

違いは、PowerShellでは冪等にできないということではありません。スクリプトで自分が書いていた確認と適用を、リソースへ任せることです。途中で失敗した端末や設定済みの端末でも、同じ「あるべき状態」を基準に再適用できます。²

3.2. リソースがget・test・setを受け持つ

DSCの中心にあるリソースは、レジストリ値・Windows機能・環境変数など、構成対象ごとの操作を提供します。利用者は「何がどうあるべきか」を書き、「どう設定するか」はリソースに任せます。⁶

構成全体を適用するdsc config setは、各インスタンスをまずtestし、望む状態にないものにだけsetを呼びます。これが、同じ構成を繰り返し適用できる仕組みです。³

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

図4: 構成全体の適用では、まず比較し、必要なリソースインスタンスだけを変更する。

3.3. 単体のresource setと、構成全体のconfig setを混同しない

dsc resource setは、指定したリソースのsetを常に呼びます。事前にテストするかは、リソースの実装とマニフェストのimplementsPretestに依存します。config setが行う事前テストを、resource setにもあると思い込まないことが重要です。³

flowchart TB
    accTitle: 構成全体と単体呼び出しの事前テストの違い
    accDescr: config setは各インスタンスをテストして必要な場合だけsetを呼ぶが、resource setはリソースのsetを常に呼び、そこでの事前テストはリソースの実装とマニフェストに依存する
    config["config set"] --> test["各インスタンスをテスト"]
    test --> needed{"望む状態か？"}
    needed -->|"はい"| skip["setを呼ばない"]
    needed -->|"いいえ"| apply["setを呼ぶ"]
    single["resource set"] --> direct["リソースのsetを呼ぶ"]
    direct -.-> impl["事前テストは実装次第"]

図5: 同じsetでも、DSCが事前テストする構成全体の操作と、リソースへ直接渡す単体操作を区別する。

最初は単体のget・testで観察し、複数の状態を管理する段階で構成ドキュメントへまとめる、と分けると理解しやすくなります。冪等性は再実行のための性質であり、権限不足やリソースの実行エラーをなくすものではありません。

4. 最初の操作 ── インストールしてget・testで観察する

4.1. dsc.exeを用意し、使えるリソースを確認する

インストール方法は、GitHubのリリースからアーカイブを展開してPATHへ追加する方法と、WindowsでMicrosoft Storeソースを指定してwingetから入れる方法の2つです。¹

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

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

dsc resource list

DSC本体を用意することと、使いたいリソースを利用できることは分けて確認します。ここで対象の型名を見つけてから、入力するプロパティを指定します。旧世代のPSDSCリソースを使う場合は、6章のアダプタも確認してください。

4.2. 最初はユーザー配下のレジストリを読む

構成ドキュメントを書かなくても、リソースは1つずつ呼び出せます。次の例はHKCU配下の値をgetで読み、testで望む状態かを判定します。どちらも、値を変更するための操作ではありません。⁷

# 現在の状態を取得する(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対応リソース）"]

図6: listでリソースを探し、getで現在値を読み、testで宣言との差を確かめてからsetへ進む。

HKLMやシステム設定など、マシン全体を変えるsetには管理者権限が必要です。最初の試行はユーザー配下(HKCUなど)の例から始め、変更を伴う操作では対象と権限を確認します。Windows PowerShell系PSDSCリソースのアダプタ利用も管理者実行が前提です。⁷ 実行ユーザーと構成の分け方は8章で扱います。

5. 構成ドキュメント ── 宣言から適用後の確認まで

5.1. YAMLに「何がどうあるべきか」をまとめる

構成ドキュメントは、複数のリソースインスタンスをまとめて宣言するYAML/JSONファイルです。最低限$schemaとresourcesを定義し、各インスタンスに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')]"

この例では、3章の宣言をファイルにまとめ、動作モードをappModeパラメーターにしました。部署や環境によって違う値を、構成の本体から分けて扱えます。parametersとvariablesで重複定義を減らし、動的な値も表現できます。式には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

図7: 文書のスキーマ、環境ごとの値、リソースの宣言を分けると、設定の意図をデータとして読める。

構成がデータになる利点は、「この端末には何が設定されているべきか」をYAMLの差分としてレビューできることです。ただし、データだから無害という意味ではありません。参照したリソースがシステムを変更するので、8章の信頼性確認も必要です。⁸

5.2. test → what-if → set → getの順に進める

適用前に、必ず観察を挟みます。dsc config testは望む状態との差分の有無を報告し、dsc config set --what-ifは変更せずに予測を表示します。⁴

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（結果の確認）"]

図8: まず差分を見て、変更の予測を確認し、納得してから適用する。最後に実際の状態を読み直す。

# 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

ここで見るものはそれぞれ異なります。testは一致の判定、what-ifは変更の予測、getは実際の状態の取得です。what-ifをリソースが直接実装していない場合はtest結果から合成されるため、予測を適用後の実測と取り違えないようにします。⁴

この順序にすることで、設定変更を一発勝負にせず、段階ごとに判断できます。適用時の権限やリソースの信頼性の確認を、冪等性やwhat-ifで代用するわけではありません。

5.3. 既存環境から始めるなら、対応リソースをexportする

dsc config exportは、現在の環境を書き起こす逆方向の入口です。--fileで渡す入力文書にexport対応リソースを列挙すると、そのリソースの既存の全インスタンスを含む構成ドキュメントを標準出力へ返します。⁹

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

どのリソースでも書き出せるわけではなく、入力文書の各リソース型は1回だけ宣言します。得られた現状を出発点にし、標準として管理したい内容を決めていきます。exportは現在の状態を書き出す操作であり、それを望ましい状態と決めるのは運用側です。⁹

flowchart TB
    accTitle: 現在の状態から管理したい宣言を作る
    accDescr: export対応リソースを入力文書に列挙すると既存インスタンスを含む構成ドキュメントが得られ、その内容を確認して運用側が標準として管理する状態を決める
    input["export対応リソースを列挙"] --> export["dsc config export"]
    export --> current["既存インスタンスの構成文書"]
    current --> review["内容を確認し標準を決める"]
    review --> desired["管理したい状態の宣言"]

図9: 現状の書き出しと、標準として採用する内容の判断は別の段階である。

6. 既存資産を活かす ── アダプタとWinGet Configuration

6.1. PSDSCリソースは、実行環境に合うアダプタで呼ぶ

v3が別プロダクトでも、既存のPSDSCリソースは無駄になりません。アダプタリソースを通して、v3の構成ドキュメントから呼び出せます。DSC 3.2で名前が変わっているため、導入バージョンと資料の名前を照合します。¹⁰

DSC本体がPowerShell非依存でも、アダプタで呼ぶ既存リソースは対応するPowerShell環境で動きます。Windows PowerShell側は内蔵のPSDesiredStateConfiguration 1.1を使い、互換のスクリプト・クラス・バイナリリソースを扱えます。¹⁰

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資産）"]

図10: DSC v3はネイティブリソースを直接呼び、既存のPowerShell資産はアダプタを介して利用する。

6.2. WinGetのv3スキーマでは、DSC v3を処理系に指定する

もう一つの接続先はWinGet Configurationです。PCキッティングの記事で紹介した.wingetファイルも、v3スキーマではDSC v3を処理系として使います。必要なのはWinGet 1.11以降とdscv3プロセッサです。¹¹

構成ファイルのmetadata.winget.processor.identifierにdscv3を指定し、resourcesを文書のルートへ直接書きます。中身は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形式を、そのままdscv3へ渡すことはできません。 properties.configurationVersion: 0.2.0を持ち、リソースをpropertiesの下へ入れるv2ファイルは、従来の処理系で動き続けます。DSC v3へ載せる場合は、公式サンプルリポジトリの「Convert to v3」に従って書式を移行します。¹¹

つまり、再利用するものを分けて考えます。PSDSCはリソースをアダプタで呼ぶ話、WinGetは構成ファイルの書式と処理系を合わせる話です。DSC v3で学ぶ状態宣言は、手元のdsc.exeからキッティングのwinget configure、Machine Configurationのような上位の管理基盤につながる共通の土台になります。¹

7. 継続運用 ── Gitを正本にし、ドリフトを検出する

7.1. まずは検出だけを自動化し、修復と分ける

構成ドキュメントはGitリポジトリに置きます。変更をプルリクエストでレビューし、マージして適用する流れにすれば、望む構成とその変更履歴を同じ場所で管理できます。手順書だけを別に更新し続ける管理から、実行できる宣言を正本にする管理へ移ります。

適用後に誰かが手で設定を変え、宣言した状態からずれることを構成ドリフトと呼びます。その検出はdsc config testの定期実行です。testは変更しないため、検出と修復を分けられます。最初は検出だけを自動化し、setによる修復は差分を確認してから行います。

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

図11: 宣言をレビューして適用し、定期的なtestで差分を検出する。修復するか宣言を更新するかは、内容を見て決める。

ドリフトが常に誤りとは限りません。現場で必要な変更をした結果なら、端末を戻すのではなく、構成ドキュメントを更新してレビュー・マージします。反対に宣言が正しければsetで修復します。どちらの場合も、正本をGitの中に置くという規律は同じです。

7.2. 「検査できなかった」と「ずれている」を区別する

定期実行では、コマンドを起動しただけで成功としないことが重要です。次の例は、DSCの実行失敗、一部リソースの検査エラー、ドリフトを区別し、いずれも非ゼロで終了させます。

# 定期実行用: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
}

flowchart TB
    accTitle: 定期検査の失敗とドリフトを区別する
    accDescr: 定期検査の例ではDSCの終了コードと出力を確認し、次にhadErrorsで検査エラーを確認し、検査結果のinDesiredStateがfalseならドリフトとして報告する
    run["DSCの終了コードと出力"] --> q1{"実行失敗・出力なし？"}
    q1 -->|"はい"| error["検査失敗（終了2）"]
    q1 -->|"いいえ"| q2{"hadErrors？"}
    q2 -->|"はい"| error
    q2 -->|"いいえ"| q3{"inDesiredStateがfalse？"}
    q3 -->|"はい"| drift["ドリフト検出（終了1）"]
    q3 -->|"いいえ"| ok["この検査では差分なし"]

図12: 検査エラーを「差分なし」と報告しない。ドリフトは、検査ができたうえで状態が一致しない結果である。

この例は、5章のように通常のリソースインスタンスを直接列挙した構成の基本形です。採用する構成やリソースに合わせ、結果の形とエラー時の扱いを確認してから監視へ組み込みます。hadErrorsが示す文書の検証失敗やリソースのエラーは、健全な状態と判定してはいけません。

7.3. 定期実行の基盤は、端末と組織の管理方法で選ぶ

DSC v3にLCMはないので、いつ誰がtestを起動するかは別に決めます。端末ならタスクスケジューラ、サーバー群ならCIランナーが使えます。無人実行の設計は別記事を参照してください。

Azureへ管理を寄せている組織では、Machine Configurationが、Azure VMとAzure Arc経由のオンプレサーバーに対して、OS設定の監査・適用をマネージドに行う受け皿になります。¹² 手元のコマンドを定期実行するのか、上位の管理基盤に載せるのかを選びます。

8. 適用前に確認すること ── 実行権限・秘密情報・信頼性

8.1. ユーザー設定とマシン設定を、構成の段階で分ける

HKLMやWindows機能など、マシン全体に関わるsetには昇格が必要です。Windows PowerShell系のPSDSCリソースをアダプタ経由で使う場合も管理者実行が前提になります。⁷

ユーザー単位の設定とマシン単位の設定は、構成ドキュメントの段階で分けておくと、実行コンテキストを設計しやすくなります。対話実行できたことだけでなく、タスクスケジューラなどで実行するときのユーザーと権限も合わせて確認します。

flowchart TB
    accTitle: 構成の対象に合わせて実行コンテキストを分ける
    accDescr: ユーザー単位とマシン単位の設定を構成ドキュメントで分け、対象ユーザーと必要な権限を確認したうえで対話実行または定期実行へ渡す
    config["管理したい設定"] --> user["ユーザー単位の構成"]
    config --> machine["マシン単位の構成"]
    user --> check["対象ユーザー・権限を確認"]
    machine --> check
    check --> exec["対話実行・定期実行"]

図13: YAMLを同じように配るだけでなく、どのユーザー・権限で適用する構成なのかも決めておく。

8.2. 秘密情報をGitへ入れず、参照リソースまで確認する

構成ドキュメントはGitに入れるデータです。パスワードやAPIキーは直書きせず、パラメーター化して実行時に渡す設計にします。5章のパラメーターは環境差分を分ける例ですが、秘密情報を構成の本体から切り離すことも重要です。

公開リポジトリから取得した.wingetや構成ドキュメントは、内容を読んでから実行します。ファイルの中身だけでなく、参照先リソースを信頼できるかも確認してください。構成ドキュメントは、リソースを通じてシステムを変更する力を持ちます。これは公式ドキュメントでも警告されている、運用上の必須事項です。⁸

9. まとめ ── 小さな設定から、実行できる正本を作る

Windowsの宣言的IaCをこれから始めるなら、Microsoft DSC v3(dsc.exe)です。4系統あるDSCを区別したうえで、まず単体のget・testで観察し、YAML/JSONの構成へまとめます。適用するときはtest → what-if → set → getの順に、判定・予測・適用・確認を分けます。⁵⁴

繰り返し適用できるのは、「手順」ではなく「あるべき状態」を書き、DSCとリソースが比較と必要な適用を引き受けるからです。既存PSDSCリソースはアダプタ経由で再利用でき、WinGet資産はv3スキーマへ書式を移行して接続できます。³¹⁰¹¹

継続運用では、v3自身にはLCMがないことを前提にします。構成の正本をGitへ置き、定期的なtestでドリフトを検出し、構成が正しければ修復、現実が正しければ構成を更新します。¹ 実行権限・秘密情報・参照先の信頼性も、適用の手順と一緒に設計します。

手順書と現実のずれを、見つけられないまま抱える必要はありません。まずは自分の端末の設定を数個、構成ドキュメントに書き起こしてtestを実行し、ずれを検出できる差分へ変えるところから始めてください。

関連記事

• winget + PowerShellでPCキッティングを自動化する ── 手順書を実行可能にする
• BATをPowerShellに移行すべきか ── 判断基準と移行の実務
• タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計
• GPOからIntuneへの移行ガイド ── 中小企業の現実解
• WSUS非推奨後のWindows Update管理

関連する相談領域

合同会社小村ソフトでは、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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。