こんにちは！Project VBAの深淵へようこそ。
今回は、現代の開発現場で避けて通れない「64bit環境におけるメモリ管理とAPI呼び出しの注意点」について、徹底的に解説していきます。
「マクロの記録」から一歩進み、大規模な工程表やリソースを自在にコントロールしようとしたとき、必ず直面するのがこのメモリとAPIの壁です。特に古いVBAコードをそのまま64bit版のMS Project（Office）で動かそうとすると、容赦なく「コンパイルエラー」や「強制終了（クラッシュ）」の洗礼を受けます。
でも、安心してください。ルールさえ把握してしまえば、怖くありません。ここをクリアすれば、あなたのProject VBAのスキルは間違いなくプロの領域に到達します。さあ、一緒に本質を紐解いていきましょう！
—
1. なぜ古いVBAコードは64bit環境でクラッシュするのか？
まず、私たちが直面している「32bit環境」と「64bit環境」の根本的な違いを知ることから始めましょう。
一言で言うと、「メモリの番地（ポインタ）の桁数が違う」ということです。
- 32bit環境: メモリの番地を「32桁の2進数（＝4バイト）」で管理します。
- 64bit環境: メモリの番地を「64桁の2進数（＝8バイト）」で拡張して管理します。
ここで、WindowsのOS機能や他のアプリケーション（C++で書かれたDLLなど）とデータをやり取りするために「API呼び出し（Declare）」を行うコードを考えてみてください。
古いVBAコードでは、メモリのアドレスやウィンドウハンドル（HWNDなど）を格納するために、好んで `Long` 型（32bit）が使われていました。
32bit環境ならこれでピッタリ収まっていたのですが、64bit環境でこれをやるとどうなるでしょう？
> 【イメージ図：メモリあふれの大事故】
>
> 64bitの巨大なデータ（8バイト） ＝＞ 【 □□□□ □□□□ 】
> 32bit用の入れ物（`Long`型 ＝ 4バイト） ＝＞ 【 □□□□ 】
> あふれたデータが周囲のメモリ領域を破壊し、Projectごと強制終了！
この「入れ物のサイズ違い」によるメモリ破壊を防ぐために用意されたのが、現代のVBAにおける必須キーワード、`PtrSafe` と `LongPtr` です。
—
2. 64bit対応の3大ルール（これだけ覚える！）
コードを書き換える際は、以下の3つのルールを呪文のように唱えてください。
1. `Declare` には必ず `PtrSafe` をつける
- 「このAPI宣言は64bit対応済みです」とVBAコンパイラに伝える合図です。これがないと64bit版Officeでは即座にエラーになります。
2. ポインタやハンドルを扱う型は `LongPtr` にする
- 環境が32bitなら4バイト、64bitなら8バイトに、自動的に姿を変えてくれる「形状記憶合金」のような型です。
3. 通常の数値データは `Long` のままでOK
- 「ポインタやハンドル（メモリ上の住所）」ではなく、単なる「数値のカウントやフラグ」であれば、64bit環境でも従来の `Long`（32bit）のままで問題ありません。ここをすべて `LongPtr` に変えてしまうのはパフォーマンス低下やバグの元なので注意しましょう。
—
3. 【実践】古いコードをモダンにリファクタリングする
百聞は一見にしかず。実務でよくある「Projectのウィンドウハンドルを取得して操作する」というシチュエーションを例に、ビフォーアフターを見てみましょう。
❌ 危険な古いコード（32bit専用）
‘ 【注意】これは64bit環境のOfficeではコンパイルエラー、または動作不良を起こします！
Declare Function GetActiveWindow Lib “user32” () As Long
Sub DoSomethingOld()
Dim hWnd As Long
hWnd = GetActiveWindow()
‘ 何らかの処理…
End Sub
- 何がダメなのか？
64bit版Officeでは、`GetActiveWindow` が返すメモリアドレス（8バイト）を、`Long` 型（4バイト）の変数 `hWnd` で受け止めようとするため、オーバーフローを起こします。
—
⭕ 安全なモダンコード（32bit/64bit 跨ぎ対応）
‘ 1. PtrSafeを付与し、戻り値を LongPtr に変更
If VBA7 Then
‘ Office 2010以降の64bit/32bit両対応の宣言
Declare PtrSafe Function GetActiveWindow Lib “user32” () As LongPtr
Else
‘ 古いOffice 2007以前の環境への配慮（必要に応じて）
Declare Function GetActiveWindow Lib “user32” () As Long
End If
Sub DoSomethingModern()
‘ 2. メモリ番地を格納する変数は必ず LongPtr を使う
Dim hWnd As LongPtr
hWnd = GetActiveWindow()
If hWnd <> 0 Then
MsgBox “現在のProjectウィンドウのハンドルを取得しました: ” & CStr(hWnd), vbInformation
Else
MsgBox “ウィンドウハンドルの取得に失敗しました。”, vbCritical
End If
End Sub
ここで登場した `#If VBA7 Then` という条件付きコンパイル定数に注目してください。
これにより、古いExcel/Project（VBA 6以前）と、現代のOffice（VBA 7以降）のどちらでコードが動いても、エラーを出さずに適切なAPI定義を自動選択させることができます。プロの現場では必須のテクニックです。
—
4. Project VBAにおける「ポインタ」とオブジェクト管理の罠
MS Projectのオブジェクトモデル（`Project`, `Task`, `Resource`）を操作する際、通常はVBAが内部でメモリ管理を肩代わりしてくれているため、私たちが直接ポインタを意識することは少ないです。
しかし、以下のようなケースではメモリ管理の意識が必要になります。
- 大量のタスク（数万行レベル）を一括処理する際のメモリリーク対策
- 外部DLL（C++等で自作したアドインなど）との連携
特に、「オブジェクト変数の解放（`Set Task = Nothing`）」を怠ると、ProjectのVBAエンジン内に不要なオブジェクト参照が残り、処理が重くなったり、最悪の場合はMS Project自体が固まる原因になります。
Sub OptimizeTaskProcessing()
Dim prj As Project
Set prj = ActiveProject
Dim tsk As Task
‘ 大量タスクをループ処理する例
For Each tsk In prj.Tasks
If Not tsk Is Nothing Then
‘ 何らかのプロパティ操作
‘ 例: tsk.Text1 = “Processed”
End If
Next tsk
‘ ループが終わったら確実にメモリ参照を解放する
Set tsk = Nothing
Set prj = ActiveProject
MsgBox “メモリクリーンアップ完了！”, vbInformation
End Sub
細かなことの積み重ねですが、こうした「オブジェクトのライフサイクル」を意識したコーディングこそが、実務で信頼されるエンジニアの証です。
—
まとめ：ここをクリアすれば、Project VBAの基本はバッチリですよ！
今回は64bit環境におけるメモリ管理とAPI呼び出しの極意について解説しました。
- 64bit環境ではポインタサイズが8バイトに拡張される
- API宣言には `PtrSafe` をつけ、アドレスを扱う変数は `LongPtr` を採用する
- 環境差異を吸収するために `#If VBA7 Then` の条件付きコンパイルを活用する
この基本さえ押さえておけば、どんなに古いレガシーマクロに出くわしても、スマートに現代の環境へと蘇らせることができます。
さあ、恐れることはありません。ご自身の開発環境でもぜひこの書き方を取り入れて、頑健で美しいProject VBAコードを組み上げていきましょう！あなたの自動化ライフを心から応援しています。
