日付・時刻データの型指定とシリアル値の罠：VBAにおける時間軸の完全支配
Excel VBAにおいて、日付や時刻の扱いは最も甘く見られがちでありながら、最も多くのシステム障害を生む魔窟である。
「たかが日付の比較」「文字列を`CDate`で包めば動く」――そう考えて実装されたコードは、数年後の環境移行、タイムゾーンの変更、あるいはExcelのバージョン差異によって必ず牙を向く。
本稿では、`Date`型が内包するシリアル値の構造的真実を暴き、期間計算やシステム間連携におけるバグを根絶するための極限の知見を提示する。
—
1. `Date`型の正体：IEEE 754倍精度浮動小数点数とシリアル値の構造
VBAの`Date`型は、内部的には8バイト（64ビット）のIEEE 754形式の倍精度浮動小数点数（Double）として格納されている。
このアーキテクチャを理解していない者は、日付・時刻の演算で必ず痛い目を合う。
- 整数部（小数点より左）： 1900年1月1日を「1」とした経過日数（シリアル値）。
- 小数部（小数点より右）： 1日を「1」とした場合の時刻の割合（24時間を「1」としたときの比率）。
浮動小数点演算がもたらす「誤差」の罠
CPUの浮動小数点演算器（FPU）の性質上、小数の加算は厳密な十進数を表現できない。例えば、時刻の「1秒」をシリアル値として表すと以下のようになる。
$$\text{1秒} = \frac{1}{24 \times 60 \times 60} \approx 0.000011574074074074073…$$
この微小な値をループ内で加算し続けたり、時刻データを`Double`のまま厳密一致（`=`）で比較したりすると、浮動小数点数の誤差により条件分岐が破綻する。これが、レガシーシステムで「なぜか特定の時刻だけバッチ処理がスキップされる」怪現象の正体である。
—
2. 期間計算における「1900年ルールの呪縛」と境界値バグ
Excelの紀元（Epoch）は 1899年12月31日（シリアル値 0）である。しかし、Lotus 1-2-3との互換性維持という歴史的負債により、「1900年をうるう年と誤認するバグ」がシリアル値に組み込まれている。
- `60` というシリアル値が存在し、それが `1900/2/29` を指す（現実には存在しない日）。
- 1900年3月1日以降のデータは、実際の経過日数とシリアル値が1日ズレた状態で同期している。
期間計算のベストプラクティス
このシステム的な歪みを回避するため、純粋な経過時間の計算には `Date` 型同士の引き算、あるいは専用の `DateAdd` / `DateDiff` 関数を使用するべきである。手動でシリアル値に `+ 1` などの補正を入れるコードは、保守性を著しく低下させる悪手である。
‘ 【推奨】DateDiffを用いた安全な経過日数計算
Public Sub CalculateBusinessSpan(ByVal dteStart As Date, ByVal dteEnd As Date)
Dim lngDays As Long
‘ 浮動小数点の誤差を排除するため、型安全な関数で差分を取得
lngDays = DateDiff(“d”, dteStart, dteEnd)
Debug.Print “経過日数: ” & lngDays & ” 日”
End Sub
—
3. システム間連携におけるシリアル値の破壊とタイムゾーン問題
基幹システム（SQL Server, Oracle, REST API等）とExcel間でJSONやCSV、あるいはOLE DB経由でデータをやり取りする際、最も頻発するのが「シリアル値の丸め誤差」と「タイムゾーンの解釈違い」である。
APIやデータベースは通常、ISO 8601形式（例: `2023-10-27T12:00:00Z`）やUTC基準の文字列・日時型を要求する。これをVBA側で安易に `Variant` や文字列として受け渡し、`CDate` で暗黙の型変換を行うと、OSのロケール設定（地域の日付形式）に依存した致命的なパースエラーを引き起こす。
Windows APIを活用した堅牢な時刻同期（レガシー環境の救済）
もしシステム連携においてミリ秒単位の正確性が求められる、あるいはUTCとローカル時間の変換を厳密に行う必要がある場合、VBA単体の関数に頼るべきではない。WindowsのKernel32 APIである `GetSystemTime` を直接叩き、システム時刻をミリ秒単位で取得・構築するアーキテクチャが求められる。
‘ 64ビット/32ビット環境両対応のAPI定義
If VBA7 Then
Private Declare PtrSafe Sub GetSystemTime Lib “kernel32” (lpSystemTime As SYSTEMTIME)
Else
Private Declare Sub GetSystemTime Lib “kernel32” (lpSystemTime As SYSTEMTIME)
End If
Private Type SYSTEMTIME
wYear As Integer
wMonth As Integer
wDayOfWeek As Integer
wDay As Integer
wHour As Integer
wMinute As Integer
wSecond As Integer
wMilliseconds As Integer
End Type
‘ 【極限の知見】OSのシステムクロックから直接UTC時刻を取得する
Public Function GetUtcNow() As Date
Dim st As SYSTEMTIME
GetSystemTime st
‘ シリアル値の罠を回避し、DateSerial / TimeSerialで安全に構築
GetUtcNow = DateSerial(st.wYear, st.wMonth, st.wDay) + _
TimeSerial(st.wHour, st.wMinute, st.wSecond)
End Function
—
4. 比較処理における「厳密性」の担保
日付と時刻を同時に比較する場合、`Date`型変数の比較演算子（`>`、`<`、`=`）は正しく機能するが、前述の通り「時刻を含まない日付比較」や「小数部の端数切り捨て漏れ」によるバグが後を絶たない。
例えば、`Now` 関数（現在の日付と時刻）から取得した値と、セルから読み込んだ日付（時刻なし＝小数部が `0`）を比較する場合、`Now` 側の小数部が残っているため、同日であっても `dteA = dteB` は `False` を返す。
堅牢な日付比較のための設計パターン
日付のみの比較を行う場合は、必ず `Int()` 関数（または `Fix()`）を用いて小数部（時刻）を剥ぎ取るか、`DateSerial` で日付部分のみを再構築しなければならない。
‘ 【極限の知見】時刻要素を完全に排除した純粋な日付比較関数
Public Function IsSameDate(ByVal dteTarget1 As Date, ByVal dteTarget2 As Date) As Boolean
‘ Int関数により、シリアル値の整数部（日付）のみを抽出する
‘ ※負の値（1899年以前）を扱うことは稀だが、Fixの挙動にも留意すること
IsSameDate = (Int(dteTarget1) = Int(dteTarget2))
End Function
—
5. チーフアーキテクトからの提言
VBAにおける `Date` 型は、Excelのセルの挙動と密結合しているがゆえに、他のプログラミング言語（C#やPythonなど）の `DateTime` 型に比べて非常にプリミティブかつ脆弱である。
1. 暗黙の型変換（Variant経由のパース）を絶対に許容しない。 すべての変数は `Dim … As Date` で明示的にタイピングする。
2. 浮動小数点演算の誤差を前提にコードを書く。 時刻の厳密一致は避け、許容誤差（イプシロン）を設けるか、整数（ミリ秒や秒単位のLongLong型）へ一度変換してロジックを組み立てる。
3. 外部インターフェースとの境界では、ISO 8601文字列へ強制変換する。 シリアル値をそのままJSONやAPIに流し込む愚は、今日で終わりにするべきだ。
技術の本質を見極め、システム基盤の足元を固めること。それこそが、レガシーとモダンを繋ぐプロフェッショナルエンジニアの責務である。
