「VB.netで開発されたシステムのソースコードが残っているが、設計書もドキュメントも一切ない」「担当していたエンジニアが退職してしまい、誰も業務ロジックを理解していない」――こうした深刻な状況に直面している企業からの相談が急増しています。VB.net（Visual Basic .NET）はWindowsアプリケーション開発で広く使われてきた言語ですが、保守できるエンジニアの不足や引き継ぎ問題が発注動機の多くを占めており、リバースエンジニアリングによる仕様書復元・システム刷新の需要は年々高まっています。

本記事では、VB.netのリバースエンジニアリングの進め方について、対象選定から成果物化まで6工程に分けて詳しく解説します。VB6（クラシックVB）との混在システムへの対処、.NET中間言語（IL）を活用した逆コンパイルの特性、GUIアプリ特有の注意点など、VB.net固有のポイントを実務ベースで紹介します。外注を検討している方も、内製でチャレンジしたい方も、この記事を読めばVB.netリバースエンジニアリングの全体像が把握できます。

▼全体ガイドの記事
・VB.netのリバースエンジニアリングの完全ガイド

VB.netのリバースエンジニアリングとは

VB.netのリバースエンジニアリングとは、既存のVB.netアプリケーションを解析し、失われた設計書・仕様書を復元したり、業務ロジックを抽出して新システム開発に活用したりするプロセスです。VB.netは.NETフレームワーク上で動作するため、コンパイル後のバイナリは.NET中間言語（IL：Intermediate Language）として格納されており、他のネイティブバイナリと比べて逆コンパイルによるソースコード復元が比較的容易という大きな特徴があります。

VB.netはC#と同じ.NETランタイム上で動作し、コンパイル後のILコードはILSpyやdnSpyといった逆コンパイラツールで読み取り可能な状態まで復元できます。これはCOBOLやC言語のようなネイティブバイナリとは根本的に異なる点であり、リバースエンジニアリングの難易度という観点では「逆コンパイル自体は容易だが、業務ロジックの解読には高いスキルが必要」というのが実態です。特に注意が必要なのは、VB6（クラシックVB）からVB.netへの移行案件が多く、VB6とVB.netでは言語仕様・実行環境ともに全く異なるため、混在システムの解析では別々の知識体系が必要になります。VB6はCOMベースのネイティブバイナリで動作するのに対し、VB.netは純粋な.NETアプリケーションであり、同一プロジェクト内にVB6コンポーネント（ActiveX DLL等）とVB.netモジュールが混在するシステムでは、COM相互運用（COM Interop）の解析まで対応する必要があり、難易度が格段に上がります。

VB.netのリバースエンジニアリングには大きく3つの用途があります。第一はレガシーシステムのモダナイゼーションです。VB.netで書かれた業務システムの設計書が存在しない、または陳腐化している場合に、既存コードから業務仕様書を復元し、C#への移行や新システム開発の基盤とする用途がもっとも多く見受けられます。C#への移行を見据えたリバースでは、言語変換後の動作保証テストが特に重要になります。

第二は仕様書・ドキュメントの復元です。開発当時のドキュメントが失われたシステムや、引き継ぎが不十分なまま稼働し続けているシステムの業務ロジックを文書化します。第三はセキュリティ脆弱性診断で、自社製品や取引先製品のセキュリティ検証を目的としてコードを解析します。なお、著作権法第30条の4（改正：2018年）により、非享受目的（仕様書復元・セキュリティ調査等）のリバースエンジニアリングは原則合法化されていますが、EULAの確認や法務部門との相談は必須です。

VB.netのリバースエンジニアリングの6工程

VB.netのリバースエンジニアリングは、対象選定から成果物化まで6つの工程で進めるのが標準的です。各工程のゴールと注意点を明確にしておくことで、プロジェクトの迷走を防ぐことができます。

