AccessをAzureで利用する方法｜構成・手順・費用の考え方

概要

この記事でわかること

• Azure SQL DatabaseとAVDの役割と構成の違い
• 既存Accessを残せる範囲と方式別の導入手順
• 接続・認証・性能を確認するポイント
• 費用・ライセンス・保守の整理と安全な本番切替

この記事の主な内容

1. AccessをAzureで利用する2つの方法と選び方
2. 方法1 手元のAccessからAzure SQL Databaseへ接続する
3. 方法2 Azure Virtual Desktop上でAccessを動かす
4. 接続と認証を設計しAzure移行後の遅さを防ぐ
5. 導入費用と運用費用を見積もる
6. 小さく検証して本番へ切り替える
7. AccessのAzure利用でよくある質問
8. まとめとAccessのAzure利用相談

想定読了時間：約20分

AccessをAzureで利用する2つの方法と選び方

AccessをAzureで利用する代表的な方法は、データの保存先をAzure SQL Databaseへ移す方法と、Azure Virtual Desktop上でAccessを動かす方法です。両者は併用できます。まず、利用者が操作する画面と、業務データを保存する場所を分けて考えましょう。

Accessの実行場所とデータ保存先を分ける

Accessでは、フォーム・帳票・VBAなどの操作や処理を担う部分を「フロントエンド」、共有データを保存する部分を「バックエンド」と呼びます。データだけをAzure SQL Databaseへ移し、フロントエンドは各利用者のPCに残す構成が可能です。[S1]

Azure SQL Databaseは、Microsoftがデータベース基盤を管理するクラウドサービスです。一方、Azure Virtual Desktop（以下、AVD）は、Azure上のWindowsデスクトップやアプリを遠隔利用するサービスです。AVDでは、AccessをAzure側のWindowsで実行します。[S3][S13]

AVDを選んでも、データの保存先が自動で決まるわけではありません。特に既存のACCDBを使い続ける場合は、ファイルの配置場所、同時利用、障害時の保全方法を別途設計します。Azure側のAccessから社内のDBへ毎回接続する構成では、回線の影響も残ります。

OneDriveやSharePointの同期フォルダへACCDBを置き、複数人が直接開く運用も避けましょう。ファイルの同期と、データベースの同時更新制御は異なります。共有データの管理方法を決めてから、必要な接続や配布を設計します。

自社の課題から構成を選ぶ

手元のWindows PCで今の画面を使い、共有データの管理を見直したい場合は、ローカルAccessとAzure SQL Databaseの組み合わせが候補です。ただし、社外回線を通る通信が増えるため、実際の検索・入力・集計の速度を確認する必要があります。

一方、利用環境をAzure側へ集約したい場合や、端末ごとのアプリ管理を減らしたい場合はAVDを検討します。AVDとAzure SQLを近いリージョンに配置すれば、AccessとDBの間の通信距離を抑える設計ができます。利用者からAVDまでの画面操作の快適さは、別に検証しましょう。

構成を絞る際は、次の点を先に整理すると比較しやすくなります。

• 利用者の端末、拠点、在宅勤務の有無
• 通常時と繁忙時の同時利用人数
• 画面や帳票を残したい範囲、外部システムとの連携
• 許容できる停止時間と、導入後の保守担当

Azure利用とWebアプリ化の違い

データをAzure SQL Databaseへ移しても、AccessのフォームがWeb画面に変わることはありません。また、AVD経由で操作する場合も、Azure上で動くWindowsアプリの画面を遠隔操作しています。ブラウザ向けの画面を新たに作るWebアプリ化とは、実行方式が異なります。

スマートフォンで使いやすい入力画面や、社外の取引先向け画面が必要なら、その部分をWebアプリやPower Appsなどで再構築する案も比較します。過去のAccess Webアプリの作成記事を、現在のMicrosoft 365で新規導入できる方式と混同しないようにしてください。[S11]

