【上級プロ】64bit環境におけるProject VBAのメモリ管理とAPI呼び出しの注意点
世に溢れるVBAの解説記事の多くは、Excelを前提とした表層的なものばかりだ。しかし、我々が扱うMicrosoft Project (MS Project)のオブジェクトモデルは、Excelのそれとは次元が違う。数千行に及ぶWBS、複雑なクリティカルパス、リソースの過負荷平準化――。Projectの内部エンジンは常に膨大なメモリとCPUリソースを消費している。
そこに「古い32bit時代の遺物」であるVBAコードを持ち込むとどうなるか？
現代の64bit版Office環境において、メモリのアドレス解決に失敗し、容赦なくExcelやProjectごと強制終了（クラッシュ）する。
今回は、開発現場で生き残るための「64bit環境におけるProject VBAのメモリ管理とAPI呼び出しの極意」を伝授する。妥協のない堅牢なコードで、あなたの自動化ツールをプロフェッショナルなレベルへと引き上げよう。
—
1. なぜ古いVBAコードは64bit環境でクラッシュするのか？
32bit版Officeから64bit版Officeへの移行における最大の断絶は、ポインタサイズの変更（4バイトから8バイトへ）だ。
WindowsのネイティブAPI（Win32 API）を呼び出す際、ハンドルやメモリ領域のポインタを受け渡すコードが32bit（`Long`型）のままであると、64bit環境では上位4バイトが切り捨てられるか、不正なメモリ領域を参照してAccess Violation（アクセス違反）を引き起こす。
特にMS Projectのマクロでは、外部ライブラリ（ウィンドウ制御やクリップボード操作など）と連携するケースが多い。ここを曖昧にしている開発者は、プロとしての資格がない。
—
2. 64bit対応の鉄則：PtrSafeとLongPtrの正しい理解
現代のProject VBAでAPIを安全に叩くためのルールは、以下の2点に集約される。
1. `Declare` ステートメントには必ず `PtrSafe` を付加する
- これにより、コンパイラに対して「このAPIは64bit環境に対応しています」と明示する。
2. メモリポインタやハンドルを保持する変数はすべて `LongPtr` 型を使う
- `LongPtr` は、32bit環境では4バイト、64bit環境では8バイトに自動的にコンパイルされる型である。通常の演算用カウンターには従来の `Long`（常に4バイト）を使い分けるのが鉄則だ。
—
3. 【実践】Win32 APIを安全に扱うプロダクションコード例
以下のコードは、Projectのウィンドウハンドル（HWND）を取得し、Windows APIを使ってウィンドウタイトルを動的に書き換える堅牢なモジュールである。
このコードは、コンパイル条件分岐（`#If VBA7`）を使用しているため、32bit版と64bit版の双方の環境で無改修に動作する。現場に混在するクライアント環境に頭を悩ませる必要はない。
Option Explicit
‘ ==============================================================================
‘ モジュール名: modWinAPI_SafeControl
‘ 概要: 64bit/32bit環境両対応のWin32 APIラッパー
‘ 開発現場のリーダーとして、環境依存のクラッシュを完全に排除する設計
‘ ==============================================================================
If VBA7 Then
‘ — 64bit (および VBA7以降) 用の宣言 —
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” ( _
ByVal lpClassName As String, _
ByVal lpWindowName As String _
) As LongPtr
Private Declare PtrSafe Function SetWindowText Lib “user32” Alias “SetWindowTextA” ( _
ByVal hwnd As LongPtr, _
ByVal lpString As String _
) As Long
‘ Projectのメインウィンドウハンドルを保持
Public destHwnd As LongPtr
Else
‘ — レガシーな 32bit Office 用の宣言 —
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” ( _
ByVal lpClassName As String, _
ByVal lpWindowName As String _
) As Long
Private Declare Function SetWindowText Lib “user32” Alias “SetWindowTextA” ( _
ByVal hwnd As Long, _
ByVal lpString As String _
) As Long
Public destHwnd As Long
End If
/
- 現在起動しているProjectインスタンスのウィンドウタイトルを安全に変更する
- @param newTitle 設定したい独自のタイトル文字列
/
Public Sub UpdateProjectWindowTitle(ByVal newTitle As String)
Dim originalTitle As String
On Error GoTo ErrorHandler
‘ 現在のProjectウィンドウのタイトルを取得（MSProjectのクラス名は “MSProject”）
‘ ※ 複数のProjectが起動している場合を考慮し、正確なアクティブウィンドウ名を指定
originalTitle = Application.Caption
‘ APIを使ってウィンドウハンドルを取得
destHwnd = FindWindow(“MSProject”, originalTitle)
If destHwnd = 0 Then
MsgBox “対象のProjectウィンドウハンドルが見つかりませんでした。”, vbCritical, “API Error”
Exit Sub
End If
‘ ウィンドウタイトルを書き換え
Dim apiResult As Long
apiResult = SetWindowText(destHwnd, newTitle)
If apiResult = 0 Then
Err.Raise vbObjectError + 1000, “UpdateProjectWindowTitle”, “SetWindowText APIの実行に失敗しました。”
End If
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “Critical Error”
‘ 実務ではここでエラーログ出力基盤へ連携する
End Sub
—
4. プロジェクト管理特有のメモリ管理の罠：オブジェクトの解放
API呼び出しだけでなく、Project VBA特有の「オブジェクトの寿命」についても言及しておこう。
Projectでは、`ActiveProject.Tasks` や `Selection.Tasks` などのコレクションをループ処理する際、不適切なオブジェクト参照を残すとメモリリークを引き起こす。特に外部データベース（SQL ServerやAccess）との連携時や、ExcelへのデータエクスポートをVBA単体で完結させる場合、以下の作法を厳守せよ。
メモリリークを防ぐための3箇条
1. オブジェクト変数は明示的に `Nothing` を代入して破棄する
- 特に `Task` や `Resource` オブジェクトをループ内で生成・取得する場合は、スコープを意識せよ。
2. 画面描画の抑制 (`ScreenUpdating`) を活用する
- 大量のタスクを一括操作する際、UIの再描画コストはメモリとCPUを圧迫する。処理の冒頭で `Application.ScreenUpdating = False` とし、必ず最後に `True` に戻すこと。
3. エラーハンドリングでの確実なクリーンアップ
- 途中でエラーが発生して処理が中断した際、リソースがロックされたままになるのを防ぐため、必ず `On Error GoTo` でクリーンアップブロックへ誘導するフローを構築すること。
—
5. まとめ：プロフェッショナルなVBA開発者であれ
「動けばいい」という妥協の産物は、環境が変わった瞬間に組織の業務を止める凶器に変わる。
今回解説した `PtrSafe` と `LongPtr` の適切な実装、そしてメモリとオブジェクトのライフサイクル管理は、単なる「エラー回避のテクニック」ではない。利用者に安心・安全な自動化環境を提供するためのエンジニアリングの基本である。
現場のリーダーであるあなた自身がこの基準を示し、保守性の高い、美しく堅牢なコードベースを築き上げてほしい。
