Accessリンクテーブルが遅いときのネットワーク・ODBC・分割DBチェック

リンクテーブルの動作が遅くなる3大原因とネットワークへの影響

Microsoft Accessのリンクテーブルが遅くなる背景には、ローカルで完結する通常の単一データベース（.accdb）とは異なる「データ送受信のオーバーヘッド」が存在します。原因を特定せずに闇雲に対策を行っても十分な改善効果は得られません。まずはボトルネックがどこにあるのかを理解することが最優先です。主な原因は以下の3つに大別されます。

1. ネットワーク遅延（LAN/WAN/VPN）とプロトコル（SMB）の影響

Access同士をファイル共有（NASやWindowsサーバー上の共有フォルダーなど）で接続している場合、Accessは「SMB（Server Message Block）」と呼ばれるファイルプロトコルを利用してデータをやり取りします。Accessエンジン（ACE/Jet）は本来、ローカルで動作するように設計されているため、クエリを実行するたびにネットワーク経由でインデックスやテーブルデータそのものを大量に読み込もうとします。これにより、ネットワークの帯域（回線速度）だけでなく「レイテンシ（遅延時間・Ping値）」が数ミリ秒増えるだけで、体感速度が劇的に低下します。

2. データベース分割における排他制御とロックファイルの頻繁な生成・削除

データベースを「フロントエンド（画面やクエリ担当）」と「バックエンド（データ格納担当）」に分割している場合、クライアントがバックエンドのリンクテーブルを開くたびに、サーバー側でロックファイル（.laccdb または .ldb）が生成され、閉じると削除されます。複数のユーザーが同時にアクセスを繰り返すと、このロックファイルの作成・更新・削除のプロセスが何度も発生し、共有フォルダ上のファイル共有ロック競合が引き起こされ、動作が驚くほど遅くなります。

3. ODBC接続におけるクエリのローカル評価とドライバーのオーバーヘッド

SQL ServerやOracle、MySQLなどのRDB（リレーショナルデータベース）とODBC経由でリンクテーブルを作成している場合、Accessがクエリを発行する際に「クエリのどの部分をSQL Serverに処理させ、どの部分をAccessローカルで処理するか」の切り分け（評価）を行います。これが不適切であると、数百万件のデータを一旦すべてAccessローカルにダウンロードしてからフィルターや結合を処理するという「ローカル評価」が発生し、ネットワーク帯域の枯渇と処理遅延を引き起こします。

修正で済むか、作り直すべきか迷ったら

現状を確認し、修正・保守・刷新のどれが現実的かを整理します。

Accessの動作改善・保守を相談する 困りごとを相談する

ネットワークとファイル共有設定の最適化

Access同士のデータベース分割（FE/BE）を行っており、共有サーバーにあるバックエンドテーブルへのリンクが遅い場合、まず確認すべきは「常時接続（生存接続 / Persistent Connection）」の設定です。これを実施するだけで、多くの場合で劇的な速度改善が見込めます。

常時接続（生存接続）を維持する具体的な手順

データベースが遅くなる最大の原因の一つである「ロックファイルの頻繁な生成・削除」を防ぐために、フロントエンドの起動中、バックエンドのリンクテーブルへの接続を常に1つ以上開きっぱなしにする（常時接続を維持する）VBAコードを実装します。

' 標準モジュールに記述するコード例
Public dbPersistent As DAO.Database
Public rsPersistent As DAO.Recordset

Public Sub KeepConnectionOpen()
    On Error GoTo Err_Handler
    ' バックエンドにある中身が空のダミーテーブル、または読み込み負荷の低いテーブルを開く
    Set dbPersistent = CurrentDb
    Set rsPersistent = dbPersistent.OpenRecordset("tbl_Dummy", dbOpenTable)
    Exit Sub

Err_Handler:
    ' エラー処理（必要に応じてログ出力など）
    Debug.Print "常時接続の確立に失敗しました: " & Err.Description
End Sub

Public Sub CloseConnection()
    ' データベース終了時に明示的に閉じる
    On Error Resume Next
    If Not rsPersistent Is Nothing Then rsPersistent.Close
    Set rsPersistent = Nothing
    Set dbPersistent = Nothing
End Sub

この KeepConnectionOpen を、フロントエンドのスタートアップフォーム（起動時に非表示で開くように設定したメニューフォームなど）の「開く時」イベントで実行します。これにより、利用者がシステムを使っている間は常にバックエンドとの接続が維持され、ロックファイルの作成・削除が1回だけで済むようになり、データ検索や登録のレスポンスが高速化します。

UNCパスによるリンクの統一

リンクテーブルを設定する際、接続先パスを「Z:\Database\Backend.accdb」のようにネットワークドライブのレジストリ文字（ドライブレター）で指定すると、Windowsがドライブレターの名前解決を行うたびにオーバーヘッドが生じることがあります。必ず「\\ServerName\ShareName\Database\Backend.accdb」のような「UNCパス」を使用して直接指定するようにリンクを再構築してください。これにより、クライアントPCごとに異なるネットワークドライブの割り当て状況に依存せず、安定した接続速度が確保できます。

