WindowsServer 2025 総合ガイド 第12回
DSC v3 入門 ― 宣言的構成管理の世界へ

基礎編（第1回〜第11回）では、Windows Server 2025の環境構築からPowerShellの基本操作、サービス管理、ネットワーク設定、ファイアウォール、イベントログ、リモート管理、役割と機能の追加、セキュリティ設定まで、サーバー管理に必要な基本スキルを手動で習得してきました。応用編となる今回からは、これらの手動設定を「コード」で自動化する方法を学んでいきます。第12回では、構成管理ツール「DSC v3（Desired State Configuration version 3）」の概念と基本操作を理解しましょう。

目次

1. 12.1 この記事で学ぶこと
2. 12.2 前提条件
3. 12.3 Infrastructure as Code（IaC）とは
   1. 12.3.1 IaCの概念
   2. 12.3.2 IaCのメリット
   3. 12.3.3 構成管理ツールの種類
4. 12.4 DSC（Desired State Configuration）とは
   1. 12.4.1 DSCの概念
   2. 12.4.2 宣言的（Declarative）と命令的（Imperative）
   3. 12.4.3 冪等性（Idempotent）
5. 12.5 DSC v3の特徴
   1. 12.5.1 DSC v2からDSC v3への進化
   2. 12.5.2 DSC v3の主要な変更点
   3. 12.5.3 DSC v3の現状と注意点
6. 12.6 DSC v3のインストール
   1. 12.6.1 前提条件の確認
   2. 12.6.2 wingetによるインストール
   3. 12.6.3 インストール確認
   4. 12.6.4 PSDesiredStateConfigurationモジュールのインストール
7. 12.7 基本コマンドの理解
   1. 12.7.1 dsc resource list ― 利用可能なリソースの一覧
   2. 12.7.2 dsc resource get ― リソースの現在の状態を取得
   3. 12.7.3 dsc resource test ― 現在の状態と目標状態の比較
   4. 12.7.4 dsc resource set ― リソースの状態を設定
   5. 12.7.5 基本コマンドのまとめ
8. 12.8 リソースの概念
   1. 12.8.1 リソースとは
   2. 12.8.2 リソースの種別
   3. 12.8.3 リソースプロバイダーの仕組み
9. 12.9 実践：リソースの状態確認
   1. 12.9.1 OS情報の確認
   2. 12.9.2 レジストリの確認
   3. 12.9.3 再起動保留状態の確認
   4. 12.9.4 手動管理とDSCの対応関係
10. 12.10 よくあるエラーと対処法
11. 12.11 まとめ
12. 12.12 次回予告
13. 12.13 参考リンク

12.1 この記事で学ぶこと#

• Infrastructure as Code（IaC）の概念と利点を理解する
• DSCの「宣言的」アプローチと「冪等性」の概念を理解する
• DSC v3をインストールし、基本コマンドを実行できる
• DSCリソースの概念を理解し、リソースの状態を確認できる

12.2 前提条件#

• 基礎編完了（第1回〜第11回）
• PowerShellスクリプティングの基礎を理解していること（第4回）
• Windows Server 2025にリモートデスクトップ接続できる状態
• PowerShell 7.4を管理者として起動できる状態

12.3 Infrastructure as Code（IaC）とは#

応用編の最初のテーマは「Infrastructure as Code（IaC）」です。まず、この概念を理解することから始めましょう。

12.3.1 IaCの概念#

Infrastructure as Code（IaC）とは、サーバーやネットワークなどのインフラ構成を、手作業ではなく「コード（設定ファイル）」として定義・管理する手法です。

基礎編では、PowerShellのコマンドを1つずつ実行してサーバーを設定してきました。たとえば、第5回で学んだサービスの設定は以下のような手順でした。

[実行環境: PowerShell 7.4 (管理者)]

# 手動での設定手順（命令的アプローチ）
# 1. サービスの状態を確認する
Get-Service -Name "W32Time"

# 2. サービスが停止していたら起動する
Start-Service -Name "W32Time"

# 3. スタートアップの種類を「自動」に変更する
Set-Service -Name "W32Time" -StartupType Automatic

