LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

うるう秒が入った日に、ログの時刻が前後して集計が合わなくなった。最近はうるう秒の話を聞かないが、もう気にしなくてよいのか分からない——。サーバーの時刻を扱う現場では、こうした疑問がよく出てきます。うるう秒とは、原子時計で刻む時刻と地球の自転に基づく時刻のずれが大きくなりすぎないよう、協定世界時（UTC）に1秒を挿入または削除する調整のことです。

前回の挿入は2017年1月1日です。それ以降は行われていませんが、ログの順序や時刻同期の設定には今も影響が残り、うるう秒をやめる時期を決める議論も大詰めを迎えています。本記事では、システムの開発・運用の担当者に向けて、うるう秒の仕組み、システムへの影響と対処の方式、廃止に向けた動き、そして外部に頼むときに確認したい点を整理します。

うるう秒とは

うるう秒には3つの時刻が関わります。TAI（国際原子時）は、各地の原子時計をもとに国際度量衡局（BIPM）が計算する時刻です。UT1（世界時）は地球の自転の角度から求める時刻で、自転の速さが揺らぐぶん1日の長さも変わります。UTCは、TAIと同じ速さで進み、TAIとの差を整数の秒に保つ時刻です。

UTCとUT1の差は少しずつ開いていきます。この差が0.9秒以内に収まるよう、必要になったときにUTCへ1秒を足し引きするのがうるう秒です。^*1 実施を決めるのはパリ天文台にあるIERS（国際地球回転・基準系事業）の地球回転センターで、日本ではNICT（情報通信研究機構）がその決定を受けて日本標準時に反映します。

制度が始まった1972年の時点で、TAIとUTCの差は10秒でした。その後うるう秒が入るたびに差が広がり、2017年1月1日からは37秒になっています。^*2 これまでに入ったうるう秒は27回で、すべてUTCに1秒を足す調整でした。直近の5回は次のとおりです。

日本標準時はUTCより9時間進んでいるため、UTCの23時59分60秒は日本の午前8時59分60秒にあたります。2017年の例では、1月1日の午前8時59分59秒と9時00分00秒のあいだに「8時59分60秒」が挿入されました。^*1 日本では、うるう秒は元日や7月1日の朝に起きる出来事です。

うるう秒の仕組み

IERSは半年ごとに「Bulletin C」という通知を出し、次の6月末か12月末にうるう秒を入れるかどうかを知らせます。2026年7月6日付のBulletin C 72は、2026年12月末にはうるう秒を入れないと告げており、UTCとTAIの差は37秒のままです。^*3 これまでに使われた日は、6月末と12月末だけです。

決定はコンピューターにも届く形で配られます。NTP（ネットワーク経由で時刻を合わせる通信規約）のパケットにはLI（Leap Indicator）という2ビットの欄があり、その月の最後の1分が61秒になるか59秒になるかを前もって伝えます。^*4

もう一つの経路が、うるう秒の一覧ファイルです。IERSが公開している leap-seconds.list には、過去のうるう秒とTAIとの差に加えて、ファイルの有効期限が書かれています。いま公開されている版の期限は2027年6月28日です。^*2 Linuxのタイムゾーン定義 right/UTC もうるう秒の情報を持ち、chronyはこれを読んで次のうるう秒を知ることができます。

NTPの全体の構成やサーバーの選び方は「NTPの仕組み」で扱っています。UTCと各地の時刻の関係は「タイムゾーンとUTCとは？日時設計の基本を解説」も参考になります。

システムへの影響

影響の根っこは、多くのコンピューターが使うUnix時間（1970年1月1日0時UTCからの経過秒数）が、うるう秒を数えない点にあります。Pythonの公式ドキュメントも、WindowsとほとんどのUnix系システムでは、うるう秒がこの秒数に含まれないと説明しています。^*5 Unix時間の上では1日は常に86,400秒で、23時59分60秒という時刻は表せません。

表せない1秒をどう処理するかで、起きることが変わります。Linuxのカーネルに任せる方式では、うるう秒の直後の0時0分0秒に時計が1秒戻り、23時59分59秒台が2回現れます。その間のログは時刻で並べると前後が入れ替わり、終了時刻から開始時刻を引くと経過時間が負になることもあります。

import time
from datetime import datetime

try:
    datetime(2016, 12, 31, 23, 59, 60)
except ValueError as e:
    print(e)  # second must be in 0..59

# 経過時間は monotonic で測る
start = time.monotonic()
run_batch()
elapsed = time.monotonic() - start

Pythonの datetime は秒に60を受け付けません。time.monotonic() は後戻りせず、時計の調整にも左右されない時計です。処理時間やタイムアウトを time.time() で測ると、うるう秒や時刻の補正で値が狂います。待ち時間の決め方は「タイムアウト設計とは」で扱っています。

