VB.netのリバースエンジニアリングの発注/外注/依頼/委託方法について

VB.netのリバースエンジニアリングは、事前準備、発注先の選定、RFP作成と契約、プロジェクト推進の順に進めます。

通常の開発と違い、発注側が積極的に関わらなければ品質が担保されません。中でもVB.netとVB6の違いを正しく理解しているかどうかが、プロジェクトの成否を大きく左右します。

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

VB.netリバースエンジニアリングを外注する前の準備

4つの準備領域を揃えると、見積もりや成果物の認識を合わせやすくなります。

VB.netのリバースエンジニアリングを成功させるには、発注側の事前準備が欠かせません。ベンダー選定や発注作業に入る前に、対象システムの資産状況を正確に把握し、目的と成果物要件を明確にし、業務部門の協力体制を確保しておく必要があります。この準備が不十分だと、見積もりに大きな食い違いが生じ、成果物の品質に不満が残りやすくなります。

資産状況：ソース、プロジェクト、ファイル数、行数の概算
成果物要件：解析で明らかにしたい業務ルールと納品物
協力体制：業務部門で確認や判断を担う担当者

対象システム資産の棚卸

対象システムのソース資産は、プロジェクトの構成、規模、LOCの内訳から洗い出します。

プロジェクト構成：VB.netプロジェクト（.vbprojファイル）の一覧とソリューション構成
規模：ファイル数と行数の概算
LOCの内訳：業務ロジック部分のLOCと、全LOC（デザイナーコード含む）

Visual StudioのWindowsフォームアプリケーションは、デザイナーが自動生成するコードがLOCに大量に含まれます。そのため、この区別がないと、LOC従量課金で取った見積もりとベンダーの認識が大きくずれます。

次に、既存のドキュメント資産を確認します。古い設計書や画面仕様書、フローチャートがあれば、古くても手元に残しておくことで、ベンダーの解析精度が上がり、工数も抑えられます。こうした情報を事前にまとめてベンダーに渡すと、見積もりの精度と解析の品質の両方が上がります。

ドキュメントがない場合は、次の履歴が業務ロジックの変遷を追う手がかりになることがあります。

変更履歴：Gitコミット履歴、SVNログ等
課題管理の履歴：Redmine、JIRA等のチケット履歴

VB6混在確認と言語仕様の違いの理解

VB.netのリバースエンジニアリング発注で、最も見落とされやすく、影響も大きいのが「VB6との混在」です。VB.netとVB6は名前こそ似ていますが、言語仕様は全く異なります。VB6はCOMベースのランタイムで動くインタープリタ言語で、VB.netは.NET CLRランタイム上で動くコンパイル言語です。

エラーハンドリングとオブジェクト指向の実装方式、データ型の扱いは、それぞれ根本的に異なります。さらに、API呼び出しの方式も違うため、両者が混在するシステムは解析の難易度が格段に上がります。特に、COM相互運用（COMインターオペラビリティ）でVB6コンポーネントを.NETのコーラーから利用しているシステムは、解析に特別な工数が必要です。

VB6との混在は見積もりとツール選定に響くため、発注前に、COM DLLの有無や追加費用の決め方、.NET Frameworkの版を押さえておきます。

COM DLLの有無：GACに登録されたCOM DLL（.vbp・.cls・.bas・.frm形式）の有無を確認し、ベンダーへ伝える
追加費用の算定方法：VB6コンポーネントが後から見つかった場合に備えて、契約時に決めておく
.NET Frameworkのバージョン：.NET 2.0〜4.8 / .NET 5以降のどちらを使っているかが、対応するリバースツールの選定に影響する

VB.netとVB6の違いを発注側が正確に把握しておくことが、プロジェクトの成否を分ける第一歩です。

目的と成果物要件の明確化

「なぜリバースエンジニアリングをするのか」を明確にすると、成果物の粒度や品質基準、スコープが定まります。目的は大きく3つに分けられます。

