NTPとは｜時刻同期の仕組みとストラタム・公開NTPサーバーを実測で解説

NTPのやり取りは、たった1往復です。クライアントが「送った時刻」を入れて問い合わせ、サーバーが「受け取った時刻」と「返した時刻」を入れて返します。クライアントは「受け取った時刻」を足した4つの時刻から、自分の時計がどれだけずれているかを計算します。

sequenceDiagram
    participant C as クライアント
    participant S as サーバー
    Note over C: T1 送信
    C->>S: 要求 UDP 123
    Note over S: T2 受信
    Note over S: T3 送信
    S->>C: 応答 T1・T2・T3
    Note over C: T4 受信

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（カーネル 6.18）の上で、chrony 4.5（Ubuntu の 4.5-1ubuntu4.2）・ntpsec 1.2.2（ntpd・ntpq・ntpdig）・tcpdump 4.99.4・libfaketime 0.9.10 の .deb を作業用のフォルダーに展開して使いました（apt でのインストールはしていません）。ip netns でサーバー役とクライアント役の2つのネットワーク名前空間を作り、veth（10.193.0.1 と 10.193.0.2）でつないで、その中だけで NTP を話させています。ホストの時計は一切変えていません。chronyd は時計を操作しない -x モード、ntpd は disable ntp と disable kernel で起動し、さらにどちらも setpriv で時刻を変える権限（CAP_SYS_TIME）を外しています（ntpd のログには ntp_adjtime: Operation not permitted と出ました）。時計のずれは libfaketime で「そのプロセスにだけ見える偽の時刻」を作り、ずれが縮む様子は Python 3.13.18 で書いた仮想の時計で確かめました。外部のNTPサーバーには接続していません。Windows・Mac の手順は Microsoft・Apple の公式ページ、公開NTPサーバーは NICT・pool.ntp.org・インターネットマルチフィードの公式ページ、仕様は RFC 5905・RFC 8915 で確かめ、図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

NTPとは（意味と、ふだんの時刻合わせとの違い）

この節では、NTPという言葉の意味と、電波時計や時報のような身近な時刻合わせと何が違うのかが分かります。

NTPは「Network Time Protocol（ネットワーク・タイム・プロトコル）」の略で、コンピューターの時計をネットワーク経由で合わせるための約束ごと（プロトコル）です。今の版は NTP version 4 で、RFC 5905 に定められています。パソコン・スマホ・サーバー・ルーターの多くが、電源を入れている間ずっと NTP で時計を合わせ続けています。

コンピューターの時計は、水晶の振動を数えて時間を進めています。水晶の振動の速さは個体差や温度で少しずつ違うため、放っておくと1日に数秒ずれることもあります。たとえば「100万分の100（100ppm）速い」時計は、1日で8.64秒、30日で約4分進みます。この「ずれ続ける」性質を、ネットワーク越しに直し続けるのが NTP の役目です。

ふだんの時刻合わせと NTP の違い

NTPのいちばんの特徴は、「問い合わせて返ってくるまでの時間」を毎回測り、その分を計算で差し引く点です。インターネットでは数ミリ秒から数百ミリ秒の遅れが毎回変わるため、届いた時刻をそのまま使うと、その遅れの分だけずれます。

「NTP」が指すもの（場面別の意味）

「NTP」という言葉は、話す場面によって指しているものが少し違います。

NTPの仕組み（4つの時刻でずれと遅延を計算する）

この節では、NTPが4つの時刻からどうやって「時計のずれ」と「往復遅延」を求めるのかが、実際の数字で分かります。

NTPは、1回の問い合わせで T1〜T4 の4つの時刻を集めます。T1 と T4 はクライアントの時計、T2 と T3 はサーバーの時計で測った時刻です。

ここから、次の2つを計算します（RFC 5905 の式です）。

• オフセット（時計のずれ）：θ = ((T2 − T1) + (T3 − T4)) / 2。サーバーの時計から見て、クライアントの時計がどれだけ遅れているか（マイナスなら進んでいる）。
• 往復遅延：δ = (T4 − T1) − (T3 − T2)。往復にかかった時間から、サーバーの中で処理していた時間を引いたもの。

数字で計算してみる

クライアントの時計が3秒進んでいて、行きも帰りも10ミリ秒かかり、サーバーの処理に1ミリ秒かかったとします（サーバーの正しい時刻で 12:00:00.000 に送ったとする）。

θ ＝ ((0.010 − 3.000) + (0.011 − 3.021)) ÷ 2 ＝ −3.000秒、δ ＝ (3.021 − 3.000) − (0.011 − 0.010) ＝ 0.020秒です。クライアントの時計が3秒進んでいることと、往復に20ミリ秒かかったことが、正しく出てきます。

この式は「行きと帰りにかかる時間が同じ」という前提で成り立っています。行きと帰りの時間が違うと、その差の半分がそのままオフセットの誤差になります。これは後の「NTPの精度の限界」の節で実測します。

