Accessの移行先クラウドDB比較｜Azure SQL・RDSなどの選び方

結論：AccessフロントエンドをODBC接続で残しながらバックエンドをクラウドDBへ移せる

AccessのバックエンドDBをクラウド上のマネージドデータベースへ移す主な選択肢として、この記事では3つのマネージドDB（Azure SQL Database・Amazon RDS for SQL Server・Google Cloud SQL for SQL Server）と、比較対象としてIaaS VM上またはオンプレミスのSQL Serverを取り上げます。データをクラウドに置きつつAccessからリンクテーブルで接続する構成は、MicrosoftのSSMA（SQL Server Migration Assistant）公式ドキュメントでも「既存のAccessアプリケーションをリンクテーブル経由で継続利用できる」と説明されています（Linking Access Applications to SQL Server and Azure SQL Database — Microsoft Learn）。ただし、クエリ・VBA・データ型などの互換性検証と修正が必要になる箇所は生じます。

どの選択肢が合うかは、すでに契約しているクラウド環境、Accessフロントエンドを残す期間の長さ、ネットワーク構成、予算の4点で変わります。この記事では各選択肢の位置づけと注意点を中立に整理します。料金やスペックの具体的な数値は変動が激しいため、本文では断定せず「要確認」と明示します。判断・費用感は当社（Access移行支援を手がける弊社）の実務に基づく見解です。

4つの選択肢の位置づけ

まず選択肢全体を俯瞰します。どれも「SQL Serverエンジンを使う」か「SQL Server互換」ですが、管理の主体・接続経路・コスト構造がそれぞれ異なります。

SQL Serverバックエンドへの移行総論と、AccessフロントエンドとSQL Serverをリンクテーブル経由で接続する基本的な仕組みはこちらの記事で詳しく解説しています。ODBCドライバのバージョン選定とDSN設定の実務はODBCドライバ記事を参照してください。本記事はそれらと役割を分け、「クラウドマネージドDBの選択肢比較」に絞ります。

Azure SQL DatabaseとAccessの接続：Microsoftが公式サポートする経路

Azure SQL DatabaseはMicrosoftのPaaS型マネージドRDB（リレーショナルデータベースサービス）です。基盤OS・DBエンジンのパッチ適用・自動バックアップなど多くのデータベース管理機能をMicrosoftが担います。利用者が引き続き管理するのはデータ・アプリケーション・認証・ネットワーク設定・性能最適化・保持期間設定などです（What is the Azure SQL Database service? — Microsoft Learn）。

AccessとAzure SQL Databaseの接続は、MicrosoftのサポートページにODBC経由でリンクテーブルを作る手順が掲載されています（Link to or import data from an Azure SQL Server Database — Microsoft Support）。認証方式はSQL Server認証のほか、Microsoft Entra ID（旧Azure Active Directory）によるEntra統合認証やEntraパスワード認証も選べます。SQL Server認証はパスワードをリンクテーブルに平文保存するリスクがあると公式ドキュメントが警告しており、当社ではEntra ID認証が要件に合う場合はそちらを推奨します。なお、Azure SQL DatabaseではオンプレのWindows統合認証（Integrated Security=True）は使えません。WindowsアカウントでのSSOを使いたい場合はMicrosoft Entra統合認証（ActiveDirectoryIntegrated）として構成する必要があります。

ただし当社の実務経験で注意が必要だと感じる点が2つあります。

• Azureのファイアウォール設定。公開エンドポイントへ直接接続する構成では、クライアントPCの送信元グローバルIPをAzureポータルで許可する必要があります。Private Endpoint＋VPN/ExpressRouteを使う構成では別のアクセス制御になります。
• インターネット経由のレイテンシ。Accessのリンクテーブルはネットワーク遅延の影響を受けやすく、LAN内のSQL Serverと比べてフォームの応答が遅くなるケースがあります。データ量・クエリ設計・ネットワーク環境によるため一概には言えませんが、移行前にパフォーマンス検証を行うことを強く勧めます。

マネージドの利点として、Azure SQL Databaseは完全バックアップ・差分バックアップ・ログバックアップを自動で実施し、自動バックアップの保持期間内の任意時点へのポイントインタイムリストアに対応しています。高可用性はサービス側の設計に組み込まれており、ゾーン冗長を有効化することで可用性を高められます。料金・スペック・保持期間の詳細はMicrosoft公式ページで要確認です。