引き継ぎ問題の解決：担当者の退職後に誰も業務ロジックを理解していない状態を解消するため、仕様書を復元する
C#等への移行準備：VB.netからC#への移行を見据えて、業務ロジックを文書化する
セキュリティ診断：自社製品の脆弱性を特定する解析。成果物はセキュリティレポートになり、解析の観点も業務仕様書とは別になる

この目的なら、業務仕様書レベルの成果物が最低限必要です。機能一覧と業務フローに加え、画面仕様と入出力定義も含みます。

C#移行を想定する場合は特に注意が必要で、業務仕様書を作るだけでは足りません。詳細設計書レベルの成果物を求めるとともに、言語変換後の動作保証テスト費用を見積もりに明示させることが大切です。

VB.netからC#への変換ツールによる自動変換は、技術的には可能です。ただし、変換後のコードが「若手エンジニアで保守可能な品質か」を、保守性の観点から必ず確認する必要があります。逆コンパイルで得た変数名のない断片的なコードをそのまま転記した仕様書は、C#移行の要件定義には使えません。

ポイント

発注前に、ソース資産の規模とVB6コンポーネント、.NET Frameworkのバージョンを把握しておくと、見積もりの食い違いを減らせます。業務ロジックLOCと全LOCを分けて数えてあるかが、判断の目安になります。

発注先の選定

技術実績と運用体制を合わせて見る構成です。

VB.netのリバースエンジニアリングの発注先には、通常のシステム開発会社やセキュリティ専門企業など複数の候補があります。そのため、対象システムの特性に合わせて、適切な発注先を選びます。特に、VB.net固有の対応実績とクリーンルーム運用体制の有無は、最優先で確認したいポイントです。

VB.net対応実績の確認ポイント

発注先候補には、VB.net固有の対応実績を必ず確認してください。まず、「VB.net（VB6ではなく）のリバースエンジニアリングを過去に実施したか」を直接確かめます。VB6のリバース実績はあってもVB.netは初めてというベンダーは、.NET CLRの逆コンパイル特性を正しく理解していない可能性があります。

VB.netは、ILSpy・dnSpy・JetBrains dotPeekといった.NET専用の逆コンパイラで、比較的ソースに近い形まで復元できます。一方で、GUIとビジネスロジックが混在したWindowsフォームのコードを読み解くには、特有のノウハウが必要です。

そのうえで、次の実績を確認します。

VB6混在システム：COM相互運用（COMインターオペラビリティ）の解析経験。発注先の技術力を測る重要な指標です
成果物の粒度：フローチャートのみか、業務仕様書レベルか、詳細設計書レベルか。事前に確かめておくと、納品後の品質不満を防げます
C#移行の実績：C#への言語変換の経験と動作検証の実績（C#移行を前提とする場合）
変換後コードの保守性：変数名復元、コメント生成、業務ロジックの背景ドキュメント化まで対応できるかが、長期的な成否を左右します

実績を確かめるには、過去の成果物サンプル（機密情報を除いたもの）の提示を依頼すると効果的です。

クリーンルーム運用体制の見極め

発注先を選ぶ際は、クリーンルーム手法を自社のプロセスとして実際に運用できる体制があるかを確かめます。法的リスク管理の観点から欠かせない確認です。体制が整っていないベンダーに発注すると、後日、著作権侵害のリスクが発注側にも及ぶ可能性があります。

クリーンルーム手法は、解析チーム（Dirty Room）と開発チーム（Clean Room）を完全に分けて、著作権侵害（依拠性）を回避する手法です。1980年代にフェニックス・テクノロジーズがIBM BIOSを合法的に逆エンジニアリングした際に確立されました。解析チームが作成した仕様書だけを開発チームに渡し、元のソースコードは一切見せない、厳密な運用が求められます。

体制を見極めるには、次の3点を確認します。

社内規定：解析チームと開発チームの分離が、社内規定として文書化されているか
法務・仲介担当者：仕様書に著作権保護対象の表現が混入していないかを確認する担当者が配置されているか
先例を踏まえたリスク管理：セガ対アッコレード事件（1993年）のような先例を踏まえた法的リスク管理ができているか