この方法は、手順を1つずつ実行するため直感的でわかりやすい反面、以下のような課題があります。

• 再現性の問題：手順書通りに実行しても、人によって微妙な差異が生まれることがある
• スケーラビリティの問題：サーバーが10台、100台と増えた場合、すべてに同じ設定を手動で適用するのは現実的ではない
• ドキュメントとの乖離：手順書と実際の設定が時間とともにずれていく

IaCでは、サーバーの「あるべき状態」を設定ファイルとして記述します。この設定ファイル自体がインフラの「ドキュメント」となり、そのままシステムに適用することで、何台のサーバーに対しても同一の設定を確実に展開できます。

12.3.2 IaCのメリット#

IaCを導入することで、以下のようなメリットが得られます。

基礎編との関連： 第11回で学んだセキュリティテンプレート（INFファイル）を思い出してください。セキュリティ設定をファイルにエクスポートし、別のサーバーにインポートするアプローチは、IaCの考え方に近いものでした。IaCはこの考え方をさらに体系化・発展させたものです。

12.3.3 構成管理ツールの種類#

IaCを実現するためのツールは複数存在します。代表的なものを簡単に紹介します。

本シリーズでは、Windows Server環境との親和性が最も高いDSC v3を使用します。DSC v3はMicrosoftが開発した構成管理ツールで、PowerShellとの統合が優れており、Windows Serverの管理に最適です。他のツールとの詳細な比較は本シリーズの範囲外ですが、DSCで学ぶ「宣言的な構成管理」の概念は、他のツールにも共通するものです。

12.4 DSC（Desired State Configuration）とは#

DSCは「Desired State Configuration」の略で、日本語にすると「望ましい状態の構成」です。その名の通り、システムの「あるべき状態（Desired State）」を定義し、システムをその状態に維持するためのツールです。

12.4.1 DSCの概念#

DSCの基本的な考え方は非常にシンプルです。

1. 「あるべき状態」を定義する：構成ファイル（YAML形式）に「サーバーがどうあるべきか」を記述する
2. 現在の状態と比較する：DSCが現在のサーバーの状態と、定義した「あるべき状態」を比較する
3. 差異があれば修正する：差異が見つかった場合、DSCが自動的にサーバーを「あるべき状態」に変更する

たとえば、「W32Time（Windows Time）サービスは常に起動していて、スタートアップの種類は『自動』であるべき」という状態を定義しておけば、DSCはその状態を実現し、維持します。

12.4.2 宣言的（Declarative）と命令的（Imperative）#

DSCを理解するうえで最も重要な概念が、「宣言的」と「命令的」の違いです。基礎編で書いてきたPowerShellスクリプトと比較して説明します。

命令的（Imperative）アプローチ ― 「どうやるか」を記述する

基礎編で学んだPowerShellスクリプトは「命令的」なアプローチです。「何をするか」の手順を1つずつ記述します。

[実行環境: PowerShell 7.4 (管理者)]

# 命令的アプローチ：手順を1つずつ記述する
# 「どのように（How）」サービスを設定するかを書く

# 手順1: サービスの現在の状態を取得する
$service = Get-Service -Name "W32Time"

# 手順2: サービスが停止していたら起動する
if ($service.Status -ne "Running") {
    Start-Service -Name "W32Time"
    Write-Host "W32Timeサービスを起動しました" -ForegroundColor Green
}

# 手順3: スタートアップの種類を確認し、「自動」でなければ変更する
if ($service.StartType -ne "Automatic") {
    Set-Service -Name "W32Time" -StartupType Automatic
    Write-Host "スタートアップの種類を「自動」に変更しました" -ForegroundColor Green
}

宣言的（Declarative）アプローチ ― 「何を達成したいか」を記述する

DSCでは「宣言的」なアプローチを取ります。「最終的にどうなっていてほしいか（What）」だけを記述し、「どうやってその状態にするか（How）」はDSCに任せます。

# 宣言的アプローチ：「あるべき状態」だけを記述する
# 「何を（What）」達成したいかだけを書く
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2024/04/config/document.json
resources:
  - name: W32Timeサービスの設定
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Ensure W32Time is running
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: W32Time
            State: Running
            StartupType: Automatic

