Accessデータベースが「ファイルが壊れました」と言い出したとき何をすべきか。実録と予防策

Access破損！初動は原本保護

朝いちで共有ドライブのAccessファイルを開くと、突然エラーが出る。昨日まで動いていたのに、今日に限って開けない。現場の空気が一気に重くなる。

この瞬間に一番やってはいけないのは、焦って原本を触り続けることです。開き直す、上書き保存を試す、ネットワーク越しに雑にコピーする。これらは復旧の選択肢を減らす。

まず、最初の10分でやることは決まっている。

– 共有ドライブ上の原本は開かない（開き直さない）
– 開いている人がいれば全員クローズ
– OneDrive/SharePoint同期配下なら同期を止める（競合を避ける）
– 原本をローカルにコピーして隔離する（以降の作業はコピーだけ）
– 「いつから壊れたか」「直前に何をしたか」をメモする

復旧の勝負は、技術より順番です。まず証拠（原本）を守り、作業場所（コピー）を分ける。

次に、現場で事故を止めるには、復旧担当が最初に「触るな」を明確に出すのが効く。

– 「Accessが破損しました。共有フォルダ上のファイルは開かないでください」
– 「復旧作業はこちらで行います。開いている人は今すぐ閉じてください」
– 「勝手にコピーを増やさないでください（どれが最新か分からなくなります）」

Access破損、運用の落とし穴

Accessは「1つのファイル」を多層（テーブル、クエリ、フォーム、レポート。VBA）で使う。そのため、共有ドライブで多人数が同時に開く運用や、VPN/無線の瞬断。スリープ復帰の接続断に弱い。OneDrive/SharePointの同期フォルダ配下に置くと。同期競合が破損を加速させることもある。

一方で、つまり、壊れた原因が「コード」ではなく「運用」にあるケースが多い。復旧しても、運用を変えない限りまた壊れる。

よくある誤解は「1回直れば大丈夫」だ。Accessは壊れた時点で、運用のどこかが既に限界を超えている。
復旧と同時に。最低でも「分割DB」と「バックアップ運用」は入れる必要がある。

現場で実際に壊れやすいトリガーも挙げておく。

そのため、– 共有ドライブの混雑時間帯（朝/締め前）に同時に開かれる
– VPNが不安定なまま更新クエリを走らせる
– バックエンドが開きっぱなしの状態でPCがスリープする
– 同期が入ったタイミングで。同じaccdbが別名で複製される。

データ破損時の正しい対処と注意

「たまたま壊れた」ではなく。「壊れる条件が揃った」と考える方が再発防止につながる。

からなくなる）」

しかし、これが本当に厄介で、私も一度。現場の方々が良かれと思って作った「最新版_確定」「最終版_修正済み」「本当に最終版」といったコピーの山に埋もれて。どれが壊れる前の最後の状態なのか見極めるのに途方もない時間を費やしました。善意だったことは重々承知しているのですが。復旧作業は「どれが正しいか」を特定するだけでも大変な労力がかかります。焦る気持ちは分かりますが、まず「触らない」が最優先なのですね。

また、自分で何とかしようと。ネットで調べた得体の知れない修復ツールを試してしまうのも危険です。私も最初は「これで直るかも！」と藁にもすがる思いで試したことがありましたが。結局は状況を悪化させるだけでした。もし社内にIT担当やAccessに詳しい方がいるなら。遠慮なく助けを求めるのが一番の近道だと学びました。私のような文系事務職が、見よう見まねで専門的なツールを扱うのは。かえってデータを壊すリスクを高めてしまうだけなのです。

Accessトラブルは学びの機会：バックアップと安定化

Accessが一度壊れてしまうと、その復旧作業は本当に大変なものです。しかし、このトラブルを単なる事故で終わらせてはいけません。むしろ。「なぜ壊れたのか」「どうすれば壊れにくくなるのか」を考える絶好の機会だと私は捉えるようになりました。復旧作業が終わった後、一息ついてから必ず行うべきは。再発防止のための仕組みづくりです。

さらに、具体的には、まずバックアップの運用を徹底することから始めました。毎日決まった時間に自動でバックアップが取られるように設定し。いざという時に「いつの時点に戻すか」をすぐに判断できるようにしました。また。Accessのデータ部分とプログラム部分を分ける「分割データベース」の導入も。安定稼働には不可欠だと痛感しました。これによって、万が一の破損時にもデータだけは守りやすくなり。復旧の負担を大きく減らすことができたのです。

