- 概要
- この記事でわかること
- この記事の主な内容
- 1. Accessの「最適化/修復」とは？まず仕組みと効果を理解しよう
- 2. Accessファイルの容量はなぜ増える？削除してもサイズが戻らない理由
- 3. Accessデータベースを手動で最適化/修復する方法｜開いているDB・開いていないDB
- 4. 「閉じるときに最適化する」を設定する方法｜自動実行のメリットと注意点
- 5. 最適化/修復を実行する前に確認すること｜バックアップ・排他アクセス・権限・複数ユーザー
- 6. 最適化しても容量が減らない・実行できない時の対処｜2GB上限と根本対策
- 7. まとめ｜最適化は「容量削減」と「保守」のために正しく使う
- 8. よくある質問（FAQ）
- 参考情報
概要
| 結論：この記事の結論 Accessの最適化/修復は、ZIPのようにデータそのものを圧縮する処理ではありません。削除済みオブジェクトや一時オブジェクトなどが使っていた未使用領域を整理し、データベースファイルを再構成してサイズを小さくする保守機能です。実行前にはバックアップを取り、他のユーザーが開いていない状態を確保してから行うことが重要です。 |
この記事でわかること
- Accessファイルの容量が使用に伴って増える理由
- 最適化/修復で容量が減る仕組みと「圧縮」の正しい意味
- 開いているデータベースと、開いていないデータベースを手動で最適化する方法
- ［閉じるときに最適化する］の設定方法と複数ユーザー利用時の注意点
- 最適化しても容量が減らない、実行できない場合の切り分け方
- 2GB上限が近い場合に、分割DBやSQL Server／Azure SQLを検討する判断基準
この記事の主な内容
1.Accessの「最適化/修復」とは？まず仕組みと効果を理解しよう
2.Accessファイルの容量はなぜ増える？削除してもサイズが戻らない理由
3.Accessデータベースを手動で最適化/修復する方法｜開いているDB・開いていないDB
4.「閉じるときに最適化する」を設定する方法｜自動実行のメリットと注意点
5.最適化/修復を実行する前に確認すること｜バックアップ・排他アクセス・権限・複数ユーザー
6.最適化しても容量が減らない・実行できない時の対処｜2GB上限と根本対策
7.まとめ｜最適化は「容量削減」と「保守」のために正しく使う
8.よくある質問（FAQ）
想定読了時間：約10～13分
1. Accessの「最適化/修復」とは？まず仕組みと効果を理解しよう
Accessの「データベースの最適化/修復」は、使い続けるうちに残った不要領域を整理してファイルを再構成し、容量の縮小や状態改善を図るための保守機能です。Microsoftの公式情報では「圧縮と修復」と表現される場合もありますが、本記事では検索時に一般的な「最適化/修復」という呼び方で統一します。
重要なのは、最適化を「データをZIPのように圧縮する機能」と考えないことです。Accessでは、オブジェクトを削除しても、そのオブジェクトが使用していたディスク領域がすぐに解放されないことがあります。最適化は、その空いた領域を回収し、データベースファイルを作り直すことでサイズを小さくします。
最適化で期待できること・できないこと
| 項目 | 期待できること | 注意点 |
|---|---|---|
| ファイル容量 | 未使用領域を回収し、ファイルサイズを小さくできる | 実データ自体が大きい場合、削減幅は小さい |
| 動作 | 肥大化が原因の一部処理で改善が期待できる | すべての「遅い」原因を解消する機能ではない |
| 修復 | 一定の破損や不整合の修復に役立つ | 修復できないオブジェクトやデータが残る場合がある |
| 2GB対策 | 不要領域が多ければ上限までの余裕を戻せる | 実データ量が2GBに近い場合は根本解決にならない |
| 注意：最適化/修復はバックアップの代わりではありません 破損したデータベースを修復する過程で、破損テーブルの一部データが切り捨てられる場合があります。Microsoftも、通常のバックアップとは別に、最適化/修復を実行する直前のバックアップを推奨しています。 |
「最適化」と「修復」は別々に実行するの？
現在のAccessでは、容量整理と修復をまとめたコマンドとして提供されています。利用者が「最適化だけ」「修復だけ」を個別に選択するというより、同じ処理の中で未使用領域の整理と一定の修復を行うイメージです。破損が疑われる場合は、修復後にテーブル・クエリ・フォーム・レポート・VBA・外部接続まで動作確認してください。
2. Accessファイルの容量はなぜ増える？削除してもサイズが戻らない理由
Accessのファイル容量は、レコードを追加した時だけ増えるわけではありません。データの追加・更新、フォームやレポートのデザイン変更、インポート処理などを繰り返すことで、ファイル内部に再利用されない領域や一時的なオブジェクトが残り、徐々に大きくなることがあります。
とくに業務システムでは、「CSVを一時テーブルへ取り込む→更新処理を行う→一時データを削除する」といった処理を毎日繰り返すことがあります。見た目上は一時テーブルのレコードを削除していても、ファイルそのもののサイズが元に戻らず、数か月で大きく膨らむケースがあります。
削除したデータの分だけ、すぐファイルが小さくなるわけではない
Accessでは、削除したオブジェクトやデータが使用していた領域が、OS上のファイルサイズから即座に差し引かれるとは限りません。空いた領域はデータベース内部に残り、後から再利用されることがあります。そのため、大量削除をしてもエクスプローラー上のファイルサイズがほとんど変わらないことがあります。
最適化/修復を実行すると、こうした未使用領域を整理して新しい状態に再構成するため、ファイルサイズが小さくなる可能性があります。つまり、削除処理と最適化は役割が異なります。
容量が増えやすい代表的なパターン
| パターン | なぜ増えるのか | 実務での確認ポイント |
|---|---|---|
| CSV・Excelの取込→削除 | 一時テーブルへの大量追加と削除を繰り返す | 一時テーブルの使い方、削除頻度、再膨張までの期間 |
| 大量更新・追加 | レコードの追加・更新でファイルが成長する | 実データ量そのものが増えていないか |
| フォーム・レポート等の改修 | 設計変更の積み重ねでファイルが肥大化することがある | 開発用Front Endの定期保守 |
| 添付ファイル・OLE | 画像や文書など実データそのものが大きい | 本当にDB内へ格納する必要があるか |
| 共有Back End | 複数ユーザーが同じデータファイルを継続利用する | 利用停止時間を確保してBack End側を保守する |
Accessのファイル上限は「2GB－システム領域」
Accessデータベース（.accdb／.mdb）の合計サイズは、Microsoft公式仕様で「2GBからシステムオブジェクトに必要な領域を差し引いたもの」が上限です。これはWindowsの一般的なファイル上限ではなく、Accessデータベース側の仕様です。
したがって、1.8GBや1.9GBまで大きくなったデータベースを「最適化すれば必ず解決できる」と考えるのは危険です。未使用領域が多ければ大きく縮むことがありますが、実データそのものが増えている場合は、アーカイブ、DB分割、SQL Server／Azure SQLへの移行などを検討する必要があります。
3. Accessデータベースを手動で最適化/修復する方法｜開いているDB・開いていないDB
最も基本的なのは、対象データベースを開いた状態で手動実行する方法です。操作自体は数ステップですが、最適化/修復では対象ファイルを再構成するため、作業前にバックアップと利用者停止を確認してから実行してください。
開いているデータベースを最適化する手順
1. 対象のAccessデータベースを開き、必要な作業を保存します。
2. ［ファイル］→［情報］を開き、［データベースの最適化/修復］を選択します。環境によっては「データベースの圧縮と修復」など、表記が多少異なる場合があります。
3. 処理完了後、データベースを開き直し、起動・入力・検索・更新・帳票・外部連携など主要機能を確認します。
実行前に最低限確認したい4項目
操作に慣れていても、共有DBや重要データで「そのまま最適化」を実行するのは避けます。最低限、バックアップ・排他アクセス・権限・業務停止の4点を確認してから実施します。詳しい理由は後ほどH2-5で解説します。
開いていないデータベースを最適化/修復する方法
対象DBを直接開けない場合や、別のデータベースを保守したい場合は、Accessだけを起動して対象ファイルを指定する方法があります。Microsoft公式手順では、Accessを起動し、対象DBを開いていない状態で［データベース ツール］から最適化/修復を実行し、対象ファイルを選択します。
1. 対象データベースを誰も使用していないことを確認します。
2. Accessを起動し、対象データベースを開いていない状態にします。
3. ［データベース ツール］→［データベースの最適化/修復］を選択します。
4. ［最適化元データベース］等の選択画面で、対象の.accdb／.mdbファイルを指定します。
5. 処理後、対象ファイルを開いてデータ・オブジェクト・主要機能を確認します。
最適化前後は「容量」と「動作」を両方確認する
効果確認では、最適化前後のファイルサイズだけを見るのではなく、起動時間、フォーム表示、クエリ実行、帳票出力など、もともと問題になっていた動作も確認します。容量が大きく減っても、遅さの原因がネットワーク、クエリ設計、インデックス、VBA処理などにある場合は、体感速度が変わらないことがあります。
| 確認項目 | 最適化前 | 最適化後 | 判断 |
|---|---|---|---|
| ファイルサイズ | 実機検証時に記録 | 実機検証時に記録 | 削減量だけでなく再膨張の速さも確認 |
| 起動時間 | 症状を記録 | 同じ操作で比較 | 改善しなければ別原因を調査 |
| 主要クエリ・フォーム | 遅い箇所を記録 | 同条件で再確認 | 設計・ネットワーク等の切り分けへ |
| エラー有無 | 発生内容を記録 | 再発確認 | 修復後も残る場合はバックアップや再構築を検討 |
4. 「閉じるときに最適化する」を設定する方法｜自動実行のメリットと注意点
Accessには、データベースを閉じるたびに自動で最適化/修復する「閉じるときに最適化する」設定があります。毎回手動操作をする必要がなくなるため、単独利用の小規模DBでは便利です。一方、共有DBでは利用者の終了タイミングと最適化が重なるため、安易な常時ONはおすすめできません。
「閉じるときに最適化する」の設定手順
1. 対象データベースを開き、［ファイル］→［オプション］を選択します。
2. ［Accessのオプション］で［現在のデータベース］を開きます。
3. ［アプリケーション オプション］の［閉じるときに最適化する］をオンにします。
4. ［OK］で保存し、データベースを閉じて再度開きます。
この設定はAccess全体の共通設定ではなく、現在開いているデータベースごとに設定します。別の.accdbでも自動最適化したい場合は、そのファイル側でも個別に設定が必要です。
| 重要：複数ユーザーDBでは自動最適化を安易に有効化しない Microsoftは、閉じるときの自動最適化ではデータベースが一時的に利用できなくなるため、複数ユーザーで使うデータベースには設定しないことを推奨しています。共有Back Endは保守時間を決め、利用者を停止して手動で実施する方が管理しやすくなります。 |
手動・自動・開いていないDBの使い分け
| 方法 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| 手動最適化 | 単独利用／保守時間を決めて実行 | 実行タイミングを管理しやすい | バックアップ・排他確認が必要 |
| 閉じるときに自動 | 単独利用で頻繁に肥大化する小規模DB | 操作忘れを防ぎやすい | 共有DBには不向き。終了時の処理時間も増える |
| 開いていないDBを指定 | 直接開けないDB／管理者が別ファイルを保守 | 対象を明示して処理できる | 使用者がいないことを必ず確認 |
5. 最適化/修復を実行する前に確認すること｜バックアップ・排他アクセス・権限・複数ユーザー
最適化/修復は通常の保守機能ですが、業務データベースでは「いつでも押してよいボタン」ではありません。Microsoftも、開始前にバックアップ、排他的アクセス、十分なファイルアクセス許可を確認するよう案内しています。とくに共有Back Endは、保守作業として計画して実施することが重要です。
1. 実行直前のバックアップを作る
定期バックアップがあっても、最適化/修復の直前にもう1つコピーを残します。破損を含むデータベースでは、修復処理の結果として一部データが切り捨てられる場合があるためです。作業日時が分かるファイル名で保存し、必要なら前後のファイルサイズも記録しておくと、問題発生時の切り戻しが容易です。
2. 他のユーザーが開いていない状態を確保する
最適化/修復には排他的アクセスが必要です。共有フォルダー上のBack Endを複数人が利用している場合は、全員がフォームを閉じただけではなく、Access自体を終了しているかまで確認します。定期保守なら「毎月第1金曜18時から」など保守時間を決め、利用停止を周知すると運用しやすくなります。
3. ファイルと保存先の権限を確認する
対象ファイルに十分なアクセス権がないと、最適化/修復を正常に実行できないことがあります。ネットワーク共有では、ユーザー本人のAccess権限だけでなく、Windows側の共有権限やフォルダーのアクセス許可も関係します。権限不足が疑われる場合は、管理者へ確認してください。
4. Front EndとBack Endを分けて考える
複数人で使うAccessでは、フォーム・クエリ・レポート・VBAなどを各PCのFront Endに置き、共有データをBack Endに分離する構成が基本です。Front EndとBack Endでは肥大化の原因も保守タイミングも異なるため、「どちらを最適化する必要があるのか」を分けて判断します。
例えば、一時テーブルや作業用クエリでFront Endだけが膨らんでいるなら、利用者PC側のFront Endを更新・再配布する運用が有効です。一方、共有Back Endが膨らんでいる場合は、全利用者を停止してBack End側を計画的に最適化します。
| 実務視点 最適化の効果は「何MB減ったか」だけで評価しません。数日・数週間でまた元のサイズへ戻るなら、一時テーブル、取込→削除処理、添付/OLE、共有構成など、肥大化の原因を特定する段階です。再膨張までの期間を記録すると、根本対策の優先度を判断しやすくなります。 |
6. 最適化しても容量が減らない・実行できない時の対処｜2GB上限と根本対策
最適化/修復を実行しても、必ず大幅にファイルが小さくなるわけではありません。減らない場合は「未使用領域が少ない」のか、「実データそのものが大きい」のか、「対象を間違えている」のかを切り分けます。また、処理そのものが実行できない場合は、ロックや権限、破損状態も確認します。
| 症状・原因 | 確認ポイント | 次の対策 |
|---|---|---|
| 実データ量が大きい | レコード件数、長いテキスト、添付、OLE等 | アーカイブ、外部保管、SQL Server等を検討 |
| 未使用領域が少ない | 削除・取込の履歴が少なく、もともと効率的 | 大幅減少しなくても異常とは限らない |
| リンクテーブル中心 | 実データは別のBack End／SQL Serverにある | リンク先のデータベース側を確認する |
| 共有DBがロック中 | 他ユーザー、残ったAccessプロセス、ロックファイル | 全利用者停止後に再実行 |
| 権限不足 | 対象ファイル・共有フォルダーのアクセス権 | 管理者へ権限確認 |
| 破損が残る | 修復メッセージ、MSysCompactErrorsの有無 | バックアップから復旧、再構築を検討 |
| 2GB付近まで成長 | 実データ＋オブジェクトが上限へ接近 | DB分割、アーカイブ、SQL Server／Azure SQLへ |
リンクテーブルのデータ容量は、Front Endを最適化しても減らない
リンクテーブルを使っている場合、Front Endの.accdbにはリンク情報があり、実データは別のBack EndファイルやSQL Serverに保存されています。Front Endを最適化しても、リンク先Back Endのファイルサイズは変わりません。容量問題の対象がどのファイルなのかを最初に確認してください。
修復が部分的にしか成功しない場合はMSysCompactErrorsを確認する
破損したデータベースの修復が部分的にしか成功しなかった場合、Accessは修復できなかったオブジェクトを「MSysCompactErrors」というシステムテーブルに記録することがあります。表示された場合は、その内容を確認し、以前のバックアップから戻せるオブジェクトがないか検討します。
2GB上限が近い場合は「最適化の回数」ではなく構成を見直す
Accessは1つの.accdb／.mdbで、システム領域を差し引いて約2GBという上限があります。最適化で数百MB空いたとしても、業務データの増加速度が大きければ、いずれ同じ問題が再発します。短期間で再膨張するDBほど、定期最適化の頻度を上げるより、構成を見直した方が効果的です。
- 古いデータを履歴DBへ分離・アーカイブする
- Front End／Back Endを分割し、各利用者にはFront Endを配布する
- 一時テーブルや大量取込処理の設計を見直す
- 添付ファイル・OLEオブジェクトをDB外へ保管できないか検討する
- データ量・同時利用者・可用性の要件が大きい場合はSQL Server／Azure SQLへ移行する
最適化しても容量が増え続けるAccessは、構成から見直せます
インフォースでは、Accessファイルの肥大化原因調査、一時テーブル・取込処理の見直し、Front End／Back End分割、破損リスクを抑える運用設計、SQL Server／Azure SQLへの移行まで支援しています。単に「最適化を繰り返す」のではなく、なぜ容量が増えるのかを切り分けて、長期運用しやすい構成を検討します。
7. まとめ｜最適化は「容量削減」と「保守」のために正しく使う
Accessの最適化/修復は、使用に伴って残った未使用領域を整理し、データベースファイルを再構成する保守機能です。データそのものをZIPのように圧縮するわけではありませんが、削除や一時処理を繰り返して肥大化したファイルでは、容量を大きく減らせることがあります。
安全に実行するには、直前バックアップ、排他的アクセス、十分なファイル権限を確認します。単独利用では［閉じるときに最適化する］も便利ですが、複数ユーザーDBでは一時的に利用できなくなるため、保守時間を確保した手動実行が基本です。
また、最適化してもほとんど容量が減らない、短期間で再び2GB近くまで膨らむ場合は、実データ、一時テーブル、添付/OLE、共有構成などを見直す必要があります。Accessの限界に近づいている場合は、分割DBやSQL Server／Azure SQLへの移行も選択肢です。
8. よくある質問（FAQ）
正常なデータベースであれば、最適化/修復は通常の保守機能として利用できます。ただし、破損したテーブルを修復する際に一部データが切り捨てられる場合があるため、Microsoftも実行直前のバックアップを推奨しています。
必ず毎日実行する必要はありません。ファイルの増加状況や業務処理によって適切な頻度は異なります。頻繁に肥大化する場合は、最適化回数を増やすだけでなく、取込→削除処理や一時テーブルなどの原因を確認した方が効果的です。
単独利用のデータベースでは便利な設定です。一方、複数ユーザーが使うデータベースでは、最適化中に一時的に利用できなくなるため、Microsoftは設定しないことを推奨しています。共有DBは保守時間を決めて手動実行する方が安全です。
未使用領域が少ない、または実データ自体が大きい可能性があります。添付ファイルやOLE、大量のレコードが残っている場合は、最適化しても大幅には減りません。リンクテーブルの場合は、実データが別ファイルにある点にも注意してください。
未使用領域が多ければ一時的に余裕を戻せる場合がありますが、実データ量が上限に近い場合は根本解決になりません。アーカイブ、DB分割、SQL Server／Azure SQLへの移行などを検討します。
全利用者がデータベースを閉じ、排他的にアクセスできる保守時間に実行します。共有Back Endを最適化する場合は、事前に利用停止を周知し、直前バックアップを取得したうえで作業します。
最適化は主に未使用領域を整理してファイルを再構成する役割、修復は一定の破損や不整合の回復を図る役割です。現在のAccessでは「最適化/修復」または「圧縮と修復」として1つのコマンドで提供されています。
参考情報
●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/help-access-run-faster
● Microsoft Support｜Access デスクトップ データベースを共有する方法
https://support.microsoft.com/ja-jp/access/ways-to-share-an-access-desktop-database