ストラタムとは（NTPサーバーの階層）

この節では、NTPサーバーの「ストラタム」という番号の意味と、数字の大小が何を表すのかが分かります。

ストラタム（stratum）は、基準となる時計から何段離れているかを表す番号です。原子時計や GPS 受信機のような基準の時計そのものを0とし、それに直接つながったサーバーが1、そのサーバーから時刻をもらうサーバーが2、と1段ごとに増えます。

1. 0基準の時計（原子時計・GPS・標準電波）ネットワークには直接出ない。NTPの応答でストラタム0は「不明・無効」の意味になる
2. 1基準の時計に直結したNTPサーバーNICT の ntp.nict.jp は日本標準時を基準とするストラタム1（NICT の公式 Q&A）
3. 2ストラタム1から時刻をもらうサーバー社内のNTPサーバー・公開サーバーの多く。手元の実験のサーバー役も2
4. 3ストラタム2から時刻をもらう機器社内サーバーから合わせるパソコンなど。手元のクライアント役は同期後に3になった
5. 15同期に使える最下段段が深いほど、途中の誤差が積み重なる
6. 16同期していないntpq -p で「.INIT.」と並んで出たら、まだ一度も応答を得ていない

ストラタムは「精度の順位」ではなく「段数」です。ストラタム1でも遠くて混んでいれば、近くのストラタム2より誤差が大きくなることがあります。NICT の Q&A も、ストラタム2の MFEED について「十分な時刻精度を有しています」と書いています。数字が小さいサーバーを選ぶことより、近くて安定したサーバーを複数指定することのほうが効きます。

手元の実験では、サーバー役の chrony を local stratum 2（自分の時計を基準として配る設定）で起動しました。クライアント役が同期すると、自分のストラタムは「サーバーの番号＋1」の3になりました。

$ chronyc tracking      （クライアント役）
Reference ID    : 0AC10001 (10.193.0.1)
Stratum         : 3

NTPパケットの中身（UDP 123番・48バイト）

この節では、NTPの要求と応答が実際にどんな形でネットワークを流れているのかが、tcpdump の原文で分かります。

サーバー役の名前空間で tcpdump を動かし、クライアント役の chrony の問い合わせを1往復だけ取りました。

$ tcpdump -i t193a -n -c 2 -vv udp port 123
10.193.0.2.48321 > 10.193.0.1.123: NTPv4, Client, length 48
	Leap indicator:  (0), Stratum 0 (unspecified), poll 1 (2s), precision 32
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
	  Reference Timestamp:  0.000000000
	  Originator Timestamp: 0.000000000
	  Receive Timestamp:    0.000000000
	  Transmit Timestamp:   1153621354.603797902 (1936-07-23T02:22:34Z)
10.193.0.1.123 > 10.193.0.2.48321: NTPv4, Server, length 48
	Leap indicator:  (0), Stratum 2 (secondary reference), poll 1 (2s), precision -25
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: 0x7f7f0101
	  Reference Timestamp:  4002393634.842044953 (2026-10-31T00:00:34Z)
	  Originator Timestamp: 1153621354.603797902 (1936-07-23T02:22:34Z)
	  Receive Timestamp:    4002393669.497789579 (2026-10-31T00:01:09Z)
	  Transmit Timestamp:   4002393669.497839882 (2026-10-31T00:01:09Z)

（行頭の時刻と bad udp cksum の表示は省きました。後者は veth のチェックサム計算の省略によるもので、通信の失敗ではありません。）

NTPの時刻は「秒（32ビット）」と「秒の端数（32ビット、約233ピコ秒刻み）」の64ビットです。秒の欄が一巡する2036年の問題は、Unix 時刻の2038年問題と並んで知られています。2038年問題やうるう秒の扱いなど、プログラムで日付を扱うときの注意は、関連記事「日付処理の落とし穴8選｜2038年問題・うるう秒・うるう年2100年」で扱っています。この記事は、その手前の「OSの時計そのものを正しく保つ仕組み」を扱います。

NTPが使う123番以外のよく使うポートは、関連記事「ポート番号一覧【2026年版】well-knownポートと確認コマンドの早見表」で扱っています。

NTPで時計のずれが縮む様子（ステップとスルー）

この節では、NTPがずれを見つけたあと、時計をどうやって合わせるのか（一度に合わせる・少しずつ合わせる）が、実測の表で分かります。

NTPのソフトは、ずれが大きいときは時計を一度に合わせ（ステップ）、小さいときは時計の進む速さを少し変えて徐々に合わせます（スルー、slew）。ntpsec の公式ドキュメントでは、ステップにするかどうかの境目は既定で128ミリ秒、Linux などのカーネルが時計の速さを変えられる上限は1秒あたり0.5ミリ秒（500ppm）で、「1秒のずれを直すのに2000秒かかる」と説明されています。

仮想の時計で確かめる

