AccessのDB分割（フロントエンド/バックエンド）で延命する方法

結論：分割は延命策であり、根本解決ではない

Accessのデータベース分割とは、1つのaccdbファイルを「バックエンド（テーブルとデータだけ）」と「フロントエンド（クエリ・フォーム・レポート・マクロ・モジュール）」の2ファイルに再編成することです。バックエンドをサーバーに1つ置き、フロントエンドを各ユーザーのPCにコピーして使います。ネットワークに流れるのがデータだけになるため、複数人での利用が重い・壊れやすい問題をある程度緩和できます。

ただし、分割してもバックエンドの2GB上限はなくなりませんし、同時書き込みの競合という根本的な問題も残ります。複数人で使うと遅い・壊れるの原因はAccessがファイル共有型であることにあり、分割はその症状を和らげる処置です。当社の延命支援の経験から言うと、もう2〜3年使い続けたい場合の現実的な選択肢になります。

分割が効く場面と、効かない場面

分割が効くのは、主に2つのパターンです。一つ目は、複数人が同じaccdbを共有フォルダに置いて開き、フォームやレポートのデザインデータもネットワーク越しに読み込んでいるケース。この構成では、毎回クエリやフォームのオブジェクトがネットワークを流れて遅くなります。分割するとフロントエンド（クエリ・フォーム等）は各PCのローカルに置けるので、ネットワーク負荷が下がります。Microsoftの公式解説でも「ネットワークを通じて共有されるのはデータのみ」と説明されています。

二つ目は、フロントエンドの改修頻度が高いケース。分割前は全員が使う1ファイルを排他で開く必要があり、その間は他の利用者の操作に制限がかかります。フロントエンドを分離すると、バックエンドは触らずフロントだけ改修できます。

効かない場面も明確です。データ量自体が2GBに近づいている場合、分割してもデータはすべてバックエンドに移るだけで、データ総量は変わりません。公式仕様にあるとおりバックエンドのaccdbの上限も同じく2GBで、上限に達すると新規データの追加などファイルサイズを増やす処理ができなくなります。また、同時書き込みが多い業務では競合エラーは引き続き起きます。分割しても解決しない問題についてはAccessの2GBの壁とAccessファイルが破損したらもあわせてご覧ください。

Database Splitterウィザードの使い方

Accessには標準で「Database Splitter（データベース分割ツール）」が用意されています。手順は次のとおりです。

1. 分割前に必ずバックアップを取る（ウィザードに「元に戻す」機能はないため）
2. 安全のため、全ユーザーにデータベースを閉じてもらう
3. 分割したいデータベースをローカルドライブにコピーし、そのコピーをAccessで開く
4. 「データベースツール」タブの「データの移動」グループにある「Accessデータベース」をクリックする
5. ウィザードが起動したら「データベースの分割」をクリックする
6. バックエンドの保存先としてサーバーのフォルダーを指定して保存する
7. 完了メッセージが表示されたら、手元のファイルがフロントエンドになっている

操作手順の詳細はMicrosoft公式の「Split an Access database」に記載されています。分割が完了すると、フロントエンドのテーブルはバックエンドへのリンクテーブルに置き換わります。見た目は同じですが、テーブルを開くとネットワーク越しにバックエンドのデータを参照します。

なお、OneDriveやSharePointに置いたaccdbを直接開いて使う運用は公式に非推奨です。当社の実務では、バックエンドはLAN上のWindowsファイルサーバーに置くことを基本にしています。

フロントエンドの配布と管理

分割後、フロントエンドは各ユーザーのPCにコピーして配布します。配布方法は公式では3通り挙げられています。メールに添付して送る、ネットワーク共有フォルダに置いて各自コピーしてもらう、CDなどのメディアで配布する。実務上は共有フォルダに「配布用フロント」フォルダを作り、そこからコピーしてもらうのが手軽です。

フロントエンドを改修したときは、全員のPCのコピーを更新する必要があります。これが管理上の手間になりがちで、「古いフロントを使い続けた利用者がエラーを出す」というトラブルが発生することもあります。利用者が多い場合は、起動時に最新フロントをコピーするVBAを仕込む方法もありますが、自動更新の仕組みを作る分だけ構造は複雑になります。

