2026.11.08 業務システム

Power BIとAccessの連携：接続手順・ACEエラー・ゲートウェイ更新とDB移行

Power BIとAccessの連携は、Accessデータベースコネクタでaccdbファイルを読み込むだけなら数分で終わります。つまずくのは、読み込み時の「Microsoft.ACE.OLEDB.12.0 provider is not registered」のエラーと、Power BI Serviceで定時更新するときのゲートウェイと資格情報の設定です。この記事では、コネクタの前提、Power BI Desktopでの接続手順とPower Queryのコード、ACEのエラーをPowerShellで切り分ける方法、ゲートウェイで更新するときの要件、AccessのままでよいかSQL Serverへ移すかの判断までを作業の順に示します。仕様の根拠は2026年11月時点のMicrosoft Learnの記述です。

まとめ：Power BIとAccessの連携はインポート専用の接続とACEとゲートウェイの準備

AccessからPower BIへの接続はインポートモードだけで、DirectQueryは使えません。読み込みには64ビット版のAccessデータベースエンジン（ACE）が要り、32ビット版のOfficeが入ったPCではここで止まります。Power BI Serviceで自動更新するなら、ゲートウェイを入れたPCにも64ビット版のACEを入れ、資格情報は匿名認証を選びます。

この構成で回るのは、ファイルが2GBより十分小さく、更新が1日数回で足りる間です。複数の部署が同時に書き込む、ゲートウェイのPCにOfficeを入れられない、といった条件が1つでも当てはまれば、データをSQL ServerやAzure SQLへ移し、Accessは入力画面として残す形に切り替えます。

Power BIからAccessに接続する仕組みとAccessデータベースコネクタの前提

Power BIはAccessのファイルを直接読むのではなく、Windowsに入っているACEのOLE DBプロバイダーを経由して読みます。ここを押さえると、後のエラーと更新の要件がすべて説明できます。

Accessデータベースコネクタがインポート専用である点と使える認証の種類

Power QueryのAccessデータベースコネクタのページでは、対応製品はExcel、Power BI（セマンティックモデル）、Power Query Onlineで、サポートされる機能は「インポート」だけです。レポートを開くたびにAccessへ問い合わせるDirectQueryは選べず、データはモデルに取り込んだ時点のコピーになります。

認証の種類は匿名・Windows・Basic・組織アカウントの4つが並んでいますが、Power BI Serviceで更新するときに選べるのは実質的に匿名だけです。理由はゲートウェイの章で扱います。

64ビット版Power BI DesktopとACEのビット数の一致条件

AccessとXLSのインポートに関するトラブルシューティングによると、Power BI Desktopは64ビットのアプリケーションとしてのみ提供されており、64ビットのACEを必要とします。同じページは、ACEが正しく動かない状況として次の3つを挙げています。

ACEがインストールされていない
ACEのビット数（32ビットか64ビットか）がPower BI Desktopと一致しない
Microsoft 365のサブスクリプション版Officeでファイルを扱っている

実務で一番多いのは2つ目です。社内PCの標準が32ビット版Officeのままだと、そのOfficeに付いてくるACEも32ビットなので、64ビットのPower BI Desktopからは見えません。

DesktopでのAccess読み込み手順とPower Queryのコード例

ACEが正しく入っていれば、接続の操作そのものは短く済みます。

[データを取得]からナビゲーターでテーブルを選ぶまでの4つの操作手順

コネクタのページにある手順を、Power BI Desktopの画面に沿って並べると次のとおりです。

[ホーム]＞[データを取得]＞[詳細]で一覧を開き、[Access データベース]を選ぶ
accdbまたはmdbのファイルを選んで[開く]を押す（ファイル共有にあるものはUNCパスで開く）
[ナビゲーター]で読み込むテーブルにチェックを入れる
そのまま使うなら[読み込み]、列の型や不要な列を整えるなら[データの変換]を押す

2番目でネットワークドライブの文字（Z:など）から開くと、そのドライブ文字がクエリに書き込まれます。ゲートウェイのPCには同じドライブ文字がないことが多いため、最初から\\サーバー名\共有名の形で開いておくと、後で接続先を書き換える手間を省ける構成です。Power Queryの画面操作に慣れていない場合はPower Queryの使い方の手順と結合の種類を先に読むと全体がつかめます。

Access.Database関数で接続先のパスをパラメーターに切り出すコード例

