Windows 11を使っていて、PCの時刻が実際の時刻から約1分ずれていることに気づきました。

普段使いであれば1分程度のズレは大きな問題にならないこともありますが、開発環境では話が変わります。

API認証、JWT、OAuth、ログ、Git、クラウドサービスなどでは時刻を利用することがあるため、PCの時計が大きくずれている状態はできれば避けたいところです。特に最近は、Shopifyアプリの開発も行っており、時間のずれがあるとエラーになってしまうので、この点は致命的です。

今回、Windows 11の「今すぐ同期」を押しても永遠にローディングしたままになる問題が発生したため、w32tm コマンドを使って原因を調査しました。

最終的には、

• Windows側の時刻同期サービスに問題があった
• 一度Windows Timeサービスが無効になっていた
• NTPサーバーへの通信にも不安定な挙動があった
• スマートフォンのテザリングでは正常に同期できた
• マンション備え付けWi-Fiでは同期できたりできなかったりする
• w32tm /stripchart を使うと現在の時刻差を確認できる

というところまで切り分けることができました。

今回は備忘録として、実際に行った確認方法と、Windowsの時刻同期関連コマンドの使い方をまとめます。

今回発生した症状

最初に気づいたのは、Windows 11の時刻が実際より約1分ずれていたことでした。

Windows 11では、

設定 → 時刻と言語 → 日付と時刻

から「今すぐ同期」を押すことができます。

しかし、今回の環境ではボタンをクリックしても処理が終わらず、ずっとローディングしたままになりました。

PCの再起動を行っても改善しませんでした。

そこで、設定画面ではなくWindows標準の時刻同期ツールである w32tm を使って状態を確認することにしました。

w32tmとは？

w32tm はWindowsに標準搭載されている、Windows Timeサービスを確認・設定するためのコマンドです。

Windowsの時刻同期では、主に次の仕組みが使われています。

Windows
  ↓
Windows Timeサービス（W32Time）
  ↓
NTPサーバー
  ↓
正確な時刻を取得

Windows 11の設定画面にある「今すぐ同期」も、最終的にはこのWindows Timeサービスを利用しています。

そのため、設定画面で同期できない場合は w32tm を使うことで、より詳しい状態を確認できます。

コマンドプロンプトは管理者として起動する

今回使用するコマンドの多くは管理者権限が必要です。

スタートメニューで、

cmd

と検索し、

コマンド プロンプト → 管理者として実行

を選択します。

Windows Terminalを使っても問題ありません。

まず現在の同期状態を確認する

最初に実行したのがこちらです。

w32tm /query /status

これはWindows Timeサービスの現在の同期状態を確認するコマンドです。

今回、最初は次のようになっていました。

閏インジケーター: 3 (同期未実行)
階層: 0 (未指定)
最終正常同期時刻: 未指定
ソース: Local CMOS Clock

特に重要なのが、

ソース: Local CMOS Clock

です。

これはインターネット上のNTPサーバーではなく、PC本体の内部時計を使用している状態です。

また、

閏インジケーター: 3 (同期未実行)

となっているため、正常にNTP同期されていないことが分かります。

現在使用している時刻ソースを確認する

より簡単に同期元だけ確認する場合は、

w32tm /query /source

を使います。

正常にNTP同期されていない場合は、

Local CMOS Clock

と表示されることがあります。

正常な場合は、

time.windows.com,0x9

や、

ntp.nict.jp,0x9

などが表示されます。

現在どこから時刻を取得しているのかを確認したい場合に便利です。

Windows Timeサービスを再起動する

Windowsの時刻同期は、

Windows Time

というサービスによって動作しています。

サービスを再起動する場合は、

net stop w32time

で停止し、

net start w32time

で開始します。

まとめて実行する場合は、

net stop w32time
net start w32time

です。

その後、

w32tm /resync /rediscover

を実行します。

時刻を強制的に再同期する

手動で同期を実行したい場合は、

w32tm /resync /force

を使います。

正常に同期できる場合は、

再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

と表示されます。

今回、問題が発生している状態では、

時刻データが利用できなかったため、
コンピューターは同期をとり直しませんでした。

と表示されました。

/forceと/rediscoverの違い

今回よく使用したのが次の2つです。

w32tm /resync /force

と、

w32tm /resync /rediscover

です。

ざっくり分けると、

/force
→ 現在設定されている時刻ソースを使って強制的に同期

/rediscover
→ ネットワーク構成や時刻ソースを再検出してから同期

という違いがあります。

単純に今すぐ同期したい場合は、

w32tm /resync /force

で十分です。

NTPサーバーを手動で指定する

Windows標準では time.windows.com が利用されることがあります。

手動で設定する場合は、

w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /update

を実行します。