方法1 手元のAccessからAzure SQL Databaseへ接続する

この方法では、共有テーブルをAzure SQL Databaseへ移し、手元のAccessからODBCで接続します。ODBCは、アプリとデータベースを接続するための共通の仕組みです。導入は、現状調査、Azure側の準備、データ移行、再リンク、動作確認の順で進めます。

手順1 現行Accessと移行対象を調べる

まず、開発原本と現在のデータをバックアップし、調査にはコピーを使います。テーブルの件数だけでなく、主キー、データ型、リレーション、リンク先、クエリ、VBA、ExcelやCSVとの連携を一覧にします。業務データと一時作業用テーブルも区別しましょう。

主キーがないテーブルや、日付・数値を文字列で保存している列は、移行後の更新や集計に影響する可能性があります。また、フォームから参照する値やAccess独自の関数を含むクエリは、そのままSQL側へ移せるとは限りません。どこをAccess側に残すかを確認します。

手順2 Azure SQLと接続環境を準備する

Azureのサブスクリプションとリソースグループを用意し、SQLデータベースのリージョン、性能、ストレージ、バックアップ方針を決めます。Azure SQLの「論理サーバー」は、複数のDBを管理する単位です。AccessをインストールするWindows仮想マシンではありません。

接続方式は、公開エンドポイントを使うか、Private Endpointで非公開接続にするかを選びます。同時に、接続ユーザーの認証方法とDB内の権限を設計します。ネットワークで到達できることと、データを読み書きできることは別の条件です。

手順3 SSMAで評価してデータを移す

MicrosoftのSQL Server Migration Assistant for Access（SSMA）で、移行対象を評価できます。Azure SQL Databaseを移行先とするプロジェクトを作り、評価レポート、データ型の対応、変換結果を確認してから、テーブル定義とデータを反映します。[S2]

SSMAを実行するだけで、Accessのフォーム・レポート・VBAまでAzure SQL上で動くようになるわけではありません。移行できない処理や、動作の差が出る箇所はAccess側の修正も含めて対応します。本番データを移す前に、検証用DBで一連の工程を試してください。

手順4 ODBCを設定してリンクテーブルを切り替える

Accessを実行するPCに、対応するMicrosoft ODBC Driver for SQL Serverを導入します。32bit・64bitはWindowsの種類だけで判断せず、実行するAccessまたはRuntimeに合わせます。接続先のサーバー名、DB名、認証方式、暗号化設定をそろえて接続を確認します。

Accessの外部データ機能で、SQL側のテーブルをリンクテーブルとして利用します。既存リンクはリンクテーブルマネージャー等で管理し、フォームやクエリが参照する名前との整合も確認します。画面表示だけで終わらせず、登録・更新・削除ができるかまで試しましょう。

各利用者には、それぞれのフロントエンドを配布します。編集用の原本ACCDBと配布版を分け、必要に応じてACCDEやAccess Runtimeを利用します。ACCDEはデータへのアクセス権を管理する機能ではないため、DB側の権限設計も必要です。

手順5 業務の結果を移行前と照合する

検証では、件数が合っていることに加え、金額合計、キーの重複、NULL、日付、文字化けを確認します。検索、伝票入力、月次集計、帳票出力を同じ条件で実行し、結果と処理時間を比較します。データの照合と性能テストは、Microsoftの移行ガイドでも分けて扱われています。[S2]

なお、外部SQLへデータを移しても、Accessファイル自体の容量上限は残ります。ACCDBやMDBの上限は原則2GBで、システム領域なども含みます。大量データをローカルテーブルへ再取り込みする処理があれば、その処理による肥大化も確認してください。[S1]

方法2 Azure Virtual Desktop上でAccessを動かす

AVDを利用すると、Azure上のWindowsにAccessを導入し、利用者は遠隔接続して操作できます。既存画面を継続しやすい方法ですが、Windows環境、Accessの配布、データ保存先、利用者の接続をまとめて設計する必要があります。

