共有フォルダの1つのaccdbを複数人で開く運用が危険な理由

結論：1つのaccdbを複数人が直接開く運用は破損リスクがある

先に結論を書きます。ファイルサーバーの共有フォルダに1つのaccdbを置き、複数のPCから直接開いて使う運用には、データ破損のリスクがあります。Microsoftの公式ドキュメントは「ネットワーク経由で同時に複数のユーザーがデータベースファイルを直接共有すると、破損するリスクが小さくあります。長いテキストフィールドを頻繁に編集するユーザーがいる場合はリスクが大きくなり、時間とともにリスクは増えていきます」と明記しています。小さなリスクではあっても、条件によって積み上がる構造的な問題があるのが共有フォルダ運用の実態です。

この運用がなぜ危ないのか。大きく3つの理由があります。ネットワーク切断が書き込みの途中で発生すると破損につながること、Accessのロックファイルが前提とする権限要件がファイルサーバー環境では満たされないことがあること、そしてテーブルだけでなくフォームやレポートを含む全オブジェクトがネットワーク越しに転送されるため動作が重くなること、です。以下で順に説明します。

ネットワーク切断で書き込みが中断すると破損する

Accessのaccdb形式はACE（Access Database Engine）を使うファイルサーバー型のデータベースです。SQLサーバー型と異なり、クライアントPCが直接ファイルを読み書きします。書き込みの途中でネットワーク接続が切断された場合、Accessはデータベースを破損済みとしてマークします。

Microsoftの「最適化と修復」ドキュメントでは、「ユーザーがデータの変更を始め、その変更がネットワーク接続の切断などにより中断された場合、Accessはデータベースファイルを破損済みとしてマークする」と説明しています。

マップドドライブ（Zドライブなど）でネットワーク共有を参照している場合、特定の条件下で切断が起きやすくなります。Microsoftのサポートドキュメントによれば、グループポリシーの設定（Replace設定）によりネットワークドライブが定期的に切断・再接続される場合や、アイドル状態が続いてドライブが自動切断される場合に「ネットワークアクセスが中断されました」エラーが発生し得ます。UNCパス（\\ServerName\FolderName\FileName.accdb 形式）を使うと、こうしたマップドドライブ固有の切断要因を回避できます。

なお、Windows 10 バージョン1803以降の環境では、SMB（サーバーメッセージブロック）のリース動作とAccessデータベースエンジンの組み合わせが問題を引き起こすケースも報告されています。Microsoftのサポートページに対処法が掲載されており、ファイルサーバー側でSMBリースを無効化するレジストリ変更を案内していますが、これはあくまで症状を緩和するワークアラウンドです。

ロックファイルの仕組みと、権限が足りないときに何が起きるか

Accessは複数人での同時利用を管理するためにロックファイル（拡張子.laccdb）を使います。accdbを共有モードで開くと、同じフォルダに同名の.laccdbファイルが自動で作られます。このファイルには誰がどのレコードを使っているかが記録され、最後の1人が閉じると自動で削除されます（Microsoftのロックファイル解説）。

ロックファイルが正常に機能するには、共有利用者全員がaccdbファイルの置かれたフォルダに対して「読み取り・書き込み・作成・削除」の権限を持つ必要があります。同じMicrosoftドキュメントには「削除権限がない場合や、データベースが破損済みとしてマークされている場合はロックファイルが残り続ける」とも書かれています。

権限が不足していると、ロックファイルを作成できないなど権限に関連するエラーが発生することがあります。排他モード（Open Exclusive）で開いた場合はロックファイルは作られませんが、その間は他のユーザーが一切アクセスできなくなります。

Microsoftの同ドキュメントでは同時利用数についても触れており、技術上は最大255ユーザーまで対応としながら、「頻繁にデータを追加・更新するユーザーがいるAccessファイルサーバー構成では、25〜50ユーザー以下にとどめることが推奨される」と記載しています。10人以下の環境でも、同じレコードを複数人が同時に編集するような運用では競合が起き得ます。

全オブジェクトがネットワークを流れる構造的な問題

分割されていない（単一ファイルの）accdbをファイルサーバーに置いた場合、フォームやレポート、クエリ、VBAコードも含めたすべてのオブジェクトがネットワーク越しに転送されます。Microsoftの共有方法ドキュメントでは「すべてのデータベースオブジェクトがネットワーク越しに送られるため、パフォーマンスが低下する可能性がある」と明記されています。

未分割構成では、データだけでなく、フォームやレポートなどのオブジェクトも必要に応じてネットワーク経由で読み込まれます。ファイルが大きくなるほど、またユーザーが増えるほど、ネットワーク負荷は積み上がります。

さらに同ドキュメントは、この構成ではセキュリティ面でも問題があることを指摘しています。「各ユーザーがデータベースファイルの完全なコピーを持つことになるため、不正アクセスのリスクが高まる」という記載があります。

当面の改善策：DB分割で破損リスクを下げる

