Accessが遅いときの原因切り分けと総合対処

結論：原因の種類によって対処が全く変わる

「Accessが遅い」という相談を受けたとき、最初にやることは原因の特定です。ファイルの肥大化なのか、クエリ設計の問題なのか、ネットワーク経由の使い方なのかによって、対処は全く異なります。ここを飛ばして「全部最適化してみた」という対応では、当たることもあれば全く効かないこともある。

この記事では、Accessが遅くなる原因を6つのカテゴリに分けて切り分け方を整理します。各カテゴリの詳しい手順は既存の個別記事に委ねているので、まずここで自分のケースがどれに当たるかを判断してください。

原因カテゴリの切り分け表

以下は当社が移行支援や改善対応の中で積み重ねてきた実務上の分類です。複数が重なっているケースも珍しくありませんが、まず症状から一番疑わしいカテゴリを絞ります。

A. ファイル肥大化・未最適化

Accessは通常の使用中に削除したオブジェクトや一時オブジェクトの領域をそのまま抱え込みます。Microsoftの公式ドキュメントには「オブジェクトを開くのが遅くなり、クエリの実行が通常より長くかかり、一般的な操作が全体的に遅く感じられる」と記載されており（Compact and repair a database | Microsoft Support）、最適化（コンパクト）を実行すると未使用領域が除去されて速度が戻ることがあります。

また、Microsoftの公式ページ「Help Access run faster | Microsoft Support」には、Name AutoCorrectの無効化、閉じるときに自動コンパクトする設定（Compact on Close）の有効化も速度改善策として挙げられています。Name AutoCorrectはオブジェクト名の変更を自動追跡する機能で、設計が固まったデータベースでは切っておいて問題ありません。なお、Compact on Closeはクローズ時にデータベースの可用性を一時的に妨げるため、複数人で共有しているデータベースでは設定しない選択肢もあります（同公式ページより）。

最適化の正しい手順と、最適化では直らない破損パターンについてはAccessの「最適化/修復」の正しい使い方と修復できない壊れ方で整理しています。

B. クエリ設計・インデックス不足

当社がAccess改善案件で最も多く見てきた原因がこれです。絞り込みや結合に使っている列にインデックスがない、DLookup・DSumをクエリの列として何行分も呼び出している、という2パターンが大半を占めます。データが少ないうちは気にならなくても、行数が増えると一気に重くなるので「昔は速かったのに」という訴えはだいたいこれです。

Microsoftのperformance全般のページでも「インデックスを作成することが最もよいパフォーマンス改善策の一つ」と明記されています。WHERE句の絞り込み列や結合列に利用可能なインデックスがなければ、ACEエンジンがテーブルを先頭から全件なめる処理（テーブルスキャン）が発生しやすくなります。

切り分け方として、まず遅いクエリをデータシートビューで単体実行してみてください。フォームで遅くても単体のクエリは速い場合、コンボボックスなどが別途クエリを多発している可能性があります。クエリ自体が遅いならインデックスとドメイン集計関数の見直しが有効です。

詳しい改善手順はAccessクエリ高速化の技術とAccessのインデックス設計を参照してください。

C. ネットワーク共有・同時利用

Accessはファイル型データベースです。ファイルサーバー上の1つのaccdbを複数人が直接開く構成では、各ユーザーのPCがネットワーク越しにデータページを都度引き取りに行きます。ユーザーが増えるほど遅くなるのはこの設計上の特性で、クエリやインデックスの最適化だけでは構成上の制約を完全には解消できません。

Microsoftの公式ドキュメントによると、Accessファイルサーバー構成は最大255ユーザーまで接続できますが、頻繁にデータを追加・更新する用途では25〜50ユーザーを目安にするよう注記されています（Description of Access lock files (laccdb and ldb) | Microsoft Learn）。

まず試せる応急策はDB分割（フロントエンド/バックエンド分離）です。テーブルだけをサーバーに置き、フォームやクエリを含むフロントエンドを各自のPCにコピーする構成にすると、ネットワーク転送量が減って速度が改善します。同時利用者が多い場合や根本解決が必要な場合は、SQL Serverへのバックエンド移行が選択肢になります。

詳細はAccessが複数人で使うと遅い・壊れる原因を参照してください。

D. ネットワーク経由のリンクテーブルとパス管理

リンクテーブルの接続パスがマップドドライブ（例: Z:\db.accdb）で設定されている場合、ドライブの割り当てが変わったり切れたりすると接続の確認や再試行で遅延が出ます。UNCパス（例: \\server\share\db.accdb）で設定し直すと、ドライブ割り当てへの依存を避けられます。

