ドキュメントが存在しないレガシーシステムをどう刷新するか、あるいは既存ソフトウェアの仕様を正確に把握したいというニーズは、多くの企業で切実な課題となっています。リバースエンジニアリングは、ソースコードや実行バイナリから設計情報・業務ロジックを逆方向に復元する技術であり、適切な手順を踏まなければ大きなリスクを抱えることになります。本記事では、リバースエンジニアリングの進め方を工程ごとに詳しく解説し、失敗しないための実務的なポイントをお伝えします。

リバースエンジニアリングは技術的な側面だけでなく、法的・組織的な準備が不可欠です。静的解析と動的解析の組み合わせ方、成果物の粒度設定、外注か内製かの判断基準まで、プロジェクトを成功させるための全体像を網羅的に解説します。特に「コードは読めたが業務ロジックの意図が分からなかった」という典型的な失敗パターンを避けるための具体的な対策も紹介します。

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

リバースエンジニアリングの全体像

リバースエンジニアリングとは、完成品から設計情報・仕様・構造を逆方向に復元するプロセスです。ソフトウェア分野では、ソースコードや実行バイナリを解析し、設計書や業務仕様書を再構築することを指します。製品の改善や互換システムの開発、セキュリティ脆弱性の発見、そしてレガシーシステムのモダナイゼーションが主な用途です。

ソフトウェアのリバースエンジニアリングには大きく分けて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つの工程を順守することで、プロジェクトのスコープを適切にコントロールできます。

最初の工程は「対象システムの選定」と「目的の言語化」です。モダナイゼーション目的であれば「どの業務機能を優先して復元するか」、セキュリティ診断であれば「どの攻撃面を検証したいか」を事前に明確化します。対象範囲が曖昧なままだと、LOC（行数）ベースで見積もりを取った際にスコープが際限なく膨らむ「LOC見積の罠」に陥ります。目的が確定したら、次に解析ツールと環境を整備します。ツール選定の実務的な判断基準として、API・スクリプティング重視ならBinary Ninja、チーム協調解析ならGhidra（NSA開発の無料OSS）、逆コンパイラ品質を最優先するならIDA ProかBinary Ninjaが最適です。いずれのツールも、本解析用に隔離された専用環境（仮想マシンまたは物理的に分離されたPC）を用意することが、法的リスク管理上も重要です。

静的解析は、プログラムを実際に実行せずにソースコードやバイナリを調査する手法です。逆コンパイル（デコンパイル）や逆アセンブル（ディスアセンブル）を通じて、制御フローグラフやデータフローを分析します。Java・C#のような中間言語（IL/バイトコード）ベースのシステムは比較的高品質に復元できますが、COBOLやネイティブCコンパイラの出力は変数名が消失し「意味のない変数名の羅列」になるケースが多く、静的解析だけでは業務ロジックを理解するのに限界があります。動的解析は、デバッガを使ってプログラムの実際の実行状態をリアルタイムに追跡する手法です。x64dbgなどのデバッガを使い、関数の入出力値、メモリの変化、API呼び出しの連鎖を追跡することで「実際の処理の流れ」を把握できます。静的解析と動的解析は相互補完的な関係にあり、どちらか一方だけでは不完全なケースが多いため、両手法を組み合わせることが一般的な実務です。

解析で得た生の情報は「実装レベル」の情報です。これを「設計レベル」さらに「仕様レベル」へと段階的に抽象化していく工程をDesign Recoveryと呼びます。実装レベルでは変数の値や関数の呼び出し関係が分かるだけですが、設計レベルではモジュール構成やデータモデルが見え、仕様レベルでは「この機能は何のためにあるか」という業務目的が明確になります。この抽象化プロセスで特に重要なのが「業務部門の協力」です。ソースコードから分かるのはHow（どう動くか）であり、Why（なぜその仕様か）は元の業務担当者や業務ドキュメントなしには復元できません。成果物化の工程では、フローチャート・業務仕様書・詳細設計書の3段階の粒度を事前に合意した上で作成します。フローチャートは最もシンプルで安価ですが、新システム開発には不十分なケースが多く、画面遷移図やDB設計を含む詳細設計書レベルまで求めるのか、依頼前に明確にしておくことが見積もり齟齬を防ぐ上で欠かせません。

