LASSIC Media らしくメディア
VB6・Access業務アプリ刷新・移行の外注ポイント
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Visual Basic 6.0のIDE（開発環境）は2008年4月8日にサポート対象外となっており、新規開発や大幅な改修ができない状態が続いています*1。
- Accessのデータベースファイルは1つあたり2ギガバイト、同時接続数は255までという上限がMicrosoft公式に定められています*2。
- 複数人で共有するAccessデータベースは、データを持つ「バックエンド」と画面を持つ「フロントエンド」に分割することが公式に推奨されており、分割しないまま共有すると破損リスクが上がります*3。
目次
VB6・Access業務アプリとは何か、なぜ今刷新が必要なのか
VB6・Access業務アプリとは、Visual Basic 6.0（以下VB6。1998年にリリースされたプログラミング言語・開発環境）やMicrosoft Accessで作られ、部門内の在庫管理・受発注・帳票出力などの業務を支えているデスクトップアプリケーションを指します。多くは2000年代に情報システム部門や現場の担当者が自作したもので、Windows上で長年動き続けてきました。
刷新が急がれる背景は、技術面と組織面の両方にあります。技術面では、VB6のIDE（開発環境）が2008年に非サポートとなったため新規開発ができず、Accessのファイル型データベースには容量や同時接続数の上限が設けられています。
組織面では、アプリを作った担当者が退職・異動し、仕様書が残らないまま「触れる人がいない」状態に陥っているケースが目立ちます。次章以降では、この2つの側面をVB6・Access特有の論点として順に整理していきます。
VB6ランタイムのサポート実態——動くことと開発できることは別問題
Microsoftの公式サポート方針によると、VB6ランタイム（アプリの実行に必要な基本ライブラリと実行エンジン）は、サポート対象のWindowsバージョンが稼働している期間中は提供されます*1。つまり、既存のVB6アプリがWindows 11やWindows Server 2022の上で動作すること自体は、現時点で妨げられていません*1。
一方でVB6のIDE（統合開発環境）は、2008年4月8日にサポート対象外となりました*1。Microsoftはこの方針の中で「Visual Basic 6アプリケーションを作成・保守する正式な手段は存在しない」としており、モダンな技術への置き換えを推奨しています*1。ランタイムのサポート範囲についても「既存アプリケーションに対する重大な不具合と重要度の高いセキュリティ問題のみ」に限られる、という条件が付されている点に注意が必要です*1。
もう一つの制約が、実行環境のアーキテクチャです。VB6ランタイムのファイルは32ビット専用のままで更新されておらず、64ビット版のWindowsおよびWindows Serverでは、VB6アプリとすべてのランタイムコンポーネントがWOW（32ビットアプリを64ビットOS上で動かす仕組み）環境下でのみサポート対象になります*1。将来的にWOW環境そのものの扱いが変わる可能性を考えると、この前提に依存し続けることにはリスクがあります。
要するに、VB6アプリは「今のところ動く」状態であっても、「新しい機能を追加できる」「不具合を自由に直せる」状態ではありません。改修が必要になった際に対応できる開発者を確保しにくい点も、実務上の負荷になっています。
AccessのファイルDB構造の限界——2GBの壁と255接続、共有時の破損リスク
Accessは、他のデータベース製品と異なり、データそのものを1つのファイル（.mdbまたは.accdb）として保存する仕組みを採っています。この構造がゆえに、Microsoft公式の仕様には明確な上限値が定められています*2。主な数値を整理すると次の通りです。
| 項目 | Access（.mdb/.accdb）の上限 |
|---|---|
| データベースファイルの容量 | 2ギガバイト（システムオブジェクトの分を除く）*2 |
| 同時接続数 | 255*2 |
| 利用可能な接続数 | Microsoft 365版で512、非Microsoft 365版で256*2 |
| 開けるテーブル数 | Microsoft 365版で4,096、非Microsoft 365版で2,048（リンクテーブル等を含む）*2 |
| 1テーブルあたりのフィールド数 | 255*2 |
容量の上限そのものは意外と早く近づきます。画像や添付ファイルを多く保存する運用、あるいは何年分ものトランザクションデータを蓄積してきた運用では、2ギガバイトという枠が現実的な制約として立ちはだかります。
複数の担当者が同時にフォームを開いて入力する運用も、255という同時接続数の枠内に収まっているかを一度確認しておく価値があります。
複数人で共有するAccessデータベースについて、Microsoftは「データを保持するバックエンド」と「クエリ・フォーム・レポートなどを保持するフロントエンド」に分割する方式を推奨しています*3。分割していない状態でネットワーク越しに共有すると、複数ユーザーが同一ファイルへ同時にアクセスするため、ファイル破損のリスクが高まるとされています*3。分割した構成であれば「ファイル破損が起きても、通常はそのユーザーが開いていたフロントエンドのコピーに限定される」という利点があります*3。長年運用されてきた野良アプリの中には、この分割がされていないまま共有フォルダ上で稼働しているものも少なくありません。
属人化した「野良アプリ」の実態——仕様書なし、作成者退職後のブラックボックス化
VB6・Accessアプリの刷新を難しくしているもう一つの要因は、技術的な制約というより組織的な事情です。多くの部門アプリは、当時のプログラミングに詳しい社員が業務の合間に作り上げたもので、要件定義書や設計書が残されていない場合が大半です。フォームのボタンに埋め込まれたイベントプロシージャや、Accessのマクロ・VBAモジュールの中にしか、業務ロジックが記録されていない状態も珍しくありません。
作成者が在籍している間は、質問すればすぐに答えが返ってくるため、問題として認識されにくい面があります。ところが退職や異動が発生すると、「なぜこの計算式になっているのか」「このボタンを押すとどの帳票が出力されるのか」といった基本的な情報が、担当部署の誰にも分からなくなります。これがいわゆる「野良アプリ」のブラックボックス化です。
複数の部門で似たような野良アプリが独立して作られ、少しずつ改修を重ねてきた結果、社内に何本あるのかを情報システム部門が正確に把握できていない企業もあります。刷新を検討する際は、まず対象アプリを網羅的に洗い出すところから始める必要があり、この初期段階の負荷が過小評価されがちです。
移行先の3つの選択肢——Web/クラウド再構築・ローコード・パッケージ/SaaS
VB6・Accessアプリの移行先は、大きく3つの方向性に分けられます。どれが適しているかは、業務の独自性や利用人数、既存アプリの複雑さによって変わります。
(A) Web/クラウド業務アプリへの再構築
既存の業務フローや帳票の形式を維持したい場合、Web技術やクラウド基盤を使ってアプリをゼロから再構築する選択肢があります。既存のVB6・Accessアプリに固有の業務ロジックが複雑で、他システムに寄せにくい場合に選ばれやすい選択肢です。開発の自由度が高い一方、要件定義から設計、実装までの工程を一通り踏む必要があります。
(B) ローコード/ノーコード（Power Appsなど）への置換
Microsoftは、Access上のデータをPower PlatformのDataverseへ移行するためのツールを公式に提供しています*4。移行後は、既存のAccessクライアントを使い続けながらPower Platformの機能も併用できるほか、デスクトップ・スマートフォン・タブレットに対応したアプリを作成できるとされています*4。
注意点として、DataverseとAccessではサポートするデータ型が完全には一致しません*4。データ型によって容量の上限が異なる場合もあるため、移行前にデータ型ごとの互換性を確認する工程が欠かせません*4。ロジックが比較的単純な入力・照会系のアプリであれば、ローコードへの置換で対応できる範囲が広がります。
(C) パッケージ/SaaS導入
在庫管理や受発注のように、業界標準に近い業務であれば、独自開発ではなく既存のパッケージソフトやSaaSに置き換える方法も検討に値します。自社の業務フローをパッケージ側の標準機能に合わせる調整が必要になりますが、開発工数そのものを抑えられる可能性があります。
| 選択肢 | 向いているケース | 検討すべき点 |
|---|---|---|
| (A) Web/クラウド再構築 | 業務ロジックが独自で複雑、他システムに寄せにくい | 要件定義からの工程が必要、開発規模の見積り |
| (B) ローコード（Power Appsなど） | 入力・照会が中心で、ロジックが比較的単純 | データ型の互換性、容量上限の違い*4 |
| (C) パッケージ/SaaS | 業界標準に近い業務（在庫・受発注など） | 自社フローとパッケージ標準機能の差分調整 |
移行を進める4つのステップ——棚卸しから段階的リプレースまで
VB6・Accessアプリの移行は、いきなり作り直しに着手するのではなく、実態把握から始める段取りが実務的です。ここでは4つのステップに分けて整理します。
ステップ1：棚卸し。社内に存在するVB6・Accessアプリを部門横断で洗い出し、利用頻度・利用人数・稼働しているPCの環境を確認します。想定より多くの野良アプリが見つかることも少なくありません。
ステップ2：仕様の掘り起こし。フォームの構造、VBAモジュール、マクロの処理内容を解析し、業務担当者へのヒアリングを重ねて仕様を再構築します。仕様書が存在しない前提での作業になるため、コード解析と現場ヒアリングを組み合わせる進め方が求められます。
ステップ3：優先度付け。利用頻度が高く業務への影響が大きいアプリ、あるいはAccessの容量上限や同時接続数に近づいているアプリを優先的に扱います。逆に利用者が少なく影響範囲の狭いアプリは、後回しにする判断もあり得ます。
ステップ4：段階的リプレース。優先度の高いアプリから小さい範囲で移行を試し、既存システムと並行運用しながら検証を進めます。一括での切り替えは業務停止のリスクを伴うため、範囲を絞った段階移行が現実的です。
これらの工程を外注する場合、委託先が「仕様書がない前提での要件再定義」に対応できるかどうかが選定の分かれ目になります。コードを読み解いて業務ロジックを再構築する作業と、現場担当者へのヒアリングを丁寧に重ねる作業の両方が必要になるため、開発だけでなく業務分析の経験も問われます。
まとめ：VB6・Access業務アプリ刷新で押さえる3つの視点
本稿ではVB6・Access業務アプリの刷新を、公式情報に基づいて整理しました。第一に、VB6のIDEは2008年に非サポートとなり、ランタイムのサポートも重大な不具合・重要なセキュリティ問題への対応に限られています*1。第二に、Accessのデータベースファイルには2ギガバイトの容量上限と255の同時接続数上限があり、共有時にはバックエンドとフロントエンドへの分割が推奨されています*2*3。第三に、移行先はWeb/クラウド再構築・ローコード・パッケージ/SaaSの3方向があり、対象アプリの棚卸しと仕様の掘り起こしを経て段階的に移行を進める進め方が実務に合っています。
よくある質問
VB6アプリは今も動いているのに、なぜ刷新を検討する必要がありますか。
VB6ランタイムはサポート対象のWindowsバージョンが稼働している間は提供されますが、IDE（開発環境）は2008年4月8日に非サポートとなっており、新規開発や大幅な機能追加はできません*1。ランタイムへのサポートも、重大な不具合と重要度の高いセキュリティ問題に限られています*1。動作していることと、改修・保守を続けられることは別の問題として捉える必要があります。
Accessのデータベースファイルが容量の上限に近づいています。どう対応すればよいですか。
Accessのデータベースファイルは1つあたり2ギガバイトが上限で、システムオブジェクトの分を除いた実容量はそれよりも少なくなります*2。バックエンドを複数のファイルに分ける方法もありますが、恒常的な対応にはならないため、Web/クラウドアプリやローコード基盤への移行を含めて検討することをおすすめします。
作成者が退職していて仕様書が残っていません。何から始めればよいですか。
まずは対象アプリの棚卸しから始め、フォームやVBAモジュール・マクロを解析しながら業務担当者へのヒアリングを重ねて仕様を再構築します。仕様書がない前提での要件再定義は時間を要する作業になるため、優先度の高いアプリから着手する進め方が実務的です。
ローコード（Power Appsなど）への置き換えで注意すべき点はありますか。
MicrosoftはAccessのデータをDataverseへ移行するツールを提供していますが、AccessとDataverseではサポートするデータ型が完全には一致せず、データ型によって容量の上限が異なる場合があります*4。移行前にデータ型ごとの互換性を確認し、対応できない項目がないかを洗い出しておく必要があります。
VB6・Accessアプリの移行を外注する場合、何を確認すればよいですか。
仕様書がない状態からコード解析と業務ヒアリングで仕様を再構築できるか、対象アプリの棚卸しから対応できるか、段階的な移行スケジュールを組めるかを確認します。移行先がWeb/クラウド再構築・ローコード・パッケージ/SaaSのいずれになるかによっても、必要な体制は変わってきます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Microsoft「Support Statement for Visual Basic 6.0」（Microsoft Learn）（https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy）
- *2 出典：Microsoft「Access specifications」（Microsoft Support）（https://support.microsoft.com/en-us/access/access-specifications）
- *3 出典：Microsoft「Split an Access database」（Microsoft Support）（https://support.microsoft.com/en-us/access/split-an-access-database）
- *4 出典：Microsoft「Migrate Microsoft Access data to Microsoft Dataverse」（Power Apps、Microsoft Learn）（https://learn.microsoft.com/en-us/power-apps/maker/data-platform/migrate-access-to-dataverse）
