合同会社小村ソフト
日本語 English 한국어 繁體中文 العربية
相談する
メニュー

VB6 / Access業務アプリの延命と移行 ── 残す・包む・置き換えるの判断表

· · VB6, Access, VBA, レガシー資産, 既存資産活用・移行, Windows開発, データベース移行, モダナイゼーション, 判断表, 技術相談

「VB6 で書かれた基幹の一部がまだ現役」「Access で作った台帳が、実は部門の業務を支えている」──中小企業の相談では、この 2 つが今もかなり高い頻度で出てきます。共通しているのは、作った本人がすでに退職していたり、動いている理由を誰も正確に説明できなかったりすることです。それでも壊れずに動いているので、優先順位はどうしても下がりがちです。

当ブログではこれまで、COM / ActiveX / OCX とは何か、ActiveX / OCX の残す・包む・置き換える判断表、VBA の制約と将来性と、個別の技術要素については書いてきました。この記事では対象を絞り、日本の中小企業に今も広く残る 2 大レガシー資産──VB6 アプリケーションとMicrosoft Access 業務アプリ──について、「このまま残すか」「一部だけ包んで延命するか」「置き換えるか」を判断する実務ガイドをまとめます。判断の型は ActiveX / OCX の記事で使った「残す・包む・置き換える」の 3 択をそのまま踏襲しますが、対象が変わればリスクの中身も変わるので、この記事独自の論点を中心に整理します。

1. まず結論

  • VB6 の IDE・開発環境自体は、2008 年 4 月時点で正式サポートが終了しています。新規開発や改修を正式な手段で行う方法はもう提供されていません。1
  • 一方で VB6 ランタイム(msvbvm60.dll など)は、それが同梱される Windows のサポート期間中は動作します。「既存の VB6 アプリは、対応 Windows 上ではおおむね動き続ける」という前提は今も成立しますが、これは Windows 側のサポート期間に完全に従属した話です。1
  • VB6 は 32bit 専用で、64bit ネイティブコンパイルはできません。64bit OS 上では WOW64 という 32bit 互換環境の中で動いています。1 64bit 専用の DLL・SDK・COM コンポーネントと連携する必要が出た時点で、単体のプロセスでは完結しなくなります。
  • Access の .mdb / .accdb を読み書きする「Access Database Engine(ACE)」も 32bit/64bit の縛りがあります。1 台のマシンには片方のビット数しか入らず、Office のビット数と一致させる必要があります。2 Office は Office 2019 / Microsoft 365 以降、既定のインストールが 64bit に変わっているため、旧来の 32bit 前提で作られた Access アプリや ActiveX 部品は、新しい端末に入れ替えた瞬間に動かなくなることがあります。34
  • 共有フォルダー上で複数人が同時に .accdb を開く運用は、今も現場で多い一方、破損・パフォーマンス低下のリスク要因です。ネットワーク越しの書き込みは、接続が不安定になった際にデータ破損につながり得ることが案内されています。5 台帳の規模や同時利用人数が増えてきたら、SQL Server などへのアップサイズを検討する段階です。
  • 判断の軸は ActiveX / OCX のときと同じで、その資産が単なる画面なのか、業務ロジックとデータを抱えた境界面なのかです。安定稼働していて範囲が閉じているなら残す、一部だけ近代化したいなら包む、UI や実行基盤の制約が事業の足を引っ張っているなら置き換える、という順で考えます。

2. VB6の現状 ── ランタイムは生きているが、開発の後ろ盾はない

まず前提を正確にしておきます。マイクロソフトは 2008 年 4 月 8 日付で「Visual Basic 6.0 の IDE(および Visual Studio 6.0 の IDE)はサポート対象外」であることを表明しており、VB6 アプリケーションを作成・保守する正式な手段はもう提供されていない、モダンな技術への置き換えを強く推奨する、という立場を明確にしています。1

一方で同じ発表の中で、VB6 ランタイムはそれが同梱される Windows バージョンのサポート期間中は動作対象であるとも述べられています。既存の VB6 アプリは対応 Windows 上で「そのまま動く」ことが期待されており、サポートの範囲は深刻な後退(リグレッション)と重大なセキュリティ問題への対応に限られる、とされています。1 つまり「新しい Windows に入れても壊れないでほしい」という最低限の期待はできますが、「困ったときに機能追加や個別調査をしてもらえる」という意味でのサポートはありません。