リバースエンジニアリング固有の注意点と失敗パターン

リバースエンジニアリングプロジェクトには、技術的な課題と組織的な課題の両方が伴います。典型的な失敗パターンを事前に把握しておくことで、プロジェクトを適切にコントロールできます。

「コードは読めたが業務ルールの意図が分からず、移行後にバグが多発した」というケースが最も典型的な失敗です。ソースコードにはHow（処理の流れ）は記録されていますが、Why（なぜその処理を行うか）は業務担当者の頭の中にしか存在しないことが多いからです。特にCOBOLやPL/Iで書かれた30年以上稼働し続けたシステムでは、当時の業務担当者が既に退職していることも多く、業務ロジックの「意図」が完全に消失しているケースがあります。このリスクを軽減するには、解析工程と並行して現役の業務担当者へのヒアリングセッションを設けることが不可欠です。もう一つの失敗パターンは「変換後コードの保守性」の問題です。機械的な逆コンパイルで生成されたコードは変数名が意味不明な文字列になり、コメントも存在しないため、若手エンジニアでは保守できないスパゲティコードが生まれます。発注前に「変数名の復元」「コメントの自動生成」「業務ロジック背景のドキュメント化」を成果物要件に含めるよう、契約段階で明確にしておくことが重要です。

難読化（Obfuscation）が施されたコードは、逆コンパイルしても制御フローが意図的に複雑化されており、解析に多大な工数がかかります。制御フロー平坦化という手法では、本来シンプルなif-else分岐が多数のダミー条件分岐で包まれるため、正規のコードと囮コードを区別するだけで膨大な時間が必要です。暗号化されたソースコードや実行時に復号される構造のプログラムは、理論的には復元できても実用的な工数に見合わないケースがあります。これが「リバースエンジニアリングの技術的限界」であり、難読化・暗号化が強固なほど費用と期間が跳ね上がる要因です。見積段階で対象コードの難読化レベルを事前確認し、工数に反映させることが重要です。

法的リスクの回避：著作権法・クリーンルーム手法

リバースエンジニアリングは適切に実施すれば合法ですが、対象や目的によっては著作権法・不正競争防止法・特許法に抵触するリスクがあります。法的リスクを正確に理解し、適切な手続きを踏むことがプロジェクトの継続性を守ります。

2018年（平成30年）の著作権法改正により、第30条の4が新設され、「著作物に表現された思想又は感情の享受を目的としない利用」については権利者の許諾なく著作物を利用できることが明確化されました。マルウェア解析・セキュリティ調査・仕様書復元・互換性確保などを目的とするリバースエンジニアリングは、この「非享受目的」に該当するとして原則合法化されています。ただし「非享受目的」であることを事後的に立証できる体制を整えておくことが重要です。具体的には、解析専用のパソコンを用意して解析のみに使用することと、解析過程をレポートや作業ログに記録しておくことが有効な立証手段となります。EULAに「リバースエンジニアリング禁止」条項がある場合でも、互換性確保のために不可欠な場合や独占禁止法上の不公正な取引方法に該当する場合には、その条項が無効とされる可能性があります。

クリーンルーム手法とは、解析チーム（Dirty Room）と開発チーム（Clean Room）を完全に分離し、開発チームは解析チームが作成した仕様書のみを見て新システムを開発するアプローチです。1980年代のフェニックス・テクノロジーズ対IBM BIOS訴訟で確立されたこの手法は、著作権侵害における「依拠性」（元のコードに依拠して複製したという事実）を回避するための実務的な方法です。重要なのは、解析チームと開発チームの間に「法務・仲介担当者」を配置し、仕様書に著作権保護の対象となる「表現」が混入していないかを検査することです。純粋な「機能」「アルゴリズム」「業務ロジック」のみが仕様書に記載されていることを確認した上で、開発チームに引き渡します。外注ベンダーを選定する際は、このクリーンルーム手法を自社のプロセスとして運用している実績があるかを必ず確認すべきポイントです。