リバースエンジニアリングの成否は、最初の目的設定で8割が決まります。まず「何のためにリバースするのか」を明確にしてください。仕様書の復元が目的なのか、C#への移行に向けた業務ロジック抽出なのか、脆弱性診断なのかによって、解析の深度・成果物の粒度・必要な工数が大きく異なります。次に対象システムのスコープを定義します。VB.netアプリケーションの全モジュールを解析するのか、特定の機能（例：受発注処理、在庫管理）のみを対象にするのかを早期に確定させないと、際限なく工数が膨らむ「スコープクリープ」が発生します。

特にVB.netシステムでは、VB6時代から段階的に移行・改修されてきたケースが多く、フォルダ構成を確認するだけで「これはVB6のActiveX DLLが残っている」「.NET Frameworkのバージョンが複数混在している」といった複雑な事情が判明することがあります。対象選定の段階でシステム全体のファイル構成・依存関係を棚卸しし、VB6コンポーネントとVB.netモジュールの混在状況を把握しておくことが後の工程を大きく左右します。

VB.netの逆コンパイルには、.NET ILを読み取ってVB.netソースに復元できるツールが必要です。代表的なツールとしてはILSpy（オープンソース・無料）、dnSpy（デバッグ機能付き）、dotPeek（JetBrains製・無料）などがあります。これらのツールはいずれも.NET ILからC#やVB.netのソースコードを生成する機能を持っており、元のVB.netコードに近い形でソースを復元できます。ただし、逆コンパイル結果が元のコードと完全に一致するわけではなく、変数名の消失、メソッド名の変換、ラムダ式の展開など、オリジナルと差異が生じることを前提に作業を進める必要があります。

VB6コンポーネントが混在する場合は、VB6バイナリの解析にOllyDbgやx64dbgといったネイティブバイナリ向けデバッガも必要になります。COM相互運用の解析にはOleViewやRegSvr32を使ったインターフェース確認作業も加わります。解析専用の隔離環境（サンドボックス）を用意し、本番環境とは完全に分離した状態で作業することが、法的リスク管理の観点からも重要です。

静的解析では、VB.netの実行ファイル（.exe・.dll）をILSpyなどで逆コンパイルし、復元されたソースコードを精査します。まずナームスペース・クラス・メソッドの全体構造を把握し、モジュール間の依存関係を整理します。次に重要度の高い業務ロジック（受注処理・計算ロジック・データベースアクセス層等）を特定して重点的に解析します。

VB.netのWindowsアプリケーションでは、GUIデザインを定義するPartialクラス（.designer.vbファイル相当のコード）と業務ロジックが同一クラスに混在しているケースが多く、どのコードが画面描画でどのコードが業務処理なのかを分離する作業に相当な時間を要します。Formクラスに数千行のコードが直接書かれているモノリシックな構造も珍しくなく、この「画面定義と業務ロジックの分離が不明確な状態」はVB.netアプリの典型的な構造問題です。静的解析の段階で、UIイベントハンドラと業務ロジックを丁寧に分類し、業務ルールが書かれたメソッドを洗い出すことが後工程の品質を左右します。

動的解析は、実際にアプリケーションを実行させながら処理の流れを追跡する手法です。dnSpyのデバッグ機能を使えば、VB.netアプリケーションのソースが存在しない状態でもブレークポイントを設定してステップ実行が可能になります。静的解析で業務ロジックの概要は把握できても、「この分岐条件が実際にどのケースでどう動くか」「DBから取得したデータがどう変換されるか」といった動的な振る舞いは実行トレースでしか確認できません。

動的解析においては、業務部門の担当者の協力が不可欠です。実際の業務データを使った動作確認、「この画面でこの操作をしたときに何が起きるか」の確認作業は、技術者だけでは完結しません。VB.netシステムの多くはWindowsのGUIアプリケーションであるため、操作シナリオベースで動的解析を進め、画面操作ごとのデータ処理フローを記録していくアプローチが効果的です。また、データベースアクセスについてはSQL Serverプロファイラ等でクエリをキャプチャし、どのデータがどの業務処理で読み書きされているかのデータフロー図を作成します。