Amazon RDS for SQL ServerとGoogle Cloud SQLの位置づけ

Amazon RDS for SQL ServerはAWSのPaaS型マネージドSQL Serverです。エンドポイントは通常の「xxx.rds.amazonaws.com」形式で、SQL Serverクライアントから標準のTDSプロトコルで接続できます（Connecting to your Microsoft SQL Server DB instance — AWS Docs）。AccessからのODBC接続も技術的にはこれと同じ経路を利用しますが、ODBCドライバの選定やAWSセキュリティグループの設定など、Accessとの組み合わせは事前検証が必要です。

ただし、SSMA for Accessが明示する正式ターゲットはSQL Server・Azure SQL Database・Azure SQL Managed Instanceです。Amazon RDS for SQL Serverをターゲットとして製品名で指定する専用フローはSSMA公式では確認できていません（当社確認）。SQL Serverターゲットとして接続できる可能性はありますが、権限やサービス制約を含めて事前検証が必要です。実際の移行ではMicrosoftとAWS両方の設定が必要になるため、Azure SQL Databaseよりもセットアップ工数がかかる場合があります。

Google Cloud SQL for SQL ServerはGCPのPaaS型マネージドSQL Serverです。クライアントからの接続はパブリックIPや Private Service Connectなど複数の接続経路を選べますが、Accessからの接続はSQL Server標準のODBC経由になるため、接続方式やファイアウォール設定はGCPのCloud SQLドキュメントで確認が必要です。AzureやAWSと比べてAccessとの組み合わせで実績を公式に案内するドキュメントは少なく、GCPの設定知識が別途必要です。

Amazon RDSとGoogle Cloud SQL、どちらもマネージドの利点（バックアップ自動化・パッチ適用・高可用性オプション）はAzure SQLと同様に提供されています。コスト・SLA・スペック上限は各社の公式ページを直接確認してください。変動が激しく、ここでの数値断定は避けます。

Accessフロントエンドを残す場合のODBC接続とレイテンシの注意点

利用者のPCやオンプレミス環境からクラウドDBへ接続する場合は、通常、通信経路がインターネット・VPN・専用線のいずれかを経由します。これはLAN内のSQL Serverと構造的に異なり、レイテンシの影響が出やすい点に注意が必要です。一方、Accessフロントエンド自体をクラウド内の仮想デスクトップやVM上で動かし、同じクラウドのプライベートネットワーク（VNet/VPC）内でDBに接続する構成もあり、その場合はインターネット経由の遅延を避けやすくなります。

AccessのODBCリンクテーブルでは、クエリ設計によってテーブルをローカルに引き込む処理や行単位の更新が増えることがあり、LAN内では問題にならない遅延が、インターネット越しでは体感できる差になることがあります。Microsoftの移行ガイドも、リンクテーブル経由のクエリ設計がパフォーマンスに影響する旨を案内しています（Linking Access Applications — Microsoft Learn）。当社が実務で確認している対策は以下のとおりです。

• パススルークエリの活用。AccessがSQL文を変換せずクラウドDB側に直接送る仕組みで、サーバー側で処理を完結させるため通信回数を減らせます（ただしAccessのクエリデザイングリッドが使えなくなるトレードオフがあります）。
• クラウドDBのリージョンを利用者に近い場所に設定する。一般に地理的に近いリージョンは遅延低減が期待できますが、改善幅はネットワーク環境次第なので実測で確認してください。
• ローカルのAccessテーブルとクラウドのリンクテーブルを同一クエリで結合しない。混在クエリはパフォーマンス問題の主な原因になります（詳細はアップサイジング記事参照）。

リモートワーク環境でVPN越しにAccess共有ファイルを開く運用は別の問題を起こしやすいことはこちらで解説しています。クラウドDBへのODBC接続はVPN越しの共有accdbとは構造が異なりますが、ネットワーク遅延への配慮は共通です。

Accessフロントエンドを中長期的に使い続ける場合は、Accessのサポート期限（Access 2021は2026年10月13日終了予定）とのバランスも考慮する必要があります。バックエンドをクラウドDBに移しても、フロントエンドのAccess自体のサポート問題は別途残ります。

