Accessの「最適化/修復」の正しい使い方と修復できない壊れ方

結論：最適化は「掃除」、修復は「応急処置」であり、どちらもバックアップの代わりにはなりません

Accessの「データベースの最適化/修復」（英語名: Compact and Repair）は、削除済みレコードが占めていた未使用領域を回収してファイルを小さくする機能と、軽微な破損を直す機能の2つを兼ねています。どちらも有用ですが、Microsoftの公式ドキュメントには「修復の過程で、破損したテーブルのデータが切り捨てられる場合がある（Access may truncate some data from tables that are damaged）」と明記されています。つまり最適化を実行した結果、データが減ってしまうことがある。この事実を知らずに使っている方が多く、この記事ではそこを含めて解説します。

先に全体像を示します。最適化でできること・できないこと、修復で直らない破損パターン、修復前に必ずバックアップが要る理由、そして修復で直らなかった場合の選択肢の順に説明します。バックアップの具体的な取り方はバックアップ設計の記事に、破損してしまったときの手順はAccessファイルが破損したらに譲ります。

最適化が実際にやること

Accessはレコードを削除してもファイルサイズが縮まりません。削除された行が占めていた領域は空きとして残り、ファイルが大きくなり続けます。最適化はその空き領域を取り除き、ファイルを実際のデータ量に見合ったサイズに戻す処理です。公式ドキュメントには「データを圧縮するのではなく、未使用領域を取り除くことでファイルを小さくする（makes your database file smaller by eliminating unused space）」と書いてあります。

定期的に実行するメリットは2つあります。ファイルサイズが適正に保たれ、2GBの上限に近づくのを遅らせられること。それと、肥大化したファイルで起きやすい動作の不安定さが改善されることです。この2点については公式も効果として認めています。

一方で、最適化が「やらないこと」もあります。削除したデータを消した結果、そのデータは復元できません。また最適化を実行しても、深刻な破損を完全に修復する保証はありません。「最適化すれば壊れたデータが戻る」という期待は持たないほうがよいです。

手動実行と「閉じるときに最適化」設定の使い方

手動で実行する場合の手順は次のとおりです。

1. 対象データベースを開いている他のユーザー全員に閉じてもらう（最適化は排他アクセスが必要で、他のユーザーが接続したまま実行することはできません）
2. データベースをAccessで開く
3. 「ファイル」→「情報」→「データベースの最適化/修復」をクリックする（「データベースツール」タブの同名項目からも実行できる）
4. 完了後、ファイルサイズが縮小していることをエクスプローラーで確認する

閉じているデータベースを最適化したい場合は、Accessを起動して空白のデータベースを開き、「ファイル」→「閉じる」の後に「データベースツール」→「データベースの最適化/修復」から対象ファイルを指定します。

「閉じるときに最適化」（Compact on Close）は、データベースを閉じるたびに自動で最適化を実行するオプションです。「ファイル」→「オプション」→「現在のデータベース」にあるチェックボックスで、データベースごとに設定します。

ただしこの自動設定には注意点があります。複数人で使うデータベースをこのオプション付きで運用すると、誰かが最後に閉じるたびに最適化が走ります。最適化は排他アクセスが必要なので、閉じようとしている人以外が接続していると実行されないか、エラーが出ます。また、「閉じるたびに自動実行」という動作は、実行前のバックアップを取る機会がない状態で走ることを意味します。公式は実行前のバックアップを推奨しているので、Compact on Closeをオンにするなら、別途バックアップの自動化も組み合わせるべきです。

修復機能の限界：直らない破損パターン

「最適化/修復」の「修復」部分は、修復できる範囲の破損の修正を試みます。ここで重要なのが、先述した公式の注記です。

「修復の過程で、破損したテーブルのデータが切り捨てられる場合がある。バックアップからデータを復旧できることもある（During the repair process, Access may truncate some data from tables that are damaged. It is sometimes possible to recover this data from a backup.）」

これは「修復で直る」ではなく「修復でデータが減る場合がある」という話です。ただし、最適化では未使用領域が除去されてファイルが小さくなるのは正常な結果です。データ欠落を疑うべきなのはファイルサイズそのものではなく、修復後のレコード件数・内容の変化や、後述するMSysCompactErrorsテーブルの記録です。修復を実行したら、これらを確認してください。

