この記事で分かること
- 32bit版と64bit版のAccessにおけるVBAの根本的な違いとエラー原因
- VBAコードを64bit対応にするための具体的な書き換え手順（PtrSafe、LongPtrの使い分け）
- ActiveXコントロールや参照設定など、移行時に陥りやすい「落とし穴」とその対処法
- 社内での修正可否を切り分けるための移行判断基準と、安全なテスト移行プロセス
Accessの32bitと64bitの違いがVBAに与える影響
Microsoft Office（Access含む）には、32bit（ビット）版と64bit版の2つのアーキテクチャが存在します。近年、新規に導入されるWindows PCやMicrosoft 365（旧Office 365）では、デフォルトで64bit版がインストールされるケースが一般的になりました。これにより、古いPC（32bit版Office環境）で問題なく動いていたAccessファイル（.mdbや.accdb）を新しいPCに移行した際、「コンパイルエラー」が発生して起動すらできなくなるトラブルが頻発しています。
なぜ環境が変わるだけでVBAが動かなくなってしまうのでしょうか。その最大の原因は、コンピュータがメモリ上のデータを処理する際の物理的な「アドレス（ポインタ）」の扱える幅が異なる点にあります。
32bit環境では、メモリのアドレスや識別子（ウィンドウハンドルなど）は4バイト（32ビット）で管理されていました。しかし、64bit環境ではこれが8バイト（64ビット）へと拡張されます。Access VBAの内部で、Windowsのシステム機能（Windows API）を直接呼び出す記述（Declareステートメント）を行っている場合、従来の32bit仕様のまま動作させようとすると、メモリのサイズ不一致が発生し、Accessが予期せぬクラッシュを起こしたり、コンパイルエラーとして処理を中断したりするのです。
32bit環境と64bit環境における主な違いを以下の表にまとめました。
| 比較項目 | 32bit版Access（Office） | 64bit版Access（Office） | VBA開発・保守への影響 |
|---|---|---|---|
| アドレス・ポインタのサイズ | 4バイト（32ビット） | 8バイト（64ビット） | API呼び出し時に引数や戻り値のデータ型を変更する必要がある。 |
| API宣言用のキーワード | Declare Function... |
Declare PtrSafe Function... |
64bit環境ではPtrSafe属性の記述が必須となり、無い場合はコンパイルエラー。 |
| ポインタ用データ型 | Long 型（4バイト整数） |
LongPtr 型（環境依存型） |
32bit/64bitの双方に互換性を持たせるため、LongPtrへの書き換えが必要。 |
| 外部コンポーネント | 32bit用のOCX / DLLのみ動作 | 64bit用のOCX / DLLのみ動作 | 古いActiveXコントロール（カレンダーなど）は64bit環境で動作しない。 |
| 最大メモリ制限 | 約2GB（システム全体で共有） | 実質制限なし（OS上限まで） | 大量データを扱うクエリや処理において、64bit化によりメモリ不足が解消される。 |
このように、単なるバージョンの違いではなく、内部的なデータ処理の枠組み自体が大きく変化しているため、VBAコード側の調整（マイグレーション）が必要不可欠となります。
VBAコードを64bit対応に修正するための具体的な手順
動かなくなったAccess VBAを64bit環境、または両方の環境で安全に動作させるためには、コードの書き換え手順を正しく理解する必要があります。主な修正ステップは以下の3つです。
1. PtrSafe属性の追加
Windows APIなどの外部DLLを呼び出すために、モジュールの先頭に記述される「Declare」ステートメントに対して、PtrSafeキーワードを挿入します。これは、VBAコンパイラに対し「このAPI呼び出しは64bit環境での動作を考慮して記述されている（安全である）」ことを通知するための宣言です。
【32bit専用の記述例】
Declare Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As Long, ByVal lpString As String, ByVal cch As Long) As Long【64bitに対応した記述例】
Declare PtrSafe Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As LongPtr, ByVal lpString As String, ByVal cch As Long) As LongPtrSafeというキーワードが、Declareの直後に配置されている点に注目してください。64bit環境では、この記述が1箇所でも欠けていると、ファイルを開いた段階で即座に実行時エラーとなります。
2. LongPtrデータ型への変更
APIの宣言文や、そのAPIとやり取りをする変数において、「ポインタ」や「ハンドル（hWnd、hDCなど）」を表すデータ型を、従来の Long 型から LongPtr 型に変更します。LongPtr は、動作しているOffice環境を自動的に判別し、32bit環境であれば4バイトの Long として、64bit環境であれば8バイトの LongLong（64ビット整数型）として自動的に振る舞いを変えてくれる、非常に便利な「エイリアス型」です。
注意点として、APIの引数のうち、ポインタやハンドル以外の「単なる数値（サイズやフラグなど）」を表す変数については、Long 型のまま変更しないようにしてください。すべてを LongPtr にしてしまうと、意図しないメモリ破損の原因となります。
3. 条件付きコンパイル（#If VBA7）の導入
社内でまだ32bit版Officeを利用しているPCと、64bit版に移行したPCが混在している場合、どちらの環境でもエラーなく動作する「マルチ環境対応」のコードを書く必要があります。これには「条件付きコンパイル引数（#If...Then...#Else）」を利用します。
【両環境に対応する条件分岐の記述例】
#If VBA7 Then
' Office 2010（VBA7）以降の環境で実行される（32bit/64bit両対応）
Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#Else
' Office 2007以前の古い32bit環境で実行される
Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#End IfVBA7 というコンパイル定数は、Office 2010（VBA バージョン7.0）以降で自動的に True と判定されます。この条件分岐を使うことで、1つのAccessファイルを複数のPC環境に配布しても、それぞれの環境に最適なコードが自動的に選択されて実行されるため、管理コストを大幅に下げることができます。
移行時に注意すべき3つの落とし穴とエラーの対処法
APIの宣言部に PtrSafe を追加するだけで解決すれば簡単ですが、実際の業務システム移行では、一筋縄ではいかない「落とし穴」がいくつか存在します。実務で特によく遭遇する3つの課題とその解決アプローチを紹介します。
1. 外部ActiveXコントロール（OCX）の互換性問題
古いAccessシステムで非常によく利用されている「カレンダーコントロール（MSACAL.calendar）」や、リスト表示を拡張する「Common Controls（MSCOMCTL.OCX：ListViewやTreeView、ProgressBarなど）」は、開発が終了しており、32bit版のライブラリしか提供されていません。これらは64bit版のOffice環境では動作させることができず、フォームを開こうとした瞬間に強制終了するか、コントロール自体が表示されずにエラーを引き起こします。
【対処法】
これらの古いActiveXコントロールは使用を諦め、Accessの標準機能に置き換える必要があります。たとえば、カレンダーはAccess 2010以降の標準機能である「日付選択カレンダー（日付型のテキストボックスに自動付与される機能）」に置き換え、ListViewは標準の「サブフォーム（データシートビュー）」や「リストボックス」にリファクタリング（再設計）を施すのが最も安全で、将来にわたってメンテナンスしやすい構成になります。
2. データベース参照設定の「参照不可（MISSING）」エラー
移行先の新しいPCに異なるバージョンのOffice（またはExcel）がインストールされていると、VBA内の「参照設定」が古いパスを追いかけてしまい、「参照不可（MISSING）」という状態に陥ることがあります。このエラーが発生すると、本来は互換性に問題がない単純な文字列操作関数（Left, Mid, Format など）ですら「プロジェクトまたはライブラリが見つかりません」という無関係なエラーを吐いて停止してしまうため、開発者を混乱させがちです。
【対処法】
VBAの開発画面（VBE）を開き、メニューの「ツール」＞「参照設定」を確認します。「参照不可」と書かれたチェックボックスが存在する場合は、一度そのチェックを外し、必要な場合は新しい環境に適したライブラリ（例：Microsoft Excel 16.0 Object Libraryなど）にチェックを入れ直します。可能であれば、プログラムを「参照設定（事前バインディング）」から、コード内でオブジェクトを動的に生成する「実行時バインディング（Late Binding：CreateObjectを使用）」に書き換えることで、バージョンの差異による参照エラーを根絶できます。
3. LongPtrとLongの混同によるメモリ破壊やクラッシュ
APIの書き換え作業中に、不要な箇所まで LongPtr に変更してしまったり、逆に LongPtr にすべきポインタ変数を Long のまま放置してしまったりすることがあります。64bit環境において、8バイトのアドレス値を4バイトの Long 変数に代入しようとすると、メモリ領域の超過（バッファオーバーフロー）が発生し、エラーメッセージすら表示されずにAccessアプリケーション自体が突然デスクトップから消滅する（クラッシュする）という深刻な事態を招きます。
【対処法】
使用しているすべてのAPI呼び出しについて、Microsoft公式ドキュメントやWindows APIの定義（Win32API_PtrSafe.txtなど）を参照し、どの引数が「ハンドル（hWnd等）」や「ポインタ」であり、どれが「単なる数値（定数）」であるかを1つずつ厳密に切り分けてコードを適用してください。感覚に頼った一括置換は極めて危険です。
32bitから64bitへの移行判断基準と実務での推奨プロセス
現在稼働中のAccessシステムについて、「32bit環境のまま引き伸ばすべきか、それとも今すぐ64bit対応化に踏み切るべきか」という移行判断は、システム管理者や現場の担当者にとって非常に悩ましい問題です。以下のチェックリストを参考に、自社に最適な判断を下してください。
移行を推奨する判断基準
- 社内PCのリプレイス計画がある： 今後2〜3年以内にPCの買い替えや、Windows 11、Microsoft 365（64bit推奨）への全社移行が予定されている場合、直前に慌てるのではなく、事前にAccessファイルの移行検証と改修を済ませておくべきです。
- Accessが頻繁にフリーズ・強制終了する： 扱っているデータのレコード数が数万〜数十万件を超え、複雑なクエリやマクロを実行した際に「メモリが不足しています」というエラーや処理遅延が発生している場合、64bit化することでPC本来のメモリ性能をフルに活かせるようになり、動作が劇的に安定・高速化します。
- 開発元・保守担当者が退職し、ブラックボックス化している： 動いているうちに専門家へ診断を依頼し、現在のソースコードが今後も動作し続けられる状態（近代化）にしておく必要があります。放置する期間が長くなるほど、将来的な移行コストは跳ね上がります。
実務における安全な移行推奨プロセス（4ステップ）
いきなり本番環境でAccessファイルを書き換えて配布すると、業務停止などの致命的なトラブルに直結します。必ず以下の安全なステップに沿ってテストを進めてください。
- ソースコードの静的解析（アセスメント）： 既存のAccessファイルをコピーし、VBAコード全体に対して「Declare」「PtrSafe」「ActiveX」といったキーワードで検索をかけ、改修が必要な箇所をすべてリストアップします。
- サンドボックス（検証環境）の用意： 本番環境に影響を与えないよう、64bit版のOfficeをインストールした検証専用のテストPCを社内に少なくとも1台確保します。
- コード改修と機能テスト： 修正手順に則り、コード書き換えを実施。テスト環境にて、データの入力、集計処理、PDFやExcelへのエクスポート、印刷など、日常業務で行うすべてのシナリオが問題なく完遂できるかを検証します。
- 段階的（並行）導入： まずは1〜2名のキーマンや特定部署のみ先行して新しい64bit対応版ファイルを配布し、実稼働で想定外のエラーが出ないかを1〜2週間モニタリングします。そこで問題がなければ、全社に向けて正式に展開します。
自社内での検証やコード改修において、「どのAPIをどう書き換えれば良いか判断がつかない」「エラーが多すぎてお手上げ状態になってしまった」という場合は、無理に自社対応を続けず、Access開発に精通したシステム開発会社へソースコードの診断と修復を相談することをお勧めします。プロに依頼することで、短期間で安全にシステムを延命・近代化することが可能です。
Access移行におけるよくある質問（FAQ）
32bit版から64bit版へのAccess移行に関して、現場のシステム担当者やユーザーから特によく寄せられる代表的な質問と回答をまとめました。
Q. PtrSafeをDeclareの後に追加すれば、すべてのエラーは消えますか？
A. いいえ、残念ながらそれだけでは解決しないケースが多いです。PtrSafeを付与することは、コンパイラに対して「64bitに対応するための修正を行います」と約束する宣言に過ぎません。宣言文の中にある変数や引数のデータ型（例：Long から LongPtr への変更など）を適切に修正し、さらにActiveXコントロール（OCX）の不整合などをすべて解消して初めて、エラーなく動作するようになります。
Q. 同一の社内ネットワーク上で、32bit版と64bit版のAccessファイルを共存・併用することは可能ですか？
A. 条件付きコンパイル（#If VBA7）を使用して、32bitと64bitのどちらの環境でも動くように作成されたAccessファイルであれば、共存および同一データの共有は可能です。ただし、1台のPCの中に「32bit版Office」と「64bit版Office」を同時にインストールすることは、Microsoft公式でもサポートされていないため、PCごとにどちらか一方のアーキテクチャに統一する必要があります。
Q. カレンダーやリストビューなどのActiveXコントロールが原因で動かない場合、どのような代替手段がありますか？
A. カレンダーについては、Access 2010以降であれば、日付型のテキストボックスを配置するだけで、ユーザー入力時に「カレンダーから日付を選択する簡易ポップアップ（日付選択コントロール）」が自動で表示されるため、これに置き換えるのが最も簡単です。リストビュー（ListView）については、Accessの標準機能である「サブフォーム（データシートビュー表示）」や「複数列対応のリストボックス」へデザインをリフォームすることで、32bit/64bitの壁を気にせず長期的に安定して稼働させることができます。
Q. 自社にAccess VBAの有識者がおらず、移行作業が進みません。外注する場合の注意点は？
A. 外注（アウトソーシング）する際は、単に「コードのコンパイルエラーを消す（PtrSafeを付けるだけ）」の対応ではなく、実務に即した結合テストまでをトータルで引き受けてくれる開発実績の豊富なパートナーを選ぶことが非常に重要です。また、今後再びアーキテクチャやOSの変更があっても困らないよう、「参照設定の整理」や「条件付きコンパイルを用いたマルチ対応」まで仕様書に残して納品してもらえるか確認すると良いでしょう。
