64bit VBAの深淵：LongとLongLong、そしてメモリアクセスの境界線
多くのVBAエンジニアがいまだに「とりあえずIntegerは使わずLongを使っておけ」という古い教義を盲信している。しかし、Officeの64bit化が標準となった現在、その無知はシステムをクラッシュさせるトリガーになり得る。
メモリの配置、ポインタの挙動、そしてOSのABI（Application Binary Interface）を理解せぬままコードを書くことは、時限爆弾を抱えて走るようなものだ。本稿では、VBAにおけるデータ型の真実と、Windows API連携時に発生する「静かなる破壊」を防ぐための極限の知見を記す。
—
1. データ型の再定義：VBAにおける「Long」の欺瞞
VBAの `Long` 型は、32bit環境下では4バイトの符号付き整数であり、64bit環境下でも4バイトを維持する。ここが多くの開発者の誤解の起点だ。
- Long: 常に4バイト（32bit）。
- LongLong: 常に8バイト（64bit）。※VBA7以降でのみ利用可能。
- Integer: 常に2バイト（16bit）。
「64bit OfficeだからLongが8バイトになるのでは？」という期待は幻想である。VBAのABIは下位互換性を守るために、`Long` のサイズを固定している。64bit環境下でポインタやハンドルを扱う場合、`Long` ではオーバーフロー（あるいはデータ切り捨て）が発生し、メモリアクセス違反が引き起こされる。
—
2. Windows API連携における「型」の絶対原則
Windows APIを呼び出す際、`PtrSafe` キーワードとともに、アドレスを保持する変数は必ず `LongPtr` 型で定義せねばならない。
`LongPtr` は、実行環境のビット数に合わせて自動的にサイズが変化する「カメレオン型」だ。
- 32bit環境：4バイト
- 64bit環境：8バイト
禁忌：API宣言の正解例
APIの引数にポインタ（メモリ上のアドレス）を渡す際は、必ず `LongPtr` を使用すること。
If VBA7 Then
‘ 64bit/32bit両対応の宣言
Private Declare PtrSafe Function GetActiveWindow Lib “user32” () As LongPtr
Private Declare PtrSafe Sub CopyMemory Lib “kernel32” Alias “RtlMoveMemory” ( _
ByRef Destination As Any, _
ByRef Source As Any, _
ByVal Length As LongPtr)
Else
‘ レガシー32bit Office用
Private Declare Function GetActiveWindow Lib “user32” () As Long
Private Declare Sub CopyMemory Lib “kernel32” Alias “RtlMoveMemory” ( _
ByRef Destination As Any, _
ByRef Source As Any, _
ByVal Length As Long)
End If
—
3. メモリ最適化とオブジェクト解放の流儀
VBAのガベージコレクションは参照カウンタ方式である。しかし、特にAPIで取得したメモリブロックや、COMオブジェクトを扱う際、明示的な解放を怠ると、メモリリークは確実に蓄積する。
オブジェクトの明示的解放ルール
「スコープを抜ければ解放される」と考えるのはアマチュアだ。長期稼働する自動化ツールでは、以下のイディオムを徹底せよ。
Public Sub HighPerformanceProcess()
Dim objShell As Object
Set objShell = CreateObject(“WScript.Shell”)
On Error GoTo Cleanup
‘ メイン処理
Cleanup:
‘ エラー時でも確実にメモリを解放する
If Not objShell Is Nothing Then
Set objShell = Nothing
End If
‘ APIで確保したメモリがある場合は、ここで解放処理（LocalFree等）を呼ぶ
End Sub
—
4. 64bit移行の極限チェックリスト
レガシーシステムを64bit環境へ移行する際、以下の項目を必ず精査せよ。
1. 構造体のパディング: APIに渡す構造体において、64bit環境ではポインタが8バイトになるため、構造体内のメンバ配置（オフセット）が32bit時と異なる。`Type` 宣言の並び順がメモリレイアウトに直結していることを忘れるな。
2. LongLongの使い所: `LongLong` は、64bitの整数計算（ファイルサイズや高精度タイムスタンプ）にのみ使う。ポインタ代わりに使用してはならない。
3. Variant型の罠: `Variant` はメモリを大量に消費し、かつランタイムの推論コストが高い。極限までパフォーマンスを求めるループ処理では、必ず静的型（`Long`, `Double`, `String`）へキャストすること。
—
結びに代えて：アーキテクトの視点
VBAは「おもちゃ」ではない。適切に設計され、メモリ管理がなされたVBAコードは、C++等のネイティブ言語に近い安定性と速度を実現できる。
`Long` か `LongLong` か、あるいは `LongPtr` か。この選択一つに、エンジニアの習熟度が現れる。「動くからいい」ではなく、「なぜその型でなければならないのか」を論理的に説明できないコードは、いずれ必ず破綻する。
この記事を読んだ諸君が、自身のシステムを再検証し、より堅牢なアーキテクチャへと昇華させることを期待する。コードの静寂は、エンジニアの規律から生まれるものだ。