もう一つ実務上効いてくるのが、VB6 ランタイムは 32bit 専用ファイルであり、64bit OS 上では WOW64 という 32bit エミュレーション環境の中でのみサポート対象になる、という点です。1 これは「VB6 アプリは今後も 32bit プロセスとしてしか生きられない」ということを意味します。64bit 専用の計測器 SDK や新しい暗号ライブラリを使いたくなったとき、VB6 側のプロセスにそのまま読み込むことは原理的にできません。この壁を越える方法は、実質的に「別プロセスに切り出して連携する」の一択で、具体的な構成は「32bitアプリから64bit DLLを呼ぶCOMブリッジ実例」で扱った内容がそのまま使えます。VB6 アプリからブリッジを使う場合も考え方は同じで、64bit の機能をアウトプロセス COM サーバーやヘルパー EXE に閉じ込め、VB6 側はそれを呼ぶだけにします。

VB6 アプリの多くは ActiveX / OCX コントロールを画面部品として抱えています。これらの部品自体の残す・包む・置き換え判断は「ActiveX / OCX を今どう扱うか」で詳しく扱っているので、VB6 アプリの中に埋め込まれた個々のコントロールの判断はそちらを参照してください。この記事では、VB6 アプリ全体をどう扱うか、という一段上のレイヤーの判断に焦点を当てます。

3. Accessの現状 ── ファイル形式・ACEのビット数・共有フォルダーの現実

3.1 .mdb / .accdb とACEのビット数

Access のデータは .mdb(旧形式)または .accdb(2007 以降)というファイルに格納され、これを読み書きするランタイムコンポーネントが Access Database Engine(ACE、Jet の後継)です。実務で頻発するのがビット数の不一致トラブルです。従来の Jet OLE DB プロバイダーは 32bit 版しか提供されておらず、ACE は 32bit / 64bit の両方が提供されているものの、1 台の端末にはどちらか一方しかインストールできず、その端末の Office のビット数と一致させる必要がある、と案内されています。2 Visual Studio 側でも、Visual Studio 2022 以降が 64bit プロセスになったことで、32bit の Access プロバイダーを使うデータツールが接続できなくなるケースが明記されています。6

さらに厄介なのが Office 側の既定値の変化です。Office 2010〜2016 は既定で 32bit 版がインストールされていましたが、Office 2019 および Microsoft 365 からは既定のインストールが 64bit 版に変わっています。3 加えて、64bit 版の Office プロセスは 32bit のバイナリを読み込めないため、既存の 32bit ActiveX コントロールや COM アドインは 64bit Office ではそのまま動作しません。4 つまり「何年も同じ Access アプリを使い続けてきたのに、PC を入れ替えたら急に動かなくなった」という事故の多くは、Office のビット数が既定で切り替わったことと、それに ACE や埋め込みコントロールのビット数が追随できていないことが原因です。この手のトラブルの切り分け手順は「Office 2024/Microsoft 365でActiveXが動かない原因と確認手順」にまとめてあります。

3.2 共有フォルダーでの多人数利用というリスク

Access アプリのもう一つの定番構成が、共有フォルダー上に置いた .accdb を複数人が同時に開く運用です。小規模なら長年問題なく動きますが、これは本質的に危うい構成です。ネットワーク越しの書き込みは、接続が不安定になった際に書き込み失敗やファイル破損につながり得ることが案内されていますし、5 ファイルサーバーへのアクセスが遅延・タイムアウトした際に Access がディスク/ネットワークエラーを報告する事例も古くから知られています。7 破損の芽そのものは共有ファイルへの同時アクセスという点で、当ブログの「ファイル連携の排他制御の基礎知識」で扱った競合パターンと構造がよく似ています。Access はロックファイル(.laccdb)による排他制御を内蔵していますが、Wi-Fi 経由のノート PC、VPN 越しの在宅利用、スリープ復帰後の再接続といった「接続が不安定になりやすい経路」が増えるほど、事故率は上がります。

