VB.netのリバースエンジニアリングは、対象選定と目的の明確化から成果物化まで、6つの工程で進めるのが標準的です。保守できるエンジニアの不足や引き継ぎ問題を背景に相談が増えており、VB6との混在や逆コンパイルの特性など、VB.net固有の注意点もあわせて工程ごとに説明します。
▼全体ガイドの記事
・VB.netのリバースエンジニアリングの完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
VB.netのリバースエンジニアリングの概要
VB.netのリバースエンジニアリングは、既存のVB.netアプリケーションを解析して、失われた設計書や仕様書を復元したり、業務ロジックを取り出して新システムの開発に活かしたりする作業です。
VB.netは.NETフレームワーク上で動作し、コンパイル後のバイナリは.NET中間言語（IL：Intermediate Language）の形で格納されています。このため、他のネイティブバイナリと比べて逆コンパイルでソースコードを復元しやすいという、大きな特徴があります。
他言語との違い・特性
VB.netは、COBOLやC言語のようなネイティブバイナリとは根本的に異なる特性を持ちます。VB6とVB.netは言語仕様も実行環境も全く異なるため、混在システムの解析には別々の知識体系が必要です。VB6はCOMベースのネイティブバイナリで動作するのに対し、VB.netは純粋な.NETアプリケーションです。
- 逆コンパイルのしやすさ：VB.netはC#と同じ.NETランタイム上で動作し、ILコードはILSpyやdnSpyで読める状態まで復元できます。
- 業務ロジックの解読：逆コンパイル自体は容易でも、読み解くには高いスキルが必要です。
- 移行案件の多さ：VB6（クラシックVB）からVB.netへの移行案件が多く、特に注意が必要です。
- COM相互運用の解析：同一プロジェクト内にVB6コンポーネントが混在すると、COM Interopまで対応が必要になり、難易度が格段に上がります。
主な用途（レガシー移行・脆弱性診断・仕様書復元）
VB.netのリバースエンジニアリングには大きく3つの用途があります。第一はレガシーシステムの刷新（モダナイゼーション）で、設計書が存在しないか古くなっている業務システムについて、既存コードから業務仕様書を復元し、C#への移行や新システム開発の基盤にする用途が最も多く見られます。C#へ移行する場合は、言語変換後の動作保証テストが特に重要になります。
第二は仕様書・ドキュメントの復元です。開発当時の資料が失われたシステムや、引き継ぎが不十分なまま稼働し続けているシステムの業務ロジックを文書にまとめます。第三はセキュリティ脆弱性診断で、自社製品や取引先製品のセキュリティ検証を目的としてコードを解析します。
なお、著作権法第30条の4（改正：2018年）により、非享受目的（仕様書復元・セキュリティ調査等）のリバースエンジニアリングは原則として合法とされています。ただし、EULAの確認や法務部門との相談は欠かせません。
VB.netのリバースエンジニアリングの6工程
VB.netのリバースエンジニアリングは、対象選定から成果物化まで6つの工程で進めるのが標準的です。各工程のゴールと注意点を先に決めておけば、プロジェクトの迷走を防げます。
- 工程1：対象選定と目的の明確化
- 工程2：解析環境とVB.net特化ツールの準備
- 工程3：逆コンパイルと静的解析
- 工程4：デバッガと実行トレースによる動的解析
- 工程5：実装から設計・仕様への抽象化
- 工程6：仕様書や新システム設計書の成果物化
工程1：対象選定・目的明確化
リバースエンジニアリングの成否は、最初の目的設定で8割が決まります。仕様書の復元か、C#への移行に向けた業務ロジックの抽出か、脆弱性診断かによって、解析の深さや成果物の粒度、必要な工数が大きく変わるため、まずは目的をはっきりさせます。
VB.netアプリケーションの全モジュールを解析するのか、受発注処理や在庫管理など特定の機能だけを対象にするのかは、早期に確定させる必要があります。決めないまま進めると、際限なく工数が膨らむ「スコープクリープ」が起きます。
VB.netシステムには、VB6時代から段階的に移行・改修されてきた案件も多くあります。こうした案件では、フォルダ構成を見るだけで「これはVB6のActiveX DLLが残っている」「.NET Frameworkのバージョンが複数混在している」といった事情が判明することもあります。対象選定の段階でファイル構成と依存関係を洗い出し、混在状況を把握しておくことが、後の工程を大きく左右します。
工程2：解析環境・ツール準備（VB.net特化ツール）
VB.netの逆コンパイルには、.NET ILを読み取ってVB.netのソースに復元できるツールが必要です。代表的なものは、ILSpy（オープンソース・無料）、dnSpy（デバッグ機能付き）、dotPeek（JetBrains製・無料）などです。
これらのツールは、.NET ILからC#やVB.netのソースを生成する機能を持っており、元のコードに近い形でソースを復元できます。ただし、変数名の消失、メソッド名の変換、ラムダ式の展開などが起きるため、元のコードとは差異がある前提で作業を進める必要があります。
VB6コンポーネントが混在する場合は、VB6バイナリの解析にOllyDbgやx64dbgといったネイティブバイナリ向けデバッガも必要になります。さらに、COM相互運用の解析では、OleViewやRegSvr32を使ったインターフェース確認作業も加わります。解析専用の隔離環境（サンドボックス）を用意し、本番環境とは完全に分離して作業することは、法的リスク管理の観点からも欠かせません。
工程3：静的解析（逆コンパイル・逆アセンブル）
静的解析では、VB.netの実行ファイル（.exe・.dll）をILSpyなどで逆コンパイルし、復元されたソースを精査します。まず、ネームスペース・クラス・メソッドの全体構造を把握して、モジュール間の依存関係を整理します。次に、受注処理や計算ロジック、データベースアクセス層など重要度の高い業務ロジックを特定し、重点的に解析します。
VB.netのWindowsアプリケーションでは、GUIデザインを定義するPartialクラス（.designer.vbファイル相当のコード）と業務ロジックが同じクラスに混在しているケースが多くあります。そのため、画面描画のコードと業務処理のコードを切り分ける作業に、相当な時間がかかります。
Formクラスに数千行のコードが直接書かれたモノリシックな構造も珍しくありません。この「画面定義と業務ロジックの分離が不明確な状態」は、VB.netアプリに典型的な構造上の問題です。静的解析の段階で、UIイベントハンドラと業務ロジックを分類し、業務ルールが書かれたメソッドを洗い出すことが、後工程の品質を左右します。
工程4：動的解析（デバッガ・実行トレース）
動的解析は、実際にアプリケーションを実行させながら処理の流れを追跡する手法です。dnSpyのデバッグ機能を使えば、ソースがない状態でもブレークポイントを設定して、ステップ実行できます。
静的解析で業務ロジックの概要はつかめても、分岐条件が実際にどう動くか、DBから取得したデータがどう変換されるかといった振る舞いは、実行トレースでしか確認できません。そのため、業務部門の担当者の協力が不可欠です。実際の業務データで「この画面でこの操作をしたときに何が起きるか」を確認する作業は、技術者だけでは完結しません。
VB.netシステムの多くはWindowsのGUIアプリケーションであるため、操作シナリオに沿って動的解析を進め、画面操作ごとのデータ処理の流れを記録していくのが効果的です。また、データベースへのアクセスは、SQL Serverプロファイラなどでクエリを取得し、どのデータがどの業務処理で読み書きされているかを示すデータフロー図を作成します。
工程5：抽象化（Design Recovery：実装→設計→仕様）
静的解析と動的解析で得た情報をもとに、実装の詳細から設計、仕様へと段階的に抽象化する工程です。これをDesign Recoveryと呼びます。具体的には、メソッドの処理フローを「業務フロー図」に、クラス間の関係を「業務エンティティ関連図」に、画面と機能の関係を「画面遷移図」に整理します。
VB.netシステムでは「コードは読めるが業務ルールの意図がわからない」という状況が頻発します。たとえば、ある計算式が「なぜその係数を使うのか」、分岐条件が「どのビジネスルールから来ているのか」といったWhy（なぜ）の情報は、コードからは読み取れません。
この部分は、業務部門のキーパーソンへのヒアリングで補う必要があります。抽象化の工程では、コードから読み取れるHowの情報と、業務部門から聞き取るWhyの情報を統合して、初めて使える仕様書になります。また、この工程で作る成果物の粒度が、後の新システム開発や引き継ぎの質を決めます。
工程6：成果物化（仕様書・新システム設計）
最終工程では、解析結果を発注の目的に合わせた成果物にまとめます。成果物の粒度は大きく3段階あります。
フローチャートレベルは業務の流れを図示したもので、主要業務の流れを俯瞰するのに適しています。ただし、新システム開発の直接の入力としては情報が不足します。業務仕様書レベルは、画面仕様と機能一覧を含み、業務フローや入出力定義まで扱う水準で、開発会社へのRFP作成や要件定義の基盤として使えます。
詳細設計書レベルは、データベース設計やAPI仕様を含み、画面遷移図やテスト仕様まで揃った水準で、そのまま開発に着手できます。C#への移行を見据える場合は、言語変換後の動作保証テストに使う「テストケース仕様書」も重要な成果物になります。移植後の業務ロジックを検証するテストシナリオは、リバース工程で業務部門と確認しながら作っておくと、移行後の品質トラブルを大きく減らせます。
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は、情報解析・調査研究・セキュリティ確保などを目的とした「非享受目的」のリバースエンジニアリングを適法としています。ただし、その適法性を後から示せるよう、解析作業の記録を残しておくことが大切です。
実務では、解析専用のパソコンを用意し、本番環境や開発環境から分離した状態で解析を行い、解析の目的と対象、手順、結果をレポートに記録します。また、逆コンパイルで得たコードを直接流用せず、業務仕様として抽象化した文書だけを成果物にすれば、依拠性の問題を避けられます。
外注 vs 内製の判断軸
自社で内製するか外注するかは、スキル・リソース・リスク管理の観点から総合的に判断する必要があります。
内製が適しているケース
内製が適しているのは、社内に.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は逆コンパイルでソースを復元しやすい一方、GUIと業務ロジックの混在、VB6コンポーネントとの混在、難読化への対処など、固有の難しさもあります。
特に、「VBで書かれたシステムを保守できるエンジニアが社内にいない」という引き継ぎ問題から始まる案件では、コード解析に加えて業務部門へのヒアリングを組み合わせることが、成否を分けます。C#への移行を見据える場合は、言語変換後の動作保証テストまで見通して成果物を設計します。
法的リスクへの備えとして、クリーンルーム手法を使い、非享受目的の記録を残しておけば、安全かつ合法的にプロジェクトを完遂できます。外注を検討する場合は、VB6との混在実績、クリーンルーム体制、成果物の粒度の3点を重点的に確かめたうえで、発注先を選んでください。
▼開発を相談する前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。