日本国内であれば、NICTのNTPサーバーを使うこともできます。

w32tm /config /manualpeerlist:"ntp.nict.jp,0x9" /syncfromflags:manual /update

設定後は、

net stop w32time
net start w32time
w32tm /resync /force

のようにサービスを再起動して同期します。

現在設定されているNTPサーバーを確認する

現在の時刻同期先を詳しく確認するには、

w32tm /query /peers

を使用します。

今回の環境では、

ピア数: 1

ピア: time.windows.com,0x9
状態: アクティブ
モード: 3 (クライアント)

のように表示されました。

設定上はNTPサーバーが登録されていても、実際に同期できているとは限らない点には注意が必要です。

Windows Timeの詳細設定を確認する

より詳しく設定を確認する場合は、

w32tm /query /configuration

を使います。

今回確認できた項目には、

NtpClient
Enabled: 1
Type: NTP
NtpServer: time.windows.com,0x9

などがありました。

Enabled: 1 であれば、NTPクライアント自体は有効です。

Windows Timeサービスが無効になっていた

調査中、一度次のエラーが発生しました。

システム エラー 1058 が発生しました。

指定されたサービスは無効であるか、
または有効なデバイスが関連付けられていないため、
開始できません。

この状態では、

net start w32time

を実行してもWindows Timeサービスを開始できません。

また、

w32tm /query /status

も、

そのサービスを開始できませんでした。
(0x80070426)

となりました。

この場合、Windows Timeサービスを有効化します。

sc config w32time start= demand

成功すると、

[SC] ChangeServiceConfig SUCCESS

と表示されます。

その後、

net start w32time

を実行すると、

Windows Time サービスは正常に開始されました。

となりました。

Windows Timeサービスを再登録する

設定がおかしくなっている可能性がある場合は、Windows Timeサービス自体を再登録する方法もあります。

まず停止します。

net stop w32time

続いて登録解除します。

w32tm /unregister

そして再登録します。

w32tm /register

必要に応じて、

sc config w32time start= demand

でサービスを有効化し、

net start w32time

で起動します。

今回実際に実行した流れは次の通りです。

net stop w32time
w32tm /unregister
w32tm /register
sc config w32time start= demand
net start w32time

その後NTPサーバーを設定します。

w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /update

現在のPC時刻が何秒ずれているか確認する

今回特に便利だったのが、

w32tm /stripchart

です。

例えば、

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

とすると、PCの時刻と time.windows.com の時刻差を確認できます。

今回、最初は次のようになりました。

10:55:44, +52.6892440s
10:55:46, +52.6926343s
10:55:49, +52.6911037s

つまりPCの時計が約53秒ずれていたことになります。

このコマンドは非常に便利です。

Windowsの自動時刻同期が正常に動いているかとは別に、

「今のPCの時計が実際に何秒ずれているのか」

を確認できます。

1回だけ確認する場合

5サンプルも必要なければ、

w32tm /stripchart /computer:time.windows.com /samples:1 /dataonly

でも確認できます。

例えば、

11:17:12, +00.0010513s

であれば、

約0.001秒、つまり約1ミリ秒程度の差しかありません。

最終的にはほぼ正確な時刻になった

今回の調査後、

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

を実行すると、

11:17:12, +00.0010513s
11:17:14, +00.0015054s
11:17:16, -00.1071133s
11:17:18, +00.0018045s
11:17:20, +00.0030756s

となりました。

ほとんどのサンプルで数ミリ秒しかずれていません。

1回だけ約0.1秒の値がありますが、通常のWeb開発で問題になるレベルではありません。

stripchartで0x800705B4が出る場合

NICTのNTPサーバーを確認したところ、

w32tm /stripchart /computer:ntp.nict.jp /samples:5 /dataonly

で、

エラー: 0x800705B4

が発生しました。

これはタイムアウトです。

つまり、

NTPサーバーへ問い合わせ
↓
一定時間待つ
↓
応答なし

という状態です。

この場合、PCだけではなく、

• Wi-Fi
• ルーター
• ファイアウォール
• インターネット回線
• NTPサーバーとの通信経路

なども疑う必要があります。

Event Viewerのログをコマンドで確認する

Windows Timeサービスの詳しいエラーを確認したい場合は、イベントログを見ることもできます。

今回は次のコマンドを利用しました。

wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:20 /rd:true /f:text

直近20件のWindows Time関連イベントを取得できます。

今回のログでは、

Event ID: 47

手動で構成されたピア time.windows.com,0x9 に
8回連絡しましたが、有効な応答を受信しませんでした。

という警告が確認できました。

これは非常に重要な情報でした。

Event ID 134：DNS解決エラー

別の時間帯では、

Event ID: 134

も発生していました。

内容は、

