PowerToysの便利な機能を紹介する記事は山ほどあります。困るのはその先で、情報システム部門が業務端末へ配る立場になったときです。誰が入れていいのか、どの機能を止めるのか、更新をどう抑えるのか。この記事では、winget でのサイレント配布、ADMXテンプレートの配置、Software\Policies\PowerToys に書くレジストリ値、IntuneのOMA-URIによる同等制御までを、公式ドキュメントの記載とコピーして動くコマンドで示します。
まとめ｜PowerToysを業務端末へ配布する前に決める4つの前提
先に結論から並べます。ひとつ目は制御の入口です。Group Policyの公式ドキュメントによれば、管理用テンプレート（ADMX）はバージョン0.64以降に同梱され、ユーティリティ全体をまとめて止めるポリシーは0.75.0以降でサポートされます。古い版が端末に残っていると、ポリシーを配っても効きません。配布とバージョン統制はセットで考えることになります。
ふたつ目はインストール経路です。インストール手順のページには、ユーザーごとのチャネルと全ユーザー向けのチャネルという2種類のインストーラーが説明されています。前者は %userprofile%\AppData\Local\Programs に入り、他のユーザーからは使えません。管理下に置きたいなら後者へ寄せ、前者をポリシーで禁止する流れになります。
3つ目は更新の分岐です。更新チャネルのページでは、StableとInsiderの2チャネルが用意され、Insiderは夜間のプレリリースビルドを受け取ると説明されています。実際にGitHubのリリース一覧を見ると、2026年9月上旬時点で安定版が v0.101.2362.0（2026年8月25日）、プレビューが v0.101.2453.0（2026年9月4日）と別々に並んでいました。業務端末で夜間ビルドを受け取らせる理由はありません。
4つ目は止める機能の選別です。PowerToysには端末間でクリップボードとファイルを共有する機能や、貼り付け内容をオンラインのAIモデルへ送る機能が含まれます。ここを開けたまま全社配布すると、資産管理の帳簿に載らない情報経路ができることが問題です。似た性格の開発者向けツール群についてはDevToysとは？開発者の万能ツールの機能・対応OS・インストール方法【Windows/Mac/Linux】でも扱いましたが、PowerToysは管理面のポリシーが揃っている点が違います。
PowerToysの構成と0.101系で分かれた更新チャネルの扱い
配布設計に入る前に、対象が何であるかを揃えておきます。PowerToysは単体アプリではなく、独立した多数のユーティリティを1つのインストーラーで束ねた集合体です。この構造が、後段のポリシー設計をやりやすくしています。
単体アプリではなくユーティリティ集合であることの実務的な意味
公式のポリシー一覧には、Advanced Paste、Always on Top、Awake、Color Picker、Command Palette、FancyZones、File Locksmith、Hosts ファイル エディター、Image Resizer、Keyboard Manager、Mouse Without Borders、New+、Peek、PowerRename、PowerToys Run、Registry Preview、Screen Ruler、Text Extractor、Workspaces、ZoomIt といったユーティリティが並び、それぞれに「有効状態を構成する」ポリシーが用意されています。
つまり導入判断は「PowerToysを入れるか入れないか」の二択ではありません。入れたうえで、有効にする機能を管理側が選ぶという設計が取れます。これは、機能単位の制御ができない一般的なフリーソフトとの決定的な違いです。
StableとInsiderの2チャネルと端末側で受け取るビルドの違い
更新チャネルのドキュメントは、Stableを既定かつ推奨とし、Insiderを「安定したリリースよりも検証が少なく、不安定になる可能性がある」ビルドと明記しています。加えて、Insiderから Stable へ戻してもダウングレードやアンインストールは行われず、入っているInsider版のほうが新しければ、次の安定版が出るまでその版に留まると説明されています。
ここが運用上の落とし穴です。ユーザーが一度Insiderへ切り替えると、管理側が後からStableへ戻しても端末の版はプレリリースのまま残ります。バージョンを揃えたいなら、切り替えを許す前にポリシーで塞ぐ順序が要ります。手元での版の確認は、GitHubのAPIを叩くのが早いです。
curl -s "https://api.github.com/repos/microsoft/PowerToys/releases?per_page=5" | ConvertFrom-Json |
Select-Object tag_name, published_at, prerelease実行すると、prerelease が False の行が安定版です。筆者が2026年9月上旬に実行したときは、prerelease=False の最新が v0.101.2362.0、その上に3本のプレビューが積まれていました。
wingetとMSI引数でPowerToysをサイレント配布する手順
配布の実装に入ります。キッティングのイメージ作成に含めるのか、配布済み端末へ後から流し込むのかで手順が変わりますが、コマンド自体は共通です。作業手順の全体設計はキッティングとは？PC設定の手順・手作業とクローニングの違いと外注判断【情シス向け】に整理してあります。
システム要件と全ユーザー向けインストーラーを選ぶ理由と判断基準
公式が示す最小要件は、Windows 11 または Windows 10 バージョン2004（20H1 / ビルド19041）以降、64ビットプロセッサ（x64 または ARM64）、そして Microsoft Edge WebView2 ランタイムです。WebView2はセットアップ中にブートストラップ経由で入るため、事前配布は必須ではありません。ただし外部通信を絞った環境では、ここで止まる可能性を見ておきます。
インストーラーの種類は前述の2系統です。全ユーザー向けを選ぶと %ProgramFiles% 配下へ入り、端末上の全アカウントで利用可能です。共用端末や、退職者アカウントの整理が発生する環境では、こちらに寄せたほうが後の棚卸しが楽になります。ARM64端末が混在するなら、配布パッケージもアーキテクチャ別に用意します。
winget installのコマンドとMSI引数によるログ出力の指定
公式ドキュメントが示すコマンドは次の1行です。そのうえで、インストーラー実行可能ファイルは Microsoft Standard Installer のコマンドラインオプションを受け付け、/quiet（サイレント）、/passive（進行状況バーのみ）、/log（ファイルへのログ記録）が使えると記載されています。
# 基本形（公式ドキュメント記載のコマンド）
winget install --id Microsoft.PowerToys --source winget
# 無人配布：同意を自動承認し、サイレント実行してログを残す
winget install --id Microsoft.PowerToys --source winget `
--accept-package-agreements --accept-source-agreements `
--override "/quiet /log C:\Windows\Temp\powertoys_install.log"
# 版を固定して配る（バージョンを揃えたいとき）
winget install --id Microsoft.PowerToys --source winget --version 0.101.2362.0--override を付けると、wingetが既定で渡す引数の代わりに、指定した文字列がそのままインストーラーへ渡ります。ログの出力先は端末側で書き込める場所を指定してください。配布スクリプトの戻り値だけでは、WebView2の取得に失敗したのか、既に同じ版が入っていたのかを区別できません。
配布後にバージョンとインストール経路を機械的に確認する具体的な手順
配布が終わったら、端末側で実際に入った版と経路を確かめます。ユーザーごとのインストールが過去に行われていると、全ユーザー向けと二重に存在する状態が起こり得ます。
# wingetから見た導入状況
winget list --id Microsoft.PowerToys
# アンインストール情報から版と導入先を取る（machine-wide側）
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" |
Where-Object { $_.DisplayName -like "PowerToys*" } |
Select-Object DisplayName, DisplayVersion, InstallLocation
# ユーザーごとの導入が残っていないかを確認する
Get-ItemProperty "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" |
Where-Object { $_.DisplayName -like "PowerToys*" } |
Select-Object DisplayName, DisplayVersion, InstallLocationHKCU側にヒットが出た端末は、ユーザーが自分で入れた個体です。全ユーザー向けを配る前に、そちらを先に消しておかないと、更新通知が二系統から飛ぶ状態になります。端末の導入経路そのものを統制する仕組みはWindows AutopilotとMicrosoft Entra ID（旧Azure AD）連携ガイド｜Entra参加の要件・設定手順【2026年版】で扱った初期展開の設計と接続します。
ADMXテンプレートを配置してグループポリシーを効かせる手順
配布できたら、次は制御です。PowerToysのポリシーは管理用テンプレートで提供され、入手先はGitHubのリリースページになります。ここを知らずに探し回る時間が、この作業で一番もったいない部分です。
GroupPolicyObjectsFilesの入手と単体端末への配置
公式ドキュメントによれば、管理用テンプレートは最新リリースの Assets セクションに GroupPolicyObjectsFiles-<Version>.zip という名前で置かれています。展開して出てくる PowerToys.admx と PowerToys.adml を、ポリシー定義フォルダーへ配置します。
# 単体端末へ配置（例: C:\Windows\PolicyDefinitions）
Copy-Item .\PowerToys.admx "$env:SystemRoot\PolicyDefinitions\" -Force
Copy-Item .\PowerToys.adml "$env:SystemRoot\PolicyDefinitions\en-US\" -Force
# 配置後にローカルグループポリシーエディターで確認
gpedit.mscadml は言語フォルダーに入れる点を外すと、エディターにカテゴリが出るのに設定名が空になります。日本語環境でも、配布物に含まれるのが en-US の adml であれば en-US フォルダーへ置きます。存在しない言語フォルダーは作成して構いません。
セントラルストアへの配置とコンピューター構成が優先される規則
ドメイン環境では、各端末へ配るのではなくセントラルストアへ置きます。公式の手順は、ドメインコントローラーの %systemroot%\sysvol\domain\policies\PolicyDefinitions に admx を、その配下の言語フォルダーに adml をコピーするというものです。複数のドメインコントローラーがある場合、次のレプリケーション間隔でファイルが複製されます。
設定の在り処は、コンピューターの構成とユーザーの構成の両方にある「管理用テンプレート / Microsoft PowerToys」です。ここで押さえるべきは優先順位で、公式は「両方の設定が構成されている場合、コンピューターの構成での設定がユーザーの構成での設定より優先されます」と明記しています。部署ごとの例外をユーザー側で作っても、端末側で同じ項目を構成していれば通りません。例外運用を設計するなら、コンピューター側は未構成のまま残す判断が要ります。
もうひとつ、個別ユーティリティのポリシーは全体ポリシーより強く働きます。「ユーティリティのグローバルな有効化状態を構成する」で全体を無効にしつつ、業務で使う数個だけを個別ポリシーで有効に戻せる構成です。この順序を逆に理解していると、意図と反対の結果になります。
レジストリとIntuneで個別ユーティリティを止める設定の実物
GPOを配れない環境、あるいは配布スクリプトで完結させたい場合は、レジストリへ直接書く経路があります。公式ドキュメントは各ポリシーについてレジストリのパスと値名を公開しているため、ADMXを配置しなくても同じ状態を作れます。
Software\Policies\PowerToysに書くDWORDの実値
ポリシーの格納先は Software\Policies\PowerToys です。全ユーザー向けに効かせるなら HKLM 配下へ書きます。以下は、業務端末で先に閉じておく価値が高い項目をまとめたものです。
$key = "HKLM:\Software\Policies\PowerToys"
New-Item -Path $key -Force | Out-Null
# 端末間のファイル転送とクリップボード共有を止める
New-ItemProperty -Path $key -Name "MwbFileTransferEnabled" -PropertyType DWord -Value 0 -Force | Out-Null
New-ItemProperty -Path $key -Name "MwbClipboardSharingEnabled" -PropertyType DWord -Value 0 -Force | Out-Null
New-ItemProperty -Path $key -Name "MwbSameSubnetOnly" -PropertyType DWord -Value 1 -Force | Out-Null
# 貼り付け内容をオンラインAIモデルへ送る経路を閉じる
New-ItemProperty -Path $key -Name "AllowPowerToysAdvancedPasteOnlineAIModels" -PropertyType DWord -Value 0 -Force | Out-Null
# ユーザーごとのインストールと、プレビュービルドへの移行を禁止する
New-ItemProperty -Path $key -Name "DisablePerUserInstallation" -PropertyType DWord -Value 1 -Force | Out-Null
New-ItemProperty -Path $key -Name "PreviewUpdatesDisabled" -PropertyType DWord -Value 1 -Force | Out-Nullここで一点、ドキュメントを読み飛ばすと確実に踏む差異があります。プレビュービルドを禁止するポリシーのGP一意名は DisablePreviewUpdates ですが、レジストリの値名は PreviewUpdatesDisabled です。名前が入れ替わっているため、GP名をそのまま値名に使うと設定が無視されます。このポリシー自体は0.100.0以降でサポートされる点も、古い版が残る端末では効いてきます。
IntuneのOMA-URIで同じ制御を配布する具体的な構成手順
Intune管理下の端末なら、ADMXを取り込むか、カスタムプロファイルのOMA-URIで同じ項目を配れます。テンプレートの取り込み自体はIntuneへのカスタム管理用テンプレートのインポート手順に従ってください。OMA-URIで直接指定する場合の書式は、公式が項目ごとに示しています。
# 例1: Mouse Without Borders のファイル転送を無効化
/Device/Vendor/MSFT/Policy/Config/PowerToys~Policy~PowerToys~MouseWithoutBorders/MwbFileTransferEnabled
値（文字列）: <disabled/>
# 例2: プレビュービルドの更新を無効化
/Device/Vendor/MSFT/Policy/Config/PowerToys~Policy~PowerToys~InstallerUpdates/DisablePreviewUpdates
値（文字列）: <enabled/>
# 例3: すべてのユーティリティを既定で無効にする
/Device/Vendor/MSFT/Policy/Config/PowerToys~Policy~PowerToys/ConfigureAllUtilityGlobalEnabledState
値（文字列）: <disabled/>OMA-URIのパスは先頭にドットが付く形式（./Device/...）で公式に記載されています。ノードの区切りに含まれる ~ はカテゴリの階層を表し、MouseWithoutBorders・InstallerUpdates・AdvancedPaste・PowerToysRun・FileExplorerPreview・NewPlus・GeneralSettings が用意されています。端末管理基盤そのものの選定はMDMとは？モバイルデバイス管理の仕組みとEMM/UEMの違い・選び方【情シス向け】で整理しました。
PowerToys Runのプラグインを個別に止める設定と適用確認
ランチャー機能であるPowerToys Runは、プラグイン単位でも制御できます。値名にはプラグインフォルダーの plugin.json に書かれたプラグインIDを使い、0が無効、1が有効、2がユーザーに委ねる、という3値を取ります。
# プラグイン個別制御（公式ドキュメント記載の例）
# パス: Software\Policies\PowerToys\PowerLauncherIndividualPluginEnabledList
# 0778F0C264114FEC8A3DF59447CF0A74 = 2 → OneNote プラグインはユーザー判断
# 791FC278BA414111B8D1886DFE447410 = 0 → Program プラグインを強制無効
# CEA0FDFC6D3B4085823D60DC76F28855 = 1 → Calculator プラグインを強制有効
# 適用後の確認
gpupdate /target:computer /force
Get-ItemProperty -Path "HKLM:\Software\Policies\PowerToys" | Format-List設定変更を反映するにはPowerToys Runの再起動が要る、と公式に注記されています。ポリシーを配った直後に効果を確認しようとして「効いていない」と判断するのは早計です。レジストリに値が入っていることを上のコマンドで確かめてから、プロセスを再起動して見てください。
情報システム部門が止める機能と全社へ残す機能を分ける判断基準
ここからは判断の話です。ポリシーが用意されている以上、全部を止めるか全部を開けるかの二択にする理由はありません。情報の出口になる機能だけを閉じ、作業時間に効く機能は開ける、という線引きが現実的です。
先に閉じる：端末間でファイルとクリップボードを渡す経路の管理方針
迷わず閉じてよいのは Mouse Without Borders のファイル転送とクリップボード共有です。この機能は複数台のWindows端末を1組のキーボードとマウスで操作し、あいだでファイルとクリップボードを受け渡します。便利であることと、資産管理の外側に情報経路ができることは別の問題です。
公式にはファイル共有がクリップボード共有に依存すると書かれており、クリップボード共有を無効にするとファイル共有も自動的に無効になります。両方を明示的に0にしておくほうが、監査時の説明は簡潔です。加えて MwbSameSubnetOnly を1にすると、同一サブネット内の接続だけに制限できます。検証環境で機能自体を使う場合は、この3項目の組み合わせで範囲を絞ってください。
条件付きで閉じる：貼り付け内容を外部へ送るAI連携の判断基準
Advanced Paste のオンラインAIモデルは、クリップボードの内容をプロンプトとして外部サービスへ送る機能です。ポリシーを無効にすると、ユーザーはAI貼り付けを有効にできず、PowerToys設定でOpenAIキーを設定することもできなくなります（0.81.1以降でサポート）。
判断の分岐は、社内に生成AI利用のガイドラインがあるかどうかです。承認済みのAIサービスと利用範囲が定義されているなら、この機能を一律で禁止する必然性は薄れます。定義がない状態で開けると、どのデータがどこへ渡ったかを後から追えません。ガイドライン整備が済むまでは0で閉じ、整備後に見直す。その順序を推奨します。なお設定の変更にはAdvanced Pasteの再起動が必要と注記されています。
残して効果が出る機能と、全社配布後の運用を回すための管理体制
残す価値が高いのは、作業時間に直接効く3つです。PowerToys Run（ランチャー）、FancyZones（ウィンドウ配置）、PowerRename（一括リネーム）は、いずれも外部へ情報を送らず、端末内で完結します。File Locksmith や Image Resizer も同じ性格で、閉じる理由が見当たりません。
一方で、残すと決めた以上は版の統制と問い合わせ対応が発生します。四半期ごとに安定版へ揃える、プレビューチャネルは塞ぐ、ポリシーの適用結果を資産管理台帳と突き合わせる。この程度の運用でも、端末台数が増えると片手間では回りません。導入後の運用設計や内製化の進め方まで含めて相談したい場合は、保守運用 / 内製化支援で対応しています。台帳側の整備はIT資産管理とは？目的・ツール機能と選び方・運用判断を解説も参考にしてください。
PowerToysの配布後につまずく箇所と切り分けの実行手順
最後に、実際の配布で報告が上がりやすい3つの症状と、その切り分けをまとめます。いずれも仕様として説明が付くもので、原因を知っていれば数分で片が付きます。
ポリシーを配ったのに設定が変わらないときに見る3点と確認手順
まず確認するのは版です。ポリシーにはそれぞれサポート開始バージョンがあり、グローバルな有効化状態は0.75.0以降、プレビュービルドの無効化は0.100.0以降、Mouse Without Borders 系は0.83.0以降が条件です。端末に古い版が残っていれば、ポリシーは単に無視されます。
次にレジストリの値名です。前述の PreviewUpdatesDisabled のように、GP一意名と値名が一致しない項目があります。3つ目の確認対象は優先順位で、コンピューター構成とユーザー構成の両方を触っていないかどうかです。この3点で大半は説明が付きます。
管理者権限で動くアプリの上でユーティリティが効かない場合の対処方法
管理者として実行しているアプリケーションの上では、通常起動のPowerToysは反応しません。Windowsの権限分離による挙動で、不具合ではありません。開発者が管理者権限のターミナルやIDEを常用している端末では、この報告が必ず上がります。
回避策はPowerToysを管理者モードで動かすことですが、全社に配る設定としては勧めません。常時昇格した状態のユーティリティが常駐することになり、端末の権限設計と噛み合わないためです。該当者を絞り、必要な端末だけ個別に判断するほうが筋が通ります。
よくある質問
PowerToysは企業で使っても問題ないライセンスですか？
PowerToysはMicrosoftがGitHub上でオープンソースとして公開しているツール群で、リポジトリはMITライセンスで提供されています。企業内で利用する際に追加のライセンス費用は発生しません。ただし社内の審査では、ライセンス条件よりも「どの機能を有効にするか」が論点になります。ADMXでの機能制御が可能である点を、審査資料に含めておくと話が早く進みます。
ユーザーが勝手にインストールするのを止められますか？
停止経路は2つです。ひとつは「ユーザーごとのインストールを無効にする」ポリシー（DisablePerUserInstallation・0.68.0以降）で、これはコンピューターポリシーとしてのみ設定できます。もうひとつは「ユーティリティのグローバルな有効化状態を構成する」を無効にする方法で、公式には、この設定を無効にするとすべてのユーティリティが常に無効になり、ユーザーは有効にできなくなると記載されています。
Microsoft StoreとwingetとGitHubのどれで配るべきですか？
公式はMicrosoft Store経由を推奨していますが、これは個人利用を前提とした案内です。企業配布では、版を固定でき、ログを取れ、サイレント実行できる winget か、GitHubから取得したインストーラーをMSI引数付きで実行する経路を選びます。Storeアプリの配布を統制できる基盤が既にあるなら、Storeでも構いません。判断軸は、版を管理側で決められるかどうかです。
更新をこちらのタイミングで止めることはできますか？
自動ダウンロードとインストールを止めるポリシー（DisableAutomaticUpdateDownload）が0.68.0以降で用意されています。あわせて、新しい更新のアクションセンター通知を無効にする設定（DisableNewUpdateToast・0.78.0以降）と、更新後にリリースノートを表示しない設定（DoNotShowWhatsNewAfterUpdates・同0.78.0以降）を組み合わせると、業務中にポップアップが出る状況を抑えられます。
ARM64のWindows端末でも同じ手順で配布できますか？
システム要件にはx64とARM64の両方が挙がっており、インストーラーも PowerToysSetup-0.##.#-arm64.exe が用意されています。winget install は端末のアーキテクチャに合わせて取得するため、コマンド自体は共通で問題ありません。インストーラーのファイルを直接配布する運用にしている場合だけ、アーキテクチャ別の振り分けが必要になります。
関連記事
- DevToysとは？開発者の万能ツールの機能・対応OS・インストール方法【Windows/Mac/Linux】：同じ開発者向けユーティリティ集の比較対象です。
- Windows AutopilotとMicrosoft Entra ID（旧Azure AD）連携ガイド｜Entra参加の要件・設定手順【2026年版】：端末の初期展開と参加設計を扱います。
- キッティングとは？PC設定の手順・手作業とクローニングの違いと外注判断【情シス向け】：配布作業そのものの設計に対応します。
- MDMとは？モバイルデバイス管理の仕組みとEMM/UEMの違い・選び方【情シス向け】：Intuneを含む端末管理基盤の選定に関わります。
- IT資産管理とは？目的・ツール機能と選び方・運用判断を解説：配布後の台帳整備と棚卸しの前提です。