接続すると、Power Queryの[詳細エディター]にはAccess.Database関数を使ったクエリができます。引数はファイルのバイナリで、File.Contentsで読んだ中身を渡す形です。ファイルの置き場所が変わる運用なら、パスをAccessPathという名前のテキスト型パラメーターに切り出し、次のように書き換えます。

let
    Source = Access.Database(
        File.Contents(AccessPath),
        [CreateNavigationProperties = false]
    ),
    Orders = Source{[Schema = "", Item = "T_Orders"]}[Data],
    Typed = Table.TransformColumnTypes(
        Orders,
        {{"OrderDate", type date}, {"Amount", Currency.Type}}
    )
in
    Typed

AccessPathには\\fileserver01\share\sales\sales.accdbのようなUNCパスを入れます。CreateNavigationPropertiesは、リレーションシップをたどる列を作るかどうかの指定で、既定値はfalseです。

パラメーターにしておく利点は、Power BI Serviceのセマンティックモデルの設定画面からパスを変えられる点です。Power BIでのデータの更新には、クエリパラメーターはインポートモードでのみサポートされ、モデルの設定で構成すると書かれています。ファイルを別のサーバーへ移したときに、Desktopで開き直して再発行しなくて済みます。

Access接続時のACEプロバイダー未登録エラーの原因と解消手順

Power BI DesktopでAccessのファイルを開こうとして「Microsoft.ACE.OLEDB.12.0 provider is not registered」のエラーが出たら、まずACEがどのビット数で入っているかを確かめます。

PowerShellでACEプロバイダーの登録状況とビット数を確かめるコマンド例

Windowsに標準で入っているWindows PowerShell（PowerShell 7ではない方）を開き、次を実行します。1行目は今のPowerShellが64ビットで動いているかを、2行目以降はそのビット数から見えるACEのプロバイダーを表示します。

[Environment]::Is64BitProcess
(New-Object System.Data.OleDb.OleDbEnumerator).GetElements() |
    Where-Object { $_.SOURCES_NAME -like 'Microsoft.ACE.OLEDB*' } |
    Select-Object SOURCES_NAME, SOURCES_DESCRIPTION

1行目がTrueで、2行目以降に何も出なければ、64ビットのACEは入っていません。比較のために、32ビット版のWindows PowerShell（C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe）で同じコマンドを実行し、こちらにだけMicrosoft.ACE.OLEDBが出るなら、32ビット版Officeに付いてきたACEしかない状態です。

ファイルを実際に開けるかは、次の3行で確かめられます。ゲートウェイのPCで実行しておくと、Power BIを介さずにACEとファイル共有の両方を点検できます。

$cn = New-Object System.Data.OleDb.OleDbConnection 'Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\\fileserver01\share\sales\sales.accdb'
$cn.Open(); $cn.GetSchema('Tables') | Where-Object { $_.TABLE_TYPE -eq 'TABLE' } | Select-Object TABLE_NAME
$cn.Close()

32ビット版Officeとクイック実行版Officeの環境で起きる不一致の解消手順

ACEを足す方法は、PCに入っているOfficeの種類で変わります。クイック実行版Officeの外部からACEを使えない問題の解説では、Microsoft 365 Apps for Enterpriseのバージョン2009以降で、ACEをOfficeの仮想環境の外から使えるようにする対応が済んでいます。主な組み合わせは次のとおりです。

PCのOffice	追加のインストール	対応
Microsoft 365 Apps	不要	そのままDesktopから読める
Office LTSC 2021	不要	64ビット版ならそのまま読める
Office 2016・2019 Pro Plus	必要	LTSC 2021へ更新、または下記ランタイム
Officeなし（ゲートウェイ用サーバーなど）	必要	下記の64ビット版ランタイムを導入
32ビット版Office	入れ直しが必要	Officeを64ビット版で入れ直す

表のMicrosoft 365 Appsは、バージョン2009以降・64ビットの条件です。Office LTSC 2021はボリュームライセンス版、Office 2016・2019 Pro Plusはクイック実行・ボリュームライセンス版を指します。Pro Plusの行で更新の代わりに入れるのはAccess 2013 ランタイムです。Officeなしの行で導入するのは、64ビットの Microsoft 365 Access Runtimeです。