同時利用人数が増える、または処理が重くなってきたときの定番の逃げ道が、Access のテーブルを SQL Server や Azure SQL に移し、Access 側はリンクテーブルとして参照する構成です。SQL Server Migration Assistant(SSMA)などのツールを使い、Access のテーブルを移行した後、元の Access テーブルを移行先のテーブルへのリンクに置き換えることで、画面(フォーム・レポート・クエリ)はそのまま、データだけをより堅牢な基盤へ移せます。8 ただしリンクテーブル化には、集計処理が遅くなる(サーバー側で実行できない関数に依存していると、Access がテーブル全体をローカルへ引き下げてから処理する)、オートナンバー列の挙動が変わる、といった移行後特有の問題が知られており、パススルークエリやビューへの置き換えが必要になる場面もあります。8 また Access のアプリケーションは、テーブルを持つ「バックエンド」データベースと、画面・クエリ・マクロを持つ「フロントエンド」データベースに分割する設計が古くから推奨されています。9 ここで重要なのは、分割しただけでは不十分という点です。バックエンド(テーブル)だけを共有フォルダーに置き、フロントエンドは各ユーザーの端末にコピーして配置し、各自のローカルコピーから利用するのが正しい構成です。フロントエンドまで共有フォルダー上の1ファイルを全員で開き続ける運用は、分割していても「画面・クエリ・マクロを共有ファイルに対して同時に読み書きする」リスクが残ったままで、開くまでの待ち時間の悪化やデザイン変更時の競合といった問題を引き起こします。共有フォルダー運用のまま延命するにせよ SQL Server へ寄せるにせよ、まず「バックエンドの共有」と「フロントエンドの各端末への配置」の両方ができているかどうかが最初のチェックポイントになります。

4. 判断表

VB6 アプリと Access アプリを、利用状況・リスク要因ごとに整理すると、次のように判断できます。

対象 利用状況・リスク要因 目安
VB6 デスクトップアプリ 端末・Windows バージョンが固定され、変更要求も小さい 残す
VB6 デスクトップアプリ 64bit 専用 DLL・SDK・COM コンポーネントとの連携が必要になった 包む(64bit ヘルパー/COM ブリッジ)
VB6 デスクトップアプリ 開発者不在、ソース散逸、または頻繁な改修要求がある 置き換える
VB6 アプリ内の ActiveX/OCX 部品 UI 部品のみで代替コントロールがある 置き換える(部品単位)
VB6 アプリ内の ActiveX/OCX 部品 機器制御・帳票など仕様を抱えている 包む(まず境界を切り出す)
Access アプリ(個人利用・単独ファイル) 1 人称利用、バックアップ運用済みで同時アクセスがない 残す
Access アプリ(共有フォルダー・少人数) 数人が交代で利用、バックエンド共有+フロントエンドは各端末にローカル配置済み 残す(この構成済みなら延命しやすい)
Access アプリ(共有フォルダー・多人数/常時同時アクセス) 同時利用者が多い、破損・遅延の経験がある 包む(SQL Server へリンクテーブル化)
Access アプリ(32bit ACE/ActiveX 依存) Office の 64bit 化・端末更新が予定されている 包む/置き換えを先に検証(第3.1節)
Access の VBA ロジック 業務ロジックが集中し、他システム連携や Web 化の要求がある 段階的に置き換え(UI→ロジックの順)

補足として、この表の「包む」は多くの場合、データだけ、または境界だけを先に近代化し、画面や操作感はいったん維持するという意味です。全部を一度に作り直すのではなく、リスクの高い部分から順に手を付けるための一時的な着地点だと捉えてください。

判断表の使い方としては、まず「対象」の行を絞り込み、次に「利用状況・リスク要因」に自分の状況が当てはまるかを確認します。同じ VB6 アプリでも、ある画面は残す、ある機能は包む、という具合に行単位・機能単位で判断を分けてよいことが重要です。「VB6 アプリだから全部同じ扱い」とまとめてしまうと、本来は残せるはずの安定部分まで巻き込んで工数が膨らみます。

5. シナリオ別に見る判断の当てはめ方

判断表を実際の相談に当てはめると、だいたい次の 3 パターンに収束することが多いです。

シナリオ 1: 社内専用の在庫管理 VB6 アプリ、変更要求は小さい。 対象端末が数台に固定され、ネットワークにも出ていかない構成であれば、判断表は「残す」に寄ります。ここでの実務対応は、第 7 章のリスク軽減策(バックアップ・文書化・実行環境固定)を淡々と積み上げることに尽きます。無理に .NET へ移行する動機がない限り、費用対効果が合わないことのほうが多いです。