両者の違いを表にまとめます。

ポイント： 宣言的アプローチでは、「サービスが既に起動しているかどうか」の判断をDSCが行います。命令的アプローチのようにif文で条件分岐を書く必要がありません。これにより、構成ファイルがシンプルで読みやすくなります。

12.4.3 冪等性（Idempotent）#

DSCのもう1つの重要な概念が「冪等性（べきとうせい）」です。冪等性とは、同じ操作を何度実行しても結果が変わらない性質のことです。

命令的アプローチの場合、同じスクリプトを2回実行すると問題が起きることがあります。

[実行環境: PowerShell 7.4 (管理者)]

# 命令的アプローチの問題：冪等性がない例
# ファイアウォール規則を追加するスクリプト（第7回の内容）

# 1回目の実行：規則が作成される → OK
New-NetFirewallRule -DisplayName "Allow HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow

# 2回目の実行：同名の規則が既に存在するためエラーになる → NG
# エラー: New-NetFirewallRule: Cannot create a file when that file already exists.

この問題を回避するには、「既に存在するか確認してから作成する」という条件分岐を追加する必要があります。

# 冪等性を自分で実装する場合
$existingRule = Get-NetFirewallRule -DisplayName "Allow HTTP" -ErrorAction SilentlyContinue
if (-not $existingRule) {
    New-NetFirewallRule -DisplayName "Allow HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
}

DSCの宣言的アプローチでは、この冪等性が自動的に保証されます。「HTTP通信を許可するファイアウォール規則が存在すべき」と定義しておけば、DSCは以下のように動作します。

• 規則が存在しない場合：規則を作成する
• 規則が既に存在する場合：何もしない（既に「あるべき状態」のため）
• 規則の設定が異なる場合：正しい設定に修正する

つまり、DSCの構成を何度適用しても、サーバーは常に同じ「あるべき状態」に収束します。これにより、安心して繰り返し構成を適用できます。

12.5 DSC v3の特徴#

DSCには複数のバージョンが存在します。本シリーズでは最新のDSC v3を使用します。ここでは、DSC v3の特徴と、従来バージョンとの違いを説明します。

12.5.1 DSC v2からDSC v3への進化#

DSC v3は2025年3月にバージョン3.0.0がGA（General Availability：一般提供）となり、その後2025年6月にバージョン3.1.0がリリースされました。従来のDSC v2（PowerShell Desired State Configuration v1.1およびv2）から大幅にアーキテクチャが変更されています。

12.5.2 DSC v3の主要な変更点#

LCM（Local Configuration Manager）が不要に

DSC v2では、LCM（Local Configuration Manager）と呼ばれるサービスがWindows上で常駐し、構成の適用や監視を行っていました。DSC v3ではLCMが廃止され、dscコマンドを直接実行する方式に変わりました。これにより、以下のメリットが生まれます。

• シンプルな実行モデル：コマンドを実行するだけで構成を適用できる
• 統合の容易さ：タスクスケジューラやCI/CDパイプラインなど、コマンドを実行できるツールなら何でもDSCを呼び出せる
• リソース消費の削減：常駐サービスが不要なため、システムリソースの消費が少ない

YAML / JSON形式の構成ファイル

DSC v2ではMOF（Managed Object Format）という独自形式のファイルを使用していましたが、DSC v3ではYAMLまたはJSON形式で構成を記述します。YAMLは人間が読み書きしやすいデータ形式で、多くの構成管理ツールで採用されています。YAML構文の詳細は次回（第13回）で学びます。

クロスプラットフォーム対応

DSC v3はRust言語で実装された単一の実行ファイル（dsc / dsc.exe）として動作します。Windows、Linux、macOSで利用可能です。本シリーズではWindows Server 2025での使用に焦点を当てますが、学んだ概念はLinux環境でも応用できます。

重要： 本シリーズではDSC v3のみを扱います。DSC v2（LCM、MOFファイル中心のアプローチ）は扱いません。インターネット上でDSCに関する情報を検索する際は、DSC v3の情報であることを確認してください。DSC v2の情報をDSC v3に適用するとエラーが発生する場合があります。

