Accessの同時接続255の実際｜快適に使える人数の現実的な上限

結論：仕様上の255は別として、快適に使えるのはおおむね5〜10人が目安です

Microsoft Accessは、1つのデータベースを同時に使えるユーザー数を255と仕様で定めています（Access仕様 - Microsoft）。ただし255という数字はあくまで技術上の上限であり、実務で問題なく使えるかどうかとは話が別です。当社がAccess解析・移行支援で見てきた現場の経験からすると、快適に使えるのはおおむね5〜10人程度で、同時利用が10人を超えると環境や業務内容によって遅延が目立ち始めます。この記事では255という仕様の中身、実用上限を左右する要因、人数が増えたときの対策を整理します。

なお「複数人で使うと遅くなる・壊れる」という動作上の問題については、Accessが複数人で使うと遅い・壊れる原因で詳しく解説しています。本記事は「そもそも何人まで使えるか」に焦点を絞ります。

255という数字の正確な意味

Microsoftの公式仕様ページには「同時接続ユーザー数：255」と記載されています。Microsoftの技術資料によると、Accessのデータベースエンジン（ACE）が対応できる同時ユーザー数が255であり、その結果ロックファイル（.accdb形式なら.laccdb、旧.mdb形式なら.ldb）の最大サイズが16KB（255ユーザー×64バイト/エントリー）に収まる設計になっています。

ロックファイルはデータベースを共有で開いた各ユーザーのコンピューター名とセキュリティ名を記録し、バイト範囲ロックを使ってレコードやページのロック状態を管理する仕組みです。.laccdbロックファイルの仕組みで詳しく解説していますが、仕様上の同時ユーザー数の上限は255です。

実用上限はなぜ仕様値より低いのか

255という上限に到達する前に、実際のユーザーは別の問題に直面します。当社の実務経験では、以下の4つの要因が重なることで、仕様の255よりずっと少ない人数で限界に達するケースがほとんどです。

ネットワーク負荷：Accessはファイル共有型の仕組みで動くため、クエリの処理に必要なデータをいったんPCに引き込んでから演算します。人数が増えると社内ネットワークを流れるデータ量が増加し、速度が落ちます。100Mbps程度のLAN環境で10人前後が同時に集計クエリを走らせると、明らかな遅延が出始める現場は珍しくありません。

書き込み競合とロック待ち：Accessの既定設定（楽観的ロック）では、複数人が同じレコードを同時に編集できますが、後から保存しようとした人に書き込み競合の警告が出ます。レコードを排他ロックする設定にしていると、一方が編集中は他の人が待機させられます。どちらの設定でも人数が増えるほど競合が起きやすくなり、体感速度が下がります。更新頻度の高い業務ほど影響が大きくなります。

ファイルサイズの膨張：Accessは1ファイル2GBが上限です（Accessの2GBの壁参照）。人数が多いほどデータの蓄積が速く、サイズ上限への接近も早まります。データ量の増加やインデックス設計の粗さが重なると、クエリが読み取るページ数と通信量が増えてネットワーク越しの処理が遅くなる場合があります。

クエリ設計の影響：単純な一覧表示でも、設計が悪いと全レコードをいったん取り込んでから絞り込む動きをするクエリがあります。利用者が少なければ気にならなくても、10人が同時に同じクエリを走らせるとネットワーク負荷が跳ね上がります。

上記の人数はあくまで当社の実務経験に基づく目安です。ネットワーク速度・サーバースペック・業務内容（参照中心か更新中心か）によって大きく変わります。

人数が増えたときに試せる応急策

構造を変えずに対応できる手段もあります。ただしどれも延命策であり、根本的な解決にはなりません。

DB分割（フロントエンド/バックエンド）：データを格納するバックエンドファイルと、画面（フォーム・レポート）を収めたフロントエンドファイルに分け、フロントエンドを各PCにコピーして使う方式です。ネットワーク越しに転送するデータ量が減るため、5〜10人程度の構成では効果があります。ただし同時書き込み競合の仕組みそのものは変わりません。

有線LANの使用：当社の現場経験では、無線LANで接続している環境は通信が安定しにくく、書き込み中の切断がファイル破損につながるケースがありました。有線化で破損リスクは下げられますが、人数が多い状態での遅延解消には限界があります。

クエリの最適化：不要な全件取得を減らし、インデックスを適切に張るだけで、同じ人数でも動作が大幅に改善することがあります。改善の余地が大きい場合はAccessが遅いときの対処も参考にしてください。

20人超の場合：SQL Serverバックエンド化が現実的な選択肢

同時利用者が20人を超えてAccessでの安定運用が難しくなった場合、データ部分だけをSQL Serverに移す「バックエンド化」が有効な選択肢になります。フォームやレポートはAccessのまま使い続けられるため、現場への影響を最小限に抑えながら、Accessファイル共有固有の同時利用の制約を緩和できます。

SQL Serverはサーバー側でクエリ処理を行えるため、最適化されたクエリではAccessが自分でデータを引き込んで処理するよりもネットワーク転送量を大幅に減らせます（ただしAccess固有の関数を使ったクエリはクライアント側で処理される場合があります）。SQL Server Expressは無料版ですが10GBの容量制限があり（SQL Server Expressの制限参照）、利用者規模や業務量によって有償版が必要になる場合もあります。

バックエンド化の設計思想と手順についてはAccessからSQL Serverへのバックエンド移行で詳しく解説しています。段階移行の第一歩として取り組みやすい方法です。

現在の利用人数・同時接続状況・クエリの設計がどのような状態かを把握したい場合、無料の解析可否チェックで確認できます。データを送る前に、そのAccessが解析できる状態かどうかを判定します。

よくある質問

Q. 255人まで使えると聞いたので大丈夫と思っていたが、実際は何人が限界ですか。

255は仕様上の技術的な上限であり、快適に使える人数の保証ではありません。当社の実務経験では、ネットワークや業務内容にもよりますが、同時接続が10〜20人を超えるとロック待ちや遅延が顕著になるケースが多いです。使っているAccessが何人規模を想定しているかを確認し、不安なら現状の解析をお勧めします。

Q. フロントエンドを各自PCにコピーすれば255人まで使えますか。

フロントエンド/バックエンド分割をしても、バックエンドのデータベースを同時に使えるユーザー数は255の制約を受けます（Microsoftの技術者コミュニティでも同じ見解が示されています）。また255に達する前に、ネットワーク負荷や書き込み競合で実用限界に達するのが現実です。

Q. 今は10人で使っていて問題ないが、20人に増える予定です。どうすればよいですか。

20人への増員は要注意のラインです。まずDB分割ができていない場合は分割し、クエリのインデックス設計を見直すことで延命できる場合があります。それでも不安であれば、早めにSQL Serverバックエンド化を検討するのが現実的です。人数が増えてから慌てて対応するより、増員前に準備できると工数が少なく済みます。

Q. Accessの「同時接続」はどこで確認できますか。

Accessには同時接続数をリアルタイムで表示する標準機能はありません。ロックファイル（.laccdb/.ldb）にはコンピューター名とセキュリティ名のエントリーが記録されていますが、ユーザーがデータベースを閉じてもエントリーは自動的に削除されないため、ロックファイルだけでは現在の接続者を正確に把握できません（Microsoftの公式資料にも同様の注意があります）。現在の接続ユーザーを調べるには、VBAでJet UserRosterを呼び出す方法があります。