ホストの時計は変えないので、Python で「OSの時計を読むだけの仮想の時計」を作り、NTPの要求を自分で組み立ててサーバー役の chrony に問い合わせました。仮想の時計は3秒進んでいて、1秒ごとに問い合わせます。

# 仮想の時計を NTP で合わせる実験（OS の時計は読むだけで、書き換えない）
import socket, struct, time, sys
NTP_EPOCH = 2208988800  # 1900-01-01 から 1970-01-01 までの秒数
host, _, port = sys.argv[1].partition(':'); SERVER = (host, int(port or 123))
MODE = sys.argv[2]                 # none / slew / step / step-burst
OFF0 = float(sys.argv[3])          # 最初のずれ（秒）
DRIFT = float(sys.argv[4]) * 1e-6  # 時計の進みぐせ（ppm）
POLLS = int(sys.argv[5]); INTERVAL = float(sys.argv[6])
t0 = time.time(); corr = 0.0
def vnow():  # 仮想の時計の今の値
    el = time.time() - t0
    return time.time() + OFF0 + DRIFT * el + corr
def ts(x):
    s = int(x + NTP_EPOCH); f = int((x + NTP_EPOCH - s) * 2**32)
    return struct.pack('!II', s, f)
def un(b):
    s, f = struct.unpack('!II', b); return s - NTP_EPOCH + f / 2**32
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); sock.settimeout(2)
print('回  ずれ(ms)    往復遅延(ms)  ストラタム  処置')
for i in range(POLLS):
    def sample():
        t1 = vnow()
        sock.sendto(b'\x23' + b'\x00' * 39 + ts(t1), SERVER)  # LI=0 VN=4 Mode=3
        data, _ = sock.recvfrom(512); t4 = vnow()
        t2 = un(data[32:40]); t3 = un(data[40:48])
        return ((t2 - t1) + (t3 - t4)) / 2, (t4 - t1) - (t3 - t2), data[1]
    n = 4 if (i == 0 and 'burst' in MODE) else 1   # 最初だけ4回聞いて遅延最小を使う
    theta, delta, stratum = min((sample() for _ in range(n)), key=lambda r: r[1])
    act = '-'
    if MODE.startswith('step') and abs(theta) > 0.128:
        corr += theta; act = f'ステップ {theta:+.3f}s'
    elif MODE == 'slew' or (MODE.startswith('step') and abs(theta) <= 0.128):
        adj = max(-0.0005 * INTERVAL, min(0.0005 * INTERVAL, theta))  # 最大 500ppm
        corr += adj; act = f'スルー {adj*1000:+.3f}ms'
    print(f'{i+1:2d}  {theta*1000:+12.3f}  {delta*1000:9.3f}     {stratum:2d}        {act}')
    time.sleep(INTERVAL)

スルーだけで合わせた場合と、最初にステップした場合の結果です。

$ python3 vclock.py 10.193.0.1 slew 3 0 6 1
回  ずれ(ms)    往復遅延(ms)  ストラタム  処置
 1     -3002.487      5.058      2        スルー -0.500ms
 2     -2999.494      0.068      2        スルー -0.500ms
 3     -2998.991      0.062      2        スルー -0.500ms
 4     -2998.526      0.133      2        スルー -0.500ms
 5     -2998.003      0.087      2        スルー -0.500ms
 6     -2997.490      0.070      2        スルー -0.500ms

$ python3 vclock.py 10.193.0.1 step 3 0 6 1
回  ずれ(ms)    往復遅延(ms)  ストラタム  処置
 1     -2999.988      0.077      2        ステップ -3.000s
 2        -0.001      0.078      2        スルー -0.001ms
 3        -0.018      0.119      2        スルー -0.018ms
 4        +0.021      0.148      2        スルー +0.021ms
 5        -0.005      0.064      2        スルー -0.005ms
 6        +0.001      0.067      2        スルー +0.001ms

スルーは1秒ごとに0.5ミリ秒ずつしか縮まず、3秒のずれを直すには計算上100分ほどかかります。そのため、起動直後に大きくずれていたら一度だけステップし、あとはスルーで保つ、という動き方が一般的です。Ubuntu の chrony の設定ファイル（パッケージに入っている雛形）には makestep 1 3 があり、「最初の3回の更新までに1秒より大きくずれていたらステップする」という意味です。なお chrony は、ntpd より速くスルーできます（公式ドキュメントでは、スルーの速さの上限 maxslewrate の既定は 83333.333ppm＝12分の1）。

1回目の測定が外れることがある

スルーの1回目は往復遅延が5.058ミリ秒と大きく、ずれも −3002.487ms と2.5ミリ秒ほど外れていました。遅延が大きい回の測定は、その分だけ誤差が大きくなります。そこで、最初だけ4回問い合わせて往復遅延が最も小さい回を使う形（chrony・ntpd の iburst に近い考え方）にし、時計の進みぐせ（100ppm）も加えて試しました。

