【NTP入門 第1回】なぜ時刻同期が必要か ― 認証・証明書・ログ・規制を支える「時刻」と、時計がずれる理由

「ADにログオンできない端末が1台だけあります。パスワードは合っているんですが……」
「発行したばかりの証明書が『まだ有効ではありません』と言われます」

こんな問い合わせの原因が、サーバーや端末の時計のずれだったことはありませんか。

サーバーの時刻は、合っていて当たり前と思われがちです。ところが時刻がずれると、認証の失敗、証明書のエラー、ワンタイムパスワードが通らない、ログの時刻がそろわないといった問題が、時刻とは無関係に見える形で表に出ます。

連載「NTP入門」では、なぜ時刻を合わせるのかから始め、時刻の基礎、NTPの仕組み、Linux（chrony）・Windows・ネットワーク機器・仮想基盤での設定、社内の時刻同期の設計、セキュリティ、PTPによる高精度の同期までを全11回で扱います。第1回は、なぜ時刻同期が必要かです。

---

連載の進め方

第1回〜第3回が土台です。第1回で「なぜ合わせるのか」、第2回で「何に合わせるのか」、第3回で「どうやって合わせるのか」を押さえると、第4回以降の設定の意味がすぐ分かります。

コマンドは、Linuxのchronyc・timedatectlと、Windows標準のw32tm・PowerShellを併記します。各回の最後の「考えてみよう」は、自分の職場の環境を思い浮かべながら答えてみてください。

---

時刻がずれると起きること

時刻のずれによる障害の特徴は、エラーの表示に「時刻」という言葉がほとんど出てこないことです。

• Kerberos認証：クライアントとドメインコントローラーの時刻が、既定で5分を超えてずれると、ログオンやファイル共有へのアクセスが失敗する
• 証明書：有効期間を時刻で判断するため、端末の時計が遅れていると、発行されたばかりの証明書が「まだ有効でない」と扱われる
• ワンタイムパスワード（TOTP）：認証アプリのコードは30秒ごとの時刻から作られるので、時計がずれると正しいコードが拒否される
• ログ：時刻がそろっていないと、複数の機器のログを並べて、障害や不正アクセスの順序を追えない
• データ：「新しい方を残す」判断を時刻で行う分散データベースやファイル同期では、ずれた時計が新しいデータを古いデータで上書きしかねない

時刻は、認証・暗号・記録・データの整合を下支えする共通の土台なのです。

---

認証と証明書で時刻を使う仕組み

仕組み	時刻の使い方	許容されるずれ	ずれたときの症状
Kerberos（AD のログオン）	認証子の時刻で再送攻撃を防ぐ	既定5分	KRB_AP_ERR_SKEW、ログオン・ファイル共有の失敗
証明書（TLS）	Not Before〜Not After の間だけ有効	期間の内であること	ERR_CERT_DATE_INVALID、発行直後の証明書が無効
TOTP（認証アプリ）	30秒ごとの時刻からコードを作る	前後1刻み程度（検証側の設定）	正しいコードが拒否される
SAML・OpenID Connect	アサーション・トークンの発行時刻と有効期限	実装ごとに数分程度の猶予	SSO のログインが失敗する
DNSSEC・NTS	署名や証明書の有効期間を時刻で確かめる	期間の内であること	名前解決や安全な時刻同期そのものが失敗する

冒頭の「発行したばかりの証明書が有効でない」は、この図のとおりです。端末の時計が遅れていると、証明書の有効期間が「まだ始まっていない」ように見えます（証明書の有効期間は連載「証明書入門」第4回）。

ワンタイムパスワード（TOTP、RFC 6238）も同じ理屈です。認証アプリとサーバーは、共有した秘密の値と「今の時刻を30秒で割った番号」から、同じ6桁のコードを計算します。時計が30秒以上ずれると番号が変わり、別のコードになります。多くのサーバーは前後1刻み（±30秒）程度まで受け入れますが、スマートフォンの時計が手動設定で数分ずれていると、何度入力しても通りません。