また、修復が部分的にしかできなかった場合、Accessは「MSysCompactErrors」という非表示のシステムテーブルに修復できなかったオブジェクトの一覧を記録します。修復後にそのデータベースを開き、「オブジェクト名」を「テーブル」にして「MSysCompactErrors」を探すと、何が直らなかったかを確認できます（隠しオブジェクトの表示がオフの場合は「ナビゲーションオプション」で表示に切り替える）。

修復コマンドで対応できない破損パターンをまとめると以下のとおりです。

修復前のバックアップが欠かせない理由

修復コマンドを実行すると元のファイルが上書きされます。「試したら余計に壊れた」「データが減った」というケースで確実に元へ戻すには、事前のバックアップが必要です（ファイル履歴やクラウドの版管理、ボリュームシャドウコピーなどから戻せる可能性もありますが、環境に依存します）。

当社に修復の相談が来るケースで、バックアップなしに修復コマンドを何度も実行してしまった後のファイルは、選択肢が著しく狭まります。元のファイルが何であったかを遡る手がかりがないからです。

実行前のバックアップは「ファイル」→「名前を付けて保存」→「データベースのバックアップ」で取れます。修復コマンドの実行前にこれを1つ取っておけば、修復後に問題が生じても元の状態に戻せます。最適化の前後でバックアップを取ることを習慣にするのが、最もシンプルな安全策です。バックアップの運用全体についてはバックアップ設計の記事を参照してください。

修復で直らなかった場合の選択肢

修復コマンドを試してもデータベースが正常に開かない、開けてもデータに欠損がある、という場合の次の手順を整理します。

1. バックアップを探す。最近取ったバックアップがあれば、それからの復元が最も確実です。バックアップ時点から破損までの間に入力したデータは入れ直しが必要になりますが、ファイル全体を失うよりはるかに被害が小さい。
2. 新規ファイルへのインポート再構築を試みる。新しい空のaccdbを作り、破損ファイルから「外部データ」→「Accessデータベース」でテーブルやフォームを1つずつインポートします。破損が特定オブジェクトに限られている場合は、残りを救出できます。
3. 上記が難しい場合は専門家によるデータ取り出しを検討する。原本への書き込みや修復の反復は避け、原本を複製・保全してから作業する。現状のままのファイルを保管した状態で相談することをおすすめします。

繰り返し破損するようなら、使い方や環境に構造的な問題がある可能性があります。破損の原因と予防についてはAccessファイルが破損する7つの原因と予防が参考になります。また、今手元のファイルで解析や復旧を試みることが可能かどうかは、ファイルを送らずに無料の解析可否チェックで事前確認できます。

よくある質問

Q. 最適化するとデータが消えますか。

通常の最適化でデータが消えることはありません。消えるのは削除済みのレコードが占めていた空き領域です。ただし、ファイルがすでに破損している状態で修復を実行すると、破損したテーブルのデータが切り捨てられることがあります（公式に明記）。正常なファイルへの最適化はデータを消しません。心配なら実行前にバックアップを取れば後戻りできます。

Q. Compact on Closeはオンにすべきですか。

1人で使うファイルなら有用です。自分が閉じるたびに最適化が走るので、肥大化を防げます。複数人で使う場合は慎重に。排他アクセスが必要なため、他の人が接続していると実行できず、競合が起きることがあります。また実行前のバックアップが自動では取られないので、バックアップ自動化と組み合わせないと修復によるデータ切り捨てリスクへの備えがない状態になります。

Q. 最適化したら逆に重くなりました。なぜですか。

当社の実務では、最適化の直後に一時的な速度低下が見られた例があります。テーブルの統計情報（クエリ最適化に使われる情報）が最適化でリセットされ、その状態でクエリを実行するとAccessが非効率な実行計画を選ぶことがある、というのが当社の見立てです。多くの場合は一度クエリを実行すると改善します。最適化後に重い状態が続く場合は、クエリの設計や使用しているインデックスを確認してください。

Q. 修復したら一部のフォームやレポートが消えました。

修復できなかったオブジェクトがあった場合、その情報が「MSysCompactErrors」テーブルに記録されることがあります。修復後はこのテーブルを確認してください。復元できないオブジェクトがあれば、バックアップからフォームやレポートだけをインポートして復元できます。バックアップがない場合は、破損前のファイルを元に再作成するしかありません。この状況は、事前バックアップの重要性を示す典型的なケースです。