Win32_PageFileSetting が空になる原因と対処法｜ページファイル自動管理と PowerShell での確認手順

PowerShell や WMI でページファイルを調べようとしたとき、「Win32_PageFileSetting をクエリしてもインスタンスが 0 件」「No instance(s) available」となり、環境によっては取得できる──この現象に戸惑う管理者は少なくありません。本記事では、その原因と仕様、PowerShell での確認方法、監視・運用のベストプラクティスまでをまとめて解説します。

Win32_PageFileSetting をクエリしても空になる症状とは

まず、現場で実際に遭遇する症状を整理します。次のような PowerShell コマンドを実行しても、結果が空になるケースです。

# PowerShell（CIM）でページファイルの設定を取得
Get-CimInstance Win32_PageFileSetting

# もしくは古い書き方（非推奨）
Get-WmiObject Win32_PageFileSetting

このとき、出力は次のようになります。

PS C:\&gt; Get-CimInstance Win32_PageFileSetting
# 何も表示されない（空）

PS C:\&gt; (Get-CimInstance Win32_PageFileSetting).Count
0

WMI クエリ（WQL）や WMIC でも同様です。

# WQL
Get-CimInstance -Query "SELECT * FROM Win32_PageFileSetting"

# WMIC（非推奨）
wmic pagefileset list /format:list
:: No Instance(s) Available.

ところが、別のサーバーや別の PC では同じコマンドで値が取れることがあります。そのため、

「OS のバージョン違い（Windows 10 / 11 / Server 2019 など）の問題？」
「PowerShell のバージョンによる不具合？」
「セキュリティパッチで仕様が変わったのでは？」

と疑われがちですが、これらは本質的な原因ではありません。

結論：原因は「ページングファイルの自動管理」がオン

この現象の正体はとてもシンプルで、OS の設定に依存しています。

ページングファイルの自動管理がオンになっていると、Win32_PageFileSetting にはインスタンスが一切作成されません。

逆に言うと、Win32_PageFileSetting から値が取得できる環境は、ほぼ確実に「自動管理がオフ（手動で初期サイズ・最大サイズを設定している）」状態です。

まとめると、次のようになります。

ページファイル設定	AutomaticManagedPagefile	Win32_PageFileSetting の結果	Win32_PageFileUsage の結果
自動管理（推奨設定）	true	0 件（インスタンスなし）	使用中のページファイル情報が取得できる
手動設定（固定サイズ／上限指定）	false	1 件以上のインスタンスが返る	使用中のページファイル情報が取得できる

この挙動は不具合ではなく、WMI クラスの設計上の仕様です。

Win32_PageFileSetting は「設定」、Win32_PageFileUsage は「実態」

ページファイル関連の WMI クラスは複数あり、役割が紛らわしいため整理しておきます。

クラス名	種類	主な役割	自動管理時の挙動
`Win32_PageFileSetting`	設定情報	手動で設定したページファイルの初期サイズ／最大サイズなどの構成値を保持	自動管理時はインスタンスなし（空）
`Win32_PageFileUsage`	使用状況	実際に稼働しているページファイルの割り当てサイズや使用量（CurrentUsage, PeakUsage）を返す	自動管理でも常に使用状況が取得できる
`Win32_PageFile`	ファイル情報	ページファイル自体のパスやサイズなどの情報を返す（実体に近い）	環境によっては情報が取れるが、監視にはやや扱いづらい

ポイントは、Win32_PageFileSetting は「構成クラス」なので、OS が自動で決めている部分は保存されないという点です。一方、Win32_PageFileUsage や Win32_PageFile は「現状どうなっているか」を返すクラスなので、自動管理かどうかに関わらず情報が取得できます。

なぜ自動管理だと Win32_PageFileSetting が空になるのか

もう少し仕組み寄りの話をしておきます。

Win32_PageFileSetting は「固定の設定」を WMI のリポジトリに持つためのクラス
自動管理にすると、OS がメモリ・ディスク空き・クラッシュダンプの要件などから動的にサイズを決定
その結果、「ユーザーが明示的に設定したサイズ」が存在しない状態になる

このとき、WMI の概念としては

構成情報が存在しないのだから、クラスのインスタンスも存在しない

という扱いになります。よって、クエリ結果が 0 件になるのは仕様通りです。

別の言い方をすると、

自動管理 = 「OS がよしなに決めるので、固定設定は空」
手動設定 = 「ユーザーが指定した固定値があるので、WMI にも構成値が残る」

という動作です。

PowerShell での確認手順（自動管理かどうかを判定）

ここからは実践編です。まずは、問題の原因である「ページングファイルの自動管理」がオンかどうかを PowerShell で確認します。

