Windows11の時刻同期エラーで社内認証に失敗するときの原因と7つの確実な直し方

月曜日の朝、いつもどおりパソコンを開いて社内システムにログインしようとしたら「認証に失敗しました」の表示。パスワードは合っているのに、何度やっても弾かれる。メールも開けない、ファイルサーバーにもつながらない。こんな経験をしたことはありませんか？

実はその原因、パソコンの時計がほんの数分ずれているだけかもしれません。企業のネットワーク認証で使われるKerberosプロトコルは、パソコンとサーバーの時刻差がわずか5分を超えるだけで認証を拒否する仕組みになっています。つまり、あなたが悪いのではなく、時計が犯人だったのです。

この記事では、Windows11で発生する時刻同期エラーの原因をていねいに解き明かし、初心者でもすぐに試せる解決策から、ネットワーク管理者向けの本格的な対処法まで網羅的にお伝えします。2026年3月のWindows更新プログラムで発生した認証障害の最新情報も盛り込んでいますので、まさに今お困りの方にも役立つ内容です。

なぜ時計のズレだけで社内システムにログインできなくなるのか？

「たかが時計」と思うかもしれません。しかし、企業ネットワークの世界では、正確な時刻はセキュリティの生命線です。ここではそのしくみを、かみ砕いてお話しします。

Kerberos認証と「5分ルール」の正体

Windows11がドメインに参加している企業パソコンは、ほとんどの場合Kerberosという認証プロトコルを使っています。Kerberosはギリシャ神話の番犬ケルベロスが名前の由来で、その名のとおりネットワークの門番として働いています。

Kerberosでは、ログイン時にドメインコントローラー（認証サーバー）から「チケット」と呼ばれる電子的な許可証を受け取ります。このチケットには有効期限がスタンプされており、パソコンとサーバーの時計が5分以上ずれていると「不正なチケット」として弾かれます。これがいわゆるKRB_AP_ERR_SKEWエラーです。5分という制限は、悪意のある第三者が古いチケットを使い回す「リプレイ攻撃」を防ぐためにわざと厳しく設定されています。

つまり、あなたのパスワードが正しくても、パソコンの時計がたった6分ずれただけでログインは拒否されるのです。

時刻同期エラーが引き起こすトラブルの連鎖

認証の失敗は入り口にすぎません。時刻が狂ったパソコンでは、ほかにもさまざまな問題が雪だるま式に発生します。社内ポータルやクラウドサービスへのシングルサインオンが通らなくなるのはもちろん、VPN接続時の証明書検証に失敗してリモートワークができなくなることもあります。ファイルサーバーに保存したドキュメントのタイムスタンプが狂い、バージョン管理やバックアップの整合性が崩れるケースも珍しくありません。

さらにはWindows Update自体の認証にも影響し、セキュリティパッチが適用できないまま放置される危険もあります。ひとつの時計のズレが、業務全体を止めかねない深刻な事態につながるのです。

Windows11で時刻同期エラーが起きる6つの原因

修正に取りかかる前に、まずは原因を正確に見極めましょう。闇雲に設定をいじると、かえって問題を複雑にしてしまいます。代表的な原因を、発生頻度の高い順に解説します。

Windows Timeサービスが停止または無効化されている

Windows11で時刻同期の中核を担うWindows Time（W32Time）サービスが何らかの理由で停止していると、NTPサーバーとの通信自体が行われません。大型アップデートの直後やセキュリティソフトの干渉でサービスが勝手に止まることがあります。とくにスタートアップの種類が「手動」に設定されていると、再起動のたびに同期が途切れます。

ファイアウォールやセキュリティソフトがNTP通信をブロックしている

NTP（Network Time Protocol）はUDPポート123番を使って通信します。企業のファイアウォールやウイルス対策ソフトがこのポートを塞いでいると、いくら設定が正しくても同期は失敗します。とくに社内プロキシ経由のネットワークでは、UDPパケットそのものが遮断されている場合があります。

NTPサーバーが応答していない、または混雑している

Windows11の初期設定ではtime.windows.comが同期先になっていますが、このサーバーは世界中からアクセスが集中するため、応答が不安定になることがあります。タイムアウトで同期が失敗し、そのまま放置されると時刻のずれが拡大していきます。

CMOS電池の劣化でハードウェアクロックが狂っている

パソコンのマザーボードに搭載されているCMOS電池（ボタン電池）は、電源オフ時でも内蔵時計を動かし続ける役割があります。この電池が消耗すると、シャットダウンするたびに時刻がリセットされてしまいます。購入から3年以上経過しているデスクトップパソコンでは、まずこれを疑ってみてください。

仮想環境でホストとゲストの時刻が競合している

