拡張子「.mdb」が付いたファイルを見つけたものの開き方が分からない。その謎のファイル拡張子mdbはMicrosoft Accessで作成された古いデータベース形式のファイルかもしれません。
※注意：mdbという拡張子が使われるファイルは他にもあります。
ここでは、mdbの基本と、読出しの試行でつまずきやすいポイント、開けた後にも生じやすい課題を個人環境で判断できる範囲に絞って解説しています。
mdbとは何か？Accessデータベースの基本
mdbは、Microsoft Accessで使われてきたデータベースファイル形式です。いわゆる「表計算のファイル」と違い、データを表（テーブル）として複数持ち、それらをクエリで抽出・集計し、フォームで入力し、レポートで印刷する、といった一連の仕組みを1ファイルにまとめられるのが特徴です。
ただし、同じ拡張子.mdbでも作られた時代（Accessの世代）によって互換性が変わります。まずは「mdb＝Accessの古いデータベースかもしれない」という前提で開ける条件を整理していくのが安全です。
現行Accessに使われるaccdbとの違い
現行バージョンのAccessでは、主に.accdbが標準形式として使われています。一方で.mdbは旧形式で、現在でも“読み込み対象”として残っているという位置づけです。
つまり、現行Accessでもmdbを扱えるケースは多いものの、古すぎる世代（Access97以前）のmdbは対象外になることがあります。
ファイル構成は表とフォームとクエリ
mdbの中身は、最も重要なのが表（テーブル）です。実データの多くはテーブルに入っています。これが確認できれば、最悪フォームやレポートが使えなくてもデータとしての救出は成立しやすくなります。
一方で、フォーム（入力画面）やクエリ（抽出・集計条件）、レポート（帳票）に業務の処理手順が埋め込まれている場合は、テーブルだけ取り出しても元とまったく同じ運用は出来ないと考えて良いでしょう。
このように、まずテーブルの存在を確認し、次に必要な部品（クエリ等）がどこまで重要かを見極めながら操作性切り捨ての妥協点を探ることになります。
mdbファイルのバージョン差・32bit/64bitでの違い
mdbのバージョン差は、開ける・開けないの分岐に直結します。特に古い世代のmdbは、現行Access側が想定していない形式のことがあり、その場合はファイルが壊れているのではなく世代が適合できずに開けないという結果になります。
また作成時のアプリケーション（OS）が32bitか64bitでも、参照設定や外部連携（古いActiveX、ODBC連携、アドインなど）が絡むと読出しの障害になりデータの復元難易度は上がります。
mdbが開けたのに動作が不安定、ボタンが反応しない、エラーが出る、といったときは、データ自体よりも実行環境の依存関係に問題が生じていると考えられます。
古いAccessファイルを開く手段
mdbを開く手段の第一候補は、やはりMicrosoft Accessです。ただし、ここで現実的な壁になるのがPCにAccessを追加で入れようとしても、思った通りにインストールできない問題です。
特に個人PCでは、Officeの構成や契約プランの影響でAccessだけを簡単に足せないケースがあります。
Accessインストールの難関（同じバージョンが入らない？）
Officeが既に入っているPCに、同じ世代のAccessを追加しようとしても、うまくいかないことがあります。これは「同じバージョンに見えるが、エディションやインストール方式が違う」「構成が固定されている」といった理由で、追加や混在が難しくなるためです。
特に、パーソナル系の構成では、Accessが最初から含まれていないことがあり、後から単体で足したいのに手順が通らないという仕様上の問題が存在します。
この場合、オフィスパーソナルを一度アンインストールしてプロフェショナルを入れる。またはAccessだけバージョン違いを入れる（近いバージョンでもダメな場合あり）などの手段がありますが、適合の見極めが難しく個人での対応は現実的ではありません。
ビュワー（Accessランタイム）を使う
Access Runtime（ランタイム）は、Access本体がなくても、Accessアプリ（MS-Accessでは作成したファイルをアプリと呼ぶことがある）を動かすための実行環境として用意されているものです。用途が合えば、mdbの中身を確認したり、既に用意されている画面（フォーム）で閲覧・操作できたりします。
ただし、ランタイムは万能ではありません。設計・編集の自由度は下がり、ファイルの作りやセキュリティ設定によっては期待した動きにならないこともあります。
Access Runtimeで出来るのは、テーブルの中身の閲覧やデータの更新であり、フォーム編集などの機能はありません。
したがって、Access Runtimeの位置づけはAccess本体が入れられない状況で、まず中身を確認するための現実的な手段として押さえるのが適切です。
LibreOffice Baseで代替できないか？
結論から言うと、LibreOffice BaseをAccessの代わりにして.mdbを扱うのは、実務上ほぼ無理と考えた方が安全です。特に、mdbを普通に開いて、画面（フォーム）やクエリ込みでそのまま使うという期待には応えられないでしょう。
LibreOffice BaseはAccessの代替ではなく、せいぜい中身を覗けたら儲けものの位置づけになりがちです。データ救出作業は、Baseを主軸にせずAccess（またはランタイム）を中心にした方が迷いにくいです。
救出後にも難関あり？文字化修正や変換対象
現行のAccessを使ってmdbファイルが開けたとしても、それで作業が終わるとは限りません。古いデータほど、文字コードの差で見え方が崩れることがあります。ここで慌てて上書き保存すると状況を悪化させることもあるため注意が必要です。
文字コードの想定違いで読めない
文字化けは、データ自体が壊れているのではなく、表示や変換の過程で文字コードの扱いが合っていないときに起きます。
古い環境で作られたmdbは、周辺の設定（フォントやコードページ）も含めて成立していた可能性があり、別環境へ持ち込むと違いが露出します。
この問題は、修正作業に入る前に「元のデータがどう見えるか」を確認し、可能ならデータ退避→検証の順で進めるとデータ損失の被害が増えにくいです。まずは保存の安全性を優先し、表示の修正は後工程に回すのがコツです。
他形式へはまずCSVへ書き出して保存が基本
長期保存や移行を目的にするなら、まずは表データ（テーブル）をCSVへ書き出して退避するのが基本です。CSVはアプリに依存しにくく、表計算・他DB・スクリプト処理など受け皿が広いため、読める形を確保するという救出目的に利用できます。
複数テーブルがある場合は、テーブルごとにCSVを分け、分かる範囲で命名してフォルダにまとめると、後から追跡しやすくなります。フォームやクエリの再現が難しい状況でも、最小限データとして残すことはできます。
この場合、リレーション（データ連結）の保持は難しいため、移行後のアプリケーションで設定しなおす作業が必須になります。
手に負えないケース、パスワード・破損
パスワード保護や暗号化がかかっているmdbは、正しい手がかりがないと前へ進めません。また、ファイル破損が疑われる場合は、開くたびに状況が変わったり、途中でエラーが出たりするため焦って上書きしないことが重要です。
この段階では無理に直すより原本を保護したうえで作業はコピー側で検証し被害を広げないことが最優先です。
自力での対応範囲を超えていると判断できたら、そこで作業を止め、専門業者へ依頼することも視野に入れるべきでしょう。