AccScan
延命・注意

VPN・リモートワークでAccessが遅い・壊れる理由と対策

VPN経由で共有フォルダのAccessを直接開く運用は、Microsoftが「パフォーマンス低下と破損リスクのため避けること」と公式に推奨しない構成です。ファイル共有型の仕組みとWAN越し特有のリスク、リモートデスクトップ・SQL Serverバックエンド化などの代替手段を比較します。

まずは、自社のAccessが「解析できるか」を無料で確認できます。

約2分・ファイル送信不要・発注義務なし

結論:VPN経由の直接共有は非推奨。仕組み上、遅延・破損リスクが高まります

在宅勤務の普及以降、「自宅からVPNで会社の共有フォルダに接続し、Accessファイルを直接開く」という運用が増えました。ところがこの方法は、Microsoftの公式ドキュメントで「パフォーマンスが低下する可能性があり、データベースが破損するおそれがあるため避けること」と警告されています(出典は後述)。遅くなるだけでなく、データが壊れる可能性があります。

この記事では、なぜVPN越しのAccess直接共有が問題を起こしやすいのかを技術的に整理し、現実的な代替手段を比較します。「社内にいるときは問題ないのにリモートだと重い」と感じている方に、構造から理解してもらうことを目的に書いています。

なぜVPN越しだと遅くなるのか

Accessはファイル共有型のデータベースです。クエリを処理するデータベースサーバーが存在せず、共有フォルダ上の1つの.accdbファイルをクライアント側のAccess Database Engineが直接読み書きします。この仕組みでは、データの検索・集計・フォーム表示のたびに、必要なデータをネットワーク越しにPCへ転送してから処理します。

社内LAN(ギガビット有線)は一般にWANより低遅延・高帯域のため問題が顕在化しにくいですが、VPN経由のWAN接続では帯域や遅延の影響を受けやすく、大幅に遅くなる場合があります。Microsoftの公式ドキュメントも「WANでのAccess分割データベース共有はパフォーマンスが低下することがある」としており、Microsoftコミュニティには「社内で5〜8秒かかる処理が、単純計算では80秒程度になり得る」という説明もあります(コミュニティ参加者による試算であり、公式仕様ではありません)。

さらにAccessはSMBプロトコル(Windowsのファイル共有)を使ってファイルに直接アクセスします。クライアント側でデータを処理するため、クエリによっては多数のファイルI/Oとネットワーク通信が発生し、遅延の影響を受けやすい設計です。SQL Serverはサーバー側でクエリを処理して主に結果セットを返す構成のため、この点で仕組みが根本的に異なります。

破損リスクがLAN共有より高い理由

在宅勤務向けのVPNは一般的にインターネット回線を経由するため、社内LANと比べて瞬断・遅延変動が起きやすい環境です。

Microsoftの公式サポートドキュメントには「データの書き込み途中でネットワークサービスが失われると、Accessはデータベースファイルを破損済みとしてマークする」と明記されています。書き込みが中断されると破損済みとマークされ、修復やデータ損失が生じる可能性があります。社内LAN共有でも切断時の破損は起きますが、VPNではその頻度が上がりやすいと言えます。

当社の実務でも、テレワーク開始後にAccessの破損報告が増えたケースを複数経験しています。いずれも「社内では問題なかった」という共通点がありました。

なお、VPN切断でAccessが正常終了しなかった場合、次に共有ファイルを開こうとしても「使用中」と表示されることがあります。ロックファイルの仕組みや「使用中」エラーへの対処については.laccdbロックファイルと「使用中」エラーの解説を参照してください。

Microsoftが推奨する代替手段の比較

Microsoftの「Deploy an Access application」ページでは、WAN環境(VPN含む)でのAccess分割データベース共有を避けるよう明示し、代替としてRemote Desktop Services(RDS)を挙げています。実務上の選択肢を整理すると、次のようになります。

方法概要VPN越し共有との違い向くケース
リモートデスクトップ(RDS)社内サーバー上のAccessをRDPで操作。データは社内に留まるAccessのデータファイル自体をWAN越しに読み書きしない。主としてUI情報を転送するため、データ転送量を大幅に抑えられるAccessをそのまま使い続けたい場合に、VPN越し直接共有より破損リスクを抑えやすい遠隔運用
SQL Serverバックエンド化データ部分をSQL Serverへ移し、Accessはフロントエンドとして残すサーバー側でクエリを処理して結果セットを返す設計のため、SMBファイル共有より通信量と破損リスクを抑えやすい(ただし性能はクエリ設計とVPN品質に依存)リモートユーザーが多い、またはデータ量が増えてきた場合
クラウド業務システムへ移行kintone・Power Appsなどブラウザで動くシステムへ置き換えVPNなしでHTTPS経由で利用でき、Accessファイル共有特有の同時利用・破損問題を回避しやすいAccessを刷新したい場合・同時利用人数が多い場合
VPN越しに.accdbを直接共有(現状)社内共有フォルダのAccess ファイルをVPN経由で開く非推奨。パフォーマンス低下と破損リスクあり

リモートデスクトップ(RDS)は現実的な選択肢か

