Accessの社内データベース移行ガイド — 5つの移行先と費用目安

Microsoft Accessで作った顧客台帳・受注管理・在庫管理などの社内データベースは、作った担当者が退職したり、Officeの更新で動かなくなったり、リモートワークで共有が不安定になったりした時が移行を考えるタイミングである。移行先は大きく5つ（Accessの延命、kintoneなどのノーコード、Power Apps、パッケージSaaS、Webシステムの再構築）に分かれ、費用の目安は小規模なら数十万円から、業務全体を作り直す中規模で150万〜500万円程度、他システムとの連携がある大規模では500万円以上になることが多い。

この記事では、IT担当者がいない会社の経営者や総務担当者に向けて、移行を検討すべきサイン、5つの移行先の比較、費用の目安、進め方、失敗しがちなポイントを順に整理する。費用はあくまで一般的な市場の目安であり、データ量、画面数、連携先、要件の詰め方によって大きく変わる点に注意してほしい。

Accessは手軽に業務システムを作れる反面、作った人にしか中身がわからない状態になりやすい。次の項目に複数当てはまるなら、移行の検討を始める目安になる。

- 作った担当者が退職した、または異動して、誰も中身を説明できない
- 画面やレポートの修正を頼める人が社内にも外部にもいない
- Officeのバージョンアップや64bit版への切り替えで、フォームやマクロが動かなくなった
- 複数人が同時に使うと遅い、ロックされる、「データベースが破損しました」と表示される
- 在宅勤務や外出先から使えず、VPNや遠隔操作で無理に回している
- ファイル共有フォルダー上の1ファイルに全員がつないでいて、破損したら全データを失う不安がある
- バックアップが手動、または取っているかどうか誰も把握していない
- データがExcelにエクスポートされ、手作業で加工されて別の台帳が増えている
- 取引先や会計ソフト、ECなど他システムとの連携を手作業のコピーで済ませている
- 起動に時間がかかる、ファイルサイズが大きくなりすぎて限界が近い

特に「担当者の退職」と「共有ファイルの破損リスク」は、起きてから対処すると業務が止まる。動いているうちに計画的に移すほうが、費用も混乱も小さく済む。属人化そのものの問題はシステムの属人化を解消するにはでも整理している。

移行先に絶対の正解はなく、利用人数、画面の複雑さ、帳票の多さ、他システム連携、将来の変更頻度で向き不向きが決まる。費用は一般的な市場の目安であり、規模や要件で上下する。

実際には、1つに絞らず組み合わせる例も多い。たとえば「顧客台帳はkintone、請求は会計SaaS、特殊な見積計算だけ小さなWebアプリ」といった形である。

データを格納する部分（テーブル）だけをSQL ServerやAzure SQLなどのデータベースに移し、画面とレポートはAccessのまま使い続ける方法である。ファイル共有による破損や同時利用の遅さはかなり改善される。一方で、Access自体の保守担当者がいない問題や、Officeのバージョン更新のたびに動作確認が必要になる点は残る。「数年の時間を稼ぐ手段」と割り切るのが現実的で、その間に本格的な移行先を検討する使い方が向く。

顧客台帳、案件管理、問い合わせ管理のような「表を中心にした業務」は、kintoneなどのノーコード製品に置き換えやすい。画面は現場が自分で調整でき、リモートワークにも対応する。ただし、細かな計算ロジックや凝った帳票、数十万件を超えるデータには限界がある。カスタマイズが増えすぎて保守が難しくなる例もあるため、kintoneのカスタマイズの限界を事前に確認しておきたい。製品選びの全体像はノーコード・ローコード導入ガイドにまとめている。

Microsoft 365を既に契約している会社では、Power Appsで業務アプリを作り、データをDataverseやSharePointリストに置く方法がある。Accessからの乗り換え先として名前が挙がることが多く、Microsoft製品同士で認証や権限をそろえやすい。ただし、SharePointリストには扱えるデータ量や機能に制約があり、Dataverseやプレミアム機能は追加ライセンスが必要になる場合がある。最新の仕様と価格は、Microsoftまたは販売パートナーに確認してほしい。

