Access マルチユーザー運用の限界：10人の壁・破損リスク・移行先選定のロードマップ

「Access のマルチユーザー運用は 10 人が限界」というのは、現場で語られる経験則。実際には設計次第で 5〜15 人の幅があるが、それを超えると性能・破損リスクが急速に悪化する。本稿は、Access マルチユーザー運用の実態と、限界を超えた組織が取るべき移行先選定のロードマップを整理する。

1. Access マルチユーザー運用の限界要因

• 同時オープン制約：理論上は 255 ユーザまで同時アクセス可能だが、実用上は 5〜10 人。それ以上は性能が著しく劣化する。
• ファイルロック競合：複数ユーザが同じレコードを同時に更新したとき、ロック制御の不整合が破損の原因になる。
• ネットワーク経由のレスポンス：Access は本来デスクトップ DB として設計されており、ネットワーク経由のアクセスは想定外。共有フォルダ上の Access ファイルへのアクセスは、レコード操作のたびに大量のネットワーク通信が発生する。
• ファイル破損リスク：マルチユーザー時の破損確率は、ユーザ数の二乗に比例する経験則。10 人を超えると月 1 回以上の破損が発生する。
• 復旧の難しさ：マルチユーザー運用中にファイルが破損すると、誰のデータが残っているか追跡困難。

2. 「10 人の壁」の実態

「Access は 10 人が限界」という経験則は、次の条件で発生する。

• 共有フォルダ上の単一 Access ファイルに全ユーザがアクセス
• VBA・複雑なクエリ・大量レコードの同時操作
• ネットワーク経由（無線 LAN、リモート VPN を含む）

逆に、以下の条件なら 10 人以上でも運用可能。

• 分割 DB アーキテクチャ（フロント・バックエンド分離）
• SQL Server / Azure SQL バックエンド化
• 有線 LAN・高速ファイルサーバ
• シンプルなクエリ・少量レコード

3. ユーザ数別の推奨構成

4. 限界超過の典型的な症状

• 動作の極端な遅延：レコード保存に 10 秒以上かかる、フォーム表示に 5 秒以上かかる。
• 同時保存時のエラー：「他のユーザが更新中です」エラーが頻発、保存できない。
• 頻繁な破損：月 1 回以上の破損、修復不能な状態。
• 業務効率の低下：システム操作で業務が止まる時間が増加、現場の不満。
• 復旧作業の常態化：情シスがバックアップ復元に時間を取られる。

5. 限界超過時の対応進め方

1. 緊急対応（即時〜2 週間）：日次バックアップの強化、分割 DB アーキテクチャへの移行、ファイルサーバの性能改善。
2. 暫定対応（1〜3 ヶ月）：データバックエンドの SQL Server / Azure SQL 化。Access フロントは継続使用。
3. 本格対応（3〜12 ヶ月）：kintone・Power Apps への移行プロジェクト立ち上げ。要件定義・移行計画。
4. 本番運用（12〜18 ヶ月）：新システムへの完全移行・Access 廃止。

6. 移行先選定の判断軸（マルチユーザー運用 12 人超）

マルチユーザー運用の限界が来たら、業務領域に応じて最適な移行先を選定する。1 つに絞る必要はなく、業務領域別に複数ツールを使い分けることも現実的。

「10人の壁」の正体：なぜ Access はマルチユーザーで破損するのか

「Access が10人くらいで使うと不安定になる」というのは、現場でよく聞く話です。これは Access の「ファイルベースDB」という基本設計上の制約に由来する、必然の現象です。

ファイルベースDBの根本的制約

Access はクライアント・サーバー型のRDB（SQL Server や PostgreSQL のような）ではなく、共有フォルダ上の.accdbファイルに各クライアントが直接書き込む方式です。これにより以下の問題が発生します。

• ロックファイル（.laccdb）の競合：Access はロックファイルでアクセス権を管理しますが、SMB（Windows ファイル共有）プロトコル上では複数クライアントからの同時更新時にロック競合が頻発
• ネットワーク経由のページ単位読み書き：Accessはデータベースを4KBページ単位で扱い、各クライアントが必要なページを共有フォルダから読み込み・書き戻しする。ネットワーク不安定時に書き込みが失敗するとファイル破損の原因に
• 差分マージのロジックがない：複数クライアントが同じレコードを編集した時の競合解決ロジックがなく、後勝ち or エラーになる