外注 vs 内製の判断軸とROI分水嶺

リバースエンジニアリングを外注するか内製するかは、技術力と費用対効果の両面から判断する必要があります。また、既存システムをリバースして刷新するのか、ゼロから新規開発するのかの判断も、プロジェクトの成否を大きく左右します。

外注が適切なのは、対象言語・プラットフォームに精通した専門家が社内にいない場合、法的リスク管理（クリーンルーム手法）を自社で担える体制がない場合、そして短期間での成果が求められる場合です。特にCOBOL・PL/Iといったレガシー言語は国内でも経験者が激減しており、内製対応は現実的ではないケースが多いです。一方、内製が適切なのは、自社製品のセキュリティ自己診断（ペネトレーションテスト）や、既存システムの保守担当者が業務を継続する中で逐次的に仕様書を整備するような継続的な取り組みです。内製の場合でもGhidraのような無料ツールを活用することでコストを抑えられますが、習得コストと解析精度の限界には注意が必要です。セキュリティ専門企業と業務システムSIerでは得意領域が異なり、マルウェア解析・IoT機器解析はセキュリティ専門企業に、レガシーシステムのモダナイゼーションは業務SIerへの依頼が基本的な使い分けの方針です。

リバースエンジニアリングを活用したモダナイゼーションと、ゼロからの要件定義による新規開発のどちらが優れているかは、現行システムの状態によって大きく異なります。現行システムに有効な業務ロジック（生存率が高い）が多く含まれており、かつドキュメントが失われている場合は、リバースエンジニアリングによる業務ロジック復元が投資対効果の高い選択です。一方、現行システムが「過去の遺物」的な機能を多数抱えており、それらを移植することがかえってコストの無駄となる場合は、スクラッチ開発が合理的です。判断のフレームワークとして有効なのは、「現行機能のうち新システムでも必要な機能の割合（業務ロジック生存率）」を事前調査することです。生存率が60%以上であればリバース活用、40%以下であれば新規開発が一般的な目安となります。いずれの場合も、不要な機能まで移植して開発コストが膨らむリスクへの対策として、現行機能の要否判定を業務部門と共同で実施する「機能棚卸し」の工程を設けることを推奨します。

費用相場とコストの内訳

リバースエンジニアリングの費用は、対象システムの規模・言語・目的・成果物の粒度によって幅があります。概算費用を把握した上で、適切な予算計画を立てることが重要です。

ソースコード解析による仕様書復元はLOC（行数）ベースの従量課金が一般的です。市場相場は基本料金として30万円（4,000行まで）、超過分は1行あたり50円程度が目安となります。具体的な事例を挙げると、ECサイトの商品登録機能（約10ファイル・4,000行）で約30万円、API連携システムの外部I/O項目リスト化で約50万円、WordPressポータルサイトのCMS構造解析で約60万円、在庫予約システム（約30ファイル・セキュリティ確認含む）で約80万円という相場感があります。

ここで注意が必要なのが「LOC課金の落とし穴」です。COBOLの1万行とReactの1万行では、1行あたりの情報密度も複雑さも全く異なります。COBOLは1行に複数の業務ロジックが詰まっているケースが多く、Reactのような宣言的フレームワークはコード行数が少なくても実際の処理が複雑なものがあります。行数だけで見積もりを取るベンダーは、言語特性を無視したLOC単価を適用するリスクがあるため、言語ごとの適正単価レンジを事前に確認することが重要です。また、特急料金として通常の短納期化は総額の20〜30%増、超特急（休日・深夜対応）は40〜60%増が相場となります。

リバースエンジニアリングを入り口とするレガシーシステムのモダナイゼーション全体では、手法によって費用規模が大きく異なります。リホスト（単純移行）は数千万円〜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事業会社出身のプロフェッショナルが「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を創業。