「仕様書のないレガシーシステムを、このまま塩漬けにし続けるコストはどのくらいなのか」「リバースエンジニアリングを実施した後、費用は本当にそこで終わるのか」――ドキュメントが失われた老朽化システムを抱える情シス部門にとって、こうした費用面の見通しは刷新・移行の意思決定を左右する重要な論点です。リバースエンジニアリングとは、ソースコードや実行バイナリを解析し、失われた設計情報・業務仕様を逆方向に復元する、刷新・移行プロジェクトの前段に位置する分析・調査工程です。この工程には一時的な解析費用だけでなく、実施後に発生する継続費用、そして実施しなかった場合に静かに膨らみ続ける放置コストという、複数の費用の層が存在します。
本記事では、リバースエンジニアリングの保守・運用費用・ランニングコストについて、一時費用としての解析費用の内訳、実施後に発生する継続費用（復元仕様書のメンテナンス・解析ツールのライセンス費用）、そして実施を先送りした場合に発生する「見えない保守コスト」までを、具体的な費用感とともに整理して解説します。目先の解析費用だけでなく、中長期での総費用（TCO）の視点から判断材料を得たい方に向けた内容です。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・リバースエンジニアリングの完全ガイド
リバースエンジニアリングとは何か（保守運用費用の観点から捉える理由）
リバースエンジニアリングは、ソースコードや実行バイナリを解析して業務仕様書・設計書を復元する取り組みであり、新しいシステムを構築するわけではないため、通常の「保守・運用費用」という言葉のイメージとは少し異なる費用構造を持ちます。稼働中のシステムのように毎月のサーバー費用や保守契約が発生し続けるわけではなく、多くの場合は一定期間で完了するプロジェクト型の取り組みです。しかし、その解析結果である復元済みドキュメントをどう維持管理するか、解析に用いたツールのライセンスをどう継続するか、そして何よりリバースエンジニアリングを実施せず現状を放置し続けた場合にどれだけの保守コストが積み上がるかという視点まで含めて考えると、これは立派な「費用」のテーマになります。
ブラックボックス化したレガシーシステムに潜む「見えない保守コスト」
仕様書が失われ、ソースコードだけが頼りの状態で運用され続けているシステムは、表面上の保守費用（保守契約料や監視費用）以上に、目に見えないコストを蓄積しています。改修のたびに影響範囲の調査に想定以上の時間がかかること、担当できるエンジニアが限られ属人化が進むこと、障害発生時の原因特定に長時間を要することなどが、実質的な保守コストを押し上げています。リバースエンジニアリングは、この見えないコストの根本原因である「仕様が分からない」という状態そのものを解消するための投資と位置づけることができます。
本記事で扱う3層の費用構造
リバースエンジニアリングの費用を正しく理解するには、(1)解析そのものにかかる一時費用、(2)解析完了後に発生する継続費用、(3)解析を実施しなかった場合に膨らみ続ける放置コスト、という3つの層に分けて考える必要があります。多くの企業は(1)の一時費用だけを見て「高い・安い」を判断しがちですが、(2)と(3)を含めた中長期の総費用で比較しなければ、本当に合理的な意思決定はできません。以下、この3層構造に沿って順に解説していきます。
リバースエンジニアリングにかかる費用の内訳（一時費用）
継続費用や放置コストを考える前提として、まずは解析そのものにかかる一時費用の相場を押さえておきましょう。
LOC課金の仕組みと相場
ソースコード解析による仕様書復元は、LOC（行数）ベースの従量課金が業界標準です。市場相場は基本料金として30万円（4,000行まで）、超過分は1行あたり50円程度が目安となります。規模で見ると、小規模プロジェクト（ECサイトの一機能やAPI連携システムなど）は30〜80万円、中規模プロジェクト（1〜10万行程度の業務システム）は300〜800万円、大規模プロジェクト（10万行以上の基幹システム）は1,000万円を超えるケースも珍しくありません。ただし、COBOLやPL/Iのようなレガシー言語は標準単価の1.5〜2倍になるなど、言語によって単価が補正される点に注意が必要です。
成果物粒度別の費用差
成果物としてどこまでの粒度を求めるかによっても費用は変動します。処理の大まかな流れを図示するフローチャートレベルは標準LOC課金の50〜70%程度、各機能の処理内容・入出力項目・業務ルールを文書化する業務仕様書レベルは標準の100%、画面遷移図やDB設計まで含む詳細設計書レベルは標準の150〜250%が目安です。目的が単なる現状把握なのか、新システム開発にそのまま使える情報が必要なのかによって、適切な粒度を選ぶことが一時費用の最適化につながります。粒度を必要以上に高く設定すると初期費用は膨らみますが、後述するように、粒度が低すぎると継続費用や放置コストの面でかえって割高になることもあるため、バランスの見極めが重要です。
リバースエンジニアリング実施後の保守運用費用（継続費用）
リバースエンジニアリングは一度実施すれば費用が完全にゼロになるわけではなく、その後も緩やかに継続する費用が存在します。この継続費用を見落とすと、後になって想定外の支出が発生することになります。
復元した仕様書のメンテナンスコスト
せっかく解析によって復元した業務仕様書や設計書も、その後のシステム改修に合わせて更新し続けなければ、数年のうちに再び実態と乖離した「使われないドキュメント」になってしまいます。これは、リバースエンジニアリングによって一度は解消したはずの「仕様書散逸問題」が再発するリスクであり、復元したドキュメントを「生きた資料」として運用し続けるための体制づくりが必要です。具体的には、改修案件が発生するたびに該当箇所のドキュメントを更新するルールを社内規程に組み込むこと、ドキュメントの更新履歴を管理する担当者を明確にすることが有効です。この運用コストは、解析費用そのものと比べれば小さいものの、継続的に発生する費用として計画に織り込んでおくべきです。
解析ツールのライセンス継続費用
内製での解析体制を継続する場合、解析ツールのライセンス費用も継続的なコストになります。Ghidraのように無料で利用できるオープンソースツールもありますが、IDA ProやBinary Ninja、CAST Imagingといった商用ツールは年間ライセンス費用が発生し、機能や解析対象の幅が広がるほど費用も高くなります。単発のプロジェクトであれば外部ベンダーに委託してツール費用を都度の見積もりに含めてもらう方が合理的なケースが多い一方、継続的にレガシーコードの解析・保守を行う体制を社内に持つのであれば、ツールライセンスへの年間投資として予算化しておく必要があります。どちらの体制を取るかは、自社で今後どの程度の頻度で解析作業が発生するかの見込みに応じて判断します。
リバースエンジニアリングを行わなかった場合の放置コスト
費用対効果を正しく判断するためには、リバースエンジニアリングを「実施した場合の費用」だけでなく、「実施せず先送りした場合に発生し続ける費用」も比較する必要があります。
属人化・緊急対応による割増コスト
仕様書がない状態が続くと、システムの内部構造を理解しているのは限られた担当者だけという属人化が進みます。その担当者が不在であったり、退職してしまったりした場合、障害対応や緊急の改修を外部の技術者に依頼せざるを得なくなり、通常の解析よりも大幅に割高な緊急対応費用（特急対応の場合、通常の20〜60%増が相場）が発生します。また、レガシー言語を扱える技術者は国内でも希少性が高まっており、緊急時に確保できる人材が限られる分、単価も高止まりしやすい傾向にあります。計画的にリバースエンジニアリングを実施し、仕様を可視化しておくことは、こうした緊急対応の割増コストを回避するための予防策としても機能します。
先送りするほど膨らむ複利的コスト構造
リバースエンジニアリングの先送りコストは、時間が経つほど直線的にではなく複利的に膨らんでいく傾向があります。システムが稼働し続ける限り改修は積み重なり、仕様と実態の乖離はさらに広がります。当時の業務担当者が退職すれば、業務ロジックの「意図」は完全に失われ、後から復元しようとしても既存ドキュメントやヒアリング先が存在しない分、解析コストそのものも上昇します。経済産業省のDXレポートが指摘する「2025年の崖」も、こうしたレガシーシステムへの対応の先送りが将来的に大きな経済損失につながるという警鐘です。現時点でのリバースエンジニアリング費用を「高い」と感じても、数年後に同じ作業を行うコストと比較すれば、早期着手の方が結果的に安く済むケースが多いことを理解しておく必要があります。
保守運用費用を最適化する実務ポイント
一時費用・継続費用・放置コストの全体像を踏まえた上で、実際に費用を最適化するための実務的なポイントを整理します。
内製と外注のハイブリッド体制
すべてを外部ベンダーに委託すると一時費用が高くなりがちですが、すべてを内製化しようとすると専門人材の採用・育成コストと解析ツールのライセンス費用がかさみます。現実的な最適解は、高度な専門性が要求される解析作業（難読化解除・ホスト固有仕様の解読など）は外部ベンダーに委託し、成果物の整理やドキュメント化の一部、その後の継続的なメンテナンスは社内担当者が担うハイブリッド体制です。これにより、外注費用を抑えつつ、復元した仕様書を継続的に更新していく体制を社内に残すことができます。
段階的発注によるコストコントロール
全機能を一括で解析対象にするのではなく、優先度の高い業務機能から段階的に発注する方法も、費用を平準化する上で有効です。まず重要度の高い一部の機能を先行して解析し、成果物の品質やベンダーとの相性を確認した上で次のフェーズを発注すれば、初期投資のリスクを抑えられます。また、断片的にでも残っている過去の仕様書・設計書・操作マニュアルを事前に社内で収集・整理してベンダーに提供することで、解析工数そのものを削減し、見積もり金額を下げることも可能です。複数社から相見積もりを取り、言語補正や成果物粒度、継続費用の見込みまで含めた条件を横比較することも、費用を適正化する上での基本動作といえます。
まとめ
本記事では、リバースエンジニアリングの保守・運用費用・ランニングコストについて、(1)一時費用としてのLOC課金の相場と成果物粒度別の費用差、(2)実施後に発生する継続費用（復元仕様書のメンテナンスコストと解析ツールのライセンス費用）、(3)実施を先送りした場合に膨らみ続ける放置コストという3層の費用構造で解説しました。目先の解析費用だけを見て判断するのではなく、この3層すべてを含めた中長期の総費用で比較することが、合理的な意思決定につながります。
先送りコストは複利的に膨らんでいく性質を持つため、「今はまだ大丈夫」という判断が数年後に大きな負担となって返ってくるケースは少なくありません。内製と外注のハイブリッド体制、段階的な発注、残存ドキュメントの事前整備といった実務的な工夫で費用を最適化しながら、早めに信頼できるパートナーへ相談することをお勧めします。
▼全体ガイドの記事
・リバースエンジニアリングの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。