RDS(Remote Desktop Services)は、社内のサーバー上でAccessを動かし、手元のPCにはその操作画面を転送します。Microsoftの公式ドキュメントでは「クライアントとサーバー間のデータ転送が最小化され、UIを効率的にストリームする」と説明されています。Accessのデータファイル自体をWAN越しに読み書きしないため、VPN越しの直接共有より破損リスクを大幅に抑えられます。

ただしRDS環境の構築・維持にはWindowsサーバーとRDS CAL(クライアントアクセスライセンス)が必要で、設定やユーザー管理の手間もあります。既存のRDS環境がある会社でもライセンスや収容能力の余裕を確認してから移行してください。環境がない場合は導入コストを見積もったうえで判断することをおすすめします。

RDS環境でAccess分割データベースを動かす場合、各ユーザーのセッションごとにフロントエンドを別フォルダに置く設計が推奨されます(同一フロントエンドを複数セッションで共有するとテンポラリテーブルや抽出条件の扱いが競合することがあります)。

SQL Serverバックエンド化の位置づけ

AccessのフロントエンドはそのままにデータだけSQL Serverへ移す構成(アップサイジング)は、VPN越し運用の悩みを解消する有力な選択肢のひとつです。ファイル共有型のAccessは必要なデータページをSMB経由で読み書きするため多数のネットワーク往復が発生しやすいのに対し、SQL Serverはサーバー側でクエリを処理して結果セットを返す構成のため、VPN越しの通信量と破損リスクを抑えやすくなります。ただし、パフォーマンスはクエリ設計やVPN品質にも依存します。

構成の詳細はAccessの画面はそのまま、データだけSQL Serverへ移す構成で解説しています。また、複数人での遅さや破損の背景にあるファイル共有型の限界についてはAccessが複数人で使うと遅い・壊れる原因もあわせて参照してください。

ただし、SQL Serverバックエンド化はAccessフロントエンドのクエリやVBAの一部を書き換える作業が生じることがあります。既存のAccessが複雑な場合、移行コストと安定性向上のメリットを比較して判断してください。アップサイジングでも解決しきれない部分については、段階的な移行(ハイブリッド移行)も選択肢です。詳しくは全面移行しない選択肢|Accessと新システムのハイブリッド段階移行を参照してください。

現状の運用でリスクを減らすには

「すぐに移行できない」「RDS環境もない」という場合のために、VPN越し共有を続けるうえでのリスク軽減策をまとめます。ただしこれらは延命策であり、根本的な解決にはなりません。

  • DB分割の徹底:データファイル(バックエンド)と操作画面(フロントエンド)を分割し、フロントエンドは各PCのローカルに置く。これで転送されるのはデータだけになり、VPN越しの通信量を削減できます。
  • 有線接続の確保:電波状況が不安定なWi-Fiでは瞬断リスクが増えます。可能であれば有線LANへ切り替えることで、接続断による破損のリスクをある程度下げられます。
  • VPN切断前に必ずAccessを閉じる:VPN切断やPCスリープの前にAccessを手動で閉じる習慣を徹底します。書き込み中に切断が重なると破損する可能性があり、その結果サーバー側のセッションやロック状態が一定時間残ることがあります。
  • こまめなバックアップ:破損リスクが高い環境では、日次以上の頻度でバックアップを取り、世代を複数保持します。

パフォーマンス改善の全体像についてはAccessが遅いときの原因切り分けと総合対処も参考になります。現状のAccessがどの程度の構造リスクを抱えているか把握したい場合は、無料の解析可否チェックで確認できます。

よくある質問

Q. VPN速度が速ければAccess共有でも問題ありませんか。

速度だけが問題ではありません。在宅勤務向けのVPN接続は帯域が十分でも、インターネット経由では瞬断や遅延変動が起きやすい傾向があります。Accessは書き込み途中の切断に弱く、速いVPNでも破損リスクは残ります。MicrosoftもWANでのAccess分割データベース共有を避けるよう警告しています。

Q. リモートデスクトップとVPN直接共有、どちらが安全ですか。

Accessデータベースの破損リスクという観点では、RDS構成のほうが抑えやすいです。RDPでは操作画面を転送する形でAccessを使うため、Accessのデータファイル自体をWAN越しに読み書きしません。クライアント側のRDP切断が起きても通常はサーバー上のセッションが継続するため、VPN越しにファイルを直接開く構成より破損リスクを下げられます。MicrosoftもWAN環境ではこの構成を推奨しています(なお、RDPをインターネットへ直接公開する運用は別途セキュリティ対策が必要です)。

Q. DB分割すればVPN越しでも大丈夫ですか。

部分的には改善しますが、根本的な解決にはなりません。DB分割でフロントエンドをローカルに置くと転送データは減りますが、バックエンド(データファイル)はまだVPN越しの共有フォルダ上にあります。書き込み中の切断破損リスクは残ります。

Q. テレワーク開始後にAccessが壊れることが増えました。直せますか。

Accessの「最適化/修復」機能で軽微な破損は回復できる場合があります。ただし修復しても同じ運用を続ければ再び壊れます。繰り返す場合は運用方法の見直し(RDS移行またはバックエンドのSQL Server化)が必要です。破損修復の手順はAccessファイルが破損したら|修復の手順と根本対処を参照してください。

触れないAccessが「診断できるか」だけ、確かめませんか。

顧客データは送信不要。発注の義務もありません。

約2分・ファイル送信不要・発注義務なし/説明はオンライン・売り込みはしません