破損したAccess DBの技術的な復旧手順｜新規DBインポートと部分救出

結論：標準の修復機能で直らない場合でも、段階的な救出に可能性はあります

Accessの「最適化/修復」機能で開けないファイルは、すべてのデータが失われたわけではありません。新規ファイルへのオブジェクト単位インポートや、テーブルだけを切り出す部分救出で、状態が改善するケースがあります。ただし「必ず直る」とは言えません。破損の深さや種類によって取り出せる量は変わり、試行操作が状態を悪化させることもあります。以下の手順は「元ファイルには一切触れない」前提で進めてください。

第一歩：元ファイルの保全（これだけは外せない）

壊れたファイルをいきなり操作すると、手がかりが失われます。最初にやることは1つ、元ファイルをコピーして、以後その原本は絶対に触らないことです。

ただし、ストレージ自体に問題がある場合はコピーを開始する前に確認が必要です。ディスクから異音がする、Windowsがドライブを認識しない、ファイルのコピー操作自体でI/Oエラーが出るといった兆候があれば、操作を止めて専門のデータ復旧業者に相談してください。そうした兆候がなければ、次の手順でコピーを取ります。

• Accessを使用しているユーザーが全員ファイルを閉じているか確認する。ロックファイル（.accdbは.laccdb、.mdbは.ldb）がフォルダに残っている場合は利用中の可能性がありますが、破損時は残留することもあるため有無だけで判断せず、全ユーザーと連携プログラムが終了していることを口頭でも確認してから作業する
• ファイルエクスプローラーでコピーし、できれば別の物理媒体（外付けドライブや別PCのローカルドライブ）に保管する。同一ドライブ内の別フォルダだと、媒体障害時に原本と一緒に失うリスクがあります
• 元ファイルには以後一切触れない。属性変更も含め、操作しない
• 以降の作業はすべてコピー側で行う。作業用コピーを複数作っておくと、操作を誤ってもやり直せます

最適化/修復を試みる前にも、このコピー取得は必須です。公式ドキュメントには「修復の過程でテーブルのデータが切り捨てられる場合がある」と明記されており、バックアップからデータを復旧できる場合があるとMicrosoftは記しています（Compact and repair a database – Microsoft Support）。

ステップ1：まず標準の最適化/修復を試す

コピーに対して最適化/修復を実行します。破損したファイルが直接開けない場合は、いったんAccessを起動して空のデータベースを作り、「ファイル」→「閉じる」で空のDBを閉じてから「データベースツール」→「データベースの最適化/修復」で破損コピーを指定する方法が公式の手順です（Compact and repair a database – Microsoft Support）。軽微な破損であればこれで開けるようになることがあります。修復が一部しかできなかった場合、Accessは修復できなかったオブジェクトをシステムテーブル「MSysCompactErrors」に記録します。修復後に開いた場合は、このテーブルを確認してどのオブジェクトが影響を受けたかを把握してください。

最適化/修復の詳細な手順と、修復できない破損のパターンについては最適化/修復の正しい使い方で解説しています。

ステップ2：新規DBへオブジェクト単位でインポートする

最適化/修復で開けない場合は、新規の空データベースを作り、破損ファイルからオブジェクトを1つずつインポートする方法を試します。これが「再構築による救出」の基本手順です。

1. Accessを起動し、「空のデータベース」を新規作成する（例: recovery_work.accdb）
2. 「外部データ」タブ→「新しいデータソース」→「データベースから」→「Access」を選び、破損したコピーファイルを指定する（メニュー表示はバージョンにより異なる場合があります）
3. 「オブジェクトのインポート」ダイアログが開く。テーブル・クエリ・フォーム・レポート・マクロ・モジュールを個別に選択してインポートを試みる
4. インポートに失敗したオブジェクトが出た場合、そのオブジェクトをスキップして残りを取り出す

インポートが失敗する原因は破損だけとは限りません。オブジェクト間の依存関係や、バージョン間の機能差が原因のこともあります。エラーメッセージを確認してから対処してください。インポートできたテーブルのデータ件数を元の状態と照合し、欠損がないか確認します。

ステップ3：テーブルだけ救出し、フォーム等は再作成

フォームやモジュールがインポートできない場合でも、テーブルのデータだけは取り出せることがあります。テーブルが救出できれば、フォームやレポートは新規に作り直せます。業務上データそのものが最優先のはずですので、まずテーブルの救出に集中するのが現実的です。

注意点が1つあります。救出対象のファイルがDB分割構成（フロントエンド/バックエンド）の場合、フロントエンド側のテーブルはリンクテーブルであることが多く、インポートしてもレコードのコピーではなくリンクが再作成されるだけです。実際のデータを持っているのはバックエンドファイル（通常は別の.accdb）です。どちらのファイルが壊れているかを確認し、データが入っているファイルを救出対象にしてください。

