結論(先に要点)
- 費用相場は「50万円〜2,000万円超」と幅が非常に広い。 これは手抜きの説明ではなく、Accessシステムは中身の規模差が大きいという実態を表している。画面数・テーブル数・帳票数・VBAの行数・データ移行量・外部連携の6要素で金額はほぼ決まる。
- 移行先は大きく3系統。 kintone等のローコード(軽量なAccess向け)、Power Apps(Microsoft 365環境向け)、Laravel等のスクラッチ開発(複雑・大規模向け)。加えて「今は移行せず延命する」という第4の選択肢も、費用対効果しだいでは正解になりうる。
- 失敗の大半は技術ではなく段取りで起きる。 一気に切り替える「ビッグバン移行」、VBA棚卸し不足、旧Accessと新システムの二重入力、現場に使われず放置——このあたりが定番の落とし穴だ。
- 見積書は総額ではなく「内訳」と「前提条件」で読む。 データ移行費・保守費・追加費用の扱いが曖昧な見積もりは、後から膨らむ。本記事後半に、危険な見積もりを見抜くための読み方とチェックリストを用意した。
- 相場の数値は各所の公開情報(後述の二次情報を含む)を整理したもので、自社の金額は棚卸しをしないと確定しない。まず現状を可視化することが、ムダな見積もり比較を減らす近道になる。
Accessの限界を体系的に整理したAccess移行ガイド|属人化業務をWeb・クラウドへ移す方法、移行先の全体比較を扱ったAccess廃止後の代替システム5選も、あわせて読むと判断の解像度が上がる。本記事は特に「費用」と「見積もりの見極め方」に焦点を当てる。
INSTANT ESTIMATE
計算式より、60秒で概算を出しませんか?
システム種別・規模・連携先を選ぶだけで、開発費用・期間・月額運用費の概算をその場で表示します。
この記事を読むべき人
- 長年使ってきたAccessを、そろそろWebシステム/クラウドへ移したいが、費用感がまったく掴めていない経営者・事業責任者
- 相見積もりを取ったら会社ごとに金額が数倍違い、どれが妥当か判断できずに止まっている情シス兼任担当者
- Accessの作成者が退職・高齢化し、「壊れたら誰も直せない」状態に不安を抱えている決裁者
- 補助金を使って移行したいが、対象範囲や進め方が分からない担当者
- ベンダーの見積もりを鵜呑みにして「追加費用でトラブルになった」経験があり、次は失敗を避けたい方
「うちの規模だと結局いくらかかるのか」「何を基準に発注先を選べばいいのか」を、根拠つきで判断できる状態を目指す構成にした。
目次
- なぜ今、Access→Web化を検討すべきか
- 移行費用が10倍ぶれる理由:金額を決める6つの変数
- 規模別の費用相場(根拠つき)
- 移行先パターンの比較と選び方
- 見積もりの内訳:どこにいくらかかるのか
- データ移行の手順と落とし穴
- よくある失敗パターン
- 見積もりの読み方:危険な見積もりの見抜き方
- 発注前チェックリスト
- ベンダーに聞くべき質問(第三者検証の観点)
- 補助金の活用
- GXOに相談すべきタイミング
- よくある質問(FAQ)
なぜ今、Access→Web化を検討すべきか
「まだ動いているから」を理由に先送りされがちなテーマだが、放置コストは静かに積み上がっている。判断を後押しする材料を、公式情報を軸に整理する。
サポート終了という時限爆弾
Microsoftの永続版(買い切り)Accessには、明確なサポート終了日が設定されている。複数の解説記事が引く公開情報を整理すると、Access 2016/2019はすでにサポートが終了しており、Access 2021も2026年10月13日にサポートが終了する予定とされている(各バージョンの正確な終了日は必ずMicrosoftのライフサイクル情報で確認すること)。Microsoft 365版のAccessはサブスクリプション契約が続く限り利用できるが、Microsoftの投資の重心はPower Platform側へ移っているとみられる。
サポート終了は「その日から使えなくなる」ものではないが、OSやOffice更新に伴う不具合が起きても公式サポートが受けられなくなる。つまり「壊れてから直せない」リスクが年々高まる。移行は、使えているうちに計画的に進めるほど安く・安全に済む。壊れてからの緊急移行は、選択肢が減り、費用も跳ね上がる。
同時接続と容量の構造的な限界
Accessの仕様上限は、Microsoft公式ドキュメント「Access の仕様と制限」で確認できる。同時接続ユーザー数は255、データベースファイル(.accdb)の合計サイズは2GB、1テーブルのフィールド数は255——これらは公式の数値だ。
ただし注意したいのは、255ユーザーはあくまで理論上の上限だという点である。ファイルベースのデータベースであるAccessは、ネットワーク越しに複数人が同時に書き込むと、応答遅延やファイル破損のリスクが現実的に高まる。実運用では「数名〜十数名を超えたあたりから不安定になる」という指摘が、移行支援を手がける各社の解説で共通して語られている(これは二次情報・実務知見であり、公式の数値ではない)。2GBの容量上限も、画像や添付ファイルを扱うシステムなら数年で到達しうる。リモートワークでVPN越しにAccessファイルを開く運用は、速度低下と破損の温床になりやすい。
属人化——最大のリスクは「人」に宿る
技術的な限界以上に深刻なのが、属人化だ。Accessは現場の担当者が独学でVBAを組み上げていることが多く、仕様書が存在しないまま業務の根幹を支えているケースが少なくない。作った本人が退職・異動すれば、誰も中身を説明できず、改修も不可能な「ブラックボックス」と化す。この状態は、システムが動いている間は表面化しないが、いざ担当者が抜けた瞬間に事業リスクとして噴出する。
属人化の解消は、Web化で最も見えにくく、しかし最も価値の大きい効果だ。設計と業務ロジックがドキュメント化・システム化され、複数人で運用・改修できる状態になること自体が、移行に投資する十分な理由になる。
移行費用が10倍ぶれる理由:金額を決める6つの変数
「Access移行の費用は?」に一言で答えられないのは、Accessという言葉が指す中身の幅が広すぎるからだ。テーブル3つの住所録も、テーブル30・VBA数千行の基幹システムも、同じ「Access」と呼ばれる。費用は次の6変数でほぼ決まる。見積もりを読むときも、この6軸で分解すると各社の差が理解できる。
横にスクロールして確認できます
| 変数 | 費用への影響 | 見積もり前に自社で数えるべきこと |
|---|---|---|
| 画面数(フォーム) | 大 | 入力・検索・一覧画面の数 |
| テーブル数・リレーション | 大 | テーブル数と、テーブル間の関連の複雑さ |
| 帳票・レポート数 | 中〜大 | 印刷帳票・集計表・ラベルの種類数 |
| VBA/マクロの行数 | 最大級 | モジュール行数、外部処理の有無 |
| データ移行量・品質 | 中 | レコード数、重複・表記ゆれの多さ |
| 外部連携 | 中〜大 | Excel/CSV連携、他システム接続の数 |
このうち費用を最も大きく左右するのがVBAの行数だ。単純なデータ管理ならローコードツールに置き換えるだけで済むが、VBAで複雑な業務ロジック(自動採番、条件分岐、帳票生成、他システム連携)が組まれている場合、その一つ一つを移行先で再実装する必要があり、ここが工数の山になる。「テーブルは少ないがVBAが数千行」という一見小さなAccessが、見積もりで数百万円になるのはこのためだ。
逆に言えば、この6つを自社で棚卸ししてから見積もりを取るだけで、各社の金額差の理由が読めるようになり、不当に高い見積もりや、あとで追加費用が発生する安すぎる見積もりを見抜けるようになる。
規模別の費用相場(根拠つき)
以下は、Access移行・Access開発を扱う各社の公開情報を整理した相場観だ。いずれも自社事例の実数ではなく、業界の公開レンジを二次情報として整理したものであり、実際の金額は前節の6変数と移行先の選択で大きく変わる。断定ではなく「当たりをつけるための目安」として使ってほしい。
横にスクロールして確認できます
| 規模の目安 | テーブル数/VBA量 | 有力な移行先 | 費用レンジ(目安) | 期間の目安 |
|---|---|---|---|---|
| 極小(〜3名利用) | 5以下/ごく少量 | ローコード(kintone等) | 数十万〜100万円台 | 1〜2ヶ月 |
| 小規模(3〜10名) | 5〜15/少〜中 | kintone/Power Apps | 100万〜300万円台 | 1〜3ヶ月 |
| 中規模(10〜30名) | 15〜30/中〜多 | Power Apps/スクラッチ | 300万〜800万円台 | 3〜6ヶ月 |
| 大規模(30名超・基幹) | 30超/大量 | スクラッチ開発 | 800万〜2,000万円超 | 6ヶ月〜1年超 |
補足として、Access関連の開発を扱う複数の費用相場ページでは、シンプルな顧客管理で20万〜50万円、販売管理で40万〜70万円、工程管理など複雑なもので80万〜150万円といったレンジも示されている(これらは主にAccess自体の改修・小規模開発を想定した二次情報で、Webシステムへのフル移行とは前提が異なる点に注意)。フルスクラッチのWeb移行になると、要件定義・設計・テスト・データ移行が本格化するため、金額帯は一段上がる。
システム開発費用全体の考え方は中小企業のシステム開発費用ガイドで予算帯別に整理している。「そもそもいくらでどこまで作れるのか」を掴んでから移行の見積もりを読むと、判断がぶれにくい。
移行先パターンの比較と選び方
Access移行の相談で最初に問われるのが「どこへ移すか」だ。代表的な3系統に、忘れられがちな第4の道を加えて整理する。
横にスクロールして確認できます
| 比較項目 | kintone等ローコード | Power Apps | スクラッチ(Laravel等) |
|---|---|---|---|
| 初期費用の目安 | 数十万〜300万円 | 100万〜500万円 | 500万〜2,000万円超 |
| 月額 | ユーザー課金(1,500円/人〜が目安) | Microsoft 365ライセンス活用可 | サーバー費(月1万〜5万円等) |
| VBAロジック再現度 | 限定的(JS等で代替) | 限定的(Power Fxで代替) | 完全(PHP/JS等で再実装) |
| 複雑なリレーション | 苦手(フラット寄り) | Dataverseで対応 | RDBで完全対応 |
| 向くケース | 軽量な台帳・案件管理 | 既にMicrosoft 365利用 | 複雑・大規模な基幹業務 |
※料金は各サービスの公開情報をもとにした目安。プランや構成で変動するため、正確な金額は各公式で確認すること。
kintone等ローコード:軽量なAccessの受け皿
顧客台帳、案件管理、在庫リストのような比較的シンプルなデータ管理なら、kintoneをはじめとするローコードツールで十分に置き換えられる。開発が速く、初期費用も抑えやすい。弱点は、Accessで凝ったリレーショナル設計をしている場合、フラットなデータ構造に合わせるための設計見直しが要る点。将来カスタム開発の壁にぶつかったときの逃げ道は脱kintoneのカスタム開発移行ガイドにまとめている。
Power Apps:Microsoft 365環境ならではの近道
すでにMicrosoft 365を全社導入している企業なら、Power AppsとDataverseでMicrosoftエコシステム内に移すのが合理的な場合が多い。Teams・SharePoint・Power Automateとの連携で、承認フローやリマインドの自動化まで一気に組める。ライセンスを既に持っていれば追加コストを抑えやすいのも利点だ。
スクラッチ開発:複雑・大規模なAccessの本命
テーブルが多く、VBAで独自ロジックが張り巡らされた基幹システムは、Laravel等でフルカスタムのWebシステムに作り直すのが現実解になりやすい。Accessの制約(同時接続・容量・帳票・権限)をすべて解消でき、将来の拡張やIoT・API連携の基盤にもなる。費用は最も高いが、事業の中核を支えるシステムなら投資対効果は見合う。
第4の道:あえて「今は移行しない」延命策
見落とされがちだが、移行しない判断も選択肢だ。利用者が2〜3名以下、データが2GBに余裕があり、数年以内に業務自体が縮小・廃止される見込みなら、フル移行に数百万円かけるより延命が合理的なこともある。具体的には、データ部分だけをSQL ServerやSharePointに外出しして破損リスクを下げ、フロントはAccessのまま使い続ける「フロント/バック分離」などの手がある。ベンダーが最初から「全部作り直しましょう」としか言わない場合は、この延命策も含めて費用対効果を比較したか、必ず確認したい。
見積もりの内訳:どこにいくらかかるのか
総額だけを見ても妥当性は判断できない。Access移行の見積もりは、おおむね次の工程で構成される。各項目が見積書に明記されているか、金額の内訳が読めるかが、良い見積もりの条件だ。
横にスクロールして確認できます
| 工程 | 主な作業 | 費用がぶれやすいポイント |
|---|---|---|
| 要件定義・棚卸し | 現行Accessの解析、業務ヒアリング、仕様化 | ここを省くと後工程で追加費用が噴出する |
| 設計 | テーブル設計の見直し、画面・帳票設計 | 正規化のやり直し量で変動 |
| データ移行 | クレンジング、移行スクリプト、検証 | 「別途見積もり」にされがちな要注意項目 |
| 画面・機能開発 | フォーム/検索/一覧の再実装 | 画面数に比例 |
| 帳票開発 | 印刷帳票・集計表の再現 | Access帳票の作り込みが多いと膨らむ |
| VBA再実装 | 業務ロジックの移植 | 費用の最大変動要因 |
| テスト・並行稼働 | 突合検証、新旧並走 | 短縮するとリリース後に事故る |
| 保守・運用 | リリース後の改修・障害対応 | 月額の範囲と単価を要確認 |
特に注意すべきはデータ移行費と保守費だ。この2つを本体見積もりから外し、「別途」「実費」とだけ書く見積もりは、後から想定外の請求につながりやすい。データ移行は移行成功の生命線であり、無視できるコストではない。
データ移行の手順と落とし穴
データ移行は「Accessから新システムへコピーする作業」ではない。長年蓄積された汚れをどう扱うかが成否を分ける。
手順1:Accessの棚卸し(1〜2週間)
テーブル・クエリ・フォーム・レポート・VBAモジュール・外部連携を一覧化する。これは見積もり精度を上げるためにも、発注前に自社で着手できる工程だ。
横にスクロールして確認できます
| 棚卸し項目 | 確認内容 |
|---|---|
| テーブル | 数、レコード数、リレーション構造 |
| クエリ | 選択・更新・クロス集計等の種類と数 |
| フォーム | 入力・検索・一覧画面の数 |
| レポート | 帳票・集計表・ラベルの種類 |
| VBA | モジュールの行数、外部処理の有無 |
| 外部連携 | Excel/CSV出力、他システム接続 |
手順2:データクレンジング(1〜4週間)
汚れたデータをそのまま移すと、新システムに不整合を持ち込むことになる。重複レコードの統合、「(株)/株式会社」などの表記ゆれ・全角半角の統一、テスト用や退職者などの不要データ削除、必須項目のNULL対処——ここを先にやるほど後工程が軽くなる。
手順3:テーブル設計の見直し(2〜4週間)
Accessの構造をそのまま複製してはいけない。同じデータが複数テーブルに散っている冗長構造を、移行を機に正規化する。この設計の質が、移行後の使い勝手と拡張性を決める。
手順4:移行の実行
横にスクロールして確認できます
| 方法 | 手順 | 注意点 |
|---|---|---|
| CSVエクスポート | Access→CSV→新システムへインポート | 文字コード(UTF-8/Shift_JIS)の取り違えに注意 |
| ODBC接続 | Access→ODBC→新DBへ直接移行 | リレーション情報は別途再構築 |
| 移行スクリプト | Python等で自動移行を組む | 検証テストケースを事前に用意 |
手順5:検証と並行稼働(4〜8週間)
レコード件数の突合、主要な集計値の一致確認、特殊文字・空白などエッジケースの検証を行う。そのうえで1〜2ヶ月の並行稼働を設け、新旧の結果が一致することを確認してから旧Accessを廃止する。「正のデータは新システム」と明示し、旧Accessは早めに読み取り専用にするのが安全だ。
よくある失敗パターン
Access移行がこじれるのは、技術力より段取りの問題であることが多い。定番の落とし穴を挙げる。自社の計画がこれに当てはまっていないか、発注前に点検してほしい。
- ビッグバン移行(一気切替):並行稼働を省いて一夜で切り替え、移行漏れや不具合が本番で噴出する。読み取り系→マスタ→トランザクションと段階的に移すのが鉄則。
- VBA棚卸し不足:見えない業務ルールがVBAに埋まっており、移行後に「あの自動計算がない」と発覚する。棚卸しを甘くすると追加費用の温床になる。
- 二重入力(ダブルメンテ):移行期間中に旧Accessと新システムの両方へ入力し続け、どちらが正か分からなくなる。正のデータソースを片方に統一する運用ルールが必須。
- 現場定着の失敗:研修不足で新システムが使われず、こっそりAccessに戻る。UIの使いやすさとオンボーディングを軽視すると投資が無駄になる。
- データ品質の引き継ぎ:汚れたデータをそのまま移し、新システムでも不整合が続く。クレンジングを移行前工程として見積もりに含める。
- 保守の空白:作って終わりで、改修体制を決めていない。誰がどのSLAで直すのかを契約時に固める。
見積もりの読み方:危険な見積もりの見抜き方
相見積もりで金額が数倍違うのは珍しくない。安いほうが得とは限らず、高いほうが丁寧とも限らない。総額ではなく次の観点で読むと、地雷を避けられる。
- 要件定義・棚卸しの工程が独立して計上されているか。 ここが「サービス」「無料」で消えている見積もりは、要件が固まらないまま進み、後半で追加費用が膨らむ典型パターンだ。
- データ移行費が本体に含まれているか、別途か。 「データ移行は別途実費」とだけ書かれた見積もりは、後から数十万〜数百万円が乗る余地がある。移行対象のテーブル数・レコード数の前提が書かれているかも確認する。
- VBAの再実装範囲が明記されているか。 「現行同等」の一言で済ませた見積もりは危険。どのロジックを移し、どれを廃止するのかの線引きがないと、認識のズレが後で炎上する。
- テスト・並行稼働の期間と工数が入っているか。 ここを削って安く見せている見積もりは、リリース後の事故で結局高くつく。
- 保守費の範囲と単価。 月額に何が含まれ、範囲外の改修は何時間いくらか。ここが曖昧だと、稼働後のコストが読めない。
- 前提条件と除外事項が書かれているか。 良い見積もりほど「この見積もりに含まないもの」を明記している。除外事項がゼロの見積もりは、むしろ警戒したほうがいい。
見積もりの読み解きや、複数社の比較でどうしても判断がつかないときは、システム移行・再構築の相談として第三者に見てもらうのも有効だ。発注前に一度、利害関係のない立場のレビューを挟むだけで、避けられる失敗は多い。
発注前チェックリスト
見積もり依頼の前に、自社でここまで整理しておくと、精度の高い見積もりが取れ、比較もしやすくなる。丸投げよりも失敗率が確実に下がる。
- Accessファイルを全て洗い出した(部門・個人のPCに散っていないか)
- テーブル数・レコード数・リレーションを数えた
- フォーム(入力・検索・一覧)の画面数を数えた
- 帳票・レポートの種類と数を数えた
- VBAモジュールのおおよその行数を把握した
- 外部連携(Excel/CSV/他システム)を洗い出した
- 実際の同時利用者数と、今後の増加見込みを確認した
- 「残す機能」と「この際やめる機能」を仕分けた
- 移行の目的(属人化解消/リモート対応/拡張性など)を1つに絞った
- データのクレンジングが必要な箇所(重複・表記ゆれ)を把握した
- 補助金の利用可否・スケジュールを確認した
- 「延命」も含めて費用対効果を比較する前提を持った
ベンダーに聞くべき質問(第三者検証の観点)
同じ要件でも、ベンダーによって提案も金額も変わる。次の質問への答え方で、その会社が自社の利益ではなく顧客の成功を見ているかが分かる。
- 「なぜこの移行先を勧めるのか」—— 自社が得意なものを一律に勧めていないか。kintone/Power Apps/スクラッチ/延命を、自社の状況に沿って比較したうえでの結論か。
- 「データ移行の失敗リスクと対策は」—— クレンジングと検証をどう設計するか、具体的に説明できるか。
- 「VBAのどのロジックを移し、どれを捨てるか」—— 棚卸しの深さがここに出る。
- 「並行稼働はどれくらい設けるか」—— 短すぎる提案はリスクを軽視している。
- 「リリース後の保守は誰が、いくらで、どのSLAで」—— 作って終わりにならないか。
- 「この見積もりに含まないものは何か」—— 除外事項を即答できるかで、見積もりの誠実さが分かる。
こうした問いを投げる前提として、自社側にも判断軸が必要になる。移行の前に現状と要件を第三者の目で整理したいなら、移行前の第三者診断のように、発注を前提にしない壁打ちから始める手もある。要件が固まっていない段階での本発注は、追加費用と手戻りの最大の原因だ。
補助金の活用
Access→Web移行は、補助金の対象になりうる。ただし制度名・枠・上限額は年度ごとに見直されるため、必ず公式で最新情報を確認してほしい。
2026年度は、従来の「IT導入補助金」が**「デジタル化・AI導入補助金2026」**へと名称・枠組みが刷新されている。公式サイトでは通常枠、インボイス枠、セキュリティ対策推進枠、複数者連携デジタル化・AI導入枠などの申請枠が案内されている(補助率・上限額は枠と年度で変わるため、公式のシミュレーターや各枠の説明で確認すること)。kintone・Power Apps等のクラウド/SaaS導入費がこうした枠の対象になりうる。スクラッチ開発のように設備投資性が強い案件は、ものづくり補助金の外部委託費が対象になる場合がある。
補助金は「取れれば半額前後の負担軽減」になりうる一方、申請要件・スケジュール・対象経費の線引きが複雑で、間に合わなければ全額自己負担になる。制度の全体像と申請の進め方は中小企業の補助金完全ガイド2026に整理している。移行計画と補助金スケジュールは、必ずセットで組み立てたい。
GXOに相談すべきタイミング
次のいずれかに当てはまるなら、本発注の前に一度、整理・診断のフェーズを挟む価値がある。
- 相見積もりの金額が数倍違い、どれが妥当か判断できない
- Accessの作成者が退職間近で、中身を説明できる人がいない
- 「全部作り直し」の提案しか出てこず、延命も含めた比較ができていない
- データ移行費や保守費が見積もりから抜けていて、総額が読めない
- 補助金を使いたいが、対象範囲とスケジュールの組み方が分からない
GXOでは、レガシー刷新の進め方そのものを扱うレガシー刷新・移行の進め方に加え、発注を前提にしない現状整理から入ることもできる。まずは「今のAccessが何でできていて、どの移行先が合い、いくらが妥当か」を、利害関係のない立場で棚卸しするところから始めるのが、遠回りのようで最短だ。
相談の前に、この記事の「発注前チェックリスト」を埋めておくと、初回の壁打ちで得られる精度が大きく上がる。数字が揃っているほど、概算費用も現実的なものになる。
よくある質問(FAQ)
Q1. AccessのVBAマクロはそのまま移行できますか?
VBAのコードはそのままでは移行できません。移行先で再実装が必要です。kintoneではJavaScript、LaravelではPHP/JavaScript、Power AppsではPower Fxで業務ロジックを組み直します。まずVBAを棚卸しし、「残すロジック」と「この機会にやめるロジック」を仕分けることが、費用を抑える第一歩です。
Q2. Accessのフォームやレポートはそのまま使えますか?
Access独自形式のため、フォームもレポートもそのままでは移行先で使えません。画面デザインと帳票レイアウトは移行先で作り直します。ただし既存の画面構成を「参考設計」として使うのが一般的で、ゼロから考え直す必要はありません。
Q3. 移行中もAccessは使い続けられますか?
使い続けられます。新システム完成後に並行稼働期間を設け、新旧のデータが一致することを確認してからAccessを廃止するのが安全です。並行稼働中は「正のデータは新システム」と決め、二重入力を避ける運用ルールを敷きます。
Q4. データ量が多い(数百万レコード)場合、どのくらいかかりますか?
データ量だけでなく、テーブル数やリレーションの複雑さにも左右されます。数百万レコードなら、クレンジングに2〜4週間、移行スクリプトの開発・実行に1〜2週間、検証に2〜4週間が目安で、全体で2〜3ヶ月を見込むのが現実的です。
Q5. なぜ会社によって見積もりが数倍も違うのですか?
Accessは中身の規模差が大きく、VBAの量・帳票の作り込み・データ移行の扱いをどこまで見積もりに含めるかで総額が変わるためです。安い見積もりは要件定義・データ移行・保守が「別途」になっていることが多く、後から追加費用で膨らむことがあります。総額ではなく内訳と前提条件で比較するのが正解です。
Q6. 移行せずにAccessを延命する選択肢はありますか?
あります。利用者が少なく、データ容量に余裕があり、数年内に業務が縮小・廃止される見込みなら、データをSQL ServerやSharePointに外出しして破損リスクを下げ、フロントはAccessのまま使う「延命」が合理的な場合もあります。「作り直し」ありきで判断しないことが大切です。
参考資料
- Microsoft「Access の仕様と制限」(同時ユーザー数255/DBサイズ2GB等の公式仕様) https://support.microsoft.com/ja-jp/office/access-の仕様-0cf3c66f-9cf2-4e32-9568-98c1025bb47c
- IPA(情報処理推進機構)「DX白書2024」(2024年2月公表) https://www.ipa.go.jp/publish/wp-dx/dx-2024.html
- 中小機構「デジタル化・AI導入補助金2026」公式サイト https://it-shien.smrj.go.jp/
- 中小企業庁「ものづくり補助金総合サイト」 https://portal.monodukuri-hojo.jp/
※本記事の費用相場は、Access移行・開発を扱う各社の公開情報を二次情報として整理したものであり、GXOの案件実績値ではありません。実際の費用は、現行Accessの棚卸し結果と移行先の選択によって確定します。各サービスの料金・補助金の要件は改定されるため、発注・申請前に必ず公式の最新情報をご確認ください。






