「サーバーはOSの既定のpool、ネットワーク機器は昔からの公開NTP、PDCはtime.windows.com……参照先がばらばらです」
「オンプレとAWSのログを並べると、ごくまれに時刻が合わないことがあるそうです」
ここまでの回で、LinuxやWindows、機器ごとの設定を見てきました。でも機器ごとにばらばらに設定していると、全体としての時刻はそろいません。
第7回では、社内の時刻同期の階層をどう設計するかを扱います。台数、公開NTPサーバーの選び方、GNSS、クラウドの時刻、そしてうるう秒の「スメア」を混ぜない設計まで、第1回〜第6回の知識をつなげます。
社内の時刻同期の階層設計
社内の時刻同期は、3つの層に分けて設計すると整理できます。
- 外部の時刻源：NICTなどの公開NTPサーバー、GNSS受信機付きのアプライアンス、クラウドの時刻サービス
- 社内のNTPサーバー：2〜4台を置き、種類の異なる外部の時刻源を複数参照して、社内に時刻を配る
- サーバー・ネットワーク機器・端末：原則として社内のNTPサーバーだけを参照させ、インターネットへは直接出さない
こうすると、外部への通信（UDP 123）を社内のNTPサーバーに絞れ、外部に問題が起きても社内の時刻はそろったままです。ADのドメインでは、フォレストルートのPDCエミュレーターが社内のNTPサーバーを参照し、ほかのDCとドメインのメンバーはドメインの階層に従って時刻を受け取ります（第5回、連載「Active Directory入門」）。
ポイント
外と話すのは中段（社内のNTPサーバー）だけ。下段の機器は、社内の時刻しか見ない。
参照先の割り当て
| 対象 | 参照先 | 設定の手段 | 注意点 |
|---|---|---|---|
| 社内の NTP サーバー | 種類の異なる外部の時刻源を4つ以上 | chrony.conf の server・pool | 同じ組織・同じ方式の時刻源に偏らせない |
| PDC エミュレーター（フォレストルート） | 社内の NTP サーバー | w32tm /config または GPO | 役割を移したら、新旧両方の設定を見直す |
| ほかの DC・ドメインのメンバー | ドメインの階層（NT5DS） | 既定のまま | 手動で外部を指定しない（Kerberos のずれの原因） |
| Linux サーバー | 社内の NTP サーバー全台 | chrony.conf の server | 仮想マシンはゲストのツールとの二重の同期に注意（第4回） |
| ネットワーク機器・アプライアンス | 社内の NTP サーバー2台以上 | 各機器の NTP 設定 | IP で指定したら、変更時に直す機器の一覧を持つ |
| 仮想基盤（ESXi・vCenter） | 社内の NTP サーバー | 第6回 | ホストと仮想マシンの関係は第6回 |
| ドメイン外の端末 | 社内の NTP サーバー | MDM・構成プロファイル等 | Windows の既定は time.windows.com |
冒頭の「参照先がばらばら」は、この表に沿って1つずつ社内のNTPサーバーへ寄せていくのが近道です。
台数と冗長：1台・2台では足りない理由
- NTPのクライアントは、複数の時刻源の答えを比べ、ほかと食い違うもの（falseticker）を外して時刻を決める（第3回）
- 1台だと誤った時刻に気づけず、2台だと食い違いには気づけてもどちらが正しいか決められない。3台あれば多数決で1台の誤りを外せるが、1台が止まった瞬間に2台と同じ状態に戻る
- そのためRFC 8633（BCP 223）は、正確な時刻が必要なら、独立した種類の異なる時刻源を4つ以上使うよう勧めている
信頼できる機関でも誤ることはあります。2026年9月9日には、NICTの公開NTPで、冗長系の一部から10分あまり、誤った時刻が配信されたとNICTが公表しています。1つの時刻源に頼らないことが、設計の基本です。
社内のNTPサーバーの構成例
- 台数と置き場所：拠点・データセンターを分けて2〜4台。クライアントには全台を参照させる。1台の停止と1台の誤りの両方に耐えるなら4台
- 外部の参照先：各サーバーが、種類の異なる外部の時刻源を4つ以上参照する（例：GNSSアプライアンス＋NICT＋pool）。
minsourcesで、1つの時刻源だけでは時計を動かさないようにする - 外部と切れたとき：
local stratum 10 orphanを全台に書き、互いを参照させる。外部を失っても社内のNTPサーバー同士が同じ時刻にそろい、クライアントがばらばらにならない
# /etc/chrony.conf（社内の NTP サーバー ntp1 の例）
server gnss1.corp.example.jp iburst prefer
server ntp.nict.jp iburst
pool jp.pool.ntp.org iburst maxsources 2
server ntp2.corp.example.jp iburst
server ntp3.corp.example.jp iburst
minsources 2
local stratum 10 orphan
allow 192.0.2.0/24
allow 2001:db8:10::/48
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony
log tracking measurements statistics第4回で「localは隔離環境だけ」と書きましたが、社内のNTPサーバー全台にorphan付きで書き、互いを参照させる構成は例外です。外部を失ったときに、社内のNTPサーバーがばらばらの時刻を配らないための設定です。
公開NTPサーバーの選び方
| 時刻源 | 運用者・特徴 | うるう秒 | NTS |
|---|---|---|---|
| ntp.nict.jp | NICT（日本標準時）。stratum 1。小金井と神戸。IPv6 対応 | 挿入（スメアしない） | 公式の案内なし |
| jp.pool.ntp.org | ボランティアのサーバー群。日本のゾーンは約50台。保証なし | スメアしない | 未対応 |
| time.google.com | Google の公開 NTP | 24時間のスメア | 未対応（FAQ に明記） |
| time.cloudflare.com | Cloudflare。エニーキャスト | スメアしない | 対応 |
| time.aws.com | AWS の公開エンドポイント | スメア | 記載なし |
| time.windows.com | Microsoft。Windows の既定 | 記載なし（Windows 自体はスメアしない方針） | 記載なし |
| time.apple.com | Apple。Apple 製品の既定 | 公式の記載なし | 記載なし |
| nts.netnod.se | Netnod（スウェーデン）。stratum 1 | 記載なし | 対応 |
スメア（この後で説明）するものとしないものを、1台のクライアントや1台の社内のNTPサーバーで混ぜないのが原則です。社内のNTPサーバーの外部の参照先は、NICT・GNSS・poolなどスメアしないものでそろえるのが基本です。
公開NTPサーバーを使うときの注意
- NICT：申請は不要で無料。問い合わせは1時間平均20回（1日480回）以内。社内に配るstratum 2のサーバーから短い間隔で参照するなど、これを超える場合は事前に連絡する。IPアドレスではなくホスト名
ntp.nict.jpで指定する（自社の名前で使うならCNAME） - pool.ntp.org：ボランティアの運用で保証はない。業務や人命が正しい時刻に依存するなら、インターネットから取るだけにしないよう公式に明記されている。参照は4台まで、社内ではNTPサーバーにまとめて取る。製品に組み込むならベンダーゾーンを申請する
- 福岡大学（clock.nc.fukuoka-u.ac.jp）：長年の過負荷のため停止の方針を公表しており、2019年3月に1台（133.100.11.8）を停止した。ホスト名は現在名前解決できない。古い機器やソフトに設定が残っていたら外す（IPアドレスの直書きも探す）
- 各社の公開サーバー：無料だがSLAはないものが多い。リープスメアの有無が違うので混ぜない
社内から外へ出るNTPは社内のNTPサーバーだけにし、ファイアウォールで宛先を絞ります。ログでUDP 123の宛先を集計すると、直接外へ出ている機器が分かります。
GNSS受信機付きのアプライアンス
stratum 1の時刻源を社内に置く方法が、GNSS（GPS・みちびき等の衛星測位システム）の受信機を内蔵したNTPアプライアンスです。
- 屋上のアンテナで衛星の電波を受け、時刻と1PPS信号で自分の時計を合わせ、社内にNTP（機種によってはPTPも）で配る
- インターネットに依存しないため、閉じたネットワークや、監査で時刻の出どころ（トレーサビリティ）を示す必要がある場合に向く
- 一方で、アンテナの設置と配線、妨害電波（ジャミング）や偽の信号（スプーフィング）、受信機のソフトの不具合（2019年のGPSの週番号のロールオーバー等）という固有の弱点がある
- 衛星を受けられない間は、内蔵の発振器（OCXOやルビジウム）で時刻を保つ（ホールドオーバー）ため、その性能も選定の要素
衛星が主、ネットの時刻源は見張り役です。弱点の違う時刻源を組み合わせ、互いに監視させます。
クラウドの時刻
AWS
- Amazon Time Sync Service：全インスタンスから
169.254.169.123（IPv6はfd00:ec2::123、Nitroのみ）で使える。リンクローカルなので経路の設定は不要。AL2023とWindowsのAMIは既定で参照する（連載「クラウド入門」第7回・第14回）。うるう秒はスメアして配る。オンプレなど外からはtime.aws.com（同じくスメア） - PTPハードウェアクロック（PHC）：第7世代以降の対応インスタンスを
precision-timeのプレイスメントグループで起動すると、NTPの精度が上がり、LinuxではENAドライバー（2.10.0以降）経由でPHC（/dev/ptp_ena）を時刻源にできる。PHCはスメアしない - リンクローカルのサービス（DNS・メタデータ・NTP等の合計）は、毎秒1024パケットが上限
# Linux（/etc/chrony.conf）
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4
refclock PHC /dev/ptp_ena poll 0 delay 0.000010 prefer # PHC を使えるときだけ
# Windows（管理者の PowerShell）
w32tm /config /manualpeerlist:169.254.169.123 /syncfromflags:manual /update
w32tm /query /sourceAWSは、うるう秒の間は、スメアするNTPとスメアしないPHCを併用しないよう勧めています。平常時は同じ時刻なので問題ありませんが、うるう秒の告知が出たら、どちらかに寄せます。
Azure・Google Cloud
| 項目 | Azure | Google Cloud |
|---|---|---|
| 時刻の出どころ | ホスト。Microsoft 所有の GPS 付き Stratum 1 に同期 | メタデータサーバーの NTP（metadata.google.internal、169.254.169.254） |
| Linux | VMICTimeSync がホストの時計を PHC（/dev/ptp_hyperv）として見せる。新しいイメージは chrony の refclock PHC /dev/ptp_hyperv poll 3 dpoll -2 offset 0 stratum 2 が既定 | chrony に server metadata.google.internal iburst だけを書く |
| Windows | 既定はホストの時刻（VMICTimeProvider）と time.windows.com の併用。ホストだけにもできる | metadata.google.internal だけを参照 |
| うるう秒 | 公式の記載なし | 24時間のスメア。外部の NTP と混ぜないよう明記 |
| 注意点 | 保守で最大30秒止まると、VMICTimeSync が時刻を補正する。AD の DC は PDC だけ外部を参照し、VMICTimeProvider を無効にする手順が公開 | 外部の NTP を併用すると時刻が予測できない動きをする |
クラウドの「PTPハードウェアクロック」は、ホストの正確な時計を仮想マシンにPHCとして見せる仕組みで、利用者のネットワークにPTPのパケットが流れるわけではありません（PTPは第9回）。
リープスメア
冒頭の「オンプレとAWSのログが、ごくまれに合わない」の原因になりうるのが、リープスメアです。
- うるう秒の1秒を一度に挿入せず、前後の長い時間に薄く広げて、時計を少しずつ遅らせる方法
- Googleは、うるう秒の前日の正午から翌日の正午（UTC）までの24時間にわたって直線的にならし、この間の1秒は通常より約11.6マイクロ秒長くなる（約11.6ppm）。AWSのAmazon Time Sync ServiceやGoogle Cloudも、スメアした時刻を配る
- 利点：23:59:60という時刻や時計の巻き戻しが起きず、うるう秒に弱いソフトウェアの障害を避けられる
- 欠点：スメアの間はUTCから最大0.5秒ずれること、スメアしないサーバーと答えが食い違うこと
うるう秒は2017年1月が最後で、IERSは2026年12月末も挿入しないと発表しています。2027年5月20日からは連続したUTCに移ることが、2026年10月の第28回CGPMで決まりました（第2回）。
スメアを混ぜない設計
| 構成 | 何が起きるか | 対策 |
|---|---|---|
| 1台のクライアントがスメアありとなしを両方参照 | うるう秒の前後で時刻源が2群に割れ、正しいものを選べない（2015年に実際に発生、RFC 8633） | 1台の参照先はどちらかにそろえる |
| 社内の NTP サーバーが Google と NICT を混ぜて参照 | 同上。社内全体に波及する | 外部の参照先の方針を決めて統一する |
| EC2 で NTP（スメア）と PHC（スメアなし）を併用 | うるう秒の間だけ食い違う | AWS はうるう秒の間の併用を勧めない |
| オンプレ（スメアなし）と AWS（スメア）のログを突き合わせ | うるう秒の前後で最大0.5秒ずれる | 要件を確認。必要ならオンプレも time.aws.com にそろえる |
| スメアした時刻を公開サーバーとして外部に配る | 受け手がスメアと気づけない | RFC 8633 は公開サーバーでのスメアを禁止（MUST NOT） |
平常時は、スメアの有無に関係なく同じ時刻です。うるう秒はIERSのBulletin Cで約半年前に告知されるので、告知が出たら、自社の時刻源ごとのスメアの有無の一覧（公開NTPサーバーの表）を確認します。第11回の演習（問2）でも扱います。
運用と監視
- 閾値：要件から決める。例：一般のサーバーは100msで警告、1秒で重大（Kerberosの許容5分より十分小さく）。監査の要件があればそれに合わせる
- 見る項目：ずれ（
chronyc trackingのSystem time）、同期の状態（Leap statusがNot synchronised、stratum 16）、到達性（chronyc sourcesのReach）、使える時刻源の数 - ログ：chronyは
log tracking measurements statisticsとlogchange 0.1（0.1秒を超える補正をsyslogに出す）。syslogサーバーへ集約する - Windows：
w32tm /stripchartで相手とのずれを測る。イベントログ「Time-Service/Operational」の257〜266（時刻の変更、時刻源の変更、再同期の要求など）を証跡として保管する - 証跡：構成図・設定・ずれの記録を残し、「いつ、どの時刻源に、どの精度で合っていたか」を示せるようにする（規制は第1回）
$ chronyc tracking | grep -E 'System time|Leap status'
System time : 0.000567769 seconds slow of NTP time
Leap status : Normal
PS> w32tm /stripchart /computer:ntp1.corp.example.jp /dataonly /samples:3
PS> Get-WinEvent -LogName Microsoft-Windows-Time-Service/Operational -MaxEvents 10考えてみよう
- 自社のNTPサーバーは何台で、それぞれ何を参照していますか。1台が誤った時刻を返したら、クライアントは気づけますか。
- 社内の機器や古いソフトに、
clock.nc.fukuoka-u.ac.jpやIPアドレスで直書きした外部のNTPサーバーが残っていないか、どう洗い出しますか。 - オンプレとAWSの両方にシステムがあるとき、うるう秒の告知が出たら何を確認しますか。
ヒント：この記事の台数の図、公開NTPサーバーの表と注意、スメアを混ぜない設計の表が手がかりです。参照先はLinuxではchronyc sources、Windowsではw32tm /query /peersで確認し、ファイアウォールのログで外へ出るUDP 123の宛先を集計します。
まとめ
- 社内の時刻同期は外部の時刻源 → 社内のNTPサーバー → 機器・端末の3層で考える
- 外へ出るUDP 123は社内のNTPサーバーだけ。ADはPDCエミュレーターだけが社内のNTPを見る
- 時刻源は種類の異なるものを4つ以上。1台・2台では誤りを見抜けない
- 社内のNTPサーバーは全台に
local stratum 10 orphanで、外部を失ってもそろえる - 公開NTPは利用条件を守り、停止方針の福岡大学などの古い設定を外す
- GNSSは弱点の違う時刻源と併用し、ホールドオーバーの性能を確かめる
- スメアあり（Google・AWS）となし（NICT）を混ぜない。うるう秒の告知が出たら一覧を確認
次回は、時刻同期そのものが攻撃されるとどうなるか、どう守るかを扱います。
連載「NTP入門」全11回
全回の目次と、読む順番・目的別の読み方は、NTP入門の入口のページにまとめています。
- なぜ時刻同期が必要か
- 時刻の基礎知識
- NTPの仕組み
- Linuxの時刻同期（chrony）
- Windowsの時刻同期
- ネットワーク機器・仮想基盤
- 設計と推奨構成（この記事）
- NTPのセキュリティ
- PTPと高精度同期
- 時刻同期のトラブルシュート
- 時刻同期の設計演習
コメント