【VBA極限設計】64bit時代を生き抜く：LongとLongLongの「型」の真実
世の中に溢れる「VBA入門書」は、32bit時代の遺物だ。
「とりあえずIntegerを使っておけばいい」「Longにすればなんとなく安心」――そんな思考停止したコーディングは、64bit版Officeが標準となった現代では、ただの技術的負債だ。
今日は、プロのアーキテクトが現場で守っている、データ型選定の鉄則を叩き込む。メモリレイアウトを理解し、API呼び出しでクラッシュを起こさないための「真の作法」を伝授しよう。
—
1. なぜ「Integer」が駆逐されるべきなのか
かつての16bit/32bit環境では、`Integer`はCPUにとって処理が速いという神話があった。しかし、現代の64bit CPUにおいて、ネイティブなデータ幅は64bit（8バイト）だ。
- Integer (16bit): 現代のCPUは、これを処理する際に「32bit/64bitへの拡張」という余計な変換コストを払う。
- Long (32bit): 現代のVBAにおいて、メモリ効率と実行速度のバランスが最も取れている「標準」だ。
結論: カウンタ変数だろうがフラグだろうが、VBAの整数値はすべて`Long`で定義せよ。`Integer`を使う理由は、Excelの旧式セル行数（65,536行）との互換性以外、どこにも存在しない。
—
2. Long vs LongLong：64bitの境界線を理解する
VBAにおける`LongLong`型は、64bit版Office（64bit版Windows）でのみ存在する。32bit版Officeで書くと即座にコンパイルエラーになる「環境依存の境界線」だ。
使い分けの絶対ルール
1. 基本は `Long`: ほとんどの業務ロジック（ループ、計算、ID管理）はこれで完結する。
2. `LongLong` が必要な時:
- 64bit環境におけるメモリポインタ（アドレス）を扱う場合。
- Windows APIで`HWND`や`HANDLE`、`ULONG_PTR`といった型を要求される場合。
- 極めて巨大な数値（21億を超えるカウント）を扱う場合。
—
3. 実践：Windows API連携の堅牢な設計（PtrSafe）
API呼び出しで「メモリアクセス違反」が起きる最大の原因は、32bitと64bitでポインタサイズが異なることを無視しているからだ。
ここで`PtrSafe`キーワードと`LongPtr`型という「魔法の杖」を使う。`LongPtr`は、32bit環境では`Long`（4バイト）に、64bit環境では`LongLong`（8バイト）に自動的にコンパイルされる、まさにクロス環境対応の救世主だ。
【プロダクションコード例】堅牢なAPI定義テンプレート
If VBA7 Then
‘ VBA7 (Office 2010以降) では PtrSafe を使用
‘ LongPtr を使うことで、32/64bit両環境で型を自動調整する
Private Declare PtrSafe Function GetActiveWindow Lib “user32” () As LongPtr
Else
‘ 旧Office環境用（互換性維持のため）
Private Declare Function GetActiveWindow Lib “user32” () As Long
End If
Public Sub SecureApiCall()
‘ ポインタやハンドルを受け取る際は必ず LongPtr を使用する
Dim hWindow As LongPtr
hWindow = GetActiveWindow()
If hWindow <> 0 Then
Debug.Print “ウィンドウハンドル: ” & hWindow
Else
MsgBox “ウィンドウの取得に失敗しました。”
End If
End Sub
—
4. 現場で「バグらせない」ための3箇条
1. 型の明示を強制せよ:
`Option Explicit`を記述しないエンジニアは、現場から追放されても文句は言えない。暗黙の型変換（Variant型への自動昇格）は、メモリリークとパフォーマンス低下の温床だ。
2. ポインタには常にLongPtr:
「このAPIは32bitで動くからLongでいいや」という油断が、数年後のOSアップデートでシステムを破壊する。最初から`LongPtr`で定義する癖をつけろ。
3. データベース連携（ADO/DAO）の注意点:
データベース側が`BIGINT`（64bit整数）を返してくる場合、VBAの`Long`ではオーバーフローする。必ず`Currency`型（小数点以下4桁まで正確な64bit固定小数点型）で受け取るか、文字列としてキャストして回避せよ。
—
最後に：プロのエンジニアであるために
あなたが書くコードは、あなたがいなくなった後も動き続ける。
「動けばいい」という考えは、開発者として最も安易な道だ。今回解説したメモリレイアウトへの意識は、API連携だけでなく、大量のレコード処理やファイルI/Oにおけるボトルネック解消にも直結する。
今日から、すべての`Integer`を`Long`に書き換え、APIの定義を見直せ。
それが、あなたのツールを「趣味のスクリプト」から「堅牢な業務システム」へと昇華させる第一歩だ。
何か技術的な壁に突き当たったら、またここへ戻ってきなさい。
常に論理的で、かつ最も効率的な解法を提示してやる。
