問題の概要
ハードウェアのアップグレードや Microsoft 365 への移行後に、このエラーに遭遇したことがあるかもしれません。これは、64ビット版の Office が従来の32ビット版とは異なるメモリ・アドレスの処理を行うために発生します。32ビット・システムでは4バイトのポインタを使用しますが、64ビット・システムでは8バイトのポインタを使用します。
レガシーな VBA コードには、Windows の DLL から関数を呼び出すための Declare ステートメントが含まれています。これらの古いステートメントは64ビットのメモリ・アドレッシングに対応していないため、VBA コンパイラはメモリ破損や Excel の完全なクラッシュを防ぐためにこれらをブロックします。実際には、コードが8バイトのアドレスを4バイトのバケツに詰め込もうとしている状態です。
デバッグのプロセス
エラーが発生すると、VBA エディタは通常 Declare で始まる特定の行をハイライトします。この行は、user32.dll や kernel32.dll などの Windows API と通信しようとしています。
これを修正するために、64ビット・コンパイラは2つの特定の変更を必要とします。
- PtrSafe キーワード: これは VBA に対して、「このコードを確認済みであり、64ビット環境で実行しても安全である」ことを伝えます。
- LongPtr データ型: これは動的な型です。32ビット版 Office では自動的に4バイト、64ビット版 Office では8バイトに調整されます。
解決策：コードの更新
1. クイック修正（64ビット専用）
チームが64ビット版 Office のみを使用している場合は、構文を直接更新できます。Declare キーワードの後に PtrSafe を挿入するだけです。
従来の32ビット・コード：
Declare Function GetTickCount Lib "kernel32" () As Long
更新後の64ビット・コード：
Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
2. 堅牢な修正（クロスプラットフォーム互換性）
多くの職場では、一部のユーザーが依然として古い環境を使用している可能性があります。条件付きコンパイルを使用すれば、すべてのユーザーでマクロを動作させることができます。これには #If VBA7 定数を使用します。これは、まさにこのようなアーキテクチャの変更に対応するために Office 2010 で導入されたものです。
#If VBA7 Then
' このセクションは Office 2010 以降（32ビットおよび64ビット）で実行されます
Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
#Else
' このセクションは Office 2007 以前で実行されます
Declare Function GetTickCount Lib "kernel32" () As Long
Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
#End If
3. ポインタとハンドルの特定
PtrSafe を追加するだけでは不十分です。メモリ・アドレスや「ハンドル」を保持するすべての変数について、Long を LongPtr に置き換える必要があります。これを見落とすと、関数が呼び出された瞬間に Excel がクラッシュする可能性があります。
API 呼び出しにおける以下の一般的なパラメータを確認してください：
- hWnd: ウィンドウ・ハンドル。
- hDC: デバイス・コンテキスト・ハンドル。
- lpv or lp: 「lp」（Long Pointer）で始まるすべての変数。
- lParam and wParam: メッセージ・パラメータ。
更新後の複雑なタイマー関数の例を以下に示します：
#If VBA7 Then
Declare PtrSafe Function SetTimer Lib "user32" (ByVal hwnd As LongPtr, ByVal nIDEvent As LongPtr, ByVal uElapse As Long, ByVal lpTimerFunc As LongPtr) As LongPtr
#Else
Declare Function SetTimer Lib "user32" (ByVal hwnd As Long, ByVal nIDEvent As Long, ByVal uElapse As Long, ByVal lpTimerFunc As Long) As Long
#End If
検証手順
コードを更新した後は、単に動作することを願うだけでなく、以下の手順で修正を検証してください：
- VBA エディタを開き、[デバッグ] > [VBAProject のコンパイル] を選択します。ポップアップが表示されずにコンパイルできれば、構文は有効です。
- マクロをテストします。 「型が一致しません」エラーが表示される場合は、本来
Longのままにすべき標準の数値（カウンタなど）をLongPtrに変換してしまった可能性があります。 - 可能であれば、従来の32ビット・マシンでファイルを開いてください。これにより、
#If VBA7のロジックが他のユーザーの環境で破損していないことを確認できます。
重要なポイント
- Long vs. LongPtr:
Longは常に32ビットです。LongPtrは「スマート」であり、必要に応じて64ビットに拡張されます。メモリ・アドレスに関わるものにはすべてLongPtrを使用してください。 - VBA7 vs. Win64: モダンな Office バージョンをチェックするには
#If VBA7を使用します。#If Win64は、64ビット環境専用のコードを記述する必要がある場合にのみ使用してください。 - ドキュメントの確認: 迷ったときは、Microsoft の Win32 API ドキュメントで関数を検索してください。パラメータが
HANDLEまたはPTRとしてリストされている場合は、LongPtrを使用します。