「クリーンルーム手法を適用する」という言葉だけでなく、具体的な運用プロセスを提示できるかで判断します。

ポイント

VB.net固有の対応実績があり、クリーンルーム手法を自社の運用として示せる発注先を優先します。VB6のリバース実績だけでは、VB.netの逆コンパイル特性を押さえているとは限りません。

RFP作成と契約

発注先候補が絞り込めたら、RFP（提案依頼書）を作成して各社に提案を求めます。

VB.netのリバースエンジニアリングのRFPには、通常のシステム開発とは異なるVB.net固有の情報を必ず含めます。契約段階での法的リスク管理も欠かせません。

RFPのVB.net固有記載事項

RFPには、次に挙げるVB.net固有の情報を必ず記載します。

対象システムの概要：業務機能・規模・稼働年数
.NETのバージョン：VB.netおよび.NET Frameworkのバージョン（2.0〜4.8 / .NET 5以降を区別）
VB6コンポーネント：有無と概要（COMインターオペラビリティの有無）
ファイル数と推定LOC：業務ロジック部分と全LOCの両方
その他の情報：難読化ツールの適用有無、既存ドキュメントの有無と種類、データベーススキーマの構造（SQL Server等）

成果物の要件も、具体的に書きます。フローチャート、業務仕様書、詳細設計書のどのレベルが必要かを明記し、「新システム開発の要件定義に直接使えるレベル」という品質基準を言葉にします。

C#への移行を想定するなら、次の項目を追加します。

テストケース仕様書：作成の有無
動作保証テスト費用：言語変換後の費用の明示
変換後コードの保守性基準：変数名復元・コメント生成の有無

ベンダーには、VB6混在システムの対応実績とクリーンルーム手法の運用体制の詳細を、提案書に明記するよう求めます。業務部門へのヒアリング実施方法と頻度、VB6コンポーネント発見時の追加費用算定方法も、あわせて示してもらいます。そのため、各社の対応力を比較しやすくなります。

NDA・クリーンルーム手法の条項

VB.netのリバースエンジニアリングを発注する場合、契約段階での法的リスク管理が不可欠です。リバースエンジニアリングの過程では、ソースコード・業務データ・ビジネスロジックへのアクセスが発生するため、まずNDA（秘密保持契約）を締結します。NDAには、秘密情報の定義と利用目的の制限（解析業務のみに限定）を盛り込みます。加えて、漏洩時のペナルティと、契約終了後の情報返却・廃棄義務も含めます。

次に、クリーンルーム手法の適用を契約条項として明記することをお勧めします。条項には、次の3つのプロセスを含めます。解析チームが作成した仕様書のみを開発チームに引き渡し、法務・仲介担当者が、著作権保護対象の表現が混入していないかを確認します。さらに、仕様書には純粋な機能・アルゴリズムの記述のみを含め、元ソースコードの表現は含めないことです。こうした条項で、後日の法的トラブルを防ぎます。

さらに、「非享受目的」（著作権法第30条の4）での解析であることを示すため、解析過程の記録やレポートの作成・保存を義務付ける条項も有効です。解析専用のパソコンで実行し、解析過程をレポートに記録しておけば、後から「機能享受目的ではない」ことを立証できます。そのような体制を整えておくことが必要です。

ポイント

RFPにはVB.net固有の情報を書き、契約ではNDAとクリーンルーム手法の条項を先に整えます。VB6コンポーネントが後から見つかった場合の費用の決め方を契約時に合意しておけば、後の食い違いを減らせます。

プロジェクト推進の役割分担

三者の担当をWBS上で並べると、責任範囲を共有できます。

VB.netのリバースエンジニアリングプロジェクトを円滑に進めるには、業務部門・IT部門・ベンダーの三者で役割を明確に分け、それぞれの責任範囲を事前に決めておく必要があります。

三者の連携がうまく機能しないと、成果物の品質低下や工期の長期化は避けられません。

3者（業務部門×IT部門×ベンダー）WBS

