Accessで作った業務システムの限界と移行判断

Accessの業務システムは、同時利用・データ量・担当者の退職・OSやOfficeのバージョンアップという4つの壁で限界を迎えます。放置すればするほど移行コストは上がるため、限界のサインが2つ以上重なった時点で本格的な移行判断に入るべきです。

「10年前に総務の担当者が作ったAccessの受発注管理、いまも現役で動いている」——中小企業の情シス担当や経営者から、こうした相談を受ける機会が増えています。当時は最適な選択でした。ExcelよりはるかにDB的な管理ができ、社内の誰かが少し勉強すれば作れて、外注コストもかからない。ただし年月が経つほど、Access特有の技術的な限界と、作った人がいなくなることの組織的なリスクが同時に重くのしかかってきます。本記事では、受託開発の立場からAccessシステムの限界の正体と、移行を判断するための具体的な基準を整理します。

Accessで作った業務システムに起きる4つの限界

Accessの限界は「同時利用」「データ量」「属人化」「OS/Officeのバージョンアップ」の4つに集約され、いずれも運用年数が伸びるほど顕在化します。

第1の限界は同時利用への弱さです。Access（Jet/ACEエンジン）は仕様上255接続まで対応するとうたわれていますが、これは理論上の上限にすぎません。実際にはファイル共有型のデータベースであるため、複数人が同時に同じテーブルを更新するとレコードロックの競合が発生しやすく、利用者が増えるほど「開くのに時間がかかる」「入力中にフリーズする」といった不満が積み重なります。何人から劣化が始まるかは回線速度・端末・テーブル設計次第で変わるため断定はできませんが、拠点をまたいだ同時アクセスや利用者数が二桁に乗ってきた段階で、体感の重さを訴える声が増えるのは一般的に知られたパターンです。

第2の限界はデータ量の上限です。.mdb/.accdb形式のデータベースファイルには1ファイルあたり2GBという明確な技術仕様上の上限があります。これはテーブルのデータだけでなく、インデックスや一時オブジェクトも含めたサイズなので、実質的に使える容量はさらに小さくなります。運用年数が長く、日々の取引データや添付ファイルを蓄積し続けているシステムほど、この上限に近づくスピードが速くなります。

第3の限界は属人化です。多くのAccessシステムは、情シス専任ではない担当者が独学のVBAとマクロで組み上げています。作った本人が在籍している間は「ちょっとした不具合ならその場で直せる」状態が保たれますが、異動や退職でその人がいなくなった瞬間、コードはコメントもドキュメントもないブラックボックスになります。次に何か直したいと思っても、誰も中身を読める人がいない、という状態です。

第4の限界はOS・Officeのバージョンアップへの追従です。Windowsの更新やOfficeのバージョン変更、32bit/64bit環境の混在によって、ADO/DAOの参照設定が壊れたり、特定のマクロが動かなくなったりする事例は現場でよく見られます。Access本体や特定バージョンの詳細なサポート終了時期は流動的なため個別に要確認ですが、「アップデートのたびに何かが壊れる」という運用の不安定さそのものが、限界の兆候として現れます。

なぜ「動いているから大丈夫」を続けると危険なのか

限界を放置するリスクは、目に見える不具合よりも「いつ壊れるか分からない」状態が続くことにあります。壊れてから移行を検討すると、選択肢も期間も大きく制約されます。

Accessシステムの怖さは、限界を迎えても「一応動いている」ように見え続ける点にあります。同時利用の競合はエラーで落ちるのではなく「遅い」「たまに固まる」という体感として現れ、データ量の上限も突然ファイルが壊れるまで表面化しないことが多くあります。この「動いているから大丈夫」という状態が、実は最も危険な段階です。

放置した場合に発生しやすいリスクは大きく3つです。1つ目はデータ破損による業務停止で、ファイルサイズが上限に近づいた状態で書き込みエラーが起きると、直近のデータが失われるだけでなく、業務そのものが止まります。2つ目は退職による長期のブラックボックス化で、担当者がいなくなってから改修が必要になると、まず「何が書いてあるか読む」ところから始めなければならず、通常の改修より工数が大きく膨らみます。3つ目は移行の選択肢が狭まることです。壊れてから慌てて移行先を決めると、比較検討の時間が取れず、結果的に自社の業務に合わない仕組みを選んでしまうリスクが高まります。