$ python3 vclock.py 10.193.0.1 step-burst 3 100 8 2
回  ずれ(ms)    往復遅延(ms)  ストラタム  処置
 1     -3000.002      0.010      2        ステップ -3.000s
 2        -0.184      0.085      2        スルー -0.184ms
 3        -0.207      0.058      2        スルー -0.207ms
 4        -2.211      4.079      2        スルー -1.000ms
 5        +0.589      0.080      2        スルー +0.589ms
 6        -0.190      0.051      2        スルー -0.190ms
 7        -0.196      0.068      2        スルー -0.196ms
 8        -0.221      0.086      2        スルー -0.221ms

• 4回目だけ往復遅延が4.079ミリ秒に跳ね、ずれも −2.211ms と外れました。1回の測定をそのまま信じると、時計をかえって狂わせます。chrony や ntpd は、複数の測定から遅延の小さいものを選ぶ「フィルター」でこれを避けています。
• 100ppm 速い時計は、2秒ごとに約0.2ミリ秒ずつ進みました。この仮想の時計は「速さ」を直していないので、毎回0.2ミリ秒前後のずれが残ります。本物のソフトは次の節のように、時計の速さのくせ（周波数）も推定して直します。

chronyの出力の読み方（sources・tracking）

この節では、Linux で多く使われている chrony の chronyc sources・chronyc tracking の出力の読み方が、実物で分かります。

クライアント役の chrony を、libfaketime で「3秒進み、しかも100ppm速く進む」偽の時計を見せた状態で、時計を操作しない -x モードで起動しました。chrony の公式ドキュメントによると、-x は「時計を一切調整しないが、ずれと周波数は推定し続ける」モードです。

# クライアント役の chrony.conf（作業フォルダーの中）
server 10.193.0.1 iburst minpoll 1 maxpoll 2
bindcmdaddress /srv/s4/r17/t193/w/cli/chronyd.sock
pidfile /srv/s4/r17/t193/w/cli/chronyd.pid
driftfile /srv/s4/r17/t193/w/cli/drift
logdir /srv/s4/r17/t193/w/cli/log
log measurements statistics tracking

$ FAKETIME="+3 x1.0001" LD_PRELOAD=.../libfaketime.so.1 \
  setpriv --bounding-set -sys_time chronyd -x -f chrony.conf

起動して1秒後のログです。

2026-10-31T00:00:46Z Disabled control of system clock
2026-10-31T00:00:47Z Selected source 10.193.0.1
2026-10-31T00:00:47Z System clock wrong by -3.000147 seconds

「System clock wrong by -3.000147 seconds」が、chrony が見つけたずれです。ふつうのモードならここでステップしますが、-x なので何もしません。12秒後の chronyc sources -v は次のとおりでした。

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.193.0.1                    2   1   377     0  +1969ns[+3473ns] +/-   12us

続けて chronyc tracking です。3分ほどたった時点の値も並べます。

Reference ID    : 0AC10001 (10.193.0.1)
Stratum         : 3
Ref time (UTC)  : Sat Oct 31 00:00:54 2026
System time     : 3.001200676 seconds fast of NTP time
Last offset     : +0.000001504 seconds
RMS offset      : 0.000032006 seconds
Frequency       : 97.095 ppm fast
Residual freq   : -0.031 ppm
Skew            : 4.082 ppm
Root delay      : 0.000023729 seconds
Root dispersion : 0.000007007 seconds
Update interval : 2.0 seconds
Leap status     : Normal

偽の時計に仕込んだ「100ppm 速い」を、chrony は3分ほどで 100.003ppm と推定しました。時計を直していないので System time は3.0012秒から3.0168秒へ増えていて、その増え方（約156秒で15.6ミリ秒）も100ppm と一致します。ふつうのモードの chrony は、この推定した周波数で時計の速さそのものを直すので、ずれが再び広がりにくくなります。推定した周波数は driftfile に保存され、次に起動したときの出発点になります。

ntpq -pの読み方（ntpsec・ntpd）

この節では、ntpd（ntpsec）の ntpq -p の各列の意味と、offset・jitter・reach の読み方が分かります。

ntpsec の ntpd をクライアント役の名前空間で、時計を動かさない設定で起動しました。

# ntpsec のクライアント役（時計は動かさない）
server 10.193.0.1 iburst minpoll 3 maxpoll 4
disable ntp
disable kernel
driftfile /srv/s4/r17/t193/w/ntpsec/drift
statsdir /srv/s4/r17/t193/w/ntpsec/
statistics peerstats loopstats
filegen peerstats file peerstats type none enable
filegen loopstats file loopstats type none enable
restrict default kod limited nomodify noquery
restrict 127.0.0.1

起動直後と、約1分後（8回の応答が集まったあと）の ntpq -p です。

$ ntpq -p 127.0.0.1      （起動直後）
     remote           refid      st t when poll reach   delay   offset   jitter
===============================================================================
 10.193.0.1      .INIT.          16 u    -    8    0   0.0000   0.0000   0.0001

$ ntpq -p 127.0.0.1      （約1分後）
     remote           refid      st t when poll reach   delay   offset   jitter
