先に要点
サーバー運用で、時刻同期は地味ですがかなり重要です。
普段は目立ちませんが、障害調査やセキュリティ調査のときにログの時刻がずれていると、何が先に起きたのかを追えなくなります。
そこで使われる代表的な仕組みが NTP です。
NTPは、ネットワーク越しに基準時刻と照合し、サーバーの時計をずれにくくするためのプロトコルです。
この記事では、2026年4月22日時点で RFC 5905、NIST Internet Time Service、主要Linuxのchrony系ドキュメントを確認しながら、NTPとは何か、時刻同期がずれると何が起きるのかを整理します。
サーバー初期設定の全体像は、VPSを借りたら最初にやることは？SSH・ファイアウォール・更新設定の初期チェックリスト もあわせて読むとつながりやすいです。
NTPとは何か
NTPは Network Time Protocol の略で、ネットワークを使ってコンピューターの時計を同期するためのプロトコルです。
RFC 5905では、NTPはコンピューターの時計を同期するために広く使われているプロトコルとして整理されています。
サーバーには内部時計がありますが、何もしなくても永久に正確なわけではありません。
少しずつ進んだり遅れたりします。仮想サーバー、コンテナホスト、クラウド環境でも、時刻同期の仕組みが正しく動いていることは前提にしすぎない方が安全です。
NTPを使うと、サーバーはNTPサーバーに問い合わせ、現在時刻との差を見ながら自分の時計を調整します。
Linuxでは、現在は chrony や systemd-timesyncd のような仕組みで時刻同期を管理することが多いです。古い資料では ntpd もよく出てきます。
タイムゾーンとNTPは別物
時刻の話で混ざりやすいのが、タイムゾーンとNTPです。
タイムゾーンは、時刻をどの地域の表示にするかの設定です。
たとえばUTCで保存するのか、日本時間として表示するのか、ログや画面でどう見せるのかに関係します。
NTPは、時計そのものを基準時刻に合わせる仕組みです。
タイムゾーンが正しくても、サーバーの時計自体が5分ずれていれば、ログや認証の判定はずれます。
| 項目 | 見るもの | ずれると起きること |
|---|---|---|
| タイムゾーン | UTC、日本時間などの表示・解釈 | ログや画面の表示時刻が読み違えられる |
| NTP | サーバー時計そのものの同期 | 認証、証明書、ログ順序、ジョブ実行が壊れる |
実務では、保存はUTC、表示は利用者の地域、サーバー時計はNTPで同期、というように役割を分けて考えると整理しやすいです。
時刻同期がずれると何が起きるのか
時刻が少しずれるだけなら大したことがないように見えます。
しかし、サーバーでは いつ起きたか が多くの処理の前提になっています。
ログ調査が難しくなる
一番分かりやすい影響はログです。
Webサーバー、アプリ、DB、ジョブ、ロードバランサー、監視ツールの時刻がずれていると、障害の流れを追いにくくなります。
たとえば、アプリログでは10:00にエラー、DBログでは9:58にタイムアウト、ロードバランサーでは10:03に502が出ているように見えると、何が原因で何が結果なのかが分かりにくくなります。
実際には同じ瞬間に起きた問題でも、時刻がずれているだけで調査が遠回りになります。
監視やログの基本は、監視はどこまで必要？死活監視・ログ監視・通知設計の基本を実務目線で解説 でも整理しています。
認証やトークンで失敗する
ログイン、API認証、JWT、署名付きURL、ワンタイムパスワードのような仕組みでは、有効期限が重要です。
サーバーの時計が進みすぎていると まだ有効なはずのトークンが期限切れ と判断されることがあります。逆に遅れていると、失効したはずのものを有効と見てしまう可能性もあります。
認証の問題に見えて、実は時刻ずれだった、という切り分けは珍しくありません。
特に複数サーバー構成では、1台だけ時計がずれていると、特定のサーバーに振り分けられたときだけ失敗するように見えます。
TLS証明書や署名検証で詰まる
HTTPS の証明書には、有効期間があります。
サーバーやクライアントの時刻が大きくずれていると、まだ有効な証明書を 期限切れ や まだ有効ではない と判断することがあります。
外部API連携でも、リクエスト署名やタイムスタンプ付きの認証を使っている場合、時刻差が大きいと拒否されることがあります。
APIキーや署名の設定を疑う前に、サーバー時刻を確認した方が早いケースがあります。
cronやジョブ実行がずれる
定期実行ジョブも時刻に依存します。
バックアップ、レポート生成、メール配信、請求処理、期限切れデータの削除などは、サーバーの時計を前提に動きます。
時刻がずれていると、想定より早く実行されたり、遅れて実行されたりします。
時計が急に大きく補正された場合は、ジョブが二重に動いたように見えたり、逆に動いていないように見えたりすることもあります。
分散システムで順序が分からなくなる
複数サーバー、キュー、DB、キャッシュ、外部サービスが関わる構成では、時刻はイベント順序の手がかりになります。
すべてを時計だけで判断するのは危険ですが、ログやトレースを見るときには時刻がかなり重要です。
サーバー間で時計がずれていると、Aで処理したあとBで処理したはずなのに、ログ上は逆に見えることがあります。
障害調査、監査ログ、不正アクセス調査では、このずれがかなり痛くなります。
NTPまわりで見るポイント
実務では、NTPの理論を細かく覚えるより、同期が有効で、どこを見れば状態が分かるかを押さえる方が大事です。
Linuxでは環境によってコマンドが違いますが、よく見るのは次のあたりです。
timedatectl
chronyc tracking
chronyc sources -v
systemctl status chronyd
systemctl status systemd-timesyncd
見るポイントは、NTP同期が有効か、同期先が見えているか、ずれが大きすぎないか、サービスが落ちていないかです。
クラウド環境では、OSイメージやディストリビューションによって標準の時刻同期サービスが違うため、使っている環境の公式ドキュメントも確認します。
よくある注意点
NTPでよくある失敗は、外向き通信を絞った結果、NTPサーバーへ到達できなくなることです。
NTPは一般にUDP 123番を使います。ファイアウォール、セキュリティグループ、社内プロキシ、クラウドのネットワーク制限で通信できないと、時刻同期が止まることがあります。
もうひとつは、1つの公開NTPサーバー名を雑に固定してしまうことです。
本番では、クラウド事業者が提供する時刻同期サービス、組織内のNTPサーバー、信頼できる複数の時刻ソースを使うなど、構成に合わせて選びます。NISTのInternet Time Serviceのような公的なサービスもありますが、利用条件や推奨設定を確認して使うべきです。
また、時刻が大きくずれた状態で急に補正されると、アプリやジョブの挙動に影響することがあります。
本番で大きなずれを見つけた場合は、単に 時刻を合わせれば終わり ではなく、ログ、ジョブ、認証エラー、外部連携失敗が起きていないかも確認します。
まず確認するチェックリスト
サーバーを立てた直後や、認証・証明書・ログ時刻で違和感があるときは、次を確認します。
- NTP同期が有効になっているか
timedatectlでNTP synchronizedが確認できるか- chronyやtimesyncdなど、実際に使っているサービスが起動しているか
- 同期先NTPサーバーへ到達できるか
- ファイアウォールでUDP 123番を塞いでいないか
- タイムゾーン設定とアプリの保存時刻の方針が混ざっていないか
- 複数サーバーで時刻差が大きくないか
- 障害発生時刻を複数ログで突き合わせられるか
このあたりを初期設定や監視項目に入れておくと、あとから調査で苦しくなりにくいです。
まとめ
NTPは、サーバーの時計をネットワーク経由で基準時刻に合わせるためのプロトコルです。
普段は目立ちませんが、ログ、認証、証明書、定期ジョブ、分散システムの土台になっています。
時刻同期がずれると、障害原因の順序が追えない、トークンが期限切れ扱いになる、証明書検証に失敗する、ジョブが想定外のタイミングで動く、といった問題が起きます。
サーバー運用では、アプリのデプロイや監視だけでなく、OSの時刻同期も基本項目として見ておくべきです。
時計が合っている ことは地味ですが、トラブル時にチームを助けるかなり強い前提になります。
参考リンク
- RFC Editor: RFC 5905 - Network Time Protocol Version 4
- NIST: Internet Time Service
- Red Hat Documentation: Configuring NTP Using the chrony Suite