VB6で動いている業務システム、まだ大丈夫だろうか」
こうした不安を抱えている情シス担当者の方は、決して少なくないと思います。エンジニア歴30年、VB6で書かれた業務システムを長年触り続けてきた立場から、正直に申し上げます。
VB6が今もまだ動いていることの方が、奇跡に近いのです。
私は1990年代後半、まだWindows 95やWindows 98が現役だった時代から、VB(Visual Basic)で業務システムを開発・保守してきました。あの頃から現在に至るまで、Windowsが新しいバージョンに変わるたびに、VBで書かれたシステムは何かしら動かなくなってきました。そのたびに、私は一人で「動くのか動かないのか」を調べ、必要な改修を行い、次の更新に備えてきました。
率直に言って、VB6が2026年の今もWindows 11上で動いていることは、技術的な観点から見ると驚くべき事実です。Microsoftが互換性レイヤーを保ち続けてくれているからこそ、なんとか延命できているにすぎません。
しかし、その互換性は永久には続きません。私が30年間見てきた事実から言えるのは、「いつか必ず動かなくなる日」が来るということです。それが「いつ」かは分からないだけで、「来るか来ないか」は確定しています。
この記事では、VB6システムを抱える情シス担当者の方向けに、Windows更新によって起こりうる5つのリスクと、それぞれへの現実的な対応策をお伝えします。30年の現場で実際に遭遇してきた経験ベースで、業務観点の話を中心にまとめました。
1. OSが変わるたびに改修してきた30年の歴史
最初にお伝えしたいのは、**「VBで書かれたシステムは、OSが変わるたびに何らかの改修が必要だった」**という歴史的事実です。
私が業界に入ったWindows 95/98の時代から、VBは進化を続けてきました。VB4、VB5、VB6と続き、それぞれのバージョンアップでもコードの調整が必要でした。さらに困ったのは、Windows側の更新です。Windows 95からWindows 98、Windows Me、Windows 2000、Windows XP、Windows Vista、Windows 7、Windows 8、Windows 10、Windows 11と、OSが新しくなるたびに、VBで書いたシステムのどこかが必ず動かなくなりました。
正直に告白すると、当時は情報が少なく、「もしかしたら改修しなくても動いたかもしれない」のに、念のために大規模な改修を実施したケースもありました。動くか動かないかを確認する手段が限られていたため、安全を期して全面的に手を入れざるを得なかったのです。当時の私は社内SEとして一人でこれらの対応を任されていたため、「下手に動かして本番が止まったら誰が責任を取るのか」という恐怖と常に隣り合わせでした。
Windows 95からWindows 11まで、約30年。これだけの時間が経って、VB6が現在も動いていることは、Microsoftの互換性維持努力と、世界中の業務システムがVB6に依存している現実が背景にあります。しかし、Microsoftがいつまでこの互換性を保つかは保証されていません。
実際に、Windows 11への移行時には、IE11(Internet Explorer 11)のサポートが完全終了し、IE依存していたVB6システムの一部が動かなくなる事例が多発しました。次の大型更新で何が動かなくなるかは、誰にも予測できません。
私が30年見てきた事実から言えるのは、過去20年以上、VB6はOSが変わるたびに「どこかが動かなくなる」を繰り返してきたということです。そして、その傾向は今後も続きます。
2. ActiveXコントロール「クラスが登録されていません」エラー
VB6システムでもっとも頻繁に発生するWindows更新トラブルが、**「クラスが登録されていません」**というエラーメッセージです。これはVB6のActiveXコントロール(画面部品の元になる仕組み)が、Windows更新によって正しく登録されなくなる現象です。
具体的には、印刷ボタンを押したら出るエラー、グリッド表示の画面でアプリが落ちる、特定の画面を開いた瞬間にエラーで止まる、といった症状で現れます。多くの場合、エラーメッセージは「クラスが登録されていません」「実行時エラー'429'」といった形で表示されます。
なぜこうしたエラーが起きるのか。背景にはCOM(Component Object Model)というWindowsの仕組みがあります。VB6はWindows標準のCOMコンポーネントに依存しており、これらはレジストリに登録されている必要があります。Windows更新の際、互換性の問題や設計上の判断から、特定のCOMコンポーネントの登録が解除されたり、別のバージョンに置き換えられたりすることがあるのです。
特に深刻なのが、64bit版Windowsへの移行です。VB6は32bitアプリケーションのため、64bit Windowsでは互換レイヤー(WoW64)を経由して動作します。しかし、ActiveXコントロールの中には64bit環境で正しく動作しないものがあり、これが原因でエラーが発生するケースが増えています。
対応策としては以下の3パターンがあります。
第一に、該当ActiveXコントロールの再登録です。regsvr32コマンドで該当のOCXファイルを再登録すると、エラーが解消する場合があります。ただし、これは応急処置にすぎません。次のWindows更新でまた同じ問題が再発する可能性が高いからです。
第二に、互換モードでの実行です。アプリケーションのプロパティから「以前のバージョンのWindowsとの互換性で実行する」を有効にする方法ですが、これも根本解決ではありません。
第三に、代替コンポーネントへの差し替えです。問題の起きているActiveXを、より新しいまたは安定したコンポーネントに置き換える対応です。これには相応のコード改修が必要になりますが、長期的には最も安定する対応です。
業務上の影響は深刻です。一つのエラーで業務システムの主要機能が停止することがあり、その間は業務が止まります。私の経験では、こうしたトラブルが発生した際、原因特定だけで丸一日かかることもありました。
3. Jet OLEDB 4.0問題: ある日突然データベースに繋がらなくなる
3番目のリスクは、データベースアクセスができなくなる問題です。これは私自身が過去に何度も経験してきた事象で、最初に遭遇したときの戸惑いを今でも覚えています。
「あれ、データベースにアクセスできない」
ある日、いつも通りシステムを動かそうとすると、データベース接続の段階でエラーが出るようになる。調べてみると、データベースへの接続方法そのものが変わっていた、という経験です。
VB6でAccessデータベース(.mdbファイル)を扱う際、多くの業務システムがMicrosoft Jet OLEDB 4.0というデータベースエンジンを使っています。接続文字列にProvider=Microsoft.Jet.OLEDB.4.0と記述するパターンです。
ところが、このJet OLEDB 4.0には深刻な制約があります。32bit版しか提供されていないのです。つまり、64bit版のWindowsで64bit版のアプリケーションから利用しようとすると、繋がりません。32bitアプリケーション(VB6本体)から呼び出す限りは動作しますが、開発環境や周辺ツールが64bit化されると、思わぬところで動かなくなります。
さらに、Microsoftは将来的にJet OLEDB 4.0のサポートを段階的に縮小する方向性を示しています。新しい接続方式である**ACE OLEDB(Microsoft Access Database Engine)**への移行が推奨されていますが、この移行も簡単ではありません。
接続文字列を書き換えるだけで済むケースもあれば、データベースファイル自体を.mdb形式から.accdb形式に変換する必要があるケースもあります。.accdb形式はAccess 2007以降の形式で、より新しい機能を持っていますが、VB6から直接扱うには別途ドライバ(Microsoft Access Database Engine Redistributable)のインストールが必要です。
私が現場で経験したのは、ある日突然「データベース接続エラー」が頻発するようになり、調査してみるとWindows更新でJet OLEDB 4.0関連のセキュリティ更新が入り、接続方法に変更があった、というケースでした。原因を特定するまでに数日を要し、その間業務システムは部分的に停止していました。
対応策は段階的に検討する必要があります。まず短期的には、ACE OLEDBへの接続文字列変更で対応できるか試します。次に、それで解決しない場合は、データベース形式自体の.accdb化を検討します。長期的には、AccessからSQLite、PostgreSQL、MySQLといった他のデータベースへの移行を計画することが望ましいです。
データベース移行は工数のかかるプロジェクトですが、Access依存からの脱却は、Windows更新リスクへの根本的な対策となります。
4. Excel COM連携: バージョン更新で動作が変わる罠
4番目のリスクは、Excel連携機能が動かなくなる問題です。VB6システムの多くは、Excelとの連携機能を持っています。データをExcelに出力したり、Excelの計算結果を取り込んだり、印刷をExcel経由で行ったりする処理です。
これらの連携は典型的にOLEオートメーションという仕組みで実装されています。VB6コードの中にCreateObject("Excel.Application")という記述があれば、これに該当します。Excelをプログラムから起動し、セルに値を書き込んだり、計算を実行させたり、印刷指示を出したりするコードです。
このOLE連携は、Excelのバージョンが変わると動作が変わることがあります。Excel 2003、Excel 2007、Excel 2010、Excel 2013、Excel 2016、Excel 2019、Microsoft 365と進化する中で、メソッドの名前が変わったり、引数の意味が変わったり、戻り値の型が変わったりするケースが発生してきました。
特に深刻なのが64bit版Officeへの移行です。Microsoftは2020年頃から64bit版Officeを標準として推奨するようになり、企業でも徐々に64bit化が進んでいます。しかし、VB6は32bitアプリケーションなので、64bit版Excelとの連携には互換性の問題が発生する可能性があります。
実際に発生する症状としては、印刷時に「クラスが登録されていません」エラーが出る、Excelから戻り値を受け取れない、特定のセル範囲を読み込もうとすると落ちる、といったパターンです。
加えて、マクロ付きExcelファイル(.xlsmや.xls)の扱いも変わってきました。セキュリティ強化の流れで、マクロを含むExcelファイルの読み込みには警告が出たり、デフォルトでマクロが無効化されたりするようになっています。VB6からExcel経由でマクロを動かすような複雑な処理は、特にトラブルが発生しやすい領域です。
対応策としては、まずopenpyxl等のPythonライブラリへの段階的移行が現実解です。VB6からExcelを呼び出している処理を、徐々にPythonスクリプトに置き換えていくアプローチです。openpyxlはPythonのライブラリで、Excelファイル(.xlsx形式)を直接読み書きできます。Excelアプリケーション本体を起動する必要がないため、64bit/32bitの互換性問題からも解放されます。
ただし、すべてのExcel連携をPython化するには工数がかかります。短期的な対応としては、特に問題が発生している箇所のみを優先的に書き換える、という段階アプローチが現実的です。
5. 一人で対応してきた30年の現場感と「いつか必ず来る日」
最後にお伝えしたいのは、技術的な話ではなく、30年間VB6システムと向き合ってきた一人のエンジニアとしての現場感です。
私は社内SEとして、長年VB6システムを一人で対応してきました。Windowsが新しいバージョンに変わるたびに、「動くのか、動かないのか」を確認する作業を繰り返してきました。動かなくなった部分があれば、原因を特定し、修正し、テストし、本番に反映する。これを20年以上続けてきました。
正直に言うと、気が気ではありませんでした。
一人で対応している以上、トラブルが発生した時の責任はすべて自分にかかってきます。「動くはず」と思って本番に反映したら動かなかった、ということが起きれば、業務が止まり、社員の作業が止まり、顧客への影響が出ます。
OSの更新が予定されるたびに、私はまずテスト環境で動作確認を行いました。動かない部分が見つかれば、それを修正します。修正方法を知らない場合、どこに問題があるのか分からず、結果的に大規模な改修を行うこともありました。後から振り返れば、もっと小規模な修正で済んだかもしれない、と思うことも多々ありました。
なぜそうなったか。答えは単純で、情報が少なかったからです。
VB6に関する情報は、特に2008年のサポート終了以降、加速度的に少なくなっています。Stack Overflowで質問しても答えが付かない、書籍も新しいものが出ない、Microsoftの公式ドキュメントも更新されない。一人で問題に立ち向かう時、頼れる情報源が極端に限られているのです。
これは、現在VB6システムを抱えている情シス担当者の方々が、これから直面する可能性のある状況です。今は動いているシステムでも、次のWindows更新で動かなくなった時、対応できる人材が社内にいるでしょうか。外部に依頼しようとしても、VB6を扱える技術者は年々減っています。
私が30年の経験から最も伝えたいことは、**「動かなくなる前に対策を打つ選択肢がある」**ということです。動かなくなってから慌てて対応するのと、動いているうちに計画的に対応するのとでは、コストも精神的な負担も全く違います。
選択肢は大きく3つあります。
選択肢1: 現状を正確に把握する
まず最初に取れる現実的な選択肢は、現在のシステムが「何をしているのか」を正確に把握することです。コードのドキュメント化、データベース構造の整理、リスク評価レポートの作成などです。これがあれば、いざトラブルが発生した時の対応速度が劇的に上がります。
選択肢2: 延命対応で当面動かす
予算や時間の制約で抜本的な対応がすぐに取れない場合、まず動いている状態を維持する延命対応です。Windows更新で起きた問題を都度修正し、業務継続を最優先にする方針です。中長期的な解決ではありませんが、当面の業務を守る現実的な選択肢です。
選択肢3: 計画的にPythonへ移行する
最も根本的な解決策は、Pythonなど現代的な言語への移行です。一気に全システムを移行するのは大きなプロジェクトになりますが、機能単位で段階的に移行する方法もあります。Pythonへの移行は、Windows更新リスクからの完全な解放を意味します。
まとめ: 今動いているうちに、選択肢を持っておく
5つのリスクをまとめます。
１．OSが変わるたびにVBは動かなくなってきた(歴史的事実)
２．ActiveXコントロール登録解除問題(Windows更新の典型的トラブル)
３．Jet OLEDB 4.0でDBアクセス不能(64bit化の影響)
４．Excel COM連携の互換性破壊(Office更新で動作変化)
５．一人で抱える現場の精神的負担(情報不足の中での孤立)
これらは「もし起きるかもしれない」リスクではなく、「いつか必ず起きる」事象です。30年の経験から言えるのは、それが「いつ」かが分からないだけだということです。
現在VB6システムを抱えている情シス担当者の方に、私からお伝えしたいのは次の3点です。
第一に、あなたの不安は正しいということ。「いつか動かなくなる」という漠然とした不安は、技術的に裏付けのある正しい認識です。
第二に、動かなくなる前に取れる選択肢があるということ。現状把握、延命対応、計画的移行という3つの選択肢を、状況に応じて組み合わせる戦略が現実的です。
第三に、一人で抱え込む必要はないということ。30年VB6を扱ってきた立場から、現状把握から計画的移行まで、各フェーズに応じたサポートをご提供しています。
私は現在、ココナラで以下のサービスを提供しています:
・VB6システムの延命・保守対応
・VB6コードの解析・ドキュメント化
・VB6/AccessからPythonへの移行支援
「まず現状を整理したい」「予算ができるまで延命したい」「計画的に移行したい」、それぞれの段階に応じたご相談を歓迎します。
「いつか必ず来る日」が来てから慌てるのではなく、今動いているうちに選択肢を確保しておくこと。それが、30年VB6と向き合ってきたエンジニアからのメッセージです。
最後までお読みいただき、ありがとうございました。