最短復旧の要、バックアップと合意

私のようなプログラミングの知識がない事務職でも。Accessの安定運用には関わることができます。大切なのは、壊れた時にどうするかだけでなく。そもそも壊れないようにするためにはどうすべきか、という視点を持つことです。この経験が、私がVBA独学を始めるきっかけにもなりました。トラブルは辛いですが、そこから学び、改善していくことで、より強く。より賢くなれるのだと信じています。

最短復旧は「バックアップに戻す」

まず、復旧で一番強いのは修復テクではなく、バックアップです。まず確認するのは2つだけ。

バックアップ確認と復元方針

– バックアップがある場所
– 何時点のバックアップか（失う入力がどれだけか）

昨夜のバックアップがあるなら、まず復元して業務再開し。失った分だけ追加入力する方が速い。バックアップが古い、または無い場合は、次の「修復」「救出」に進む。

次に、ここで大事なのは「復元の意思決定」だ。何時点に戻すかを関係者と合意しないと、復旧後に揉める。
復旧担当は、最初に「戻す時点」と「失う入力」を言い切る。

もしバックアップが無いなら、それ自体が最大の問題です。
今回の復旧が終わったら「バックアップがある状態」を作る。ここまでが復旧作業の一部になる。

Access障害対策：修復とデコンパイル

まずは隔離コピーに対して「最適化/修復」を試す。

一方で、ポイントは、原本でやらないこと。隔離コピーだけで試し、修復後に最低限の動作確認をする。

– 代表フォームが開けるか
– 入力して保存できるか
– 代表クエリが実行できるか
– 帳票プレビューが落ちないか

ここで起動できても安心しない。再発防止までセットで入れる。

そのため、実務で迷わないように、やる順番を固定する。

1) 全員クローズ（誰かが開いていると結果がブレる）
2) 隔離コピーを作る（原本は触らない）
3) Accessを空で起動して修復を実行する（ダブルクリックで開かない）
4) 動作確認（フォーム/クエリ/帳票）を通す

この段階で「開けるようになった」だけで共有ドライブへ戻すのが一番危ない。
復旧直後は、ローカルで半日〜1日は安定確認してから。運用へ戻す方が事故が少ありません。

しかし、修復トライ：/decompile（刺さる時は刺さる）

最適化/修復で直らない場合、VBAの中間コードや参照関係が壊れていることがある。そこで `/decompile` を試す価値がある。

AccessデコンパイルとVBAコンパイルの手順と注意

– Accessを閉じる
– `MSACCESS.EXE` を探す（環境で場所が違う）
– `/decompile` 付きで起動する
– 起動できたらVBAをコンパイルして保存する

さらに、万能ではないので、効かなければ深追いせず次へ進む。

/decompile は「魔法の修復」ではない。中間コードを捨てるだけなので、起動できたら必ずコンパイルして保存する。
参照設定が壊れている場合は。先に参照エラーを解消しないとコンパイルが通らありません。

業務復旧：Access段階移植と失敗回避

修復がダメなら、壊れた器に固執せず、新規DBへ段階的に移植する。

まず、順番を固定すると、復旧が現実的になる。

– まずテーブル（データ）
– 次にクエリ（集計の核）
– 最後にフォーム/レポート/VBA

フォームや帳票は作り直せるが、データは作り直せない。復旧の目的は「Accessを直す」ではなく「業務を戻す」です。

次に、段階移植が強い理由は、切り分けができるからです。一括で全部インポートすると、失敗した瞬間に「何が原因か分からない」状態になる。
まずテーブルが救えれば最悪は回避できる。フォームや帳票は後から作れる。

移植で詰まるのは「どこまで救うか」を決められないことです。
復旧の最優先は、業務の止血。最小復旧で戻してから、必要な画面や帳票を順に戻す。
全部を完璧に戻そうとすると、復旧が終わらありません。

やってはいけないこと（復旧を失敗させる典型）

一方で、復旧の大事故は、だいたい善意から起きる。

復旧で繰り返す失敗と確実な手順

– 壊れた原本を共有ドライブ上で開き直す（追い打ち）
– 原本を移動して「隔離したつもり」になる（操作が発生する）
– 復旧担当以外が勝手にコピーを増やす（どれが正か分からなくなる）
– 同期フォルダに戻してしまう（同期競合で再破損する）
– 「直ったからOK」で運用を変えない（翌月また壊れる）