自動管理の有無を確認する

# 1) 自動管理の有無を確認
Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, AutomaticManagedPagefile

出力例：

Name   AutomaticManagedPagefile
----   ------------------------
SRV01  True

True … ページングファイルの自動管理が有効
False … 手動設定（自動管理が無効）

Win32_PageFileSetting の結果を確認する

# 2) Win32_PageFileSetting を確認
Get-CimInstance Win32_PageFileSetting |
  Select-Object Name, InitialSize, MaximumSize

自動管理が有効な環境では何も返ってきません。一方、手動設定している環境では例えば次のように表示されます。

Name           InitialSize MaximumSize
----           ----------- -----------
C:\pagefile.sys       1024        4096

「設定」ではなく「実態／使用量」を確認する

ページファイルの監視やトラブルシュートでは、多くの場合「設定値」よりも「実際にどれだけ使われているか」が重要です。そのときに使えるのが Win32_PageFileUsage です。

# 3) Win32_PageFileUsage で実態を確認
Get-CimInstance Win32_PageFileUsage |
  Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage

出力例：

Name           AllocatedBaseSize CurrentUsage PeakUsage
----           ----------------- ------------ ---------
C:\pagefile.sys             2432          120       512

AllocatedBaseSize … 現在割り当てられているページファイルのサイズ（MB）
CurrentUsage … 現在使用中のサイズ（MB）
PeakUsage … 起動後のピーク使用量（MB）

このクラスは自動管理でも利用可能なので、運用監視ではこちらを使うのが望ましいです。

自動管理のまま必要情報を取得する（推奨パターン）

多くの環境では、Microsoft の推奨どおり「ページングファイルの自動管理」を有効のままにしておくほうが安全です。よって、

自動管理のままで
必要な情報（使用量、ピーク、ディスク空きなど）を監視する

という方針がおすすめです。

シンプルな監視スクリプト例

単純に現在値とピーク値を表示するだけなら次のようになります。

$usage = Get-CimInstance Win32_PageFileUsage

$usage | Select-Object Name,
  AllocatedBaseSize,
  CurrentUsage,
  PeakUsage

これを複数台に対して実行して CSV に吐き出せば、簡易的なレポートを作ることができます。

$servers = @("SRV01","SRV02","SRV03")

$result = foreach ($s in $servers) {
  $u = Get-CimInstance Win32_PageFileUsage -ComputerName $s -ErrorAction SilentlyContinue
  if ($null -ne $u) {
    [PSCustomObject]@{
      ComputerName      = $s
      Name              = $u.Name
      AllocatedBaseSize = $u.AllocatedBaseSize
      CurrentUsage      = $u.CurrentUsage
      PeakUsage         = $u.PeakUsage
    }
  }
}

$result | Export-Csv -Path ".\PageFileUsage.csv" -NoTypeInformation -Encoding UTF8

これだけでも、

どのサーバーでページファイルの使用率が高いか
ピーク使用量が物理メモリに対して十分か

などを把握できます。

物理メモリと組み合わせて見る

ページファイルのサイズや使用率を見るときは、物理メモリとの関係も重要です。例えば、次のように物理メモリと一緒に集計することもできます。

$cs   = Get-CimInstance Win32_ComputerSystem
$mem  = [math]::Round($cs.TotalPhysicalMemory / 1MB)

$pf   = Get-CimInstance Win32_PageFileUsage

[PSCustomObject]@{
  ComputerName      = $cs.Name
  TotalMemoryMB     = $mem
  PageFileAllocated = $pf.AllocatedBaseSize
  PageFileCurrent   = $pf.CurrentUsage
  PageFilePeak      = $pf.PeakUsage
}

こうした情報から、

物理メモリが十分なのにページファイルのピークが高い → メモリリークなどの疑い
物理メモリに対してページファイルが極端に小さい → クラッシュダンプ取得に問題が出る可能性

といった分析も行えます。

Win32_PageFileSetting から構成情報を取得したい場合の手順

とはいえ、監査や構成管理の都合で「固定サイズを WMI 経由で取得したい」という要件もあります。その場合は、自動管理をオフにして手動設定に切り替える必要があります。

この操作はシステム設定に影響するため、必ず 計画メンテナンスの時間帯に、管理者権限で実行してください。また、変更内容によっては再起動が求められることがあります。

自動管理をオフにする（PowerShell）

