【上級プロ】64bit環境におけるProject VBAのメモリ管理とAPI呼び出しの注意点
レガシーな32bit版Officeの時代は終わった。現代のエンタープライズ環境において、MS ProjectのVBAも完全なる64bitネイティブとして稼働させる必要がある。しかし、`Declare`文の闇雲な書き換えや、メモリ管理の概念なきコードは、突発的なクラッシュやヒープ破損という致命的なシステム障害を引き起こす。
本稿では、Project VBAのオブジェクトモデルの挙動、ポインタとメモリの物理的構造、そしてWindows API連携における極限の知見を、チーフアーキテクトの視点から解き明かす。
—
1. 64bit VBAの核心：PtrSafeとLongPtrの正しい理解
64bit版VBAへの移行において、単に`Declare`文に`PtrSafe`を付与し、すべての変数を`LongPtr`に置き換える開発者が後を絶たない。これは重大な設計ミスだ。
データの物理サイズを見極めよ
- `Long`型: 64bit環境であっても常に4バイト（32bit）である。Windows APIのハンドル（HWND）やポインタ値以外で、単なる数値やループカウンタ、インデックスを`LongPtr`にしてはならない。
- `LongPtr`型: 32bit環境では4バイト、64bit環境では8バイトに自動拡張される型である。「メモリ上のアドレス（ポインタ）」や「ウィンドウハンドル」を格納する場合にのみ使用する。
誤ったAPI定義の例と正解
以下の例は、Windowsのクリップボードや外部メモリを操作する際によくある誤りだ。
‘ 【× 悪臭を放つレガシーコード】
‘ 32bit時代のコードを無理やりPtrSafeにしただけ。メモリ破壊の原因になる。
Declare PtrSafe Function GlobalAlloc Lib “kernel32” (ByVal wFlags As Long, ByVal dwBytes As Long) As Long
‘ 【〇 厳密な型定義を行ったモダンコード】
‘ dwBytes（サイズ）は64bit環境でも4バイトのままで十分な場合が多いが、API仕様に厳密に従う。
If Win64 Then
Declare PtrSafe Function GlobalAlloc Lib “kernel32” (ByVal wFlags As Long, ByVal dwBytes As LongPtr) As LongPtr
Declare PtrSafe Function GlobalLock Lib “kernel32” (ByVal hMem As LongPtr) As LongPtr
Declare PtrSafe Function GlobalUnlock Lib “kernel32” (ByVal hMem As LongPtr) As Long
Else
Declare PtrSafe Function GlobalAlloc Lib “kernel32” (ByVal wFlags As Long, ByVal dwBytes As Long) As Long
Declare PtrSafe Function GlobalLock Lib “kernel32” (ByVal hMem As Long) As Long
Declare PtrSafe Function GlobalUnlock Lib “kernel32” (ByVal hMem As Long) As Long
End If
チーフアーキテクトの知見： 条件付きコンパイル（`#If Win64 Then`）を制する者のみが、クロスプラットフォーム（32bit/64bit混在環境）の安定性を手に入れることができる。
—
2. Projectオブジェクトモデルとメモリのライフサイクル
MS ProjectのVBAエンジンは、ExcelやWordとは異なる特殊なメモリ管理を行っている。特に数万件規模のタスクを持つ大スケジュールの操作では、GC（ガベージコレクション）のタイミングとCOMオブジェクトの参照解放がボトルネックになる。
変数の即時解放とスコープの最小化
`Project`オブジェクト、`Task`オブジェクト、`Resource`オブジェクトは、VBA側から見るとCOMラッパーに過ぎ背後で巨大なC++のメモリ構造を保持している。
Sub OptimizeTaskProcessing()
Dim appProj As MSProject.Application
Set appProj = ActiveProject
Dim tsk As MSProject.Task
Dim i As Long
‘ 画面描画とイベントを停止し、COMオブジェクトの余計な生成・破棄サイクルを抑制
appProj.ScreenUpdating = False
appProj.Calculation = pjCalculationManual
On Error GoTo ErrorHandler
For i = 1 To appProj.Tasks.Count
Set tsk = appProj.Tasks(i)
If Not tsk Is Nothing Then
If tsk.PercentComplete < 100 And tsk.Finish < Date Then
' 処理ロジック
tsk.Text1 = "要確認"
End If
' ループ内でのオブジェクト参照の明示的破棄
Set tsk = Nothing
End If
Next i
ErrorHandler:
' 復元処理
appProj.Calculation = pjCalculationAutomatic
appProj.ScreenUpdating = True
If Err.Number <> 0 Then
MsgBox “予期せぬエラー: ” & Err.Description, vbCritical
End If
End Sub
メモリ最適化の極意： ループ内でオブジェクト変数（`tsk`など）を使い回す場合、次のイテレーションに入る前に必ず `Set tsk = Nothing` を明示せよ。これを怠ると、VBAの参照カウントが意図せず保持され続け、マクロ終了時までメモリリークを引き起こす。
—
3. 大規模システム連携時のAPI呼び出しとメモリリーク対策
外部DLL（C/C++製のアドインや独自COMコンポーネント）をProject VBAから呼び出す際、64bit環境特有の「データパディング（境界調整）」と「スタック破壊」に直面する。
構造体（Type）のバイトパディング問題
32bitと64bitでは、メモリ上のアラインメント（境界合わせ）が異なる。APIに構造体を渡す際、メンバの順序やデータ型の選択を誤ると、メモリがずれてプロセスがクラッシュする。
‘ 64bit環境に対応したAPI構造体の定義例
If Win64 Then
Private Type PROJECT_USER_DATA
ProcessId As Long
ThreadId As Long
BufferPtr As LongPtr ‘ 8バイト境界にアラインされる
DataSize As Long
End Type
Else
Private Type PROJECT_USER_DATA
ProcessId As Long
ThreadId As Long
BufferPtr As Long ‘ 4バイト境界
DataSize As Long
End Type
End If
確実なメモリ解放パターン（SafeMemoryHandle）
API経由で確保したメモリは、VBAの自動メモリ管理の対象外である。必ず `Finally` ブロック相当の構造を作り、例外発生時でも確実に解放する設計にしなければならない。
Public Sub ExecuteExternalApiCall()
Dim hMem As LongPtr
Dim pBuffer As LongPtr
Dim byteSize As LongPtr
byteSize = 1024 ‘ 1KBのメモリ確保
‘ 1. メモリの割り当て
hMem = GlobalAlloc(&H2, byteSize) ‘ GMEM_MOVEABLE = &H2
If hMem = 0 Then
MsgBox “メモリの割り当てに失敗しました。”, vbCritical
Exit Sub
End If
‘ 2. ポインタのロック
pBuffer = GlobalLock(hMem)
If pBuffer = 0 Then
GoTo CleanUpMem
End If
‘ — ここでAPIによるデータ処理を行う —
‘ Call SomeExternalApi(pBuffer, byteSize)
CleanUpMemory:
‘ 3. 確実なロック解除とメモリ解放
If pBuffer <> 0 Then
Call GlobalUnlock(hMem)
End If
If hMem <> 0 Then
Call GlobalFree(hMem)
End If
Exit Sub
CleanUpMem:
If hMem <> 0 Then
Call GlobalFree(hMem)
End If
End Sub
(※注: `GlobalFree` APIの定義も同様に `PtrSafe` かつ引数を `LongPtr` にしておく必要がある)
—
4. チーフアーキテクトからの最終提言
64bit版Project VBAの開発は、単なる「動けばいい」というレベルのコードを受け付けない。ハードウェアの物理アドレス、ポインタのサイズ、COMオブジェクトのライフサイクル、そしてOSのメモリ管理機構までを視野に入れた者だけが、10万行を超える巨大なスケジュール管理マクロを何年もの間、安定稼働させることができる。
「動いているから触らない」ではなく、「なぜその型なのか」「なぜそのタイミングで解放するのか」を説明できるコードベースこそが、真にプロフェッショナルなエンタープライズアーキテクチャである。