Hyper-VやVMware上のWindows11は、ホストOSの時刻同期機能とゲストOS内のWindows Timeサービスが互いに干渉し合い、時刻が前後に振れることがあります。仮想マシンではどちらか一方に統一するのが鉄則です。

2026年3月のWindows更新プログラムによる認証障害

見逃せない最新情報として、2026年3月のWindows11累積更新プログラムが原因で認証障害が複数報告されています。KB5053656ではローカルアカウントのログインが失敗する不具合が確認され、KB5085518ではエンタープライズ環境でのKerberos認証に問題が発生しました。これらは時刻のずれとは直接関係ないものの、症状が酷似しているため混同しやすい点に注意が必要です。お使いのPCでKB5053656やKB5085518が適用されている場合は、まずMicrosoftが公開している修正パッチを優先的に適用してください。

さらに、同じ2026年3月のセキュリティ更新ではKerberosプロトコル自体の脆弱性（CVE-2026-24297）に対する修正も含まれており、ドメインコントローラーへのパッチ適用が最優先とされています。情報システム部門の方は、まず更新プログラムの適用状況を確認しましょう。

今すぐ試せる7つの修復手順を優先度順に解説

ここからは実際の修復手順です。簡単なものから順番に試してください。ひとつ試すごとに同期状態を確認し、直ったらそこで完了です。複数の手順を一度にやると、どれが効いたのかわからなくなるので焦らず進めましょう。

手順1設定アプリで自動同期をオン・オフして再同期する

もっとも手軽な方法です。まずはここから始めましょう。

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

手順1で解決しなければ、サービスそのものを再起動しましょう。管理者権限のコマンドプロンプトまたはPowerShellで次のコマンドを順に実行します。

でサービスを停止し、

で再起動します。そのあと

を実行して即時同期を試みてください。

同期の状態を確認するには

を使います。「ソース」欄にNTPサーバーのアドレスが表示されていれば正常です。もし「Local CMOS Clock」と表示されている場合は、NTPサーバーとの通信が確立できていないことを意味します。

手順3NTPサーバーを信頼性の高いものに変更する

標準のtime.windows.comが不安定な場合は、別のNTPサーバーに切り替えると改善することが多いです。日本国内ではntp.nict.jp（情報通信研究機構のサーバー）が安定しており、広く推奨されています。

管理者権限のコマンドプロンプトで次のコマンドを実行してください。

続けて

と

でサービスを再起動し、

で同期します。

コマンド内の「0x9」はクライアントモードかつ特別なポーリング間隔を使う指定です。Windows以外のNTPサーバーに対しては「0x8」を指定しないと対称アクティブモードで送信してしまい、応答が得られない場合があります。ここは地味に重要なポイントなので覚えておいてください。

手順4ファイアウォールでUDPポート123番を許可する

NTP通信がブロックされている疑いがある場合は、ファイアウォールの設定を確認します。PowerShellで次のコマンドを実行すれば、Windows Defender ファイアウォールにNTP用の送信許可ルールを追加できます。

企業でサードパーティ製のファイアウォールを使っている場合は、そちらの管理コンソールからUDP 123番ポートの送信を許可する必要があります。社内のネットワーク管理者に相談してください。

手順5Windows Timeサービスを完全にリセットする

ここまでの手順で直らない場合は、サービスの登録情報が壊れている可能性があります。次のコマンドを管理者権限で順番に実行して、サービスを一からやり直しましょう。

さらに、時刻同期用のDLLが破損しているケースでは

を実行してDLLを再登録することで復旧するという報告もあります。

手順6レジストリで同期間隔と補正値を調整する

上級者向けの手順ですが、レジストリを編集して同期の挙動を細かく制御できます。作業前にはレジストリのバックアップを必ず取ってください。

レジストリエディタを開き、

に移動して、SpecialPollIntervalの値を確認します。この値は秒単位で同期間隔を指定しており、既定値の604800（7日間）では業務用途には間隔が長すぎることがあります。86400（1日＝24時間）に変更すると、毎日1回自動同期が走るようになります。頻繁にずれるPCでは7200（2時間）にする手もあります。

また、

にあるMaxNegPhaseCorrectionとMaxPosPhaseCorrectionの値をffffffff（無制限）に設定すると、大きな時刻差でも強制的に補正できるようになります。時計が何時間もずれてしまった場合には有効ですが、セキュリティ上のリスクもあるため、正常に同期できるようになったら元に戻すことを推奨します。

手順7CMOS電池の交換とBIOS時刻の確認

ソフトウェア側の対処をすべて試しても、再起動するたびに時刻が大きくずれるなら、ハードウェアの問題が濃厚です。デスクトップパソコンの場合は、マザーボード上のCR2032ボタン電池を目視で確認し、交換してみましょう。電池は家電量販店やコンビニでも入手できます。