静的解析・動的解析で得た情報をもとに、実装レベルの詳細から設計レベル・仕様レベルへと段階的に抽象化する工程です。これをDesign Recoveryと呼びます。具体的には、メソッドレベルの処理フローを「業務フロー図」に変換し、クラス間の関係を「業務エンティティ関連図」として整理し、画面・機能の関係を「画面遷移図」としてまとめます。この工程で作成する成果物の粒度が、後の新システム開発や引き継ぎの質を決定します。

VB.netシステムでは「コードは読めるが業務ルールの意図がわからない」という状況が頻発します。例えば、ある計算式が「なぜその係数を使うのか」「この分岐条件はどのビジネスルールから来ているのか」といったWhy（なぜ）の情報はコードからは読み取れません。この部分は業務部門のキーパーソンへのヒアリングで補完する必要があります。抽象化工程では、コードから読み取れるHowの情報と、業務部門から聞き取るWhyの情報を統合して、初めて使える仕様書が完成します。

最終工程では、解析結果を発注目的に合わせた成果物としてまとめます。成果物の粒度は大きく3段階あります。フローチャートレベルは業務の流れを図示したもので、主要業務の流れを俯瞰するのに適していますが、新システム開発の直接の入力としては情報が不足します。業務仕様書レベルは画面仕様・機能一覧・業務フロー・入出力定義を含む水準で、開発会社へのRFP作成や要件定義の基盤として使用できます。詳細設計書レベルはデータベース設計・API仕様・画面遷移図・テスト仕様まで含む水準で、そのまま開発着手が可能なレベルです。

C#への移行を見据えたVB.netリバースエンジニアリングでは、言語変換後の動作保証テストのための「テストケース仕様書」も重要な成果物となります。業務ロジックが正確に移植されたかを検証するためのテストシナリオを、リバース工程で業務部門と確認しながら作成しておくことで、移行後の品質トラブルを大幅に減らすことができます。

VB.net固有の注意点

VB.netのリバースエンジニアリングには、他言語とは異なるVB.net固有の注意点があります。これらを事前に把握しておくことで、プロジェクトの想定外のコスト増加や品質トラブルを回避できます。

VB.netリバースエンジニアリングでもっとも多い失敗パターンは、「コードは読めたが業務ルールが復元できなかった」というケースです。逆コンパイルでソースコードを取得しても、変数名が意味のない名前（例：var1, tempA）に変換されている、コメントが一切ない、業務ルールを理解しているはずの元開発者が既に退職しているという三重苦の状況が珍しくありません。この結果、新システムに移行したものの業務ロジックの誤解によるバグが多発し、リバース工程でかかったコスト以上の損失が生じるケースがあります。

VB6とVB.netの混在システムにおけるもう一つの典型的な失敗は、VB6コンポーネントを見落とすことです。フォルダ構成を見るとVB.netのプロジェクトファイル（.vbproj）しかないように見えても、実際にはGACに登録されたCOM DLLがVB6で開発されており、それをVB.netから呼び出している構造になっていることがあります。このVB6コンポーネントを解析対象外にしてしまうと、重要な業務ロジックが丸ごと抜け落ちた仕様書が出来上がるリスクがあります。

.NETアプリケーションは逆コンパイルが容易なため、商用製品ではDotfuscatorやConfuserExといった難読化ツールが適用されているケースがあります。難読化が施されたVB.netバイナリでは、クラス名・メソッド名・変数名が意味のない文字列（例：a, b, AA_0x1f2e）に変換され、制御フローが意図的に複雑化されています。このような場合、単純な逆コンパイルでは人間が読める品質のコードは得られません。

難読化されたVB.netコードの解析には、制御フロー解析ツールを使った難読化解除（de-obfuscation）の追加工程が必要になり、工数・費用ともに大幅に増加します。発注前に対象システムが難読化されているかどうかをILSpyで確認し、難読化の程度を見積もりに反映させることが重要です。自社システムの保護を目的とした難読化の場合は、難読化の適用範囲と設定を把握している担当者（システム開発会社や元担当者）に確認するのが近道です。

法的リスクの回避

