概要
| この記事の結論 Accessは複数人で同時利用できます。基本は、共有するテーブルと各利用者が操作する画面を分け、各PCにフロントエンドを置く構成です。仕様上の同時ユーザー数の上限は255ですが、快適に使える人数を保証する数字ではありません。同時編集の多さ、データ量、クエリ、ネットワークを確認し、実際の利用条件で判断します。 |
この記事でわかること
- 仕様上限と実用人数を区別
- 画面は各PCへ配布
- 編集競合を運用で扱う
- 負荷と回線条件で構成を選ぶ
この記事の主な内容
- Accessで同時利用できる人数の考え方
- 複数人利用の基本構成
- 同じデータを編集した場合の動作
- 共有を始める前に準備すること
- 遅いときや壊れるときの切り分け
- SQL Serverや別構成を検討する目安
- よくある質問
想定読了時間:約7分~9分
1 Accessで同時利用できる人数の考え方
Accessは複数人の同時利用に対応しています。ただし「使える上限」と「業務上快適な人数」は別です。Microsoftの仕様表では同時ユーザー数の上限を255としていますが、その人数で任意の業務処理が快適に動くという意味ではありません。
少人数でも、全員が大きな集計や大量更新を同時に動かせば待ち時間が増えます。反対に、参照中心で絞り込みが適切なら負荷を抑えられます。「何人までなら必ず安全」という固定値を当てはめず、同時操作の内容で判断しましょう。
- 同時接続している人数と、そのうち更新している人数。
- 1回の検索で読む件数と、更新する件数。
- ピーク時間帯に重なる帳票・取り込み・集計処理。
- データ元までの通信品質と切断の有無。
2 複数人利用の基本構成
複数人利用では、各PCに画面用のフロントエンドを置き、共通のバックエンドへリンクする構成が基本です。フォームやクエリを共有フォルダーの同じフロントエンドから全員で開く方法とは分けて考えます。

| 置く場所 | 主な内容 | 運用の要点 |
|---|---|---|
| 各利用者のPC | フォーム・クエリ・帳票など | 各自のコピーから起動 |
| 安定した共有先 | 実データのテーブル | 権限とバックアップを管理 |
| 開発・保全用の場所 | 元ACCDBと版管理記録 | 利用者配布用と区別 |
共有先としてOneDriveやSharePointのドキュメントライブラリ上のAccessファイルを複数人で直接開く運用は避けます。ファイル同期は、DBの同時更新を調整する機能の代わりにはなりません。
参考:Microsoft Accessデータベースを分割する
参考: Microsoft Accessデスクトップデータベースを共有する方法
3 同じデータを編集した場合の動作
同じレコードを2人が編集すると、設定や編集のタイミングによって保存時の競合やロック待ちが発生します。編集を始めてから保存するまでが長い画面では、別の人の処理と重なりやすくなります。
保存時の競合を前提にした画面と運用
ロックを短くする方式では、保存時に他の人の変更を検出したら再表示して確認する運用が必要です。反対に編集中のレコードをロックする設定では、他の人が待つ場面が増えます。設定名だけで選ばず、実際の入力手順で検証します。
- 競合メッセージを無視して上書きしない。
- 入力内容と他の利用者の更新を確認してから保存し直す。
- 編集画面を開いたまま離席する運用を減らす。
- 一括更新や締め処理を通常入力と同時に実行してよいか決める。
連番をMax+1などで安易に作る処理は、複数人が同じ値を計算する競合を起こすことがあります。主キーや一意性の制約も含めて、同時利用を前提とした登録処理を設計してください。
4 共有を始める前に準備すること
利用開始前には、各端末で共有先へ到達できるだけでなく、登録・修正・削除に必要な権限があるか確認します。Accessの共有ではロック情報ファイルを作成・削除できるフォルダー権限も関係します。ファイル本体だけの権限で判断しないようにしましょう。
1. 全利用者のAccessの製品・Build・bit数と接続方法を記録します。
2. 共有モードで開く設定と、各PCのフロントエンド配置を確認します。
3. 検証用データを用意し、2台以上で参照・登録・同一レコードの編集を試します。
4. ピーク時の業務処理を想定して時間を測ります。
5. 利用停止と復旧の手順、連絡先、バックアップの取得方法を決めます。
ここで確認した環境と結果は、運用を変えたときの比較基準になります。端末追加やAccess更新後も、同じ確認項目で動作を点検すると原因を追いやすくなります。
複数テーブルや複数端末への影響が分からない場合は、変更目的と現状の構成を整理してお気軽にご相談ください。
5 遅いときや壊れるときの切り分け
特定の時間帯に遅い場合は、全員の入力に加えて帳票や一括処理が重なっていないか調べます。常に同じ検索だけが遅いなら、そのクエリの条件や索引を先に確認します。症状に応じて調査順を変えることが大切です。
| 症状 | 確認すること |
|---|---|
| 起動だけ遅い | フロントエンドの場所と起動時処理 |
| 検索だけ遅い | 抽出範囲、結合、インデックス |
| 保存できない | 競合、権限、切断 |
| 破損が繰り返す | ネットワーク、強制終了、共有運用 |
利用中のロック情報ファイルを手動で削除して解決しようとしてはいけません。まず誰が開いているかを確認します。破損が疑われる場合も、原本を保全し、利用停止と復旧を計画してから対処してください。

6 SQL Serverや別構成を検討する目安
同時書き込みが増えた、停止の影響が大きくなった、権限や監査の要件が厳しくなった場合は、サーバー型DBへの移行を検討します。画面をAccessに残し、データだけSQL Serverなどへ移す方法もあります。
遠隔地の利用が増えた場合は、通信条件を含めて構成を見直します。VPNを通せばファイル共有が常に安定するわけではありません。アプリをデータに近い場所で動かす構成やWeb化も、費用・運用体制・利用端末と合わせて比較します。
まず現在の負荷と障害を測り、改善したい目標を決めます。Accessを使い続けるかどうかより、入力待ち時間、復旧時間、保守の負担をどこまで抑えたいかを具体化する方が、必要な投資を判断しやすくなります。
よくある質問(FAQ)
仕様上限は255ユーザーですが、実用人数は処理内容と環境で変わります。上限をそのまま運用目標にしません。
複数人利用では分割し、各PCのフロントエンドから共通バックエンドへ接続する構成を基本に検討します。
競合やロックが発生する可能性があります。保存時の確認や再表示などを含めた設計と運用が必要です。
想定する同時操作、登録・更新、集計、競合時の動作を実際の端末と回線で試し、結果と待ち時間を記録します。
複数人利用の安定化と構成診断が必要な場合
この記事の手順を作業用コピーで確認しても解決しない場合や、業務への影響が大きく自社だけで判断しにくい場合は、お気軽にご相談ください。Accessの現在の構成、発生している症状、変更したい内容をもとに、調査・改修の範囲を整理します。
ご相談時は、Accessの製品名・Build・bit数、エラーの内容、対象ファイルの構成、直前に変えた設定を分かる範囲でお知らせください。機密データやパスワードは公開フォーム等へそのまま記載しないでください。