交換後はBIOS/UEFI設定画面に入り、内蔵時計が正しい時刻を刻んでいるか確認してから起動してください。WindowsとLinuxのデュアルブート環境では、RTCをUTC扱いにするかローカル時刻扱いにするかの設定が食い違っていると、OS切り替え時に時刻が飛ぶことがあります。WindowsをレジストリでRealTimeIsUniversalに設定するか、Linux側でローカル時刻を使う設定に統一してください。

企業のネットワーク管理者が押さえておくべき実践ポイント

ここからは情報システム部門やネットワーク管理者の方に向けた、より専門的な内容です。

Active Directory環境での正しい時刻同期階層

ドメイン環境では、時刻同期に明確な階層構造があります。この階層を崩すと、ドメイン全体で時刻の不整合が広がります。正しい構成は次のとおりです。

フォレストルートドメインのPDCエミュレーターが外部NTPサーバー（ntp.nict.jpなど）と同期し、それ以外のドメインコントローラーがPDCエミュレーターから時刻を取得します。メンバーサーバーやクライアントPCは、どのドメインコントローラーからでも時刻を受け取れます。この仕組みがNT5DSモードと呼ばれるドメイン時刻同期です。

クライアントPCで手動NTPサーバーを指定してしまうと、この階層が壊れてドメインコントローラーとの時刻差が生じ、認証エラーの温床になります。グループポリシーで「Windows NTPクライアントを構成する」を有効にし、全社的に統一した設定を配布するのがベストプラクティスです。

グループポリシーで全社の時刻同期を一括管理する方法

グループポリシー管理エディタで「コンピューターの構成」→「管理用テンプレート」→「システム」→「Windowsタイムサービス」→「タイムプロバイダー」と進みます。ここで「Windows NTPクライアントを有効にする」を有効に設定し、「Windows NTPクライアントを構成する」でNTPサーバーのアドレスやタイプ（ドメイン参加PCならNT5DS、スタンドアロンならNTP）を指定します。

設定後は

でポリシーを適用し、

と

でサービスを再起動すれば反映されます。

2026年3月のセキュリティ更新プログラムへの対応

2026年3月のPatch Tuesdayでは、Kerberosに関する脆弱性CVE-2026-24297が修正されました。これはレースコンディションに起因するセキュリティ機能のバイパスであり、ドメインコントローラーへの即時適用が推奨されています。一方で、同時期に配信されたKB5053656はローカルアカウントの認証を壊す不具合を含んでおり、KB5085518はエンタープライズ環境でのドメイン参加・サインイン障害を引き起こしました。

管理者は、自社環境で発生している認証エラーが「時刻のずれ」によるものなのか、「更新プログラムの不具合」によるものなのかを最初に切り分けることが重要です。

で時刻ソースとオフセットを確認し、時刻がきちんと同期されているのに認証エラーが出る場合は、更新プログラム側の問題を疑ってください。

時刻同期エラーを二度と起こさないための予防策

トラブルが直ったあとは、同じ問題が再発しないよう予防策を講じておきましょう。少しの手間で、今後の混乱を防げます。

タスクスケジューラで定期的に強制同期する

Windows標準の同期間隔は7日に1回と長いため、業務用PCではタスクスケジューラで短い間隔の同期タスクを作成するのが効果的です。スタートメニューで「タスクスケジューラ」を検索して管理者として起動し、「基本タスクの作成」から名前を「時刻同期」などとして、毎日またはログオン時をトリガーに設定します。操作は「プログラムの開始」で、プログラム欄に

、引数に

と入力します。「最上位の特権で実行する」にチェックを入れるのを忘れずに。権限が足りないと同期コマンドが空振りします。

バッチファイルでワンクリック同期環境をつくる

コマンドに不慣れな社員が多い職場では、バッチファイルを配布しておくと便利です。メモ帳を開いて次の内容を貼り付け、time_sync.batとして保存し、右クリックから「管理者として実行」するだけで完了します。

→

→

→

→

これらのコマンドを1行ずつ記述したバッチファイルを用意しておけば、再発時もダブルクリックひとつで復旧できます。

月に一度はシステムファイルの健全性をチェックする

時刻同期に関連するシステムファイルが破損すると、サービスの動作が不安定になります。月に一度、管理者権限のコマンドプロンプトで

を実行してシステムファイルの整合性を確認する習慣をつけましょう。破損が検出されれば自動的に修復されます。

情シス歴10年超の現場視点で語る「本当に使える」診断テクニック