手順1 利用者とライセンスを確認する

最初に、利用者の人数・勤務時間・同時利用数と、必要なWindows環境を確認します。AVDの利用権、AccessやMicrosoft 365 Appsの利用条件、Azureリソースの料金は分けて調べてください。契約中のMicrosoft 365があるだけで、すべての費用や利用条件を満たすとは限りません。[S4]

複数の利用者が同じ実行環境を使う構成では、Microsoft 365 Appsの共有コンピューターのライセンス認証など、配置方式に合った設定も確認します。Access Runtimeを選ぶ場合も、AVDやWindowsの利用権まで無料になるわけではありません。[S9]

手順2 Windows環境と利用者別の保存先を準備する

AVDでは、Accessを実行する仮想マシンを「セッションホスト」と呼び、その集合を「ホストプール」として管理します。業務の負荷と利用方法に合わせて構成を選び、利用者ごとの設定やファイルを保持するプロファイルの保存先も準備します。[S12]

続いて、Accessまたは対応するRuntime、ODBCドライバ、必要なフォント、外部部品を導入します。既存のActiveX・OCX・DLLがある場合は、バージョンとbit数も確認してください。各利用者が書き込む一時ファイルや作業テーブルの保存先を分けることも重要です。

手順3 Accessを配布して接続を割り当てる

フロントエンドは、利用者ごとの専用フォルダなどへ配布し、共有の一つのファイルを全員が直接実行する構成を避けます。デスクトップ全体を提供するか、プール型のホストでRemoteAppとしてAccessアプリを提供するかを選び、利用者に接続先を割り当てます。[S3][S12]

データ保存先にAzure SQLを選ぶ場合は、AVD側からDBへの接続を設定します。既存のACCDBを残す場合は、ファイル共有の権限、ロック、通信の安定性を検証します。AVDへ載せ替えただけで、ファイル容量やクエリ設計の課題まで解消されるわけではありません。

手順4 印刷やファイル連携まで試す

AVDで特に確認したいのは、Accessの外に出る処理です。例えば、CSVの保存先がAzure側になり、利用者のPCで見つけられない場合があります。プリンターやクリップボードの転送も、接続方式と組織のポリシーによって使える範囲が変わります。

• 帳票の改ページ、PDF出力、日本語フォント、利用者側の印刷
• CSV・Excelの読込と出力先、共有フォルダへのアクセス権
• Outlookや外部アプリを呼び出す処理、メール送信
• 接続切断後の再接続、ログオフ、次回起動時の設定の保持

社内と在宅の両方から、代表業務を一通り操作してください。画面が開くことに加え、利用者が出力ファイルを受け取れること、二重登録せず業務を完了できることまで確認すると、切替後の手戻りを減らせます。

接続と認証を設計しAzure移行後の遅さを防ぐ

Azure利用では、ネットワーク経路、名前解決、認証、DB権限を順に確認します。また、接続に成功しても、業務で必要な速度が出るとは限りません。通信の回数と取得データ量を含めて、処理の設計を見直します。

公開接続と非公開接続を選ぶ

公開エンドポイントを使う場合は、接続元のIPアドレスを必要な範囲に制限し、通信の暗号化と適切な認証を組み合わせます。在宅勤務などで送信元IPが変わる場合は、許可設定の更新方法や共通の接続経路を決めておきましょう。

Private Endpointは、Azureの仮想ネットワーク内にプライベートIPを持つ接続口を設ける仕組みです。社内や自宅のPCから使うには、VPNやExpressRouteなどによる接続経路と、DNSによる名前解決も必要です。接続口を作成するだけでは、社内から到達できるようにはなりません。[S5]

また、Private Endpointを追加しても、公開アクセスが自動で無効になるわけではありません。非公開経路の疎通を確認したうえで、公開ネットワークアクセスの設定を変更します。暗号化や認証は、非公開接続でも引き続き必要です。[S5]

