MENU

Visual Studio 2022で「Microsoft.ACE.OLEDB.12.0 provider is not registered」を解決する方法｜Excel/Accessと32bit/64bit対策

Visual Studio

Visual Studio 2022 で .NET から Excel / Access を ACE OLE DB（Microsoft.ACE.OLEDB.12.0）で扱おうとしたら「provider is not registered」で実行時に止まる…。このエラーは Visual Studio に“登録”する話ではなく、実行PCの ACE プロバイダーの有無と 32/64 ビット不一致が原因です。現場で再発しない直し方を、切り分け手順つきでまとめます。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

「Microsoft.ACE.OLEDB.12.0 provider is not registered」とは何が起きているのか

エラー文 The Microsoft.ACE.OLEDB.12.0 provider is not registered on the local machine. は、アプリが OLE DB プロバイダー「Microsoft.ACE.OLEDB.12.0」 を呼び出そうとしたときに、Windows 側で「そのプロバイダーが見つからない（登録されていない）」と判断された状態を表します。

ここで重要なのは、Visual Studio がプロバイダーを登録するわけではないという点です。ACE は COM コンポーネントとして OS にインストールされ、レジストリに登録されます。つまり、直すべき対象は開発環境（VS）ではなく実行環境（PC）です。

代表的な原因は2つ

  • ACE（Office / Access Database Engine）がインストールされていない
  • インストールされている ACE のビット数（32/64）と、アプリが動いているビット数が一致していない
症状よくある状況最短の当たり
開発PCでは動くが、配布先で落ちる配布先に ACE が入っていない / Office が入っていない配布先に同ビット数の ACE を導入する
Debug では落ちるが、x86 にすると動くPCに32bit版Office（＝32bit ACE）が入っているアプリを x86 で動かす or Office/ACE を 64bit に統一
x64 でビルドすると落ちる32bit ACE しかない（またはその逆）アプリと ACE のビット数を揃える
Provider 名を 12.0→16.0 に変えても落ちるそもそも ACE 未導入 / ビット数不一致 / そのプロバイダー名が登録されていない実機で「入っている Provider 名」とビット数を確認する

結論：Visual Studio で“登録”するのではなく、PCに ACE を入れてビット数を合わせる

この問題の核心は次の1行に集約されます。

「実行されるプロセスのビット数」と「OSに登録されている ACE プロバイダーのビット数」が一致していないと、プロバイダーは見つからない。

同じ Windows でも、32bit 用に登録された COM は 64bit プロセスから見えません（その逆も同様）。そのため、AnyCPU のままビルドして実行環境によって 64bit になった瞬間に、32bit ACE が見えなくなり「not registered」になります。

まず最優先でやるべき切り分け：アプリが今どちらのビット数で動いているか

「Office が 32bit か 64bit か」を確認する前に、今あなたのアプリ（実行プロセス）が 32bit / 64bit のどちらで動いているかをログで確定させると、原因特定が一気に速くなります。

C#で実行ビット数を出す（最短）

using System;