負のうるう秒の問題もあります。国際度量衡総会の2022年の決議は、地球の自転の観測から初めての負のうるう秒が必要になる可能性を示し、その挿入は想定されたことも試されたこともないと述べています。^*6 1秒を削る場合は23時59分59秒が飛ばされます。

ステップとスミアの違い

うるう秒への対処は、大きくステップとスミアに分かれます。ステップは時計を1秒だけ一気に戻す方式で、スミアは前後の長い時間をかけて時計の進みをわずかに変え、1秒を少しずつ吸収する方式です。時刻が後戻りしない代わりに、その間はUTCから0.5秒ほどずれることがあります。

Linuxで広く使われるchronyでは、leapsecmode という設定で次の4つから方式を選びます。^*7

• system：カーネルが0時0分0秒に時計を1秒戻す。カーネルがうるう秒に対応していれば、これが既定
• step：chronyd自身が時計を1秒戻す。カーネル側の不具合を避けたいときに使う
• slew：時計の進みを調整して1秒を取り戻す。時刻の飛びを嫌うアプリケーション向けで、既定の上限値のLinuxでは補正に12秒かかる
• ignore：うるう秒では何もせず、その後の通常の補正に任せる

Googleは2008年から自社のサーバーでスミアを使っており、UTCの正午から翌日の正午までの24時間をかけて直線的に1秒を吸収する方式を標準として提案しています。^*8 この間の時計の速さの変化は約11.6ppm（100万分の11.6）で、AmazonもAWSで同じ方式を使っているとされます。下の図は、スミアした時計とUTCとの差の動きです。

うるう秒の直前、スミアした時計はUTCより0.5秒弱遅れています。UTCに1秒が挿入された直後には、逆に0.5秒弱進んだ状態になります。そこから12時間かけて差を縮め、翌日の正午にUTCと一致します。自社のNTPサーバーでスミアをする場合、chronyの説明書は次のような設定を推奨例として示しています。

# /etc/chrony.conf（NTPサーバー側でスミアする例）
leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001024 leaponly

# クライアント側で、うるう秒の予告が届いているかを見る
$ chronyc tracking | grep "Leap status"
Leap status     : Normal

chronyc tracking の Leap status 欄は通常 Normal で、予告が届くと Insert second や Delete second に変わります。うるう秒が決まった年に全サーバーでこの欄を見ておくと、予告が届いていない機器を見つけられます。

廃止に向けた動き

2022年の第27回国際度量衡総会（CGPM）は決議4で、うるう秒による時刻の不連続が、衛星測位システム（GNSS）、通信、送電といった重要な基盤で深刻な誤作動を招くおそれがあると指摘しました。そのうえで、UT1とUTCの差の上限を2035年まで、またはそれより前に引き上げると決めています。^*6 上限を大きく広げればうるう秒は要らなくなるため、この決定は「うるう秒の廃止」と呼ばれています。

具体的な日付は、2026年10月13日から15日にかけて開かれる第28回総会で審議されます。BIPMが公開している決議案Cは、連続したUTCを2027年5月20日から有効とし、UT1とUTCの差の上限を3,600秒（1時間）とする内容です。^*9 決議案は、2025年3月に開かれた専門家の会合が、負のうるう秒が必要になる確率は2035年までに30％に達すると見積もったことを挙げ、前倒しの理由の一つにしています。^*9

決議案Cは、電波で時刻を配る機器について、国際電気通信連合（ITU）の決議655が2035年まで、遅くとも2040年までの移行期間を認めていることも引いています。

決議案が採択されても、うるう秒を含む過去の記録は残ります。新たなうるう秒が入らなければTAIとUTCの差は37秒のまま固定され、過去の時刻を秒の単位で計算し直す処理は、この先も続きます。

つまずきやすい点

1つ目は、スミアする時刻源とスミアしない時刻源を混ぜて参照することです。chronyの説明書は、スミアするサーバーに同期させるクライアントは、まったく同じ方法でスミアするサーバーだけを使うよう注意を促しています。社内のNTPサーバーとクラウドの時刻同期サービスを両方参照すると、うるう秒の前後で参照先どうしが0.5秒近く食い違い、補正が不安定になります。

2つ目は、システムごとに方式がばらばらなことです。ログを突き合わせるシステムの一方がステップ、もう一方がスミアで動いていると、同じ出来事の記録がうるう秒の前後で0.5秒近くずれます。どの方式で時計を合わせているかを設計書に書いておくと、障害の調査でログを並べるときに迷いません。

3つ目は、試験のしにくさです。うるう秒の予告はおよそ半年前で、本番の時刻を動かして試すこともできません。時刻を自由に設定できる検証環境で、時計が1秒戻ったときと1秒飛んだときのバッチの動きを確かめておきます。

4つ目は、うるう秒の情報の更新漏れです。chronyの説明書によると、right/UTC のタイムゾーン情報からうるう秒を知る設定では、うるう秒の少なくとも12時間前までに情報を更新しておく必要があります。^*7 この更新を、OSの定期更新とあわせて運用手順書に入れておきます。