# 自動管理をオフにする
Set-CimInstance -Query "SELECT * FROM Win32_ComputerSystem" `
  -Property @{ AutomaticManagedPagefile = $false }

# 反映されたか確認
Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, AutomaticManagedPagefile

手動のページファイルを作成する

例えば、C ドライブに 1 GB ～ 4 GB のページファイルを作成したい場合は次のようになります。

Invoke-CimMethod -ClassName Win32_PageFileSetting -MethodName Create `
  -Arguments @{
    Name        = "C:\pagefile.sys"
    InitialSize = 1024   # MB
    MaximumSize = 4096   # MB
  }

その後、構成情報が Win32_PageFileSetting に作成されたか確認します。

Get-CimInstance Win32_PageFileSetting |
  Select-Object Name, InitialSize, MaximumSize

期待される出力例：

Name           InitialSize MaximumSize
----           ----------- -----------
C:\pagefile.sys       1024        4096

注意事項：

手動でサイズを小さくしすぎると、メモリ不足時に OS が不安定になったり、完全メモリダンプが取得できなくなったりします。
ディスクの空き容量を事前に確認したうえでサイズを決めてください。
変更後は再起動を求められることが多いため、本番サーバーでは必ず事前の告知と検証を行ってください。
wmic や Get-WmiObject は将来的に廃止方向なので、CIM 系コマンドレット（Get-CimInstance / Set-CimInstance など）の利用を推奨します。

ワンライナーで「自動／手動」を判定しつつ適切な情報を取得する

「自動管理なら使用量」「手動設定なら構成値」を一発で確認したい場合は、次のようなワンライナーが便利です。

$cs = Get-CimInstance Win32_ComputerSystem
if ($cs.AutomaticManagedPagefile) {
  Write-Host "自動管理のため、Win32_PageFileSetting は空です。実使用量を表示します。"
  Get-CimInstance Win32_PageFileUsage |
    Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage
} else {
  Write-Host "手動設定のため、構成値を表示します。"
  Get-CimInstance Win32_PageFileSetting |
    Select-Object Name, InitialSize, MaximumSize
}

このスクリプトをプロファイルに仕込んだり、ショートカット化しておくと、

「値が取れないのは異常なのか仕様なのか？」
「いま見るべきは設定値なのか、使用量なのか？」

が一目で判断できるようになります。

監視・運用の考え方：何をどの順番で見るべきか

ページファイルに関する監視やトラブルシューティングでは、闇雲に設定値だけを見ても全体像は掴めません。次のような順番でチェックすると、実態を効率よく把握できます。

ステップ	観点	確認方法	ポイント
1	自動管理の有無	`Win32_ComputerSystem.AutomaticManagedPagefile`	自動管理か手動設定かで「読むべきクラス」が変わる
2	使用量・ピーク	`Win32_PageFileUsage`	CurrentUsage / PeakUsage を定期的に記録し、傾向を把握
3	ディスク空き容量	`Win32_LogicalDisk` など	ページファイル拡張余地やクラッシュダンプの格納スペースを確保
4	物理メモリとのバランス	`Win32_ComputerSystem.TotalPhysicalMemory`	メモリ増設やアプリケーションのチューニングも検討

しきい値の考え方（例）

しきい値の設定は環境に依存しますが、例として次のようなイメージで考えると分かりやすくなります。

項目	目安のしきい値例	アラート内容
ページファイル使用率	AllocatedBaseSize の 80% 超	メモリ不足が頻発していないか確認、アプリのメモリ使用状況を調査
ページファイルピーク使用率	80% 超が継続	慢性的なメモリ不足の可能性。物理メモリ増設やアプリ配置の見直しを検討
ページファイル配置ディスクの空き容量	10%以上を維持	クラッシュダンプやログが出力できるだけの空き容量を確保

実際の監視ツールでは、上記に加えて以下のような情報も組み合わせるとより精度が上がります。

メモリ使用率（パフォーマンスカウンター）
プロセス単位のメモリ使用量（Get-Process 等）
ディスク I/O レイテンシ

よくある勘違い・ハマりどころ

最後に、Win32_PageFileSetting 周りでよくある勘違いや落とし穴をまとめておきます。

「Win32_PageFileSetting が空 = ページファイルがない」と誤解してしまう

実際には、自動管理の環境ではページファイルは普通に存在しており、Win32_PageFileUsage から使用情報も取得できます。Win32_PageFileSetting が空なのは「設定が自動だから、固定の構成値がない」だけです。

OS のバージョン差だと思い込んでしまう

「Windows Server 2012 では取れたのに、Windows Server 2019 では取れない」といったケースでは、OS バージョンよりもページファイルの設定モード（自動／手動）が違っているだけであることがほとんどです。

WMIC のエラー表示だけを見て不具合と判断してしまう

