VB6がWindows 11で動かない原因と確認すべきポイント
VB6で作られた業務システムをWindows 11のパソコンで起動しようとしたときに、アプリが立ち上がらない、実行時エラーが出る、特定の画面だけ開かない、帳票が印刷できない、AccessやSQL Serverに接続できないといった問題が起こることがあります。
VB6アプリがWindows 11で動かない場合、原因は一つとは限りません。
「VB6ランタイムが入っていないだけ」と考えがちですが、実際にはOCX・ActiveX・DLL、Accessデータベース、ODBC設定、32bit/64bitの違い、帳票ツール、プリンタ設定、共有フォルダの権限などが関係している場合があります。
また、Windows 10では動いていたアプリでも、Windows 11の新しいパソコンに入れ替えたタイミングで動かなくなることがあります。
これはOSそのものだけでなく、旧PCに入っていた部品や設定が新PCに引き継がれていないことが原因になっているケースもあります。
この記事では、VB6がWindows 11で動かないときに確認すべきポイントを、既存業務システムの保守・改修の視点で整理します。
VB6はWindows 11で動かないことがあるのか
VB6で作られたアプリが、すべてWindows 11で動かないわけではありません。
単純な画面と処理だけで作られているVB6アプリであれば、Windows 11上でも起動する場合があります。
一方で、業務システムとして長年使われてきたVB6アプリでは、外部部品、帳票、データベース、共有フォルダ、プリンタ、古い設定ファイルなどに依存していることが多く、Windows 11の新しい環境で不具合が出ることがあります。
特に注意したいのは、「起動するかどうか」だけで判断しないことです。
起動はするが、登録ボタンを押すとエラーになる。
検索画面は開くが、帳票出力だけできない。
一部の端末では動くが、別の端末では動かない。
Windows 10では動いていたが、Windows 11の新PCでは動かない。
管理者として実行すると動くが、通常起動では動かない。
このようなケースでは、VB6アプリ本体だけでなく、周辺環境を含めて確認する必要があります。
また、VB6の「開発環境」と「実行環境」は分けて考える必要があります。
利用者が業務で使うEXEを動かしたいのか、開発者がVB6のIDEを使って修正・ビルドしたいのかで、確認すべき内容は変わります。
この記事では主に、VB6で作られた既存アプリがWindows 11で動かない場合の確認ポイントを中心に解説します。
VB6がWindows 11で動かない主な原因
VB6アプリがWindows 11で動かない場合、代表的な原因として次のようなものがあります。
VB6ランタイムが不足している。
OCX・ActiveX・DLLが登録されていない。
旧PCに入っていた外部部品が新PCに入っていない。
32bit前提の部品やODBC設定が合っていない。
Accessデータベースに接続できない。
SQL ServerやOracleなどの接続設定が変わっている。
帳票ツールや印刷処理がWindows 11環境で動かない。
共有フォルダや固定パスにアクセスできない。
Program Files配下やCドライブ直下への書き込みが制限されている。
プリンタ名や用紙設定が旧PCと異なっている。
ウイルス対策ソフトやセキュリティ設定にブロックされている。
このように、VB6が動かない原因はランタイムだけではありません。
業務システムでは、画面、データベース、帳票、CSV、ファイル出力、外部連携が一体になっていることが多いため、どのタイミングで止まるのかを確認することが重要です。
まず確認したいエラーの出方
原因を調べる前に、まず「どのように動かないのか」を整理します。
同じ「動かない」でも、内容によって調査する場所が変わります。
たとえば、次のように分けて確認します。
アプリを起動しても何も表示されない。
起動直後にエラーメッセージが出る。
ログイン画面までは開くが、ログイン後に止まる。
特定の画面だけ開かない。
検索はできるが、登録・更新ができない。
印刷や帳票出力だけできない。
CSV取込やCSV出力だけ失敗する。
AccessやSQL Serverへの接続で止まる。
旧PCでは動くが、新PCでは動かない。
実務上は、エラーメッセージの内容も重要です。
「コンポーネントが正しく登録されていません」
「ActiveXコンポーネントはオブジェクトを作成できません」
「実行時エラー 429」
「実行時エラー 339」
「データベースに接続できません」
「ファイルが見つかりません」
「パスが見つかりません」
「権限がありません」
このようなメッセージが出ている場合、どの部品やファイル、どの処理で止まっているのかを切り分ける手がかりになります。
エラー番号やメッセージは、画面のスクリーンショットだけでなく、できれば文字として控えておくと調査しやすくなります。
VB6ランタイムの確認ポイント
VB6アプリを実行するには、実行に必要なランタイムが関係します。
ただし、VB6ランタイムの有無だけで判断するのは危険です。
VB6本体のランタイムがあっても、アプリが使っているOCX、DLL、帳票部品、データベース接続部品が不足していれば、正常に動かないことがあります。
確認すべき点は次の通りです。
旧PCではそのアプリが正常に動いているか。
新PCには同じEXEだけをコピーしたのか。
インストーラーを使ってセットアップしたのか。
必要なOCXやDLLも一緒に配置されているか。
それらの部品がWindowsに登録されているか。
旧PCにだけ入っていた部品がないか。
VB6アプリは、EXEファイルだけをコピーすれば必ず動くとは限りません。
開発時に使われていた部品や、セットアップ時に登録されていた部品が必要になることがあります。
旧PCでは長年の運用の中で必要な部品が入っていたため動いていたが、新PCには入っていないため動かない、というケースは珍しくありません。
OCX・ActiveX・DLLの確認ポイント
VB6アプリがWindows 11で動かない原因として多いのが、OCX・ActiveX・DLLの問題です。
古いVB6システムでは、標準機能だけでなく、外部部品を使って画面や帳票を作っていることがあります。
たとえば、次のような部品です。
グリッド表示部品。
カレンダー入力部品。
帳票出力部品。
バーコード出力部品。
PDF出力部品。
通信処理用DLL。
独自に作成された共通DLL。
OfficeやExcel連携用の部品。
これらの部品は、ファイルが存在するだけでは不十分な場合があります。
Windowsに登録されていないと、VB6アプリから呼び出せないことがあります。
特に、実行時エラー339や429が出る場合は、OCXやActiveXが見つからない、または正しく登録されていない可能性があります。
また、部品によってはライセンスが必要なものもあります。
旧PCでは開発環境や古いインストーラーによって部品が入っていたが、新PCでは同じ部品を用意できないケースもあります。
この場合、単にファイルをコピーして登録するだけでは解決できないことがあります。
提供元がなくなっている部品や、Windows 11での動作を想定していない部品が含まれている場合は、代替部品への置き換えや、画面・帳票部分の改修が必要になることもあります。
Accessデータベースを使っている場合の確認ポイント
VB6の業務システムでは、Accessのmdbファイルをデータベースとして使っているケースがあります。
Windows 11でVB6アプリが動かない場合、アプリ本体ではなくAccessデータベースへの接続で止まっていることがあります。
確認したい点は次の通りです。
mdbファイルの保存場所は変わっていないか。
共有フォルダ上のmdbにアクセスできるか。
接続文字列が旧PCのパスのままになっていないか。
Access Database EngineやODBC設定が必要ではないか。
32bit版と64bit版の違いが影響していないか。
テーブル名やクエリ名が変わっていないか。
ファイルの権限やロック状態に問題がないか。
よくあるのは、旧PCでは「C:\System\Data\main.mdb」にデータがあったが、新PCではフォルダ構成が変わっており、同じパスにファイルが存在しないケースです。
また、共有フォルダ上のmdbを使っている場合、Windows 11のPCからその共有フォルダにアクセスできるか、読み書き権限があるかを確認する必要があります。
Access DBを使った古いVB6システムでは、同時利用やファイル破損、ネットワーク遅延の影響も受けやすいため、Windows 11対応をきっかけに運用方法を見直した方がよい場合もあります。
32bit・64bit環境の確認ポイント
VB6アプリは基本的に32bitアプリとして考える必要があります。
Windows 11の多くは64bit環境ですが、32bitアプリ自体が動かないという意味ではありません。
ただし、32bitアプリから利用する部品、ODBC、Office、Access、外部DLLなどの組み合わせで問題が出ることがあります。
特に注意したいのは、ODBC設定です。
64bit Windowsには、32bit用ODBCと64bit用ODBCがあります。
VB6アプリから参照しているのは32bit側のODBC設定であることが多いため、64bit側にだけDSNを作成しても、VB6アプリから見えないことがあります。
また、OfficeやAccessのbit数も関係することがあります。
旧PCでは32bit版Officeが入っていた。
新PCでは64bit版Officeが入っている。
Access連携やExcel出力でエラーが出る。
このような場合、VB6アプリ側の処理や使用している部品との組み合わせを確認する必要があります。
外部DLLを使っている場合も、32bit前提のDLLかどうかを確認します。
VB6アプリから64bit専用DLLを直接使うことはできないため、古いDLLや外部連携処理がある場合は注意が必要です。
権限・セキュリティ設定の確認ポイント
Windows 11では、古いVB6アプリが前提としていた書き込み場所や実行権限が合わない場合があります。
特に注意したいのは、次のような処理です。
Program Files配下に設定ファイルを書き込んでいる。
Cドライブ直下にログファイルを作成している。
アプリと同じフォルダにデータファイルを出力している。
Windowsのシステムフォルダにファイルを置いている。
管理者権限がないと実行できない処理がある。
旧Windows環境では動いていた処理でも、Windows 11では権限不足で失敗することがあります。
確認方法としては、管理者として実行した場合に動くかを一時的に確認する方法があります。
管理者として実行すれば動く場合、権限や書き込み先が原因になっている可能性があります。
ただし、常に管理者として実行する運用は、セキュリティや管理面で望ましくない場合があります。
根本的には、設定ファイルやログファイルの保存場所を見直す、ユーザーが書き込み可能なフォルダへ移すなどの対応を検討します。
また、ウイルス対策ソフトやセキュリティ製品が、古いEXEや外部DLLをブロックしている場合もあります。
突然起動しなくなった場合や、一部のPCだけで動かない場合は、セキュリティソフトのログや隔離状況も確認します。
ファイルパス・共有フォルダの確認ポイント
VB6の古い業務システムでは、固定パスを前提にしていることがあります。
たとえば、次のようなパスです。
C:\VB6App\Data
C:\Program Files\System
D:\Data
Z:\共有
\server\share\data
Windows 11の新しいPCでは、ドライブ構成、ユーザー名、共有フォルダ、ネットワークドライブの割り当てが旧PCと異なる場合があります。
アプリが固定パスを参照している場合、そのパスが存在しないだけでエラーになることがあります。
特に、ネットワークドライブの割り当てには注意が必要です。
旧PCではZドライブに共有フォルダが割り当てられていた。
新PCではZドライブが割り当てられていない。
UNCパスではアクセスできるが、ドライブ名ではアクセスできない。
利用者ごとにネットワークドライブの割り当てが違う。
このような場合、VB6アプリ側がどのパスを参照しているかを確認する必要があります。
CSV取込、CSV出力、帳票保存、ログ出力、バックアップ処理などは、ファイルパスの影響を受けやすい部分です。
帳票・印刷処理が動かない場合の確認ポイント
VB6アプリでは、帳票や印刷処理で問題が出ることがあります。
画面表示や登録処理は動くのに、印刷ボタンを押すと止まる場合は、帳票ツールやプリンタ設定が原因かもしれません。
確認したい点は次の通りです。
使用している帳票ツールは何か。
帳票用のOCXやDLLが新PCに入っているか。
プリンタ名が旧PCと同じか。
通常使うプリンタが設定されているか。
用紙サイズや余白設定が変わっていないか。
PDF出力機能が外部部品に依存していないか。
ラベルプリンタやドットプリンタなど特殊プリンタを使っていないか。
請求書、納品書、見積書、送り状、ラベルなどを出力しているVB6システムでは、プリンタ名や帳票部品に依存していることがあります。
旧PCではプリンタ名が「Canon XXX」だったが、新PCではドライバ名が変わっている。
旧環境では帳票OCXが入っていたが、新PCには入っていない。
印字位置がずれる。
プレビューは出るが印刷できない。
PDF出力だけ失敗する。
このような場合、アプリ本体ではなく、帳票と印刷周りを重点的に確認します。
データベース接続でエラーが出る場合の確認ポイント
VB6アプリが業務システムとして使われている場合、Access、SQL Server、Oracle、MySQLなどのデータベースに接続していることがあります。
Windows 11で動かない場合、データベース接続が原因になっていることがあります。
確認するポイントは次の通りです。
接続先のデータベースは何か。
接続文字列はどこに書かれているか。
INIファイルや設定ファイルを使っていないか。
ODBC DSNが登録されているか。
32bit側のODBCに設定されているか。
サーバー名やIPアドレスが変わっていないか。
ログインIDやパスワードが変わっていないか。
Windows認証かSQL認証か。
旧PCからは接続できるか。
新PCからサーバーに通信できるか。
VB6システムでは、接続文字列がソースコード内に直接書かれている場合もあれば、INIファイルや設定ファイルに書かれている場合もあります。
新PCへEXEだけをコピーしても、設定ファイルがないと接続できないことがあります。
また、古いODBCドライバやOLE DBプロバイダを使っている場合、Windows 11の新PCに同じドライバが入っていないことがあります。
DB接続エラーが出る場合は、アプリ側だけでなく、接続に必要なドライバや設定も確認します。
Windows 11で一時的に動かす場合の対応
業務上すぐに使う必要がある場合、一時的な対応として次のような方法を試すことがあります。
互換モードで実行する。
管理者として実行する。
旧PCに入っていたランタイムや部品を確認する。
必要なOCXやDLLを確認する。
ODBC設定を旧PCと同じように作成する。
設定ファイルやフォルダ構成を旧PCに合わせる。
プリンタ名や共有フォルダの設定を確認する。
ただし、これらはあくまで一時的な延命策です。
「動いたから問題ない」と判断するのではなく、どの部品に依存して動いているのかを把握しておくことが重要です。
特に、古いPCから必要な部品をコピーして何とか動かしている場合、次のPC入替やWindows更新で再び同じ問題が起こる可能性があります。
また、ソースコードがない、開発環境が再現できない、帳票部品の入手先が分からないといった状態では、今後の改修や障害対応が難しくなります。
動かない原因を調査するときの進め方
VB6アプリがWindows 11で動かない場合は、やみくもに設定を変えるのではなく、順番に確認していくことが大切です。
まず、旧PCでは正常に動くのかを確認します。
旧PCで動く場合は、新PCとの差分を調べます。
次に、新PCでどの時点で止まるのかを確認します。
起動時か。
ログイン時か。
画面を開いたときか。
検索時か。
登録時か。
印刷時か。
CSV取込時か。
終了時か。
止まる場所が分かれば、原因の範囲を絞り込めます。
次に、エラーメッセージとエラー番号を記録します。
VB6の実行時エラーは、原因を探す手がかりになります。
そのうえで、次の情報を洗い出します。
EXEファイルの場所。
設定ファイルの有無。
利用しているOCX・DLL。
データベースの種類。
ODBC設定。
帳票ツール。
プリンタ設定。
CSVやログの出力先。
共有フォルダの場所。
利用者の権限。
業務システムの場合、すべての機能を一度に確認するのではなく、重要機能から優先的に確認します。
たとえば、販売管理であれば、ログイン、得意先検索、商品検索、売上登録、請求書出力、CSV出力など、業務に直結する処理から確認します。
VB6システムをWindows 11で使い続けるリスク
Windows 11で一時的にVB6アプリが動いたとしても、今後も安心して使い続けられるとは限りません。
VB6システムを使い続ける場合、次のようなリスクがあります。
Windows更新やPC入替のたびに不具合が出る可能性がある。
必要なOCXやDLLを再入手できない場合がある。
帳票ツールの提供元がなくなっている場合がある。
開発環境を再現できない場合がある。
ソースコードがあってもビルドできない場合がある。
担当者が退職すると仕組みが分からなくなる。
セキュリティや権限管理の面で運用が難しくなる。
Access DBや共有フォルダ運用に限界が出る。
特に、Windows 11対応をきっかけに初めて問題が表面化した場合、今まで偶然動いていただけで、システムとしてはかなり古い状態になっていることがあります。
古いVB6システムでは、仕様書が残っていない、画面数が多い、使っていない機能が残っている、帳票やCSVが外部業務に影響しているなど、改修前の調査が重要になります。
改修・移行を検討した方がよいケース
次のような場合は、一時的に動かす対応だけでなく、改修や移行を検討した方がよい状態です。
Windows 11の新PCに入れるたびに不具合が出る。
ランタイムやOCXを入れても安定しない。
外部部品の入手先が分からない。
ソースコードはあるがビルドできない。
ソースコードが残っていない。
Access DBの同時利用や容量に不安がある。
帳票やCSVの変更依頼が多い。
担当者しか分からない処理が多い。
今後も機能追加や制度変更対応が必要。
業務上止まると困る重要システムである。
このような場合、Windows 11で無理に延命するだけでは、将来的なリスクが残ります。
もちろん、すぐにすべてを作り直す必要があるとは限りません。
まずは現行システムの調査を行い、どの機能が使われているのか、どの機能が不要なのか、どの部分が外部部品に依存しているのかを整理することが大切です。
VB.NET・C#・Web化など移行先の考え方
VB6システムを今後も使い続ける場合、移行先はいくつか考えられます。
既存のWindowsアプリに近い形で残したい場合は、VB.NETやC#によるWindowsアプリとして再構築する方法があります。
画面構成や操作感を大きく変えずに移行しやすい場合があります。
一方で、複数拠点で利用したい、ブラウザで使いたい、端末ごとのセットアップを減らしたい場合は、Webシステム化も選択肢になります。
また、すべてを一度に移行するのではなく、重要機能から段階的に移行する方法もあります。
たとえば、次のような進め方です。
まず現行VB6システムを調査する。
利用している画面、帳票、CSV、DBを整理する。
Windows 11で動かす必要がある機能を優先する。
不要な機能を除外する。
重要機能だけを先に移行する。
帳票やCSV連携を段階的に置き換える。
VB6からの移行では、単純にソースコードを変換するだけでは不十分なことが多くあります。
業務フロー、データベース、帳票、外部連携、利用者の操作を確認したうえで、移行方針を決める必要があります。
相談前に整理しておきたい情報
VB6アプリがWindows 11で動かない場合、相談前に次の情報を整理しておくと、原因調査や見積もりが進めやすくなります。
現在のシステムの用途。
Windows 11で出ているエラーメッセージ。
旧PCでは正常に動くか。
新PCではどの処理で止まるか。
EXEファイルだけでなくソースコードがあるか。
VB6の開発環境が残っているか。
使用しているデータベースの種類。
Access DB、SQL Server、Oracleなどの接続先。
使用しているOCX・DLL・ActiveX。
帳票ツールや印刷処理の有無。
CSV取込・CSV出力の有無。
利用人数と利用部署。
今後も使い続けたい機能。
不要になっている機能。
特に重要なのは、ソースコードの有無です。
ソースコードがあれば、原因調査や改修、移行の選択肢が広がります。
一方、EXEしか残っていない場合は、動作環境の再現や再構築を含めて検討する必要があります。
また、旧PCがまだ動いている場合は、その環境をすぐに処分しない方がよい場合があります。
旧PCには、必要なOCX、DLL、ODBC設定、帳票部品、プリンタ設定、接続情報などが残っている可能性があるためです。
まとめ
VB6がWindows 11で動かない原因は、VB6ランタイムだけとは限りません。
OCX・ActiveX・DLL、Accessデータベース、ODBC設定、32bit/64bit環境、帳票ツール、プリンタ設定、共有フォルダ、権限、セキュリティ設定など、さまざまな要因が関係します。
まずは、アプリがどの時点で止まるのか、どのエラーが出ているのか、旧PCでは動くのかを整理することが重要です。
一時的に動かすだけであれば、互換モード、管理者実行、必要部品の確認、ODBC設定、フォルダ権限の確認などで解決する場合もあります。
ただし、業務で今後も使い続けるシステムであれば、延命対応だけでは不安が残ります。
Windows 11対応をきっかけに、現行VB6システムの構成、利用状況、外部部品、データベース、帳票、CSV連携を整理し、改修・移行の必要性を検討することが大切です。