うるう年判定 — グレゴリオ暦 4/100/400 ルールと次の閏年

閏年の知識が実務で重要になる場面

閏年の判定は、単なるカレンダーの知識にとどまらず、ソフトウェアのバグ・金融計算の誤差・法的な期日のズレに直結する実務上の問題です。1900 年を閏年と誤認したシステムは多数存在し、2000 年問題（Y2K）の一部もグレゴリオ暦のルール（400 で割り切れる年は閏年）を正しく実装していないことに起因していました。

2 月 29 日生まれの方にとっては、自分の誕生日と次の 2 月 29 日がいつ来るかという情報は個人の生活設計と直結します。法律上（民法 143 条）では 2 月 28 日が満年齢の到達日とされることが多いですが、保険・年金・契約の条件によっては解釈が異なります。閏年の情報を外部サービスに問い合わせる必要はなく、ブラウザ内で完結させるべき計算です。

外部 API に閏年判定を依存することの問題

閏年判定は最もシンプルな算術の一つです（4 で割れる AND 100 で割れない OR 400 で割れる）。それにもかかわらず、外部 API に問い合わせる設計のカレンダーツールが存在します。このような設計では、「何年の閏年情報を調べたか」というログが API プロバイダーに残ります。生年が 2 月 29 日であることを調べる操作は、誕生日情報の開示に近い行為です。

また、年号や暦法の違い（ユリウス暦・グレゴリオ暦・和暦）に絡む計算では、外部サービスが使っている基準が自分の用途と一致しているかを確認することが難しく、誤った結果を受け取っても気付きにくいです。閉じたブラウザ内で自分が制御できる計算ロジックを使うことが、信頼性の観点でも有益です。

JavaScript の Date オブジェクトだけで閏年を完全判定

このツールはグレゴリオ暦の 3 ルール（① 4 の倍数 ② 100 の倍数は例外 ③ 400 の倍数は例外の例外）を JavaScript の算術演算（% 演算子）で実装しています。外部 API を呼ばず、Date オブジェクトの new Date(year, 1, 29).getDate() === 29 による確認も組み合わせて判定の確実性を高めています。

前後 10 件の閏年一覧は、対象年から ±40 年の範囲を 1 年ずつ走査するだけのシンプルな算術です。2 月 29 日生まれの次の誕生日計算も同じロジックで求めます。DevTools の Network タブを開いたまま年を変更しても、追加リクエストは発生しません。

閏年の知識を実務・生活設計に使う場合

ソフトウェア開発では、2 月の日数（28 日か 29 日）に依存する計算（月次バッチ処理の最終日判定・期間計算・フォーム入力の日付バリデーション）を実装するときに閏年判定が必要です。このツールで 1900 年・2000 年・2100 年の判定結果を確認しておくと、実装のテストケース設計に役立てられます。

2 月 29 日生まれの方の年齢計算や記念日管理では、このツールの「次の 2 月 29 日まで○日」表示を活用してください。閏年は 4 年に 1 回（ただし 100 年に 1 回スキップ、400 年に 1 回復活）のため、次の 2 月 29 日が 4 年後か 8 年後かは状況によって変わります。

グレゴリオ暦の改暦経緯と暦法ごとの閏年ルール

現行のグレゴリオ暦（Gregorian calendar）は 1582 年にローマ教皇 Gregory 13 世が制定した暦法で、それ以前のユリウス暦（Julian calendar、紀元前 45 年制定）の閏年ルール「4 年に 1 回」が抱える誤差を補正したものです。ユリウス暦は 1 年を平均 365.25 日とするのに対し、実際の太陽年は 365.2422 日のため、128 年で約 1 日のズレが累積します。グレゴリオ暦の 4/100/400 ルール（400 年で 97 回の閏年）はこの誤差を 3300 年で 1 日まで抑えます。改暦時に 10 日間（1582-10-04 の翌日が 1582-10-15）がスキップされ、英国・米国の植民地は 1752 年まで採用が遅れたため Cal 9 1752 で 2 の翌が 14 になる UNIX の cal コマンドの挙動はこの歴史的事実を反映しています。

JavaScript の Date オブジェクトは proleptic Gregorian calendar（グレゴリオ暦を改暦以前の年代にも遡って適用する仕様）を採用しており、new Date(1500, 1, 29) のように 1582 年以前を扱う場合、ユリウス暦の実際の挙動とは異なります。Intl.DateTimeFormat の calendar オプションで julian / hebrew / islamic / chinese / japanese（和暦）などを指定すると別暦法に切り替えられます。和暦は明治以降グレゴリオ暦と完全に一致（1873 年改暦）するため閏年ルールも同じですが、令和元年（2019）は 5/1 から始まる特殊な年で、年初の閏年判定に注意が必要です。

閏年バグの歴史的事例とソフトウェア実装の注意点

ソフトウェアの閏年バグは商用システムで繰り返し発生しています。1996 年に Microsoft Excel が 1900 年を閏年と誤認 する仕様を Lotus 1-2-3 との互換性のために保持し続けたことは有名で、現在も Excel の DATE 関数は 1900-02-29 を有効な日付として返します（実際には 1900 年は 100 で割れて 400 で割れないため閏年ではない）。2012 年には Microsoft Azure が閏年処理のバグで全世界的に障害を起こし、Windows Phone のスケジュールアプリも同年に同様のバグで一日中タイマーが停止しました。2024 年 2 月 29 日にも Tesla、OpenSea などで関連バグが報告されました。

実装の標準パターンは (year % 4 === 0 && year % 100 !== 0) || year % 400 === 0 の単一式ですが、論理演算の優先順位を誤って year % 4 === 0 && (year % 100 !== 0 || year % 400 === 0) と書いても結果は同じ（&& が || より先に評価されるが、ここではどちらでも正しい）です。ただし year % 4 === 0 && year % 100 !== 0 || year % 400 === 0 のように括弧なしで書くと演算子優先順位の解釈で意図と異なる挙動になる言語（Python の and / or 評価順は同じだが、SQL の AND / OR でも誤りやすい）もあります。テストケースには 1900（非閏）/ 2000（閏）/ 2024（閏）/ 2100（非閏）/ 2400（閏）を含めることが、業界で広く知られたベストプラクティスです。2 月 29 日生まれの満年齢を法律上の解釈（28 日到達）で計算したい場合は age-calc を、次の 2 月 29 日までの日数を細かく見たい場合は date-diff を併用すると、いずれも入力した生年を外部に出さずに処理できます。