結論：64bitで動かない原因の多くは「Declare文」と「API」
Accessを 32bit から 64bit に変更した直後、
それまで問題なく動いていたVBAが
コンパイルエラーになる
実行時に止まる
何も起きない
といった症状を起こすことがあります。
原因のほとんどは
Windows API の宣言（Declare文）が64bitに対応していないことです。
なぜ64bitで急に動かなくなるのか
32bit Access では通っていたコードでも、
64bit Access では次の点が厳密にチェックされます。
ポインタサイズの違い
Declare文に
PtrSafeが必須LongとLongPtrの使い分け
👉 64bitは制限が厳しくなったと考えると分かりやすいです。
チェック①：Declare文に PtrSafe が付いているか
64bit Accessでは、
Windows API を使う場合に PtrSafe が必須です。
❌ 32bit用のままの例
Declare Function GetTickCount Lib “kernel32” () As Long
⭕ 64bit対応
Declare PtrSafe Function GetTickCount Lib “kernel32” () As Long
これが無いだけで
**コンパイルエラー（宣言が正しくありません）**になります。
チェック②：Long と LongPtr を正しく使っているか
ポインタやハンドルを扱う変数は、
64bitでは Long では足りません。
よくある間違い
Dim hWnd As Long
正しい書き方
Dim hWnd As LongPtr
数値 → Long
ポインタ・ハンドル → LongPtr
これが64bit対応の基本です。
チェック③：APIを本当に使う必要があるか
実務では次のようなケースが非常に多いです。
ネットのコードをそのままコピペ
実は Access 標準機能で代替できる
たとえば
Clipboard操作やコピー処理は、
APIを使わなくても実装できます。
👉 APIを使わない
＝ 32bit / 64bit 両対応で安全
チェック④：参照設定がズレていないか
Accessのバージョン変更やPC変更後に、
参照設定の不整合が起きることがあります。
確認方法
VBE（Alt + F11）
→ ツール
→ 参照設定
「参照不可」と表示されていないか
不要なライブラリがチェックされていないか
これだけで解決する場合もあります。
チェック⑤：古いActiveX・コントロールを使っていないか
64bit Accessでは、
古いActiveX
サードパーティ製コントロール
が 動作しない／読み込めない 場合があります。
エラーが出ないのに動かない時は、
フォーム上のコントロール自体も疑ってください。
よくある勘違い
❌ Access 64bitは不安定
❌ VBAが壊れている
❌ Officeのバージョンの不具合
👉 実際は
32bit前提のコードが残っているだけのことがほとんどです。
どうしても直らない場合の考え方
APIを使わずに書き直せないか
Access標準機能で代替できないか
実務では、
APIを捨てた方が安定・保守が楽になるケースが多いです。
まとめ
64bitでVBAが動かない原因は Declare文が最多
PtrSafeとLongPtrを必ず確認APIは必要最小限に
標準機能で代替できるならその方が安全
👉 64bit対応とは、難しくすることではなく
👉 余計な依存を減らすことです。
内部リンク
Access VBAでClipboardを扱う最も簡単な方法（64bit対応・API不要）