12.5.3 DSC v3の現状と注意点#

DSC v3は2025年にGA（一般提供）されたばかりの比較的新しいツールです。以下の点を認識しておきましょう。

• 急速に発展中：DSC v3.0.0が2025年3月にGA、v3.1.0が2025年6月にリリースされ、開発が活発に続いています。バージョンアップに伴いコマンドや仕様が変更される可能性があります
• 組み込みリソースは限定的：DSC v3にネイティブで組み込まれているリソースは、レジストリ管理やOS情報取得など基本的なものに限られます。ただし、アダプター機能を通じて既存のPowerShell DSCリソース（PSDesiredStateConfiguration モジュール等）を利用できます
• ドキュメントの整備は進行中：公式ドキュメントは継続的に拡充されていますが、従来のDSC v2と比較するとまだ発展途上の部分があります

これらの点を踏まえたうえで、DSC v3は「構成管理の概念を学ぶ」「基本的な自動化を実践する」という目的には十分に活用できます。

12.6 DSC v3のインストール#

ここからは実際にDSC v3をインストールし、使い始める準備を行います。

12.6.1 前提条件の確認#

DSC v3をインストールする前に、前提条件が満たされていることを確認します。

[実行環境: PowerShell 7.4 (管理者)]

# PowerShellのバージョンを確認（7.4以降であること）
$PSVersionTable.PSVersion

実行結果の例：

Major  Minor  Patch  PreReleaseLabel BuildLabel
-----  -----  -----  --------------- ----------
7      4      6

PowerShell 7.4以降がインストールされていない場合は、第2回の手順に従ってインストールしてください。

# wingetが利用可能か確認
winget --version

実行結果の例：

v1.9.25200

注意： wingetはWindows Server 2025のDesktop Experienceに標準搭載されています。Server Coreではwingetが利用できないため、DSC v3のインストール方法が異なります（GitHubリリースページからの手動ダウンロードが必要）。本シリーズではDesktop Experienceを前提としています。

12.6.2 wingetによるインストール#

DSC v3は、Microsoft Storeを通じてwingetでインストールできます。以下のコマンドを実行してください。

[実行環境: PowerShell 7.4 (管理者)]

# DSC v3のインストール
# Microsoft Store経由でインストールすると、自動更新が有効になります
winget install --id 9NVTPZWRC6KQ --source msstore --accept-package-agreements --accept-source-agreements

実行結果の例：

Found DesiredStateConfiguration [9NVTPZWRC6KQ] Version Unknown
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully installed

Tips： winget search DesiredStateConfiguration を実行すると、利用可能なパッケージを確認できます。「DesiredStateConfiguration」が安定版、「DesiredStateConfiguration-Preview」がプレビュー版です。本シリーズでは安定版を使用します。

12.6.3 インストール確認#

インストールが完了したら、dscコマンドが使えることを確認します。

[実行環境: PowerShell 7.4 (管理者)]

# DSCのバージョンを確認
dsc --version

実行結果の例：

3.1.0

注意： dsc コマンドが見つからない場合は、PowerShellを一度閉じて再起動してください。インストール時にPATH環境変数が更新されますが、既存のセッションには反映されないことがあります。

dscコマンドのヘルプを表示して、利用可能なサブコマンドを確認しましょう。

# DSCコマンドのヘルプを表示
dsc --help

実行結果の例：

DSC v3.1.0

Desired State Configuration

Usage: dsc [OPTIONS] <COMMAND>

Commands:
  config    Apply a configuration document
  resource  Invoke a specific DSC Resource
  schema    Get the JSON schema for a DSC type
  help      Print this message or the help of the given subcommand(s)

Options:
  -t, --trace-level <TRACE_LEVEL>    Trace level [possible values: error, warn, info, debug, trace]
  -o, --output-format <OUTPUT_FORMAT> Output format [possible values: json, pretty-json, yaml, json-array, pass-through]
  -h, --help                          Print help
  -V, --version                       Print version

主要なサブコマンドは2つです。

12.6.4 PSDesiredStateConfigurationモジュールのインストール#