「10人」が破綻点になる根拠

「なぜ10人なのか」には明確な技術的閾値があるわけではなく、複合的な要因の結果です：

1. 同時書き込みの確率：10人が同時に書き込みを試みる確率が、業務時間帯で10〜20%に達する。確率論的に競合・破損が発生
2. ネットワーク帯域：100Mbps Ethernet で 10人がページ読み込みを同時実行すると、ネットワークが詰まり始める
3. ロックファイル管理：Access のロック管理が、10〜15ユーザーで内部的に処理しきれなくなる
4. 圧縮頻度の追従限界：マルチユーザー利用ではゴミ領域が早く溜まり、毎日の圧縮処理が必要な状態に

マルチユーザー利用での「症状」と発生メカニズム

マルチユーザー運用で発生する代表的な問題と、その技術的メカニズムを整理します。

症状1：データ破損（File Corruption）

「データベースを修復する必要があります」というエラーメッセージが頻繁に表示される状態。

• 原因：書き込み中のクライアントがネットワーク断・PCフリーズ・強制終了した場合、ファイルの内部構造（ヘッダ・インデックス・ページ）が不整合になる
• 頻度：5人で月1回、10人で週1回、20人で日次レベル
• 対処：「圧縮と修復」を実行。最悪の場合バックアップから復元

症状2：レコードロックの過剰発生

「このレコードは他のユーザーが編集中です」というメッセージが頻発し、業務効率が落ちる状態。

• 原因：Access のページレベルロック（4KB単位）またはレコードロックの設定が業務要件に合っていない
• 対処：「楽観的ロック」（レコード保存時のみロック）への変更で改善

症状3：同時書き込み衝突

2人が同じレコードを編集して保存した時、後者の変更が失われる、または「書き込み競合」エラーが表示される。

• 原因：差分マージロジックがないため、競合発生時の解決は手動
• 対処：業務フロー上で「同じレコードを同時編集しない」運用ルールを徹底

症状4：パフォーマンス劣化

「ユーザー1人で使う時は3秒、5人同時で30秒、10人で1分」のように、ユーザー数に応じて性能が悪化。

• 原因：ファイルロック競合 + ネットワーク帯域不足 + Access内部処理の限界
• 対処：フロントエンド／バックエンド分離・データのSQL Server移行

症状5：ファイルサイズの異常膨張

5GB を超えるような急激なファイルサイズ増加。テンポラリデータが正しく解放されない状態。

• 原因：マルチユーザー利用でテンポラリデータの圧縮タイミングが取れず、ファイルにゴミが溜まる
• 対処：自動圧縮設定（オプション→現在のデータベース→「閉じる時に最適化」をON）。ただし、共有モードでは効果限定

ユーザー数別の推奨アーキテクチャ

業務規模・ユーザー数に応じた現実的な構成パターンを整理します。

「フロントエンド／バックエンド分離」の徹底解説

マルチユーザー運用で問題を抱える組織が最初に試すべきは、ファイル分割です。その手順と運用ルールを詳しく解説します。

分割の手順

1. 対象ファイルのバックアップを取得（複製＋別名保存）
2. Access で対象ファイルを開く
3. 「データベースツール」タブ → 「データの移動」グループ → 「Access データベース」（データベース分割ツール）
4. バックエンドファイルの保存先を指定。命名は「元ファイル名_BE.accdb」形式が分かりやすい
5. 分割完了。元のファイル名はそのまま残り、新規にバックエンドファイル（_BE.accdb）が作られる
6. バックエンドファイル（テーブルのみ）はサーバーの共有フォルダに配置
7. フロントエンド（元ファイル、テーブル以外は全部）を各PCのローカルフォルダにコピー配布

分割後の必須運用ルール

