Accessのデータを活かしフロントだけWeb化する構成

結論：データを残したままフロントを刷新するのは、コストと操作変更を両立させやすい構成だ

Accessの移行を検討するとき、「データを捨てず、画面だけ変えたい」という要望は珍しくありません。これは、テーブルとデータをSQL Serverなどのサーバー型DBへ移した上で、入力・照会の操作画面（フロントエンド）だけをWebアプリやローコードツールで作り直す構成です。当社では「フロント刷新型」と呼んでいます。

この構成が向くのは、「Accessのデータは正しい。ただ画面が古くて複数人で使いにくい、または社外からアクセスできない」という状況です。全機能をスクラッチでWeb化するより工数が少ない傾向があり、リスクを区切りながら段階的に進めやすいのが特徴です（当社実務基準）。一方で、Accessのフォームに絡んだVBAロジックが多いほど、「画面だけ変える」つもりが「ロジックの再実装」に変わりやすいという落とし穴もあります。

この記事はAccess全面Web化（スクラッチ開発）や段階移行全般とは軸が異なります。「データは活かし、画面だけWebにする」という構成の設計判断と実務的な注意点に絞って解説します。

フロント刷新型の基本構成

フロント刷新型の出発点は、Accessのデータ（テーブル）をSQL ServerやPostgreSQLといったサーバー型DBへ移すことです。この移行が先に完了している、あるいはリンクテーブル経由でSQL Serverにすでに接続している状態を前提として、フロントエンドを別のWebアプリに差し替えます。

Microsoftの公式移行ガイドでは、SQL Serverをバックエンドとし、Accessフロントエンドをリンクテーブル経由で継続利用できる2層構成を案内しています（Migrate an Access database to SQL Server — Microsoft Support）。フロント刷新型はこの2層構成の「フロントをWebアプリに差し替える」ステップを加えたものです。

Webフロントのオプション：ローコードと自社開発

SQL Serverにデータが移った後、画面側のWebアプリには大きく2つの方向があります。Microsoft 365環境がある企業では、Power Appsが候補になりやすいと当社では見ています（当社実務基準）。そうでない場合はReact / Vue.jsなどを使った自社開発やSaaS型ローコードが選択肢になります。

Power AppsとSQL Serverの接続については、MicrosoftがSQL Server接続のコネクタとOn-premises Data Gatewayを公式にサポートしています（Connect to SQL Server from Power Apps — Microsoft Learn）。Power Apps側でフィルター・集計などの操作をSQL Server側に処理を委ねる「委任（delegation）」の仕組みがあり、大量データを扱う場合は委任可能な関数かどうかを事前に確認する必要があります。

VBAロジックをどう引き継ぐか

フロント刷新型で最も見積もりが狂いやすいのが、VBAロジックの扱いです。「画面を変えるだけ」と思っていたのに、Accessのフォームイベントにビジネスロジックが埋め込まれているケースが当社の支援経験では多い印象です（当社実務基準）。

VBAのロジックには大きく2種類あります。一つは入力値の検証・計算など画面操作に紐付いたもの、もう一つは集計や連携処理など業務フローに紐付いたもの。前者はWebフロントの画面ロジックとして再実装できますが、後者は「どこに置くか」を改めて設計する必要があります。SQL Serverのストアドプロシージャ（DBサーバー上に保存する処理）として移すか、APIサーバーとして分離するか、ローコードの自動化（Power Automateなど）に置き換えるか、プロジェクトの規模と体制によって判断が変わります。

VBAコードに仕様書がなく、コメントもほとんどない状態は珍しくありません。フロント刷新型であっても、まず現行のVBAの処理を棚卸しする作業は省けません。この棚卸しを怠ると、後から「あの計算ロジックはどこに実装するか」が次々と出てきて、工数が膨らみます。

帳票（Accessレポート）については、フロント刷新の対象に含めるか否かを最初に決めておくことをお勧めします。印刷帳票の再現は工数がかかりやすいため、一度Accessレポートを使い続けながらデータだけSQL Serverから取得する形で当面続け、帳票の刷新は次のフェーズに回すという判断も現実的です（当社実務基準）。

向くケース・向かないケース

「向かないケース」に該当する要素が複数ある場合、フロント刷新型よりも全面的なスクラッチWeb化を最初から視野に入れた方が最終的なコストが下がることもあります。移行先の選択肢を横断的に比較したい場合はAccessの移行先比較の記事が参考になります。

費用の考え方

フロント刷新型の費用は、主にWebフロントの開発規模とVBAロジックの複雑さで決まります。以下はあくまで参考値で、実際の費用は現状調査を経た個別見積になります（当社実務基準）。

全面スクラッチWeb化（Access移行の費用相場参照）と比べると、既存のデータ構造を活かせる分、DB設計・データ移行の工数は抑えられる傾向があります。一方、Webフロントの実装コストはスクラッチ開発と基本的に同じです。「フロントだけ変える」からといって費用が大幅に下がるわけではない点は現実として押さえておく必要があります。

現状のAccessがフロント刷新型に向くかどうか不明な場合は、無料の解析可否チェックで状況を確認してみてください。VBAの複雑さやテーブル構造を元に、適した移行パターンをお伝えできます。

よくある質問

Q. Accessのフォームをそのまま残しつつ、一部の画面だけWebに変えられますか。

はい、可能です。データをSQL Serverに移した後、一部の業務画面だけWebアプリで対応し、残りの業務は引き続きAccessフロントエンド（リンクテーブル接続）で使い続ける構成が取れます。ただしAccessのサポート期限（Access 2021は2026年10月13日に終了予定）を踏まえると、最終的にAccessフロントエンドを廃止するまでの計画をあわせて立てておくことをお勧めします。

Q. Power AppsはSQL Serverのデータを直接扱えますか。

はい、Power AppsにはSQL Server専用のコネクタが用意されており、テーブルの読み書き・フィルター・集計をSQL Server側で処理する委任機能もあります（Connect to SQL Server from Power Apps — Microsoft Learn）。オンプレミスのSQL ServerにはOn-premises Data Gatewayを経由して接続します。ただしこのコネクタはPremiumコネクタ扱いのため、Power Apps Premiumやper app、pay-as-you-goなど、Premium機能を使えるライセンス設定が必要です。詳細はMicrosoftのライセンス資料で事前に確認してください。

Q. VBAのロジックはどこに移せばよいですか。

処理の種類によって移し先が変わります。入力検証や計算など画面操作に紐付いたものはWebフロントのロジックとして実装します。集計・バッチ処理など業務フローに紐付いたものはSQL Serverのストアドプロシージャ、APIサーバーサイドのプログラム（Python / Node.jsなど）、またはPower Automateでの自動化が選択肢になります。どれが合うかは業務の性質と開発チームの技術構成による部分が大きく、一般的な正解はありません（当社実務基準）。

Q. Accessのレポート（帳票）はフロント刷新のタイミングで同時に対応しないといけませんか。

必須ではありません。フロント刷新型の現場では、帳票だけは当面Accessレポートを使い続け、データをSQL Serverから引いてくる形で継続するという判断もよく見られます（当社実務基準）。帳票の刷新は工数がかかるため、フロントの刷新と時期をずらして段階的に進める方が、現場への影響を小さくしやすいです。ただし帳票刷新も最終的には必要になるため、計画上は外さないようにしてください。