接続トラブルは層ごとに切り分ける

接続できないときは、すぐにAccessの設定を変えるよりも、次の順で確認すると原因を絞りやすくなります。IP到達性とログイン可否、テーブルの更新可否を別々に扱うのがポイントです。

Private Endpoint経由でも、接続文字列には通常のサーバー名「<server>.database.windows.net」を使い、DNSで適切なIPへ解決します。IPアドレスを直接指定する方法とは区別してください。また、必要な通信ポートはProxy・Redirectなどの接続ポリシーによって変わります。[S5][S6]

Microsoft Entra IDは、組織の利用者やアプリのIDを管理するサービスです。ODBCドライバにはEntra IDを使う認証方式がありますが、Accessの起動・再リンク・再接続時に認証がどう動くかは利用環境で確認します。多要素認証の有無だけで、対応可否を一律に決めないようにしましょう。[S8]

利用者へ配る接続情報に、移行作業で使った管理者の資格情報を流用しないでください。業務に必要なテーブルや操作に権限を絞り、退職・異動時の変更方法も決めます。接続パスワードを保存する場合は、配布ファイルや設定の扱いまで含めて管理します。

通信往復と取得件数を減らす

Accessから遠隔DBへ何度も問い合わせる処理は、1回ごとの応答待ちが積み重なります。全件を読み込んでからAccess側で絞り込む処理や、VBAで1件ずつ更新する処理は、移行前に確認したい箇所です。Azure側の性能を上げるだけでは、改善しきれないことがあります。

まず、フォームを開く時点で対象期間や顧客を絞り、必要な列だけを取得するようにします。集計や一括更新は、SQL側で処理する案を検討してください。パススルークエリやビューを使う場合も、更新可能性や既存フォームとの関係を確かめたうえで適用します。

ここで見直すのはVBAの使用そのものではなく、処理の役割分担です。データの抽出・集計・一括更新と、画面制御・入力チェック・エラー処理を整理します。インデックスや実行計画も確認し、利用拠点と同時利用条件をそろえて改善効果を測りましょう。

今のAccessを残してAzureで使う構成を整理しませんか

既存Accessの画面・帳票・VBA・データ連携を確認し、Azure利用に向けた構成と改修範囲の整理をご相談いただけます。利用拠点、同時利用人数、困っている操作が分かる資料をお持ちいただくと、検討を進めやすくなります。

導入費用と運用費用を見積もる

費用は、移行・改修にかかる初期費用と、Azure・ライセンス・保守の継続費用に分けて見積もります。Azure SQLの料金だけ、あるいはAVDの仮想マシン料金だけでは、運用全体の費用を比較できません。

構成ごとに必要な項目をそろえる

同じAzure利用でも、ローカルAccessとAVDでは課金対象が異なります。見積書を比べる場合は、含まれている作業とリソースをそろえ、既存契約で利用できるものと新規契約が必要なものを区別しましょう。

Azure SQLとAVDを併用する場合は、両方のリソースを見積もります。一方、Azure SQLを使うために、必ずSQL Server用のWindows VMを別途立てるわけではありません。SQL ServerをVM上で運用する方式は別構成として比較します。

月額を左右する前提条件を記録する

Azure料金計算ツールでは、リージョン、サービスの種類、性能、容量、稼働時間などの条件を合わせて試算します。見積もりには確認日と通貨も残してください。料金や利用条件は変わるため、記事中の固定金額だけで予算を決めないことが大切です。[S10]

• 平常時と繁忙時の同時利用人数、利用時間帯
• 本番・検証環境の数と、それぞれの稼働時間
• DB容量、増加量、バックアップ保持と冗長化の要件
• 夜間停止の可否、無人処理の時刻、再開時に許容する待ち時間

自動停止などを使って費用を抑える場合は、業務の利用時間とバッチ処理に合うかを確認します。計算リソースを止めても、ストレージなどに料金が残る構成があります。停止時にどの費用が減るのかまで含めて試算しましょう。