プロジェクト開始前に、業務部門・IT部門・ベンダーの三者でWBS（Work Breakdown Structure）を共同で作成することを推奨します。このWBSを契約書の附属資料として添付しておくと、責任範囲の認識のずれを防げます。

WBSでは、どの作業をどの側が受け持つかを、担当ごとに割り当てて示します。

ベンダー（解析）：対象ソースコードの受領と環境構築、静的解析（逆コンパイル・制御フロー解析・データフロー解析）
ベンダー（追加解析・仕様書）：VB6コンポーネントのCOM解析と動的解析、仕様書ドラフトの作成・修正
IT部門（資料・環境）：ソースコード・実行ファイル・関連ライブラリを暗号化して安全に転送する
IT部門（進行）：データベーススキーマやテーブル定義を渡し、スケジュール管理と進捗確認、ベンダーと業務部門の橋渡しを担う
業務部門（ヒアリング・承認）：週1〜2回のヒアリングに対応し、仕様書ドラフトを承認する

動的解析は、デバッガによる実行トレースで行います。仕様書ドラフトは週次の業務部門ヒアリングを経て仕上げ、その際のクリーンルーム手法の記録も保持します。

解析に必要な開発環境は、Windowsバージョン・.NET Frameworkバージョン・SQL Serverバージョン等を含めて提供します。

業務部門は、ヒアリングで業務ロジックの意図や背景を説明し、現行機能の要否を判断して不要な機能を特定します。

業務ロジックのWhy復元のための業務部門協力

VB.netのリバースエンジニアリングで業務ロジックの「意図（Why）」を復元するには、コードの技術的な解析に加えて、業務部門の知見が要ります。たとえば、ある計算式がなぜその係数を使っているのか、ある分岐条件がどのビジネスルールに基づくのかは、コードから読み取れない情報です。こうした情報は、業務部門のキーパーソンへのヒアリングによってのみ補えます。

コードから「どう動くか（How）」はベンダーが解析できても、「なぜそうなのか（Why）」は業務部門の協力なしには復元できません。そのため、発注前に業務部門の協力体制を確保することが必須です。

具体的には、次の4点を確保すると効果的です。

担当者の確定：ヒアリング対応が可能な担当者を、発注前に確定させる
対象者のリストアップ：対象システムの業務を最もよく知る社員（元担当者・長期利用者・業務責任者）を挙げる
ヒアリング時間の確保：プロジェクト期間中に週数時間のヒアリング対応ができる体制を、事前に確保する
週次の回答サイクル：ベンダーが「コードを読んで疑問に思った箇所のリスト」を週次で提示し、業務部門が翌週までに回答する

業務部門の担当者が解析工程で積極的に関与するかどうかが、最終的な成果物の品質を最も左右する要因です。協力が得られない場合、成果物は「どう動くかはわかるが、なぜそうなのかがわからない仕様書」になり、後の新システム開発で業務ロジックの誤解によるバグが多発するリスクが高まります。

ポイント

業務部門、IT部門、ベンダーの責任範囲をWBSの段階で揃えておくことが土台になります。業務部門が週次のヒアリングに応じられるかは、早めに決めておく必要があります。

よくあるトラブルと回避策

VB.netのリバースエンジニアリングの発注では、決まったトラブルのパターンが繰り返し起きています。事前に知っておけば、回避するか、影響を小さく抑えられます。なかでも、VB.net固有のトラブルは、VB6との混在による見積もりの食い違いと、変換後コードの保守性問題の2つで、どちらも必ず押さえておく必要があります。

VB6/VB.net混在システムの見積齟齬

最も多いトラブルは「見積もりと実際の費用の食い違い」で、VB6/VB.net混在システムではこのリスクが特に高まります。主な原因は次の2つです。

デザイナーコードによるLOCの膨らみ：Visual Studioが自動生成するデザイナーコードがLOCに大量に含まれる
VB6コンポーネントの後発見：プロジェクト開始後にVB6で開発されたCOM DLLの存在が判明すると、追加工数が大幅に発生する