外部に委託するときに確認しておきたい点

時刻同期は、要件定義で話題に上りにくい項目です。開発や保守を外部に頼むときは、次の点を提案書や設計書で確かめておきます。

• 各サーバーとクラウドが参照する時刻源と、その時刻源がスミアするかどうか
• chronyなどのうるう秒の設定値と、その値を選んだ理由
• 処理時間やタイムアウトを、単調に増える時計で測っているか
• ログの時刻にタイムゾーンと秒未満の桁を持たせ、同じ時刻の記録を連番などで並べられるか
• 時計の後戻りや1秒の飛びを、検証環境で試したか
• 連続したUTCへ移った後も、過去の時刻の計算が正しく動くか

複数の事業者が関わる構成では、時刻の方針を誰がまとめるのかを先に決めておきます。方式を担当ごとに決めると、うるう秒の前後で記録が合わない原因になります。保守契約の範囲に、時刻同期の設定の見直しやタイムゾーン情報の更新が含まれているかも確かめておきます。

まとめ：うるう秒で確かめておきたい3つの点

うるう秒にシステムで備えるうえで、確かめておきたい点は3つに整理できます。第一に、OSやNTPの設定がうるう秒をステップとスミアのどちらで処理するのかを把握し、参照先の方式をそろえること。第二に、経過時間の計測やログの並べ替えを壁時計の時刻だけに頼らないこと。第三に、2026年10月の国際度量衡総会の結果を確かめ、連続したUTCへ移るまでの計画を立てておくことです。この3点を踏まえておけば、「数年ぶりの1秒のせいで、元日の朝に集計が合わなくなった」という事態を避けやすくなります。時刻同期の設計や検証に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：総務省・情報通信研究機構「『うるう秒』挿入のお知らせ」（2016年7月8日）（https://www.nict.go.jp/press/2016/07/08-1.html）。出典：NICTの報道発表。2017年1月1日午前8時59分59秒と9時00分00秒のあいだに8時59分60秒を挿入したこと、原子時計に基づく時刻と天文時のずれを0.9秒以内に収める調整であることを参照（2026年10月確認）
2. *2　参考：IERS「leap-seconds.list」（https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list）。出典：IERS地球回転センターが公開するうるう秒の一覧。1972年のTAIとUTCの差10秒から2017年1月1日の37秒までの各回、候補日の説明、ファイルの有効期限（2027年6月28日）を参照（2026年10月確認）
3. *3　参考：IERS「Bulletin C 72」（2026年7月6日）（https://datacenter.iers.org/data/latestVersion/bulletinC.txt）。出典：2026年12月末にうるう秒を入れないこと、2017年1月1日以降のUTC−TAIが−37秒であることを参照（2026年10月確認）
4. *4　参考：IETF「RFC 5905 Network Time Protocol Version 4」（https://www.rfc-editor.org/rfc/rfc5905）。出典：NTPパケットのLeap Indicator（2ビット）の値と意味（Figure 9）を参照（2026年10月確認）
5. *5　参考：Python Software Foundation「time — Time access and conversions」（https://docs.python.org/3/library/time.html）。出典：Unix時間がうるう秒を数えないこと、time.monotonic() が後戻りせずシステムの時計の調整を受けないこと、CLOCK_TAIに最新のうるう秒の表が要ることを参照（2026年10月確認）
6. *6　参考：BIPM「Resolution 4 of the 27th CGPM (2022) On the use and future development of UTC」（https://www.bipm.org/en/cgpm-2022/resolution-4）。出典：うるう秒による不連続が重要な基盤に誤作動を招くおそれ、負のうるう秒が想定も試験もされていないこと、UT1−UTCの上限を2035年まで、またはそれより前に引き上げる決定を参照（2026年10月確認）
7. *7　参考：chrony「chrony.conf(5) Manual Page」（4.5）（https://chrony-project.org/doc/4.5/chrony.conf.html）。出典：leapsecmode の4つの方式、slewの補正時間、スミアの推奨設定、スミアするサーバーだけを参照する注意、leapsectz の更新期限（12時間前）を参照。Leap status の値は chronyc(1) の説明による（2026年10月確認）
8. *8　参考：Google「Leap Smear — Google Public NTP」（https://developers.google.com/time/smear）。出典：2008年からのスミアの運用、正午から正午までの24時間の直線的なスミア、約11.6ppmの速さの変化、うるう秒の前後で約0.5秒ずれること、AWSでの採用を参照（2026年10月確認）
9. *9　参考：BIPM「Draft Resolutions — 28th meeting of the CGPM」（https://www.bipm.org/en/cgpm-2026/documents）。出典：決議案C（連続したUTCを2027年5月20日から有効、UT1−UTCの上限3,600秒、2035年までに負のうるう秒の確率30％、ITUの決議655の移行期間）を参照。総会の会期（2026年10月13〜15日）はBIPMの第28回総会のページによる（2026年10月確認）

Tweet