DSC v3の組み込みリソースだけでなく、従来のPowerShell DSCリソース（サービス管理、Windows機能の管理など）を使用するために、PSDesiredStateConfigurationモジュールをインストールします。

[実行環境: PowerShell 7.4 (管理者)]

# PSDesiredStateConfigurationモジュールのインストール
Install-Module -Name PSDesiredStateConfiguration -Repository PSGallery -Force

実行結果の例：

Installing package 'PSDesiredStateConfiguration'
Downloaded 0.00 MB out of 0.37 MB.

# インストールされたモジュールを確認
Get-Module -Name PSDesiredStateConfiguration -ListAvailable |
    Select-Object -Property Name, Version, ModuleBase

実行結果の例：

Name                          Version ModuleBase
----                          ------- ----------
PSDesiredStateConfiguration   2.0.7   C:\Program Files\PowerShell\Modules\PSDesiredStateConfiguration\2.0.7

解説： PSDesiredStateConfigurationモジュールは、DSC v3のアダプター機能を通じて利用されます。このモジュールにはService（サービス管理）、WindowsFeature（Windows機能の管理）、File（ファイル管理）、Environment（環境変数管理）など、Windows Serverの管理に便利なリソースが含まれています。

12.7 基本コマンドの理解#

DSC v3の基本コマンドを学んでいきましょう。DSC v3のコマンドは、dsc resource（個別リソースの操作）とdsc config（構成ファイルによる一括操作）の2つに大別されます。今回はdsc resourceコマンドを中心に学びます。

12.7.1 dsc resource list ― 利用可能なリソースの一覧#

dsc resource list は、システムにインストールされているDSCリソースの一覧を表示するコマンドです。まず、DSC v3に組み込まれているリソースを確認しましょう。

[実行環境: PowerShell 7.4 (管理者)]

# 利用可能なDSCリソースの一覧を表示
dsc resource list

実行結果の例：

Type                                      Kind      Version  Caps       RequireAdapter  Description
----                                      ----      -------  ----       --------------  -----------
Microsoft.DSC.Transitional/RunCommandOnSet Resource  0.1.0    gs------   …
Microsoft.DSC/Assertion                    Group     0.1.0    gs--t---   …
Microsoft.DSC/Group                        Group     0.1.0    gs--t---   …
Microsoft.DSC/PowerShell                   Adapter   0.1.0    gs--t-e-   …
Microsoft.Windows/RebootPending            Resource  0.1.0    g-------   …
Microsoft.Windows/Registry                 Resource  0.1.0    gs-w-d--   …
Microsoft.Windows/WMI                      Adapter   0.1.0    g-------   …
Microsoft/OSInfo                           Resource  0.1.0    g------e   …

表示されるリソースの情報を理解しましょう。

上記はDSC v3に組み込まれているリソースです。PowerShell DSCリソース（PSDesiredStateConfigurationモジュール）を使用するには、アダプターを指定してリソースを一覧表示します。

# PowerShellアダプター経由のリソースを一覧表示
dsc resource list --adapter Microsoft.DSC/PowerShell

実行結果の例（一部抜粋）：

Type                                           Kind      Version  Caps       RequireAdapter
----                                           ----      -------  ----       --------------
PSDesiredStateConfiguration/Archive            Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Environment        Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/File               Resource  1.0.0    gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Group              Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Log                Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/MsftDscPackage     Resource  1.0.0.0  gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/ProcessSet         Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Registry           Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Script             Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Service            Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/ServiceSet         Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/User               Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsFeature     Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsFeatureSet  Resource  1.1      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsOptionalFeature    Resource  1.0      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsOptionalFeatureSet Resource  1.0      gs--t---   Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsProcess     Resource  1.1      gs--t---   Microsoft.DSC/PowerShell

解説： RequireAdapter列にMicrosoft.DSC/PowerShellと表示されているリソースは、PowerShellアダプター経由で呼び出されるリソースです。基礎編で学んだサービス管理（PSDesiredStateConfiguration/Service）やWindows機能の管理（PSDesiredStateConfiguration/WindowsFeature）など、実用的なリソースが豊富に用意されています。

