VB6の逆コンパイルは可能？ソース紛失時の対応方法
VB6で作られた業務システムを長年使っていると、実行ファイルは残っているものの、ソースコードが見つからないというケースがあります。
たとえば、古い販売管理システム、在庫管理システム、帳票出力ツール、受発注システムなどで、現在も業務では使っているものの、開発当時の担当者が退職していたり、開発会社との契約が終わっていたりして、ソースコードの保管場所が分からないという状況です。
このような場合に、「EXEファイルから逆コンパイルできないか」「ソースコードを復元できないか」と考えることがあります。
結論からいうと、VB6のEXEから何らかの情報を解析できる場合はあります。
しかし、元のソースコードを完全に復元し、そのまま改修に使える状態に戻すことは、基本的に難しいと考えた方がよいです。
逆コンパイルは、あくまで補助的な調査手段です。
ソースコードがないVB6システムを今後も使い続けたい場合は、逆コンパイルだけに頼るのではなく、現行システムの動作調査、関連ファイルの確認、データベース構造の確認、必要機能の整理、再構築や移行の検討まで含めて考える必要があります。
この記事では、VB6の逆コンパイルは可能なのか、分かること・分かりにくいこと、ソースコードを紛失した場合に確認すべきこと、再構築や移行を検討する判断ポイントを解説します。
VB6の逆コンパイルとは
逆コンパイルとは、コンパイル済みの実行ファイルから、元のプログラム構造や処理内容を読み取ろうとする作業です。
VB6の場合、開発時には .vbp、.frm、.bas、.cls などのソースファイルを使います。
これらをコンパイルすると、実行用の .exe や .dll などが作成されます。
通常、利用者が業務で使っているのはEXEファイルです。
しかし、改修や再ビルドを行うには、元のソースコードが必要になります。
逆コンパイルは、このEXEファイルなどから、元の処理を推測しようとする考え方です。
ただし、逆コンパイルをしても、開発者が書いた元のソースコードがそのまま戻るわけではありません。
コメント、変数名、処理の意図、画面ごとの設計思想、業務上の意味までは、基本的に復元できません。
そのため、逆コンパイルは「完全な復元」ではなく、「手がかりを探す作業」と考える方が現実的です。
VB6のEXEからソースコードは復元できるのか
VB6のEXEからソースコードを完全に復元することは、基本的に難しいです。
一部の情報を読み取れる場合はあります。
画面構成の一部、使用している文字列、参照しているDLLやOCX、処理の流れの一部などが確認できることはあります。
しかし、元の開発プロジェクト一式を取り戻せるわけではありません。
たとえば、次のようなものは復元が難しいです。
開発者が付けた変数名。
ソース内のコメント。
処理の目的や業務上の意味。
フォームごとの細かなイベント処理。
仕様書に書かれていた業務ルール。
元のプロジェクト構成。
改修しやすい形のソースコード。
特に業務システムでは、単に処理が分かればよいわけではありません。
なぜその処理をしているのか、どの画面で使われているのか、どの帳票に影響するのか、どのデータベースを更新しているのかまで分からないと、安全に改修することはできません。
そのため、「EXEがあるから逆コンパイルすれば改修できる」と考えるのは危険です。
VB6の逆コンパイルで分かる可能性があること
VB6の逆コンパイルや解析で、ある程度の手がかりを得られる場合があります。
たとえば、次のような情報です。
フォームや画面構成の一部。
使用しているコントロール。
プログラム内に含まれる文字列。
参照しているDLLやOCX。
接続文字列や設定値の手がかり。
エラーメッセージ。
メニュー名やボタン名。
一部の処理の流れ。
外部ファイル名。
データベース名やテーブル名の手がかり。
これらの情報は、ソースコードがない場合の現行調査に役立つことがあります。
たとえば、EXE内に残っている文字列から、どのデータベースに接続しているか、どの帳票を出力しているか、どのファイルを読み書きしているかを推測できる場合があります。
また、古いVB6システムでは、外部OCXやDLLに依存していることが多くあります。
関連ファイルの情報を確認することで、実行環境の再現や移行時の調査に役立つことがあります。
ただし、これらはあくまで手がかりです。
その情報だけで安全に改修できるとは限りません。
VB6の逆コンパイルで分かりにくいこと
逆コンパイルで分かりにくいのは、開発者が意図していた業務仕様です。
業務システムには、画面上では見えにくいルールが多く含まれています。
たとえば、次のようなものです。
締め処理の条件。
請求金額の端数処理。
在庫数の更新タイミング。
CSV出力の項目順。
帳票に出す条件。
特定得意先だけの例外処理。
月末だけ動く処理。
入力値によって分岐する業務ルール。
古い運用に合わせた例外処理。
逆コンパイルで処理の断片が見えたとしても、その意味を正しく理解するには、実際の業務、データ、利用者の操作、帳票、外部連携を確認する必要があります。
また、変数名やコメントが分からないと、処理を読めても意味を取り違えることがあります。
特に、金額計算、日付計算、在庫管理、請求処理などでは、少しの誤解が業務上のミスにつながります。
そのため、逆コンパイルだけで仕様を確定するのは避けた方がよいです。
P-Codeとネイティブコードの違い
VB6のEXEは、コンパイル形式によって解析のしやすさが変わる場合があります。
VB6には、大きく分けてP-Codeとネイティブコードという考え方があります。
P-Codeは、中間コードに近い形式です。
ネイティブコードは、より機械語に近い形式です。
一般的には、P-Codeの方が処理構造を読み取りやすい場合があります。
一方、ネイティブコードは解析しても読みやすい形になりにくく、元のVB6ソースコードに近い形へ戻すことは難しくなります。
ただし、P-Codeであっても完全復元できるわけではありません。
読み取れる情報が多い場合でも、それを業務システムとして改修可能なソース一式に戻せるとは限りません。
結局のところ、コンパイル形式に関係なく、逆コンパイルは補助的な調査手段として考えるのが現実的です。
ソースコードがないVB6システムでまず確認すべきこと
VB6システムのソースコードが見つからない場合、最初に行うべきことは逆コンパイルではなく、開発資産がどこかに残っていないかを確認することです。
まずは、次のものを探します。
.vbp ファイル。.frm ファイル。.bas ファイル。.cls ファイル。.frx ファイル。
開発用フォルダ。
古い共有フォルダ。
バックアップHDD。
旧サーバー。
退職者が使っていたPC。
保守会社から受領した納品物。
インストーラー。
セットアップ媒体。
仕様書。
操作マニュアル。
テストデータ。
VB6の開発プロジェクトでは、複数のファイルが一式で存在していることが多いです。
EXEだけでなく、プロジェクトファイルやフォームファイル、標準モジュール、クラスモジュールなどが残っていないか確認します。
古いシステムでは、正式なドキュメントフォルダではなく、担当者のPCや共有フォルダの深い階層に開発資産が残っていることもあります。
また、バックアップソフトやNAS、外付けHDD、古いサーバーに残っている場合もあります。
逆コンパイルを検討する前に、まずは開発資産の捜索を行うことが重要です。
逆コンパイルより先に確認したい関連ファイル
ソースコードが見つからない場合でも、EXE以外の関連ファイルが残っていることがあります。
たとえば、次のようなファイルです。
DLL。
OCX。
INIファイル。
設定ファイル。
MDBファイル。
SQL Serverの接続情報。
帳票定義ファイル。
CSVテンプレート。
ログファイル。
マスタデータ。
インストール用のフォルダ。
これらは、システムの動作を理解するための手がかりになります。
特に、VB6システムではOCXやDLLを利用していることがあります。
画面部品、帳票ツール、通信処理、バーコード、グリッド表示などで外部コンポーネントを使っている場合です。
ソースコードがなくても、実行環境にどの部品が必要かを確認できれば、現行システムの維持や再構築時の調査に役立ちます。
また、INIファイルや設定ファイルには、データベース接続先、ファイル出力先、プリンタ名、共有フォルダパスなどが記載されていることがあります。
これらは逆コンパイルしなくても確認できる重要な情報です。
ソースコードが見つからない場合の現実的な対応方法
ソースコードが見つからない場合は、いくつかの対応方法があります。
まずは、現行システムの動作を調査します。
実際に画面を操作し、どの機能があるか、どの帳票が出るか、どのデータを更新しているかを確認します。
次に、画面と機能を一覧化します。
メニュー、入力画面、検索画面、印刷画面、マスタメンテナンス、集計処理などを洗い出します。
さらに、帳票やCSV出力を確認します。
どの帳票が業務上必要なのか、どのCSVが外部システムに渡されているのかを整理します。
データベースがある場合は、テーブル構造やデータ内容も確認します。
Access、SQL Server、Oracleなど、どのデータベースを使っているかを確認し、テーブル名や項目名、更新タイミングを調べます。
そのうえで、必要に応じてEXEや関連ファイルから手がかりを探します。
逆コンパイルや解析は、その一部として使う位置づけです。
つまり、対応の流れは次のようになります。
開発資産を探す。
関連ファイルを確認する。
現行システムの動作を調査する。
画面・帳票・CSV・DBを整理する。
EXEから分かる範囲を補助的に確認する。
改修できるか、再構築すべきか判断する。
いきなり逆コンパイルから入るよりも、この流れの方が現実的です。
逆コンパイル結果をもとに改修するリスク
逆コンパイルで何らかのコードや構造が見えたとしても、それをそのまま改修に使うにはリスクがあります。
まず、読み取れた内容が正確とは限りません。
元のソースコードとは違う形で表示されることがありますし、処理の意味を正しく判断できない場合があります。
また、コメントや変数名がないため、処理の意図が分かりにくくなります。
業務仕様を誤解したまま修正すると、画面上は動いているように見えても、帳票やデータ更新に影響が出ることがあります。
さらに、一部だけ修正しても、他の箇所に影響する可能性があります。
古いVB6システムでは、グローバル変数、共通モジュール、画面間の値渡し、外部ファイルの読み書きなどが複雑に絡んでいることがあります。
逆コンパイルで得た情報だけを頼りに修正すると、次のような問題が起こりやすくなります。
改修範囲が判断できない。
テストすべき箇所が分からない。
業務ロジックの意味を誤解する。
エラーの原因を追いきれない。
将来的な保守性が改善しない。
再度同じ問題が起きる。
短期的に一部の手がかりを得ることはできても、長期的な保守体制を考えると、逆コンパイルだけに依存するのはおすすめできません。
再構築を検討した方がよいケース
ソースコードがないVB6システムでは、再構築を検討した方がよいケースがあります。
たとえば、次のような場合です。
ソースコードが完全に失われている。
開発環境も残っていない。
EXEしか残っていない。
逆コンパイル結果だけでは仕様が分からない。
今後も継続して改修予定がある。
Windows 11対応も必要になっている。
帳票や外部連携が多い。
現行システムの保守担当者がいない。
業務フロー自体も古くなっている。
周辺でExcelや手作業が増えている。
このような場合、無理に逆コンパイル結果から改修するよりも、現行システムの動きを確認したうえで、必要な機能を再構築する方が安全なことがあります。
再構築といっても、すべてを一度に作り直す必要はありません。
重要な機能から段階的に作り直す方法もあります。
たとえば、まずは帳票出力だけを新しくする。
CSV連携だけを作り直す。
マスタ管理だけをWeb化する。
月次処理だけを再構築する。
現行システムを残しながら、一部機能を外出しする。
このように、業務への影響を抑えながら段階的に進める方法もあります。
VB6システムを再構築する場合の進め方
VB6システムを再構築する場合は、最初に現行システムの利用状況を確認します。
どの部署が使っているのか。
何人が使っているのか。
毎日使っているのか。
月末だけ使っているのか。
どの帳票が必要なのか。
どの機能はもう使っていないのか。
古いシステムでは、画面は多いものの、実際に使っている機能は一部だけということがあります。
逆に、目立たない機能が重要な締め処理に使われていることもあります。
そのため、まずは使っている機能と使っていない機能を分けます。
次に、画面・帳票・CSV・データベースを整理します。
画面一覧、帳票一覧、CSV一覧、テーブル一覧を作ることで、再構築の範囲を把握しやすくなります。
そのうえで、必要な機能だけを仕様化します。
古い画面をそのまま再現するのではなく、現在の業務に合わせて残す部分と見直す部分を分けます。
移行先としては、VB.NET、C#、Webシステム、Access、Excel連携、パッケージソフトなどが候補になります。
どれを選ぶかは、業務内容、利用人数、拠点数、今後の改修予定によって変わります。
最後に、旧システムとの結果比較を行います。
特に、金額計算、日付計算、締め処理、帳票、CSV、データベース更新は重点的に確認します。
移行先の選択肢
ソースコードがないVB6システムを今後も使う場合、移行先はいくつか考えられます。
一つは、VB.NETやC#によるWindowsアプリとして再構築する方法です。
現在の画面操作に近い形を残しやすく、社内PCで利用する業務システムに向いている場合があります。
もう一つは、Webシステム化する方法です。
ブラウザから利用できるようにすることで、端末ごとのインストール負担を減らしやすくなります。
複数拠点で利用する場合や、将来的に運用しやすい形にしたい場合に検討できます。
また、システム全体を作り直すのではなく、一部機能だけを置き換える方法もあります。
たとえば、帳票出力だけ、CSV取込だけ、マスタ管理だけを切り出す方法です。
場合によっては、パッケージソフトやSaaSへ置き換える方がよいこともあります。
自社独自の処理が少なく、一般的な販売管理や在庫管理で代替できる場合は、すべてを個別開発で作り直す必要はありません。
重要なのは、逆コンパイルできるかどうかだけで判断しないことです。
今後そのシステムを何年使うのか、どこまで改修が必要なのか、誰が保守するのかを考えたうえで移行先を決める必要があります。
ソース紛失時に見積もり前に整理したい情報
VB6システムのソースコードがない状態で相談する場合、事前に整理しておくとよい情報があります。
現在使っているEXEファイル。
関連フォルダ一式。
DLLやOCXなどの関連ファイル。
設定ファイル。
データベース。
使用しているPCやサーバー環境。
画面数。
帳票数。
CSV出力の有無。
外部システム連携の有無。
利用部署。
利用人数。
現在困っていること。
今後も残したい機能。
使っていない機能。
希望する移行先。
希望時期。
すべてが分かっていなくても問題ありません。
ただし、EXEだけでなく、実行に必要なフォルダ一式やデータベース、設定ファイルがあると、調査の精度が上がります。
また、実際にシステムを使っている担当者から、どの機能を使っているかを聞いておくことも重要です。
ソースコードがない場合、利用者の操作や業務フローが仕様を把握する大きな手がかりになります。
法的・契約上の注意点
VB6の逆コンパイルを考える場合は、法的・契約上の注意も必要です。
自社で開発したシステムなのか。
開発会社に依頼して作ったシステムなのか。
ソースコードの権利がどこにあるのか。
契約上、解析や改修が許されているのか。
第三者製ソフトではないか。
ライセンス違反にならないか。
これらを確認せずに解析を進めるのは避けるべきです。
特に、他社が権利を持つソフトウェアや、購入した市販ソフトを無断で解析することは問題になる可能性があります。
業務上必要な調査であっても、自社が権利を持つシステムかどうか、契約上問題がないかを確認したうえで対応することが大切です。
まとめ
VB6の逆コンパイルによって、EXEファイルから一部の情報を確認できる場合はあります。
しかし、元のソースコードを完全に復元し、そのまま改修に使える状態へ戻すことは基本的に難しいと考えた方がよいです。
逆コンパイルで分かる可能性があるのは、画面構成の一部、文字列、参照ファイル、処理の手がかりなどです。
一方で、変数名、コメント、業務仕様、開発者の意図、改修しやすいプロジェクト構成までは戻りません。
ソースコードを紛失した場合は、まず開発資産やバックアップを探すことが重要です。.vbp、.frm、.bas、.cls、.frx などのファイル、旧PC、旧サーバー、共有フォルダ、外付けHDD、保守会社からの納品物を確認します。
それでもソースが見つからない場合は、現行システムの動作、画面、帳票、CSV、データベース、関連ファイルを調査し、必要な機能を整理します。
逆コンパイルは、あくまで補助的な調査手段です。
今後も長く使う業務システムであれば、無理にEXEから改修しようとするのではなく、再構築やVB.NET・C#・Webシステムへの移行も含めて検討することをおすすめします。