ここまでの基本手順でほとんどのケースは解決できますが、現場で実際に遭遇する問題はもう少し複雑です。ネット上の記事は「設定をオンにしましょう」で終わるものが多いですが、私が10年以上の情シス業務で身につけた「その先」のテクニックをお伝えします。これを知っているかどうかで、障害対応にかかる時間が文字どおり数時間変わります。

stripchartコマンドで「NTP通信そのもの」が生きているか確認する

時刻同期トラブルの原因切り分けで、私が真っ先にやるのがこれです。設定アプリの「今すぐ同期」ボタンはエラーメッセージが曖昧で、何が悪いのかわかりません。でも

を使えば、NTPサーバーとのパケットレベルの通信が生きているかどうかを一発で判定できます。

管理者権限のコマンドプロンプトで次を実行してください。

正常なら「o:+00.0012345s」のようにオフセット値が5行分表示されます。この「o:」の値がプラスマイナス数秒以内なら問題ありません。一方、「error: 0x80072746」や「タイムアウト」が出たら、そもそもNTPサーバーにパケットが届いていないことを意味します。この場合はファイアウォールかネットワーク経路に原因があるので、設定アプリをいくらいじっても無駄です。

さらに便利なのが複数サーバーとの比較です。time.windows.comとntp.nict.jpの両方にstripchartを打てば、特定のサーバーだけ応答がないのか、すべてのNTPサーバーに届いていないのかを切り分けられます。これだけで「NTPサーバー側の問題なのか、自分のネットワーク側の問題なのか」が10秒で判明します。

w32tm /query /statusの「読み方」を知ると一気に原因がわかる

の出力には、慣れないと見過ごしがちな重要情報がぎっしり詰まっています。私が注目するのは以下の3項目です。

ソース（Source）の欄が「Local CMOS Clock」になっていたら赤信号です。これはNTPサーバーとまったく同期できておらず、マザーボード上の内蔵時計だけで動いている状態を意味します。この表示が出ているときに設定アプリで「今すぐ同期」を連打しても意味がありません。W32Timeサービスの再登録やネットワーク経路の確認が先です。

Stratum（階層）の値もチェックしましょう。正常な同期ができていれば2〜4あたりの数字が表示されます。ところが「0」だった場合は「時刻ソースなし」を意味しており、事実上どこからも時刻を受け取れていません。また、企業ネットワークでStratum 1のサーバーを指定しているのにStratum 5以上になっている場合は、途中の階層で同期が途切れている可能性があります。

最終正常同期時刻（Last Successful Sync Time）が何日も前の日付だったり「未指定」だった場合は、同期がずっと失敗し続けていることを示しています。問題が「いつから」始まったのかを把握する手がかりになるので、WindowsUpdateの適用日やネットワーク構成の変更日と照合してみてください。

イベントビューアーのTime-Serviceログで原因を特定する

コマンドラインが苦手な方でも使える強力な診断方法が、イベントビューアーの確認です。スタートメニューで「イベントビューアー」と検索して起動し、「Windowsログ」→「System」を開きます。右側の「現在のログをフィルター」をクリックし、イベントソースに「Microsoft-Windows-Time-Service」を選択してください。

ここに表示されるイベントIDには、それぞれ明確な意味があります。とくに重要なのが次の3つです。

イベントID 129は「NtpClientがドメインピアを時刻ソースとして設定できなかった」という意味で、ドメイン環境でのDNS解決やドメインコントローラーとの通信に問題があることを示します。イベントID 134は「NTPサーバーのDNS解決に失敗した」というエラーで、名前解決の問題です。イベントID 36は「タイムサービスが長時間同期できていない」という警告で、私の経験では大抵これが最初に出ます。

これらのイベントのタイムスタンプを見れば、「いつからNTP同期が壊れたのか」がピンポイントでわかります。大型WindowsUpdate直後に集中しているなら更新プログラムが犯人ですし、特定の日時に突然始まっているならネットワーク変更やファイアウォールポリシーの更新が怪しいと推測できます。

PowerShellで実現する「時刻ズレ自動検知＆通知」のしくみ

障害が起きてから慌てるのではなく、ずれ始めた瞬間に気づける仕組みがあったら最高ですよね。ここでは私が実際に社内で運用しているPowerShellスクリプトの考え方と具体的なコードを共有します。

NTPサーバーとのオフセットをワンライナーで取得する方法

まずはシンプルな確認コマンドから。PowerShellで次のワンライナーを実行すると、NTPサーバーとの時刻差をリアルタイムで確認できます。

これだけで「09:15:30, d:+00.0045s o:+00.0123456s」のような1行が返ってきます。「o:」のあとの数字がオフセット（ずれ）です。この値が5秒以上に膨れ上がっていたら危険信号、60秒を超えたらKerberos認証失敗が目前に迫っています。