注意： アダプター経由のリソース一覧を初めて表示する際は、リソースの検出に時間がかかることがあります（数十秒程度）。これはDSCがPowerShellモジュールを検索してキャッシュを構築するためです。2回目以降はキャッシュが利用されるため高速になります。

12.7.2 dsc resource get ― リソースの現在の状態を取得#

dsc resource get は、指定したリソースの現在の状態を取得するコマンドです。「今、サーバーがどういう状態にあるか」を確認できます。

組み込みリソースの場合

まず、組み込みリソースのMicrosoft/OSInfoを使ってOS情報を取得してみましょう。

[実行環境: PowerShell 7.4 (管理者)]

# OS情報を取得する
dsc resource get --resource Microsoft/OSInfo

実行結果の例：

actualState:
  $id: https://developer.microsoft.com/json-schemas/dsc/os_info/20230303/Microsoft.DSC.OS_Info.schema.json
  family: Windows
  version: 10.0.26100
  edition: Windows Server 2025 Datacenter
  bitness: "64"
  architecture: x86_64

このコマンドは入力（--input）を必要としません。Microsoft/OSInfoリソースはシステム情報を取得するだけの読み取り専用リソースです。

入力が必要なリソースの場合

多くのリソースでは、「どのリソースインスタンスの状態を取得するか」を指定するための入力が必要です。たとえば、レジストリリソースでは「どのレジストリキーの状態を取得するか」を指定します。

# レジストリの状態を取得する（キーパスを入力として指定）
dsc resource get --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion"

実行結果の例：

actualState:
  keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
  _exist: true

入力の指定方法には以下のオプションがあります。

Tips： DSC v3はコンソールに直接出力する場合はYAML形式で、パイプラインに出力する場合はJSON形式をデフォルトで使用します。出力形式を明示的に指定するには --output-format（-o）オプションを使用します（例：-o json、-o yaml、-o pretty-json）。

12.7.3 dsc resource test ― 現在の状態と目標状態の比較#

dsc resource test は、リソースの現在の状態と、指定した目標状態を比較するコマンドです。実際に変更は行わず、「差異があるかどうか」だけを確認します。

[実行環境: PowerShell 7.4 (管理者)]

# レジストリキーの存在をテストする
dsc resource test --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion"

実行結果の例：

desiredState:
  keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
actualState:
  keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
  _exist: true
inDesiredState: true
differingProperties: []

テスト結果の読み方を確認しましょう。

存在しないレジストリキーをテストすると、差異が検出されます。

# 存在しないレジストリキーをテストする
dsc resource test --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\DSCTest\NonExistent"

実行結果の例：

desiredState:
  keyPath: HKLM\SOFTWARE\DSCTest\NonExistent
actualState:
  keyPath: HKLM\SOFTWARE\DSCTest\NonExistent
  _exist: false
inDesiredState: false
differingProperties:
- _exist

inDesiredState: false は「目標状態ではない（変更が必要）」を意味し、differingProperties に _exist が表示されていることから、「キーが存在しない」ことが差異の原因であることがわかります。

12.7.4 dsc resource set ― リソースの状態を設定#

dsc resource set は、リソースを指定した目標状態に設定するコマンドです。実際にシステムに変更を加えます。

[実行環境: PowerShell 7.4 (管理者)]

# テスト用のレジストリキーを作成する
dsc resource set --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\DSCTest"

実行結果の例：

beforeState:
  keyPath: HKLM\SOFTWARE\DSCTest
  _exist: false
afterState:
  keyPath: HKLM\SOFTWARE\DSCTest
  _exist: true
changedProperties:
- _exist

set コマンドの出力は以下の情報を含みます。

冪等性を確認するために、同じコマンドをもう一度実行してみましょう。

# 同じコマンドを再度実行する（冪等性の確認）
dsc resource set --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\DSCTest"

実行結果の例：

beforeState:
  keyPath: HKLM\SOFTWARE\DSCTest
  _exist: true
afterState:
  keyPath: HKLM\SOFTWARE\DSCTest
  _exist: true
changedProperties: []

2回目の実行では、beforeStateが既に_exist: trueであるため、何も変更されません（changedPropertiesが空配列）。これが冪等性です。