テーブルが取り出せたら、次の点を確認します。

• テーブルごとのレコード件数（記憶や別のバックアップと照合できる場合）
• 主要な日付フィールドの最終レコードが欠損していないか
• 数値・テキスト型のフィールドに明らかな文字化けや切り捨てがないか

フォームの再構築が必要になった場合、テーブルの項目構成が手元にあると作業がしやすくなります。ブラックボックス化したAccessの解析手順にDatabase Documenterを使ったテーブル構造の可視化方法を掲載しているので参照してください。

ここまでで回復しない場合は専門家へ

JetComp等の旧ツールや外部製品について

「JetComp（JETCOMP.exe）」というツールの名前を見かけることがあります。Microsoft Q&Aでは2025年8月時点で退役の可能性が指摘されており、現在は公式の配布・サポートページを確認できません（Microsoft Q&A、回答2025-08-04）。現在は公式サポートを確認できない旧ツールとして位置づけてください。第三者サイトで配布されているものは非公式です。

サードパーティの「Access修復ソフト」と称する製品も複数存在します。効果の程度は製品や破損の状況によりまちまちで、当社では第三者検証をしていないため評価できる立場にありません。使用を検討する場合は、必ずコピーに対してのみ試してください。元ファイルへの適用は絶対に避けてください。

上記の手順をすべて試みてもデータが取り出せない場合、原因がファイル内部の論理的な破損なのか、記録媒体の障害なのかによって、頼るべき専門家が異なります。

• ディスクからファイルのコピー自体が失敗する、ストレージのエラーが出るといった症状がある場合は、媒体の物理障害を扱うデータ復旧業者への相談を検討してください
• ファイルのコピーは取れるが中身が読めない場合は、Access/Jetエンジンの内部構造に詳しい業者または技術者への相談が向いています

いずれの場合も、相談前に元ファイルのコピーが手元に残っているかを確認してください。業者によって対応範囲が異なるため、事前に確認することをおすすめします。

今後また同じ事態を繰り返さないためには、破損の原因を把握することが先決です。ネットワーク経由での共有での書き込み中断が破損を引き起こしやすいことは公式ドキュメントでも言及されています。詳しくはAccessファイルが破損する原因と予防をご覧ください。

破損が繰り返している場合、バックエンドをSQL Serverに移す構成変更は、Accessバックエンドファイルの共有による破損リスクを下げる有力な選択肢です（フロントエンドや端末側の問題は別途対処が必要です）。今の構成のまま運用継続に不安がある場合は、現在のAccessの構造とリスクを可視化することが次のステップです。無料の解析可否チェックで、まず状況の把握から始められます（顧客データの送信は不要です）。

よくある質問

Q. 新規DBへのインポートを試みたところ、一部のオブジェクトでエラーが出ます。残りは取り出せますか。

エラーになったオブジェクトをスキップして、ほかをインポートすることは可能です。「オブジェクトのインポート」ダイアログで取り出せるものだけを選んで進めてください。インポート失敗の原因は破損だけでなく、オブジェクト間の依存関係やバージョン差異のこともあるため、エラーメッセージを確認することをおすすめします。

Q. 最適化/修復を実行したら、インポートできていたテーブルのレコード数が減りました。

修復の過程でデータが切り捨てられた可能性があります。Microsoftの公式ドキュメントにもこのリスクが明記されています。元ファイルのコピーがまだ手元にあれば、そちらに対してインポート再構築を試みてください。コピーを取る前に実行してしまった場合は、Windowsのファイル履歴やシャドウコピー、クラウドの版履歴など既存のバックアップ手段に頼ることになります。そうした手段もない場合は、復旧の可能性が大きく下がります。

Q. フォームやVBAコードも含めて完全に復元できますか。

フォームとVBAモジュールは、テーブルに比べると破損の影響を受けやすい傾向があります（当社の実務経験による）。インポートできればそのまま使えることもありますが、インポートできない場合は元の動作に戻せないことがあります。VBAのコード内容が手元のメモや別の記録に残っていると、再構築の手がかりになります。

Q. 今後また壊れないようにするにはどうすれば良いですか。

ネットワーク経由でのファイル共有中に通信が中断されると破損につながります。DB分割（フロントエンド/バックエンド構成）と定期的な最適化でリスクを下げられます。それでも繰り返す場合は、バックエンドをSQL Serverに移す構成変更がバックエンドファイルの破損リスクを下げる有力な選択肢です。バックアップの設計については延命中のAccessを守るバックアップ設計を参照してください。