表の最後の行が厄介です。個人用ゲートウェイのトラブルシューティングには、32ビット版のExcelがあるPCには64ビット版のACEを入れられないと明記されています。Access Database Engine 2016の再頒布可能パッケージは、Microsoft 365 Appsと同じバージョン番号16.0を使うため推奨されていません。32ビット版のOfficeを使い続ける理由がアドインなどで残っているなら、Power BIを使う人だけ64ビット版へ移すか、Power BI用の作業PCを分けるのが現実的です。

Power BI ServiceでAccessを定時更新するゲートウェイの要件と資格情報

Desktopで読めても、Serviceへ発行しただけではデータは更新されません。Accessのファイルは社内にあるため、DesktopとServiceの違いと発行・更新・ゲートウェイの設定手順で扱ったオンプレミスデータゲートウェイが必要です。ここではAccessに固有の要件だけを扱います。

ゲートウェイのPCに64ビット版ACEを入れ、パスの表記をそろえる手順

ゲートウェイを入れたPCは、Desktopとは別にACEを持っている必要があります。コネクタのページは、ゲートウェイと同じPCに64ビット版のOfficeがあればACEは入っており、ない場合はMicrosoft 365 Access Runtimeから入れるよう案内しています。手順は次のとおりです。

ゲートウェイのPCで前の章のPowerShellを実行し、64ビットのACEがあるかを見る
無ければ64ビット（x64）の Microsoft 365 Access Runtime を入れ、PowerShellの確認をやり直す
ゲートウェイの管理画面で、データソースの種類にAccessを選び、Desktopと同じパスを入力する
Serviceのセマンティックモデルの設定で、そのゲートウェイとデータソースを割り当てる

3番目のパスは1文字単位でそろえます。データソースの管理（インポートとスケジュールされた更新）には、Desktopとゲートウェイのデータソースで名前が一致しなければならず、IPアドレスで指定したならゲートウェイ側もIPアドレスにする必要があると書かれています。Desktopでドライブ文字から開いていた場合は、ここでゲートウェイが候補に出てきません。同じページには、再発行するとゲートウェイとデータソースの関連付けが外れ、所有者が付け直す必要があるとも書かれています。

Access Runtimeのページには、ACEはタスクスケジューラーでの無人実行やASP.NETなどのサーバー側アプリケーション向けではないという注意書きもあります。ゲートウェイでの利用はPower BIが案内する構成ですが、常時稼働の仕組みとしては弱い部品です。

資格情報は匿名認証を選ぶ理由とファイル共有の読み取り権限の考え方

Serviceでデータソースの資格情報を入れる画面では、Windows認証を選ぶとサインインのエラーになります。個人用ゲートウェイのトラブルシューティングには、Power BI ServiceはAccessデータベースについて匿名認証だけをサポートしており、ACE OLEDBを使うデータソースのWindows認証は非サポートなので匿名を選ぶ、と書かれています。同じ箇所にあるのは、従来のACE OLEDBプロバイダーでは匿名の資格情報はWindowsの資格情報と同じだという説明です。

匿名を選んでも、ファイル共有の権限が要らなくなるわけではありません。実際にファイルを開くのはゲートウェイのPCで動いているプロセスなので、そのプロセスを動かしているWindowsアカウントにファイル共有の読み取り権限を与えておく必要があります。前の章の3行のPowerShellを、ゲートウェイと同じアカウントで実行して開ければ、権限の設定は足りています。

SharePoint・OneDrive上のAccessにゲートウェイが要る理由

「クラウドに置けばゲートウェイは要らない」と考えがちですが、Accessには当てはまりません。コネクタのページは、Power Query OnlineではAccessデータベースがローカルネットワーク上にあってもWebサイト上にあっても、ゲートウェイを選ぶ必要があるとしています。ファイルをどこに置いても、読み込むのは64ビットのACEを入れたゲートウェイのPCだということです。

クラウドへ移しても更新の経路は変わらないため、置き場所はファイルサーバーのままにし、ゲートウェイからUNCパスで読む構成にします。

Access連携の継続かSQL ServerやAzure SQLへの移行かを決める基準

ここまでの準備で連携は動きますが、続けてよいかは別の問題です。

Accessのまま連携してよい条件と、2GBと255ユーザーの上限で見送る場面

Accessの仕様では、データベースの合計サイズは2GBからシステムオブジェクトの領域を引いた大きさまで、同時ユーザー数は255までです。Accessのまま連携してよいのは、次の条件がそろっている場合に限ります。