初期費用だけで構成を決めない

画面を残せる構成でも、複雑なクエリや外部連携が多いと調査・改修が必要です。また、AVDでは端末側の管理を減らせても、Azure側のWindows更新やAccess配布の管理は残ります。社内で担当する作業と外部へ委託する作業を分け、継続して運用できるかを判断します。

小さく検証して本番へ切り替える

本番移行は、代表業務の検証で構成の妥当性を確認してから進めます。日常入力だけでなく、月末集計や帳票出力まで含めて合格条件を決め、移行と復旧の両方をリハーサルしておきましょう。

棚卸しから運用確認までを5段階で進める

1. 棚卸し：原本、データ、外部連携、利用者、現行の処理時間を記録します。
2. 代表業務の検証：検索・更新・集計・帳票で方式と性能を確かめます。
3. リハーサル：データ移行、配布、接続切替、照合、復旧を試します。
4. 本番切替：更新を停止し、最終移行と照合後に利用を再開します。
5. 運用確認：接続エラー、処理時間、利用料、バックアップと配布状態を確認します。

各段階の完了条件は、業務担当者とシステム担当者で共有します。「検索結果が同じ」「請求合計が一致する」「所定の時間内に帳票が出る」など、操作と結果で判定できる条件にすると、切替判断が曖昧になりません。

更新データを守って切り戻す

本番切替では、旧環境への入力を止める時刻、最終データ移行、照合担当、再開判定者を決めます。切替後も旧環境へ入力できる状態が残ると、新旧にデータが分かれます。旧環境を参照用にするなど、業務側の運用もそろえてください。

問題が起きた場合も、単純に古いAccessへ戻してはいけません。新環境で登録・更新したデータがある場合は、まず更新を止め、そのデータを保全します。旧環境へ反映する方法と照合ができてから切り戻す、または新環境を修復するかを判断します。

旧フロントエンドへ戻すことと、データベースを復元することも別です。新旧のAccessで対応するテーブル構造が異なる場合、古い配布版だけを戻しても動きません。配布版、接続先、DB構造の組み合わせを記録し、復旧用の手順に含めましょう。

Azure移行後の運用担当を決める

Azure SQL Databaseには自動バックアップがありますが、保持期間や復元の方法は運用要件に合わせて確認します。Accessの開発原本や配布版、外部ファイルまでDBのバックアップに含まれるわけではありません。保管先と世代管理を別に用意してください。[S7]

復元テストでは、データを戻せることに加え、復元先への接続切替、Accessの再リンク、業務再開まで確認します。AVDを使う場合は、セッションホストやプロファイルが使えなくなった場合の対応も必要です。担当分担の例を示します。

よくある質問（FAQ）

まとめとAccessのAzure利用相談

AccessのAzure利用は、画面を動かす場所とデータの保存先を分けると、構成を選びやすくなります。手元のAccessからAzure SQLへ接続する方法、AVD上でAccessを動かす方法、両者を組み合わせる方法を、業務・回線・費用・保守体制で比較しましょう。

最初に取り組むのは、原本・テーブル・VBA・外部連携の棚卸しと、代表業務での検証です。既存Accessの調査からSQL Server・Azure SQLへの移行、必要な改修、運用整理まで、状況に応じた進め方をご相談いただけます。

参考情報

[S1] Migrate an Access database to SQL Server

[S2] Access to Azure SQL Database migration guide

[S3] What is Azure Virtual Desktop

[S4] Licensing Azure Virtual Desktop

[S5] Azure Private Link

[S6] Connectivity architecture

[S7] Automated backups

[S8] Using Microsoft Entra ID with the ODBC Driver

[S9] Deploy Microsoft 365 Apps by using Remote Desktop Services

[S10] Pricing Calculator

[S11] Access Services in SharePoint Roadmap

[S12] Azure Virtual Desktop terminology

[S13] What is Azure SQL Database