===============================================================================
*10.193.0.1      127.127.1.1      2 u    2    8  377   0.0280   0.0084   0.0033

ntpq -p の delay・offset・jitter の単位はミリ秒です。chronyc の出力（ns・us・秒が混在）と単位が違うので、比べるときは注意が要ります。起動直後は st が16、refid が .INIT.、reach が0で、「まだ一度も応答を得ていない」状態でした。

サーバーの時計を2.5秒遅らせると

次に、サーバー役の chrony に libfaketime で「2.5秒遅れた時計」を見せて起動し直しました。

$ ntpq -p 127.0.0.1      （直後）
 10.193.0.1      127.127.1.1      2 u    -    8  377   0.0622 -2499.98 2314.535

$ ntpq -p 127.0.0.1      （約1分後）
*10.193.0.1      127.127.1.1      2 u    1    8  377   0.0622 -2499.98   2.9876

直後は jitter が2314ミリ秒に跳ね、先頭の記号が消えて（不使用）同期の相手から外れました。測定値が急に2.5秒変わったため、「ばらつきが大きい相手」と判断されたためです。約1分後、2.5秒のずれのままの測定がそろうと jitter は2.9876まで下がり、* が戻りました。統計ファイル（peerstats）の最後の3行は次のとおりで、ずれ（4列目、秒）が −2.4999 秒で安定していく様子が分かります。

61344 493.684 10.193.0.1 b01a -2.499979922 0.000053101 0.000115900 1.336299868
61344 501.709 10.193.0.1 b62a -2.492072111 0.015896371 0.000116019 0.941946200
61344 509.683 10.193.0.1 b62a -2.499976490 0.000062158 0.000115960 0.002987575

なお、ntpq -c rv では leap=11（同期していない）のままでした。disable ntp で自分の時計を合わせないため、ntpd は自分を「同期済み」と名乗りません。ふつうに動かしている ntpd で leap=11 が続くなら、まだ同期できていないという意味です。

NTPの精度の限界（往復遅延と非対称な経路）

この節では、NTPでどこまで正確に合わせられるのかと、行きと帰りの時間が違うときに生まれる誤差が、実測で分かります。

行きと帰りに別々の遅延を入れる UDP の中継プログラムをサーバー役の名前空間で動かし、仮想の時計（ずれ0）から中継経由で問い合わせました（tc の netem はこの環境のカーネルで使えなかったため、中継で代わりにしています）。

# 行きと帰りで別々の遅延を入れる UDP 中継（tc netem の代わり）
import socket, sys, time
out_d, back_d = float(sys.argv[1]) / 1000, float(sys.argv[2]) / 1000
up = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); up.bind(('10.193.0.1', 1123))
srv = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); srv.connect(('127.0.0.1', 123))
while True:
    data, cli = up.recvfrom(512)
    time.sleep(out_d); srv.send(data)          # 行き（クライアント→サーバー）
    reply = srv.recv(512)
    time.sleep(back_d); up.sendto(reply, cli)  # 帰り（サーバー→クライアント）

時計は1ミリ秒もずれていないのに、行きだけ20ミリ秒遅いと「10ミリ秒遅れている」、40ミリ秒遅いと「20ミリ秒遅れている」と測りました。NTPの式は行きと帰りが同じ時間という前提なので、片寄りの半分がそのまま誤差になります。往復が同じ10ミリ秒ずつなら、往復20ミリ秒でも誤差はほぼ0でした。

• 誤差の上限は「往復遅延の半分」です。往復が20ミリ秒の経路なら、最悪で10ミリ秒ずれる可能性があります。chrony の +/- や ntpd の root distance は、この考え方で誤差を見積もっています。
• 近いサーバーほど誤差の上限が小さくなります。NICT の公開ページも、利用者の時刻精度は「数ミリ秒から数百ミリ秒位まで大きく変化する場合があります」と書いています。
• マイクロ秒より細かい精度が要る用途（金融の取引記録・放送・通信設備など）では、機器の中で時刻を記録する PTP（IEEE 1588）が使われます。

公開NTPサーバー一覧（NICT・MFEED・pool.ntp.org）

この節では、誰でも使える公開NTPサーバーと、使うときの決まりごとが分かります。

公開サーバーは「善意で配られている時刻」です。NICT の Q&A は、問い合わせの間隔について「1時間平均で20回(1日の合計が480回)を超えないように」と書き、ntpd の設定例として16秒間隔（minpoll 4 maxpoll 4）を示しています。また、NTP version 1 には対応していないと案内しています。

• 1IP アドレスではなく名前で指定する運営側がサーバーを入れ替えたり振り分けたりできるように。NICT も ntp.nict.jp での登録を求めている
• 23〜4つのサーバーを指定する1つだけだと、その相手が狂ったときに気づけない。多数決で外れ値を除ける
• 3社内の機器はまず社内のNTPサーバーに向ける社内に1〜2台の NTP サーバーを置き、外の公開サーバーに問い合わせるのはその台数だけにする
• 4製品に公開サーバーの名前を焼き込まない大量に出荷する機器は、pool.ntp.org の「ベンダ向け情報」の手続きに従う