復旧時は、操作する人を1人に絞る。これだけで失敗確率が下がる。
ファイル名もルール化しておくと混乱が減る。例として、隔離コピーには必ず日付を入れておく。
`DB_2026-04-17_corrupt_copy.accdb` のような命名にすると、復旧作業の履歴が追える。

Access安定運用の鍵：分割DBと管理

そのため、Accessを続けるなら、最低ラインは分割DBです。データ（バックエンド）だけを共有し、画面/VBA（フロント）は各自PCで使う。共有ドライブでフロントを使い回す運用は、結局同時編集問題が残る。

運用もセットで固定する。

– バックアップの置き場所を固定（個人PCに散らさない）
– 世代管理（複数世代を残す）
– 障害時の一次対応（原本を開かない。隔離コピー。全員クローズ）を1枚にして配布
– 改修の時間帯と担当者を固定。

しかし、復旧後にここを整えるだけで、「次の朝にまた壊れる」をかなり減らせる。

バックアップは「取る」だけでは足りない。復元できることが担保されていないバックアップは、いざという時に役に立たない。
最小構成でもいいので、次の運用を決めておく。

– 毎日: 終業後にバックエンドDBをコピー（世代は7日分）
– 毎週: フロントの最新版を配布フォルダへ配置（更新履歴を1行残す）
– 毎月: バックアップから起動テスト（代表フォーム/帳票だけ）

さらに、加えて、変更管理も軽くでいいので入れる。

変更・復旧時の運用ルールと記録

– 変更した日付と担当者を1行で残す（どこを触ったか）
– 重大な変更は。業務時間外に実施する
– フロント配布は「最新版をローカルへコピーしてから起動」を徹底する。

復旧が終わった直後に、もう1つだけやっておくと良い。
「今回の原因」と「次に壊れた時の一次対応」を。A4一枚で残すことです。
この一枚があるだけで。次回は“復旧担当が来るまでの間に悪化させる事故”を止められる。

野良DB破損とシステム移行

まず、ファイルベースで多人数運用する限り、破損リスクはゼロにならない。同時編集に強いサーバーDB（SQL Server等）へ移すか。Pythonでバッチ/ETL化して人が触る回数を減らすと。破損対応そのものが消える。

「また壊れた」が一度でも起きたら、移行は検討ではなく計画にした方がいい。
Accessの復旧はできても、復旧担当の人生の時間は戻らありません。

本格的にやるなら、SQLやサーバー、認証。バックアップまで体系的に押さえた方が速い。
__SAMURAI_URL__
で基礎から整えれば。属人化した「野良DB」から抜け出せる。

次に、そして、延命作業に時間を使い続けるべきか迷うなら。
__LEVTECH_URL__
で市場価値を確認しておくと判断材料になる。

よくある質問（ここで詰まって復旧が止まる）

Q. 「修復」を押せば直りますか？
A. 直ることもあるが。直らないこともある。重要なのは「原本ではなく隔離コピーで試す」ことと。「バックアップ確認を先にやる」こと。

OneDrive/SharePoint利用の危険 デー…

一方で、Q. OneDrive/SharePointに置いても大丈夫ですか？
A. 個人利用なら成立することもあるが。多人数運用では危険度が上がる。同期競合は破損を加速するので、分割DB＋運用ルールが最低ライン。

Q. フォームや帳票が壊れたら終わりですか？
A. 終わりではない。最悪、テーブル（データ）さえ救えれば業務は戻せる。画面や帳票は作り直せる。

データベース復旧の鉄則

– 止血: 原本を開かない、全員クローズ。同期停止
– 保全: ローカルに隔離コピー（作業はコピーのみ）
– 最短復旧: バックアップがあれば戻す（戻す時点を合意）
– 修復: 最適化/修復→動作確認→必要なら/decompile
– 救出: 新規DBへ段階移植（テーブル→クエリ→フォーム等）
– 再発防止: 分割DB＋バックアップ/変更管理の運用を固定。

そのため、復旧は「技術力の勝負」ではなく、「判断と順番の勝負」だ。
迷ったら、次の基準に戻ると良い。

– 原本を守れているか（触っていないか）
– 作業は隔離コピーだけでできているか
– まず業務を戻す方針になっているか（完璧を狙っていないか）
– 再発防止の運用を決めたか（分割DBとバックアップ）

今回の破損は痛いが、逆に言えば「危ない運用が可視化された」ということでもある。
このタイミングで土台を立て直せば、次の月曜の朝の不安は確実に減る。

関連リンクとチェックリスト

学習サービスとアンケート