「このサーバーだけ、時刻が2分ずれています」
「VMの時刻が、ときどき数分ずれては戻ります」
時刻のずれの問い合わせは、原因がさまざまです。通信が届いていない、時刻源が使われていない、誰かが時計を動かしている……。やみくもにコマンドを打つより、順番に確かめるほうが早く着きます。
第10回では、第1回〜第9回の知識を使って、時刻同期のトラブルの切り分けをまとめます。最後に連載の早見表も載せます。
切り分けの手順
| 段階 | 確認すること | Linux（chrony） | Windows（w32tm・PowerShell） |
|---|---|---|---|
| 0 症状を固める | どの機器が・どれだけ・どちら向きに・いつから・常にか時々か | date -u、timedatectl | (Get-Date).ToUniversalTime()、w32tm /tz |
| 1 同期しているか | 同期の有無、現在のずれ、stratum、Leap status | chronyc tracking | w32tm /query /status |
| 2 時刻源は使われているか | 参照先ごとの状態、Reach、選ばれているか | chronyc sources -v、chronyc selectdata -v | w32tm /query /source、w32tm /query /peers |
| 3 届くか | UDP 123 の往復、名前解決 | chronyd -Q ‘server 名前 iburst’ | w32tm /stripchart /computer:名前 /samples:3 /dataonly |
| 4 誰が時計を動かしたか | step の記録、二重の同期、仮想化のツール | journalctl -u chronyd、vmware-toolbox-cmd timesync status | Get-WinEvent（Time-Service、Kernel-General の ID 1＝時刻の変更） |
- 比べるときは、表示のタイムゾーンに惑わされないようUTCで並べる
- 段階1で同期していれば段階4へ、していなければ段階2・3へ進む
- Ubuntu・Debianのサービス名は
chrony（journalctl -u chrony）。chronyc trackingとw32tm /query /statusの読み方は、第4回・第5回
ポイント
同期していなければ通信と時刻源を、同期しているのにずれるなら「時計を動かす者」を疑う。
同期しないとき① 届いているか（UDP 123）
- NTPはUDP 123。サーバーは123番で受けて123番から返す。クライアントの送信元ポートは実装で違い、chronyは既定でランダム（RFC 9109の推奨）、w32timeは送信元も123番に固定。ファイアウォールは宛先のUDP 123で許可し、戻りの通信も通るようにする
- NTSを使う場合は、鍵交換（NTS-KE）のTCP 4460も必要（第8回）
- 名前で指定しているときは名前解決も疑う。Windowsはイベント134（手動で指定した参照先のDNS解決の失敗）、chronyは
chronyc sources -aで名前のまま（ID#…）残る
$ chronyd -Q -t 10 'server ntp.nict.jp iburst' # 時計は変えず、ずれだけ表示（root 不要）
2026-09-26T07:14:08Z System clock wrong by -0.000870 seconds (ignored)
$ chronyd -Q -t 8 'server 192.0.2.123 iburst'
2026-09-26T07:14:16Z Timeout reached
PS> w32tm /stripchart /computer:ntp.nict.jp /samples:3 /dataonly
16:14:08, +00.0008123s
PS> w32tm /stripchart /computer:192.0.2.123 /samples:3 /dataonly
16:14:18, エラー: 0x800705B4
（抜粋）Timeout reachedやエラー: 0x800705B4（英語版はerror:。タイムアウト）は、応答が届いていない合図です。Test-NetConnectionはTCPしか試せず、UDPのNTPは確かめられません。またw32tm /stripchartは送信元に一時的なポートを使うため、成功しても、送信元123番のw32time本体が通るとは限りません。w32tm /resyncの結果と、/query /statusの「最終正常同期時刻」（Last Successful Sync Time）も確かめます。逆に、ネットワークの機器が送信元のポートで扱いを変えていると、/stripchartは失敗するのに w32time 本体は同期できている、ということもあります。
同期しないとき② 時刻源が使われない
| 見え方（chrony） | 意味 | Windows で近い表示 | 次に確かめること |
|---|---|---|---|
| ^?、Reach が 0 | 同期済みの応答が1度も来ていない | w32tm /query /peers の State が Pending | 到達性（前の節） |
| Reach が 0 なのに ntpdata の受信数が増える | 相手が非同期（stratum 16、Leap status が Not synchronised）。応答はあるが使えない | w32tm /stripchart /packetinfo の Stratum・Leap Indicator | 相手の上流の同期状態 |
| x | 多数派と合わない（falseticker） | — | その時刻源の上流、リープスメアの混在 |
| ~ | 測定のばらつきが大きい | — | 経路の遅延の揺れ（VPN・無線・混雑） |
| * が1つもない | 選べる時刻源がない、または多数派がない | Source が Local CMOS Clock・Free-running System Clock | 時刻源の数と独立性 |
$ chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.corp.example.jp 2 6 377 34 +112us[ +140us] +/- 18ms
^+ ntp3.corp.example.jp 2 6 377 36 -310us[ -282us] +/- 21ms
^x ntp2.corp.example.jp 2 6 377 35 -2104ms[-2104ms] +/- 20ms
^? ntp4.corp.example.jp 0 6 0 - +0ns[ +0ns] +/- 0ns
$ chronyc ntpdata ntp4.corp.example.jp | grep -E 'Leap|Stratum|valid RX'
Leap status : Not synchronised
Stratum : 16
Total valid RX : 12- 上の例のntp4は、応答は届いている（valid RX 12）のに、相手が非同期（stratum 16）なので使われていない。ntp4の上流を調べる
- ntp2は多数派と2秒ずれており、
x（falseticker）として除かれている - 時刻源が2つだと、食い違ったときにどちらが正しいか決められず、chronyは
Can't synchronise: no majorityをログに出して同期をやめる。RFC 8633は、独立した時刻源を4つ以上使うよう勧めている（第7回）
公開の時刻源も誤ることがあり、NICTの公開NTPは2026年9月9日に10分あまり、冗長系の一部から誤った時刻を配信しました。
大きくずれたときの直し方
冒頭の「このサーバーだけ2分ずれている」を、どう直すかです。
| 項目 | chrony（Linux） | w32time（Windows） |
|---|---|---|
| 自動で step する条件 | makestep 1.0 3（RHEL・Ubuntu の既定）：起動後の最初の3回の更新で、1秒を超えるときだけ | ずれが MaxAllowedPhaseOffset を超えるとき（ドメイン参加 300秒、ワークグループ 1秒） |
| それ以外のとき | slew。既定の上限は 83333ppm（1秒あたり約83ms）で、60秒のずれなら最短でも約12分 | slew（時計の進み方を調整して少しずつ直す） |
| 直す量の上限 | maxchange で設定できる（既定では制限なし） | MaxPosPhaseCorrection・MaxNegPhaseCorrection（メンバーは無制限、DC は48時間、ワークグループは15時間）。超えるとイベントを記録して直さない |
| 手動ですぐ直す | chronyc makestep（残りの slew をやめて一度に step） | w32tm /resync（参照先を探し直すなら /rediscover） |
$ sudo chronyc makestep
200 OK
$ journalctl -u chronyd | grep stepped # Ubuntu は -u chrony
... System clock was stepped by 63.207841 seconds
PS> w32tm /resync /rediscover
（抜粋）
- 上限を超えて直さないときに
w32tm /resync /forceがよく紹介されますが、Microsoft Learnの構文には記載がありません - stepで時刻が戻ると、ログの順序の逆転、同じ時刻の重複、cronやタスクスケジューラーの二重実行・実行漏れ、DBやクラスターの異常が起きる
- 大きなずれは業務を止められる時間帯に直し、アプリを再起動する。60秒のずれでも、安全なslewでは10分以上かかる。直す前に、どちらを取るか決める
仮想マシンの時刻の飛び
冒頭の「VMの時刻がときどき数分ずれては戻る」の答えです。
仮想マシンの時計は、ゲストのOSだけでなく、ホストや仮想化のツールからも動かされます。よくある原因は3つです。
- 二重の同期：VMware Toolsの定期同期やHyper-Vの時刻同期と、ゲストのchrony・w32timeが別々の時刻に合わせようとして、時刻がのこぎりの歯のように行き来する
- スナップショットの復元：時計が取得した時点まで戻る
- 一時停止や保存状態からの再開：止まっていた時間だけ遅れる
VMware Toolsは、再開・vMotion・スナップショットの復元などのときに、一度だけホストの時刻へ合わせる同期を既定で行い、定期同期を無効にしても働きます。このため、ホストの時刻がずれていると、そのずれがゲストに持ち込まれます。時計を直す仕組みは1台に1つにし、ホストのNTPも必ず監視します（第4回・第6回）。
Kerberos・証明書・ログの時刻のずれ
| 影響 | 見えるエラー・記録 | 許されるずれの目安 |
|---|---|---|
| Kerberos 認証の失敗 | KRB_AP_ERR_SKEW（0x25）。DC のセキュリティログ 4771 の失敗コード 0x25、端末のシステムログの Kerberos イベント 4、Linux の kinit は Clock skew too great（連載「Kerberos入門」第13回の「Clock skew too great」の節） | 既定で5分（Kerberos ポリシーの「コンピューターの時計の同期の最長トレランス」、krb5.conf の clockskew 300秒） |
| 証明書のエラー | NET::ERR_CERT_DATE_INVALID、openssl の certificate is not yet valid (9)・has expired (10) | 端末が遅れていると、発行直後の証明書が「まだ有効でない」になる（連載「証明書入門」第10回） |
| ワンタイムパスワード（TOTP） | コードが通らない | 30秒ごとに変わる。前後1つ程度を許す実装が多い |
| ログの突き合わせ | 順序が逆になる、同じ事象が数分ずれる | 時刻のずれに加え、UTC と JST の混在、年やタイムゾーンのない形式。RFC 5424・RFC 3339 形式で記録する |
Kerberosの5分は「UTCと合っているか」ではなく、「DCと端末が合っているか」で判定されます。全員が同じだけずれていれば認証は通りますが、証明書や外部のサービスで問題になります。調べるときは、エラーの時刻と、ずれの大きさ・向き（進みか遅れか）を記録します。
原因と確認コマンドの対応表
| 原因 | 見える症状 | Linux（chrony） | Windows（w32tm・PowerShell） |
|---|---|---|---|
| UDP 123 が通らない | Reach が 0、最終同期が古い | chronyd -Q ‘server 名前 iburst’、chronyc sources | w32tm /stripchart /computer:名前、w32tm /resync |
| 名前解決の失敗 | 参照先が名前のまま | chronyc sources -a、getent ahosts 名前 | イベント 134、Resolve-DnsName 名前 |
| 相手が非同期（stratum 16） | 応答はあるが ^? のまま | chronyc ntpdata（Stratum・Leap status） | w32tm /stripchart /packetinfo |
| 時刻源が少ない・食い違う | x、Can’t synchronise: no majority | chronyc selectdata -v、journalctl -u chronyd | w32tm /query /peers、w32tm /monitor |
| 大きなずれ | slew が終わらない、直らない | chronyc tracking（System time）、chronyc makestep | w32tm /query /status /verbose（Phase Offset）、w32tm /resync |
| 二重の同期（仮想化） | 時刻がのこぎり状に揺れる | vmware-toolbox-cmd timesync status、ログの time jump detected | w32tm /query /source、VMwareToolboxCmd.exe timesync status |
| ホスト・上位のずれ | 同じホストや拠点の機器がそろってずれる | 上位で chronyc tracking | w32tm /monitor、w32tm /stripchart で上位を順にたどる |
| Kerberos の時刻差 | 4771 の 0x25、Clock skew too great | chronyc tracking、kinit | Get-WinEvent（4771）、w32tm /stripchart /computer:DC名 |
連載の早見表
困ったときに戻る場所を、連載全体でまとめておきます。
| 回 | テーマ | 押さえること | 使う場面 |
|---|---|---|---|
| 第1回〜第2回 | 必要性、時刻の基礎 | Kerberos の5分・証明書・ログ、UTC とうるう秒（2027年5月から連続した UTC）、2036年・2038年問題 | 説明、ログの UTC 化（第11回の問2） |
| 第3回 | NTP の仕組み | stratum（16 は非同期）、4つのタイムスタンプ、root delay と root dispersion、slew と step | 状態の読み方（問3・問4） |
| 第4回 | Linux（chrony） | chrony.conf、chronyc tracking・sources、makestep | すべての調査 |
| 第5回 | Windows | ドメイン階層と PDC エミュレーター、w32tm /query、高精度の条件 | AD の設計（問1・問4） |
| 第6回 | 機器・仮想基盤 | ホストとゲストの二重の同期、ESXi・vCenter、複合機 | 仮想マシン（問3） |
| 第7回 | 設計と推奨構成 | 独立した時刻源4つ以上、社内 NTP の階層、クラウドの時刻とリープスメア | 階層の設計（問1・問2） |
| 第8回〜第9回 | セキュリティ、PTP | 公開の制限と NTS、PTP と PTP ハードウェアクロック | 公開サーバー、高精度（問4） |
| 第10回 | トラブルシュート | 届くか → 使われるか → 誰が時計を動かしたか | 障害対応（問3） |
どの回も、「この機器の時計を、誰が、どの時刻源に合わせて動かしているか」を意識すると理解しやすくなります。
振り返りと持ち帰り
- 時刻はUTCを基準に、独立した4つ以上の時刻源から、1本の階層でそろえる。外部は社内NTPだけが参照し、リープスメアの有無を混ぜず、ログはUTCで記録する
- 時計を動かす仕組みは1台に1つ。chrony・w32timeと仮想化のツールによる二重の同期を避け、大きなずれのstepは業務への影響を考えて行う
- 同期の状態は数値で読み、監視して示す。
chronyc tracking・sources（Windowsはw32tm /query /status・/stripchart）で、届くか → 使われるか → 誰が時計を動かしたかの順に確かめる
参考資料
- RFC：5905（NTPv4）、7822（拡張フィールド）、8573（MAC認証）、8633（ベストプラクティス、BCP 223）、8915（NTS）、9109（ポートのランダム化）、9523（Khronos）、9769（インターリーブモード）、4120（Kerberos）、6238（TOTP）、5424（syslog）、3339（日時の書式）
- 時刻の機関：NICT 日本標準時グループ「公開NTP」、IERS Bulletin C（うるう秒の発表）、BIPM 第27回CGPM（2022年）決議4、NTP Pool Project
- 公式ドキュメント：chronyのドキュメント（chrony-project.org）、Red Hat・Ubuntuの時刻同期の手引き、Microsoft Learn（Windows Time サービスのツールと設定、高精度時刻のサポート範囲）、Amazon EC2 ユーザーガイド（精密な時刻とAmazon Time Sync Service）、Broadcom TechDocs（ESXiの時刻の構成、VMware Toolsの時刻同期）、IEEE 1588-2019
考えてみよう
- 「このサーバーだけ時刻が2分ずれている」と言われました。最初の3つのコマンドは何ですか。Linuxの場合とWindowsの場合で答えてください。
chronyc sourcesで、ある時刻源がReach 377なのに^?のままです。何が考えられ、次に何を確かめますか。- 本番のDBサーバーの時刻が3分進んでいました。今すぐ直すか、slewで直すか、何を材料に決めますか。
ヒント：この記事の切り分けの表と図、「時刻源が使われない」の表とchronyc ntpdata、大きなずれの直し方の表が手がかりです。まずは自分のサーバーでchronyc sources -v（Windowsはw32tm /query /status）を実行し、どの時刻源に合わせているかを確かめてみてください。
まとめ
- 切り分けは症状を固める → 同期しているか → 時刻源は使われているか → 届くか → 誰が時計を動かしたか。比べるときはUTCで
- UDPは
Test-NetConnectionで試せない。chronyd -Qとw32tm /stripchartで届くかを見る ^?でも応答はあることがある（相手がstratum 16）。xは多数決で除かれた時刻源- 大きなずれはstepかslewかを決めてから直す。
/resync /forceは公式の構文にない - 仮想マシンは二重の同期・復元・再開で時刻が飛ぶ。ホストの時刻も監視する
- Kerberosは相手（DC）とのずれで判定される。エラーの時刻と、ずれの向きを記録する
次回はいよいよ最終回。これまでの知識を使って、時刻同期の階層・ログ・障害・精度を要件から決める設計演習に取り組みます。
連載「NTP入門」全11回
全回の目次と、読む順番・目的別の読み方は、NTP入門の入口のページにまとめています。
- なぜ時刻同期が必要か
- 時刻の基礎知識
- NTPの仕組み
- Linuxの時刻同期（chrony）
- Windowsの時刻同期
- ネットワーク機器・仮想基盤
- 設計と推奨構成
- NTPのセキュリティ
- PTPと高精度同期
- 時刻同期のトラブルシュート（この記事）
- 時刻同期の設計演習
コメント