判断表：どのNTPサーバーを使うか

NTPの設定方法（Windows・Mac・Linux）

この節では、Windows・Mac・Linux で NTP による時刻同期を確かめる方法と、同期先を変える方法が分かります。

Windows

Microsoft のサポートページの手順です（Windows 11 の画面の表記）。

Microsoft Learn の「Windows タイム サービスのツールと設定」に載っている w32tm のコマンドです。

w32tm /query /status        時刻同期の状態を表示する（/verbose で詳しく）
w32tm /query /source        今の時刻源を表示する
w32tm /query /peers         ピア（同期先）とその状態の一覧
w32tm /resync               ためた統計を捨てて、すぐに再同期する
w32tm /stripchart /computer:ntp.nict.jp /samples:5
                            相手とのずれを一定間隔で表示する
w32tm /config /manualpeerlist:"ntp.nict.jp" /syncfromflags:manual /update
                            同期先を手動で指定し、設定を反映する

ドメインに参加していないパソコンの既定の同期先は time.windows.com,0x9、ドメインに参加しているパソコンはドメインの階層（ドメイン コントローラー）から時刻を合わせます（Microsoft Learn の記載）。会社のパソコンで同期先を勝手に変えると、ドメインのログインに影響することがあるので、管理者の方針に従います。

Mac

Apple のサポートページ「Macで「日付と時刻」設定を変更する」の手順です。

1. アップルメニュー ＞「システム設定」を開く。
2. サイドバーの「一般」をクリックし、「日付と時刻」をクリックする（下にスクロールが要る場合がある）。
3. 「日付と時刻を自動的に設定」をオンにする。時刻サーバー（ソース）は「設定」ボタンを押して入力する。

Linux（chrony・systemd-timesyncd）

Ubuntu の公式ドキュメントによると、systemd-timesyncd は以前の標準インストールに含まれていましたが、Ubuntu 25.10 以降は chrony に置き換えられています。同期しているかどうかは timedatectl status の System clock synchronized: yes と NTP service: active で分かります。chrony を使っているなら、次の3つで状態を確かめます。

chronyc sources -v     どのサーバーを使っているか（^* が使用中）
chronyc tracking       自分の時計のずれ・周波数・ストラタム
chronyc sourcestats    サーバーごとのずれのばらつき

同期先は /etc/chrony/chrony.conf（Ubuntu の場合。/etc/chrony/sources.d/ に分けて置くこともできる）の server か pool の行で指定します。Ubuntu のパッケージに入っている雛形の主な行は次のとおりでした。

pool ntp.ubuntu.com        iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2
sourcedir /etc/chrony/sources.d
driftfile /var/lib/chrony/chrony.drift
makestep 1 3
leapsectz right/UTC

NICT を加えるなら server ntp.nict.jp iburst の1行を足し、chrony を再起動します。iburst は起動直後に4〜8回続けて問い合わせて、早く合わせるための指定です（chrony の公式ドキュメント）。問い合わせ間隔の既定は minpoll 6（64秒）〜maxpoll 10（1024秒）です。

時刻がずれると起きる問題

この節では、時計がずれていると何が起きるのかが、症状の例とともに分かります。

時刻のずれは、それ自体より「時刻を前提にした仕組み」が壊れることで問題になります。

証明書のずれは、openssl で「検証する時刻」を変えて確かめられます。手元で作った有効期間30日（2026年10月31日〜11月30日）の証明書を、時計が狂った場合の時刻で検証した結果です。

$ openssl verify -CAfile server.crt -attime $(date -d '2026-01-01' +%s) server.crt
CN = ntp.t193.test
error 9 at 0 depth lookup: certificate is not yet valid
error server.crt: verification failed

$ openssl verify -CAfile server.crt -attime $(date -d '2027-06-01' +%s) server.crt
CN = ntp.t193.test
error 10 at 0 depth lookup: certificate has expired
error server.crt: verification failed

$ openssl verify -CAfile server.crt server.crt
server.crt: OK

時計が過去に戻っていると「not yet valid」、未来に進んでいると「has expired」になりました。ブラウザで多くのサイトに証明書エラーが出るときは、サイトより先に自分の時計を確かめると早く片づきます。

ログの時刻をそろえる考え方は関連記事「タイムゾーン設計｜UTC保存・JST表示をDB別実行結果で解説」、定期実行の設定は関連記事「cronの書き方｜設定例30パターンの早見表と落とし穴まとめ」、時刻を表示・計算するコマンドは関連記事「dateコマンドのフォーマット一覧と日付計算｜月末・macOS差異もコピペで」で扱っています。

うるう秒とスメア

