この記事で分かること
- ExcelマクロとAccess連携でエラーが発生する主な技術的原因と仕組み
- WindowsやOfficeのアップデートによる影響とエラー回避のポイント
- 専門のシステム開発会社へ修正依頼を出す前に準備しておくべき情報
- 失敗しない外注先の選び方と、将来的なシステム刷新（Web化など）の視野
ExcelマクロとAccess連携が動かなくなる技術的原因
Excel VBAからAccessへデータを流し込んだり、逆にAccessからデータを取り出したりする処理は、一般的に「ADO（ActiveX Data Objects）」または「DAO（Data Access Objects）」と呼ばれる外部ライブラリを用いてプログラムが組まれています。この連携部分が何らかの原因で遮断されると、突然システム全体が停止します。
主な原因として、以下の4つの技術的要素が挙げられます。
1. 参照設定の「MISSING（参照不可）」エラー
Excelマクロは、外部プログラム（Accessなど）を操作するために「参照設定」という仕組みを利用しています。OfficeのアップデートやPCの買い替えに伴い、指定されたバージョンのライブラリ（例：Microsoft Office 16.0 Access Database Engine Object Library など）がPC内に存在しなくなると、「参照不可（MISSING）」となり、コンパイルエラーが発生してマクロが一切動かなくなります。
2. 接続文字列（ConnectionString）とプロバイダの不一致
ExcelからAccessのデータベースファイル（.mdb または .accdb）に接続する際、「接続文字列」という接続先や認証情報を記したコードを使用します。
- 旧形式のAccess（.mdb）：
Provider=Microsoft.Jet.OLEDB.4.0; - 新形式のAccess（.accdb）：
Provider=Microsoft.ACE.OLEDB.12.0;（バージョンにより数値は異なる）
データベースのファイル形式を変更したにもかかわらず、マクロ内の接続文字列が古いまま（Jetプロバイダのまま）になっていると、「プロバイダーが見つかりません」などのエラーで接続に失敗します。
3. Officeのビット数（32bit / 64bit）による互換性問題
近年、多くの企業でPCの買い替えやOfficeの再インストールに伴い、Office（Excel）が32bit版から64bit版へ移行しています。VBA内で外部のDLLを呼び出すAPI宣言（Declareステートメント）が使用されている場合、64bitに対応した記述（PtrSafeキーワードの追加や変数の型変更）を行わないと、コンパイルエラーでマクロが実行できなくなります。
4. テーブル構成（スキーマ）やデータ型の変更
Access側のテーブル構造を変更（フィールド名の変更、データ型の変更、主キーの設定など）したにもかかわらず、Excelマクロ側のSQL文（INSERT INTO、UPDATE、SELECTなど）やVBAコードが古い構造のままになっている場合、実行時にデータ型不一致などのエラーが発生します。
| エラーの事象 | 主な原因 | 発生しやすいシチュエーション |
|---|---|---|
| コンパイルエラー：ユーザ定義型が定義されていません | 参照設定（DAO / ADO）の外れ、またはライブラリのバージョン変更 | PCの入れ替え、Officeのバージョンアップ時 |
| 実行時エラー ‘3706’: プロバイダーが見つかりません | 接続文字列の指定ミス、または64bit/32bitの互換性なし | Accessファイルを.accdbに更新した、Excelを64bit化した時 |
| 実行時エラー ’70’: 書き込み禁止、またはアクセス拒否 | Accessファイルが読み取り専用、または他ユーザーによる排他ロック | 複数人での同時操作時、ネットワーク共有フォルダの権限不足 |
| コンパイルエラー：このコードは64ビットシステムでの使用向けに更新する必要があります | Windows API宣言にPtrSafe属性がない | PCの買い替えに伴うOfficeの64bit化 |
Access連携マクロが動かなくなる5つのきっかけ
システム自体には何も手を加えていないはずなのに、ある日突然動かなくなるケースが非常に多いのがこの連携システムの厄介な点です。その背景には、以下のような実務上の「きっかけ」が存在します。
1. WindowsやMicrosoft Officeの自動アップデート
最も頻発するのが、Microsoftによる定期アップデートです。セキュリティパッチの適用により、これまで許可されていたマクロの実行や外部ファイルへのアクセスが急にブロックされることがあります。また、セキュリティ向上のために「インターネットやネットワークから取得したファイルをブロックする」設定が自動で適用されることも原因の一つです。
2. ファイルサーバーの移行や共有フォルダのパス変更
社内のファイルサーバーが新しくなったり、NAS（ネットワークHDD）のIPアドレスやフォルダ階層が変更されたりした場合に発生します。Excelマクロ内にAccessデータベースの保存場所が「絶対パス（例: C:\Folder\database.accdb または \\Server\Folder\database.accdb）」で直接書き込まれている（ハードコーディングされている）と、パスが変わった瞬間に関連付けが切れ、データベースを見つけられなくなります。
3. Accessのデータベース形式の更新（.mdb から .accdb）
セキュリティ面やサポート切れの観点から、古いAccessファイル（.mdb）を最新の（.accdb）に変換して保存し直した際、Excel側のマクロに組み込まれている「接続ドライバー」のプログラムを修正し忘れることで、データ連携部分で致命的なエラーが発生します。
4. PCの買い替えによるOfficeのビット数変更
新しく購入したPCにプリインストールされているOfficeが64bit版である場合、従来の32bit版Officeで作成されたVBAマクロ（特に外部連携やAPI呼び出しを行うもの）は、そのままでは動作しない可能性が極めて高くなります。社内で「ある人のPCでは動くが、自分のPCでは動かない」という現象が起きている場合、このビット数違いが原因であることがほとんどです。
5. 複数ユーザーの同時アクセスによる競合
Accessはファイルベースのデータベースシステムです。アクセス集中時の排他制御（ロック処理）がVBA側で適切に設計されていないと、同時に複数のExcelからAccessにデータを書き込もうとした際に競合が発生し、ファイルが破損したり、「データベースがすでに開かれている」といったロックエラーが発生してシステムがダウンします。
プロに修正依頼する前に確認・準備すべき4つのポイント
「マクロが動かなくなったので直してほしい」と外部の開発会社やフリーランスのエンジニアに相談する際、事前の情報整理ができているかどうかで、見積もり回答の早さや修正にかかる工数（コスト）が劇的に変わります。以下の4つのポイントを準備・確認しておきましょう。
1. 正確なエラーメッセージと発生箇所の特定
エラーが発生した瞬間に画面に表示されるダイアログボックスのスクリーンショットを保存してください。また、VBAのエラー画面で「デバッグ」ボタンが押せる場合は、デバッグをクリックして黄色くハイライトされているプログラム行を確認し、そのコード部分も画像やテキストとして控えておきます。これらは開発者にとって最も価値のある手がかりです。
2. 現状のシステム環境情報の整理
プログラムが動作している環境情報は非常に重要です。以下の項目をあらかじめメモしておきましょう。
- OSのバージョン: Windows 10 または 11
- ExcelおよびAccessのバージョン: Office 365, Office 2021, 2019など
- Excel・Accessのビット数: 32bit版か、64bit版か（確認方法：Excelの「ファイル」＞「アカウント」＞「Excelのバージョン情報」）
- 動作しているPCの台数: 特定のPCだけで発生するのか、社内の全PCで発生するのか
3. 最新のファイル一式（テスト用データの準備）
開発会社がバグを再現し、修正作業を行うためには、実際に動かしていた「Excelマクロ有効ブック（.xlsm）」と「Accessデータベースファイル（.accdb / .mdb）」の現物が必要です。ただし、個人情報や極秘の社外秘データが含まれている場合は、ダミーデータ（テスト用の架空の氏名や数値など）に置き換えた「テスト用ファイル」を準備して提供できるようにしておくと、セキュリティ的にも安心です。
4. トラブル発生前後の変化（タイムライン）の整理
「いつから動かなくなったか」および「その前後に何があったか」を時系列で整理します。
- 「先週のWindows Updateのあとに急に動かなくなった」
- 「社内サーバーをクラウド（SharePointやOneDriveなど）に移行してからエラーになるようになった」
- 「PCを新しいものに交換してからエラーが発生するようになった」
このような背景情報は、エンジニアが原因を一瞬で見抜くための強力なヒントになります。
外注先（開発会社）の選び方と失敗を防ぐチェックリスト
ExcelマクロやAccessの改修・修復を外部に依頼する場合、どのようなパートナーを選ぶべきでしょうか。単に「システム開発ができる」という会社に依頼すると、思わぬミスマッチが生じることがあります。以下のチェックリストを基準に選定を行ってください。
1. ExcelとAccess「双方」のVBA開発実績があるか
システム開発会社の中には、Webアプリや大規模な基幹システムの開発は得意でも、ローカルPC上で動くExcel VBAやAccessの特性を深く理解していないところもあります。「ExcelマクロからADOを経由してAccessを制御する」といった、デスクトップ連携固有のノウハウを豊富に持っている会社を選ぶことが、スピーディな解決の鍵となります。
2. コードやデータベースの「納品・公開」方針を確認する
修復作業を依頼する際、修正後のVBAプロジェクト（ソースコード）がパスワードでロックされずにオープンな状態で納品されるかを確認しましょう。コードがブラックボックス化されてしまうと、将来的に再び軽微な修正が必要になった際に、同じ業者に依存し続けなければならなくなり、余計なコストが発生します。
3. 将来的なシステム刷新（Web化やDB移行）を視野に入れた提案ができるか
ExcelとAccessの連携は非常に手軽で便利ですが、企業の成長に伴ってデータ量が肥大化すると、Accessの容量限界（2GB）に達したり、同時アクセスによるファイル破損リスクが高まったりします。単にマクロを「その場しのぎ」で修理するだけでなく、「データ量が増えてきたので、次はSQL Serverへ移行しましょう」「将来的にはWebシステム化して、マルチデバイスで使えるようにしましょう」といった、中長期的なDX・システム開発のロードマップを提示できるパートナーが理想的です。
| 選定基準 | 確認ポイント | 選ぶべき理由 |
|---|---|---|
| 専門知識の有無 | Excel VBAとAccess（ADO/DAO）の具体的な改修実績がホームページ等に掲載されているか。 | トラブルの原因特定が早く、工数（開発費）を大幅に削減できるため。 |
| 対応スピードと柔軟性 | 既存の壊れたシステム（他社製マクロや自作マクロ）の現状分析・ソース解析に対応してくれるか。 | 仕様書がない状態からでも、ソースコードを直接解読して修復できるため。 |
| 拡張提案力 | Accessの限界を理解し、SQL Server移行やWebシステム化へのアップグレード提案ができるか。 | 業務の拡大に合わせて、システムを無理なくステップアップさせることができるため。 |
ExcelとAccessの連携トラブルに関するよくある質問
マクロの作成者が退職し、VBAにロック（パスワード）がかかっていてコードが見えません。それでも修理は依頼できますか？
はい、対応可能です。専門の開発会社であれば、一定の技術的アプローチによりVBAのロック解除や解析、あるいは同様の処理を行うマクロの再構築を行うことができます。パスワードが不明な場合でも、まずはそのままのファイルをお見せいただき、ご相談ください。
Accessの容量上限（2GB）に達してシステムが動きません。応急処置はありますか？
応急処置としては、Accessの「データベースの最適化と修復」を実行することで、一時的にファイルサイズを縮小させ、動作を回復させることができます。ただし、根本的な解決にはデータベース内の不要な古いデータを別ファイルにアーカイブするか、Microsoft SQL Serverやクラウドデータベース等への移行設計が必要です。
特定のPCでのみ「参照不可」エラーが発生します。どうしてでしょうか？
そのPCにインストールされているOfficeのバージョンやビット数が、他のPCと異なっている可能性が高いです。特に「64bit版Office」がインストールされているPCでは、従来の「32bit用ライブラリ」を読み込めずエラーになります。VBAの参照設定を見直すか、プログラム内でビット数に依存しない「レイトバインディング（CreateObject関数を使用する動的結合）」の記述に書き換えることで解消できます。
修復の費用はどのくらいかかりますか？
パスの変更やライブラリの参照設定変更など、軽微なバグ修正であれば数万円程度の低予算（クイックパックなど）で迅速に解決できる場合が多いです。一方で、データベース設計自体の見直しや、複数個所のソースコードの書き換えが必要な場合は、10万〜50万円以上の開発費用が必要になる場合もあります。まずは現状分析と診断（ロードマップ策定など）を受けられることをお勧めします。
