『UNIXという1つの土台の上に、いまのiPhone・Mac・Linux・Androidが建っている』で見たUNIXは、もう1つ、あまり知られていない置き土産を残しています。いまこの瞬間の時刻の数え方です。
時刻は、1つの数字でしかない
パソコンやスマートフォンの内部では、時刻は「年・月・日・時・分・秒」という形では持たれていません。「1970年1月1日午前0時（協定世界時）から何秒経ったか」という、ただの1つの整数として持たれています。これをUnix時間（エポック秒）と呼びます。2026年のいまなら、約18億という数字です。画面に「2026年8月23日」と表示されているのは、この数字を人間が読める形に変換した結果にすぎません。
なぜ1970年なのか
始まりは、もっと早い年でした。UNIXが動き始めた1971年ごろのマニュアルには「1972年1月1日からの経過時間」を、1秒の60分の1刻みで32ビットの整数に収めると書かれています。刻みが細かい分、扱える範囲は短く、このままでは2.26年ごとに数字が一周してしまう——マニュアル自身が「これは2.26年ごとに危機を保証する」と書くほどでした。
この問題は、同じ1973年のうちに直されます。4th Edition のマニュアルでは、刻みを60分の1秒からまるごと1秒に変え、基準日を1970年1月1日に定め直しました。刻みを粗くした分、同じ32ビットで136年ぶんの範囲を扱えるようになったわけです。UNIXが実際に動き始めた時期に近い、区切りのいい年——それが1970年が選ばれた理由です。
136年で足りると思っていたのに、65年で足りなくなる
32ビットの整数は、符号（プラスかマイナスか）を示す1ビットを引くと、2の31乗（約21億）通りの数字しか表せません。 1970年から数えて約21億秒後、日本時間では2038年1月19日に、この数字は上限に達します。その1秒後、数字は最大値から一気に最小値へ折り返り、多くのシステムは1901年12月と誤って解釈します。 これが「2038年問題」です。
136年ぶんの余裕を持たせたはずが、なぜ65年ほどで足りなくなったのか。136年というのは「あと136年は大丈夫」という意味であって、「2106年まで大丈夫」という意味ではなかったからです。整数がマイナスになれないよう符号ぶんの1ビットを引くと、実際に安全に数えられるのは半分の68年、2038年までしかありません。
すでに前触れも起きています。2038年より先の日付を計算に使った時点で、この上限を超えてしまうからです。2006年には、AOLserverというWebサーバソフトが「10億秒後にタイムアウトする」という設定をしたことで、この境界を超えて誤作動しました。2022年の元日には、Microsoft Exchangeのウイルス対策エンジンが、更新バージョン番号を日付に変換する計算でこの上限を超え、新年早々スキャン機能が丸ごと止まるという事故も起きています（通称「Y2K22」）。本番の2038年を待たずに、境界の手前で先に問題が表面化する、という形の事故がすでに複数回起きているわけです。
うるう秒とは、そもそも相性が悪い
もう1つ、Unix時間には最初から組み込まれた割り切りがあります。UNIX系OSが共通で守るべき決まりごとをまとめた規格であるPOSIXの仕様では、「1日は必ず86400秒」と決め打ちされています。 ところが実際の地球の自転は一定ではなく、ずれを補正するために不定期に「うるう秒」が挿入されます。規格の前提と、現実の時間がずれる瞬間があるということです。
このずれが実際に障害を起こした例があります。2016年末から2017年始めにかけてのうるう秒で、CloudflareのDNSサーバは、うるう秒によって発生したマイナスの時間差を処理しきれずエラーを起こし、一部のDNS応答が失敗しました。Cloudflare自身が経緯を公開しています。
対策として、Googleはうるう秒を1日かけてゆっくり吸収する「leap smear（うるう秒のならし運転）」という手法を2011年から使っています。うるう秒をそのまま挿入せず、前後24時間の時刻をわずかに引き伸ばして、1秒のずれを目立たなくするやり方です。
AIエージェントの足元にも、同じ数字がある
Unix時間は、UNIXという1つのOSの中だけの話ではありません。認証に使われるJWT（JSON Web Token）という仕組みは、有効期限や発行時刻をUnix時間の秒数で表すと規格に定められています。AIエージェントがAPIを呼び出すとき、キャッシュの有効期限を確認するとき、ログに記録された時刻を並べ替えるとき——その裏側では、たいてい1970年基準の秒数が動いています。
面白いのは、Windowsだけは違う流儀を選んだことです。Windowsの内部時刻は、1601年1月1日からの100ナノ秒刻みで数えられています。同じ「基準日からの経過量で時刻を表す」という発想でありながら、選んだ基準日も刻みもまったく別なわけです。それでも、外部とやり取りする多くのAPIでは、結局Unix時間に変換して渡すことになります。
まとめ
- コンピュータの内部時刻は「年月日」ではなく、1970年1月1日からの経過秒数という1つの整数にすぎない
- 1970年が選ばれたのは、UNIXが実際に動いていた時期に近い、区切りのいい基準日だったから。当初はもっと細かい刻みで、2.26年しかもたない設計だった
- 符号付き32ビットの整数は2038年1月19日に上限を超える。2038年より先の日付を計算に使うと、本番の前に境界を超える事故が起きる——実際に2006年・2022年に起きている
- うるう秒は規格上「無いもの」として扱われ、実際に処理を誤って障害を起こした例（2016年末のCloudflare）がある
- JWTのようにAIエージェントの周辺で使われる仕組みも、たいていUnix時間の秒数の上に建っている
いま動いているAIエージェントも、その裏側でトークンの有効期限やキャッシュを管理するとき、1969年にUNIXが生まれ、1973年に基準日として選ばれた1970年1月1日からの経過秒数を、いまも数え続けています。