ODBCリンクテーブルを高速化する設定

SQL Serverなどの外部RDBとODBC（Open Database Connectivity）を介してリンクしている場合、Accessはただのフロントエンド（表示機）として機能します。しかし、Accessが裏側で非効率なクエリを生成してしまうと、サーバー側がどれだけハイスペックでも動作は遅くなります。以下の設定で見直しを行いましょう。

1. SQLパススルークエリの活用

通常のリンクテーブルに対するクエリは、AccessがSQLを解析して送信しますが、これだと不要なデータまでローカルに読み込む原因になります。「パススルークエリ」を使用すれば、記述したSQLがそのまま直接SQL Serverなどのサーバー側で実行（パススルー）され、処理結果のみがAccessに返されます。

• 設定手順: クエリデザインを開き、プロパティシートで「パススルー」を「はい」に設定。SQL Server用の接続文字列を設定し、クエリを実行します。
• 効果: 大量のレコードに対する集計処理（SUM、GROUP BYなど）や、ストアドプロシージャの実行を数分から数秒レベルに高速化できます。

2. ODBCドライバーの選定

長年使用しているシステムでは、古い「SQL Server」や「MSDASQL」といった古いドライバーが選択されている場合があります。最新の「ODBC Driver for SQL Server」（例：ODBC Driver 17 または 18）に変更することで、接続プーリングの効率化やプロトコルの最適化が行われ、描画速度やデータ送受信速度が向上します。

3. テーブルの主キー（インデックス）の有無をチェック

ODBCリンクテーブルを作成する際、Access側で「一意の識別子（主キー）」を指定しないと、リンクテーブルは「読み取り専用」になり、さらに特定のレコードを更新・検索する際にインデックスが効かず、テーブル全体をスキャン（フルスキャン）してしまうため非常に動作が遅くなります。リンク作成時のダイアログで、必ず主キーとなるフィールドを選択するようにしてください。すでにリンクされている場合は、一度リンクを削除してから再作成してインデックスをマッピングし直します。

データベース分割（FE/BE）におけるパフォーマンス改善手順

Accessを社内で複数ユーザーで共有する場合、フロントエンド（FE）とバックエンド（BE）への分離は必須の設計です。しかし、運用の方法を誤ると速度低下だけでなくデータベースの破損原因にもなります。

1. フロントエンド（FE）は各クライアントPCのローカルに必ず配置する

最もやってはいけない運用の代表格が、「共有サーバー上にある1つのフロントエンド（FE）ファイルを、複数ユーザーが直接ダブルクリックして開く」という手法です。これは動作を極端に遅くするだけでなく、データベースが瞬時に破損する原因になります。FEは必ず、各ユーザーの「Cドライブ（ローカル）」にコピー（配布）して使用してください。バックエンド（BE）ファイルのみを共有サーバー（NAS等）に配置します。

2. フロントエンド自動配布用バッチファイルの作成

「FEをローカルに配布すると、システムの修正があったときに全員のPCを書き換えるのが面倒」という問題は、以下のような単純なバッチファイル（.bat）を作成して、ユーザーにはこのバッチファイルを起動してもらう仕様にすることで解決できます。

@echo off
REM 共有サーバー上の最新FEファイルをローカルにコピーして起動するバッチファイル
set SERVER_PATH="\\ServerName\ShareName\System\App_FE.accdb"
set LOCAL_PATH="C:\LocalSystem\"
set FILE_NAME="App_FE.accdb"

if not exist %LOCAL_PATH% (
    mkdir %LOCAL_PATH%
)

REM サーバーのファイルが新しい場合のみコピーする
xcopy %SERVER_PATH% %LOCAL_PATH% /Y /D

REM ローカルのFEファイルを起動
start "" %LOCAL_PATH%%FILE_NAME%

このバッチファイルへのショートカットを各自のデスクトップに置いておけば、管理者が共有サーバー上のFEを更新するだけで、次回起動時に自動で最新版がローカルにダウンロードされ、快適かつ安全に動作します。

3. 「サブデータシート」プロパティを[なし]にする

意外な落とし穴として、バックエンドの各テーブルの「サブデータシート」プロパティがあります。これがデフォルトの「自動」になっていると、テーブルやフォームを開くたびに、リレーションシップが結ばれている他の子テーブルの内容までAccessが親切に自動読み込みしようとするため、莫大な遅延が発生します。
バックエンドの全テーブル（特にデータ件数が多いメインテーブル）のデザインビューを開き、プロパティシートの「サブデータシート」を「[なし] (None)」に変更してください。これだけで劇的なロード時間の短縮が期待できます。

修正で済むか、作り直すべきか迷ったら

現状を確認し、修正・保守・刷新のどれが現実的かを整理します。

Accessの動作改善・保守を相談する 困りごとを相談する

リンクテーブルが遅い問題に関するよくある質問（FAQ）

Public 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 (tdf.Attributes And dbSystemObject) = 0 Then
            On Error Resume Next
            tdf.Properties(PROP_NAME).Value = "[None]"
            If Err.Number = 3270 Then ' プロパティが存在しない場合
                On Error GoTo 0
                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