VB6開発環境の構築方法と注意点
VB6で作られた既存システムを保守・改修する場合、ソースコードを確認するだけでなく、VB6の開発環境を用意しなければならないことがあります。
ただし、VB6は現在のWindows環境を前提にした開発ツールではありません。
そのため、Windows 10やWindows 11のパソコンに新しく開発環境を作ろうとすると、インストールで止まる、VB6が起動しない、フォームが開かない、参照設定が不足する、OCXやDLLが見つからない、ビルドできないといった問題が起こることがあります。
また、VB6の開発環境は、単にVisual Basic 6.0をインストールすれば終わりではありません。
既存システムで使っている外部部品、帳票ツール、データベース接続、ODBC設定、参照ライブラリ、プリンタ設定、共有フォルダなども含めて、旧環境をどこまで再現できるかが重要です。
この記事では、VB6開発環境の構築方法と、既存VB6システムを改修・移行する前に確認すべき注意点を整理します。
VB6開発環境とは
VB6開発環境とは、Visual Basic 6.0で作られたソースコードを開き、修正し、ビルドして実行ファイルを作成するための環境です。
一般的には、Visual Basic 6.0またはVisual Studio 6.0に含まれるIDEを指します。
既存のVB6システムでは、次のようなファイルで構成されていることが多くあります。
vbpファイル。
frmファイル。
basファイル。
clsファイル。
frxファイル。
resファイル。
外部OCXやDLL。
帳票定義ファイル。
INIファイルや設定ファイル。
vbpはVB6プロジェクトの中心になるファイルです。
frmは画面、basは標準モジュール、clsはクラスモジュールです。frxにはフォーム上の画像やバイナリ情報が含まれることがあります。
既存システムの改修では、これらのファイルがそろっているかどうかが重要です。
EXEファイルだけが残っていても、通常はVB6で修正・再ビルドすることはできません。
実行環境と開発環境は分けて考える
VB6について相談を受けるとき、よく混同されるのが「実行環境」と「開発環境」です。
実行環境とは、利用者がVB6で作られたアプリを使うための環境です。
EXEファイル、VB6ランタイム、必要なOCX・DLL、データベース接続設定などがあれば動く場合があります。
一方、開発環境とは、ソースコードを開いて修正し、ビルドするための環境です。
VB6のIDE、SP6、参照ライブラリ、外部部品、帳票ツール、開発時ライセンスなどが必要になります。
つまり、利用者のPCでアプリが動いているからといって、そのPCで開発できるとは限りません。
逆に、開発環境があっても、実行環境に必要な部品が不足していれば、作成したEXEが正常に動かないこともあります。
保守・改修を行う場合は、まず「アプリを動かしたいのか」「ソースを修正したいのか」を分けて考える必要があります。
VB6開発環境が必要になる場面
VB6開発環境が必要になるのは、主に既存システムを修正・調査・移行したい場合です。
たとえば、次のような場面です。
Windows 11に変更したらVB6アプリが動かなくなった。
エラーが出る箇所をソースコードから確認したい。
帳票のレイアウトを修正したい。
CSV出力項目を追加したい。
消費税や単価計算などの業務ロジックを変更したい。
Access DBやSQL Serverの接続先を変更したい。
外部部品の依存関係を確認したい。
VB.NETやC#への移行前に現行仕様を調べたい。
このような場合、EXEだけでは対応できません。
ソースコードを開き、コンパイルできる状態にする必要があります。
ただし、古いVB6システムでは、ソースコードが残っていても、当時の開発PCでしかビルドできないことがあります。
そのため、開発環境を新しく構築する前に、旧PCや旧サーバーに残っている環境を確認することが重要です。
VB6開発環境を構築する前に確認すべきこと
VB6開発環境を作る前に、最初に確認すべきことがあります。
特に重要なのは、次の項目です。
インストールメディアが残っているか。
正規のライセンスを確認できるか。
VB6 SP6を適用できるか。
ソースコード一式が残っているか。
vbp、frm、bas、cls、frxなどがそろっているか。
旧PCで現在もビルドできるか。
使用しているOCXやDLLが分かるか。
帳票ツールや外部部品のインストーラーが残っているか。
データベース接続先が分かるか。
本番環境と開発環境の設定が分かれているか。
特に避けたいのは、旧PCを確認せずに初期化・廃棄してしまうことです。
古いVB6システムでは、旧PCの中にしか残っていない情報があります。
たとえば、参照設定、登録済みOCX、ODBC設定、帳票ツール、プリンタ設定、INIファイル、ビルド手順などです。
新しいPCにVB6を入れ直せば再現できると思っていても、外部部品がそろわずにビルドできないことがあります。
そのため、まず旧環境を保全し、現在の状態を把握してから新環境を作る方が安全です。
VB6開発環境の基本的な構築手順
VB6開発環境を構築する場合、大まかな流れは次の通りです。
まず、使用するOSを確認します。
次に、Visual Basic 6.0またはVisual Studio 6.0をインストールします。
その後、VB6 SP6を適用します。
続いて、必要なOCX・DLL・帳票ツールを配置・登録します。
プロジェクトを開き、参照設定やコンポーネント設定を確認します。
最後に、ビルドできるか、作成したEXEが動くかを確認します。
ただし、実務ではこの通りに進まないことも多くあります。
インストール時にエラーが出る。
SP6が適用できない。
プロジェクトを開くとMissingが出る。
フォームを開くと外部部品が不足している。
コンパイルエラーが出る。
ビルドはできても実行時エラーが出る。
帳票だけ出力できない。
このような場合、VB6本体ではなく、外部部品や参照設定、データベース接続、帳票周りが原因になっていることがあります。
Windows 10・Windows 11で構築するときの注意点
VB6は、現在のWindows 10やWindows 11を前提に作られた開発環境ではありません。
そのため、Windows 10やWindows 11へインストールする場合、通常の業務アプリのように簡単に入るとは限りません。
管理者権限、互換性設定、インストールするコンポーネントの選択、SP6の適用、不要な古いコンポーネントの扱いなどに注意が必要です。
また、インストールできたとしても、それだけで安心はできません。
VB6のIDEが起動する。
ソースコードを開ける。
フォームが正常に表示される。
参照設定にMissingがない。
コンパイルできる。
EXEを作成できる。
作成したEXEが実行環境で動く。
ここまで確認して、初めて開発環境として使える状態に近づきます。
特にWindows 11では、OSの更新やセキュリティ設定によって、古い開発環境や外部部品の動作に影響が出る可能性があります。
「一度入ったから大丈夫」ではなく、今後のPC入替や保守継続まで考えておく必要があります。
VB6 SP6を適用する理由
VB6開発環境を構築する場合、SP6の適用は重要な確認ポイントです。
既存のVB6システムが、SP6適用済みの環境で開発・ビルドされていた場合、新しく構築した環境にも同じ更新状態を再現しないと、ビルド結果や動作に差が出る可能性があります。
また、開発者ごとに環境が違うと、あるPCではビルドできるが別のPCではビルドできない、という状態になることがあります。
確認したいのは、次の点です。
旧開発環境にSP6が適用されているか。
新環境にも同じ更新が適用できているか。
プロジェクトの参照設定に差が出ていないか。
外部部品のバージョンが旧環境と同じか。
ビルドしたEXEの動作が旧環境と同じか。
VB6の開発環境では、本体だけでなく、周辺部品のバージョン差が不具合の原因になることがあります。
そのため、旧PCの環境を確認できるうちに、インストール済みの部品や参照設定を記録しておくことが大切です。
OCX・DLL・ActiveXの確認ポイント
VB6の既存システムで特に問題になりやすいのが、OCX・DLL・ActiveXです。
業務システムでは、VB6標準の部品だけでなく、外部コンポーネントが使われていることがあります。
たとえば、次のような部品です。
グリッド表示部品。
カレンダー入力部品。
タブコントロール。
バーコード出力部品。
帳票出力部品。
PDF出力部品。
通信処理用DLL。
独自に作成された共通DLL。
Excel連携用の部品。
これらの部品は、ファイルがあるだけでは使えない場合があります。
Windowsへ登録されていないと、VB6のプロジェクトを開いたときにエラーになります。
32bitのOCXやDLLを登録する場合、64bit Windowsでは登録場所や実行するregsvr32の違いにも注意が必要です。
たとえば、32bit部品はSysWOW64側のregsvr32で登録する必要がある場合があります。
ただし、むやみに登録作業を行うのは避けるべきです。
どの部品が必要なのか、旧PCでどのバージョンが使われていたのか、ライセンスが必要な部品ではないかを確認してから進める必要があります。
特に古い帳票ツールや市販OCXは、提供元がなくなっていたり、インストーラーが残っていなかったりすることがあります。
この場合、開発環境の再現が難しくなり、移行や再構築を検討した方がよいこともあります。
参照設定・コンポーネント設定の確認ポイント
VB6プロジェクトを開いたら、まず参照設定とコンポーネント設定を確認します。
参照設定に「MISSING」や「参照不可」のような状態がある場合、そのままでは正常にビルドできません。
外部ライブラリやデータベース関連の参照が不足している可能性があります。
特に確認したいのは、次のような参照です。
Microsoft ActiveX Data Objects。
Microsoft DAO。
Microsoft Office関連ライブラリ。
Excel関連ライブラリ。
Access関連ライブラリ。
外部帳票ツール。
独自DLL。
共通ライブラリ。
Office連携があるシステムでは、旧PCと新PCでOfficeのバージョンやbit数が違うことで問題が起こる場合があります。
また、ADOやDAOを使ってAccess DBやSQL Serverへ接続している場合、参照設定だけでなく、接続文字列やODBC設定も確認する必要があります。
フォームを開いたときにエラーが出る場合は、画面上で使っているコントロールが不足している可能性があります。
その場合、参照設定だけでなく、コンポーネント設定も確認します。
データベース接続の確認ポイント
VB6開発環境を構築した後、ビルドできてもデータベースに接続できなければ、動作確認はできません。
既存VB6システムでは、次のようなデータベースが使われていることがあります。
Access。
SQL Server。
Oracle。
MySQL。
PostgreSQL。
独自形式のファイル。
CSVや固定長ファイル。
まず、現行システムがどのデータベースを使っているかを確認します。
次に、接続情報がどこに書かれているかを確認します。
ソースコード内に直接書かれている場合もあれば、INIファイルや設定ファイルに書かれている場合もあります。
開発環境で特に注意したいのは、本番データベースへ誤って接続しないことです。
開発中にテストだと思って登録処理を実行したところ、本番データが更新されてしまうと大きな問題になります。
そのため、開発環境ではテスト用DB、テスト用フォルダ、テスト用接続文字列を用意しておく必要があります。
ODBCを使っている場合は、32bit ODBCと64bit ODBCの違いにも注意します。
VB6アプリから参照するのは32bit側のODBC設定であることが多いため、64bit側だけにDSNを作成しても接続できないことがあります。
帳票・印刷機能の確認ポイント
VB6システムでは、帳票や印刷機能が重要な役割を持っていることが多くあります。
請求書、納品書、見積書、発注書、送り状、ラベル、一覧表など、業務で使用する帳票がVB6アプリから出力されている場合、開発環境でも帳票周りの確認が必要です。
確認するポイントは次の通りです。
帳票ツールを使っているか。
帳票用OCXやDLLが必要か。
帳票定義ファイルがどこにあるか。
プリンタ名に依存していないか。
用紙サイズや余白設定に依存していないか。
PDF出力機能が外部部品に依存していないか。
旧PCと新PCで印字位置が変わらないか。
帳票周りは、画面やロジック以上に環境依存が出やすい部分です。
開発環境でビルドできても、帳票出力時にエラーが出ることがあります。
また、出力はできても印字位置がずれる、罫線がずれる、フォントが変わる、バーコードが読めないといった問題が起こることもあります。
特に古い帳票ツールを使っている場合、Windows 11環境での再現が難しいことがあります。
この場合、帳票部分だけを別方式に置き換える、またはシステム全体の移行時に帳票を作り直す検討が必要になることもあります。
ソースコードを開くときの確認ポイント
VB6のソースコードを開くときは、通常はvbpファイルから開きます。
ただし、最初から修正作業に入るのは避けた方が安全です。
まずは、現状のまま開けるか、ビルドできるかを確認します。
確認の流れとしては、次の順番が安全です。
ソースコード一式をバックアップする。
vbpファイルからプロジェクトを開く。
参照設定にMissingがないか確認する。
フォームが正常に開けるか確認する。
コンポーネント不足のエラーがないか確認する。
ソースを変更せずにコンパイルする。
EXEを作成する。
作成したEXEをテスト環境で動作確認する。
この段階で重要なのは、何も変更していない状態でビルドできるかどうかです。
もし現状のソースをそのまま開いただけでエラーが出る場合、ソースの問題ではなく、開発環境の再現不足が原因かもしれません。
逆に、ビルドはできても旧EXEと動作が違う場合、部品のバージョン差や設定差が影響している可能性があります。
VB6開発環境を新しく作る場合のリスク
VB6開発環境を新しく作る場合、いくつかのリスクがあります。
まず、当時と同じ環境を完全に再現できない可能性があります。
古い開発PCには、長年の運用の中で追加されたOCX、DLL、帳票ツール、ODBC設定、プリンタ設定などが入っていることがあります。
新しいPCにVB6本体だけを入れても、同じようにビルドできるとは限りません。
次に、ソースコードが完全ではない場合があります。
vbpファイルはあるが、frmやfrxが足りない。
外部DLLのソースがない。
帳票定義ファイルがない。
共通モジュールが別フォルダにあった。
参照しているファイルが旧PCのローカルパスになっている。
このような状態では、開発環境を作っても正常にビルドできない場合があります。
また、開発者のPCごとに環境差が出るリスクもあります。
複数人で保守する場合は、開発環境の構築手順、使用する部品のバージョン、参照設定、接続先、ビルド手順を記録しておくことが重要です。
旧PCの開発環境を保全すべき理由
VB6開発環境が残っている旧PCは、すぐに初期化・廃棄しない方がよい場合があります。
旧PCには、現在のシステムを保守するための情報が残っている可能性があります。
たとえば、次のような情報です。
インストール済みのVB6環境。
SP6の適用状態。
登録済みOCX。
外部DLL。
帳票ツール。
ODBC設定。
OfficeやAccessのバージョン。
プリンタ設定。
INIファイル。
ビルド時のフォルダ構成。
参照設定。
これらは、新しいPCで開発環境を再構築するときの手がかりになります。
また、旧PCではビルドできるが、新PCではビルドできない場合、旧PCと新PCの差分を調べることができます。
可能であれば、旧PCをそのまま保管する、ディスクイメージを取得する、仮想化できるか検討するなど、後から確認できる状態にしておくと安心です。
開発環境と本番環境を分ける重要性
VB6開発環境を作るときは、本番環境と開発環境を分けることが重要です。
古いVB6システムでは、接続先や出力先がソースコード内に直接書かれている場合があります。
そのまま開発環境で実行すると、本番データベースを更新してしまう可能性があります。
確認したいのは、次のような点です。
接続先DBが本番かテストか。
CSV出力先が本番フォルダではないか。
帳票出力先が本番プリンタではないか。
ログ出力先が本番環境と共通になっていないか。
設定ファイルで接続先を切り替えられるか。
テスト用データを用意できるか。
特に販売管理、在庫管理、請求管理、顧客管理などのシステムでは、開発中の操作が本番データに影響すると大きな問題になります。
開発環境を構築したら、まずテスト用DBやテスト用フォルダを用意し、誤って本番に接続しないようにしてから動作確認を行うべきです。
VB6開発環境を構築しても解決しないケース
VB6開発環境を構築すれば、すべての問題が解決するとは限りません。
次のような場合は、開発環境を作っても保守が難しいことがあります。
ソースコードが不足している。
外部部品が入手できない。
帳票ツールが古く再現できない。
開発環境は作れたがビルドできない。
ビルドできても実行時にエラーが出る。
仕様が分からず修正範囲を判断できない。
担当者が退職して業務ルールが分からない。
一部の機能が長年使われておらず、必要性が判断できない。
このような場合、無理にVB6環境を再現して改修を続けるよりも、必要な機能を整理して再構築した方が安全な場合があります。
特に、今後も長く使う業務システムであれば、開発環境の再現だけを目的にするのではなく、将来的な保守性も含めて判断する必要があります。
VB6からVB.NET・C#へ移行する前の確認ポイント
VB6開発環境を構築する目的が、移行前の調査である場合もあります。
VB.NETやC#へ移行する前には、まず現行システムの内容を整理します。
画面数。
帳票数。
使用しているデータベース。
使用しているOCX・DLL。
CSV取込・出力。
外部システム連携。
バッチ処理。
利用している部署。
現在も使われている機能。
使われていない機能。
VB6からの移行では、ソースコードを変換するだけでは不十分なことが多いです。
画面の作り方、イベント処理、外部部品、帳票、DB接続、エラー処理、ファイル出力などを確認し、どこまで移行するのかを決める必要があります。
すべての機能をそのまま移行するのではなく、現在使っている機能だけを移行する方法もあります。
古いシステムには、過去には使っていたが現在は使っていない機能が残っていることがあるためです。
VB6開発環境を再現できれば、現行仕様を確認しやすくなります。
ただし、再現に時間がかかる場合は、画面やDB、帳票、利用者ヒアリングから仕様を整理して再構築する方が現実的な場合もあります。
VB6開発環境の構築を相談する前に整理したい情報
VB6開発環境の構築や既存システムの改修を相談する場合、事前に次の情報を整理しておくと進めやすくなります。
現在のシステムの用途。
いつ頃作られたシステムか。
現在も使っている部署や人数。
ソースコードの有無。
EXEだけでなくvbp、frm、bas、clsなどが残っているか。
インストールメディアとライセンスの有無。
旧開発PCが残っているか。
旧PCでVB6が起動するか。
旧PCでビルドできるか。
使用しているデータベース。
使用しているOCX・DLL・帳票ツール。
Windows 10やWindows 11で発生しているエラー。
今後もVB6のまま改修したいのか。
VB.NET、C#、Webシステムなどへ移行したいのか。
特に、旧開発PCが残っているかどうかは重要です。
旧PCが残っていれば、参照設定、外部部品、ODBC、帳票、ビルド手順などを確認できます。
旧PCがない場合は、残っているソースコードと実行環境から必要な情報を洗い出す必要があります。
まとめ
VB6開発環境は、既存VB6システムを保守・改修するために必要になることがあります。
ただし、現在のWindows 10やWindows 11環境でVB6開発環境を構築する場合、単にVB6をインストールするだけでは不十分です。
SP6、OCX、DLL、ActiveX、帳票ツール、参照設定、データベース接続、ODBC、プリンタ設定、共有フォルダなど、旧環境に含まれていた要素を確認する必要があります。
また、開発環境と実行環境は別物です。
EXEが動いているからといってソースを修正できるとは限らず、開発環境が作れたからといって本番環境で正常に動くとも限りません。
VB6開発環境を構築する場合は、まず旧PCや旧環境を保全し、ソースコード、ライセンス、外部部品、参照設定、DB接続、帳票周りを整理することが重要です。
今後も長く使う業務システムであれば、VB6環境を再現して延命するだけでなく、VB.NET、C#、Webシステムなどへの移行や再構築も含めて検討するとよいでしょう。