概要
| この記事の結論 Access＋Azure SQL構成とは、Windows上のAccessで画面・帳票・VBAを動かし、業務データをAzure SQL Databaseに保存する構成です。ODBCのリンクテーブルなどで接続し、既存の操作を活かしながらデータの保存先をクラウドへ移せます。 ただし、画面や処理がそのまま動くかは検証が必要です。データを移すだけでWebアプリになったり、必ず処理が速くなったりするわけではありません。本記事では役割分担から接続・費用・運用まで整理し、自社に合う構成か判断するポイントを解説します。 |
この記事でわかること
- AccessとAzure SQL Databaseの役割分担
- 社内SQL ServerやWebアプリとの違い
- 既存機能を活かせる条件と、速度を左右する要因
- 接続経路・認証・権限の考え方
- 費用、バックアップ、導入前に確認する項目
この記事の主な内容
- Access＋Azure SQL構成の仕組み
- オンプレミスSQL ServerやWeb化との違い
- 導入で得られるメリットと性能の注意点
- 接続経路と認証をどう設計するか
- 費用と導入後の運用で確認すること
- 自社に向くかを判断する5つの確認項目
- よくある質問
想定読了時間：約15分～18分
1 Access＋Azure SQL構成の仕組み
Accessは画面と帳票を Azure SQL Databaseはデータを担当
この構成では、利用者が操作する画面側と、業務データを保存する側を分けます。画面側を「フロントエンド」、データ側を「バックエンド」と呼びます。Microsoftも、Accessのフロントエンドを残し、SQL Server系のデータベースへ接続する方法を案内しています。
利用者は、各Windows PCに置いたAccessファイルからフォームを開き、検索・入力・帳票出力を行います。Azure SQL Databaseには、顧客や受注などの共有データを保存します。Azure SQL Databaseは、Microsoftが基盤の更新などを管理するクラウドのデータベースサービスです。
| 対象 | 主な配置先 | 担当すること |
|---|---|---|
| フォーム・レポート・VBA | 利用者のWindows PC | 入力、表示、帳票、操作の制御 |
| 共有するテーブルとデータ | Azure SQL Database | データ保存、検索、更新、制約の管理 |
| リンクテーブル・接続設定 | Accessと利用者PC | 外部DBへの接続 |
| 作業用の一時データ | 処理ごとに設計 | ローカルに残すかDB側へ移すかを判断 |
例えば、本社と営業所が同じ受注データを扱う場合、それぞれのPCに画面用ファイルを配布し、共通のデータベースへ接続します。これは構成を説明するための例です。拠点を増やす際は、回線や利用者権限も一緒に準備します。
ODBCリンクテーブルとインポートの違い
ODBCは、Accessなどのアプリから外部データベースへ接続するための仕組みです。リンクテーブルを使うと、AccessからAzure SQL Database上のデータを参照し、更新可能な条件を満たす場合は追加・変更・削除も行えます。
一方、インポートは、その時点のデータをAccessへコピーする操作です。コピーした後の変更が、自動で元のデータベースへ反映されるわけではありません。複数拠点で同じ業務データを扱う場合は、この違いを理解して設計します。
なお、リンクしていても、他の利用者の変更がすべての画面に即座に表示されるとは限りません。表示の再取得や、同じレコードを複数人が変更した場合の競合処理は、アプリ側で確認する必要があります。
画面やVBAがWebアプリになるわけではない
データをAzureへ移した後も、フォームやVBAは基本的にWindows上のAccessで実行します。利用端末には、製品版Accessまたは対象アプリを動かせるAccess Runtimeなどの実行環境が必要です。
スマートフォンやMacのブラウザーから直接使う画面が必要な場合は、Webアプリなどのフロントエンドを別に設計します。先にデータを整理しておくことは将来の拡張に役立ちますが、画面の作り直しや権限設計は別の作業です。
2 オンプレミスSQL ServerやWeb化との違い
Azure上でSQL Server系のデータベースを使う方法には複数の選択肢があります。本記事の主対象は「Azure SQL Database」です。Azure上のWindowsサーバーにSQL Serverをインストールする構成とは、管理範囲が異なります。
Azure SQL DatabaseとManaged InstanceとAzure VMの区別
| 選択肢 | 主な管理単位と特徴 | 選定時の確認点 |
|---|---|---|
| Azure SQL Database | データベース中心のマネージドサービス。OSの保守はMicrosoftが担当 | 必要なSQL機能と料金・性能設定 |
| Azure SQL Managed Instance | インスタンス単位で提供。SQL Serverとの高い互換性を重視 | 既存機能への依存、ネットワーク、費用 |
| Azure VM上のSQL Server | 仮想マシン上でSQL Serverを運用 | OS・SQL Serverの保守とバックアップの運用 |
Managed Instanceは、複数のデータベースやインスタンス機能を利用する既存環境の移行で候補になります。ただし、SQL Serverとあらゆる条件で同じ動作になるわけではありません。Azure SQL Databaseとの機能差を確認して選びます。
例えば、定期処理をSQL Server Agentで動かしている場合、Azure SQL Databaseでは同じ機能をそのまま使えません。別の実行方法を設計するか、他の構成を検討します。Accessの保存先を移すだけなのか、既存サーバー上の処理全体を移すのかで判断が変わります。
社内SQL Serverと比べて変わる管理範囲と通信
社内設置のSQL ServerとAccessを組み合わせる場合も、画面とデータを分ける考え方は共通です。Azure SQL Databaseにすると、サーバー基盤の管理負担を減らせる一方、PCからクラウドまでの通信経路を考慮する必要があります。
| 比較項目 | 社内SQL Server＋Access | Azure SQL Database＋Access | Webアプリ |
|---|---|---|---|
| 主な画面の実行場所 | WindowsのAccess | WindowsのAccess | ブラウザー |
| データへの接続 | 主に社内LANなど | 設計したクラウド接続経路 | Webアプリ側で接続を設計 |
| 既存Access画面 | 活用を検討できる | 活用を検討できる | 原則として再構築 |
| 主な運用課題 | サーバー保守と端末配布 | 通信・DB設定・端末配布 | Web基盤とアプリの保守 |
ブラウザー利用が必要な場合の選択肢
社外の利用者にも画面を提供したい、端末へAccessを配布したくない、といった要件があるなら、WebアプリやPower Appsなども比較対象になります。画面、帳票、データ連携、ライセンスを含めて検討します。
Azure Virtual DesktopなどでWindows上のAccessを遠隔利用する方法もあります。この場合、利用者の手元から画面を操作できても、Access自体は遠隔のWindows環境で動いています。Webアプリとして作り直す方法とは区別してください。
3 導入で得られるメリットと性能の注意点
Access＋Azure SQL構成は、既存画面を活かしながら共有データの基盤を見直したい場合に向いています。ただし、資産を再利用できる範囲と、速度が改善するかどうかは個別に確認します。
既存画面を活かしながらデータ管理を分離できる
フォームや帳票を使い続けられれば、操作方法の変更や再教育の範囲を抑えられます。一方、Access独自の関数やデータ型、クエリ、VBAの更新処理には修正が必要な場合があります。見た目が同じでも、業務処理の結果まで確認してください。
特に、各レコードを識別する主キー、採番、日付、金額、Nullの扱いは確認しておきたい項目です。Nullは「値が入っていない状態」であり、ゼロや空文字とは異なります。移行前後で件数だけでなく、集計値や帳票の内容も照合します。
Accessファイルの容量上限は原則2GBです。共有データをAzure SQL Databaseへ移せば、そのデータをAccessファイル内へ保存し続ける必要はなくなります。ただし、ローカルの一時テーブルや取り込みデータでAccess側が再び大きくなることはあります。[2]
DBの運用負担を軽くできるがAccess保守は残る
Azure SQL Databaseでは、OSやデータベースエンジンの更新、自動バックアップなどの基盤機能をMicrosoftが提供します。そのため、自社でサーバー基盤を維持する作業を減らせます。
利用企業には、権限管理、性能の監視、費用確認、バックアップ設定の確認、復旧の判断が残ります。また、Accessのフォーム・VBAの改修、配布、端末環境の管理も必要です。クラウド移行後の担当範囲をあらかじめ決めておきましょう。
全件取得と繰り返し通信を見直して速度を確認する
クラウドへ移すと、通信の往復にかかる時間が処理速度へ影響します。DBの性能だけを上げても、少量のデータを何度も取りに行く処理では、待ち時間が大きく残る場合があります。
例えば、画面を開くたびに大量の受注データを取得し、PC側で当月分へ絞り込む処理は見直し候補です。実際にどこで絞り込まれているかを確認したうえで、必要なデータだけを返すクエリや、DB側のビューなどを検討します。
パススルークエリは、SQLを接続先へ送って実行するAccessの機能です。集計や一括処理の候補になりますが、結果を通常の更新用リンクテーブルと同じように編集できるとは限りません。検索・集計と入力・更新の用途を分けて設計します。
性能の判断には、検索画面、登録処理、月次帳票などの代表業務を使います。同じデータ量・検索条件・利用端末で時間を比較し、営業所など実際の回線でも試します。単独操作だけでなく、複数人の同時操作も確認することが大切です。
4 接続経路と認証をどう設計するか
接続の設計では、「どこから到達できるか」「誰として接続するか」「どのデータを操作できるか」を分けて考えます。これらはそれぞれ、ネットワーク経路、認証、データベース権限の問題です。
公開エンドポイントのIP制限とTLS接続
公開エンドポイントは、インターネット側から到達できる接続口です。Azure SQLのファイアウォールで接続元IPアドレスを制限し、TLSで通信を暗号化します。公開接続を選ぶことと、誰でもデータへアクセスできることは同義ではありません。
この方式では、拠点の外向きIPアドレスや在宅勤務時の接続元を管理します。接続元が頻繁に変わる場合は、許可設定の運用も検討事項です。また、必要なポートは接続ポリシーで異なるため、「1433番だけ開ければすべての構成で使える」とは限りません。
Private Endpointに必要なネットワーク経路とDNS
Private Endpointは、Azureの仮想ネットワーク内のプライベートIPアドレスを使ってサービスへ接続する仕組みです。社内PCから利用する場合は、VPNやExpressRouteなどの到達経路と、接続先名を正しく解決するDNSを設計します。
Private Endpointを作成しただけでは、公開接続は自動で無効になりません。非公開接続に限定する場合は、経路と名前解決を確認してから、パブリックネットワークアクセスを無効にする設定も必要です。
VPNの要否は、このような接続方式によって変わります。公開接続なら常に不適切、VPNがあれば無条件に安全、という判断はできません。企業の接続ポリシーと利用場所に合わせて選びます。
Entra IDやSQL認証と最小権限の設定
接続する利用者の確認には、Microsoft Entra IDやSQL認証などを使います。Entra IDはMicrosoftのID管理基盤です。ODBCドライバーには多要素認証に対応する対話型の認証方式もありますが、Access、ドライバー、組織の認証設定を組み合わせて確認します。
認証できることと、必要な業務操作ができることは別です。参照だけの利用者と更新担当者を分け、業務に必要な最小限のDB権限を付与します。管理者の資格情報を利用者全員で共用する設計は避けてください。
ODBCドライバーは、Accessの32bit／64bitに合うものを用意します。Windowsが64bitでも、Accessは32bitの場合があります。接続エラーを解消するために証明書の検証を恒久的に無効化するのではなく、接続先名、証明書の信頼、ドライバー設定を確認します。
5 費用と導入後の運用で確認すること
導入費用は、Azure SQL Databaseの料金だけでは決まりません。データ移行やAccess改修の初期費用と、DB・ネットワーク・端末・保守の継続費用を分けて見積もります。
DBとネットワークと端末を含めて総費用を確認する
| 費用の区分 | 主な内容 | 見積もりでそろえる条件 |
|---|---|---|
| 初期の調査・改修 | 現状調査、移行、画面・クエリ改修、試験 | 対象機能、データ量、停止可能時間 |
| DBの利用 | 処理性能、保存領域、バックアップなど | リージョン、性能、稼働、保持設定 |
| ネットワーク | VPN、Private Endpoint、転送など | 接続方式、拠点数、対象サービス |
| 利用端末・配布 | Access実行環境、ドライバー、配布管理 | 台数、ライセンス、更新方法 |
| 保守・運用 | 問い合わせ、監視、復旧試験、変更対応 | 担当範囲、対応時間、試験頻度 |
料金はサービスや契約条件で変わるため、一定の月額をすべての業務へ当てはめることはできません。公式料金情報を使い、必要な性能や保存量をそろえて比較します。検証用環境を別に持つ場合は、その費用も含めます。[8]
サーバーレスは、利用状況に応じて計算リソースを調整する選択肢です。自動停止に対応する構成で停止できた場合も、保存領域などの費用は残ります。また、接続が続く使い方や、停止からの再開待ちを許容できない業務では、期待した効果が得られない場合があります。
自動バックアップと業務復旧手順を分ける
自動バックアップがあっても、誤更新や障害から業務を再開する手順は必要です。「何時間まで止められるか」「どの時点までのデータを戻せればよいか」を決め、保持期間や冗長性が要件に合うか確認します。
例えば、ポイントインタイム復元では、過去の時点の状態を別のデータベースとして復元します。その後、復元結果を確認し、必要に応じてAccessの接続先を切り替える作業が発生します。バックアップの存在だけでなく、接続と業務操作まで試しておきましょう。
移行を切り戻す場合も、旧Accessファイルへ接続し直すだけでは不十分なことがあります。切替後に新しいDBへ登録したデータを保全し、旧環境へ戻す範囲と方法を決めます。誤って同じ取引を二重登録しないよう、照合方法も用意してください。
Access原本と配布版とドライバーを管理する
画面・VBAを修正するための原本ACCDBは、配布用ファイルと分けて保管します。ACCDEを配布する場合は、原本から再生成する運用にします。利用者ごとのフロントエンドを管理し、どの版を使っているか分かる状態にしておくと更新時の混乱を抑えられます。
端末ごとにAccessの版・bit数、ODBCドライバー、接続設定を記録します。Azure側のDBが正常でも、PCの設定や回線が原因で使えなくなることがあります。問い合わせ時には「起動できない」「認証できない」「特定処理だけ失敗する」を分けて確認します。
いまのAccessを活かしたクラウド化を検討している方へ
既存の画面・帳票・VBAをどこまで活かせるか、通信や運用にどのような変更が必要かを整理すると、移行範囲を判断しやすくなります。構成や改修範囲に迷う場合は、お気軽にご相談ください。
6 自社に向くかを判断する5つの確認項目
WindowsのAccessを使い続けながら共有データをクラウドへ集約したい場合は、この構成が候補になります。次の5項目を確認し、実際の業務で使えるかを小さく試してから判断します。
端末と既存機能と通信と権限と運用を棚卸しする
| 確認項目 | 確認すること | 判断につなげる問い |
|---|---|---|
| 利用端末 | Windows、Access環境、拠点、台数 | ブラウザーやスマホの専用画面が必要か |
| 既存機能 | フォーム、帳票、VBA、外部連携 | 原本があり、変更点を調査できるか |
| 通信と性能 | 回線、取得量、同時利用、処理時間 | 主要業務が許容時間内に終わるか |
| 認証と権限 | 利用者ID、MFA、DB権限、接続経路 | 誰が何を操作できるか管理できるか |
| 費用と復旧 | 月額、保守担当、停止許容、戻し方 | 継続運用と障害対応を担えるか |
現状調査から試験移行と業務検証へ進む
最初に、Accessの原本、データの保存先、主要機能、外部ファイルとの連携を調べます。そのうえで、試験用のデータを用意し、MicrosoftのSSMAなどで移行時の課題を確認します。SSMAはデータやスキーマの移行を支援するもので、画面やVBAを自動でWeb化するツールではありません。
試験では「接続できた」で終わらせず、次の操作と結果を確認します。
- 検索・追加・変更・削除が想定どおり動く
- 件数、金額、日付、帳票の内容が移行前と一致する
- CSVやExcelとの入出力が続けて使える
- 複数人の同時更新と通信切断時にデータを取り違えない
- Accessの再配布と、復旧後の接続を実行できる
本番切替前には、データ更新を止める時点、最終移行、照合、利用再開の担当を決めます。切替後に入力したデータをどう保全するかも含め、切り戻しの条件を文書にしておくと判断がぶれにくくなります。
Access継続か画面再構築かを要件に合わせて選ぶ
既存の帳票や入力画面が業務に合っているなら、Accessを残す価値があります。一方、スマートフォンでの入力や外部利用者への公開が中心なら、画面の再構築も検討します。利用目的に合わせて、継続する部分と変更する部分を選んでください。
Access＋Azure SQL構成の導入判断では、データの保存場所に加えて、画面の互換性、通信、権限、費用、復旧まで確認することが大切です。主要業務を試験環境で動かし、結果を確かめることが、必要な改修範囲を見極める第一歩になります
よくある質問（FAQ）
再利用できる場合がありますが、すべてを無改修で使えるとは限りません。データ型、主キー、クエリ、VBAの更新処理、帳票、外部連携を確認します。画面が開くことだけでなく、登録内容や集計結果の照合も必要です。
データを移すだけでは、Accessの画面はブラウザー用に変わりません。ブラウザーやスマートフォン向けの画面が必要なら別途開発を検討します。遠隔のWindows環境でAccessを動かす方法もありますが、Webアプリ化とは異なります。
すべての構成で必須ではありません。公開エンドポイントへ接続する方法と、Private EndpointへVPNなどを通じて接続する方法があります。どちらも認証・DB権限・暗号化が必要で、非公開接続では経路とDNSも設計します。
必ず速くなるとは限りません。通信の往復回数、取得するデータ量、クエリ、DBの処理性能に左右されます。主要機能を実際の回線とデータ量で測定し、必要に応じて処理を見直します。
必要な性能、稼働状況、保存量、ネットワーク構成、保守範囲で変わります。Azure SQL Database単体の料金に加え、接続、端末、配布、監視や復旧対応の費用も含めて見積もることが大切です。
AccessとAzure SQLの構成について相談する
現在のAccessにどのような機能があり、どの処理で困っているかを整理することで、データ移行だけで対応できる範囲と、改修が必要な範囲が見えてきます。利用人数・拠点・主要画面・帳票・データ量をまとめ、お気軽にご相談ください。
参考情報
[1] Azure SQLへのリンクとインポート
https://support.microsoft.com/ja-jp/access/link-to-or-import-data-from-an-azure-sql-server-database
[2] Migrate an Access database to SQL Server
https://support.microsoft.com/en-us/access/migrate-an-access-database-to-sql-server
[3] Access to Azure SQL Database Migration guide
https://learn.microsoft.com/en-us/azure/azure-sql/migration-guides/database/access-to-sql-database-guide?view=azuresql
[4] SQL DatabaseとManaged Instanceの機能比較
https://learn.microsoft.com/ja-jp/azure/azure-sql/database/features-comparison?view=azuresql
[5] Azure Private Link for Azure SQL Database
https://learn.microsoft.com/en-us/azure/azure-sql/database/private-endpoint-overview?view=azuresql
[6] Using Microsoft Entra ID with the ODBC Driver
https://learn.microsoft.com/en-us/sql/connect/odbc/using-azure-active-directory?view=sql-server-ver17
[7] Automatic backups Azure SQL Database
https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview?view=azuresql
[8] Azure SQL Database Single Database 料金
https://azure.microsoft.com/ja-jp/pricing/details/azure-sql-database/single
[9] Serverless compute tier Azure SQL Database
https://learn.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview?view=azuresql
[10] Connectivity architecture Azure SQL Database
https://learn.microsoft.com/en-us/azure/azure-sql/database/connectivity-architecture?view=azuresql
[11] What is Azure SQL Database
https://learn.microsoft.com/en-us/azure/azure-sql/database/sql-database-paas-overview?view=azuresql
[12] Restore a database from a backup
https://learn.microsoft.com/en-us/azure/azure-sql/database/recovery-using-backups?view=azuresql
[13] ODBC Driver System requirements and installation
https://learn.microsoft.com/en-us/sql/connect/odbc/windows/system-requirements-installation-and-driver-files?view=sql-server-ver17