マネージドDBとオンプレ継続の比較：何を委託して何を持つか

クラウドのマネージドDBを選ぶ主な動機は「運用の委託」です。下表で整理します。

「社外にデータを出したくない」という要件がある業種や、クラウドへの接続自体が許可されない環境では、クラウドマネージドDBはそもそも選択肢に入りません。ただし「公開インターネット接続だけが禁止されている」場合は、VPN・専用線・Private Endpoint等を組み合わせることでクラウドDBを閉域網経由で使う構成も取れます。逆に、ITリソースが限られていてバックアップや冗長化の設計・運用が難しい場合は、マネージドDBに委託するメリットが大きいです。

どの選択肢でも、初期の移行費用（データ移行・ODBC設定・テスト）と継続的な運用費（クラウドの月額料金または社内インフラ保守）の両面で見積もりを取るのが確実です。費用感については移行費用の解説記事もあわせてご覧ください。

段階移行への組み込み方：まずSQL Serverバックエンドから

クラウドDBへのバックエンド移行は、Accessを段階的に置き換えていく第一歩として有効です。全面移行の前に「データだけクラウドに置き、フロントエンドはAccess継続」という段階を踏むことで、切り替えリスクを下げながらバックアップや同時接続の課題を先に改善できます。

具体的な移行パターンについてはハイブリッド段階移行の記事で整理しています。どのクラウドDBを選ぶかより先に「フロントエンドをいつまでAccessで使い続けるか」を決めることで、バックエンドの選択肢も絞られます。フロントエンドの置き換えまで含めた移行先の検討は移行先比較記事を参照してください。

現状のAccessがクラウドDB移行に向いた構成かどうか、まず確認したい場合は無料の解析可否チェックで現状を把握するところから始められます。ファイルの送信は不要です。

よくある質問

Q. AccessのフロントエンドをそのままにしてAzure SQL Databaseだけに移行できますか。

技術的には可能です。SSMAでテーブルとデータをAzure SQL Databaseに移行し、ODBC経由でリンクテーブルを張ることで、既存のフォームやレポートを引き続きAccessで使う構成を取れます。Microsoft公式のSSMAドキュメントとMicrosoftサポートのODBC接続ガイドの両方がこの構成を案内しています。ただし、ファイアウォール設定・認証方式・レイテンシの確認はセットで必要です。

Q. Azure SQL Database、Amazon RDS、Google Cloud SQLのどれが一番安いですか。

料金は構成（スペック・リージョン・冗長化・バックアップ保持期間・データ転送量など）によって大きく変わります。また各社が頻繁に価格を改定するため、ここでの断定は避けます。各社の料金計算ツールで同一スペックを比較するか、当社にご相談ください。Azureの場合、有効なSoftware Assurance付きの対象SQL Serverライセンスを持っている場合にAzure Hybrid Benefitを適用できる仕組みがあり、実質的なコストが変わることがあります（対象条件の詳細は要確認）。

Q. PostgreSQLへの移行はSQL Serverへの移行と何が違いますか。

SQL Server系のエンジンを使う選択肢（Azure SQL Database・Amazon RDS for SQL Server・Google Cloud SQL for SQL Server）は、Accessのデータ型との互換性が比較的高い点で共通しています。SSMA for Accessが明示する正式ターゲットはSQL Server・Azure SQL Database・Azure SQL Managed Instanceです。RDS for SQL ServerやCloud SQL for SQL Serverへのそのまま適用は事前検証が必要です。PostgreSQLはサーバーライセンスが無料でLinux対応など異なる強みを持ちますが、AccessフロントエンドをODBCで接続し続ける場合にはデータ型の差異への対処が追加で必要です。詳細はPostgreSQL移行記事で解説しています。

Q. クラウドDBに移すとAccess 2021のサポート終了問題は解決しますか。

解決しません。バックエンドのデータをクラウドDBに移しても、フロントエンドがAccessである以上、Accessのサポート期限問題は別途残ります。Access 2021は2026年10月13日にサポート終了予定で、2025年11月8日時点でESU（有償延長セキュリティ更新）の提供案内は確認できていません。クラウドDBへのバックエンド移行は「データの安全性や同時利用の改善」には有効ですが、フロントエンドの更新計画は別軸で立てる必要があります。