Console.WriteLine($@"OS 64bit: {Environment.Is64BitOperatingSystem}
Process 64bit: {Environment.Is64BitProcess}
IntPtr.Size: {IntPtr.Size}");
  • Process 64bit: True → 64bit プロセスで動いています（64bit ACE が必要）
  • Process 64bit: False → 32bit プロセスで動いています（32bit ACE が必要）

GUI アプリでも、起動時にログファイルへ出す、例外ログに含めるだけで十分です。配布先で再現したときに「プロセスが64bitだった」と分かれば、次の手が即決できます。

原因の9割：32bit/64bit の不一致を解消する（最重要）

このエラーの典型パターンはアプリの実行ビット数と、インストールされている ACE（Office/Access Database Engine）のビット数が違うことです。方針は2択です。

方針向いているケースVisual Studio 側の設定PC側（ACE/Office）注意点
64bit に統一新規開発 / 配布先が64bit前提 / 大きいExcelや大量データx64 でビルド・実行（AnyCPU運用なら 32bit優先は無効）64bit の Office / Access Database Engine を導入端末に 32bit Office が入っていると衝突しやすい。Officeの入れ替えが発生しがち
32bit に統一既存PCが32bit Officeで統一 / 入れ替えが難しいx86 でビルド・実行（AnyCPUのままは避ける）32bit の Office / Access Database Engine を導入64bit OSでも動くが、メモリ制約などで大規模処理は工夫が必要

64bit に揃える場合（おすすめになりやすいが、現場の制約で決まる）

「現行環境で一番スッキリする」のは、アプリも Office/ACE も 64bit に揃えることです。実際、32bit版 Office 365 が原因で、64bit版に入れ替えたら解決というケースはよくあります。

  • Visual Studio のプロジェクト設定で ターゲットを x64 にする
  • （.NET Framework / AnyCPU運用の場合）Prefer 32-bit（32ビットを優先）をオフ
  • 端末側の Office / Access Database Engine を 64bit に統一する

32bit に揃える場合（既存Officeが32bitの現場では現実的）

「PC群がすでに 32bit Office で固まっている」「情シス都合で Office の入れ替えができない」という現場では、アプリ側を x86 で運用するのが堅実です。

  • Visual Studio の構成マネージャーで x86 を作成
  • 以後は x86 でビルド／実行（AnyCPU のままだと環境次第で 64bit になり事故ります）
  • 配布先にも 32bit の ACE が必要（開発PCだけ直しても再発します）

Visual Studio 2022 での具体的な設定ポイント（C# / .NET）

Platform target を固定する（AnyCPUは“事故りやすい”）

このエラーが出ている状態では、まず「アプリがどのビット数で動くか」を固定するのが効果的です。Visual Studio 2022 なら、次のどちらかが現場で多いです。

  • 配布先が32bit Office（32bit ACE） → アプリは x86 固定
  • 配布先が64bit Office（64bit ACE） → アプリは x64 固定

AnyCPU は「PCによって 32/64 が変わる」ため、ACE を使う案件では相性が悪くなります。特にテスト端末や配布先が混在していると、Debug では動いて Release で落ちる、といった“厄介な揺れ”が起きます。

「Prefer 32-bit（32ビットを優先）」の扱い

プロジェクトの種類によって表示や挙動は異なりますが、一般に次を意識すると安全です。

  • AnyCPU を使うなら：「Prefer 32-bit」をどうするかが重要（ON なら 32bit で動きやすい）
  • 確実に揃えるなら：AnyCPU をやめて x86 / x64 を明示するのが一番トラブルが少ない

テストプロジェクト（MSTest/xUnit/NUnit）も同じ罠に落ちる

意外と見落とされるのが、本体は x86 で動くのに、テストランナーが x64 で動いて落ちるパターンです。CI で突然失敗する原因にもなります。

テストでも ACE を触る場合は、以下を同じ方針で揃えてください。

  • テストプロジェクトの Platform target も x86 / x64 を揃える
  • ローカル実行・CI 実行で「実行ホストがどのビット数か」をログに残す
  • 可能なら、ACE を使う部分はインターフェースで分離し、テストではモックに差し替える（環境依存を減らす）

PC側の準備：ACE（Office/Access Database Engine）が入っているか確認する

「入っているはず」と思っていても、実際は入っていない／片方のビット数しか入っていないことが多いです。確認は次の2系統がおすすめです。

方法：インストール済み OLE DB プロバイダーを C# で列挙する

実務で一番強いのは、実機で「何が登録されているか」をコードで列挙してしまうことです。プロバイダー名が 12.0 なのか 16.0 なのか曖昧でも、列挙すれば確定します。

using System;
using System.Data;
using System.Data.OleDb;

class Program
{
    static void Main()
    {
        DataTable dt = OleDbEnumerator.GetRootEnumerator();
        foreach (DataRow row in dt.Rows)
        {
            var name = row["SOURCES_NAME"]?.ToString();
            if (name != null && name.Contains("ACE", StringComparison.OrdinalIgnoreCase))
            {
                Console.WriteLine(name);
            }
        }
    }
}

出力に Microsoft.ACE.OLEDB.12.0 や Microsoft.ACE.OLEDB.16.0 が見えれば、その PC には該当プロバイダーが登録されています。見えない場合は「未インストール」か「別ビット数にだけ登録」されている可能性が高いです。

方法：レジストリで32bit/64bitの登録場所を確認する

管理者権限がある環境なら、レジストリのキー存在で「32bit 側にあるのか / 64bit 側にあるのか」を判断できます。

確認したいこと代表的な確認先意味
64bit プロバイダーの登録HKLM\SOFTWARE\Classes\Microsoft.ACE.OLEDB.12.0
HKLM\SOFTWARE\Classes\Microsoft.ACE.OLEDB.16.0		64bit プロセスから見える登録
32bit プロバイダーの登録HKLM\SOFTWARE\WOW6432Node\Classes\Microsoft.ACE.OLEDB.12.0
HKLM\SOFTWARE\WOW6432Node\Classes\Microsoft.ACE.OLEDB.16.0		32bit プロセスから見える登録

PowerShell でさっと確認したい場合は、次のように “ある/ない” を機械的に見られます。

$providers = @("Microsoft.ACE.OLEDB.12.0","Microsoft.ACE.OLEDB.16.0")
$roots = @(
  "HKLM:\SOFTWARE\Classes",
  "HKLM:\SOFTWARE\WOW6432Node\Classes"
)

foreach ($p in $providers) {
  foreach ($r in $roots) {
    $key = Join-Path $r $p
    "{0} : {1}" -f $key, (Test-Path $key)
  }
}

True が出る場所が、その PC に登録されているビット数側です。アプリが 64bit で動くなら上段（SOFTWARE\Classes）側に登録が必要、アプリが 32bit で動くなら WOW6432Node 側に登録が必要、という考え方になります。

ACE の導入：Office がある場合／ない場合の現実的な選択肢

ACE は、ざっくり言うと次のどちらかで入ります。

  • Microsoft Office（Access を含む構成）として入る
  • Microsoft Access Database Engine（Redistributable）として入る

Office が入っている場合：まず Office のビット数に合わせる

Office が入っている PC では、まず Office が 32bit か 64bit かを確認し、それに合わせてアプリの Platform target を決めるのが最短です。Office が 32bit なのにアプリを x64 で動かすと、32bit ACE しか見えず落ちます。

現場では「Office 365 は全部64bitだと思っていたが、実は 32bit が混ざっていた」ということが本当に多いです。配布先での再発を防ぐには、情シス側の標準（32/64）を確認し、アプリ側の方針を最初に決め打ちするのが得策です。

Office を入れたくない場合：Access Database Engine を配布前提にする

サーバーや業務端末に「Office 一式」を入れる運用は避けたい、という方針は一般的です。その場合、Access Database Engine を配布先に導入してもらう（またはインストーラーで同梱する）運用になります。

ただし、ここでも最大の罠はビット数です。

  • 配布先が 32bit Office を既に持っている → 32bit の Engine を入れるのが安全
  • 配布先が 64bit Office または Office なし → 64bit の Engine を入れて、アプリも x64 に寄せるのがスムーズ

「32bit Office と 64bit Engine を同居させたい」などの話は、環境によっては通る方法が語られることもありますが、運用・保守の観点ではトラブルの温床になりやすいです。特別な事情がない限り、同じPC内は同じビット数で統一するのが現場で一番揉めません。

接続文字列の落とし穴：12.0 固定が安全とは限らない

質問では「12.0 を登録する方法」となりがちですが、実務では次の2点も見落とされやすいです。

  • 実機に入っている Provider 名が 12.0 とは限らない
  • Provider 名を変えても、ビット数が合っていなければ同じエラー

12.0 と 16.0 の考え方

ACE 12.0 は古い世代として語られることが多く、現行環境では Office/Engine の世代に合わせて 16.0 系が見える構成もあります。一方で、環境によっては「Engine は新しくても Provider 名は 12.0 のまま」ということもあり、ここは決め打ちが危険です。

一番確実なのは「そのPCに登録されている Provider 名」を列挙して、その名前を接続文字列に使うことです（前述の列挙コードが効きます）。

用途別の接続文字列例（Excel / Access）

対象例（Provider 12.0）ポイント
Excel（.xlsx）Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\data\sample.xlsx; Extended Properties="Excel 12.0 Xml;HDR=YES;IMEX=1";HDR=YES は先頭行を見出し扱い。IMEX=1 は型推測の揺れ対策に使われることが多い
Excel（.xls）Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\data\sample.xls; Extended Properties="Excel 8.0;HDR=YES;IMEX=1";.xls は Excel 8.0 と書くケースが多い
Access（.accdb）Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\data\sample.accdb; Persist Security Info=False;Excel と違って Extended Properties は必須ではないことが多い
Access（.mdb）Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\data\sample.mdb; Persist Security Info=False;古い .mdb でも ACE で開けるケースが多い（環境依存）

Provider を 16.0 に変える場合は、Provider=Microsoft.ACE.OLEDB.16.0; のように差し替えます。ただし、その名前が実機に登録されていることが前提です（登録がなければ同じ “not registered” になります）。

実装例：OleDbConnection で Excel を読む最小コード

「プロバイダーは入っているはずなのに動かない」を早く切り分けるために、まずは最小コードで接続確認をするのがおすすめです。業務ロジックに埋もれた状態で調査すると、例外が握りつぶされて原因が見えにくくなります。

using System;
using System.Data;
using System.Data.OleDb;

class Program
{
    static void Main()
    {
        var path = @"C:\data\sample.xlsx";
        var connStr =
            "Provider=Microsoft.ACE.OLEDB.12.0;" +
            $"Data Source={path};" +
            "Extended Properties=\"Excel 12.0 Xml;HDR=YES;IMEX=1\";";

        using var conn = new OleDbConnection(connStr);
        conn.Open();

        using var cmd = conn.CreateCommand();
        cmd.CommandText = "SELECT * FROM [Sheet1$]";

        using var da = new OleDbDataAdapter(cmd);
        var dt = new DataTable();
        da.Fill(dt);

        Console.WriteLine($"Rows: {dt.Rows.Count}");
    }
}

この最小コードで “not registered” が出るなら、問題はほぼ 実行環境（ACEの有無/ビット数）にあります。逆に、ここが通るなら接続文字列やシート名、権限、Excel側の形式など別の要因に進めます。

現場のチェックリスト（これを順に潰すと最短で直る）

再発を防ぐには「開発PCで直った」で終わらせず、配布先も含めて同じ観点で揃える必要があります。以下の順にチェックすると遠回りしにくいです。

チェック項目確認方法期待する状態
アプリが 32bit/64bit どちらで動いているかEnvironment.Is64BitProcess をログ出力方針（x86 or x64）と一致している
配布先PCの Office のビット数Office の「アカウント」画面などで確認アプリと同じビット数
ACE Provider が登録されているかOleDbEnumerator で列挙 / レジストリ確認必要な Provider 名が見える
Visual Studio の Platform targetx86/x64/AnyCPU の確認、構成マネージャー確認AnyCPU に頼らず、運用方針のビット数に固定
接続文字列の Provider 名実機で列挙した Provider 名と照合登録されている Provider 名を使用

よくある落とし穴と、ハマらないための実務的アドバイス

落とし穴：開発PCだけ64bitにして「解決した」と思い込む

開発PCで Office を 64bit に入れ替えたら直った、という体験は強いのですが、配布先が 32bit Office のままだと確実に再発します。配布先が複数台ある場合は、次のどちらかを決めて運用として固定しましょう。

  • 配布先の Office/Engine を 全台64bit に統一し、アプリも x64
  • 配布先の Office/Engine を 全台32bit に統一し、アプリも x86

落とし穴：AnyCPU + 環境依存で“たまたま動いている”状態

AnyCPU のままでも、たまたま 32bit で動く環境では問題が出ません。しかし、Windows Update、Office更新、PC入替、CI のホスト変更などでプロセスビット数が変わった瞬間に落ちます。ACE を使う場合、AnyCPU は「将来の不具合予約」になりがちです。

落とし穴：Excel のシート名・範囲指定で別エラーになり、原因がブレる

“not registered” を直した後、次に出やすいのが「シート名が違う」「$ を付け忘れた」「先頭行が空で型推測がズレる」などの Excel 特有の別問題です。調査を混線させないために、まずは次のように切り分けるのがコツです。

  • まずは 接続できるか（Openできるか）だけを確認する
  • 次に シート一覧を取得して、実際のシート名をログに出す
  • 最後に SELECT を実行してデータ型や NULL を調整する

落とし穴：サーバーで Office / ACE 前提の運用にしてしまう

業務アプリを Windows Server 上で動かす場合、Office や ACE のインストールが運用面でネックになることがあります（パッチ適用、競合、権限、実行ユーザーなど）。「どうしても Excel を読みたい」だけなら、ACE 以外の方式も検討余地があります。

ACE を使わない選択肢（要件次第ではこちらが安全）

「配布先に Office/Engine を入れたくない」「ビット数でトラブルを起こしたくない」という要件が強い場合、Excel 取り込みは別手段の方が安定します。用途別に考えると判断しやすいです。

やりたいことACE を使うACE 以外の代表例現場での向き不向き
Excel（.xlsx）を読み取り中心で取り込みたい○（ただし配布先依存）Open XML 系ライブラリ / Excel 読み取りライブラリ配布先に何も入れたくないなら代替が強い
Access（.accdb）に対してSQLで読み書きしたい○（要件次第でDB移行も検討）Access のまま運用するなら ACE が現実的
社内PCが Office で統一されている○代替も可能統一済みなら ACE で割り切るのもあり

ただし、Access（.accdb）の読み書きを業務要件で必須としている場合、ACE を避けられないこともあります。その場合は本記事の通り、ビット数統一と配布先前提の整理を最優先に進めるのが正攻法です。

トラブルシューティング：この順で確認すると迷子にならない

最後に、現場で「結局どこから見ればいいの？」となったときのチェック順をまとめます。ここまでの内容を短いフローに落としたものです。

  • アプリが今 32bit/64bit のどちらで動いているかをログで確定する
  • 配布先PCに入っている Office / Engine のビット数を確認する
  • 必要なら アプリの Platform target を x86 / x64 に固定する
  • OleDbEnumerator で Provider 名を列挙し、接続文字列の Provider と一致させる
  • 最小コードで接続できることを確認してから、本体ロジックに戻す

この流れで進めれば、「Visual Studio で 12.0 を登録する方法」を探して時間を溶かすことなく、原因の大半を最短で潰せます。ACE は便利ですが環境依存が強い分、方針（x86/x64）を先に決めて統一することが、結局いちばんコストが低い解決策になります。

Visual Studio
32bit 64bit Excel Access Visual Studio 2022 ACE OLE DB

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次