シナリオ 2: 複数部門で共有する Access 台帳、利用人数が増えてきた。 数年前は 2〜3 人で使っていた Access アプリが、部門統合や業務拡大で 10 人規模の同時アクセスになってきた、というのはよくある相談です。この場合、判断表は「包む」寄りになります。まずバックエンドの共有・フロントエンドの各端末へのローカル配置ができているかを確認し(第 3.2 節)、できていなければ先に分割・配置し直します。そのうえで、破損やパフォーマンス低下の兆候(開くまでの待ち時間が伸びた、.laccdb が残留してロックが解除されないなど)が出ているなら、テーブルを SQL Server へ移行し、Access 側はリンクテーブルとして参照する構成に切り替えます。8 画面はほぼそのまま使えるため、利用者側の教育コストを抑えながらデータ基盤だけを堅牢にできます。

シナリオ 3: 開発者が退職した VB6 の基幹アプリ、Web 化の要求がある。 ソースはあるが誰も触れる人がいない、社外から使いたいという要求も出てきた、という状況では、判断表は「置き換える」に寄ります。ただし基幹であるほど、いきなりの全面リライトはリスクが高すぎます。第 9 章の手順どおり、まず業務ロジックの棚卸しと影響範囲の小さい機能の切り出しから始め、段階移行で進めるのが現実的です。

6. よくあるアンチパターン

VB6・Access の延命・移行案件で繰り返し見かける失敗パターンを先に共有しておきます。判断表を当てはめる前に、まずここに当てはまっていないかを確認してください。

アンチパターン 何がつらいか まずの直し方
「古いから」で対象を選ばず全面リライトを決める 仕様発掘と不具合再現が同時進行になり、工数が読めなくなる 判断表の行単位で対象を絞り、まず棚卸しから始める
32bit の ACE / ActiveX と 64bit Office の混在を放置する 端末更新のたびに「動かなくなった」事故が起きる(第3.1節) ビット数を揃えるか、境界を切って包む
共有フォルダー上の .accdb を無制限に多人数化させる 破損・パフォーマンス低下が徐々に悪化する(第3.2節) バックエンド共有+フロントエンドの各端末へのローカル配置、または SQL Server へのアップサイズを検討
VB6 のソース一式・依存 OCX を個人 PC にしか置いていない 退職・PC 故障で資産そのものが失われる ソース管理システムや共有ストレージへ集約する
「動いているので触らない」を何年も続ける 前提を説明できる人がいなくなり、残すコストが見えなくなる 実行環境と依存関係の文書化(第7章)
リンクテーブル化しただけで満足する Access 側の関数に依存したクエリがサーバー側で実行できず、かえって重くなる パススルークエリやビューへの置き換えを検討する8
業務ロジックの棚卸しをせずに UI だけ作り直す 隠れた例外処理や計算ロジックが漏れ、移行後に業務が止まる 置き換え前に VBA・モジュール単位での棚卸しを行う(第9章)

この中で特に発生頻度が高いのは、ビット数の混在放置と、共有フォルダーの多人数化の 2 つです。どちらも「今日壊れる」話ではなく、端末更新や利用者増加といった、いつか必ず来るきっかけで顕在化するという共通点があります。

7. 残す場合の現実的なリスク軽減策

残すという判断が現実的なケースは多く、それ自体は間違いではありません。ただし「動いているから触らない」を続けるほど、前提が誰にも説明できなくなるリスクは積み上がります。最低限、次は手当てしておくべきです。

  • バックアップの世代管理を機械的に回す。Access の .accdb は 1 ファイルで完結するぶん、日次で世代バックアップを取るだけでもかなりの事故を吸収できます。VB6 アプリはソース一式(.vbp, .frm, .bas, .cls)と、依存する OCX・DLL・レジストリ登録情報までまとめて保全します。
  • 後継者不在対策として、実行環境の前提を文書化する。対応 OS、Office のビット数、必要なランタイム・依存 DLL・登録手順を、少なくとも「新しい PC で動かなくなったときに何を確認すればよいか」が分かる粒度で残します。
  • 実行環境を意図的に固定する。Windows や Office の自動更新でビット数や既定設定が変わることが事故の引き金になるため(第 3.1 節)、対象端末だけは更新ポリシーを分け、更新前に検証してから展開する運用にします。
  • クリーン環境でのスモークテストを用意する。新しい端末へ展開する前に、まっさらな環境でインストール・登録・起動・主要操作が通ることを確認できる手順を用意しておくと、展開のたびに「動くはずなのに動かない」で止まる時間を減らせます。
  • 呼び出し箇所を 1 か所に寄せる。VB6 の COM 呼び出しや Access のリンクテーブル参照をアプリ全体にばらまかず、可能な範囲で窓口を絞っておくと、将来包む・置き換えるときの着手点が明確になります。

