【NTP入門 第2回】時刻の基礎知識 ― UTC・TAI・うるう秒の廃止、UNIX時刻とNTP時刻、2036年・2038年問題、RTC

「ログの時刻がJSTのサーバーとUTCのサーバーがあって、並べると9時間ずれて見えます」
「うるう秒の日は、何か準備が必要ですか？」

時刻を合わせる前に、何に合わせるのかを知っておく必要があります。世界の「正しい時刻」は誰が決めていて、コンピューターはそれをどう数えているのでしょうか。

第1回では、時刻がずれると何が起きるかを見ました。第2回では、UTC・うるう秒・エポック・タイムゾーンといった時刻の基礎と、コンピューターの時計の仕組みを扱います。

---

天文の時刻と原子の時刻

時刻には、地球の自転をもとにした「天文の時刻」と、原子の振動をもとにした「原子の時刻」の2系統があります。

• 昔の1秒は、平均した1日の86,400分の1だった。英国グリニッジ天文台の子午線での平均太陽時がGMT（グリニッジ平均時）で、これを天文観測で精密にしたものが世界時（UT）
• 観測地点ごとに求めた値がUT0、地球の自転軸のふらつき（極運動）を補正して地球全体で共通にしたものがUT1（季節変動も補正したUT2は、今はほぼ使わない）
• ところが地球の自転は、潮汐による減速や大気・海洋・地球内部の動きで揺らぐ
• そこで1967年に、1秒はセシウム原子の振動 9,192,631,770 回分と定義し直された。この秒で数え続けた時刻が国際原子時（TAI）で、世界の約450台の原子時計から国際度量衡局（BIPM）が計算する

天文の時刻は観測して決め、原子の時刻は数えて決めるのです。

---

UTC・TAI・UT1・GMT・JSTの関係

時刻	何に基づくか	他との関係（2026年9月）	使われる場面
UT1	地球の自転（観測）	UTC との差は ±0.9秒以内に保たれてきた	天文、衛星の軌道計算
TAI	原子時計の加重平均	TAI − UTC ＝ 37秒（2017年1月から変わらず）	時刻の基準の計算
UTC	TAI の秒＋うるう秒で UT1 に寄せる	世界の時刻の基準。NTP が配る時刻	サーバー・ログの記録
GMT	グリニッジの平均太陽時（歴史的な呼び名）	日常では UTC と同じ意味で使われるが厳密には別	英国の冬の常用時
GPS 時刻	GPS の原子時計	うるう秒を入れない。GPS − UTC ＝ 18秒	GNSS 受信機の内部
JST	UTC(NICT) ＋ 9時間	夏時間なし	日本の常用時

• UTCは、TAIと同じ原子の秒で刻み、うるう秒でUT1に寄せた時刻。NTPが配るのはUTC
• UTCそのものはBIPMが毎月、各国のデータから後で計算して公表する時刻で、各国の機関が実時間で作る近似値をUTC(k)と呼ぶ。日本ではNICT（情報通信研究機構）のUTC(NICT)で、JSTはこれに9時間を足した時刻

ポイント
サーバーの内部とログはUTCで持ち、人が見るときにタイムゾーンで変換するのが基本。

---

うるう秒

UTCはTAIと同じ原子の秒で刻むため、そのままでは地球の自転（UT1）から少しずつ離れます。そこで1972年から、UT1との差が0.9秒を超えないよう、国際地球回転・基準系事業（IERS）の判断で、UTCに1秒を足し引きしてきました。これがうるう秒です。

• 挿入は原則6月末か12月末で、23時59分59秒の次に23時59分60秒を入れる（日本時間では8時59分60秒）
• 27回すべてが1秒を足す調整で、最後は2016年12月31日（日本時間2017年1月1日）
• NTPは、パケットのLI（うるう秒指示子）で事前に予告する（第3回）

しかし「1分は60秒」「時刻は戻らない」を前提にしたプログラムは多く、2012年にはLinuxカーネルの不具合で多数のサーバーのCPU使用率が急上昇し、2017年には時間差が負になってCloudflareのDNSの一部が失敗しました。うるう秒は、障害の種でもあったのです。

---

うるう秒の廃止の決定

冒頭の「うるう秒の日は準備が必要か」への答えは、「もう入らない見込み」です。

• 2022年11月の第27回国際度量衡総会（CGPM）は決議4で、UT1とUTCの差の上限を遅くとも2035年までに大きくすることを決め、少なくとも100年はUTCを連続させられる新しい上限を次の総会に示すよう求めた
• これを受けて2026年10月15日、第28回CGPMは決議5（決議案Cとして提出）を採択し、「連続したUTCを2027年5月20日から有効にし、|UT1−UTC|の上限を3,600秒（1時間）とする」ことを決めた。うるう秒の廃止は、2035年から2027年5月20日に前倒しされた
• 前倒しの背景は、地球の自転が速まり、前例のない「1秒を削る」負のうるう秒が必要になりそうなこと。2025年の専門家の会合は、その確率を2035年までに30%と見積もり、重要インフラを混乱させる危険が高いとされた
• なお、IERSは2026年12月末もうるう秒を入れないと発表しており、TAI−UTCは37秒のまま