販売管理、在庫管理、顧客管理、受注管理には、既製のSaaSが数多くある。自社で作り込むより初期費用が安く、法改正や機能追加が自動で反映されるのが利点である。一方で、Accessで積み上げた独自の運用ルールや帳票をそのまま再現できるとは限らない。「業務をパッケージに合わせて変える」覚悟が必要で、現場の運用変更にかかる負担も含めて判断する。

独自の計算や業務ルールが会社の強みになっている場合や、他システムとの連携が多い場合は、Webシステムとして作り直す選択肢がある。ブラウザーから使えるのでリモートワークや多拠点に強く、権限管理や操作履歴も設計しやすい。反面、費用は最も大きくなりやすく、要件定義の質と発注先選びが成否を分ける。過去の発注先に不満がある場合や、保守を引き継いでくれる先を探す場合は開発会社の乗り換えガイドも参考になる。

下表は、Accessの規模別に移行にかかる一般的な市場の目安である。同じテーブル数でも、VBAの量、帳票の数、連携先、データの汚れ具合で大きく変わる。複数社から、前提条件をそろえて見積もりを取って比較するのが基本になる。

見積もりを見る際は、本体の開発費だけでなく、データ移行、旧システムの調査、テスト、操作説明、保守費用が含まれているかを確認したい。上の目安には、月額ライセンスや保守費は含めていない。一般的な開発費の考え方はシステム開発の費用と相場にもまとめているので、あわせて参照してほしい。

- ステップ1：現状の棚卸し（テーブル・クエリ・フォーム・レポート・VBAマクロ・利用者を洗い出す）
- ステップ2：データ品質の確認とクレンジング（重複・表記ゆれ・欠損を整理する）
- ステップ3：移行先の選定（5つの選択肢から、要件と予算で絞り込む）
- ステップ4：並行稼働（新旧を同時に動かして結果を突き合わせる）
- ステップ5：切り替えと旧データベースの読み取り専用保管

ステップ1の棚卸しでは、Accessの中にある部品を一覧にする。テーブルの数と項目、クエリの数、フォームとレポートの数、VBAやマクロのコード量、実際に使っている人と使う頻度を表にまとめる。使われていない画面やクエリも多く見つかるため、移行対象を絞る良い機会になる。作った担当者が不在の場合でも、外部の専門家に調査を依頼すれば、中身を読み解いて仕様書に起こせることが多い。

ステップ2のデータ品質確認は軽視されがちだが重要である。顧客名の表記ゆれ（株式会社の位置、全角・半角）、重複した取引先、必須項目の空欄、日付が文字列で入っているケースなどは、移行先にそのまま持ち込むと不具合の原因になる。移行前にルールを決めて整理する。

ステップ3の選定は、棚卸しの結果をもとに、前述の5つの比較表へ当てはめて行う。ステップ4の並行稼働では、一定期間、新旧どちらにも入力するか、旧データベースを参照専用にして新システムで運用し、請求額や在庫数などの結果が一致するかを確認する。ステップ5では、切り替え後も旧データベースを読み取り専用で保管する。過去の取引を調べる場面や、移行漏れが後から見つかった場面で役に立つ。

- VBAに隠れた業務ロジック：画面の裏で自動計算や自動採番、ボタン押下時の更新処理が動いており、仕様書に残っていない
- Excelとの連携：Accessからエクスポートした表を、現場がExcelで加工して使っている流れが見落とされる
- 帳票の再現：請求書や納品書のレイアウトが微妙に違うだけで、取引先から指摘される
- 文字コードと日付型：文字化け、全角・半角の混在、日付が文字列、和暦、空の日付の扱いなどで移行時にエラーが出る
- 移行中のデータ二重入力：切り替え期間中に新旧両方へ入力する負担が現場に集中し、入力漏れや不一致が起きる
- 棚卸しの省略：使っていない機能まで全部作り直し、費用と期間が膨らむ
- 権限と運用ルールの未整備：誰がどこまで見て変更できるかを決めずに公開してしまう

とくにVBAの隠れロジックとExcel連携は、現場の人にとって当たり前になっているために、ヒアリングで出てこないことが多い。実際の操作を画面で見せてもらいながら棚卸しすると見つけやすい。Excelで管理している業務を仕組み化する考え方はExcelからシステムへのIT化ガイドで解説している。