限界を先送りするほど、いずれの移行方式を選んでも移行コストは上がっていきます。逆に言えば、まだシステムが安定して動いているうちに移行を検討し始める方が、選択肢も予算も自社でコントロールしやすいということです。

移行の選択肢 クラウド化・Webアプリ化・パッケージ移行・延命

移行の選択肢は大きく4つあり、それぞれ初期費用・移行期間・データ移行の難易度が異なります。自社の業務の複雑さと予算感で選ぶのが基本です。

Accessからの移行先として検討されるのは、主に次の4パターンです。

移行方式	初期費用の目安	移行期間の目安	データ移行の難易度
クラウド化（業務クラウドへの載せ替え）	30万〜150万円	1〜3ヶ月	中（業務ロジックの再設計が必要）
Webアプリ化（受託でのスクラッチ開発）	150万〜500万円	3〜6ヶ月	高（VBAロジックの仕様化から必要）
パッケージ移行（業務パッケージソフトへの乗り換え）	50万〜200万円＋月額ライセンス	2〜4ヶ月	中〜高（自社運用への合わせ込み次第）
延命（当面は保守のみで据え置き）	数万〜数十万円	なし（先送り）	ー（リスクは残存）

※上記はいずれも見込みの目安であり、実際の費用・期間は業務範囲やデータ量、既存VBAの複雑さによって変動します。

クラウド化は、業務クラウド（kintone等のノーコード/ローコード基盤）にテーブル構造と入力フォームを載せ替える方式です。既存の業務フローが比較的シンプルで、複雑な帳票出力やロジックが少ない場合に適しています。初期費用を抑えやすい一方、Access特有の凝った集計処理や複雑な条件分岐は、そのままでは移植できず再設計が必要になることが多いです。

Webアプリ化は、受託開発でスクラッチのWebアプリケーションを作る方式です。Accessに蓄積されたVBAロジックを丁寧に仕様化し直せるため、自社の業務に最も合った形に作り直せるのが強みですが、初期費用と期間はもっとも大きくなります。複数拠点からの同時アクセスや、外部システムとの連携が必要な会社に向いています。

パッケージ移行は、業界特化の業務パッケージソフトウェアに乗り換える方式です。同業他社での導入実績がある分、安定性は見込みやすいものの、自社独自の運用ルールをパッケージの標準機能に合わせて変更する必要があり、その合わせ込みの手間が想定より大きくなるケースがあります。

延命は、当面は保守だけを続けて移行を先送りする選択です。予算や体制が整っていない段階では現実的な判断ですが、前段で見た通り先送りするほど後のコストは上がるため、「いつまで延命するか」の期限を決めておくことが重要です。

データ移行で実際につまずくポイント

Access移行で最も工数を見誤りやすいのはデータ移行そのものです。正規化の崩れ・ロジックの仕様化・並行稼働の設計を軽視すると、想定の1.5倍以上の工数になります。

受託開発の現場でAccess移行を手がけると、見積り段階で見落とされがちなつまずきポイントがいくつも出てきます。

1つ目は正規化の崩れです。長年運用されてきたAccessのテーブルは、当初の設計から逸脱して「同じ意味のカラムが複数のテーブルに重複している」「1つのカラムに複数の情報が詰め込まれている」状態になっていることが少なくありません。移行先のシステムにそのまま持っていくと不整合が起きるため、テーブル設計を作り直す工程が必要になります。

2つ目はVBAロジックのブラックボックス化です。特に作った担当者がすでに退職しているケースでは、コメントのないマクロやVBAコードを1行ずつ読み解き、「何をしている処理なのか」を仕様として書き起こす作業が発生します。この仕様化の工程は、システムの複雑さによっては移行作業全体の3割以上を占めることもあり、見積り時に軽視されやすい部分です。