Kerberosの許容差は、グループポリシーのKerberosポリシー「コンピューターの時計の同期の最長トレランス」（既定5分）で決まります。短くすると再送攻撃に強くなりますが、全端末の時刻同期が前提です（第5回。Kerberos の側の仕組みは連載「Kerberos入門」第4回の「時刻のずれの上限（既定5分）」の節）。

なお、安全な時刻同期の方式であるNTSが、時刻の確認に証明書を使う「鶏と卵」の問題は、第8回で扱います。

---

ログ・データ・ファイルへの影響

障害や不正アクセスの調査では、ファイアウォール、Webサーバー、データベース、ADなど、複数の機器のログを時刻で並べ、何がどの順で起きたかを組み立てます。

• ログ：1台だけ2分遅れていると、原因と結果が逆に見え、調査を誤った方向へ導く。ログを集約する場合も、機器が記録した時刻と受け取った時刻の違いに注意が要る
• データ：Cassandraのように書き込みの時刻で「後に書いた方を正」とするデータベースや、更新時刻で新旧を判断するファイル同期・バックアップが、ずれた時計のせいで新しいデータを失うことがある
• 開発：makeはファイルの更新時刻で再ビルドの要否を決めるため、NFSサーバーと時刻がずれると「Clock skew detected」と警告し、必要なビルドを飛ばすことがある

ジョブの実行時刻や証跡の信頼性も、時刻の正しさに依存します。

---

規制・基準が求める時刻

業種によっては、時刻の精度そのものが規制で求められます。

規制・基準	対象	求める内容
MiFID II の RTS 25（EU 委任規則 2017/574）	取引所と取引参加者	UTC からのずれを、高頻度取引は100μs以内（記録は1μs単位）、その他は1ms以内、音声取引などは1秒以内
FINRA Rule 6820（米国、CAT）	証券会社	NIST の時刻から50ms以内（手作業の注文は1秒以内）。毎営業日の開始前に同期し、記録を残す
PCI DSS v4.0 要件 10.6	カード情報を扱うシステム	時刻同期の技術を使う。外部（UTC・TAI に基づく）から受け取るのは指定した中央の時刻サーバーだけ。設定と時刻データを保護する
監査・フォレンジック全般	ログ・証跡	時刻の出どころ（UTC へのトレーサビリティ）と、同期していた証拠を示せること

• 規制の数値は「UTCからどれだけずれていないか」で書かれ、同期していたことの記録（監視のログ）を求めるものが多い
• PCI DSSの「外部から受け取るのは中央の時刻サーバーだけ」は、第7回で扱う社内の階層設計そのもの
• 1ms以下の要件は、インターネット越しのNTPでは満たせず、Windowsの高精度時刻（第5回）やPTP（第9回）を検討する。第11回の演習でも扱う

---

時計がずれる理由

そもそも、なぜコンピューターの時計はずれるのでしょうか。

コンピューターの時計は、水晶発振器が一定の周波数で振動する回数を数えて時間を測っています。ところが水晶の周波数は、製造のばらつきで公称値から少しずれています。このずれをppm（百万分率）で表します。

• 1ppmは1日あたり 86,400秒×10⁻⁶＝約0.086秒のずれに当たる
• サーバーやパソコンの時計の誤差は数十ppmも珍しくない。20ppmなら1日に約1.7秒・1か月で約52秒、50ppmなら1日に約4.3秒・1か月で2分以上ずれる
• 周波数は温度でも変わり（RTCに使う音叉型の水晶は25℃付近から外れるほど遅れる）、経年でも変化する
• 仮想マシンでは、ホストの負荷や一時停止、ライブマイグレーションで、時計が遅れたり飛んだりする（第4回）

時計は、合わせても放っておけば必ずずれるのです。NTPは時刻を直すだけでなく、このずれる速さ（周波数の誤差）も測って補正します。

ポイント
1ppm＝1日あたり約0.086秒。「1か月止まっていたNTP」は、数十秒〜数分のずれを生む。

---

必要な精度の目安

では、どこまで合わせればよいのでしょうか。用途によって、必要な精度は大きく違います。