バックエンドのバックアップについてはバックアップ設計で解説しているとおり、データが入ったバックエンド側を優先して定期的に取ります。フロントエンドは設計変更のたびに1世代保管しておけば、誤って改修した場合でも戻せます。

分割しても残る問題

分割は、Accessの限界を押し上げる処置ではありません。次の3点は分割後も変わらず残ります。

Accessがファイル共有型データベースである以上、これらはアーキテクチャ上の制約です。書き込み競合が頻発する、将来的にデータ量が2GBに近づきそう、という状況であれば、分割で延命を延ばしながらSQL Server Expressへのバックエンド移行を検討する時期です。移行後の動作や制限事項は当該記事をご覧ください。

移行を見据えた分割の使い方

分割構成にしておくと、将来の移行がやりやすくなる場合があります。バックエンドのテーブルとデータだけをSQL ServerやAzure等に移し、フロントエンドのリンクテーブルの接続先を変える、という段階移行の流れが取りやすいからです。当社の移行支援でも、分割済みのAccess DBは「バックエンドから先に移す」という工程に入りやすいと感じています。

一方、分割がかえって面倒になる場面もあります。手を加えたい人が社内にいない、フロントエンドの配布や管理が手に負えない、バックエンドを置くサーバーがない、といった環境では、分割するよりシンプルに1ファイルのまま夜間バックアップを強化する選択肢もあります。分割は万能ではなく、環境と体制に合った方法を選ぶことが大切です。

2025年時点でAccess 2021を使っている場合、2026年10月13日にサポートが終了する予定です。分割の検討と並行して、移行の準備を始めるかどうかの判断が必要な時期です。現在の環境がどの状態かを把握したい場合は、無料の解析可否チェックでファイルの概況を確認できます。ファイルの送信は不要です。

よくある質問

Q. 分割すると既存のフォームやマクロは動かなくなりますか。

ウィザードで分割すると、フロントエンドのテーブルがリンクテーブルに置き換わります。フォームやクエリはそのまま残り、テーブル名で参照している限り多くの場合は変更なしで動きます。ただし、VBAのコードがカレントデータベースのファイルパスを前提としていたり、ローカルにしか存在しないテーブルを直接操作している箇所があると、分割後に動作が変わる場合があります。分割前にテスト環境で一通り動作確認してから本番に適用するのが安全です。

Q. バックエンドはどこに置くのが適切ですか。

当社の実務では、LAN上のWindowsファイルサーバーを推奨しています。NASを使う場合は、SMBのロック機能に正しく対応した製品であることを事前に確認してください（Accessとの互換性や切断時の挙動は製品によって差があります）。OneDriveやSharePointに置いたAccess DBを直接開くことは公式に非推奨とされており、予期しない動作が起きる可能性があります。バックアップの保管先としてならOneDriveも使えますが、バックエンド自体を同期フォルダに置くのは避けてください。

Q. 分割すると何人まで同時に使えますか。

Accessの公式仕様では、同時ユーザー数の上限は255と定義されています。ただしこれは理論上の上限で、実務では同時書き込みが増えるほど競合やロックが起きやすくなります。分割によってネットワーク負荷は減り、トランザクションが速く完了するぶん競合する時間幅は短くなり得ますが、ロック方式は変わらないため競合を根本解決するわけではありません。頻繁に同じテーブルへ複数人が書き込む業務では、利用者数にかかわらず競合エラーが出ることがあります。SQL ServerなどのサーバーサイドDBへの移行を検討すべきタイミングは、エラーが業務に支障を与え始めた段階です。

Q. 分割した後、元の1ファイルに戻せますか。

ウィザードに「元に戻す」機能はありません。最も確実なのは分割前のバックアップから復元することです。バックアップがない場合でも、バックエンドのテーブルをフロントエンドへ手動でインポートし直す方法はありますが、手間がかかります。分割作業の前に必ずバックアップを取っておくのは、このためでもあります。