wmic pagefileset list のようなコマンドで “No Instance(s) Available.” と表示されると、あたかもエラーのように見えますが、これは「インスタンスが存在しない（= 自動管理で構成情報がない）」というだけです。

監視で「設定値」だけを集めてしまう

構成管理の観点から設定値を集めることは意味がありますが、性能・安定性の観点では実際の使用量を監視することが重要です。自動管理のまま、Win32_PageFileUsage を用いた監視に切り替えるほうが、現代的な運用にマッチします。

まとめ：Win32_PageFileSetting が空でも慌てない

本記事のポイントを整理します。

Win32_PageFileSetting が空になる最大の理由は「ページングファイルの自動管理」がオンだからであり、不具合ではありません。
Win32_PageFileSetting は「手動で設定した固定値」を表す構成クラスなので、自動管理時はインスタンスそのものが作成されません。
ページファイルの使用量やピークを知りたい場合は、Win32_PageFileUsage を使うのが正しいアプローチです。
自動管理のまま運用する場合は、「設定値」ではなく「実態（CurrentUsage, PeakUsage）＋ディスク空き＋物理メモリ」を組み合わせて監視するのがおすすめです。
どうしても構成値を WMI から取得したいときは、自動管理をオフにして手動設定に切り替え、Win32_PageFileSetting のインスタンスを作成します（ただし、本番環境では十分な検証と計画を必須とすること）。
トラブルシュート時は、まず AutomaticManagedPagefile の値を確認し、「なぜ空なのか」を仕様レベルで理解しておくと、原因切り分けがスムーズになります。

Win32_PageFileSetting を「取れるはずの情報が取れない問題」として捉えるのではなく、「設定モードによって見える情報が変わるだけ」と理解しておくと、PowerShell や WMI を利用した運用・監視の設計がぐっとやりやすくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Win32_PageFileSetting が空になる原因と対処法｜ページファイル自動管理と PowerShell での確認手順

Win32_PageFileSetting をクエリしても空になる症状とは

結論：原因は「ページングファイルの自動管理」がオン

Win32_PageFileSetting は「設定」、Win32_PageFileUsage は「実態」

なぜ自動管理だと Win32_PageFileSetting が空になるのか

PowerShell での確認手順（自動管理かどうかを判定）

自動管理の有無を確認する

Win32_PageFileSetting の結果を確認する

「設定」ではなく「実態／使用量」を確認する

自動管理のまま必要情報を取得する（推奨パターン）

シンプルな監視スクリプト例

物理メモリと組み合わせて見る

Win32_PageFileSetting から構成情報を取得したい場合の手順

自動管理をオフにする（PowerShell）

手動のページファイルを作成する

ワンライナーで「自動／手動」を判定しつつ適切な情報を取得する

監視・運用の考え方：何をどの順番で見るべきか

しきい値の考え方（例）

よくある勘違い・ハマりどころ

「Win32_PageFileSetting が空 = ページファイルがない」と誤解してしまう

OS のバージョン差だと思い込んでしまう

WMIC のエラー表示だけを見て不具合と判断してしまう

監視で「設定値」だけを集めてしまう

まとめ：Win32_PageFileSetting が空でも慌てない

この記事を書いた人

コメント

コメントするコメントをキャンセル

Win32_PageFileSetting が空になる原因と対処法｜ページファイル自動管理と PowerShell での確認手順

Win32_PageFileSetting をクエリしても空になる症状とは

結論：原因は「ページング ファイルの自動管理」がオン

Win32_PageFileSetting は「設定」、Win32_PageFileUsage は「実態」

なぜ自動管理だと Win32_PageFileSetting が空になるのか

PowerShell での確認手順（自動管理かどうかを判定）

自動管理の有無を確認する

Win32_PageFileSetting の結果を確認する

「設定」ではなく「実態／使用量」を確認する

自動管理のまま必要情報を取得する（推奨パターン）

シンプルな監視スクリプト例

物理メモリと組み合わせて見る

Win32_PageFileSetting から構成情報を取得したい場合の手順

自動管理をオフにする（PowerShell）

手動のページファイルを作成する

ワンライナーで「自動／手動」を判定しつつ適切な情報を取得する

監視・運用の考え方：何をどの順番で見るべきか

しきい値の考え方（例）

よくある勘違い・ハマりどころ

「Win32_PageFileSetting が空 = ページファイルがない」と誤解してしまう

OS のバージョン差だと思い込んでしまう

WMIC のエラー表示だけを見て不具合と判断してしまう

監視で「設定値」だけを集めてしまう

まとめ：Win32_PageFileSetting が空でも慌てない

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

結論：原因は「ページングファイルの自動管理」がオン

コメントするコメントをキャンセル