AccessをWebシステム化する｜スクラッチ開発移行の費用と進め方

結論：Web化は自由度が高い分、準備に手を抜くと高くつく

AccessをWebシステムに移す選択肢は、kintoneやPower Appsのようなローコードツールでは再現できない帳票や業務ロジックを持つ場合に有効です。フロントエンドにWebブラウザ、バックエンドにPostgreSQLやSQL ServerなどのDBサーバーを置く構成は、Accessの1ファイル2GB上限を回避でき、当社の支援実務では、共有ファイル構成で問題になりがちな同時利用時の性能低下や破損リスクも抑えやすくなります。社外公開や外部システムとの連携にも対応できます。

ただし費用と期間は移行先の中で一般に大きくなりやすく（当社実務基準）、現状のAccessを正確に把握しないまま着手すると途中で仕様変更が膨らむリスクがあります。スクラッチ（ゼロからの個別開発）の場合、費用は要件の複雑さと規模に応じた個別見積になり、数百万円台から始まることが多い。「とにかくWeb化すれば解決する」という発想より、「Accessの何を引き継いで、何を変えるか」を先に決めることが成否を分けます（当社実務基準）。

Accessの何がWebシステムに移るのか

Accessはテーブル・クエリ・フォーム（操作画面）・レポート（帳票）・マクロ・VBAモジュール（ビジネスロジック）といった複数の要素を一つのデータベースファイルで管理できます。Webシステム化ではこれらをそれぞれ別の場所に分散させます。

移行で時間を食うのは大抵、帳票とVBAロジックです。帳票はレイアウトの位置合わせや合計行の挙動まで再現が必要になることがあり、当社が支援してきた案件ではVBAの仕様書が残っていないケースが大半でした（当社実務基準）。VBAの処理をすべてコードから読み解いた上で要件定義に落とし直す工程が、移行期間の30〜40%を占めることは珍しくありません（当社実務基準）。

Web化が向くケース・向かないケース

Web化は万能ではなく、要件によっては費用対効果が合わないこともあります。次の基準で判断してください。

移行先の選択肢をkintone・Power Apps・FileMakerも含めて横断的に比べたい場合は、Accessの移行先を比較した記事が参考になります。

費用と期間の目安

スクラッチのWebシステム開発は、Accessの規模と要件によって費用が大きく変わります。以下はあくまで参考の目安で、実際の費用は現状調査と要件整理を経た個別見積になります（Access移行の費用相場に詳しい考え方を書いています）。

費用を大きく左右するのは「現状の把握にどれだけ手間がかかるか」です。仕様書が残っていないAccessでも、構造と動作から要件を引き出す作業は可能ですが、その分の工数は必ずかかります。また、全機能を一度に移す一括移行より、利用頻度の高い業務から段階的に移す方が、リスクを抑えやすい傾向があります（当社実務基準）。

移行プロジェクトの進め方（工程と期間の内訳）はAccess移行プロジェクトの7ステップで整理しています。

AccessのVBAロジックと帳票をどう引き継ぐか

Web化でつまずく筆頭が、VBAとレポートの引き継ぎです。当社が支援してきた案件では、仕様書や担当者が不在の状態で引き継ぎを求められるケースが多く、まず解析から始める必要があります（当社実務基準）。

VBAについては、処理の流れをコードから読み解くだけでなく、「正常ケース以外の例外処理がどこに埋まっているか」を探す作業が特に時間がかかります。VBAにコメントがなく、処理が複数モジュールにまたがっている場合、1本の業務フローを追うだけで数日を費やすことがあります。Webシステム側でこれを再現する際には、言語（PythonやC#など）の選択だけでなく、「Accessでは暗黙的に動いていた挙動を明示的に書き直す」必要があり、ここで仕様の抜け漏れが出やすくなります（当社実務基準）。