• フロントエンドはローカル配置：絶対に共有フォルダで複数人が直接開かない
• バックエンドは1箇所のみ：複数の場所にバックアップする場合、本番として使うのは1つに統一
• バックアップ自動化：バックエンドファイルを毎晩自動バックアップ（タスクスケジューラ + xcopy）
• フロントエンド更新管理：FE を更新したら全ユーザーに新版を配布する手順を明文化
• UNC パスでリンク：「\\server\share\BE.accdb」のような UNC パスで FE→BE をリンク

分割で解決しないケース

分割しても以下のケースでは追加対策が必要です。

• 30名以上の同時利用：分割だけでは性能・破損リスクが残る → SQL Server / Azure SQL 外出しへ
• 大量データ処理：1テーブル100万レコード超 → SQL Server で大量データ処理
• 遠隔地ユーザー：VPN や外部からのアクセスを業務要件にする場合 → クラウドDBへ
• モバイル対応：スマホ・タブレットからアクセスしたい → kintone / Power Apps への移行

SQL Server / Azure SQL バックエンド化で「30名規模」まで耐える

10〜30人規模のマルチユーザー運用では、データ部分だけ SQL Server / Azure SQL に出してフロントは Access のまま、という構成が最もコスト効率良く性能を確保できます。

移行先 DB の選定

• SQL Server Express（無料、10GB制限）：オンプレで自社運用したい組織
• SQL Server Standard（買い切り、数十万円〜）：本格的なオンプレ運用
• Azure SQL Database（月600円〜）：クラウドで運用負荷を最小化
• SQL Server in Azure VM：既存のSQL Server を含むワークロード全体をクラウドへ

SSMA（SQL Server Migration Assistant）による移行

1. Microsoft公式のSSMA for Access（無料）をダウンロード・インストール
2. SSMA で Access ファイルを開く
3. 変換対象のテーブルを選択
4. SQL Server 接続情報を設定
5. 変換実行（テーブル構造の自動変換 + データの一括コピー）
6. 移行検証（レコード数突合・サンプルデータ比較）
7. Access 側で「外部データ → リンクテーブル → ODBCデータソース → SQL Server」でリンク作成
8. VBA や フォームの動作確認

パフォーマンス改善の効果

30名超は素直に SaaS 移行を検討する

30名を超えるマルチユーザー運用は、Access の延命策では限界です。本格的な業務システム（kintone / Salesforce / Power Apps / Microsoft Dynamics 365）への移行を検討します。詳細は親ピラー記事を参照。

移行先選定の3つの判断軸

1. 業務領域：営業中心 → Salesforce、業務全般 → kintone、Microsoft環境継続 → Power Apps
2. カスタマイズ性：「現状のフォーム・レポートを完全再現」必須 → kintone / Power Apps、標準業務寄せ可能 → Salesforce
3. 予算：年間100万円以下 → kintone、年間500万円以上 → Salesforce / Dynamics

緊急対応：10人を超えても今すぐ移行できない時の暫定策

「移行プロジェクトはこれからだが、来月から12人で使い始めなければならない」という暫定対応が必要なケース：

• 業務時間帯のシフト：午前・午後で利用者を分けて、同時利用人数を実質減らす
• 役割分担の明確化：「データ入力は3名のみ」「他は閲覧のみ」のように同時書き込み発生を最小化
• 毎晩の圧縮自動化：業務時間外に圧縮と修復を自動実行するタスクスケジューラ
• 毎時バックアップ：破損時の復旧時間を最小化
• VPN 経由のリモート Desktop：「Access はサーバーに置いて、各人がリモートデスクトップで操作」する構成（パフォーマンスは落ちるが安定）

関連ガイド・クラスター

• 【完全マスター】Access 移行ガイド 2026 — 親ピラー記事
• Access 2GB制限の突破方法 — 同じく Access の限界をカバー
• Access のセキュリティリスクと2026年対策
• Access 緊急脱却 30日プラン
• Access のモバイル対応の限界と次世代モバイルアプリ化

関連ピラー

• 【完全マスター】Microsoft Access 移行ガイド 2026
• 【完全マスター】ERP移行 完全ガイド 2026

執筆・監修

Koki Soga

Aurant Technologies アーキテクト・コンサルタント