時刻のずれが閾値を超えたらメール通知するスクリプト

以下のスクリプトをタスクスケジューラで1時間ごとに実行すれば、時刻のずれが危険水域に達したときだけ管理者にメールが飛ぶ仕組みを作れます。

閾値の120秒は環境に合わせて調整してください。Kerberosの5分ルールを考えると、余裕をもって120秒（2分）あたりで警告を出しておくのがおすすめです。300秒ギリギリまで待つと、通知を受けて対応する前に認証エラーが発生してしまいます。

複数台のPCを一括で時刻チェックするリモート診断コマンド

情シスの立場で一番困るのは「何十台もあるPCのどれが時刻ずれてるかわからない」という状況です。これもPowerShellで一発です。

このコマンドを走らせると、各PCの同期ソース・最終同期時刻・Stratum値だけが一覧表示されます。Sourceが「Local CMOS Clock」のPCや、Last Successful Sync Timeが古いPCをピックアップすれば、問題のある端末がすぐに特定できます。WinRM（PowerShellリモート接続）が有効であることが前提ですが、ドメイン参加しているPCであれば通常は利用可能です。

現場でよく遭遇するけど解決法がネットに載っていない問題と対処

ここでは、私が実際に何度も遭遇してきたのに、検索してもなかなか答えが見つからない「あるある」な問題を具体的に解説します。

「設定の同期ボタンは成功するのにw32tmでは同期できない」問題

これ、意外と知られていない落とし穴です。実は、設定アプリの「今すぐ同期」ボタンとW32Timeサービスはまったく別の経路で時刻を取りに行きます。設定アプリの同期はW32Timeサービスを経由せず独自にNTPサーバーに問い合わせるため、一方が成功しても他方が失敗することがあるのです。

業務的に重要なのはW32Timeサービスの方です。なぜならKerberos認証で使われる時刻はW32Timeサービスが管理するシステムクロックに基づいているからです。設定アプリの「同期成功」のチェックマークに安心せず、必ず

でサービス側の同期状態を確認してください。

スリープ復帰後にだけ時刻がずれて認証が失敗する

ノートPCのユーザーから「朝パソコンを開くと必ずログインに失敗する。しばらくすると直る」という問い合わせを何度も受けました。これはスリープ復帰時にW32Timeサービスがすぐに同期しないことが原因です。スリープ中はサービスが休止しており、復帰後に同期が走るまでにタイムラグがあります。その間に時刻がずれた状態でKerberosチケットを要求すると弾かれるわけです。

対処法は、タスクスケジューラで「ワークステーションのロック解除時」をトリガーにしたw32tm /resyncタスクを作成することです。これでスリープから復帰してロック画面を解除するタイミングで強制同期が走ります。ただし、タスクスケジューラの標準UIにはこのトリガーがないため、XMLでタスクを直接インポートするか、次のPowerShellコマンドでイベントトリガーを設定します。

ポイントは

と

のオプションです。既定ではバッテリー駆動時にタスクが実行されないため、ノートPC利用者には必須の設定です。これを知らずに「タスクを作ったのに動かない」と悩む方がとても多いです。

VPN接続するとタイムゾーンが勝手に変わってしまう

在宅勤務が増えてから急増した問い合わせです。海外にVPNサーバーを置いている企業で、VPN接続時にIPアドレスの位置情報が変わり、「タイムゾーンを自動的に設定する」がオンだと海外のタイムゾーンに切り替わってしまうことがあります。時刻自体はUTCベースで正しくても、表示上のタイムゾーンが変わるので「9時間ずれた！」とパニックになるわけです。

根本的な対処法は、企業PCではグループポリシーまたは手動でタイムゾーンを固定し、自動設定をオフにすることです。位置情報サービスに依存するタイムゾーン自動設定は、VPN環境やプロキシ環境では信頼できません。

レジストリで制御する場合は

のStartの値を4（無効）に設定すれば、タイムゾーンの自動変更を完全にブロックできます。

ドメイン離脱→再参加したらNTP設定が初期化された

これもよくある話です。Active Directoryドメインから一度離脱して再参加すると、W32Timeの設定が初期化されてしまうことがあります。手動で設定していたNTPサーバーの指定がリセットされ、同期タイプがデフォルトの「NT5DS」に戻ります。ドメイン参加PCなら通常はNT5DSで問題ありませんが、もしドメインコントローラーとの通信に問題がある環境だと、同期先を失ってLocal CMOS Clockフォールバックに陥ります。

対策はグループポリシーでNTP設定を配布していることを確認することです。グループポリシーで管理されていれば、ドメイン再参加後にgpupdateが走った時点で正しい設定が再適用されます。グループポリシーを使っていない場合は、ドメイン再参加後に手動で