NTPのパケットには、うるう秒を予告する欄（Leap indicator）があります。うるう秒の日に、1秒を一度に挟む方法と、前後の時間で少しずつ吸収する「スメア」があります。Google の公開NTPのページは、スメアをするなら「正午から正午（UTC）までの24時間で直線的に」行う形を勧めています。スメアしているサーバーとしていないサーバーを混ぜて指定すると、その期間は最大で1秒近く食い違うため、どちらかにそろえます。chrony にも、うるう秒の扱いを決める leapsecmode の設定があります。

NTSとSNTP（安全な時刻同期と簡易版）

この節では、NTPを暗号で守る NTS と、簡易版の SNTP が何で、どう違うのかが分かります。

ふつうのNTPは暗号化も認証もされていないため、途中で応答を書き換えられても気づけません。NTS（Network Time Security、RFC 8915）は、TLS で鍵を交換し、NTPの応答に「本物である証拠」を付ける仕組みです。時刻そのものは秘密ではないので、隠すのではなく「書き換えられていないこと」を確かめます。

サーバー役とクライアント役の chrony で、自分で作った証明書（10.193.0.1 の名前入り）を使って NTS を動かしました。

# サーバー役に足した行
ntsserverkey /srv/s4/r17/t193/w/nts/server.key
ntsservercert /srv/s4/r17/t193/w/nts/server.crt
# クライアント役
server 10.193.0.1 iburst nts minpoll 1 maxpoll 2
ntstrustedcerts /srv/s4/r17/t193/w/nts/server.crt

$ chronyc -n authdata      （クライアント役）
Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
10.193.0.1                   NTS     1   30  128    7    0    0    8   64

tcpdump で見ると、最初に TCP の4460番で TLS のやり取り（鍵の交換、NTS-KE）があり、そのあとの NTP のパケットは48バイトではなく188バイトになっていました。iburst の指定どおり、最初は0.5秒おきに続けて問い合わせています。

09:09:27.249069 IP 10.193.0.2.42914 > 10.193.0.1.4460: Flags [S], ...
（TLS のやり取りが続く）
09:09:27.305870 IP 10.193.0.2.42914 > 10.193.0.1.4460: Flags [F.], ...
09:09:27.753067 IP 10.193.0.2.50391 > 10.193.0.1.123: NTPv4, Client, length 188
09:09:27.753200 IP 10.193.0.1.123 > 10.193.0.2.50391: NTPv4, Server, length 188
09:09:28.259742 IP 10.193.0.2.45586 > 10.193.0.1.123: NTPv4, Client, length 188
09:09:28.769817 IP 10.193.0.2.38617 > 10.193.0.1.123: NTPv4, Client, length 188

信頼する証明書をわざと別のものにすると、クライアント役のログに次のエラーが出て、サーバーは「使えない（^?）」扱いになりました。

TLS handshake with 10.193.0.1:4460 (10.193.0.1) failed : Error in the certificate verification. The certificate is NOT trusted. The certificate issuer is unknown.

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 10.193.0.1                    0   1     0     -     +0ns[   +0ns] +/-    0ns

NTS は証明書を使うので、時計が大きく狂っていると証明書の期限の確認で失敗する、という順番の問題があります。chrony にはこれに備えた設定もあります（nocerttimecheck など。使う前に公式ドキュメントで意味を確かめる）。

ntpsec の ntpdig は SNTP のクライアントで、オプションを付けなければずれを表示するだけで時計は変えません。サーバー役に問い合わせた結果です。

$ ntpdig 10.193.0.1
2026-10-31 09:06:23.371344 (+0900) -0.001205 +/- 0.001265 10.193.0.1 s2 no-leap

$ ntpdig -j 10.193.0.1
{"time":"2026-10-31T09:06:23.778273+0900","offset":0.000012,"precision":0.000044,"host":"10.193.0.1","ip":"10.193.0.1","stratum":2,"leap":"no-leap","adjusted":false}

-j の JSON に "adjusted":false（時計は変えていない）と出ています。1回目のずれ（−1.205ms）と2回目（＋0.012ms）で1ミリ秒ほど違うのは、1回だけの測定だと遅延の揺れをそのまま受けるためで、SNTP が簡易版と呼ばれる理由がよく分かります。

よくあるエラーとつまずき（症状→原因→直し方）

この節では、NTPで時刻が合わないときの症状と、原因・直し方の対応が、手元で出たエラーの原文とともに分かります。

よくある質問

Q. NTPは何の略ですか。読み方は。

A. Network Time Protocol（ネットワーク・タイム・プロトコル）の略で、「エヌ・ティー・ピー」と読みます。今の版は NTP version 4（RFC 5905）です。

Q. NTPサーバーとは何ですか。

A. NTPで正しい時刻を配る側のコンピューターです。ストラタム（階層の番号）を持ち、クライアントの問い合わせに受信時刻・送信時刻を入れて返します。chrony や ntpd は、設定しだいでクライアントにもサーバーにもなります。

Q. NTPはどのポートを使いますか。