3つ目はマスタデータの表記ゆれです。取引先名や品目名が、入力担当者や時期によって微妙に異なる表記で登録されているケースは非常に多く、そのまま移行すると新システム側で同一の取引先が別々のレコードとして扱われてしまいます。名寄せ作業は地味ですが、移行後の業務品質を左右する重要な工程です。

4つ目は並行稼働期間の設計です。旧システムと新システムを完全に切り替えるのではなく、一定期間は両方を並行して動かし、データを突き合わせて検証する期間を設けるのが安全です。この並行稼働の設計を軽視して一気に切り替えると、移行漏れに気づいた時にはすでに旧システムのデータにアクセスできない、という事態になりかねません。

これらのつまずきポイントは、いずれも「移行してみないと分からない」性質のものではなく、事前の棚卸しとヒアリングで多くを事前に洗い出せます。移行の見積りを取る際は、データ移行の設計にどれだけ工数を割いているかを必ず確認することをお勧めします。

移行タイミングをどう判断するか

移行タイミングの判断基準は5つあります。このうち2つ以上に当てはまる場合は、本格的な移行検討に入るべきサインです。

「いつ移行すべきか」という問いに唯一の正解はありませんが、判断材料になる具体的なサインは次の5つに整理できます。

1つ目は、同時利用者からの「重い」「固まる」という報告が月に複数回出ているかどうかです。2つ目は、データベースファイルのサイズが2GBの上限に近づいている、あるいは明らかに動作が遅くなっているかどうかです。3つ目は、システムを作った本人がすでに退職している、または近く退職する予定があるかどうかです。4つ目は、OSやOfficeのアップデートによって過去に機能が動かなくなった経験があるかどうかです。5つ目は、複数拠点対応・外部システム連携・スマートフォンからの利用といった新しい業務要件に応えられていないかどうかです。

これらのうち1つだけであれば、当面は保守で様子を見る判断もあり得ます。ただし2つ以上が同時に当てはまる場合は、限界が単発の不具合ではなく構造的な問題になっているサインです。特に「作った人がすでにいない」状態と「動作が重い/データ量が上限に近い」状態が重なっている場合は、次に何か大きな不具合が起きた時に対応できる人が誰もいない、という最も危険な組み合わせになるため、早めの移行検討を強くお勧めします。

まとめ

Accessで作った業務システムは、同時利用・データ量・属人化・OS/Officeのバージョンアップという4つの壁を、運用年数が伸びるほど確実に迎えます。厄介なのは、限界を迎えても「一応動いている」ように見え続けることで、これが移行判断を先送りさせる最大の要因です。移行の選択肢はクラウド化・Webアプリ化・パッケージ移行・延命の4つがあり、自社の業務の複雑さと予算感で選べます。ただしどの方式を選ぶ場合も、データ移行の設計（正規化の見直し・VBAロジックの仕様化・マスタの名寄せ・並行稼働期間）を軽視すると工数が大きく膨らむ点は共通です。

本記事で挙げた5つの判断基準のうち2つ以上に心当たりがある場合は、システムが完全に壊れる前に移行の選択肢を検討し始めるタイミングです。自社のAccessシステムがどの限界にどれだけ近づいているか、どの移行方式が合っているか判断に迷う場合は、初月無料の経営AI診断（通常30万円相当）で現状のシステム構成を可視化し、移行の優先度までご一緒に整理することもできます。

関連記事

• ノーコードから本格開発へ移行すべきタイミング 判断基準5つと進め方 — 関連: 移行タイミングの判断基準の考え方
• AI導入後の保守運用コストを抑える5つのポイント 中小企業の実例で解説 — 関連: 保守コストの内訳と抑え方
• 中小企業のAI開発ベンダー選定基準7項目 相見積もり前に押さえる視点 — 関連: 移行先ベンダーの選び方
• 中小企業のIT導入補助金2026 対象枠と補助額・申請の流れを解説 — 関連: 移行費用に使える補助金
• 受注管理のAI自動化はどこまで可能か 中小製造業のための実務ガイド — 関連: 別クラスタの自動化事例