Googleが「うるう秒」を回避するために行っている、時間を1ミリ秒ずつ引き伸ばす「ドロップ」技術とは
(本記事の文字数：約9,400文字)
あなたのスマートフォンには「23時59分60秒」という時刻が表示されたことがあるだろうか。答えはほぼ確実に「ない」だろう。しかし、この「存在してはいけない時刻」は、1972年以降、合計27回にわたって世界中の標準時に挿入されてきた。これが「うるう秒」である。
うるう秒とは、原子時計が刻む精密な時間（国際原子時：TAI）と、地球の自転に基づく天文時（UT1）のズレを補正するために、協定世界時（UTC）に1秒を加える（あるいは理論上は減らす）調整のことだ。地球の自転は一定ではない。潮汐摩擦によって100年あたり約2.3ミリ秒ずつ1日の長さが延びているほか、地殻変動、海流、大気の変化など、さまざまな要因で日々微妙に揺らいでいる。
この「たった1秒」の調整が、現代のデジタルインフラにとって巨大な脅威となっている。そして、その脅威に対してGoogleが編み出した解決策が「リープスミア（Leap Smear）」と呼ばれる、時間を少しずつ引き伸ばす巧妙な技術なのだ。
第1章：1秒が引き起こした大混乱——2012年の惨劇
2012年7月1日、UTC 23時59分59秒と翌日00時00分00秒の間に、1秒が挿入された。日本時間では朝の8時59分60秒。この瞬間、世界中のインターネットサービスが次々と崩壊した。
Reddit、LinkedIn、Yelp、FourSquare、Gawker、StumbleUpon——名だたるサービスが障害に陥った。Redditは公式Twitterで「午後5時（PST）のうるう秒に関連したJava/Cassandraの問題が発生している」と報告。Mozilla（Firefoxの開発元）でも障害が起きた。オーストラリアのカンタス航空に至っては、フライト予約システムが2時間にわたってダウンするという事態に見舞われた。
障害の原因は、Linuxカーネルのうるう秒処理にあった。Linuxは23時59分60秒を直接表現できないため、00時00分00秒の直後に時計を1秒戻すことでうるう秒を挿入する。この「時間の逆行」が、スレッド管理に関するバグを引き起こし、サーバーのCPU使用率を異常に跳ね上げた。最新のカーネルバージョンでもこの不具合が発生したことが、事態の深刻さを物語っている。
具体的には、Linuxカーネルのhrtimer（高解像度タイマー）サブシステムが、時刻の逆行を検知した際に無限ループに陥るという現象が発生した。Javaの実行環境も影響を受け、Apache Cassandraデータベースを使用していた多くのサービスで、スレッドが100パーセントのCPU使用率でスピンし続けるという状態になった。技術者たちは、サーバーを再起動することでしか復旧できなかった。
2016年末のうるう秒でも被害は続いた。Cloudflareでは、DNSサーバーが「時間は後ろに進むことはない」という前提のもとに設計されていたために、年明け直後の数時間にわたってサービスが中断した。同社の技術責任者ジョン・グラハム＝カミング氏は、原因が「時刻が巻き戻ったかのような状況」にあったと認めている。
Cloudflareのケースでは、Go言語で書かれたDNSサーバーのコードが、時刻の単調増加性を前提としていた。うるう秒による1秒の巻き戻しが発生すると、タイムスタンプの比較処理でパニックが発生し、DNSクエリの処理が停止した。同社は事後の分析で、全世界のDNSクエリの約0.2パーセントに影響があったと報告している。この「わずか0.2パーセント」が、実際には数百万件のDNSリクエストの失敗を意味していた。
1秒。たった1秒で、インターネットの基盤が揺らぐ。この事実は、私たちのデジタル社会がいかに「時間が前に進み続ける」という前提の上に成り立っているかを鮮やかに示している。
第2章：Googleが体験した「2005年の教訓」
Googleがこの問題を最初に深刻に受け止めたのは、2005年のうるう秒のときだった。当時のGoogleサイト信頼性エンジニアであるクリストファー・パスコー氏は、こう振り返っている。「2005年のうるう秒の際に、いくつかのクラスタシステムが小規模ながら作業の受け入れを停止した。サイト自体やデータには影響がなかったが、将来の問題を防ぎたかった。」
Googleのような超大規模分散システムでは、時刻同期が命綱だ。数十万台のサーバーが世界中に散らばり、1秒間に数百万件のリクエストを処理している。これらのサーバー間で「いま何時か」がずれていたら、データの整合性は崩壊する。メールの受信順序が狂う。データベースのトランザクションが破綻する。検索結果のランキングすら不正確になりかねない。
Googleの分散データベース「Spanner」は、外部整合性（external consistency）という厳格な保証を提供している。これは、トランザクションAがトランザクションBより前に完了したなら、AのタイムスタンプはBより必ず小さくなるという保証だ。この保証を実現するために、SpannerはTrueTime APIという独自の時刻管理システムを使用している。TrueTimeは、現在時刻を単一の値ではなく、誤差範囲を含む区間として表現する。各データセンターには原子時計とGPS受信機が設置され、時刻の不確実性を数ミリ秒以内に抑えている。
そしてGoogleのサービスは、設計思想として「時刻が正しくなければ動作を拒否する」ように作られていた。つまり、うるう秒によって1秒でも時計がおかしくなれば、システムが自分自身を止めてしまう。これは安全装置として正しい設計だが、うるう秒という「正しい異常」には対応できない。
2005年の経験から、Googleのエンジニアたちは重大な結論に達した。「うるう秒に対応するために、何万行ものコードを修正し、何千ものサービスをテストするよりも、時計そのものを変更する方が合理的だ」と。
2008年、Googleは世界で初めてリープスミアを実装し、本番環境に投入した。当時のエンジニアリングチームは、この技術を「最もエレガントな回避策」と評した。なぜなら、アプリケーション層のコードには一切手を加えることなく、インフラ層の時刻管理だけで問題を解決できたからだ。
2005年の苦い経験を経て、Googleのエンジニアたちは画期的な解決策を考案した。その名も「リープスミア（Leap Smear）」。直訳すれば「うるう秒の塗り広げ」だ。
第3章：リープスミアの仕組み——1秒を86,400等分する魔法
リープスミアの基本的なアイデアは、驚くほどシンプルだ。「1秒をいきなり追加するのではなく、長い時間をかけて少しずつ時計を遅くすることで、いつの間にか1秒分を吸収してしまう」というものである。
Googleは当初、うるう秒の前後10時間ずつ、合計20時間にわたって時計の速度を0.0014パーセント遅くするという方式を採用していた。2008年、2012年、2015年、2016年のうるう秒でこの20時間スミアが使われた。
その後、AmazonのAWSなど他の大手クラウドプロバイダーとの互換性を確保するため、Googleは24時間リニアスミアに移行した。現在の方式は次のとおりだ。
スミア開始時刻はうるう秒の日のUTC正午（12時00分00秒）、スミア終了時刻は翌日のUTC正午（12時00分00秒）。スミア方式は24時間にわたる線形（リニア）スミアである。
具体的にどうなるか。通常、1日は86,400秒だ。リープスミアでは、この86,400秒のそれぞれを約11.6マイクロ秒（μs）ずつ引き伸ばす。1秒÷86,400≒11.574マイクロ秒という計算だ。つまり、スミア期間中の「Googleの1秒」は、本来の1秒よりも0.00116パーセントだけ長い。
この周波数変化は約11.6ppm（百万分の11.6）。これは、一般的なコンピュータに搭載されている水晶発振器の製造誤差や温度変動による揺らぎ（数十ppm程度）の範囲内に収まる数値だ。NTPプロトコルの最大スルーレート（500ppm）と比べればはるかに小さい。つまり、時計を監視するソフトウェアから見ても、「ちょっと時計がゆっくりだな」程度の変化にしか見えない。
スミアの途中経過を見てみよう。うるう秒の瞬間（UTC 23時59分60秒）、Googleのスミア時計はUTCより約0.5秒遅れている。そこでUTCが1秒をジャンプ挿入する。すると、スミア時計は逆にUTCより約0.5秒進んだ状態になる。そして残りのスミア期間で徐々にその差を詰めていき、翌日正午にはUTCと完全に一致する。
技術的には、Googleは自社のNTPサーバー群（time.google.com）にリープスミアを実装している。世界中に分散配置されたこれらのNTPサーバーは、ストラタム1（最上位階層）の原子時計から直接時刻を取得し、スミアアルゴリズムを適用した時刻をクライアントに配信する。Google Cloudのユーザーは、何も設定を変更することなく、自動的にスミア時刻の恩恵を受けられる。
この方式が優れているのは、スミア期間中もスミア期間外も、時計は常に前に進み続けるという点だ。時間の逆行もない。61秒の分もない。23時59分60秒という存在しない時刻もない。Googleのサーバーにとっては、うるう秒の日はまったく普通の日と何も変わらない。
Googleサイト信頼性エンジニアリングチームの間では、このリープスミアは「最もクールな回避策のひとつ」として語り継がれているという。なぜなら、この仕組みのおかげで、Googleの巨大なコードベース全体を検査・修正するという途方もない作業から解放されたからだ。
実際、Googleのコードベースは数十億行に及ぶとされている。その全てでうるう秒対応を検証することは事実上不可能だ。リープスミアという「時計側の解決策」が、この不可能を可能にした。
第4章：スミアは「嘘の時間」か？——法的・技術的な論点
リープスミアは万能ではない。スミア期間中、Googleの時計はUTCと最大で約0.5秒ずれる。これは「Googleの時計は嘘をついている」とも言える状態だ。
法的な問題も指摘されている。多くの国では、通信料金の課金や金融取引のタイムスタンプは「正確なUTCまたはそれに基づく法定時」に基づくことが求められている。スミア時計のタイムスタンプは、厳密にはUTCではない。携帯電話の通話課金が秒単位で行われるシステムでは、0.5秒のずれが理論上は課金の不正確さにつながる可能性がある。
金融業界では、この問題はさらに深刻だ。株式取引では、注文のタイムスタンプが1ミリ秒違うだけで、何百万ドルもの利益が変わることがある。高頻度取引（HFT）を行う企業は、マイクロ秒（100万分の1秒）単位で時刻を管理している。彼らにとって、0.5秒のずれは致命的だ。
そのため、金融機関の多くは、リープスミアを使用せず、うるう秒を正確に処理する独自のNTPインフラを維持している。米国の証券取引委員会（SEC）は、取引所に対して、タイムスタンプの精度を50マイクロ秒以内に保つことを義務付けている。この基準を満たすため、取引所は原子時計やGPS時刻源を直接使用し、スミアは適用しない。
また、スミアの方式が統一されていないという問題もあった。Googleが20時間スミアを使っていた時期に、Bloombergは2,000秒（約33分）のスミアを、UTC-SLSは1,000秒のスミアをそれぞれ独自に採用していた。異なるスミア方式を使うNTPサーバーを混在させると、サーバー間の時刻が最大1秒もずれるという本末転倒な事態が起こりうる。
この問題に対処するため、Googleは2018年に「24時間リニアスミア」を業界標準として提唱し、AmazonのAWSも同じ方式を採用した。AWSのブログでは、「24時間リニアスミアは、クラウド環境における最も実用的なうるう秒対策」と明記されている。
さらに、Googleはスミア時計とTAI（国際原子時）やGPS時刻との間で精密な変換を行うオープンソースライブラリ「unsmear」をGitHubで公開している。このライブラリを使えば、スミア時刻から真のUTCやTAI、GPS時刻への変換が、マイクロ秒精度で可能だ。ライブラリには、過去のすべてのうるう秒とスミア方式の履歴が記録されており、任意の時点でのスミア量を計算できる。
このライブラリの存在が示すのは、リープスミアが単なる「ごまかし」ではなく、精密に定義され、可逆的な時間変換であるということだ。
Googleの公式ドキュメントにはこう記されている。「スミアは時計を漠然と汚す方法ではない。それは定義された、精密な、可逆的な変換である。」
第5章：地球が加速している——予想外の逆転劇
ここまでの話は、すべて「正のうるう秒」——時間を1秒追加する方向の話だった。1972年以来27回のうるう秒は、すべて正の方向だった。地球の自転は潮汐摩擦によって長期的に遅くなり続けているのだから、これは当然のことだと思われていた。
ところが、2020年に異変が起きた。
2020年、地球は1960年以来の記録で最も短い日を28回も更新した。7月19日には、86,400秒より1.4602ミリ秒も短い自転周期を記録。2022年6月29日には、さらにそれを上回る1.59ミリ秒短い日が観測された。地球の自転が、なぜか加速し始めたのだ。
国際地球回転・基準系事業（IERS）は、地球の自転速度を毎日測定している。その測定手法は、遠方のクエーサー（準恒星状天体）からの電波を、世界各地の電波望遠鏡で同時観測する超長基線電波干渉法（VLBI）だ。この方法により、地球の自転角度を0.00001秒の精度で測定できる。
IERSのデータによれば、2020年から2022年にかけて、地球の1日の長さは平均的に86,400秒より約0.5ミリ秒短くなった。これは統計的に有意な変化であり、観測史上初めて「負のうるう秒」の必要性が現実味を帯びた瞬間だった。
この原因は完全には解明されていない。地球内部のコアの運動、チャンドラー揺動（地球の自転軸のふらつき）の消失、海流や大気パターンの変化など、複数の仮説が提唱されている。興味深いことに、2024年にスクリップス海洋研究所のダンカン・アグニュー氏がNature誌に発表した論文では、地球温暖化による極地の氷の融解が赤道付近に水を移動させ、地球の自転を遅くする方向に働いていると指摘されている。つまり、温暖化がなければ、地球はもっと速く回っており、すでに「負のうるう秒」が必要になっていた可能性があるのだ。
アグニュー氏の論文では、グリーンランドと南極の氷床が年間約2,800億トン減少しており、この水が海洋に移動することで、地球の慣性モーメントが変化していると分析されている。フィギュアスケート選手が腕を広げると回転が遅くなるように、質量が地球の中心から離れると自転は遅くなる。温暖化がこの効果を生み出し、地球の自然な加速を打ち消しているというのだ。
負のうるう秒とは、23時59分58秒の直後に00時00分00秒がくる——つまり23時59分59秒が消滅する——という史上初の事態だ。正のうるう秒ですらこれだけの大混乱を引き起こしてきたのに、「1秒を削除する」という未知の操作がどのような影響を及ぼすかは、誰にもわからない。
Metaのエンジニアたちは公式ブログでこう警告した。「負のうるう秒の影響は大規模にテストされたことがない。タイマーやスケジューラーに依存するソフトウェアに壊滅的な影響を与える可能性がある。」
実際、多くのシステムは負のうるう秒を想定していない。NTPのプロトコル仕様書には負のうるう秒の処理方法が記載されているが、実装されたことは一度もない。データベースのタイムスタンプ処理、ログファイルの時系列解析、暗号証明書の有効期限検証——これらすべてで、未検証のコードパスが実行されることになる。
もしGoogleのリープスミアが負のうるう秒に対応するとしたら、時計を11.6マイクロ秒ずつ「速く」する方向にスミアをかけることになる。86,399秒のSI秒を使って、正午から正午の24時間で1秒分を吸収する。理論上は同じロジックが適用可能だが、実際に試されたことはまだない。
Googleのエンジニアたちは、負のうるう秒が発表された場合に備えて、既にテスト環境でシミュレーションを行っていると報告されている。しかし、本番環境での実証は、実際に負のうるう秒が挿入されるまで不可能だ。
第6章：うるう秒の終焉——2035年に向けて
2022年11月18日、フランスで開催された第27回国際度量衡総会（CGPM）で、歴史的な決議が採択された。「2035年までに、うるう秒の挿入を廃止する」というものだ。
BIPMの時間部門長であるパトリツィア・タヴェッラ博士は、この決定を「歴史的」と評した。59の加盟国の代表が投票し、アメリカとフランスが廃止を主導。ロシアは「原則として反対ではないが、GLONASSの対応に時間が必要」として2040年への延期を求めたが、2035年が妥協点として決まった。
廃止後、原子時計と天文時のずれは「1秒以上」に拡大することが許容される。具体的な上限値は2026年の第28回CGPMで決定される予定だ。有力な案は、ずれが1分に達するまで放置し（50から100年かかると予測されている）、その時点で「うるう分」を挿入するというものだ。
この決定に至るまでには、10年以上の議論があった。2012年の世界無線通信会議（WRC-12）では、うるう秒廃止案が提出されたが、合意に至らなかった。天文学者たちは、UTCと天文時の結びつきを重視し、廃止に反対した。しかし、2012年と2016年のうるう秒障害を経て、情報技術側の危機感が高まった。
2025年現在、この廃止決定を強く後押ししたのは、Google、Meta、Amazon、Microsoftといったテック大手だった。彼らにとって、不規則に挿入され、6ヶ月前にしか予告されず、あらゆるシステムに潜在的な障害を引き起こすうるう秒は、まさに「時限爆弾」だったのだ。
Metaは公式ブログで、「うるう秒は、現代の分散システムにとって避けられないリスクであり、リープスミアのような回避策はあくまで応急処置に過ぎない。根本的な解決は廃止しかない」と主張した。
ある試算では、1回のうるう秒がグローバル経済にもたらす直接的な損害は、低く見積もって数千万ドル、最悪の場合は1億ドル規模に達する可能性があるとされている。金融、航空、大規模インターネットプラットフォームにリスクが集中しているという。
2035年以降、UTCは原子時計に完全に従うようになる。天文学者たちは、独自の天文時系を維持し続けるだろう。しかし、私たちの日常生活と、グローバルなデジタルインフラは、原子時計の刻む均一な時間の上で動くことになる。
終章：時間は前に進む——リープスミアが教えてくれること
Googleのリープスミアは、一見すると「たった1秒」の問題に対する過剰な対応に見えるかもしれない。しかし、その背後には深い洞察がある。
現代のデジタルシステムが依存している最も根本的な前提のひとつが、「時間は一方向に、均一に流れる」というものだ。データベースのトランザクション順序、分散システムのコンセンサスアルゴリズム、暗号プロトコルの有効期限——これらすべてが、時間の単調増加性を前提としている。
リープスミアは、この前提を守るための技術だ。1秒を86,400の微小な断片に分割し、それぞれの瞬間に11.6マイクロ秒ずつ忍ばせることで、システムに「異常」を感じさせない。時間は常に前に進み続ける。
この技術が守っているのは、Google検索やGmailだけではない。Google Cloud上で動く無数のサービス、Google Public NTPを参照する世界中のサーバー、そしてその先にいる何十億人ものユーザーの日常だ。
興味深いのは、リープスミアが「技術的負債」を回避する戦略の好例でもあるという点だ。もしGoogleがリープスミアを採用せず、すべてのコードベースをうるう秒対応にしていたら、その対応コストは数千万ドルに達していただろう。そして、負のうるう秒という新たな脅威に対して、再び全コードベースの見直しが必要になっていた。
リープスミアは、この無限のメンテナンスループから脱出する方法を示した。「問題をシステムの境界面で吸収する」という設計思想だ。アプリケーション層には手を加えず、インフラ層で問題を解決する。この思想は、マイクロサービスアーキテクチャ、サービスメッシュ、サーバーレスコンピューティングなど、現代のクラウドネイティブ技術にも通底している。
2035年、もしうるう秒が本当に廃止されれば、リープスミアはその歴史的使命を終えるかもしれない。しかし、「破壊的な変化を、感知できないほど小さな変化の連続に置き換える」という思想は、ソフトウェアエンジニアリングのあらゆる場面で生き続けるだろう。
次にあなたがGoogleで検索するとき、ふと思い出してほしい。あなたが何気なく見ている時刻は、Googleのエンジニアたちが1秒の1万分の1レベルで調整し続けてきた、途方もなく精密な「嘘」かもしれないということを。
そしてその「嘘」こそが、世界中のインターネットを守っている真実なのだ。
参考文献
Google Developers「Leap Smear」公式ドキュメント 2023年
Google Cloud Blog「Making every (leap) second count with our new public NTP servers」2016年
国際度量衡局（BIPM）「うるう秒挿入履歴」1972年から2016年
Cloudflare Blog「How and why the leap second affected Cloudflare DNS」2017年
Meta Engineering Blog「It's time to leave the leap second in the past」2022年
Nature誌 Duncan Agnew「Climate change and leap second timing」2024年
第27回国際度量衡総会（CGPM）決議文書 2022年
GitHub「google/unsmear」オープンソースライブラリ 2018年
国際地球回転・基準系事業（IERS）「地球自転パラメータデータ」2020年から2024年
Amazon Web Services Blog「Handling Leap Seconds with Amazon Time Sync Service」2018年