すぐに移行できない場合、まず取り組むべきなのはDB分割（フロントエンド/バックエンド分割）です。テーブルだけを持つバックエンドaccdbをファイルサーバーに置き、フォームやレポートを持つフロントエンドaccdbは各ユーザーのPC（ローカル）で動かす構成です。

分割後はネットワーク越しに流れるのが主にテーブルデータになり、動作が軽くなります。フロントエンドが破損しても影響は当該ユーザーに限定されやすく、他のユーザーはそのまま作業を続けられます。バックエンドが破損した場合は全ユーザーに影響が出るため、バックエンドの定期バックアップは必須です。分割の手順はAccessのDB分割（フロントエンド/バックエンド）で延命する方法を参照してください。

DB分割でリスクを下げたうえで、フォルダのアクセス権限を正しく設定し、接続方式をUNCパスに変えておくことが次のステップです。マップドドライブでのアクセスは、前述のグループポリシーによる切断問題を起こしやすいため、\\サーバー名\共有名\ファイル名.accdb 形式のUNCパスを使うほうが安定します。

定期的なバックアップも欠かせません。ネットワーク共有環境では夜間の自動バックアップを組んでおくことを当社では強く推奨しています。バックアップ設計の詳細は延命中のAccessを守るバックアップ設計を参照してください。

根本解決：バックエンドをSQL Serverに移す

DB分割は延命の手段であり、ファイル共有型の限界を根本から解消するものではありません。共有accdbをSMB越しに直接読み書きすることに固有の破損リスクを大幅に下げたい、同時利用者が増えてきた、という場合は、バックエンドをSQL Serverへ移行することが有効な選択肢になります。

SQL Serverはクライアント-サーバー型のデータベースで、Accessとはデータの扱い方が根本的に異なります。クライアントPCはファイルを直接読み書きするのではなく、SQL Serverに対してクエリを送る設計が基本です。サーバー側で適切に処理できるクエリでは転送量の削減と同時利用時の安定性向上が期待できます。共有accdbをSMB越しに直接読み書きすることに固有の破損リスクは大幅に低減されます。既存のフォームやレポートはAccessのまま活用できるケースが多く、操作画面を変えずに段階移行の第一歩として取り組めます。

費用をかけずに試したい場合はSQL Server Expressが選択肢です。容量・CPU・メモリなどの制限はありますが、無料で使えます。詳細な仕様と移行手順は無料のSQL Server ExpressにAccessのデータを移す手順と制限をご覧ください。バックエンドをSQL Serverへ移すアーキテクチャの全体像はAccessの画面はそのまま、データだけSQL Serverへ移す構成で解説しています。

現在の共有フォルダ運用が不安で、まず自社の状況を整理したい場合は、無料の解析可否チェックでファイルの状態を確認することから始められます（ファイルの送信は不要です）。

よくある質問

Q. 「使用中のため開けません」というエラーが出ます。これはどういう状態ですか。

他のユーザーが排他モード（Open Exclusive）で開いている可能性があり、その場合は閉じてもらうしかありません。なお公式には、ロックファイルが残り続けるのは「利用者に削除権限がない場合」か「データベースが破損とマークされている場合」の2つとされています。全ユーザーがaccdbを閉じているのに.laccdbが残るときは、この2点を確認してください。ロックファイル自体が壊れても本体のaccdbは通常どおり動作するとされていますが、手動で削除する場合は必ず全員が閉じた状態で、事前にバックアップを取ってから行ってください。

Q. 2人程度の少人数なら共有フォルダ運用でも大丈夫ですか。

人数が少なければ競合は減りますが、破損リスクがゼロになるわけではありません。Microsoftは人数によらず「ネットワーク共有で複数人が同時に直接アクセスすると小さなリスクがある」としており、頻繁にデータを編集する運用ではリスクが高まると明記しています。2人でも毎日データ入力するなら、DB分割とバックアップを組み合わせることを当社では推奨しています。

Q. VPNで会社のファイルサーバーに繋いでいます。リスクはさらに高いですか。

インターネット経由のリモートアクセスなど、遅延や瞬断が大きいVPN/WAN環境では、社内LANよりAccess共有ファイルの破損リスクが高まる場合があります。MicrosoftのAccessアプリケーション展開ガイドでも、WAN経由でのAccessファイル共有はパフォーマンス低下や問題のリスクがあることが述べられています。Accessが複数人で使うと遅い・壊れる原因と、同時利用に強い移行先でも触れていますが、回線品質によっては社内LAN以上のリスクが出ます。バックエンドをSQL Serverへ移すか、クラウド型のWebシステムへ移行することが、この環境への現実的な対策です。

Q. 破損が繰り返し起きています。修復しても意味がありますか。

「最適化と修復」で一時的に動くようになっても、根本的な原因（ネットワーク切断による書き込み中断・多人数による直接共有・SMBリース問題など）が残っていれば破損は再発します。繰り返す破損は構造的な問題のサインです。Accessファイルが破損したらで修復手順と根本対処を解説しているので、あわせてご覧ください。