Windows Developer Configurationsは、Windows 11の開発PCを「毎回同じ状態でセットアップする」ための公式な構成ファイル群です。今回のポイントは、手作業でVS Code、Git、WSL、PowerShell 7、各言語ランタイム、Windows設定を再現するのではなく、WinGetベースの構成としてチームで共有・再実行しやすくなったことです。
とくに新入社員や業務委託メンバーのオンボーディング、PC交換、検証用端末の初期化、Windows 365 Cloud PCの標準化に効果があります。一方で、管理者はそのまま全社展開する前に、WinGetの利用ポリシー、DSCリソースの信頼性、WSLによる再起動、プロキシやパッケージソース制限との衝突を確認する必要があります。
MicrosoftはBuild 2026で、Windows Developer Configurationsを一般提供として案内し、WinGetによりVS Code、GitHub Copilot、WSL、PowerShell 7、開発者向け設定を1コマンドで構成できるものとして説明しています。米国時間2026年6月2日の発表は、日本時間では2026年6月3日にあたります。(Windows Blog)
Windows Developer Configurationsとは
Windows Developer Configurationsは、Windowsの開発環境を宣言的にセットアップするための構成ファイルとスクリプト群です。Microsoft Learnでは、Dev Configsを「新しいWindowsマシンを1つのコマンドでready-to-codeの状態にする、キュレーションされたオープンソース構成ファイル」と説明しています。構成は再実行しても安全な設計とされ、パッケージ、OS設定、インストール後の処理をまとめて扱います。(Microsoft Learn)
従来の開発環境構築では、次のような属人的な作業が起きがちでした。
- 「手順書どおりに入れたはずなのに、Node.jsやPythonのバージョンが違う」
- 「WSL、Git、VS Code拡張、PATH設定のどこかでつまずく」
- 「プロジェクト参加者ごとにターミナルやファイル表示設定が微妙に違う」
- 「PC交換のたびに半日から1日かけて環境を作り直す」
Windows Developer Configurationsの狙いは、こうした初期セットアップを「人間が覚える手順」から「レビュー可能な構成ファイル」に移すことです。
何が変わるのか
今回の変更は、Windowsにまったく新しいパッケージ管理の仕組みが追加されたというより、既存のWinGet Configurationを使った実用的な開発者向けセットアップパスが整備された、と見るのが正確です。
| 観点 | これまで起きやすかったこと | Windows Developer Configurationsで変わること |
|---|---|---|
| 開発PCの初期構築 | 手順書、個人メモ、口頭説明に依存 | .winget構成やスクリプトで再現しやすくなる |
| ツール導入 | VS Code、Git、WSL、言語環境を個別にインストール | 目的別の構成を選び、一括適用できる |
| チーム標準化 | メンバーごとに設定差分が出やすい | 構成ファイルをリポジトリ管理し、変更履歴を追える |
| 再セットアップ | PC交換や初期化のたびに手作業 | 同じ構成を再実行して復旧しやすい |
| 管理者の確認 | 何が入ったか後から追いにくい | 構成ファイルを事前レビューできる |
MicrosoftのGitHubリポジトリでは、Windows Developer Configについて「fresh Windows installから開発ボックスへ1コマンドで移行する」構成として説明され、Windows Dev Config、WSL Comfort、Workloadsの3系統が用意されています。(GitHub)
用意されている3つの構成パターン
Windows Developer Configurationsは、用途に応じて大きく3つに分けて考えると理解しやすくなります。
Windows Dev Config
Windows Dev Configは、Windows 11の新規環境を開発用ワークステーションとして整えるための構成です。
公式リポジトリでは、PowerShell 7、Git、GitHub CLI、VS Code、.NET SDK、Python、Node.js、PowerToys、WSL + Ubuntu、Windows Terminal関連の設定、開発者向けWindows設定などが例として挙げられています。(GitHub)
向いているのは、次のようなケースです。
- 新しい開発PCを支給する
- 検証用のWindows 11 VMを短時間で作りたい
- チームの標準的なWindows開発環境を決めたい
- WSLを含むWindows + Linux開発環境をまとめて準備したい
注意点は、WSLの有効化で再起動が必要になることです。公式READMEでも、WSL有効化に伴う再起動後、サインイン後にRunOnceで構成が再開される旨が説明されています。(GitHub)
WSL Comfort
WSL Comfortは、WindowsとWSLを組み合わせたターミナル体験を整えるための構成です。
たとえば、zshまたはbash、Starship、fzf、ripgrep、fd、bat、eza、zoxide、jq、Homebrew、Gitの既定設定、Nerd Font、Windows Terminalプロファイルなど、日常的なCLI作業を快適にする要素を選べます。(GitHub)
フルセットの開発PC構成までは不要で、まずWSLとシェル体験だけ標準化したいチームに向いています。
Workloads
Workloadsは、特定の言語やフレームワーク向けの単体ツールチェーンを入れる構成です。
公式READMEでは、TypeScript、Python、.NET、Go、Java、Rust、PHP、WinForms、WinUI 3などのワークロードが例示されています。各ワークロードはconfiguration.wingetとinstall.ps1を持ち、用途に応じて必要な構成だけを適用できます。(GitHub)
実務では、いきなりWindows Dev Configを全体適用するより、まずWorkloadsで「Pythonチーム向け」「TypeScriptチーム向け」のように小さく始めるほうが安全です。
WinGet Configurationとの関係
Windows Developer Configurationsの土台は、Windows Package Managerのwinget configureです。
WinGet Configurationは、YAML形式の構成ファイルにソフトウェア、バージョン、ツール、依存関係、OS設定を定義し、PowerShell DSCとWindows Package Managerを使って目的の開発環境へ近づける仕組みです。Microsoft Learnでは、手動のマシンセットアップやプロジェクトオンボーディングを、信頼性と再現性のある単一コマンドにまとめられると説明されています。(Microsoft Learn)
重要なのは、WinGet Configurationが「順番に命令を実行するだけのバッチファイル」ではないことです。構成ファイルには、前提条件を表すAssertionsと、インストールや設定を表すResourcesを記述します。WinGetは構成を検証し、必要なDSCリソースを使って望ましい状態を適用します。(Microsoft Learn)
つまり、チームで使うなら次のように役割分担できます。
| 役割 | 見るべきポイント |
|---|---|
| 開発者 | 自分の担当言語・ツールが含まれているか、既存環境に影響しないか |
| チームリード | プロジェクトで必要なツールが標準化されているか |
| 情シス・管理者 | 組織ポリシー、パッケージソース、管理者権限、監査方針に合うか |
| セキュリティ担当 | DSCリソース、PowerShellスクリプト、外部ソースの信頼性を確認できるか |
対象者と影響範囲
Windows Developer Configurationsの影響を受けるのは、主にWindows 11で開発環境を構築・管理するチームです。一般ユーザーのPCに自動で適用される更新ではありません。構成ファイルを取得し、winget configureなどで明示的に実行した場合に影響します。
影響が大きい人
| 対象者 | 影響 |
|---|---|
| Windows 11で開発するエンジニア | 初期セットアップやPC交換時の手作業を減らせる |
| 開発チームのリード | チーム標準の環境構成をレビュー・共有しやすくなる |
| 情シス・端末管理者 | WinGet、Store、PowerShell、WSL、権限昇格の管理方針を見直す必要がある |
| セキュリティ担当 | 構成ファイルとDSCリソースの信頼性確認が必要になる |
| Windows 365管理者 | Developer configuration付きCloud PCの活用を検討できる |
MicrosoftはBuild 2026で、Windows 365 with Developer configurationもPublic Previewとして案内しています。これはローカルPCだけでなく、クラウド上のWindows開発環境を標準化する流れとも関係します。(Windows Blog)
影響が小さい人
次のような場合は、すぐに対応する必要性は高くありません。
- 個人PCで手動セットアップに満足している
- 開発環境をすべてDev ContainerやクラウドIDEで完結している
- 会社の標準イメージやIntune構成で開発PCを厳密に管理している
- WinGetやMicrosoft Storeへのアクセスが制限されている
- WSLを利用しない方針の端末である
ただし、将来的にオンボーディング標準化やPC交換対応を改善したい場合は、早めに検証用VMで動作確認しておく価値があります。
管理者が最初に確認すべき設定
企業や学校で使う場合、開発者にコマンドだけ渡して実行させるのは避けるべきです。とくに次の設定を確認してください。
| 確認項目 | 見る理由 |
|---|---|
| WinGetの利用可否 | App InstallerやWinGet CLIがポリシーで無効化されていると実行できない |
winget configureの利用可否 | Configuration機能自体がポリシーで制限される場合がある |
| Microsoft Storeソース | Storeソースを使うパッケージがある場合、組織の制限と衝突する可能性がある |
| 追加ソースの許可 | 社外リポジトリや追加ソースを使う設計にする場合、Allowed Sourcesを確認する |
| PowerShell実行ポリシー | スクリプトやDSCリソースの実行に影響する可能性がある |
| プロキシ・SSL検査 | winget、GitHub、PowerShell Galleryへの接続で失敗しやすい |
| WSLと仮想化 | BIOS/UEFIの仮想化設定やVM上のネストされた仮想化が必要になる場合がある |
| 再起動許可 | WSL有効化などで再起動が入るため、業務時間中の実行に向かない |
Windows Package Manager関連のPolicy CSPには、WinGet CLIの実行可否を制御するEnableWindowsPackageManagerCommandLineInterfacesや、Configuration機能を制御するEnableWindowsPackageManagerConfigurationがあります。どちらもWindows 11 version 24H2以降を対象に含むポリシーとして説明されています。(Microsoft Learn)
開発者が試す前の準備
個人検証であっても、いきなり普段使いのPCに適用するのではなく、次の順で進めるのが安全です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 検証用VMまたは予備PCを用意する | 既存環境への影響を避ける |
| 2 | 公式リポジトリの内容を確認する | 何がインストール・変更されるか把握する |
| 3 | winget --versionを確認する | 必要なWinGetバージョンを満たすか確認する |
| 4 | winget configure --enableを実行する | Configuration機能を有効化する |
| 5 | 目的に合う構成を選ぶ | フル構成、WSL、言語別構成を選択する |
| 6 | 実行ログを残す | 失敗時の切り分けに使う |
| 7 | 再起動後に確認する | WSLやPATH反映を確認する |
winget configureの公式ドキュメントでは、構成ファイルの実行だけでなく、show、list、test、validate、exportなどのサブコマンドも案内されています。展開前には、少なくともvalidateやshowで構成内容を確認するとよいでしょう。(Microsoft Learn)
基本的な実行イメージ
Gitがすでに入っている環境なら、公式リポジトリを取得して構成を適用します。
winget configure --enable
git clone https://github.com/microsoft/WindowsDeveloperConfig.git
cd WindowsDeveloperConfig
winget configure -f .\windows-dev-config\dev-config.winget --accept-configuration-agreements --disable-interactivityクリーンインストール直後でGitがない場合は、ZIPをダウンロードして展開する方法も公式READMEで案内されています。実運用では、検証済みのZIPや社内フォークを配布し、どの時点の構成を使ったか分かるようにしておくと安全です。(GitHub)
なお、--accept-configuration-agreementsや--disable-interactivityは無人実行には便利ですが、内容を確認せずに使うべきではありません。最初の検証では対話ありで実行し、何が求められるのか確認してから自動化に移すのが現実的です。
展開前に必ず見るべきセキュリティポイント
WinGet Configurationは強力ですが、構成ファイルの中身を信頼できることが前提です。Microsoft Learnでは、実行前に各リソースを確認し、何がインストール・変更・適用されるかを把握するよう推奨しています。さらに、管理者シェルで実行した場合は管理者コンテキストの変更ごとに確認プロンプトが出ないこと、ユーザーコンテキストでも構成全体でUACプロンプトが1回だけになる場合があると説明されています。(Microsoft Learn)
とくに注意したいのはDSCリソースです。PowerShell DSCリソースは任意のコード実行を含み得るため、発行元、スクリプト内容、参照先を確認しなければなりません。PowerShell Galleryも多様な発行者のモジュールを含むため、組織内では「Microsoft公式だからすべて無条件に許可」ではなく、構成ごとにレビューする姿勢が必要です。(Microsoft Learn)
実務では、次のルールを決めておくと運用しやすくなります。
- 公式リポジトリの
mainを直接実行せず、検証済みのコミットや社内フォークを使う - 構成変更はPull Requestでレビューする
- 追加するパッケージID、ソース、DSCリソースを一覧化する
- 秘密情報、アクセストークン、個人設定は構成ファイルに入れない
- 端末のセキュリティベースラインと衝突するWindows設定は事前に除外する
- 検証結果、失敗ログ、既知の制限をオンボーディング手順に残す
既存の手順書やスクリプトから移行する考え方
Windows Developer Configurationsは、既存のオンボーディング手順を一気に捨てるものではありません。まずは手作業のうち、再現性が必要で差分が出やすい部分から構成ファイルに移すのが失敗しにくい進め方です。
移行しやすいもの
- Git、GitHub CLI、VS Codeなどの標準ツール
- PowerShell 7やWindows Terminalの基本構成
- Node.js、Python、.NET、Go、Javaなどの言語ツールチェーン
- WSLとUbuntuの初期構成
- ファイル拡張子表示、隠しファイル表示、Developer Modeなどの開発者向けWindows設定
移行に注意が必要なもの
- 社内証明書、VPN、EDR、DLPなどセキュリティ製品の構成
- 個人のSSH鍵、Git署名鍵、APIトークン
- ライセンス認証が必要な商用ツール
- プロジェクト固有のデータベース接続情報
- 管理者がIntuneやGPOで強制しているWindows設定
判断基準はシンプルです。チーム全員に必要で、バージョンや設定差分が不具合につながるものは構成化の候補です。個人ごとに異なる情報、監査や承認が必要なもの、セキュリティ境界に関わるものは別管理に分けます。
よくある失敗と対処
| 症状 | 原因の例 | 対処 |
|---|---|---|
winget configureが認識されない | Configuration機能が未有効、App Installerが古い、ポリシーで無効 | winget configure --enable、App Installer更新、管理ポリシー確認 |
| 内部エラーで失敗する | 非昇格環境でVisual C++ Redistributableが不足 | 公式READMEの案内に従い、対象アーキテクチャのVC++ Redistributableをインストール |
| WSLのセットアップで止まる | 仮想化が無効、VMでネストされた仮想化が未設定 | BIOS/UEFIまたはホスト側VM設定を確認 |
| 再起動後に進んでいないように見える | WSL有効化後のRunOnce再開待ち | サインイン後しばらく待ち、ログを確認 |
pythonやnodeが見つからない | PATHが現在のシェルに反映されていない | 新しいターミナルを開く、またはワークロード付属のinstall.ps1を使う |
| 社内ネットワークで失敗する | プロキシ、SSL検査、GitHubやPowerShell Galleryへの接続制限 | 事前に許可先、パッケージソース、プロキシ設定を整理 |
| 既存のWindows設定が変わった | Dev Configが開発者向けの既定設定を適用 | 変更される設定を事前レビューし、社内版では不要な項目を除外 |
公式READMEでも、VC++ Redistributable不足、WSLに必要な仮想化、PATH反映、RunOnceによる再開などのトラブルシューティングが整理されています。(GitHub)
管理者向けの展開チェックリスト
小規模チームなら個別実行でも始められますが、組織で使うなら展開設計が必要です。
| フェーズ | 確認すること |
|---|---|
| 検証前 | 対象OS、WinGetバージョン、ネットワーク制限、実行権限を確認 |
| 構成レビュー | インストールされるパッケージ、DSCリソース、Windows設定、再起動有無を確認 |
| セキュリティ確認 | 発行元、スクリプト内容、外部接続先、ログ取得方法を確認 |
| パイロット | 情シス管理端末ではなく、開発者に近い実機・VMで試す |
| 展開 | 対象グループ、実行タイミング、失敗時の戻し方を決める |
| 運用 | 構成変更をPRレビューし、変更履歴と既知の問題を残す |
展開単位は、最初から全社ではなく「特定プロジェクトの新規参加者」「Windows 11の新規開発PC」「検証用Cloud PC」などに絞るのがおすすめです。
開発チームでの実用的な使い分け
Windows Developer Configurationsだけで、すべての開発環境管理が解決するわけではありません。Dev Container、Docker、WSL、Intune、ゴールデンイメージとは役割が異なります。
| 選択肢 | 向いている用途 |
|---|---|
| Windows Developer Configurations | Windows開発PCの初期状態、共通ツール、OS設定の標準化 |
| Workloads | 言語別・プロジェクト別の軽量なツール導入 |
| WSL Comfort | WSLとターミナル体験の改善 |
| Dev Container | リポジトリ単位の実行環境や依存関係の隔離 |
| Intune/GPO | 組織ポリシー、セキュリティ設定、端末管理 |
| ゴールデンイメージ | OSやセキュリティ製品を含む大規模な初期配布 |
おすすめは、階層を分ける運用です。
まず、IntuneやGPOでセキュリティベースラインを管理します。次に、Windows Developer Configurationsで開発PCとしての共通ツールを入れます。最後に、プロジェクト固有の依存関係はDev ContainerやWorkloadsで分けます。
この分け方にすると、OS管理、開発者体験、プロジェクト依存関係が混ざりにくくなります。
導入すべきケース、まだ待つべきケース
Windows Developer Configurationsは、すべての組織が即導入すべきものではありません。導入判断は、オンボーディングの頻度と管理要件で考えると分かりやすくなります。
導入しやすいケース
- 新規メンバーの参加が多い
- Windows開発PCの構築手順が長く、担当者によって差が出る
- WSL、VS Code、Git、各言語環境を標準化したい
- 検証用Windows 11環境を頻繁に作り直す
- 開発者のセルフサービス環境構築を進めたい
- Windows 365の開発者向けCloud PCを検討している
慎重に進めるべきケース
- 端末の設定変更が厳しく制限されている
- WinGetやMicrosoft Storeが禁止されている
- PowerShellスクリプト実行が原則不可
- 開発環境が完全にクラウドIDEへ移行済み
- WSLや仮想化の利用が禁止されている
- 社内プロキシや証明書検査が強く、外部ソース取得に制限が多い
待つべきケースでも、検証自体は価値があります。実際に試すことで、どのポリシーが障害になるのか、どのツールなら構成化できるのかが明確になります。
まず取るべき行動
開発者なら、最初はWorkloadsかWSL Comfortから試すのが安全です。普段使いのPCではなく、Windows 11の検証用VMや予備端末で実行し、何が変わるかを確認してください。
管理者なら、次の順番で進めると失敗しにくくなります。
| 優先度 | やること |
|---|---|
| 高 | WinGet、Configuration、App Installer、CLI実行ポリシーの状態を確認 |
| 高 | 公式構成をそのまま実行せず、検証用環境で内容とログを確認 |
| 高 | WSL、再起動、仮想化、プロキシ、パッケージソースの制限を洗い出す |
| 中 | 社内で許可するパッケージと不要なWindows設定を整理 |
| 中 | GitHubリポジトリをフォークし、レビュー付きで社内版を管理 |
| 中 | 新規参加者向けの小さなパイロットから開始 |
| 低 | 全社展開やCloud PC展開は、ログ取得と失敗時対応が固まってから検討 |
Windows Developer Configurationsの価値は、単に「セットアップが速い」ことではありません。構成をファイルとしてレビューでき、再実行でき、チームで改善できる点にあります。
まずは現在のオンボーディング手順を棚卸しし、手作業で差分が出やすい項目から構成化してください。Windows開発環境を属人化させないことが、今回の変更を実務で活かす最も大きなポイントです。
コメント