この記事で分かること
- 古いmdb形式と最新のaccdb形式におけるシステム上の違いと移行のメリット・デメリット
- 移行時に発生しやすい「参照設定」「VBAコード」「コントロール」の互換性トラブルの原因
- システムを破損させずに安全にaccdb形式へ変換するための実務的な5つのステップ
- Accessのまま使い続けるべきか、Webシステム化へ踏み切るべきかの明確な判断基準
mdb形式からaccdb形式へ移行すべき理由と仕様の違い
Access 2003以前の標準形式である「.mdb」と、Access 2007以降で導入された「.accdb」の間には、内部データベースエンジンやセキュリティモデルにおいて根本的な設計の違いがあります。古いmdbファイルを最新のWindows環境や最新のOffice（Microsoft 365など）で使い続けることは、動作の不安定化やセキュリティリスクの増大を招くため、早期の移行設計が強く求められます。
両者の最大の違いは、データを処理するデータベースエンジンにあります。mdb形式では「Jetデータベースエンジン」が使用されていましたが、accdb形式ではより堅牢な「ACE（Access Database Engine）」へと進化しました。これにより、暗号化アルゴリズムが強化され、データ破損のリスクが大幅に軽減されています。また、mdb形式では利用できなかった新しいデータ型や、添付ファイル機能などもaccdb形式ではサポートされています。一方で、かつて広く使われていた「ユーザーレベルセキュリティ」機能はaccdb形式で廃止されたため、これを利用しているシステムは移行にあたり注意が必要です。
| 比較項目 | mdb形式（Access 2003以前） | accdb形式（Access 2007以降） |
|---|---|---|
| 標準データベースエンジン | Jet (Microsoft Jet DB Engine) | ACE (Access Database Engine) |
| セキュリティ暗号化 | 古いRC4ベース（強度が低い） | 強固なAES暗号化に対応 |
| ファイルサイズ上限 | 最大2GB | 最大2GB（内部最適化による効率化あり） |
| ユーザーレベルセキュリティ | 対応（.mdwファイルによる制御） | 非対応（廃止） |
| 添付ファイル・複数値フィールド | 非対応 | 対応 |
mdbからaccdbへ移行するメリットは、最新のOffice環境において動作保証が得られる点と、セキュリティ面での脆弱性を克服できる点にあります。また、共有フォルダに置かれたファイルの読み書き時の耐久性も、新エンジンにより向上します。一方でデメリット（移行コスト）として、移行作業に伴う動作テストの手間や、一部の古いVBAコード・コントロールの書き換えコストが挙げられます。しかし、今後のビジネスにおけるOSアップデートやPCのリプレイスを考慮すると、移行は遅かれ早かれ避けられない必須のタスクと言えます。
mdbからaccdbへの移行プロセスで発生する代表的な互換性トラブル
長年にわたり改修が繰り返されてきたmdbファイルをaccdbに単純変換すると、多くのケースでエラーが発生します。実務においてシステム移行の障壁となりやすい、代表的な4つの互換性トラブル要因を技術的な視点から詳しく見ていきましょう。
1. 参照設定のミスマッチ（「参照不可」エラー）
AccessのVBAプロジェクトで他ツールやライブラリを操作するために登録されている「参照設定」が、新しいAccessの環境に存在しない場合に発生するエラーです。例えば、古いバージョンのDAOライブラリ（「Microsoft DAO 3.6 Object Library」など）への参照設定が残っていると、accdb変換後に「参照不可（MISSING）」とマークされ、システム全体がコンパイルエラーになります。accdbでは、最新の「Microsoft Office Access database engine Object Library」に自動的、もしくは手動で置き換える必要があります。
2. VBAにおける64bit API宣言の不整合
現在導入されているOfficeの多くは64bit版です。一方で、古いmdbが作成された当時は32bit版Officeが主流でした。VBAコード内でWindowsの基本機能（Win32 API）を直接呼び出している場合（例：ファイルの選択ダイアログ、待機処理を行うSleep関数など）、従来の宣言方法のまま64bit版Accessで実行しようとすると、コンパイルエラーが発生してマクロの実行が完全に停止します。32bit用ポインタと64bit用ポインタの違いを吸収するために、VBAコード側の記述方法を適切に変更する必要があります。
3. 非推奨・廃止されたActiveXコントロールの不整合
かつてmdbの入力フォームで頻繁に使用されていた特定のActiveXコントロールの一部は、現在のAccessでは完全にサポートが打ち切られています。特に代表的なのが、日付選択で多用された「カレンダーコントロール（MSCAL.Calendar）」です。これが配置されたままのフォームを開こうとすると、オブジェクトが読み込めない旨のエラーが表示され、画面のデザインが崩れたり、入力処理が動作しなくなったりします。その他、古いバージョンのTreeViewやListViewなども同様の不具合を引き起こす温床となります。
4. ユーザーレベルセキュリティ設定（.mdw）の非サポート
mdb形式では、ワークグループ情報ファイル（.mdw）を利用してユーザーごとに閲覧・編集権限を制御する「ユーザーレベルセキュリティ」が利用可能でした。しかし、この機能はaccdb形式では完全に廃止されています。セキュリティ設定が施されたmdbファイルを変換すると、権限情報を読み込めなくなるため、データベースへのアクセス自体が拒否されるか、全ての権限が無効化されてしまうなどのトラブルが生じます。移行する前に、権限管理の設計自体を見直す必要があります。
移行作業を安全に進めるための具体的な確認ポイントと対処手順
互換性の課題を克服し、安全かつ確実にデータベースの移行を遂行するための実務フローを紹介します。場当たり的に変換を行うのではなく、以下のステップを踏むことで手戻りやデータ破損の危険を最小限に抑えられます。
ステップ1：現状のバックアップと動作環境の確認
移行作業を開始する前に、必ず元のmdbファイルの複製を作成し、安全な場所に保管してください。また、新しく移行先となるPCのOSバージョンおよび、インストールされているMicrosoft Office（Access）が「32bit版」か「64bit版」かを必ず確認してください。このビット数の違いによって、後に発生するVBAエラーの修正方針が大きく分岐します。
ステップ2：ファイル形式の標準変換処理
最新のAccessを起動し、対象のmdbファイルを開きます。その後、メニューの「ファイル」から「名前を付けて保存」を選択し、「accdb形式（Access データベース）」を選択して新しい名前で保存を実行します。ここで変換自体に失敗する場合は、データベースファイルが部分的に破損している可能性があるため、あらかじめ「データベースの修復・最適化」を行ってから変換を再試行します。
ステップ3：VBAデバッグと64bit API対応の書き換え
変換したaccdbファイルを開き、Visual Basic for Applications（VBA）のエディタ画面を立ち上げます。メニューの「デバッグ」から「セグメントのコンパイル」を実行し、エラーが発生する箇所を特定します。特に64bit版Officeを導入している場合は、API宣言の記述を以下のように修正する必要があります。
' --- 旧32bit環境用のAPI宣言（修正前） ---
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
' === 32bit/64bit両方に対応させた宣言（修正後） ===
#If VBA7 Then
Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#Else
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#End If
このように、#If VBA7という条件付きコンパイル文を利用し、新しいVBA環境（VBA7）であればPtrSafeキーワードを付与して呼び出すようにコードを修正します。また、ハンドルやポインタを処理する変数や引数の型がLong型で宣言されている場合は、64bit環境でも適切に処理ができるようLongPtr型への変更も併せて実施してください。
ステップ4：非推奨コントロールの代替対応
前述した「カレンダーコントロール（MSCAL.Calendar）」などのエラーが起きている箇所は、該当するActiveXコントロールをフォームから削除します。Access 2007以降では、日付型のフィールドにバインドされたテキストボックスであれば、プロパティシートの「日付選択カレンダーの表示」を「日付」に設定するだけで、標準機能として近代的な日付選択ポップアップが表示されるようになります。独自開発された古いコントロールは、極力Access標準のパーツに置き換えることが運用の安定化に繋がります。
ステップ5：データ連携・テストと稼働検証
もしフロントエンド（画面やマクロを格納したファイル）とバックエンド（データテーブル専用のmdbファイル）に分割して運用している場合は、双方をaccdb形式に変換した上で、フロントエンド側の「リンクテーブルマネージャー」を起動し、接続先となるパスを新しいaccdbファイルに更新します。その後、帳票のテスト印刷やデータの書き込みテストを入念に実施し、エラーが発生しないことを検証してください。
互換性トラブルを解消した後の運用と将来的なWebシステム化
無事にmdbからaccdbへの移行作業を終えたとしても、それで企業のシステム課題がすべて根本解決するわけではありません。Accessというツールには、物理的な仕組みに起因する重大な制約や限界が依然として残されているためです。
特に顕著な課題となるのが、「同時利用時の書き込み競合によるデータ破損」「ファイルサイズ2GBの制限」「拠点間ネットワーク経由での動作遅延」です。多くのスタッフが共有フォルダ上の1つのAccessファイルを同時に操作すると、排他制御の失敗によってデータベースが破損する確率が高まります。また、リモートワークや拠点間のネットワーク越しでの利用においては、Accessの通信処理量が多くなるため動作が極端に重くなり、実用に耐えないケースが多々見られます。したがって、現状の移行をクリアした後は、システムを「Accessのまま修正を重ねて延命させるか」、あるいは「クラウド対応のWebシステムへと刷新するか」を中長期的な視点で検討することが重要です。
以下の条件に該当する場合は、Accessのアップデートに終始するのではなく、Webシステム化を本格的に推進すべきタイミングと言えます。
- 複数の拠点やテレワーク環境からシステムに同時アクセスしたい場合（ネットワーク遅延問題の解決）
- システムの同時利用人数が常に5〜10名を超えており、頻繁にフリーズや破損が起きる場合
- PCだけでなく、スマートフォンやタブレットなどのマルチデバイスから業務データを閲覧・更新したい場合
- データの蓄積量がファイルサイズ上限（2GB）に近づいており、過去ログの削除や分割作業が負担になっている場合
Webシステム化を行うことで、データベースをMicrosoft SQL ServerやPostgreSQLなどの強固なサーバー環境へ集約し、ブラウザを介していつでも、どこからでも高速かつ安全に業務システムへアクセスできる環境を構築できます。単なるファイル形式の変換作業をきっかけに、自社の業務プロセスをさらに進化させるDX（デジタルトランスフォーメーション）への一歩を踏み出すことも視野に入れてみてください。
Q. mdbをaccdbに変換する際、既存のVBAマクロは全て書き換えが必要ですか？
いいえ、必ずしも全てを書き換える必要はありません。大半の通常の処理（クエリの実行、フォーム操作、Excel出力など）を担う標準的なVBAコードはそのまま動作します。書き換えが必要になるのは、Windows APIの直接呼び出し（Declare宣言が含まれる記述）を行っている部分や、古い参照設定に依存している処理、廃止されたカレンダーなどのコントロールを利用している箇所のみに限定されます。
Q. 64bit版のAccessでmdb形式を使い続けることは可能ですか？
技術的には、64bit版Accessであってもmdbファイルをそのまま開いてデータを参照・更新することは可能な場合があります。しかし、Jetデータベースエンジン向けの古いモジュールやVBAコードが混在していると、予期せぬ重大なコンパイルエラーや動作不良を引き起こす可能性が極めて高く、マイクロソフトの動作保証やサポートの対象からも外れるため、速やかにaccdb形式へ変換することをおすすめします。
Q. 移行作業中にデータベースが破損して開けなくなってしまった場合の対応は？
まず、変換前のバックアップファイルに戻して作業を再開してください。移行前のmdbファイル自体に内部エラーが含まれていることが原因であるため、移行前の環境でAccessの標準機能である「データベースの最適化/修復」を実行します。それでも破損が解決しない場合は、新規に空のaccdbファイルを作成し、そこへ古いmdbファイルからテーブルやクエリなどのオブジェクトを1つずつ「外部データのインポート」機能で段階的に移送し、どのオブジェクトが破損しているかを切り分ける方法が有効です。