'time.windows.com,0x9' での DNS 解決エラー

です。

つまり、

time.windows.com
↓
IPアドレスへ変換できない

状態でした。

ただし、その後、

Event ID: 137

で、

手動ピア time.windows.com,0x9 の解決に成功しました。

となっていたため、DNSについては一時的な問題だった可能性があります。

VMICTimeProviderのEvent ID 158は今回の原因ではない

ログには、

Event ID: 158

タイム プロバイダー 'VMICTimeProvider' は、
現在のハードウェアおよび操作環境がサポートされないことを示して停止しました。

というメッセージも大量にありました。

一見すると怪しく見えますが、

非 HyperV ゲスト環境の VMICTimeProvider では、
これは予期された動作です。

とも書かれています。

通常の物理PCでHyper-V仮想マシンとして動作していないのであれば、このログは今回の問題とは関係ありません。

スマートフォンのテザリングで原因を切り分ける

今回、原因特定で最も役に立ったのがネットワークを変更するテストでした。

普段はマンション備え付けの無料Wi-Fiを利用しています。

そこでPCを一時的にスマートフォンのテザリングへ接続して、「今すぐ同期」を実行しました。

すると、

一瞬で時刻同期に成功しました。

これにより、

Windowsそのもの
→ 少なくとも同期できる状態

スマートフォン回線
→ 同期成功

マンションWi-Fi
→ 同期失敗

という切り分けができました。

Windowsだけを疑っていたのですが、実際にはネットワーク側にも問題がある可能性が高いことが分かりました。

Wi-Fi中継器も疑った

私の環境では、マンションWi-Fiをそのまま利用するのではなく、部屋の中でWi-Fi中継器も使用しています。

そのため、

マンションWi-Fi
↓
中継器
↓
PC

という構成になっています。

そこで中継器を経由せず、

マンションWi-Fi
↓
PC

へ直接接続しました。

その状態で、

w32tm /resync /force

を実行すると、一度は、

コマンドは正しく完了しました。

となりました。

さらに、

w32tm /query /source

を確認すると、

ntp.nict.jp,0x9

になりました。

正常同期された状態

そのとき、

w32tm /query /status

は次のようになりました。

閏インジケーター: 0 (警告なし)
階層: 2 (二次参照 - (S)NTP で同期)
参照 ID: 0x85F3EEA4
最終正常同期時刻: 2026/08/18 11:11:09
ソース: ntp.nict.jp,0x9

これは正常にNTP同期できている状態です。

特に、

閏インジケーター: 0
階層: 2

が重要です。

「最終正常同期時刻」だけでは判断できない

しばらくして再び、

w32tm /query /status

を確認すると、

閏インジケーター: 3 (同期未実行)
階層: 0 (未指定)
最終正常同期時刻: 2026/08/18 11:11:09
ソース: ntp.nict.jp,0x9

となっていました。

ここで注意したいのが、

最終正常同期時刻

です。

これはあくまで、

「最後に正常同期した時刻」

です。

現在も同期されているという意味ではありません。

現在の状態を見る場合は、

閏インジケーター
階層

を見る方が重要です。

ポーリング間隔について

今回、

ポーリング間隔: 10 (1024s)

と表示されていました。

1024秒 は約17分です。

つまりWindowsは毎秒NTPサーバーへ問い合わせているわけではありません。

そのため、

最終正常同期時刻が2分前

というだけなら問題ありません。

2分前に同期されていても普通です。

ただし、

閏インジケーター: 3
階層: 0

になっている場合は、現在の同期状態に問題があります。

time.windows.comではstripchartが成功した

興味深かったのが、NICTではタイムアウトしていた一方、

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

では正常に取得できたことです。

結果は、

11:17:12, +00.0010513s
11:17:14, +00.0015054s
11:17:16, -00.1071133s
11:17:18, +00.0018045s
11:17:20, +00.0030756s

でした。

つまり、

NTP通信が完全に使えない

というわけでもありません。

特定のNTPサーバーや通信条件によって挙動が変わる、少しややこしい状態でした。

stripchartが成功してもWindowsの自動同期が成功するとは限らない

今回の調査で重要だったポイントです。

w32tm /stripchart

が成功しているからといって、

w32tm /resync

も必ず成功するわけではありません。

実際、今回も、

stripchart
→ 成功

resync
→ 失敗

という状態が発生しました。

そのため、

「NTPサーバーへ到達できること」

と、

「Windows Timeサービスとして正常同期できること」

は分けて考えた方がよさそうです。

Windowsの「今すぐ同期」がローディングしていても時刻差は小さい場合がある

今回最終的には、

Windows 11の設定画面では、

今すぐ同期
→ ローディングしたまま

という状態が残りました。

一方、

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

では数ミリ秒程度の誤差しかありませんでした。