最後のうるう秒は2016年末で、制度として止める段階に入りました。ただし、うるう秒を前提にした仕組み（第7回で扱うリープスメアなど）は、当面は残ります。

---

エポック：UNIX時刻とNTP時刻

コンピューターは、時刻を「ある起点（エポック）からの経過秒」で数えます。起点は仕組みごとに違います。

数え方	起点（エポック）	形式	注意
UNIX 時刻	1970-01-01 00:00:00 UTC	経過秒。うるう秒は数えない	32ビット符号付きは2038年に桁あふれ
NTP 時刻	1900-01-01 00:00:00 UTC	秒32ビット＋端数32ビット（約233ピコ秒刻み）	秒の欄が2036年に桁あふれ
Windows（FILETIME）	1601-01-01 00:00:00 UTC	100ナノ秒単位の64ビット	西暦3万年ごろまで表せる
GPS 時刻	1980-01-06 00:00:00 UTC	週番号＋週の中の秒	10ビットの週番号は1024週で一巡（2019年4月に2回目）

$ date +%s
1790407000
$ date -u -d @0
Thu Jan  1 00:00:00 UTC 1970
PS> [DateTimeOffset]::UtcNow.ToUnixTimeSeconds()
1790407000
PS> [DateTimeOffset]::FromUnixTimeSeconds(0).UtcDateTime
1970年1月1日 0:00:00

• NTP時刻とUNIX時刻の差は2,208,988,800秒（70年分、うるう日17回を含む）
• どちらもうるう秒を数えないため、うるう秒の瞬間は同じ秒を2回数えるか、実装が前後で調整する
• PowerShellではDateTimeOffsetを使うと、UTCで確実に扱える

---

2036年問題

NTPのタイムスタンプは、1900年1月1日からの秒を32ビットの符号なし整数で表します。表せるのは約136年分で、2036年2月7日6時28分16秒（UTC、日本時間15時28分16秒）に秒の欄が桁あふれして0に戻ります。

• RFC 5905は、この区切りをエラ（era）と呼び、1900年からをエラ0、桁あふれ後をエラ1とする
• パケットにはエラの番号が入らないため、受け取った側は自分の時計から今のエラを判断する。クライアントの時計がサーバーと68年以内に合っていれば、エラをまたいでも正しく計算できる
• chronyもビルド日の前50年〜後86年に割り当てるため、現行版は2036年以降も動く
• 危ないのは、秒の値を常に1900年からとみなす古い実装や組み込み機器と、RTCの電池切れなどで大昔に戻った機器

同じ秒の値でも、自分の時計しだいで136年違う日付になるのです。

---

2038年問題

対象	何が起きるか	現状と対策
32ビット符号付きの time_t	2038-01-19 03:14:07 UTC（日本時間12:14:07）の次が1901年12月13日になる	64ビットの Linux・Windows は64ビット。32ビットの Linux はカーネル5.6・glibc 2.34 以降で64ビットを選べる
組み込み機器・古いアプリ	同上。中身が見えないことが多い	メーカーに対応状況を確認し、更新できない機器は計画的に入れ替える
ファイルシステム	更新時刻などを2038年以降にできない	ext4 は256バイトの inode なら対応。XFS は bigtime（xfsprogs 5.15 以降の既定）で2486年まで
データベース	MySQL の TIMESTAMP 型は2038-01-19 03:14:07 UTC まで	DATETIME 型などへの見直し

$ date -u -d @2147483647
Tue Jan 19 03:14:07 UTC 2038
PS> [DateTimeOffset]::FromUnixTimeSeconds([int]::MaxValue).UtcDateTime
2038年1月19日 3:14:07

2036年問題はNTPの時刻の形式、2038年問題はOSやアプリが内部で使うUNIX時刻の形式の問題で、別物です。有効期限が2038年を超える証明書、長期のタイマー、未来の日付の計算では、2038年より前に表面化することがあります。

---

タイムゾーンとRTC：LinuxとWindows

項目	Linux	Windows
タイムゾーンの名前	tz database の Asia/Tokyo	独自の ID Tokyo Standard Time
確認と変更	timedatectl、timedatectl set-timezone Asia/Tokyo	Get-TimeZone、Set-TimeZone -Id “Tokyo Standard Time”（tzutil /g も可）
OS の中の時刻	UTC で持ち、表示のときに変換	UTC で持ち、表示のときに変換
RTC に書く時刻（既定）	UTC	ローカル時刻（日本なら JST）
RTC の扱いを変える設定	timedatectl set-local-rtc 1（systemd は非推奨）	レジストリの RealTimeIsUniversal（公式サポート外）

