概要
| この記事の結論 Accessファイルの破損が疑われたら、まず全員の利用を止め、元のファイルを保全します。破損以外の原因を確認したうえで、作業用コピーに対して最適化/修復を試してください。改善しない場合は、正常なバックアップからの復元や、新しいデータベースへのインポートを検討します。開けるようになっても、件数・金額・最新データ・業務動作を確認するまでは復旧完了と判断しません。 |
この記事でわかること
- 修復前に行う利用停止と原本保全
- ファイル破損と、端末・権限・リンクの問題の切り分け
- 開ける場合と開けない場合の最適化/修復の手順
- バックアップ復元と新規DBへのインポートの使い分け
- 復旧後の確認、再発防止、専門相談へ切り替える目安
この記事の主な内容
- 破損が疑われたら、まず利用停止と原本保全を行う
- 本当に破損しているか、症状と保存先を切り分ける
- 作業用コピーで「データベースの最適化/修復」を試す
- 修復できない場合はバックアップ復元とインポートを検討する
- 復旧後はデータと業務動作を確認してから再開する
- 破損の再発を防ぐ運用と専門相談の目安
- よくある質問
- まとめ
想定読了時間：約18分～約20分
1. 破損が疑われたら、まず利用停止と原本保全を行う
最初に行うのは、修復ボタンを押すことではなく、現在の状態を残すことです。原本を変更せずに保管しておけば、作業前後を比較したり、別の復旧方法を検討したりできます。修復結果が悪かった場合に備え、作業はコピーで進めます。
Accessファイルの破損とは、データベースの内部構造や保存データが損なわれ、正常な読み書きやオブジェクトの利用ができなくなった状態です。ここでいうオブジェクトは、テーブル・クエリ・フォーム・レポートなど、データベースを構成する部品を指します。
全員がAccessを終了する
共有している場合は、利用者全員に入力・更新を止めてもらい、Accessを通常の手順で終了します。画面を閉じただけで処理が残っていることもあるため、終了できない端末があるときは管理者へ状況を伝えてください。タスクの強制終了を、全員終了の代わりに安易に使わないようにします。
他のアプリや定期処理から同じファイルを更新している場合は、それらも確認します。復旧担当者には、停止対象、停止開始時刻、利用再開の連絡先をまとめておきます。利用中にコピーしたファイルを、正常な状態のバックアップとして扱うことは避けてください。
原本と作業用コピーを分ける
利用が止まったら、エクスプローラーで対象ファイルをコピーし、日時と用途が分かる名前で保管します。例えば「受注_障害時点_20260915_1000.accdb」を保全用とし、そこから「受注_修復作業用.accdb」を作成します。保全用は開いて操作せず、修復の対象にしません。
このコピーは障害時点の状態を残すもので、破損前の正常なバックアップとは区別します。また、ファイルを複製できない、読み取りエラーが出る場合は、保存装置や共有先にも問題がある可能性があります。操作を繰り返さず、管理者へ相談してください。
エラーと発生状況を記録する
エラー画面を保存し、発生時刻、直前の操作、ファイル名、保存先、影響を受けた利用者を記録します。「開かない」だけでなく、「起動時に止まる」「特定の帳票だけ失敗する」といった再現条件を残すと、確認対象を絞れます。
併せて、Accessの製品名・バージョン・ビルド・32bitか64bitか、最後に正常に使えた時刻、バックアップの保管場所も調べます。詳しい原因が分からなくても、実際に表示された文言と操作の順番が残っていれば調査の手掛かりになります。
2. 本当に破損しているか、症状と保存先を切り分ける
Accessが開けないからといって、必ずファイルが破損しているとは限りません。保存先へのアクセス権、接続先の変更、利用環境の違いでも処理は止まります。原本の保全後に、どこで、誰に、何が起きるかを比べて確認しましょう。
特定のPCだけか、全員に起きるかを確認する
一人だけ使えない場合は、そのPCの環境や手元のファイルを優先して調べます。全員に同じ症状が出る場合は、共通の保存先や実データ側を確認します。ただし、この分け方だけで原因は確定しません。複数の要因が重なることもあります。
| 症状・発生範囲 | 優先して確認する対象 | 判断時の注意 |
|---|---|---|
| 特定のPCだけで開けない | Accessの環境、手元のファイル、接続設定 | 共有データの破損と即断しない |
| 全員が同じ操作で失敗する | 共有先、実データ、共通の変更点 | 通信・権限の問題も調べる |
| 特定の画面や帳票だけ失敗する | 該当オブジェクト、参照クエリ、部品 | テーブル全体の破損とは限らない |
| リンク先が見つからない | サーバー名、フォルダ、接続先 | 移動や名称変更を確認する |
| マクロがブロックされる | 配布元とセキュリティ設定 | ファイル修復とは別に対応する |
権限やリンク切れを修復操作と分けて考える
リンクテーブルとは、別ファイルや外部データベースのテーブルへ接続する仕組みです。保存先が変わると、画面側が正常でも接続できなくなります。まず、以前の接続先と現在の保存先が一致しているかを確認し、むやみにデータを移さないようにします。
PC変更後に症状が出た場合は、Accessと外部ドライバーの構成も確認対象です。マクロの警告が出る場合も、原因を調べずにセキュリティを全面的に無効化しないでください。これらは、破損ファイルを修復する操作とは目的が異なります。
また、容量不足のメッセージが出る場合は、保存先の空き容量とAccessファイルの大きさを確認します。ACCDB・MDBのファイルサイズ上限は、システム用の領域を含めて2GBです。上限に近い状況を、破損と同じ問題として扱わないことが大切です。
フロントエンドとバックエンドを区別する
分割されたAccessでは、主に画面や処理を持つファイルをフロントエンド、実データを持つファイルをバックエンドと呼びます。普段開いているファイルだけをコピーしても、リンク先にある実データまで保存されるわけではありません。
実務上は、どのテーブルがどこに保存されているかを最初に整理します。ローカルテーブルに一時データ以外の情報を持つ構成もあるため、「フロントエンドにはデータがない」と決めつけず、保全すべき範囲を確認してください。
さらに、コピーしたフロントエンドでもリンク先が本番のままなら、操作によって本番データを更新します。検証に入る前に接続先や起動処理を確認し、検証用データへ切り替えるなど、本番に書き込まない環境を用意します。構成が不明な場合は管理者へ依頼しましょう。
3. 作業用コピーで「データベースの最適化/修復」を試す
ファイル内部の問題が疑われる場合は、Accessの標準機能である「データベースの最適化/修復」を検討します。最適化は不要になった領域を整理する処理で、必要な業務データを削除して軽くする操作ではありません。修復を実行しても、すべての損傷が直るとは限りません。
操作前に排他アクセスと保存先を確認する
最適化/修復には、そのファイルを他の利用者が使っていない排他的な状態と、十分なファイル権限が必要です。Microsoftは、修復処理で破損したテーブルの一部データが切り捨てられる場合があるため、事前のバックアップを案内しています。
作業場所は同期対象外のローカルフォルダなど、利用者が取り違えにくい場所にします。元ファイルとは別に処理結果を書き出せる空き容量も確保してください。作業用コピーを置いただけで安心せず、リンク先と自動実行される処理の確認も済ませておきます。
ファイルが開ける場合の手順
以下は製品版Accessを前提とした操作です。画面の表記や配置はバージョンによって異なることがあるため、「最適化/修復」に相当するコマンドを確認してください。独自メニューで操作が制限されている場合は、保守担当者に依頼します。
1. 原本保全と利用停止を確認し、対象の作業用コピーを開きます。
2. ［ファイル］から［情報］を開き、［データベースの最適化/修復］を選びます。
3. 処理が終わるまで待ち、表示された結果やエラーを記録します。
4. 作業対象と処理後のファイルを確認し、復旧候補として別に保管します。
操作入口はMicrosoftの公式手順に基づきます。メッセージだけを見て本番へ戻さず、後述する件数や業務動作の確認へ進んでください。待ち時間が長いだけで処理失敗と決めつけず、応答や保存先の状態を管理者と確認します。
ファイルが開けない場合はAccess単体から実行する
対象ファイルを直接開けなくても、Access側から修復するファイルを選べます。破損が疑われるファイルを何度もダブルクリックするのではなく、Accessを起動して、データベースを開いていない状態から操作します。
1. Accessを起動し、開始画面から［空のデータベース］を作成します。
2. ［ファイル］の［閉じる］で、そのデータベースを閉じます。Access自体は終了しません。
3. ［データベースツール］の［データベースの最適化/修復］を選びます。
4. ［最適化元データベース］で、原本ではなく作業用コピーを指定します。
5. 保存先などの指定画面が出る場合は内容を確認し、処理後の結果を記録します。
修復を求めるメッセージが表示された場合も、原本が保全されていることを確認してから進めます。失敗したコピーだけを残して元の状態を失わないよう、作業日時と試した方法を記録してください。同じ操作を際限なく繰り返す必要はありません。
修復結果とMSysCompactErrorsを確認する
修復が一部のみ成功した場合、修復できなかったオブジェクトの情報が「MSysCompactErrors」というシステムテーブルに記録されることがあります。表示された場合は内容を保存し、正常バックアップから何を戻すべきかを検討する材料にします。
ただし、エラー表が見当たらないことだけで、全データが正常と判断してはいけません。実務上は、修復前後のファイルを区別したうえで、帳票や外部記録との照合結果も残します。最適化で容量が減った場合も、減った量だけからデータ欠損の有無を判断することはできません。
4. 修復できない場合はバックアップ復元とインポートを検討する
修復が難しい場合は、正常なバックアップから戻せるかを先に確認します。バックアップの時点が業務上許容できるなら、復元を優先する選択もできます。すべての方法を順番に試す必要はなく、残っているデータと業務への影響で判断します。
| 方法 | 主な目的 | 前提・限界 |
|---|---|---|
| 最適化/修復 | 現在のファイル内部の問題を修正する | 一部しか直らない場合がある |
| バックアップ復元 | 正常に保存された時点へ戻す | その後の更新は別途確認が必要 |
| 新規DBへのインポート | 読み出せるデータや部品を移す | 損傷した部分を救出できるとは限らない |
正常なバックアップの日時と内容を確認する
復元元には、正常に利用できることを確認したバックアップを使います。作成日時だけでなく、必要なテーブルや設計がそろっているかも確認してください。障害発生後に取得したコピーが、正常な復元元とは限りません。
例えば、前日18時のバックアップへ戻すなら、当日朝に登録した注文が含まれていない可能性があります。これは復元が失敗したという意味ではなく、戻した時点の違いです。どこまで戻してよいかと、戻らない更新をどう確認するかを、業務担当者と決めます。
別の場所で復元候補を確認する
本番ファイルへすぐ上書きせず、まずバックアップのコピーを検証用の場所へ置きます。分割DBであれば、画面と実データの組み合わせ、リンク先も確認します。外部システムへの送信処理がある場合は、検証中に送信されない状態にしてください。
復元候補を開き、主要データと業務操作を確認します。バックアップ後の更新は、入力元の注文書やCSV、出力済み帳票などと照合します。古いバックアップと障害時点のデータを無条件で結合すると、重複や取り消し済みデータの復活が起こり得るため、業務上の識別番号を使って判断します。
空のデータベースへ読み出せるオブジェクトを取り込む
正常なバックアップがない場合や、一部の設計・データを救出したい場合は、新しいデータベースへのインポートを検討します。インポートは部品を複製する機能であり、読み取れないデータを必ず修復する機能ではありません。
1. Accessで空のデータベースを作成し、「受注_再構築候補.accdb」など別名で保存します。
2. ［外部データ］から［新しいデータソース］、［データベースから］、［Access］を選びます。
3. 取り込み元に作業用コピーを指定し、現在のデータベースへオブジェクトをインポートする選択肢を選びます。
4. テーブル・クエリ・フォームなどの各タブで、取り込むものを選びます。
5. 必要なオプションを確認して実行し、エラーと取り込み結果を記録します。
テーブルの実データも移すときは、定義だけでなくデータを含む設定を確認します。リレーションシップなどの取り込みもオプションで指定します。「すべて選択」は現在のタブが対象なので、ほかの種類のオブジェクトを取り落とさないようにしてください。
リンクテーブルの場合は、接続情報を取り込めても、その先のデータを保全できたとは限りません。また、起動設定やVBAの参照設定、外部ファイルへのパスなども、元と同じように使えるか別途確認します。インポート成功だけを業務再開の条件にしないことが重要です。
失敗するオブジェクトを絞り込み、ACCDEの制約も確認する
一括インポートに失敗した場合は、種類ごと、さらに少数ずつ選択して、どの範囲で失敗するかを記録します。試行ごとに空の検証用DBを用意すると、重複した名前や前の結果との混同を避けやすくなります。読み出せた部分と、未確認の部分を分けて管理してください。
元ファイルがACCDE・MDEの場合は、フォーム・レポート・モジュールを別のDBへエクスポートできません。 設計を直すには、元のACCDB・MDBや開発元の保管物を探します。拡張子を変更するだけで編集可能な原本に戻すことはできません。
復元する時点と、救出できた範囲は別の情報です。「どの日付のデータへ戻したか」「不足している更新は何か」を一覧にしてから切り替えると、再開後に古い情報を正しい情報として扱う事故を防ぎやすくなります。
修復できないAccessや、データ欠損が心配な場合はご相談ください
標準の修復で改善しない場合や、復元後のデータに不安が残る場合は、現在の状態を保全したうえでご相談ください。症状・共有構成・バックアップの有無をもとに、調査と復旧方針の整理、再発防止に向けた運用改善を支援します。復旧できる範囲はファイルの状態によって異なります。
5. 復旧後はデータと業務動作を確認してから再開する
復旧の判断は、ファイルが開くかどうかだけではできません。業務で必要なデータがそろい、予定した操作が正しくできることまで確認します。確認項目を先に決め、実施者と結果を残してから切り替えると、見落としを減らせます。
件数・主要金額・最新更新を照合する
まず主要テーブルの件数、受注金額や在庫数量などの重要な集計値、直近の登録データを確認します。照合相手は、正常バックアップだけでなく、業務上の原票や出力済み帳票も使います。障害時点のファイル自体が不正確な可能性を考慮してください。
| 確認項目 | 確認する内容 | 異常があった場合 |
|---|---|---|
| 件数 | 主要テーブルの件数と期間別内訳 | 増減した期間・対象を絞る |
| 金額・数量 | 合計と業務上の主要な内訳 | 明細と原票を突き合わせる |
| 最新データ | 最終登録分、変更・取消の反映 | 復元時点以降の更新を補完する |
| 主キー・関連 | 重複、明細の親データ、関連付け | 関連が欠けた対象を確認する |
| 業務動作 | 入力・検索・帳票・入出力 | 再開前に原因を調べる |
合計値が一致していても、個別の明細が入れ替わっていたり、欠落と重複が相殺されていたりする可能性はあります。重要な業務では、代表的な明細と直近の取引を識別番号で照合します。確認できない範囲を「問題なし」と扱わず、担当者間で共有しましょう。
リレーション・リンク・参照設定を確認する
新しいDBへ移した場合は、テーブル間の関係やクエリの参照先、リンク先を確認します。VBAを使うシステムでは、参照しているライブラリや外部部品も確認対象です。画面が表示されても、特定のボタンを押したときだけエラーになる場合があります。
バックアップへ戻した画面が、現在のテーブル構造に対応しているかも確認してください。画面側とデータ側の版がずれると、存在しない項目を参照したり、登録に必要な項目が不足したりします。単に両方のファイルが開くことだけで、組み合わせが正常とは判断できません。
フォーム・帳票・入出力を試し、復旧版を保存する
検証用データで、登録、修正、削除、検索、帳票出力、CSVの取り込み・書き出しなど、実際の業務の流れを通して確認します。更新を伴う試験は、原本や本番のリンク先に対して実行しないでください。外部連携がある場合は、接続先と送信結果も確認します。
確認が終わった復旧版は、切替前に保存します。利用停止を継続した状態で本番へ配置し、各利用者が正しい版と接続先を使うことを確認してから再開します。障害時点の原本、復旧内容、補完した更新、未解決事項は、後から経緯を追えるように残しておきましょう。
6. 破損の再発を防ぐ運用と専門相談の目安
ファイルを復旧できても、保存方法や共有環境の問題が残れば再発する可能性があります。Accessを使い続ける場合も、バックアップ、共有構成、終了方法、障害時の連絡先を整えることが重要です。復旧作業と再発防止は分けて計画しましょう。
世代バックアップと復元訓練を行う
バックアップは、同じ一つのファイルへ上書きし続けるのではなく、複数の時点を残します。最新の保存分に障害が含まれていても、以前の正常な時点を選べるようにするためです。必要な保存頻度と保管期間は、失ってよい更新量や業務上の保存要件から決めます。
また、ファイルが保存されているだけでなく、実際に戻して使えるかも定期的に確認します。分割DBでは、特に実データ側のバックアップが重要です。担当者不在でも実施できるよう、保存先・復元手順・確認方法を引き継いでおきます。
共有方式と通信、終了方法を見直す
複数人で使う場合は、利用者ごとにローカルのフロントエンドを持ち、LAN上のバックエンドへ接続する分割構成を検討します。Microsoftも、画面側とデータ側を分ける共有方式を示しています。[S4] 分割しただけですべての障害がなくなるわけではなく、運用の確認は引き続き必要です。
OneDriveやSharePointの文書ライブラリに置いたAccessファイルを、その場所から直接開く運用は避けます。複数のコピーや予期しない動作につながる可能性があるためです。これはSharePointリストへリンクする方式とは別の話なので、両者を混同しないでください。
通信切断や電源断、強制終了が発生していないかも確認します。更新中に通信が途切れる環境では、アプリ側だけを修正しても改善しないことがあります。サーバー・ストレージ・ネットワークの記録を管理者に調べてもらい、障害の発生時刻と照らし合わせます。
「閉じるときに最適化する」は、全員に一律で有効化する設定ではありません。共有DBでは一時的に利用できなくなる影響があるため、利用停止とバックアップを組み合わせた保守時間を設けるなど、運用条件に合わせて判断します。
Access継続とSQL Server移行を判断する
利用規模や業務要件によっては、画面をAccessのまま残し、データをSQL Serverへ移す選択肢があります。 ただし、移行は破損したデータを自動的に直す手段ではありません。まず復旧と整合性の確認を行い、その後の改善策として検討します。
判断材料は、同時利用の状況、データ量、拠点間の接続、許容できる停止時間、バックアップ・復元の要件です。Accessの分割運用で改善できるのか、データベース側の変更が必要かを整理すると、現在の画面や業務を生かした対策を選びやすくなります。
作業を止めて相談する条件を決める
次のような状態では、操作を重ねる前に管理者や専門会社へ相談します。復旧作業に使える時間も業務によって異なるため、重要なシステムでは、いつまで自力調査を行うかをあらかじめ決めておくと判断しやすくなります。
- ファイルをコピーできない、保存装置の読み取りエラーが出る
- 標準の最適化/修復で改善せず、原因を絞れない
- 重要データが欠けている、正常なバックアップが見つからない
- 修復後も障害が繰り返し、業務停止の影響が大きい
相談時は、エラー、発生時刻、試した操作、共有構成、バックアップの日時を伝えます。保全したファイルを渡す必要がある場合は、業務データの取扱いと受け渡し方法を確認してください。分かっていることと未確認のことを分けて伝えると、調査を進めやすくなります。
よくある質問
いいえ。権限、リンク先、利用環境、マクロのブロックなどでも開けない・動かない症状が出ます。まず原本を保全し、特定のPCだけか、全員に起きるか、どの操作で失敗するかを確認してください。
必ず直るとは限りません。一部のオブジェクトやデータが復旧できない場合もあります。修復後は、主要データと業務動作を確認してから利用を再開します。原本に対して繰り返し試すことは避けてください。
読み出せるデータやオブジェクトを救出できる場合はありますが、失われた内容を必ず元に戻せるわけではありません。旧PCや納品物、管理された過去の保存物も確認し、残っている情報を保全したうえで復旧方針を検討します。
laccdbは利用中のロック情報を管理するファイルで、削除してもデータベース本体の破損は修復されません。利用者や処理が残っている状態で削除を試みず、まず利用状況と終了状態を確認してください。
リンク先の実データは、フロントエンドを戻すだけでは復元されません。どのファイルや外部DBにデータがあるかを確認し、その保存先に適した方法で復旧します。画面とデータの版が合っているかも確認が必要です。
まとめ
Accessファイルの破損が疑われたら、全員の利用停止と原本保全から始めます。破損以外の原因を切り分けたうえで、作業用コピーで修復し、必要に応じて正常バックアップからの復元や新規DBへのインポートを検討してください。
復旧後は件数・金額・最新データ・業務動作を確認し、正しい版と接続先で利用を再開します。再発する場合は、バックアップや共有方式、通信環境まで見直すことが重要です。原本を残し、判断の根拠を記録しながら進めましょう。
Accessの破損原因の調査から運用改善までご相談ください
Accessの保守・改修、SQL Serverへのデータ移行など、現在のシステムに合わせた対応を検討します。修復が難しい、復元後の確認に不安がある、障害を繰り返している場合は、症状とバックアップの状況を添えてご相談ください。
参考情報
Microsoft Support データベースを最適化および修復する
Microsoft Support バックアップと復元によるデータ保護
Microsoft Support データベースオブジェクトのインポート
Microsoft Support Accessデスクトップデータベースの共有方法
Microsoft Support Accessの仕様
Microsoft Support 別のAccessデータベースへのオブジェクトのエクスポート
Microsoft Support AccessからSQL Serverへの移行