- 概要
- この記事でわかること
- この記事の主な内容
- 1. Accessのファイル容量を圧縮する最も簡単な方法｜まず「最適化/修復」を実行
- 2. なぜAccessのファイル容量は増える？｜削除しても未使用領域が残る仕組み
- 3. Accessの最適化/修復を手動で行う手順｜開いているDB・開いていないDB
- 4. 「閉じるときに最適化する」で自動圧縮する方法と注意点
- 5. 最適化/修復の前に必ず確認すること｜バックアップ・排他アクセス・権限
- 6. 最適化しても容量が減らない・すぐ増える場合の原因と根本対策｜2GB到達前に見直す
- 7. まとめ｜最適化/修復は定期メンテナンス、再肥大化するなら構造を見直す
- 8. よくある質問（FAQ）
- 参考情報
概要
| この記事の結論 Accessのファイル容量を小さくする最も簡単な方法は、［データベースの最適化/修復］を実行することです。これはZIPのようにデータそのものを圧縮する処理ではなく、削除や一時処理などでファイル内に残った未使用領域を回収し、データベースファイルを小さくするメンテナンス機能です。実行前にはバックアップを取り、共有データベースでは他の利用者が使用していない状態を確認してから行います。 |
この記事でわかること
- Accessの「最適化/修復」でファイル容量を小さくする基本手順
- レコードやオブジェクトを削除しても、すぐファイルサイズが小さくならない理由
- バックアップ・排他アクセス・ファイル権限を確認してから実行すべき理由
- 「閉じるときに最適化する」の設定方法と、複数ユーザーDBでの注意点
- 最適化しても容量が減らない／すぐ増える場合の原因と、2GB到達前の根本対策
この記事の主な内容
1.Accessのファイル容量を圧縮する最も簡単な方法｜まず「最適化/修復」を実行
2.なぜAccessのファイル容量は増える？｜削除しても未使用領域が残る仕組み
3.Accessの最適化/修復を手動で行う手順｜開いているDB・開いていないDB
4.「閉じるときに最適化する」で自動圧縮する方法と注意点
5.最適化/修復の前に必ず確認すること｜バックアップ・排他アクセス・権限
6.最適化しても容量が減らない・すぐ増える場合の原因と根本対策｜2GB到達前に見直す
7.まとめ｜最適化/修復は定期メンテナンス、再肥大化するなら構造を見直す
8.よくある質問（FAQ）
想定読了時間：約10～13分
1. Accessのファイル容量を圧縮する最も簡単な方法｜まず「最適化/修復」を実行
Accessのファイルが大きくなったとき、まず試したいのが［データベースの最適化/修復］です。Microsoftも、Accessのデータベースファイルは利用に伴って大きくなることがあり、最適化/修復によって未使用領域を取り除くことでファイルサイズを小さくできると案内しています。
ここでいう「圧縮」は、ZIPファイルのようにデータを圧縮して格納する意味ではありません。Accessが使わなくなった領域を整理し、必要なデータやオブジェクトを残したまま、ファイル内部の空き領域を回収する処理です。そのため、最適化前後でファイルサイズが大きく変わることがあります。
最適化/修復とは何をする機能？
| 項目 | 内容 | 実務上のポイント |
|---|---|---|
| 未使用領域の回収 | 削除や一時処理などで残った使われていない領域を整理する | 容量削減の中心となる処理 |
| データベースの修復 | 一部の破損や不整合を修復できる場合がある | 破損が疑われる場合は修復後に内容確認を行う |
| パフォーマンス改善 | ファイル整理により動作が改善する場合がある | 容量縮小＝必ず高速化ではない |
| データ自体の圧縮 | ZIPのようにデータそのものを圧縮する処理ではない | 実データ量が多い場合は大幅に減らないこともある |
| 最初に覚えておきたいこと 最適化/修復は日常メンテナンスとして有効ですが、作業中はデータベースファイルへの排他アクセスが必要です。共有ファイルの場合は、他の利用者が使用していない時間帯に実行してください。また、修復処理を伴うため、事前バックアップを取ってから実施する運用が安全です。 |
2. なぜAccessのファイル容量は増える？｜削除しても未使用領域が残る仕組み
Accessでは、レコードの追加・更新・削除、インポート、クエリ実行、フォームやレポートの設計変更などを繰り返すうちに、データベースファイルが徐々に大きくなることがあります。特に、定期的に大量データを取り込んでから削除するような運用では、実際のデータ件数に比べてファイルサイズが大きく見えることがあります。
理由は、削除したデータや一時的に使用した領域が、Windows上のファイルサイズから即座に差し引かれるとは限らないためです。Accessのファイル内部には使われなくなった領域が残り、それが積み重なると「データは減らしたのにファイルだけ大きい」という状態になります。
容量が増えやすい代表的な使い方
| 原因・運用 | なぜ大きくなりやすいか | 確認ポイント |
|---|---|---|
| 大量データのインポート | 取り込み・加工の過程で一時領域を使うことがある | 取り込み後に不要テーブルや一時データが残っていないか |
| 追加・削除の繰り返し | 削除しても未使用領域がファイル内に残ることがある | 削除後に最適化してサイズ差を確認 |
| 一時テーブルを多用 | 作成・削除を繰り返す設計はファイル肥大化につながりやすい | 一時データの作り方・保存先を見直す |
| 添付ファイル・OLEオブジェクト | 画像やファイルをDB内に保持すると実データ量そのものが増える | 外部保存＋パス管理が適するか検討 |
| 設計変更を長期間反復 | フォーム・レポート等の編集が続く開発用DBはサイズが増えやすい | リリース前にバックアップして最適化 |
最適化/修復の仕組み｜未使用領域を回収してファイルを作り直す
最適化を実行すると、Accessはデータベース内部を整理し、現在使われているデータやオブジェクトを残したうえで、使われていない領域を取り除いた状態へ再構成します。したがって、未使用領域が多いほどファイルサイズが大きく減る可能性があります。
一方、ファイルの大部分を実データや添付ファイルが占めている場合、最適化してもサイズはほとんど変わりません。その場合は「最適化が効かなかった」のではなく、削減できる未使用領域が少ない可能性を疑います。
3. Accessの最適化/修復を手動で行う手順｜開いているDB・開いていないDB
最適化/修復は、現在開いているデータベースに対して実行する方法と、対象データベースを開かずに別のAccess画面から実行する方法があります。通常のメンテナンスでは前者が簡単です。対象ファイルを直接開けない場合や、別ファイルを指定して処理したい場合は後者を使います。
開いているデータベースを最適化/修復する手順
| STEP | 操作 | 確認ポイント |
|---|---|---|
| 1 | 対象のAccessファイルをバックアップする | 作業前のファイルを別名・別場所へ保存 |
| 2 | 他のユーザーが使用していないことを確認する | 共有DBでは全利用者に退出してもらう |
| 3 | ［ファイル］→［情報］→［データベースの最適化/修復］を選ぶ | 処理中はファイルを操作しない |
| 4 | 処理後に起動・入力・検索・帳票などを確認する | ファイルサイズと業務機能を確認 |
Microsoftの案内では、開いているデータベースに対してこのコマンドを実行すると、最適化および修復されたデータベースのコピーが同じ場所に作成されます。実務では、処理後にファイル名・更新日時・サイズを確認し、主要機能が問題なく動くことまで確認しておくと安心です。
開いていないデータベースを最適化/修復する手順
対象データベースを直接開けない場合でも、Accessを起動した状態からファイルを指定して最適化/修復できます。Microsoftの現行手順では、Accessを起動して空のデータベースを開いた後に閉じ、［データベースツール］から［データベースの最適化/修復］を選択して対象ファイルを指定します。
データベースを使用している他のユーザーがいないことを確認する。
Accessを起動し、テンプレート画面から［空のデータベース］を開く。
［ファイル］→［閉じる］で空のデータベースを閉じる。
［データベースツール］→［データベースの最適化/修復］を選択する。
対象のAccessファイルを指定して実行し、完了後に内容を確認する。
※Accessのバージョンや表示言語によってメニュー名称・位置が異なる場合があります。公開時はWindows 11 64bit＋Microsoft 365 Access最新チャネルの実画面で最終確認してください。
| 方法 | 向いている場面 | メリット | 注意点 |
|---|---|---|---|
| 開いているDBを手動実行 | 通常の定期メンテナンス | 操作が最も簡単 | 排他アクセスとバックアップが必要 |
| 開いていないDBを手動実行 | 対象DBを直接開けない／別ファイルを指定 | 対象ファイルを選んで処理できる | 他ユーザーが使っていないことを確認 |
| 閉じるときに自動実行 | 単独利用のDBで毎回メンテナンスしたい | 実行忘れを減らせる | 複数ユーザーDBでは安易に使わない |
4. 「閉じるときに最適化する」で自動圧縮する方法と注意点
Accessには、データベースを閉じるタイミングで自動的に最適化/修復を行う［閉じるときに最適化する］オプションがあります。毎回手動で実行する必要がないため、単独利用のデータベースでは管理を簡単にできます。
ただし、この設定は「Access全体の共通設定」ではなく、現在開いているデータベースごとに設定する項目です。また、最適化中はデータベースが一時的に利用できなくなるため、Microsoftは複数ユーザーが使うデータベースではこのオプションを設定しないことを勧めています。
「閉じるときに最適化する」の設定手順
対象のAccessデータベースを開く。
［ファイル］→［オプション］を選択する。
［Accessのオプション］で［現在のデータベース］を選択する。
［アプリケーション オプション］の［閉じるときに最適化する］をオンにする。
［OK］を選択し、データベースを閉じて再度開く。
自動最適化が向くケース・向かないケース
| 運用 | 判断 | 理由 |
|---|---|---|
| 1人で使うローカルDB | ○ 検討しやすい | 終了時の一時停止が他ユーザーへ影響しにくい |
| 小規模でも共有フォルダ上で複数人利用 | △ 原則は慎重に | 終了タイミングで他利用者の可用性に影響する可能性がある |
| 業務時間中に常時利用する共有DB | × 安易に有効化しない | 処理中の利用停止が業務影響につながる |
| 肥大化が激しいDB | △ 自動化だけで解決しない | 根本原因の設計・データ保持方法を別途見直す必要がある |
5. 最適化/修復の前に必ず確認すること｜バックアップ・排他アクセス・権限
最適化/修復は便利な機能ですが、業務データを扱う以上、「容量が大きいからすぐ実行」ではなく、事前確認を済ませてから行うことが重要です。特にバックアップ・排他アクセス・ファイル権限の3点は、Microsoftの案内でも開始前の確認事項として挙げられています。
実行前のチェックリスト
| 確認項目 | チェック内容 | なぜ必要か |
|---|---|---|
| バックアップ | 元ファイルを別名・別場所へコピーしている | 修復後に問題が見つかった場合に戻せるようにする |
| 排他アクセス | 他のユーザーがデータベースを開いていない | 最適化/修復にはファイルへの排他アクセスが必要 |
| ファイル権限 | 対象フォルダ・ファイルへ必要な書き込み権限がある | コピー作成や置き換えに必要 |
| 処理時間 | 業務影響の少ない時間帯を選んでいる | 処理中はデータベースを利用できない |
| 動作確認項目 | 起動・入力・検索・更新・帳票・外部連携を決めている | 修復後の異常を早く発見する |
共有データベースでは「いつ実行するか」まで運用に含める
ネットワーク上の共有Accessを最適化する場合は、作業者だけの判断で実行せず、利用者へ事前に停止時間を案内してから行う方が安全です。定期メンテナンスとして実施する場合は、処理にかかった時間を記録しておくと、次回以降の停止時間を予測しやすくなります。
また、共有データベースで肥大化や破損が頻発する場合は、単に最適化の回数を増やすより、Front EndとBack Endの分割や、利用者ごとにFront Endを配布する構成を検討した方が安定するケースがあります。
破損が疑われる場合は「修復後の内容確認」までセット
Accessが破損を検知して最適化/修復を促した場合、修復が成功しても内容確認は必要です。Microsoftは、完全に修復できた場合でもデータベース内容が正常か確認するよう案内しています。部分的にしか修復できなかった場合は、修復できなかったオブジェクトがシステムテーブル「MSysCompactErrors」に記録されることがあります。
| 注意「最適化/修復が完了した＝必ず元通り」とは限りません。特に破損が疑われるファイルは、バックアップを残したうえで、主要フォーム・クエリ・帳票・外部連携の動作確認まで実施してください。 |
6. 最適化しても容量が減らない・すぐ増える場合の原因と根本対策｜2GB到達前に見直す
最適化/修復を実行しても容量がほとんど減らない場合や、一度小さくなっても短期間で元のサイズへ戻る場合は、未使用領域だけが問題ではない可能性があります。実データ量、添付ファイル、一時テーブル、インポート処理、共有構成などを切り分けて確認します。
容量が減らない／すぐ増える代表的な原因
| 原因 | 見分け方 | 対策の方向性 |
|---|---|---|
| 実データ量そのものが多い | 最適化後もサイズがほぼ変わらない | 古いデータのアーカイブ、別DB・SQL Server等への移行を検討 |
| 添付ファイル・OLEが多い | 画像・PDF等をDB内に大量保存している | 外部保存＋パス管理へ変更できるか検討 |
| 定期インポートと削除を反復 | 毎日・毎月の処理後に容量が急増する | 一時テーブルの使い方や処理フローを見直す |
| 一時テーブル・作業テーブルが残る | 不要テーブルや中間データが蓄積している | 処理後の削除・再利用設計を見直す |
| 共有DBを一体型で運用 | 複数ユーザーが同じファイルを直接操作している | Front End／Back End分割を検討 |
| 破損・不整合が繰り返す | エラーや強制終了も併発している | バックアップ確認、分割、ネットワーク・PC環境まで調査 |
Accessのファイルサイズ上限は「2GB－システム領域」
Accessの.accdb／.mdbデータベースには、ファイル全体で「2GBからシステムオブジェクトに必要な領域を差し引いた値」というサイズ上限があります。これはWindowsの「1ファイル最大2GB」という制限ではなく、Accessデータベース自体の仕様です。容量が1GBを超えて継続的に増えている場合は、2GB直前になってから慌てるのではなく、早めにデータ構造と運用を見直した方が安全です。
Microsoftは、この制限を回避する方法の1つとして、別のAccessデータベースにあるテーブルへリンクする方法も案内しています。ただし、ファイルが増えるほど管理が複雑になるため、データ量・利用人数・将来の拡張性によってはSQL ServerやAzure SQLへデータを移す方が適するケースもあります。
2GB到達前に検討したい根本対策
| 対策 | 向いている状況 | 注意点 |
|---|---|---|
| 不要データの整理・アーカイブ | 過年度データを日常業務でほとんど参照しない | 削除前に保存義務・参照要件を確認 |
| 一時テーブル・インポート設計の見直し | 定期処理のたびに容量が増える | 処理方式そのものを改善する |
| Front End／Back End分割 | 複数ユーザーが共有DBを使う | Back End自体の2GB上限は残る |
| 複数Access DBへのテーブル分散 | すぐにDBMS移行できないがテーブル単位で分離できる | リンク・バックアップ・保守が複雑になりやすい |
| SQL Server／Azure SQLへ移行 | データ量・利用人数・同時更新が増えている | 移行設計・接続・権限・性能検証が必要 |
| 最適化してもAccessの容量がすぐ増える場合は、構造・運用から見直しを 最適化/修復は有効なメンテナンスですが、短期間で再び肥大化する場合は、不要領域だけでなくデータ保持、インポート処理、一時テーブル、添付/OLE、共有構成などに原因がある可能性があります。 既存Accessの容量・性能調査から、分割DB、保守改善、SQL Server／Azure SQL移行まで状況に応じて支援していますのでお気軽にご相談下さい。 |
7. まとめ｜最適化/修復は定期メンテナンス、再肥大化するなら構造を見直す
Accessのファイル容量を簡単に小さくするには、まず［データベースの最適化/修復］を実行します。これはデータをZIPのように圧縮する機能ではなく、ファイル内部の未使用領域を回収してサイズを縮小するメンテナンス処理です。
実行前には必ずバックアップを取得し、共有データベースでは他の利用者が使用していない状態を確保します。単独利用であれば［閉じるときに最適化する］も利用できますが、複数ユーザーDBでは一時的な利用停止が発生するため、安易に有効化しない方が安全です。
最適化しても容量が減らない、またはすぐ再肥大化する場合は、実データ量、添付ファイル、一時テーブル、インポート設計、共有構成を確認します。Accessデータベースの上限は2GBからシステム領域を差し引いた値です。上限に近づく前に、アーカイブ、Front End／Back End分割、SQL Server／Azure SQLへの移行まで含めて検討すると、長期運用しやすくなります。
| Accessの容量・性能でお困りですか？ 「最適化してもすぐ容量が戻る」「1GBを超えて増え続けている」「共有DBが重い」「破損や強制終了も増えている」といった場合は、ファイル圧縮だけでは解決しないことがあります。既存Accessの構造・データ量・処理・利用環境を確認し、最適な改善方法をご提案します。 |
8. よくある質問（FAQ）
最適化/修復は、正常なデータを削除するための機能ではありません。未使用領域の回収と修復を行うメンテナンス機能です。ただし、修復を伴う処理であり、破損状態によっては結果確認が必要です。業務データでは必ずバックアップを取ってから実行してください。
一律の削減率はありません。未使用領域が多ければ大きく減る場合がありますが、実データや添付ファイルが容量の大半を占めている場合は、ほとんど減らないこともあります。実行前後のファイルサイズを比較して判断します。
1人で使うローカルDBでは便利ですが、複数ユーザーが共有するデータベースでは安易に有効化しない方が安全です。最適化中はデータベースが一時的に利用できなくなるため、MicrosoftもマルチユーザーDBでは設定しないことを勧めています。
他のユーザーがファイルを使用している状態では実行できません。最適化/修復には排他アクセスが必要です。利用者へ作業時間を案内し、全員がデータベースを閉じたことを確認してから実行します。
最適化だけに頼らず、不要データのアーカイブ、一時テーブルやインポート処理の見直し、Front End／Back End分割、テーブルの別DB分散、SQL Server／Azure SQLへの移行を検討します。なお、Front End／Back End分割だけではBack Endファイル自体の2GB上限はなくなりません。
回収できる未使用領域が少なく、実際のデータ・添付ファイル・OLEオブジェクトなどが容量を占めている可能性があります。また、処理のたびに一時データが大量に作られる設計では、一度減ってもすぐ再肥大化します。原因を切り分けて根本対策を検討します。
参考情報
- Microsoft Support｜最適化と修復を使用してデータベース ファイルの問題を予防および修復するhttps://support.microsoft.com/ja-jp/access/compact-and-repair-a-database
- Microsoft Support｜Access の仕様
https://support.microsoft.com/ja-jp/access/access-specifications - Microsoft Support｜Access データベースを分割する
https://support.microsoft.com/ja-jp/access/split-an-access-database