VB6 特有の注意点として、開発機自体の保全も挙げておきます。IDE のインストールメディアやライセンス、ビルドに必要な外部コントロール(OCX)の開発者版、ビルド手順のメモは、実行環境以上に散逸しやすい資産です。改修の予定が当面なくても、ビルドが再現できる状態を 1 台の環境(仮想マシンのスナップショットなど)として保存しておくと、いざ小さな改修が必要になったときの選択肢が大きく広がります。

既存 Windows ソフトを壊さずに保守・改修したい場合は、既存Windowsソフトの改修・保守の対象領域です。

8. 包む場合の現実的な選択肢

「包む」は、古い資産を狭い境界の内側に閉じ込め、周辺からは新しい窓口として見せるアプローチです。VB6・Access ではおおむね次の 3 パターンに集約されます。

(a) VB6 の COM コンポーネントを .NET から COM 相互運用で呼ぶ。 VB6 で書かれたクラスモジュールを ActiveX DLL(アウトプロセスなら EXE)として公開している場合、.NET 側から COM 相互運用で呼び出すことができます。VB6 側は 32bit のままなので、64bit の .NET アプリから呼ぶ場合は第 2 章で触れたビット数の壁が同じ形で立ちはだかります。呼び出し側を 32bit で揃えるか、アウトプロセス COM サーバーとして 32bit プロセスに閉じ込めるかの選択は、「32bitアプリから64bit DLLを呼ぶCOMブリッジ実例」の構成をそのまま裏返して当てはめられます。COM 自体の基礎は「COM / ActiveX / OCX とは何か」を参照してください。

(b) Access の VBA ロジックを段階的に .NET / Web へ移す。 Access アプリの中には、フォームの裏に業務ロジックが濃く詰まっているケースと、単なるデータ入力・一覧表示にとどまるケースが混在しています。まず VBA モジュールを棚卸しし、他システムに依存しない純粋な計算・検証ロジックから .NET のクラスライブラリへ切り出し、Access 側からは COM 経由、または中間の Web API 経由で呼ぶ形に変えていく進め方が現実的です。VBA そのものの制約と、どこまでを VBA に残すべきかの判断軸は「VBAとは何か - 制約、将来性、置き換えるべき場面」で詳しく整理しています。

(c) UI だけ先に置き換え、データとロジックは温存する。 Access のフォームが古い、遅い、社外から使えない、といった不満が中心なら、データ層(SQL Server 化したテーブル)とロジックはそのままに、UI だけを Web やデスクトップの新しい技術に置き換える選択肢があります。第 3.2 節のリンクテーブル化と組み合わせれば、「データは SQL Server、旧 UI (Access) と新 UI が同じデータを見る」という過渡的な二重稼働も可能です。ただし、Access 側の VBA が UI とロジックを密結合させている場合は、この分離作業自体が(b)の棚卸しを先に済ませないと成立しません。

3 つの選択肢を整理すると、次のようになります。

選択肢 向く場面 見るポイント
(a) VB6 COM を .NET から呼ぶ VB6 側のロジックはそのまま活かし、新しい画面や周辺機能だけ .NET で作りたい ビット数(32bit で揃えるか、アウトプロセスで橋渡しするか)、登録・配布
(b) Access の VBA ロジックを段階移植 フォームの裏に濃い業務ロジックがあり、他システムとの連携要求が出てきた 純粋なロジックと UI・DB 操作の分離、呼び出し経路の設計
(c) UI だけ先に置き換え UI の古さ・社外アクセスへの不満が中心で、データとロジックは信頼できる データ層の分離度、旧 UI との並走期間の長さ