$ timedatectl
               Local time: Sat 2026-09-26 16:16:19 JST
           Universal time: Sat 2026-09-26 07:16:19 UTC
                 RTC time: Sat 2026-09-26 07:16:19
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
PS> Get-TimeZone | Select-Object Id, BaseUtcOffset
Id                  BaseUtcOffset
--                  -------------
Tokyo Standard Time      09:00:00

• 1台でWindowsとLinuxを切り替えて起動すると、Linuxが RTCに書いたUTCを、WindowsがJSTとして読むため、時計が9時間ずれる。日本は夏時間がないため、Linux側をset-local-rtc 1にすると実害が少なく済む
• サーバーでは、全台のタイムゾーンをそろえることが重要。冒頭の「JSTとUTCが混在して9時間ずれて見える」は、ログを並べる前にどちらかへそろえて比べる

---

コンピューターの時計（RTCとシステムクロック）

コンピューターには2つの時計があります。

• RTC（リアルタイムクロック）：マザーボード上の電池で動く時計（BIOSクロック、ハードウェアクロックとも呼ぶ）。電源を切っても動くが、精度は高くない
• システムクロック：CPUのタイムスタンプカウンター（TSC）などの進みを時間に換算して、OSが刻む時計。アプリケーションやログはこちらを使う
• 起動時にOSがRTCを読んで初期値にし、以後はシステムクロックが独立して進む。NTPが合わせるのもシステムクロックで、RTCへは定期的に書き戻す（Linuxではchronyのrtcsyncでカーネルが11分ごとに書き込む。第4回）
• RTCの電池が切れると、起動直後の時刻が大きく狂う。仮想マシンのRTCは仮想のもので、起動時の時刻はホストから受け取る（第4回・第6回）

---

時刻の源

社内の時刻も、たどれば原子時計に行き着きます。

時刻の源	仕組み	精度の目安	使いどころ
原子時計（セシウム・水素メーザー・ルビジウム）	原子の振動で秒を刻む	標準時の元。ルビジウムは小型で機器にも入る	NICT などの標準時の機関、GNSS が止まったときの保持
GNSS（GPS・みちびき等）	衛星の原子時計の時刻を受信し、受信機が 1PPS 信号を出す	1μs 以下	社内の stratum 1 サーバー、基地局、PTP のグランドマスター
標準電波 JJY	NICT が長波で時刻を送る。40kHz おおたかどや山（福島県）、60kHz はがね山（佐賀県・福岡県）	受信条件に左右される	電波時計、屋内で GNSS が受からない機器
NICT の公開 NTP（ntp.nict.jp）	日本標準時に直結した stratum 1 を公開	ネット越しで数ms〜数百ms（NICT の説明）	社内の NTP サーバーの上位（第7回）
公開 NTP・クラウドの時刻サービス	pool.ntp.org、各社の公開サーバー、Amazon Time Sync Service（169.254.169.123）等	環境による	第7回、連載「クラウド入門」第7回

• 日本標準時は、NICT（東京都小金井市）が複数のセシウム原子時計と水素メーザーで作るUTC(NICT)に9時間を足したもの
• 1PPSは、GNSS受信機や原子時計などの機器が出力する1秒ごとのパルスで、衛星が直接出す信号ではない
• アナログ電話回線のテレホンJJYは2024年3月末で終了し、光電話回線の光テレホンJJYが続いている

---

考えてみよう

1. 担当サーバーのログは、UTCとJSTのどちらで記録されていますか。混在していたら、障害調査で時刻をそろえるときに何に気をつけますか。
2. 職場に、2036年や2038年の桁あふれの影響を受けうるものはありますか（更新できない組み込み機器、32ビットのOS、MySQLのTIMESTAMP型など）。
3. うるう秒の調整をやめると、UTCと太陽の動き（UT1）の差はどうなりますか。システムの運用で何が楽になり、何が残りますか。

ヒント：この記事の関係表、うるう秒の廃止の年表、2036年問題・2038年問題の表と日付が手がかりです。timedatectl・Get-TimeZoneで、実際の設定を確かめてみてください。

---

まとめ

• 時刻には天文の時刻（UT1）と原子の時刻（TAI）がある。NTPが配るのは、TAIの秒でUT1に寄せたUTC
• TAI−UTCは37秒。JSTはUTC(NICT)＋9時間
• うるう秒は27回で、最後は2016年末。2026年10月の第28回CGPMで、廃止は2027年5月20日に前倒しされた
• NTP時刻は1900年、UNIX時刻は1970年が起点。2036年問題（NTP）と2038年問題（UNIX時刻）は別物
• OSの中はUTC。RTCの扱いはLinux（UTC）とWindows（ローカル時刻）で違う
• NTPが合わせるのはシステムクロック。社内の時刻も、たどれば原子時計に行き着く

次回は、NTPがネットワーク越しにどうやって時刻のずれを測り、どう直すのかを扱います。

---

連載「NTP入門」全11回

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