用途	必要な精度の目安	根拠	主な手段
Kerberos・AD のログオン	5分以内（運用では1秒以内を目標）	Kerberos ポリシーの既定	NTP（Windows Time）
TOTP（ワンタイムパスワード）	30秒の刻みの内。数秒以内が望ましい	RFC 6238	NTP
ログの突き合わせ・SIEM	1秒〜10ms	運用の要件（イベントの順序）	NTP
分散データベース・クラスター	ms 単位（製品が上限を定める）	各製品の要件	LAN 内の NTP
金融の取引記録	1ms（高頻度取引は100μs）、米国は50ms	MiFID II、FINRA	NTP・PTP
5G（TDD）の基地局	UTC から ±1.5μs	ITU-T G.8271	GNSS＋PTP

自分の端末のずれを測ってみる

PS> w32tm /stripchart /computer:ntp.nict.jp /samples:3 /dataonly
ntp.nict.jp [(アドレス):123] を追跡中。
3 サンプルを収集中。
現在の時刻は 2026/09/26 16:20:01 です。
16:20:01, +00.0021473s
16:20:03, +00.0019855s
16:20:05, +00.0020312s                    （抜粋。値は相手との差）

$ chronyc tracking | grep -E 'System time|Leap status'
System time     : 0.000641572 seconds slow of NTP time
Leap status     : Normal

• Windowsのw32tm /stripchartは、指定したNTPサーバーと自分の時計の差を、決まった回数だけ測って表示する。時刻は変えないので、調べるだけなら安全
• Linuxのchronyc trackingのSystem timeは、chronyが見積もった「今のずれ」。上の例は約0.64ms遅れている（読み方は第4回）
• 数msなら正常。数秒〜数分ずれていたら、時刻同期が止まっているか、参照先が間違っている

NTPで届く精度の目安は、インターネット越しで数ms〜数十ms、LAN内で1ms未満（数百μs）です（RFC 5905）。多くの業務システムはNTPで十分ですが、「1ms以内」を求められたら、NTPの構成を見直すかPTPを検討する、というのが判断の分かれ目です。Windows Server 2016以降は、条件を満たせば1ms程度の精度を狙えます（第5回）。

---

考えてみよう

1. 自分の担当システムで時刻が5分ずれたら、最初に困るのはどの仕組みですか。エラーの表示から「時刻のずれ」だと気づけるでしょうか。
2. 時計が30ppm進むサーバーでNTPが止まっていたら、1か月で何秒ずれますか。Kerberosの5分に達するのは何日後ですか。
3. 自分のPCの今のずれを測ってみてください。Windowsではw32tm /stripchart /computer:ntp.nict.jp /samples:3 /dataonly、Linuxではchronyc trackingのSystem time行です。ずれは何msでしたか。

ヒント：この記事の「認証と証明書で時刻を使う仕組み」の表、1ppm＝1日あたり0.0864秒の計算、必要な精度の目安が手がかりです。30ppmなら1日に約2.6秒です。

---

まとめ

• 時刻のずれは、認証・証明書・ワンタイムパスワード・ログ・データの不具合として表に出る
• エラーに「時刻」と出ないことが多く、原因に気づきにくい
• Kerberosは既定5分、証明書は有効期間、TOTPは30秒の刻みで時刻を使う
• 規制は「UTCからのずれ」と「同期していた記録」を求める
• 時計は水晶の個体差・温度・経年でずれる。1ppm＝1日約0.086秒
• 多くの業務はNTPで足りる。1ms以内を求められたら構成の見直しかPTP

次回は、「正しい時刻」とは何か（UTC・うるう秒・タイムゾーン）と、コンピューターの時計の仕組みを扱います。

---

連載「NTP入門」全11回

1. なぜ時刻同期が必要か（この記事）
2. 時刻の基礎知識
3. NTPの仕組み
4. Linuxの時刻同期（chrony）
5. Windowsの時刻同期
6. ネットワーク機器・仮想基盤
7. 設計と推奨構成
8. NTPのセキュリティ
9. PTPと高精度同期
10. 時刻同期のトラブルシュート
11. 時刻同期の設計演習