帳票については、Accessのレポートは既定でTwip単位（1ポイント=20Twip）が使われる箇所が多く（座標系はポイントやピクセル等に変更も可能）、細かいレイアウトに依存した帳票ほど、PDFや印刷用帳票への変換時に見た目の再現で想定外の時間がかかることがあります（当社実務基準）。請求書・納品書・検査表など、行数が可変で改ページ位置が変わる帳票ほど難度が上がります。帳票専用ライブラリ（JasperReportsやFastReportなど）を使う方法もありますが、それ自体の設計・テストに相応の工数が必要です。

こうした難しさがあるため、まず現状のAccessを解析して「何が存在するか」を可視化することが、Web化の成功に直結します。現状が把握できていない状態で開発会社に見積を取っても、後から仕様追加・変更が発生して費用が膨らむリスクがあります。現状解析の段階から支援が必要な場合は、無料の解析可否チェックからお気軽にご確認ください。

技術構成の一般的なパターン

Accessから移行するWebシステムの技術構成は開発会社によって異なりますが、よく選ばれる組み合わせを参考として紹介します（特定の技術を推奨するものではありません）。

• データベース: PostgreSQL（オープンソース）またはSQL Server（Microsoftのライセンス）が、当社の支援実務ではAccessからの移行先として採用例が多い（当社実務基準）。AccessのJet/ACE SQLとは方言が異なるため、クエリの書き直しが必要になる
• サーバーサイド: Python（Django / FastAPI）やNode.js、C#（ASP.NET Core）などが使われる。VBAのビジネスロジックをここに移植する
• フロントエンド: React、Vue.js、またはサーバーサイドレンダリング系のフレームワーク。Accessフォームのように複雑な入力規則や連動項目がある場合、この実装の比重が高くなる
• API接続: フロントエンドとバックエンドの間をREST API（HTTPで呼び出すデータのやり取りの仕組み）で接続する構成が一般的
• 帳票: ブラウザ印刷（CSS）で対応できる場合はコストが低く済むが、帳票が複雑な場合は専用のPDFエンジンを別途組み込む

どの技術を選ぶかは、開発チームの得意分野や既存のインフラ環境によって変わります。発注前に「移行後の保守は誰がやるか」まで見据えて技術選定に関わることを、当社は移行支援の立場からお勧めしています（当社実務基準）。

よくある質問

Q. AccessをWebシステムに移すと、操作感はどう変わりますか。

Webブラウザ上のUIに変わるため、Accessのフォームとは見た目も操作も変わります。「同じ画面デザインに」という要件は工数を大きく増やすため、業務フローは引き継ぎつつUIは使いやすく作り直すアプローチが現実的です。操作の変更をできるだけ小さくしたい場合は、フォーム・画面はAccessに残しDBだけSQL Serverに移す段階移行（アップサイジング）を先に行うという考え方もあります。詳しくはAccessのDBをSQL Serverに移す構成の記事をご覧ください。

Q. スクラッチ開発とローコード開発、費用はどちらが安いですか。

初期費用はローコード（kintoneやPower Apps）が低く、スクラッチは高くなる傾向があります。ただし月額のランニングコストはローコードで継続的に発生するため、長期利用ではトータルコストが逆転するケースもあります（当社実務基準）。また、ローコードツールの制約に合わない帳票や複雑なロジックがある場合、カスタマイズや外部連携の費用が積み上がって、スクラッチと大差なくなることもあります。どちらが安いかは要件と使用期間次第です。

Q. 仕様書のないAccessからWeb化はできますか。

できます。Accessファイルが解析できる状態であれば、テーブル構造・クエリ・VBAコード・フォームの構成から現状を把握できます。当社では設計情報とふるまいの解析を行った後、Web化の要件定義に必要な情報を整理する支援をしています。開発そのものは開発会社への発注になりますが、「何を移すか」の整理を先に済ませることで、開発会社への見積依頼が具体的になります。

Q. Access移行に失敗しないためには何が大事ですか。

当社の移行支援経験から見ると、繰り返されやすいパターンは現行仕様の把握不足・帳票の後回し・一括移行による現場の混乱です（当社実務基準）。いずれも「現状を正確に知る」と「段階的に進める」で回避しやすくなります。典型的な失敗パターンはAccess移行が失敗する5つのパターンにまとめています。