境界整理や移行方針をまず相談したい段階であれば、既存資産活用・移行支援、実装に入る前の設計レビューとしては技術相談・設計レビューが対応領域です。

9. 置き換える場合の進め方

置き換えを選ぶのは、UI やビット数の制約が事業のスピードを直接妨げている、開発者不在で保守自体が立ち行かない、といった状況です。全面リライトをいきなり始めるのではなく、次の順序を踏むと事故が減ります。

  1. データ移行の検証を先にやる。 Access → SQL Server のようなデータ移行では、オートナンバーの採番タイミングの違い、Access 側にしかない関数への依存、一意インデックスの欠落など、移行後にしか顕在化しない差分があります。8 本番データの複製で移行と業務シナリオの往復テストを済ませてから、本番切り替えに進みます。
  2. 業務ロジックの棚卸しをする。 VB6 のフォーム/モジュール、Access の VBA/マクロ/クエリの中身を機能単位で洗い出し、「単なる画面」なのか「仕様を抱えた境界面」なのかを見分けます。この見分け方は ActiveX / OCX の判断と同じですが、VB6・Access の場合は長年の運用で積み上がった業務理解そのものが資産になっている分、発掘に時間がかかりやすい点が固有の重さです。
  3. 段階移行(ストラングラーパターン)で進める。 全機能を一度に置き換えるのではなく、リスクが低く独立性の高い機能から新システムへ切り出し、旧アプリと新アプリを一定期間並走させます。新旧のどちらのデータが正なのかを機能単位で明確にし、並走期間の終了条件をあらかじめ決めておくことが、この進め方を破綻させないための最低条件です。
  4. UI 部品や画面構成の置き換えを先に済ませておくと楽になる。 VB6 アプリが ActiveX / OCX を UI 部品として使っている場合、その部品だけを先に現代的なコントロールへ置き換えておくと、後段の全体置き換えの見積もりが立てやすくなります。個別の判断は「ActiveX / OCX を今どう扱うか」を参照してください。
  5. 並走期間中の観測手段を用意する。 旧アプリと新アプリを並走させている間は、どちらの処理でどんな結果が出たかを比較できるログや突き合わせの仕組みを用意しておきます。観測手段がないまま切り替えを進めると、「新システムに切り替えたら数字が合わなくなった」という事故に気づくのが数か月後になりかねません。

古い Windows アプリの仕様棚卸しから段階置き換えまでを対象とするサービスとしては、Windowsアプリのリプレイスがあります。

10. 移行を始めるときのチェックリスト

判断表(第 4 章)を当てはめる前に、次の順で棚卸しをしておくと、方針決定にかかる時間がかなり短縮できます。

  1. 対象を洗い出す。 VB6 の .exe / .dll / .ocx、Access の .mdb / .accdb を、ファイル名・バージョン・配置場所ごとに一覧化します。
  2. 利用状況を確認する。 利用者数、同時アクセスの有無、共有フォルダー運用かどうか、日次・月次いずれの頻度で使われているかを確認します。
  3. 実行環境の前提を確認する。 対応 Windows のバージョン、Office のビット数、必要なランタイム・依存 DLL・COM 登録の有無を洗い出します(第 2〜3 章)。
  4. データの所在と規模を確認する。 Access であればファイルサイズ、テーブル数、レコード数と増加ペースを把握します。SQL Server 化の要否を判断する材料になります。
  5. 業務ロジックの複雑さを見積もる。 VBA モジュールの行数、マクロの数、フォームの数、VB6 側のフォーム・クラスモジュールの数から、棚卸しにかかりそうな工数の当たりをつけます。
  6. バックアップと復旧手順の有無を確認する。 バックアップが取られていない、または復旧を試したことがない対象は、判断以前にまずここを整備します。
  7. ここまでの結果を判断表に当てはめる。 対象・利用状況が整理できたら、第 4 章の表に照らして、残す・包む・置き換えるのどれに寄るかを機能単位で仮決めします。

この手順を飛ばすと、後になって「何が難しかったのか」を説明できないまま工数だけが膨らむ、という展開になりがちです。

11. まとめ

