64bitの深淵へ：Project VBAレガシーコードを現代環境で再起動させるための「真の作法」
Project 2010以前の遺産が、現代の64bit Windows環境で「死」を迎えるのは必然だ。Office 2010の導入と共に導入されたVBA 7.0は、32bitという安寧の地を奪い去った。
多くのエンジニアが「なんとなく」で`PtrSafe`を付け、`Long`を`LongPtr`に書き換えて満足しているようだが、それは地雷原を裸足で歩くようなものだ。本稿では、レガシーProject VBAを64bit環境で完全に掌握するための、アーキテクトとしての極限の知見を授ける。
—
1. 64bit移行の核心：型定義の非互換性という病理
32bit時代の`Long`（4バイト）は、64bit環境のポインタ（8バイト）を格納できない。ここが最大のボトルネックだ。
修正の鉄則
- `LongPtr`の採用: ポインタやハンドル（HWND, HANDLEなど）を保持する変数は、必ず`LongPtr`に置換せよ。これは32bit環境では4バイト、64bitでは8バイトに自動的に変化する特殊な型だ。
- `LongLong`の分離: 64ビットの整数値を純粋に扱いたい場合のみ`LongLong`を使用せよ。ポインタの代用にしてはならない。
誤ったコードの修正例（Win32 API）
‘ 【レガシー】32bit専用の記述
‘ Private Declare Function GetActiveWindow Lib “user32” () As Long
‘ 【現代の正解】VBA 7.0以降のコンパイル条件付きコンパイル定数を使用
If VBA7 Then
‘ 64bit対応のDeclare宣言
Private Declare PtrSafe Function GetActiveWindow Lib “user32” () As LongPtr
Else
‘ 32bit互換の旧記述
Private Declare Function GetActiveWindow Lib “user32” () As Long
End If
—
2. メモリの「腐敗」を防ぐ：オブジェクトライフサイクルの管理
Project VBAにおいて、`Application.ActiveProject`や`Task`オブジェクトを安易に使い回すのは悪手だ。特に長期間稼働するマクロや、外部DLLを呼び出すシステムでは、オブジェクトの参照がメモリに残り続け、メモリリークを招く。
アーキテクトの推奨：明示的解放の徹底
VBAのガベージコレクションを信じてはならない。特に`Project.Application`や`Task`をループ内で生成する場合、`Nothing`への代入は義務である。
Public Sub OptimizeTaskProcess()
Dim prj As Project
Dim tsk As Task
Set prj = ActiveProject
‘ プロセス終了時に確実にメモリを解放する
On Error Resume Next
For Each tsk In prj.Tasks
If Not tsk Is Nothing Then
‘ 処理
End If
Next tsk
‘ ここが重要：参照カウントを強制的に下げる
Set tsk = Nothing
Set prj = Nothing
End Sub
—
3. システム間連携の極限：API呼び出しの安定化
Project 2010以前のコードは、しばしば`kernel32`や`user32`の古い関数に依存している。これらを64bit環境に持ち込む際、最も危険なのは「引数の型」の不一致によるメモリ破壊だ。
実践的チェックリスト
1. 文字列の受け渡し: `ByVal String`はUnicodeの問題を孕む。特に外部DLLとの連携では、`StrPtr()`を用いて明示的にメモリ上のアドレスを渡すのが最も安全だ。
2. 構造体のパディング: Windows APIに渡す構造体（`TYPE`）は、64bit環境でパディング（詰め物）のサイズが変わる。構造体をAPIに渡す際は、`PtrSafe`宣言だけでなく、構造体内部のメンバ変数が64bitアライメントに適合しているか再確認せよ。
—
4. 最後に：レガシー保守という戦い方
我々が向き合っているのは単なる古いコードではない。「ビジネスロジックの結晶」だ。
Project 2010以前のコードを修正する際、全てのロジックをリファクタリングしようとするのは愚策である。まずは「環境への適応（PtrSafeの適用）」を行い、次に「メモリ管理の正常化（Set = Nothingの徹底）」を行う。この二段階を踏むだけで、システムは劇的に安定する。
もし、貴殿が触れているコードが現代のOSでクラッシュを繰り返すのであれば、それはコードのせいではない。APIの定義が、OSの進化という重力に耐えられなくなっているだけだ。
コードを書き換える際は、常に `#If VBA7 Then` を盾にせよ。それが、過去の遺産を尊重しつつ、未来の安定を勝ち取る唯一の手段である。
—
伝説のアーキテクトからの助言:
「動くから良い」というエンジニアの感性は捨てろ。「なぜ動いているのかを型レベルで証明できるか」を常に自問せよ。それができないコードは、いずれ必ず貴殿の足をすくうことになる。