A. UDP の123番です。手元の tcpdump でも、要求と応答はどちらも123番宛て・123番から流れていました。NTS を使う場合は、最初の鍵の交換に TCP の4460番も使います。

Q. ストラタムは小さいほど良いのですか。

A. 段数が少ないという意味で、精度の順位ではありません。遠いストラタム1より、近くて安定したストラタム2のほうが誤差が小さいことがあります。サーバーを3〜4つ指定するほうが効果があります。

Q. 時刻のずれはどのくらいまで小さくできますか。

A. 経路しだいです。NICT の公開ページは、インターネット越しの利用者の精度を「数ミリ秒から数百ミリ秒位まで」と書いています。手元の名前空間どうし（遅延がほぼ無い経路）では数マイクロ秒でした。誤差の上限は往復遅延の半分で、行きと帰りの遅延が違うとその差の半分がずれとして残ります。

Q. Windows の時計がずれるのはなぜですか。

A. 「時刻を自動的に設定する」がオフになっている、同期先に届かない（会社のネットワークで UDP 123 が通らない）、ドメインの時刻階層がずれている、などが考えられます。状態は w32tm /query /status、今の時刻源は w32tm /query /source で確かめられます。

Q. 社内の機器を ntp.nict.jp に直接向けてもよいですか。

A. 数台なら問題になりにくいですが、台数が多いなら社内に NTP サーバーを置き、外に問い合わせるのはそのサーバーだけにします。NICT は1時間平均20回を超えないよう求めています。

Q. 時計を手で合わせればNTPは要らないのでは。

A. 水晶の時計は進み方にくせがあり、100ppm 速い時計なら1日で8.64秒進みます。手で合わせても、すぐまたずれます。NTPは「ずれ」だけでなく「進み方のくせ」も推定して直し続けます（手元の chrony は 100.003ppm と推定しました）。

Q. NTPを使うと時刻が急に飛ぶことはありますか。

A. 大きくずれていたときにステップで直すと、時刻が飛んだり戻ったりします。chrony の makestep 1 3 のように「起動直後だけステップ」にしておくと、動いている間はスルー（少しずつ）で直り、時刻は飛びません。

まとめ

• NTPは、ネットワーク越しに時計を合わせる約束ごと（UDP 123番）です。4つの時刻からずれ（オフセット）と往復遅延を計算します。
• ストラタムは基準の時計からの段数で、1が最上位、16は「同期していない」。精度の順位ではないので、近いサーバーを3〜4つ指定します。
• ずれは「起動直後だけステップ、あとはスルー」で直すのが基本です。スルーだけだと3秒のずれに約100分かかりました。
• 誤差の上限は往復遅延の半分です。行きだけ20ミリ秒遅いと、ずれていない時計を「10ミリ秒遅れ」と測りました。
• 時刻のずれは証明書・ログイン・ワンタイムパスワード・ログの順番を壊します。改ざんを防ぎたいなら NTS（RFC 8915）を使えます。

参考・出典

いずれも2026年10月29日に確かめました。

• RFC 5905「Network Time Protocol Version 4: Protocol and Algorithms Specification」：https://www.rfc-editor.org/rfc/rfc5905
• RFC 8915「Network Time Security for the Network Time Protocol」：https://www.rfc-editor.org/rfc/rfc8915
• RFC 6238「TOTP: Time-Based One-Time Password Algorithm」：https://www.rfc-editor.org/rfc/rfc6238
• chrony「chronyd(8)」（4.5）：https://chrony-project.org/doc/4.5/chronyd.html
• chrony「chrony.conf(5)」（4.5）：https://chrony-project.org/doc/4.5/chrony.conf.html
• NTPsec「ntpd - Network Time Protocol (NTP) Daemon」：https://docs.ntpsec.org/latest/ntpd.html
• NICT 日本標準時グループ「公開NTP」：https://jjy.nict.go.jp/tsp/PubNtp/index.html
• NICT「NICT公開 NTP FAQ」：https://jjy.nict.go.jp/tsp/PubNtp/qa.html
• インターネットマルチフィード「時刻情報提供サービス for Public」：https://www.mfeed.ad.jp/ntp/
• NTP Pool Project「プールを利用するためにNTPを設定する方法は?」：https://www.ntppool.org/ja/use.html
• Microsoft Learn「Windows タイム サービスのツールと設定」：https://learn.microsoft.com/ja-jp/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings
• Microsoft サポート「Windows で時刻、日付、タイム ゾーンの設定を設定する」：https://support.microsoft.com/ja-jp/help/4026213
• Microsoft Learn「Maximum tolerance for computer clock synchronization」：https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization
• Apple サポート「Macで「日付と時刻」設定を変更する」：https://support.apple.com/ja-jp/guide/mac-help/mchlp1124/mac
• Ubuntu Server documentation「Synchronize time using timedatectl and timesyncd」：https://ubuntu.com/server/docs/how-to/networking/timedatectl-and-timesyncd/
• Google for Developers「Leap Smear」：https://developers.google.com/time/smear

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。