VB6・Access の扱いを決めるときに最初に見るべきは「古いかどうか」ではなく、次の 3 点です。

  • VB6 は IDE の後ろ盾を失った 32bit 専用の実行環境であるという前提を正しく理解しているか(第 2 章)。
  • Access の ACE・ActiveX は Office のビット数に縛られ、共有フォルダー運用は同時アクセスが増えるほど破損リスクが上がるという前提を織り込めているか(第 3 章)。
  • その資産が単なる画面なのか、業務ロジックとデータを抱えた境界面なのかを見分けられているか(第 4 章の判断表)。

この 3 点が整理できれば、「残す」なら実行環境を固定しバックアップと文書化を怠らない(第 7 章)、「包む」なら 32/64bit ブリッジや段階的な .NET/Web 化でデータとロジックを守る(第 8 章)、「置き換える」ならデータ移行の検証と業務ロジックの棚卸しを先にやる(第 9 章)、という進め方に自然につながります。VB6・Access は、古いからといって闇雲に捨てるべき対象ではなく、長年の業務知識が詰まった現物です。ただし現物と付き合い続けるための実行環境固定・境界整理・移行検証という宿題からは、いつまでも逃げ続けられるわけではありません。まずは第 10 章のチェックリストに沿って棚卸しから始めることをおすすめします。

関連記事

関連する相談領域

合同会社小村ソフトでは、VB6・Access を含む既存資産の棚卸しと移行方針の整理、32bit/64bit ブリッジを含む延命設計、段階的なリプレイスの計画・実装を扱っています。

参考リンク

  1. Microsoft, Visual Basic 6.0 Support Announcement. VB6 IDE / Visual Studio 6.0 IDE は 2008年4月8日付でサポート対象外となったこと、VB6 ランタイムは同梱される Windows バージョンのサポート期間中は動作対象であること、ランタイムは32bit専用で64bit OSではWOW(WOW64)環境下でのみサポートされることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, Microsoft OLE DB Provider for Jet and Jet ODBC driver are available in 32-bit versions only. Jet OLE DBプロバイダー/Jet ODBCドライバーは32bit版のみ提供されること、ACE(Access Database Engine)は32bit/64bitの両方があるが1台の端末にはどちらか一方のみインストール可能で、Officeのビット数と一致させる必要があることについて。 ↩ ↩2

  3. Microsoft Learn, 64-bit Visual Basic for Applications overview. Office 2010/2013/2016 は既定で32bit版がインストールされる一方、Office 2019 および Microsoft 365 からは既定のインストールが64bit版に変わったことについて。 ↩ ↩2

  4. Microsoft Learn, Compatibility between the 32-bit and 64-bit versions of Office. 64bit版OfficeのネイティブプロセスはActiveXコントロールを含む32bitバイナリを読み込めないこと、既存の32bit ActiveXコントロールは64bit Officeと互換性がないことについて。 ↩ ↩2

  5. Microsoft Learn, “Delayed Write Failed” error message states that your data has been lost. ネットワーク共有上のファイルへの書き込みが接続断などで失敗した場合、対象ファイルが破損する可能性があり、その処理はアプリケーション側の責任であることについて。 ↩ ↩2

  6. Microsoft Learn, Connect to a database in Visual Studio. Visual Studio 2022以降は64bitプロセスになり、一部のデータツールが32bit版のOLEDB/ODBCプロバイダー(32bit版Access OLEDBプロバイダーを含む)を使ったデータベースに接続できなくなることについて。 ↩

  7. Microsoft Learn, System stops responding, slow file server performance, or delays occur when you work with files that are located on a file server. ファイルサーバーへのアクセス遅延時に、Access の .mdb ファイルを開こうとすると「ディスクまたはネットワークエラー」が発生し得る事例について。 ↩

  8. Microsoft Learn, Link Access applications to SQL Server and Azure SQL (AccessToSQL). Access のテーブルを SQL Server / Azure SQL へ移行した後、元のテーブルをリンクテーブルとして参照する構成と、移行後に起こり得るパフォーマンス低下やオートナンバー列の挙動差などの問題について。 ↩ ↩2 ↩3 ↩4 ↩5

  9. Microsoft Learn, Add and remove Access database files (AccessToSQL). Access データベースをテーブルを持つバックエンドデータベースと、クエリ・フォーム・レポート・マクロ・モジュールを持つフロントエンドデータベースに分割する設計について。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る