「このExcelとAccessのファイル、絶対に消さないでくださいね」。前任者から引き継ぎのときにそう言われたきり、中身をほとんど触らないまま数年が経った。見積書も、在庫も、取引先の履歴も、気づけば社内のあらゆる情報がその一つのAccessファイルに集約されている。フォームを開けば入力できるし、ボタンを押せば帳票も出る。だから今まで何とかなってきた。しかし最近、ファイルを開くたびに「応答なし」の表示が数秒続くようになった。同僚から「今日、Accessが固まって保存できなかった」と言われる回数も増えている。担当者しか触れないその画面の裏側で、いったい何が起きているのか。多くの中小企業の情シス・総務担当者が、今まさにこの状態に直面しています。
この記事では、Accessで構築された業務システムがなぜ限界を迎えるのか、その仕組みを技術的な背景から整理し、限界のサインをどう見極めるか、そして移行先をどう選ぶかを具体的に解説します。「今すぐAccessをやめるべきだ」という結論ありきの話ではありません。Accessには今なお正当な使いどころがあり、闇雲に移行することが正解とは限らないからです。判断のための材料を揃えることを目的にしています。
この記事で分かること
Accessが抱える技術的な限界(同時アクセス数・データ容量・属人化したVBAマクロ)を正しく理解した上で、「まだ延命できる状態か」「移行を検討すべき状態か」を見極める判断基準を提示します。移行先として候補になる選択肢を、コストと難易度別に整理し、失敗しやすい移行の進め方についても触れます。
先に結論を要約すると、判断の流れは次の4段階です。
- 限界の正体を知る: Accessが「壊れている」のではなく、設計上そうなる仕組みを理解する
- 自社の状態を診断する: 同時利用人数・データ量・担当者の状況という3つの軸でリスクを測る
- 移行先を比較する: Excel・ノーコード/ローコードツール・フルスクラッチ開発など、コスト感の異なる選択肢を把握する
- 移行の進め方を押さえる: 何を作り直すべきかを明確にしてから着手する
「動いているから大丈夫」という感覚だけで先送りにせず、技術的な根拠を持って次の一手を選べるようにすることが、この記事のゴールです。
Accessという製品の立ち位置を正しく理解する
結論から言うと、Access（データベースソフト）は「壊れやすいソフト」ではなく、そもそも少人数・小規模データ向けに設計された製品です。この前提を理解しないまま使い続けると、限界のサインを「不具合」だと誤解してしまいます。
Accessは1992年に初版が登場して以来、プログラミングの専門知識がなくても表形式のデータベースと入力フォームを作成できるツールとして、日本の中小企業に広く普及してきました。専門のシステム開発会社に発注するほどの予算がなくても、パソコンが得意な社員が一人いれば、業務に合わせた管理システムを内製できる。この手軽さこそがAccessの最大の価値であり、今なお多くの現場で使われ続けている理由です。
一方で、Accessは元々「個人または小規模なチームでの利用」を前提に設計された製品です。大人数が同時にアクセスする業務や、大量のデータを扱う業務向けには作られていません。この設計思想を知らないまま、業務の拡大とともに利用人数やデータ量が増えていくと、ソフト自体は何も変わっていないのに、突然「限界」という形で問題が表面化します。
実務上の視点: 「昔は問題なかったのに、最近急に重くなった」という相談の多くは、Accessが劣化したのではなく、利用実態がAccessの設計上限に近づいてきたことが原因です。原因を「経年劣化」だと誤解すると、再起動やパソコンの買い替えといった的外れな対処に時間を使ってしまいます。
限界のサインその1: 同時アクセス数の壁
結論から言うと、Accessは同時に接続できるユーザー数に上限があり、この上限に近づくと動作が不安定になります。Microsoft公式のAccess仕様によれば、1つのAccessデータベースに同時接続できるユーザー数の上限は255ユーザーとされています。
「255人も使っていないから関係ない」と思うかもしれませんが、実務上の不安定化はこの上限よりずっと手前、数人から十数人程度の同時利用で始まることが少なくありません。Accessはファイル共有型のデータベースであり、複数人が同じファイルに同時アクセスするたびに、ファイルサーバー経由でのロック処理(データの整合性を保つための排他制御)が発生します。ネットワークの経路が長くなったり、無線LAN経由でのアクセスが増えたりすると、このロック処理の待ち時間が急激に伸び、「応答なし」や強制終了の頻発につながります。
同時アクセスに関する典型的な症状を整理すると、次のようになります。
- 複数人が同時に開くと、片方が保存できない・エラーが出る
- 昼休み明けなど、アクセスが集中するタイミングで極端に重くなる
- リモートワーク中の社員がVPN経由で開くと、ファイル破損が起きやすい
- 「今、誰かが編集中です」という排他ロックの表示が頻発する
これらの症状が月に数回程度であれば、運用の工夫(利用時間の分散、フォルダ構成の見直し)で当面しのげる場合もあります。しかし週に何度も発生する、あるいは特定の時間帯に必ず発生するようになった場合は、単なる一時的な不調ではなく、構造的な限界に近づいているサインだと捉えるべきです。
限界のサインその2: データ容量の壁
結論から言うと、Accessのデータベースファイル(.accdb形式)には、1ファイルあたり2ギガバイトというサイズの上限があります。これはMicrosoft公式のAccess仕様に明記されている制約で、正確には「2ギガバイトからシステムオブジェクトに必要な領域を差し引いた容量」が実質的な上限です。
2ギガバイトと聞くと大きな容量に思えるかもしれませんが、写真や添付ファイル、スキャンしたPDFなどをデータベース内に直接格納する運用をしていると、想像より早く上限に近づきます。特に、次のようなデータを多く扱う業務では注意が必要です。
| データの種類 | 容量を圧迫しやすい理由 |
|---|---|
| 商品写真・現場写真の埋め込み | 1件あたり数百KB〜数MBが積み重なる |
| スキャンした帳票・契約書のPDF添付 | 高解像度スキャンは1件で数MBに達することも |
| 長年蓄積した取引履歴・ログ | 件数が数十万件を超えると圧迫が顕著になる |
| 複数のテーブルを1ファイルに集約 | 業務追加のたびにテーブルが増え続ける |
上限に近づくと、新しいレコードの追加時にエラーが出たり、ファイルの破損リスクが高まったりします。応急処置として、圧縮と修復機能を使えば一時的に空き容量を確保できますが、これは根本解決ではなく延命処置に過ぎません。データそのものを他のテーブルやファイルに分割する、添付ファイルを外部の共有フォルダやクラウドストレージに逃がすといった対応でしのいでいる会社も多いですが、これも運用の複雑化という別のコストを生みます。
限界のサインその3: 属人化したVBAマクロと担当者不在
結論から言うと、Accessの限界は技術的な容量の問題だけでなく、「中身を理解している人が社内にいない」という体制面の問題として現れることが多くあります。
Accessの強力な機能の一つに、VBAマクロによるカスタマイズがあります。ボタン一つで複雑な集計や帳票出力ができるのは、裏側でVBAのコードが動いているためです。しかし、この柔軟性は諸刃の剣でもあります。前任の担当者が独学で組み上げたコードは、コメント(説明書き)がほとんど残されていないことが多く、後任者が中身を理解しようにも手がかりがありません。
こうした状態は、次のような悪循環を生みます。
- 前任者が業務の合間に、その場しのぎでマクロを追加していく
- マクロ同士が複雑に絡み合い、全体像を把握している人がいなくなる
- 前任者が異動・退職し、修正できる人が社内からいなくなる
- 小さな不具合が起きても、直せないまま放置される
- 「このシステムには触れない」という空気が社内に定着する
この状態は、システムそのものの限界であると同時に、属人化という組織的なリスクでもあります。Accessファイルが実質的に「誰も中身を説明できないブラックボックス」と化しており、それを扱える担当者が一人しかいないという状況は、その担当者が単一障害点（SPOF）になっていることを意味します。担当者が急に休職・退職した場合、業務そのものが止まりかねません。
実務上の視点: VBAマクロの中身を今いる人だけで解読する具体的な手順は、別記事「『作った人しか分からない』ExcelマクロとVBAを今いる人だけで解読する方法」で詳しく解説しています。移行を検討する前に、まず現状のマクロが何をしているかを可視化しておくと、移行先の要件定義がスムーズになります。
限界のサインその4: 32bit/64bitとOffice更新への対応
結論から言うと、AccessはMicrosoft 365 Apps(旧Office 365)の一部として提供されており、Windowsやほかのソフトのアップデートに巻き込まれる形で、突然動かなくなるリスクを常に抱えています。
代表的なつまずきどころが、32bit版と64bit版の違いです。Microsoftは64bit版のインストールを既定の推奨としていますが、古いAccessファイルの中には、32bit環境専用に書かれたVBAコードやActiveXコントロール(古い形式の外部部品)を使っているものがあります。パソコンの入れ替えや、社内のIT担当者が良かれと思って64bit版に統一した結果、特定のマクロだけが動かなくなるというトラブルは頻繁に起きています。
さらに注意したいのが、Accessのサポート形態そのものです。買い切り型の「Access LTSC 2021」は、Microsoft公式のライフサイクル情報によれば、メインストリームサポートの終了日が2026年10月14日(米国太平洋時間)と設定されています。サブスクリプション型のMicrosoft 365 Appsに含まれるAccessは、常に最新の状態に更新され続けることが前提の「モダンライフサイクルポリシー」の対象であり、明確な終了日は設定されていませんが、その分、古いバージョン向けに作られたマクロやアドインが将来の更新で動かなくなるリスクを常に内包しています。
つまり、Accessという製品自体がなくなるわけではなくても、「今動いているこのファイル」が次のWindows更新やOffice更新で動かなくなる可能性は、常にゼロではないということです。この不確実性こそが、多くの担当者が漠然とした不安を抱く根本的な理由だと言えます。
自社の状態を診断する: 3つのチェック軸
ここまでの限界のサインを踏まえて、自社のAccessシステムがどの段階にあるかをチェックしてみましょう。次の3つの軸で状態を確認してください。
- 同時利用人数: 同時にファイルを開く人数は何人か。5人を超えたあたりから不安定化のリスクが上がり始めます
- データ容量と成長速度: 現在のファイルサイズはどの程度か。上限(2GB)までの余裕年数を、直近1年の増加量から逆算できるか
- 担当者の理解度: マクロの中身を説明できる人が、今の社内に何人いるか。0人であれば最優先で対処が必要な状態です
この3つのうち、いずれか一つでも「赤信号」に該当する場合は、次の一手を検討すべきタイミングに来ています。
| チェック軸 | 黄信号 | 赤信号 |
|---|---|---|
| 同時利用人数 | 3〜5人が同時に開くことがある | 週に数回、保存エラーや応答なしが発生する |
| データ容量 | ファイルサイズが1GBを超えている | 増加ペースから見て1〜2年以内に2GBへ到達する |
| 担当者の理解度 | マクロの一部だけ理解できる人がいる | 誰もマクロの中身を説明できない |
すべてが黄信号以下であれば、当面は延命が可能な状態です。老朽化した社内システム全般の「延命か作り直しか」という判断軸については、別記事「老朽化した社内システムの『延命 vs 作り直し』判断基準」でTCO・技術的負債・機会損失という3つの評価軸から詳しく解説しています。Accessに限らず判断に迷う場合は、あわせて参照してください。老朽化システムの刷新タイミングそのものについては、老朽化した社内システムをいつ・どう刷新するかでも判断基準が整理されています。
移行先の選択肢を比較する
結論から言うと、Accessからの移行先は「Excelに戻す」という選択肢を除けば、大きく3つの方向性に分けられます。どれが正解ということはなく、予算・社内のITリテラシー・業務の複雑さによって最適解が変わります。
選択肢1: クラウド型の業務改善ツール(kintone等のノーコード・ローコード)
ノーコード・ローコードと呼ばれるクラウドサービスは、プログラミングの専門知識がなくても、ドラッグ&ドロップに近い操作でデータベースと入力画面を構築できます。月額数千円からの利用料で始められ、複数人・複数拠点からの同時アクセスにもクラウドサービスとして最初から対応しているため、Accessが抱えていた同時アクセス数の壁を回避しやすいという利点があります。
一方で、Accessで培った複雑なVBAマクロのロジックを、ノーコードツールの機能だけで完全に再現できるとは限りません。複雑な帳票レイアウトや、独自の計算ロジックが多いシステムほど、移行時に「今までできていたことができない」という壁にぶつかりやすくなります。
選択肢2: Excel+クラウドストレージへの縮小移行
利用人数が少なく、複雑な計算ロジックもそれほど多くない場合は、Excelとクラウドストレージ(SharePointやGoogleドライブ等の共同編集機能)の組み合わせに縮小移行するという選択肢もあります。コストはほぼゼロに近く、社内の誰もが操作に慣れているという利点がありますが、Accessが担っていたデータベースとしての整合性チェックやリレーション(関連するデータ同士のつながり)の機能は失われるため、あくまで小規模な業務向けの選択肢です。
選択肢3: 専門会社によるフルスクラッチ・システム開発
業務が複雑化し、既製のノーコードツールでは表現しきれないロジックを抱えている場合は、フルスクラッチ開発で自社専用のシステムを開発するという選択肢が視野に入ります。初期費用はノーコードツールより高額になりますが、業務にぴったり合わせた設計ができ、同時アクセス数やデータ容量の制約からも根本的に解放されます。
この3つの選択肢を比較すると、次のような傾向になります。
| 選択肢 | 初期コスト感 | 向いているケース |
|---|---|---|
| ノーコード・ローコードツール | 低〜中(月額課金が中心) | 業務ロジックが比較的シンプルで、早く移行したい場合 |
| Excel+クラウドストレージ | ほぼゼロ | 利用人数が少なく、データベース機能への依存度が低い場合 |
| フルスクラッチ開発 | 中〜高(初期費用が発生) | 業務ロジックが複雑で、長期的に使い続けるシステムが必要な場合 |
「相場はいくらか」という質問をよく受けますが、金額はシステムの複雑さや発注先によって大きく変動するため、この記事では断定的な金額を示しません。複数社からRFP（提案依頼書）をもとに見積もりを取り、比較検討することをおすすめします。
移行を成功させるための進め方
結論から言うと、移行で最も失敗しやすいのは「今のAccessファイルを、そのまま新しいツールに置き換えようとする」進め方です。長年運用してきたAccessファイルには、もう使われていない項目や、当時の業務都合で残っただけの機能が紛れ込んでいることがほとんどです。
移行を成功させるための進め方を整理すると、次のようになります。
- 今の業務フローを棚卸しする: Accessのどの機能を、誰が、どの頻度で使っているかを洗い出す
- 本当に必要な機能だけを抽出する: 使われていない機能まで移植しようとしない
- データをクレンジングしてから移す: 重複・不要データを整理してから移行する(データクレンジング)
- 並行運用期間を設ける: いきなり切り替えず、一定期間は新旧両方を動かして検証する
- 移行後のマニュアルを整備する: 属人化を繰り返さないよう、操作手順を文書化する
特に重要なのが、データのクレンジングです。長年運用されてきたAccessデータベースには、表記ゆれ(「株式会社」と「(株)」が混在するなど)や、重複した取引先情報が蓄積されていることが少なくありません。これらを整理しないまま新システムに移すと、新しいシステムでも同じ混乱が再現されてしまいます。
実務上の視点: 移行プロジェクトを外部の開発会社に依頼する場合は、「今のAccessファイルと同じものを作ってください」という依頼の仕方は避けるべきです。前任者の場当たり的な設計まで踏襲してしまい、結局同じ問題を抱えたシステムができあがるリスクがあります。まずは自社の業務フローを整理し、要件定義の段階で「本当に必要な機能」を明確にしてから発注することが、移行の質を大きく左右します。
いきなり全面移行しない: 小さく試す進め方
結論から言うと、移行を検討する際は、いきなり全業務を新システムへ切り替えようとせず、まず一部の業務だけで小さく試すことをおすすめします。長年運用してきたAccessシステムは、複数の業務が複雑に絡み合っていることが多く、一度にすべてを移そうとすると、要件の洗い出しだけで数か月かかることも珍しくありません。
具体的には、次のような段階を踏むと、移行の失敗リスクを抑えられます。
- PoC（概念実証）で技術的な相性を確認する: 候補ツールが自社の業務データや連携先と問題なく動くか、小規模な検証で確かめる
- MVP（実用最小限の製品）の範囲を決める: 最初から全機能を移そうとせず、最も業務への影響が大きい部分から着手する
- 一部の部署・業務だけで先行運用する: 全社展開の前に、限られた範囲で実際に使ってもらいフィードバックを得る
- 問題がなければ範囲を広げる: 先行運用で見えた課題を解消してから、対象業務・対象人数を段階的に拡大する
この進め方は、フルスクラッチ開発を外部の開発会社に依頼する場合にも有効です。契約の初期段階で全機能分の予算を確定させるのではなく、まず優先度の高い機能に絞ったSOW（作業範囲記述書）を結び、検証しながら次のフェーズに進むという契約形態を提案できないか相談してみる価値があります。合わせて、契約不適合責任の範囲や、納品後の保守契約がどこまでカバーするのかも、契約前に必ず確認しておきましょう。「作って終わり」ではなく、運用が始まってからの不具合対応やちょっとした改修依頼にどこまで応じてもらえるのかは、Accessのときのような属人化を繰り返さないためにも重要な確認ポイントです。
実務上の視点: 一部の担当者は「小さく試すと二度手間になるのでは」と懸念しますが、実際には逆です。全面移行してから大きな設計ミスに気づくよりも、小さな範囲で早期に問題を発見し修正する方が、結果的なコストは小さく済みます。Accessが長年愛用されてきた理由も、突き詰めれば「小さく始められる手軽さ」にありました。移行先を選ぶ際も、その手軽さの精神を引き継ぐ進め方が適しています。
移行先を選ぶ際に確認しておきたい観点
移行先の候補が絞り込めてきたら、契約前に次の観点も確認しておくと、Accessから移行したはずが別の限界にすぐ直面する、という事態を避けやすくなります。
- データの持ち出しやすさ: 将来別のツールへ乗り換える際、CSV等の汎用形式でデータを一括エクスポートできるか(データポータビリティ)
- 特定ベンダーへの依存度: そのツール・開発会社でしか保守できない独自仕様になっていないか(ベンダーロックイン)
- 契約後のサポート体制: 導入後の運用サポートや、不具合対応の範囲が契約(保守契約)に明記されているか
- 既存の他システムとの連携: 会計ソフトや基幹システムなど、他のツールとデータ連携する必要がないか
これらの観点は、Accessという1つのツールの限界を乗り越えるためだけでなく、次の移行先で再び同じような「担当者不在」「ベンダーロックイン」の問題を繰り返さないための予防策でもあります。せっかく移行するのであれば、5年後、10年後にも同じ悩みを繰り返さない体制づくりまで視野に入れて選定することをおすすめします。
まとめ: 「壊れる前」に判断材料を揃える
Accessで動く業務システムは、決して「悪いもの」ではありません。少人数・小規模データという条件の範囲内であれば、今後も十分に実用に耐えるツールです。問題は、業務の拡大とともにその条件を超えてしまっているのに、限界のサインに気づかないまま使い続けてしまうことにあります。
この記事で紹介した3つのチェック軸(同時利用人数・データ容量・担当者の理解度)のいずれかが赤信号に近づいているなら、それは「今すぐ移行しなければならない」という警告ではなく、「判断材料を揃え始めるタイミングが来た」というサインだと捉えてください。ファイルが実際に壊れてから移行を検討するのでは、選択肢は限られ、時間的な余裕もなくなります。平常時のうちに現状を可視化し、複数の移行先候補を比較検討しておくことが、結果的に最もコストを抑えた移行につながります。
次に読む記事として、Accessの中身であるVBAマクロを今いる人だけで解読する具体的な手順を知りたい方は「作った人しか分からない」ExcelマクロとVBAを今いる人だけで解読する方法を、老朽化システム全般の延命・作り直し判断についてより体系的に整理したい方は老朽化した社内システムの「延命 vs 作り直し」判断基準をあわせてご覧ください。また、Accessのファイルが既に破損しかけている、あるいは動かなくなってしまった場合はレガシーシステムからデータだけ救出する方法を、Access以外にVB6・Delphi製の古い業務システムも併存している場合はVB6・Delphi製システムはいつまで動くか。移行タイミングの見極めもあわせてご確認ください。
