序文：日付という名の「幻影」を剥ぎ取る
Excel VBAの世界において、初心者とシニアエンジニアを分かつ最大の境界線の一つが「日付の扱い」だ。
多くの開発者は、セルに表示された「2023/10/27」という文字列を日付そのものだと誤認している。しかし、我々アーキテクトにとって、日付とは単なる「Double型の浮動小数点数（シリアル値）」に過ぎない。この本質を理解せず、安易に文字列操作関数（Left, Right, Mid）や、環境依存の強い`Format`関数に頼ることは、グローバル環境やシステム間連携において、音を立てて崩壊する脆弱なコードを生み出すことに等しい。
本稿では、Excelの表示形式という甘い罠を排し、メモリ上の実態からWindows APIレベルの制御まで、日付処理の「極限の知見」を詳解する。
—
1. 内部構造の真実：Date型はDouble型のエイリアスである
VBAにおける`Date`型は、8バイトの浮動小数点数だ。整数部が1899年12月30日からの経過日数を表し、小数部が時刻（1日を1.0とした割合）を表す。
なぜ1899年12月30日なのか？
これはLotus 1-2-3との互換性を保つためにExcelが採用した「1900年うるう年バグ」を内包した設計に起因する。この歴史的経緯を知ることは、レガシーシステムとのデータ整合性を保つ上で不可欠な教養である。
‘ 日付の実態を暴く
Sub RevealDateIdentity()
Dim dt As Date
dt = #10/27/2023 12:00:00 PM#
‘ Date型をDoubleにキャストすると、その正体が見える
Dim serialValue As Double
serialValue = CDbl(dt)
‘ 45226.5 という数値が出力される
Debug.Print “Serial Value: ” & serialValue
End Sub
この「数値」として扱う感覚こそが、パフォーマンス最適化の鍵となる。日付の比較を行う際、`Format`関数で文字列化してから比較するのは三流だ。シリアル値のまま数値比較を行うのが、CPUサイクルを最小化する唯一の正解である。
—
2. 暗黙の型変換という「静かなる毒」
VBAは非常に寛容な言語だが、その寛容さが牙を剥くのが`CDate`や`DateValue`による文字列からの変換だ。
地域設定（Locale）の呪縛
`CDate(“01/02/03”)`というコードがあったとする。
- 日本環境（JP）では、2001/02/03 と解釈される。
- 米国環境（US）では、January 2nd, 2003 と解釈される。
- 英国環境（UK）では、1st February 2003 と解釈される。
システム間連携において、OSの地域設定に依存する関数を使用することは、将来的なバグを予約することに他ならない。
ベストプラクティス：ISO 8601形式とDateSerial
外部システム（APIやDB）とのやり取りでは必ずISO 8601形式（YYYY-MM-DD）を介し、VBA内部では`DateSerial`を使用して組み立てるべきだ。
‘ 文字列から安全にDate型を生成する堅牢な関数
Public Function SafeParseDate(ByVal dateStr As String) As Date
On Error GoTo ErrorHandler
‘ YYYY/MM/DD 形式を想定
Dim parts() As String
parts = Split(Replace(dateStr, “-“, “/”), “/”)
If UBound(parts) = 2 Then
‘ 地域設定を無視し、明示的に年・月・日を指定
SafeParseDate = DateSerial(CInt(parts(0)), CInt(parts(1)), CInt(parts(2)))
Else
Err.Raise 5, , “Invalid Date Format”
End If
Exit Function
ErrorHandler:
SafeParseDate = 0 ‘ エラー時はシリアル値0を返す
End Function
—
3. Windows APIによる高精度タイムスタンプの取得
VBA標準の`Now`関数や`Timer`関数は、分解能が低い。ミリ秒単位のログ出力や、厳密なトランザクション管理が必要なシステム連携では、Windows APIを直接叩くのが定石だ。
特に、`GetSystemTime`（UTC）や`GetLocalTime`（ローカル時間）を使用することで、`SYSTEMTIME`構造体を直接操作し、VBAの`Date`型では削ぎ落とされるミリ秒情報を保持できる。
‘ Windows API 構造体定義
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
Private Declare PtrSafe Sub GetLocalTime Lib “kernel32” (lpSystemTime As SYSTEMTIME)
‘ ミリ秒を含むISO 8601形式のタイムスタンプを生成
Public Function GetPreciseTimestamp() As String
Dim st As SYSTEMTIME
GetLocalTime st
‘ バッファ確保を最小限にするため、一気に整形
GetPreciseTimestamp = Format$(st.wYear, “0000”) & “-” & _
Format$(st.wMonth, “00”) & “-” & _
Format$(st.wDay, “00”) & “T” & _
Format$(st.wHour, “00”) & “:” & _
Format$(st.wMinute, “00”) & “:” & _
Format$(st.wSecond, “00”) & “.” & _
Format$(st.wMilliseconds, “000”)
End Function
—
4. メモリ最適化とオブジェクトのライフサイクル
日付処理を大量に行うループ（例：100万行のログ解析）において、`Variant`型の変数に日付を格納するのは避けるべきだ。`Variant`は16バイトを消費し、型判定のオーバーヘッドが発生する。必ず強データ型（Strong Typing）である`Date`型、あるいは`Double`型を明示的に宣言せよ。
また、Excelのセルから値を取得する際、`.Text`プロパティを参照してはならない。`.Text`はセルの表示形式（書式）を反映した文字列を返すため、列幅が足りない場合に`”
“`を返すという致命的な仕様がある。データ処理には必ず`.Value`または`.Value2`（シリアル値そのもの）を使用すること。
‘ パフォーマンスを極限まで追求した日付集計の例
Sub HighPerformanceDateProcessing()
Dim dataArray As Variant
dataArray = Sheet1.Range(“A1:A1000000”).Value2 ‘ 2次元配列へ一括ロード
Dim i As Long
Dim currentSerial As Double
Dim total As Double
For i = LBound(dataArray) To UBound(dataArray)
‘ Value2で取得したDouble値を直接扱う
If IsNumeric(dataArray(i, 1)) Then
currentSerial = dataArray(i, 1)
‘ 2023年1月1日（シリアル値：44927）以降か判定
If currentSerial >= 44927 Then
total = total + 1
End If
End If
Next i
End Sub
—
5. 結論：エンジニアが守るべき「鉄則」
日付というデータは、ユーザーインターフェース（UI）においては「文字列」として振る舞うが、ビジネスロジックにおいては「数値」であり、システム間連携においては「標準規格（ISO）」でなければならない。
1. 表示形式に騙されるな: セルの見た目は単なる化粧だ。常に`Value2`（シリアル値）を見ろ。
2. 地域設定を信用するな: `CDate`や`Format`はローカル環境で牙を剥く。`DateSerial`やISO形式を徹底せよ。
3. 計算は数値で行え: 日付の加減算や比較は、`Date`型のまま（あるいは`Double`で）行え。文字列変換は出力の最終段階まで行わない。
我々が保守すべきは、現在動いているコードだけではない。5年後、10年後の異なるOS環境、異なるロケールでも、変わらず正確な時を刻み続ける「堅牢なるロジック」である。この知見を胸に、貴殿のコードを真のプロフェッショナル・グレードへと昇華させてほしい。