つまり、

Windows設定画面
→ 正常に処理完了しない

現在のPC時計
→ 実際にはかなり正確

というケースもあります。

開発用途で重要なのは、最終的にはPCの時刻がどれくらいずれているかです。

開発では何秒くらいのズレまで問題ない？

一般的なWeb開発で、

0.001秒
0.01秒
0.1秒

程度の差を気にする必要はほぼありません。

例えば、

• Git
• GitHub
• Node.js
• npm
• Vercel
• Netlify
• API
• OAuth
• JWT
• Docker
• データベース
• 一般的なWebアプリ

などで、0.1秒程度の誤差が原因で問題になるケースは通常ほとんどありません。

今回最初に発生していた、

約53秒

のズレとはまったく違います。

私の場合は、

±1秒以内

程度であれば、通常の開発用途ではひとまず問題なしと判断することにしました。

今後、時刻差だけ確認したい場合

今回一番使いやすかったので、今後はこのコマンドを覚えておこうと思います。

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

1回だけなら、

w32tm /stripchart /computer:time.windows.com /samples:1 /dataonly

です。

例えば、

+00.0030756s

なら約3ミリ秒。

+01.2000000s

なら約1.2秒。

+52.0000000s

なら約52秒ずれています。

よく使ったコマンドまとめ

最後に、今回使用したコマンドを用途別にまとめます。

現在の同期状態を確認

w32tm /query /status

見るポイント：

閏インジケーター
階層
最終正常同期時刻
ソース

現在の時刻ソースだけ確認

w32tm /query /source

正常例：

time.windows.com,0x9

異常例：

Local CMOS Clock

設定中のNTPサーバーを確認

w32tm /query /peers

Windows Timeの詳細設定

w32tm /query /configuration

今すぐ時刻同期

w32tm /resync /force

NTPサーバーを再検出して同期

w32tm /resync /rediscover

Windows Timeサービス停止

net stop w32time

Windows Timeサービス開始

net start w32time

Windows Timeサービスを手動起動可能にする

sc config w32time start= demand

time.windows.comをNTPサーバーに設定

w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /update

NICTをNTPサーバーに設定

w32tm /config /manualpeerlist:"ntp.nict.jp,0x9" /syncfromflags:manual /update

PCとNTPサーバーの現在の時刻差を確認

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

NICTとの時刻差を確認

w32tm /stripchart /computer:ntp.nict.jp /samples:5 /dataonly

Windows Timeサービスを登録解除

w32tm /unregister

Windows Timeサービスを再登録

w32tm /register

Windows Timeのイベントログを確認

wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:20 /rd:true /f:text

トラブル発生時の確認手順

今回の経験から、次回同じ問題が起きた場合は次の順番で確認すればよさそうです。

1. まず同期状態

w32tm /query /status

2. 同期元

w32tm /query /source

3. 強制同期

w32tm /resync /force

4. 実際の時刻差

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

5. サービス確認

net stop w32time
net start w32time

6. NTPサーバー再設定

w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /update

7. イベントログ確認

wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:20 /rd:true /f:text

8. 別のネットワークで確認

スマートフォンのテザリングなどへ一時的に切り替えます。

これで同期できるのであれば、

Windows

ではなく、

Wi-Fi
ルーター
マンション回線
ネットワーク制限

などを疑うことができます。

今回の結論

今回のWindows 11の時刻同期問題は、単純にWindowsの設定を変更すれば解決するものではありませんでした。

最初は約53秒ずれており、

ソース: Local CMOS Clock

となっていました。

Windows Timeサービスの確認、再起動、再登録、NTPサーバー変更などを試した結果、一時的には正常同期できました。

さらにスマートフォンのテザリングでは即座に同期できたため、最終的にはマンション備え付けWi-Fiを含むネットワーク側にも問題がある可能性が高いと判断しました。

一方で、最終的な実際の時刻差を、

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

で確認すると、

約0.001〜0.1秒

程度でした。

そのため、Windowsの設定画面にある「今すぐ同期」は正常終了していないものの、現時点でのPC時計そのものは開発用途として十分な精度になっています。

今回特に覚えておきたいのは、

w32tm /query /status

だけではなく、

w32tm /stripchart

を利用することです。

Windowsの同期状態に問題があったとしても、

「実際にPCの時計が何秒ずれているのか」

を直接確認できるので、トラブルシューティングでは非常に役立ちました。

また、Windows側だけを疑うのではなく、

別回線へ接続して同期できるか試す

という方法も非常に有効でした。

Windows 11で「今すぐ同期」が終わらない、Local CMOS Clock になっている、時刻データが利用できなかった と表示される場合には、同じように w32tm を使って順番に切り分けると原因を特定しやすくなります。