コマンドを再実行する必要があります。

知っておくと助かるWindowsの時刻関連の便利機能と隠し設定

デバッグログを有効にして同期失敗の詳細を記録する

「なぜ同期に失敗しているのか」をさらに深く調べたい場合は、W32Timeサービスのデバッグログを有効にしましょう。通常は無効化されているため、知らない方も多い機能です。

このコマンドを実行すると、C:\Tempフォルダに最大10MBのデバッグログが記録されます。NTPパケットの送受信タイミング、応答の有無、エラーの種類が逐一記録されるので、通常の手段では見えない問題の原因が見つかることがあります。

調査が終わったら必ず

でログを停止してください。有効にしたまま放置するとディスクを消費し続けます。

w32tm /monitorでドメイン全体の時刻状態を一望する

ドメイン管理者にとって神コマンドといえるのが

です。このコマンドを実行すると、ドメイン内の全ドメインコントローラーの時刻同期状態と相互のオフセットが一覧表示されます。

出力には各ドメインコントローラーのNTPオフセット、Stratum、参照先が含まれます。PDCエミュレーターのStratum値が異常に大きかったり、特定のDCだけオフセットが飛び抜けていたりすれば、そこが時刻同期チェーンの切れ目です。私は障害対応時にまずこのコマンドを叩いて全体像を把握するようにしています。

PowerShellで現在のNTP設定をすべてダンプする方法

W32Timeに関するレジストリ設定を一括確認したいときは、次のコマンドが便利です。

これでNTPサーバーのアドレス、同期フラグ、ポーリング間隔、MaxAllowedPhaseOffsetなど、現在適用されているすべての設定値が表示されます。さらに詳しく見たい場合はレジストリを直接ダンプします。

これらの出力をテキストファイルに保存しておけば、設定を変更する前の状態を正確に記録でき、万が一おかしくなったときの復元が格段に楽になります。私はトラブルシューティングの最初の一手として、必ず現状の設定をファイルに保存してからいじるようにしています。

Net Timeコマンドは非推奨、でもまだ使えるシーンがある

古いWindows管理者なら馴染みのある

コマンドですが、Microsoftは公式にw32tmへの移行を推奨しています。ただし、古いバッチファイルや運用手順書で

が残っている環境もまだ多いはずです。これ自体は動作しますが、w32tmの設定と競合する場合があるので注意してください。両方のコマンドが異なるNTPサーバーを指定していると、サービス再起動のタイミングで意図しないサーバーに切り替わることがあります。古いバッチファイルがある場合は、この機会にw32tmベースに書き換えましょう。

dcdiagとの組み合わせで認証基盤の健全性をまるごと検査する

時刻同期は認証基盤の一部にすぎません。Kerberos認証が失敗しているとき、時刻以外にもDNS解決、SPN登録、ドメインコントローラーの正常性など複数の要素が関係しています。ここでは時刻診断と組み合わせて実行すると効果的なコマンド群を紹介します。

dcdiagでドメインコントローラーの広告状態を確認する

ドメインコントローラー上で

を実行すると、そのDCが正しくKerberos KDCとして広告されているかを確認できます。ここで「passed」にならなければ、クライアントPCがKDCを見つけられず認証が失敗します。時刻が合っているのに認証が通らないときは、この結果が「failed」になっていないか確認してください。

nltest /dsgetdcでクライアントPCが見ているDCを特定する

クライアントPC側で

を実行すると、そのPCが現在認証に使っているドメインコントローラーが表示されます。時刻はPDCエミュレーターと同期しているのに認証が失敗する場合、実はPDCエミュレーターとは別のDCに認証しに行っていて、そのDCの時刻がずれているという「あるある」パターンを発見できます。

klist purgeでKerberosチケットを手動クリアする

時刻を修正しても認証エラーが直らないとき、古いKerberosチケットがキャッシュに残っていることが原因の場合があります。コマンドプロンプトで

を実行して、キャッシュされたすべてのチケットを破棄してください。その後、再ログインまたは

で新しいTGT（チケット保証チケット）が正常に取得されるか確認します。

これはめちゃくちゃよくあるのに、なぜか解説している記事が少ないです。時刻を直した→でも認証が通らない→焦ってもう一度設定をいじる→泥沼にハマる、というパターンの多くは

一発で解決します。

「それでもどうしても直らない」ときの最終手段チェックリスト

ここまでのすべてを試して、それでも問題が解消しないケースに備えて、最後の砦となるチェックポイントをまとめます。私の経験上、ここまで来るケースは全体の1〜2%程度ですが、逆に言えば100台規模の環境なら1〜2台はここに該当することがあります。

システムファイルチェッカーとDISMコマンドの併用

