リバースエンジニアリングは、対象の選定から成果物化まで6つの工程を順に進めて、設計情報や業務ロジックを復元していく取り組みです。
技術面に加えて法的・組織的な準備も欠かせず、目的が曖昧なまま解析を始めると、費用をかけても「結局何が分かったのか」という結果になりがちです。
- 対象選定とツール準備
- 静的解析・動的解析・抽象化
- 法的リスクとクリーンルーム
- 成果物化と外注・内製の判断
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
リバースエンジニアリングの全体像
リバースエンジニアリングとは、完成品から設計情報や仕様、構造を逆方向にたどって復元する作業です。ソフトウェアの分野では、ソースコードや実行バイナリを解析し、設計書や業務仕様書を再構築することを指します。
主な用途は、製品の改善や互換システムの開発です。このほか、セキュリティ脆弱性の発見や、レガシーシステムのモダナイゼーションにも使われます。
リバースエンジニアリングの定義と主な用途
ソフトウェアのリバースエンジニアリングには、大きく分けて3つの主要な用途があります。一つ目は「レガシーシステムのモダナイゼーション」で、設計書が失われたCOBOLやPL/Iで書かれた基幹システムの業務ロジックを復元し、新しい技術基盤への移行を実現します。
二つ目は「セキュリティ診断・脆弱性発見」で、マルウェア解析や自社システムへの攻撃経路の特定に活用されます。三つ目は「仕様書・マニュアルの再構築」で、引き継ぎドキュメントが不十分なシステムの仕様を明文化し、保守性を向上させます。いずれも、「現状把握ができていない」という課題への解決策として機能します。
言語・プラットフォーム別の特性と難易度の違い
リバースエンジニアリングの難易度と適切なアプローチは、対象となる言語やプラットフォームによって大きく異なります。たとえば、レガシー言語（COBOL / PL/I / C言語）は、独自ミドルウェアやホスト固有仕様がブラックボックス化しており、バイナリ解析が中心となります。
中間言語（C# / Java / VB.net）は、IL（中間言語）からの逆コンパイルで比較的ソースに近い形まで復元できます。ただし、変数名の消失やロジックの断片化によって、スパゲティコード化するリスクがあります。
PHPやPythonなどのスクリプト言語は、そもそもソースが読める場合が多いため、「逆コンパイル」より「難読化解除」や「設計意図の解読」が主題となります。一方で、Web・モバイル系（React / iOS / Android / Flutter）は、Web API通信の解析やFlutter特有のDart言語バイナリ構造への対応が必要で、最新の専門知識が求められます。
リバースエンジニアリングの6工程
リバースエンジニアリングのプロジェクトは、工程を明確に管理して進めることが成功の鍵です。目的が曖昧なまま解析を始めると、膨大なコストをかけたにもかかわらず「結局何が分かったのか」という状況に陥ります。そのため、6つの工程を順に進めることで、プロジェクトのスコープを適切にコントロールします。
工程1：対象選定・目的明確化 ／ 工程2：解析環境・ツール準備
最初の工程は、対象システムの選定と目的の言語化です。モダナイゼーションが目的なら「どの業務機能を優先して復元するか」、セキュリティ診断なら「どの攻撃面を検証したいか」を事前に明確にします。対象範囲が曖昧なままだと、LOC（行数）ベースで見積もりを取った際にスコープが際限なく膨らむ「LOC見積の罠」に陥ります。
目的が確定したら、次に解析ツールと環境を整備します。ツールは、重視する点によって選ぶのが実務的です。API・スクリプティング重視ならBinary Ninja、チーム協調解析ならGhidra（NSA開発の無料OSS）、逆コンパイラの品質を最優先するならIDA ProかBinary Ninjaが最適です。
どのツールを使う場合も、本解析用に隔離された専用環境（仮想マシンまたは物理的に分離されたPC）を用意することが、法的リスク管理の面でも重要です。
工程3：静的解析 ／ 工程4：動的解析
静的解析は、プログラムを実際に実行せずにソースコードやバイナリを調べる手法です。逆コンパイル（デコンパイル）や逆アセンブル（ディスアセンブル）を通じて、制御フローグラフやデータフローを分析します。Java・C#のような中間言語（IL/バイトコード）ベースのシステムは、比較的高品質に復元できます。
ただし、COBOLやネイティブCコンパイラの出力は、変数名が消失して「意味のない変数名の羅列」になるケースが多く、静的解析だけでは業務ロジックを理解するのに限界があります。一方、動的解析は、デバッガを使ってプログラムの実際の実行状態をリアルタイムに追跡する手法です。
たとえば、x64dbgなどのデバッガを使い、関数の入出力値、メモリの変化、API呼び出しの連鎖を追跡することで、「実際の処理の流れ」を把握できます。静的解析と動的解析は相互補完的な関係にあり、どちらか一方だけでは不完全なことが多いため、両方を組み合わせるのが一般的な実務です。
工程5：抽象化（Design Recovery） ／ 工程6：成果物化
解析で得た生の情報は「実装レベル」の情報です。これを「設計レベル」、さらに「仕様レベル」へと段階的に抽象化していく工程を、Design Recoveryと呼びます。実装レベルでは変数の値や関数の呼び出し関係が分かるだけですが、設計レベルではモジュール構成やデータモデルが見えてきます。
仕様レベルまで進むと、「この機能は何のためにあるか」という業務目的が明確になります。この抽象化の過程で特に重要なのが、業務部門の協力です。ソースコードから分かるのはHow（どう動くか）であり、Why（なぜその仕様か）は、元の業務担当者や業務ドキュメントがなければ復元できません。
成果物化の工程では、フローチャート・業務仕様書・詳細設計書の3段階の粒度を、事前に合意したうえで作成します。フローチャートは最もシンプルで安価ですが、新システム開発には不十分なケースが多くあります。そのため、画面遷移図やDB設計を含む詳細設計書レベルまで求めるのかを、依頼前に明確にしておくことが、見積もりの食い違いを防ぐうえで欠かせません。
リバースエンジニアリング固有の注意点と失敗パターン
リバースエンジニアリングのプロジェクトには、技術面と組織面の両方の課題が伴います。典型的な失敗パターンを事前に知っておけば、プロジェクトを適切に管理できます。
典型的な失敗パターン：業務ロジックの意図が復元できないケース
「コードは読めたが業務ルールの意図が分からず、移行後にバグが多発した」というケースが、最も典型的な失敗です。その理由は、ソースコードにHow（処理の流れ）は残っていても、Why（なぜその処理を行うか）は業務担当者の頭の中にしか存在しないことが多いからです。
特にCOBOLやPL/Iで書かれた30年以上稼働したシステムでは、当時の担当者がすでに退職していることも多く、業務ロジックの「意図」が完全に消失しているケースがあります。このリスクを軽減するには、解析工程と並行して現役の業務担当者へのヒアリングを設けることが不可欠です。
もう一つは「変換後コードの保守性」です。機械的な逆コンパイルで生成されたコードは、変数名が意味不明になり、コメントもないため、若手エンジニアには保守しにくいスパゲティコードが生まれがちです。発注前に「変数名の復元」「コメントの自動生成」「業務ロジック背景のドキュメント化」を成果物要件に含め、契約段階で明確にしておくことが重要です。
難読化・暗号化への対処と技術的限界
難読化（Obfuscation）が施されたコードは、逆コンパイルしても制御フローが意図的に複雑にされており、解析に多大な工数がかかります。たとえば、制御フロー平坦化という手法では、本来シンプルなif-else分岐が多数のダミー条件分岐で包まれるため、正規のコードと囮コードを区別するだけで膨大な時間が必要です。
また、暗号化されたソースコードや実行時に復号される構造のプログラムは、理論的には復元できても、実用的な工数に見合わないケースがあります。これが「リバースエンジニアリングの技術的限界」で、難読化や暗号化が強固なほど、費用と期間が跳ね上がる要因です。
発注側は、見積もりの段階で対象コードの難読化レベルを事前に確認し、工数に反映させることが欠かせません。
法的リスクの回避：著作権法・クリーンルーム手法
リバースエンジニアリングは、適切に実施すれば合法です。ただし、対象や目的によっては、著作権法・不正競争防止法・特許法に抵触するリスクがあります。そのため、法的リスクを正しく理解して必要な手続きを踏むことが、プロジェクトを継続するうえで欠かせません。
著作権法第30条の4と「非享受目的」の要件
2018年（平成30年）の著作権法改正で第30条の4が新設され、「著作物に表現された思想又は感情の享受を目的としない利用」は、権利者の許諾なく著作物を利用できることが明確になりました。マルウェア解析やセキュリティ調査、仕様書の復元、互換性の確保などを目的とするリバースエンジニアリングは、「非享受目的」に該当するため、原則として合法とされています。
ただし、「非享受目的」であることを事後に立証できる体制を整えておくことが不可欠です。具体的には、解析専用のパソコンを用意して解析のみに使うことと、解析過程をレポートや作業ログに記録しておくことが、有効な立証手段になります。
EULAに「リバースエンジニアリング禁止」の条項があっても、互換性確保のために不可欠な場合や、独占禁止法上の不公正な取引方法に当たる場合には、その条項が無効とされる可能性があります。
クリーンルーム手法の実務：解析チームと開発チームの完全分離
クリーンルーム手法は、解析チーム（Dirty Room）と開発チーム（Clean Room）を完全に分け、開発チームは解析チームが作成した仕様書のみを見て新システムを開発する方法です。この手法は1980年代のフェニックス・テクノロジーズ対IBM BIOS訴訟で確立され、著作権侵害における「依拠性」（元のコードに依拠して複製したという事実）を回避するための実務上の手段です。
重要なのは、解析チームと開発チームの間に「法務・仲介担当者」を配置し、仕様書に著作権保護の対象となる「表現」が混入していないかを検査することです。そのうえで、純粋な「機能」「アルゴリズム」「業務ロジック」だけが仕様書に記載されていることを確認し、開発チームに引き渡します。
外注ベンダーを選ぶ際は、このクリーンルーム手法を自社のプロセスとして運用している実績があるかを、必ず確認すべき点です。
外注 vs 内製の判断軸とROI分水嶺
リバースエンジニアリングを外注するか内製するかは、技術力と費用対効果の両面から判断する必要があります。また、既存システムをリバースして刷新するか、ゼロから新規開発するかの判断も、プロジェクトの成否を大きく左右します。
外注が適切なケースと内製が適切なケース
外注が適切なのは、対象言語・プラットフォームに精通した専門家が社内にいない場合や、法的リスク管理（クリーンルーム手法）を自社で担える体制がない場合です。また、短期間での成果が求められる場合も、外注を選ぶ理由になります。
特にCOBOL・PL/Iといったレガシー言語は、国内でも経験者が激減しており、内製対応は現実的ではないケースが多いです。一方、内製が適切なのは、自社製品のセキュリティ自己診断（ペネトレーションテスト）や、既存システムの保守担当者が業務を継続する中で逐次的に仕様書を整備するような継続的な取り組みです。
内製でもGhidraのような無料ツールを使えばコストを抑えられますが、習得コストと解析精度の限界には注意が必要です。また、セキュリティ専門企業と業務システムSIerは得意領域が異なるため、マルウェア解析やIoT機器解析は前者に、レガシーシステムのモダナイゼーションは後者に依頼するのが基本です。
スクラッチ開発 vs リバース活用モダナイゼーションのROI判断
リバースエンジニアリングを活用したモダナイゼーションと、ゼロからの要件定義による新規開発のどちらが優れているかは、現行システムの状態によって大きく異なります。現行システムに有効な業務ロジック（生存率が高い）が多く含まれ、かつドキュメントが失われている場合は、リバースエンジニアリングによる業務ロジック復元が投資対効果の高い選択です。
一方、現行システムが「過去の遺物」といえる機能を多く抱えていて、それらを移植するとかえってコストの無駄になる場合は、スクラッチ開発が合理的です。判断の枠組みとして有効なのは、「現行機能のうち新システムでも必要な機能の割合（業務ロジック生存率）」を事前に調べることです。
この生存率が60%以上であればリバース活用、40%以下であれば新規開発が一般的な目安となります。いずれの場合も、不要な機能まで移植して開発コストが膨らむリスクへの対策として、現行機能の要否判定を業務部門と共同で実施する「機能棚卸し」の工程を設けることを推奨します。
費用相場とコストの内訳
リバースエンジニアリングの費用は、対象システムの規模や言語、目的、成果物の粒度によって幅があります。そのため、概算費用を把握したうえで、予算計画を立てる必要があります。
LOC課金の相場と「落とし穴」
ソースコード解析による仕様書復元は、LOC（行数）ベースの従量課金が一般的です。市場相場は基本料金として30万円（4,000行まで）、超過分は1行あたり50円程度が目安となります。
LOC課金で見積もる場合の金額は、対象の機能や規模によって次のように分かれます。
- ECサイトの商品登録機能：約10ファイル・4,000行で、約30万円
- API連携システムの外部I/O項目リスト化：約50万円
- WordPressポータルサイトのCMS構造解析：約60万円
- 在庫予約システム：約30ファイル、セキュリティ確認を含み、約80万円
- 特急料金：通常の短納期化は総額の20〜30%増、超特急（休日・深夜対応）は40〜60%増
COBOLの1万行とReactの1万行では、1行あたりの情報密度も複雑さも異なり、ここに「LOC課金の落とし穴」があります。実際に、COBOLは1行に複数の業務ロジックが詰まりやすく、Reactは行数が少なくても処理が複雑なことがあります。行数だけで見積もりを取るベンダーは、言語特性を無視したLOC単価を適用するリスクがあるため、言語ごとの適正単価レンジを事前に確認することが重要です。
モダナイゼーション全体の費用規模：手法別比較
リバースエンジニアリングを入り口とするレガシーシステムのモダナイゼーション全体では、手法によって費用規模が大きく異なります。リホスト（単純移行）は数千万円〜1億円台で、期間は3〜6ヶ月が目安です。
リプラットフォームは1億円〜3億円で6〜12ヶ月、リファクタリングは2億円〜5億円で12〜18ヶ月です。リビルド・リライトは5億円以上で、18ヶ月以上が目安となります。
セキュリティ・脆弱性診断では、自動ツール診断が10〜30万円、手動診断（標準）が50〜150万円です。モバイルアプリ（iOS / Android）での診断は、両OS対応で工数が倍増し、50〜250万円の範囲となります。
まとめ
リバースエンジニアリングを成功させるには、対象選定から成果物化までの6つの工程を適切に進めることが前提です。そのうえで、業務部門の協力を得ながら「Why（業務ロジックの意図）」まで復元することが、最も大切です。
技術的な解析と並んで、法的リスク管理（著作権法30条の4・クリーンルーム手法）と成果物の粒度合意も、プロジェクトの品質と安全性を左右します。
言語・プラットフォームによって難易度とアプローチが大きく異なります。LOC課金は、言語特性によって単価が大きくぶれる点にも注意が必要です。さらに、「変換後コードの保守性」を成果物要件に含めることは、後々の保守コスト削減に直結します。
外注先を選ぶ際は、対象言語の実績、クリーンルーム体制、業務部門との協業実績の3点で評価し、信頼できるパートナーとプロジェクトを進めることを推奨します。
全体ガイドとして、リバースエンジニアリングの完全ガイドもあわせてご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。