# テスト用に作成したレジストリキーを削除する（PowerShellで）
Remove-Item -Path "HKLM:\SOFTWARE\DSCTest" -Force

重要： dsc resource set はシステムに実際の変更を加えます。本番環境では、必ず dsc resource test で事前に差異を確認してから set を実行する習慣をつけてください。これは第13回以降で学ぶ「テストファースト」の原則に通じます。

12.7.5 基本コマンドのまとめ#

ここまで学んだDSC v3の基本コマンドをまとめます。

また、構成ファイル（YAML/JSON）を使って複数のリソースをまとめて操作するコマンドもあります。こちらは第13回で詳しく学びます。

12.8 リソースの概念#

DSCを使いこなすためには、「リソース」の概念をしっかり理解する必要があります。

12.8.1 リソースとは#

DSCにおけるリソース（Resource）とは、管理対象の単位です。たとえば、以下のようなものがリソースとして定義されています。

各リソースは、対象の「状態を取得する（get）」「状態をテストする（test）」「状態を設定する（set）」といった操作を持っています。リソースの内部で、実際にどのようなPowerShellコマンドやAPIが実行されるかは、リソースの実装に隠蔽されています。利用者は「あるべき状態」を宣言するだけで済みます。

12.8.2 リソースの種別#

DSC v3には、以下の3種類のリソースがあります。

特に重要なのがAdapterです。DSC v3はRust製のツールですが、アダプターを通じてPowerShellベースの既存DSCリソースを呼び出すことができます。

• Microsoft.DSC/PowerShell：PowerShell 7.x用のDSCリソースを呼び出すアダプター
• Microsoft.Windows/WindowsPowerShell：Windows PowerShell 5.1用のDSCリソースを呼び出すアダプター

本シリーズでは、構成ファイルの中でPowerShellアダプターを通じてPSDesiredStateConfigurationモジュールのリソースを利用する方法を、次回以降で学びます。

12.8.3 リソースプロバイダーの仕組み#

DSC v3のリソースは、以下のような仕組みで動作しています。

1. DSC v3コマンド（dsc）が構成ファイルまたはコマンドライン引数を受け取る
2. 指定されたリソースタイプに応じて、リソースプロバイダー（実行ファイルやPowerShellモジュール）を呼び出す
3. リソースプロバイダーが実際のシステム操作（レジストリの読み書き、サービスの起動・停止など）を実行する
4. 結果がJSON形式でDSC v3に返される

リソースプロバイダーの実装方法は多様です。組み込みリソース（Microsoft.Windows/Registryなど）はDSC v3の実行ファイルに含まれていますが、PowerShellモジュールとして実装されたリソースはアダプター経由で呼び出されます。また、bash、Python、C#、Goなど、さまざまな言語で独自のリソースを作成することも可能です。

12.9 実践：リソースの状態確認#

ここまでの知識を活用して、実際にDSCでリソースの状態を確認してみましょう。基礎編で手動管理していた対象を、DSCで確認する方法を実践します。

12.9.1 OS情報の確認#

まず、Microsoft/OSInfoリソースでOS情報を取得します。

[実行環境: PowerShell 7.4 (管理者)]

# OS情報を取得する
dsc resource get --resource Microsoft/OSInfo

実行結果の例：

actualState:
  $id: https://developer.microsoft.com/json-schemas/dsc/os_info/20230303/Microsoft.DSC.OS_Info.schema.json
  family: Windows
  version: 10.0.26100
  edition: Windows Server 2025 Datacenter
  bitness: "64"
  architecture: x86_64

これは第1回で Get-ComputerInfo コマンドレットで確認した情報と同等のものです。DSCリソースを通じて同じ情報を取得できることがわかります。

12.9.2 レジストリの確認#

第11回でセキュリティ設定に使用したレジストリの状態を、DSCで確認してみましょう。

[実行環境: PowerShell 7.4 (管理者)]

# Windows Updateの設定に関するレジストリキーを確認
dsc resource get --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"

実行結果の例：

actualState:
  keyPath: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
  _exist: true