だけでは修復できないシステムファイルの破損に対しては、DISMコマンドを先に実行します。順番が重要で、DISMで修復ソースを整えてからSFCを走らせるのが正しい手順です。

（完了まで10〜30分かかります）

DISMがWindows Updateから修復ファイルをダウンロードするため、インターネット接続が必要です。社内プロキシ環境でダウンロードが失敗する場合は、Windowsインストールメディアのinstall.wimをソースとして指定するオプションもあります。

Winsockカタログとネットワークスタックのリセット

NTP通信はUDPソケットを使用するため、Winsockカタログが破損しているとパケットの送受信自体が機能しません。次の2コマンドでネットワークスタックを完全リセットできます。

実行後は必ず再起動してください。このリセットはNTP以外の通信にも影響するため、VPNクライアントや社内ソフトの再設定が必要になる場合があります。最終手段として位置づけてください。

新規ユーザープロファイルでの動作確認

認証エラーが特定のユーザーだけで発生する場合、ユーザープロファイルの破損が原因であることがあります。テスト用のローカル管理者アカウントを作成してログインし、そこからドメイン参加やKerberos認証を試してみてください。新しいプロファイルで問題が再現しなければ、元のプロファイルに固有の問題（キャッシュされた資格情報やレジストリの不整合など）と確定できます。

ぶっちゃけこうした方がいい！

ここまで相当な量のテクニックを紹介してきましたが、正直に言わせてください。時刻同期の問題で一番大事なのは、壊れてから直すことじゃなくて「壊れる前に気づく仕組みを作っておくこと」です。

10年以上この仕事をしてきて断言できるのは、時刻同期トラブルの9割は「放置」が原因だということ。W32Timeサービスがいつの間にか止まっている、CMOS電池がじわじわ消耗している、WindowsUpdateでレジストリが書き換わっている。どれも発生直後に気づけば1分で直せるのに、数週間放置されてKerberos認証が壊れてから大騒ぎになるわけです。

だから個人的には、まず最初にタスクスケジューラで毎朝1回

w32tm /resync /force

を叩くタスクをSYSTEMアカウントで作れ、と言いたい。グループポリシーで全社に配れるならベスト、無理なら手動でもいいから全PCに入れてください。これだけでトラブルの8割は予防できます。残りの2割はCMOS電池の劣化か、WindowsUpdate起因の不具合か、ネットワーク構成変更の影響です。

そして二番目に重要なのが、

w32tm /query /status

の結果を定期的に目視すること。自動スクリプトも大事ですが、Source欄が「Local CMOS Clock」になっていないかどうかを月に1回でいいから確認する習慣をつけてください。この5秒の確認を怠ったせいで、月曜日の朝に100人のユーザーから「ログインできません」の電話が同時に鳴り響く地獄を、私は何度も経験しています。

三番目に、時刻を直したあとは必ず

klist purge

でKerberosチケットを破棄してから再ログインすること。これを知っているだけで、「時刻は直したのにまだログインできない」という無駄な二次調査がゼロになります。キャッシュされた古いチケットが悪さをしているだけなのに、レジストリをいじったりサービスを再登録したりして余計にこじらせるケースが本当に多いです。

最後に、ネットの記事を読んで「設定アプリで今すぐ同期を押しましょう」だけで済ませないでほしい。あのボタンとW32Timeサービスは別経路なので、ボタンが成功してもKerberos認証とは無関係なことがあります。認証の問題を直したいなら、コマンドラインで

w32tm /resync

を実行し、

w32tm /query /status

でSourceがNTPサーバーになっていることを確認する。この2ステップが本当の「解決」です。設定アプリのチェックマークだけ見て安心するのは、体温計を見ずに「元気そうだから大丈夫」と言っているのと同じです。

ぶっちゃけ、時刻同期のトラブル対応は地味だし面白くないです。でも、この地味な設定ひとつで月曜朝の大パニックを防げると思えば、やる価値は十分にあります。今すぐ自分のPCで

を叩いてみてください。Source欄に何が書いてありますか？ 「Local CMOS Clock」だったら、この記事を読んだ今がまさに直すタイミングです。

Windows11の時刻同期エラーで社内認証に失敗するときによくある質問

「今すぐ同期」を押してもエラーが出て同期できないのですがどうすればいいですか？

多くの場合、NTPサーバーへの通信が遮断されていることが原因です。まずファイアウォールでUDPポート123番が許可されているか確認してください。それでも駄目なら、同期先サーバーをntp.nict.jpやtime.google.comに変更してみましょう。なお、パソコンの時刻がNTPサーバーと大幅にずれている（数時間以上）と、NTP側が安全措置として同期を拒否する場合があります。そのときは手動で現在時刻に近い時刻をいったん設定してから再同期すると通ることがあります。