ファイルサイズが1GB程度までで、増え方が年に数百MB以内
書き込むのが1部署の数人で、Power BIは読み取りだけ
更新は1日数回のインポートで足り、数分前のデータが要らない
ゲートウェイのPCに64ビットのACEを入れられる

反対に、複数の拠点が同じファイルに書き込んでいる、ファイルが1.5GBを超えて圧縮と修復の作業が月例になっている、という状態ならAccessのままの連携は見送ります。Power BIの定時更新が書き込み中のファイルを読みに行くたびに、ロックや破損の心配を抱えることになるからです。

SSMA for Accessでデータを移しAccessの画面はリンクテーブルで残す方法

移すときにAccessのフォームやレポートまで作り直す必要はありません。SQL Server Migration Assistant for Access（SSMA）は、AccessのテーブルをSQL Server 2019以降（WindowsとLinux）、Azure SQL Database、Azure SQL Managed Instanceへ移すMicrosoftのツールです。インストールの前提は、Windows 11以降またはWindows Server 2022以降、.NET Framework 4.7.2以降、DAOプロバイダー12.0または14.0、メモリ4GB推奨です。

移した後は、AccessアプリケーションをSQL Serverにリンクする機能で、元のテーブルをバックアップしたうえでリンクテーブルに置き換えます。入力画面はAccessのまま、データだけがSQL Serverに入る形です。リンクの注意点は3つあります。

SQL Server認証を使うとパスワードがリンクテーブルに平文で保存されるため、Windows認証にする
SQL Serverに無い関数を使うクエリは、テーブルを丸ごと手元に引いてから処理されて遅くなる。パススルークエリやビューに直す
リンクテーブルの列の追加や型の変更はAccessからできず、SSMSのインストールと使い方で紹介しているSSMSで行う

ハイパーリンク型の列は移行後にnvarchar(max)の文字列になり、リンクとしての機能は失われます。移す前に、ハイパーリンク型を使っている画面を洗い出しておきます。

移行後にPower BIの接続先をSQL Serverへ差し替えるときの作業と注意点

データがSQL Serverに入ると、Power BI側の制約がまとめて外れます。データソースの管理のページにあるとおり、SQL ServerはDirectQueryにも対応しており、ゲートウェイのPCにACEを入れる必要もなくなります。クラウドへ移すなら、Azure SQL Databaseはゲートウェイなしでも更新できる移行先です。移行先の選び方はAzure SQL DatabaseとSQL Server・Managed Instanceの違いで整理しています。

Power BIのクエリは、Access.Databaseの行をSql.Databaseに置き換えれば、後ろの列の型変換などはそのまま使えます。テーブル名がSSMAの変換で変わっていないか、日付と金額の型が意図どおりかは、置き換えた後にDesktopで確かめてから再発行します。

Accessのテーブル設計が正規化されていない、どのクエリが業務で使われているか誰も把握していない、という状態での移行は、ツールを回すだけでは終わりません。データベース設計・移行支援では、現在のAccessファイルとPower BIのレポートを確認したうえで、テーブル設計の見直しと移行の手順、Accessの画面を残す範囲を切り分けられます。

Power BIとAccessの接続・更新の条件についてよくある質問

Power BIとAccessの連携で寄せられやすい質問に、Microsoft Learnの記述を根拠に答えます。

Power BIからAccessにDirectQueryで接続できますか？

できません。Power QueryのAccessデータベースコネクタがサポートしている機能はインポートだけです。レポートを開くたびに最新のデータを見せたい場合は、データをSQL ServerやAzure SQL Databaseへ移し、そちらにDirectQueryで接続します。インポートのまま鮮度を上げるなら定時更新の回数を増やしますが、共有容量では1日8回が上限です。

Excelの古いxlsファイルでも同じACEのエラーが出るのはなぜですか？

Power BI Desktopは、Accessのファイルと Excel 97-2003 形式のxlsファイルの両方をACEで読み込むためです。トラブルシューティングのページは、xlsで同じエラーが出た場合の解決策として、Excelでファイルを開いてxlsx形式で保存し直す方法を挙げています。xlsxはACEを使わずに読めるので、ビット数の不一致を気にしなくて済みます。

Access Database Engine 2016を入れればエラーは直りますか？

Microsoft 365 Appsが入っているPCでは推奨されていません。両者が同じバージョン番号16.0を使うため、予期しない動作の原因になり、Officeの検出でインストールが止まる場合もあると公式文書に書かれています。現在の案内は、64ビットの Microsoft 365 Access Runtime を入れる方法です。