「うるう秒が廃止され、うるう時間に移る」と聞くと、近い将来、世界の時計がまるご1時間飛ぶように感じるかもしれません。しかし、2026年8月24日時点の正確な状況は少し違います。
「秒単位の不連続な調整を終わらせる」方向は国際的に決定済みです。一方、2027年5月20日から連続UTCにすることと、地球自転時UT1とUTCの差を最大3,600秒（1時間）まで許容することは、2026年10月の国際度量衡総会（CGPM）で採決される「決議案」です。まだ最終決定ではありません。
何が決まり、何がまだ決まっていないのか
地球の自転による時間がUT1、原子時計を基礎に世界で共通利用する時間がUTCです。自転速度は一定ではないため、両者の差が0.9秒に近づくと、IERSがうるう秒を告示してきました。1972年以降に実施されたのは、すべて「正のうるう秒」で、合計27回です。
| 時点 | 内容 | 公開日現在の位置づけ |
|---|---|---|
| 2022年 | CGPM決議4で、UT1−UTCの最大値を2035年までに引き上げると決定 | 決定済み |
| 2026年1月 | 連続UTCを2027年5月20日に開始し、|UT1−UTC|の上限を3,600秒とする案を公表 | 決議案 |
| 2026年10月13〜15日 | ヴェルサイユの第28回CGPMで審議 | これから |
| 2026年12月末 | IERS Bulletin C 72は「うるう秒なし」と告示 | 告示済み |
なぜ「たった1秒」がITシステムを止めるのか
人間にとっては1秒でも、コンピュータにとっては「あるはずのない時刻ラベル」です。正のうるう秒では 23:59:60 が現れます。一方、負のうるう秒が実施されると、23:59:58 の次が 00:00:00 になります。
NTPの仕様には「最後の1分が61秒」と「59秒」の両方を通知するビットがあります。つまりプロトコル上は負のうるう秒も想定されています。難しいのは、その通知を受け取ったOS、データベース、ジョブ管理、ログ収集、分散ストレージが同じ方法で処理するとは限らないことです。
具体的な破綻パターン
- 負の経過時間：
end - startが負になり、範囲を前提にした関数が異常終了する。 - ログの重複・欠落：同じタイムスタンプのイベントが並ぶ、または存在しない時刻に予約されたジョブが飛ぶ。
- 分散ノード間の不一致：一部がステップ、一部がスミアで処理すると、同じ「UTC」を名乗りながら一時的に時刻が異なる。
- 一意制約・並び順：タイムスタンプだけを一意キーやイベント順序に使う設計が破綻する。
Metaの技術ブログは、2012年のReddit障害で高分解能タイマーの問題からCPUが過活性化した例、2017年のCloudflare DNS障害で「時間は戻らない」という前提から負の引数を関数に渡して停止した例を紹介しています。ただし、「うるう秒なら必ず障害が起きる」のではありません。問題は、日常のテストではほぼ発生しない例外だからこそ、組み合わせの穴が本番時に見つかることです。
Leap Smearは解決策だが、世界共通ではない
Googleは、うるう秒の1秒を24時間に広げ、時計をわずかに遅くまたは速く進める「Leap Smear」を使っています。正のうるう秒なら急に1秒増やす代わりに、24時間の各秒を約11.6マイクロ秒ずつ長くします。
スミアは「不連続を貸し切りする」実用的な方法ですが、Googleとそれ以外で広げる時間や形が異なる場合があります。Google Public NTPも、スミアしないNTPサーバーと混ぜて設定しないよう注意しています。
地球の自転はなぜ速くなったり遅くなったりするのか
地球は剛体の球ではありません。大気、海洋、地下水、氷床、マントル、液体鉄の外核が動き、角運動量をやり取りしています。短期には風や海流、季節的な気圧変化、数十年単位では外核の流れ、長期には月による潮汐摩擦が日の長さを変えます。
NASAが2024年に紹介した研究では、陸上の氷が溶けて海へ移ると質量が極から低緯度側に移り、フィギュアスケート選手が腕を広げた時のように自転が遅くなると説明されています。
ここで少しややこしいのが「負のうるう秒」の予測です。2024年のNature論文は、地球の外核などの傾向から、現在のUTC定義を続ければ2029年に負のうるう秒が必要になると予測しました。極域の氷の融解が自転を遅くする分、必要時期を従来見通しの2026年から3年後ろにした、という結果です。ただしこれは予測であり、負のうるう秒が2029年に告示されたわけではありません。
「うるう時間」は、100年後に時計を1時間飛ばす話なのか
現在の決議案の中心は「大幅調整の日程」ではなく、UT1とUTCの差の許容上限を0.9秒から3,600秒へ広げることです。BIPMの決議案は、これでUTCを数百年にわたって連続させられるとしています。
「数年ごとに1秒だけ時計を例外動作させる」のをやめ、天文時との差を長期間貯めるということです。将来、夏時間やタイムゾーン変更のように1時間調整する可能性は議論されていますが、その方法と日程はまだ決まっていません。
連続UTCでIT運用はどう変わるか
エンジニア側が今やるべき5項目
- 経過時間、タイムアウト、リトライは「単調増加クロック」で計測する。
- UTCのwall clockは「発生した時刻の表示」に使い、順序は連番や論理時計で補う。
- 社内のNTP・PTP・GNSSとクラウドのスミア方式を文書化し、異なる方式を混在させない。
- 移行日が正式決定するまでは、61秒の1分と59秒の1分をテスト項目から外さない。
- 2026年10月のCGPM決議と、半年ごとのIERS Bulletin Cを継続確認する。
視覚的に知りたい人へ
ご提供いただいた動画は、負のうるう秒がなぜ技術者にとって未経験の問題なのかを視覚的に確認するのに役立ちます。なお、タイトルの「From 2026」は当時の予測です。現在はNature論文の2029年予測と、2026年CGPMの連続UTC決議案を併せて読むのが正確です。
まとめ
- うるう秒を終わらせる方向は、2022年に国際合意済み。
- 2027年5月20日から連続UTC、UT1との差を最大1時間まで許容することは、2026年10月に審議される案。
- 負のうるう秒は時間を過去に戻すのではなく、23時59分59秒を飛ばす。未実施なためシステム実装の不確実性が大きい。
- 「うるう時間」は定期的な1時間ジャンプの決定ではなく、天文時とUTCの差を長期間蓄積する構想。
- IT運用では、時刻表示用クロックと経過時間用クロックを分けることが基本。
公式・一次出典
- BIPM：CGPM Resolution 4 (2022)
- BIPM：Draft Resolutions – 28th meeting of the CGPM
- BIPM：28th meeting of the CGPM (2026)
- IERS：Bulletin C 72
- Google for Developers：Leap Smear
- RFC 8633：Network Time Protocol Best Current Practices
- Meta Engineering：It’s time to leave the leap second in the past
- Nature：A global timekeeping problem postponed by global warming (2024)
- NASA：How Climate Is Changing Earth’s Rotation
※本記事は2026年8月24日時点の公式発表と論文にもとづきます。2026年10月のCGPMで決議案が変更・否決される可能性があります。
コメント