デザイナーコードの例を挙げると、「実際の業務ロジックは5,000行だが、デザイナーコードを含めると30,000行になる」というケースもあります。そのため、LOC従量課金で見積もりを取る際は、「業務ロジック部分のLOC」と「全LOC（デザイナーコード含む）」を分けた見積もりを提示するよう、発注前に確認してください。

VB.netとVB6は解析手法が根本的に異なるため、VB6のCOMインターオペラビリティ部分には、.NETの逆コンパイラとは別のアプローチが必要です。そのため、追加費用は単純なLOC比例では算定できません。その場合の追加費用の算定方法を、契約時に合意しておくことが大切です。

さらに、LOC従量課金の「罠」として、VB.netの1万行とCOBOLの1万行では、複雑さも1行の意味も全く異なります。言語やコンポーネントの種別ごとに適正単価を確認し、行数だけで見積もるベンダーには注意が必要です。

変換後コードの保守性問題

VB.netのリバースエンジニアリングで「仕様書は完成したが、新システムを開発できる品質ではなかった」という保守性の食い違いは、深刻なトラブルです。

逆コンパイルで得たコードをそのまま仕様書に転記しただけの成果物には、次のような問題が出るケースがあります。

変数名：IL（中間言語）レベルの抽象的な名称のまま（「var_1」「field_2」等）残っている
業務ロジックの意図：説明がないフローチャートだけになっている

技術的には「解析完了」でも、実用に耐えない品質です。この問題を防ぐには、発注前に「成果物のサンプル」を提示してもらい、品質水準を事前に確認することが有効です。特にC#移行を想定した発注では、変換後コードの保守性基準として、「変数名の意味的復元」「業務ロジック背景（Why）のコメント記述」「スパゲティコード化の解消」の3点を成果物要件に明記するよう推奨します。

機械変換だけに頼ったC#変換では、変換後コードが若手エンジニアで保守可能な品質にならない可能性が高いです。そのため、変換後の動作保証テスト費用を見積もりに明示させることも大切です。成果物の品質基準（「新システム開発の要件定義に直接使用できるレベル」など）を契約書に明記しておけば、判断基準が明確になり、納品後のトラブルを未然に防げます。

ポイント

見積もりの食い違いは、LOCの内訳とVB6コンポーネントの有無を発注前に示してもらうと減らせます。変換後の保守性は、基準を成果物要件に書いておくことが効果的です。

まとめ

発注前チェックリストと成功のポイント

VB.netのリバースエンジニアリングを外注で成功させるため、発注前に確認したい点をチェックリストとして整理します。

準備段階では、次の点を確認します。

ソース資産の棚卸：ファイル数、LOC概算、業務ロジックLOCと全LOCの区別
VB6コンポーネントの有無：GACに登録されたCOM DLLとCOMインターオペラビリティの有無
.NET Frameworkバージョン：使っているバージョンを確認する
目的と成果物要件：フローチャート、業務仕様書、詳細設計書のどのレベルが必要かを明確にする
業務部門の協力体制：ヒアリング対応者を確定させる

発注先の選定では、VB.net（VB6ではなく）のリバースエンジニアリング実績と、VB6混在システムの対応実績を確認します。さらに、クリーンルーム手法の具体的な運用プロセスを提示できるかと、成果物サンプルの品質を必ず確かめます。

RFP作成では、VB.net固有情報（.NETバージョン・VB6混在有無・難読化有無・LOC概算）を記載し、C#移行を想定する場合は、動作保証テスト費用の明示も求めます。

契約と推進では、次の点を押さえます。

契約：NDAを締結し、クリーンルーム手法を条項に入れる
成果物と追加費用：成果物の品質基準を明記し、VB6コンポーネント後発見時の追加費用算定方法を合意しておくことが必須です
役割分担：業務部門（Why提供）、IT部門（技術情報・進捗管理）、ベンダー（技術解析・成果物作成）
進め方：三者でWBSを共同作成し、週次のヒアリングサイクルを設定すると、プロジェクトを成功へ導けます

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

開発を相談する前に、次の無料ホワイトペーパーもご活用ください。
【2026年最新版】AI駆動開発の完全ガイドブックをご覧いただけます。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。