この記事で分かること
- Accessの起動が極端に遅くなる4つの根本原因
- 起動速度を劇的に改善するAutoExecマクロと初期表示フォームの最適化手順
- ネットワーク共有環境（NAS・ファイルサーバー）における高速化テクニック
- データベースのパフォーマンスを維持するための開発者向けチューニング設定
Accessの起動が遅いと感じたときにまず疑うべきポイント
Accessデータベースの動作や起動が重くなると、多くの人が「登録されているデータ件数が多すぎるのではないか」「ファイルサイズが上限（2GB）に近づいているからではないか」と考えがちです。しかし、実は空のデータベースファイルであっても、起動時の設定や設計が適切でないと、起動に数十秒以上の時間がかかることがあります。
起動速度の低下を引き起こす主な原因は、ファイルサイズそのものよりも、「起動した瞬間にAccessが何を行っているか」という内部処理にあります。特に、以下の要因が複合的に絡み合っているケースが目立ちます。
- ネットワーク経由でのデータ接続：サーバー上の共有ファイルに直接アクセスしている場合、起動時にすべてのテーブルの接続確認が行われ、通信のボトルネックが発生します。
- 重すぎる初期起動プロセス：起動と同時に大量のデータを読み込んだり、複雑な集計クエリを実行したりする設計になっている。
- 不要な参照設定やコンパイル未実行：プログラム（VBA）の実行準備に時間がかかっている。
まずは、どのような要素が起動速度に影響を与えているのか、全体像を整理してみましょう。以下の表は、各要因の影響度と改善の難易度をまとめたものです。
| 主な要因 | 起動への影響度 | 改善の難易度 | 具体的な対策 |
|---|---|---|---|
| ネットワーク（リンクテーブル） | 極大 | 中 | フロントエンドのローカル配置、常時接続の維持 |
| スタートアップフォームのクエリ | 大 | 低 | フォームの非連結化、遅延読み込みの実装 |
| AutoExecマクロの初期化処理 | 大 | 低 | 不要な起動時処理の削減・タイミング分散 |
| データベースファイルの肥大化 | 中 | 低 | 「データベースの最適化と修復」の実行 |
| サブデータシートの自動作成 | 中 | 低 | テーブルプロパティの「サブデータシート名」を「なし」に設定 |
| 参照設定の破損・コンパイル未実行 | 小 | 低 | VBAのコンパイル、不要な参照の解除 |
このように、原因に応じた適切なアプローチをとることで、システムを大幅に書き換えることなく、起動速度を劇的に改善することが可能です。
起動速度を左右する起動時処理の見直し
Accessが起動する際、最初に実行される「AutoExec（オートエグゼック）マクロ」や「スタートアップフォーム（最初に開く画面）」の設定は、起動速度にダイレクトに影響します。ここを見直すだけでも、体感速度が大きく向上します。
1. AutoExecマクロの記述内容をチェックする
AutoExecマクロは、Accessファイルがダブルクリックされて開かれた瞬間に、ユーザーの操作を介さずに自動実行される特殊なマクロです。ここに以下のような処理が組み込まれていると、画面が表示される前に処理待ちが発生し、起動が遅くなります。
- 過去データのバックアップや、古い一時データ（ワークテーブル）の削除クエリの実行
- マスタデータの最新化のための、外部データ（CSVやExcel）のインポート処理
- 外部システム（Web APIやSQL Serverなど）との通信同期処理
【対策】：これらの処理は、必ずしも「起動した瞬間」に完了している必要はありません。例えば、一時データのクリアは「メニュー画面から特定の処理ボタンを押した時」や「システムを終了する時（閉じる時）」に実行するようにタイミングをずらしましょう。起動時は、システムの「初期表示に必要な最低限の処理」のみに絞り込むことが鉄則です。
2. スタートアップフォームの読み込み負荷を軽減する
Accessの設定で「フォームの表示」に指定されている起動時フォーム（メニュー画面やメインダッシュボード）の設計も重要です。このフォーム自体に重いデータが紐づいていると、起動が極端に遅くなります。
特に避けるべきなのは、「起動画面に大量のレコードを表示する仕様」です。例えば、起動画面を開いた瞬間に、数万件の売上データ一覧がサブフォームに全件表示されるような設計です。Accessは起動時に、その数万件のデータをネットワーク越しにすべてローカルメモリに読み込もうとします。
【具体的な改善手順（フォームの非連結化）】：
- 起動用のメニュー画面（メインフォーム）は、特定のテーブルやクエリに接続しない「非連結（レコードソースを空にする）」にします。
- データを表示するサブフォームがある場合は、起動時には何も表示しない（空の）状態にしておきます。
- ユーザーが「日付」や「担当者」などの検索条件を指定し、「検索」ボタンをクリックしたタイミングで初めて、サブフォームのレコードソース（RecordSourceプロパティ）にSQLやクエリを設定してデータを読み込ませます。
この「必要なときに、必要な分だけデータを読み込む（オンデマンド読込）」設計に移行するだけで、起動時間はほぼゼロ（一瞬で開く状態）になります。
3. 初期化処理（VBA）の実行イベントを見直す
フォームが開く際、VBA（Visual Basic for Applications）で初期化処理を行う場合、イベントの選択にも注意が必要です。フォームの「開くとき（Form_Open）」イベントは、フォームが画面に描画される前に実行されるため、ここに重いクエリ処理やDLookup関数などのデータ取得処理を大量に記述すると、描画自体がブロックされて「画面が固まった」ような状態になります。
描画をスムーズに行うためには、初期化処理を「読み込み時（Form_Load）」や、フォームが表示された後の「タイマ時（Form_Timer）」イベントなどを利用してわずかに遅延させて実行するテクニックが有効です。
ネットワーク環境とファイル構成の見直しによる起動高速化
Accessを社内の複数メンバーで共有して利用する場合、ファイルの配置方法やリンクテーブルの設定が原因で、起動が著しく遅くなることがあります。ファイル共有環境における正しい構築パターンを理解しましょう。
1. フロントエンドとバックエンドの分割（分離）を徹底する
最もやってはいけない共有方法は、「サーバー上の1つのAccessファイルを、全員が直接ダブルクリックして開く」という運用です。これは起動が劇的に遅くなるだけでなく、データの競合によるファイル破損のリスクを極めて高めます。
Accessを共有利用する際の基本原則は、「フロントエンド（FE）」と「バックエンド（BE）」の分割です。
- バックエンド（BE）：テーブル（データ本体）のみを格納し、社内の共有サーバー（ファイルサーバーやNAS）に配置します。
- フロントエンド（FE）：画面（フォーム）、レポート、クエリ、VBAプログラムを格納し、利用する各ユーザーのローカルPC（Cドライブなど）にそれぞれコピーして配置します。FE内のテーブルは、BE内のテーブルへの「リンクテーブル」として構成します。
各ユーザーが自身のパソコン（ローカル）にあるFEを起動するため、画面のデザイン情報やプログラムの読み込みはローカル処理となり、起動が非常にスムーズになります。ネットワークを流れるのは「必要なデータ（レコード）」だけになるため、通信負荷も最小限に抑えられます。
2. リンクテーブルの常時接続（LDBキープ）テクニック
データベースを分割し、フロントエンド（ローカル）からバックエンド（サーバー）へリンクテーブルを貼っている場合、起動時にAccessが各テーブルの接続確認を行うため、リンクテーブルの数が多いほど起動が遅くなります。Accessは、リンク先のデータにアクセスするたびに、ロックファイル（.ldb または .laccdb）の作成と削除を繰り返す性質があるためです。
これを防ぐために、「起動中にバックエンドへの接続を1つだけ常に維持しておく（常時接続）」という高度なチューニング手法が有効です。
【常時接続の実装手順】：
- バックエンド（BE）に、レコードが1件だけ入った「tbl_KeepAlive」といったダミーのテーブルを作成します。
- フロントエンド（FE）の起動時に、このダミーテーブルを「読み取り専用（非表示）」で開く処理をVBAで実行します。
- システムを終了するまで、この接続（レコードセット）を保持したままにします。
以下は、標準モジュールに記述する常時接続用のVBAサンプルコードです。
' グローバル変数として保持し、接続が切れないようにする
Public dbKeepAlive As DAO.Database
Public rsKeepAlive As DAO.Recordset
Sub ConnectToBackend()
On Error Resume Next
' データベースオブジェクトの取得
Set dbKeepAlive = CurrentDb
' ダミーテーブルを読み取り専用（前方スクロールのみ）で開き、接続を維持する
Set rsKeepAlive = dbKeepAlive.OpenRecordset("tbl_KeepAlive", dbOpenForwardOnly, dbReadOnly)
End Sub
このマクロをAutoExecやスタートアップフォームの読み込み時に実行しておくことで、ロックファイルの再作成処理が発生しなくなり、起動時だけでなく、システム使用中の画面遷移やクエリ実行も劇的に高速化します。
起動速度を大幅に改善するための開発者向け設定とチューニング
プログラムやデータベースの「見えない設定」を最適化することで、システム全体のポテンシャルを引き出し、起動を高速化させることができます。以下の3つのポイントをチェックしてください。
1. サブデータシートの自動作成を「なし」にする
Accessの隠れた「遅延原因」の代表格が、テーブルの「サブデータシート」機能です。これは、テーブルを開いたときに、関連する子テーブルのデータを「＋」マークで展開して表示する機能です。
デフォルト（初期設定）では、Accessが自動的にテーブル間のリレーションシップを解析してこのサブデータシートを表示しようとします。そのため、テーブルを起動（リンク）するたびに裏側で膨大な解析処理が走り、動作が重くなります。実務でこの機能を使うことは稀ですので、すべてオフにすることをお勧めします。
【設定変更手順】：
- 対象のテーブルを「デザインビュー」で開きます。
- プロパティシートを表示し、「サブデータシート名」プロパティを「[自動]」から「[なし]」に変更します。
- ファイルを保存します。
※テーブル数が数十個以上ある場合は、すべてのテーブルを手動で変更するのは大変なため、以下のようなVBAコードを実行して一括変更するのが効率的です。
Sub DisableSubdatasheets()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim prop As DAO.Property
Const PROP_NAME As String = "SubdatasheetName"
Set db = CurrentDb
For Each tdf In db.TableDefs
' システムテーブルは除外
If Left(tdf.Name, 4) <> "MSys" And Left(tdf.Name, 1) <> "~" Then
On Error Resume Next
tdf.Properties(PROP_NAME) = "[None]"
If Err.Number = 3270 Then ' プロパティが存在しない場合は作成する
Set prop = tdf.CreateProperty(PROP_NAME, dbText, "[None]")
tdf.Properties.Append prop
End If
On Error GoTo 0
End If
Next tdf
MsgBox "すべてのテーブルのサブデータシートを[なし]に設定しました。", vbInformation
End Sub
2. VBA参照設定の整理とコンパイルの実行
VBAプログラムを含んでいるシステムの場合、内部コードの状態が原因で起動時に遅延（あるいはフリーズ）が生じることがあります。
-
不要な「参照設定」の解除：
VBAの編集画面（Alt + F11）のメニュー「ツール」→「参照設定」を開きます。使用していない外部ライブラリ（古いExcelオブジェクトや、他社製のアドインなど）にチェックが入ったままになっていると、起動時にそのプログラムを探しに行くため時間がかかります。特に「参照不可」と表示されている項目がある場合は、即座にチェックを外してください。 -
コンパイルの実行：
プログラムを変更したあと、コンパイル（コンピュータが読める形式に翻訳する処理）を行わずに保存すると、Accessを起動して最初にVBAが動く瞬間に自動コンパイルが走り、起動がもたつきます。VBA画面のメニュー「デバッグ」→「[プロジェクト名] のコンパイル」をクリックし、エラーがない状態で一度保存（上書き保存）を完了させておきましょう。
3. データベースの最適化と修復の実行
Accessは、データの追加・更新・削除を繰り返すと、ファイル内部に不要な一時領域（ゴミデータ）が残り、ファイルサイズが実態よりもどんどん肥大化していきます。これにより、起動時に不要なメモリ空間を確保しなければならなくなり、遅延の原因になります。
メニューの「ツール」→「データベースオブジェクト」→「データベースの最適化と修復」を実行することで、内部が整理され、ファイルサイズが圧縮されるとともに、インデックスが再構築されて起動およびクエリの処理速度が向上します。これは、月に1回などの定期メンテナンスとして実行することをお勧めします。
よくある質問（Q&A）
Q1. フロントエンド（FE）を各自のローカルPCに配布すると、システムの修正・アップデートがあった時に対応が大変になりませんか？
A1. 最新版のフロントエンド（FE）ファイルを共有サーバー上に1つ「マスター」として置いておき、起動時にローカルへ自動でコピーして起動する「ランチャー（バッチファイルやVBScript）」を作成してユーザーに配布する方法が一般的です。ユーザーはデスクトップに置いたバッチファイルのショートカットをダブルクリックするだけで、常に最新のシステムを高速なローカル環境で起動できるようになります。開発者自身が全員のPCを回って上書きする必要はありません。
Q2. Accessオプションにある「閉じるときに最適化」にチェックを入れて自動化するのは良い方法ですか？
A2. 一見便利に見えますが、複数人で共有している環境や、バックエンドファイルに対してこの設定を有効にすることは避けるべきです。閉じる処理が走っている最中にネットワークが切断されたり、別のユーザーがアクセスしようとしたりすると、ファイルが破損（お釈迦に）なるリスクが高まります。また、終了時に毎回待ち時間が発生するため利便性も損なわれます。最適化は、利用者が誰もいない時間帯（夜間など）に手動、または自動タスクで実行するのが安全です。
Q3. LANではなく、VPNやリモートワーク環境でAccessを開くと起動が極端に遅いのですが、どうすれば良いですか？
A3. 正直なところ、Accessのリンクテーブル（ファイル共有型）は、VPNやインターネット回線などの「広域ネットワーク（WAN）」経由で利用するようには設計されていません。わずかな回線遅延でも、Accessにとっては致命的な速度低下を招きます。この場合の解決策としては、(1) リモートデスクトップ（RDS/Citrix）環境を構築し、サーバー上でAccessを動かして画面だけを手元に転送する、(2) データベース（バックエンド）を「SQL Server」や「Azure SQL Database」に移行（アップサイジング）し、Accessは画面のみ（フロントエンド）として利用する、といったインフラ面の見直しが必要です。
Q4. 起動時に「セキュリティ警告：このコンテンツの一部が無効にされました」と表示されます。これも起動を遅くしますか？
A4. はい、影響します。この警告バーが表示されている間、AccessはマクロやVBAコードの実行を制限し、バックグラウンドでの初期化処理をストップさせて待機状態になります。ユーザーが「コンテンツの有効化」をクリックしてから初めて初期動作が走るため、ユーザーの体感上の起動速度は大幅に低下します。これを防ぐには、フロントエンド（FE）ファイルを配置しているローカルフォルダを、Accessの「信頼できる場所」としてセキュリティセンターに登録してください。これにより、警告を一切表示させずに安全かつ瞬時に起動できるようになります。