特定のレジストリ値を含めて確認するには、valueNameを指定します。

# レジストリ値まで指定して確認
dsc resource get --resource Microsoft.Windows/Registry --input '{"keyPath": "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion", "valueName": "ProductName"}'

実行結果の例：

actualState:
  keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
  valueName: ProductName
  valueData:
    String: Windows Server 2025 Datacenter
  _exist: true

Tips： --input に渡す値はYAML形式でもJSON形式でも構いません。JSONの場合はバックスラッシュのエスケープ（\\）が必要になるため、シンプルな入力ならYAML形式のほうが読みやすくなります。

12.9.3 再起動保留状態の確認#

サーバー管理でよく遭遇する「再起動保留中」の状態も、DSCリソースで確認できます。

[実行環境: PowerShell 7.4 (管理者)]

# 再起動が保留されているかを確認
dsc resource get --resource Microsoft.Windows/RebootPending

実行結果の例：

actualState:
  rebootPending: false

rebootPending: false であれば、再起動は不要です。Windows Updateの適用後やWindows機能の追加後に true になることがあります。

12.9.4 手動管理とDSCの対応関係#

ここまでの実践を通じて、基礎編の手動管理とDSCの対応関係を整理しましょう。

現時点では「DSCでも同じ情報が取得できる」ことを確認しただけですが、次回以降で構成ファイルを使った本格的な自動化を学ぶことで、DSCの真価が発揮されます。

12.10 よくあるエラーと対処法#

トラブルシューティングのヒント： DSCコマンドの詳細な実行ログを確認するには、--trace-level trace オプションを使用します。たとえば dsc --trace-level trace resource get -r Microsoft/OSInfo のように指定すると、DSCの内部動作の詳細なログが表示されます。

12.11 まとめ#

第12回では、応用編の最初のステップとして、DSC v3（Desired State Configuration v3）の概念と基本操作を学びました。

• Infrastructure as Code（IaC）
  • インフラの構成をコードとして定義・管理する手法
  • 手作業によるミスの削減、環境の一貫性、バージョン管理が主なメリット
• 宣言的アプローチ
  • DSCは「何を達成したいか（What）」を記述する宣言的アプローチ
  • 基礎編で学んだPowerShellスクリプトの「どのように実現するか（How）」を記述する命令的アプローチと対比される
• 冪等性（Idempotent）
  • 同じ操作を何度実行しても結果が変わらない性質
  • DSCでは冪等性が自動的に保証され、安全に繰り返し適用できる
• DSC v3の特徴
  • スタンドアロンのコマンドとして動作（LCM不要）
  • YAML / JSON形式の構成ファイル
  • クロスプラットフォーム対応
  • 既存のPowerShell DSCリソースをアダプター経由で利用可能
• 基本コマンド
  • dsc resource list：利用可能なリソースの確認
  • dsc resource get：リソースの現在の状態を取得
  • dsc resource test：現在の状態と目標状態の比較
  • dsc resource set：リソースの状態を設定

基礎編で手動で行ってきたサーバー設定を、DSCを使って「宣言的」に管理するための第一歩を踏み出しました。次回からは、構成ファイル（YAML）を使った本格的な構成管理を学んでいきます。

12.12 次回予告#

第13回では「DSC構成ファイルの作成 ― YAMLの基本とリソース定義」と題して、YAML構文の基礎を学び、実際に構成ファイルを作成してテスト・適用する方法を学びます。環境変数やレジストリの設定を例に、dsc config test と dsc config set コマンドの使い方を実践します。構成ファイルを通じて、複数のリソースをまとめて管理する方法を身につけましょう。

12.13 参考リンク#

• Announcing Microsoft Desired State Configuration v3.0.0 – PowerShell Team
• Get started with Microsoft Desired State Configuration v3.0.0 – PowerShell Team
• DSC v3 ドキュメント – Microsoft Learn
• DSC v3 GitHub リポジトリ – PowerShell/DSC
• PSDesiredStateConfiguration モジュール – GitHub
• dsc resource コマンドリファレンス – Microsoft Learn
• Using DSC v3 on Windows Server 2025 – Microsoft Tech Community