また、リンクテーブルのパスが古いままになっていると、開こうとするたびにAccessが接続試行を繰り返す場合があります。当社が確認した事例では、これが原因で起動や表示に大幅な時間がかかっていたケースがありました。リンクテーブルマネージャーで接続先を確認・再設定するのが診断の第一歩です。詳しくはAccessリンクテーブル運用の注意点を参照してください。

E. 2GB上限への接近

Accessのデータベースファイルは2ギガバイト（システムオブジェクト分を除く）が上限です。これは公式仕様として明記されています（Access specifications | Microsoft Support）。2GBに接近すると書き込み失敗や保存できないエラーが発生するリスクが高まります。速度低下の直接原因とは別の問題ですが、同時に発生していることが多いため切り分けが必要です。未使用領域の蓄積でファイルが膨らんでいる場合は最適化でサイズが縮小して動作が安定することがあります。実データ量が原因の場合は最適化では解消しません。

ファイルサイズは、エクスプローラーでaccdbファイルを右クリックしてプロパティを開けば確認できます。当社では運用上の警戒目安として1.5GBを使っていますが、実際の危険度は今後の増加量や一時処理の必要容量によっても変わります。データ量が原因なら設計や運用の見直しか、バックエンドをSQL Serverへ移すことを検討してください。詳細はAccessの2GBの壁とは？を参照してください。

F. マシン・環境要因

特定のPC1台だけ遅い場合は、そのPCのスペックや設定が原因のことがあります。Microsoftの公式ページでは、RAMの追加、不要なプログラムの終了、ハードディスクのクリーンアップ、不要なWindowsサービスの無効化なども改善策として挙げられています。

見落としやすいのがウイルス対策ソフトです。当社が確認した事例では、リアルタイムスキャンが.accdbや.laccdb（ロックファイル）に干渉して、ファイルの開閉や書き込みのたびにスキャン待ちが発生して遅くなるケースがありました。ウイルス対策ソフトの除外設定についてはウイルス対策ソフトでAccessが遅い・壊れる？で詳しく説明しています。

また、AccessがSQL ServerやCSVなど外部データへのリンクテーブルを大量に持っている場合、起動時の処理（AutoExecマクロや起動フォームなど）がそれらを参照・更新していると遅くなることがあります。使っていないリンクテーブルが放置されていないか確認してみてください。

改善が見込めない場合や、複数の原因が重なって根本解決が必要な場合は、無料の解析可否チェックでファイルを送らずに状況を仮判定できます。

よくある質問

Q. 最適化（コンパクト）しても速くならないのはなぜですか。

最適化が効くのは、主にファイルの未使用領域が原因のケースです。実データ量の増加が原因のケースでは最適化では改善しません。クエリ設計、インデックス不足、ネットワーク構成が原因の場合も同様です。ただし、2GB付近まで膨らんでいても未使用領域が多い場合は最適化でサイズが縮小して改善することがあります。症状から原因カテゴリを絞って対処する必要があります。

Q. DB分割（フロントエンド/バックエンド）にすると確実に速くなりますか。

ネットワーク共有による速度低下（カテゴリC）には有効なことが多いですが、クエリ設計やインデックス不足が原因の場合は効きません。また、分割後もバックエンドがネットワーク上にある以上、同時書き込みの競合やAccess固有の2GB上限はそのまま残ります。

Q. SQL Serverに移せば必ず速くなりますか。

バックエンドをSQL Serverに移すと、Accessのファイル共有方式に起因する2GB上限の制約は解消できます。同時実行性も高まりますが、SQL Serverでもロック待ちや書き込み競合は発生するため、競合がゼロになるわけではありません。また、Accessフロントエンドファイル自体の2GB制約はそのまま残ります。クエリ設計やインデックス不足の問題も残るため、当社の経験では移行後にクエリの見直しが必要なケースは珍しくありません。移行の方法によってはパフォーマンスが下がるケースもあるため、設計の検討が欠かせません。

Q. 原因が複数重なっている場合、どこから手をつければいいですか。

まずカテゴリEの2GB接近を確認してください。ここが問題なら他の改善が無意味になることがあります。次に、遅いクエリを単体で実行してクエリ単体の遅さか環境の問題かを切り分けてください。特定のクエリだけ遅い→カテゴリB、全体的に遅い→カテゴリA、複数人で遅い→カテゴリC、という順番で絞るのが実務上の手順です。