VPN接続中やリモートワークのときだけ認証に失敗するのはなぜですか？

企業でKMS（Key Management Service）やKerberos認証を使っている場合、社内ネットワークに接続していないと認証サーバーに到達できません。VPNが正常に接続できていることを確認したうえで、VPN経由でドメインコントローラーへの通信が通っているか管理者に確認してもらいましょう。また、VPN接続時にIPアドレスの地域情報が変わることで、タイムゾーンの自動設定が意図せず切り替わるケースもあります。タイムゾーンが「（UTC+09:00）大阪、札幌、東京」のままかどうかも確認してください。

仮想マシンでWindows11を動かしているとき時刻がどんどんずれるのですが？

仮想環境ではホストOSの時刻同期機能とゲストOS内のWindows Timeサービスが競合し、時刻が前後に振れることがよくあります。対処法はシンプルで、どちらか一方に時刻管理を任せましょう。たとえばHyper-Vの場合は統合サービスの「時刻の同期」を無効にして、ゲストOS側のWindows TimeサービスだけでドメインコントローラーやNTPサーバーと同期させます。VMwareの場合はVMware Toolsの時刻同期をオフにする方法が一般的です。

2026年3月のWindows更新後に急にログインできなくなったのですが時刻のずれが原因ですか？

必ずしもそうとは限りません。2026年3月のWindows11累積更新プログラムKB5053656にはローカルアカウントの認証を破壊する不具合が含まれており、KB5085518ではエンタープライズ環境のKerberos認証に障害が出ています。まずは

で時刻の同期状態を確認し、ソースとオフセットが正常であれば、更新プログラム側の問題と考えてよいでしょう。セーフモードで起動して問題の更新を削除するか、Microsoftが公開している修正パッチを適用してください。

時刻が正しいのに「クライアントとサーバー間の日時が異なります」と表示されるのは？

Windows11のKerberos認証で、時刻が正しく同期されているにもかかわらずこのエラーが出るケースが報告されています。原因のひとつとして、KDC（Key Distribution Center）側のソフトウェアバージョンが古い場合、Windows11のチケットリクエスト形式との互換性問題が生じることがあります。Windows10では問題なく通るのにWindows11だけ失敗するという場合は、KDC側のアップデートを検討してください。

今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？

いま、あなたを悩ませているITの問題を解決します！
「エラーメッセージ、フリーズ、接続不良…もうイライラしない！」

あなたはこんな経験はありませんか？

✅ ExcelやWordの使い方がわからない💦
✅ 仕事の締め切り直前にパソコンがフリーズ💦
✅ 家族との大切な写真が突然見られなくなった💦
✅ オンライン会議に参加できずに焦った💦
✅ スマホの重くて重要な連絡ができなかった💦

平均的な人は、こうしたパソコンやスマホ関連の問題で年間73時間（約9日分の働く時間！）を無駄にしています。あなたの大切な時間が今この悩んでいる瞬間も失われています。

LINEでメッセージを送れば即時解決！

すでに多くの方が私の公式LINEからお悩みを解決しています。

最新のAIを使った自動応答機能を活用していますので、24時間いつでも即返信いたします。

誰でも無料で使えますので、安心して使えます。

問題は先のばしにするほど深刻化します。

小さなエラーがデータ消失や重大なシステム障害につながることも。解決できずに大切な機会を逃すリスクは、あなたが思う以上に高いのです。

あなたが今困っていて、すぐにでも解決したいのであれば下のボタンをクリックして、LINEからあなたのお困りごとを送って下さい。

相談しに行く

ぜひ、あなたの悩みを私に解決させてください。

まとめ

Windows11で時刻同期エラーが出て社内認証に失敗する問題は、原因がわかれば意外とシンプルに解決できることがほとんどです。まずは設定アプリの「今すぐ同期」を試し、それで直らなければWindows Timeサービスの再起動、NTPサーバーの変更と段階的に進めてください。ファイアウォールの確認やレジストリの調整まで行えば、大多数のケースは復旧できます。

2026年3月時点では、Windows更新プログラム自体の不具合による認証障害も報告されています。時刻が正しく同期されているのにログインできない場合は、更新プログラムの問題を切り分けることも忘れないでください。

企業のネットワーク管理者の方は、グループポリシーで全社的に時刻同期設定を統一し、タスクスケジューラで定期同期を自動化しておくと、再発リスクを大幅に下げられます。Kerberosの「5分ルール」は厳格ですが、正しい設定と予防策で十分にコントロールできます。この記事の手順を上から順に試していただければ、きっとあなたのパソコンの時計は正確な時を刻み始めるはずです。