VB.netのリバースエンジニアリングを行う際には、著作権法・不正競争防止法・EULAへの配慮が不可欠です。法的リスクを正しく理解した上で適切な手順を踏むことで、安全にプロジェクトを進めることができます。

クリーンルーム手法とは、解析チーム（Dirty Room）と開発チーム（Clean Room）を完全に分離し、解析チームが作成した仕様書のみを開発チームに引き渡すことで、著作権侵害（依拠性）を回避する手法です。1980年代にフェニックス・テクノロジーズがIBM BIOSの互換製品を開発した際に確立されたこの手法は、現在でも業務システムのリバースエンジニアリングにおける法的リスク回避の標準的な手法です。具体的には、解析チームと開発チームの間に法務・仲介担当者を配置し、仕様書に著作権保護対象の「表現」が混入していないかを確認した上で引き渡します。

著作権法第30条の4は、情報解析・調査研究・セキュリティ確保等の「非享受目的」のリバースエンジニアリングを適法としています。この適法性を事後的に立証するためには、解析作業の記録を残しておくことが重要です。具体的には、解析専用のパソコンを用意して本番環境・開発環境から隔離した状態で解析を実施し、解析目的・対象・手順・結果をレポートとして記録します。また、VB.netの逆コンパイルで得られたコードを直接コピーして流用するのではなく、業務仕様として抽象化した文書のみを成果物とすることで、依拠性の問題を回避できます。

外注 vs 内製の判断軸

VB.netのリバースエンジニアリングを自社内製で実施するか外注するかの判断は、スキル・リソース・リスク管理の観点から総合的に検討する必要があります。

内製でのリバースエンジニアリングが適しているのは、社内に.NETの深い知識を持つエンジニアが在籍しており、かつ対象システムの業務についても理解があるケースです。また、機密性が極めて高いシステム（個人情報・営業秘密が大量に含まれる等）で社外に情報を出せない場合も、内製を選択せざるを得ないことがあります。ただし、VB.netリバースエンジニアリングの経験がないエンジニアが初めて取り組む場合、学習コスト・試行錯誤のコストが想定を大きく上回るリスクがあります。社内にVB6とVB.netの両方に精通したエンジニアがいない場合は、外注を強くお勧めします。

外注が適しているのは、社内にVB.netリバースエンジニアリングの経験者がいないケース、VB6とVB.netの混在システムで複雑な解析が見込まれるケース、短期間で確実に成果物を出す必要があるケースです。外注先の選定では、VB.net固有の解析実績（特にVB6との混在システム経験）、クリーンルーム手法の運用体制、C#移行案件の経験、成果物の粒度（フローチャートから詳細設計書まで対応できるか）を確認します。費用の目安としては、LOC従量課金で基本料金30万円（4,000行まで）、超過分は1行あたり50円程度が相場です。ただし、VB6との混在や難読化がある場合は割増費用が発生することを前提に見積もりを取得してください。

まとめ

VB.netのリバースエンジニアリングは、対象選定・目的明確化から始まり、ツール準備・静的解析・動的解析・抽象化・成果物化の6工程で進めます。VB.netは.NET ILから逆コンパイルによるソース復元が比較的容易ですが、GUIと業務ロジックの混在、VB6コンポーネントとの混在、難読化への対処など、固有の難しさが存在します。特に「VBで書かれたシステムを保守できるエンジニアが社内にいない」という引き継ぎ問題を発端とした案件では、コード解析だけでなく業務部門へのヒアリングを組み合わせた総合的なアプローチが成功の鍵となります。

C#への移行を見据えたリバースエンジニアリングでは、言語変換後の動作保証テストまで見通した成果物設計が重要です。法的リスク管理においては、クリーンルーム手法の適用と非享受目的の記録保持を徹底することで、安全かつ合法的にプロジェクトを完遂できます。外注を検討する場合は、VB6との混在実績・クリーンルーム体制・成果物粒度の3点を重点的に確認した上で発注先を選定してください。

▼全体ガイドの記事
・VB.netのリバースエンジニアリングの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。